Which Tests Can Be Automated and Which One Shouldn’t

Which-Tests-Can-Be-Automated-and-Which-One-Shouldn’t

Actually, it’s not quite a correct question: which tests exactly should (or shouldn’t) be automated. Instead, we have to ask more specific questions. For example, a good fact check would benefit from considering your current status, so that you don’t waste your time.

Do I have enough information about a product and a place where the problems may be? Should I make sure that we don’t rush into test development?

If the answer is no, you should study the software under test in more detail. And make notes about all the potential risks.

If you cannot say a definite yes, think about the following questions:

1. What is the specific fact or final performance of the software you’re interested in? Could QA service give a necessary answer?
2. Do I have enough information about a product? And where can bugs be?
3. Wasn’t it tested by someone else (for example, by a programmer)?

Next, think about the possible answers to the questions about product risks:

1. How does the software need to behave, so I or somebody else could fix a bug?
2. What’s the simplest and the most complex way to test the product performance?
3. Is it possible to implement this test for the machine interface (in other words, to automate)?

After that, you should analyze product risks:

• What can happen to a product that we might find a bug there when testing a suggested fact?
• Is it really a problem? Is it a high risk?
• Why do we think that this is a high risk?
• What does intuition tell you?

Maybe if there is an extremely significant risk, it is better to negotiate all the current nuances rather than coming up with testing scenarios on your own.

You may assume that this is an important fact. Think about the way how to test it and about the expense of such testing:

1. What’s the best way to test this fact?
2. Is it the fastest, most understandable, and most budget-friendly way to test it?
3. Will the testing be suitable for a machine interface?

After, analyze alternative options, especially if you test at the GUI stage:

• Are there any dilemmas while testing this fact with this method and doing it reliably?
• What dilemmas might we have missed here or elsewhere?
• Isn’t there something more important than just testing this fact, to implement it now? Is it ongoing?

Analyze the perspective for the future. On the one hand, the software and some facts about it may not always be stable: What exactly causes that fact to change? Is it acceptable? If not, is it necessary to develop a test for this fact?

Conclusion

You can ask questions like that ad infinitum. But as you gain more experience, the answers to these and not only these questions will become trivial to you. And of course, everything described above isn’t an exhaustive list. You may ask your questions. If you pay attention to the answers, however, then you automatically increase your confidence that your tests are powerful, valuable, and budget-friendly!