AGILE TESTING is a method of software testing that follows the principles of agile software development. Unlike the Waterfall software development model, the Agile software development model demands that testing be conducted at the initial stages of (almost parallel to) development. Agile testing is not sequential (that it be done only after coding is complete) but is a continuous process.
- agile testing: Testing practice for a project using Agile software development methodologies, incorporating techniques and methods, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm.
Agile Testing vs Waterfall Testing
|AGILE TESTING||WATERFALL TESTING|
|Test planning is minimal and the test process less structured.||
Test planning is thorough and the test process highly structured.
|Testing is conducted at the beginning of (almost parallel to) software development. In other words, testing is incremental and continuous.||
Testing is conducted only after the completion of coding. In other words, testing is sequential.
|There is very limited test documentation.||
Test documentation, like test plan and test cases, are very elaborate.
|Requirement changes being frequent poses a challenge to testing. As the project progresses, one needs to adapt (maybe even improvise.)||
Requirement changes being less likely eases the testing process.
|Acceptance testing is conducted at the end of each iteration / sprint. Customer feedback is continuous and SURPRISES come in small packages which can be dealt with easily.||
Acceptance testing is conducted only at the tail end of the project. Customer feedback arrives late and the risk of getting a BIG SURPRISE, probably with huge costs involved, is high.
|Testers and developers work closely. Both of them assume the role of PARTNERS in QUALITY.||
Testers and developers work separately. Testers assume the role of GATEKEEPER of QUALITY.
This article on Agile Testing assumes that you already understand Agile software development methodology (Scrum, Extreme Programming, or other flavors of Agile).
Agile Testing Manifesto
This is adapted from agilemanifesto.org and it might look a little silly to copy everything from there and just replace the term “development” with “testing” but here it is for your refreshment.
We are uncovering better ways of testing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile Testing Values
- Individuals and interactions over processes and tools: This means that flexible people and communication are valued over rigid processes and tools. However, this does not mean that agile testing ignores processes and tools. In fact, agile testing is built upon very simple, strong and reasonable processes like the process of conducting the daily meeting or preparing the daily build. Similarly, agile testing attempts to leverage tools, especially for test automation, as much as possible. Nevertheless, it needs to be clearly understood that it is the testers who drive those tools and the output of the tools depend on the testers (not the other way round).
- Working software over comprehensive documentation: This means that functional and usable software is valued over comprehensive but unusable documentation. Though this is more directed to upfront requirement specifications and design specifications, this can be true for test plans and test cases as well. Our primary goal is the act of testing itself and not any elaborate documentation merely pointing toward that goal. However, it is always best to have necessary documentation in place so that the ‘picture’ is clear and the ‘picture’ remains with the team if/when a member leaves.
- Customer collaboration over contract negotiation: This means that the client is engaged frequently and is closely in touch with the progress of the project (not through complicated progress reports but through working pieces of software). This does put some extra burden on the customer who has to collaborate with the team at regular intervals (instead of just waiting till the end of the contract, hoping that deliveries will be made as promised). But this frequent engagement ensures that the project is heading in the right direction and not toward the building of a frog when a fish is expected.
- Responding to change over following a plan: This means accepting changes as being natural and responding to them without being afraid of them. It is always nice to have a plan beforehand but it is not very nice to stick to a plan, at whatever the cost, even when situations have changed. Let’s say you write a test case, which is your plan, assuming a certain requirement. Now, if the requirement changes, you do not lament over the wastage of your time and effort. Instead, you promptly adjust your test case to validate the changed requirement. And, of course, only a FOOL would try to run the same old test case on the new software and mark the test as FAIL.
Principles Behind Agile Testing Manifesto
Behind the Agile Testing Manifesto are the following principles which some agile practitioners, unfortunately, fail to understand or implement. We urge you to go through each principle and digest them thoroughly if you intend to embrace Agile Testing. On the right column, the original principles have been re-written specifically for software testers.
|We follow these principles:||What it means for Software Testers:|
|Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.||Our highest priority is to satisfy the customer through the early and continuous delivery of high-quality software.|
|Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.||Welcome changing requirements, even late in testing. Agile processes harness change for the customer’s competitive advantage.|
|Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.||Deliver high-quality software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.|
|Business people and developers must work together daily throughout the project.||Business people, developers, and testers must work together daily throughout the project.|
|Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.||Build test projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.|
|The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.||The most efficient and effective method of conveying information to and within a test team is a face-to-face conversation.|
|Working software is the primary measure of progress.||Working high-quality software is the primary measure of progress.|
|Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.||Agile processes promote sustainable development and testing. The sponsors, developers, testers, and users should be able to maintain a constant pace indefinitely.|
|Continuous attention to technical excellence and good design enhances agility.||Continuous attention to technical excellence and good test design enhances agility.|
|Simplicity–the art of maximizing the amount of work not done–is essential.||Simplicity–the art of maximizing the amount of work not done–is essential.|
|The best architectures, requirements, and designs emerge from self-organizing teams.||The best architectures, requirements, and designs emerge from self-organizing teams.|
|At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.||At regular intervals, the test team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.|
The Recurring Question
So what happens to all the traditional software testing methods, types and artifacts? Do we throw them away?
Naaah! You will still need all those software testing methods, types, and artifacts (but at varying degrees of priority and necessity). You will, however, need to completely throw away that traditional attitude and embrace the agile attitude.
Last Updated on August 31, 2020 by STF