The episode explores superstitions in quality work, including cultural beliefs about unlucky numbers, “don’t deploy on Fridays” practices, and team rituals, while emphasizing collaboration, process improvements, and the role of bugs in driving systemic changes. Examples like unreproducible bugs, demo anxieties, and the “This works on my machine” myth highlight how superstitions shape testing practices and team dynamics.

MOT This Week in Testing

MOT - This week in Testing - Varied hosts, group chat, often with community questions and involvement. Show notes have a full transcript.

• https://www.ministryoftesting.com/podcasts
• https://www.ministryoftesting.com

Episode Details

• Show Notes: https://www.ministryoftesting.com/podcasts/this-week-in-testing?wchannelid=czgwdadw2c&wmediaid=aj1dors1zs
• Published: 2026-02-13T16:54:34Z
• Duration: 49:13
• Author: Unknown

Overview

The podcast investigates how superstitions play a role in quality work, particularly in testing, where intuition and predictive instincts often lead to the development of unofficial beliefs and rituals. It examines the historical and cultural origins of superstitions, such as the perceived unluckiness of Friday the 13th, and draws parallels to practices in software development, like avoiding deployments on Fridays or the belief that bugs vanish during screen sharing. The discussion highlights how these beliefs, while not always rooted in logic, can influence testing processes and contribute to team culture.

The podcast also considers the challenges of dealing with unreproducible bugs and how past errors can lead to the creation of new, more effective testing practices. It acknowledges that, despite their lack of logical foundation, superstitions can serve as informal team rituals that foster a sense of shared experience and strengthen collaboration within the testing community. These practices, though unofficial, may provide psychological comfort and a sense of control in an otherwise unpredictable field.

What If

• What if you implement a strict no-deployment policy on Fridays for critical systems?

  • Move: Create a company-wide rule to avoid deploying code on Fridays, especially for systems involving real money or user data.
  • Why now: The text highlights that avoiding Friday deployments reduces risk of compounding issues over weekends and aligns with practical concerns (not superstition).
  • Expected upside: Fewer post-deployment emergencies, improved team morale, and faster resolution of issues that do arise during the workweek.

• What if you containerize all test environments using Docker to eliminate the “This works on my machine” superstition?

  • Move: Adopt Docker or similar tools to ensure test and production environments are identical across all developer machines.
  • Why now: The text notes that environment discrepancies are a root cause of superstitions, and Docker was developed specifically to address this.
  • Expected upside: Reduced debugging time, higher confidence in test results, and fewer “works on my machine” surprises during production rollouts.

• What if you introduce a mandatory pre-release quality gate that checks for environmental consistency and edge cases?

  • Move: Automate a quality gate (e.g., via CI/CD pipelines) that blocks deployments unless all tests pass across multiple environments and edge conditions.
  • Why now: The text references a case where a deployment error was fixed by implementing a quality gate, which prevented future discrepancies.
  • Expected upside: Fewer production bugs, faster root-cause analysis, and increased trust in automated testing as a replacement for superstition-based practices.

Takeaway

• Involve engineers early in the design process to foster collaboration and reduce miscommunication, as highlighted by Claire Norman’s experience where early engineer involvement led to smoother workflows.
• Avoid deploying code on Fridays due to practical risks like reduced team availability and increased difficulty in resolving weekend issues, even if the decision is based on logistical concerns rather than superstition.
• Use containerization tools like Docker to eliminate environment inconsistencies that cause the “This works on my machine” superstition, ensuring reliable testing across different setups.
• Implement quality gates and deployment checks after a problematic release (e.g., discrepancies between tested and deployed code) to prevent future issues, as demonstrated by the example of fixing coordination between customer and merchant app deployments.
• Always perform smoke testing even when concerned about real money being at stake, as skipping it (like in Ujwal’s case) led to critical post-deployment issues that could have been avoided with basic validation.