Agile Testing and the Need for Speed

Agile, in terms of software development, has incorrectly and for too long come to mean fast and “getting product out the door quicker.” But Agile is not about speed; it is about being flexible.

I always begin my discussions on Agile development by getting a definition for the word Agile. Agile, in terms of software development, has incorrectly and for too long come to mean fast and “getting product out the door quicker.” But Agile is not about speed. It is about being flexible and responding to change. When I say this, I then pull out the Agile Manifesto. Nowhere is speed or faster mentioned.

The fact of the matter is many companies have switched to Agile development practices not because it’s a smarter or better way of manufacturing software, not because they’ve made a decision to apply lean manufacturing practices or, in fact, because teams will wind up being happier if Agile is well implemented. Instead, this Agile thing is implemented uniquely for the purpose of delivering code/product faster to the customers.

So, let’s leave aside discussion about Agile’s pros and cons and teams being happier or not — and talk only about the need for speed and its impact on traditional test teams.

To restate a few facts about Agile for this discussion: the Scrum is about project management, XP is about development practices, and neither deals with traditional testing tasks.

My main discussion points in this series have been what testers need to beware of in Agile development and how to implement Agile so that better software gets to your customers and testing can be successful! However, I don’t want to talk about specific test methods here. That is worth its own study.

It is a fact we will be getting faster deliveries or more code. Traditional test teams must respond to this need for speed and faster releases by changing our ways and changing our perceptions of testing. Given this need for speed, how can test teams respond? The following seven points will help you find your way.

First, unit testing and automated user story acceptance testing, done by developers, will release better quality software to test teams than when there is no testing by developers.

Second, continuous integration, including the re-running of unit tests and the running of whatever kind of smoke test or automated regression tests you have available, should increase the speed of qualifying your build for testing.

Third, test teams being involved from the start with sizing and estimating user stories will increase a test team’s understanding of functionality and design for more efficient test case design.

Fourth, a hardening sprint, release sprint or regression sprint – whatever you call it – for end to end system test or beta testing will help deal with the inability to run integration and bigger, longer scenarios versus small, narrow new functionality tests. We will discuss what happens in a hardening sprint elsewhere.

This testing happens after a feature freeze once the soon-to-be delivered functionality is completely integrated.

All of these things need to be in place to help test teams deal with the need for speed and the pressure of very short, quick release cycles.

Fifth, and unequivocally the most important, is that the need for the massive test automation in Agile projects IS the defining difference between releasing good software or releasing a time bomb to your customers. Test automation is not optional.

All those excuses like:

  • Our UI changes too much
  • Our developers never designed for testability
  • We don’t have the skill
  • The tools are too expensive
  • Our managers won’t invest in automation
  • Our managers don’t understand automation
  • Automation doesn’t help me find bugs

… these arguments, which were valid arguments for a long time in the history of software development, are no longer valid. I am not the saying that you need to automate 100% of your testing, but I am saying, to be successful in Agile you need massive automated regression testing.

If any of these lingering arguments about the “why not to” automate persist in your company you should deal with them. Do not accept them as fact! There are many reasons why a subject matter expert/black box, perhaps non-technical skill set can automate significant areas for testing. First and foremost is your job security. Also, there are far too many good tools and far too many solutions for automating to think none will work for you. Keyword driven testing, with one automation engineer supporting up to a dozen black box testers, or developers building harnesses are just two of the many solutions available to you. Remember, it’s 2012 so get with the program.

If significant automation is not happening you need to change that!

Sixth, when we talk about the need for speed, we have to talk about test artifacts. In the move to Agile, your business analysts stop writing huge requirements documents. Your developers don’t have to write engineering specifications. Why should test teams have to write test plans? Why should test teams have to write test cases for that matter? In Scrum and XP, there are no test cases documented except unit tests and the automated user story acceptance tests. There are no test case managers. User scenarios, workflows and end-to-end tests that test teams once labored over do not need to be documented. Did you talk about that in Scrum training?

There is no call for them in lean manufacturing. If it doesn’t go to the customer, don’t do it. In the great majority of test situations, your test plans and test cases don’t go to customers so don’t write them!

