Author: gradulescu

Agile – Scrum Framework

As I was saying in my previous article, Scrum is an Agile Framework. In other words, a set of rules that are followed in order to implement a product in an Agile environment.

In Scrum, teams work in sprints that usually take like two to four weeks. Each sprint is preceded by a Planning Meeting that has the purpose of prioritizing backlog tasks. During development, the tasks are moved from one status to another into a Scrum Board, that is used to track the evolution of the sprint. At the end of the sprint, the finished tasks are moved into the production environment, and the unfinished ones are moved back to backlog.

Scrum is defined by three main notions: Scrum Principles, Scrum Aspects and Scrum Processes

Scrum Principles

1. Empirical Process Control – emphasizes the core philosophy of Scrum based on three ideas: transparency, inspection, and adaptation.
2. Self-organization – focuses on the idea that workers deliver better results when self-organized and this always translates into a happy customer
3. Collaboration – focuses on the three dimensions related to collaboration: awareness, articulation, and appropriation
4. Value-Based Prioritization – highlights the focus of Scrum on delivering maximum business value, as soon as possible during the Software Development Life Cycle
5. Time-Boxing – describes how time is considered a limiting constraint in Scrum, being used to help manage project planning and execution in a way that best suits the project
6. Iterative Development – emphasizes how to manage changes in a better way and so that we build products that are as close as possible to what the customer wants.

Scrum Aspects

1. Organization – Understanding the roles and responsibilities in a project project which follows the Scrum framework is crucial for a successful implementation of it.
2. Business Justification – It is important that the organization performs a complete and accurate business assessment before starting any project. This helps the people in charge with making decisions to understand why there is a need for change of a product, to be aware of the justification of that change and the team capacity to accomplish this change taking into account given resources.
3. Quality -In Scrum, quality is defined as the ability of a product that was developed to meet customer expectations and to accomplish the requirements defined in the business analysis phase.
4. Change – Every project, regardless of its method or framework used, is prone to change. It is mandatory that the product development team clearly understands that in Scrum there is always room for change
5. Risk – this is a concept defined as an uncertain event that can affect the software development process or the good functionality of a product in a good way or a bad way.

Scrum Processes

Scrum has a total of 19 processes grouped into five phases as follows:

a) Initiate

• Create project vision – The project business case is reviewed to create a Project Vision Statement and the Product Owner is identified.
• Identify Scrum Master and Stakeholders – Based on some selection criteria, the Scrum Master is identified and assigned, as well as the stakeholders (people who are interested one way or another in the product)
• Form Scrum Team – Scrum team members are identified, usually by the product owner. Sometimes, the Scrum Master can also be involved into this process.
• Develop Epics – In this process, the Project Vision statement serves as a basis for creating the Epics (large, unrefined user stories) during what it is called User Group Meetings
• Create a Prioritized Product Backlog – Epics are refined into more specific details and prioritized according to their importance for the project. Also the ‘Done’ criteria (a set of rules that are applicable to all User Stories in a given Sprint)
• Conduct release planning – Scrum Core Team reviews the User Stories in the Prioritised Product Backlog to develop a Release Plannning Schedule.

b) Plan and Estimate

• Create User Stories – User stories and their respective Acceptance Criteria are defined and then incorporated into the Prioritized Product Backlog. User stories are usually written by the product owner and are designed to ensure that the customer requirements are very well understood.
• Approve, Estimate and Commit User Stories – In this process, the product owner approves the user stories for a sprint, and the Scrum Master and Scrum team estimate the effort required in order for the functionality to be created. The Scrum Team commits to develop the customer requirements in the form of Approved, Estimated, and Commited User Stories.
• Create Tasks – The Approved, Estimated and Commited User Stories are compiled into a Task List, usually during a Task Planning meeting.
• Estimate Tasks – The Scrum Core Team estimates the effort required to accomplish each task in the Task List, during a Task Estimation Workshop, creating an Effort Estimated Task List
• Create Sprint Backlogs – In this phase, the Scrum Core Team creates a Sprint Backlog during Sprint Planning Meetings. A sprint Backlog contains all the tasks that should be completed in the sprint.

