There are two ways of improving software product development. The Agile way or the highway. Quality Assurance in Agile software development significantly improves the development process. If it’s implemented from the beginning (while reviewing specification document) and kept until the end (regression and launch testing) it benefits the product. It provides the first and the last line of defense.
In comparison to Waterfall, Agile (especially SCRUM) is a revolutionary approach to software development. SCRUM is the most popular Agile framework, so most people mean SCRUM when thinks about Agile.
To explain, how testing differs between the aforementioned means of software development, we need a short description of them. This is a big change for software developers, but an even bigger change for software testers.
The waterfall is based on a carefully planned project management approach. Each phase is designed and planned at the beginning of the project, and people just follow the plan.
The team follows the instruction of a Project Manager who is superior to team members. The Project Manager follows the check–act pattern (monitors the progress and implements corrective actions if needed). Optimizations are introduced while auditing the project or when quality management indicates that there is an issue to solve.
SCRUM is different. It lets you achieve your business goals quicker and more seamlessly thanks to a more flexible nature. In SCRUM, the emphasis is put on the empirical and adaptive approach instead of long and complicated planning. Teams work in short cycles called sprints. Team members plan each iteration by choosing the items defined by the Product Owner from the Product Backlog and create a dedicated backlog for each iteration (Sprint Backlog). During the iteration, the development team works on the features. The feature is considered done when it fulfills the Definition of Done criteria. Flexibility and the ability to adjust to changing situations are the priorities here.
The main difference in test management between SCRUM and the traditional model is that here we have a designated person, a Test Manager, who is responsible for the testing area. Also, the traditional model uses V-Model for test management. The Test Manager has many responsibilities which can be divided into two main groups:
Agile introduces Quality Assurance very early in the software development process to foresee and spot issues way ahead of their time. It’s mean to eliminate bottlenecks before they even happen – it’s the “minority report” of software development. While everybody is focused on writing code, the QA Specialists are those who anticipate threads that can even derail the project. Therefore Quality Assurance Specialists are those who, by incorporating experiences from previous projects, can actively build the project at hand and improve the future work of the team.
Early testing is only a part of the deal. One of the keys to success is the white-box versus black-box dilemma. Black-Box testing assumes that the team doesn’t have knowledge of a system and its functions. The only knowledge they have is limited to the understanding of what actions the system should perform for the benefit of the user. White-Box testing is like open-heart surgery. It lets the QA team understand the system by peeking under the hood. This method lets the custom software development company prepare better testing scenarios for the future. Even if they will not be handy at the moment, they definitely can prove themselves later.
In SCRUM there are no designated roles, the whole team is responsible for project quality, including testing.
Testers, developers, and business representatives are responsible for the quality at every step of the software development process (this model is often called the power of three or three amigos).
Coding and testing activities take place during the sprint – they are not treated separately. The overall test manager's role is covered by SCRUM testing practices.
Teams are cross-functional but they require a member with dedicated testing expertise. This person is then responsible for designing appropriate risk-oriented tests and implementing them in all sprints. This role also includes advising the Product Owner on QA and product release issues. A tester is also a kind of a QA coach, who explains basics.
Before Product Backlog items may be taken into a sprint, they must be developed and understood by the team. The team role is to ensure that the requirements are concise and understood, and the QA role is to identify missing details or non-functional requirements.
Testing activities take place through iteration, not only at the end. Very often these activities are parallel to programming. Testing activities include both manual and automated testing.
Due to the specifics of the SCRUM projects, programmers mainly focus on creating Unit Tests and testers spend most of their time creating, executing, monitoring, and maintaining automated tests and results. Most of the manual test is done using defect-based and experience-based techniques e.g. exploratory testing. Testers write automated test cases for integration and system testing.
Also the structure of tests in Agile looks different in comparison to the traditional model. The emphasis on automation is far greater than in the traditional model. Efficient SCRUM teams go directly from acceptance criteria in User Stories to automated tests. The test automation provides confidence that the product does what it should and that it is built right.
This leads to a general trend, where testers with strong technical backgrounds are preferred. In fact, the most valuable tester is an automated one. Preferably they have the ability to understand and write the code. In fact, the most valuable software developers and testers are those who are the most versatile.
Automation must be well-thought-out and planned carefully. It takes time to prepare the testing framework but you also need skilled Quality Assurance specialists who are able to create it. In this article, we have described the skills of a highly effective software tester.
The time when automation is introduced must also be suitable because when there are substantial changes made in the System Under Test, it will result in high maintenance cost of the testing framework. With that said, you have to remember that too much automation in testing can lead to a whole new area of problems. The software development partner should be keen on the prioritization of test cases and decide on which of them should be automated. There’s also an additional thing to consider – in some cases, data may change or the testing scenario is not reproducible. Testing under these conditions can alter the data.
There is no doubt that Agile testing improves the software. There are a few lessons that can be drawn from testing in Agile but one seems particularly important. Yes, it’s good to have a specialist focused on automatic testing on board. Yes, they can be a little more expensive. Yes, it’s worth it long-term. If you’re not willing to invest in quality, there will always be another company that delivers your product to the customer, long months after the initial opportunity.