Agile Testing: Asking the Right Questions


This is very much "traditional" testing applied to para-functional aspects of the system like performance, reliability and so on. Again, the questions below are a small subset of what should be asked.

Is the response time of the system acceptable? Initial answers to these questions set performance baselines. Subsequent testing provides information for trending which allows us to detect changes in performance quickly.
What are the bottlenecks in the system? Once performance baselines are established additional load can be applied to the system until response times are unacceptable. Through the use of tools the tester can provide the team with insights that allow the system to be tuned.
What are the largest loads that the system can handle? The questions here are typically extreme like "What is the largest file the system can handle?" or "What is the maximum number of concurrent users the system can support?" or "How long can the system run at maximum load?"
How well does the system recover when over-stressed? Here we are questioning how well the system reacts to stress and how well does it recover when over-stressed?


Agile testers add considerable value to agile teams by asking the right questions and radiating answers back to the team



There are a few key points I would like to make:

  • Agile testing in the left-most quadrants requires strong team collaboration. This adds significant value by helping the team get to "done, done", preventing defects, and finding other defects earlier.
  • While operating in the left-most quadrants the testing mindset needs to be "Are we done?" rather than "Is this shippable?"
  • Traditional testing techniques will work very well on agile teams when operating in the right-most quadrants. The main shift for testers will be to pragmatically automate some of this work to support continuous testing and to radiate information back to the team on a regular basis.
  • Session-based testing works well with agile teams.
  • Manual scripted test cases have little value on most agile teams.

About the Author

Declan Whelan is an active software developer and agile coach.He is a professional engineer with twenty-five years of experience in the software industry supporting many types of businesses including financial, medical, educational, manufacturing, and utilities.He was co-founder and CTO for Innovasys, a start-up company that developed electronic imaging and workflow products for the financial market.He successfully transitioned the company from a start-up through to profitable venture and eventual sale.Declan is a certified Scrum Master and a member of the IEEE Computer Society, Agile Alliance, and Scrum Alliance. Declan's focus is on working in the trenches with teams to deliver better value, quality, and time-to-market through agile principles and practices.

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!