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 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 ...
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 ...
There is a multitude of Agile testing techniques that are quite sophisticated. The DAD process can help guide your process of tailoring decisions. Agile developers are said to be quality infected, and disciplined agilists strive to validate their work to the best of their ability. As a result they are finding ways to bring testing and ...
This is part 2 of a 2-part article series; part 1 was featured in the September 2020 issue of the LogiGear Magazine, and you can check it out here. Part 1 discussed the mindset required for Agile, as well as explored the various quadrants of the Agile Testing Quadrants model. Part 2 will delve into ...
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.
LogiGear Magazine – November 2010
One of the features of using Agile methods is the opportunity for continuous improvement within a project. There are a number of improvement opportunities throughout a typical iteration or sprint─over the next few weeks I’m going to walk through a few, starting this week with the Retrospective. Retrospectives are one of the many tools in ...
Build the right test platform including infrastructure, virtual lab and process. Testing embedded software is both similar and dissimilar to application software testing. The first eye-catching thing is that embedded software is significantly less visible to the end user. User interfaces are limited; there may be a console-based text menu, a simple command line interface, ...
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 ...
Over the years many Agile proponents have come out strongly against offshoring some of the development team, and in particular against having a remote testing team. We made use of not one, but two separate outsourcing providers located in two distant locations. While we had many challenges, what we found was that by starting with ...
Testing is often looked upon by many as an unmanageable, unpredictable, unorganized practice with little structure. It is common to hear questions or complaints from development including: What are test teams doing? Testing takes too long Testers have negative attitudes
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 ...

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