Our Software Testing Philosophy III
This is the final part of our article, you already learned more about our company and the essential points of our philosophy. In this last chapter, we will focus on the results of each project.
- 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.
- Below are some questions which we believe you may want to ask while measuring software testing within your company:
- Are your testers finding the most important bugs?
- Is your team more aware and considerate of the quality of your product?
- Are teams and stakeholders being provided with the precise, clear, and needed information to help them make the best decisions about the product?
- What is the ratio between actual costs and planned costs within your software testing?
- What is the ratio between the actual time taken vs planned time within your software testing?
- As time progresses, are the testers more aware of what to test first, how to test it and why?
- As time progresses, is the percentage of bugs marked as ‘won’t do’ reducing?
- As a team, are you meeting the needs of the majority of your audience?
- 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.
This article was written by Alex Dillon
CEO of TechAID
OTHER POSTS YOU MIGHT LIKE
Quality – Impact – Purpose It is vital for us to be a transparent company with our clients,…
Approach Continuing with our previous article, where we talked about our three software testing philosophy topics focused on…