logo logo

The 3 Biggest Software Testing Mistakes

When you have worked in the software development industry as a software tester for more than a decade you already may have made many mistakes. Making mistakes is not bad at all, people usually learn from their mistakes and improve their way of working and skillset. Especially software testers who are new to the field make simpler mistakes, but as I wrote before, making mistakes can be a good thing. 

In this article, I will share the 3 biggest software testing mistakes you can make, no matter which level of experience the tester has. The article should prevent you from making these mistakes. So let’s jump right into it!

Software Testing Mistake 1: Not Asking Questions

One of THE biggest mistakes from my point of view is when software testers are not asking any or enough questions during the development phase of a product. We all know that the later a bug or problem gets found the more expensive/complex it is to fix. Therefore, software testers must be involved as early as possible in the software development lifecycle.

In the best-case scenario, testers already take part in product discovery phases and pair with product managers, designers, and interaction designers on new systems or new features to ask questions about testability, usability, or potential technical issues that they might already see. By technical issues, I mean more the non-functional problems an application can run into such as performance problems, security topics, and accessibility concerns just to name a few.

In my opinion, a software tester should work closely with the product manager during all stages of the discovery phase and then later closely with the development team, when the implementation and testing phase starts. Software tester should be part of the development team, attending daily standups, refinement, planning, and review meetings to always have the chance to ask questions.

Typical questions a software tester should raise are:

  • Do we know for whom we are building the new feature?
  • Do we know of any technical limitations on the user side, e.g. devices, internet connection of our users, and so on?
  • How can we test this feature on our staging systems?
  • Do we have any regulatory topics to cover?
  • Are there potential data protection topics to cover?

The mentioned questions in the list show just an excerpt of things to ask. The questions depend on the product you are developing and testing and will look completely different depending on the context of your product.

Additionally, the experience of the software tester plays a big role to avoid this mistake. An experienced software tester will ask completely different questions, because of their deep product and technology knowledge from the past. On the other hand, a new software tester on the project might ask “easier” questions with a fresh mind, without the history of the product. Both can be beneficial for a product. 

Mistake 2: Trying to Automate Everything

The second mistake that I have seen over the past years in many teams and organizations is the mindset to automate everything. Usually, this mindset comes from people who have no real understanding of what automation is good for and what to expect from it. 

Before a team should start the automation, they should sit together and talk about the different parts of the software architecture. There might be sections of the application that are still under heavy development and not mature enough to cover with automated checks. On the other hand, there might be parts that are critical for the product and should get a much more detailed focus on automation and quality checks. And there might be completely software products with a limited lifecycle such as marketing landing pages or special event pages, that might be available for days or weeks. In this case, automation might be completely worthless and a waste of time.

Therefore, a risk assessment of the product must be the first step before writing a single line of test automation, combined with asking the right questions.

Once the parts are identified which are worth covering with automation, the team should talk again on which level the automated checks should be implemented. In this case, the test pyramid is helpful to drive the discussion. 

If automation is done right, it will help the team to change code with confidence and to ship faster to the production system.

Software Testing Mistake 3: Re-Using The Same Test Data

The third mistake that I have seen in the past and made myself in my early days as a software tester was to re-use the same test data over and over again in a test cycle. I had to learn the hard way that this was a bad idea.

Software products rely on data. Data can be user inputs such as text, image, voice, or data that is being transferred in a defined format between systems. Test data can also be a specific state or configuration of the system under test. 

Once the test data has been used in a test cycle, it is not in the same state as it was before. User inputs might have changed, the system state is a different one or the configuration is different, too. The next time someone will execute the same test with the same data as it was before, this person can’t be sure that the system behaves as expected because it relies on used test data. And this might have a huge impact on the test results and on the released product, too.

In order to test an application, the software development team must know and define the data that will be processed by the software. In the next step, the team must create the test data for the development and testing cycle to verify that the product works as expected. Generating test data is not an easy task. Depending on the complexity of the system and the involved technologies this might be a difficult task to do.

In the best case, a team can generate the test data with a script. The generated test data can be used for a specific test and can be deleted or reset afterward.

A solid test data strategy is key to success in modern software applications and should not be underestimated by a team, but the invested time will be worth it.

Making Mistakes Is Something Good

In this article, I covered three mistakes in software testing that I have seen in the last years working as a software test engineer in different teams and organizations. There are for sure much more mistakes a team or individual person can make when it comes to software testing. 

We are all humans and make mistakes, which I think is good. From mistakes, we learn and we improve our skills and knowledge. In the best case, a team is transparent enough to share the mistakes with others in the company to establish an open-minded culture of failure. 

What are your biggest mistakes in software testing? Let me know in the comments section below. 

About the author

Daniel Knott

Daniel loves digital products with high quality being it web or native mobile applications. In that past 10 years, he worked as Lead Software Test Engineer for different native mobile apps.

During his time as test engineer he wrote 2 books – Hands-On Mobile App Testing and Smartwatch App Testing. Since 2018, Daniel is leading the product development for XING’s native UWP app and likes to release products customers will love.

He is a frequent blogger at www.adventuresinqa.com.

Leave a Reply