RBP has been updated and given a nice new UI plus some bonus improvements

Good tests and bad tests do not really exist. It’s up to us as testers to create quality tests and determine what are the most suitable tests to discover information about specific risks. We can do this by questioning and discussing ideas with our teams. Additionally by discovering risks, forming test ideas around those risks, and being observant when executing them. Not every test will be of the same quality, or be structured in the same way, so you need to remain vigilant. It’s up to us, as we test, to question what we have done and what we have learned, to see if assumptions were made or if details were missed. We can always learn and improve to deliver better testing.

Diagrams are abstract graphical representations of complex ideas and systems. They're used to convey information, facilitate discussions. In the world of software and testing, diagrams can come in many forms. Diagrams can be used to describe complex systems in ways that plain language cannot. It can trigger discussion and help weed out any misunderstandings and assumptions. They're easy to create and build during collaborative sessions.Diagrams are models, and all models are flawed. Each diagram has a specific purpose, and misusing the diagram can cause problems. Assumptions are made when creating diagrams, and ignoring those assumptions may lead to issues and bugs. Diagrams give us one perspective of a system or idea, and your project may require more than one perspective.Diagram examples:  You could have process diagrams that describe a sequence of actions, which will carry out on the triggering of an event.  Wireframe diagrams that show how UI components are laid out on a web page.  Data flow diagrams that show the flow of data through a system.  Integration maps that show how services connect to one another. 

The dictionary definition of a risk is a situation involving exposure to danger. Software development risks are situations that can negatively impact your project, your product, or your business. This may include loss of quality, money, damage to reputation, or safety to others. Identifying risks early can help you mitigate them. You can determine as a team whether they are unacceptable or unacceptable risk. Risks can also inform how and where we should test as well. Just like you can't find every bug in a product, you can't discover every risk. Risks can appear anywhere on a project or a product, which in a large domain can be hard to manage. Risks are viewed very negatively in many cases for some people, and they can be biased towards not wanting to identify them or accept them. As software testing and quality professionals we sometimes have to be advocates for risks, which takes skill. Example risks: Installability is a type of risk. This is a risk around installing maybe an app on your phone. There are different types of data risks which are around the amount of or the type of data flowing through your application. There are also performance risks. Performance risks could be user load or data load, that affects the speed, of your applications. 

Biases or cognitive biases are irrational judgments or subconscious inferences made from the data available to us. In testing, biases have the effect of causing you to miss or focus too much on specific behavior, processes, or data. We use our knowledge of biases in testing to improve our strategies by using biases to our advantage. Biases can be used as a heuristic, for example, in learning about our team's desires and expectations. Ignoring biases can affect your perception of the product you're testing and the quality of your testing. It may lead to gaps in your testing, and bugs could slip through. You need to be aware when you're using a bias deliberately that there is potential information you're missing out on, and you need to carry out additional activities to balance it out. Being conscious of biases allows us to attempt to prevent them from negatively impacting our testing. We could also use biases to focus or zone in on specific testing activities. Example biases: Inattentional blindness, when you miss something in one area of the application because you're focused on another point. Confirmation bias, when you promote data that proves your point of view and ignore data that challenges it. Observational bias. So the expectancy what that what we see, what we want to see, or in testing, create tests to return what we want to see. 

Four people. A woman and three men standing next to each other looking cool at the camera – they are attempting to look like they are in a band. One of them is holding a phone with a picture of ano...

Elevate to senior test automation roles with mastery in automated checks, insightful reporting, and framework maintenance

Unlock the essential skills to transition into Test Automation through interactive, community-driven learning, backed by industry expertise

Ascend to leadership roles by mastering strategic skills in automation strategy creation, planning and execution

At TestBash Autumn 2023