Last week I attended the CONQUEST 2010 conference. As I was invited to be part of an experts panel, I answered some questions from the conference attendees about testing, quality, and how all of this works. In particular I was invited as an expert on Agile testing. The session was voice recorded, in order for the transcript to be provided online in a few weeks. Since it will be on German and we had to restrict our answers to two minutes, I asked the organizers, Karin Vosseberg and Andreas Spillner, whether I may translate the questions to English and publish them on my blog, and got the permission to do so. So, this is the first set of questions (from the CONQUEST 2010 attendees) and answers (from myself). The first set of questions is filed under the topic “Testing as a profession”.

Testing as a profession

Question:
Education and the necessary skill-set of testers are still underestimated! Tester are often paid lower than other roles in the IT. This lets larger Testing-Companies provide services [outsourcing] for low daily rates, but obviously the same companies save expenses with the education of their employees and therefore place “Low-Performance-Testers”. All this together leads to a bad reputation of testers.

My question therefore:
How can we stop this loop?

Answer:
Simply put, this is a negative feedback loop. As recently elected Testing-Luminary Gerald M. Weinberg discusses in his Quality Software Management series, it is a self-reinforcing feedback loop, but with negative outcome. Now, using all the techniques that Mr. Weinberg gave me in this sense, let’s analyze the situation with a bit more thought rather than taking the situation as giving.

First of all in every system there is a possibility to make choices. Let’s see where the choices might be taken in the described system. Outsourcing companies may be able to provide lower wages than the norm in our industry, but no one is telling you to take their service as granted to be as professional as that of a skilled tester. That said you may decide not to use the lower performing services from an outsourcing company in first place. It is as easy as saying the word “No”.

Second the lack of good education does not ask you to give away the responsibility to train and educate your staff. You may hire a respected test consultant for some days, for a training course, for a seminar, or a lecture. In case you’re looking for an Agile expert, here is a little older TOP100 of blogs related to Agile and testing, from which you may want to hire someone. Additional ideas are reading blogs, attending online testing challenges and courses, reading books, and more of the stuff I will be covering in my talk on self-education in software testing at Agile Testing Days in Berlin and EuroSTAR in Copenhagen this year. In case you cannot attend one of them, EuroSTAR asked me to run a webinar on it, and you may download and watch it on your own right now.

So, both, education and the choice of oursourcing are decisions that you may make. Of course, you may want to stick with the current situation, and see our profession degenerate. I’m surely trying to prevent this, and I hope that I gave some hints on how to do it.

Question
Scrum says that everyone should be able to everything. Programmers test, and tester program. Also, every programmer shall be able to develop everything. Based upon detailed expert knowledge this is often not practicable.
I would like to get to know what your experiences from the praxis are?

Answer:
First of all, this is a very enormous misconception about Scrum and Agile in general. Scrum asks to build cross-functional teams, but it does not ask to put just generalists in there. Instead the team needs to be created with all the abilities so that it can deliver the product it has itself committed to. That means that if database is part of the product, then I would make sure to bring in the necessary database knowledge to the team as well. As a ScrumMaster I may want to remind the team when I sense some lack there, and help establish the discussion with upper management to bring in a database expert. The same holds for testing on the project as well. If the product needs performance testing during the iteration, I may want to see an performance tester on the team in addition to all the other specialists.

From the praxis it is of course not practicable to have everyone building everything on the team. When a Scrum team starts, there will of course be specialists in some areas, and just few generalists. There will also be specialized tasks on the taskboard. Still, if a team member has nothing to do, walks to the taskboard in order to pick a new item to work on, he may want to pick a task not from his special area. If testing is a problem on a Scrum team, then everyone is asked to help the team meet the commitment, even if this means that the ProductOwner takes on some testing tasks. I consider this point to be essential for the definition of the word “team”.

From my past I remember a project when we had overseen a part that needed to be developed. We had maybe two weeks left, but no one was wanting to do this (on a non-Scrum environment). No one had the expertise with the task at hand, and therefore avoided to learn about this new area. Since I couldn’t understand this resistance to learn something, I stood up myself as a team member, and took the responsibility with this task on me. I shamelessly failed to develop it right the first time, fell down, but was able to deliver what we needed in the end. It was a great learning opportunity, but I was still a tester on that team that had developed something and learned from it (for example the necessity of early feedback). I would expect such behavior from a professional team.

Question:
Which test-specific roles are there on Agile projects? Should there be test-specific roles?

Answer:
One of the main advantages on Agile teams is the torn down walls between programming and testing. Since everyone may help out with the coding or with the testing, the team complements itself over time. This is one of the most wonderful aspects of Agile software development. That said, by bringing in test-specific roles we would build up again the walls that we have just learned are better torn down. This does not fit well into my model of successful software development.

Anyhow, this does not mean that testers are not welcome on Agile projects and teams. Quite the opposite. Since the team gets the feedback early on what goes wrong, and is asked to take on the responsibility to improve their process during the iteration retrospective, it is enabled to steer against negative outcomes. If a tester is missing, then the team may decide that a programmer is taking over more testing tasks during the next iterations to help cope with this. Surely, this will have an impact on the velocity of the team, but since the team decides how much work they can take on in order to fulfill their agreed upon “Definition of Done” as it is called in Scrum, the quality stays the same, but maybe the inevitable shipping date has to be postponed – or the scope being reduced. Scrum and the other Agile methods provide this early feedback on the healthiness of the project early on, when the options are manifold to cope with it. I think this is better than having a project 95% done 95% of the time, only to find out that it will be two years late.