This article follows-up with the series of articles about tackling test complexity, adding a view on the importance of product knowledge, when coping with the complexity of testing. Let’s assume that you understand already, who your customers are;)
I managed testing of a large integrated suite of software products on one of my past projects. Each product had its years of individual history already, when the decision was made to release them as a suite. And each of them was quite complex on its own, even without considering integration with other products. The number of installation issues reported by customers started increasing to an unacceptable level after a couple of years of the products suite’s existence. The whole engineering organization became concerned about the issue. First hypotheses about the cause assumed that the released installer was defective or that the product documentation was unclear. These were not proven however. So, we decided to conduct a profound root-cause analysis.
Understanding customer needs for being able to do good testing sounds like commonplace that doesn’t need a special discussion. And testing projects often omit to discuss them indeed. Testing teams often start their project involvement with reading functional (or non-functional) specifications, skipping the customer view. I’m still mentioning it on the first place in the introduction of approaches to tackle testing complexity.
A problem you might face while extending the OpenDJ functionality with a plugin is to develop proper unit tests. OpenDJ comes with a set of tools to facilitate the testing, but since they are tightly integrated within the build framework, you might find it difficult to execute your unit tests from outside of the framework. This article will try to give you short guidelines on how to integrate and execute your tests.
Software complexity is one of the most significant challenges that a software tester may face. Testing software that is complex usually requires a breadth of knowledge and experience. The goal that the tester needs to accomplish with regards to complexity is: to test the software in a reasonable time and at a reasonable cost.
As an example, think about ways to test upgrades of a database system with the following support matrix that gives altogether billions of combinations to test. Can this test scope be reasonably covered? Maybe. Let’s see several techniques that can help addressing complexity.
Do you know the joke? “What’s the difference between a methodologist and a terrorist? Well, you can negotiate with a terrorist.”. It was perhaps more true for terrorists of the 20th century than those of the 21th, but you get the point. We met a “methodologist” the other day and that gave me the impulse to write this blog.
Here comes a universal recipe that I often hear on software release projects that are planning outsourcing of functional testing responsibilities.
|Take an experienced test designer to define test cases. Then take several clickers to do the execution based on those pre-defined test cases and you are done with your testing team.|
A clicker is meant to be a human being, literate and having some user experience with GUI based applications. Assuming that instructions are well written, the person will click through GUI based tests reasonably well. No need for special skills. Anyone can do it, right!? Hiring staff is going to be dirty cheap. Wow, that’s just perfect!!
Or, wait a minute, it isn’t? Such argumentation probably annoys most of testers. This kind of job advertisments is still part of the reality of the testing profession in Central Europe (and people from other parts of the world would probably confirm that we are not alone). The good news is that there is plenty of highly valued tester jobs as well. Let us try to name a few attributes that make the tester’s job more appreciated.
Testers often debate about testers’ place in the world of software engineering and the world’s perception of testers. Both well known names (, ) and the broader community (, ) contribute. We (testers) often get frustrated, deffensive, when non-testers say that testing doesn’t need thinking, that it is only about pressing buttons, that experience or qualification are not imporant. Basically that anyone could do it. In a response, we try to define ourselves (, ), suggest ways to deal with non-testers (), educate them () or trying to challenge ourselves (). The more I talk to peers and the more I read about the issue, the more I think that we are running in circles and that discovering new ways to continue the debate could help.