Essential Software Testing Tools Blog

They say communication is the key to good relationships. Your weekly software test status report is one very important component to building good relationships, both within your team and outside of your team. A good software test status report, provided to all the stakeholders in your project, gives people confidence that you will deliver.

Here are some tips for what to include in your weekly software test status reports:

Summary: a single paragraph describing how the testing has progressed during the last week and what the main concerns are.

Current version under test: version of the product that the test team is currently testing

Important Defects: a list of bugs that have the biggest impact on your testing (usually a list a blocker defects).

Project Issues: A list of the project issues (e.g. lack of resources) that need to be resolved in order for the testing to continue without obstruction.

Expected releases: when you are expecting the next release from the development team and what fixes/functionality you expect in the release.

Schedule/Progress: Are you on track to complete the testing on the estimated completion date? For example if you track the test cases you run you may list planned vs. actual test cases completed for the period

Including a test dashboard on the status report can also be useful. A dashboard aims to show a high level status of the testing in a graphical or table format. Your dashboard could cover items such as:

Test Areas: a list of areas your testing is covering
Current Effort: how much effort is currently being applied to the test area
Coverage: level of coverage planned for the test area
Quality: a subjective estimate of the quality level for the test area
Bugs: number of bugs raised within the test area
Comments: important points relating to the test area

Depending on your audience, your software test status report can be a quick one page summary or run to 3 or 4 pages. The most important point is to make sure you keep your software test status reports relevant and up to date. The more relevant and up to date the more likely people are to take notice. After all, one of the main purposes of this software test status report is to get other people to carry out their obligations to help you keep the software testing on track.

Software Test coverage is one of the most important indicators of your software test progress. There are many different ways to track software test coverage; bugs, requirements, components, code, configuration, change, data, etc. Using just one method will never present you with an accurate picture. Using multiple methods to track software test coverage will always give you a clearer picture.

The most common methods for tracking test coverage include:

Bug count: this helps demonstrate that a product is not ready for release. However, an absence of recorded bugs won’t show that the product is ready for release.

Requirements coverage: testing each requirement will help prove that the product meets the customer’s needs. Where requirements are subjective it can be difficult to gauge how well a requirement is covered.

Component coverage: tracking tests against individual components of a product can help show components that haven’t been covered. Again the problem here is that it is difficult to accurately gauge how well a component has tested.

Code coverage: the lines-of-code covered measure is useful for showing how much of the application you have exercised. However, this method won’t tell you if functionality is missing or if the features implemented meet the customer’s requirements.

Test case coverage: the number of test cases covered as a percentage of the test cases you planned to run is one of the simplest test coverage measures. This measure can be very misleading though as it depends largely on the scope of coverage of each test case.

 

Taken together a range of different software coverage figures can be a very powerful indication of test coverage. For example you may know that you have completed test cases covering all of the products components. You may also know that your code coverage is 10% higher than you achieved for a previous release. In addition, bug counts for this version may list only a few minor bugs. These values taken together would be a far stronger indication of good software test coverage than just one value which says we’ve completed 70% of our software test cases.

How often do you feel overwhelmed with the amount of software testing you need to complete for your next product release? Twice a week? Four times a week? Every day? It is a frustrating fact of testing that there is never enough time to complete all the testing. Rather than finding a way to deal with this, most software test teams simply hope that they’ve done enough.

If that is what you’re doing why not consider prioritising your software testing? When you prioritise your software testing you:

• Find the serious bugs sooner
• Deliver the results needed by the team faster
• Don’t waste time on irrelevant tests

 

It would be great if we had more testers and realistic deadlines but in the real world we often get little influence over those variables. You have the resources you have, and you need to make the most of them.

We can’t help you decide on the precise priorities for each of your tests, as you need knowledge of the product to do that. However, the following 6 points will help guide you :

 

1. Review defect trends from previous product releases
2. Identify areas where bugs have been fixed or new functionality added
3. Balance test priorities across early and later builds for the product
4. Make sure you have well defined meanings for each priority you use
5. Ensure you have consistent priorities across all your tests
6. Review test results from previous test runs

 

The solution is not just to hope that you’ve done enough software testing. The solution is to find a system that enables you to prioritise software tests and focus on what matters most.

Why is it so important to consider your software test documentation requirements? Well for starters we all spend a significant amount of time writing software test documents. So getting the content and pitch wrong means wasting a significant amount of time and effort. Here are 7 questions that will help you get the pitch and content right for your software test documentation.

1. Should I document what to test or how to test it? Step by step how to test it documentation can be useful where you hand tests over to 3rd parties. If your test team know what they are doing, try saving some effort and just outline what needs to be tested.

2. Is the product design changing? The level of detail in your test documents should increase as the design gets closer to completion. When the product you are testing is still changing then detailed test documents will probably need changing later too.

3. Will you deliver your documents to a third party? If you deliver your documentation to a customer then you should consider any standards they demand. If your documentation is only needed internally then think about meeting a lower level of requirements in order to achieve your objectives.

4. Who is going to read your test documentation? If you find yourself writing test documentation that no one seems to read then you should question why you write it. Where you are handing your test documentation to other testers to read then pitch your test documentation with that audience in mind.

5. Will your documentation facilitate delegation? Where you use test plans to coordinate and drive the test project you will obviously need to write with a level of detail. Where you are writing and running test cases for yourself then consider saving some effort and just outline the testing.

6. How much maintenance are you prepared to invest in? The more detailed your test documentation the more time you need to reserve for maintenance. Where your product design is changing rapidly you should consider putting time aside later to update your documents.

7. How will you track document changes? Where you provide your documentation to a third party, or a customer, you should consider a strict version control regime. At a minimum your test documents should be identifiable with unique ids, versions and titles.