c) Implement

• Create Deliverables – The Scrum Team Works on the tasks in the Sprint Backlog to create Sprint Deliverables. The progress of the work and activities are recorded into a Scrum Board. Issues encountered by the Scrum Team may be updated into an Impediment Log.
• Conduct Daily Standup – A daily meeting is conducted, having the purpose to let the other team members know about their progress and eventual impediments in finishing the tasks
• Groom Prioritized Product Backlog – The prioritized product backlog is updated and mantained during a prioritized backlog review meeting, in which any changes or updates of the backlog are discussed.

d) Review And Retrospect

• Convene Scrum of Scrums – Scrum Team representatives convene for Scrum of Scrum meetings in which they collaborate and track their respective progress, impediments and dependencies across teams. This Scrum of Scrum meeting is only relevant when there is more than one Scrum Team involved in large projects
• Demonstrate And Validate Sprint – In this process, the Scrum Team demonstrates the Sprint Deliverables to the product owner and the relevant stakeholders in a sprint review meeting. The purpose of a Review Meeting is to secure approval and acceptance of the product or service by the product owner
• Retrospect Sprint – In this process, the Scrum Master and Scrum Team meet in order to discuss lessons learned, which will be documented for further reference. The result of this phase can be some Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations.

e) Release

• Ship Deliverables – Accepted Deliverables are delivered or transmitted to the relevant stakeholders. The successful completion of the sprint is documented into a formal Working Deliverables Agreement.
• Retrospect Project – In this process, organizational stakeholders and Scrum Core Team members assemble to retrospect the project, identify, document and internalize the lessons learned. The lessons might lead to documentation of Agreed Actionable Improvements to be implemented in future projects.

Scrum Definitions

1. Tasks Status

a) Backlog Tasks – A set of functionalities that need to be implemented, gathered into a Management Software in order to have a complete view over what is to be created. The backlog functionalities are collected into a series of tasks that have a status with the same name: backlog. These are the start point in the actual development process. I will try to explain this backlog in terms that are more understandable. Let’s suppose that you bought a house and you want to equip it with some furniture, but you do not have all the money to buy it all at once. So you make a list with items that you wish to buy, imagining how your house will look like. These are the backlog items.

b) To Do Tasks – Now, after creating that list, you want to schedule them on periods. You plan to buy the couch and the chairs in November, the table in January, the kitchen furniture in March etc. I will call these periodes as Sprints. So, the first of November comes, and you mark the November items as To Do. Meaning that you are going to buy them in the close future, but you haven’t started yet. The first sprint starts.

c) In Progress Tasks – Then, on the 15th of November you decide to start shopping, and go buy the couch. At this point, you mark “buying a couch” on your list as In Progress, because you already started searching for a couch.

d) Done Tasks – You have finally found it, and bought it, so you mark “buying a couch” on your list as “Done“.

e) Next, you want to start searching for chairs, but you realise that the couch was very expensive and there were no money left for the chairs, so you change back the status of “buying chairs” on your list to “Backlog“. So basically, this is all you could do of your November plans, meaning that the November sprint has finished, and next sprint is to start.

2. Scrum roles

In Scrum, the roles are divided into two categories:

a) Core Roles

• Product Owner – the person responsible for achieving maximum business value for the project. The Product Owner represents the Voice of the Customer
• Scrum Master – a facilitator who ensures that the Scrum Team is provided with an environment suitable for the completion of the project successfully
• Scrum Team – the group or team of people who are responsible for understanding the requirements specified by the Product Owner and creating the Deliverables of the project

b) Non-Core Roles

• Stakeholders – a collective term that includes customers, users, and sponsors who frequently interract with the Scrum Core Team, and influence the project throughout the project’s development life cycle
• Scrum Guidance Body (SGB) – an optional role, which generally consists of a set of documents and/or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters.
• Vendors – people who provide products and/or services that are not within the core competencies of the project organization

