Testing Services provides a platform for QA professionals to discuss and gain insights in to the business value delivered by testing, the best practices and processes that drive it and the emergence of new technologies that will shape the future of this profession.

« Top 4 cost hurdles while doing on premise testing | Main | Dynamic systems can't have static solutions »

Testing for an Agile Project - Cool breeze in Summer


For a software testing professional, working in an agile project is no less than a breeze of cool air in the hot summer. The point that I am trying to drive is that for a tester, who works regularly in projects that operate in the traditional model, the agile model is a very welcome change. Let me tell you why...

As testers in non-agile projects, some of the challenges we face are

· Timing of our inclusion in the project

· Utter dependence on documentation

· Coping up with abrupt changes in requirements

· Insufficient channels of communication with the Development Team or other stakeholders

Let me explain how each of these aspects is handled in Agile projects in turn making our life simpler:

· Timing of our inclusion in the project

Normally, we are almost always included somewhere in the middle or towards the end of the development project.  By this time, the development team would have completed most of the coding. We end up uncovering defects in requirements and design when the coding is almost over! With each defect we find that is attributed to an earlier phase in the life cycle, we are pushing ourselves into more trouble! Then we need to plan more re-tests to ensure that the fixes have not broken the other parts of the application. This increases the cost of the project as well as the risk of not adhering to the time-to-market deadlines.

In contrast, in agile projects, we are included in the project, at the same time as developers. The 'how to test' section of the user stories are documented before they are coded. The development team takes guidance from the documented tests while coding.  This approach avoids the number of defects and hence reduces the re-testing effort


· Utter dependency on documentation

In non-agile projects, the entire planning, estimation, scheduling, test case identification, etc. depends on the provided documents. We never get a chance to participate in the requirements gathering exercise. We only get to 'analyze' the requirements after they are documented. If the requirement documents are not detailed enough, we can miss testing something important. Also, it has to be ensured on an ongoing basis that we and the analysts/developers are working with the same version of requirements in the project.

On the other hand, in agile projects, we are an integral part of the team. Estimations and Scheduling for the tests are done in sync with the overall development planning, estimation and scheduling.  We have a chance to participate in the requirements gathering exercise and would have the same understanding of the requirements at any point of time as the developers. Requirements in agile projects are documented as User stories, which are simple and detailed enough by default. So, there is no scope for missing requirements.  For each user story that is being documented, we discuss 'How to test' part with the developers and ensure that these test cases are documented. Developers write the code to ensure that our tests are satisfied.


· Coping up with abrupt changes in requirements

We hate requirement changes because the requirements are not independent by nature and so any change may also impact other requirements leading to significant re-work. We always have the testing window fixed and have to adopt techniques like risk-based testing, to select the tests intelligently for re-testing. There is never the luxury of running all the planned tests for every requirement change.

In agile projects, since the development as well as testing is done in an incremental fashion, handling requirement changes are easier. If the requirement change leads to newer user stories, these are handled in the same fashion as other yet-to-be-code-tested user stories. Care is taken to move them into appropriate future sprints so that the integration testing is logical. If the requirement change is within the user story, handling it is simple as it is limited to updating the test coverage for that particular user story  as each user story is an independent entity. Hence we work in a more disciplined atmosphere where we are always in control of what we do.


· Insufficient channels of communication and collaboration with Development Team or other stakeholders

In non-agile projects, there are multiple challenges with respect to communication and collaboration. Since, we do not have the opportunity to collaborate in real time, we depend heavily on documentation and spend time on emails and phones to sync up with the other stakeholders on the requirements and issue clarifications rather than on any innovations, which could bring down the cost of the project or improve the testing cycle time of the project.

In agile projects, we are engaged with the other stakeholders, right from the Initiation phase. We interact with the larger team, using multiple channels of communication, all in real-time. We have the same view of the application as the other stakeholders  as we participate in Release planning and Sprint planning. We can quickly and efficiently resolve issues as daily standup meetings provide a chance to discuss issues as soon as they arrive providing real- time handling of defects. Constant communication among stakeholders provides a platform to debate each other's perspectives and opens a window for innovation. Surely Agile projects provide myriad opportunities for rewards and recognitions.

Now, isn't all this cool? I am sure most of the tester community would agree with me.


Do let me know your thoughts on the same.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Infosys on Twitter