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.
As of starting this serious blogging again, when I want to write about real experiences during my day, there are of course some factors that have to be stated before talking about what I really want to talk about. For example I need to mention testing situation, team, product elements etc. all of which are the good heuristics for any given testing project. But how much of the context is needed? And how much can I leave out without being irresponsible in my posting?
I have a couple of blog posts on the way, to kick start this blog, but I would really like some input on this before digging deeper into the blogging. As a tester (I see this as a personality and requirement of a tester), I want to be very exact in the context, but being that I risk to overpost needless information. And that sounds like overspecifying systems requirements, of course. This will also cause the posts to be too long for anyone to want to read them.