3. Scrum Artifacts

Scrum defines a series of artifacts that are useful throughout the development process:

• Product Vision
• Sprint Goal
• Product Backlog
• Sprint Backlog
• Definition of Done
• Burn-Down Chart
• Increment

From these artifacts, there are three that are defined as primary artifacts in a Scrum framework:

• Product Backlog – an ordered list of features that are needed as part of the end product and it is the single source of requirements for any changes to be made to the product
• Sprint Backlog –  A set of Product Backlog items selected for the current Sprint, plus plans for delivering product increments for achieving Sprint goals
• Increment – The sum of all the Product Backlog items completed during a Sprint combined with the increments of all previous Sprints

Basically these are some basic information about Scrum Agile Framework. I have taken the information about Scrum processes and roles from the SBOK.

You can also use the Scrum guide as a refference for studying Scrum.

I will be back with some detailed explanation about the above terms. Till then, I wish you a magnificent week and good luck with studying Scrum. 🙂

Agile Methodology

Agile is a particular approach to project management that is used in SDLC, which is based on incremental development and step by step product delivery.

It is based on adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change (according to Wikipedia).

Contrary to the Waterfall Methodology, which supposes that each phase is started only after the previous one has been fully completed, Agile states that the project is divided into multiple parts, each part going through each phase, everything being delivered to the client at the end. This way, the client can give early feedback over the product that was created, and the final software can be improved over time.

The Agile software development refers to a process that is aligned with the concepts listed in the Agile Manifesto:

1. Customer satisfaction by early and continuous delivery of valuable software -> Instead of a feedback of the entire product at the end of the development process, the customer specifies exactly what he wants as the product is created, so that improvements can be made every time they are needed
2. Welcome changing requirements, even in late development -> If the customer decides in the middle of the development that he wants some modifications over what he originally requested, this can be done without many approvals, budgeting and other organisational issues that would make this kind of task very difficult in a Waterfall environment
3. Deliver working software frequently (weeks rather than months) -> Many times, a company faces delays, and project risks that were not mitigated. This may cause frustration for the customer, as he expects to see some results. Working in an Agile environment gives him some part of the product, for proving that we are actually working on their needs.
4. Close, daily cooperation between business people and developers -> Daily stand up meetings provide the stakeholders with information regarding the status of the project, the eventual delays, and problems that appeared in the development process. Also, documentation does not stand between effective comunication, so eventual changes do not need to be argued based on documentation.
5. Projects are built around motivated individuals, who should be trusted -> People work in a close collaboration, and every person is involved in the process. Everyone understands what it needs to be delivered, so everyone can come up with improvement ideas.
6. Face-to-face conversation is the best form of communication (co-location) -> People discuss in meetings rather than through documentation and approval software. This encourages engagement and brings people together, connecting them for a better collaboration.
7. Working software is the primary measure of progress -> The progress is not monitored throught test cases executed, passed and failed, but through working software. This is the most important thing when working with Agile.
8. Sustainable development, able to maintain a constant pace -> It is important to avoid bottlenecks and stay on track, mantaining the deadlines as well as the quality of the product.
9. Continuous attention to technical excellence and good design -> The focus is on the team, to make sure they are the best in what they do and, if they are not, they are trained, sustained for evolution
10. Simplicity—the art of maximizing the amount of work not done—is essential -> It is important to create the best product with a limited number of resources, and to create a simple product that would achieve it’s potential without writing 500000 lines of code that would make it not that performant. Less is more.
11. Best architectures, requirements, and designs emerge from self-organizing teams -> Each team should create it’s own pace, deadlines and goals, instead of following some general rules. This way, teams are managed easier and less pron to mistakes.
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly -> Agile is about constantly following the flow of development and adapt based on the results, changing where there is a need for change in order to minimise the effort done and deliver quality results.

How to use Agile

An agile process can be implemented through various frameworks:

