The introduction of ‘Agile testing’, is somewhat understood by those who are at the shallow end of agile methodology as – “less testing”, or “no testing at all”, at times, which is truly a myth. Traditionally, we have seen in Waterfall models that testing professionals were particularly engaged in large numbers, during the final phase of software lifecycles. Although the V model recommends that the testing activities should start right from the beginning of the Requirements-Gathering phase, usually a small number of testing professionals would be engaged then, and their numbers would gradually increase as the project moves towards System Integration functional testing phases.
Unlike the traditional method, in agile testing, both planning and execution are iterative and exercised in as many periodic cycles as possible (sprints), for a project. This would be determined by the number of sprints planned in the project.
Five aspects that stand out about agile testing than historical methods
(1) As agile methodology states in a scrum team (if it is), there should be a BA, a developer and a tester, who can accomplish a user story to the definition of a “done”, state. This clearly states the need for a tester in agile teams at all times.
(2) Where we traditionally had major releases, agile has iterative releases of smaller units of completed works, which means the cycles of functional testing – system integration, User-Acceptance, Regression and any other functional testing required, will have to be performed along with the primary story-testing for each sprint in the release. This clearly shows the importance of testing and resource requirements in agile.
(3) ‘Less documentation’ is a phrase often heard for agile methodology, which does not mean that there is no documentation needed. The test strategy that dictates the test activities has to be defined, which will guide the testing practices to be adhered to and the standards required for reporting purposes. This will be the ‘Definition of Done’ for a ‘user story’ to be set as ‘completed’. This also means the artefacts such as a plan, and test cases remain as previously maintained, however, they are more contained to satisfy the acceptance criteria of the story, which is a smaller unit of the bigger business requirements.
(4) Defects and reporting are always part and parcel of the testing observation outcome. While this is an iterative process, it becomes more relevant to ensure these are kept up-to-date and available when requested.
(5) Traceability of all the testing activities is vital support for any testing professional, which will come in handy during audits.
Exhaustive Documentation
Traditionally, there were overlaps and heavy documentation, which at times were never used, or seen by peers. Especially reports of test activities in the early phase of a project would be just a mere satisfaction of the checklist required. Some even converted the software requirements specifications to testing requirements which to me is better handled by documenting the requirements as user stories in agile. Test case updates would often take a long time, as they were written for the requirements, which are generally bigger than a user story.
Evidence and Documentation of testing are always good when they are maintained to the extent of relevancy, throughout my career, I have seen agile practices have channelized their activities to achieve this goal.
Stability in Resourcing
In order to meet the project deadlines, short-term contract professionals were hired to complete the testing, at times, When testing becomes the bottleneck for a product to be released, to meet the project deadlines, short-term contract professionals were hired, which not only stresses out the test manager to ensure these new professionals are trained and well-informed of the required testing activities but also puts the new professionals in a challenging role to ensure the testing activities are completed to the standards required. On the contrary, agile testing would ensure the resource requirements stay stable as the professionals are required throughout the project. Resource allocation has been more uniform in agile methodology when compared to the waterfall approach. This not only allows the team to grow and perform the required but also IT professionals in testing can achieve their career goals successfully.