First of all, I want to be clear that this series of posts have nothing to do with my work at Atlassian. These posts are experiences from previous assignments with Jayway, and I am just now gathering my thoughts on it.
The basic principles of DET (Session, People, Focus and Reporting) are pretty easy to follow, so just doing it basic style will give some value. This is of course a place for a disclaimer, since running with the basics here would be similar to scrum, easy-to-follow rules that are just not so easy to follow. The sections below are about some aspects of the basics that we tweaked to fit the context. Read more…
First of all, Ill have to report a bug in James’ blog post. We only got $23 for the worst bug report award.=)
Then I would like to thank for the fun competition James set up, it was really a learning experience and in retrospect I would maybe have put even more effort in the learning parts throughout the exercise. This, and my ability to concentrate may also have been impaired because of the time of day (after 6 pm after long conference day) and that I was still jet-lagged. But enough whining now, here is the story and my learnings that hopefully will help me make better decisions in the future. Read more…
Recently my consulting company migrated all our email accounts to google apps. Even if the main reason was to get the emails on a new platform, this was a good step for our entire infrastructure, where I found a good and easy-to-use tool for my testing and note taking.
I have written before about what I think of pair testing with developers. This post is going to give you some more examples of the benefits.
Pair testing is like pair programming, in the way that you get each other to concentrate on the task at hand. Otherwise it is easy to step into sidetracks and staying there for too long. Sidetracks are possible also in a pair, but the time it takes to get back on track is shorter.
This time, I am actually performing the tests together with both of the developers of the system. It is another system from last time, but one of the developers is the same.
Just like the other system, I have learned alot about how the developers think and master the tools useful for this testing, giving me all sorts of perspectives on the product. They are both different in how they think of things, but their knowledge of the system is the same, but anyway they have different ways of expressing how the system works. This is a very exciting setting for me as tester, to gather and filter relevant information to the risks that we are facing.
Another aspect of this product, is that we have a very narrow deadline for production. This has lead to an enormous interest with the product owner, which is spending sometimes hours in a day following our progress of tuning the product for release. This gives also exciting discussions, since he has an even broader view of the users and functionality. He is technical, but sometimes I still have to translate the meaning of words between developers and him, in any direction. This is why I think of communication as a very important aspect in testing. More about that later.
Getting to the point, sitting next to developers when solving a bug, gave me the chance of getting a glance at the workflow in the product code. Usually I try to avoid this deep digging, but since he was holding the weel, I could just watch the exploration of the code. If I dont follow, I can just ask about explanation to see if there are risks to be considered. Yesterday, this actually revealed a bug. When trying to find another bug, I was observant enough about a discrepancy in another part of the code. Highlighting this just made my partner express the words I really like to hear from any developer: “Thats a bug!”
This was followed by an explanation about it, and the most important thing, it was a bug that would have been really hard to find if it had been ruining things later on.
The thing in this case, would be that if this bug had been seen by myself reviewing the code, I would not have been sure about it, and the feedback loop to any developer would have been a very long one, for this type of issue. Typo in a string, would that ruin your day? Well, in this case, the string value was very important, but as a tester do you think about that at all times?
We saved alot of money on the hours we would have been throwing away of finding this bug later on, and I think that is worth the money spent on two persons testing together, may it have been a developer and a tester.
At the moment I am the only test resource within an agile team of about 10 people. I am very new to the environments while the developers are much more experienced. At least that is what i think.
The team is an outsourced resource, and responsible for about 12 different smaller products towards a big organization. The products could be said to be somewhat a foundation for the rest of development within the company. Since there are so many different products, the developers also have some more responsibility to some of them. Since I started here, I have been testing two of the products briefly. One of which I was testing today…
I had the privilege to do some testing together with a developer. Before this I have been reading up on the existing documentation of that specific product, and come up with something they want to call test specification, but I would more call it test ideas/heuristics formulated in a document to make people happy. I have also had the document briefly reviewed with another developer which gave very much more value than he could have thought.
Me and the developer actually sat together by the computer, following my heuristics. And here was the funniest experience: Since the product is delivered to other developers for use in their development, my pairmate actually answered both questions from his development point of view, and that of a user of the product. This made the situation even more comfortable for me as a tester, since I just had to ask the right questions, without having to know what to ask, and he would fill in the blanks, and then he would answer the question himself. That way my questions were very much of the character how things should be explained. All I had to do in the meantime was taking notes on key features and what happened, and also keep track of the “test specification” so it was up to date with what we actually did for testing the product. I was using my pairmate pretty much as a testing tool and oracle at the same time.
Since my view of testing is on a much higher level than that of my pairmate, there was somewhat of a frustration using the high-level tool I wanted to use for smoke testing and verification. This tool is developed by another department in the same company, and does have alot of time-consuming steps before answers to the heuristics are visible. With this in mind, I had to minimize the use of this tool and use it efficiently. It also helped that my developer had his own tasks on his laptop beside him when having to wait for the system or for me taking notes.
As a conclusion, I had many good experiences from this kind of testing:
– I got a much deeper insight into the product after this session. I could actually do some testing myself from other heuristics later on, with for me before unknown shortcuts and solutions to problems that occurred during the pair session.
– It made me understand the actual usage of the product in a better way, since this was a development product and my pairmate was a possible user of the product as well. That made me realize that some of my test heuristics actually were useless and would just add costs if used in testing.
– Using my brief domain knowledge but good testing skills and thinking, we could together create a confidence in the product and its state of quality to a satisfying degree. We both could point out issues with the product, very often without the other one noticing also. This is because we see things differently.
– I had the chance of educating a developer briefly in the art of testing, thinking a little different, making him realize himself about where bugs can be found etc. This is something every good developer should have, some brief knowledge in testing.
– And of course, the statement of all statements about how effective pair programming is: we were focused on our task all the way through. Since you are working with someone else, both are thinking about the task and pushing for finishing it. My own view on this is that you of course dont bring up your mail or blog feeds while having someone looking at the same screen as yourself, and this of course gives a productive setting. This has to be complemented with some breaks now and then of course.