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 software testing philosophy. In this last chapter, we will focus on the results of each project.
Results of our Software Testing Philosophy III
- 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?
- Our teams and stakeholders being provided with the precise, clear, and needed the 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?
- As time progresses, are the testers more aware of what to test first, how to test it and why?
- What is the ratio between the actual time taken vs planned time within your software testing?
- As a team, are you meeting the needs of the majority of your audience?
- Is the percentage of bugs marked as ‘won’t do’ reducing?
- 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.
OTHER POSTS YOU MIGHT LIKE
Let us formulate the following questions in our head: Do we know the importance of context driving testing? What are its values? When should we use it?. After thinking about these questions, we want to answer them by sharing with you the importance of context-driven…
Quality – Impact – Purpose It is vital for us to be a transparent company with our clients, that is why this article talks about our philosophy behind our software testing service, which inspires us and at the same time allows us to integrate with…