So now let’s move from theory to practice. I am not advocating testers stop documenting their work completely, but let’s look at other teams. If other teams cut back on their documentation of the product they will increase their speed. We cannot be expected to continue to write as much as we have and increase speed. If you want speed you have to cut back on documenting the test process. The seventh and last point- and the most optional- is in strict Scrum/XP implementations, there is no notion of a bug.

Design and development are followed by unit test runs and re-runs, and testing happens on that functionality. When what we used to call a bug happens, the person testing tells the developer in the same bullpen or at the daily scrum and the developer either fixes it or the team decides not to. The idea of having big bug databases is not prescribed in XP or Scrum!

Now let’s talk about more common implementations of Agile processes. Most teams still use bug databases, but with distributed teams and off-time-zone groups the need for tracking issues is too great to only rely on a daily standup.

It is worth reiterating that with lean manufacturing principles in mind we should cut back on test artifacts or we will remain project artifacts. Most teams that have become Agile have stopped writing test plans the way they did in the past. Many test teams have significantly cut back on documenting test cases. In the end, what will work for your team is up to the team and is also reliant on an attitude of striving for continuous improvement. I will stress again that you need to re-examine you artifact production to become faster.

To summarize, test teams must respond to the need for speed. In doing so, do not start by looking within. Look for other team members to share the test workload and automate, automate, automate!

Michael Hackett

Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006).
He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them. “He who knows to unlearn, learns best.” — Anonymous The following are some of the key aspects ...
To begin this article, it would be a good idea to, remember this key point: Agile Manifesto Value #1 Individuals and interactions over processes and tools Tools work at the service of people. People, particularly intelligent people, can never be slaves to tools. People talking to each other, working together and solving problems is much ...
Keeping an eye on the horizon in the testing world is an important part of staying in the game. Hans is no stranger to looking to the future with eyes wide and ears open. His expertise is what makes Hans valuable at the STARWEST Expo, which he recently delivered two talks to.
SKILLS Agile teams need training! One of the missing links in the implementation of Agile development methods is the lack of training for teams. I noticed in our recent survey on Agile that only 47% of the respondents answered “Yes” that they had been trained in the Agile development process, with over half responding “No.” ...
Our comprehensive issue on Agile, which was set to be released in June, has been moved to early July. We’ve made this decision in order to accommodate an article from one of our industry’s thought leaders. We’re really excited about this piece and we’re sure you will be too! LogiGear Magazine is dedicated to bringing ...
LogiGear Magazine – July 2013 – Agile Testing
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part One of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile” LogiGear Corporation LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and offers ...
Agile methods were developed as a response to the issues that waterfall and V-model methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed. From www.agiletesting.com.au A software tester’s role in traditional software development methodology, a.k.a waterfall & the V-model can be ...
Testing in Agile Part 1 – INTRODUCTION TO AGILE In case you missed the first part of the series in our last magazine issue from Michael Hackett, Agile’s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic.
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Two of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile”  LogiGear Corporation LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and offers ...
This is part 1 of a 2-part series. The 1st part will discuss the culture and mindset around Agile, and how Agile Quadrants are used. Part 2 will discuss how to use the Agile Quadrant, the significance of Automation in Agile Quadrants and how to use Agile Quadrants to overcome Quality Assurance headaches. Organizations aspire ...
If your Agile implementation is not about people, you’ve missed the boat! The most profound impact to becoming more Agile is happier teams! Agile manifesto Value #1: * Individuals and interactions over processes and tools Words like these do not show up in Waterfall or RUP SDLC process descriptions. Agile cannot get more basic than ...

One thought on “Agile Testing and the Need for Speed

  1. Hi Pierre,Thx for your feedback! I agree and of crsoue also only deal with my very personal current view. Certificates therefore might probably be treated as safety belt for employees / contractors / customers in terms of entry cards or license for the sales pitch game. There is still the question left about certificate vs. knowledge matter of discussion not only in IT, but nearly within any education system.Probably getting teams developed and self-organized is probably one of the most challenging but also potentially fruitful aspects in Agile (besides talking about management, empowerment, customer and business value ). You see, I take engineering practices for granted (as we learned it in education and all our other projects). Many of these new education programs might be damned good I know e.g. about CAT, which is really a great concept. I just rather would like to target the same stuff at the whole team, instead of addressing single experts and maybe their individual topic of career development / perspectives (still not to be underestimated in fully agile organizations without hierarchies as we know it).Best,Michael

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe