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

Agile is a philosophy focused on delivering constant value to customers incrementally and frequently, based on communication and feedback. These two ingredients are vital to a successful Agile recipe. Agile is no longer a buzzword or an unknown territory in the industry. Agile has progressed leaps and bounds the last few years and has matured to ...
Author Jonathan Rasmusson explains in his latest book how to successfully set-up, execute and deliver Agile projects. Download the excerpt below for “Chapter 7: Estimation The Fine Art of Guessing.” To read his interview in last month’s issue, please click on “Spotlight Interview: Jonathan Rasmusson” to read his views on the best practices for test ...
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 ...
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 ...
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 ...
Michael Hackett sat down with FNC’s Chris Floyd to get his take on numerous Agile topics.
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Three 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 ...
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 ...
As CTO of Xebia and highly experienced in offshore testing in India, Guido articulates his methods in addressing common challenges faced by the in-house and offshore teams. He weighs heavily on strategic tactics as well as key cultural aspects to execute efficient and effective Agile methods. 1. I work at a US-based company and we ...
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 ...
In the decade since the Agile Manifesto, the movement has encouraged a number of best practices like test-driven development, user-centered design, iterative development, clean code, refactoring, continuous integration, and—arguably—cloud computing. I’m a card-carrying Agile zealot, and to me its benefits are unarguable. Is your IT organization ready to be Agile, seriously? Score yourself on these ...
Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams – from scrappy startups to big corporations ...

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. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe