TestBash is an annual opportunity for testers across the globe - and MoTaverse - to get together in a single place.  More than just a conference, it's a friendly and welcoming place to meet other people who are passionate about testing, quality, and community.  From scheduled talks to planned workshops to spontaneous chats, there are plenty of opportunities to learn and get to know people from the community.  The MoT team take care of participants by organising a diverse range of contributions and contributors, offering accommodations, and providing quiet spaces.  TestBash is truly something special, which has helped to launch speaking careers, bud friendships, and grow testing and quality enthusiasts.

Test design is both a creative and scientific process for determining what and how to test. The what is about making it something that's going to be useful information that's going to actually help someone in at the end of the day. For me, the how plays a big part in that as well because I've seen that happen where someone maybe thinks that they're testing a certain thing, but the how that they're doing it actually is testing something else.The how is important as well.

A mnemonic I came up with while trying to think of ways to help people test like a tester

Put extremely simply, a test to me is an experiment; a way of conducting research. I see a lot of cross-over with, and ideas we can draw from, the area of science. I don’t think we need to get super specific about what a test is, because the possibilities are so broad. I think that’s a good thing, and one of the fun things about testing.

To me, it’s more or less about baking in quality from the start, always having an eye on the state of an SUT and how to improve it as you go along. This would be in contrast to building a thing entirely before thinking about whether or not it actually solves a problem or adds any value or whether anyone would actually want to use it. - Cassandra H. Leung

Acceptance criteria are a list of points on a work item (often a documented as a ticket in a work tracking tool) that must be completed in order for: The work item to be considered "done" in the workflow Stakeholders (e.g., product owner, customer, end users) to accept the work as complete It can be helpful to write acceptance criteria in a "given, when, then" format.  For example:Given I'm not logged into the system,When I navigate to the My Profile page,Then I will be prompted to log inAcceptance criteria can be used to generate testing ideas, and they can also be tested themselves.  Does the described behaviour make sense in context?  Is this really necessary in order to solve the problem?  Is the implementation method really crucial to the acceptance of this work item?One of the best ways to write acceptance criteria is during a collaborative, story shaping meeting, such as Three Hats / Three Amigos or a refinement session, where people from different disciplines are present.  This will help the team to raise questions and concerns as early as possible.

Heuristics are resources or tools you can use most of the time to help you with stuff. It's not always going to be correct, but most of the time, it can help you in some way.

Risk is about much more than just defects or products. Risk is about impact; consequences; human beings. A risk isn't just a bug that might happen. A risk is something which could have a significant negative impact on real people.

It's normal for us to have biases - a tendency to lean one way or another, which we may or (more commonly) may not be aware of.  This can affect the judgements and decisions we make in an unreasonable or unfair way.Say, for example, you prefer the colour blue over red.  When given the choice to accept one of two people into your team, you may choose the person who is wearing blue over the person who is wearing red, because you like blue better and subconsciously take that to mean the person wearing blue is the better choice.  In reality, the two things have no relation, so it would be unreasonable to make your decision based on this.The difficulty is that if you're not aware of this bias, it's very difficult to counteract.  That's why biases can be dangerous, and it's important that we make a conscious effort to try and identify them, and remain open to other, more logical factors to base our judgements and decisions on.In software production, biases can cause us to miss potential issues or risks, or make decisions which do not support the quality of the product.  If you have a particular stance on something but you don't know why, or notice a pattern in your behaviour that can't be reasonably explained, there may be biases at play.  Take it as an opportunity to check in with yourself and review which facts are and are not relevant.

Explore various strategies and mindsets that promote continuous learning

Boost your career in software testing with the MoT Software Testing Essentials Certificate. Learn essential skills, from basic testing techniques to advanced risk analysis, crafted by industry experts. Early access available now at a discounted rate!

PowerPoint Karaoke is an improvisation game where each person presents 5 slides to an audience without knowing the contents of the slides or the topic!