In this blogpost I like to discuss some of the software testing pitfalls I encountered over the last few years. Some of them are related to software testing in general, others are related to specifically test automation (Because that is my main area of interest).
This might be a never ending discussion. My personal opinion; certification is definitely not the guarantee for a good tester, but it allows people to talk a common language. Furthermore, it gives you some proven practices and methods. How much you can use of these methods and practices, depends on the context. I often saw people who became a tester with a background in the area of development or operations. It’s funny if you hear them talk about software testing. Meetings with people without a common knowledge are not efficient at all!
I mostly work in environments where we have to test a web application. I often hear tester say that they don’t see the value of applying testing techniques, because it’s just a web application. I think this is really odd, because why should you relate the use of testing techniques to the nature of the application under test (test object)? It makes more sense to relate the use of testing techniques to the business value of the application under test. You have to test more if the business value is high and testing techniques help to produce more efficient test cases.
You will see it more often that there is less time spent on the preparation and specification phase of software testing. It’s mostly coming from teams who are saying that they apply some form of Agile. I think you should always define some sort of testplan and test cases or test charter, regardless of the development methodology you are using. The level of detail depends on the context where you’re working in.
One of the most heard problems in software testing is the lack of test environments or up-to-date test environments. Utilizing modern tools we can create and distribute test environments on the fly. We also often see that data across environments is totally different. Having those two problems it’s hard to automate testing.
Recently I heard something funny. In a company where they apply Agile, they said: unit testing is up to the developers, we shouldn’t even look at it. (To save time…)
Developers are not testers and (probably) never will be. So, we need to help them with writing proper unit tests. Think of positive and negative cases and even testing all possibilities of a decision. (Also known as: decision testing or multiple decision determination testing) I think, it should also be our task to check periodically the quality of the unit test and verify if they still use testing techniques.
These are just a couple of pitfalls in software testing.