My friend, who I coached as a junior cricketer, has qualified for Ultimate Pool in the UK. I'm sponsoring him to cover fees and travel. When I gave him my details I put my company as the Ministry o...

I missed parts of This Week in Quality today because my toilet seat broke and I don't like sitting on porcellaine. So I had to go buy a new one. With the MoTaverse being the MoTaverse, it's no su...

Hear honest job-search and career-change stories, pick up confidence-boosting advice from the community, and enjoy the wonderfully weird side-threads that make the MoTaverse feel like home.

Evolve from executor to orchestrator by integrating AI and holistic product insights to accelerate quality in high-stakes engineering environments.

This week, I spent some time meeting and talking with Shawn Vernier. It was great hearing about his background, what brought him to QA, and the value he finds in the QA Community. As he spoke, I to...

A quality police dynamic can occur when teams become divided, and Quality Engineers are positioned, explicitly or implicitly, as the people who “approve” work. In this situation, they can become de facto gatekeepers rather than collaborators, which may create an “us vs them” dynamic in teams, lead to defensive behaviour around incidents and bugs, and reduce psychological safety. Impact Developers and engineers may disengage from quality ownership. Quality Engineers may be blamed for missed issues. Collaboration may decrease rather than increase. Root cause This may happen when shared ownership is talked about in teams, but accountability is not truly shared. It can be noticeable in teams where authority remains centralised while responsibility is supposedly distributed.

A toast message (or often simply referred to as "toast") is a small, non-modal notification that pops up briefly on a screen to provide feedback about an operation.Key characteristics: Non-intrusive: It appears over the UI but does not block the user from interacting with the rest of the application. Transient: It disappears automatically after a few seconds without requiring the user to dismiss it, and goes away quickly. Informational: Typically used for low-priority updates, such as "Message Sent," "Settings Saved," or "Item Added to Cart."

Traditional software testing is the process of evaluating a software application through test scripts to ensure it meets specified requirements and is free of bugs.In a traditional (often Waterfall) environment, testing is typically a distinct phase that occurs after the code has been fully developed but before the product is released to the user.Key characteristics Sequential timing: It usually follows a "test-last" approach, occurring at the end of the development lifecycle. Verification & validation: It confirms the software does what it was designed to do (Verification) and ensures it fulfills the user's actual needs (Validation). Documentation-heavy: Relies on formal and detailed test plans, test cases, and requirement traceability matrices, without much room for flexibility. Goal-Oriented: The primary objective is to identify bugs, errors, or gaps in the software to ensure quality and reliability. Pros and consThe Pros Stability and clarity: Since testing starts after the design phase, the "goalposts" rarely move. Testers know exactly what to look for based on fixed documentation, which can be good for heavily regulated industries where requirements can be very explicit, specific and detailed. Structured control: It’s easy to track progress and milestones. You know exactly when the testing phase begins and ends. Discipline: The heavy emphasis on documentation (test plans, scripts, and logs) creates a highly traceable audit trail, again a big plus in regulated industries. Reduced complexity: Because the software is "finished" before testing starts, there’s no need to worry about the code changing while you're trying to find bugs. The Cons Risk and rigidity: Late Bug Discovery: Finding a fundamental flaw at the very end of the cycle is expensive and time-consuming to fix, which means that testing is often perceived as a bottleneck. High risk of delays: If testing reveals a major issue, the entire release date is pushed back, as there is no "buffer" time. This can lead to bugs being ignored or swept under the rug. Lack of Flexibility: It’s very difficult to pivot. If a user's needs change halfway through development, traditional testing usually can't account for it until the next major version. The result of this rigidity is additional costs, in terms of time and money. The "Wall" effect: There is often a disconnect between developers and testers, leading to a "throw it over the wall" mentality rather than collaboration. Isolated teams communicate less effectively, which can cause misunderstandings and rivalries.

As I screwed up making coffee this morning and have to drink out of Robert’s mug.I am reminded that cute designs can also have a terrible user experience as this little bear’s ears stab me in the f...

Bots can have default messages to greet, but they can be troublesome