In the year 2000, a group of software developers comprising popular computer professionals such as Martin Fowler met and discussed ways to accelerate software development. The objective was to speed up the release of new software.
Less than a year after that meeting, the Agile story was back on the agenda as the same group of 17 developers met again. This is when the "Manifesto for Agile Software Development" emerged, which set out four essential principles. One of the building blocks of Agile Manifesto was "Working Software over comprehensive documentation". What it emphasized was that, the real progress in software development is the software that works, not artifacts. It was a great message considering the world was full of stories about unsuccessful IT projects with extensive documentation.
As a result, many companies that initially adopted Agile reduced or eliminated the generation of IT documentation in areas such as software testing. The core idea was that a small feature will be picked up in sprint and will be developed as well as tested there. The Business Analyst or the product owner will explain the functionality to be developed, the developer will code and the tester will test in the same sprint. This new understanding changed the way Software testing was carried out in many organisations, test artifacts such as the test plan or test strategy were not used. This trend continues even today in a few companies but others produce essential documents. However, the question remains outstanding "Are documentation such as the test strategy is important for Agile projects and if so, what should be included in these". The purpose of this blog is to shed light on this issue to help test leaders and managers especially those who are newly joining or managing agile projects.
To understand the need for a testing strategy in Agile projects, it is important to ask “what is the real purpose of testing?” Well, the real objective is to validate if the built software has met business requirements, has no critical flaws, works well functionally and operationally. As we can see, there are various aspects of the software which should be validated by tests unless the software getting built is extremely simple which rarely is the case. This is not only about functionality the software offers. As an example, if a web application is getting built, there are various aspects that need to be thought well such as how would it deal with security attacks from hackers, how would it behave in different browsers, different operating system, with large number of users etc. All of these things have to be looked at carefully, otherwise there will be disasters. There will also be important considerations from a team and project perspective, such as risks, people, test environments, access, etc., to be managed. That’s where a Test strategy document proves to be very valuable. Different organizations can call it different, some prefer to call it a Test Approach. In agile projects, whatever the name may be, it is always useful to reflect and capture test considerations in a compact document instead of exhaustive documentation as a process.
Below is an agile testing strategy template showing the important aspects that need to be considered to successfully conduct testing and manage all identified risks. No matter what type of document is used, what really matters is the thought process. It’s important to be thinking about important testing aspects such as objectives of testing, kind of testing that needs to be conducted, Project and product risks so that appropriate mitigation plan can be in place, Tools to be used, CI/CD pipelines etc. Successful teams typically consider all of these aspects and plan accordingly before embarking on testing. Therefore, my recommendation is to opt for a minimal test strategy document, but capture all important aspects from a testing perspective to ensure success and minimize failures.
Comentários