Lessons learned as a tester on Agile Teams...

Hi Ainars,

That is not completely true that agile practitioners don’t manage. The creation of a backlog of prioritsed work, the rapid planning of the stand-up and pair negotiation is actually management. What happens to all of us is that we get stuck in a mental model. Maybe we see testers as curious, developers as builders, and managers as people in suites. These suite people then manage, this includes big plans, big diagrams and status meetings. Once this association is set it’s difficult to break.

Truth is management takes many forms. The agile projects I work on are the best managed projects I have ever seen… it’s the lack of “big management” that actually proves these projects are very well managed.

So, when you say “I feel like I just realized what would actually be a lesson for me to learn: there are no need to manage and control the exploratory testing and neither to worry about system level tests” I think you are a half right. You should manage and control your testing, but, with the right effort at the right time.

Jamie

Can I comment even though I am not a tester?

1) Time boxed exploratory testing.
Here we can time box an exercise to hammer the software to see what bugs we find. This is a nice team activity and can be useful for finding problems. It only works when embedded in a larger process. It is a very good team building exercise.

2) Deploy the application.
People like to tinker. Our customers, our analysts, our managers. Thus, release the application as part of the build and people will use it. This does 2 things: a) helps find bugs; b) applies a light bit of pressure on the developers to not let any silly bugs seep through.

3) It’s a classic, but, “crash early and crash often”.
In Java this has never been easier. You need to do a few things during development: a) ban all log statements. Any one who enters logs in their code should be taken outside and executed. Why? Why not, is the more appropriate question. Banning logging forces much more value adding activities such as debugging and unit test authoring. b) use assertions. These should be added where the old log statements went. c) do not use checked exceptions, ever.

4) Balance your pipe with a kick arse generalising specialist.
If you are lucky you will have someone who is a real buster who can test, develop, and do everything else as well. This person will probably be your lead, either officially or un-officially. They can pair on all tasks and should do often. This stops either the testing tasks or development tasks from becoming the bottleneck. However, much more importantly, this person gets a good overview of everything that is going on. Antony, this is very similar to your point about nurturing each others skills. See this for more details: http://jamiedobson.co.uk/?q=node/14 .

5) Attack training and team cohesion.
This is often overlooked. But, you can’t effectively test, or be an assimilated tester, if you didn’t go through the steps of a proper project set up. This technical terror we have created is nothing in comparison to the power of the dark side... er I mean, all these other things we have talked about are nothing compared to decent set up. Without the setup, the game is up. So, as I tend to do, I have turned a testing problem into a management problem. This can be re-translated into a testing lesson like this: if you don’t know the goal of your project, or you colleagues, you have to take responsibility for team cohesion. Without this you are dead anyway, so forget Fit and forget Junit.

The same goes for training, including developer training. If you are debugging stack traces because your developers are crap, you are dead. Stop sub-optimising and get started on the developer training. And for those haters who think this is not their job, answer me this: whose job is it? Working within the bounds of your role, your written orders, or doing what your boss says without questioning them is irresponsible. And will bring you no joy. By the way, technically, this is known as the Nuremburg Defense.

They are my tips. I have more, many more. But I don’t want to bore your poor reading public. Hope all is well in London mate, Jamie.

My question was how do you manage tasks. Absolutely not-agile question:). Agile don’t manage. You don’t care which user story implementation caused the later exploratory testing to add one more user story, do you? Whenever someone feels that ET should take place it take place.
I believe you are right that words have a different meaning for both of us. I was actually cheating saying that all your lessons applies to me perfectly well. Actually I could apply the to some degree using your words in my context. My point was however that those lessons would hardly be the Lessons for me (who is trying to optimize instead of apply “best practices”) should I switch to agile development team. I feel like I just realized what would actually be a lesson for me to learn: there are no need to manage and control the exploratory testing and neither to worry about system level tests. Test efforts should self-organize. Just as cost and demand self-organize in market economy.
Maybe I’m wrong again, but I try really hard to understand the actual difference, not the difference between two processes by-book.

Can I comment even though I am not a tester?

