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

I have worked with testers on an Agile team before and it has worked very well for both the team and the customer. In my previous role at Bank of Ireland, testers who had come from a traditional testing background worked within our teams to help ensure we had quality deliverables at the end of ...
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 ...
Writing code that is easy to read and easy to test is difficult to achieve. The fact that poorly written code can function often leads to coding practices that are effective but not necessarily efficient. Too often, many programmers fresh out of school write code in the manner that was effective for passing their courses, but contains ...
“Agile is to software development what poetry is to literature. It is very difficult to do well, very easy to do poorly, and most people don’t understand why a good poem is good and a bad poem isn’t…” – from the web
This article presents ten tips for Agile testing based on our experience. However, don’t expect to find the perfect test approach for your company or software project in this article. That is still something you will have to find out yourself! Several years ago I started as test manager on a J2EE project. The project ...
Take our quick survey on Testing in an Agile Development Team! 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. There are many positive things about the move to be more Agile and responsive in software ...
Maximize the function of your teams The Modern Agile philosophy created by the folks at Industrial Logic is one of the most exciting ideas I’ve encountered in a while. Moving beyond the pre-canned “You must do X to be Agile” mindset that I’ve seen becoming more and more prevalent.
Agile Automation Michael Hackett – Senior Vice President – LogiGear Corporation 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 ...
LogiGear Magazine – November 2010
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Four 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 ...
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 ...
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 ...

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