Skip to main content

Combining Defining Quality and Exploratory Testing Models

 In my previous few posts I have talked about a couple of things.

  1. What does quality look like? This talked about understanding what quality looks like using quality attributes.
  2. A model for exploratory testing. This talked about based upon risk, across 3 factors, how you can come up with a way to decide how much exploratory testing you need to do.

This post will talk about how these 2 things fit together

The above diagram that shows how these 2 things can work in tandem to enable you to decide how to test a new feature.

Let's look at each stage….

Stage 1 

Quality Attributes

At this stage you identify the quality attributes that may be affected by the feature. Depending on your quality attributes this may include things such as:

  • Usability
  • Performance
  • Reliability
  • Security

Other Risk Factors

Also at this stage you can define how you will measure the other risk factors that are part of the model for exploratory testing. The aim here is to define the following:

  • What levels you will have for feature complexity, developer experience and impact the client
  • How will you measure the amount of exploratory testing you will do based upon the combination of complexity, developer experience and impact to client

Stage 2

At this stage you: 

  • Assess what risks impact each quality attribute as well as the level of risk. For example this could be that the new feature could pose a high risk to the performance attribute because the feature will have to do a lot of database calls. The output of this will be that all risks to the quality attributes have been identified as well as their risk level
  • Analyse each of the risk factors for the feature. So this is assigning levels for complexity, developer experience and impact to client for the feature. The output of this will be the levels for the complexity, impact to client and developer experience.

Stage 3

Now that you have the output from stage 2 you now have the information needed to help you come up with the actions and decisions that are required in order to test the feature. These actions and decisions should help do the following:

  • Manage risks to the quality attributes For example, How will the team manage the risk to the effect on performance? Will there be additional performance tests added?
  • To manage the risks at a team, technology and client level. This is manifested in the amount of exploratory testing that will be done on the feature and will be defined by the levels identified in stage 2.  What this is doing is thinking about other risks outside of the teams defined quality attributes and looks more at the team (developer experience), technology (complexity) and client (impact to client) risks that can impact the quality of a feature.

Stage 4

This brings us onto stage 4. Once all other stages are done you now as a team can make a decision about how, why, where and when the testing will be performed for that feature.  By working through this process you understand the risks and can put plans in place to manage them with your testing strategy for the feature.

Now who does that testing is a discussion for another post……..

Comments

Popular posts from this blog

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide

Testing and Mindfulness

How aware are you? Do you live in the here and now or is your mind always somewhere else? This blog post is about Mindfulness. Mindfulness is a simple meditation and is defined as (According to Wikipedia): "The intentional, accepting and non-judgemental focus of one's attention on the emotions, thoughts and sensations occurring in the present moment" Now Mindfulness has become more popular in the west in recent years as it has shown to have benefits for people who are suffering from Depression and Anxiety. It has been around for a while and is often thought to of originated from Buddhism and some people believe it started thousands of years ago. Now modern life is hectic and I’m sure we all have lots of things going on in our lives that keep our Brains busy and trying to focus on one thing at a time can be a challenge. I can't remember the number of times I've been doing something and my mind is somewhere else entirely. Mindfulness helps you focus on

Building a test strategy for a new team

Teams, we have all been on them. Some are good and some are bad. Some we never wanted to leave and others we probably couldn't wait to leave. Now most of the time (well in my experience anyway) you tend to get put into a team that already exists. Maybe you are a new hire or maybe you have asked to change to a different product team.  When you do this, more than likely there will already be a testing strategy in place. It may be that you adapt it and change it in any way you see fit to improve the testing. But imagine if everyone on the team was new? How would you decide your testing strategy? This post will go through some useful things you can do to help a new team develop a test strategy. Table of Contents ๐Ÿ“ˆ What is a Test Strategy? ๐Ÿค” Where should I start? ๐ŸŽฏ Understand the company and their goals ๐Ÿ’ช Play to the teams strengths ๐Ÿ‘️‍๐Ÿ—จ️ Understand what quality looks like ๐Ÿ“ Understand Scope ๐Ÿงช Understand the type of tests you need ๐Ÿ“Š Measure your success ๐Ÿค Collaborate ๐Ÿ“ Summar