Test improvement in Agile/Scrum*

This is the translation of my article for Polteq in TestnetNieuws 2012-1.

Testnet exists fifteen years, in this time testing and the context of testing has changed a lot. This should have influenced test improvement models, but are the current test improvement models fit for Agile/Scrum? Most of the models are based on the tradition development and test methodologies  (waterfall) . The key areas that get addressed by these models depend largely on the phases in these development models. One change we see within Agile/Scrum is the phases that are used… Above all, we see that not only the phases have changed, but the role of testing too. A test manager needs a new point of view on Agile projects and for the testers in Scrum teams we see new demands. Testing has become a role in stead of a function! To assess the maturity of testing, we need to change the models and incorporate Agile/Scrum into the models.

Maturity

To be able to improve, we need to asses the current maturity of Agile/Scrum and of testing. Testing is not “just a phase” but part of the whole. We are thinking about the following levels of maturity:

• No Agile/Scrum (it’s called Agile, but it is waterfall);
• Agile/Scrum process in place (all useful meetings and artifacts are introduced, we see little waterfalls with more and more Agile elements)
• Agile/Scrum is understood and applied (good incremental/iterative development incorporating the Agile principles)

To achieve optimal improvement, not only testing has to be addressed. However in this article the focus will be on some important testing aspects.

Test knowledge

The first prerequisite is a vast knowledge of testing. The evolution of testing is depicted in the following figure. At first testing was at the pioneering phase; everything had to be invented. After that the structured approaches started to emerge. The logical next step was to let go of the structure and use the gained (structured) knowledge in an Agile way. When starting to work Agile before learning the structure, the testing basics will miss and we keep reinventing “test wheels”.

The tester

Agile/Scrum has different demands for testers than waterfall projects. The test needs to do more tasks, which previously were dealt at higher levels in the organization. For instance planning and estimation are now dealt with at team level. We need more proactive testers. Since test basis usually does not exists when a sprint starts, the tester needs to actively help to get it. Don’t wait behind your desk until the specifications are ready! Help the team by creating clear Definitions of Done per backlog item.

Test management

The test manager will have a facilitating role in Agile/Scrum. The role might be a little less test manager and somewhat more team manager. So supply the teams with people that have enough test expertise! However there will be enough work in the area of testing for the test manager. When the product backlog gets assembled, the test manager should think and communicate about risks. This will help to find the dependencies between backlog items as early as possible and will help to decide what to do in the regression tests and/or end-to-end tests. The test manager has the overall view on risks! When multiple teams exist, this is a very important aspect. Another tasks for the test manager is creating generic test approach. For Agile/Scrum this can consist of how to deal with critical issues, demands for test automation and minimal mandatory reporting. Make sure to know the context, it can be organisation wide or only for the Agile projects. Creating a generic approach will give the business more insight and the business still feels like there is some control.

Planning

Sad enough, testing is often only partly involved. Planning sessions take place without involving testers or with not enough respect for the testers. Resulting in incorrect estimations and too little thought about the risks. Testers need to be involved in all phases within Agile/Scrum. Preparations like assembling and prioritizing the product backlog also needs input from testing.

Test automation

An important element of testing within Agile/Scrum is test automation. This is necessary to keep up in the incremental process, since the regression test will become bigger and bigger. Within test automation there are a lot of improvement possibilities. Good automation isn’t as easy as it seems. The foundation of good automation is a sound architecture (test framework). Make sure that the test automation is kept up-to-date.

Business commitment

The organization as a whole needs to support the new way of working. Controlling based on reports is no longer possible, so the business needs to actively communicate with the teams. This will lead to guiding the teams in the right direction while they still have enough freedom to be Agile. Teams can still do some reporting to help involve the business. Most tools that teams use to keep track of progress and managing defects have reporting facilities. Make sure that the reports deliver what the business needs to know!

Conclusion

It is important to realize that the focus and approach of testing within Agile/Scrum is different. The team is responsible for quality, so testing has become a team responsibility. All people in the team will be testing, but the testers still have the testing expertise. So especially the testers can help to improve the testing within Agile/Scrum.

*) Agile/Scrum is Agile with Scrum

Advertisement

Testing gets disqualified

Last week I read an article (in Dutch) which presented some negative views on testing and IT people in general. “Just like other professionals they don’t like to take the blame.” Technology is unreliable and the -superior- human always has to fix it. The writer states that the root cause in 80 percent of the incidents is human failure. This seems strange; since the technology is developed and used by humans I’d say that this should be 100 percent… But the reasoning of the writer has some more strange ways. “From humans we can expect that a failure is made every now and then, but from machines we may expect more.” I think that the writer underestimates the humans in this case. Humans can recognize when something goes wrong. When they see something goes wrong, they can correct it, where a machine cannot think.

“All people involved seem to be stuck in sub optimal processes and don’t make use of modern technology” Some people indeed are stuck in processes and in some areas I think that is a good thing. But more and more development is Agile and will adapt. The next point actually felt insulting. “Instead of ‘fooling around’ IT people rather use the word ‘testing’.” So here we have a ‘manager’ disqualifying the work I love to do. I don’t have the feeling that he has any idea of what he is talking about.

