The essence of Agile development is delivering working software frequently. Ever since this methodology has been introduced, there is a new way of doing things, and this also has influenced the role of not just developers, but also QA testers and other team members.

Let us first quickly go through the differences between Agile and Waterfall development –

  • Agile is all about time-boxed development. Sprints (development cycles) are usually 2-4 weeks long and limited in scope. Waterfall development cycles span across many months.
  • Continuous integration with daily /weekly deployments or code compilation. Because of this, the software is constantly changing. In the waterfall model, the code is compiled after it’s fully developed.
  • Requirements /Scope are smaller in Agile to fit each Sprint. This gives flexibility for the client to change requirements and prioritize the scope for upcoming Sprints. Waterfall is more structured where the requirements /scope is fully defined and enforces strict Change management rules.
  • Though Agile has gained considerable momentum and popularity, there are challenges. And we will look at these from a QA /Tester’s perspective. Correspondingly, let’s also look at some solutions that may help overcome (if not completely) the challenge –

    Changing requirements

    Challenge:As requirements are added /updated /removed, it directly affects the scope of testing. User stories may change or be dropped mid-sprint which in turn impacts the test cases that need to be prepared and executed, which may be frustrating at times.

    Solution: Since quality is a shared ownership, the developers too need to be involved early in testing. Testers should keep updated notes on what is and not done. This will help to make informed decisions and avoid releasing incomplete software.
    The statement – “Change is inevitable” should be understood by one and all in the team.

    Loss of focus

    Challenge: The activities carried out by the Tester during the Sprint is manifold – discuss with BA on stories w.r.to current and future sprint, Work on RCA (root cause analysis) for broken build, setup test environment and prepare test data, review test cases for Unit /integration /Regression tests, be available during production release.
    This will certainly result in testers go off-focus.

    Solution: Implement automation wherever possible, for example – running regression tests. Developers can use code analyzers to minimize the defects caught during testing. A thorough understanding of the product outcome and regular discussions with the client and/or product owner helps plan your activities well.

    Broken build

    Challenge: With code changing very frequently, there is a high chance that a build might break thereby affecting the functionality. This will not only result in increased time and effort to fix the issue but also impact the trust with the client who is expecting a working software after each sprint.

    Solution: The cause of this could be us being resource-constrained, lack of quick problem solving, inadequate test coverage. The one solution to these is probably Automating your build. This certainly needs the effort to revisit the test cases, but you can be sure your builds will run successfully.

    Detecting defects early in the Sprint

    Challenge: It’s expensive to fix defects towards the end of the sprint cycle. Due to the shorter span of Sprint (2-4 weeks), it may sometimes become challenging to identify all relevant defects and fix them for the next upcoming build.

    Solution: Scope your requirements and testing to fit the Sprint. If you feel that a requirement may not fit into the sprint due to its magnitude of effort and complexity, discuss with the team, product owner and pre-empt it to the next Sprint.
    It may also be worthwhile to look Exploratory testing during the requirements analysis to list out the potential risks and failure points.
    Developers can make use to third-party tools /plugins to ensure good code quality.

    Owning the Automation testing

    Challenge: probably an intangible one, but quite important – Who really owns the Automation. There may be times when one community of the team tries to treat automation as completely owned by them whereas other teams completely ignore and wash away their hands.

    Solution: the ‘One team’ culture should be reminded daily. Each member should understand the essence of Agile in working as one team and not as individual communities who pass the packet of work after each phase as it happens in the waterfall model.

    Applying continuous testing

    Challenge: Though Agile promotes testing right from the beginning of the Sprint, there may be times when there is a gap, or the testing may not be moving smooth as expected. The causes may be – inadequate understanding of the stories by the testers, difference in the feedback given to developers, lack of active exchange of ideas between the testers and developers.

    Solution: Testers should regularly collaborate with the Product owners to ensure their understanding of the stories are correct. Constant reviews of test cases with all stakeholders, Acceptance criteria for test cases, implementing continuous regression testing via automation.

    Working Agile requires a mindset change. And this change needs 100% support from all stakeholders, especially the senior management to percolate the message on benefits to one and all. This may take some time, but the focus should be lost in the interim.
    The focus of Agile should always be – the Value it will generate for the client or the team.

    [Total: 4    Average: 4.5/5]