• Scrum – a framework in which teams work in sprints that usually take like two to four weeks. Each sprint is preceded by a Planning Meeting that has the purpose of prioritizing backlog tasks. During development, the tasks are moved from one status to another into a Scrum Board, that is used to track the evolution of the sprint. At the end of the sprint, the finished tasks are moved into the production environment, and the unfinished ones are moved back to backlog.

• Kanban – Kanban is the Japanese word for visual signal or billboard. Kanban does not have sprints, being a continuous process. The tasks are aranged into a Kanban Board, similar to a Scrum board, containing four columns: Backlog, To Do, In Progress and Done. Each column can contain one or more tasks. The To Do column is filled in with tasks assigned to a certain developer. As the tasks are gaining progress, they can be moved from one column to another. A Backlog task will be moved to a To Do column when the latter is empty, as well as a To Do task will be moved to an In Progress column when the latter is empty. The top most task is the most important, so it will have the biggest priority.

• Extreme Programming (XP) – a frameork in which teams work in sprints that usually take like one to two weeks. Unlike Scrum, in which the product owner decides the priority of the tasks but the Scrum team decides the items and their execution order, in XP the prioritising is done by the customer, and the order decided by him must be followed by the team. Also, if in Scrum the focus is on the team, roles and how things are done, in XP there is an emphasis on Engineerinng Techniques like BDD, TDD, pair programming, etc (I will explain all this notions in future different articles for better understanding). Better said, it focuses on quality software delivered based on technical emphasis.

• Feature Driven Development (FDD) – FDD was first introduced to the world in 1999 via the book Java Modeling In Color with UML. It is focused on features, which are developed in five steps: model, build the feature list, plan, design, build the future. So instead of focusing on the process and roles as in a Scrum approach, we focus on features that are to be developed. Features are divided in phases of development that usually take no longer than two weeks. Features are usually developed in feature branches that, after development, are merghed into master branches and released to the production environment throguh pull requests (FDD is very neatly explained here)

• Adaptive System Development (ASD) – ASD is based on a repeating set of speculate, collaborate and learn cycles. It is characterised by the fact that it is mission focused, feature based, iterative, time boxed, risk driven and change tolerant. It is an antecedent of Agile Software Development. It is called Adaptive because it is made to…adapt to the change conditions caused by different factors. Technology can go out of date, requirements can change, stakeholders might change their expectations etc.

• Dynamic Systems Development Method (DSDM) – It is a framekwork that shaped the Agile Manifesto, which led to the forming of the Agile Alliance, a nonprofit organization committed to supporting people who explore and apply Agile values, principles, and practices to make building software solutions more effective, humane, and sustainable (according to their site). It is the longest established full project Agile approach, created as an extension of RAD (Rapid Application Development). It is very useful for projects with tight time constraint and low budget, and consists of three phases: Pre-Project, Project Life Cycle, Post-Project.

• Lean Software Development (LSD) – LSD is an Agile framework that focuses on the problems instead of the features, by developing a culture of collaboration and continuous improvement, delivering results in a reasonable amount of time. It is a holistic way of working which gives you the necessary insights for continuous improvement. It is based on various principles that avoid building waste and tries to deliver quality results in a reasonable time.

• Crystal Clear – It is about establishing principles and priorities that would help the team develop a valuable product for the customer, which can bring profit and success. The delivery is pretty frequent, usually taking two weeks or a month, maximum. The team comunicates in daily meetings in order to set goals and track them, and developes strategies for fast delivery. As in Scrum, Crystal Clear focuses on the people and not artifacts, and it has an emphasis on general knowledge. This means that everybody in the team should have the same level of information (technical and business), so that one person can replace a missing other. The levels of crystal method are defined by two facts: what losses can cause the pottential defects and the number of people involved.

So these are basically the most important frameworks for working in Agile.

