MoT Leeds hosted a panel discussion on Leading with Quality, which sparked a lively debate on several topics. The unexpected one was which AI had written the questions! It didn't, it was all me. He...

Emily is delivering a talk called how raising quality bug cards prepares you for becoming a quality leader

The BOSCARD mnemonic is a tool that can be used to help understand the context around the problem or project. It also serves as the minimum context needed for a one page test strategy.BOSCARD stands for; Background – reason for the project, key stakeholders etc. Objectives – What are you trying to achieve? Good objectives are SMART (Specific, Measurable, Achievable, Realistic and Time-bound). Scope – ensure you define the scope (including what is out of scope). Constraints – consider any constraints or restrictions that limit or place conditions on the project. Assumptions – consider all factors that, for planning purposes, are considered to be true before starting. Risks – outline any risks identified and a quick assessment of each. Deliverables – define what is going to be tangibly produced.

A “branching strategy” refers to the strategy that a software development team employs when writing, merging and shipping code in the context of a version control system like Git. Teams adopt a branching strategy because it enable parallel development and keeps the main codebase stable.With branching, each code author works locally in a separate branch focused on a specific task. Branches are published and merged following peer code review. There are two main types of branches; persistent and ephemeral. Persistent branches are long-lived, holding stable, shared code that reflect the state of the project at key stages.  Ephemeral branches are short-lived and focus on specific development tasks. Engineers create them from a persistent branch and delete them after merging.  Example An example branching strategy is GitFlow which supports structured, multi-stage software development using a pre-defined set of persistent and ephemeral branches. There are three persistent branches. The main branch contains production-ready code. Teams tag it for releases (e.g., v2.0.1) and often configure CD pipelines to deploy it automatically. The develop branch acts as an integration branch. Developers merge completed feature branches into develop for staging and testing. A release/* branch stages code for production release. Teams fork a release/* branch from develop to stabilize a version before release. Only bug fixes, documentation updates, and final QA changes are allowed in a release branch. There are also ephemeral branches. A feature/* branch isolates work for a new feature, enhancement, or experiment. A developer branches a feature/* branch from develop, works on it independently, and merges changes back after review and testing. They then delete the branch. A hotfix/* branch is an emergency fix to main to address critical issues in production. Developers create such a branch main, fix the issues, and merge the changes into both main (to deploy) and into develop (to sync), and deploy immediately. They delete the branch after merging. Gitflow Workflow Create a feature/* branch from develop. Work on the feature. Merge feature branch into develop. When ready to release, create a release/* branch from develop. Finalize the release in the release/* branch. Merge the release into both main and develop. Tag the release on main for versioning. Testers should seek to understand the branching strategy adopted in their teams, to understand changes in the test environment and how code is shipped to end users.

Influencing theDesignEvaluation, andAcquisition ofTools to support testingThe idea-t framework contains 12 heuristic questions and supporting information which are intended to provoke thought and ideas when designing or choosing a test tool.

Our printed version of The Testing Planet has a center spread of 'spot the difference' and this year it was inspired, supported and created with the wonderful Emily O'Connor Here she is at MoTaC...

Cognitive dissonance is the mental discomfort that results in holding two conflicting beliefs, values or attitudes. People tend to relieve this tension in different ways such as rejecting, explaining away or avoiding new information, which is easier than changing your beliefs like “it works on my machine”!

Confirmation bias is an error in judgement that results in a person being more inclined to believe information that confirms their existing beliefs. This can impact software testing in multiple ways such as; not investigating particular system areas due to the belief that they are high-quality, being unable to identify edge cases due to your own use of the system under test or bug reports being dismissed if they do not fit the teams mental model of system functionality.

A cognitive bias is a systematic error in thinking that affects the decisions and judgements that people make. This could be described as “a deviation from reality in judgement” due to our limited memory, mental capacity, attention span or inability to separate from our emotions.Examples in software testing include: Looking for bugs you already suspect, rather than exploring unexpected behaviours Underestimating the number of test cases or the amount of time needed to test complex interactions