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!
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