Understanding the Testing Mindset

It is critical to understand that testing is a mindset before we go any further. Testing methodologies, tools, frameworks, etc. are irrelevant if you first do not understand that testing is first and foremost, a mindset.

The reason why software development teams and QA teams are separate is because both teams view an application completely differently. Developers are responsible for building things, while QA professionals are responsible for breaking things. If developers want to write tests, they need to learn to think the way that a QA professional does and then translate that way of thinking into automated tests.

Now that we understand that testing is a mindset, we need to discuss how this mindset plays out in the day to day work of software development. As new feature requests or bugs come in, you and your team should be thinking first about how you are going to test the application code related to these changes. These discussions should not be held in isolation, but should always incorporate both dev and QA teams. Even if your QA team is only doing manual testing, their input is incredibly valuable. They can help provide the test cases that they would expect to run against this new feature, which the developers can then translate said test cases into automated tests.

If you do not have a dedicated QA team, then the development team should be having discussions on what kinds of tests are going to be necessary to ensure this new feature is working correctly. An easy way to do this is to start with the end goal and work backwards. What does this new feature need to do? Once you understand that, you can break the problem down into small incremental steps, and translate those steps into tests. This way you have a clear path to achieve your goal and a suite of tests that will confirm everything is working properly.

If you are doing Agile, the test cases can be captured in the user stories as acceptance criteria for the story to be done.