One short note about Kanban and Scrum, they are the most used Agile frameworks and are defined as pull systems, meaning that they make sure the things to be done (identified by different use cases) are going as fast as possible from Backlog to the Customer and that bottlenecks are prevented. Both have a person to help the development team to adopt and maintain good habits. For Scrum, this person is called a Scrum master and for Kanban is called an Agile Coach.

When to use Agile

• The team is comfortable with change and is open for flexibility
• The project is new, not updated (it works for updated projects too, but new projects are best suited for Agile)
• When tight deadlines and frequent, changes are to be expected
• When fast delivery is more important than quality
• When the team is willing to think outside the box and not following guidelines

Advantages of Agile:

• Nothing is strictly established, so there is always room for easy change and improvement, ensuring the up-to-date of the product that you are building
• Sooner feedback and bigger probability to deliver a quality and useful software
• Constant fixing of problems
• More effective communication

Downfalls of Agile:

• If not throughly managed, you may end up out of budget because of too many changes
• Initial planning might prove unuseful
• The product might deviate from the initial plan

These are some basic information of Agile, that I have decided to share with you, based on what I have learned over time and based on my work experience. If you didn’t quite understand the process of Agile development, don’t worry. I will come back with subsequent articles regarding what each of the above frameworks mean and how would a regular development process look in each of them, so stay tuned.

Waterfall Methodology

I have told you in my previous articole about existing SDLC methodologies that can be used in the software creation process.

This article is the first one in a series of articles that describe in detail the methodologies mentioned before.

I will start with Waterfall methodology, as it is one of the most common and oldest ones (actually, it was the first SDLC model to be used), being encountered in many of the existing companies. It is a pretty inflexible methodology which supposes that all the requirements are well defined before the development start. SDLC phases are followed rigurously at a low level, meaning that each phase starts after the previous one has finished completely. Testing phase usually starts after the development is finished, so the advantage of early testing is not used.

The waterfall SDLC methodology was first introduced by Winston Royce in 1970 and it  was the first public documented life cycle model. 

The waterfall methodology is divided into the following phases:

• Requirements gathering – Define the characteristics of the product and record them into the requirements document
• System Design – Based on the requirements, the company must study the existing resources and decide whether some new hardware is needed or some software upgrades are required
• Implementation and Execution – After the requirements are designed and the system preconditions have been met, the product is created based on the previously created specifications
• Testing – The testing phase follows the implementation step, and has the purpose of finding potential defects of the software and to increase confidence into the end product
• Release – After the testing is complete, the product is released into production, meaning that it is made accessible for the use of the end user
• Maintenance – The process in which we make sure the preconditions in which the software works are met. It could be a hardware upgrade, a software version increase or any other type of maintenance.

Advantages of Waterfall methodology

• Easy to understand
• Easy to use and manage
• Works very well for short projects
• It guarantees predictability, so you can trust the timelines with reduced possibility to exceed deadlines
• You know ever since the beginning what to expect and how would the result will look like
• The entire process is well documented, so any new person being assigned on the project can easily understand what the project to be developed is supposed to do

Downfalls of the Waterfall methodology

• It is very inflexible, so changing the requirements in the middle of the development process is pretty hard
• If you have a high amount of risk that is identified, then waterfall might not be appropriate. A risk might imply changing the requirements and, of course, the code, so that you can mitigate it.
• Defects are only found in the testing phase, when the product is already fully developed. So, instead of creating tests for a single future or module, you create tests for the entire project, which increases the risk of missing something.
• Working software is available late in the SDLC process, so feedback can only be provided from user when many defects already appeared
• Usually a series of test cases is followed blindly, and most of the times the tester doesn’t try to find some other test cases. If he does, this would mean to change the test plan, test deadline, test report, depending of the new number of tests that are to be found, and sometimes additional development resources need to be included in the project
• If a requirements change necessity is detected during the implementation, then most of the times it must be treated as a separate project

When to use Waterfall methodology

• Short projects with a low level of complexity
• Projects with a low level of risk
• Projects where the requirements are very well known ever since the beginning and the probability of requirements changing is small
• The team is experienced and knows very well the technology to be used

