I got some positive response about DET that I wrote on my blog and in my CAST session proposal, so I thought I would elaborate a little on where I think this could be going. I will probably cover more hands on aspects in the coming weeks, but I really want to explain a vision I have around it first.
How about including the business stakeholders?
In my current project, I started to involve our main business stakeholders in our test sessions from the start when I got involved. And they have gotten really excited about attending once a week. Read more…
I am currently working in a team of testers in a quite big project. It should be noted that the project size and process limits my personal scope and the things I can really change. The test team has not been there for very long, and our environment responsible s haven’t yet gotten the test environments completely up. One reason for that is that some parts of the system have not been completely delivered just yet, so the possibility to test the functionality flow is limited. But when do we start testing? Read more…
I just read Eric Jacobsons post on testers as plate spinners, and I like the idea. When I am testing a product, I try to get the broad test perspective before I go deep. This would be the same as spinning all plates in the beginning, and then of course they drop off one after the other while spinning just a few for longer time.
However, I think is wise to think about the context also when talking about this. As a part of a test team, having all of them just cover the broad and shallow areas can get you into trouble if time is limited. In that case maybe it is better to manage the team so that not all plates are spun by all team members. I think that is what Mihai is trying to make a point about in his comment. But I don’t like the statement he makes about not having all team artists because they are really engineers. That statement is really about a tester that has a hard time letting go of old process models, and not about the engineer or artist.
My view is that engineers are artists in most areas. They explore the solutions, with or without rules, but preferably not completely bound to the rules. Comparing with the circus artist again, if you have a team that collaborates around the problem at hand they will solve the problem. It will be a self-managing team of artists.
Thanks for the post Eric!
“I have heard a little on Kanban, which somewhat could be called an evolved agile or at least something in that direction. What i now am interesting in knowing is if these ideas, that are sprung from lean very much, affect or should affect the view of testing. What I do know, is how I would like to perform testing in the agile context. So what about kanban? Does it change the agile testing even more?”
The above quote is how I started this blog post some time ago. I didnt know how to continue in a somewhat professional manner. Part of that was because I had not gotten any picture in my head about how kanban works.
Yesterday, I attended the monthly Agile Skåne meeting, and one of the topics that was brought up was kanban. Since I was not the only one that didnt have so much of knowledge in it, we got a crash course in the form of a success story. While listening, I got some kind of vision of it.
Since I have been working alot with scrum, I had to ancor this kanban thing in scrum. I will now see kanban as scrum with the shortest sprints you can have, the size of a story. Then I will take into account another thing from kanban, the value stream context, which in my perspective means having only two places on the board that are allowed to have piles of cards, that is “Wishlist” and “Value for customer”. Having only these piles, while other categories like “implemented”, “tested”, “ready for test” or “ready for deployment” are not allowed to stack cards, you will get a flow of value towards the customer without leaving stories behind as untested.
While thinking of this, I realized that one issue with agile testing that has been bothering me for some time, and still does, will be easier in kanban. Why does testing in a scrum team many times end up in the discussion on “definition of done”? This is exactly one of the bigger issues I see when testing in the agile context. With this and the value stream context of kanban in mind, I realized that the fact that you extend the number columns on the board past the “sprint demo done” will visualize the testing in a more obvious way. This has the positive effect that the agile tester does not have to advocate testing as hard as sometimes is the case within developers. In the agile context, you can always add some columns when realizing where you want done to be, but in kanban this is default, meaning that the tester does not even have to argue for getting the “To test” column on the scrum board.
By only looking at this aspect of it, and imagining a little more about the kanban context, I would say that kanban is better suited for test than agile and scrum are. But I think Ill have to get back to this later on when having more knowledge of kanban.