How to create an effective test plan
Software is complex, but writing software is even more complex. There are so many factors that come into play when writing software that it is hard to think of all the exceptions that might occur and cause all sorts of havoc. We need UI tests, smoke tests, regression tests, edge case tests, integration tests, and so on.
If the organisation relies on us to run all these tests every time they make a change, we would be spending most of their time testing rather than coding.
We as developers and IT Pros know, or should know, how important it is to test the created work. Testing software requires a different mindset than developing software does. When tests are written by developers who are not trained in writing tests, we don’t always get the results at the quality level we need.
To minimise the risks, it would be helpful if we tested our software in many ways, which means we need to have a lot of tests in place. These could come in the form of Unit Tests, Integration Tests, Automated UI tests and many other methods.
Testing also helps during development. We often find that refactoring a piece of code leads to unwanted side effects. Sometimes when fixing a bug, the developers inadvertently introduce new bugs in other parts of the system. Having a good set of unit tests in place might help by alerting the developer that something is wrong.
- Learn more about Test Driven Development (TDD) on Microsoft Docs.
This works only if the testing is done regularly and consistently. Most of us developers know we need to run unit tests to get better software, but that is not enough.
Test automation helps
The answer to this dilemma is obvious: automate the tests.
In Visual Studio, you can turn on the option to run all tests continuously or at least after each build. This way a defect will be caught as soon as possible if the right tests were written. When this setting is on, we cannot forget about running them—the tools remembers this for us.
Other types of tests are more problematic. You usually do not want to run a full integration test after each build because these test runs can take hours.
A better solution would be to have them as part of your build pipeline. If you use Azure DevOps, you can take advantage of the Build Pipelines engine, which enables you to script out all tests and run them whenever you see fit.
For instance, you can build a pipeline that runs after each code check-in. These tests usually include unit tests and some regression tests. They run quickly and notify developers when their code is not accepted.
Other tests, such as UI and integration tests, can be set up to run at a fixed interval. It is customary to have these tests run every night, but in these days of global teams it’s hard to identify what night is. So, you have to come up with a time that works for you.
With Azure Pipelines, you can automate all sorts of builds and tests, including Python, Java, and Mobile, among others.
Where to begin?
Testing is something that needs to be done from the start. To have the biggest chance of success, testing needs to be part of every step of the software design process. During design, planning, development, and deployment, testing should be on everybody’s mind all the time. Test professionals can help with identifying good test cases, but since a lot of the tests are being automated, developers will be part of the test team as well.
We can break down the process as follows:
- Identify which types of test can be run often and which ones should be run periodically.
- Write the test plans on a high level
- Create unit tests
- Create UI Tests
- Create integration tests.
But remember, it is very important have these tests in place, and to run them often. If you make them automated where possible, and as part of your build pipeline, you can never forget to run them.