Why is it called waterfall? Because the project phases are performed in a linear way, and the output of one phase is the input for the next one, just like the waterfall passes some location coordinates to enter some others.

According to Wikipedia, the earliest use of the term waterfall may have been in a 1976 paper by Bell and Thayer.

If you want to learn more about the waterfall methodology, you could take a look at Software Engineering Methodologies: A Review of the Waterfall Model and ObjectOriented Approach, and of course you could check the official syllabus provided by the ISTQB official website.

I will come back with my next article about the Agile methodology.

SDLC Methodologies

In my previous article, I have told you about Software Development Life Cycle, what it is and what are the roles in an SDLC. In this article I want to tell you about the methodologies that can be used in SDLC.

Let’s start with the beginning, and talk about what a methodology is. According to the Cambridge dictionary, a methodology is a system of ways of doing, teaching, or studying something. Another definition says that a methodology is a set of methods used in a particular area of study or activity. So just to make it simple, a methodology is in my opinion a set of guidelines for studying, teaching, working or performing other activities that need to follow a plan.

In IT, methodologies are a set of strategies and approaches which define the process of developing a software, creating a proper environment for delivering the expected results in the planned timeline.

In SDLC, there are various methodologies that can be used:

1. Waterfall
2. V-Model
3. Incremental
4. RAD
5. Agile
6. Iterative
7. Spiral
8. Prototype
9. DevOps
10. Lean
11. Big Bang

The most common methodologies encountered in SDLC are Waterfall and Agile, but choosing the right one depends on the type of business you have. If for some projects Agile will bring success, for others it could not be such a good idea. So choosing the right methodology is the key to the success of the project.

Things to take into account when choosing the methodology:

• Size of the project – If the project is very large, waterfall might not be very useful, because it is pretty inflexible and hard to manage
• The changes that might appear during the process – If often changes are forseen, then you should choose a more flexible methodology, because changing in the middle of the development process in an inflexible one implies changing documentation, timeline, and even resources, which might increase the actual costs of the project
• Cost of the eventual delivery delays – If the results must be delivered fast, then a methodology to sustain rapidity of the results would be suitable. Otherwise you might come across to making some promises you can’t keep and lose your clients
• The size of the team – The larger the team, the harder to manage. You should take into account assigning tasks, making sure the deadlines are met and that the plan is followed
• The technical knowledge of the team – If you don’t choose the right methodology in this case, you risk having a product that cannot be developed. You must create the proper environment to ensure that the team has the means to study and adapt during development
• Lessons learned from previous projects (if any) – If you have passed through some previous projects, than you should make an analysis. What brought you success, what went wrong, what should you improve?

This are some minimal information about the SDLC methodologies. I will come back with some future articles in which I will provide detailed information about each one, so stay tuned.

Software Development Life Cycle

In your career as a QA you will bump into this process every single day without even realising. What is Software Development Life Cycle? Also known as SDLC, it is the process in which a product is defined, designed, tested and launched into the production environment for the use of the end user. Better said, it is a framework defining the tasks performed at each step in the software development process

The steps of SDLC

• Concept
• Analysis
• Project management
• Business requirements design
• Technical architecture definition
• Technical requirements design
• Implementation
• Testing
• Release

Detailed description of the SDLC steps

• Concept – The concept phase is the one in which the client comes up with the idea of the product. The general expectations are discussed, as well as the necessity of it. Let’s take an example to create a better understanding of this phase. I will make use of Goodreads. Most of you who like reading are aware what this platform is and what can you do with it. Let’s suppose for the sake of argument that this platform doesn’t exist yet. You are the director of a huge publishing house (just as a supposition, I don’t have the slightest idea regarding who initiated Goodreads) and you want to have a site on which authors can publish their own works and readers can keep the count of the books they read. So you come up with the idea and proceed to the next step

• Analysys – You talk to your editors, you decide the necessity of the platform and think that it would be a good way to keep track of all the books you have by author, genre or title, and also offer your clients quizzes, quotes, events and other information they might be interested in. After the idea has been approved by the majority of the people interested in it, the next step comes into the story.

