When working with our mission of creating an organization wide test strategy I was thinking about quality related problems we have in some projects. I realized that the expected quality is not explicitly stated anywhere. This means neither customer nor development team are aligned about which level of quality is expected to be delivered when done. I needed something to achieve a better awareness of quality requirements and a light weight way of stating them explicitly. Read more…
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…
About the title, I was inspired by Alexis Ohanians talk at this years Öredev, Only your mom wants to use your website. And just to point out, the story below is not strictly chronological.
My grandma is not very much of a technician. Yet she uses her computer and Internet every day, all day long. To do what? Listen to the Icelandic web radio of course, sharing her digital photos through email and play hearts, spider and winmine amongst other things. Any of these tasks must be enabled in the least amount of scripted steps to achieve as there is no room for exploration when grandma uses her computer. I have to do the exploration. Read more…
This post is originally posted on our company blog, any feedback is greatly appreciated.
Our company has moved more from delivering individual consultant services to taking whole in-house product commitments delivered as a service to our customers. During the last months we have also been in a process of re-evaluating the core company values. Through this values work it has been clear that we want to feel proud about the quality delivered to our customers.
The transition in itself has evolved in a good agile manner, where a bigger quality initiative was a natural step forward. My first task was to investigate the current (not explicitly stated) quality values and propose an organization wide quality vision which has been lacking. This post will explain what I have done so far and the further work on it. The further work consists of defining models and activities to use in an implementation of our values.
Since quality covers many aspects of software development, it was clear at an early stage that our present status was not always that the product itself was of bad quality. Sometimes the development team think the quality is bad but the customer is happy, and sometimes the other way around. It actually goes down to managing the expectations of all stakeholders (team, customers, end users etc) and maximize the perceived quality accordingly.
Some people have learned that I will give them my thoughts on anything they put in my hands. Most commonly this would be in the software domain, but just as much I will give my thoughts on anything that I can inspect, question or at least have some clue about how it should be, or not be. Sometimes I dont even know this much, but I am able to ask the right questions for the producer to realize the flaws himself. Apart from software this can be documents of some sort or even important emails they are sending.
I really enjoy questioning “products” with the sharp eye of a hard-to-please customer or just like a regular user. With my profession I also have some of the necessary skills to communicate what I believe are flaws or suggestions of improvement in constructive ways that will motivate or even compel changes to be made before deployment. Sometimes the bugs I find are very serious, and sometimes not so serious, but all of them at least become visible to the stakeholder that shows it to me.
Thinking about all the software products I have gotten my hands on, there is a remarkable amount of them where obvious bugs or flaws have appeared almost instantly when doing the first exploration of the product. I have no numbers to build this discussion on more than just a gut feeling that as a tester, if I just get a hand on a product, there will be questions to ask and bugs revealed almost instantly.
I dont know why this is the case, but there are of course several factors that are more obvious than others usually. Things like environment and configurations, testability in development, testing skills and heuristics of developers or even inattentive blindness are factors that usually cover a lot of this. But isn’t there another dimension? The dimension of not only letting another person look and inspect the product, but letting a tester have a look. Sometimes I wonder if my feeling “hand it to me, and Ill show you how broken it really is”, is it something that everyone can sign up on, or is it the way of the tester?
An example of this was when a friend and colleague of mine showed me the product he was currently working on, a mobile phone application. As a tester in the project he had been questioning this particular app for some weeks already. Within 5 minutes I discovered something that for me was an obvious and serious bug, but he and his team had not discovered it before. Was it a coincidence, or is it cause I am a tester and will look at the application in a different way than my colleague? I am quite sure that any other person than another tester would not have found the bug. Say what you want about it, but it was a good thing letting me play with the product for 5 minutes while having a break. And what if you include me fulltime as a tester in a project where you dont have any dedicated tester?
I think of this quite often, and especially when it come to smaller projects (1-5 people) that just say they cannot afford having a tester that does not produce value. And as a tester it is not so easy to prove the value added before getting involved. Though this is a whole new story, can any team of any size creating any product AFFORD to NOT have a tester if you not only think of the customer value created but also include the customer value that you risk to loose if/when delivering an untested product?
“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.