This morning I was in a hurry. Not only did I have to get to my train on time, I also had to refill my train pass with another 30 days, before I got on the train. And of course I wasn’t the only one in the same situation when I came to the ticket office, so I had to wait for my turn.
As always when facing these kind of obstacles in my way, the natural thing for me is to find a better solution. This time I had to get a quicker way to refill my card. Looking at the small vending machine, where you normally buy ordinary tickets for a cheaper price with a card filled with money, I saw a sticker that I have never seen before. Apparently they upgraded the machine to be able to refill my kind of card as well with credit cards. YAYE! The last time I remember this machine getting an upgrade was when you started to be able to refill the money cards with money from credit cards.
So, happy with my new knowledge, I followed the instructions for refilling.
“Swipe credit card”
“Insert train card”
Observing the fact that the machine understands what kind of card it is
*Machine spits out card*
“Your purchase exceeds 850 kr” (Yes, of course it does, this card costs 1060 kr.)
Not so happy anymore, I have to try it again, to see if it was actually happening what I saw.
I start to think about how this could happen in an upgrade of software. From before when these machines were new, you were only able to buy tickets for a train ride. You could buy family tickets etc, but the fact is that a regular one-way/one-person ticket never exceeded 78 kr (or something), which used to be the maximum price for in-region travel, pretty much did not get you above 850 kr. One question would be, when did they put this limit? Was it when they started to take credit cards, or was it in there from the beginning, not allowing you to use the refill cards for more than the limit?
Some other relevant questions would be:
Who decided on the limit 850 kr? Legal issue?
And why this amount?
Wouldn’t it have been easier to have 1000? This would of course also have been a wrong amount for my monthly card, but at least it would have made sense as a maximum value.
Then we got the business value when they realized that the customers could refill their monthly cards in these machines. The cost of having employed people doing this must be soo much higher than doing the development for upgrading the machines. But did it cost too much to test it properly? Did noone even consider old business rules (ex 850 kr limit) as a risk when implementing new business rules for the refills?
I returned to another machine to take a photo of it later today. Since I was not in the same hurry, I realized the sign above it stating the obvious bug as a technical malfunction. But the thing is that this sign was not present at the first machine where I was this morning. If I would have seen it this morning, I would probably not have gotten frustrated like I did.
So I guess they realized the bug in production by the customers, but they could have the documentation for the bug at all machines. Like the company needs worse reputation than they already have.
I wonder how much testing they do when creating software for coffee vending machines?
The other day when I was getting my usual cup of coffee in the morning, there was a guy with a laptop connected to the open vending machine. (Fortunately there are two of them right next to each other, so I got my coffee). But I just had to ask the guy what he was doing.
He was very happy to actually get the question, that someone was actually interested in what he was doing. So he started to talk about coffee and milk in vending machines, and how no coffee vending machines are allowed to call it milk in their coffee anymore. The white powder was apparently not real milk powder or something (I didnt dare to ask him, next time maybe). So instead of solving the issue by actually putting real milk in the machines, they change the software and labels to say white instead of milk. For me as a coffee-with-milk drinker this was a somewhat disturbing thought. What am I actually drinking? (some google got me to this, and this)
Anyway, a couple of days later I was waiting for my turn to get coffee, and a colleague of mine starts to curse. He didnt get his special “Cappuchino with mandelkrubb (english?)” when pushing that button.
Regular coffee for him, but I actually had to test that too. I actually like that sometimes. When asking for that, I can see in the display that what I actually asked for was “Soup”. So my next question would be, did I actually get my Cappuchino but blended as soup or did I get soup made as coffee?
And hey, I know that has to be some kind of setting, what to have on which button etc. But how on earth was this messed up with the white powder setting? And how much testing does coffee vending machine vendors do?
I will leave those questions unanswered.
“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.
The title of this post is one of the most common defense I get when I argue that testing should be involved as early as possible when developing software. And I have to admit that there is some truth in this. But how much is “something”? What is actually required to be able to carry out testing in the sense of verifying some level of quality in a product?
Of course, this depends on the kind of testing you are implying. If you are thinking about some certain kind of testing, like unit testing, user acceptance testing etc, there are certain things that these contexts require. But think about once more what I am actually saying. “Testing needs to be involved as soon as possible to get the most value in a product.”
For this statement I prefer to use the definition of testing that James Bach uses in his rapid testing: “Testing is questioning a product in order to evaluate it”. Having that in mind, the testing carried out throughout a project is questioning the current product as it looks at the moment. In the beginning of a project I can very well see the product as the sketches on the whiteboard on the first day, until there is something more concrete. Questioning a whiteboard sketch will reveal requirements misunderstandings early on while testing the ready to launch product means different kinds of questioning.
Anyone who wants to argue more about the early involvement of testing?