I am currently working in a team of testers in a quite big project. It should be noted that the project size and process limits my personal scope and the things I can really change. The test team has not been there for very long, and our environment responsible s haven’t yet gotten the test environments completely up. One reason for that is that some parts of the system have not been completely delivered just yet, so the possibility to test the functionality flow is limited. But when do we start testing? Read more…
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?
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.