Testing "Software" Times

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

  In my previous few posts I have talked about a couple of things. What does quality look like? This talked about understanding what quality looks like using quality attributes. 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 hav