Testing "Software" Times

In this post I am going to talk about monitoring and observability. Now what are monitoring and observability? Monitoring is defined as….. "to watch and check a situation carefully for a period of time in order to discover something about it" From <https://dictionary.cambridge.org/dictionary/english/monitoring> Observability is defined as….. "to watch carefully the way something happens or the way someone does something, especially in order to learn more about it" From <https://dictionary.cambridge.org/dictionary/english/observe?q=Observing> So the main difference between the 2 is that one is around checking to discover something whilst the other is about watching something in order to learn more about it. Why are both important? They are both important as they can tell us different things about a system and can provide us with information that can feed into decisions and actions that can be made both now and in the future to improve software quality as

Feedback is important. In fact feedback is what helps us improve and enables us to make informed decisions at the correct time. For example imagine you are driving a car in icy weather and the steering goes light. This feedback tells you that you need to take action as it is likely your car has started to slide. So feedback can help us take action to keep us safe and without it the human race would still be stuck in the dark ages. Now typically you will be asked for feedback in the following types of situations: Feedback on a training course Feedback on colleges for the appraisal process However, there is more to feedback than that. This post will talk about why feedback is important, the effects of slow feedback and how if this feedback was quicker how it would lead to better outcomes. What is feedback? Here’s the definition from Wikpedia: “information about reactions to a product, a person's performance of a task, etc. which is used as a basis for improvement.” So feedback is all

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