This is the final part of our article, you already learned more about our company and the essential points of our software testing philosophy. In this last chapter, we will focus on the results of each project.

Results

Conventional software testing metrics are often misleading and can lead to undesired decisions. However, they’re what we have to work with at the moment, so until something better comes along, we need to use them to approximate the information we need. We just need to ensure we use them wisely and be conscious of the impacts and risks in doing so.

Here we have some questions which we believe you may want to ask while measuring software testing within your company:

1. 1. Are your testers finding the most important bugs?
   2. Is your team more aware and considerate of the quality of your product?
   3. Our teams and stakeholders being provided with precise, clear, and needed information to help them make the best decisions about the product?
   4. What is the ratio between actual costs and planned costs within your software testing?
   5. As time progresses, are the testers more aware of what to test first, how to test it and why?
   6. What is the ratio between the actual time taken vs planned time within your software testing?
   7. As a team, are you meeting the needs of the majority of your audience?
      
   8. Is the percentage of bugs marked as ‘won’t do’ reducing?
   9. As a team, are you producing less critical bugs in production?

Do any of the questions above, or any other metrics you put in place make sense within your context?

• • The number of bugs reported is not as important as those bugs which are important to the team, stakeholders, and audiences.
  • Exploratory testing can be documented and reported on with the use of session-based testing.
    
  • Testing is about providing information to the team and stakeholders. If testing is failing to provide the needed information, it is failing at its primary goal.
  • To provide the information needed, test reporting needs to clearly tell 3 stories: the story of the product’s quality, the story of the testing done and not done, and the story of the testing quality, which tells why it was done or why it was not sufficient.

Communication is key!

               Now we say goodbye with this publication, but we will see you soon.

Please do not forget us! Feel free to keep in touch with us

This article was written by Alex Dillon
CEO of TechAID
Twitter: @masterpiece91