For quite some time now I have struggled with making note taking a natural part of my personal progress while testing. And well, I can say that it has really made impact on many other aspects of my work in other situations as well. I am actually quite proud to say that it has made great impact on how I perform in general, and how easy it is to make follow ups when done with anything. Now I would like to take this some steps further to explore how my notes can give more value to the whole team in a project setting, both mine and the teams’ collective notes.
I was at a SAST Öresund meeting last thursday. It was time again to hear a little more about the knowledge of agile within the testing community in the south of Sweden. I am sorry to say that other times I have gotten somewhat disappointed, but this time I felt that people are actually starting to get it.
The first presentation, I am not going to say so much about. It was about using Scrum in an outsourced test project. The number of questions that were thrown at the end of the session showed that there was a big number of uncertainty and inconsistency for the presentation to gain acceptance in the audience of testers. It also proves my point on the agile maturity at SAST. In my point, and probably more with me when thinking of all the questions, I am not so sure the project was very agile at all actually with its surrounding managemental and additional processes used to achieve the goals for the poor Scrum team.
Then there was Thomas Stjern from Inceptive, that presented the view on requirements management in the agile context. When listening to Thomas, it struck me that he was almost exactly describing some things that are in the book that I am reading at the moment, Bridging the communication gap by Gojko Adzic, about having User stories on a really high level. Then they become business rules for development and then Fitness tables for acceptance testing during development. I will cover more on this in future posts.
What was more exciting for me about the presentation, was the view of the roles of the requirements/business analyst and the tester. As Thomas referred to scrum teams of size 4-6 people, the role of business analyst and tester could obviously and preferably be the same person. By doing that, you will never have knowledge/information drop when creating tests from requirements. Going back to Gojkos book, it makes even more sense to do this, as he talks about the requirements written as acceptance tests in the first place.
In some projects I have been in, the business analyst tasks have been carried out by the product owner or scrum master person. This has always created a gap in knowledge about the domain and the customers true wishes between this person and me as a tester. In my current project though, I have actually grown the amount of trust from my project stakeholders, that I was a part of the requirements discussions before any of the features in a the new release were started to be developed. Compared to the other projects I have been involved in at the same client, I have always gotten involved sometime during development before a release. As this is my 6th product release of a product here, I have every time gotten closer and closer to the initial meeting of the release. Now I have caught up and I see this as a big difference to the first release I had. This time, I have the overall understanding of the design and am able to focus more on the actual testing and quality of the developed product, during development. In contrast to when I need to gather fragments of old discussions together and then analyse what is actually wanted from the product by the customer, and do this maybe after everything has been developed.
Somehow, this also relates to my post on Dare (not) putting your product in a testers hands?. Will you invite your tester to the next design/requirements/scope workshop or meeting? I can assure you that a good tester in that position will find the bugs in the discussions. See my post on that here
How often do you find a really serious bug the first thing you do on monday mornings? Or any mornings for that matter, when you just started to look at it.
How often is it the other way around, that the first thing you do is trying to remember what you did on friday, to cause that serious issue you found at 4.30 before you were leaving for home and for the weekend?
For me, it is always the latter. Not only fridays, but any day of the week, the most common time when I find bugs is really late in the afternoon, preferably if you are having an appointment or anything right after work. =) But why is that?
I have three possible explanations, that I have been thinking about:
1. You could be testing a really hard-to-set-up system, that takes half of the day setting up before it is possible to test even a little bit. This is the reason for me every now and then. Recently we have been setting up load tests during night, which have failed a couple of times, so the mornings have been devoted to investigate logs for failure explanations and then it has taken some time to reset databases and getting up and running again. Usually with a bug fix or configuration tweak that also takes some time to verify.
2. Exploring the product and its features and areas all day has made you get more sensitive to finding the weaknesses, and poking the system in these spots make the really tricky bugs appear. These might be the most severe afternoon bugs, or the opposite, the ones that are too complex to be a threat to the product and just are hard to fix, with no value added if fixed.
3. You are unintentionally defocusing from the tasks at hand since it is getting late in the day and the lack of energy is carrying your senses in completely other directions from what you have been doing all day. The defocusing strategy is actually something that is brought up in rapid testing contexes for finding other types of bugs than you normally do. Lack of energy just makes you get in this mode automatically during afternoons. These bugs are more too often hard to recreate for investigation, since your lack of energy might miss out on observing the reason behind the bug.
Have you experienced the afternoon bug heuristic? What have been causing you to find them? and specifically, why do you find them at that time?
“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.