“Let IT do what it’s good in, automate.” This is the only paragraph of the article where I had some recognition. Automation, more specific test automation, is used too little in the software development. I also see that in a lot of development processes people say that automation is too difficult, or too expensive. By now we must understand that it will cost you to invest in (test) automation, but if chosen well on what to automate, it will pay back.

I read the article just before I went away for a couple of days. I actually expected a lot of responses about how wrong the author was and that he made some statements that are clearly his opinion, but not based on any thorough research. Strange enough, it got positive responses… So I just had to write about it.

How to become a better tester?

In a lot of professions we see that people want to grow and become better in what they do. It’s a pity to see that within testing a lot of people are just doing what they always do, the way they always do it. Why does it seem that a lot of testers don’t try to get better at testing? Is it because they don’t know how or should the title of Martijn de Vrieze’s post “Is testing the dumping grounds of IT?” be answered with yes too much? Let’s try to put some pointers down on how to become a better tester.

Know your basics

The first step to becoming a better tester, is to know what testing is about. Most testers have at some point in their career participated in a “testing foundation course”. The basic terminology learnt in such a course, together with some basic techniques, should not be forgotten. I’m not saying that you should apply everything all the time, but just don’t forget it. The courses are called foundation for a reason! Every house needs a foundation, not only the first couple of times you build a house.

Be passionate and keep practicing

You’ve got to love what you do and keep on practicing to become better! Have you ever seen an Olympic champion that did not train? Every piece of software (or hardware) you’re testing is different. So you get new challenges continuously, but you’ve got to treat them as new challenges too. Of course you have some basic tests that are valid to execute in this context, but it’s a new challenge so try new methods and think outside the box. Only executing standard tests will not make you a better tester.

Read and write

One way to learn about the test profession is to read. A lot of useful sources on testing exist. When you are reading this, you found one of the sources: blogs. More and more testers start blogging to let the community know what is in their minds and to help others that might run into similar situations. In my opinion, every tester should at least read one book on testing, but preferably more than one. The software testing club has a nice lineup here. Writing a blog is valuable to become a better tester too. It helps you realize what you do and structure it. The comments that you’ll get will also help you to think again on what you wrote.

Attend meetings with other testers

Face-to-face communication will help even more. Attend conferences, specialist group meetings and peer meetings. Every time you discuss about a testing topic (or just listen to others that are discussing), you will get something out of it. Either it strengthens you in your opinion, or it will help you to understand why your opinion should be adjusted. A conference is a great place to learn. People take the time to prepare presentations, so you will get a complete story. Meet-up with other testers to talk about these presentations and share your views. Never stop learning!!

Go to the dark side

Last month I saw a video of @EvilTester (Alan Richardson) in which he explained that we need to go to the dark side of testing. This was a great video and helped me a lot to realize what needs to happen for me to become a better tester. If you have 41 minutes to watch it, please do! He clearly states that a tester needs a sense of humor and take responsibility for what you do.

Building blocks of a good (software testing) course

In my opinion a good course will contain theory, experience based stories and a practical part. Each of these will deliver value to the participants in its own way, therefore I think all these elements need to be present in every course. No software testing course can be complete without some actual testing in it.

Theory

Theory is considered to be boring by most of the participants, but it’s necessary! The theory will provide some common understanding of terms and definitions that can be used throughout the course. Of course the theory is best accepted by participants when it’s backed by experience based stories, but these stories alone will not suffice to bring the message. It’s up to the teachers to deliver a good mix of theory and experience based stories! The theoretical part of the course is actually a guideline for the teacher, so no relevant subjects for the course are forgotten. Since a course is usually not limited to a single teacher, the theoretical part will make sure that the minimal need information to make the course worthwhile is delivered every time.

Experiences

In the previous paragraph I mentioned that it’s up to the teacher to deliver a mix of theory and experience based stories. Beware for courses where the teacher lacks personal experience in the provided content. However, the teacher is the only one that provides experience stories. A good course will use some form of discussions to let all the attendees share their knowledge. Stimulate all attendees to participate in discussions. Where one person sees problems, the other already tackled these. A good teacher will learn from these discussions and will be able to provide more information every next course. It’s important to acknowledge that you, as a teacher, do not know everything. Also give credit to the attendees and tell them that you will use their input to improve the course.

Practice

To improve the chance that the information in a course sticks with the attendees; always make sure to have some exercises. In the case of software testing, make sure there is some actual testing in the course! Challenge all the people to actively try to make the topic work for them. To really learn something, people need to apply the learned in their own context. Soft skills are important for testing too! Help people develop their soft skills e.g. by letting them present a part of the course and than using the group to give feedback.

What makes a good course great, is a follow up session after the course. Let the attendees try to work with the material in their context and then let them tell how it worked out. As a teacher you’ll learn how the provided material will work out in different contexts, preparing you even better for next courses.

Conclusion

Theory is needed to provide the context for the course. Add stories based on experience to emphasize how the theory can help in real world situations. Let people practice with the provided material, enabling them to apply the material in their own context.