• Project management – It is the phase in which resources are alocated: people, applications, tools etc. Timeline of the project is defined and budget is alocated so the business has control over what to pay.

• Business requirements design – This phase supposes that a dedicated person takes the concept and “puts it on paper” (of course they are stored on electronic devices, we don’t live in the 19th century any more, but put it on paper sounded good). So this is the phase in which the final idea starts to gain a form. The business analyst must be sure to define all the functionalities that are expected from the final plarform. Every single button, every single filtering and every single text on the page must be documented. Every single non documented requirement is a not created requirement and a not created requirement is an unhappy client.

• Tehnical architecture definition – In this step, normally an application architect analyses the requirements and their impact over the system. It updates the system architecture schema, makes sure that technical requirements are correctly defined, but also discusses with all the people involved into the process, making sure that deadlines are met and client exectations are fulfilled. I don’t know exactly all the responsabilities that an IT architect has, as architecture is the only phase I haven’t been directly involved in. From my observations, the responsabilities of an IT architect sometimes interwine with the ones of an IT manager. Correct me if I am wrong.

• Technical requirements design – This is the step where the project technical definition is created. So basically a technical analyst is a person that tells the developer what is needed from a technical point of view. It could be a new table in a database, a new report, a new connection between two systems or a simple data transformation. Think about the construction of a building . The owner requires a new building, the architect creates the building schema for the engineer and the engineer tells the workers how to create the rooms, how to paint the walls, where to put a door and where to leave the entrance open,where to put parquet and where to put floor tiles. So basically, a technical analyst is like that engineer.

• Development – After the technical analysys is done, the developer takes the requirements and developes the application. In this phase, beside the direct requirements of the technical analyst, the developer must take into account also the additional needs for creating the product. They have to define the sources for the tables, create the necessary procedures, define the connections, take into account performance, security etc, and put these information together (for knowledge about tables and procedures and what are they used for, I recommend you techonthenet.com).

• Testing – After the product/application has been developed, it must be sent to the testing team (or QA team) for review. The role of the tester is to try to pass through as many scenarios as possible. He has to think about everything that the end user might try, every situation that could cause problems and put himself into the shoes of the end user. Returning to that Goodreads platform, a tester has to make sure that he can add books, filer them by name, title, author, genre, create quotes, mark a book as read, reading or want to read and many other functions that could be tried by the end user. He is responsible with the finding of product defects and reporting them to the development team. After the testing is complete and the product is ready to use, the next final phase starts.

• Release – Is the process of putting the application/product into the production environment. What is a production environment? It is the fancy naming of launching the product to the market. If before the release the only people having access to that product were the ones that were developing/testing it/other people in the company, after the release the final client also has access to it. And returning again to Goodreads, if John Nash, a random reader from Canada would have tried to access goodreads.com before the release, he would have received a message: “This site can’t be reached“. But after being released, John Nash would have seen the homepage of Goodreads.com and would have been able to use it, add books as an author, mark books as read and use some other functionalities that have been defined.

Are all the above steps used?

Well, it depends on the company. Generally speaking, all the above steps are used in big companies, corporations, but they can also be used in medium companies. It all depends on the structure. Sometimes the business analyst and technical analyst are one and the same person, sometimes they don’t exist and their job is done by the development team. The same thing happens with the IT architect. He is not always present in a company. Who will always exist in an SDLC are the business owners, development and testing team.

Why do we need SDLC?

Well, it is because we need some control over what happens when developing a product. If we don’t use some guidelines and don’t have some goals to reach, then everybody would do what he or she thinks and in the end we will have a product that is not working, or even worse, a product that is working but does completely other things than expected. You can find a picture with what happens many times even in a SDLC process:

This image has already become viral in the IT world, and it reflects pretty well the reality. So basically this is why we need SDLC. To make sure that image one actually coincides or it is at least close to image twelve.

