Nguyên tắc cơ bản của kiểm thử phần mềm

Recently, I had a conversation with Paul Gerrard, the internationally renowned, award-winning software engineering consultant, author, and coach.

We discussed the fact that testing is at the heart of software development. Obviously, as testers, we spend all day testing and thinking about testing. But developers test every line of code they write. Sometimes, users test. In fact, the all-pervasive nature of testing is what makes it so hard to pin down. But it’s vital that we do. Because this isn’t an esoteric issue, it’s one that goes to the heart of the software testing landscape. When we have a clear vision of the fundamental purpose of our role as testers, we put ourselves in a much stronger position to add value to the business.

The fundamental of testing is that it tests the fundamentals

When we take it right back to basics, a test is a procedure. To carry out that procedure, we need to think the steps through and develop a model for what’s required to conduct the test.

Our model might be as simple as a list of features that are exercised in sequence and the paths you can go down to get there. Of course, it’s unlikely to end up being as simple as that. There are feedback loops where you go back one step because the requirement isn’t detailed enough, or the test reveals that delivering on the requirement is more complicated than anticipated, or the workaround the developer needed to implement to meet a requirement has created a knock-on effect that the users hadn’t thought of.

We’ll likely want to capture how that model looks. But it doesn’t matter if we capture it using an Excel spreadsheet, a whiteboard, or some test software. It doesn’t matter which approaches we use to run the tests. It doesn’t matter how we write the tests down. It doesn’t matter which tools we use to test – or even if we use tools at all. It doesn’t matter which approach was used to bring a project to fruition.

This is all just detail – and, ultimately, the easy stuff we can learn. What’s more important is our critical thinking abilities and capacity to formulate that model in the first place. We need the ability to see what needs to be tested and how we’ll test it. We need to be able to plot our path through the software and spot the potential issues.

We can take things to the next level by balancing our critical thinking abilities with commercial acumen. Who are our stakeholders in this project? What information will those stakeholders need to see to make a decision? What will good look like for them? How will we negotiate when different stakeholders have different requirements? What are the risks involved in letting this bug go? How much testing is enough testing?

When we have this understanding, we bring value to the discussions and debates with stakeholders about completeness, conflicts, accuracy, ambiguities, and everything else that good software depends on.

The tangled world of testing

The trouble is, it’s very easy to lose sight of these fundamentals – and about the skills that a tester needs.

There is a wealth of different software testing approaches. There is a wealth of test execution tools we can use to run tests.

It’s very easy to find people who advocate for one approach or tool over another. You’ll find that job adverts will ask for proficiency in a certain testing approach or knowledge of a certain software suite. We’ll gravitate towards the people who advocate for the same approaches as we do. We’ll prioritize job applicants with experience in the right tools.

But the truth is this is just noise.

Every development approach has its strengths and weaknesses. Every testing approach has its strengths and weaknesses. Every approach is almost invariably applied imperfectly in the real world, which magnifies the weaknesses and downgrades the strengths.

That’s not a criticism, by the way, that’s simply a reflection of the reality of human nature. Software development and testing is a mathematical business. And yet we expect it to function perfectly when it runs up against the messy reality of humanity, vague specifications, siloed thinking, and conflicting requirements.

The fundamental requirement of the tester, therefore, is their ability to cut through that messy reality, spot the anomalies, and highlight the ambiguities. Our critical thinking abilities are necessary to balance the mathematical needs of software development with the complex, nuanced needs of the world it seeks to help. When we do that, we help to create software that truly adds value.

Forget about the how; concentrate on the bigger picture

As developers and testers, it’s easy to get caught up in the standards we should know and the definitions we should use. We can debate the value of structured testing, exploratory testing, automated testing, and manual testing. We can argue about the models we use and why we use them. We can highlight the value of one tool over another.

What matters is our clarity of thinking. It’s the clarity of thinking that testing brings that helps us – and the wider business – discern what the system is really doing and where the problems are.

If you’d like to explore these ideas in more depth, watch the recording of my LinkedIn livestream with Paul: A New Model for Testing 2.0. Aside from the fundamentals of testing, we covered a lot of other ground in our conversation – you can read about the other areas of discussion in Transforming Software Testing: From Overhead to Opportunity and Using AI in Testing.