How does Agile testing work as an integrated component of development journeys
When working on an Agile project, there is continuous discussion about development processes and timely, iterative delivery to customers. For the most part, Testing is construed, without much thought, to be an ‘included’ part of Agile Development process, just as design and requirements analysis are. Yet the domain of software testing is often ignored, or at the least not paid an equal attention.
There are multiple approaches or frameworks within Agile like SCRUM, Scaled Scrum, Kanban, XP and others. As the complexity of software development processes is increasing continuously, the software testing processes also need to evolve and mature to keep up with the development approaches. Agile testing is a relatively newer approach which focuses on testing smarter rather than investing considerable efforts, all the while delivering high-quality results.
The testers and developers are required to put in higher level of collaboration in Agile Testing. Agile testing is all about seamless integration between development and testing processes; the testers provide corrective feedback to the development team during the development cycle, while the development team reduces probability of high number of defects. Agile testing is a continuous process rather than being sequential. The testing begins at the start of the project and there is ongoing integration between testing and development. The common objective of agile development and testing is to achieve higher quality product, free of defects and errors.
Agile Testing explained: What IS NOT Agile Testing?
Agile methods have been growing in popularity since the first formal adaptations in late 1990s to early 2000s. Agile has its own fan clubs and is fragmented in to practice areas, from simple, single team based Agile Scrum to complex models like SAFe Agile. Besides the more popular Agile methods, there are relatively lesser known yet equally effective methods like Crystal, DSDM and Feature Driven methodology. Regardless of the method, all Agile methodologies share much of the same philosophy and features – regular feedback loops, speed, flexibility, and above all, regular communication and interactions between stakeholders, whose roles have been clearly defined and limited in all Agile methodologies.
Image Source: Clarion Technologies
Traditional testing practices have taken their lead from the Waterfall model of software development, where requirements gathering, software design, and implementation follow a deliberate and often lengthy path. Waterfall methodology has fallen out of favor recently, as Agile is becoming increasingly popular. Despite the tide of time in favor of Agile methods, waterfall testing still exists and in many cases is seen as flourishing. The ‘waterfall testing’ in an Agile implementation is particularly like an island in the middle of water which steadfastly holds its own.
The lack of Agile testing strategy is particularly characterized by two kind of practices. First, reliance on testing as an end point to development. Many development teams still consider testing as a conclusion to development stage. This promotes the view that testing must test the entire user story or feature or MBI or increment produced in its entirety. Secondly, testing at the end of development cycle is seen as merely a rubber stamp activity. Development teams often give impression that they have coded what needs to be coded and testing is merely a formality.
Today as seen in many Agile implementations, development may have moved to Agile however ‘testing at the end of development cycle’ continues to exist in its previous avatar, clearly meaning that Testing has lagged. This kind of hybrid Agile is being followed everywhere, where development stages include everything from high level design to business analysis to client collaboration, only excluding testing. Reasons can be many, perhaps out of convenience and / or ignorance, or perhaps due to simplicity. Perhaps the people did not understand the difference between Agile testing and Waterfall testing, hence just carried over many of the same documents and processes as used in Waterfall. In most cases, testing is simply seen as a control point, or check-gate, rather than treating it as it should be, a value addition activity.
Agile Testing explained: What IS Agile Testing?
So what is Agile testing again? For some reason, people often treat Agile testing as a black box, not knowing what to expect. Agile testing is not a ready made approach, or a set of pre-defined test cases, or pre-determined set of processes. What Agile testing is, like all other Agile processes, an adaptive approach depending on the project and the functionalities being delivered.
There is inbuilt uncertainty in an Agile project. When an Agile project starts, what the final shape of product or what will the system look like, is not known. Agile projects begin with requirements which continue to change till the time product meets acceptance. As a project moves forward, the risk profile of the project changes. At the beginning of a project, the risk profile is higher and as the project moves forward the risk profile grows conservative as there is more at stake during later stages. As the team learns to work together, the team and project dynamics change over time. The timescales change over time; WIP inventory and backlog continues to change over time. Similarly, Agile testing approach also must undergo a change to meet the changing, adaptive requirements of the Agile project. Whatever is the approach being adapted for development processes, testing should follow the same approach.
Image Source: Medium
The below are some rules that may be followed to define Agile Testing approach for the project or the function:
- An iterative approach to test software or product being built to aid meeting project goals
- Less focus on framework and rigid structure; higher focus on adapting to project requirements
- Risk profile -: Agile testing process must adapt to changing project risk profile. Test cases need to build in the amount of risk as per the risk profile at different stages of the project.
- # Defects -: Amount of testing work can change over time as the knowledge of developers increases with time. This may require changes to the testing approach.
- Systems architecture -: may change over time as project moves along. Testing team needs to build or import capabilities to meet this changing profile.
- Timescales -: The timescales themselves change over time. During certain stages in a project, a feature may span multiple sprints, while in other stages there may be multiple features delivered in a single sprint.
- Extra reporting -: another aspect of testing is the usual practice of publishing reports, test plans, templates, processes, etc. The reporting output must adapt to the project and its environment. If the project is unique, documentation may be more than other projects.
- Documentation -: By nature, testing is a process heavily reliant on documentation. This doesn’t mean however that documentation should be a rigid requirement. Changing documentation approach to adapt to project is a facet of Agile testing. For example, if the team uses JIRA or any other tools, then testing process needs to adapt to the same. If the team is using github to upload the test cases, then that’s the approach testing should follow.
- Communication -: there is greater responsibility to use variable communication as demanded by the project environment.
Agile test strategy Is a critical input for not only running effective Agile development processes but it provides excellent support to organization’s DevOps initiative, and the benefits of Agile testing extend beyond the immediate benefits of continuous testing. And continuous testing is vital to improving product quality.
As compared to testing at the end of finishing development, Agile development stresses on early and frequent testing of finished and unfinished code changes. In the world of Agile, testing needs to happen early and often. So, instead of waiting for development to be finished before testing begins, testing happens continuously as components or tasks on a particular user story or feature are completed.
Agile Testing Methodologies
Image Source: Infobeans
Test-Driven Development (TDD) − Test-Driven Development (TDD) is based on coding guided by tests. The word “test” in Test Driven Development may be misleading. The primary goal of Test-Driven Development is to make the code clearer, simple and bug-free. Test-Driven Development starts with designing and developing tests for every small functionality of an application. In TDD approach, first, the test is developed which specifies and validates the intended function of the code being written.
Acceptance Test-Driven Development (ATDD) − Acceptance Test-Driven Development (ATDD) is based on regular communications between end users or customers, developers and testers and driven by pre-defined Acceptance Criteria and Acceptance Test Cases. The thought behind Acceptance-test-driven-development is that user or customer perception of the system or product is just as important as its functionalities, so this perception is ideal to drive performance in order to help increase chances of adoption. To give this idea life, ATDD collects input from end users / customers, uses those input points to develop acceptance criteria, translates that criteria into manual and / or automated acceptance tests and then writes code against those tests. Like TDD and BDD, ATDD is a test-first methodology, not a requirements driven process. Acceptance-test-driven-development generally goes a step further than the regular Test-driven-development or Behavior-driven-development approaches, as it directly goes to the source or – end users and / or customers, to understand the rationale behind the product and how it will be used.
Behavior-Driven Development (BDD) − Behavior-Driven Development (BDD) testing is based on the expected behavior of the software envisaged by the project team. BDD approach is based on same principles as Test Driven Development approach, but instead of unit tests, it calls for testing at higher level, usually at business level. Instead of starting with a technical-facing unit test as in the case of Test driven development, BDD starts with an initial requirement based on end user or customer behavior and calls for tests that are “human readable” and can even replace some requirements documentation. This requirement is based on behaviors that the product should exhibit, creating an airtight guide for engineers to use as they develop tests.
Exploratory Testing -: Exploratory testing gives the testing team and testers an ownership over the code to test it in an organized, yet chaotic way. In exploratory testing, testers are not following documented test steps, but rather exploring the vulnerabilities in the software in imaginable and clever ways to try to break it. Testers document defects as usual, but detailed documentation of what and how the application was tested may not be always provided.
Exploratory testing doesn’t follow a set script or test cases. Rather, it’s about developing the most intuitive tests based on each unique functionality of the software. Because of its unconventional approach, exploratory testing often mimics how users or end customers will interact with the software in real world.
Session Based Testing – Session based testing is a step further than exploratory testing. Session based testing develops on the exploratory testing approach by providing more structure. As exploratory testing is completely unscripted, it relies heavily on the skills and experience of the testing team and testers involved, which is not the best fit always. Session based testing provides structure and accountability by developing a charter for testing and running testing in time-boxed intervals. Additionally, testers are required to report on the testing that took place during each session.
The test process is not a separate process that can be outsourced or left alone, it is merged with the development processes. The true benefits of Agile testing are revealed when it is used as part of Agile development and accorded an equal importance. The sooner testing team and testers get involved, better it is for the project. Ideally, testers should be part of the overall scheme of things from day one, simply because giving testers a seat at the table from the start provides a higher level of insight into requirements and goals, encourages collaboration and helps hammer home the need to conduct frequent, continuous testing.