• 1) Time boxed exploratory testing. Here we can time box an exercise to hammer the software to see what bugs we find. This is a nice team activity and can be useful for finding problems. It only works when embedded in a larger process. It is a very good team building exercise.
• 2) Deploy the application. People like to tinker. Our customers, our analysts, our managers. Thus, release the application as part of the build and people will use it. This does 2 things: a) helps find bugs; b) applies a light bit of pressure on the developers to not let any silly bugs seep through.
• 3) It’s a classic, but, “crash early and crash often”. In Java this has never been easier. You need to do a few things during development: a) ban all log statements. Any one who enters logs in their code should be taken outside and executed. Why? Why not, is the more appropriate question. Banning logging forces much more value adding activities such as debugging and unit test authoring. b) use assertions. These should be added where the old log statements went. c) do not use checked exceptions, ever.
• 4) Balance your pipe with a kick arse generalising specialist. If you are lucky you will have someone who is a real buster who can test, develop, and do everything else as well. This person will probably be your lead, either officially or un-officially. They can pair on all tasks and should do often. This stops either the testing tasks or development tasks from becoming the bottleneck. However, much more importantly, this person gets a good overview of everything that is going on. Antony, this is very similar to your point about nurturing each others skills. See this for more details: http://jamiedobson.co.uk/?q=node/14 .
• 5) Attack training and team cohesion. This is often overlooked. But, you can’t effectively test, or be an assimilated tester, if you didn’t go through the steps of a proper project set up. This technical terror we have created is nothing in comparison to the power of the dark side... er I mean, all these other things we have talked about are nothing compared to decent set up. Without the setup, the game is up. So, as I tend to do, I have turned a testing problem into a management problem. This can be re-translated into a testing lesson like this: if you don’t know the goal of your project, or you colleagues, you have to take responsibility for team cohesion. Without this you are dead anyway, so forget Fit and forget Junit. The same goes for training, including developer training. If you are debugging stack traces because your developers are crap, you are dead. Stop sub-optimising and get started on the developer training. And for those haters who think this is not their job, answer me this: whose job is it? Working within the bounds of your role, your written orders, or doing what your boss says without questioning them is irresponsible. And will bring you no joy. By the way, technically, this is known as the Nuremburg Defense.

They are my tips. I have more, many more. But I don’t want to bore your poor reading public. Hope all is well in London mate, Jamie.

[textile]To me, "Done" means "We've implemented the behaviours/capabilities that we committed to for that sprint (iteration)". I've found that defining the scope of the work with Stories and Acceptance Tests up-front and demonstrating completion of the work by automatically running those Acceptance Tests as highly effective. This, however, is not specifically a Scrum practice. It is a practice from XP that some people merge with their application of Scrum.

"Done" does not necessarily mean "Feature complete". Although it can mean that if the customer doesn't have any more items relating to that feature on the product backlog... but even then it means "Feature Complete until we realise we need something else in that feature".

We build on behaviours/capabilities incrementally one sprint at a time based on our client's priorities.

Exploratory testing might provide:

* Feedback to developers - extend unit tests/code to make more robust where applicable
* Feedback to the team and product owner (customer/product director) on what other behaviours/capabilities are enabled by the development so far. Often, undesirable behaviours are reported as bugs. Personally, I prefer to deal with these as new Stories with associated Acceptance Tests that go on the backlog.

Why would this need an extra column? It's just another task on the board.

I question how you define 'somewhat agile'. Based on our conversations and what you've wrote, I've heard of your teams using some tools and practices commonly associated with Agile Development. Using tools and practices from an Agile methodology doesn't equal agility. Sadly this seems to be the assumption made by too many people. Many seem to assume that if they can put a tick next to each 'Agile' practice that makes them 'Agile'. I disagree with that.

I think I also disagree with your statement that "system testing is missing in agile" but then that depends on what you mean by 'system testing'. It also depends on what you mean by 'agile'.

You assert that the lessons I've listed are mostly the same as yours. I'm not sure that they are. I think we'd both have to elaborate on what we mean by each statement before we could be confident that this is the case. I suspect that the words have a different meaning for both of us. I also suspect the application of these lessons have a very different effect when applied to teams I work with and the teams you are working with.

So, what do you mean by 'agile', in what way are you 'somewhat agile'? What do you mean by 'System Testing' and What do you mean by 'system testing is missing in agile'?

Antony Marcano

Antony, I’ve told you my project style and you know it isonly somewhot agile and the word agile is never actually used here. However all the lessons learned apply to my environment perfectly well, except that we have BA role instead of developers participating UAT test creation.
There is one thing I want to ask you to clarify. How exactly do you manage 2 testing tasks you mentioned: “use exploratory testing” and “write Acceptance Tests”?
”e.g. in Scrum, as tasks on the sprint backlog (no separate test plan)” do you mean a separate item in backlog for each of those tasks, or they are part of user story? I’ve seen photos with desks and cards arranged in columns for “not started”, (for TDD “unit test creation”,) “in progress” and “done”. I really miss there are two more columns “agree on Acceptance Tests“ and “use exploratory testing to generate feedback”. Why they are not included? Only because they are afraid it will look like waterfall? Or because they demand different skills and preferably different persons assigned: a tester + customer write Acceptance Test. Or maybe Acceptance tests are written even before SCRUM planning (during requirements gathering as in VV model) and be a part of user story card? Maybe also exploratory testing are not par of “DONE” in SCRUM because SCRUM DONE idea miss one thing – feature integration. As a QA person I would never say done to any feature until I see how it integrates with other features been developed in parallel. I don’t mean if integration does not break it, I mean use-cases when both features are used together. That’s what why the idea of system testing is so essential, but somehow missing in agile, isn’t it?