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

  How do you know the software product your team produces is quality?  Well the answer is… you don't  really  know, the only people that can evaluate the quality of a piece of software is the customer. Some of you may disagree, but for me having been part teams that develop software that we don’t use on an everyday basis in real world situations, we are not in a position to say whether it is quality or not. It's like building a car and never driving it - how do you know it's any good? However,  what we can do is understand under what conditions we are happy to ship our product to our clients. What we can do is to define what we think our 'internal quality' is and what it looks like.   So how can we define what quality looks like?  In the dim and distant past I have worked in places where so long as the software worked it was OK to be shipped. Yeah they may have been a quick check to make sure the system wasn’t slow but outside of that it was pretty much all about fu