When to use SDLC?

Allways. It is a useful solution for delivering the right results and have a control over the development process. It is a guideline that will help you deliver the right results in the expected time.

How to use SDLC?

There are various methodologies that can be used with SDLC like Waterfall, Agile, V-Model, Incremental etc. But I will discuss them in the next articles in more detail while leaving you read, understand and remember what I have told you in this one.

What is QA?

I will start my first blog article with an introduction to QA. As much as a QA tester might laugh at the fact that some don’t know the answer to this question, it is absolutely normal for somebody who has never interacted with this domain and never thought he or she would.

So, QA stands for Quality Assurance and is the process of testing an application, web site, game or any other product that one wants to launch for own use or sell it as an individual product to the public.

Usually the QA phase is the subsequent of development and there are dedicated people who perform this kind of task. In order to become a software tester, first of all you need to want to do so and be motivated. You can’t be a good software tester if your motivation is “I want to do this because they pay good” or “I want to do this because I can’t do something else”. I mean at the beginning might be a good motivation, but unless you start to enjoy what you are doing, you won’t be able to be a great tester. Good, yes, but not great.

QA is about searching, investigating, being patient and being willing to dig up until you find the problem, or at least until you do everything you can for it. And moreover, QA is about breaking an application into pieces and actually being glad to do it. Why? Because if you don’t, the end user will and it will be thousand times worse if he does.

People often ask me: what does it take to be a QA? Well, there are many qualities you need to have. Below you can find a graphic with what it takes to be a QA Analyst.

• patient
• willing to novelty
• solution driven
• passionate
• ambitious
• motivated
• team player
• attentive to details
• pron to constructive criticism

Probably there are more qualities, I mean there certainly are, but these are the ones that come to my mind for the moment. It sounds like a job interview, doesn’t it? Well it might, but knowing these makes you prepared for that interview you are so unpatiently wating for. Don’t worry if you don’t have all those qualities. Some can be developed throught time. And for those that cannot, there are solutions that can cover up that lack so you can enjoy a happy successful life as a Software Tester.

Do I have all those qualities? Maybe I do, maybe I don’t. I would have to ask my boss for this. My personal opinion would be that I don’t. I don’t think I am a great tester. As a matter of fact, I think that there are few actually great, amazing testers on the QA market. But I do my job and I always try to improve myself. I think this is what actually matters in the end. Nobody demands perfection. Employers usually demand from you willingness to be provoked, to search for information when you don’t know and to deliver results in time. So if this is what you are doing now, it is more than enough.

The most important thing to remember about being a QA tester is that testing can’t be learned over night. It takes practice, patience and ambition. If you wait long enough and study long enough you will get to the top of the QA members.

So, you may ask, what future brings you the Software Testing? Here is a schema I have designed for you to understand how you can grow in this field, professionally speaking.

As you can see, you can start as a Junior QA Engineer, then climb up the lader until the point where you will have to choose the direction, whether being a QA architect or a QA manager. Honestly, I haven’t seen in Romania available QA architect jobs, but it seems that the position actually exist, so if you scroll that job application and see this, you’d better know where it is actually positioned in the QA hierarchy. Whatever the path you want to choose, you will have to know that climbing up the professional lader of QA means taking on more responsabilities and working more. So you will have to think carefully before making the decision of accepting a higher role. As appealing as it would sound l and as much as it would tickle your ego, a higher position implies stress, responsability and a lot of work. It is wonderful if you can do it and be successful with it, but if you don’t, going back to a lower level might have a pretty harsh psychological impact over you. You don’t want that, so be patient. Think throughly before accepting any offer and remember that the most important thing is for you to feel good and accomplished. It matters neither other’s opinions nor demonstrating something. The only thing that matters is you.

So that being said, I will leave you play your game…pardon, prepare yourself to be a Software Engineer and hope this article brought some light for you about what Software Testing really is. I will come back with a series of articles in which I will provide a more detailed approach into testing, so keep in touch.