# Anne-Marie Charrett > I write and work with tech and product leaders on the quality and organisational problems that stall good teams. Three decades in engineering Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### What I do URL: https://www.annemariecharrett.com/aboutme/ Last updated: 2026-05-06T22:31:00.000Z If you know what you need, email [hello@annemariecharrett.com](mailto:hello@annemariecharrett.com). I'll point you to the right next step. If you're still working out the move, [go to Know Your Move](https://www.annemariecharrett.com/knowyourmove/). #### Coaching and training I coach people working in quality, engineering, and leadership roles — especially where the challenge is organisational, not just technical. I also deliver training in exploratory testing, quality coaching, and thinking more clearly about quality in practice. #### Advisory and consulting I work with organisations that want to strengthen quality engineering practices, build better judgment into delivery, and create more sustainable ways of working. Usually less about fixing testing, more about improving the system around it. #### Speaking I speak at conferences, leadership forums, and selected community events on quality engineering, leadership, systems thinking, and change. I do a limited number of in-person events each year and I'm selective about where I spend that energy. If you're considering me for an event, send the details to [hello@annemariecharrett.com](mailto:hello@annemariecharrett.com): audience, format, timing, and what kind of conversation you want to create. #### Writing Essays, field notes, the newsletter, and *The Quality Coach's Handbook*. The ideas show up in different forms. The through-line is the same: better systems, better judgment, better conversations about quality. ### Talks & Articles URL: https://www.annemariecharrett.com/articles_and_talks_on_software_testing/ Last updated: 2021-10-18T09:36:18.000Z An out of date page which I intend to clean up, just not today.... **CoachingTesters Talk** at Lets Test Stockholm May 2012\. Here are some photos by [@ru\_altom](http://twitter.com/ru%5Faltom/status/201892673450287105/photo/1/large?ref=annemariecharrett.com) & [@DuncNisbet](https://twitter.com/?ref=annemariecharrett.com#!/DuncNisbet/status/199869512949055488/photo/1) and a write up by David Greenlees We are the 99% Movie of STPCon Keynote March 2012 or if you prefer the Slides Video Interview at CAST 2011 on coaching software testers Article on CoachingTesters **SoftwareTestPro:** [Coaching Testers Podcast Twist #69](http://static1.squarespace.com/static/59a16751f43b558cac63ce35/59a1698187da808b8645e63f/59a16a6687da808b8645fb82/1503750758456/69-charrett-coaching-testers.mp3?format=original&ref=annemariecharrett.com) **SoftwareTestPro:** Coaching Testers Podcast Twist #70 **StickyMinds Article:** [From One Expert to Another: Meeta Prakash ](http://www.stickyminds.com/s.asp?F=S17212%5FCOL%5F2&ref=annemariecharrett.com) *(you may need to login)* Coaching Testers Podcast (Eurostar) **Article: Test Testing Planet:**[ I’m a tester get me out of here! October 2011](http://www.thetestingplanet.com/2011/11/im-a-tester-get-me-out-of-here/?ref=annemariecharrett.com) CAST Conference: Coaching Testers STANZ Melbourne: Motivating Testers **Interview**: by Testing Circus April 2011 **Article: The Testing Planet – Monkey Business March 2011** Free PDF to be released shortly. **Article: [Beware the Lotus Eaters](https://mavericktester.com/beware-the-lotus-eaters/?ref=annemariecharrett.com) February 2011** I wrote a feature article for Logigear Magazine, it starts on page 8. **Talk: Exploratory Testing Workshop, Agile Tours, October 2010** **[Exploratory testing workshop](http://www.slideshare.net/amcharrett/exploratory-testing-workshop?ref=annemariecharrett.com)**View more [presentations](http://www.slideshare.net/?ref=annemariecharrett.com) from [Anne-Marie Charrett](http://www.slideshare.net/amcharrett?ref=annemariecharrett.com). **Talk: Discover you Inner Tester at Dublin DDD October 2010** **[Discovering your inner tester](http://www.slideshare.net/amcharrett/discovering-your-inner-tester-5402765?ref=annemariecharrett.com)**View more [presentations](http://www.slideshare.net/?ref=annemariecharrett.com) from [Anne-Marie Charrett](http://www.slideshare.net/amcharrett?ref=annemariecharrett.com). **Article on Software Testing and Startups** This article appeared recently in T.E.S.T magazine on the pros and cons of working with startups T.E.S.T Magazine, June 2009 **Presentation on software testing and startups** I gave this presentation to SOFTTEST on working with startups. Its got some information on where I source my work, the type of work I get and what I see as the key criteria a tester needs to have working for startups. [Startups And Software Testing](http://www.slideshare.net/amcharrett/startups-and-software-testing?ref=annemariecharrett.com)View more [documents](http://www.slideshare.net/?ref=annemariecharrett.com) from [amcharrett](http://www.slideshare.net/amcharrett?ref=annemariecharrett.com). Presentation June 2009 You will need adobe reader to view it. ## Article on Software Test Consulting This article is a bit of fun, but gives an insight into what it takes to become a successful software test consultant. [Twelve Traits of a Tip Top Test Consultant](http://www.slideshare.net/amcharrett/twelve-traits-of-a-tip-top-test-consultant?ref=annemariecharrett.com)View more [documents](http://www.slideshare.net/?ref=annemariecharrett.com) from [amcharrett](http://www.slideshare.net/amcharrett?ref=annemariecharrett.com). ### Privacy Policy URL: https://www.annemariecharrett.com/privacy-policy/ Last updated: 2025-11-01T21:54:27.000Z This site is run by **AMH Solutions Pty Ltd** in Sydney, Australia. We use [Ghost](https://ghost.org/?ref=annemariecharrett.com) as our publishing platform. ## What Information We Collect **When you subscribe or purchase an article:** - Your email address - Your name (if you provide it) - Payment information (handled by Stripe - we never see your card details) **Automatically collected:** - Which articles you read - Your IP address and browser type - How you use the site (via Google Analytics) ## How We Use Your Information We use your data to: - Give you access to content you've paid for - Keep you logged in - Send receipts and subscription updates - Improve the site and understand what content is popular We don't sell your information. We don't share it except where necessary (see below). ## Who We Share Data With **Google Analytics** \- We use Google Analytics to understand how people use the site (which articles are popular, how long people read, etc.). See [Google's privacy policy](https://policies.google.com/privacy?ref=annemariecharrett.com). **Senja** \- We use Senja to display testimonials. See [Senja's privacy policy](https://senja.io/privacy?ref=annemariecharrett.com). **Stripe** \- Processes payments securely. See their [privacy policy](https://stripe.com/privacy?ref=annemariecharrett.com). **Ghost** \- Our publishing platform. Self-hosted, so your data stays with us. **Legal requirements** \- We may need to share information if required by law. ## Your Rights You can: - **Access your data** \- Ask us what we have - **Correct your data** \- Update your details anytime - **Delete your account** \- We'll remove your information - **Export your data** \- Get a copy in a readable format To exercise these rights, email: **[privacy@annemariecharrett.com](mailto:privacy@annemariecharrett.com)** ## How Long We Keep Your Data - **Active accounts:** Until you delete them - **Purchase records:** 7 years (Australian tax requirements) - **Deleted accounts:** Permanently erased within 30 days ## Cookies We use cookies to keep you logged in and make the site work. **Analytics cookies:** We use Google Analytics to understand which content is popular and how people use the site. You can opt out using browser extensions like [Google Analytics Opt-out](https://tools.google.com/dlpage/gaoptout?ref=annemariecharrett.com). For more details, see our [Cookie Policy](COOKIE%5FPOLICY.md). ## Security Your data is protected with: - HTTPS encryption - Secure authentication - Regular security updates - Stripe's PCI-compliant payment processing ## International Users Our servers are in Australia. If you're accessing from overseas, your data will be processed here. For EU users: We comply with GDPR. You have the rights listed above under "Your Rights". ## Changes to This Policy We'll update this page if our privacy practices change. Major changes will be announced via email. ## Contact Questions about your privacy? Email **[support@annemariecharrett.com](mailto:support@annemariecharrett.com)** **AMH Solutions Pty Ltd** Sydney, Australia --- ## Content Ownership All content on this site is owned by Anne-Marie Charrett and may only be used with permission, except where marked with a Creative Commons license. Content with a Creative Commons license may be used according to the terms of that license. --- *This policy is based on [Ghost's privacy policy](https://ghost.org/privacy/?ref=annemariecharrett.com) with additions specific to our subscription and pay-per-article features.* ## ### terms of service URL: https://www.annemariecharrett.com/terms-of-service/ Last updated: 2025-11-01T21:58:06.000Z # Terms of Service **Last Updated:** November 2, 2025 Welcome! This site is run by **AMH Solutions Pty Ltd** in Sydney, Australia. ## The Basics By using this site, you agree to these terms. If you don't agree, please don't use the site. ## What We Offer **Free Content** \- Available to everyone **Paid Subscriptions** \- Monthly or yearly access to all premium content **Individual Articles** \- Buy single premium articles for one-time access ## Your Account **You need to:** - Be at least 16 years old - Provide a valid email address - Keep your password secure - Not share your account **We'll:** - Keep your account secure - Never share your password - Let you delete your account anytime ## Subscriptions **How it works:** - Subscribe monthly or yearly - Access all premium content while subscribed - Cancel anytime (no refunds for unused time) - Auto-renews unless you cancel **Cancellation:** - You can cancel from your account settings - Access continues until the end of your billing period - No refunds for partial months/years ## Pay-Per-Article Purchases **When you buy an article:** - You get permanent access to that specific article - It's a one-time payment (not a subscription) - Access it anytime from your account - No refunds unless there's a technical problem ## Refunds **Subscriptions:** No refunds for partial periods. Cancel before renewal to avoid charges. **Individual articles:** All sales final, except if we can't deliver the content due to technical issues. **Problems?** Email **[support@annemariecharrett.com](mailto:support@annemariecharrett.com)** and we'll sort it out. ## What You Can't Do Don't: - Share your account with others - Copy or republish our content - Use the content commercially without permission - Try to hack or abuse the site - Be abusive to others ## Content Rights All content belongs to Anne-Marie Charrett unless stated otherwise. **Your license:** - Read content you've paid for - Access from your personal devices - Keep it for personal use **You can't:** - Republish or redistribute content without permission - Use it commercially without permission - Remove copyright notices ## Canceling Your Account You can delete your account anytime by emailing **[support@annemariecharrett.com](mailto:support@annemariecharrett.com)** If we cancel your account for violations, you lose access to purchased content without refund. ## Service Availability We try to keep the site running smoothly, but sometimes things break. We're not responsible for: - Temporary outages - Technical issues - Service interruptions We're a small operation, so we appreciate your patience. ## Liability We provide content "as is". We're not liable for: - How you use the information - Decisions you make based on the content - Indirect damages or losses **Maximum liability:** The amount you paid for the specific content in question. ## Changes to These Terms We may update these terms. If we make significant changes, we'll email you. Continuing to use the site means you accept the new terms. ## Governing Law These terms are governed by Australian law. Any disputes will be handled in New South Wales courts. ## Payment Processing Payments are processed by [Stripe](https://stripe.com/?ref=annemariecharrett.com). By purchasing, you also agree to [Stripe's terms](https://stripe.com/legal/consumer?ref=annemariecharrett.com). ## Contact Questions? Email **[support@annemariecharrett.com](mailto:support@annemariecharrett.com)** **AMH Solutions Pty Ltd** Sydney, Australia --- *We keep these terms simple and fair. If something's unclear, just ask.* ### Pricing URL: https://www.annemariecharrett.com/pricing-quality-coach-book/ Last updated: 2024-10-12T08:05:46.000Z Elevate your software testing skills to a new level with my quality coach book _This page is for paying subscribers only._ ### Guest Writers URL: https://www.annemariecharrett.com/guest-writers/ Last updated: 2023-09-16T04:12:55.000Z _No content available._ ### Dictator or Liberator URL: https://www.annemariecharrett.com/dictator-or-liberator/ Last updated: 2023-09-23T21:29:20.000Z _This page is for subscribers only._ ### Testimonials URL: https://www.annemariecharrett.com/testimonials/ Last updated: 2024-10-12T06:12:49.000Z _No content available._ ### Quality Coach FAQ URL: https://www.annemariecharrett.com/faq/ Last updated: 2025-11-01T21:51:34.000Z ## Billing & Invoices ### How do I get an invoice or receipt? You can view and download your invoices anytime through the Stripe billing portal: **[Get Invoice/Receipt](https://billing.stripe.com/p/login/5kA6p7cEW9C6g00000?ref=annemariecharrett.com)** After logging in with your email, you'll be able to: - View all past invoices - Download receipts as PDFs - Update your billing information - View your payment history ## Managing Your Subscription ### How do I cancel my subscription? You can cancel your subscription anytime: 1. Click the **Account** or **Subscribe** button in the navigation menu 2. Go to your account settings 3. Click **Manage Subscription** 4. Select **Cancel Subscription** Your access will continue until the end of your current billing period. ### How do I upgrade my subscription? To upgrade from free to yearly: 1. Click the **Account** button in the navigation menu 2. Go to your account settings 3. Click **Manage Subscription** 4. Select the Quality Coach Book plan option You can also upgrade from the free newsletter to paid subscription the same way, or click **Subscribe to Quality Coach Book** on the home page. ### Can I change my email address? Yes! Log in to your account and you can modify your email address and other details from your account settings. ## Email & Newsletters ### How often will I receive emails? We send emails at the following frequency: **Free Newsletter Subscribers:** - **1 email per month** \- Monthly Quality Coach Newsletter featuring community picks, recent articles, and quality engineering insights **Paid Subscribers (Quality Coach Book):** - **1 email per month** \- New Quality Coach Book chapter (sent early, before the newsletter) - **1 email per month** \- Monthly Quality Coach Newsletter (same as free subscribers, sent after book chapter) - **Average: 2 emails per month** Paid subscribers get early access to new content - book chapters are delivered to your inbox first, then featured in the monthly newsletter that goes to all subscribers. We respect your inbox! You can unsubscribe from any email at any time. ### What's the difference between the newsletter and the book? - **Newsletter (Free)**: Monthly roundup of quality engineering content, community articles, and general insights. Free members will have accesss to a pay per article model if they wish it. - **Quality Coach Book (Paid - $20/year)**: Monthly chapter releases, workshop templates, practical guides, and in-depth content for quality coaches ## Content & Access ### Can I download the book? No, the Quality Coach Book cannot be downloaded as a single file. Each month, a new chapter is sent to your inbox and posted online for you to read. This "book as a service" model means you get fresh content regularly.You can purchase a Kindle version of the book. See below ### Can I buy the published Quality Coach's Handbook? Yes! The Quality Coach's Handbook is now available for purchase in multiple formats: **Purchase the Quality Coach's Handbook:** - **[Buy Ebook on Leanpub](https://leanpub.com/qc?ref=annemariecharrett.com)** \- Digital version, DRM-free (I get more royalties from Leanpub! 😁) - **[Buy Paperback or Hardback on Amazon](https://www.amazon.com/dp/B0FGYF6DG6?ref=annemariecharrett.com)** \- Physical copies - **[Buy Online Course on Leanpub](https://leanpub.com/c/quality-coach?ref=annemariecharrett.com)** \- Video course with exercises and materials **What's the difference between the published book, online course, and the subscription?** - **Published Book (Leanpub/Amazon)**: Complete, edited version of the handbook - perfect for reference and keeping on your shelf - **Online Course (Leanpub)**: Video-based learning with structured lessons, exercises, and downloadable materials - **Online Subscription ($20/year)**: Access to the original content as it was first published, plus ongoing new chapters and updates All options give you access to quality coaching frameworks, workshops, and practical guides. Choose the format that works best for your learning style! ### What do I get with a paid subscription? For $20/year, you get: - Access to all Quality Coach Book chapters (40+ articles and growing) - Monthly new chapter delivered to your inbox - Workshop templates and instructions - Practical guides for quality coaches - Community discussion and comments - Supporting the creation of quality engineering content ### Do you offer a free trial? Yes! New subscribers get a **5-day free trial** to explore all the premium content before committing. ## Contributing & Testimonials ### Can I be a guest writer? Absolutely! If you want to become a guest writer, please email me at **[contributor@annemariecharrett.com](mailto:contributor@annemariecharrett.com)** All guest content is compensated through book subscriptions. ### Can I provide a testimonial? I'd love that! You can submit testimonials here: **[Submit a Testimonial](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)** Your testimonial may be featured on the website and in promotional materials. ## Technical Issues ### I'm having trouble accessing premium content 1. Make sure you're signed in to your account 2. Check that your subscription is active (Account → Manage Subscription) 3. Try signing out and back in 4. Clear your browser cache and cookies 5. If issues persist, contact me at the email below ### I didn't receive my email 1. Check your spam/junk folder 2. Add [noreply@annemariecharrett.com](mailto:noreply@annemariecharrett.com) to your contacts 3. Check your email settings in your Account page 4. Contact me if you're still not receiving emails ## Still Have Questions? If you have a question that's not answered here, feel free to reach out: - **Email**: [support@annemariecharrett.com](mailto:support@annemariecharrett.com) - **Comments**: Leave a comment on any blog post --- *Last Updated: November 2, 2025* ### Buy the Quality Coach book URL: https://www.annemariecharrett.com/buy-the-quality-coach-book/ Last updated: 2025-06-16T05:20:28.000Z ## Quality Coach Book ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/06/title_page.jpg) #### [Buy in paperback](https://ee23-2403-5811-1d53-00-ab5.ngrok-free.app/?ref=annemariecharrett.com) ### Tip Jar URL: https://www.annemariecharrett.com/tip-jar/ Last updated: 2024-10-13T04:51:29.000Z _This page is for paying subscribers only._ ### Give a Gift Subscription URL: https://www.annemariecharrett.com/gift-subscription/ Last updated: 2024-10-13T04:51:30.000Z _This page is for paying subscribers only._ ### Advanced User Settings URL: https://www.annemariecharrett.com/advanced-settings/ Last updated: 2024-11-08T21:09:59.000Z _No content available._ ### Group Subscriptions URL: https://www.annemariecharrett.com/group-subscriptions/ Last updated: 2024-10-13T04:51:31.000Z _This page is for paying subscribers only._ ### Buy a Group Subscription URL: https://www.annemariecharrett.com/buy-group-subscription/ Last updated: 2024-10-13T04:51:31.000Z _This page is for paying subscribers only._ ### Welcome to the Quality Coach Book URL: https://www.annemariecharrett.com/welcome-to-the-quality-coach-book/ Last updated: 2025-07-09T07:59:36.000Z _This page is for paying subscribers only._ ### Welcome to the Quality Coach Newsletter URL: https://www.annemariecharrett.com/welcome-to-the-quality-coach-book-2/ Last updated: 2025-07-08T22:34:11.000Z _This page is for paying subscribers only._ ### How I Use AI in My Writing URL: https://www.annemariecharrett.com/how-i-use-ai-in-my-writing/ Last updated: 2026-05-03T02:40:34.000Z _This page is for paying subscribers only._ ### Quality Coach Researcher URL: https://www.annemariecharrett.com/quality-coach-researcher/ Last updated: 2025-12-11T11:15:00.000Z ## How Your Data is Used & Protected ### What We Collect When you chat with the Quality Coach Researcher, we store: - **Your questions and the AI's answers** \- saved in a secure database to maintain conversation history - **Your Ghost membership status** \- to verify access (free or paid member) - **Usage metrics** \- like response times and conversation length, to improve performance ### What We DON'T Collect - We never store API keys or passwords in the browser - Your email is only used for access verification (not stored in chat logs) - We don't track your browsing behavior outside the chat widget ### How the AI Works 1. **Your question** is sent to our secure backend server 2. The system searches the Quality Coach's Handbook for relevant content 3. Your question + book excerpts are sent to Llama 3.1 70B model 4. The AI generates a response grounded in the Handbook 5. The answer is returned to you with source references ### Privacy Safeguards - **No training on your data**: Your conversations are NOT used to train AI models - **Secure transmission**: All data is encrypted in transit (HTTPS) - **Rate limiting**: Protection against abuse - **Local embeddings**: Book content search happens on our servers using locally-run models—no external API calls for that step ### Third-Party AI Provider The conversational AI using open-source models (Llama 3.1). Together.ai's privacy policy applies to the text sent for processing. We chose Together.ai because they: - Use high-performance open-source models (not closed systems like GPT-4) - Don't use customer data for model training - Provide transparent pricing and performance ### Your Control - **Beta phase**: Currently free for all members for 3 months - **Data retention**: Conversations are stored indefinitely to improve the service - **Future options**: We're exploring data export and deletion features **Questions?** Contact us at \[support@annemariecharrett.com\] ### archive URL: https://www.annemariecharrett.com/archive/ Last updated: 2026-04-22T00:03:48.000Z _This page is for paying subscribers only._ ## Posts ### From Bulldozer to Scalpel URL: https://www.annemariecharrett.com/from-bulldozer-to-scalpel/ Last updated: 2026-07-08T23:48:51.000Z I've worked on a number of large transformation programs. One of the hardest challenges is aligning a change to a high-level metric. How does rolling out a test-automation tool affect defect leakage? How does introducing a quality coach change delivery outcomes? These questions are notoriously hard to answer. The truth is, what looks like causation is often just correlation. Sure, your metric moved — but perhaps not solely because of the initiative you rolled out. What went unmeasured was the new leadership or the org restructure. And because they weren't measured, their impact goes unnoticed. Any high-level metric shifts for a range of reasons, and many of them sit outside your radar. Engineers treat metrics with extreme wariness. We know metrics are proxies for something you can't count. We measure test coverage because "quality" is subjective and constantly changes. Point a program at a number, and teams will move the number, whether or not anything improved. None of that survives contact with a budget meeting. I've been on both sides of this, in consulting and in salaried roles, and here's what I've learned: arguing why metrics are poor measures wins the argument, rarely the money. "It's complicated, metrics are proxies" doesn't fund the work. Being able to show that something the company cares about shifted does. I know it sucks, but it's the reality. So what's left is pragmatic. Use several metrics so no single one drives behaviour, accept the ones you're handed, and improve what you can. No answer is optimal. For me, pragmatism beats ideology. This leaves me with a slightly sour taste in my mouth. I know it's the right choice to make, but I'm not exactly comfortable with it. ## Measure the gap, not the goal The way out isn't a better metric or a better argument. It's to look one level down, at the failure modes underneath the metric. Instead of "did this initiative move flow efficiency," ask "did this initiative close the code-review wait that a team demonstrably has?" It's a clean question: the wait dropped, or it didn't. And review wait-time is a known component of flow efficiency. So the line of sight runs the other way: flow efficiency, down to the wait state that feeds it, to the failure mode, to the intervention aimed at it. ## This is the Signal Engine This is the engine I described in the [last post,](https://www.annemariecharrett.com/mine-the-gaps/) built on the [design patterns](https://www.annemariecharrett.com/by/) from the first. It starts from the idea that failure will always exist, so we should learn from it rather than treat it as a threat. Here, the failure data does one more job: it drives the change. It reads the engineering and ops data, finds the failure modes a team actually has, matches an intervention to one, and measures whether the gap closed. ## Fit, not mandate Transformation programs are expensive and unwieldy, perhaps why consultants love them. They're driven from the top down and often have little relevance to the change a team actually needs. They're the cod-liver oil of enterprise — you take it because it's good for you. Every team is told to adopt the same initiative regardless of context, which is impossible; you can't apply contract testing to systems that have no APIs. However, that doesn't mean they're ineffective. In organisations where tickets are the currency, a mandated task eventually gets done. It's using a bulldozer to hammer in a nail — clumsy, but the nail goes in. What it costs you is the team, who know better than anyone what the real problem is, and would rather spend the effort elsewhere. That real problem the team knows about? It's a failure mode they feel the impact of every day. The reason might be obvious — long waits on peer review. Or opaque — stories sliced too big. These are the failures the engine reads in the data. Because the gap it measures is the team's own, so is the fix. A blanket mandate ships contract testing to every team — including the ones with no API to test. The Signal Engine matches instead: contract testing where the gap is interface drift, something else where it isn't. Same catalogue, different pick, because the gap is different. That's it. The failure mode you use to prove impact at the budget meeting is the same one that makes the fix fit the team. One buys you the line of sight; the other buys you the relevance. A top-down initiative stops being a bulldozer dropped on every team and becomes a scalpel aimed at the one thing that team needs cut. ### Mine the Gaps URL: https://www.annemariecharrett.com/mine-the-gaps/ Last updated: 2026-07-02T06:34:13.000Z **Every control leaks. The breach is the signal — diagnose it, fix it and use it to harden the most appropriate control.** In the last post, I argued that in software engineering, the terrain never stops moving. The map we draw is out of date the moment we use it. The obvious response is to keep redrawing: add a check for every breach we find. But every addition makes the map denser. Test suites bloat, alerts get buried, and eventually the map is so cluttered we can't read it at all. So how do we design controls that are slim yet trustworthy? Rather than treating a breach as the failure of a control, treat it as a lesson. A failure mode you hadn't thought of or didn't know about. One that makes the system more robust once it's fixed. Use breaches as learning points and your controls get sharper on each one. Every failure leaves the system stronger than it found it. ## Mining for Failure Each failure is a rich vein to mine. Think of any root cause analysis. You start with the obvious: the alert that fired, the logs, the system behaviour. Then you dig. There's the commit that introduced it and the review that passed it. The CI run, and which tests stayed green when they shouldn't have. The metrics and traces either side of the event. The deploy it rode in on and the feature flag nobody knew still existed. An incident timeline and the messaging thread where three engineers worked out what was happening in real time. The Jira ticket, the Confluence design doc that said this case was out of scope, the runbook that didn't cover it. The support tickets from the customers who hit it first, and the revenue tied to those accounts. One failure running through engineering, ops, product, and the business. All of it waiting to be understood so the product comes back more resilient than before. ## Going Underground What would a system that did this look like? To keep the map theme going, I couldn't go past the London Underground, and my days of listening to Mind the Gap as I jumped on the tube at Embankment. Picture the system as an Underground map. The Central line is your deployment pipeline, and each station on it is a control point. Each control is designed to detect a specific type of failure, providing a defence-in-depth approach. Branching off the Central line is the Signal Engine. Its job is to process the failures the controls catch, before and in production. With AI as the enabler, it diagnoses the failure, determines its position in the queue, selects the fix, and applies it to both the system and the controls. Each decision reads from its own catalogue — a failure-mode catalogue for the diagnosis, a priority catalogue that ranks what to fix first, and a catalogue of interventions that are endorsed and accepted as valid fixes. And the Circle line is the loop that carries the lesson back, taking what the engine learned and returning it to the controls so the next failure of that kind gets caught sooner. ## Mining the Gaps The Signal Engine is where AI does the work. Any failure is a trigger that fires it: diagnosed, weighed, fixed, and left behind as an early hardening layer for whatever changes next. **Diagnose** — Is it a failure of the control or the system? What's the nature of the failure mode? Where else in your system and/or control does this failure mode reside? Use existing code as the source of truth. **Prioritise** — not every gap deserves your best effort today. What's the impact, technical or business? What's the likelihood it recurs, and what does it threaten — from a customer and business perspective? Rank it against everything else that's open. **Select** — reach for a fix that fits. The reflex is "add a test." But the better lever might be to slice the change into smaller pieces, harden a control, or fix the code itself. Match the fix to the gap. **Verify** — leave a sensor behind, and leave it at the control that should have caught this in the first place. A failing unit test, not a customer ticket. Early and cheap often beats late and expensive. The cheapest option is never having it happen in the first place. **Learn** — harden the catalogues. Write down what you learned, where the engine can find it next time. ### Flaky Test Example Imagine you have a test in your test automation suite. The test fails in CI. This is how the Signal Engine might operate. **Diagnose:** The engine matches it against the test interdependence failure mode: two tests sharing the same setup. It then walks through your repository looking for this pattern in your codebase. **Prioritise:** The test impacts a critical business scenario, placing it at the top of the queue for fixing. **Select:** Fixing the setup is the identified fix; however, it turns out the underlying code shares state it shouldn't. Two fixes are required. **Verify:** Add an option to run tests in random order. This tests both the setup and the underlying code. **Learn:** The result goes into the catalogues where the engine looks next time. Both fixes are logged against the pattern, so the second occurrence costs less than the first. **Alert Monitoring Example** Here's another example. Imagine your service is running in production. A support ticket arrives. Diagnose: The engine matches it against the detection-by-customer failure mode: monitoring that follows the architecture while customers follow the journey. It then walks through your telemetry looking for where this journey went dark. Prioritise: The journey that failed carries the traffic and the revenue, placing it at the top of the queue for fixing. Select: The easy fix would have been to add an alert; the fix to improve the overall system is to add better tracing on the critical user journey. Verify: Add a synthetic check that runs the journey and fails when it breaks. This tests both the instrumentation and the alert. Learn: The result goes into the catalogues where the engine looks next time. Both fixes are logged against the pattern, so the second occurrence costs less than the first. This is a system that learns from failure. More antifragile than resilient. ## Catalogues The engine reads from, and writes back to, three catalogues — one for each decision it makes. **The failure-mode catalogue** — every failure named and matched, mined from your own incidents and from the industry's. Give it time and it holds the failures you've never personally hit, so you catch them the first time instead of the second. **The intervention catalogue** — every entry is the fix that resolved a failure mode, and the evidence it held. The engine reaches in and selects the best-fit move from history instead of guessing. **The priority catalogue** — ties failures to the objectives and KPIs they actually threaten, ranking them by severity so the engine knows what to fix first. It stops you spending your best effort on your smallest problem. And all three grow. Every breach makes the catalogues denser, and denser catalogues make the next diagnosis faster and the next fix better. ## Revolution or Evolution? There are tools that do parts of this. They'll tell you how your teams are working, score you against DORA. What I've not seen is a feedback loop that gets stronger from new information. My experience is that until now, this has simply been too expensive to execute. The reading, the cataloguing, the matching, and the inferring from context weren't things the industry was particularly interested in investing in. The cost has been too high, and the return difficult to see. So the post-incident review gets written, filed, and never read again. The catalogue that was meant to grow stays a wiki page nobody's opened in years. Suddenly, this part is now cheap. It's now something a machine does well enough to keep the loop turning. Working the full vein used to be a luxury; now it's accessible. ## Direction of Travel A breach is one way to fire the engine: something got through, and the loop works backwards to find out why. But you can also point it forwards — mine the delivery and operational data for gaps before they surface as incidents. Either way, the failure mode is the pivot — backwards you find it from the map, forwards from the terrain. Once it's named, the intervention catalogue can be applied. The final post in this series runs the engine forwards, inside a company-wide transformation. ## Diamonds are forever The gaps in our controls will never fully close. The terrain keeps moving, and new ones open as fast as you shut the old ones. So don't mind them. Mine them. Stop chasing a perfect map of a terrain that won't hold still. Go to where the dragons are. Download my paper for a fuller version of this analysis. [Mine-the-Gaps-Whitepaper-CharrettMine-the-Gaps-Whitepaper-Charrett.pdf702 KBdownload-circle](https://www.annemariecharrett.com/content/files/2026/07/Mine-the-Gaps-Whitepaper-Charrett.pdf "Download") ### Resilience is dead, long live antifragility URL: https://www.annemariecharrett.com/by/ Last updated: 2026-06-25T07:43:37.000Z It's official. AI is non-deterministic, and it will confidently produce things you never asked for and never wanted. I know, you're shocked 😆. There's some excellent work in play to manage this drift. Angie Jones pointed me to [Sonar's AC/DC — the Agent Centric Development Cycle](https://docs.sonarsource.com/agent-centric-development-cycle?ref=annemariecharrett.com). Artem Yakimenko designed the lovely [Claude watchdog](https://github.com/Temikus/claude-watchdog?ref=annemariecharrett.com), a critical post-mortem that runs on every Claude Code session. But exactly what are your guardrails managing the drift *from* — the map, or the terrain? The word *drift* smuggles in an assumption — that our map of the world was right at the start, and a guardrail's job is to hold the system to it. But here's the thing we all know in software engineering: the map starts changing the moment it hits the terrain, because of what we don't know, but also because the terrain is constantly changing. Technology, requirements and teams change too fast for the decisions we made at the start to stay true. It's probably the one constant we can cling to on any software project. Something is going to change. It's the whole reason agile was invented, the whole reason we ship MVPs — so we can learn and correct as we build. And AI is no different. Our existing guardrails and controls are only those we think of at a given point in time. The biggest silent failure will be the incompleteness of our guardrails. They can't be the whole picture — there's too much complexity to hold in advance, and by the time the system is real, the ground under it has already moved. So a control built to defend the original map is defending something we already know is incomplete. A compliance control answers one question: what do we block? A resilient one adds a second — how do we get back to where we were? Neither asks if "where we were" was right in the first place. The alternative is to design for antifragility — controls that get better because they failed, not despite it. Controls that treat a breach not as damage to repair but as the one signal worth having: the place where the map was wrong. That's a different design brief. A control that learns has to do five things. **1\. Defence in depth** Layer your controls. Why? Because every barrier has holes you can't see in advance. Never trust one to be complete. That's the Swiss cheese model: each layer has holes, and a failure gets through only when they line up. The failure that gets through is the signal — it shows you a hole that was always there, what kind it is, and which layer it's in. That's invaluable information for any AI system: it tells you what failure modes actually exist in yours. Layers for defence in depth — think software testing, observability, monitoring, alerting. **2\. Correct the system, and revise the control** When a control fires, don't just instruct the AI to fix the defect and close the ticket. Use the signal to revise the controls themselves as well. A second loop does root-cause analysis on the control itself — which layer should own this failure — instead of bolting the same fix onto every layer. **3\. Hunt for the failure** The control's job is not "did it pass?" It's "where is it failing?" Think Karl Popper: you never prove a system right, you only find where it's wrong, and the only thing that teaches you is the case that breaks. Train your agents and controls to go looking. Don't wait for a breach to be logged — try to cause one. Red-team it, break it in a sim, run it at the edges. Apollo's simulation team had one job: break the crew on the ground so reality couldn't. A control that only catches what wanders into it is a control still hoping it thought of everything. **4\. Process the signal** A raw signal isn't a decision. Between the breach and the response sits real work that AI is great at: - detect the gap - assess the context - prioritise by impact - Identify the best intervention (it might not be a code fix) **5\. Make failure survivable** You can only hunt for failure and learn from breaches if failure is cheap. Some of that comes from defence in depth — a hole in one layer is a near miss, not a catastrophe. The rest you build deliberately: staged rollouts; a live abort; an expiry on every control so it's revisited before it hardens into dogma. None of this is exotic. It's what you already do when you build software — ship small, watch what breaks, change your mind. The mistake to avoid is stopping the moment we call something a "control," and reverting to the fantasy that this time we thought of everything. We didn't. We never do. So build controls that go looking for where you're wrong, and get stronger every time they find it — because the case that breaks teaches you what conformity never will. --- *Sources:* - *Sonar — AC/DC, the* [*Agent Centric Development Cycle*](https://docs.sonarsource.com/agent-centric-development-cycle?ref=annemariecharrett.com) *(Guide → Generate → Verify → Solve).* - *Artem Yakimenko —* [*claude-watchdog*](https://github.com/Temikus/claude-watchdog?ref=annemariecharrett.com)*, a post-session post-mortem for Claude Code.* - *Map* Theatrvm orbis terrarvm [https://blogs.loc.gov/maps/2020/04/ortelius-a-legendary-mapmaker/](https://blogs.loc.gov/maps/2020/04/ortelius-a-legendary-mapmaker/?ref=annemariecharrett.com) ### Code reviews: what are they good for? URL: https://www.annemariecharrett.com/code-reviews-what-are-they-good-for/ Last updated: 2026-05-26T00:21:29.000Z Pick an urban park with paved paths, and beside it you'll see the path people actually take. Worn in the grass. [It's called the desire path](https://www.forbes.com/sites/lauriewinkless/2024/08/26/desire-lines-the-unofficial-pedestrian-paths-that-shape-the-city/?ref=annemariecharrett.com). First instincts suggest that the planners got it wrong. The worn path is the true path. But is that true? A desire path is the path of least resistance for the people who created it. It's a shortcut for able-bodied people. But it's not the path for someone in a wheelchair or pushing a pram through mud. They need a paved route. Both paths add value. Chesterton's fence reminds us to think about why things exist before we go to replace them. G.K. Chesterton wrote way back in 1912: > There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." ## Code Reviews This feels like an important reminder in a time when we're eagerly codifying all our engineering processes into agents. The one that's getting plenty of attention now is code reviews. The concept of the code review was [introduced at IBM in 1976 to catch bugs](https://en.wikipedia.org/wiki/Fagan%5Finspection?ref=annemariecharrett.com). Michael Fagan's formal inspection was built to find defects early, when they're cheapest to fix. Today's pull request is a lighter, looser descendant of that. The data show that very few bugs are caught this way. Across studies that classified what review actually changes, [roughly three-quarters of the issues are about maintainability and style](https://www.researchgate.net/publication/266657932%5FModern%5Fcode%5Freviews%5Fin%5Fopen-source%5Fprojects%5FWhich%5Fproblems%5Fdo%5Fthey%5Ffix?ref=annemariecharrett.com), not whether the code works. The bugs it catches are mostly the small kind tests already catch. Code reviews come into play for knowledge sharing and to provide a formal method of approval. Microsoft's own study of the practice found that [reviews are less about defects than people expect, and more about knowledge transfer and team awareness](https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/?ref=annemariecharrett.com). My experience is that peer reviews are there as part performance theatre, part sharing knowledge and part coaching of junior engineers. Where you work plays a part here. I've worked inside XP teams using pair programming as their method of review. I've also worked in highly regulated environments where pull requests are a form of compliance. The work a code review actually does is decided by the value placed on it. ## What is the work? This matters because if you or someone in your company is thinking of replacing peer reviews with an agent, it's worth understanding what might get lost if the intended intent, rather than the actual work, is the one that's automated. If peer reviews are doing other hidden work beyond 'quality gate', you're going to need to pull that apart, find out what the actual work is and ways to replace that work. For instance, if the real value of a [quality gate is accountability,](https://www.simplermachines.com/notes-from-o11ycon-2026/?ref=annemariecharrett.com) how will the agent provide it? If it's to coach junior software engineers, will that still be required and what other programs need to be put in place? If it truly is to quality gate, are linters a better option? And if peer reviews are simply performance theatre, are they needed at all? What does accountability look like when agents build, test and deploy? What sort of coaching will juniors need if code is no longer the currency? These are the interesting questions we can be asking ourselves. Before we jump to paving the path around the fence, let's ask what that fence's intent was, what it's really for now, and whether it's doing the work we think it is — or other, hidden work. The kind we only discover once it's gone. ### What the Dashboard won't tell you URL: https://www.annemariecharrett.com/what-the-dashboard-wont-tell-you/ Last updated: 2026-05-21T00:15:50.000Z Someone pushed back on [last week's post](https://www.annemariecharrett.com/stop-measuring-fast-start-measuring-better/). The shift isn't *measure better*, they said. It's *measure confidence*. It's a sharper word for part of what I was getting at. When AI moves PR throughput, the dashboard shows more activity. Leaders can't tell whether the system is healthier or just busier. Confidence names what's missing. But confidence is a visibility problem. It's about what leaders can see. The post was also about something else. What the system has to absorb when more change reaches production. More incidents in absolute terms. Senior engineers pulled into recovery instead of review. Capability that was meant to uplift quietly turning into operational load. Humans carrying more, not less. That's not a visibility problem. It's a load problem. A dashboard can give you confidence. It can't tell you what the system is absorbing while you're looking at it. Confidence is what leaders need from measurement. Better is what the system needs from the work. Both matter. Naming them as the same thing collapses one into the other, and the one that gets lost is usually the one happening to people. ### Stop Measuring Fast. Start Measuring Better URL: https://www.annemariecharrett.com/stop-measuring-fast-start-measuring-better/ Last updated: 2026-05-12T02:19:38.000Z ### Pull requests are quality control Engineering teams often treat pull requests (a popular mechanism for peer review) as a quality-control mechanism. It's where senior judgment gets applied to code before it reaches production; where context gets checked, trade-offs get surfaced, risk gets noticed, and weaker work gets caught before it escapes. When the pull request queue becomes a bottleneck, leadership takes notice because it introduces delays into the delivery process. This bottleneck exists because judgment is scarce. Senior engineers are expensive, and pull requests are one of the places where that scarcity becomes visible. ### AI appears to solve the throughput problem AI is a natural fit for the work around judgment: first-pass review, summarising the diff, pattern matching, test suggestions, boilerplate, and cleanup. So it is not surprising that teams start seeing throughput move. Liz Fong-Jones describes Honeycomb's peak weekday merges moving from roughly 30 to roughly 74 a day, with important caveats: it is a peak weekday figure, it is entangled with other organisational changes, and it does not cleanly separate net new capacity from substitution. That is exactly why it is useful here. It is a concrete example of local throughput changing fast without pretending the causal story is simple. From an engineering point of view, this looks like good news. The PR queue gets shorter. More work gets merged. The bottleneck appears to ease. But it does not disappear. It moves. ### The system is not getting worse. It is destabilising If escape rate stays roughly the same while throughput rises, that does not mean nothing has changed. It means the system is now processing more change at the same rate of defects getting through. More change reaches production. Change is the leading driver of incidents, so more change means more incidents in absolute terms. More people have to pick up the slack. The quality percentage can look stable while the human cost rises. That is not the same as saying AI-assisted PRs are reducing quality. Teams may well be maintaining quality at the point of review. The issue is that the system as a whole is now carrying more production change, and the rest of the chain has to absorb it. Liz Fong-Jones makes a related point: defects don't have to stay escaped for long. With strong observability, the time between a defect reaching production and the team catching it shrinks. That doesn't change the escape rate, but it changes the cost of an escape. It is one of the ways a system can absorb more change without the human cost rising in lockstep. Operational load is one example of where pressure shows up. Incident response is another. The pressure does not vanish. It shows up somewhere else — and whether the system can absorb it depends on what else is in place. Operational load is one example. Incident response is another. The pressure does not vanish. It shows up somewhere else. This is not a story about a bad system becoming worse. It's about a stable system, bottlenecks and all, being destabilised by a new source of local acceleration and then trying to stabilise again. ### What the dashboard misses When PR throughput rises, the obvious reading is that engineering productivity is improving. The more important question is whether the rest of the system is absorbing that throughput cleanly. If the dashboard shows PRs climbing, here is what may also be true: - Escape rate stays flat - More incidents happen in absolute terms - Operational load rises - Rework climbs as downstream problems surface - Senior engineer attention shifts from review to downstream recovery None of this means the AI-assisted PRs are bad. It means throughput is no longer the whole story. That is the trap. Throughput can look healthier while the wider system is carrying more strain. ### Better matters more than faster This is why I think the leadership move is better, not faster. Faster will come anyway. That is what AI does. It reduces the cost of producing change whether we ask for speed or not. The more interesting question is whether it helps people do better. In the PR example, the focus should not be on how to push even more work through the queue. It should be on how to make the PR itself better: clearer, better tested, easier to review, more explicit about risk, and more likely to hold up downstream. If we get better, faster will come with it. If we chase faster first, we may simply destabilise the system harder. ### Capability uplift is what better looks like Most people conceptually agree with building quality in. Split stories well. Make quality shared. Expect software engineers to own at least some of the test automation. The blocker is bandwidth. Systems tend to defend their current equilibrium. Not because it is good, but because it is familiar. The status quo is usually the safer bet, even when it is visibly flawed. Under pressure, that tendency gets stronger. So when we ask engineers to build more quality in, the system does not hear "better." It hears "more." Leadership rarely makes room for that shift. Slow down now so we can speed up later is not a persuasive line in a system already being pushed to ship more. Leadership are reluctant to adopt the concept that removing waste from a system speeds up work because the cost of adoption feels too high. And even if the time existed, testing well is hard. It takes technical skill. It takes product understanding. It takes judgment. It takes holding several mental models in your head at once while still writing code. We are asking a lot. The fair question is whether we are giving people what they need to do it well. My hypothesis is that AI makes "doing better" easier. If agents can provide skills, guardrails, heuristics, and examples at the point of work, then people can produce better PRs, think more clearly about risk, and test more effectively without needing thirty years of quality expertise first. That is capability uplift. Not asking more from a stressed system, but lowering the cost of better practice inside it. Take a staff engineer, principal, tech lead, or quality coach. Someone whose judgment is genuinely load-bearing. Normally, they can only support a small number of teams before context-switching strips the work of depth. AI cuts the cost of context pickup, so their experience can spread further at the same depth. That is the real productivity gain. Senior judgment spreads further. ### What to measure instead If the goal is better, not faster, then these are the questions senior leadership could be asking. Not: how many PRs did we merge this sprint? But: are PRs getting better, or just moving faster? Not: did throughput go up? But: what happened to rework and operational load as throughput went up? Not: is escape rate stable? But: what is the absolute incident load now that more change is landing in production? Not: how fast is review turnaround? But: is good judgment being applied in review, or are we mostly accelerating work through the system? Not: how many engineers do we need? But: are our humans feeling less burnt out, not more? Not: how many teams can this senior person touch? But: can they support more teams at the same depth because context pickup is easier? These are the measures that tell us whether the system is getting better, not just busier. ### Better before faster My hypothesis is that we get the productivity and quality gains when we focus our agents on helping people do better, not merely faster. Faster will come naturally. Better will not. Better requires intent. If we use agents to make PRs better, make testing easier, make context pickup faster, and spread senior expertise further through the system, then the system has a chance to restabilise at a higher level of capability. If we use AI mainly to increase throughput, we should not be surprised when the pressure shows up further down the chain. That is the shift in measurement. Stop measuring fast. Start measuring better. --- **Further reading:** - 2025 DORA Report: State of AI-Assisted Software Development — Google Cloud / DORA - Faros AI: Rework Rate as the 5th DORA Metric — for downstream cost patterns - Liz Fong-Jones' talk at Sydney Tech Leaders, May 2026 — for the 30-to-74 peak weekday merge example and its caveats *Disclaimer: No animals were tested in the writing of this article. Tokens? That's a different matter.* **From last week** Product owners ask questions. Quality professionals provide information on those questions. Somewhere along the way, we split the work into roles. It made sense for managing labour. It makes no sense for delivering customer value. [*The Split We Agreed to Pay For* →](https://www.annemariecharrett.com/quality-was-always-one-job/) ### The Split We Agreed to Pay For URL: https://www.annemariecharrett.com/quality-was-always-one-job/ Last updated: 2026-05-09T02:13:40.000Z When I built the handbook chatbot, my hypothesis was that it would drive book sales. Along with the chatbot, I built tests to make sure it worked. Technical accuracy wasn't enough. The hypothesis failed. Book sales stayed flat. But I learned something. Users weren't asking the book factual questions. They were asking things like: *"a change I pushed for has stalled because nobody sees why it matters anymore. Help me work out what to say next"* So the hypothesis shifted. People weren't looking for what's in the book — they were looking for context-specific advice, the kind that draws on thirty years of work in the quality space. I changed what the chatbot was for. Instead of answering questions about the handbook, it would answer the questions I see my clients asking. But what does good look like for a use case that's non-deterministic and heavily context-dependent? I took the real user interactions and built a set of golden answers against them. The initial responses were too vague — they could have been anyone's. So I added deterministic checks for specific elements of each response. Did it cite a section of the handbook? Did it stay in the voice of the book, or had it slipped into therapy-speak? Did it refuse cleanly when the question fell outside the handbook's scope? I kept iterating until those passed. Holding the hypothesis and the evaluation as one piece of work is what produced the second version. If I'd handed the testing to someone else, they'd have built something that passed. They wouldn't have built something that worked. Only then was it ready for deployment and real customer feedback. The feedback will refine the hypothesis, or kill it. New hypotheses, new evaluations. So the cycle continues. ## The split we agreed to pay for Questions sit at the [heart of quality](https://www.annemariecharrett.com/contemporary-quality-engineering/): who matters, what matters, what's at risk. In discovery, we ask them as hypotheses. In testing, we answer them through evidence. Two sides of the same inquiry. Somewhere along the way, we split them. [Product owners took the hypothesis side — the "right product" question. Quality professionals took the evidence side — the empirical answer.](https://www.annemariecharrett.com/product-excellence-continuous-quality-from-discovery-to-support/) The split made sense for managing labour in complex systems, and companies slice work according to their org structure anyway. It makes no sense in terms of delivering customer value, but it's a cost we've implicitly agreed to pay. David Klahr's SDDS model — Scientific Discovery as Dual Search — describes the cognitive structure underneath all of this. You're searching two spaces at once: a hypothesis space and an experiment space. You form a partial hypothesis, design an experiment, observe the outcome, and update both spaces. A disconfirmed hypothesis doesn't just rule something out — it reshapes what you choose to test next. The two searches interact. Discovery is the interaction. Teresa Torres makes the same argument from the product side. In *Continuous Discovery Habits*, discovery and delivery aren't sequential phases — they run in parallel, continuously, and by the same team. Talking to customers weekly, testing assumptions, mapping the opportunity space. Ongoing, interleaved work. The reason it collapsed into the silo model is that this kind of search is cognitively expensive and organisationally inconvenient. Most orgs have a definition of done and a release date, so the search space closes. The hypothesis becomes an assumption. The test becomes a formality. Quality becomes whatever shipped, and monitoring and alerting catches some of what slipped through. Isolation and decoupling are great testing strategies. Lousy for delivering customer value. ## You can't run it in separate lanes anymore The person forming the hypothesis needs to understand what the evaluation can tell them. The person reading the evidence needs to understand what the user was actually trying to achieve. Split that work and you'll build a system that answers questions correctly and solves nothing. AI gives us tools to manage this complexity that we didn't have before. Evaluation at scale. Synthesising signal from probabilistic outputs. Closing the loop between user intent and system behaviour faster than any human process ever could. The temptation is to hand those tools to the existing roles and call it progress. Product owners get an AI that helps with prioritisation. Quality professionals get an AI that generates test cases. The silo survives, better tooled. Quality remains nobody's whole job — just everybody's half-answer. The opportunity is to treat discovery and testing as what they always were: the same search, conducted together, in pursuit of customer value. AI makes that tractable at scale for the first time. --- *David Klahr, whose work on dual-space search shaped how I think about exploratory testing, passed away on 26 April 2026\. I based training on his Big Trak X2 discovery research.* *Thanks, Maria Kedemo* and *Isabel Evans, for feedback on this article.* ### Everyone owns quality. Nobody knows what that means URL: https://www.annemariecharrett.com/everyone-owns-quality-nobody-knows-what-that-means/ Last updated: 2026-05-05T05:47:18.000Z There's a genuine argument for developers owning quality. When a team is responsible for what it ships — end to end — quality stops being a handoff problem. It gets built in rather than bolted on. Feedback loops tighten. Defects get caught earlier, by the people with the most context to fix them. It's less rework, not more. Most QA headcount reductions just aren't that argument in practice. ## **What is the work?** Before asking who owns quality, it's worth asking whether anyone has agreed on what quality work actually is. Is it writing tests? Reviewing acceptance criteria before dev picks up a ticket? Running exploratory sessions? Tracking defect patterns over time? Flagging when the test environment is unreliable? Someone has to answer that — and the answer has to be shared, not assumed. Most organisations skip this step. They remove the function, point at the developers, and call it ownership. What they've actually done is distribute responsibility without distributing definition. The work isn't transferred. It's orphaned. ## **Do people have capacity to do it?** Even when the work is named, the people now responsible for it already have full jobs. Developers absorb quality work imperfectly and inconsistently — not because they can't do it, but because capability is different from capacity, and both are different from the habits and systems that make quality reliable at scale. Quality work done in the gaps looks different from quality work done with focus. That gap doesn't show up in the sprint. It shows up in production. ## **The delayed bill** Defects found in production cost significantly more to fix than defects found during development. The exact multiplier varies, but the direction doesn't. Catching something before it ships is cheap. Catching it after isn't. A headcount reduction in QA is a bet that the redistribution will work — that developers will absorb the work at sufficient depth, consistently, without specialist support. More often than not, it becomes a risk transfer: from this quarter's budget to future engineering time, customer trust, and incident response. By the time the bill arrives, the causal chain is hard to see. The reduction looks like it worked. ## **Two questions before you decide** Should developers own quality? Yes — and the organisations that make it work are worth learning from. But has anyone named what the work actually is? And does the person now carrying it have the time and tools to do it? If not, the work hasn't moved. It's just no longer visible enough to manage. ### Contract Testing Isn't the Hard Part URL: https://www.annemariecharrett.com/contract-testing-isnt-the-hard-part/ Last updated: 2026-05-05T05:47:38.000Z ## Where Do We Start? Most teams aren't avoiding contract testing because they think it's of little value. They're not starting because starting takes time that offers little or no reward. Features ship. Testing infrastructure doesn't show up in a sprint review. So contract testing stays on the backlog. Never quite making it into planning. The backlog wallflower. How can quality coaching help overcome that inertia? ## A Quality Coach in your repo Recently, I ran an experiment. I built a test strategy [**skill**](https://claude.com/blog/how-to-create-skills-key-steps-limitations-and-examples?ref=annemariecharrett.com) based on my approach to risk, failure modes, and where testing matters. A skill in machine learning is a reusable set of instructions that encodes how to reason through a specific problem; think of it as a playbook you write once and run repeatedly. I ran it against two repositories I'd never seen. Teams I didn't know. Domain knowledge based on what existed in the repositories. What came back wasn't "consider contract testing" or "integration testing would help here." It was specific: start with this contract, in this part of the system, because this is where business risk and technical failure modes concentrate. Not a recommendation. A starting point. That alone would have been useful. But the output also surfaced integration failures the teams didn't have visibility on — not just prioritising known work, but pulling unknown risk into the light. Two problems solved from a codebase I'd never read. ## The skill draws the path There's a concept I've written about before — the [elephant and the rider](https://www.annemariecharrett.com/coaching-upwards/). The rider knows the right direction. The elephant won't move without a clear path. Teams stuck on where to start aren't short of knowledge — they're short of a path. The skill draws the path. Once that happens, the coaching conversation changes. You're no longer the person who spends weeks reading the code, building a mental model, and earning the right to say "*start here*." What you're doing now is helping the team understand the output, build confidence in the methodology, and act on it. The skill works because it encodes a specific way of reasoning about risk — weighing business impact against technical failure mode, before making a recommendation. Generic prompts get generic answers. Encoded methodology gets specific ones. What the skill can't do is what comes after. Getting a team started is one thing. What happens at six months — when the system has changed, the team has turned over, and nobody remembers why they started with that contract — is a different coaching conversation. That's where continuous feedback, adaptation, and auditing against measurable outcomes come in. --- Ask yourself. What's stopping your teams from starting a quality improvement? Is it time? Is it know-how? Is it confidence? That gap might now be encodable. The question is whether you've made your methodology explicit enough to encode it. Most of us haven't. Not fully. ### QC newsletter 41: I've been writing. Just not sending URL: https://www.annemariecharrett.com/newsletter/qc-newsletter-41-ive-been-writing-just-not-sending/ Last updated: 2026-04-07T07:39:32.000Z Who's with me in trying to stay sane out there? I've been bouncing between embracing what life has to offer and the very strong temptation to hide under the duvet and pretend the world isn't happening. It's one reason why these newsletters have been sparse. But I have been writing. Just not sending. This issue is a catch-up — a batch of things I've been working on and thinking about since we last spoke. Be kind to yourself. Anne-Marie --- ## 📘 Ask the Handbook I built the Quality Coach Researcher thinking people would use it as a standalone tool — ask a coaching question, get an answer grounded in the Handbook. Useful, right? Turns out I had the framing wrong. By analysing the usage, it turns out the people who got the most out of it weren't using it instead of the book. They were exploring a specific topic, seeing how deep the material went, and then making a purchase. It's a discovery tool, not a replacement. So I've repositioned it. It now lives on the book page as **Ask the Handbook** — ask a question, get an answer in real time before you commit. Free, no sign-up. You can also switch roles — engineering manager, test lead, delivery lead — so answers are framed for your context, not just a generic quality coach. [\[Try "Ask the Handbook" →\]](https://annemariecharrett.com/tag/book?ref=annemariecharrett.com) --- ## Quality Coach's Handbook **My Genie Got It Wrong: Evaluating LLMs for a RAG Chatbot** When I built the Quality Coach Researcher, I assumed picking the right LLM would be straightforward. It wasn't. I ran 100 iterations comparing Llama 70B, 405B, and GPT-4, and the AI agent's own recommendation turned out to be wrong. This post is about what I learned and how I'd approach it differently. [\[Read the post →\]](https://www.annemariecharrett.com/my-genie-got-it-wrong-evaluating-llms-for-a-rag-chatbot/) --- ## 🛣️ Tech Leadership A distinctly human perspective on tech leadership. **Staying Sane in a Post Modern Tech World** 2025 was genuinely a great year for me professionally — conferences, workshops, good work. And yet there's something disorienting about the pace of change in tech right now that I keep coming back to. [\[Read the post →\]](https://www.annemariecharrett.com/staying-sane-in-a-post-modern-tech-world/) **Not Technical Enough: Really?** I've had a shadow following me my entire career. Her name is "not technical enough." This post is a celebration of looking her in the face. [\[Read the post →\]](https://www.annemariecharrett.com/not-technical-enough-really/) --- ## 🌱 Around the Grounds Having done my own evals, I find that what Katja Obring writes in this article makes a lot of sense. [The oracle has opinions - Kato CoachingThis is part of a series where I write about what I’m learning in an AI evals and analytics course. Earlier posts cover the basics of evals, sniff tests, and quantitative evaluation with LLM-as-a-judge. In traditional testing, the oracle is trustworthy. You know what the right answer is, or at least you know who decides. \[…\]![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-kato-coaching-dynamic-1-270x270-1.webp)Kato CoachingKatja Obring![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/llm-judge-needs-evaluation.png)](https://kato-coaching.com/the-oracle-has-opinions/?ref=annemariecharrett.com) Lisa Crispin is offering a free on-demand course on measuring quality improvement. [Continuous quality improvement supported by metrics - Holistic Testing with Lisa CrispinFree online, on demand course to learn ways to set quality goals, design small experiments to work towards them, measure progress effectively![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-donkey-144-270x270.gif)Holistic Testing with Lisa CrispinLisa Crispin![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Quiccheck.png)](https://lisacrispin.com/2026/03/26/continuous-quality-improvement-supported-by-metrics-course/?ref=annemariecharrett.com) Supply chain attacks on npm packages and LiteLLM made dependency hygiene feel urgent. Marit van Dijk's post is a practical response — using IntelliJ IDEA to find out not just which dependencies are vulnerable, but whether your code is actually hitting the vulnerable API. [Read the post -> ](https://maritvandijk.com/vulnerable-api-usage/?utm%5Fsource=rss&utm%5Fmedium=rss&utm%5Fcampaign=vulnerable-api-usage) Royalee Martin, Veronika Pliusnina and Alessandra Moreira have joined forces on the engineering quality podcast. Worth checking out this podcast for its diverse content. Fiona Charles and I were guests on the topic of Quality Coaching. --- ## 📅 Upcoming **Testing Talks Sydney — 6 August 2026** I'll be at Testing Talks again this year. If you're in Sydney, come say hello. [\[Event details →\]](https://testingtalks.com.au/?ref=annemariecharrett.com) --- **Happy reading,** Anne-Marie Sign up for the Quality Coach newsletter — monthly updates in your inbox, plus additional tokens for Ask the Book, the interactive Quality Coach's Handbook chatbot. [Signup to newsletter ](#/portal/signup) ### Not technical enough: Really? URL: https://www.annemariecharrett.com/not-technical-enough-really/ Last updated: 2026-04-08T22:21:48.000Z Meet my shadow. Her name is "Not technical enough" and she's been walking beside me for all of my working career. It doesn't matter that I studied engineering at university It doesn't matter that I learnt to program in my first role It doesn't matter that I can comfortably analyse systems and identify failure modes It doesn't matter that..., well you get the picture. My shadow is partly created by my own insecurities, but also by where the sun sits on the horizon. When the sun is low, my shadow is long. The sun tells me: "We want someone really technical for this role" "You only got that promotion because you're a woman" "You're not one of us unless you code" *"Not One of us, Not one of us, Not one of us" they chant.* My shadow gets longer and darker. Today, I change the message. Today, you are one of me. My shadow has a new name, it's "Irreducible" and she's there to remind me to view myself by what I am, rather than what I'm not. To code or not to code is NOT the question; How you show up is. Have a question about quality coaching? Ask the handbook [Ask the Handbook](#) ### Staying Sane in a Post Modern Tech world URL: https://www.annemariecharrett.com/staying-sane-in-a-post-modern-tech-world/ Last updated: 2026-01-12T00:17:51.000Z Before I start, I want to be clear. 2025 was an awesome year. I got to attend some incredible conferences such as Yow!, Agile Testing Days, Testing Talks. Plus, I got to attend a Kent Beck workshop kindly hosted by my work. I co-led a tutorial with Fiona Charles on expecting to lead quality which was freakin awesome! I plunged into the world of AI and agents, and discovered liberation in what I had first treated with suspicion. And I published a book. One of my most proud achievements. 2025 was an awesome year. It was also a demanding year. As many before me know, you don't get a free pass writing a book and working full-time. The effort will impact you. It takes something out of you. And it takes a while for that something to fill up again. In addition, the organisation I work for is undergoing significant change. Change is great if you are the one delivering it, not so much fun if you're on the receiving end. I experienced both. Like many of us, I find the reality of AI in our lives deeply unsettling. The fun of playing with a shiny, exciting toy contrasts with the consequences it will have for our industry and our lives. Add extensive international travel, and it's an understatement that I ended the year fatigued. Fortunately, I've had the opportunity to take a long break, which has been a real blessing. I have done little for weeks other than reading trashy novels and swimming in the ocean. The clincher? I didn't worry about anything. I didn't worry because I realised I really needed this time. I didn't care whether I was social (well, I did a little) or whether the house was messy (it was). I didn't analyse my day or my relationships, and I didn't think about work. This state of 'just doing' has been soul-nourishing. I believe that we are witnessing the birth of a new paradigm within software engineering. New paradigms emerge when old models cease to function, and right now, there's a whole bunch of us scratching our heads, wondering how the hell we got here1. Burnout is the new epidemic, and quiet quitting has entered our dictionaries. Job losses are on the rise, and many people are lying low, hoping that somehow things will turn around. AI has entered the workforce, creating instability and uncertainty for the future of software engineering. Of course, software engineering doesn't live in a bubble, and we are currently experiencing change at a societal level that exacerbates our anxiety and stress. Climate change, new world orders, security threats, and the renewed emphasis on 'the other' make us question how tomorrow will play out. I find it hard not to think about how my local beach may or may not exist when I go down for a swim. When things "feel" chaotic and out of control, our anxiety rises. Simple decisions start becoming difficult. The overwhelm is real. In 2010, the philosopher Byung-Chul Han wrote a book titled [The Burnout Society](https://www.amazon.com.au/Burnout-Society-Byung-Chul-Han/dp/0804795096?ref=annemariecharrett.com)2, which hypothesises that we no longer live in a disciplinary society in which command-and-control is the order of the day. Instead, we live in an achievement-oriented one. We require that our work be meaningful and internally motivated rather than being told what to do. We achieve our goals. We are also responsible for any failure. But logically this can't be true. We work within systems where chaos is often imposed on us, without regard for the achievements that seem so vital to the system's outcomes. Just as the "crying Indian"3 campaign was used to promote litter consciousness while giving waste-polluting companies a free pass on accountability, we in software engineering have somehow become accountable for outcomes we can't possibly achieve without real agency. Achievement-oriented subjects who work in a chaotic system will never meet our internal expectations. Consequently, we attribute the failure to ourselves. We believe we're not resilient enough. We think we haven't established the psychological safety teams needed to achieve outcomes. We blame ourselves for indecisiveness and/or disorganisation when, in reality, it's impossible to sustain change amid chaos. What if the best we can do in these situations is nothing? Rabbits confronted with headlights often stand stock-still. Humans read this behaviour as fragile and stupid. But is that true? What if, in the face of extreme obstacles, rabbits know the best chance of survival is to do nothing and wait for the danger to pass? At work, what would this 'do nothing' look like? Doing nothing is not failing to turn up. It's not quiet quitting. It's not giving up because everything is impossible and too hard. By doing nothing, I mean doing our work without ascribing value or meaning to it. Doing nothing means fulfilling your contractual obligations, nothing more, nothing less. It means ignoring outcomes that are impossible to achieve. Not because people are incapable, but because the system is so stacked up that it is impossible to intentionally achieve them. The good news is that this now means you don't need to be a rock star; you don't need to be overinvested in improving your organisation. You are simply invested in performing your contractual tasks. You see the hyperbole for what it is and focus on the task at hand. Working in the moment, attending to the task at hand, and letting go of the inner voice that critiques is hard work. Intentionally, 'doing nothing' is hard work. It requires catching yourself in the moment and mentally walking away from the chatter. For me, that requires meditation, taking proper breaks, not eating at my desk, and not working past certain hours. It's about consciously adding 'trivial' tasks to my day, such as hanging out my washing, taking a midday nap, and going for a walk for its own sake. It's about doing some weeding in the garden, or reading a trashy novel. Motivation is irrelevant here. What's important is balance. A useful frame here is the idea of a 'full tank' - that we have activities that stress our bodies and others that relax them. Surprisingly, coding - even when you're in the zone - is a stressor. So is going to the gym, regardless of the dopamine hit. Knowing which activities deplete and which replenish can help you find balance. If you're interested in this, check out [Tank](https://www.thisisyourtank.com/?ref=annemariecharrett.com)4. Burnout is your body telling you to wake up and change something. Don't ignore this opportunity to tweak your life and your perspective. Because in doing nothing, we are in fact doing something. It took me around 2 days to research and write this article. If it saved you time or gave you something to think about, tips are appreciated 😁 [Tipping Jar ](#/portal/support) **References & Further Reading** **1** **Articles on broken systems** [My Ambition Didn’t Die. The System Made the Status Quo Unlivable.Burnout, resilience scams, and the capitalist patriarchal system women are opting out of.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F1b47155c-b605-4e9c-a512-48eec7af773e-2Fapple-touch-icon-180x180.png)The Truth Bomb Times with Michelle RedfernMichelle Redfern![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2Ff1f585e5-d0f0-4015-aa6d-f509250f724a_752x453.png)](https://michelleredferndotcom.substack.com/p/my-ambition-didnt-die-the-system) An article I recently wrote on systems and working inside them: [There are no bad testers only bad systemsAvoid labelling people as good or bad testers, focus on how to improve the system![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-30.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1617036544881-b5416ccf84fe-1)](https://www.annemariecharrett.com/there-are-no-bad-testers-only-bad-systems/) 2 I found this book hard to read. [This article](https://psyche.co/ideas/the-achievement-society-is-burning-us-out-we-need-more-play?ref=annemariecharrett.com) is far more digestible. 3Keep America Beautiful was founded by packaging corporations (Coca-Cola, American Can Company, etc.) in 1953\. The 1971 "Crying Indian" ad shifted blame for pollution from industry to individuals - "People start pollution. People can stop it." The actor wasn't even Native American. The campaign successfully deflected attention from corporate responsibility onto consumer guilt for decades. 4[Tank](https://www.thisisyourtank.com/?ref=annemariecharrett.com) is a framework and tool that helps you understand which activities stress your body and which restore it. I've found it useful for avoiding burnout. ### My Genie Got It Wrong: Evaluating LLMs for a RAG Chatbot URL: https://www.annemariecharrett.com/my-genie-got-it-wrong-evaluating-llms-for-a-rag-chatbot/ Last updated: 2026-04-13T07:42:01.000Z ## Not all LLMs are alike I recently attended the **Yow! Conference**, where a couple of talks on the Sustainability and Security of LLMs stood out to me. The first was a talk by [Charles Humble](https://yowcon.com/melbourne-2025/sessions/3627/green-ai-making-machine-learning-environmentally-sustainable?ref=annemariecharrett.com) titled Green AI: Making Machine Learning Environmentally Sustainable. The second by [Katharine Jarmul](https://yowcon.com/melbourne-2025/sessions/3648/hacking-ai-systems-how-to-still-trick-artificial-intelligence?ref=annemariecharrett.com) on Hacking AI Systems: How to (Still) Trick Artificial Intelligence Both speakers discussed the concept of *"Using the right model for the job."* From a sustainability perspective, right-sizing the LLM reduces energy consumption. One speaker suggested using open source models where possible. For security reasons, using an [over-parametrised LLM](https://datasciencedojo.com/blog/overparameterization-in-llms/?ref=annemariecharrett.com) can expose your model to abuse. ## Quality Coach Research Tool I've created a [research tool ](https://www.annemariecharrett.com/)that lets you explore the [Quality Coach's Handbook](https://www.annemariecharrett.com/tag/book/) based on your specific role and questions. Using machine learning, it provides tailored summaries and points you to relevant chapters for deeper reading. It's like having a personalised guide through the handbook that adapts to whether you're a test lead, engineering manager, or quality coach. With greater awareness from the talks, I realised I need to be more particular about the model I used. Sustainability, security, and content accuracy are high priorities for me. I decided to evaluate the models against these criteria. Turns out there's a name for this type of testing. It's called [evals](https://platform.openai.com/docs/guides/evals?ref=annemariecharrett.com). ## Eval Criteria Accuracy of response also matters. This is my book. There is no way I'm going to allow a chatbot authoritatively make up content in my name. The criteria for the evaluation were: 1. **Reasoning Ability**: Can it respond effectively depending on the persona (CEO vs. Test Lead)? 2. **Energy Efficiency**: Can we minimise the carbon cost without sacrificing quality? 3. **Open Source**: Can we move away from proprietary providers to use open-source? ## Potential Models I used GPT-4 as the baseline, since that is what I used in my MVP. The two models I decided to evaluate against **GPT-4** were **Llama 3.1 70B** and **Llama 3.1 405B**. In particular, I wanted to test the 405b model because the genie (Kent Beck's term for an agent) highly recommended it as the preferred reasoning model. It confidently explained that smaller models would fail the accuracy test. This recommendation immediately made me suspicious. ## Engineers solve problems Running this experiment manually means juggling API specs across providers, building a test harness with proper rate limiting, and wrangling the output into a visual format. It's not complex work, but it's time I'd rather spend on experiment design and analysis. So I delegated. I designed the experiment1, then treated the genie as my programmer. - My prompt: "I want to run a reliability test comparing Llama 70B and 405B. I want to measure quality, latency, and energy. Use GPT-4 as the baseline." - The Genie: 1. Refactored the backend to support hot-swapping models. 2. Wrote a script to execute 100 iterations per model. 3. Implemented a "Judge" pattern where GPT-4 scored the open-source models on a 1-5 scale for "Relevance" and "Voice." I was then able to quickly run some tests. The results shocked the genie (I was less surprised 😎). ## **E**val Results It turns out that the 70B model significantly outperformed the 405B model. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/12/image.png) - **The 405B Model**: The model provided quality, but failed on viability. It was too heavy. It caused timeouts and latency spikes, and it required massive computational resources, making it unsustainable. - **The 70B Model**: It was the clear winner. - **Quality**: It scored **4.8/5** on relevance (matching GPT-4). - **Persona**: It nailed the distinct voices (Strategic CEO vs. Tactical Coach). - **Sustainability**: It ran **6x faster** and used a fraction of the energy. For my specific context, the 405B model was overkill. The 70B model was the "Toyota Prius"—reliable, efficient, and more than capable. ## Increased Optionality My real takeaway, though, wasn't about choosing the best model for the job. It wasn't that you shouldn't trust your genie (I already knew that); it was that these tools enabled choice. The genie allows me to test, not guess. I moved from assumption to evidence in hours, not days. That speed creates options. When 405B failed, I could pivot to 70B immediately - an open-source model that uses less energy and is equally reliable. ## 1Model Comparison Experiment ### Objective Compare the reliability, quality, and efficiency of three LLM models for the Quality Coach Handbook chatbot. ### Test Configuration **Question Asked:** "How do we shift from a testing-focused culture to a whole-team quality culture?" **Persona Used:** Executive — expecting strategic, high-level responses appropriate for executive stakeholders **Iterations:** 100 per model ### **Models Tested:** 1. Meta-Llama-3.1-70B-Instruct-Turbo 2. Meta-Llama-3.1-405B-Instruct-Turbo 3. GPT-4 (gpt-4-1106-preview) ### Steps Per Iteration 1. **Retrieve Context** — Query the vector store for the top 3 most relevant book chunks 2. **Build Prompt** — Construct a persona-aware system prompt with the retrieved context 3. **Call LLM** — Send the question to the model being tested (temperature 0.7) 4. **Judge Response** — GPT-4 evaluates the response on 3 criteria (0-5 each): - **Relevance**: Does it directly answer the question? - **Persona Voice**: Is the tone appropriate for a CEO/Executive? - **Grounding**: Does it cite sources from the handbook? 5. **Record Metrics** — Log latency, response length, quality scores, and errors to CSV ### Quality Coach newsletter #39 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-39/ Last updated: 2025-12-20T20:48:28.000Z **📱 Quality Coach Researcher Launch** The [Quality Coach Researcher ](https://www.annemariecharrett.com/introducing-the-quality-coach-researcher/)is like having your quality coaching expert on tap. The research is a chatbot that provides tailored advice from the quality coach's handbook based on your role. Ask it a question, and depending on your role, it will provide contextual advice. The quality coach researcher is now accessible to everyone. **Free Access**: Try it out with 5 queries, no signup required. Perfect for exploring what the researcher offers. **Free Members**: Get 10 queries per month. Sign up to keep the conversation going. **Paid Subscribers**: Unlimited queries plus continued first access to continued content. Try it out at [annemariecharrett.com](https://www.annemariecharrett.com/) you will see the rotating icon on the bottom right-hand side with "Ask the Book" ### Recent Articles Some recently published posts that I haven't got round to sharing! [Introducing the Quality Coach ResearcherI wrote The Quality Coach’s Handbook as a practical guide, something you can pick up for an answer when a question at work arises. Now I wonder if a chatbot could supplement the book by quickly locating relevant content? I decided to build the Quality Coach Researcher, an augmented service![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-25.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1481627834876-b7833e8f5570)](https://www.annemariecharrett.com/introducing-the-quality-coach-researcher/) [There are no bad testers only bad systemsAvoid labelling people as good or bad testers, focus on how to improve the system![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-28.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1617036544881-b5416ccf84fe)](https://www.annemariecharrett.com/there-are-no-bad-testers-only-bad-systems/) And for premium members [Have Your Slice and Eat It: Boost Quality with Vertical Story SlicingHow product features are sliced into smaller work items has a big impact on quality. Slice your epics well, and quality will follow.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-26.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1464349095431-e9a21285b5f3)](https://www.annemariecharrett.com/have-your-slice-and-eat-it-boost-quality-with-vertical-story-slicing/) [Why Software Teams Need Speed LimitsReducing the speed limit before a known bottleneck allows traffic to flow smoothly. While we feel we’re going slower, we actually get to our destination faster. The same principles apply in software engineering.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-27.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1736133255490-e09b695588ee-1)](https://www.annemariecharrett.com/why-software-teams-need-speed-limits/) **🌱 Around the Grounds** I'm behind in my reading, but I liked this from Nicola Lindgren and found myself nodding as I read it. [Is It the Relationship or the Idea that’s the Problem?I share some mental models I have on relationships, ideas and how I think people view others. These can be useful when introducing new ideas.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/nicolalindgren.PNG)![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/diagram1.png)](https://nicolalindgren.com/is-it-the-relationship-or-the-idea-thats-the-problem/?ref=annemariecharrett.com) Lisa Crispin and Janet Gregory have launched a new book! [Holistic Testing: Weave Quality into Your Product: 9781999220570: Computer Science Books @ Amazon.comHolistic Testing: Weave Quality into Your Product: 9781999220570: Computer Science Books @ Amazon.com![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-12.ico)Shop the Store on Amazon ›Follow![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/ATVPDKIKX0DER-141-8455415-7076754-95Y0DTHQF8HHGFH0D70K-uedata-s--2Frd-2Fuedata-3Fstaticb-26id-3D95Y0DTHQF8HHGFH0D70K-0)](https://www.amazon.com/Holistic-Testing-Weave-Quality-Product/dp/1999220579?ref=annemariecharrett.com) Who's with me in loving Katya Obrings work. She has a new course launched. [Become the tester people listen to: introducing Stakeholder Ready - Kato CoachingIf you work in testing or quality engineering, you know the feeling.You see risks early. You spot patterns before anyone else. You raise concerns because you care about what happens next.And yet the conversation stalls. People nod politely, then move on. It is frustrating. Not because you want attention, but because you want to make \[…\]![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-kato-coaching-dynamic-1-270x270.webp)Kato CoachingKatja Obring![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Stakeholder-ready-title-slide.png)](https://kato-coaching.com/become-the-tester-people-listen-to-introducing-stakeholder-ready/?ref=annemariecharrett.com) Parveen Khan and Suman Bala launched [Quality Unfiltered](https://podcasts.apple.com/au/podcast/quality-unfiltered/id1850841254?ref=annemariecharrett.com), and this podcast episode was on leading quality when you're not embedded in a team. Something I'm very familiar with! **📚 From the Vaults** Two older posts worth revisiting: [Emergent Quality](https://www.annemariecharrett.com/emergent-quality/) from 2018 explores my hypothesis that quality is an emergent property of complex systems. We manipulate quality by manipulating the parts: people, processes, infrastructure, product, and outcomes. We can't truly know quality—it's constantly morphing—but we can create spaces where quality naturally emerges. [Look for the Helpers](https://www.annemariecharrett.com/look-for-the-helpers/) from 2020 reminds us to focus on those who build rather than those who tear down. "By focusing on those who move forward who work to build and to help, there is a path forward. We build the path together, not ignoring our differences, but respecting them and seeing how they can complement each other." **✈️ Reflecting on 2025** What a year. Launching my book on [Leanpub](https://leanpub.com/qc?ref=annemariecharrett.com) in multiple languages and on [Amazon](https://www.amazon.com/dp/B0FGY1G62R?ref=annemariecharrett.com), as well as creating the [online course](https://leanpub.com/c/quality-coach?ref=annemariecharrett.com), has to be the highlight of my year! Agile Testing Days in Potsdam—running "Expected to Lead Quality" with Fiona Charles, and the workshop on Moving at the Speed of Trust felt like coming home. Testing Talks Melbourne had such great energy, and YOW showed me how much our quality conversations overlap with the broader engineering world. Next year? Test Automation Days. Looking forward to new conversations there. **Happy reading!** Anne-Marie ### Introducing the Quality Coach Researcher URL: https://www.annemariecharrett.com/introducing-the-quality-coach-researcher/ Last updated: 2025-12-20T07:48:40.000Z I wrote [*The Quality Coach's Handbook*](https://leanpub.com/qc?ref=annemariecharrett.com) as a practical guide, something you can pick up for an answer when a question at work arises. Now I wonder if a chatbot could supplement the book by quickly locating relevant content? I decided to build the Quality Coach Researcher, an augmented service trained on the book. Besides having a ton of fun doing this, it taught me a lot about models, UX and programming. ## Quality Coach Researcher You can ask questions like: - "What is a quality coach?" - "What's the best approach for coaching a senior engineer?" - "How do I handle pushback from stakeholders?" It'll summarise relevant passages from the book and cite its sources. It assumes you are a quality coach, but this book has always been intended as a resource for others within an organisation, for example, test leads, software engineers, engineering managers, VPs of Engineering and delivery leads. You can adjust your persona to elicit a slightly different response. If it can't find the response in the book, it will let you know. It promised me it would do that!!! 🤞🤔 ### How to use the Quality Coach Researcher Go to my [website](https://www.annemariecharrett.com/) and look for the rotating chat icon in the bottom-right corner. Click and ask away. Guest usage is limited, free member access is less limited, while premium subscriber is unlimited ### Free during beta Available to everyone during a beta period. What I will do after beta depends on the feedback I get. So let's see! ### Feedback welcome This is early days — if something doesn't work right or you have ideas, let me know. The chatbot has an opportunity for you to provide feedback on the quality of the idea or to provide suggestions. Your input helps me improve it. And of course, I left a ton of bugs in there for you to find – bring it on! 🐞 ### **How the Quality Coach Researcher Works** The Researcher uses AI to help you navigate the Handbook. When you ask a question, it searches the book for relevant content, then sends your question and those excerpts to Together.ai's Llama 3.1 model. The AI generates an answer grounded in what's actually in the Handbook—no making things up. Your conversation history is saved so we can pick up where we left off and keep improving the tool. ### **A few words on privacy** I've built this with privacy front of mind. Your conversations aren't used to train AI models; all data is encrypted, and we use rate limiting to prevent abuse. I chose Together.ai because they use transparent open-source models and don't train on customer data. For technical details on data handling and your rights, see our [Privacy & AI Usage page.](https://www.annemariecharrett.com/quality-coach-researcher/) I hope you have as much fun using it as I did building it. — Anne-Marie *20th December 2025 - Updated to reflect usage enhancements* ### The girl in the purple jeans URL: https://www.annemariecharrett.com/the-girl-in-the-purple-jeans/ Last updated: 2025-11-15T20:57:55.000Z The girl in the purple jeans plucks at her embroidered threads. The sun shines on her face, blessing her. She plucks a flower and twirls it between her fingers. How can she know that in that moment, she’s to become a symbol of a time when no fear exists, only hope She doesn’t know the force that she’ll become As she twirls her dandelion between her fingers ### Have Your Slice and Eat It: Boost Quality with Vertical Story Slicing URL: https://www.annemariecharrett.com/have-your-slice-and-eat-it-boost-quality-with-vertical-story-slicing/ Last updated: 2026-04-13T07:42:36.000Z Using software testing as the only approach to building a quality product is possible, but it's a costly, time-consuming way to deliver quality. Instead, think about [quality as an emergent property](https://www.annemariecharrett.com/emergent-quality/). Many factors affect product quality. One of these is how we slice our epics and stories. I reckon even Goldilocks would have a hard time slicing stories. It is not easy to slice them so they come out 'just right'. Just-right stories are small, testable pieces of work that deliver customer value. Well-written stories will closely mimic the [INVEST principles](https://xp123.com/invest-in-good-stories-and-smart-tasks/?ref=annemariecharrett.com). INVEST stands for Independent, Nominal, Valuable, Estimatable, Small, and Testable. But unfortunately, stories written this well are atypical. Instead, stories appear vague, obscure, large, dependent and hard to test. One of the main antipatterns I see is stories that focus on the work at hand rather than the customer. Stories become "as a backend engineer, I will develop an api so that I can connect to the front end". Here, the story is sliced horizontally by architecture rather than by business value. Slicing a story in this way requires less cognitive load and avoids the need to predict what customer value might look like. It also means work can be allocated independently with less need for communication and collaboration. But it's this lack of collaboration and alignment that manifests as poor quality. Working independently can seem efficient, but it comes with risk and cost to quality. Without explicitly defining customer value through testable acceptance criteria, team members lean to testing output instead of the outcome. For example, "As a producer, I have an api that others may consume" results in testing that the API is exposed with the right fields and will most likely test for that. Customer value is implied as something to be discovered at integration rather than made explicit from day one. Without realising it, team members make implicit assumptions about the nature of customer value. There's no real need to clarify if their assumpion is correct. The end result is it's only during user-focused software testing that teams discover if these assumptions are correct. I remember working with a software engineer who spent two weeks carefully crafting a backend API, only to discover right before deployment that the feature had been deprecated. Slicing stories vertically requires that conversation on customer value to be up front with the whole team. Value becomes formalised. [Example Mapping](https://www.annemariecharrett.com/example-mapping-workshop-for-quality-coaches/) makes it even more explicit. Another antipattern I see is the presence of unknown dependencies. This one is a killer when you work in large, complex, multi-system environments. Without understanding dependencies up front, teams lean on integration test environments to debug their assumptions. Given that most integration test environments are overutilised, this extra load puts immense strain on the overall system. Bottlenecks either emerge or become larger. Testing extends into large brittle phases, and behaviour shifts to firefighting mode. Estimation and predictability go out the window; uncertainty and micromanagement creep in, with senior management scratching their heads and muttering, “How the hell did we get here?” Given the obvious benefits, why don’t we slice stories vertically? My theory is that doing so is difficult. It requires making the unknown explicit when lot of uncertainty still exists, and that’s not easy. Slicing stories well is a skill; It hard to know exactly where to slice the story and what the customer value should be measured in. It sometimes requires us to make a best guess and, faced with new information, to commit to rewriting the stories. Not every organisation affords this trust. It also requires increased collaboration and communication. When we commit to small slices of customer value, all team members work on the same story. That means the back-end, front-end, designers, and quality engineers work in parallel which requires preplanning and knowledge. Schemas must be defined in YAML files. As new information emerges, change is required and realignment becomes necessary. This requires constant communication through pairing across role types and frequent shoulder checks. It might require working in the same repo, making the work more transparent. It's a different way of working, one that may require behavioural change. One that not every team or company is comfortable with. But if they do, the benefits are priceless. As quality coaches, how can we help teams slice stories this way? My approach is to make story splitting as easy and as frictionless as possible. I’m experimenting with AI to help create user stories. I'm exploring ways to offer feedback in safe environments through retrospectives. I’ve developed a training tool called the [Epic Slicer](https://slicer.fly.dev/?ref=annemariecharrett.com) to help teams learn how to slice stories by customer value. The Epic Slicer has predefined epics for slicing. Based loosely on the [Shu, Ha, Ri ](https://www.annemariecharrett.com/habits-and-shu-ha-ri/)concept, it invites users to explore what well-written stories look like. It then encourages users to practice slicing the epic into stories with well-written acceptance criteria. The tool offers feedback on these stories based on the INVEST principles. The tool is free to use and available to anyone who wants to coach teams on vertical story slicing. Let me know how you go! ## Recommended Reading on Slicing [Estimation Sucks. Let’s fix it.The problem with estimation is that everyone is trying to get better at being right. Let’s instead get better at being wrong.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F8590421c-a8f1-4fae-a055-9af940aafeb2-2Fapple-touch-icon-180x180.png)Tom Ridge | Showing my workTom Ridge![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F29f15aa4-1ef4-49bb-be55-7470d50bc03c_1080x1350.png)](https://tomjridge.substack.com/p/estimation-sucks-lets-fix-it) ### There are no bad testers only bad systems URL: https://www.annemariecharrett.com/there-are-no-bad-testers-only-bad-systems/ Last updated: 2026-04-22T08:28:58.000Z The unfortunate and perhaps unintended consequence of describing good testers is that it implies that there exists a bunch of 'bad' testers out there. Like "pass/fail " is to a test, this classification is unhelpful and sometimes harmful. [Quality is an emergent property of a system](https://www.annemariecharrett.com/emergent-quality/), which we typically call a company. Quality relies on[ processes, technology and people](https://www.annemariecharrett.com/contemporary-quality-engineering/) who work within this system. How we collaborate matters, as does how we slice stories. How much time is allocated and how much budget is invested in testing also impacts quality. Quality professionals work within a system that often rewards behaviours that detrimentally impact quality. Rewarding teams for how much they build rather than how much they deploy inadvertently encourages software engineering teams to focus more on output than the quality of that output. Often bad systems are inherited by people wanting to do good work. Classifying these quality professionals as good or bad is pointless when the system within which you work prevents you from doing that. As quality professionals that doesn't mean we give up and do nothing. We can choose how we respond to the constraints we face. We can question timeframes, advocate for better practices, and invest in learning and training. [Blame is unhelpful here. ](https://www.annemariecharrett.com/the-extraordinary-in-the-ordinary/)It does nothing to fix the situation and lays the blame on the profession that has the least opportunity to fix it. Instead, focus on improving the system. Examine the levers within that system that will effect change. How can space be provided to enable quality products to emerge? Encouraging collective ownership, collaboration, and continuous improvement on these are better ways to improve the system. The job is difficult enough as it is. Quality professionals need support. Leaders who build confidence and skills to support courageous activities. Leaders who teach that resilience comes through focusing on long-term goals and that often the difference between a bad and good outcome is a day. Leaders who work to create good communities. With these, we can aspire to achieve many things, and who knows, we might even get some of those goals over the line! This is the role that leaders can play. ### Quality Coach newsletter #39 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-38-2/ Last updated: 2025-10-25T00:45:58.000Z ## 🚥 Stop Starting begin Finishing I wrote this article because in enterprise one of the most powerful levers you can use is the SDLC lifecycle. Like it or not, its the backbone of of many organisations and it makes sense to focus on a process that improves rather than hinders quality. [Why Software Teams Need Speed LimitsReducing the speed limit before a known bottleneck allows traffic to flow smoothly. While we feel we’re going slower, we actually get to our destination faster. The same principles apply in software engineering.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-24.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1736133255490-e09b695588ee)](https://www.annemariecharrett.com/why-software-teams-need-speed-limits/) ## 👩‍💻Quality Coach Book I've created a centralised point for all things Quality Coaching. For now its my book and links. I'll be expanding this to include other links and references. [Quality Coach Website![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/725b756a69a7d4c235070e51acd85560-1.png)![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/f97f6be56465e13b737cd0cc3975cd98.jpg)](https://qualitycoach.io/?ref=annemariecharrett.com) ## 🏘️ Picks from the Community I found Courtney Nash's interview on the unintended consequences of automation and the concept of joint cognitive systems. Go read/listen [Exploring the Unintended Consequences of Automation in SoftwareThis article lays out some of the common assumptions and misconceptions about automation and its role in software (and software incidents), what our research has found regarding how automation shows up in software incidents, and some ideas around how people can better design automated tools to help people better handle software incidents.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/apple-touch-icon-1.png)InfoQCourtney Nash![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/unintended-consequences-automation-software-header-1759912534899.jpg)](https://www.infoq.com/articles/unintended-consequences-automation-software/?ref=annemariecharrett.com) I like this post for the links it provides in Go Deeper, including a research paper from the Department of Informatics at the University of Oslo. [✋Stop Overcommitting and 🚚 Start Delivering: The Benefits of WIP Limit in Software Development…💥 Revolutionize Your Development Process and Deliver Results Like Never Before: How Limiting WIP Can Transform Your Team’s Success 🎉![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/10fd5c419ac61637245384e7099e131627900034828f4f386bdaa47a74eae156-4)Learn Agile PracticesDaniele Scillia (Dan The Dev)![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/1-BdUTVB8KFKPjujGEsHwhiQ.jpeg)](https://medium.com/learn-agile-practices/stop-overcommitting-and-start-delivering-the-benefits-of-wip-limit-in-software-development-98d3fa1ddfda?ref=annemariecharrett.com) Let's face it anything the Charity Major's writes is worth a read. [I wrote about this topic too](https://www.annemariecharrett.com/the-extraordinary-in-the-ordinary/), Charity's post is exceptional. [In Praise of “Normal” EngineersThis article was originally commissioned by Luca Rossi (paywalled) for refactoring.fm, on February 11th, 2025\. Luca edited a version of it that emphasized the importance of building “10x engi…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/webclip.png)charity.wtfmipsytipsy![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/normal-transp-praise-of.png)](https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/?ref=annemariecharrett.com) ## 🎫 Conferences & Events I'm speaking/attending the following events **Agile Testing Days** What can I say, I cannot wait for Agile Testing Days where I get to do a tutorial on [Expected to Lead Quality ](https://agiletestingdays.com/2025/session/expected-to-lead-quality/?ref=annemariecharrett.com)along with Fiona Charles, plus a workshop on moving at the speed of trust. I'm looking forward to catching up with so many of you. [Agile Testing DaysAgile Testing Days - November 23 - 26, 2024 in Potsdam, Germany - Europe’s GreaTest Agile Testing Conference for Software Testers, Developers & Managers![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/agiletd24-icon_color.svg)trendig![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/agiletd24-icon_color.svg)](https://agiletestingdays.com/2025/session/expected-to-lead-quality/?ref=annemariecharrett.com) I'm attending Yow! Melbourne in December 2025\. [YOW! Sydney 2025![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/yow-3f1aef9d0278d5569f0275367bad6301-1.ico)YOW! Sydney 2025Trifork![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/yow-b95cbbafe522ab349b89741aedad1925-1.jpg)](https://yowcon.com/sydney-2025?ref=annemariecharrett.com) Happy reading! Anne-Marie ### Why Software Teams Need Speed Limits URL: https://www.annemariecharrett.com/why-software-teams-need-speed-limits/ Last updated: 2026-04-13T07:43:03.000Z It's no fun dealing with roadworks and bottlenecks when you're trying to get out of the city to your holiday destination. This is especially true if you have kids in the back asking, "Are we there yet?" The road system can't handle that amount of traffic. The result? Sitting in traffic for hours with that stop-start motion, guzzling fuel. A two-hour journey turns into five hours. In software engineering, we also have bottlenecks that create major problems for delivering features quickly. These bottlenecks often appear during software testing phases, as stories and epics converge into test environments where they can be tested end-to-end. Many people call these environments SIT (Systems Integration Testing). This is particularly true in large enterprises, where combinations of legacy systems, COTS products, and newer technologies create numerous unknown dependencies waiting to merge into this critical testing phase. While we know ways to test better (early and often in an isolated and decoupled way), the pressure to deliver often means shortcuts are taken. As quality professionals, we encourage teams to adopt better practices. But it's an uphill battle when teams often throw stuff over the fence to be handled in this testing phase, further exacerbating the problem. This can be fixed. Advocating for better testing and visualising dependencies is part of the picture, but it requires teams to be given agency, time, and sufficient space to do proper dependency mapping and improved testing in lower environments. ## The Solution: Theory of Constraints What if I told you there's a way to help teams reduce delivery time and improve product quality? There is. It's called the Theory of Constraints and the use of WIP limits. The Theory of Constraints encourages us to optimise for waste. Drive change and improvement by identifying your biggest bottleneck and constraining the downstream work before the bottleneck to flow at a sustainable pace that the bottleneck can handle. This is the equivalent of reducing the speed limit before a known bottleneck so traffic flows smoothly, rather than the stop-start motion we're used to enduring. The result? While we feel we're going slower, we actually get to our destination faster. How do we make this work in software engineering? We use WIP (Work in Progress) limits right before the bottleneck. This prevents build and system testing phases from taking new work off the backlog until existing work has been completed and is working in production. Start small: identify your current testing bottleneck and set a WIP limit of 2-3 items. Monitor delivery time for 2-3 sprints to see the impact. Without new work to focus on, the whole team must complete whatever testing work is at hand to reduce the bottleneck. That means everybody tests. This benefits quality enormously. It shifts ownership from the test engineers to the whole team completing the product. Teams learn about the product's behaviour, which feeds into the context and understanding of the why of the product. This is very handy knowledge when on call at 3 AM. As the whole team has a vested interest in reducing bottlenecks, software engineers will discover an engineering approach to reducing testing problems—be it test data, test automation, or environments. Understanding of key risks will grow, with software engineers building with these in mind. Preventing teams from taking on too much work does feel like you're slowing down—in the same way that reducing speed feels like it's taking longer—but the reality is different. Yes, the team is taking on fewer epics, but the throughput is the same and the delivery time is reduced. Yes, stakeholders may initially resist "doing less work," but focus conversations on faster delivery of completed features. To summarise, sometimes the solution is to speak to the measurements that companies really value. If quality is not top of mind, speak to what is. Reducing delivery time is a compelling argument for whole-team collaboration on a definition of done that is working in production. The next time your team is stuck in testing traffic jams, remember: sometimes slowing down is the fastest way forward. \--- ## Further Reading **Theory of Constraints:** Goldratt's official explanation of Theory of Constraints - perfect if you want the theory straight from the source. https://www.goldratt.com/what-is-theory-of-constraints/ **The Phoenix Project:** *The Phoenix Project* by Gene Kim and team. A novel about IT departments learning these principles. If you've ever worked in a chaotic tech environment, you'll recognize the characters. https://itrevolution.com/the-phoenix-project/ **WIP Limits Implementation:** AWS has a solid blog post on implementing WIP limits in DevOps pipelines. Less theory, more "here's how to actually do it." https://aws.amazon.com/blogs/enterprise-strategy/deliver-faster-by-limiting-work-in-progress/ **Lean Software Development:** Mary and Tom Poppendieck's *Lean Software Development* shows how these manufacturing principles apply to software. Their website has loads of additional resources too. https://www.poppendieck.com/ ### Quality Coach newsletter #38 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-38/ Last updated: 2025-09-18T07:09:47.000Z ## 🌊 Building Momentum I turns out that walking into enterprise with a whole new bag of tricks on how testing and quality doesn't hold much sway in Enterprise. If you are not careful all your lovely ideas about improving things will fall into the vortex of passive resistence. This is where people politely listen to your idea and then continues on exactly the way they've always done. This is because there is a large system in play. Any change requires a huge amount of inertia to get moving. So you need to build momentum, one conversation at a time. In this paid post, I address the importance of building relationships and communication. Especially with people who may not necessarily want to work with you. [Building Momentum for change in EnterpriseDriving change in Enterprise requires relationship building and thoughtful communication.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-23.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1640364924460-79dc436440ae)](https://www.annemariecharrett.com/building-momentum-for-change-in-enterprise/) ## 👩‍💻Need online training? If you work for an organisation that invests in online training, this might be one to consider. Leanpub have converted my book into an online course. The course is the same content as the book but with added quizzes and questions to help digest the content. You can get a 44% [discount using this coupon](https://leanpub.com/c/quality-coach/c/38?ref=annemariecharrett.com). If you want to hear about some great discounts for the book, check out my [previous newsletter](https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-37/) which has access to all the juicy discount codes. ## 🇯🇵🇧🇷🇵🇱 31 languages Thanks to TranslateAI, [my leanpub book ](https://leanpub.com/bookstore?page=2&search=quality%20coach%27s%20handbook&type=all&ref=annemariecharrett.com)is now available in many different languages, plus its passed the Ace by DAISY accessibility checker, making the book easier to read for all. If you have bought a copy of the english version and want one in your own language, email me with a copy of your original receipt and I'll send you a coupon with a 50% discount. ## 🏘️ Picks from the Community Google are offering free\* AI courses and their short. [Introduction to Generative AI | Google Cloud Skills Boost<p>This is an introductory level microlearning course aimed at explaining what Generative AI is, how it is used, and how it differs from traditional machine learning methods. It also covers Google Tools to help you develop your own Gen AI apps.</p>![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/X46FrQX4iLxHW5MxL8jICvgZM0evMEKscCeQO-2BazGdo-3D)Google Cloud Skills BoostGoogle Cloud Skills Boost![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/favicon-144.png)](https://www.cloudskillsboost.google/course%5Ftemplates/536?ref=annemariecharrett.com) *\*nothing is free, you are the product* **Two of my favourite people, Bill Matthews and Martin Hynie have kickstarted a podcast on AI.** There's a newly launched Women in Testing Newsletter that contains some interesting articles on leadership and strategy. Check it out! 👇 [https://womenintesting.beehiiv.com/](https://womenintesting.beehiiv.com/?ref=annemariecharrett.com) Shout out to [Judy Mosley](https://www.linkedin.com/in/judymosley/?ref=annemariecharrett.com) for putting this together. ## 🎫 Conferences & Events I'm speaking/attending the following events **Agile Testing Days** What can I say, I cannot wait for Agile Testing Days where I get to do a tutorial on [Expected to Lead Quality ](https://agiletestingdays.com/2025/session/expected-to-lead-quality/?ref=annemariecharrett.com)along with Fiona Charles, plus a workshop on moving at the speed of trust. I'm looking forward to catching up with so many of you. Apparently the tickets for the tutorial are selling like hotcakes, so don't miss out. Use discount code **25-150-AnMaCh** if you've not yet booked. Hurry up though early bird ends 21st September! [Agile Testing DaysAgile Testing Days - November 23 - 26, 2024 in Potsdam, Germany - Europe’s GreaTest Agile Testing Conference for Software Testers, Developers & Managers![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/agiletd24-icon_color.svg)trendig![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/agiletd24-icon_color.svg)](https://agiletestingdays.com/2025/session/expected-to-lead-quality/?ref=annemariecharrett.com) I'm attending Yow! Melbourne in December 2025\. **Testing Talks 9th October 2025** I'm attending Testing Talks in Melbourne. I'll have some copies of the Quality Coach's Handbook to give away as prizes. [Testing Talks Conference 2025 MelbourneIn 2025, we’re excited to have larger venues, technical and leadership workshops, and a variety of exciting new experiences.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-11.ico)Testing Talks Conference 2025 Melbourne![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/TT-2025-20Date-20Trasparent-20Graph-20Melbourne.svg)](https://www.testingtalks.com.au/?ref=annemariecharrett.com) **TestFlix - Panel 11th October 2025** [Testflix 2025 - Leading Global Software Testing Conference | The Test TribeTestFlix is the Leading Virtual Testing Conference. Typical TestFlix edition hosts 50+ Speakers, and sees 20,000+ signups from 4000+ Organisations and 120+ Countries.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-Icon-White-BG-270x270.jpg)The Test Tribe![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Tf-banner-2.png)](https://www.thetesttribe.com/testflix/?ref=annemariecharrett.com) [YOW! Sydney 2025![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/yow-3f1aef9d0278d5569f0275367bad6301-1.ico)YOW! Sydney 2025Trifork![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/yow-b95cbbafe522ab349b89741aedad1925-1.jpg)](https://yowcon.com/sydney-2025?ref=annemariecharrett.com) Happy reading! Anne-Marie ### Building Momentum for change in Enterprise URL: https://www.annemariecharrett.com/building-momentum-for-change-in-enterprise/ Last updated: 2025-09-17T21:06:23.000Z Driving engineering change in enterprise organisations requires building relationships and thoughtful communication. Credibility matters too, but without these two it doesn't matter how talented you are; you will find it difficult to gather momentum and make the scaled-up changes unique to enterprise organisations. ## Difference in Enterprise When it comes to enterprise, it's all about size. Rather than driving change across fifteen teams, you are driving change across five hundred teams. With size comes silos, and with silos come formal, often rigid processes and empire building. And, of course, the human glue—masses of it. The good news is that building relationships and communicating across channels will help you in all of these. ## Building Momentum In an enterprise, you need to build momentum—a wave of change that gradually builds over time. If you're lucky, after some ebb and flow, you'll hit a tipping point and people will begin to support your idea. You will know this has happened because people will talk if your ideas are the norm and totally obvious. They may even begin to adopt your idea in the belief it's their own. When you get this level of buy-in, doors will begin to open, budgets will appear, and people will invite you to meetings. That doesn't mean the work is done, but a lot of the mental battle has been won. The rest is mostly tactical, managing rollout and delivery. ## Building Momentum One thing you quickly realise when building momentum is that you can't do it alone. To build momentum, you need to build a network of allies and advocates. That's why relationships and communication matter so much. When I talk of allies, I mean more than friends or like-minded people who agree with my vision or goal. My definition of an ally is a person who has a vested interest in my goal because it benefits them. I offer to co-create with these people. I've learned that when people understand that you're not there to claim glory but are instead willing to share it, the conversation shifts. I've also learned that when you invite people to participate rather than try to own the work, goals become intertwined, and collaborations improve. That means along with allyship comes recognition. Any wins are framed as shared wins and sometimes even as their wins. ## Who is your Ally You will need allies from executive to execution. The ability to communicate and frame your vision at multiple levels matters here. The why for an executive differs from the why for a test engineer. Become practised at framing value and benefits from their perspective and in their language. Look for allies beyond the testing and quality domain. As quality is a shared responsibility, for any change to be truly successful, you will need buy-in from many other communities, such as product owners, software engineers, delivery leads, and, of course, SRES. Find ways they can bring change into their space that will enable quality to run more smoothly. For example, better unit testing for software engineers, or story splitting for delivery leads. ## Augmented Expertise When you find allies in areas beyond your domain or field of expertise, your access to expertise expands. Instead of being only strong in quality, you can now lean on their expertise in their area. This is a huge boon, and you should absolutely seek their advice and listen to their perspective. I've gained a huge respect for other specialities and am consistently impressed with how they think about and address problems in their space. Allow people to play to their strengths and ensure that you amplify that work. For example, I'm hopeless at Jira tickets, mostly because I loathe them with a passion. I know others who delight in them. I love working with these people; together, we make a real difference! One of the benefits of an enterprise is access to a diversity of skills and talent. Make the most of that pool. ## Shared leadership That's a lot of people to build relationships with and a lot of communication to do. This can be hard, gruelling work, especially at the beginning when you've yet to build credibility and people often treat you with a healthy dose of suspicion. I never said it was easy! The added bonus of sharing leadership is that there is an opportunity to step back and rebuild emotional and intellectual capacity. This is really important as you're playing the long game here. A lot of this work is about offering and building trust. And that starts with trusting in you. Have fun.... ### Quality Coach newsletter #37 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-37/ Last updated: 2025-07-09T08:30:20.000Z ## 🤷‍♀️ Paperback or Ebook? You chose! Want a copy of the book you can hold? You're not the only one. Dozens of people have asked me if there will be a paperback version. With such demand, I've been working with the good folks at Leanpub to flip the ebook into a paperback and hardback version, ready for sale on [Amazon](https://a.co/d/acEJ8f3?ref=annemariecharrett.com). ![Picture of children all listening to a book being read.](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/07/natalie-002.jpeg) Nothing like a good book.. And you are one of the first people to get access to the book. It's available in paperback through your various Amazon sites. The hardback version is available in the US, UK, DE, FR, ES, IT, NL, PL, SE (not Australia 😞). The paperback is available in the US, UK, DE, FR, ES, IT, NL, PL, SE, JP, CA, and AU. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/07/qualitycoachbook-2.png) #### Quality Coach's Handbook On sale at Amazon in paperback and hardback options [Buy Quality Goodness](https://a.co/d/0ZBHpPu?ref=annemariecharrett.com) ## 📘 40% discount on eBook version *This offer is exclusive to subscribed readers only* ## 📘 70% discount on eBook version *This offer is exclusive to existing premium readers only* ## 📘 Free copy of the Quality Coach's Handbook *This offer is exclusive to subscribed readers only* ## 📘 What's different about the published version? If you are a premium subscriber to the quality coach book, you already know about the content. But the content is hard to find, and sometimes it's not polished. The blog's content has been completely revised and edited in the published book. Plus there's new content that doesn't exist yet on this blog. The Quality Coach's Handbook covers topics such as "What is a quality coach?" "How does it work with a team?" "What coaching techniques are useful?" and "How do I think about quality in modern engineering organisations?" There is advice for Engineering Managers and Directors on how to lead quality and organisational structures to consider when adopting this model. The handbook leans toward the practical. It's based on years of experience running similar quality models in growth companies. It contains workshops on various topics, from exploratory testing, health checks, and test automation strategies to creating an improvement process. If you like the sound of the book, subscribe to my free newsletter to receive a discount on the ebook version. [Subscribe to Free Newsletter ](#/portal/signup/free) ## 🙋‍♀️ Quality, Critical Thinking and Risk in Modern Engineering I'm still writing on the blog! This recent post is about the evolution of product excellence and what quality means for discovery, delivery, and service operations. It explores what risk means for these areas and the types of questions worth asking throughout product engineering. It's a premium article, and it's worth its weight in gold when it comes to understanding how to think about quality in modern engineering. ![Quality in Discovery, Delivery and Service Operations by Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/07/BPR-5-1-1.png) [Quality, Critical Thinking and Risk in Modern EngineeringRethinking how we think about quality in discovery, delivery, and service operations can help us to better understand the nature of risk and where to apply our critical thinking skills.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-19.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/BPR-4.png)](https://www.annemariecharrett.com/quality-critical-thinking-and-risk-in-modern-engineering/) You can also check out my post on how to write a book. What can I say? It's a process! You might be surprised that I never considered myself good at English. [How to write a bookIt took me ten years to write my book. I learned few lessons on the way.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-20.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1592819695396-064b9572a660)](https://www.annemariecharrett.com/how-to-write-a-book/) ## 🏘️ Picks from the Community Enough about me! There is plenty of other great content out there. [Kent BeckKent Beck—creator of Extreme Programming and co-author of the Agile Manifesto—reflects on decades of coding, from the birth of TDD to his experiments with AI tools shaping software’s future.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/https-3A-2F-2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com-2Fpublic-2Fimages-2F9d53c70a-bdd3-4080-8425-9520ca6acfd4-2Fapple-touch-icon-180x180.png)The Pragmatic EngineerGergely Orosz![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F46e6c850-5d9a-41be-be4c-8421c0fab4ca_1456x1048.png)](https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent?ref=annemariecharrett.com) [“More than one person doing the same task? Crazy!” - Holistic Testing with Lisa Crispin“More than one person doing the same task? Crazy” is what I have often heard when I tell people about working in pairs and ensembles (aka mob programming and software teaming). Surely two people, each working on a different task or user story, gets more work done in the same amount of time. It’s hard \[…\]![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/donkey-144-9.gif)Holistic Testing with Lisa CrispinLisa Crispin![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Heart-Team.webp)](https://lisacrispin.com/2025/06/24/ensembling-in-other-professions/?ref=annemariecharrett.com) [The cost of staying invisibleAre you you’re accidentally or intentionally influential? Learn the conscious impact to build systematic influence without manipulation.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/67b324bca3f3a_1739793596_speleties.png)Author![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/vincent-camacho-unsplash685d48639cb03.jpg)](https://www.kriscorbus.eu/blog/cost-of-unconscious-impact?ref=annemariecharrett.com) [The Art of FramingIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-7.ico)Maaret Pyhäjärvi![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Screenshot-202025-06-28-20at-2011.52.04.png)](https://visible-quality.blogspot.com/2025/06/the-art-of-framing.html?ref=annemariecharrett.com) I liked this interview with Ale Moreira by Keith Klain. OK, I lied about not spruiking my book any more, but I really had to share this interview Janet Gregory and Lisa Crispin did with me. It's 15 minutes of goodness. ## 🎫 Conferences & Events I'll be at ShipItCon in Dublin on the 29th of August. [Home - ShipItConAn annual, community driven, not-for-profit conference about Software Delivery held in Dublin .![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-8.ico)ShipItCon![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/cropped-ship-it-con-2020-v2-png-1-1.svg)](https://shipitcon.com/?ref=annemariecharrett.com) I'm doing a tutorial with Fiona Charles at Agile Testing Days in November this year. It's called Expected to Lead Quality. Here's a short explainer 👇 I'm attending Yow! Sydney in December 2025\. [YOW! Sydney 2025![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/yow-3f1aef9d0278d5569f0275367bad6301-1.ico)YOW! Sydney 2025Trifork![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/yow-b95cbbafe522ab349b89741aedad1925-1.jpg)](https://yowcon.com/sydney-2025?ref=annemariecharrett.com) Happy reading! Anne-Marie ### Quality, Critical Thinking and Risk in Modern Engineering URL: https://www.annemariecharrett.com/quality-critical-thinking-and-risk-in-modern-engineering/ Last updated: 2026-04-13T23:11:43.000Z What we value and perceive as *quality* evolves over time—a cracking good night at twenty involved drinking dozens of pints and dancing until 6 a.m. The equivalent today is an evening with close friends around a fire pit, all tucked up in bed by 11\. Time definitely changes things! It makes sense that, given our software engineering advances, our product quality concept also morphs. We have invented new things like cloud computing, microservices architecture, and modern languages. SaaS products have merged our discovery and delivery, and continuous deployment merges our delivery and service operations. We're no longer distinct activities; we're that continuous infinity loop of customer value. Because of that, we need to adapt and change once again. Today, quality requires continuous conversation about the shared understanding of value through discovery, delivery, and operations. To me, it makes sense that this conversation is driven by quality professionals—people who have one foot in the world of product and one in the world of engineering. Architects, principal engineers, and SREs are also in a prime position to make this happen. ## Customer Value in Modern Engineering Quality Professionals must carry the message of customer value from discovery into delivery, ensuring that they continue to have a shared understanding of the why. Quality Professionals are product advocates. How many people in the discovery space realise and value this? ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/07/BPR--1--1-1.png) ## Risk in Modern Engineering Quality professionals focus on risk. Risk here is whatever threatens customer value. This allows teams to make the necessary tradeoffs *in an informed way* on what to build, how to build it, and how to support it. These quality professionals begin the conversation in discovery around critical user journeys and what recovery looks like. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/07/2.png) ## Critical Thinking in Modern Engineering It's not new that thinking critically is challenging when under pressure to deliver output. Quality professionals help teams think critically about quality, what quality means for the organisation, how they know they have quality and how to make quality visible. If quality professionals don't behave this way, ask yourself why. Do they have the necessary support and structures to allow them to do so? Or is their world reduced to pass/fail and taking screenshots of defects? ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/07/BPR-3.png) ## Reclaiming Customer Experience Do we even know what customer experience means? Has it been reduced to the ability to fix our mistakes quickly? We've overindexed on output and speed of delivery to the point where we've lost our understanding of customer experience. Enshitification is real. If we're not careful, AI will only amplify this. It's time for a reset. It's time for the 'voice of the customer' to return. Rather than pass/fail, how about letting quality professionals stroll through the halls of discovery, delivery and service operations and begin asking some important and necessary questions around quality and value. Who knows, this approach may be precisely what you need to help distinguish your product from the crud of software we've come to accept as a service. Buy the quality coach's handbook [![CTA Image](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2026/04/qualitycoachbook.svg.png)](https://leanpub.com/qc/c/40?ref=annemariecharrett.com) Buy the Quality Coach book on [Leanpub](https://leanpub.com/qc?ref=annemariecharrett.com) (ebook) or [Amazon](https://a.co/d/0jFdKyz?ref=annemariecharrett.com) (for hardback or paperback) [40% Discount on Ebook - all languages ](https://leanpub.com/qc/c/40?ref=annemariecharrett.com) ### How to write a book URL: https://www.annemariecharrett.com/how-to-write-a-book/ Last updated: 2025-06-20T08:05:21.000Z Writing a book has got to be one of the big badass things I've ever done. And I'm writing this post to let you know you can too. Why? Because I thought I was the worst ever writer. When it came to essay writing, my school years were torture. This was amplified by having an elder sister in the same school who was a brilliant essayist and storyteller. She most likely followed in my father's footsteps. He as a lawyer and loved nothing more than to debate, especially on paper. Once I had entrenched myself in the belief that "I couldn't write for shit but I was good at math" my Dad's skills and dislike for authority came in quite handy. He would eagerly wait to find out what my latest essay assignment was and even took to being my ghost writer. While this seemed like a brilliant short-term solution for everyone including the teachers who could brag about their A\* student, this did nothing to help me pass my English exams, where I got a spectacular D. It also entrenched my views I couldn't write as well as setting the bar really high for being a 'good writer'. In the early 2000s, I was setting up a website for my testing business, and the web developer (remember those?) advised me to start blogging to market myself. It took a few starts, but by 2006 I was onto it. My [first blog post](https://www.annemariecharrett.com/kid-in-a-sweet-shop/) in 2006 received rave reviews from the ten people who knew what a blog was and were interested in software testing. Nevertheless, I persisted and have been writing since then. I'd been approached to write a book with others, but for a multitude of reasons, the enthusiasm died. But the idea of writing a book was born—a book written by me, myself, I. Ten years later, here we are. The book is published. I call this the longest pregnancy ever. Here are my lessons learned. I attempted to write my book three times. I would get a third of the way through and stop because either I had lost my way, the book's structure needed revising, or my ideas had evolved. Questions like, should I write the book about quality engineering, or quality coaching? Should I write it from the point of view of the reader, or by topic? Or, I've changed my thinking on that topic, should I include it? By committing to writing a post once a month and publishing its content, I freed myself up from these rabbit-in-the-headlights moments, and just write. I had to let go of the fact that it might become outdated, that the content might not be suitable for the intended audience. What I realised was that structures are not defined, but emerge, and sure enough, as I continued to write, themes became clear. I continued this approach for four years, until I reached the point where I decided it was time to stop. I could have written more, way more, but I knew it was time to draw a line in the sand. I thought at this point, it would be more of a case of assembling content than writing a book, but that too proved to be untrue. Fortunately, I decided to hire Fiona Charles as my editor. With a major in English and a deep understanding of testing, she was able to critically question and refine my content. My blog writing style is quite colloquial and conversational, while the tone of the book was to be more direct. Images had to be refined and redrawn. As I assembled the book, I discovered missing content and had to add more. And I took some away, a whole section of the book as it would have been too long. It took what felt like forever. Anyone who has done this knows the painful requirement of rewriting, re-editing, and redoing multiple times. Look, I could write forever about the whole thing, but I'll end with these words of advice: - Writing is a process. Start small and keep going - Forget about 'the book', write about what you want to - Assemble the book when you've written the things you want to say - Less is more, it's ok if it doesn't address all the things - Get your writing out there and make it public. - Get an editor - Worry about distribution when you have a book That's it! My book is available for purchase at [https://leanpub.com/qc](https://leanpub.com/qc?ref=annemariecharrett.com) ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/06/title_page-1.jpg) #### Quality Coach's Handbook [Buy the book](https://leanpub.com/qc?ref=annemariecharrett.com) A final shout-out to the Leanpub people who have been a fantastic support along this journey. ### Be the spark URL: https://www.annemariecharrett.com/be-the-spark/ Last updated: 2025-04-23T09:33:22.000Z I am wood wanting to be fire. But my flames are nowhere to be seen. I have learned from the best. I've learned to keep wood dry and which trees produce the best wood for fire. Yet still no fire. To become fire, I learn that wood needs oxygen. I find people to give me that oxygen—that space to breathe. Some offered oxygen, then took it away. Others gave me room to breathe. Yet still no fire. To become fire, I learn I need a spark. But from where? Could someone else's spark help me build a fire? But this fire gets out of control, leaving me burned out and depleted, with no wood left to burn. I am now enraged. Why can't I become fire? I deserve to be fire! Why won't someone make me fire? In sheer frustration, both depleted and angry, I make a final call. I chose to light the fire. I chose to become the spark. I become fire. Spark is courage. Spark is not waiting for someone else's permission but claiming a space that all along you've been told is not yours. Spark is choosing to believe the space is yours. Spark is stepping in and making it your own, even when every fibre of your being cries you don't belong. Spark is choosing to believe in you. Without a spark, there is no fire. Be the spark. ### Laying the Foundation for Quality Software URL: https://www.annemariecharrett.com/laying-the-foundation-for-quality-software/ Last updated: 2025-04-09T07:46:40.000Z ***A Learning Mindset at Every Level*** A learning mindset in engineering means fostering curiosity, openness to feedback, and a willingness to continuously reflect and improve. It’s the opposite of a fixed approach that assumes we “know enough” or “have done this before.” Instead, teams with a learning mindset actively seek out opportunities to understand user needs better, challenge assumptions in designs, and refine their practices based on what they learn—whether through testing outcomes, user feedback, retrospectives, or production incidents. In agile squads, this mindset comes to life in how they operate day to day. It means engaging in thoughtful retrospectives and actually applying the learnings. It means test-and-learn cycles, where experiments are welcomed and failure is treated as data, not defeat. Engineers proactively ask, "What could go wrong?" during planning and iterate not just on code but on processes, tools, and team habits. A learning mindset encourages pairing and mentoring, knowledge sharing across disciplines, and openness to improving the very systems of delivery—not just the product. ***,*** This mindset shifts the role of quality from being reactive—catching bugs—to being proactive, where the entire team works together to anticipate risks, improve system resilience, and build software that truly serves its purpose. It’s not just about being better testers or engineers—it’s about becoming better learners, together. Too often, software development teams adopt an overly simplistic view of quality, assuming that the presence of testers or a dedicated QA team is sufficient to ensure reliable outcomes. This mindset relegates testers to the role of safety net: the last line of defense to catch bugs before code reaches production. But this view is fundamentally flawed. ***The Limits of Testing*** Skilled testers bring value through critical thinking and the ability to uncover risks others may overlook. Yet, they cannot retroactively inject quality into software that hasn't been thoughtfully designed and built with quality in mind from the start. It's like painting over a cracked wall without fixing the foundation—the surface may look fine temporarily, but the underlying issues will eventually show through. By the time many defects or vulnerabilities are discovered in the testing phase, it can be too late—or too expensive—to fix them properly. Teams are then left making difficult, often suboptimal decisions: Is it worth fixing now? Should we ship and hope for the best? Would we have made a different choice had we found this earlier? These are not the questions you want to be asking at the tail end of your development cycle. ***Quality as a Built-In Principle*** A stronger approach treats quality as a fundamental property of the software development process itself. This starts by involving your testing team from the very beginning—before a single line of code is written. Their perspective should shape requirements, architecture, and the very definition of "done."Encourage early conversations around testability: How will this feature be validated? What risks might we be introducing? Define testing strategies that span all levels of your stack—unit, integration, end-to-end, and exploratory. Plan for observability, monitoring, and failure recovery just as you would plan for feature development. Hold pre-mortems to uncover potential pitfalls in advance and strategize around them. ***Leadership's Role in Quality Culture*** If you are a leader, it is your job to create a culture where quality is not an afterthought but a shared responsibility. Open the door to transparent conversations around trade-offs. Yes, technical debt is inevitable. But if we treat it with intention and plan for it proactively, we can reduce its impact over time. Ultimately, a quality-first mindset enables teams to build software that is not only more stable and maintainable but also more aligned with business goals. It's a shift from reactive to proactive, from siloed ownership to shared commitment, laying the foundation for lasting success. ### 🕵️‍♀️ Quality Coach newsletter #35 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-35/ Last updated: 2025-01-19T07:50:21.000Z ## 📘 The Quality Coach's Handbook Exciting news: I'm now in the editing phase of the quality coach book! This is the working copy of the cover page. [![Quality Coach Handbook Cover Page by Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2025/01/title_page.png)](https://leanpub.com/qc?ref=annemariecharrett.com) This means you can purchase my long-awaited book in a couple of months! [Get a sneak peek ](https://leanpub.com/qc?ref=annemariecharrett.com#describing-the-quality-coach-role)of the content by checking out the draft table of contents. Or [sign up to be notified](https://leanpub.com/qc?ref=annemariecharrett.com) when it's available. ## Book Discount for loyal readers I wanted to create this premium post because it is an essential workshop quality coaches can conduct with their teams. It may get quiet around here as I wrangle the book together. In return for your patience, all premium subscribers who are current at the time of publishing will receive a special coupon offering a 🙏 discount. It's one small way to thank you for being a loyal reader over the last four years. I may publish random posts as I polish up the book. For example, I realised that the following post on Exploratory Testing in Teams had been sitting in draft for six months and deserved to be included in the book. ## 🕵️‍♀️ Exploratory Testing with a Team I wanted to put this premium post together as I felt this is an essential workshop quality coaches can do with their teams. Exploratory testing is an unfamiliar term outside of the software testing community, and many software engineering teams don't know the benefits of performing testing in this way. Whenever I've performed this with teams, the response has been enthusiastic. So why not give it a try? [Exploratory Testing with a TeamHolding an exploratory testing session is a fun way to encourage teams to think from a customer perspective.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-15.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1603714196939-6f6436c8d0c5)](https://www.annemariecharrett.com/exploratory-testing-with-a-team/) ## 📚 From the Archives Can you believe I’ve been writing about software testing for almost twenty years? Here’s some previous content on exploratory testing [How to avoid being fooled in software testingAs software testers, our role is to avoid being fooled by stuff that is potentially fooling others. We try to avoid being fooled by the product![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-16.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1610057074806-cc8dad38fa24)](https://www.annemariecharrett.com/how-to-avoid-being-fooled-in-software-testing/) [Courage in Exploratory TestingExploratory Testing doesn’t have ‘dutch courage’ to rely on. It requires us to have conversations about our information in potentially hostile environments. Sometimes we can feel like the lone fish swimming against the tide of the silent majority.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-17.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1517984922331-8dbaa8ffa9c1)](https://www.annemariecharrett.com/courage-in-exploratory-testing/) [Beware the Lotus EatersI realised how limiting my approach to testing was in this scenario. When faced with a problem beyond my immediate capability, instead of figuring out how to fix the problem, I narrowed my model.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-18.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/lotus.flower.213-2.jpg)](https://www.annemariecharrett.com/beware-the-lotus-eaters/) Check out more under the tag [exploratory-testing](https://www.annemariecharrett.com/tag/exploratory-testing/) or for more diverse content [software-testing](https://www.annemariecharrett.com/tag/software-testing) ## 🏘️ Picks from the Community The training by James Lyndsay is on my bucket list and should be on yours, too. This one is on exploring interfaces. [Exercise: Changing Input MechanismsPlay with one field and several input mechanisms.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/wpl-60x60-logo-semitrans.png)Workroom ProductionsJames Lyndsay![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1528482408018-6d6ce68171d7.jpeg)](https://www.workroom-productions.com/changing-input-mechanisms/?ref=annemariecharrett.com) I finally got around to reading this post by Beth Andres-Beck. [Forest & DesertThis guest post is written by Beth Andres-Beck, following discussions we had preparing for our recent Øredev pair keynote (link to come).![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon.svg)Software Design: Tidy First?Kent Beck![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F3276be6b-e6d3-4a2d-b7bf-c35155b2c4a0_2048x2048.png)](https://tidyfirst.substack.com/p/forest-and-desert) Some great points from Kat Obring. [From Gatekeeper to Guide: Why Emotions Matter in Quality Engineering – Kato Coaching![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/logo-chameleon-300x300.png)Kato CoachingModern Testing in Agile and DevOps teams.kato-admin![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/logo-chameleon.png)](https://kato-coaching.com/from-gatekeeper-to-guide-why-emotions-matter-in-quality-engineering?ref=annemariecharrett.com) So good to see Ale blogging again! [Same Tools, Different Uses: Adapting Leadership to New ContextsAs leaders, our toolkits are packed with experiences, strategies, and practices that have worked wonders in the past. But when we step into new environments, those familiar tools often require a di…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-cropped-road-driving-travel-tour-twitter-header-cover-hd-32-1024x512.jpg)Road Less TestedAlessandra Moreira![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/cropped-cropped-road-driving-travel-tour-twitter-header-cover-hd-32-1024x512.jpg)](https://roadlesstested.com/2025/01/14/same-tools-different-uses-adapting-leadership-to-new-contexts/?ref=annemariecharrett.com) Some salient points from Lisa Crispin. [Testing, terminology and misperceptions - Holistic Testing with Lisa CrispinTerminology adds to misperceptions of testing, testers and contributes to lack of understanding of the value of quality, whole team approach![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/donkey-144-7.gif)Holistic Testing with Lisa CrispinLisa Crispin![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Misperception.jpg)](https://lisacrispin.com/2025/01/15/testing-terminology-and-misperceptions/?ref=annemariecharrett.com) Happy reading! Anne-Marie ### Exploratory Testing with a Team URL: https://www.annemariecharrett.com/exploratory-testing-with-a-team/ Last updated: 2025-01-16T08:13:35.000Z My experience is that teams value the opportunity to perform exploratory testing sessions, aka bug bashes. Not only do the team discover bugs they might never have found, but they pick up on SME knowledge. SME knowledge is something that many engineers value but rarely get an opportunity to deepen. Cross-functional teams value the chance to do something outside their typical expertise. Use exploratory testing sessions to help explore different areas of the system and find bugs. Win-Win! ## What to Test? Most teams prefer to test something they are working on or something that is relevant to their work. This requires some extra planning, but it's worth the effort if you can achieve it. It's good to ask your team if there are any areas of the system they're keen to understand better or have concerns about in terms of quality. The alternative is to choose some random product or a product designed for software testing exercises. ## Prep Work for Exploratory Testing an in House System It's worth putting in the effort upfront to create an environment that allows people to jump into exploratory testing quickly. Think: 1) relatively self-contained and without too many dependencies, where most of the functionality can be operated without too many mocks and stubs. Mobile apps are popular for this reason. 2) What are the devices and access rights? Are they different to yours and may require modification or creation? Once set up, ask them to log in before the session to ensure they can access it. 3) Avoid logins and authentication. That is unless you have the necessary tooling and setup. If you must have logins, create logins for people in advance or ask people to develop logins as part of the setup. 4) If possible, have a good set of diverse test data ready for users to test with. Delays for test data setup will quickly kill any curiosity and enthusiasm for the session. 5) Avoid exploratory testing in production. The risk is too high in most cases, and you load your prod environment with cruddy data. ## Planning an Exploratory Testing Team Session: Planning your session: - If you plan to hold the ET session on-site, prepare food and drinks. If it's remote, ask people to order their favourite food. Budget permitting, of course! - Pairing people How will people test, individually or in pairs? (I prefer pairs with different skill sets). Will you assign pairs or allow people to choose? - Plan how to allocate the work. Having a set of charters or focus areas helps overcome the "where do I start" anxiety many people unfamiliar with this approach have. Work can be allocated in many ways: - Split the functional menu up - Assign quality attributes (or allow pairs to self-select) - Ask people to make a list of possible failures and test for those - Ask people to take on personas and test scenarios - Different platforms (devices/browsers/apps) - Time-based functionality - Interfaces (API's or scheduled batch runs) - Diversity of Test Data - Exploratory Testing at the API layer - Different Error Codes - Different request types - Diversity of request and response data - Performance of multiple requests - Have a schedule It's good to time box shorter sessions. For example, a 2hour exploratory testing workshop might look like this: - Introduction and Share Cheat Sheets: 15 mins - Test Session to familiarise and iron out glitches: 15 mins - Map out the system using a mind map: 15 mins - ET Session: 20 mins - Debrief: 10 mins - Break - ET Session: 20 mins - Debrief & Actions: 10 mins - Close - Create Cheat Sheets Cheat Sheets are handy bits of information they can use if they get stuck. Information to include in a cheat sheet is: - Link to bug tracking tool or method of tracking bugs - Temporary Login's and passwords for the ET session - References to existing information. Explainers of how the system operates, repos, swagger files, and old bugs. - heuristics for when you get stuck in testing to trigger ideas - Pre Information Send out details before the event (a week is good) with links to the site, the scope of the effort, the schedule, and where you will track bugs. Include references that explain what exploratory testing is and its value. Even if you have told teams all this before, it's good not to assume pre-knowledge. - Send out the information again 2 days before reminding them about the event. ## Pointers for Team Exploratory Testing Sessions I find it best to treat these sessions in a fun and lighthearted way to build collaboration and knowledge. Think bug bash more than deep exploratory testing. - Encourage people to pair in the testing. - Focus on different areas of the system to introduce a variety - Make sure people are not testing the code they know in intimate detail. - Encourage people to pair across specialties. - Experiment with driver/navigation pairing styles as used in mob programming - Allow people to play to their strengths. - Have a parking lot to collate ideas and suggestions - Avoid skipping the debrief; it's an opportunity to hear people's perspectives. - Make a point of saying that it's ok to get stuck and that everyone gets stuck and runs out of ideas in exploratory testing. Remind them of the cheat sheets to help with idea generation. - Check if your team knows mind maps, and if not, have a session on mind maps and their benefit before this session uses a different approach. - Not everyone adores exploratory testing. Allow people to express both positive and negative perspectives. Avoid making judgments or contradicting their viewpoints if they disagree with yours, though there’s no harm in explaining your perspective, as in, “I find that exploratory testing helps me...” - Ask them if future sessions are more useful and how to improve them. Keep the focus on fun and encourage the team's curiosity. Many teams find exploratory testing sessions a fun way to close work. Stay curious and open about your team's software testing evolution. Happy Testing! ## Bug Bashes Reading [How to use bug bashes to build better products and stronger teamsWhether you’re hunting for bugs or weeding them out, bug bashes are a great way to improve software quality while also building stronger relationships between teams.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/qase-icon-180-1.png)Qase BlogLena Nyström![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/bug-bash.png)](https://qase.io/blog/bug-bash/?ref=annemariecharrett.com) [Benefits Of A Bug Bash - And How To Run OneJames Espie shares on the Testing Planet an introduction to Bug Bashes, what they are, the value they bring and how to run one![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-0760d1d67fe3e61a1f7a312e3367ebd28a3e910f808754a27178f8021d77f308.ico)Ministry of Testing![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/article_open_graph.png)](https://www.ministryoftesting.com/articles/benefits-of-a-bug-bash-and-how-to-run-one?ref=annemariecharrett.com) [Running a Bug Bash: A GuideHow do you thoroughly test an app quickly, identifying and reporting all bugs? The answer lies in scheduling a Bug Bash.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-AO-Favicon-512-270x270.png)Atomic SpinMiranda Michalski![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/database-diagrams-vs-code-JillDeVriesPhotography-AO2022-160-1-scaled.jpg)](https://spin.atomicobject.com/bug-bash-guide/?ref=annemariecharrett.com) [Bug bash — more than just finding bugsA quick Google search for “bug bash” will give you a lot of good links about the definition and benefits of doing a bug bash.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/10fd5c419ac61637245384e7099e131627900034828f4f386bdaa47a74eae156-3)MediumBhumika Srinivas![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/0-BzymBivGiZqxYe1C.jpeg)](https://medium.com/@bhumikaiyengar/bug-bash-more-than-just-finding-bugs-78d71db1d6d8?ref=annemariecharrett.com) ## Exploratory Testing Content [Test Heuristics Cheat SheetDive into the handy Test Heuristics Cheat Sheet, new and improved for today’s modern testing professional. Support your testing efforts and generate test ideas.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-0760d1d67fe3e61a1f7a312e3367ebd28a3e910f808754a27178f8021d77f308-1.ico)Ministry of Testing![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/hnyqtthyh6tno8962l4ic254p1au)](https://www.ministryoftesting.com/articles/test-heuristics-cheat-sheet?s%5Fid=16481842&ref=annemariecharrett.com) [What Is Exploratory Testing? An Alternative To Scripted Testing And Try To Break It TestingSimon Tomes shares how Exploratory testing differs from scripted testing and the “trying to break it” mentality of testing![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-0760d1d67fe3e61a1f7a312e3367ebd28a3e910f808754a27178f8021d77f308-2.ico)Ministry of Testing![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/9h8tjez5o2fea3hb5y1sl3q1o3sl)](https://www.ministryoftesting.com/articles/d269c6b3?ref=annemariecharrett.com) [Exploratory Testing an API![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-0760d1d67fe3e61a1f7a312e3367ebd28a3e910f808754a27178f8021d77f308-3.ico)Ministry of Testing![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/article_open_graph-1.png)](https://dojo.ministryoftesting.com/dojo/lessons/exploratory-testing-an-api?ref=annemariecharrett.com) [API Usability TestingI often joke that API hackathons are basically API usability testing days, the best opportunity for API teams to see first-hand how develope…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-5.ico)Pamela Fox](http://blog.pamelafox.org/2012/03/api-usability-testing.html?ref=annemariecharrett.com) [VADER – a REST API test heuristic – QA Matters![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-6.ico)View all posts by Stuart Ashman![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/REST-API-Producer-VADER.png)](https://qa-matters.com/2016/07/30/vader-a-rest-api-test-heuristic/?ref=annemariecharrett.com) ### Quality Coach newsletter #34 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-34/ Last updated: 2024-11-28T07:17:49.000Z ## 🤖 Coaching Teams on using AI Use the enthusiasm and curiosity around AI to help teams improve their test coverage and or solve other problems. [Using AI in Quality CoachingMany teams are keen to explore how AI can help them in improve test coverage or reduce the time required for testing.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-7.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1717501218603-1fc7cca58d6c)](https://www.annemariecharrett.com/using-ai-in-quality-coaching/) ## ⏳ What shape is your test automation in? This fun workshop helps a team identify their test automation model, which can lead to fruitful discussions about what good looks like. [Create a Team Test Automation StrategyYou don’t have to be an expert in test automation to facilitate a team test automation strategy. Here’s a fun workshop you can run with any team.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-8.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1516463654219-8bdc73d1bfae)](https://www.annemariecharrett.com/create-a-team-test-automation-strategy/) Finally, my cringe, which I wrote after waking up at 3 a.m. in some stupid panic. I finally managed to claw myself down off the cliff. This is what I felt compelled to write. [TogethernessMy little one. Do not be afraid. The morning is upon us and the dawn sheds a new light. You are loved. I am with you and will hold your hand as we walk through the shadows. I cannot go where you have been. That door is closed leaving whispers![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-14.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/IMG_6721.jpeg)](https://www.annemariecharrett.com/togetherness/) ## 📚 From the Archives [Is Test Automation the new Test Documentation?In terms of effort and maintenance has test automation taken over from test documentation? We need to keep the tester at the centre of testing![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-10.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1532153975070-2e9ab71f1b14)](https://www.annemariecharrett.com/is-automation-the-new-documentation/) [Back To Basics: Automated TestingAutomating parts of testing has always existed since people have tested software. In my early days of testing the concept of separating testing into manual and automated testing never really existed. Well not where I worked anyhow. We tested, and sometimes we used tools to help us test. In conformance![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-13.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1571324062003-0f883291547a)](https://www.annemariecharrett.com/back-to-basics-automated-testing/) [Experiments in Quality CoachingUse the concept of experiments to encourage product teams to try new approaches, tools and ways of working![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-11.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1517420704952-d9f39e95b43e)](https://www.annemariecharrett.com/experiments-in-quality-coaching/) ## 🏘️ Picks from the Community Test Automation is the theme! Don't go past this great post by Melissa Fisher, which has readily available templates and training to help you achieve a risk-based approach to test automation. [Decide what tests to automate.At my workplace we are very strategic with what we automate. It’s not automating for the sake of it but a thought out strategic process. I…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/10fd5c419ac61637245384e7099e131627900034828f4f386bdaa47a74eae156-2)MediumMelissa Fisher![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/bd978bb536350a710e8efb012513429cabdc4c28700604261aeda246d0f980b7)](https://fishouthebox.medium.com/decide-what-tests-to-automate-10dc35bbb5b4?ref=annemariecharrett.com) As I obsess over playwright scripts, this article by Mike Harris caught my eye. 👀 [Benefit from a richer Page Object Model with abstract classes and functionsThe Page Object Model we create to support our automated tests can be described as a model of the application we are testing. We can make it a richer model using abstract classes and functions. “cl…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-skills-matter-p3x-people-product-process-exchange-201e280a6-flickr-10-31-2019-9-28-06-pm.png)TestAndAnalysisView more posts![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/screenshot-2024-10-24-at-08.18.08.png)](https://testandanalysis.home.blog/2024/11/25/benefit-from-a-richer-page-object-model-with-abstract-classes-and-functions/?ref=annemariecharrett.com) And another gem, this one from Jit Gosai, on where test automation offers real value 👇 [Can We Automate All the Things? Exploring the Limits of Testing in Software SystemsCan you automate all your testing? It depends on how certain you are about your software system’s behaviour.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F0c8eb16b-22d3-4bfe-950b-3902e55ab241-2Fapple-touch-icon-180x180.png)Quality Engineering NewsletterJit Gosai![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F6e629b3a-52b0-4b4c-98fa-461d3f035955_2850x1592.png)](https://open.substack.com/pub/qualityeng/p/can-we-automate-all-the-things?r=ruxr8&utm%5Fcampaign=post&utm%5Fmedium=email) ## Upcoming speaking engagements I'm finishing up my speaking events with a rant on enshittification. Join me! [Xmas Double Bill - Talking Quality & Job Search, AM Charrett & Cerosh Jacob , Thu, Dec 5, 2024, 5:30 PM | MeetupFor our December event we have a Christmas Special for you! Anne-Marie Charrett and Cerosh Jacob return with some talks on great, prescient and provocative topics! Come alo![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/m_swarm_196x196.png)Meetup![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/600_524572363.jpeg)](https://www.meetup.com/sydney-testers/events/304442031/?utm%5Fmedium=referral&utm%5Fcampaign=share-btn%5Fsavedevents%5Fshare%5Fmodal&utm%5Fsource=link) I'll be hanging out networking at Yow! Sydney - reach out if you will be there 👥 [YOW! Sydney 2024![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/yow-3f1aef9d0278d5569f0275367bad6301.ico)YOW! Sydney 2024Trifork![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/yow-b95cbbafe522ab349b89741aedad1925.jpg)](https://yowcon.com/sydney-2024?ref=annemariecharrett.com) Anne-Marie ### Using AI in Quality Coaching URL: https://www.annemariecharrett.com/using-ai-in-quality-coaching/ Last updated: 2024-11-24T01:05:55.000Z If a team approaches you with questions on how AI can assist in testing, grab it! Any motivation to improve testing is a plus, and if AI is the tool to help improve their test efforts, then use it. ## Problem, Experiment, Observe, Evaluate There are many ways to use AI to help a team. The key is to realise that AI is a tool like any other. A quality coach can assist the team in taking a systematic, experimental approach to adopting AI. The heuristic "Problem, Experiment, Observe, and Evaluate" supports such an approach. ### Identify the ***Problem*** you want AI to help solve While a team may come to you with a tool in mind, it's important to understand the problem the team wants to solve. What exactly do they want AI to help them with? Teams typically ask, "How can I improve test coverage?" and "How can I reduce the time to write tests?" So, this is an excellent place to start. I'm sure, in time, you will find many other problems that AI can help solve. Once you understand the problem, ask the team how they will measure success. Will it be improved test coverage, reduced test creation time, or faster test creation? 💡 Avoid focusing too heavily on quantitive data if the team doesn't have existing baselines. Qualitative data is sufficient for team focused early stage experimentation. If the team has quantitative data around an agreed-upon metric, you can use that. Otherwise, qualitative data is acceptable. For example, agreeing to a team discussion on the pros and cons of an experiment and coming to an agreed-upon outcome may be the more appropriate 'definition of success' and nicely circumnavigates the need to collect baseline data, which may be overkill in early-stage experimentation. ### ***Experiment*** with AI in small slices I've seen teams get excited about how AI might help. Rather than choosing big hairy problems, encourage a lean approach with experimentation. Experiments are faster and cheaper to run, and you can iterate as you learn more. Agree on when to regroup. You could use existing team rituals such as a retro or arrange a session. I like to keep this short, a maximum of thirty minutes. 💡 Avoid skipping this step. It's important as it encourages a team to reflect and share what they have learned and allows time for deeper insights. ### ***Observe*** the outcome - What did you learn about AI? Ask open-ended questions to encourage reflection. Some questions you could ask are: - How did you find using AI? - What worked? What was difficult? What surprised you? - What would you do differently? - And what do you want to do next? 💡 Experiments rarely work as intended, especially the first experiment. There are many valid reasons for this. For example, other team priorities may result in the experiment being dropped, and the setup time was more complicated than expected. Frame any outcome as a learning. Encourage the team to keep experimenting and reflecting until a successful experiment is completed or the team decides they're done. ### ***Evaluate*** the AI experiment. Remind the team of the original definition of success you outlined for the experiment. Did we solve the problem we intended to? If you used data, did the needle change on the chosen metric? Ask them to evaluate the use of AI to solve the problem at hand. Even if the success metric trended positively, there may be other reasons a team opts not to proceed. For example, the setup time is too long, or their context is inappropriate. 💡 Ask the team to consider showcasing the results of the experiment, so other teams can learn. If the team opts out, offer to write up so you can share with other teams. ## Research and company policy If you and the team are new to AI, research existing tools. Nearly every tooling company has injected AI into a tool for marketing purposes, so it pays to be sceptical and demand case studies and pilots. If you have a security department, speak to them about what's required to endorse an external tool. You may discover they already have answers, but they may not. They may also have to go on this AI journey, so bring them along and work with them together as early as possible. If a company has already endorsed an AI tool, explore how you can use that. For example, if the company has existing AI tools (such as M365 CoPilot), can we do some experiments around building acceptance test criteria or improving test design? ## Use the opportunity in AI to build collaboration Pairing with a team to get experience using a tool is a great way to build collaboration. It levels the playing field when everyone doesn't know a new tool, so I would push to do that if possible. Offer to pair with a team member to perform a trial. You can share your knowledge of acceptance tests and test coverage while they can provide context and learn how to use a new tool. Even if the context is more technical than you are familiar with, it's still an excellent opportunity to learn together; if you feel safe, open yourself to pairing with an engineer on building (for example) a playwright test together. Be the guide on what the best test to build is. Ask to control the keyboard so you can get to practise. ## Principles of Responsible AI Your company may already have researched and created principles and governance guidelines around responsible AI. Make a point of understanding these and helping any team members be aware of their responsibilities. [Australia](https://www.industry.gov.au/publications/australias-artificial-intelligence-ethics-principles/australias-ai-ethics-principles?ref=annemariecharrett.com) has adopted the UN Responsible AI principles with some modifications. I like them; they're clear and easy to understand. I developed a mnemonic around them to ensure I can speak to them at any time. It is: *We Value Fairness To All People Continuously and Repeatibly.* - Wellbeing -> Societal and individual considerations - Value -> Human Rights, Diversity and Autonomy - Fairness -> Inclusivity - Transparency -> How AI is used - Accountability -> ownership of AI product - Privacy & Security - Contestability -> the right to question the outcome - Reliability and Safety If your company hasn't yet implemented these, the United Nations has published the ["Principles for the ethical use of artificial intelligence"](https://www.unesco.org/ethics-ai/en/eia?hub=32618&ref=annemariecharrett.com) an [ethical impact assessment](https://www.unesco.org/ethics-ai/en/eia?hub=32618&ref=annemariecharrett.com). 💡 If software testing is going to be one of the critical areas in which AI is used, take the opportunity to educate teams on responsible AI and governance. Be the gold standard in this. Happy experimenting! ### Create a Team Test Automation Strategy URL: https://www.annemariecharrett.com/create-a-team-test-automation-strategy/ Last updated: 2024-11-18T20:41:04.000Z You don't have to be an expert in test automation to help facilitate a team test automation strategy. Using common test automation patterns combined with an ethos of experimentation, you can encourage a team to define an approach that works in their context. Discussing test automation is a natural place for any quality coach to start when working with a new team. Many software engineers naturally gravitate to test automation. If you want to find common ground, this will likely be it. The following workshop is designed for a quality coach to facilitate a test automation strategy the team can begin to adopt and own. ## Test Automation Workshop Workshop Duration: 90 minutes Intended Participants: The whole Product Team Format: Online 💡 [Test Automation Workshop Template ](https://www.canva.com/design/DAGWlmpIOhY/P2RgOXMLbQql3rSqqIGKXw/view?utm%5Fcontent=DAGWlmpIOhY&utm%5Fcampaign=designshare&utm%5Fmedium=link&utm%5Fsource=publishsharelink&mode=preview) 1) Explain the purpose and value of a test automation model. Explain that many models exist and that models have evolved over the years. This is because context matters. Explain the workshop's purpose: to create a team version of a test automation model. We will discover our shape! **Recommended Timebox:** 5 minutes 2) Begin the workshop by discussing the four common considerations of a test automation model: speed of tests, reliability of the test, cost of the test, and purpose. Ask the team to rank their top four criteria. **Recommended Timebox:** 10 minutes 3) Ask the team to list the test automation types they currently perform. Stress that this is not the one they think they ought to have but the one they do. They can list as many as they like. Suggest they include manual or exploratory testing in the mix if it's performed. **Recommended Timebox:** 10 minutes 4) Reminding the team to think about current practice, not aspirational, ask the team to rank the testing type according to purpose, reliability, cost, and speed. If they get stuck, point them to the original prioritisation. **Recommended Timebox:** 20 minutes 💡 If the team has many test automation types you may need more time. Consider breaking the workshop up into two sections to allow time for this discussion as it's important 5) With current practice in mind, ask the team to evaluate the effort a testing type takes by comparing it against the other testing types. They can do this on the template by lengthening or shortening the horizontal lines. Outline the shape. Is it a recognisable object? **Recommended Timebox:** 15 minutes 6) Close off the workshop with a discussion and next steps. How do people feel about the existing shape? Show them examples of other test automation models. Is there a model they aspire to? Where are the gaps? What do they want to prioritise? Use the questions in the template as prompts for discussion. Agree on the next steps and when you will reconnect. **Recommended Timebox:** 20+ minutes And that's it! The following section describes some tips and tricks you may find helpful. ## 💡Tips and Tricks The following are some tips and tricks I've picked up over the years. ### Tackling Imposter Syndrome The team may ask you questions outside your sphere of knowledge or experience. Rather than fearing this, use the opportunity to learn more about test automation. You might not be the technical guru you feel you need to be, but you know more about software testing than most. No one can be an expert on everything. Be open about your current knowledge. Let them know you will find out and get back to them. Make a point of following up; it builds trust. Offer to pair and learn together. ### Ground the discussion The workshop aims to describe current practices, not aspirational ones. Ground the workshop by asking for examples. If there is no example, it's likely to be aspirational. Put the concept/idea into the parking lot and refocus the session on the original question. ### Software Testing and Test Automation While you may view software testing as a risk mitigation exercise, the team may not see it that way. They may view test automation as reducing test execution time and increasing confidence in the build. How you address this difference is down to personal choice. I prefer to take teams on a journey of self-discovery. In time, they will begin to understand the many nuances of test automation. You may like to address this difference head-on. Tailor the workshop to your preferred style. I provided some options if you want to go deeper with the team. ### Test Coverage In my experience, many software teams attempt to automate everything. At some point, you could do a second workshop on risk and test automation that helps use risk to be selective on test automation. Sam Connolley does a [great workshop](https://www.youtube.com/watch?v=MU0CIeqwX%5FI&ref=annemariecharrett.com) on this. ### Tooling No matter how hard you try, the conversation will rapidly shift to tooling. Have a parking lot to collate their thoughts and concerns. These will be super useful later, but right now, you want to focus on ### Pressure of delivery Teams working under intense pressure may not feel they have the luxury of thought and may pressure you to "tell them what to do." Most people under stress have little capacity to take on new things. Give them small experiments, using their retrospectives to reflect on their learning. [Kata's](https://www.techwell.com/techwell-insights/2018/10/code-katas-testers?ref=annemariecharrett.com) may be a helpful approach. ### Keep it simple Some test automation models are criticised in the software testing community as too simplistic and not reflective of good testing practices. These are valid criticisms. No model is perfect, but that doesn't mean they are not helpful, especially as a starting point. Nuance comes once there's a solid grounding of experience. ### The fine line of coaching As a quality coach, your role is to balance helping the team see what good looks like with enabling them to have agency over their test automation strategy. This can be a fine line to negotiate. Too much direction and the team loses agency and decision-making; it becomes your test strategy, not theirs. Too little direction will cause the team to struggle to assemble a meaningful plan. Coaching is a skill, and I often struggle to strike the right balance. Be kind to yourself. You are learning, too. ## Test Automation Model References [Testing Pyramid: An Evolutionary TaleChange is ubiquitous in software development. New languages and frameworks are invented, old ones toppled. The one thing unwilling to move is Testing Pyramid.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/647618f73e4f16d380e8eeeb_favicon.png)link to github account![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/651de52824ca56d04844e3e1_2pyramids-midsize.png)](https://www.octomind.dev/blog/testing-pyramid-an-evolutionary-tale?ref=annemariecharrett.com) [The Testing Trophy and Testing ClassificationsHow to interpret the testing trophy for optimal clarity![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/apple-touch-icon.png)Kent C. Dodds 🌌 kentcdodds![](https://res.cloudinary.com/kentcdodds-com/image/upload/$th_1256,$tw_2400,$gw_$tw_div_24,$gh_$th_div_12/co_rgb:a9adc1,c_fit,g_north_west,w_$gw_mul_14,h_$gh,x_$gw_mul_1.5,y_$gh_mul_1.3,l_text:kentcdodds.com:Matter-Regular.woff2_50:Check%20out%20this%20article/co_white,c_fit,g_north_west,w_$gw_mul_13.5,h_$gh_mul_7,x_$gw_mul_1.5,y_$gh_mul_2.3,l_text:kentcdodds.com:Matter-Regular.woff2_110:The%20Testing%20Trophy%20and%20Testing%20Classifications/c_fit,g_north_west,r_max,w_$gw_mul_4,h_$gh_mul_3,x_$gw,y_$gh_mul_8,l_kent:profile-transparent/co_rgb:a9adc1,c_fit,g_north_west,w_$gw_mul_5.5,h_$gh_mul_4,x_$gw_mul_4.5,y_$gh_mul_9,l_text:kentcdodds.com:Matter-Regular.woff2_70:Kent%20C.%20Dodds/co_rgb:a9adc1,c_fit,g_north_west,w_$gw_mul_9,x_$gw_mul_4.5,y_$gh_mul_9.8,l_text:kentcdodds.com:Matter-Regular.woff2_40:kentcdodds.com%2Fblog%2Fthe-testing-trophy-and-testing-classifications/c_fill,ar_3:4,r_12,g_east,h_$gh_mul_10,x_$gw,l_unsplash:photo-1527871454777-032ec3f75edc/c_fill,w_$tw,h_$th/kentcdodds.com/social-background.png)](https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications?ref=annemariecharrett.com) [Using the Testing Trophy HeuristicThe Testing Trophy is a heuristic for making choices about test automation. Read ahead for answers about how and where to test your…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/10fd5c419ac61637245384e7099e131627900034828f4f386bdaa47a74eae156-1)The Quality IndexMichael Scotto![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/1-sK6dUqZ_0GpkzlzM7gvrFg.png)](https://thequalityindex.com/using-the-testing-trophy-heuristic-41a9596b8cf3?ref=annemariecharrett.com) [The Practical Test PyramidFind out what kinds of automated tests you should implement for your application and learn by examples what these tests could look like.![](https://martinfowler.com/favicon.ico)martinfowler.comHam Vocke![](https://martinfowler.com/articles/practical-test-pyramid/title.png)](https://martinfowler.com/articles/practical-test-pyramid.html?ref=annemariecharrett.com) [Testing Pyramids & Ice-Cream Cones![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-3.ico)Alister ScottAlister Scott![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/eye.jpg)](https://alisterscott.github.io/TestingPyramids.html?ref=annemariecharrett.com) [Just Say No to More End-to-End Testsby Mike Wacker At some point in your life, you can probably recall a movie that you and your friends all wanted to see, and that you and y…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-4.ico)Google Testing BlogGoogle![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/googlelogo_color_200x200.png)](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html?ref=annemariecharrett.com) [Your automation testing strategy: pyramids, triangles and beyondIf your team struggles with automation testing, don’t feel alone. This post is about figuring out where to start and establishing a solid base you can build on.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-2.ico)mablLisa Crispin![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/TestAutomationStrategy.jpg)](https://www.mabl.com/blog/your-automation-testing-strategy?ref=annemariecharrett.com) [Test Automation Strategy Template](https://www.canva.com/design/DAGWlmpIOhY/P2RgOXMLbQql3rSqqIGKXw/view?utm%5Fcontent=DAGWlmpIOhY&utm%5Fcampaign=designshare&utm%5Fmedium=link&utm%5Fsource=publishsharelink&mode=preview) by [Anne-Marie Charrett](https://www.annemariecharrett.com/) is licensed under [Creative Commons Attribution-ShareAlike 4.0 International![](https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1)![](https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1)![](https://mirrors.creativecommons.org/presskit/icons/sa.svg?ref=chooser-v1)](https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1) *Thanks* [*Irja Straus*](https://www.linkedin.com/in/irjastraus/?ref=annemariecharrett.com) *for feedback on this workshop.* ### Togetherness URL: https://www.annemariecharrett.com/togetherness/ Last updated: 2024-11-13T18:26:08.000Z My little one. Do not be afraid. The morning is upon us and the dawn sheds a new light. You are loved. I am with you and will hold your hand as we walk through the shadows. I cannot go where you have been. That door is closed leaving whispers of darkness and sadness. But I will walk with you today. Today as the dawn lights up the sky. And whatever lies out there, what ever stands in our way, we will face together. Hold my hand dear one. I am with you. ### 📖 Quality Coach newsletter #32 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-32/ Last updated: 2024-11-13T09:39:05.000Z ## 📊 You have to be this tall to do quality assistance Quality Coaching and the Quality Assistance Model is not for every tester, and it's not for every organisation. Some foundational elements make quality coaching easier to adopt. I've listed them here in this article. You will need a paid subscription to access this article. [Be this tall to do Quality AssistanceJust like any fairground ride, I recommend having these systems in place before you consider quality assistance![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-5.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/s-l1600.webp)](https://www.annemariecharrett.com/be-this-tall-to-do-quality-assistance/) ## 🎀 Coaching on Cross-Functional Requirements A great workshop by [Parveen Khan](https://www.annemariecharrett.com/author/parveen/) on cross-functional requirements. So often, teams neglect to think about quality attributes. Check how Parveen navigates a team on how to think about these elements. [Building Cross-Functional expertise in a teamProduct teams often overlook cross-functional requirements. Here’s one way to help them consider those quality attributes.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-6.png)Anne-Marie CharrettParveen Khan![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/cfr.png)](https://www.annemariecharrett.com/building-cross-functional-expertise-in-a-team/) ## 🏘️ Picks from the Community This month's theme is books & research. First, Lisa Crispin and Janet Gregory published their book on holistic testing. [Holistic Testing: Weave Quality into Your Product![](https://static.ghost.org/v5.0.0/images/link-icon.svg)LeanpubJanet Gregory![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/s_hero2x)](https://leanpub.com/holistictestingweavequalityintoyourproduct?ref=annemariecharrett.com) Isabel Evans is researching [test tooling heuristics](https://isabelevansconsultancy.wordpress.com/2024/10/31/using-the-test-tooling-heuristics-in-different-ways/?ref=annemariecharrett.com). The effort required to determine these is extensive, and it is worth reading to understand the thinking behind it. [Gáspár Nagy](https://leanpub.com/u/gasparnagy?ref=annemariecharrett.com) and [Seb Rose](https://leanpub.com/u/sebrose?ref=annemariecharrett.com) have developed a series of BDD (Behaviour Driven Development) books. [The BDD Books - DiscoveryBDD for all (3 Amigos - PO, BA, Dev, QA) : Discovery workshops, exploring behaviour using example mapping, rules, concrete examples - all are clearly explained.![](https://static.ghost.org/v5.0.0/images/link-icon.svg)LeanpubGáspár Nagy![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/s_hero2x-1)](https://leanpub.com/bddbooks-discovery/c/LeanpubWeeklySale2024Jul12?ref=annemariecharrett.com) [Nicola Lindgren](https://leanpub.com/u/nicolalindgren?ref=annemariecharrett.com) has written a book on starting your career as a software tester. [Starting Your Software Testing CareerA guide to finding your first role as a Software Tester, suggestions on useful ways to upskill and advice on how to do a great job once you have landed a role.![](https://static.ghost.org/v5.0.0/images/link-icon.svg)LeanpubNicola Lindgren![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/s_hero2x-2)](https://leanpub.com/startinginsoftwaretesting?ref=annemariecharrett.com) [Emily Bache](https://bsky.app/profile/emilybache.com?ref=annemariecharrett.com) has this coaching session on mock objects that a team can follow. Marie Cruz and Lewis Prescott have written a book on contract testing. Check it out here [Contract Testing in ActionContract testing is a simple, reliable way to make sure that each service and API plays nice with other components so you can deploy independently and safely. Large, loosely coupled systems have hundreds, even thousands, of interactions—and traditional testing can often struggle to keep up! Enter contract testing. This rapidly growing new approach checks API and service compatibility by verifying it against an agreed contract. No more unexpected integration issues, and no more breaking things in production! In Contract Testing in Action you’ll learn: The core concepts and practices of contract testing Testing microservices with Pact Consumer-driven and bi-directional testing Building a contract testing framework Converting API integration tests to contract tests Contract Testing in Action introduces the practice of contract testing through engaging hands-on examples. You’ll learn how to introduce contract tests for multiple different types of communication, from REST APIs to event-driven architecture. By the end of this practical guide, you’ll be comfortable with advanced contract testing concepts like can-i-deploy, provider states, and webhooks. You’ll even get tips on how to introduce contract testing to your team and other business stakeholders.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/Cruz-HI-1.png)Manning Publicationsfrom the author![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Cruz-HI-1.png)](https://shortener.manning.com/1GYg?ref=annemariecharrett.com) ## Upcoming speaking engagements Doing a local event to finish up the year. [Xmas Double Bill - Talking Quality & Job Search, AM Charrett & Cerosh Jacob , Thu, Dec 5, 2024, 5:30 PM | MeetupFor our December event we have a Christmas Special for you! Anne-Marie Charrett and Cerosh Jacob return with some talks on great, prescient and provocative topics! Come alo![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/m_swarm_196x196.png)Meetup![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/600_524572363.jpeg)](https://www.meetup.com/sydney-testers/events/304442031/?utm%5Fmedium=referral&utm%5Fcampaign=share-btn%5Fsavedevents%5Fshare%5Fmodal&utm%5Fsource=link) ## Please Share 😍 The monthly quality coach newsletters are my way of sharing and amplifying work in our incredible community. If you like my work, please share it with your colleagues and peers! Like the book? Why not provide a testimonial? Hit [this link](https://widget.senja.io/widget/c5d943cc-0e7d-43d3-b25e-1b7184c3fc11?ref=annemariecharrett.com), job done! Too easy! 😁 Until next time, Anne-Marie ### Building Cross-Functional expertise in a team URL: https://www.annemariecharrett.com/building-cross-functional-expertise-in-a-team/ Last updated: 2024-11-04T06:44:48.000Z Teams often focus on functional requirements during sprint planning, refinement, or three amigos, overlooking cross-functional requirements (CFRs). Performance, security, observability, and accessibility are commonly overlooked cross-functional requirements. The problem goes deeper, though. Team members differ in opinion on what these terms mean and how much they matter. ## Cross-Functional Requirements Workshop I will share a workshop I have used on many teams to help combat this challenge. The workshop facilitates discussions with the teams to achieve a common understanding of cross-functional requirements and why we should care about them. I used Miro or Mural to do this. You could include developers, testers, coaches, product owners, business analysts, and platform team members. Below is a template I used in the workshop. ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfawYdu_F2r5X60Ye0kAzDuySYWxira9ot9NuLFu2cRWC5lQGN2LLhqwOaGKMpmps5TUoMrxEpoGme3Rxmmrkp_VMpmapupyPzm1RvoxjOvReRBWgvgjK07H3fC-GYtzAqjWobgGNlzPte2xWYj-PnonWc?key=iL1hw3-wR7x_WYgA1fdW0w) Template for remote cross functional requirement workshop ## List CFR's I ask the team members to choose the cross-functional requirements for a particular product the team is working on. You will notice a long list and repeated CFRs, as every team member might add every CFR they can think of. This list is not a prioritised list yet. ## Define the terms Moving to the next part of the workshop, ask the team to define each CFR. Whenever I have done this on any team, I have observed that everyone on the team either had a different definition or the exact definition but with different terminology or understanding. Each time I did this exercise, the team's feedback was that they never realised each one of them had such a different understanding. Another observation is that sometimes teams won't agree on one definition, which is okay, in my opinion. As long as it's captured and the entire team understands and agrees. ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXcNxhI3OnPiAFfHia6K2jS8EqsGP5fHk4UG0FS-EHq-Sq4A98akIRF08IoXumX_CSFfWRtzXJ5mV3Lp2InNDRo5DuRMpvAijjQwBkx3-PwcSWKh9b6SYP6exPvSpd4gTdvGzKxzdzODYOROqc06-panZV0?key=iL1hw3-wR7x_WYgA1fdW0w) ## Prioritising Cross-Functional Requirements Now that you have a list and definitions, the next step is to prioritise or look for what's most relevant to the team's work. The product owner can drive the discussion to help the team prioritise this list. The next step is to help the team explore more detail. I ask the team to create prompt questions for each CFR. This exercise helps the team consider what they need to consider. For example, one prompt question for security testing might be, "How will user identities be verified and authenticated?" Each team member can add prompt questions to the list. Encourage as many prompt questions as possible. ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfOji1zEBDXLlMKhUJ098bXcfkctVRHE7QmJMnxJg-8zCWzRJO_4zk8ZICQHpzTRrQnbgQtrCsiRj7AnZKjm-pg41En-zMuAb1MOtGkNf8X6opDSurQCDESba8Vq7qhXLoih3_F7R0Y8nRy3jTq63ISvbhm?key=iL1hw3-wR7x_WYgA1fdW0w) Select your top 3 to 5 prompts for each CFR. These will then serve as a guide for prompt discussions during refinement. The following section discusses optional metrics in the template that may not apply to all CFRs. You can define team metrics you want to capture and evaluate for each CFR. When it's time to do a demo, you can use the metrics or status of each CFR to show what has been implemented and the current status of the implementation details. This is another way to coach and enable the team to think about CFRs instead of teams always relying on a quality engineer or tester. ## Reuse the CFR Prompts Now that you have a prioritised list of CFR, definitions, and prompts, this becomes your template. It can be published and added to a Jira user story as a template for every story, making it handy for the team to use while reviewing each story. I have used this on many teams, and it worked well for teams to know what questions to ask to start discussions. Knowing that the entire team has the same understanding makes it much more manageable. ### Be this tall to do Quality Assistance URL: https://www.annemariecharrett.com/be-this-tall-to-do-quality-assistance/ Last updated: 2024-10-30T05:30:27.000Z Do you want your organisation to adopt a quality assistance model? Have these in place before you adopt the model. ## Software Engineers who Test Your software engineers understand and agree that all software testing is part of their remit. And that means hiring engineers with this in mind. (I call this move the ultimate shift left). If you hire software engineers who would prefer QA's or test engineers to do the testing, constant friction will make the quality assistance model hard to adopt. The shift is possible, but it takes conscious effort from senior leadership. You will need to make significant changes around engineering role descriptions, hiring, and interviewing, and that's just for new hires. Coaching and training programs on software testing will be required for existing software engineers to help them understand their new scope and ways of working. ## Engineering Leadership Own Quality You can't expect teams to take on additional work without ensuring senior leadership sets expectations around quality. Ownership starts at the top. If you are serious about maintaining good quality, consider what behaviours senior leadership must demonstrate to back that up. Consider setting quality-related OKRs tied to company success. Too many senior leaders pay lip service to quality, believing that the "team should decide". In my opinion, this is a cop-out. One of the benefits of the quality assistance model is that the buck stops with leadership, which means they make the tradeoff on quality evident to everyone. [ ](https://www.geeksforgeeks.org/history-of-software-testing/?ref=annemariecharrett.com) ## Enabling Teams You must have a robust enabling team that develops and maintains test automation tooling required for a quality assistance model. These software engineers will build and maintain any necessary tooling. They can create and embed blueprints into newly created repositories, enabling product teams to begin test automation immediately. You don't want software engineers having to maintain these tools, so invest here. ## Modern Engineering practices Small slices of customer value, rapidly deployed to production, feature flagging, distributed tracing, monitoring, and alerting offer diverse risk mitigation approaches. Small slices of work reduce the risk of failure, and canary releases minimise the impact of failure. Monitoring and alerting help you identify issues, perhaps even before a customer knows them. Distributed tracing facilitates the fast identification of problems. Modern engineering practices are essential because software engineers should not be expected to perform software testing at the same level as specialised quality professionals who test all day. Also, confirmation bias is real. Spotting issues in other people's work is easier than your own. For these reasons, having alternative risk mitigation strategies minimises the impact of a software engineer missing a bug. If our software testing misses a bug, there's a solid chance we will find it through other methods. ## Context Matters Of course, the quality assistance model is not applicable in some contexts. If I deal with a massive legacy system with intricate dependencies, I want software test engineers with SME knowledge on my team. They help with early identification of unknown dependencies, customer usage and many other elements. In other contexts, there may be legal and compliance reasons why a quality assistance model won't work for you. Don't unthinkingly follow what's new and attractive. Be sensible when assessing your company's context and risk appetite. Critical thinking doesn't stop at testing a product. Advise your company to consider risks and context when adopting quality approaches. Finally, if you are a quality professional weighing up whether your company should use quality assistance, carefully identify and observe how your leadership team is performing. If you are expected to drive change with zero budget and through 'influence,' be aware of the limitations of what can be achieved. I would avoid committing to anything the engineering leadership is unwilling to invest in, whether advocacy or budget. Have fun! ### 📖 Quality Coach newsletter #31 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-31/ Last updated: 2024-10-13T21:33:52.000Z ## 🏢 Building a quality coach operating model If you intend to implement a quality coach approach at your company, you may wish to describe your [quality coach operating model](https://www.annemariecharrett.com/quality-coach-team-operating-model/). While you may be clear on what it should look like, many others in the organisation will have no clue. [Quality Coach Team Operating ModelThe hub and spoke model is an effective org structure for a quality coach enabling team![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-1.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Quality-Coach-Enabling-Team.jpg)](https://www.annemariecharrett.com/quality-coach-team-operating-model/) If you are unclear about something, trying to model it will help you clarify what good looks like. Given that the quality coach model is a relatively new concept, you must over-index what these approaches look like. Fortunately, this article gives you some ideas and things to think about. ## Other Posts A collection of posts from the archives. [Dropping the BallDoes the thought of ‘dropping the ball’ fill you with dread ? Perhaps you feel you will let people down, or more importantly yourself?![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-3.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1565499110650-e298c6be8c01)](https://www.annemariecharrett.com/dropping-ball/) [Boost your engineering capability with this growth-focused frameworkℹ️In this article, we will use the term ‘Engineering Capability’ to mean the practices and approaches we use to get work done within an engineering department. This article extends and references the work of two previous publications in this series. Namely ’Accelerate your quality culture by identifying your engineering![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-4.png)Anne-Marie CharrettNeil Younger![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1516880711640-ef7db81be3e1)](https://www.annemariecharrett.com/engineering-capability-model/) [Team Topology & Quality Engineering StructuresWhat is the optimal structure for Quality Engineering within Engineering? Anne-Marie Charrett writes about some of the complexities to consider![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon-2.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Screen-Shot-2021-10-16-at-7.04.55-pm.png)](https://www.annemariecharrett.com/team-topology-quality-engineering/) ## 🏘️ Picks from the Community It's an oldie but a goodie from [Lisa Crispin](https://www.linkedin.com/in/lisacrispin/?ref=annemariecharrett.com). [The Agile Testing Quadrants - Agile Testing with Lisa CrispinThe Agile Testing Quadrants are a thinking tool that help teams plan and execute testing activities so they can confidently deliver value![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/donkey-144-5.gif)Agile Testing with Lisa CrispinLisa Crispin![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Agile-Test-Quadrants-with-examples-v3-credited.png)](https://lisacrispin.com/2024/10/11/the-agile-testing-quadrants/?ref=annemariecharrett.com) And [Maaret Pyhäjärvi](https://www.linkedin.com/in/maaret/?ref=annemariecharrett.com) also reposted an old but great article on Ensemble Programming. [Learning programming through osmosisIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon.ico)Maaret Pyhäjärvi![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/icon18_edit_allbkg.gif)](https://visible-quality.blogspot.com/2024/09/learning-programming-through-osmosis.html?ref=annemariecharrett.com) [Gitte Klitgaard ](https://www.linkedin.com/in/gitteklitgaard?miniProfileUrn=urn%3Ali%3Afs%5FminiProfile%3AACoAAAAQ3O4BvDh2bkuyUvGZeW345bOHktQJ7rs&lipi=urn%3Ali%3Apage%3Ad%5Fflagship3%5Fsearch%5Fsrp%5Fall%3BCkbeYMANQv2%2FYFmHGK3LjA%3D%3D&ref=annemariecharrett.com)also wrote a great article on what it means to be technical. [I am not really a tech person – or am I?![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/favicon-1.ico)Nativewired![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/IMG_3456-940x705.jpg)](https://www.nativewired.com/i-am-not-really-a-tech-person-or-am-i/?ref=annemariecharrett.com) [Lena Pejgan Nyström ](https://www.linkedin.com/in/lena-pejgan-nystrom/?ref=annemariecharrett.com)writes a great series of articles on the Jurassic Park question, in which she explores the tensions between capability, morality, and legality in software engineering. [The Jurassic Park Problem & Software Development (Part 1) – QuestionAble by Pejgan![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-cropped-lg-300x300.png)QuestionAble by PejganLena Pejgan Nyström![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/5eb2b26c03a8a9e4f95209ae7898804a)](https://testing.pejgan.se/the-jurassic-park-problem-part-1/?ref=annemariecharrett.com) [Jenna Charlton](https://www.linkedin.com/in/jbcharlton/?ref=annemariecharrett.com) wrote this on point article about retaining testing talent. [Future Proofing your QA TeamJenna Charlton shares some essential strategies for managing high-performing QA teams, including retention, skill diversification, and career progression.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/quality-logic-favicon-300x300.png)QualityLogicJenna Charlton![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/two-men-collaborating-code-web.jpg)](https://www.qualitylogic.com/knowledge-center/future-proofing-your-qa-team/?utm%5Fcontent=310907319&utm%5Fmedium=social&utm%5Fsource=linkedin&hss%5Fchannel=lcp-47467) ## Upcoming speaking engagements Hustef the Hungarian Software Testing Forum conference is over. It was such a great event. Two more events in October and then a well-deserved rest. 🛏️ ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/10/IMG_6851.jpeg) [Testing Talks Conference 2024 MelbourneWe want Testing Talks Conference 2024 to be a reunion for our community. A fun event for all; to share, learn and reconnect in-person.![](https://testing-talks-release-assets.s3.ap-southeast-2.amazonaws.com/favicon.ico)Testing Talks Conference 2024 Melbourne![](https://www.testingtalks.com.au/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRIIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--d770658c6dd09517eb820728c1c197515ca70791/tt-2024-melb-graph.png)](https://www.testingtalks.com.au/upcoming-events/testing-talks-conference-2024-melbourne?ref=annemariecharrett.com) [DevOps Summit NSW 2024The leading DevOps event across APAC to discuss how emerging tech is changing the DevOps landscape.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-fav-forefront-events-03-270x270.png)Forefront EventsRuth Collins![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/DevOps-1-3.png)](https://forefrontevents.co/event/devops-summit-nsw-2024-2/?ref=annemariecharrett.com) ## Please Share 😍 The monthly quality coach newsletters are my way of sharing and amplifying work in our incredible community. If you like my work, please share it with your colleagues and peers! Until next time, Anne-Marie ### Quality Coach Team Operating Model URL: https://www.annemariecharrett.com/quality-coach-team-operating-model/ Last updated: 2024-10-12T23:23:56.000Z Where do quality coaches fit within an organisational structure? Do they permanently sit within a product team or float across multiple teams? Exactly where do quality coaches reside? Over the years, I've worked with two models and heard of blended versions of these models. The first is a quality coach permanently embedded in a team. Here, a quality coach's main objective is to work closely with one team and support other teams within a tribe. The quality coach may or may not report to an engineering manager. The other option is to have quality coaches sit within an enabling team of quality coaches. The quality coaches have their strategy, backlog, and roadmap. The enabling team's function is to support multiple product teams and tribes by offering quality coaching services. A hub-and-spoke model is a popular and helpful model for this type of team. ## The Hub The hub is internally focused. It has its internal strategy and roadmap executed through a backlog. Backlog tasks such as: - Test environment, test data strategies. - North Star vision of testing in production - Content and Workshop Templates for Quality Coaches to use as needed. - Identifying measurements and metrics. Tracking progress across engineering. - Creating career paths for quality coaches - Creating and maintaining test automation frameworks and tooling ## The Spoke The spoke part of the model is externally focused, interacting with other parts of product engineering. Predominantly, it focuses on coaching and supporting teams, but it also includes: - Collaboration efforts with Delivery and SRE and Development Practices to develop a holistic approach to quality - Integrating testing blueprints into repository templates stored in Backstage - Coaching teams on quality and facilitating workshops - Ad hoc requests for test data, environment support through a slack channel - Engineering-wide projects such as SOC2 compliance - Three-month missions where a coach sits in a team. ## Missions A mission occurs when a quality coach is embedded in a team for a fixed time. Each mission has an objective and a success metric to identify its completion. The maximum time was three months. The types of activities a quality coach would perform were: - writing test automation where the coverage was shallow - helping a new team put together their quality practices and measurements - supporting teams with complex or critical testing needs (migrations etc) The overall approach is described below: ![Quality Coach Enabling Team Hub n Spoke Model by Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/09/Quality-Coach-Enabling-Team-1.jpg) Quality Coach Enabling Team Hub n Spoke Model by Anne-Marie Charrett *Use the Canva Template link to create your own Hub and Spoke model.* [Create your own model](https://www.canva.com/design/DAGSOJ4d6EY/OmlS8N2eRv%5FIgNdR71VbRA/view?utm%5Fcontent=DAGSOJ4d6EY&utm%5Fcampaign=designshare&utm%5Fmedium=link&utm%5Fsource=publishsharelink&mode=preview) Both approaches have pros and cons. I've found the enabling team incredibly effective and efficient. It creates a sense of community and provides support in a demanding role. ## Reporting Lines It can be difficult to decide who a quality coach reports to. Quality coaches can report to a senior quality professional, engineering managers, or, if senior, directors of engineering. Most quality coaches favour being managed by a quality coach1.They feel heard and understood. Many engineering managers are uncomfortable managing quality coaches. They are unfamiliar with what success looks like and how to help in their career paths. This can be coached, but with a busy workload, many engineering managers are comfortable handing this responsibility over to a director of quality engineering. I favour keeping quality coaches' work on a team backlog, holding the quality coach accountable to the engineering manager for completing team tasks, and then having a senior quality professional as a manager who guides them along their career path. This is something to be discussed with all involved parties. Do you have a favourite model that works for you? *1 Read Lisa Crispin's comment below for a counterexample of this.* *Is this article worth a testimonial? Would you be willing to write one? I've made it super easy to write* 😁 [Give a testiomonial](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com) ### 📖 Quality Coach newsletter #30 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-30/ Last updated: 2024-09-16T22:36:33.000Z ## 🚑 Measuring Team Health This month's premium article looks at measuring team health. Having spoken to many teams, many have talked about wanting to know what good enough looks like. Like anything in software engineering, this isn't easy to define as much is context-dependent. A collection of possible measures that align with gaps the team wants to focus on is an excellent way of helping teams measure and see progress. [Is Your Quality Ecosystem Thriving?If you cant measure something, you cant improve it - Peter Drucker![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon.png)Anne-Marie CharrettDeepika Nagaraja![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/Screenshot-2024-08-25-at-5.52.33-PM.png)](https://www.annemariecharrett.com/are-you-nurturing-the-seeds-of-quality-2/) ## Other Posts I have two additional posts that explore tech leadership, Anne-Marie style. These posts are open to all. [RecognitionJust because you do an amazing job and you show value doesn’t mean you will be adequately recognised. You cannot control being recognised. You can control what brings you joy in the day.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1503451664228-da6529e661d5)](https://www.annemariecharrett.com/recognition/) [ValueWhen we take on a job, we’re entering a contract to deliver some value and its wise to demonstrate your commitment to that contract. Just don’t tie it to your self worth and the need for recognition.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/photo-1584044283481-9b18070011e1)](https://www.annemariecharrett.com/value/) ## 🏘️ Picks from the Community Collaborating and working with customer support is often overlooked but is an invaluable source when seeking to understand better what customers value. Ashley Graft offers her experience in this post. [Bringing the Engineering & Product Teams closer to customers: Working with SupportIn one of my previous roles before I decided to move completely over to test, one of my responsibilit…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8j7kvp660rqzt99zui8e.png)DEV Communityashleygraf\_![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fxcromvescvkejmhgs3ne.png)](https://dev.to/ashleygraf%5F/bringing-the-engineering-product-teams-closer-to-customers-working-with-the-support-team-c0a?ref=annemariecharrett.com) I was intrigued by this LinkedIn post by Joao Neto on using the Strangler Fig pattern for data. [Joao Neto on LinkedIn: Strangler Fig Pattern for... Data? In software architecture, the…Strangler Fig Pattern for... Data? In software architecture, the Strangler Fig Pattern is a well-known strategy for incrementally migrating legacy systems to…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/al2o9zrvru7aqj8e1x2rzsrca)LinkedInJoao Neto![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/1725534561879)](https://www.linkedin.com/posts/joaopneto%5Fstrangler-fig-pattern-for-data-in-software-activity-7237416521025654785-Me6S?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop) [Amruta Pande](https://www.linkedin.com/in/amruta-pande/?ref=annemariecharrett.com) is a QA at Canva who is writing about her experience in the AI space. Check out her work! [Test Emotional Intelligence in AIThere are many factors to consider when testing AI systems, such as bias, fairness, and functional behaviour. Apart from that, we should…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/10fd5c419ac61637245384e7099e131627900034828f4f386bdaa47a74eae156)Mediumamruta![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/1*pk7XCUcXoSWkwv0btLchPA.png)](https://medium.com/@pandeamruta27/test-emotional-intelligence-in-ai-646addc51a34?ref=annemariecharrett.com) ## Upcoming speaking engagements I am coming to the tail end of speaking conferences for this year. Three in October and then a well-deserved rest. 🛏️ [DevOps Summit NSW 2024The leading DevOps event across APAC to discuss how emerging tech is changing the DevOps landscape.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/icon/cropped-fav-forefront-events-03-270x270.png)Forefront EventsRuth Collins![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/thumbnail/DevOps-1-3.png)](https://forefrontevents.co/event/devops-summit-nsw-2024-2/?ref=annemariecharrett.com) [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Testing Talks Conference 2024 MelbourneWe want Testing Talks Conference 2024 to be a reunion for our community. A fun event for all; to share, learn and reconnect in-person.![](https://testing-talks-release-assets.s3.ap-southeast-2.amazonaws.com/favicon.ico)Testing Talks Conference 2024 Melbourne![](https://www.testingtalks.com.au/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRIIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--d770658c6dd09517eb820728c1c197515ca70791/tt-2024-melb-graph.png)](https://www.testingtalks.com.au/upcoming-events/testing-talks-conference-2024-melbourne?ref=annemariecharrett.com) Remember to subscribe for free to receive this newsletter and any free posts. Subscribing for $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until next time, Anne-Marie ### Is Your Quality Ecosystem Thriving? URL: https://www.annemariecharrett.com/are-you-nurturing-the-seeds-of-quality-2/ Last updated: 2024-09-04T08:05:37.000Z When cultivating a thriving team, the impact of best practices is like the soil that nourishes a garden. Just as a gardener must regularly test the soil's pH to ensure the right conditions for plants to flourish, leaders must assess the effectiveness of their teams' practices to foster a culture of quality. Without this critical step, even the most promising initiatives may fail to take root, leaving quality to wither on the vine. By measuring the impact of best practices, you provide the necessary nutrients for your team to grow, innovate, and ultimately, reach its full potential. Just as different plants in a garden require unique care, each team has distinct needs, and practices that help one team thrive might not suit another. There’s no one-size-fits-all approach to best practices. So, as a [quality champion](https://www.annemariecharrett.com/how-do-i-know-im-a-quality-coach/) or leader, how do you avoid blind spots, catch early warnings, and identify areas for improvement or even celebrate small wins? The key lies in evaluating practices holistically to ensure your team’s success. **Quality Health check* is a strategic review of quality processes within the teams to assess the quality maturity. It examines the effectiveness and benefits of these practices to ensure projects are delivered on time and with confidence.* 💡 Each team has distinct needs, and practices that help one team thrive might not suit another. There’s no one-size-fits-all approach to these practices. ## **How do we measure?** We can achieve this by conducting a simple survey that targets the relevant practices impacting quality. Just as healthy soil produces a bountiful garden, happy and safe teams consistently outperform. This survey offers a safe space for team members to share their insights, helping us understand if we’re truly cultivating an environment where quality can thrive. Additionally, it serves as a reminder of the core quality principles, allowing us to realign when necessary. This process reinforces these principles and empowers quality champions to coach effectively and catch early signs of potential issues, ensuring the ongoing health of the team’s work. Every team member, including the quality champion, participates in a self-assessment survey based on key drivers/criteria to evaluate their quality maturity. To quantify this qualitative data, a rating scale is recommended. While you can use any rating scale, ensure it is consistent across all criteria and teams. Example rating scale: *Strongly Agree = 1, Agree = 2, Neutral = 3, Disagree=4, Strongly Disagree =5* 💡 Onboarding every team to understand the purpose of this assessment is crucial. Help teams understand how it can create a platform for them to discuss what good looks to them. ### Each lens will yield a traffic light result. Green, Amber or Red based on three rules: 1. If any criteria are marked as Agree or Strongly agree, meaning it is GREEN, the team is satisfied with the current practices and understands the value they add. Whilst no specific actions are required,it should continue to be monitored 2. If any criteria are marked as Neither Agree or Disagree, meaning it is AMBER team should evaluate how to optimize that practice to improve quality, consider implementing actions to bring the metric back to green 3. If any criteria are marked as Disagree or Strongly Disagree, meaning it is RED, the team should prioritise identifying the cause and implement actions to bring the metric back to green. Actions are required to be monitored to completion > A dedicated **interactive** retro is conducted to go through the outcomes with the team and come up with an improvement plan to tackle the Ambers and the Reds. It is important to take a baseline rating first and reassess it every quarter. ## Create the criteria that are tailored to your team 💡 ****Keeping the team at the centre:** Throughout the process, the team shouldn’t feel like it's just another survey or a rating against other teams. The vision should clarify this and be something the teams own. I'm focusing on a few key drivers crucial for a team's success and the quality of their work, though there may be others worth reviewing during the process. This health check adds valuable context to existing metrics, helping us interpret them more effectively. When combined with empirical data, these insights can be used to derive quantitative results, giving a clearer picture of the team’s overall performance and areas for improvement. > " It’s important that the drivers, rating scale, and number of statements/criteria remain consistent across teams to enable group-wide reporting, even though the practices and statements may vary. " Below are some examples of drivers depending on team maturity. Each driver can have statements tailored to assess the current team’s practices and challenges. 1. **Collaborative quality efforts**: This measures the degree of collaboration between different roles within the team **Ex: Best Practice:* *Joint Sessions (Kick offs, Bug bash) Between Development, QA, and Product Teams.** Measuring the impact: Monitor the frequency and quality of collaboration in planning sessions. Improved collaboration should lead to fewer misunderstandings and higher shared quality goals. 1. **Streamlined communication**: Effective information flow is crucial to avoid defects caused by misunderstood or missed requirements. **Ex: Best Practice:* *Implementing Regular Cross-Functional Standups and Backlog Refinement Sessions* *.** Measuring the impact: Monitor the frequency and effectiveness of these meetings in reducing misunderstandings or missed requirements. A drop in requirement-related defects would indicate a positive impact. 1. **Distributed quality accountability**: This measures how dependent the team is on a dedicated QA. If the QA becomes a bottleneck, it may indicate the need for the team to become more self-reliant. **Ex: Best Practice:* *Pair Testing and Peer Reviews* *.** Measuring the impact: Track the extent to which non-QA team members participate in testing and reviews. An increase in participation should reduce the dependency on QA and improve overall quality. ## **Experience and key learnings:** Running subjective surveys every quarter provides valuable insights into team dynamics and quality practices. However, several challenges have impacted their effectiveness and led to limited improvement: 1. **Lack of transparency and false positivity**: The subjective nature of responses often results in inconsistent feedback, which can obscure clear action items. Ensuring clarity in survey questions and providing examples can help mitigate this issue. 2. **Limited engagement in retrospectives:** Surveys are most effective when coupled with actionable follow-ups, such as retrospectives. Limited engagement in these sessions can hinder the implementation of feedback. Encouraging active participation and clearly communicating the value of retrospectives can enhance their effectiveness and ensure that feedback leads to meaningful changes. 3. **Survey fatigue** Frequent surveys can lead to survey fatigue, which can cause participants to become disengaged or provide less thoughtful responses. To combat this, surveys should be concise and focused on key areas, and their frequency should be balanced with the team's capacity to provide thoughtful feedback. 4. **Manual reporting burden** The process of manually compiling and reporting survey data can be time-consuming and prone to errors. Investing in automated reporting tools can streamline this process, ensuring accuracy and saving time. Additionally, maintaining historical data in an accessible format is essential for tracking progress and making informed decisions. By addressing these challenges, teams can enhance the effectiveness of subjective surveys and ensure they contribute meaningfully to continuous improvement in quality practices. **Next steps:** By integrating qualitative insights from surveys with quantitative metrics like lead time and cycle time, teams can achieve a more holistic view of their performance and drive targeted improvements that enhance both process efficiency and overall quality. For example, improvements in team collaboration can be monitored against lead time metrics to assess whether better communication leads to faster project delivery. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/08/Screenshot-2024-08-28-at-12.23.32-PM.png) Sample Metrics > **When starting this with your team**, take the time to create criteria on a team-by-team basis, carefully considering current practices. Workshop these criteria with other quality champions across all teams to develop a consistent onboarding plan. Onboard your leadership first to secure buy-in, and work with your leads to ensure the criteria align with your quality vision. Remember, the goal is to embed quality into every facet of the development cycle, making it a shared responsibility. Why not try an [experiment](https://www.annemariecharrett.com/experiments-in-quality-coaching/)? Take these ideas to your teams, and start integrating these quality metrics and continuous improvement practices. ### Value URL: https://www.annemariecharrett.com/value/ Last updated: 2024-08-24T06:45:11.000Z [Choosing to follow joy](https://www.annemariecharrett.com/the-secret-ingredient-is-joy/) in your work doesn't mean we ignore demonstrating value. Part of any job is to do it and show that you've done it. That means making sure people understand what you are doing and why. This work requires constant communication about what you do and the impact you are having. My preference is to use videos and conversation. I commit to 1:1 meetings with key people in any company. Regularly catching up with peers and attending essential meetings are part of the work. Demonstrating value doesn't guarantee adequate recognition. Demonstrating value doesn't insulate against redundancy. However, not demonstrating value may expedite the above. So be wise. Demonstrate value. Treat it like brushing your teeth—a necessary activity to keep your teeth—no more, no less. Just don't let your worth depend on it. External [recognition](https://www.annemariecharrett.com/recognition/) is nice and can be useful, particularly if it comes with a pay rise, but internal self-worth is priceless. Fear Less You got this. ### Recognition URL: https://www.annemariecharrett.com/recognition/ Last updated: 2024-08-22T21:24:51.000Z Kind advisors flag concerns about my leadership style. They worry that I won't get the recognition I deserve if I take a path that leads to joy or use unconventional leadership methods. Recognition has been so hard fought. Why readily hand it over to others who happily claim it as their own? And I guess they're right in a way. Many benefit from my coaching and knowledge, integrating it into their work without formal acknowledgment. And why should they? Most of the time, they have no idea I've been seeding ideas and approaches for a long time. They believe the idea is theirs, so they see no reason why I should be acknowledged. I am being intentional. Without others, I cannot achieve my goals. I need these people to roll out my ideas. For that to happen, the ideas must be steal-worthy, and they must believe they are theirs. Like I said, this makes some people worry. They are concerned for me and think it's unfair that others should benefit from my experience, knowledge, and skills. But not for me. I'm doing work that brings me joy, and I'm doing it in a way that allows me to collaborate and connect, an approach that works to my strengths. The fear of not being suitably recognised is simply another distraction from my goal. It's a flavour of the other fears: scarcity and not 'being enough'. Besides, I've seen enough to know that recognition is highly subjective. I've seen people work tirelessly, achieve and exceed goals, yet not be recognised. It happens all the time in our industry. Fear Less. And Trust me, I've got this. ### Quality Coach newsletter #29 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-29/ Last updated: 2024-08-20T06:35:23.000Z ## 🥼 🧪 Experiments in Quality Coaching This month's premium article looks at experiments in quality coaching. Experiments are a safe way for a team to try out new ideas. The latest article discusses experiments, what they are, and why they're so helpful in quality coaching. I also share a story about how a team I was coaching experimented with BDD. I finish by sharing a few tips and tricks I've learned over the years around experimentation. [Experiments in Quality CoachingUse the concept of experiments to encourage product teams to try new approaches, tools and ways of working![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1517420704952-d9f39e95b43e?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDR8fGV4cGVyaW1lbnR8ZW58MHx8fHwxNzIyODM1MzE2fDA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/experiments-in-quality-coaching/) ## Other Posts I have two additional posts that explore tech leadership, Anne-Marie style. These posts are open to all. [The secret ingredient is joyLet joy be the reason you want to demonstrate value, anything less is a shallow win.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w1200/2024/08/IMG_6604.jpg)](https://www.annemariecharrett.com/the-secret-ingredient-is-joy/) [Be like mistWhen your role is an influencing one, with little direct control, focus on seeding ideas and providing options, less on making obvious impact![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1475265030331-ec191c580a5c?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDIxfHxtaXN0JTIwcml2ZXJ8ZW58MHx8fHwxNzIzNTg3ODk4fDA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/be-like-mist/) ## 🏘️ Picks from the Community There's been an explosion of writing within the community. It's fantastic to see so many talented people writing about their experiences in quality. I can't possibly include you all; this is a small subset. [CrowdStrike: The Blame Game - Cassandra HLSo, another huge IT outage occurred. This time, involving CrowdStrike. It seems like everyone and their pet tortoise has an opinion on this, so I didn’t jump in immediately. Here are some things I haven’t personally seen mentioned. Where’s Your DevOps Now? Remember when DevOps was this shiny, new thing that \[…\]![](https://i0.wp.com/www.cassandrahl.com/wp-content/uploads/2017/08/cropped-CHL-Square-Logo.png?fit=192%2C192&ssl=1)Cassandra HLCassandra H. Leung![](https://i0.wp.com/www.cassandrahl.com/wp-content/uploads/2024/07/Blue-Screen-of-Death-e1721981282956.webp?fit=860%2C210&ssl=1)](https://www.cassandrahl.com/blog/crowdstrike-the-blame-game/?ref=annemariecharrett.com) [The Swiss Cheese Model for Quality EngineeringHaving the time-honoured ‘Test Pyramid’ phenomenon drive a quality strategy alone isn’t good enough anymore. Here’s a more holistic thought…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)Slalom BuildImran Qureshi![](https://miro.medium.com/v2/resize:fit:1200/1*VGkzZ3aGZjpUmTarEo_Sqg.png)](https://medium.com/slalom-build/the-swiss-cheese-model-for-quality-engineering-ba05d26feb7e?ref=annemariecharrett.com) [https://isabelevansconsultancy.wordpress.com/2024/07/26/research-report-breaking-tester-stereotypes-who-is-testing-and-why-it-matters/](https://isabelevansconsultancy.wordpress.com/2024/07/26/research-report-breaking-tester-stereotypes-who-is-testing-and-why-it-matters/?ref=annemariecharrett.com) [Cultivating Resilience by Changing How You View Your IdentityDiscover how redefining your identity around core values rather than roles can boost your resilience and help you navigate life’s changes with greater ease.![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6dd42f5e-2d2b-4374-b7e7-2b6f1e359c5d%2Fapple-touch-icon-180x180.png)QUALITY BOSSQUALITY BOSS![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6a3602df-fb0e-4a67-ab41-c04504df5dab_1079x803.png)](https://qualityboss.substack.com/p/cultivating-resilience-by-changing) ## Upcoming speaking engagements I'm happy to announce I'm speaking at the Appium conference on the 13th of September. [The official Appium Conf 2024 for mobile & device test automationBack online. Improve your automation strategy, make connections with other Appium users and learn from Appium committers and test automation specialists.![](https://appiumconf.com/wp-content/uploads/2021/06/cropped-Appium-Conference-logo-pink-270x270.png)Appium Conf 2024![](https://appiumconf.com/wp-content/uploads/2024/07/Registrations-open.png)](https://appiumconf.com/?ref=annemariecharrett.com) [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Testing Talks Conference 2024 MelbourneWe want Testing Talks Conference 2024 to be a reunion for our community. A fun event for all; to share, learn and reconnect in-person.![](https://testing-talks-release-assets.s3.ap-southeast-2.amazonaws.com/favicon.ico)Testing Talks Conference 2024 Melbourne![](https://www.testingtalks.com.au/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRIIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--d770658c6dd09517eb820728c1c197515ca70791/tt-2024-melb-graph.png)](https://www.testingtalks.com.au/upcoming-events/testing-talks-conference-2024-melbourne?ref=annemariecharrett.com) Remember to subscribe for free to receive this newsletter and any free posts. Subscribing for $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until next time, Anne-Marie ### The secret ingredient is joy URL: https://www.annemariecharrett.com/the-secret-ingredient-is-joy/ Last updated: 2024-08-16T22:40:41.000Z What brings you joy? The gurgle of a baby's laugh? The rising sun painting clouds with gold, silver and copper? A hug from a loved one? Following curiosity and learning? We need joy in our lives. It's the secret ingredient that grounds us. With joy, it doesn't matter what people think of what we do. We won't feel the need for acceptance or feel we should demonstrate value to justify our worth. When we experience joy, all else fades into the distance. Deep down, most people know what brings them joy. Acknowledging and accepting that can be difficult. Following a path where you experience joy requires courage. It might require making choices that perhaps others and society don't understand. Being a quality professional brings me joy. I love the analytical side of disassembling systems to better understand how they operate and how they connect. This is my deep win1. It's deep because I accept and see the joy in what I do. The sheer joy of tapping into my curiosity and learning is enough. It's not always been that way. I've raged against the injustice of working in a profession often undervalued and dismissed. My career is littered with times when I've allowed my fear of rejection, of not 'being enough,' to dictate choices. It's taken a while, but I've now come to see these as shallow wins. They may bring temporary happiness, but they quickly fade as the next threat to my self-worth appears on the horizon. What's driving your wins, and are they bringing you deep joy? 1 Dr Pippa Grange - Fear Less. [‎Dare to Lead with Brené Brown: Brené with Dr. Pippa Grange on Fearing Less on Apple Podcasts‎Show Dare to Lead with Brené Brown, Ep Brené with Dr. Pippa Grange on Fearing Less - Mar 29, 2021![](https://t0.gstatic.com/faviconV2?client=SOCIAL&type=FAVICON&fallback_opts=TYPE,SIZE,URL&url=https://podcasts.apple.com/us/podcast/bren%C3%A9-with-dr-pippa-grange-on-fearing-less/id1730985049?i=1000645339116&size=128)Apple Podcasts![](https://is1-ssl.mzstatic.com/image/thumb/Podcasts112/v4/c1/44/4c/c1444cbd-40bd-8937-bf25-2b41cd81f1ad/mza_16462270625940875785.jpg/1200x630wp.png)](https://podcasts.apple.com/us/podcast/bren%C3%A9-with-dr-pippa-grange-on-fearing-less/id1730985049?i=1000645339116&ref=annemariecharrett.com) ### Be like mist URL: https://www.annemariecharrett.com/be-like-mist/ Last updated: 2024-08-13T22:33:56.000Z A large enterprise is not simply an organisation. It is an ecosystem. Like a massive river, it has its current; it ebbs, flows, divides, and merges. It has its unique fauna and flora. Over time, against its relentless flow, its banks crumble and disintegrate only to deposit it downstream in the form of silt. A large river rarely consists of one stream; it's a combination of multiple smaller streams merging into one. If your role in an organisation is to drive change with little direct influence, it's wise to remember the river and its ecosystem. It's hard to control the river. It requires huge investment to change its course and harness its power. Instead, be like mist—a mass of tiny droplets that settle like a blanket. Mist doesn't aim to change but to nurture. Over time, mist feeds and supports the flora and fauna, which in turn supports the river. The river will continue to do what it must. It will continue to ebb and flow, merge and connect, and all the while, it has been fed by mist without even realising it. ### Experiments in Quality Coaching URL: https://www.annemariecharrett.com/experiments-in-quality-coaching/ Last updated: 2024-08-06T20:59:35.000Z Experiments are powerful methods for driving change within product teams. An experiment provides the team with optionality, offering psychological safety. They can try something out, opt for the new change, or revert to working as before. Experiments permit teams to try new things without committing long-term to change. They offer change without removing team agency; at all times, the team decides. ## What is an experiment? An experiment is a procedure or operation carried out to resolve an uncertainty1. For an experiment, you form a hypothesis upon which experiments are designed and then run to see if that hypothesis is true. As a quality coach, you can suggest to a team that they try a new idea or concept as an experiment. It is even better if the team comes to you with a suggestion. The team can then try the idea; if it works, they can absorb it into their working methods. ## Learning opportunities Experiments can pass or fail. Failure is data that suggests the hypothesis is untrue, that assumptions are incorrect or that there are unknowns to uncover. The failure of an experiment is not a failure of the team, the quality coach, or even the proposal put forward. Viewing experiments as learning opportunities, rather than an admission of fault, encourages a team to keep evolving and experimenting within the problem space. Failure offers the opportunity to better understand the problem at hand and then make informed decisions about how to modify your assumptions about the problem and the solution, modify your approach and perhaps perform another experiment. ## Dealing with Time Constraints Teams manage and absorb much change as part of their daily work. Keeping a local machine 'clean' requires constant updating and upgrading. Engineering teams do a significant amount of housekeeping. They maintain CICD pipelines, libraries, and frameworks and sometimes test data and test environments. A software engineer once told me that a good day's work is if you can write code for three hours! With this amount of change, it's understandable for a team to be reluctant to try something new. This is especially true if a concept or tool doesn't appear to solve a team problem. But maybe a small experiment might be achievable. This is the beauty of experimentation. With a small investment, a team can opt out of long-term implementation if the value is nonexistent. ## Scaling Experimentation One concern I often hear from senior leadership is that the experimentation approach doesn't scale when you want to drive change across large enterprise organisations, which requires consistency of approach and adoption. Rather than focusing on process, I encourage focusing on the behaviours of continuous learning and problem-solving, as we know these traits are useful for organisations to respond effectively to market demand. Encouraging an experimentation mindset is one of many levers a company can use to adopt this mentality. If you are interested in driving systematic change using experimentation, read Neil Younger's articles on building an engineering framework around capability and growth. [Boost your engineering capability with this growth-focused frameworkℹ️In this article, we will use the term ‘Engineering Capability’ to mean the practices and approaches we use to get work done within an engineering department. This article extends and references the work of two previous publications in this series. Namely ’Accelerate your quality culture by identifying your engineering![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettNeil Younger![](https://images.unsplash.com/photo-1516880711640-ef7db81be3e1?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDY0fHx0ZWFtfGVufDB8fHx8MTY5MTkzMDA0MHww&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/engineering-capability-model/) [Build a culture of learning by amplifying team winsNeil Younger talks about amplifying success to drive change in this latest quality coach book article![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettNeil Younger![](https://images.unsplash.com/photo-1578269174936-2709b6aeb913?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDN8fHdpbm5pbmd8ZW58MHx8fHwxNjgwMDA5NTA4&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/) ## Case Study on Experimentation A team once approached me to experiment to trial Behaviour Driven Development (BDD). They hypothesised that this would provide certainty at the user story level. They already used TDD and felt that BDD would take their automation to the next level. like the concept of BDD, but teams often ignore the value-added bits, such as example mapping and jump straight into test automation. I was reluctant, but the team was enthusiastic and wanted to try it out. Since being responsible for quality means teams have agency over decisions on quality, the team opted to perform it as an experiment. They decided to try out BDD for three months. They held workshops and analysed the stories, breaking them into the Given, When, Then format, making it easy to use Gherkin and Cucumber scripts to automate the behaviours. Three months rolled by, and it was time to make a call. The team almost unanimously agreed that the approach was a lot of additional work for little value added. Their context was financial back-end transactions, and they found it hard to apply the user-centric approach that BDD encouraged. They opted to drop BDD and continue using a mix of Test-Driven Development (TDD) and Contract Testing, which offered sufficient test coverage. Not everyone agreed. The one person who wanted to keep BDD was the software tester! ## Considerations As a method, experiments are powerful ways to encourage change, but be careful how and when you use them. Here are some guidelines: - The team must have agency when and if to implement an experiment. - The experiment should solve a problem that matters to them rather than what you, as a quality coach, think the team needs to solve. - Frame any experiment as an opportunity to learn and understand something new about the context. What did the team learn if the problem still exists, and what might they try next? - Keep experiments small and simple. - Avoid making decisions about the next steps until the experiment has been completed. - Be clear about how success will be measured and what it might look like, whether that's quantitative, qualitative, or both. - Teams differ in their openness to experiment; if you are trying to drive systematic change, try to find a team that a) has the time and b) is open to trying new things. What will you try as an experiment? ## References 1 [https://www.merriam-webster.com/thesaurus/experiment](https://www.merriam-webster.com/thesaurus/experiment?ref=annemariecharrett.com) ### 💃Quality Coach newsletter #28 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-28/ Last updated: 2024-07-14T02:44:11.000Z ## 💃 Decoding the Dance: Customer Value & Quality There are times in our world of work when we encounter paradigm shifts in our thinking. I remember the first time I worked in a proper agile environment and finally getting that agile is not just another context in which testing is performed; it actually changes the risk profile, which impacts what and how we test. I believe product discovery and SaaS require another paradigm shift. We must change and morph how we think about quality, risk, and scope. This article is my attempt to discuss why this change is important, how it will impact, and how it relates to what you can do using a prevent, detect, and recover strategy. I hope you find it useful or at least thought-provoking. [Decoding the Dance: Customer Value Meets QualityI suggest we begin exploring different ways to think about quality. Let’s take a step back and critique our existing assumptions on quality. If we question what we accept as truth in testing, we may begin to identify new ways of achieving quality products that our customers really value.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1616696268023-d58ce531bafc?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDE5fHxkdWV0fGVufDB8fHx8MTcyMDEyODgyM3ww&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/decoding-the-dance-customer-value-meets-quality/) ## Related Posts [Reshaping Quality in Contemporary OrganisationsTo test well we need to rethink quality and how we can build quality in as opposed to testing for it at the end.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w1200/2021/06/QEModelv3-2.jpg)](https://www.annemariecharrett.com/contemporary-quality-engineering/) [Product Excellence - Continuous Quality from Discovery to SupportOverview Introducing Product Excellence, a new framework that creates a single view of quality across discovery and delivery. Delivering small batches of customer value in isolation comes with a cost. As a strategy for risk reduction, it wins hands down. It can come up short as a strategy for delivering![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/02/Product-Exellence-by-Anne-Marie-Charrett-1-1.jpg)](https://www.annemariecharrett.com/product-excellence-continuous-quality-from-discovery-to-support/) [What is Observability? What is Qualtability?Observability allows vision of the internals of a system without interference with that system. Qualtability makes visible the state of quality.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1450084195263-9a8b47617097?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDIwfHxvYnNlcnZlfGVufDB8fHx8MTYyMzkwNzM1Mw&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/observability-meet-qualtability/) ## 🏘️ Picks from the Community This is a round-up from the community. There are so many excellent posts at the moment, and these are only some of them. [Nice versus KindA video that explains the difference between being nice and being kind.![](https://curiousduck.io/assets/images/favicon/favicon.png)Curious Duck - Elisabeth Hendrickson LogoElisabeth Hendrickson CEO / Founder, Curious Duck![](https://curiousduck.io/assets/images/gen/blog/2024-07-11-nice-v-kind.jpg)](https://curiousduck.io/posts/collections/2024-07-11-nice-vs-kind/?ref=annemariecharrett.com) [Test Automation - Friend or Foe?Ideas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Friend or Foe?Maaret Pyhäjärvi![](https://resources.blogblog.com/img/icon18_edit_allbkg.gif)](https://visible-quality.blogspot.com/2024/07/test-automation-friend-or-foe.html?ref=annemariecharrett.com) [Last Call for QualityA look at why late testing fails and how to avoid this and common software testing anti-patterns.![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6dd42f5e-2d2b-4374-b7e7-2b6f1e359c5d%2Fapple-touch-icon-180x180.png)QUALITY BOSSBrie Ransom![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1c1a1c24-0964-4feb-b9a5-b25c305b5f4d_1000x1000.png)](https://qualityboss.substack.com/p/last-call-for-quality) [Flurry of bugsRecently I was doing some exploration around an area of a product. I didn’t have any specification or knowledge of the product, so it was…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumMelissa Fisher![](https://miro.medium.com/v2/1*kFrc4tBFM_tCis-2Ic87WA.png)](https://fishouthebox.medium.com/flurry-of-bugs-95dd10c7dba8?ref=annemariecharrett.com) [Good Enough Quality Is Taking a DipIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://resources.blogblog.com/img/icon18_edit_allbkg.gif)](https://visible-quality.blogspot.com/2024/06/good-enough-quality-is-taking-dip.html?ref=annemariecharrett.com) [✅ Quick Tip: Squashing CommitsAh, Github. Mostly, I feel good about it… I know the basics and use them frequently. Recently, I learned how to squash commits. And, for whatever reason, I cannot recall the commands quickly. Here’s my guide to running the commands for squashing commits.![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe132144b-f5e5-48fc-9fbb-352173a4ecaa%2Fapple-touch-icon-180x180.png)Failure is FeedbackJudy Mosley![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1c43b3fc-11ef-4d41-a972-dd01dd66b424_480x360.gif)](https://failureisfeedback.substack.com/p/quick-tip-squashing-commits) [Marit van Dijk on LinkedIn: Tips For Reading CodeAs developers, we spend more time reading code than writing it. Most of the time, we are reading code in our IDE - which provides useful features like syntax…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInMarit van Dijk![](https://media.licdn.com/dms/image/sync/D4E27AQEr6hMRKfFDcA/articleshare-shrink_800/0/1711282680368?e=2147483647&v=beta&t=eMO9qZwAUj3zPgRRrrS6bl7eAdeEbMIki1uo_8PNHWY)](https://www.linkedin.com/feed/update/urn:li:activity:7161372731865788416?updateEntityUrn=urn%3Ali%3Afs%5FupdateV2%3A%28urn%3Ali%3Aactivity%3A7161372731865788416%2CFEED%5FDETAIL%2CEMPTY%2CDEFAULT%2Cfalse%29&lipi=urn%3Ali%3Apage%3Ad%5Fflagship3%5Fmyitems%5Fsavedposts%3Bidx%2BTUqqS9iCAGrSf3D8iA%3D%3D&ref=annemariecharrett.com) ## Upcoming speaking engagements [Agile & Quality; Is quality \*really\* everyone’s responsibility?, Wed, Jul 24, 2024, 5:45 PM | Meetup\*\*Agile Quality - Is quality really everyone’s responsibility?\*\* \[Ann Marie-Charret\](https://www.linkedin.com/in/testingtimes/) In Agile, quality is a shared responsibility![](https://secure.meetupstatic.com/next/images/general/m_swarm_196x196.png)Meetup![](https://secure.meetupstatic.com/photos/event/c/e/600_518820206.jpeg)](https://www.meetup.com/scrum-12/events/298892061/?ref=annemariecharrett.com) [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Testing Talks Conference 2024 MelbourneWe want Testing Talks Conference 2024 to be a reunion for our community. A fun event for all; to share, learn and reconnect in-person.![](https://testing-talks-release-assets.s3.ap-southeast-2.amazonaws.com/favicon.ico)Testing Talks Conference 2024 Melbourne![](https://www.testingtalks.com.au/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRIIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--d770658c6dd09517eb820728c1c197515ca70791/tt-2024-melb-graph.png)](https://www.testingtalks.com.au/upcoming-events/testing-talks-conference-2024-melbourne?ref=annemariecharrett.com) Remember to subscribe for free to receive this newsletter and any free posts. Subscribing for $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until next time, Anne-Marie ### Decoding the Dance: Customer Value Meets Quality URL: https://www.annemariecharrett.com/decoding-the-dance-customer-value-meets-quality/ Last updated: 2024-07-08T09:52:28.000Z ## The voice of the customer Even before I started in this industry, there's been an interplay between customer value and quality—Juran's 1962 2nd edition of the Handbook of Quality talks about the interplay between the two. ![Juran 1962 Quality of Control Chapter 1- page 9 Quality of Design (What we now call business value) and Quality of Conformance (What we typically call product quality)](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/07/Screenshot-2024-07-05-at-9.34.04-am.png) Juran 1962 Quality of Control Chapter 1- page 9 Quality of Design (What we now call business value) and Quality of Conformance (What we typically call product quality) In software engineering, quality typically means 'product quality'. When quality professionals describe their role, it's often to be a 'voice of the customer' providing that perspective to the rest of the team. Jerry Weinberg, the doyen of software testing1, defined quality as "value to some person". Value and quality are intrinsically linked and sometimes mean the same thing. The current elevation of product discovery in our software product lifecycle, particularly in SaaS, means we must explore this relationship again. How does an emphasis on innovation of customer value impact our understanding of quality? ## Discovering Customer Value What exactly is product discovery, and how does it interact with product delivery? Product discovery is an exploration of the problem space to discover customer value. Product discovery investigates the problem space to identify hypotheses on potential customer value. We only know if these hypotheses are correct once we deliver that value to our customers. Product delivery is that medium. The process of designing, building, releasing and maintaining software allows us to know for sure if business value is delivered. It's not unfamiliar territory for most of us. Many say quality is "building the right thing and building the thing right"3. We've previously treated these two phases as entirely separate entities. We look at the quality of discovery independent of the quality of delivery. In SaaS, we can't do that because the success of product discovery is dependent on the speed of product delivery. In fact, for some, dev velocity is a proxy for innovation5. ## Building the right thing over building it right Failing to build the right thing is more important than failing to build the thing right. If we make a product that nobody wants, how perfectly it works is irrelevant. Building a desirable product means how it works will matter more. That means if a tradeoff between the two is required, the ability to innovate customer value matters more than the ability to deliver a perfect product. That tradeoff exists and is called "speed to market". Because customer value is constantly changing, morphing, and evolving, the ability to quickly iterate and test assumptions on customer value is critical. This is not great news for quality in the delivery space, where time is already the enemy of quality4\. It could potentially impact the ability to test for product quality well. Do we accept this tradeoff, or can we identify new ways to ensure quality that perhaps look beyond software testing? ## SaaS value triangle My definition of quality for SaaS models is: > Quality is how fast we deliver customer value, how stable and constant that customer value is in production6 In short: Quality = throughput + stability7 \+ availability ![Three vertices of value in SaaS by Anne-Marie Charrett 2024](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/07/image-1.png) Three vertices of value in SaaS Like the iron triangle, these factors have a relationship: 1. The value of work relies on stability, availability and throughput. 2. A product team or quality professional can trade between the elements. 3. Changes in one quality characteristic necessitate changes in others to compensate, or value will suffer. Reduce time and quality increases? Strange days indeed. I would argue that this definition of quality is closer to how senior engineering stakeholders perceive it. Time will tell if this model holds. For now, it's more speculation than theory. My question to you all is: How might your thoughts on quality change if this is true? ## Diversity in your Quality Strategy The unfortunate reality is that software testing is a time-intensive activity. Designing, creating, executing, reporting, and maintaining software testing artifacts takes time. We do these time-consuming activities until companies have seen their value. Software testing allows companies to reduce the risk of failure in production. Suppose another method of reducing the risk of failure in production were available, one that was less time-intensive yet allowed for a similar state of quality. I do not doubt that companies would explore that. Instead of depending on software testing as the only means to identify the quality state, we look at other techniques and approaches. A diverse quality strategy not only reduces dependency on software testing, but as a strategy in itself, it reduces the risk of overreliance on one approach. Check out my [Prevent, Detect, Recover](https://www.annemariecharrett.com/prevent-detect-recover/) article for ideas on creating a diverse quality strategy. ## New Quality Attributes And throwing this in, if you agree that the definition of quality has changed, doesn't that mean we need to relook at the quality characteristics, too? My potential new set of quality attributes is: - stability7 - availability - throughput - usability - accessibility - observability - [qualtability ](https://www.annemariecharrett.com/observability-meet-qualtability/) - security - scalability - serviceability8 ## In conclusion I suggest we begin exploring different ways to think about quality. Let's take a step back and critique our existing assumptions on quality. If we question what we accept as truth in testing, we may identify new ways of achieving quality products that our customers value. ## References 1 Read [Perfect Software by Jerry](https://leanpub.com/perfectsoftware?ref=annemariecharrett.com) an excellent book on software testing 2 Teresa Torres's excellent book "[Continuous Discovery Habits](https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?ref=annemariecharrett.com)" and [her website](https://www.producttalk.org/?ref=annemariecharrett.com) are a good place to start understanding the product discovery space. 3 [My article on product excellence](https://www.annemariecharrett.com/product-excellence-continuous-quality-from-discovery-to-support/) provides an overview of this 4At least, that's what the[ iron triangle](https://en.wikipedia.org/wiki/Project%5Fmanagement%5Ftriangle?ref=annemariecharrett.com) tells us. 5 Read [this article by Blameless](https://www.blameless.com/the-comprehensive-guide-on-slis-slos-and-error-budgets?ref=annemariecharrett.com) on how a proxy of discovery is the speed of delivery. 6 This definition is heavily influenced by [Accelerate](https://www.amazon.com.au/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339?ref=annemariecharrett.com) and [the 2018 State of Devops paper. ](https://services.google.com/fh/files/misc/state-of-devops-2018.pdf?ref=annemariecharrett.com) 7 [Stability](https://dora.dev/publications/pdf/state-of-devops-2016.pdf?ref=annemariecharrett.com) is another word for functional correctness and is measured by MTTR and Change Failure Rate 8 Serviceability is how easy or hard it is for others to use your service. For example, is it easy to pick up and use an API? ### 💰Quality Coach newsletter #27 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-27/ Last updated: 2024-06-13T13:17:59.000Z ## 💰The cost of change Framing change in the language of business can be an effective way to communicate strategy to business stakeholders and senior management. And there's nothing like talking money to get their attention. Boehm knew this and used this language in the 1980s when he explored the cost of change that occurred in the software development lifecycle. He collated empirical data to suggest that the cost of a defect increased significantly the further along the lifecycle it took place. For fans of Demming and Crosby, the cost-of-change model communicated the value of a "build quality in" strategy. That is, design and build with quality in mind, and it will cost you less. In the 2000s, Kent Beck hypothesised how extreme programming altered that curve, turning it from an exponential curve to a flatter one. What about now, though? What might this curve look like in 2024? In this [premium post](https://www.annemariecharrett.com/cost-of-change-in-saas/), I look at how the curve might look considering a SaaS model that uses technologies such as cloud computing, microservices, monitoring & alerting and distributed tracing. In particular, I explore the cost of large pre-production test environments and question if they continue to hold the value they did in the past. [Cost of Change in SaaSBoehm’s cost of change model has changed over the years. This article looks at the cost of change in SaaS and how it has changed the curve once again.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/06/Cost-of-Change--11-.png)](https://www.annemariecharrett.com/cost-of-change-in-saas/) Of course, I can't discuss this topic without acknowledging the concerns such a model raises. Yes, the studies are flawed, and it is true that there are contexts where defects are cheaper left, but that doesn't mean the model is without merit. In the article, I provide links to these discussions. Me? I find the model useful as a means of holding a conversation with senior business people whose major priority is not just quality; it's running a profitable business. ## 🏘️ Picks from the Community First up, I had a delightful conversation with [Bryan Jones ](https://www.linkedin.com/in/bryan-jones-mbcs-96953/?ref=annemariecharrett.com)on his [podcast Quality Blether ](https://embed.acast.com/$/63f8efe89cef06001133e36b/6661b9c5f688a100124878d8??ref=annemariecharrett.com)Vernon Next up are Vernon Richards, Sanne Visser and Chris Chant talking about quality coaching. Ashley Graf talks about heuristics to use to identify risk in legal documentation. [Heuristics for identifying legal (documentation) risks as a QA\[This article is not a substitute for professional legal advice. This article does not create an…![](https://media.dev.to/cdn-cgi/image/width=180,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8j7kvp660rqzt99zui8e.png)DEV Communityashleygraf\_![](https://media.dev.to/cdn-cgi/image/width=1000,height=500,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F9efc11l527m17c4m6hqt.png)](https://dev.to/ashleygraf%5F/heuristics-for-identifying-legal-documentation-risks-as-a-qa-dl7?ref=annemariecharrett.com) Allison Lazarz talks about the cost of logging and the impact on sustainability [Digital Clean Up: This. Is. How. | Agile AllianceAgile Sustainability Initiative Digital Clean Up: This. Is. How. Key takeaways Reducing (or setting) log retention policies is a great way to reduce unnecessary data storage Reducing data storage reduces carbon emissions Reducing data storage saves money! Some context As Agile practitioners, we aim to minimize waste. How does this align with the global sustainability![](https://www.agilealliance.org/wp-content/uploads/2021/12/agile-alliance-logo-icon-300x300.png)Agile Alliance |Heather Younger![](https://www.agilealliance.org/wp-content/uploads/2023/08/agile-sustainability-initiative-featured.jpg)](https://www.agilealliance.org/digital-clean-up-this-is-how/?ref=annemariecharrett.com) Nice experience report from Arlene Andrews testing dropdown values [Drop-down values for injectionLearning in public is grand, and when you have a team that is willing to help with something that…![](https://media.dev.to/cdn-cgi/image/width=180,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8j7kvp660rqzt99zui8e.png)DEV CommunityArlene Andrews![](https://media.dev.to/cdn-cgi/image/width=1000,height=500,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fadc9p3lhndiaykyr323w.png)](https://dev.to/arleneandrews/drop-down-values-for-injection-151k?ref=annemariecharrett.com) ## Upcoming speaking engagements [Agile & Quality; Is quality \*really\* everyone’s responsibility?, Wed, Jul 24, 2024, 5:45 PM | Meetup\*\*Agile Quality - Is quality really everyone’s responsibility?\*\* \[Ann Marie-Charret\](https://www.linkedin.com/in/testingtimes/) In Agile, quality is a shared responsibility![](https://secure.meetupstatic.com/next/images/general/m_swarm_196x196.png)Meetup![](https://secure.meetupstatic.com/photos/event/c/e/600_518820206.jpeg)](https://www.meetup.com/scrum-12/events/298892061/?ref=annemariecharrett.com) [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Testing Talks Conference 2024 MelbourneWe want Testing Talks Conference 2024 to be a reunion for our community. A fun event for all; to share, learn and reconnect in-person.![](https://testing-talks-release-assets.s3.ap-southeast-2.amazonaws.com/favicon.ico)Testing Talks Conference 2024 Melbourne![](https://www.testingtalks.com.au/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRIIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--d770658c6dd09517eb820728c1c197515ca70791/tt-2024-melb-graph.png)](https://www.testingtalks.com.au/upcoming-events/testing-talks-conference-2024-melbourne?ref=annemariecharrett.com) Remember to subscribe for free to receive this newsletter and any free posts. Subscribing for $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until next time, Anne-Marie ### Cost of Change in SaaS URL: https://www.annemariecharrett.com/cost-of-change-in-saas/ Last updated: 2026-04-22T00:40:47.000Z ## A history of the cost of change. In the 1970s, Dr Barry Boehm hypothesised that the longer it takes to find a defect, the more expensive it is to fix it1. [![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/06/costofchangeboehm.jpeg)](https://paulhammant.com/2012/11/01/testability-and-cost-of-change/?ref=annemariecharrett.com) Boehm’s logarithmic non-curve Following on, the agile & XP community hypothesised that agile & XP practices would flatten this curve as smaller batch sizes and agile practices offered faster feedback loops. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/06/Cost-of-Change--6-.png) There's been much debate about the accuracy and validity of the 'cost of change' model1. An [interesting research paper](https://www.researchgate.net/publication/308264787%5FAre%5FDelayed%5FIssues%5FHarder%5Fto%5FResolve%5FRevisiting%5FCost-to-Fix%5Fof%5FDefects%5Fthroughout%5Fthe%5FLifecycle?ref=annemariecharrett.com) on 171 software projects between 2006 and 2014 finds no credence to the hypothesis that finding defects early increases software engineering effort, suggesting that agile and new technologies have flattened the curve. However, cost and effort are not always the same thing. Effort is only part of the picture. Other costs exist. For example, the test environments where defects are found also have a not-so-insignificant cost that we must also consider in the cost of change model. ### Cost of Change in SaaS In SaaS products, while delivering product quality is important, there's the knowledge and comfort that defects in production can be found and fixed far more rapidly than previously. With good monitoring and alerting, this additional safety net allows product discovery to continue innovating to determine customer value. This impacts the cost of change model, as the cost of change in production is reduced. The next sections explore the rise of recoverability, the impact of big data, and security threats on the cost of change models in SaaS products. Buy the quality coach's handbook [![CTA Image](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2026/04/qualitycoachbook.svg.png)](https://leanpub.com/qc/c/40?ref=annemariecharrett.com) Buy the Quality Coach book on [Leanpub](https://leanpub.com/qc?ref=annemariecharrett.com) (ebook) or [Amazon](https://a.co/d/0jFdKyz?ref=annemariecharrett.com) (for hardback or paperback) [40% Discount on Ebook - all languages ](https://leanpub.com/qc/c/40?ref=annemariecharrett.com) ## The rise of recoverability As I said, good monitoring and alerting in production allow for faster recovery of any detected failure. Distributed tracing increases observability, aiding recoverability to the point where a customer is unaware that a defect ever existed. Instead of considering rolling out a fix to multiple client environments, a SaaS company has only to consider their own production environment. This reduces the need to test and deploy on multiple operating systems and hardware environments, reducing the scope of testing and the complexity of releases. Canary releases reduce the impact of failure, lowering the risk of failure and making it safer to deploy with less exhaustive testing. The combined impact of SaaS, recoverability, observability, testing in production, and staggered releases reduces the cost of change in production and makes it safer to consider. This new safety net is why we can begin to consider reduced dependency on production-like test environments, which continue to rise in cost. ## The Rise of Big Data In SaaS, data is king, queen and knave. This is not just because companies rely on data analytics to improve customer experience and derive customer insights but also because metadata is a commodity on its own. Owning and maintaining data is a commodity of its own. It's incredibly valuable in AI, with LLMs relying on datasets to train their models. Securely storing current and historical production data with suitable redundancy is expensive. So much so that FinOps as a practice has emerged to help maximise the business value of cloud computing. However, this is problematic for traditional software testing practices that advocate testing should be performed in test environments that mimic as closely as possible production environments. As the amount of data increases, so does the cost. Can a software testing strategy justify the cost of testing in these large environments when, as we've seen, it may be cheaper to rely on recoverability in production? ## Increased security concerns It's not only the cost of these environments that we need to consider. It's the threat test environments pose to a company's reputation if a test environment is breached and customer data is stolen. Test environments are often targets for security attacks. This is because test environments typically don't have the same stringent policies as production environments. To reduce the risk of security breaches, test data is often masked and obfuscated, preventing customer data from being viewed and increasing the cost of managing and maintaining the test environments. ## A New Cost of Change Curve In summary, the cost of change in production has reduced, while the cost of software testing in pre-prod test environments has increased. And companies are starting to take note. In a recent company, one of the major strategies I was asked to drive was to reduce the dependency on systems integration test environments. I believe this trend will continue to increase as more and more companies question the value of these heavy pre-production environments when, arguably, testing in production is becoming safer and is a better reflection of what the customer is experiencing. Perhaps an aspirational SaaS model is one in which we attempt to make the [cost of change linear](https://www.annemariecharrett.com/contemporary-quality-engineering/). That is, we choose activities that offer the best value based on a risk cost analysis. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/06/Cost-of-Change--10--1.png) ### Reducing Dependency on pre-production environments As quality professionals, we need to begin exploring approaches that enable us to perform good testing without being dependent on production-like environments. Thinking critically through what quality is, the threats to quality and the strategies we can adopt to mitigate threats to quality will help us develop an approach that reduces dependency on these SIT (Systems Integration Testing) environments. And there's much to look to for guidance. A good start is the [prevent, detect and recover ](https://www.annemariecharrett.com/prevent-detect-recover/)strategy that encourages us to think about approaches beyond testing and into prevention and recoverability can help us broaden and redistribute the risk of product failure. ### SIT or NO SIT, you decide. We don't perform software testing in isolation. In all of my work, I try hard to provide a balanced viewpoint that considers software testing and quality as part of product delivery. It's one of the reasons I work hard to understand the context and people's perspectives; in this article, the world is SaaS, and the people are senior engineering leaders such as VPs and CTOs. But, like anything, we must be prepared to back ourselves and what we believe offers the most appropriate strategy for our product and our company. If you fundamentally believe that having a production-like environment is in the best interests of your company, be prepared to advocate for that. Cost alone is not a justification for retiring these environments. Make sure you provide evidence-based data that substantiates your reasons. Knowing what others may be thinking will help you develop a solid strategy that justifies your reasoning. Good Luck! ### 1 *Sacred Cows* It's probably blasphemy to say that regardless of its accuracy, the cost of change model is a valuable tool when discussing quality strategies with senior leadership. But for blasphemy to exist, we must first believe in a sacred cow, and to be honest, software engineering isn't the type of profession that lends itself to sacred anything. We try things, and if they work, we continue to use them until they no longer work. I find there's enough common sense in the cost of change model to make it useful as long as I treat it as a heuristic. I get that this isn't everyone's viewpoint, and some people would rather pluck their eyes out before mentioning its existence. I'll continue to use it as it has served me well. If you wish to research the cost of the 'cost of change' model, here are some articles [Testability and Cost of ChangePaul Hammant's blogPaul Hammant![](https://paulhammant.com/images/bb_c_of_c.jpg)](https://paulhammant.com/2012/11/01/testability-and-cost-of-change/?ref=annemariecharrett.com) [The Real Cost of Change in Software Development - DZoneThere are two widely opposed (and often misunderstood) positions on how expensive it can be to change or fix software once it has been designed, coded, tested…![](https://dz2cdn1.dzone.com/themes/dz20/images/favicon.png)DZoneJim Bird![](https://dzone.com/themes/dz20/images/ArticleImg_10.jpg)](https://dzone.com/articles/real-cost-change-software?ref=annemariecharrett.com) [What Does It Really Cost to Fix a Software Defect?Bonnie Bailey writes that confirmation bias leads us to throw out the critical thinking needed to determine if the “average cost to fix one defect” metric, which is what we really have to figure out to get the data points for the Boehm curve, is really even a valid metric in the first place.![](https://www.techwell.com/sites/default/themes/techwell/favicon.ico)TechWellBonnie Bailey![](https://www.techwell.com/sites/default/files/stories/images/cropped_teasers/Jonathan%20Vanian/2013/thumb-print-1-1231735-m_1.jpg)](https://www.techwell.com/techwell-insights/2013/10/what-does-it-really-cost-fix-software-defect?ref=annemariecharrett.com) [https://www.researchgate.net/publication/308264787\_Are\_Delayed\_Issues\_Harder\_to\_Resolve\_Revisiting\_Cost-to-Fix\_of\_Defects\_throughout\_the\_Lifecycle](https://www.researchgate.net/publication/308264787%5FAre%5FDelayed%5FIssues%5FHarder%5Fto%5FResolve%5FRevisiting%5FCost-to-Fix%5Fof%5FDefects%5Fthroughout%5Fthe%5FLifecycle?ref=annemariecharrett.com) ### 🔭 Quality Coach newsletter #26 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-26/ Last updated: 2024-05-16T21:34:34.000Z ## 🔭 Tails don't wag dogs do Knowing what you can and can't control helps manage expectations. Over time, you can look for ways to incorporate some of these factors into your circle of influence. This article includes a download to help you determine what you can and can't control with your work. This is a helpful starting point for any conversation around accountability with your manager or other people in the organisation. [Tails don’t wag, dogs doKnowing what you can and can’t control helps manage expectations. Over time, you can look for ways to incorporate some of these factors into your circle of influence.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w1200/2024/05/bear-1.png)](https://www.annemariecharrett.com/tails-dont-wag-dogs-do/) ## 🏘️ Picks from the Community There are so many fantastic articles to share this month. Here's some of them: [Quality Coaching – Encouraging TestabilityAs an Agile Quality Coach, I focus on enabling teams to take ownership of the quality of their software. One of the ways I do this is by encouraging teams to consider the testability of their softw…![](https://marianneduijst.nl/wp-content/uploads/2016/10/cropped-Marianne_Duijst-270x270.jpg)Marianne DuijstMarianne Duijst![](https://marianneduijst.nl/wp-content/uploads/2024/03/Marianne-Duijst-Quality-Coaching-Testability-Sketchnote.jpg)](https://marianneduijst.nl/2024/04/22/quality-coaching-encouraging-testability/?ref=annemariecharrett.com) [Making Releases RoutineIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfVdW7yk8misvFy52tZ99rTKao7OzjS-EjnXSuk-q_TXlarhP4pWVaRgcnGUZ-nhvm32nEGdJPojXHMJuo9vlwcy0kh2z75m5os0KZ8QWiXzsKNi-2MVUfdjTxSn4hTXdOZg1ufwHMarKStaSbeZ5iDHTN8zow3xWLj7ChESD7Ui7Lm_8AuIGN1q3GlQ/w1200-h630-p-k-no-nu/Screenshot%202024-02-14%20at%2021.10.36.png)](https://visible-quality.blogspot.com/2024/02/making-releases-routine.html?ref=annemariecharrett.com) [Three Ingredients for Tasty Platform CapabilitiesLast week, Manuel Pais and Laura Tacho discussing platform success they said: Figure out what your company cares about.How to Structure Your Platform Team What the company cares about is the impact…![](https://unremarkabletester.com/wp-content/uploads/2021/01/cropped-transparent-logo-1-1.png?w=192)More Questions Than AnswersAreti Panou![](https://unremarkabletester.com/wp-content/uploads/2024/05/img_20230930_102313874.jpg?w=1200)](https://unremarkabletester.com/2024/05/01/three-ingredients-for-tasty-platform-capabilities/?ref=annemariecharrett.com) [Risks on data ProjectsI’ve been working on a data programme and one of the things is the different lense on how you think about the impact to the customer. In…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumMelissa Fisher![](https://miro.medium.com/v2/1*kFrc4tBFM_tCis-2Ic87WA.png)](https://fishouthebox.medium.com/risks-on-data-projects-413ffbb62cc0?ref=annemariecharrett.com) ## Upcoming speaking engagements [Agile & Quality; Is quality \*really\* everyone’s responsibility?, Wed, Jul 24, 2024, 5:45 PM | Meetup\*\*Agile Quality - Is quality really everyone’s responsibility?\*\* \[Ann Marie-Charret\](https://www.linkedin.com/in/testingtimes/) In Agile, quality is a shared responsibility![](https://secure.meetupstatic.com/next/images/general/m_swarm_196x196.png)Meetup![](https://secure.meetupstatic.com/photos/event/c/e/600_518820206.jpeg)](https://www.meetup.com/scrum-12/events/298892061/?ref=annemariecharrett.com) [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Testing Talks Conference 2024 MelbourneWe want Testing Talks Conference 2024 to be a reunion for our community. A fun event for all; to share, learn and reconnect in-person.![](https://testing-talks-release-assets.s3.ap-southeast-2.amazonaws.com/favicon.ico)Testing Talks Conference 2024 Melbourne![](https://www.testingtalks.com.au/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRIIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--d770658c6dd09517eb820728c1c197515ca70791/tt-2024-melb-graph.png)](https://www.testingtalks.com.au/upcoming-events/testing-talks-conference-2024-melbourne?ref=annemariecharrett.com) Remember to subscribe for free to receive this newsletter and any free posts. Subscribing for $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until next time, Anne-Marie ### Tails don't wag, dogs do URL: https://www.annemariecharrett.com/tails-dont-wag-dogs-do/ Last updated: 2024-05-08T09:02:31.000Z Asking the testing department to shift left or improve quality is like asking a dog's tail to be responsible for wagging. While tails do an excellent job of the mechanics of wagging, it's a dog's brain that controls the activity. In the same way, software testing is fundamentally an activity constrained and resourced by product owners and engineering leadership. Software testing rarely wags its tail for its own delight and instead serves a purpose dictated by others. ## Quality at senior leadership This is why it is so important that there are advocates for quality at the leadership level. People who can explain the how and the way of software testing. People who can advocate for more time, budget, and engineering ownership. This person can have any title or role, but the more senior, the better. For instance, they could be a product owner or head of engineering. In some cases, it's a senior quality professional who performs this role—someone who is on par with other senior engineering leaders. It doesn't have to be; it could be engineering or product leaders who are passionate and understand the nuances of quality beyond "automate all the things". ## Leaders must own Quality too Unfortunately, I frequently see companies putting the responsibility on team-level Quality Coaches to somehow improve quality with little support from engineering. While they agree to the concept that everyone owns quality, it somehow seems to escape them that they, too, must stump up and show the importance of quality through action. Instead, quality coaches are faced with the almost impossible task of improving quality within a team with little or no support from engineering and product leadership and constraints a quality coach has no control over. Teams incentivised to deliver features regardless of quality are not going to suddenly want to slow down to improve their unit test coverage. Teams with little agency over their time and choice of activity are simply unable to take on new work no matter how passionate they are about quality. It doesn't have to be this way, though. Engineering leadership need to recognise the gap in their skillset and either fill it or hire a senior quality person to help coach them on what is required. I feel one of the key roles of a senior quality professional is giving senior engineering and product leadership the necessary information to make informed choices about how much and where to invest in quality. ## Focus on what you can control This doesn't mean that as a quality coach, you should give up trying to impact and improve how teams think about quality. There's lots of value in working with teams, and there's always something that can be done, be it more exploratory testing, increased monitoring and/or synthetics in production. Communicating what you can be accountable for is one of the tricky parts of being a quality coach. Understanding and being aware of what you can control, can influence, and can't control helps you manage your and others' expectations around the role. The circle of control is one useful way to think about the quality coach role. [![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/05/Circles-of-Control.webp)](https://positivepsychology.com/circles-of-influence/?ref=annemariecharrett.com) Circles of Control from Positive Psychology Website ### Circle of Control > The first and smallest circle at the center is the circle of control, representing aspects of our life over which we have direct control. It is the sphere in which we can effect change. The circle of control symbolizes the areas where we can take meaningful action and make a positive difference.1 As a quality coach, what are the things you can control? Where can you effect change? What can you take *"meaningful action and make a positive difference"?* For example, it might be: - working within the given time and constraints a team has - your facilitation skills - your coaching approach - what you chose to coach on (test automation, monitoring alerting, pairing and collaboration, risk-based activities) - how much you communicate and to whom - how much you involve yourself in the testing activities - how you respond when teams reject ideas and support ### Circle of Influence The second circle is the circle of influence, described as the 'grey zone'. How much we can change things, depends on how much power we have within the organisation. > We may or may not have the power to expand our influence into this region to create change. We can certainly try. It is wise to spend some of our energy in that sphere, bearing in mind that we can control our efforts in this sphere, but not necessarily outcomes.1 As a quality coach, it's worth reflecting on what you believe you can and cannot influence. You may be able to influence a team to: - try a new testing approach such as exploratory testing - improve their test automation strategy - increase test coverage - improve monitoring and alerting - refine their critical user journeys - perform risk-storming or event mapping - how to measure quality - teams' engineering and collaboration practices But, you may not. After all, the team owns and is responsible for quality and may choose not to be 'influenced' by you. Teams may not be in a position to act on your advice, or they may fail to see the value you offer. It doesn't mean you shouldn't try to influence, but be realistic about the outcome. You can control how you respond to setbacks, though. Seeing quality improvement as a journey that everyone goes through, and these setbacks are to be expected helps me remain optimistic about the final outcome. You can also control how you communicate your efforts. Is there someone you can inform of your efforts and seek advice on what to do next? ### Circle of Concern > The circle of concern includes the events, situations, reactions, and phenomena that are clearly outside of our spheres of control and influence.1 As a quality coach working with one of two teams, you are often not in a position to influence change at a senior leadership level. That means it's likely you won't have control over: - the product we are developing - the budget allocated for quality - how other teams operate and respond to your team's efforts - the ability to determine how much time is invested in quality - the amount of money invested in tooling for testing - the number of quality coaches you hire - senior leadership's willingness to own quality It's useful to be aware of some of these factors. Knowing what you can't control helps you temper your expectations. You might even be able to use them to temper others' expectations of the role. And maybe in time, you can look out for ways some of these factors can be pulled into your circle of influence. ## Create your Quality Coach Circle of Control The University of Victoria created a template to create a circle of control as a job aid. I've modified this to create a template for a quality coach aid2. Download this template to work out the quality coach circle of control for your work. [QC circle of controlQuality Coach Template by Anne-Marie CharrettQC circle of control.pdf407 KBdownload-circle](https://www.annemariecharrett.com/content/files/2024/05/QC-circle-of-control.pdf "Download") ## Further Reading & Reference 1 These quotes come from the article by Anna Katharina Schaffner, see below. [Understanding the Circles of Influence, Concern, and ControlTeach your clients the circles of influence to help them cope better.![](https://positive.b-cdn.net/wp-content/uploads/favicon.ico)PositivePsychology.comAnna Katharina Schaffner, Ph.D.![](https://positive.b-cdn.net/wp-content/uploads/2023/05/Circles-of-influence.jpeg)](https://positivepsychology.com/circles-of-influence/?ref=annemariecharrett.com) 2 I haven't tried this out myself. If you do, I would really like to hear about how it went and what you learned. ### 🔭 Quality Coach newsletter #25 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-25/ Last updated: 2024-04-07T05:00:02.000Z ## 🔭 3 Lens Quality Assitance Model The three-lens quality assistance model encourages you to consider the role of a quality coach in the context of your existing product engineering constructs. How will a quality coach impact these teams and the organisation? How will people need to think differently? How must roles change? [3 Lens Quality Assistance ModelWhat to consider when transitioning to a quality assistance model![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w1200/2024/04/3lenses-3-2-1.png)](https://www.annemariecharrett.com/3-lens-quality-assistance-model/) I have a lot of content about creating an organisational structure. Would readers find this interesting? Please provide feedback! ## 📚 Keep helping me write this book! I'm almost ready to put this online book into a publishable format. I need six more months of writing and then editing time. The end of the year seems like a reasonable timeframe. Since I [shared my intention](https://www.annemariecharrett.com/newsletter/publishing-the-online-quality-coach-book/), I've received fantastic support from the community. Thank you 🙏 Please keep encouraging me; the final months are always challenging. You can help by giving feedback through comments, writing to me directly, or liking a post. It's all feedback that will help me understand the types of topics you find valuable. [Publishing the online Quality Coach BookIt’s hard to believe I posted about writing an online quality coach book two and a half years ago. It’s been a fascinating exercise in self-discipline. I’ve watched my membership grow from a few to almost 1000 subscribers. The book’s content has swelled to forty posts. Themes such as concepts,![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1485990005353-9abcf694f3e7?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDM5fHxib29rfGVufDB8fHx8MTcwOTM2MDM1Mnww&ixlib=rb-4.0.3&q=80&w=2000content/images/size/w1200)](https://www.annemariecharrett.com/newsletter/publishing-the-online-quality-coach-book/) ## 🏘️ Picks from the Community When Elisabeth Hendrickson announces she's holding a leadership course, you drop everything and sign up. [Elisabeth Hendrickson on LinkedIn: I am incredibly excited to tell you what I've been working on. Curious…I am incredibly excited to tell you what I've been working on. Curious Duck Studio https://lnkd.in/gbmxGqDu is now open. The studio is intended to be…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInElisabeth Hendrickson![](https://media.licdn.com/dms/image/D5622AQGGSwSNMIp8ag/feedshare-shrink_800/0/1711063218049?e=2147483647&v=beta&t=crQrvUCwzW1lmKTHKOQdWLeNKPxvaJZvBIvC8IVqYu4)](https://www.linkedin.com/feed/update/urn:li:activity:7176719301507260416/?ref=annemariecharrett.com) If that's not in the right time zone, check out Katja Obring's course Shift Left for Testers. [Katja Obring on LinkedIn: Your team is now working in agile, and you’re supposed to shift your…Your team is now working in agile, and you’re supposed to shift your testing left - but nobody told you how to do that. One of the most frequent questions…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInKatja Obring![](https://media.licdn.com/dms/image/D4E10AQHqJbE9PodU1g/image-shrink_800/0/1712215803760?e=2147483647&v=beta&t=mid77jnzEb4vtjxS1N6Ekm0Jjq_za5HYzIB_brKIxbg)](https://www.linkedin.com/feed/update/urn:li:activity:7181553640136941569/?ref=annemariecharrett.com) Two posts on quality coaching from Emna Ayadi. [https://emnaayadi.wordpress.com/2024/03/18/when-quality-coaching-meets-artificial-intelligence/](https://emnaayadi.wordpress.com/2024/03/18/when-quality-coaching-meets-artificial-intelligence/?ref=annemariecharrett.com) [https://emnaayadi.wordpress.com/2024/03/12/7-lessons-every-quality-coach-should-acknowledge/](https://emnaayadi.wordpress.com/2024/03/12/7-lessons-every-quality-coach-should-acknowledge/?ref=annemariecharrett.com) Also, Judy Mosley wrote about introducing QA Practices in an organisation. [🫱🏾‍🫲 How to Introduce QA Practices to Your Organization🖥️ Whether your tech stack is brand new or teetering with age, any time is a good time to introduce Quality Assurance practices within your organization. What do I mean by QA practices? For this article, QA practices are defined by specific standards set within an organization that increases the product’s efficiency, and quality and reduces communication confusion when bugs or defects are discovered during the development process.![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe132144b-f5e5-48fc-9fbb-352173a4ecaa%2Fapple-touch-icon-180x180.png)Failure is FeedbackJudy Mosley![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0be4cd6c-e8a6-4777-b7ec-b239e6ebe199_128x128.png)](https://failureisfeedback.substack.com/p/how-to-introduce-qa-practices-to) Some of the talks from Yow! 2o24 are not available. I enjoyed this one by Josh Armitage. A special shout-out to Lisa Crispin, who continues to show us what community looks like. Plus, celebrating that book fifteen years on. [Celebrating 10 years of friendship, courage, and joy - Agile Testing with Lisa CrispinCelebrating 10 years since meeting Gitte Klitgaard, who has helped me learn about courage and become a dear friend![](https://lisacrispin.com/wp-content/uploads/2016/11/donkey-144.gif)Agile Testing with Lisa CrispinLisa Crispin![](https://lisacrispin.com/wp-content/uploads/2024/03/Heart.png)](https://lisacrispin.com/2024/03/18/celebrating-10-years-of-friendship-courage-and-joy/?ref=annemariecharrett.com) [Looking back at Agile Testing, 15 years on - Agile TestingThe software world experiences continual technological change. Just look at how AI is taking it by storm right now. Other changes seem much slower. Test-driven development, for example, is a long way from crossing the chasm after being around for decades. We wrote our first book, Agile Testing: A Practical Guide for Testers and Agile \[…\]![](https://agiletester.ca/wp-content/uploads/2018/11/cropped-at-favicon-270x270.png)Agile TestingRumspeed![](https://agiletester.ca/wp-content/uploads/2024/04/Agile-Testing-book1_cover.jpg)](https://agiletester.ca/looking-back-at-agile-testing-15-years-on/?ref=annemariecharrett.com) ## Upcoming speaking engagements So many talks this year! [Communicating in an Isolated & Decoupled World - Anne-Marie Charrett & AI Panel , Wed, Apr 17, 2024, 5:30 PM | MeetupFor our April \*\*In-Person Meetup\*\* we have an extravaganza for you! The well-known and award winning Anne-Marie Charrett will be discussing a very prescient topic since COV![](https://secure.meetupstatic.com/next/images/general/m_swarm_196x196.png)Meetup![](https://secure.meetupstatic.com/photos/event/3/c/5/6/600_520035446.jpeg)](https://www.meetup.com/sydney-testers/events/299882989/?ref=annemariecharrett.com) [Speakers\_24 - /NEWThe /NEW\_24 speaker lineup features experts in a broad range of technology fields, representing the diverse community in Newcastle and nationally.![](https://static.ghost.org/v5.0.0/images/link-icon.svg)/NEWSarah Frazer![](https://slashnew.tech/wp-content/uploads/2024/02/NEW-Humanitix-banner-1200-x-628-px-1.png)](https://slashnew.tech/speakers%5F24/?ref=annemariecharrett.com) [Agile & Quality; Is quality \*really\* everyone’s responsibility?, Wed, Jul 24, 2024, 5:45 PM | Meetup\*\*Agile Quality - Is quality really everyone’s responsibility?\*\* \[Ann Marie-Charret\](https://www.linkedin.com/in/testingtimes/) In Agile, quality is a shared responsibility![](https://secure.meetupstatic.com/next/images/general/m_swarm_196x196.png)Meetup![](https://secure.meetupstatic.com/photos/event/c/e/600_518820206.jpeg)](https://www.meetup.com/scrum-12/events/298892061/?ref=annemariecharrett.com) [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Testing Talks Conference 2024 MelbourneWe want Testing Talks Conference 2024 to be a reunion for our community. A fun event for all; to share, learn and reconnect in-person.![](https://testing-talks-release-assets.s3.ap-southeast-2.amazonaws.com/favicon.ico)Testing Talks Conference 2024 Melbourne![](https://www.testingtalks.com.au/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBdDRIIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--0aaf86951e38d90653a7707b516d3824db4fd355/tt-2024-melb-graph.png)](https://www.testingtalks.com.au/upcoming-events/testing-talks-conference-2024-melbourne?ref=annemariecharrett.com#agenda) Remember to subscribe for free to receive this newsletter and any free posts. Subscribing for $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until then. Anne-Marie ### 3 Lens Quality Assistance Model URL: https://www.annemariecharrett.com/3-lens-quality-assistance-model/ Last updated: 2024-04-02T05:23:52.000Z Unlike Quality Assurance, Quality Assistance is a model where product engineers own the feature lifecycle from ideation to support. In this model, software testers enable teams to improve their quality rather than participate in uplifting quality. Companies wishing to adopt this model will need to consider the impact of shifting to this approach, as it impacts beyond quality coaches to product teams and potentially to product engineering leadership. In this article, I use a three-lens1 model to understand what needs amending when a company shifts to a quality assistance approach. The three lenses are: - Organisational lens These are the structures and models required for the team to exist within the organisational construct. - Squad/team/practice lens On a team level/squad/guild level how to interoperate with these structures - Quality Coach lens Areas directly impacting a quality coach include their role, career paths, etc. Frame what good looks like for quality assistance through all three lenses. By doing so, you are ensuring you have considered the impact of any changes through the eyes of a quality coach and the effect on the teams and the organisation. There's a significant amount of context to consider when adopting any approach. The following are some questions to consider. You don't have to embrace all of these, but it's worth thinking them through with engineering leadership to understand what they feel is essential. ## Organisation Structures The essence of the quality assistance model is to shift ownership of quality to all of the product engineering instead of allocating it to one role. Not only do quality coaches have to adopt new ways of working, but the whole of product engineering does, too. - Company Culture - What are the Company Values? - How big is the company? Maturity of Company (startup, scaleup, enterprise) - What is the size of the company? - Current Company Structure - What is the current company structure? What other practices will you align with (delivery, SRE, engineering)? What might need modifying to accommodate the quality assistance model? - Do Quality professionals exist in teams? How will they transition? - Team Topologies: Are there stream-aligned teams? Enablement teams? Platform teams? What will you be? How will you structure product focus versus technical focus? - Enablement Team Structure - Will you be solely a technical enablement team? - Will you work in isolation with other enablement teams or collaborate with them? - How will you maintain frameworks and tooling? - How will teams access your frameworks and example tests? - What technical tooling will you be delivering? - Practice or Guild - Will you have a guild or a practice where quality coaches can assemble and learn from each other? Will they report to the quality practice, or will their manager be within a squad? - What is the aim of the practice? What is it accountable for? - Operating models - How will you interact with feature teams? Will you wait for a request? Or will you perform audits and track progress? - What other practices will you collaborate with? Do you need an operating model for them? - How will the operating models impact roles and responsibilities? - Roles & Responsibilities - Who is responsible for elements of quality? - What roles need modifying? Will software engineers need to have software testing included in their role? How will they transition those roles? - What impact does this have on career paths? Career Growth? - Job Descriptions - What will the job descriptions look like? Will software engineering job descriptions include software testing? What other activities and tasks will they be taking on? - What HR considerations do you need to make when changing anyone's role? ### Process - Hiring Process - What will the hiring process look like for new engineers and quality coaches? - What will the hiring process look like for new engineers and quality coaches? - Onboarding Process - What new information do quality coaches need during onboarding? - What do engineers need to learn about owning software testing? What tools do they need to be taught? - What self-service product knowledge can be made available to all new hires under the product? - Transition Process - What is the current state? What will be the end state? What does success look like, and how will you track it? - How will you get from the current state to the end state? (What's your strategy and roadmap?) - What change management tasks do you need to ensure you do? Will you use the ADKAR change management model, or does the company have a method of handling change? - Who is currently managing existing quality professionals? Who should manage them? ## Interacting with Teams/Practices Interpersonal considerations are the people and groups the quality assistance model interacts with. For example, Quality Coaches, Software Engineers, Engineering Leadership, Product Managers, Designers, Practice Leads Consider the following questions: ### Informed - Who wants to know the state of the product's quality? How often should you catch up? - How will you keep people informed? Through reports? Videos? How will you share success stories? Who will quality coaches report progress to? What information sessions will you need to hold? - Who do you need to keep informed about the transition process? Who should be informed about quality improvements? - Who needs to keep you informed? What do you want to be informed about? ### Consulted - who do you need to consult to develop structures and processes? Who will be impacted by the quality coach model? Who will want to have input into how quality operates? Who should you consult who has considerable influence? ### Product Teams - What product teams will you be working with? How many? Are they value stream teams or platform teams? - What skills do software engineers have? Do they understand they are responsible for quality? What training will they need? - Will you audit teams? Will you coach or direct? How will you decide how to interact with teams? - Does the team have a whole-team approach to quality? If not, how do they manage quality? Is it working? What needs improving? - Do the product teams know what success looks like? How will you begin coaching them on what good looks like? - How will you split up quality ownership among teams? What are they responsible for? What are you responsible for? How will you go about working that out? - How will you incorporate and involve product engineering in your decision-making? ### Practices - What practices will you be collaborating with? Engineering? SRE, Delivery? Security? How do you plan to work together? How can they build quality into their ways of working? - How can you help other practices? What can you collaborate on? What can you learn from them? - What tooling are they using? What ways of working, operating models and structures do they use? - What skills do software engineers have? Do they understand they are responsible for quality? What training will they need? ## Quality Coach Practice Quality coaches may or may not sit within squads. Regardless, someone needs to consider the following: ### Career Path - What levels of quality coach will there be? How do you begin your career path? Where can it lead? - What roles and levels can you compare a quality coach role to? - Who within the organisation should you involve? HR, Engineering Leadership? - Who will manage the quality coaches, engineering managers or the Director of quality engineering? What are the reporting lines? ### Training Plan - What training needs to be given to quality professionals to shift to the quality coach role? - What training do the teams need? - Who will do the training? Is it internal or external, or both? - Do you need an additional budget for training? Who will provide that? ### Job Descriptions - What skill sets are required? Will you train up or hire in? - What does the job description look like for each level of quality coach? - Will there be a difference between a technical quality coach and a product quality coach? Will there be a different job description? How can quality coaches switch between the roles? ### Quality Practice Structure Will you have a quality practice or guild? - What will the team structure look like? - Who is responsible for what within the quality practice? - What are you responsible for as opposed to the team responsible for? (Test Environments, test data, frameworks, - How many quality coaches will you need? Now, and in the future? - What are the hiring questions? Who will perform the interviews? - What's your operating model? How will you interact with teams? How will you measure success? ### Sensible Defaults for Quality As a quality practice, it's a good idea to mock up what "good looks like" in these areas. Labelling these sensible defaults and asking for input from various stakeholders allows teams to modify them to their context. - Product Quality End State - Quality Attributes for product and/or a service - Key risk areas for the company - list of recommended tooling that quality practice supports - test data strategy, test environment strategy, test automation strategy - Company-Wide Quality Strategy - required tooling for teams, for practice - Quality Rituals & Practices you want teams to embrace. (Risk storming, Contract Testing etc.) - Principles A list of principles the company believes about quality - Quality Principles. What are the company's quality principles? Will you create them, or will you facilitate the creation of the principles? Who should be involved? - Architecture & Engineering Principles. What engineering principles will impact quality? How will quality coaches contribute to the conversation? - What principles in product and design exist? How can you incorporate quality into them? ## Request for Feedback This is my first draft of such a structure. It's clear it needs some modifications. For example, the classifications can be improved. Feel free to enter feedback in the comments below or reach out to me at feedback@qualitycoach.io 1 I first learned about the three-lens model from a class on strategic thinking by [Lifelabslearning](https://www.lifelabslearning.com/?ref=annemariecharrett.com). ### 📚Can you help me finish this book? QCN # 24 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-24/ Last updated: 2024-03-10T06:06:48.000Z ## Product Excellence Are you tired of convincing Product Managers to take extra time to build quality? Would you rather your role focus on the relationship between product and customer instead of user story and assert? Take a look at my Product Excellence framework. It takes a holistic view of quality that spans product discovery, delivery, and support. [Product Excellence - Continuous Quality from Discovery to SupportOverview Introducing Product Excellence, a new framework that creates a single view of quality across discovery and delivery. Delivering small batches of customer value in isolation comes with a cost. As a strategy for risk reduction, it wins hands down. It can come up short as a strategy for delivering![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/02/Product-Exellence-by-Anne-Marie-Charrett-1-1.jpg)](https://www.annemariecharrett.com/product-excellence-continuous-quality-from-discovery-to-support/) ## Help me write this book! I'm almost ready to put this online book into a publishable format. I need six more months of writing and then editing time. The end of the year seems like a reasonable timeframe. Since I [shared my intention](https://www.annemariecharrett.com/newsletter/publishing-the-online-quality-coach-book/), I've received fantastic support from the community. Thank you 🙏 Please keep encouraging me; the final months are always challenging. You can help by giving feedback through comments, writing to me directly, or simply liking a post. It's all feedback that will help me understand the types of topics you find valuable. [Publishing the online Quality Coach BookIt’s hard to believe I posted about writing an online quality coach book two and a half years ago. It’s been a fascinating exercise in self-discipline. I’ve watched my membership grow from a few to almost 1000 subscribers. The book’s content has swelled to forty posts. Themes such as concepts,![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1485990005353-9abcf694f3e7?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDM5fHxib29rfGVufDB8fHx8MTcwOTM2MDM1Mnww&ixlib=rb-4.0.3&q=80&w=2000content/images/size/w1200)](https://www.annemariecharrett.com/newsletter/publishing-the-online-quality-coach-book/) ## Other writing [Courage in Exploratory TestingExploratory Testing doesn’t have ‘dutch courage’ to rely on. It requires us to have conversations about our information in potentially hostile environments. Sometimes we can feel like the lone fish swimming against the tide of the silent majority.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1517984922331-8dbaa8ffa9c1?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDF8fGNvdXJhZ2V8ZW58MHx8fHwxNjIzODMyOTg5&ixlib=rb-1.2.1&q=80&w=2000content/images/size/w1200)](https://www.annemariecharrett.com/courage-in-exploratory-testing/) ## Picks from the Community Platform Engineering seems to be the theme for this month! [Fooled by Microservices, APIs and Common ComponentsIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://resources.blogblog.com/img/icon18_edit_allbkg.gif)](https://visible-quality.blogspot.com/2024/03/fooled-by-microservices-apis-and-common.html?ref=annemariecharrett.com) [Perils, Pitfalls and Pratfalls of Platform EngineeringCharity Majors discusses how platform engineering teams are different from other engineering teams, and presents some of the ways they run into traps and other troubles.![](https://cdn.infoq.com/statics_s1_20240227220903/apple-touch-icon.png)InfoQCharity Majors![](https://res.infoq.com/presentations/platform-engineering-teams/en/mediumimage/CharityMajors-medium-1706001450333.jpg)](https://www.infoq.com/presentations/platform-engineering-teams/?ref=annemariecharrett.com) [What quality attributes do developers care about?Exploring Google’s Theory of Software Quality: Lessons from a Software Engineer’s Perspective![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0c8eb16b-22d3-4bfe-950b-3902e55ab241%2Fapple-touch-icon-180x180.png)Quality Engineering NewsletterJit Gosai![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F34ad761e-1785-48c7-9d79-78cf1c3e1bfa_3245x1232.jpeg)](https://qualityeng.substack.com/p/what-quality-attributes-do-developers) [Engineering JoyTalking about what makes an enjoyable and psychologically safe workspace on the Engineering Joy podcast.![](https://www.heatherreiduff.com/apple-touch-icon-144-precomposed.png)![](https://www.heatherreiduff.com/profilepic.jpeg)](https://www.heatherreiduff.com/posts/2024/engineering-joy/?ref=annemariecharrett.com) ## Upcoming speaking engagements I've got more talks coming up and once they're formally announced I'll add them here.. [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Agile & Quality; Is quality \*really\* everyone’s responsibility?, Wed, Jul 24, 2024, 5:45 PM | Meetup\*\*Agile Quality - Is quality really everyone’s responsibility?\*\* \[Ann Marie-Charret\](https://www.linkedin.com/in/testingtimes/) In Agile, quality is a shared responsibility![](https://secure.meetupstatic.com/next/images/general/m_swarm_196x196.png)Meetup![](https://secure.meetupstatic.com/photos/event/c/e/600_518820206.jpeg)](https://www.meetup.com/scrum-12/events/298892061/?ref=annemariecharrett.com) Remember to subscribe for free to receive this newsletter and any free posts. Subscribing for $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until then. Anne-Marie ### Publishing the online Quality Coach Book URL: https://www.annemariecharrett.com/newsletter/publishing-the-online-quality-coach-book/ Last updated: 2024-03-02T06:30:16.000Z It's hard to believe I posted about writing [an online quality coach book](https://www.annemariecharrett.com/about-that-quality-coaching-book/) two and a half years ago. It's been a fascinating exercise in self-discipline. I've watched my membership grow from a few to almost 1000 subscribers. The book's content has swelled to forty posts. Themes such as concepts, workshops, and corporate structure have emerged as I write and offer a glimpse of the potential book structure. My intention was always to create a formal book. The online SaaS book was a way to stop me from being a perfectionist about the content (I had already written the first third of the book three times 😆). I believe the time is approaching when I begin to pull this book into something cohesive and publishable. To my paid subscribers, I want to thank you for your continued support. Once it is complete, long-time supporters can consider your payments as a pre-purchase! It's been an amazing journey, and I truly appreciate how your ongoing monthly contributions have encouraged me (and sometimes compelled me!) to continue to write. I plan to continue writing online, as there is still content to deliver. Please continue supporting me as I shift into the final phases of this process 😁. I'm not sure exactly how I will do that or when this will happen. I'm hoping for six months, and I most likely will self-publish, but if anyone has a compelling reason for me to publish elsewhere, [please reach out](mailto:annemarie@qualitycoach.io) 🙇‍♀️ Anne-Marie ### Product Excellence - Continuous Quality from Discovery to Support URL: https://www.annemariecharrett.com/product-excellence-continuous-quality-from-discovery-to-support/ Last updated: 2026-04-25T23:34:43.000Z ## **Overview** Introducing Product Excellence, a new framework that creates a single view of quality across discovery and delivery. Delivering small batches of customer value in isolation comes with a cost. As a strategy for risk reduction, it wins hands down. It can come up short as a strategy for delivering a quality product. This is because deconstruction often means we lose sight of the big picture, which hampers our ability to evaluate and comprehend overall product quality. Silos are great for focus but awful for quality. Threats to quality often grow in the space between silos. Here, miscommunication and ‘zero touch’ communication thrive, resulting in missed requirements, hidden dependencies and poor estimation. To combat this, we must discover ways to bridge the gaps and begin a conversation on quality grounded in shared understanding, critical thinking and risk-based analysis. In this way, we avoid Chinese Whispers where quality for our customers becomes a miserable facsimile of our original intent. ## **Discovery** and **Delivery….and support** Continuous Discovery Habits by Theresa Torres describes continuous discovery as consisting of discovery and delivery as separate yet symbiotic activities. ![Discovery - "figuring out what to build", Delivery - "then building it"](https://lh7-us.googleusercontent.com/Y_joatIfIGTZd0794eB4xsdHP5gTDRpjKPne89WN7P85U2X0Awgm2S0Vvy1HGOz8WogzvJRF3pt15aaE6NWbG63M8L5mI7iTFmf_gXtm94aIP8eHxNsjp7OHYA_FP_yFfe4UO75y6xPBbWVuMMDfs2s) From a quality perspective, the product doesn’t end at delivery; it extends into technical operations and support. Nowhere is this more true than in a SaaS product. For SaaS, it’s more than discovery and delivery; it's about maintaining and supporting our delivery. In SaaS products, we want to "figure out what to build", "then building it" and "then maintain and support it". We might even have to consider decommissioning and the data migration, security, and safety and potential job losses that go along with that. ![upload in progress, 0](https://lh7-us.googleusercontent.com/7pZQSTNDZAISkqjxjOCiu3AwpBRwnJ_asql21HhmgIBqYj0StcGXMlkAjv9kIQnYTrhLx5WZuGXtlxAA2M2sdcmYBWmDd7-UyTSHnSJa3uajMG_y-zFEPjXquQN6RmKww701ZJYeCybqmtuY5if9v7Q) In this context, quality is building the right product, building the product right, and maintaining and supporting it well. Depending on your focus, different perceptions of quality exist throughout our product lifecycle. A product manager may view quality through the lens of building the right product. An engineer focuses on building the product right, and technical operations look to support and maintain that product as it continues to serve our customers. ## **Quality is value to some person** Optimising for quality is useful and problematic. Deconstructing quality into different dimensions optimises our tests for the required information. An engineer can focus on scalability, while a designer can focus on accessibility. The result is that our proxy for quality in accessibility will be different to that for scalability. But deconstruction can cause us to lose sight of the big picture. The big picture is that quality is ultimately a relationship between the customer and the product. When we lose sight of this, we frame our experiments to suit our optimisation. It results in teams believing they have a common understanding of quality but have wildly disparate views. We want a model that allows us to generate a shared understanding of quality and how we will test for it and report on it. ## **Product Excellence** The Product Excellence model provides a holistic view of quality across discovery, delivery and support. By developing a shared understanding of quality and maintaining that perspective across all facets of the product lifecycle, we can prioritise quality to maximise customer value. ![Product Excellence Model by Anne-Marie Charret 2022](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/02/sRHB4pbCVFPDhJXBFMZ4zIAJVVZH6Nq_InQnOJiIzHh4ElfJ08czw5GoLhV1aUrCbfmRqMZiDwy3P1ll7qyoeFb7txbRDTzH4jJr_D-5LhxHKUio-FbQ0mGQyGfbEEVKBrXj15To1kXZz2MsSyX1bMg.jpeg) Product Excellence Model by Anne-Marie Charret 2022 The Product Excellence model is built upon Gabrielle Benefield’s Mobius Loop, where the product lifecycle is more cyclical than linear. The model resembles Janet Gregory’s and Lisa Crispin’s holistic testing model. However, the focus is broader across all elements of product discovery, and the conversation begins with a shared understanding of customer value. We must think holistically about quality rather than distinct product lifecycle activities. Right now, we don’t do this. We optimise our testing in the same way we optimise our roles and activities. We don’t have a common language on what quality means to us. Consequently, our testing is framed and measured in different ways and almost different languages. So even though we all passionately want to deliver quality to our customers, we rarely discuss that. ## **Customer Value** We must find commonality and a shared goal to help us begin that conversation about quality. Once we have that, we develop and sustain a cohesive view of quality across all activities. I believe the unifier is customer value. A business exists to deliver and profit from customer value. Product teams exist to ideate, build and maintain that customer value. It both unifies us and allows us to suitably optimise for differences. As you see below, each role within a product team focuses on a slightly different element of that customer value. ![Product Excellence Model by Silo Anne-Marie Charrett 2022](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/02/tPUgD8Bh3qIxoZo_nr7QdiFuqjEC5ohYPJACcNYlSC2srt9TrG4gpKcItWBD5hBoSPliIpmrch7-20nWVl9w4_xuvbPL0egPNrzt-EHQVcLbB61-NXE8rF2UvgAPuBA1nVQn34ohsbF64ver0B-ZCL8.jpeg) Product Excellence Model by Silo Anne-Marie Charrett 2022 ## **Testing is everywhere!** I once attended a combined discovery and delivery workshop. We mapped out all the activities performed across discovery, delivery and ops. It turns out we perform testing in a lot of places. ![](https://lh7-us.googleusercontent.com/5j8dQCp92hrAwS_k7LGVIrgzXxXG2AU80_DctCAaNzUgPgP_W9ACHBpSh_9H9fAXkbtx6pj8ySIyoe0qspMP6iDiw7VR7Q_cof-L8lB9VZfuvICbhckR8ZCv_WjtGQI0xUVPiawAda9MTuEKGP1mKjM) Here are some testing activities identified: - Hypothesis testing - Assumptions testing - Unit Testing - Integration Testing - Usability Testing - Acceptance Testing - Performance Testing - A/B Testing - Canary Releases - Testing in Production The purpose and nature of the test may differ, but it seems to hold that in tests we trust! We need to unify these efforts with a shared understanding of customer value. Once we have that, we can begin framing our experiments this way. We can allow for proper estimation to conduct these experiments, and we can make sure everyone in the product team can understand the state of quality at any time. ## **Good Test Design** I believe we instinctively test for customer value. We test to confirm the existence of customer value or at least a proxy of that value. We test for the “known knowns”. We sometimes neglect to test for failure, the “unknown unknowns”. Unless we train or are hired for that purpose, the instinct is to test that it confirms our hypothesis and not realise that we should also design tests with failure in mind. These “unknown unknowns” catch us out, surprise us, and turn our calculated bet into a messy gamble. ## **Critical Thinking** Critical Thinking is the antidote to these nasty surprises. Critical thinking helps us to maximise our efforts in testing. Instead of trial and error, we become intentional about what and how we test. When we view quality as a whole, we can begin to think critically across every portion of the product lifecycle. For example, we can ask: what does “build the right product” mean? How would we know we’re building the “right” product? What does success look like for that? And how important is the information in the big scheme of things? If our tests fail, what decisions will we make? ![upload in progress, 0](https://lh7-us.googleusercontent.com/TsS3-qIsKj5PIHXPhsaLVUSBA4uOmhuKJUiFPDxk_IgThTek0OsW1pYMgqi1yoYjk1voSqQ2xJVIF2tX4eFoeCufiiNs7H9Bbaxnwpu7nbcFvBEmXSu37BJQKRa_f47qyRhcoXJbNo0Cp1yz1XLxb2I) We must have a collective view of quality and understand the subtle nuances each role offers to that perspective. We must understand how to test for it and how it will inform our decision-making process. Mindlessly ‘testing everything and trying to automate all the things’ is a pretty low bar for a testing strategy. However, framing our testing with a shared understanding of quality allows us to maximise the value of our testing. ## **Critical Thinking in Test Design** We instinctively test for customer value. Our tests confirm that the chosen proxy of customer value suggests that customer value exists. Unfortunately, the process of creation is subject to confirmation bias. As a result, when we create something, we lean to confirmatory testing and omit to test for failure. There are a couple of ways to mitigate this risk. You can train product teams on good test design or have a specific role that questions and evaluates quality. Regardless, thinking critically through your testing strategy is a good idea. The information that results allows us to make informed decisions, turning our gamble into a calculated bet. ## **Risk Focuses our work** If that sounds like a lot of testing, you are right. In many contexts, we’re unwilling to invest in that rigour, instead trading our quality off against speed of delivery and cost. There is an alternative approach. Using risk as a focusing technique, we can identify what is critical and must not fail and focus our testing efforts around that. ![upload in progress, 0](https://lh7-us.googleusercontent.com/oTiTFywT5h7Pp72EO0pFCym1JNUxJo5hYRQqRgndN-6DPmx_E0eY0-sjm9UEWSZDk97gemIyyI-e-e7JPFqvv3-fbvoRU_pki2lc_9tBztptnRfzQviEdowGFyDOf7i_WJzbd23FOydhR1blZka2O-s) Risk is anything that threatens the quality of the product. Risk helps us quantify failure by assessing its impact on business value and the likelihood of failure. Designing our tests for potential failure helps us focus the testing effort on “must do”. Instead of attempting to test everything, we focus on the testing effort where failure may have its most significant impact and is most likely to occur. ## **Quality Professionals** I believe quality professionals (QP) are in the ideal position to be the golden thread that links product, delivery and support, as in their existing role, they need extensive knowledge of business value and technical complexity. QPs are adept at using risk to evaluate the quality of the product quickly, so much so that people assume it's some superpower. It's not. It’s years of tacit knowledge acquired through discovering defects in products. Quality professionals are[ like navigators on a rally team](https://www.skoda-storyboard.com/en/lifestyle/motorsport/secrets-of-a-rally-navigator/?ref=annemariecharrett.com) advising the product team to speed up when the risk is low or slow down when it's high. Quality professionals are adept in designing, executing, and reporting on experiments. That is the essence of software testing. QPs understand the importance of good test design and solid execution of tests that offer consistent and reliable results. Next time you think about product quality, pull your quality professional into the conversation. Include them in prototyping and customer experience sessions so they build up knowledge of what customer value looks like. As ideation moves into delivery, they become the product champion, keeping testing conversations focused on customer value. They will initiate discussion on quality and how to prevent, detect and recover from failure. They become a conduit of information, helping delivery with domain context and providing progress on the state of quality to delivery. Let them test in production behind a feature flag. Allow them tools such as Grafana, Prometheus and Honeycomb that allow them to analyse customer interactions in real-time. Along with technical success, allow them to feed this information into discovery and ideation. Your customers will thank you for it. ## **References** Teresa Torres - Continuous Discovery Habits [https://www.producttalk.org/2021/08/product-discovery/ ](https://www.producttalk.org/2021/08/product-discovery/ ?ref=annemariecharrett.com) Quality is value to some person was coined by Jerry Weinberg Janet Gregory’s and Lisa Crispin's Holistic Model [https://janetgregory.ca/testing-from-a-holistic-point-of-view/](https://janetgregory.ca/testing-from-a-holistic-point-of-view/?ref=annemariecharrett.com), Tester as Navigator is an XP reference used by both Lisa Crispin & David Evans, respectively. [Testing in Extreme Programming](https://books.google.com.au/books?id=eTREaOEImsgC&pg=PA20&lpg=PA20&dq=lisa+crispin+testing+XP+tester+%22navigator%22&source=bl&ots=QhBEyCKcqg&sig=ACfU3U2a0fg84hGJevgJYj4E5qyyxYBOEg&hl=en&sa=X&redir%5Fesc=y#v=onepage&q=lisa%20crispin%20testing%20XP%20tester%20%22navigator%22&f=false) by Lisa Crispin & Tip House Gabrielle Benefield Mobius Loop [https://www.mobiusloop.com/](https://www.mobiusloop.com/?ref=annemariecharrett.com) ### Glints in Leadership URL: https://www.annemariecharrett.com/glints-in-leadership/ Last updated: 2024-02-17T03:45:21.000Z I talk quite a bit about leadership as creating spaces where people can thrive and grow. It suits my leadership style to lead in such a way. I get to amplify my strengths and work in a way that rewards me. It's a beautiful experience to see people back their ideas and abilities and venture into something new. Creating spaces is about allowing people the agency to decide how the work they're accountable for is executed. It's signalling that around here, your ideas and goals are valuable and will be listened to. It's the opportunity for you, if you wish, to determine what success looks like and then give you the tools to make that happen. That means being available to people, listening to them and allowing them to succeed on their terms. It takes time for those ripples of change to have an impact. They won't come out of obvious places. And often, they're only recognisable as a glint on water. But when you see it, do everything you can to nurture it and give it room to grow. You must protect it from the elements, and when it thrives, you must celebrate it. Not everyone is going to agree with this approach. Some may see this as a threat or dismiss it as passive leadership. I've come to realise that this space is for them, too. As a leader, you offer this space to everyone, even those who operate and behave differently from you. You don't have to agree with everything they do or say, but you can be their ally. Allow them to succeed on their terms. Treat them with respect, and address your differences with diplomacy. Here, the glints in the water may be opportunities to amplify similarities and goals where both can grow. Everyone deserves to have agency, even those who disagree with you. ### Quality Coach Newsletter 23 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-23/ Last updated: 2024-02-04T05:29:33.000Z ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Motivation as a Quality Coach Moving to a quality coach role can be slightly confronting if you've typically worked within a single team. There's a certain amount of confidence required to jump into a new context who, for whatever reason, may be reluctant to include you in their work. How do you quickly convince a team that you are there to help and not inflict additional work? Well, one technique is to follow the energy. In this month's post, I explain the concept and what it requires from you. [Follow the EnergyMotivating a team when you’re not on the team is tricky business. You could be expected to conduct a workshop to identify a quality strategy. Yet, you might not have all the context available to know what risks exist and why obstacles exist. What you call quality activities, they might![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w1200/2024/02/photo-1496224027003-38fc92be458c.jpeg)](https://www.annemariecharrett.com/follow-the-energy/) ## Other writing My article 👇 on quality engineering as an enablement team has been included in the [new Team Topologies training course](https://academy.teamtopologies.com/courses/effective-enabling-teams?ref=annemariecharrett.com) for enabling teams 🎉. [Team Topology & Quality Engineering StructuresWhat is the optimal structure for Quality Engineering within Engineering? Anne-Marie Charrett writes about some of the complexities to consider![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w1200/2021/10/Screen-Shot-2021-10-16-at-7.04.55-pm.png)](https://www.annemariecharrett.com/team-topology-quality-engineering/) If you're a quality coach book member, you can read that without paying for the course! [Sing your voiceWe all have a voice and a song. Sometimes, the song beats loud in our hearts, and sometimes, it’s so quiet that you must stop everything else to listen. It’s your song. Only you can sing it. No one can sing your song like you do. Sometimes, you might think![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/01/1706434012377.jpeg)](https://www.annemariecharrett.com/voice/) [The Extraordinary in the OrdinaryRecently, I’ve heard references to mediocrity in software testing. Statements like “Tolerance of mediocrity has done massive damage to our testing field”. There’s an implicit judgment in this statement. In that word mediocre, there’s a suggestion that many in the software engineering field are somehow negligent, lazy![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1514025224826-8d3c22eecd02?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDI3fHxzaW1wbGUlMjBtZWFsfGVufDB8fHx8MTcwNTkwNDYxM3ww&ixlib=rb-4.0.3&q=80&w=2000content/images/size/w1200)](https://www.annemariecharrett.com/the-extraordinary-in-the-ordinary/) ## Picks from the Community A big shout out to the Ministry of Testing community, which regularly posts topics on quality coaches. Here's a [search of content](https://www.ministryoftesting.com/search?q=%22quality+coach%22&ref=annemariecharrett.com). [Ministry of TestingWelcome to the Ministry of Testing and our community software testing events and content.![](https://www.ministryoftesting.com/assets/favicon-4b6ba0a4118ce928dfcf3d3230cdbb09347a5a9b8d98f244c79d0d56384758bb.ico)Ministry of Testing![](https://d2h1nbmw1jjnl.cloudfront.net/downloads/Homepage-OpenGraph-Images-MoT.jpg)](https://www.ministryoftesting.com/?ref=annemariecharrett.com) Abby Bangser & Co. have written an interesting perspective on Platform Engineering models. check it out. [Announcing the Platform Engineering maturity modelCommunity post originally published on the TAG App Delivery blog by Abby Bangser and Josh Gavant The CNCF Platforms Working Group (WG) is excited to present the first release of a platform engineering…![](https://www.cncf.io/wp-content/themes/cncf-twenty-two/images/favicon.svg)CNCFJessie![](https://www.cncf.io/wp-content/uploads/2023/11/Single-Card-2-2.png)](https://www.cncf.io/blog/2023/11/20/announcing-the-platform-engineering-maturity-model/?ref=annemariecharrett.com) I didn't get to see this talk, but I heard great things. Check out Marianne Duijst's sketchnote. [Sketchnote: Quality from the CEO perspectiveAlex Schladebeck and Michael Mlynarski presented their talk: Quality from the CEO Perspective: Why Do They Not Always Strive for 100% quality? at Agile Testing Days 2022\. Alex and Michael eloquentl…![](https://marianneduijst.nl/wp-content/uploads/2016/10/cropped-Marianne_Duijst-270x270.jpg)Marianne DuijstMarianne Duijst![](https://marianneduijst.nl/wp-content/uploads/2023/11/Michael_And_Alex_-_Quality_From_CEO_Perspective-scaled.jpg)](https://marianneduijst.nl/2024/01/26/sketchnote-quality-from-the-ceo-perspective/?ref=annemariecharrett.com) Melissa Fisher is on a role with her blog posts. So many to pick. This one is the most recent. [It’s Ok to miss opportunitiesLast year I had the privilege of attending Agile Testing Days to do a workshop and talk. It had been on my goal list for a number of years…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumMelissa Fisher![](https://miro.medium.com/v2/1*kFrc4tBFM_tCis-2Ic87WA.png)](https://fishouthebox.medium.com/its-ok-to-miss-opportunities-cf295065ec10?ref=annemariecharrett.com) Something for the more technical, Judy Mosley writes on Cypress Fixtures. [Explain It Like I’m 5: Cypress FixturesDoing research on Cypress Fixtures makes me feel like this: Google “Cypress Fixtures” and there are so many tutorials and videos on the topic. It’s hard to know where to begin. Having zero knowledge of Fixtures, what’s helpful for me is dialing down to the very basics of fixtures, what they are for, how they are created, and how to use them in tests.![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe132144b-f5e5-48fc-9fbb-352173a4ecaa%2Fapple-touch-icon-180x180.png)Failure is FeedbackJudy Mosley![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1739cfcf-e726-4e74-957a-17970883f1d6_4000x6000.jpeg)](https://failureisfeedback.substack.com/p/explain-it-like-im-5-cypress-fixtures) Martin Fowler has updated his blog post on continuous integration. [Continuous IntegrationEvery developer integrates their work into mainline at least every day.![](https://martinfowler.com/favicon.ico)martinfowler.comMartin Fowler![](https://martinfowler.com/articles/continuousIntegration/card.png)](https://martinfowler.com/articles/continuousIntegration.html?ref=annemariecharrett.com) ## Upcoming speaking engagements [HUSTEF - Hungarian Software Testing Forum on LinkedIn: #hustef #softwaretesting #softwarequalityWe proudly announce our first Keynote Speaker of HUSTEF 2024, the fantastic Anne-Marie Charrett! 🎉 We can't wait to meet her personally in Budapest - How…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInHUSTEF - Hungarian Software Testing Forum![](https://media.licdn.com/dms/image/D4D22AQGXObabt-4AIg/feedshare-shrink_2048_1536/0/1706096542277?e=2147483647&v=beta&t=xd2dSo8JNQiXNzPv-59InlRsk7i1S8KxKARz44PR0C4)](https://www.linkedin.com/feed/update/urn:li:activity:7155887556297932800/?ref=annemariecharrett.com) [Agile & Quality; Is quality \*really\* everyone’s responsibility?, Wed, Jul 24, 2024, 5:45 PM | Meetup\*\*Agile Quality - Is quality really everyone’s responsibility?\*\* \[Ann Marie-Charret\](https://www.linkedin.com/in/testingtimes/) In Agile, quality is a shared responsibility![](https://secure.meetupstatic.com/next/images/general/m_swarm_196x196.png)Meetup![](https://secure.meetupstatic.com/photos/event/c/e/600_518820206.jpeg)](https://www.meetup.com/scrum-12/events/298892061/?ref=annemariecharrett.com) Don't forget you can subscribe for free and receive this newsletter plus any free posts. $2 a month gives you access to the quality coach book posts. ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Until then. Anne-Marie ### Follow the Energy URL: https://www.annemariecharrett.com/follow-the-energy/ Last updated: 2024-02-01T09:11:04.000Z Motivating a team when you're not on the team is tricky business. You could be expected to conduct a workshop to identify a quality strategy. Yet, you might not have all the context available to know what risks exist and why obstacles exist. What you call quality activities, they might hear 'extra work'. The key is to identify *their* motivation, not what *you* think their motivation should be. Jerry Weinberg coined the heuristic as "Follow the Energy". Becoming an active listener will help you better understand a team's motivation. A good way to learn this skill is to practice facilitation. Another is to learn to reframe in terms of benefit. As a quality coach, I can frame a suggestion by saying, 'Extra unit tests will make the quality better' or, 'Extra unit tests will get your weekend back'. Which one sounds more appealing to a team of engineers? Another version of the follow-the-energy lens is to look at negative energy. What frustrates people and prevents them from getting their work done? Ben Simo told me a great story about how his team became known as 'the fixers'. They identified pain with/between teams and worked to fix it. When working at Google, Trish Khoo identified her biggest superpower as getting teams to speak to each other. Following the negative energy can be helpful, especially if a team cannot vocalise what they want. It's easier to identify what's blocking you right now than some aspirational end state that neither you nor they believe will come to fruition. Part of your role as a quality coach is to help bring out what people need. Sometimes, it's recognition; sometimes, it's better technical tools, more information, or greater visibility. Do they need that? Perhaps, perhaps not. Time and learning will reveal those insights to all of you. And, of course, never forget about your energy. Make sure [you follow that too](https://www.annemariecharrett.com/voice/). ### Sing your voice URL: https://www.annemariecharrett.com/voice/ Last updated: 2024-01-29T01:21:06.000Z We all have a voice and a song. Sometimes, the song beats loud in our hearts, and sometimes, it's so quiet that you must stop everything else to listen. It's your song. Only you can sing it. No one can sing your song like you do. Sometimes, you might think you don't have a song. You do. There are times you'll want to ignore your voice because it feels like it makes life harder. Your song knows that. It stays with you and holds your hand. You might think you must voice your song for it to matter, that you don't know enough, that you are not strong enough, or that you are not bold enough. That's not true. You are enough. You see, a voice doesn't have to have noise. One of the best ways to be vocal about your song is to say nothing and let actions be the voice. You can do your song, write your song, or say your song. Songs decide how they are voiced, not the other way around. What matters is you listen to your song and, in some way, allow it to be heard. Your song matters to you and all of us around you. ### The Extraordinary in the Ordinary URL: https://www.annemariecharrett.com/the-extraordinary-in-the-ordinary/ Last updated: 2024-02-04T07:27:37.000Z Recently, I’ve heard references to mediocrity in software testing. Statements like “Tolerance of mediocrity has done massive damage to our testing field". There’s an implicit judgment in this statement. In that word mediocre, there’s a suggestion that many in the software engineering field are somehow negligent, lazy or weak. They take the easy path because they want to be liked, looking for approval from other more technical software engineers. Or they chose to remain willfully ignorant, favouring income over ethics. Being mediocre doesn’t mean any of that. It means precisely what you think it does. Being mediocre is to be middling. It’s not terrible, and it's not great. For example, most weekday meals are mediocre. They're not amazing, but they're not awful. Most of us have busy lives; we work full-time, and cooking is not our raison d'etre. A midweek meal offers sustenance and if possible, nutrition. Bonus points if it's tasty! Most of us live with this mediocrity quite comfortably. We don't expect a cordon bleu meal every night. But in the software testing profession, we’re not afforded that luxury. A loud few tell us to demonstrate value we must rise above this middling. Not only rise above it but have zero tolerance for it. Another word for mediocre is 'good enough'. Not great, not terrible. Does the job. As opposed to mediocre, 'good enough' suggests that you're doing your best. You’re not being put on a podium every sprint, but your ass isn’t being hauled in front of management, either. 'Good enough' means you don’t have ALL the words to explain what you mean or do, but you have some. Here are some indicators of 'good enough' work. - All the work you’ve been asked to do, you are performing - You know that there are plenty of things out there you could be doing, but you realise that this work is needed, so you focus on doing that - You know there are many blockers to performing work you would prefer to do; however, these are outside of your control and influence, so you focus on achieving what you can. - You are a social person and enjoy working with a team. Being part of that social construct is important to you. That doesn’t mean you agree or comply with everything that is said, but you are willing to compromise and negotiate to achieve a common outcome - You enjoy learning new things, but family and other commitments are important, so often you prioritise these needs over that. - Sometimes you speak up, sometimes you don’t, and that’s perfectly acceptable. 'Good enough' means you refer to green builds in a blog post without having to justify your intelligence and testing proficiency or face online abuse. **Good enough implies agency.** It suggests you're making informed decisions about context. You don’t have to explain or justify them to anyone unless our work requires it. There is nothing ordinary in being a tester. It’s extraordinary work. It’s tough work. Underrated, underfunded and unloved by many in software engineering. It takes courage, commitment and resilience to turn up and ‘just’ test. Mediocre is good enough. Deal with it. ### Agency is ours to keep URL: https://www.annemariecharrett.com/agency-is-ours-to-keep/ Last updated: 2024-01-11T09:55:48.000Z In software testing, an activity that provides information on the state of quality, we're often in a position where we say "If only". If only we could get developers to do better unit testing if only the requirements were more complete. If only people kept us informed about changes. But by wishing this, we put our ability to achieve outcomes into other's hands. What if we asked ourselves: what's the smallest thing I can do to make things better? What small action can I take to improve the situation? Don't get me wrong. I know how much courage this takes. But I also know how much it benefits our self-worth. So, while we acknowledge that our value is a relationship determined mostly by others, let us also acknowledge that agency is ours. No matter how small that agency might feel. So, somewhat cryptically, having agency also means saying this context is unhealthy for me to speak up in. Another context might be recognising that there is no win, regardless of how hard you try and walk away because wellbeing comes first. Or my tried and and somewhat childish version, flipping the finger, cos I'm worth it. Too much to address here in one post. Catch me in the comments. This topic really interests me, and I want to explore it. And engineering leaders? Your role is to create the space that enables agency. Be their champion. ### 🍾 HYN Quality Coach Newsletter 22 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-22/ Last updated: 2024-01-03T07:40:45.000Z # Tester or Quality Coach? The provocative title of this month's post is *"Should my company ditch testers and use Quality Coaches instead?"* It's that unspoken question that CEOs and testers want to ask. After all, if a CEO can get quality at half the cost, why wouldn't they explore the model? And of course, testers want to keep ahead of the curveball and be ready should their CEO choose to go down this path. ### It's not binary It's a false equivalence, though. A title that attempts to provoke more than inform. Classic polarisation technique. Because it doesn't have to be binary, we can mix and match different operating models. In fact, depending on a team's experience and skill set and depending on the risk profile of the software under development, I can see a company using both quality coaches and testers. For instance, for high-risk work a team can choose to have a tester embedded in a team either on secondment or for full time. Or, the adverse may be true. A team with high agency and experience in testing may decide a quality coach is a better model for them. ### It's the journey A quality coach doesn't replace a tester role, it evolves from it. As a team and company mature in practice and quality activities become a team's collective tacit knowledge, it may make sense to adopt a quality coach model. That's how I first experienced quality coaching when working with a scaleup in a fintech environment. ### A fairytale in tech So, with a nod to Shane McGowan, I penned my own fairy tale, complete with godmother. It tells the story of how quality coaching came about. It's my first time allowing my writing to venture into quasi-fiction. I'm not sure what you're going to think! Let me know! [Should my company ditch testers and use Quality Coaches instead?TL;DR: Quality coaching is a model you grow into, not adopt. That’s because testing is an acquired skill, and teams must learn how to test. Pairing is an optimal way to learn about testing. As teams learn about risks, test design, and exploratory testing, they can preempt risk and![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1512331455279-c8ae8178f586?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDF8fGZhaXJ5JTIwdGFsZXxlbnwwfHx8fDE3MDI4ODYwOTh8MA&ixlib=rb-4.0.3&q=80&w=2000content/images/size/w1200)](https://www.annemariecharrett.com/quality-coaching/) ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## The transient nature of work I co-authored a piece with Artem Yakimenko on the transience of tech and how expecting people to remain in one company for five years + is becoming more of an outlier than the norm. [👩‍💼 Manager hour - the new dynamic world of work 👨‍💼Will you really be in this job 5 years from now? Likely, neither will your people.![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F94af81fc-ee88-4326-b5dc-8f820a0da51d%2Fapple-touch-icon-180x180.png)From Startup To Scale-UpArtem![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7c57dfb-ddff-420a-b5fe-a87b21342c49_600x371.png)](https://startscaling.substack.com/p/manager-hour-the-new-dynamic-world) ## Articles from the Community So much great content being written. In particular, I'm noticing articles re-exploring the value of testers in companies. I find these articles fascinating to read, particularly if the broader engineering community has written them because they reflect what the testing community has been saying for years! 😆 [You are never taught how to build quality softwareLearning how to build quality software is not part of computer science education. How do we learn it?![](https://www.florianbellmann.com/static/favicons/safari-pinned-tab.svg)Florian Bellmann | Be curious, explore and meditate.Florian Bellmann![](https://florianbellmann.com/static/images/blog/never-taught-qa/wall.jpg)](https://www.florianbellmann.com/blog/never-taught-qa?ref=annemariecharrett.com) [Maybe Getting Rid of Your QA Team was Bad, Actually.If you have a QA team, please read this and give them a large raise.![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumDavid Caudill![](https://miro.medium.com/v2/resize:fit:1024/0*wmMiXdIcKXYLWtB3.png)](https://davidkcaudill.medium.com/maybe-getting-rid-of-your-qa-team-was-bad-actually-52c408bd048b?ref=annemariecharrett.com) (nod to [Artem Yakimenko](https://startscaling.substack.com/) for sharing these with me!) [Is Testing BouncingGet rid of testers, then start hiring testers![](https://t1.gstatic.com/faviconV2?client=SOCIAL&type=FAVICON&fallback_opts=TYPE,SIZE,URL&url=https://github.io/2023/12/06/Is-testing-bouncing.html&size=128)Wayne Roseberry, Providing Testing SolutionsWayne Roseberry, Providing Testing Solutions![](https://waynemroseberry.github.io/assets/notestersbounce.jpg)](https://waynemroseberry.github.io/2023/12/06/Is-testing-bouncing.html?ref=annemariecharrett.com) [Reviewing Pull RequestsThis is the second post in a series about asynchronous collaboration. By asynchronous, I mean that people don’t work at the same time. It’s common on distributed teams, especially acros…![](https://s0.wp.com/i/webclip.png)Chelsea TroyView all posts by Chelsea![](https://chelseatroy.com/wp-content/uploads/2019/12/Screen-Shot-2019-12-14-at-11.27.09-AM.png)](https://chelseatroy.com/2019/12/18/reviewing-pull-requests/?ref=annemariecharrett.com) And, great to see Arlene Andrew's post in dev community [Bitten By Async(Thank you to the skilled James Jordan for the cover image -…![](https://res.cloudinary.com/practicaldev/image/fetch/s--eWZ6RXEZ--/c_limit,f_png,fl_progressive,q_80,w_180/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8j7kvp660rqzt99zui8e.png)DEV CommunityArlene Andrews![](https://res.cloudinary.com/practicaldev/image/fetch/s--ct1nwu4K--/c_imagga_scale,f_auto,fl_progressive,h_500,q_auto,w_1000/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/02e3n70scdeelgis5crt.png)](https://dev.to/arleneandrews/bitten-by-async-jii?ref=annemariecharrett.com) And finally, another awesome post by Maaret Pyhäjärvi, this time on model-based testing [Model-Based Testing in PythonIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglIlJPJtuwtBX9R0h278CKAXlqP3U9gzNEHuqo1ITjL0xBN8c6Z2BMB8i-Hl-DkW640dRnZN4wrwy64cS0oTpfvjt9uai4LMjsKS77JRwwaUt1U9bA_9JISuH98zVsAe9rjH1z5r4fSLPmP41SXBfWoEbEMbhUJrzH2wZx1omHmUhcGZsrWWQ3tMFLUw/w1200-h630-p-k-no-nu/de24a9505e1890b7.png)](https://visible-quality.blogspot.com/2023/12/model-based-testing-in-python.html?ref=annemariecharrett.com) cheerio! 🥂 Anne-Marie ### Should my company ditch Testers and use Quality Coaches instead? URL: https://www.annemariecharrett.com/quality-coaching/ Last updated: 2024-01-03T08:06:25.000Z **TL;DR**: Quality coaching is a model you grow into, not adopt. That's because testing is an acquired skill, and teams must learn how to test. Pairing is an optimal way to learn about testing. As teams learn about risks, test design, and exploratory testing, they can preempt risk and build quality into their design. As a team matures in its quality practices, a tester may feel their role becomes redundant. This is a great time to introduce a quality coach. ## A fairytale in tech A long time ago (10 Julian calendar years, centuries in Bezo years), a fairy godmother was asked to devise a way of scaling testing in a hypergrowth company. The independent test team was small then, with minimal automation coverage. The engineering department was hiring rapidly, and as the number of product teams grew, so did the number of features being deployed. Consequently, this test team struggled to test quickly, rapidly becoming a bottleneck. The fairy godmother was wise. While pushed to increase the size of the team and increase test automation, she knew these solutions only patched up a problem that others couldn't see. And, as the team scaled, this problem would only be exacerbated. What the team desired most of all was access to the Book of Knowledge. Of course, the Book of Knowledge wasn't a real book. It wasn't even a confluence page. The Book of Knowledge was the company's songline. Passed from engineer to engineer, these verbal conversations shared the history of any change. The test team desired most of all to be included in these stories. To hear what the changes were and why changes were being made. They knew if they had access to this book, they would begin to understand the why and the what and test with that change in mind. Without the book, they searched aimlessly through code, attempting to figure out what had changed. The fairy godmother sent each tester on a quest. "Go forth, sit among the teams, learn their ways and learn the secrets of the book of knowledge". And so it came to be, the testers slowly began to understand the why and the what. They sat closely with the engineers, pairing to test early and often. They asked questions about changes early on, pointing out impacts to other system parts. The engineers, at first were skeptical. Who were these strangers from a foreign land, unused to their ways of working and unable to code efficiently? But the testers persisted until gradual change came. Engineers began to ask testers for their input. They began to learn their ways. Slowly teams began to embed tester's concerns into their work. Until one day, a very smart tester approached the fairy godmother with a concern. "What shall I do?" the tester wailed. "I no longer have anything to test! The engineers have learned all my wise ways and are doing it themselves!" Thus, the quality coach role was born. Not out of cost-cutting but because of existent team maturity. A quality coach who could help teams maintain quality through facilitation and guidance. Now, the fairy godmother helps other teams and companies shift to a quality coach model. But she has never forgotten that company, where quality coaching was not adopted, but through pairing and coaching emerged. ## FGM's advice to senior leadership. Some words of wisdom for senior leadership. - Quality has a cost, regardless of who does it. Your engineers must have additional time and space to perform software testing and quality-related activities. As a heuristic, if you remove a tester from a team, double the time engineers require to perform the same work. Failing to do so puts stress and possibly unrealistic expectations on teams. - Rolling out a quality coach model without an embedded tester coaching and mentoring a team is possible. Allow for longer timeframes. - Teams that have worked extensively together, have deep domain knowledge, and have the agency to experiment and learn will benefit more from a quality coach model than a newly formed team that has never owned testing without a tester. - Teams will make mistakes, you must allow them the space and time to learn these new skills. - Not all teams will benefit from quality coaching. Allow teams multiple models and let them decide if they need a tester or a quality coach That's it! I hope you all manage to get some rest over the holiday period. See you all in 2024! ### Quality Coach Newsletter 21 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-21/ Last updated: 2023-12-05T03:31:51.000Z This month's guest writer, [Allison Lazarz](https://www.annemariecharrett.com/author/allison/) explains how a story impact checklist can help us improve quality. # Story Impact Checklists in Sprint Planning Alison's article shows us how we can improve product quality early in sprint planning by adopting a checklist to prompt thinking on testing. I enjoyed reading Alison's journey of refining her checklist. Read about how we gradually refined her checklist to meet her team's needs. [Improve Your Sprint Planning with the Story Impact ChecklistEngineering Leadership![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAllison Lazarz![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/11/checklist-3.png)](https://www.annemariecharrett.com/improve-your-sprint-planning-with-the-story-impact-checklist/) ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Moving at the Speed of Trust There is a lot more to come on this topic. It explores the idea that we measure the speed of software delivery by the level of trust we can offer. Perhaps our ability to change things in our system depends on the trust levels we have built. I'm curious to explore what that world might look like. [Move at the speed of trust“Move at the speed of trust. Focus on critical connections more than critical mass—build the resilience by building the relationships.” - Adrienne Maree Brown What is trust? Trust, according to my go-to source of truth, The Thin Book of Trust by Charles Feltman, is built on four elements: \* sin…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1557837847-582372d3765b?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDh8fHRydXN0fGVufDB8fHx8MTY5OTUwNDkyMnww&ixlib=rb-4.0.3&q=80&w=2000content/images/size/w1200)](https://www.annemariecharrett.com/move-at-the-speed-of-trust/) ## Articles from the Community So much great content being written. So much inspiration from great conferences. ### Agile Testing Days 2023 Marianne Duijst shares her unique sketches from Agile Testing Days. Check them out! [AgileTD 2023: Artificial Intelligence, Quality & CommunityThe fifteenth edition of Agile Testing Days took place in Potsdam in November 2023\. I hosted a workshop on Facilitation: Enabling Team Communication & Driving Change and gave a presentation Emb…![](https://marianneduijst.nl/wp-content/uploads/2016/10/cropped-Marianne_Duijst-270x270.jpg)Marianne DuijstMarianne Duijst![](https://marianneduijst.nl/wp-content/uploads/2023/11/AgileTD_-dont-go-breaking-my-code-scaled.jpg)](https://marianneduijst.nl/2023/11/23/agiletd-2023-artificial-intelligence-quality-community/?ref=annemariecharrett.com) ### Is it a bug or a Feature request? Elisabeth Zagroba is a great storyteller, and this one is no exception. Read how feature requests and bugs become blurred and why it happened. [You Don’t Have To Call It A BugAsking a developer to build a new feature got better results than asking them to fix a bug.![](https://elizabethzagroba.com/images/avatar.png)Elizabeth Zagroba: Organizational AnarchistElizabeth Zagroba![](https://elizabethzagroba.com/images/posts/2023/caterpillar.jpg)](https://elizabethzagroba.com/posts/2023/11%5F21%5Fyou%5Fdont%5Fhave%5Fto%5Fcall%5Fit%5Fa%5Fbug/?ref=annemariecharrett.com) ### A year of AppSecurity Read LisiHocke'ss account of her year learning AppSec [AskAppSec - Finding ClosureA blog about learning, agile product development and software testing.![](https://www.lisihocke.com/favicon.ico)Finding ClosureLisi Hocke![](https://4.bp.blogspot.com/-lOAb9PHevTI/XFtkZsDqerI/AAAAAAAADjM/GETEhDEFJn4Tr7QAvkZuetemTcmXmyEZgCLcBGAs/s1600/lisihocke.jpg)](https://www.lisihocke.com/2023/12/askappsec-finding-closure.html?ref=annemariecharrett.com) ### Thank you for raising this! Melissa Fisher shares a valuable insight into the power of gratitude. [Thank you for raising this problem!Do you know what’s really awesome? When you raise a problem / quality concern and someone says to you -![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumMelissa Fisher![](https://miro.medium.com/v2/1*kFrc4tBFM_tCis-2Ic87WA.png)](https://fishouthebox.medium.com/thank-you-for-raising-this-problem-be3fc4271cb8?ref=annemariecharrett.com) That's all for this month! Anne-Marie ‌*Like the Quality Coach Book?* [*Share a testimonial!*](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com) ### Improve Your Sprint Planning with the Story Impact Checklist URL: https://www.annemariecharrett.com/improve-your-sprint-planning-with-the-story-impact-checklist/ Last updated: 2023-11-20T07:41:24.000Z By Allison Lazarz, Software Test Engineer at Cox Automotive ([allison.lazarz@coxautoinc.com](mailto:allison.lazarz@coxautoinc.com)) We’ve probably all been in situations where we’ve looked back at our 2-week sprint cycle and thought, “how did our team forget \[fill in the blank\]?” How did we forget we’d have a dependency on another team? How did we forget that it wasn’t easy to get test data to test this story? A Story Impact Checklist (SIC) is a simple tool your team can utilize *right away* to help you stay organized and prevent recurring problems from impacting sprint work. I’ve had success using it on my scrum teams for the last 8 years. I'm excited to share its benefits with you! **What is an SIC?** As the name implies, an SIC is a checklist of items that might impact the stories in your sprint. It's best used during sprint planning, when the team is discussing what tasks are needed in order to complete a story. Ideally, the SIC will prompt the team to add tasks to your stories that you may have otherwise forgotten. Getting a full picture of the work needed to complete the story during the story tasking phase will help ensure the team makes time to complete all tasks. You avoid being surprised at the last minute and not having enough time to course-correct. The checklist has two main goals: 1. Improve organization and consistency 2. Get team members involved in discussing items that could impact story completion Let’s look at each of these areas. **Improve organization and consistency** By using a checklist, you won’t forget to ask important questions that may get overlooked. It’s easy to think, “we’ll remember that next sprint” and then forget! Using the checklist as a reference will ensure you *do* remember those important questions. Some examples are: do we have the necessary data to test this story? If not, will we need to invest a significant amount of time in creating that data? Or: Do we need monitoring or alerting for this work? Having these discussions sooner than later can help the team plan effectively. Which leads into the next goal of the checklist—discussion! **Get all team members involved in discussing items that could impact story completion** One of the biggest benefits I’ve found with the SIC is that it naturally leads to important discussions about the work ahead. For example, having a discussion around test data could lead the team to realize there isn’t a way to test the story unless a user with the proper permissions is created. Perhaps it’s an involved process to get the user created. What if the team didn’t discuss this ahead-of-time, and instead waited until a day or two before the sprint ended (when the work was ready to be tested)? There’s a good chance the story would carry to the next sprint while the team waited for the user to be created. **Keep It Simple** To start getting results using a Story Impact Checklist, keep it simple and then iterate on it! Jot down a list of items you think your team would benefit from discussing during sprint planning. These can be items related to the type of work your team does (questions about browser testing or API testing) and/or questions that touch on items the team repeatedly forgets. Examples might include: - Should we document this work (and where)? - Do we need a test plan? (Will anyone review it?) - What types of testing will we do (automated, manual)? - Will this work impact existing automated tests? **Iterate, get feedback, repeat!** As you start using the checklist, you’ll likely add to it and remove from it. Mine grew from a list of 10 questions to a list of 14 questions before I heard grumbles about how long it was taking to run through the SIC for each story! I then categorized the items on the list so that the team could skip over irrelevant items. For example, I had a section for “Monitoring and Alerting,” and another for “Browser Testing.” If the category wasn’t applicable to the story, we skipped over all of the items in it. The more the team uses the checklist, the more automatic the thought process becomes around these important items. Once you feel an item on the list isn’t serving you anymore, take it off! I was on a team that had an SIC item for “release the code.” We would create a task each sprint for, “release the code,” because there were multiple occasions where the work was completed but doing the actual code release simply got overlooked. Over time, we were able to remove this item from our checklist because it became a habit and a part of our regular process to release our code after development! **What’s it look like?** Check out a few visuals below that show how my story impact checklist evolved over time. I’ve found the Story Impact Checklist to be a powerful tool for engaging in conversations about quality and testing. I hope you’ll give it a try and please reach out if you have questions about how it could benefit your team! **How My SIC Matured** The SIC is a constant progression. I went through various iterations before reaching my current version. This is based on feedback from my team and my learnings. Here are some examples, starting with my current SIC and working backward. **Version 4**: This is my current version. It is a list of tasks in Rally (our company’s Epic/Feature/Story organization software). Any time a new user story is created, that list of stock tasks is added to it. Our team reviews them after we’ve listed all the tasks we think we need to complete the story. They are our “sanity check” of important items that we want to make sure we don’t forget! - Test Data? - Test Outline? - Test Outline Review? - Verification? - Automated Tests? - Feature Flag? - User Documentation? - Monitoring and Alerting? **Version 3**: This version started a shift in thinking. Creating categories served two purposes. First, it allowed us to eliminate sections that weren’t relevant to the story, making the discussion process faster. Second, it started to help us mentally visualize which items were important to each category. Before we got to the point of running through the list, the team would often come up with tasks that met the different bullet point items because it had become a part of the process. This meant we spent less time discussing each item. Only those items that hadn’t yet been addressed became topics of conversation. **Testing** - Risks/regression testing? - Specific test data? - Automation? - Unit, integration, end-to-end - Need to fix existing automation tests? - Review Acceptance Criteria task? - Test outline and test outline review tasks? **Coding** - User permission/feature flag? - Handling half-processed data? - AWS cost-analysis - Processing, storage, bandwidth? - Documentation? **Monitoring/Alerting** - New Relic/Sumo Logic? - Add PagerDuty alerts? **Releasing** - Do we have a “Live Release” task? - Do we have an “Acceptance of Story” task? - Do we have a failover/rollback plan? - Do we need stakeholder communication? **Version 2**: After finding value in Version 1, the team thought of more important questions to discuss during sprint planning. This worked great for several sprints, then there were grumbles about how long it was taking to go through the list for each story. I decided to revamp it into categories. (See Version 3 below). 1. What’s at risk? What regression testing should be done? 2. Is there specific test data needed to test this? 3. Is there anything in this story that can be automated (including end-to-end automation)?3b. Would it affect any existing automated tests? 4. Do we have or need a fail-over plan? 5. Is this behind a user permission or feature flag? 6. Do group account scenarios need to be considered? 7. Is there a specific browser/platform we need to support for this? 8. Is it sensitive to the network or other latency? Does it need timeouts or circuit breakers? 9. Do we need to consider cache? 10. Are there defined SLAs or performance objectives? Should we performance/stress test it? 11. Do we need new metrics or analytics in place? 12. Did we add a “documentation” task? 13. How will we demo this at Sprint Review? **Version 1**: This was my first pass at questions I thought the team would benefit from discussing.We had such great conversations that we kept adding to it! (See version 2 below). 1. What’s at risk? What regression testing should be done? 2. Is there specific test data needed to tet this? 3. Is there anything in this story that can be automated (including end-to-end automation)? 4. Do we have or need a fail-over plan? 5. Is this behind a feature flag or user permission? 6. Is there a specific browser/platform we need to support for this? 7. Can we load test it? 8. Did we add a “documentation” task? 9. Do we have code review tasks? ### Move at the speed of trust URL: https://www.annemariecharrett.com/move-at-the-speed-of-trust/ Last updated: 2026-04-25T23:11:27.000Z > "Move at the speed of trust. Focus on critical connections more than critical mass—build the resilience by building the relationships." - Adrienne Maree Brown ## What is trust? Trust, according to my go-to source of truth, The Thin Book of Trust by Charles Feltman, is built on four elements: - sincerity (you're honest) - reliability (you're dependable) - competent (you can get the job done) - caring (you have other's interests in mind) ## Trust in Engineering Imagine a world of engineering work where we moved at the speed of trust. To do that, we would have to understand and be guided by: - the trust we have with our customers - the trust we had within our teams - the trust senior leadership had in their teams - the trust our investors have in our senior leadership What would the behaviours with our tribes, customer support and product teams look like? Would we interact any differently? How would we coach and share knowledge? ## Focus on critical connections Who are your critical connections? What is critical for you? For them? Might they be: - Those who have the power to make decisions - Those who unofficially are the decision-makers - Those who decide your performance rating? - Those who dictate time and effort? - Those who hold the purse strings? - Those who listen to you at night when your work has been shit? - Those you hug you when you feel you don't deserve it? ## Build the resilience... Resilience. It's not being super strong. It's having the courage to acknowledge where you are and support yourself as you pick up the pieces. And having people to support you helps you build that resilience. Those who pair with you and explain the numerous times they screwed up after you deleted a critical container. Or when you screw up a config and have a whole network fail. The people who build you up, tell you to be kind to yourself and support you through their acts of kindness are integral to the delivery of our software. Move at the speed of trust.... ## Credits To Mandy Brown for highlighting the concept to me [Change is constantadrienne maree brown outlines the principles of emergent strategy, drawing from the Earthseed verses in Octavia Butler’s Parables series, as well as other sources as diverse as Bruce Lee, Lao Tzu,…![](https://aworkinglibrary.com/favicon.ico)A Working LibraryMandy Brown![](https://aworkinglibrary.com/img/stop.gif)](https://aworkinglibrary.com/writing/change-is-constant?ref=annemariecharrett.com) To Adrienne Maree Brown for writing her ground breaking book on Emergent Strategy [Emergent Strategy: Shaping Change, Changing Worlds : brown, adrienne maree: Amazon.com.au: BooksEmergent Strategy: Shaping Change, Changing Worlds : brown, adrienne maree: Amazon.com.au: Books![](https://www.amazon.com.au/favicon.ico)adrienne maree brown![](https://fls-fe.amazon.com.au/1/batch/1/OP/A39IBJ37TRP1C6:356-9915704-5002946:DXS91S6ZPCGHATT3NRFV$uedata=s:%2Frd%2Fuedata%3Fstaticb%26id%3DDXS91S6ZPCGHATT3NRFV%26pty%3DError%26spty%3DPageNotFound%26pti%3D:1000)](https://www.amazon.com.au/Emergent-Strategy-Shaping-Change-Changing/dp/1849352607/ref=asc%5Fdf%5F1849352607?tag=bingshopdesk-22&linkCode=df0&hvadid=79989544424834&hvnetw=s&hvqmt=e&hvbmt=be&hvdev=c&hvlocint=&hvlocphy=&hvtargid=pla-4583589114406527&psc=1&ref=annemariecharrett.com) David Edgar from the Sydney Tech Leaders who pointed me to Mandy Brown ### Quality Coach Newsletter 20 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-20/ Last updated: 2023-11-07T06:28:44.000Z ## Gap Analysis in DevOps [Gap Analysis in Devops](https://www.annemariecharrett.com/gap-analysis-in-devops/) is this month's article written by [Katya Obring](https://www.annemariecharrett.com/author/katja/) where she talks about the value a quality coach can generate by "mining" the gap. She gives tips to get started, the importance of feedback and aligning with organisational values. Well worth a read. Thanks, Katya for writing a guest post. [Gap analysis in DevopsEngineering Leadership![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettKatja Obring![](https://images.unsplash.com/photo-1615477777908-f0a892b84067?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDc3fHxnYXB8ZW58MHx8fHwxNjk3NjExODg2fDA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/gap-analysis-in-devops/) ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## I am the power And you are, too. We all are. Check out my leadership post that explains we all have energy within us; it's how we shape and frame it. This is one of those life lessons post. Owning and shaping your life takes courage and commitment, and it has brought me deep happiness and contentment. Perhaps not an article for everyone, but who knows, maybe someone out there will find it useful! [I am the powerTo be precise, I am the energy. Power is energy applied. Power can be positive or negative. Energy just is. And that’s what I have. We all have it. But most times, it doesn’t feel like it, especially if things are not working out the way we want. Instead, we![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1466629437334-b4f6603563c5?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDl8fGklMjBhbSUyMHRoZSUyMHBvd2VyfGVufDB8fHx8MTY5NjQ1Njg2Mnww&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/i-am-the-power/) ## Articles from the Community I enjoyed this article from [Maaret Pyhäjärvi](https://www.blogger.com/profile/10362873485942008515?ref=annemariecharrett.com) on pairing and how a tester's role is often about what others are missing. [Anyone can test but...Ideas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDOIyN405ZHrfyoMdfkFnsdV-jrmgiiU7jUTbbyL8QL2N1Y_SZAvoHgrm4CJCTjUQzsUdGOTQmY-UQ6UEccGjy9BMc4WHsnygVnNQQmz8_IiX0Nx184KzLhbkgvTwAboeTzGRM3U9kxgTZ1QHo_ycHF6_WWnB8JydRfbIou9tU4SD-WPnscqjvkTJNKA/w1200-h630-p-k-no-nu/IMG_2970.JPG)](https://visible-quality.blogspot.com/2023/10/anyone-can-test-but.html?ref=annemariecharrett.com) Relatively new blog - Quality Boss aka Brienna Ransom shares her take on the quality assistance model. [Quality Assistance, Not AssuranceAdapted from a post I wrote in 2022 for work. I manage a team of five Quality Engineerings, supporting the work of approximately 100 software developers. A traditional approach to quality and softw…![](https://briennaransomblog.files.wordpress.com/2023/10/cropped-dallc2b7e-2023-10-15-15.43.57-digital-art-kawaii-style-firefly-.png?w=192)Quality Boss![](https://briennaransomblog.files.wordpress.com/2023/10/assistance.png?w=1200)](https://qualityboss.blog/2023/10/18/quality-assistance-not-assurance/?ref=annemariecharrett.com) For those who deal with regulatory requirements, "always honour the spirit of control". ## Anxiety at Work I was at the [Sydney Tech Leaders meetup](https://www.meetup.com/en-AU/syd-technology-leaders/?ref=annemariecharrett.com) this month and listened to Artem Yakimenko talk on practical ways to reduce anxiety at work. Not recorded, but here are the slides [Artem Yakimenko on LinkedIn: Anxiety at Work - A communication guide for leadersIt was great to speak yesterday at the Sydney Tech Leaders. If you missed the talk or want to refer to the slides, they're now published on my Speaker…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInArtem Yakimenko![](https://media.licdn.com/dms/image/sync/D5627AQEc0WJJW00jGg/articleshare-shrink_800/0/1699337926927?e=1699945200&v=beta&t=0X-DIJOQNfffH6MEFbsrQCuSrVpGwHywaFp37-d-qK8)](https://www.linkedin.com/posts/temikus%5Fanxiety-at-work-a-communication-guide-for-activity-7120921564967051264-Yce9?utm%5Fsource=share&utm%5Fmedium=member%5Fios&lipi=urn%3Ali%3Apage%3Ad%5Fflagship3%5Fdetail%5Fbase%3BV23TMhnXROypD6fgvg5EZA%3D%3D) Till next time! ‌*Like the Quality Coach Book? [Share a testimonial!](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)* Anne-Marie ### Gap analysis in Devops URL: https://www.annemariecharrett.com/gap-analysis-in-devops/ Last updated: 2023-10-18T06:54:05.000Z Gap analysis is a tool that helps us explore the space between where we are now and where we'd like to be. It's a way of assessing the disparities in performance to achieve a desired business strategy or specific objectives. In the fast-paced world of DevOps, where continuous integration and delivery are the norms, testing isn't a phase that comes after development; it's an integral part of the entire cycle. Effective testing ensures that we're not just moving quickly but also delivering quality. Just as we strive to bridge gaps in our code, gap analysis enables us to identify the areas where our testing practices might not align with our goals or the broader objectives of our DevOps environment. By analysing these 'gaps', we can make targeted improvements, fostering a culture of continuous learning and growth. ### **How to Start a Gap Analysis** First and foremost, we must be aware of our starting point. What are our existing testing processes? Are we doing manual testing, automated testing, or a combination of both? Understanding the current landscape helps us recognise what's working well and what might be improved. In the ever-evolving world of software development, the tools and methodologies we adopt can make a significant difference. Are we aligned with modern practices? Are our tools aiding us or becoming barriers? An honest evaluation here can provide valuable insights. This is where we put on our investigative hats and start looking for clues. Are there consistent bottlenecks? Are certain types of defects slipping through? It's a chance to be detectives, uncovering the underlying issues that may be holding us back. There are multiple ways to go about uncovering this information, I’ll just mention the two that I find easiest to set me on a track. My first approach will always be to talk to the team, take notes, compare what people (individually and in group sessions like sprint retrospectives) tell me, and look for patterns. Are they all complaining code reviews are a pain point because nobody feels they have time to interrupt what they’re doing to do them? Work out strategies to fix that - encourage pairing, make sure that everybody understands code reviews are high priority items, give them tools for time management, reduce the number of meetings - whatever it takes to unblock this specified thing. The second thing I do is utilise reports from any tools you use. For example, most software development teams these days will use Jira or a similar tool to organise their day to day work. These tools provide you with a multitude of reports you can utilise to spot where the bottlenecks and pain points are. Do the reports correlate with what you hear? Or do they paint a different picture? Either will help you understand and address any gaps in your testing practice. Understanding the current state is like having a roadmap of where you are. It gives you the necessary context to navigate towards your desired destination effectively. ### **Context Matters** Our ideal testing environment shouldn't exist in isolation. Instead, it needs to be firmly rooted in the larger business objectives. So while we look for clues at a team level, we need to align that to our organisations goals too. What are we trying to achieve as an organisation? How can our testing practices support that? Creating this alignment ensures that our work has purpose and direction. Great quality isn't just about tools and processes; it's a culture. So, our desired state must reflect that collaborative spirit, the breaking down of silos, and the seamless integration of development, operations, and testing. A holistic view here ensures that our ambitions fit within our operational model. Now's the time to be both realistic and aspirational. What would a well-oiled testing machine look like in our specific context? This isn't a one-size-fits-all answer but a tailored vision that considers our unique challenges, opportunities, and goals. It can be a bit scary to approach this stage of the process, and how you work out your vision can be different depending on the size of the team or organisation you’re working with. Ideally, I’d involve as much of the team as possible because it is important that we all get on the same page here. Nothing will hinder your quality practice more than a vision that’s not shared by the team, or that’s not realistic in its ambition. Depending on the maturity of your team it can be a good idea to bring in an outside facilitator, like a coach or consultant, who has experience in facilitating these sessions. Defining our desired state isn't merely an exercise in wishful thinking; it's about crafting a deliberate and considered path forward, guided by our values and the principles of Agile. ### **Mine the Gap!** With a clear understanding of where we are and where we'd like to be, we can now investigate the gaps. This comparison isn't about assigning blame or finding fault; it's a thoughtful examination of the differences between our current practices and our aspirations. Gaps are opportunities in disguise. By pinpointing where we're falling short, we can create targeted strategies to bridge these gaps. Whether it's a need for more automation, better collaboration, or a shift in our testing mindset, these identified areas are our roadmap to improvement. Agile isn't a rigid methodology; it's a flexible, adaptable approach. When conducting a gap analysis, we should embrace that agility, allowing ourselves to iterate, learn, and adapt as we uncover new information and insights. Conducting the gap analysis is like a treasure hunt, seeking out the hidden gems that will guide our growth and development. It's about curiosity, exploration, and the willingness to question our practices in pursuit of continuous improvement. ### **Ongoing efforts** Continuous testing isn't merely running automated tests regularly; it's about creating a feedback loop that informs the entire team. It aligns with the idea of "whole-team responsibility" for quality by moving away from the idea of a “testing” phase at the end of the SDLC and looks at ways to apply quality thinking earlier in the process. How well does your team slice tasks? Are features well understood before development starts? Have you collected data to verify you’re solving the right problems? All these are questions that can set you on the right path for moving testing left. Breaking down silos isn't a one-time event; it's a continuous effort. Collaborative practices foster better communication and understanding, leading to more effective and efficient testing strategies. Automation is not the solution to everything, but it can be a powerful tool for bridging certain gaps, particularly where speed and repeatability are concerned. The key is to implement it judiciously, complementing rather than replacing human insight and judgement. ### Implementing Gap Analysis Strategies for bridging the gaps are where theory meets practice. It's about taking the insights gleaned from our analysis and translating them into actionable steps that bring us closer to our desired state of effective testing within our organisation. ### Measuring Success in Gap Analysis Success must be measurable. What KPIs best reflect the health and efficiency of our testing process? It could be defect detection rates, the speed of testing cycles, or customer satisfaction scores. By choosing meaningful KPIs, we can track our progress and adjust as needed. In the spirit of Agile and continuous improvement, regular reviews are essential. Are we moving closer to our desired state? If not, what needs to change? It's about fostering a culture of ongoing learning and adaptation. Our testing strategies must always align with our broader objectives. Regular alignment checks ensure that we're not only improving our testing practices but also contributing to the overall success of our initiatives. Measuring success is not just about numbers and charts; it's about understanding our impact, learning from our experiences, and continually striving to be better. It's a mindset that embraces growth and values the journey as much as the destination. ### **It's a journey** Gap analysis is more than an exercise; it's a strategic journey from where we are to where we aspire to be. By systematically assessing our current state, defining our desired state, conducting an analysis, creating strategies, and measuring success, we unlock pathways to continuous improvement in our testing practices within our environment. This isn't a one-off solution but a living, breathing approach that grows with us. It's about being reflective, adaptive, and intentional in our pursuit of excellence. In the dynamic world of software development, where change is constant, a commitment to continuous improvement is not just beneficial; it's essential. Gap analysis is one tool in our toolkit, a lens through which we can view our practices, find opportunities for growth, and foster a culture that values quality and collaboration. With the conclusion, we've come full circle, encapsulating the process, value, and philosophy of using gap analysis to enhance our testing practices. It's a call to action and reflection. And the same principles apply if you’re not a DevOps organisation, you can still use the gap analysis to improve your quality game. ### I am the power URL: https://www.annemariecharrett.com/i-am-the-power/ Last updated: 2023-10-04T23:46:29.000Z To be precise, I am the energy. Power is energy applied. Power can be positive or negative. Energy just is. And that's what I have. We all have it. But most times, it doesn't feel like it, especially if things are not working out the way we want. Instead, we go to (SFD) Shitty First Draft\* mode. It's that story my internal voice sells as the absolute narrative. In my SFD, it typically a record along the lines of, "You're not good enough", "it's unfair", "you were never going to succeed", "Everyone hates you"..blah blah blah. You probably have your unique version of SFD that's been carefully crafted over the years. It's taken me experience, reading Brene Brown and a few life lessons to see and understand Shitty First Drafts for what they are. It's my brain's immediate reaction to an incident. And importantly, it's not necessarily true. Ignoring these stories is hard because they're so ingrained. They're almost like a comfort blanket. Weirdly, SFD confirms that I and the world are the awful places I need them to be. This act of protection is not the badass move my brain seems to think it is. Acknowledging this narrative is the first step to working from a different perspective. Once you identify and acknowledge your SFD, you can reframe the narrative into something more positive and healthier. Reframing is the power converter for your energy. If your SFD is your AC (alternating current), Reframing takes that SFD with all its drama, stormy weather and absolutes and converts it into the DC (Direct Current) of logic and reasoning. This story is way more balanced and suitable for personal growth. This new story is practical, healthy, and far more beneficial to where I want to be. We decide how to convert our energy into power. We can convert energy into a constructive or destructive force. And while we tend to lean toward destructive power. It doesn't have to be that way. We can reframe our narrative and convert that energy into a positive force. It's our choice. \*Brenee Brown calls it Stormy First Draft now. The term SFD comes from her book [Rising Strong](https://brenebrown.com/book/rising-strong/?ref=annemariecharrett.com). I prefer Shitty First Draft. ### Quality Coach Newsletter 19 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-19/ Last updated: 2023-09-28T21:43:08.000Z ## Quality is everyone's accountability What does "Quality is everyone's responsibility" actually mean? What do you mean by Quality? What do you mean by responsibility? And if everyone is responsible for quality, does that mean one outcome is poor quality? Software engineering is complex and challenging enough without introducing additional ambiguity into a system. Being clear about who owns what helps with that. This is especially important if introducing new concepts and roles (such as a quality coach). This month's premium article looks at the role of accountability in quality and how people can clarify these roles. It includes a Miro board to help you and your team or your leadership work through at an organisation level who owns what. This can be helpful, particularly if you have a platform team that owns the testing frameworks, with product teams owning test creation. [Quality: We need to talk about accountabilityWe all have accountabilities in quality. But what they are will vary according to role and seniority.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/09/Quality-RACI-Map-1.jpg)](https://www.annemariecharrett.com/everyone-is-accountable-for-quality/) ## Sign up for Anne-Marie Charrett Engineering Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Links from the Community There are some great articles from the community this month. Dig in and enjoy! [My Journey from Testing to Quality!This year I celebrated 16 years in the technology industry. Prior to this time, I had worked in many different roles and industries from Parcel Delivery Customer Services to NHS Administration.![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)Philippa Jennings![](https://media.licdn.com/dms/image/D4E12AQE_q3zIX7hYCw/article-cover_image-shrink_600_2000/0/1695920300711?e=2147483647&v=beta&t=NjZXTAMQkdyLgq45zsaitMR3oiqL-T1Z6B3XwKLfbtM)](https://www.linkedin.com/pulse/my-journey-from-testing-quality-philippa-jennings/?ref=annemariecharrett.com) [Quality Gardeners and Quality Coaches at Job&TalentHow we implemented Quality Assistance in teams while Job&Talent Engineering was changing its structure.![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)Job&Talent EngineeringJob&Talent Engineering![](https://miro.medium.com/v2/resize:fit:1200/1*2CKxTk2LZJKxjdh9Tc72bw.jpeg)](https://jobandtalent.engineering/quality-gardeners-and-quality-coaches-at-jobandtalent-52ca42de6917?ref=annemariecharrett.com) [After 171 Days - What is Quality Engineering Consulting? - Developer SamIt’s been more than 5 months since I started at Quality Minds and shifted from working as a software developer to a quality engineering consultant. I thought I would soon be doing a lot of test automation, using Cypress or Playwright, but instead of that, something totally different happened![](https://developer-sam.de/wp-content/uploads/2021/01/cropped-darthsam_a3lpc-1-270x270.png)Developer SamSam![](https://developer-sam.de/wp-content/uploads/2023/09/sam_climbing_wall.jpg)](https://developer-sam.de/2023/09/after-171-days-what-is-quality-engineering-consulting/?ref=annemariecharrett.com) [Stop Talking About the Work and Just Do It.Turning a backlog into an application in under 60 minutes.![](https://elizabethzagroba.com/images/avatar.png)Elizabeth Zagroba: Organizational AnarchistElizabeth Zagroba](https://elizabethzagroba.com/posts/2023/09%5F24%5Fstop%5Ftalking%5Fabout%5Fthe%5Fwork%5Fand%5Fjust%5Fdo%5Fit/?ref=annemariecharrett.com) That's it! Have a yippee weekend folks. ‌*Like the Quality Coach Book? [Share a testimonial!](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)* Anne-Marie ### Quality: We need to talk about accountability URL: https://www.annemariecharrett.com/everyone-is-accountable-for-quality/ Last updated: 2026-04-30T08:31:45.000Z Quality is everyone's responsibility, right? But precisely what does that look like? Having a basic understanding of what quality means for your organisation is essential. You can do [quality workshops ](https://www.annemariecharrett.com/quality-workshop/)to get a shared agreement. But what about the responsibility bit? What does that mean for a product team, Director of Engineering, VP of Engineering, or even a CTO? And how does responsibility differ from accountability? As a director of quality engineering, it will be on you to help your peers, senior leadership and teams to understand and come to a consensus on who owns and who is accountable for quality. If you don't, people will make assumptions about what you do. ## **Responsibility versus Accountability** These two words seem almost identical, but there's a subtle difference. Responsibility indicates owning a task or a thing. Accountability expands responsibility to include owning the consequences of responsibility normally measured by actions taken(or not taken). Accountability = Responsibility + Impact of Actions So when we say everyone is responsible for quality, we indicate that we all own quality regardless of the outcome. That may not be what we want. What we might want to mean (especially in the context of quality coaching) is that a team is accountable for quality; the team owns the consequences of actions that result in poor or sound quality. As a quality coach, having discussions around this distinction is vital. Do you understand what you are accountable for? And what you're responsible for? Do your manager, peers, and teams have a different perspective? I've been writing about quality for 30 years. Now you can ask that body of knowledge a question — free. [Try the free taster →](#) ## **Accountability: Responsibility’s evil twin** Let's face it: the word accountability comes with baggage. Accountability has an association with consequences. Consequence suggests failure. Ideally, accountability should be neutral. The impact of actions can be either (or both) positive and negative. Taking accountability for good outcomes feels excellent! But in many cases, that's not how it's used. How many of us have experienced blame in a PIR for allowing bugs into the wild? If accountability is not explicit, people will assume and allocate some accountability to you. And it may not be one you like. Teams may accept that we are all responsible for quality, but VPs of Engineering believe that final accountability sits with the quality coach. Directors of Engineering may assume teams are accountable for quality, failing to realise they are accountable for ensuring teams have the necessary skills and time to build quality into the product. ## **Accountability in Quality** We all have accountabilities in quality. But what they are will vary according to role and seniority. For example: - As a team quality coach, I'm accountable for ensuring that the team has the necessary skills and tools to perform quality-related activities - As a team, we're accountable for bugs in the wild - As a Director of Engineering, I'm accountable for ensuring teams have sufficient bandwidth to deal with tech debt - As a VP of Engineering, I'm accountable for engineering quality aligning with business and market and allocating suitable budgets to tooling and training. - As Product Manager, I'm accountable for setting expectations around the importance of quality and its tradeoff with speed. ## **Using RACI as a Quality Coach** RACI (Responsible, Accountable, Consulted, Informed) is a much-loved or loathed framework. The RACI model defines responsibility as 'doing the work' instead of owning the work. I've used RACI to help manage conversations around quality and who is accountable for what. This is useful, especially as the quality coach role is new and unfamiliar to many. This gives people certainty that tasks are not being overlooked or inadvertently dropped. Here's a[ ](https://miro.com/app/board/uXjVMltV0lA=/?share%5Flink%5Fid=830890736613&ref=annemariecharrett.com)[miro version of a Quality RACI model](https://miro.com/app/board/uXjVMltV0lA=/?share%5Flink%5Fid=6069611802&ref=annemariecharrett.com) I've used to good effect. Work out your stakeholders and critical categories. I've chosen Test Automation, Strategy, CI/CD Infrastructure, SLO's Test Environments, Process, Metrics and Risk Identification to demonstrate how the RACI works. As your context differs, you will likely have different categories. You will also have different stakeholders. [![Quality RACI Model by Anne-Marie Charrett](https://lh3.googleusercontent.com/A76lPg-SPtMgH7YwHwZ-R_YzPgft3gDf6f6N1xag_s2WUhyYOlH9HbOXIXazj0LIW2DbSzp1glnG_3k6PFXLfRqjgCLIyMPVZPWnQIng3yGO-P8nMoGm47AKYPPiP_lU9AYZGcSgolwRXNEfhEjNUGs)](https://miro.com/app/board/uXjVMltV0lA=/?share%5Flink%5Fid=6069611802&ref=annemariecharrett.com) It may be helpful to get more granular by having different RACI for team, senior leadership, and platform contexts. And remember, the purpose of the RACI is to have that discussion, not once, not twice, but over and over each time the organisation restructures or significant senior hires are made. ## An alternative approach without RACI When working with senior leadership, RACI is helpful as it offers clarity. However, within a team, a more consultative approach can be beneficial. Try this excellent post written by [Katrina Clokie](https://katrinatester.blogspot.com/2018/06/3-ways-to-define-your-role-without-raci.html?ref=annemariecharrett.com) on [3 ways to define your role without a RACI matrix](https://katrinatester.blogspot.com/2018/06/3-ways-to-define-your-role-without-raci.html?ref=annemariecharrett.com). What do you think? Have you used something similar in your company? *Thanks to* [*Nick Pass*](https://www.linkedin.com/in/nickpass/?ref=annemariecharrett.com) *and* [*Nick Lee*](https://www.linkedin.com/in/nicholasllee/?ref=annemariecharrett.com) *for reviewing and offering feedback.* ### Quality Coach Newsletter 18 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-18/ Last updated: 2023-09-07T18:30:54.000Z ## This month [Neil Younger](https://www.annemariecharrett.com/author/neilyounger/) returns with the final of his three post series on developing engineering cultures. Today's post on developing a growth-based framework builds on Neil's two previous posts; building a [learning culture](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/) by amplifying team wins and [accelerating a quality culture ](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/)through building engineering capability. I like how this post builds a framework that focuses on engineering at a team level and then leans on a community of practice to amplify that knowledge across engineering. Definitely one to check out! [Boost your engineering capability with this growth-focused frameworkℹ️In this article, we will use the term ‘Engineering Capability’ to mean the practices and approaches we use to get work done within an engineering department. This article extends and references the work of two previous publications in this series. Namely ’Accelerate your quality culture by ident…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettNeil Younger![](https://images.unsplash.com/photo-1516880711640-ef7db81be3e1?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDY0fHx0ZWFtfGVufDB8fHx8MTY5MTkzMDA0MHww&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/engineering-capability-model/) Premium readers, what would I do without your continued support? Thank you!🙌 If you haven't read it, [log in](https://www.annemariecharrett.com/engineering-capability-model/) using your premium membership. ## Sign up for Anne-Marie Charrett ### Home of Quality Coach Book. Tech Leadership Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ## Related Posts Of course, the other two posts by Neil are a must read too. Full of practical advice and templates to run workshops, you'd be crazy to miss out on these. [Build a culture of learning by amplifying team winsNeil Younger talks about amplifying success to drive change in this latest quality coach book article![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettNeil Younger![](https://images.unsplash.com/photo-1578269174936-2709b6aeb913?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDN8fHdpbm5pbmd8ZW58MHx8fHwxNjgwMDA5NTA4&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/) [Accelerate your quality culture by identifying your engineering capability needsHome of Quality Coach Book. Tech Leadership![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettNeil Younger![](https://images.unsplash.com/photo-1489641024260-20e5cb3ee4aa?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDF8fGpvdXJuZXl8ZW58MHx8fHwxNjg2MTQ0MTQwfDA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/) ## **Round the neighbourhood** Are you interested in learning how to assess quality practices? Check out this video chat by Lisa Crispin, Janet Gregory and Selena Delesie. [New video chat: Assessing Quality Practices with QPAM - Agile Testing with Lisa CrispinNew Agile Testing Fellowship Donkeys & Dragons video chat about quality practices assessment model QPAM with Janet Gregory & Selena Delesie![](https://lisacrispin.com/wp-content/uploads/2016/11/donkey-144.gif)Agile Testing with Lisa CrispinLisa Crispin![](https://lisacrispin.com/wp-content/uploads/2023/08/Screenshot-2023-08-15-at-3.59.48-PM.png)](https://lisacrispin.com/2023/08/15/quality-practices-assessment-with-qpam/?ref=annemariecharrett.com) This article on responsible AI was brought to my attention by Trish Khoo. [With great AI power comes great responsibilityRecent advances in deep learning techniques have led to the emergence of bigger and better models and increased adoption in mission-critical settings (self-driving cars, healthcare, malware detection, etc.). Thinking about the complexity of our lives and real-world contexts makes it somewhat…![](https://mmc.vc/apple-touch-icon.png)MMC Ventures![](https://mmc.vc/resources/placeholders/_1200x630_crop_center-center_82_none/mmc-social-card-1.png?mtime=1592300111)](https://mmc.vc/latest/with-great-ai-power-comes-great-responsibility?ref=annemariecharrett.com) And Constance Hermit brought this one to my attention. [The Expanding Dark Forest and Generative AIProving you’re a human on a web flooded with generative AI content![](https://maggieappleton.com/images/favicon/apple-touch-icon.png)Maggie AppletonLuciano Strika![](https://maggieappleton.com/images/og/fe37968757d0ac03e4b01c7496b2e8ac.png)](https://maggieappleton.com/ai-dark-forest?ref=annemariecharrett.com) ## Upcoming Events I'm speaking at LAST in Sydney on "Agile up your leadership game". A version of my Agile 2023 keynote. [LAST Conference Sydney - 22 Sept 2023LAST Conference Sydney is an affordable, grassroots mini-conference for people involved in digital product development. The schedule encourages participation and interaction via talks, workshops, and activities.![](https://www.lastconference.com/sydney/wp-content/uploads/sites/3/cropped-cropped-Untitled-design-19-270x270.png)LAST Conference SYD![](https://www.lastconference.com/sydney/wp-content/uploads/sites/3/2-1.png)](https://www.lastconference.com/sydney/?ref=annemariecharrett.com) Also, I'll be at Yow! in MPing at Sydney at the Tech Leaders Summit on the 8th of September. Maybe I'll see you there! [Home - YOW! Tech Leaders Summit Sydney 2023![](https://yowcon.com/images/favicons/yow-3f1aef9d0278d5569f0275367bad6301.ico?vsn=d)ThoughtworksTrifork![](https://yowcon.com/images/conferences/yow-b95cbbafe522ab349b89741aedad1925.jpg?vsn=d)](https://yowcon.com/tech-leaders-sydney-2023?ref=annemariecharrett.com) These conferences have a long-standing commitment to community and hold a place in my learning path. Thanks for all your hard work folks! Until next month, Anne-Marie ‌ ‌*Like the Quality Coach Book? [Share a testimonial!](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)* ### Boost your engineering capability with this growth-focused framework URL: https://www.annemariecharrett.com/engineering-capability-model/ Last updated: 2023-09-12T08:02:12.000Z ℹ️ In this article, we will use the term ‘Engineering Capability’ to mean the practices and approaches we use to get work done within an engineering department. This article extends and references the work of two previous publications in this series. Namely ‘[Accelerate your quality culture by identifying your engineering capability needs](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/)’ (the Capability phase) and ‘[Build a culture of learning by amplifying team wins](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/)’ (the Growth phase). While not essential it might be helpful to have a read of those articles first as they provide practical examples of applying this framework in the two phases. In this article, we focus on the complete framework and in particular the mechanisms that bind the two phases of Capability and Growth together. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/08/Screenshot-2023-08-27-at-10.57.55.jpg) The model provides guiding principles and a framework for growing the technical capability of an engineering department. The model aims to foster a culture where teams can learn, experiment, and grow together while sharing their success with others. ## How can this framework help? ![a group of people holding hands on top of a tree](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/08/photo-1527525443983-6e60c75fff46.jpeg) Photo by [Shane Rounce](https://unsplash.com/@shanerounce?ref=annemariecharrett.com) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) - There can be lots of moving parts in an engineering department. This framework helps aid discussions and help build a culture where it no longer becomes necessary. - It is holistic in its approach in that it doesn’t prescribe particular practices. Instead, it provides a framework for a team or a department to enable them to collectively scale the skills they are good at and facilitate the need to learn and develop at pace. - It promotes practices that can help reduce the effects of siloing knowledge and information that can often occur in large organisations. - It can catalyse an environment, a culture, where we can incorporate learning and growth into our work. - The heart of this model is one team. However, it's designed to amplify and scale across multiple teams and departments. ## Exploring the framework in more detail This model is a decision-making tool to help you focus on key capabilities and the steps required to grow those capabilities. By following the steps in this model, you can take your thinking through the key dimensions that might impact your overall engineering capability plan. ![Engineering Capability Framework diagram](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/08/image-17.png) Engineering Capability Framework The following sections will explore these steps in more detail and provide ideas and guidance on the supporting mechanisms that tie them together. ### 🏗️ Understanding the context you work in The work a team does and how they operate can influence what good looks like for them. Exploring and understanding this is essential as it impacts everything that follows. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/08/image-4.png) Examples of different Teams, including those made famous by [Team Topologies](https://teamtopologies.com/?ref=annemariecharrett.com) There will likely be common themes independent of your work and how you operate. Concentrating on these and the differences will make it easier during the Growth phase. ### 🏗️ Know what good might look like for you and the next step for improvement Inspiration of what good looks like might take several forms. Perhaps you have a [Team Charter (or Canvas)](https://alexeyivanov.com/team-canvas/?ref=annemariecharrett.com), or perhaps your company has a [Technology Radar](https://www.thoughtworks.com/radar?ref=annemariecharrett.com) (covering Techniques, Tools, Platforms, and Frameworks) that you can draw from. Maybe a direction has been set related to one, or all, of the categories by senior management, staff engineers, architects, agile coaches, etc. Other such examples include, but are not limited to; - Departmental engineering practices and standards - Team agreements on ways of working - A development framework such as [Scrum](https://en.wikipedia.org/wiki/Scrum%5F%28software%5Fdevelopment%29?ref=annemariecharrett.com), [Kanban](https://en.wikipedia.org/wiki/Kanban%5F%28development%29?ref=annemariecharrett.com), [Extreme programming (XP)](https://en.wikipedia.org/wiki/Extreme%5Fprogramming?ref=annemariecharrett.com), etc. The article [‘Accelerate your quality culture by identifying your engineering capability needs’](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/) provides a framework where you can explore and detail what good looks like for you and your team. It complements your existing material on what good looks and is a mixture of agreed company software practices and team aspirations for improvement. It also helps to define the next step in your journey which often isn’t part of engineering guidelines and practices. When looking to improve, start with an ***Aspiration***. This aspiration will be informed based on the work you did around knowing what good looks like. ![Aspirations create experiments that if succussful lead to agreed practices](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/08/image-18.png) How team aspirations can lead to departmental practices Next, propose an ***Experiment*** that you can run in your team that helps work towards this aspiration. Ideally, one experiment at a time so you can measure the benefit. Over time, and assuming success, the experiment might promote itself into an ***Agreed Practice*** for your team and maybe, also for your department. *If unsure where to start, head to [Accelerate your quality culture by identifying your engineering capability needs](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/) for practical help.* [![An example from the workshop ‘Accelerate your quality culture by identifying your engineering capability needs’](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/08/Screenshot-2023-06-07-at-15.18.30.jpg)](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/) An example from the workshop ‘Accelerate your quality culture by identifying your engineering capability needs’ 💡 Regardless of the approach you use here, I encourage you to theme or categorise, the improvement areas. A common language around this makes scaling departments, sharing resources, and supporting the growth phase easier. ### 🛠️ A systematic engineering-wide mechanism to pull in the skills you need and the support for growth and sharing Without a deliberate mechanism that actively supports and enables both the Capability and the Growth parts of the framework, you are largely leaving success to chance. You don’t have to implement it in the way described here but it is vital to take the time to ensure you have something in place. An additional outcome is the supporting mechanisms needed to make the model successful help to promote and build practices that by themselves have many additional benefits. One such mechanism is Communities of Practices. ℹ️ “Communities of practice are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.” (**Etienne and Beverly Wenger-Trayner*) Central to this framework are two supporting systematic engineering-wide approaches; - A [Community of Practice](https://en.wikipedia.org/wiki/Community%5Fof%5Fpractice?ref=annemariecharrett.com) that can offer experienced-based support and guidance around said experiments, approaches, technical knowledge and practices. This serves as a place for teams to promote their good practices while supporting other teams to pull said practices into their way of working. - A single repository of engineering knowledge that details the experiments and successful ways of working from various teams. By doing so, we start to create a library of good practices and technical abilities categorised according to the department or business need. This enables and makes it easier for, all teams to pull from these groups of practices when they identify an area they would like to improve in. Having these same systematic engineering-wide mechanisms supporting both phases (Capability and Growth) of the framework makes it easier to scale, reduces complexity, increases the adoption of good practices, and helps promote a learning and growth culture. ### 🌻 Understanding the needs of others There are many formats for teams to celebrate success and ways of working. The approach described in the article ‘[Build a culture of learning by amplifying team wins](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/)’ takes the additional step of thinking where practice could be shared and, importantly, attempts to tie that back to the department or business's collective learning and development goals. In this way, sharing becomes a deliberate act targeting the needs of others and the business. ![An example from the workshop ‘Build a culture of learning by amplifying team wins’](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/08/image-12.png) An example from the workshop ‘Build a culture of learning by amplifying team wins’ The key thing to remember is that sharing becomes a deliberate act targeting the needs of others and for that to be successful you must know what these needs are. Communities of Practice can be fundamental in understanding these needs. Simply sharing without thinking of the needs of others won’t be enough. *If unsure where to start, head to [Build a culture of learning by amplifying team wins](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/) for practical help.* ### 🌻 Celebrate your success Celebrating your success will always be important, but it brings additional benefits in the Engineering Capability Model context. - It can generate excitement and engagement in other teams - It can help promote cross-team collaboration - It can support the mechanisms for sharing and engagement in a Community of Practice Making the celebration a key part of the model puts people and teams at the forefront. ## Where should you start? While the model flows left to right starting at ‘Understanding the context you work in’, it doesn’t always need to start at the beginning. It's a cyclic loop so you can start anywhere though I’d suggest you take the time to understand the model first. You also don’t need to always start with the whole model. I like introducing the Growth part first and then building on top of that. This is often much more comfortable for teams that likely already have a culture of reflection and sharing. In this regard, the workshop and structure described in the article ‘[Build a culture of learning by amplifying team wins](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/)’ can be completely standalone. By starting with Growth first, you can build experimentation, learning, collaboration, and sharing patterns that make the Capability part much easier. Alternatively, if you have Communities of Practice that want to define what good looks like for them and their members then a good starting point will be within the Capability part. Consider starting with a single team first, assuming there is no pressing need to apply this to the whole department in one go. This allows you to refine the model to suit your context, have examples you can share with others, and build champions in the team to help spread the message. ## What’s in it for you and your team? As a Quality Coach introducing this to a team, you might want to convey what they will get out of this personally. - You, and your team, have the potential to be at the centre of improving engineering excellence across your company. - It can provide a common approach for championing what makes you and your team unique. - As this is a ‘pull’, and not ‘push’ model, you can choose how and what knowledge your team needs and when they want it. - It promotes team autonomy, while also providing guidance and suggestions for you to run with. ## Frameworks are great, but what matters is you ![brown wooden letters spelling Go For It](https://images.unsplash.com/photo-1607000975574-0b425df6975a?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDN8fGFjdGlvbnxlbnwwfHx8fDE2OTE5MzA1MTR8MA&ixlib=rb-4.0.3&q=80&w=2000) Photo by [Brett Jordan](https://unsplash.com/@brett%5Fjordan?ref=annemariecharrett.com) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit) The framework isn’t important, it is a tool to enable you to think about the complex nature of building a culture of continuous improvement and growth within your team or department. The framework isn’t as important as actually starting something. It's great as a tool to guide, support, and facilitate but without the action that follows it's largely ineffective. Start small, run an experiment, share your success and it's surprising just how quickly things can change. The framework isn’t important, you are 😃 ## ### 🦋Quality Coach Newsletter 17 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-18-2/ Last updated: 2023-09-20T23:13:43.000Z ## Prevent, Detect, Recover Three words to get your team starting to think about quality right away! 😉. [Prevent, Detect, Recover (PDR) ](https://www.annemariecharrett.com/prevent-detect-recover/)is one of my favourite concepts to use with teams. It sticks and helps teams understand that quality is broader than testing. The [latest quality coach article](https://www.annemariecharrett.com/prevent-detect-recover/) is on this topic. Premium subscribers go ahead and have a read by logging in. ## PDR in coaching upwards You can see how I've used PDR as a coaching tool in [Quality Opportunity Solution Tree](https://www.annemariecharrett.com/quality-solution-opportunity-tree/). In this post, I've taken [Teresa Torres](https://www.producttalk.org/about/?ref=annemariecharrett.com) concept and applied it to the context of quality. [Leadership in Tech is like a corsetLeadership is a corset. Are you aware of its constructs? A Leadership in tech perspective on leadership failures and a path forward![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/DALL-E-2023-06-28-21.09.48.png)](https://www.annemariecharrett.com/what-colour-is-your-leadership-corset/) [Prevent, Detect and Recover your way to predictable releasesThe quest to deliver software predictably focuses on small batches. Prevention, detection & recovery of incidents reduce unplanned work is another way to improve predictability![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1586974175094-0a7259238613?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDgyfHxwcmV2ZW50JTIwZGV0ZWN0JTIwcmVjb3ZlcnxlbnwwfHx8fDE2ODk2NzM1Nzd8MA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/prevent-detect-recover/) ## Content from the Community A lot of content this month. I couldn't put it all in so here are some ideas and posts I've found interesting. [🫱🏾‍🫲 How to Introduce QA Practices to Your Organization🖥️ Whether your tech stack is brand new or teetering with age, any time is a good time to introduce Quality Assurance practices within your organization. What do I mean by QA practices? For this article, QA practices are defined by specific standards set within an organization that increases the pr…![](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe132144b-f5e5-48fc-9fbb-352173a4ecaa%2Fapple-touch-icon-180x180.png)Failure is FeedbackJudy Mosley![](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0be4cd6c-e8a6-4777-b7ec-b239e6ebe199_128x128.png)](https://failureisfeedback.substack.com/p/how-to-introduce-qa-practices-to) [Growing an experiment-driven quality cultureLearn about the actionable steps you can take to achieve an outstanding quality culture via experimentation.![](https://leaddev.com/themes/custom/leaddev/favicon.ico)Homepage linkLisi Hocke![](https://leaddev.com/sites/default/files/styles/linkedin_card/public/2023-06/Growing%20an%20experiment-driven%20quality%20culture_0.png?itok=YXCB1dCR)](https://leaddev.com/process/growing-experiment-driven-quality-culture?ref=annemariecharrett.com) [On Expanding Universes and Fixed EnvelopesDuring the dotcom boom in the 1990s, I worked for a VC-funded internet startup. We ran on “web time” and took a move-fast-and-break-things approach.![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)Elisabeth Hendrickson![](https://media.licdn.com/dms/image/D5612AQFlbfpyKsOn3A/article-cover_image-shrink_720_1280/0/1688755094272?e=2147483647&v=beta&t=uFGjd4wsRkvcSfnJ8ZTogP4wf5QpukDY7BnC5J8y4vQ)](https://www.linkedin.com/pulse/expanding-universes-fixed-envelopes-elisabeth-hendrickson/?ref=annemariecharrett.com) That's it for this month! By the way, Agile 2023 was amazing. What a warm and welcoming community and keen to embrace other communities. And yes, the keynote was well received. ![Agile 2023 Opening Keynote: Agile up your leadership game](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/07/IMG_4907.jpeg) Agile 2023 Opening Keynote: Agile up your leadership game See you next month! Anne-Marie ### Prevent, Detect, Recover URL: https://www.annemariecharrett.com/prevent-detect-recover/ Last updated: 2023-08-28T23:32:16.000Z Prevent, Detect, Recover (PDR) is a thinking tool I use to help teams consider quality beyond testing. PDR stands for: - Prevent: activities that can be performed to prevent incidents happening in the first place. - Detect: activities or approaches that allow the discovery of incidents before deployment and release. Testing is one such activity. - Recover: activities or approaches that enable faster recovery. PDR allows teams to consider quality across ALL delivery, not just in the testing phase. Let me explain more. ### Quality != Testing Most teams underestimate how much time, expertise, and complexity goes into quality-related activities. When it comes to quality, common mistakes I see are: 1. Teams only focus on testing as the quality activity. 2. Teams rarely think about testing until after code is written. 3. Teams believe testing is quick and easy. As a result, teams often underestimate the cost of quality. They fail to consider how to maintain and recover systems post-deployment. Instead, they typically focus on testing at the expense of other approaches. For example: 1. Teams don't think about other aspects of quality such as performance, security, and scalability until there are related issues, and the resulting cost to fix this is higher post-production. 2. Teams overlook a poor CI/CD process's impact on product quality. 3. Teams only think about automated alerts after deployment, where pressure is often on to move on to the next feature. 4. Teams either over-index on critical user journeys (CUJ) and create too many Service Level Objectives (SLO) or they don't write any SLOs mainly because their benefits are not fully understood. One of the biggest threats to consistency and predictability of releases is the lack of understanding of the scope of work due to complexity and 'unknown unknowns'. Conversations with a quality coach help uncover this work, allowing teams to make informed decisions on scope. Discussing quality before any code is written gives teams an understanding of what is required to build a quality product. This benefits the team as they clearly understand 'what good looks like'. Of course, knowing and doing are two different things. In engineering, we constantly discuss tradeoffs. Quality, speed and cost are typical tradeoffs to be made. A discussion on PDR gives the information required to make informed decisions on these tradeoffs. Teams are in a better position to estimate their work accurately. In doing so, they can deliver more consistent and predictable releases. ### Gilding the Lily A senior manager or engineer will inevitably caution against 'gilding the lily' by over-engineering the solution. This is because modern engineering practices favour minimal viable product (MVP). It's wise to do so. The benefit of agile is in delivering only the business value required. But business value must be appropriately supported. After all, it's MVP not MVC (minimal viable code). Let's not under engineering systems that require intensive post-production support and can't be adequately supported due to lack of Recoverability. ### The cost of Recoverability Relying on Recoverability as the primary source of quality is an attractive proposition as it allows for increased speed of delivery. The downside is an increase in unplanned work as incidents increase. Unplanned work increases flow interruptions and reduces productivity and overall team happiness. Consistent and predictable releases can only come from understanding the full scope of work that includes quality tasks. ### When to discuss PDR PDR can be discussed at any time, but there are some occasions when discussing PDR is optimal. ### PIR's & Retros One of the most effective ways to get teams to think about PDR is in a team retrospective or during a PIR(Post Incident Review). Typically, the motivation to solve problems is higher as the experience is still fresh in their minds. Having real problems to solve often gives teams the reason and the permission to try to experiment with new approaches. PIRs and retros are the time to reflect on success and failure. PDR helps teams to systematically think through how to prevent, detect and recover from such an incident in the future. ### Planning Another valuable time to bring up PDR is in delivery planning. The impact of injecting questions and discussions on PDR at this time has a multiplier effect on quality. That's because people have time to incorporate these ideas into their work. The cost of leaving planning on quality to just before the 'testing phase' has significant downsides. ### PDR for senior management PDR is most powerful at the team level. It can be a coaching tool when explaining concepts to principal engineers, Directors of Engineering (DoE) and senior management. Influencing senior engineering provides time and resources for these quality tasks to exist. ### Prevention Tasks Implicit assumptions about scope, complexity and requirements are common causes of poor quality. Developing a shared understanding of the why and the what increases quality significantly. The following sessions/conversations can be facilitated, or the team can have them themselves. - Quality Sliders (tradeoffs) - Risk Storming Sessions - Quality Attributes Discussions - Example Mapping Sessions - Story Splitting Conversations - Vertical slicing - Small batches ### Detection Tasks Testing is an important activity that should occur as early as possible, but others exist. Teams agreeing on tasks and activities will have greater clarity on what tasks will be performed. - Test Driven Development & Pair Programming - Static code analysis & code security tools - Peer reviews - Test Planning - Levels of Testing (Unit, Integration, E2E, Test in Prod) - Types of testing (performance, security, exploratory) - Test data setup - Test environments (staging, production) - Feature Flags - Test Environment Setup - Test Automation Strategy - Test Reporting - Distributed tracing - Testing in Prod ### Recovery Tasks Again, discussing and agreeing on recovery approaches means teams can be ready before release. - Incident management - patching during an incident - testing during an incident (feature flags) - training new engineers on incident management - training new engineers on SLO's - Automatic Detection (Alerts) - Deploy and Release process - Monitoring Discussions - Automated Alerts - CUJ's & SLO's - Logging Standards ### Working with people outside of quality Many tech people scratch their heads in puzzlement when a quality professional asks to be included early in a project or feature design. After all, isn't testing something that's done in the end? As a result, you may have your work cut out to convince people to 'let you in' to meetings. The best advice is to build relationships with key influencers. In my experience, these are product managers, delivery leads and principal engineers. Also, don't assume people know anything about bug prevention and its benefits. Share articles & talks on bug prevention and shifting testing left. Talk to prevention over detection and its benefits in terms of cost of quality. Talk about better scoping leading to more accurate estimates that, in turn, offer greater predictability for releases. ### A final word on Team Maturity A common mistake quality coaches make is to assume teams have the same knowledge and depth of experience as they have, only to find that even the most essential quality activities are not being performed. As a quality coach, stay curious and ask about existing practices before jumping into advanced concepts. Make a point of rolling out new practices slowly. Allow time for new concepts to be absorbed into the team psyche. Avoid change fatigue by keeping the level of change small. Be guided by the team, their motivation, and the amount on their backlog. Do you have a similar approach? Let us know! ### What colour is your leadership corset? URL: https://www.annemariecharrett.com/what-colour-is-your-leadership-corset/ Last updated: 2023-07-02T06:34:14.000Z Don't wear one? Are you sure? Whalebone corsets might have gone out of fashion 100 years ago, but we continue using them, at least metaphorically. We all have our invisible corsets. They dictate what success looks like and what our goals and dreams are. They're carefully crafted, sometimes taking years of living and life experience. At first, these corsets are light and flexible. But often, as we experience life, our corsets become rigid and tighter. At work, there exist many types of corsets. Visible ones include cultural values, the Agile Manifesto, and Lean concepts. SaaS is arguably a corset dictating how modern products should be built and operated. These corsets can be handy. They offer structure, providing us with a standard way of working. They give us an understanding of what values are acceptable in a workplace. Other corsets exist too. Often they're unwritten rules and ways of working. It's the way 'things are done around here'. Invisible corsets are often how work gets achieved, especially in top-down, command-and-control, best-practice cultures. Leadership is a corset mostly built on narrow and archaic ideas of what leaders do and how they should behave. Most leadership skills are learned through experience, creating an echo chamber of what leaders think leadership should be. And even if leaders know better, this more traditional version of leadership will emerge when stress and tough times hit. ## Sign up for Anne-Marie Charrett ### Home of Quality Coach Book. Sign up for a free premium trial Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. Make no bones about it; tech leadership is hard graft. With leadership comes responsibility to the company and to the people you lead. You put yourself on the line daily, requiring a hefty dose of resilience. Surviving in a leadership position is often the dominating construct of the leadership corset. This corset appears innocuous a the start. Perhaps it comes from repeatedly battling the same argument until you give up. But as time passes and compliance is rewarded, the cost of speaking up becomes higher. The corset begins to become constrictive. Critical thinking gives way to defeat, and cognitive dissonance to rationalization. Leadership corsets are not only made of external constructs. They're also built on internal constructs such as expertise, ambition, and a sense of duty. These internal constructs prevent us from acknowledging 'we don't know' and asking for help. They prevent us from saying 'no' to taking time off, looking after our well-being and doing anything we tell others is a priority. And, with the drive to be the best leader, we forget it's okay to be human and make mistakes. Instead, we become intolerant of our own and others' mistakes. We create a view of a good leader that is impossible to obtain. Our corset tightens until one day; we discover we can no longer breathe. What might good leadership look like? Look around; there's plenty of material out there. But it does seem that current leadership ideology places a high bar on one person having the skills and know-how required to be a good leader. Rather than a good leader, I'd like us to focus on good leadership teams. And good leadership teams would have diverse leadership skills, demographics, and abilities. But this type of leadership team doesn't happen without intent and effort. It requires a space where diversity in leadership can thrive and grow. This space is not Kumbaya land nor an overseas junket trip. This space must be created intentionally by both exec and the leadership team. It's a space that demands we acknowledge and understand different perspectives and leadership styles. A space where respectful dialogue is prioritised. Its walls are transparent, and its hearth is welcoming. Diversity in leadership allows us to redefine the corset, perhaps expand it a little, allowing and encouraging people to loosen their internal constructs, breathe easier and be their authentic selves. Of course, we know all this. Or at least, we should know all this. It's not breaking news. There's enough literature and podcasts out there on leadership. But has our courage deserted us, or perhaps have we lost our way as our companies face increased complexity and uncertainty? I hope not. In response to this post, I hope someone will tell me a good hope story where leadership is thriving and growing. I'm sure they exist. And if so, can I work with you? ### Quality Coach Newsletter 16 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-16/ Last updated: 2023-09-06T23:20:33.000Z ## This month [Neil Younger](https://www.annemariecharrett.com/author/neilyounger/) returns with another punchy post on accelerating a culture of quality by identifying company engineering needs. This build on Neil's original post on building a [culture of learning](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/) by amplifying team wins. [Accelerate your quality culture by identifying your engineering capability needsHome of Quality Coach Book. Sign up for a free premium trial![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettNeil Younger![](https://images.unsplash.com/photo-1489641024260-20e5cb3ee4aa?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDF8fGpvdXJuZXl8ZW58MHx8fHwxNjg2MTQ0MTQwfDA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/) The post builds on Alan Page's work on [modern testing](https://www.moderntesting.org/?ref=annemariecharrett.com). It explores ways for teams to assess what matters to them and how to improve continuously—definitely, one to read. Premium readers, what would I do without your continued support? Thank you!🙌 If you haven't read it, click the link and log in using your premium membership. [Accelerate your quality culture by identifying your engineering capability needsHome of Quality Coach Book. Sign up for a free premium trial![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettNeil Younger![](https://images.unsplash.com/photo-1489641024260-20e5cb3ee4aa?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDF8fGpvdXJuZXl8ZW58MHx8fHwxNjg2MTQ0MTQwfDA&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/) ## **Quality Opportunity Solution Tree** This second premium post explores how to think critically through options that help amplify quality. Many people leap to software testing when thinking about improving quality. The reality is there exist many ways to improve quality that might even reduce dependency on software testing. This could be good news if the speed of deployment is essential to your company. [Quality Solution Opportunity TreeThis framework asks at a high level: “How else might we improve quality?”. It’s a simple open-ended question that encourages alternative perspectives, which is a good antidote to tunnel vision and SBS (silver bullet syndrome)![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/OPPTREE1-3.png)](https://www.annemariecharrett.com/quality-solution-opportunity-tree/) ### **Round the neighbourhood** Deborah Reid shares her experience as a first-time speaker. [Deborah Reid on LinkedIn: Five Things I Learnt Speaking At A Testing Conference For The First TimeI have written an article for Ministry of Testing with some top tips I learnt from my first experience as a speaker at a conference. I hope it helps others who…![](https://static.licdn.com/aero-v1/sc/h/al2o9zrvru7aqj8e1x2rzsrca)LinkedInDeborah Reid![](https://media.licdn.com/dms/image/sync/D4E27AQEAtVrB9Xjinw/articleshare-shrink_800/0/1686585815392?e=1688137200&v=beta&t=hCIwDJCoIJeiuC7GDqOc0fsW85olUTtQSWzvJ4CLTR0)](https://www.linkedin.com/feed/update/urn:li:activity:7034133009385562112?updateEntityUrn=urn%3Ali%3Afs%5FfeedUpdate%3A%28V2%2Curn%3Ali%3Aactivity%3A7034133009385562112%29&lipi=urn%3Ali%3Apage%3Ad%5Fflagship3%5Fprofile%5Fview%5Fbase%3Bu9FvrppdRviQ1dbxsYVjAg%3D%3D&ref=annemariecharrett.com) Lisa Crispin on why she loves testing and helping others. [Why I love testing, and love helping others find testing joy too - Agile Testing with Lisa CrispinWhy I got engaged in a testing career and why I love sharing my experiences and helping others improve quality and find joy![](https://lisacrispin.com/wp-content/uploads/2016/11/donkey-144.gif)Agile Testing with Lisa CrispinLisa Crispin![](https://lisacrispin.com/wp-content/uploads/2023/06/WhyHowWhat.png)](https://lisacrispin.com/2023/06/20/why-i-do-what-i-do-software-testing/?ref=annemariecharrett.com) ## Upcoming Speaking Events I'm excited to be travelling to be speaking at some upcoming events. [Agile2023 | Orlando, Florida | Agile AllianceAgile2023, Agile Alliance’s annual conference is the biggest and best international gathering of Agile professionals, bringing together practitioners from around the globe. July 24-28 in Orlando, Florida![](https://www.agilealliance.org/wp-content/uploads/2021/12/agile-alliance-logo-icon-300x300.png)Agile Alliance |![](https://www.agilealliance.org/wp-content/uploads/2022/08/agile2023-orlando-save-the-date.jpg)](https://www.agilealliance.org/agile2023/?ref=annemariecharrett.com) [Testμ Conference 2023 - Decode the Future of Testing | Join one of the world’s largest free software testing conferencesTestMu Conference is a virtual or online-only conference to define the future of testing. Join over 10,000+ software testers, developers, quality assurance experts, industry experts, and thought leaders for 3 days of learning, testing, and networking at Testμ Conference 2023 by LambdaTest. Attend 30…![](https://www.lambdatest.com/favicon.ico)Logo![](https://www.lambdatest.com/resources/images/testu/testmu23meta.png)](https://www.lambdatest.com/testmuconf-2023?ref=annemariecharrett.com) Until next month, Anne-Marie ‌ ‌*Like the Quality Coach Book?* [*Share a testimonial!*](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com) ### Accelerate your quality culture by identifying your engineering capability needs URL: https://www.annemariecharrett.com/accelerate-your-quality-culture-by-identifying-your-engineering-capability-needs/ Last updated: 2023-09-11T10:25:32.000Z In the previous article “[Build a culture of learning by amplifying team wins](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/)” I talked about how categorising ‘wins’ can support an improvement program. In this article, we will extend on this and explore how you can identify and build your capability model enabling you to better talk about what good looks like. This model is the cornerstone of such an improvement program and can help accelerate your engineering quality culture by providing a simple framework for a team and a consistent set of areas when celebrating success. To provide a practical example in this article, we will take inspiration from the ‘[Quality Culture Transition Guide](https://github.com/moderntesting/resources?ref=annemariecharrett.com)’ by [Alan Page](https://angryweasel.com/blog/about-alan/?ref=annemariecharrett.com). The Quality Culture Transition guide uses the following range; Beginning ➡ Growing ➡ Competent ➡ Optimising *I’ve replaced the original wording of ‘Chaos’ with ‘Beginning’ as I’ve found this word, for me, to better describe the start of a journey. I’ll be using this replacement throughout the article.* It has eight attributes of a quality culture; 1. Testing Breadth 2. Quality and Test Ownership 3. Technical Debt and Maintenance 4. Code Quality and Tools 5. Customer Data Analysis (Analytics) 6. Development Approach 7. Learning & Improvement 8. Quality Culture and Leadership Support # Why you might want to tailor your model One approach is to use the whole contents of the Quality Culture Transition guide. It provides a useful starting point and is ready to use with minimal effort. Using Alan’s definitions for each section can work well, and I recommend you take inspiration from them, but there are reasons why you might want to create your own; - They are more tailored to your context and work environment - It can empower the team with a sense of direction they can influence - It can have a greater sense of ownership if created by the team - They allow for variances per team - It creates a platform for teams to discuss what good looks to them 👍 I prefer utilising the original categories but supporting a team in establishing unique corresponding definitions while assisting them in shaping their journey. The important part is that the categories remain consistent across teams to enable and promote cross-team sharing. # Creating your Quality Culture Transition Guide 💡 ****Keeping the team at the centre** It is going to be important that throughout the workshop the team doesn’t feel it was a mandatory exercise seen as a metric collection or rating against other teams. Part of the vision should clarify this and should be the teams to own. Ideally, this would be done on a team-by-team basis but needs careful consideration of the current working practices across your department. If your department is small, or maybe just scaling, and you would prefer a single transition guide to be shared across teams then having representation from all teams and disciplines could be a sensible starting point. If you already have specific expected working patterns and practices across the department remember to add these to the definitions you create. It’s very likely that when the team talk about good practices they will naturally list some of the ones you are currently doing. The result will commonly be a mixture of current behaviours and aspirations for future improvements. ## Creating the whole model versus concentrating on similar slices Before you begin the workshop decide if you are going to create the whole set of definitions for the model with the team or break it down into smaller pieces. Some teams like to work on defining the sections in one go, others prefer to tackle it piece by piece over an elapsed time. ### Building the whole model first 😀 If the opportunity to complete it in one go exists, then that is often favourable as conversations in one category can help to inform others. 🤔 This requires longer dedicated time with a team and opportunities for that are harder to plan and manage. Such an opportunity might come from a newly formed team or a team going through a reboot. ### Working on similar slices Instead of doing all eight sections in one go this could be cut in half and have the team pick one from each area (Testing, Development, Approach) with the fourth being Quality culture and leadership support. | Testing | Developing | Approach | | -------------------------- | ------------------------------ | --------------------------------------- | | Quality and Test Ownership | Technical dept and maintenance | Learning and improving | | Testing Breath | Code quality and tools | Development approach | | | | Customer Data analysis and interactions | 😀 This cuts the time in half and still covers all sections within the categories. 🤔 This is a good compromise but still is only half the picture. ### Working on each category at a time 😀 This might be useful if the team already has an idea of which area they would like to improve first. It takes less time and allows them to start quicker. 😀 This can cut down on the context switching between each category. 🤔 It might miss the bigger picture and constraint opportunities to improve and experiment in other areas. 🤔 Completing each of the eight slices over a few weeks runs the risk of team fatigue. ## 1️⃣ Building a shared understanding - Ask the team for their understanding of what both the categories mean, to them, as well as the ranges used. It's okay if these mean different things to different people but it is important that for this exercise the team agree on a common definition. - Ensure that all voices of the team are heard and a common understanding is reached in terms of what the sections mean to the team, and for different members of the team. 🗒️ **Facilitator notes:** During the discussions around the categories, ideas for optimising might also come while the team is talking and they should be collected/highlighted to be used later in the workshop. ## 2️⃣ Completing the corners of Beginning & Optimising Instead of working through the range from left to right in order we instead will focus on the two edges; Beginning and Optimising. It’s often easier to think of boundaries than the separate steps that might be needed to get from the perceived start to the end. ### Beginning A suggested approach, and to enable the team to have some fun at the start, would be to use a short style anti-pattern workshop similar to [Triz](http://www.liberatingstructures.com/6-making-space-with-triz/?ref=annemariecharrett.com). - Simply ask the team ‘What are the worse ways of working you could imagine concerning ‘Quality and Test Ownership’? - Encourage the team to have some fun and don’t limit their imagination - Gather together the suggestions and turn them into a meaningful definition for ‘Beginning’. ![A table with four ranges of beginning, growing, competent, and optimising and the category of quality and test ownership.](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/Screenshot-2023-06-07-at-14.51.29.jpg) ### Optimising - Now ask the team ‘What are the best ways of working we could imagine concerning ‘Quality and Test Ownership’? - The team can use the recently completed ‘Beginning’ to help them look forward. - Gather together the suggestions and turn them into a meaningful definition for ‘Optimising’. ![A table with four ranges of beginning, growing, competent, and optimising and the category of quality and test ownership.](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/Screenshot-2023-06-07-at-14.53.08.jpg) ## 3️⃣ Deciding where you are and defining what you do next Using beginning and optimising to frame the boundaries the team decides where they think they are. The scoring isn’t important but it has to be something that the whole team agree with. 🗒️ **Facilitator notes:** You might find it interesting to ask the team to silently decide where they think they are as the following discussions can often bring out hidden assumptions, especially if there is a range of views across the team. 🗒️ **Facilitator notes:** Guide the team away from potential arguments around where they are and remind them the important thing isn’t the model, it’s what they decide to improve next using the model as a guide. ![A table with four ranges of beginning, growing, competent, and optimising and the category of quality and test ownership.](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/Screenshot-2023-06-07-at-15.01.43.jpg) Depending on where the team thinks they are they will then complete a definition. Not all definitions will be completed at the end of the exercise. - If the team thinks they are in ‘Beginning’ they decide on what the definition of ‘Growing’ looks like which helps them on the journey to ‘Optimising’. - If the team thinks they are in ‘Growing’ they decide on what the definition of ‘Competent’ looks like which helps them on the journey to ‘Optimising’. - If the team thinks they are in ‘Competent’ they decide on what this definition looks like. At the end of this exercise, the team should have an idea of where they are and importantly what they might need to do next. Note that ‘Optimising’ at this point is just a hypothesis. As the team learn from each experiment on the journey, they might change their view of what it means to be ‘Optimising’ in the future. ## 4️⃣ Repeat for each category Depending on how you have decided to tackle building up the model iterate over the other categories. ## 5️⃣ The first experiment & sharing past success The team has decided where it thinks it is and has a framework to revisit progress or regress at a future date. At this point, the model should be completed depending on how you decided to slice it and ready to use. While not strictly necessary I would encourage you to ask the team to decide; - One area on the model where they can share a practice or an experiment. This ties nicely into the previous article “[Build a culture of learning by amplifying team wins](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/)” - One area on the model that they would like to get better at. Doing this encourages the sharing of practices that might immediately help other teams and starts to create a culture of sharing and improving. By focusing on one area to start with the team come away with direct action to follow up on. This also helps limit the potentially overwhelming nature of seeing lots of areas of improvement within the Quality Culture Transition Guide. Much like within a retrospective where a team might choose one area from a range of suggestions. It’s a focus on action. # It's about the journey ![A girl sitting on a rock overlooking a valley with a winding road](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/vlad-bagacian-d1eaoAabeXs-unsplash.jpg) Photo by [Vlad Bagacian](https://unsplash.com/@vladbagacian?utm%5Fsource=unsplash&utm%5Fmedium=referral&utm%5Fcontent=creditCopyText) on [Unsplash](https://unsplash.com/photos/d1eaoAabeXs?utm%5Fsource=unsplash&utm%5Fmedium=referral&utm%5Fcontent=creditCopyText) The model you create with your team shouldn’t be seen as a race to the end. It's a journey that you will undertake together. 👣 ****One step at a time** Be mindful that your ‘Optimising’ state might seem like an unrealistic target, instead simply focus on what your next step will be. That is much more achievable. 🌳 ****It’s ok to stop and admire the scenery** Take stock of where you have got to and celebrate your success. Constant marching forward can be tiring for you and your team, remember to rest and reflect. 🔙 ****Not all journeys will always go forward** Not starting your journey might seem like an obvious statement but ensure there is time during your daily work to continue moving forward. Circumstances and context can change. Maybe the way you work isn’t as optimal as it once was. Has an external change meant that you have gone back to a previous state? You can end up in a comfort zone, viewing your successes and not letting go of things that no longer serve you, not changing to fit the new circumstances. But once you realise that circumstances have changed, you can, too. 🥾 ****Improve the path so that others can follow** As the team learns and evolves encourage them to update their definitions to reflect the journey they have taken so that others can benefit from their experiences. ⛰️ ****Beyond that hill might be another path** As teams improve they will have a better idea of what good looks like so you might find that at the Optimising stage, the team asks ‘What’s next?’. Support the team with this decision and consider; - Is there more they would like to do? - Do they want to pause and help others get to the same point? # Leadership support Inspiration of what good looks like might take several forms. Perhaps you have a [Team Charter (or Canvas)](https://alexeyivanov.com/team-canvas/?ref=annemariecharrett.com), or perhaps your company has a [Technology Radar](https://www.thoughtworks.com/radar?ref=annemariecharrett.com) (covering Techniques, Tools, Platforms, and Frameworks) that you can draw from. Maybe a direction has been set related to one, or all, of the categories by senior management, staff engineers, architects, agile coaches, etc. Any Quality Culture Transition Guide should be a mixture of agreed company software practices and team aspirations for improvement. ![A table with four ranges of beginning, growing, competent, and optimising and eight categories from the quality culture transition guide](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/Screenshot-2023-06-07-at-15.18.30.jpg) Some of these aspirations might need leadership support (budget for training for example) so remember to seek their opinion and share your experiments. In time, some of these aspirations once proven by a team might become agreed software department practices. For that to have a greater chance of success engage with those with an interest in what good might look like. # Nothings perfect When starting this with a team please keep in mind that; **No model is perfect**: Any model is a simplification; wrong, but hopefully useful in aiding discussions with a focus on action. **It is not a rule book or a blueprint:** It is a living agreement on how you might, or want, to do better. **It is not static**: It will evolve as you and your team learn and grow together. The goal here isn’t about creating a Quality Culture Transition Guide it’s about bringing a team together around a common understanding of what good could look like for them. It’s about being inspirational but practical, providing guidance in a format that is easily shared and understood. Ultimately the success of this isn’t the creation of your Quality Culture Transition Guide (although it is a good start) it is about what you do next, and I can’t wait to see what you do next 😁 ### Quality Solution Opportunity Tree URL: https://www.annemariecharrett.com/quality-solution-opportunity-tree/ Last updated: 2023-09-11T10:26:27.000Z ## **Quality is an ecosystem** The domination of SaaS as a product model and the drive to deliver software faster has dramatically impacted how we think about quality. Testing phases no longer exist. Instead, they're replaced by "testing moments". Where in the past we looked to software testing as the primary quality approach, we now look to build quality into our systems, using various tools, processes and practices that combined to allow quality to emerge. Our quality strategies look more like [this](https://en.bbv.ch/wp-content/uploads/2020/06/bbv%5Fsoftware%5Fdevelopment%5Fquality%5Fmap.pdf?ref=annemariecharrett.com): ![Software Development Quality by BBV](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/Screenshot-2023-06-07-at-2.23.44-pm.png) https://en.bbv.ch/wp-content/uploads/2020/06/bbv\_software\_development\_quality\_map.pdf ## Silver Bullets Ahoy! That doesn't stop the obsession with solving quality with silver bullets. Each boss has their pet silver bullet. I have my pet silver bullet. As humans, we can't help ourselves anchoring onto something we know will fix the world. Bless our little cotton socks! In the quality space, the terrain is littered with silver bullets of various sizes and shapes. And, as we grow more experienced, we recognise these as over simplistic solutions to difficult and complex problems. As best we can, we continue to educate our colleagues on what 'good looks like' for a quality strategy. It's a Sisyphean task. ## Not all silver bullets are equal I like to pay attention when my CTO and senior leadership talk about silver bullets. Typically the conversation begins by highlighting either one of the following concerns: - Testing takes too long - There are too many bugs in production - The feedback from testing is too slow - We can't see that state of quality - Testing is too expensive Their favourite silver bullet rapidly follows. Over the years, I've made a list of them: - We need more test automation to speed up testing - We need increased regression testing to reduce bugs - We need increased unit testing to provide faster feedback - We need better testing metrics will help see the state of quality - We need to outsource to reduce the cost of testing Here's a visual of the problem and solution space. ![How Quality Problems are expressed with associated solutions - Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/2-1.png) How Quality Problems are expressed and the solutions suggested - Anne-Marie Charrett ## Silver bullets come with a price tag We know these solutions are alloys made of some cheap metal rather than being made of silver. Often they go some way to solving some of the quality issues out there. But, more often than not, they become more expensive, complex and harder to roll out. Who knew software development was so hard? Example: test automation decreases our test automation from five days to one. We also need to hire double the number of test automation engineers, who all need suitable lead times to create these automated tests. Still, that doesn't mean that the solution is inherently wrong. It's more that we know various solutions are required to improve quality. ## Diversify your strategy A solid quality strategy relies on more than a silver bullet; instead, needing a variety of tools and tactics in your toolkit. Or, as I prefer to say, you need more than red lipstick in your makeup bag. Consider a range of tactics and approaches to improving quality. As the above map suggests, a lack of quality is rarely down to one thing. It's a range of problems from understanding the customer, and the complexity of the solution, to how internal teams communicate and collaborate and customer support. Teasing folks away from their silver bullet is not easy. I advise avoiding taking the high road by dismissing these ideas outright. Buying into some of your boss's 'silver bullet'1 solutions is not altogether a stupid strategy. It will open purse strings, give you continued support (important when things get tough) and help you frame reporting to senior leadership. Instead, I ask, "How else might we improve quality"? ## The "How else" quality framework2 This framework asks at a high level: "How else might we improve quality?". It's a simple open-ended question that encourages alternative perspectives, a good antidote to tunnel vision and SBS (silver bullet syndrome). Here's an example of the framework ![Options for Quality Strategies by Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/3.png) Alternative Options for Quality Strategies by Anne-Marie Charrett I like to bucket solutions into three categories, prevent, detect and recover. Prevent, detect, recover is a powerful heuristic that allows you to frame how quality needs to be at the start, the middle and the end of our product services. - Prevent: What solutions allow us to build quality in? - Detect: What solutions allow us to detect quality-related issues? - Recover: What solutions allow us to recover from quality-related issues? By focusing on prevention, we theoretically can reduce the time required for testing, reduce incidents, and reduce the cost of testing. So I like to focus most effort on the prevention part. Your company may need a different focus. You can prime this conversation by placing some solutions into each category and encouraging others to suggest their ideas. ![Potential alternative solutions for perceived quality problems - Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/table.png) Potential alternative solutions for perceived quality problems - Anne-Marie Charrett Once the brainstorming is exhausted (anything between 3 and 20 minutes, depending on the group), it's time to prioritise what solutions you as an organisation want to invest in. Using a [DACI is a popular model](https://www.atlassian.com/team-playbook/plays/daci?ref=annemariecharrett.com#instructions) that allows the group to explore the pros and cons of each solution. I like to consider the impact on quality, short-term gain versus long-term gain, and cost (in both time, people and resources). ## Workshop Material In the [Miro board](https://miro.com/app/board/uXjVMBaYsHw=/?share%5Flink%5Fid=615097458721&ref=annemariecharrett.com)3 below, I've linked the ideas to the original problems using the prevent, detect, recover heuristic. This connects the original problem to solutions. In reality, many of these solutions solve multiple problems. Or they create new problems. So it will never be clear cut. Still, it goes some way to moving the conversation forward in the right direction. ![Quality Opportunity Solution Tree - by Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/06/Quality-Opportunity-Solution-Tree--1--1.jpg) Quality Opportunity Solution Tree - by Anne-Marie Charrett 3 [Miro Board of a Quality Opportunity Solution Tree ](https://miro.com/app/board/uXjVMBaYsHw=/?share%5Flink%5Fid=615097458721&ref=annemariecharrett.com) You are welcome to make a copy of this board and use it for personal purposes. Also, I've put a pdf of the images in this post as a download. [PDF of Quality Framework by Anne-Marie CharrettQuality Coach FW 2023 Anne-Marie Charrett.pdf847 KBdownload-circle](https://www.annemariecharrett.com/content/files/2023/06/Quality-Coach-FW-2023-Anne-Marie-Charrett.pdf "Download") ## Lessons learned Some things I've learned over the years about defining strategies and solutions: - Offer pros and cons of options so people can understand what the choices they are making - Frame the execution of ideas as experiments that can be retired if unsuccessful. - Solutions don't have to be perfect, but they should be realistic to the context of your organisation. - Be mindful of your own bias. The answer might not be the most perfect, but it may be the most practical. - Give people early wins. Education comes in time. It's a marathon, not a sprint. - Nothing is forever; if you are overridden on an option, work to provide a date by which you can review the success of that option. Finally, don't worry if people return to choose their favoured silver bullet. Changing hearts and minds takes time. It may take lots of similar conversations before it becomes safe for people to invest in new ideas. ## Footnotes *1 Of course, if it is idiotic and dangerous, you should be vocal about that. But try to find ideas or approaches you can agree on.* *However, sometimes neither agreeing nor disagreeing with an idea and quietly let it die peacefully alongside other stupid ideas in the wasteland of rampant stupidity.* *2 This concept is built on [Teresa Torres Opportunity Solution Tree](https://www.producttalk.org/2016/08/opportunity-solution-tree/?ref=annemariecharrett.com)* ### Quality Coach Newsletter 15 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-15/ Last updated: 2023-05-21T23:30:37.000Z ## Less Friction, more Freeway This month's newsletter looks at the topic of frictionless services. I hope you enjoy it. ## It's more than a Field of Dreams It's not enough to simply create a frictionless service. I wish it were like Kevin Costner in "Field of Dreams", where "if you build it, they will come" is all it takes to simplify team scope. But in my experience, it takes hard work and intentionality to encourage teams to embrace what they perceive as 'additional work' regardless of how easy it is to pick up. We have both internal and external interference when picking up new skills and tasks. And, if we want to really embed a 'way of working into a team, into a culture, we need to work on both types of interference. Creating a frictionless service that is easy to pick up and use goes a long way to reducing external interference. Work on reducing obstacles for teams, are tangible tasks that demonstrate quick wins. These are necessary for you to grow and build relationships. Premium readers, what would I do without your continued support? Thank you!🙌 If you haven't yet read it, click on the link and log in using your premium membership. [Quality Coaching: Focusing on FrictionlessTL;DR It takes effort to persuade by logic or motivate people. You may achieve more success by removing team obstacles that are preventing them from performing quality-related tasks.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1514908162061-89747fab8b1e?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDN8fHJpZGUlMjBlbGVwaGFudHxlbnwwfHx8fDE2ODM2MTk3Mjc&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/as-a-quality-coach-frictionless-service-is-a-quality-attribute/) ## **Related Posts** Some posts/talks on platform teams and quality engineering. [Team Topology & Quality Engineering StructuresWhat is the optimal structure for Quality Engineering within Engineering? Anne-Marie Charrett writes about some of the complexities to consider![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/10/Screen-Shot-2021-10-16-at-7.04.55-pm.png)](https://www.annemariecharrett.com/team-topology-quality-engineering/) [Question with sprinkle of humility on the sideMichael Bolton tweeted yesterday: > Testers: let’s not obsess over trying to be influential, and work on beinghelpful. And let’s be careful to offer—not inflict—help. #testing\[https://twitter.com/search?q=%23testing&src=hash\]> — Michael Bolton (@michaelbolton) October 16, 2013\[https://twitter.c…![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1523568114750-b593de7df18f?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDE4fHxoZWxwfGVufDB8fHx8MTYyMzk2Mzk1MQ&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/influential-tester/) ### **Round the neighbourhood** Great to see [Heather Reiduff ](https://www.linkedin.com/in/heather-reid-21198a69/?ref=annemariecharrett.com)writing. In this post she looks back at her nine months at Glofox and writes about her wins. [Making an Impact HereSeeing the impact I’m making 6 months into my new role.![](https://heatherreiduff.com/apple-touch-icon-144-precomposed.png)![](https://heatherreiduff.com/profilepic.jpeg)](https://heatherreiduff.com/posts/2022/making-an-impact-here/?ref=annemariecharrett.com) Such an insightful post by [Maaret](https://www.linkedin.com/in/maaret/?ref=annemariecharrett.com) on the value of documentation. [The Documentation ConundrumIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4PNSHyfFcRT_q0SxW6M9Ya0CmIm2MA7UTHg3-Wy4Z7vJhKezPpqhSANPt_yLYLoamQhgdbvDtgk4CiNIe4BJ2zKD5U0mSo79ik7YsUk9G9PRq0Y7Q8qNkr-e8MLIZUgKtEHQ6nRGlJEbvGzFQ86I5voj4YTeoJKOfaFLJVPfm-5actAHyqBtU9x8/w1200-h630-p-k-no-nu/Screenshot%202023-05-18%20at%2013.35.44.png)](https://visible-quality.blogspot.com/2023/05/the-documentation-conundrum.html?ref=annemariecharrett.com) [Areti Panou](https://www.linkedin.com/in/%F0%9F%90%9D-areti-panou-01984a138/?ref=annemariecharrett.com) writes on the difference between Product Plans and Product Strategies and the value of using the product plan to communicate and interact with key people. [Care Tips for Product Plans](https://unremarkabletester.com/2023/05/16/care-tips-for-product-plans/?ref=annemariecharrett.com) This article by Dragan Stepanovic comparing code reviews and pair programming was interesting to me. [From Async Code Reviews to Co-Creation PatternsThis article dives into the throughput and quality of the async code review process, which are very important dimensions to optimize for in product development teams. It also explains why co-creation patterns – Pair and Mob programming – as an alternative way of working are able to optimize for both…![](https://cdn.infoq.com/statics_s1_20230519120639/apple-touch-icon.png)InfoQDragan Stepanović![](https://res.infoq.com/articles/co-creation-patterns-software-development/en/headerimage/generatedHeaderImage-1667590759022.jpg)](https://t.co/s2Ahx0aDc8?ref=annemariecharrett.com) ‌Finally, I wrote a post on end to end testing and how its not just how logical it not that influences a team's decision to do end to end testing. We need to consider psych safety, and a companies openness to experimentation and exploration. [Advocating for less testingTests don’t exist in an isolated repo. They represent decisions on testing based on beliefs, relationships and safety.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1614555281536-6755500b7494?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fGxlc3N8ZW58MHx8fHwxNjgxMDAzOTY4&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/a-psych-safety-reflection/) ## Upcoming Speaking Events I'm excited to be traveling to be speaking at some upcoming events. [EuroSTAR 2023 Programme | Software Testing ConferenceView the EuroSTAR 2023 Programme of talks featuring 60+ sessions from global test experts across the spectrum of software testing.![](https://conference.eurostarsoftwaretesting.com/wp-content/uploads/2021/05/cropped-es-fav-icon-270x270.png)EuroSTAR Conference![](https://conference.eurostarsoftwaretesting.com/wp-content/uploads/2022/11/ES2023-Programme-Launch.png)](https://conference.eurostarsoftwaretesting.com/conference/2023/programme/?ref=annemariecharrett.com) [Agile2023 | Orlando, Florida | Agile AllianceAgile2023, Agile Alliance’s annual conference is the biggest and best international gathering of Agile professionals, bringing together practitioners from around the globe. July 24-28 in Orlando, Florida![](https://www.agilealliance.org/wp-content/uploads/2021/12/agile-alliance-logo-icon-300x300.png)Agile Alliance |![](https://www.agilealliance.org/wp-content/uploads/2022/08/agile2023-orlando-save-the-date.jpg)](https://www.agilealliance.org/agile2023/?ref=annemariecharrett.com) [Testμ Conference 2023 - Decode the Future of Testing | Join one of the world’s largest free software testing conferencesTestMu Conference is a virtual or online-only conference to define the future of testing. Join over 10,000+ software testers, developers, quality assurance experts, industry experts, and thought leaders for 3 days of learning, testing, and networking at Testμ Conference 2023 by LambdaTest. Attend 30…![](https://www.lambdatest.com/favicon.ico)Logo![](https://www.lambdatest.com/resources/images/testu/testmu23meta.png)](https://www.lambdatest.com/testmuconf-2023?ref=annemariecharrett.com) Until next month, Anne-Marie ‌ ‌*Like the Quality Coach Book?* [*Share a testimonial!*](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com) ### Quality Coaching: Focusing on Frictionless URL: https://www.annemariecharrett.com/as-a-quality-coach-frictionless-service-is-a-quality-attribute/ Last updated: 2023-09-11T10:26:42.000Z *TL;DR It takes effort to persuade by logic or motivate people. You may achieve more success by removing team obstacles that are preventing them from performing quality-related tasks.* In his book ["The Happiness Hypothesis"](https://www.happinesshypothesis.com/?ref=annemariecharrett.com), Jonathan Haidt created the rider and elephant metaphor to describe two sides of our minds, the rational (the rider) and the emotional side (the elephant) and the path we wish to follow. He uses it to describe how our emotional side often influences us more than our logic when going down a path. [Dan and Chip Heath used this metaphor in their book Switch](https://heathbrothers.com/books/switch/?ref=annemariecharrett.com), suggesting that shaping the path, may be a more effective way of influencing change. ## The Rider and the Elephant. ## The inner game [Tim Gallwey,](https://www.performanceconsultants.com/the-inner-game?ref=annemariecharrett.com) tennis coach and one of the original thinkers of modern coaching, describes how people have both an inner and outer game and while many focus on the outer game of being skilled at a craft (in our context, software engineering), he believes that the inner game is also crucial for success. He offers this formula to describe the inner game: Performance = Potential - Interference Where potential is an ability to master a skill, interference can be both internal or external and inhibits our ability to perform. He advises the coach to focus on removing the interference, rather than aiming to improve their potential. ## Improving Product Quality When I think of quality coaching both these ideas resonate. When I first started out as a quality coach, my goal was to focus on improving people's performance. How could I help a software tester or a software developer improve their testing capability? And while I had significant success, it was clear that motivation was integral to a successful outcome. It got me thinking. What if I focused on interference instead of focusing on the potential? Why don't I focus on shaping the path, instead of trying to motivate the elephant? ## External & Internal Interference Tim Gallwey describes interference as both external and internal. Examples in the tennis world of external interference could be not having a tennis court, or not owning a racket. Internal interference is the self-talk that tells you 'you can't do serves', or 'your backhand is crap'. It feels like external interference is similar to 'shaping the path' and internal interference like 'persuading the elephant'. As quality coaches, we must deal with internal and external interferences. We have to 'shape the path' and 'influence motivation'. ## Shaping the Path Shaping the path is way easier than persuading anyone (let alone an elephant) to modify behaviour. In situations of low motivation and low trust (and low trust could be simply you are new to a team), it makes sense to focus on external factors such as: - Test Environments This is such a practical thing you can do. Focus on either creating and/or maintaining test environments. - Infrastructure Pipelines, frameworks, release processes, testing in prod. All these are critical elements of modern software development. Think about building templates into repo's allowing for rapid adoption and rollout. - Test Data There are many types of test data out there. Seed data for test automation, masked and obfuscated production data, and a blend of both. Having diverse test data is important for any team's confidence level. - Story Sizing If there is one thing I would ask teams to do to improve quality is to 1) slice stories by domain 2) scope a story from 'pixel to persistence and 3) deliver the smallest possible value. Work with your delivery lead to get this going. It will be painful at first, but the wins of this approach to improving quality and building confidence will have your team thanking you. In any of the above ways, a quality coach can remove friction in a team's delivery process and deliver value to customers. You can even measure reduced unplanned work to demonstrate improvement. You don't have to stop there. Just because an elephant is large, doesn't mean you can't persuade them a little to change their mind. ## Persuading the elephant It is difficult to persuade and motivate a team to invest in software testing for many reasons; - **Confidence:** Fun fact. Most universities offer minimal training on testing; if they do, it's on unit testing. Joining the real world and discovering testing is 'part of the work' requires learning new skills. Lack of confidence in testing ability can play a big part in why teams don't test. **Suggestion:** Arrange organised training programs in both test automation and exploratory testing. Confidence will build in time as the team gets more practised. - **Status:** "Testing is below my pay grade". As much as I wish testing was not undervalued, the stark reality is that in many organisations you will find people who perceive software testing as a task anyone can do. If you are lucky to work in these places where software testing is valued, you will find these people marginalised. **Suggestion:** My approach here is to focus on individuals in the team who support software testing and use them to try and influence the rest. - **Fear of Failure:** This one is a powerful one. I've seen teams reluctant to release in case a bug is released to production. **Suggestion:** Encouraging monitoring and the ability to recover quickly can help reduce this feeling. - **Overwhelmed:** Many teams feel pressured to release features and do not " have time to test". This is not a fun place to be in. Planning time ahead of development is required to understand and estimate. The key is to work with product owners, and delivery leads to ensure time is included from the start in a real and tangible way. Insist on this. Make this one of your red lines. Get cards on the backlog. - **Uninspired:** I LOVE TESTING, but I know many people don't enjoy it and find it boring **Suggestion:** As a quality coach, you can aim to make testing fun, doing bug bashes and exploratory testing. ## Shape the path, then work on the elephant Focusing on external factors such as building test environments, supporting tests in production, and making it safe for the team to 'fail' are good places to begin in quality coaching. This is particularly true if you are new to a team or company and want to build trust. Focus on low-hanging fruit. That is an opportunity where you can quickly demonstrate a win. A tangible success that comes quickly offers confidence in you as a quality coach. ## Now work on the elephant Play the long game with internal factors. Internal factors can take months to impact a team. Building trust and relationships is critical. Don't forget that context is critical here. Any factors below may be reasons to lower expectations in: yourself, the team and senior leadership about what success will look like for three months, six months and 12 months. - the criticality of what they're working on, - their software engineering experience - the familiarity with platform technology including testing frameworks - the experience in software testing - time allocated for experimentation and exploration - the psychological safety offered to you When putting together a plan, I suggest you include short-term wins and long-term plays to impact both internal and external interference. As always, the key is to have a toolkit of many tactics and approaches. And be prepared for change. It will come, just the shape will be uncertain. Have a plan, but be ready to tweak and pivot as the team shifts and changes. What are your experiences in influencing both internal and external factors? *thanks to Anne Colder for telling me about the Elephant and Rider and Rob Meaney for his phrase - pixel to persistence.* ### Quality Coach #14 URL: https://www.annemariecharrett.com/newsletter/quality-coach-14/ Last updated: 2023-05-06T00:32:41.000Z We're going with a Ted Lasso vibe this month. This month's [premium article](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/) is amplifying success. Neil Younger has provided us with an excellent workshop and explainer to kick-start amplifying those positive vibes in your company. [His article](https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/) includes a short video explaining the workshop, plus a miro board to help you get started. Neil has also kindly donated his writer's fee to two wannabe subscribers. If you're currently out of work and looking to jump into a quality coach role, email me at [subscriptions](subsriptions@qualitycoach.io). ## End to End Testing & Pych Safety [Bonus premium article! ](https://www.annemariecharrett.com/a-psych-safety-reflection/)This month explores the intersection between psychological safety and the need for end-to-end testing. TL: DR my hypothesis on a relationship between pych safety and the number of end-to-end tests that exist. [Advocating for less testingTests don’t exist in an isolated repo. They represent decisions on testing based on beliefs, relationships and safety.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1614555281536-6755500b7494?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fGxlc3N8ZW58MHx8fHwxNjgxMDAzOTY4&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/a-psych-safety-reflection/) ## From The Community Four articles to share this month. Such wonderful community work. Thanks all! [Quality Gardeners and Quality Coaches at JobandtalentHow we implemented Quality Assistance in teams while Jobandtalent Engineering was changing its structure.![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)Jobandtalent Engineeringjobandtalent Engineering![](https://miro.medium.com/v2/resize:fit:1200/1*2CKxTk2LZJKxjdh9Tc72bw.jpeg)](https://medium.com/jobandtalenteng/quality-gardeners-and-quality-coaches-at-jobandtalent-52ca42de6917?ref=annemariecharrett.com) [Quality Coaching Colors by Emna Ayadi](https://emnaayadi.com/2023/04/16/quality-coaching-colors/?ref=annemariecharrett.com) [On Test CasesIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjysURLNKsQ_Y-yBSo75D_K37zNOlJtxN1U761ZdNh1-0sr00HXVnToTlhl2vS2_5BiIQGOM6qV_bHNOhHIimJwDGYTtZMJSJBZetD2DUnzyLKh7zsTgoRN6nn09Po_h5eSrCDEVGVxzCvY4AFgP2UX_cb-OkhOYJCnAGr3ypCfs7cbZjw5ytKEwhI/w1200-h630-p-k-no-nu/Screenshot%202023-04-15%20at%2018.37.30.png)](https://visible-quality.blogspot.com/2023/04/on-test-cases.html?ref=annemariecharrett.com) [An example of LLM prompting for programmingGenerated knowledge and chain of thought prompting of an LLM can generate useful code.![](https://martinfowler.com/favicon.ico)martinfowler.comMartin Fowler![](https://martinfowler.com/articles/2023-chatgpt-xu-hao/xu-chat-final.png)](https://martinfowler.com/articles/2023-chatgpt-xu-hao.html?ref=annemariecharrett.com) That's all for this month. April has been a total blast! see you all next month! Anne-Marie ### Advocacy for less testing URL: https://www.annemariecharrett.com/a-psych-safety-reflection/ Last updated: 2023-09-11T10:13:20.000Z As a strategy, I'm a fan of minimising the number of end-to-end1 tests a team owns and runs. However, this advocacy for less testing can be a difficult sell. Software Engineers and testers express their reservations about adopting such a strategy. ## Good Reasons for End-to-End Tests End-to-end tests are great. Here's why: - They're relatively quick to create, especially if a separate team maintains the framework - In a world where everything is mocked, it shows the happy path works. - They offer value to non-engineering folks who can see something they know and understand working. ## Good Reasons for not having End-to-End Tests On the face of it, there are lots to like about these tests. But I'm still a reluctant advocate. Here's why: - Every test has a cost. Designing, building, running, evaluating, and maintaining costs time and expertise. Is that test worth it? - How would you write your code differently if you didn't have these tests? Would you beef up your unit tests? Having isolated and decoupled tests may take more upfront thinking and care, but I believe it has a more significant payoff in allowing us to go faster. - Be data-driven; how many bugs have these tests found post deploy? If your experience is that the count is low (when you remove false positives), then that's a super expensive safety net. Is it worth it? - And if your end-to-end tests find bugs, are they catching bugs that should have been caught at the lower testing layer (such as unit testing or contract testing)? - End-to-end tests only check what you know. It can't tell you about the unknown, unknowns. So in terms of a safety net, it's pretty poor. - Even if the intent is to create a minimal set of tests, the lure of the "just in case" safety net is strong. Regression test suites get bigger and bigger as people are reluctant to 'delete' tests. ## Deciding on a test automation strategy Two sets of reasons and two perspectives. As a quality coach, how do I help move a team forward? The options are: - Stand firm and exclude end-to-end tests from any testing strategy. After all, engineering has many standards that are absolutes. This is simply one more. - Let the team decide. Stand back and allow the team to write as many end-to-end tests as they feel comfortable. - Facilitate a discussion that allows everyone to explain their perspective, moving forward with an experiment. I've attempted all three ways with various degrees of success. But, on reflection, I think all three options are good. What matters is that you are aware of yourself and the team's context, the constraints and resources a team has, the expertise of the team and the psychological safety. These days I lean toward playing a long game where in time, teams discover a strategy that works for them. Because of this, I lean toward facilitated conversations and consensus-seeking. ## Context Matters One big reason for doing this is context. The team's context and more significant factors heavily influence software testing decisions. Look at these examples. - *A team using TDD and pair programming with vertical story slicing probably has greater confidence in the quality of their code. The need for a safety net is reduced.* - *A team where psych safety is low, experimentation is seen as indulgent, and teams are blamed when a failure occurs is likelier to want strong and visible safety nets.* ## A word on psych safety Blame and low psych safety will influence a team's decision without necessarily being articulated that way. Be mindful and empathic. Just as you hate waking up at 3 am with a pit of anxiety in your stomach, so does any team. Is it such a big deal if a few end-to-end tests give people a good night's sleep? ## You matter too But of course, your personal beliefs around testing matter too. And if it matters a lot, it's important to stick with that belief. And what about conflict? If you're about to trample over some sacred stones, does jumping into a mosh pit of conflict give your nerve endings a tingle of anticipation, or does it have you running for the hills? In summary, it's almost immaterial if you decide to go with or without end-to-end tests. Our tests don't exist in an isolated repo. They represent decisions on testing based on beliefs, relationships and safety. To change people's testing, you must change these three pillars. As a quality coach offering insight and support to their decision-making may be the most sensible strategy you can take. 1 End-to-end tests in this context are GUI tests that hit the persistence layer. ### Build a culture of learning by amplifying team wins URL: https://www.annemariecharrett.com/build-a-culture-of-learning-by-amplifying-team-wins-2/ Last updated: 2023-09-08T23:20:24.000Z There are many formats for teams to celebrate success and ways of working. The approach described in this article takes the additional step of thinking where practice could be shared and, importantly, attempts to tie that back to the department or business's collective learning and development goals. In this way, sharing becomes a deliberate act targeting the needs of others and the business. The work of Dr Steven Spear in his book ‘[The High Velocity Edge](https://itrevolution.com/devops-book-review-the-high-velocity-edge-by-dr-steven-spear/?ref=annemariecharrett.com)’ explains how a learning organisation brings business success in that new discovery of local knowledge and improvements are turned into global improvements. As a coach accelerating the capabilities of others is an important part of your role and from a quality perspective this follows the principe of being a force multiplier. ## What is it? A simple team-centric workshop that can be run in an hour or less. It focuses on what the team is good at from a technical or process point of view and when applied to an organisation can to empower other teams with their experience. At the team level it can help support the foundations of experimentation, growth and improvements while celebrating their successes. This approach can be used for any department within an organisation and isn’t specially related to the software or engineering examples used in the article. As with most practices that involve sharing, the impact of this approach expands as more teams use it, supporting each other to level up in the process. Its principles centre around: - What a team is good at (Technical and Process) - Where can they share this (At which level of the business) - How can they share this ## Why might you need it? - You want to develop a consistent and simple approach that can be used for one to many teams. - You already have a culture around learning, development, and sharing but want a way to relate this to your department or company’s areas of growth. - You are building a culture of what good looks like for your business and want this to be a collaborative process. - You find that while teams are sharing how they work others are finding it difficult to categorise and discover this learning to be able to make use of it themselves. - Your company is scaling and it is becoming harder for teams to learn and share with each other. - You have more than one team and are starting to want to accelerate team-level improvements across the department. ## How to run a workshop In the examples below, we have used a virtual [Miro board](https://miro.com/?ref=annemariecharrett.com) but the design works just as well on a physical whiteboard. The format is in three simple parts. 1. Identify what the team is great at (Technical & Process) 2. Identify where can share it (From the Team to the world!) 3. Decide which, and how, key suggestions will be shared 📹 If a video explanation is more your thing, please see this 5-minute explanation. ### 1 ) Identify what the team is great at (Technical & Process) ![A Miro board to help a team identify what they are great at (Technical & Process)](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/03/image.png) ⏰ **How long:** Spend about 5-15 minutes. Stop when people have run out of ideas. 1. Ask the team to brainstorm ideas. Add these ideas to two different coloured stickie notes. We are using blue and red in our example. 2. For technical activities, use the blue cards and the red for process activities. Everything should be able to be classified as either technical or process. 3. Encourage the team to focus on ‘What do we know’ and ‘What have we learned that we can share’. 🗒️ **Facilitator notes:** Consider the timeframe you apply this to. You might want to restrict suggestions to the last three months (or the last time you ran the workshop), or perhaps since the team was formed, or only cover suggestions from the most recent project or block of work. 🗒️ **Facilitator notes:** Sometimes, a team will only focus on their technical ability and it is worth reminding them that their ways of working are equally important. They might worry that these aren’t ‘perfect’ or unique enough to share with others but each team will be on its own journey, and their experiences will always be valuable to others. 💡**Example:** Maybe you release features using ‘[feature flags](https://www.martinfowler.com/articles/feature-toggles.html?ref=annemariecharrett.com)’ and that has meant you have more control over product changes. ### 2) Identify where they can share it (From the Team to the world!) ![A Miro board to help the team identify where they can share it](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/03/image-1.png) ⏰ **How long:** Spend about 10-15 minutes, depending on the number of ideas generated from the previous step. 1. For each of the ideas generated from the previous step, decide where they should be shared. You can move or duplicate the stickie notes; it's up to you. 2. You might want to share some items in multiple places, so duplication is helpful here. 🗒️ **Facilitator notes:** Change the sections (Team, Stream, Department, Company, The World) to suit your organisation and context. It doesn’t matter what they are but they should be relevant to you and your organisation. Maybe you don’t have streams of work but do have projects that multiple teams contribute to, for example. Importantly each section should extend the reach of the previous, so the narrowest scope is on the left and the largest scope on the right. 💡**Example:** Maybe you want to tell the department about how you engage with your stakeholders. Or maybe you want to tell the company how you approach learning as a team activity. ### 3) Decide which, and how, key suggestions will be shared ![A Miro board to help the team decide which, and how, key suggestions will be shared](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/03/image-2.png) ⏰ **How long:** Spend about 10-20 minutes with the aim to identify 2-6 key items. 1. For each of the ideas generated from the previous step, decide which are the key ones to share with other people. This is helpful if you have generated a lot of ideas. Concentrating on the ones that have the most impact might be useful. It is suggested to duplicate stickie notes from the previous step so as to keep a reference on where you are sharing them. 2. After selecting the key ideas, think about how you can share them. Add these as additional stickie notes, shown in white in our example. 3. Encourage the team to add their own ideas on how to share things. Some have been added for inspiration, but many more opportunities will not be listed. 4. When finished, you might want to add these key areas as items on your next sprint. 🗒️ **Facilitator notes:** It can help to spend a few minutes at the start brainstorming all the available ways, for your context, that you can share information. 🗒️ **Facilitator notes:** Depending on the number of suggestions generated, you might decide to share them all. The important thing to consider is the impact of those suggestions, especially if many of them exist. Asking the team to identify key ones helps them to focus on the most impactful ideas. Limiting the shared suggestions can also help reduce the team's load and make it feel less like a chore and more like a celebration. 🗒️ **Facilitator notes:** Commit to sharing as a team, perhaps assigning tasks within the session itself. 💡**Example:** Maybe you want to share your idea around feature flags with the whole of the department and have decided that this will be via broadcasting on [Slack](https://slack.com/?ref=annemariecharrett.com) and further documentation on a Wiki. ## Categorising the ‘wins’ to support an improvement program The approach described above works well for teams to encourage a sharing culture and can be used exactly as described. If you would also like to use it to help enable a learning culture and to tie it back to the collective improvement and development goals of the department or business, assuming that you have them, then an additional step is needed in the workshop. To provide a practical software engineering example of improvement areas, we will use the following categories inspired by the ‘[Quality Culture Transition Guide](https://github.com/moderntesting/resources?ref=annemariecharrett.com)’ - Testing Breadth - Quality and Test Ownership - Technical Debt and Maintenance - Code Quality and Tools - Customer Data Analysis (Analytics) - Development Approach - Learning & Improvement - Customer Success - Leadership Emphasis You might want to use these, have your own already, or be in a context other than software engineering. To apply this to the workshop, we would simply take the additional step of classifying each idea chosen to be shared using the categories above. 💡**Example:** So, in our previous example of sharing how we release under feature flags, we would classify this as a ‘Development Approach’. ![ ](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2023/03/image-3.png) By doing so, we start to create a library of good practices and technical abilities categorised to the department or business need. This enables and makes it easier for, all teams to pull from these groups of practices when they identify an area they would like to improve in. ## Make it your own The ideas presented here can be used as described, adapted, and amended to suit your situation. Remember, this is about celebrating with a team and inspiring them and others to share and learn together. The principles are simple, yet powerful when applied to a department or organisation and, coupled with other initiatives, can lead to, or support, a culture of growth and improvement. Decide when and how often you want to run these. Some teams treat it as a separate exercise, while others use it as a replacement for an existing retrospective. Either works fine, and the advantage of using an already existing retrospective meeting means no additional load on people’s calendars. Doing it this way, you could arrange one per quarter with very little overhead. Running this workshop on a cadence can help to build a team’s ‘muscle memory when it comes to learning and sharing, so much so that, in time, the workshop isn’t needed, and it just becomes how the team works. Most importantly, have fun, and make sure that teams have the time and space for activities that support the growth that ultimately makes them, and the business, more successful. *Neil has kindly donated his fee for writing this article to 2 quality coach subscriptions - Watch out for this month's newsletter if you wish to nominate someone.* ### Quality Coach Newsletter 13 URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter-13/ Last updated: 2023-03-19T05:47:38.000Z This month we have a guest post by [Gerard McCann](https://www.annemariecharrett.com/author/gerard/). Gerard talks about those moments when a learning opportunity opens itself up. Of course, as a quality coach, you want to recognise those moments and use them as opportunities to share information, provide training, or suggest a facilitated workshop. I remember when I first started working in coaching. I'd done a lot of 1:1 training with free students, but never in a formal way at work. So when I was given that learning opportunity, I quickly realised the value of this approach. It's an excellent post, with some great perspectives I hadn't thought of before. And Gerard clearly has experience in this field. Thank you for writing it. ## Teachable moments in Quality Coaching In his post '[teachable moments in quality coaching](https://www.annemariecharrett.com/teachable-moments-in-quality-coaching/)', Gerard explains what a teachable moment is: > *The term [teachable moment](https://en.wikipedia.org/wiki/Teachable%5Fmoment?ref=anne-marie-charrett) comes from education. Wikipedia says it "is the time at which learning a particular topic or idea becomes possible or easiest." Unfortunately, it's not always possible to undertake proactive quality coaching, which can mean we have to quality coach more reactively. I identify and seize teachable moments most frequently when a gap exists between the team's expected and actual performance, e.g. something has maybe not worked out in a sprint. As a quality coach, I'm jumping in quickly to help the team with the following steps and prevention from a quality perspective. The article explains the how and what around this.* ## **Related Posts** Some situational and context-related posts. [Situational Quality Coaching (when to coach, train & mentor)Like many things in tech, knowing when to coach, when to train and when to mentor depends on the team, how experienced a quality coach is, and the nature of what is to be learned.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/07/1-4.jpg)](https://www.annemariecharrett.com/situational-quality-coaching/) [Do your bugs only glow when its dark?I do a lot of offsite exploratory testing in very aggressive timelines and consequently I have to admit, I sometimes start making basic mistakes.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2009/07/bugs-e1623019965964-1.jpeg)](https://www.annemariecharrett.com/do-your-bugs-only-glow-when-its-dark/) ### **Round the neighbourhood** I found this one through Alan's Page [Five for Friday](https://5blogs.wordpress.com/2023/03/06/five-blogs-6-march-2023/?ref=annemariecharrett.com); this one is for you, Michele! [What is ‘Developer Productivity’?Providing a mental model that informs developers where to focus their time and energy to improve productivity![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumAlex Herweyer![](https://miro.medium.com/v2/resize:fit:1024/1*7l2MA31lVP-FUrzay39EMw.png)](https://medium.com/@alexherweyer/what-is-developer-productivity-4c58ec1b903e?ref=annemariecharrett.com) One of my favourite bloggers, Adam Knight, wrote the article below. This blog is chockers full of excellent articles. So do yourself a favour and head over for a perusal. [Is UX the new waterfall?‘It’s a real problem’ my host admitted as we walked down to the entrance lobby. I was in the main office of a major social media company…![](https://www.a-sisyphean-task.com/favicon.ico)Helping to Tackle the Never-Ending Challenge of Creating Software ProductsAdam Knight![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5fDqKVXLoaxve3nPUcLe696ix05P-4A0AcQ8Ajxio4s0RfoliNZ9tTJxHT9I8vJ655CF4WjLnel5515wpCwJkPqLQONAXlXvaZLdGaL_ISERVhMIyeA48_DSxH2tOu4tj1VeF3WiaWNLEUZVbOFVXJTJz9cuaZg3XzSV9eDdD7IsQnXA8oBlpWecp6A/w1200-h630-p-k-no-nu/jonatan-pie-VlH2eHyE_50-unsplash.jpg)](https://www.a-sisyphean-task.com/2023/02/is-ux-new-waterfall.html?ref=annemariecharrett.com) And some new writers (at least to me!). [Types of API protocols- REST, SOAP, graphQL, gRPCDepending on the standards and underlying protocols, there are various types of APIs as discussed by Sowmya Sridharamurthy![](https://www.accelq.com/wp-content/uploads/2021/10/favicon.png)ACCELQ IncACCELQ Team![](https://www.accelq.com/wp-content/uploads/2023/03/types_of_api_and_its_usage.jpg)](https://www.accelq.com/blog/types-of-api-and-its-usage/?ref=annemariecharrett.com) [Integrate Cypress Automated Tests in a CI/CD Pipeline (Using Github Actions) — Part 1The idea behind CI/CD is to build, test, fail, and fix quickly. This allows for quick feedback and early detection of bugs. Automated…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumSandra Isamade![](https://miro.medium.com/v2/resize:fit:783/1*_YAAJHbT-_Vny0P89qBnZg.png)](https://medium.com/@sandra.isamade/integrate-cypress-automated-tests-in-a-ci-cd-pipeline-using-github-actions-part-1-ae455196c116?ref=annemariecharrett.com) ‌Finally, I wrote a post on leadership when change happens to you. [Dealing with unwanted change (coming to a state of acceptance)How do you deal with change when it’s something that happens to you? This post explores the sense of loss and anger when unwanted change happens.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1580566675342-9945a20eb134?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDh8fHByb3N0aGV0aWN8ZW58MHx8fHwxNjc4NDgzMzQz&ixlib=rb-4.0.3&q=80&w=2000)](https://www.annemariecharrett.com/are-you-your-missing-leg/) Until next month, Anne-Marie ‌ ‌*Like the Quality Coach Book?* [*Share a testimonial!*](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com) ### Are you your missing leg? URL: https://www.annemariecharrett.com/are-you-your-missing-leg/ Last updated: 2023-03-11T03:28:42.000Z Change isn't always difficult. There are lots of things about change I adore. I like getting pay raises. I like getting job promotions. I like it when my partner organizes a surprise event for us. And I like driving change. I like seeing gaps in quality and setting about improving and fixing them and changing others' lives for what I see as better. What's harder is any change imposed upon me. Change that I don't see benefits in. My initial instinct is to rage against the machine, stand up to the tank, plastic bag in hand. On these days, the struggle is deep. The sense of injustice is so strong. I recognize there's an element of grief here due to some loss and that with it comes the five stages of denial, anger, bargaining, depression, and acceptance. Meditation encourages me to look at this change in a different light. It encourages me to acknowledge and accept these strong feelings to come to a place of acceptance. Acceptance that the status quo has changed. Accept that these changes are outside of my control. And, importantly, acceptance that I, the person, still exist. So yes, I've lost something tangible, but what makes 'me' me still exists and remains untouched. I struggle to come to this place of acceptance. Instead, I feed my rage and anger by focusing on what is lost. But through meditation, I've realised that in doing so, I'm chaining myself to the exact thing I hate. Wouldn't it suit me better to focus on what I have? Who am I? If I allow myself to focus on who 'I am" rather than what I've lost, I open myself to joy and opportunity at what might be. This all looks frustratingly simple on paper. Yet, I struggle daily to achieve even five moments of this peace. But I know my experience tells me that those five minutes will gradually stretch to ten or fifteen until there will be days I forget I have a missing limb and instead walk with pride and joy at the ability to experience life. ## Meditations I've found useful [Resources \~ RAIN: Recognize, Allow, Investigate, NurtureThe acronym RAIN is an easy-to-remember tool for practicing mindfulness & compassion using four steps: Recognize, Allow, Investigate, Nurture.![](https://www.tarabrach.com/favicon.ico)Tara Brach![](https://www.tarabrach.com/wp-content/uploads/2018/01/hand-TookaPic-pexels-photo-722X358-e1555119272224.jpg)](https://www.tarabrach.com/rain/?ref=annemariecharrett.com) *Finally, I know I come from a privileged position in writing this at a time when thousands are experiencing layoffs in tech that is affecting income, family, and visa holders. I am not attempting to speak on your behalf, diminish what you're going through, or advise you on how you should feel or act. Instead, this is a personal reflection on the change happening to me and how I'm trying to work through it.* ### Teachable moments in Quality Coaching URL: https://www.annemariecharrett.com/teachable-moments-in-quality-coaching/ Last updated: 2023-09-11T10:14:00.000Z **Intro** I'm Gerard McCann. I live and work in Belfast, Northern Ireland, as a Software Development Engineer in Test (SDET) for a smallish (100-person) organisation. There are always opportunities to improve quality based on past and current experience by identifying and seizing teachable moments. The article shows how quality coaching based on teachable moments may be approached and can help the team's efficiency and effectiveness. **Quality Coaching** As a reminder, per Anne-Marie's article, [What is a Quality Coach](https://www.annemariecharrett.com/what-is-a-quality-coach/), a "**quality coach guides, supports and rallies a team to collectively own and improve quality through facilitation, education, experimentation and visualisation. They are a passionate advocate for quality**." **Teachable moments** The term [teachable moment](https://en.wikipedia.org/wiki/Teachable%5Fmoment?ref=annemariecharrett.com) comes from education. Wikipedia says it "is the time at which learning a particular topic or idea becomes possible or easiest." Unfortunately, it's not always possible to undertake proactive quality coaching, which can mean we have to quality coach more reactively. I identify and seize teachable moments most frequently when a gap exists between the team's expected and actual performance, e.g. something has maybe not worked out in a sprint. As a quality coach, I'm jumping in quickly to help the team with the following steps and prevention from a quality perspective. The article explains the how and what around this. **Winning hearts and minds** To win hearts and minds, a sterling piece of general coaching advice is: "ask before you tell", which I think relates to the IT concept of not calling someone's baby ugly. A practical approach for this is [clean language](https://cleanlearning.co.uk/blog/discuss/clean-language-questions?ref=annemariecharrett.com), which is from psychology and offers a simple set of questions to direct a person's attention and help them figure out the best way forward. Doing this helps ensure the quality coach remains neutral (i.e. nobody's baby gets called ugly) but also helps the team establish and explore the root cause and generate potential solutions. **Don't confuse speed with progress** Einstein said if he had 60 minutes to save the world, he'd spend 55 minutes thinking about the problem and 5 minutes coming up with a solution. That's around 90% thinking time to 10% doing time. For me, that begs the question of what a good ratio of thinking to doing should be for a given situation. For example, suppose the team seems to be speeding ahead but progressing slowly due to lower quality and more bugs. In that case, there's a teachable moment around the thinking-solution ratio we've adopted, and quality coaching can help the team establish what we can do differently. **Show, don't tell** A super simple but very effective quality coaching tip coming from many teachable moments is to ask if we can show, not tell. So I ask folks how we can get on the same page, possibly using a screen share to display a web page, a Miro board or a User Story rather than talking more abstractly. When we see the same thing, there's less possibility of misunderstandings and more effective and efficient progress. **Communications** Given the central role of communication in collaboration and things like bug reports, improving the team's communication is my key quality coaching goal. If we aren't communicating optimally, getting a message across takes much longer, and the point may get missed. A book I've used for communications in quality coaching is the [First Minute by Chris Fenning](https://www.chrisfenning.com/books/?ref=annemariecharrett.com). The book explains the root causes of poor communication and how three things should be given in the first minute: context, intent and critical message. This way, the receiver isn't left asking, "what does this relate to?" (no context), "why am I involved in this communication?" (no intent) or "is there something you need me to help with?" (no key message). An example of how communications improved based on the book: I'm working on the XYZ feature scheduled for Friday's release (context). I found a significant issue affecting your test automation (intent). Please give me 10 minutes for a show and tell (key message). **Times where I identify teachable moments:** - Mob programming - I've found this helpful in proactive and reactive quality coaching. Understanding how developers think and read things like acceptance criteria versus how QA/SDET do these things is also beneficial. Where there is a difference in thinking, there's a golden opportunity to do quality coaching to help the team improve. - Code reviews - These typically offer more of a passive opportunity for quality coaching when we leave comments in a pull request, for example, on how we think a user control may be used differently from how it has been written. However, we sometimes undertake dynamic code reviews/walkthroughs, which afford more active opportunities to take quality coaching to a higher level. - Bug triage - These are great for quality coaching on areas like bug validity, bug title/description, replication steps and any other bug information that has (or has not) been given. Bug prioritisation is excellent to ensure alignment between the various stakeholders we ask to attend and for us to discuss and check in on specifics around the meaning of quality as value to some person (at some time) - Agile ceremonies - Engineering review is a crucial ceremony where we perform quality coaching to help shape User Stories, improve acceptance criteria and get testability baked in. Retrospectives are another significant ceremony where the team gets to identify opportunities for improvement, and I pick up on areas where quality coaching can be done moving forward. - Escaped bugs - In [*Lessons Learned in Software Testing*](https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124/?ref=annemariecharrett.com), the authors encourage us to consider how bugs escaped and if these are natural consequences of the approach taken to quality. Root cause analyses done on escaped bugs take time and resources, but we undertake them selectively, given that they provide the team with many opportunities for quality coaching. **Some quality coaching phrases and ideas I use:** - **What do you/we want \[to be different\]?** This is a deceptively simple phrase (stated with or without the words to be different). However, depending on which word we emphasise, it has an entirely different meaning. For example: "what *do* we want?" versus "what do *we* want?". The first variation is getting at the distinction between knowing what we do and don't want, which can sometimes help focus the team on finding solutions rather than dwelling on the problems, and the second helps get focus on what the team wants rather than what someone else wants. There is another variation where we swap the word 'want' for 'need', the two subtly, yet sometimes notably, different. - **What** **can** **we do?** This is about creating a basis for action, thinking of moving forward and choosing one of several options. It also helps shift focus from things we can't do, as these can keep us rooted in the spot. - **What's the problem we're trying to solve?** I use this question whenever a discussion seems like it's going down a rabbit hole or if we are getting bogged in implementation details without fully considering the bigger picture. - **Would the roof cave in if we stopped doing this work altogether?** This is a question from a [quote by Peter Drucker](https://www.drucker.institute/thedx/whether-the-roof-would-cave-in/?ref=annemariecharrett.com), which goes well with another of his quotes: "There is nothing so useless as doing efficiently that which should not be done at all." This is a great question I ask during quality coaching to help us ensure we do the right things and thus avoid waste. **Conclusion** Teachable moments provide us with situational quality coaching opportunities through which we help guide, support and rally the team to improve quality. ### February 23 Quality Coach Newsletter URL: https://www.annemariecharrett.com/newsletter/february-23-quality-coach-newsletter/ Last updated: 2023-03-19T07:11:31.000Z Facilitating a workshop, be it exploratory testing or risk storming, card elaboration or developing a team test strategy, is the bread and butter for quality coaches. But how often have you held a workshop only to discover that the team is too busy or implement a new ritual or change? This month, the [premium article](https://www.annemariecharrett.com/how-to-run-a-team-based-coaching-session/) explores techniques to help cement the knowledge and ensure adoption by the team. I end by exploring the nuances of these techniques so you avoid pitfalls. ## Coaching quality that sticks You've finally convinced your team to hold a coaching session on a quality-related topic. Congrats! Now, to turn this opportunity into a successful outcome. Running a task-based, time-boxed coaching session is a great way to embed concepts and new ideas into a team. Task-based coaching sessions focus on the team performing a specific activity. By doing, rather than discussing, the team gets to experience the concept as opposed to a hypothetical discussion on the topic. Coaching sessions help teams understand the concept, but if you want to embed them into a team's psyche, it requires a consistent application. This means follow-up sessions, tweaks to team processes, and the inclusion of tasks into backlogs. So while you might be tempted to pat yourself on the back after a successful coaching session, realise that you have only started the change journey. Holding a coaching session on a topic is relatively simple. You could use a formula such as this: - Agree on the topic and outcome - Use a small bit of relevant work that can be time-boxed. - Direct them through the task. Answer questions directly and as best you can. - Once the task is completed, hold a short discussion session and explore the topic in more detail. - Agree on the next steps, such as follow-up tasks and further catchup sessions. Sessions like these look relatively simple to run, but like most things in tech, it hides the skill required to run one successfully. Here are some of the challenges I've experienced; ## Related Posts I've written about how to run specific facilitated workshops. [Team Test Strategy Workshop for Quality CoachesThis workshop provides a systematic approach to developing a team test strategy for an epic or large feature. It provides a team with a framework within which they can consider all the factors that impact testing.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/07/Screen-Shot-2022-07-04-at-7.21.10-pm.png)](https://www.annemariecharrett.com/testing-strategies-are-team-strategies/) [Quality Improvement Workshop - Quality Coach BookQuality Coaches, run this workshop to figure out team quality tasks prioritisation using the sailboat analogy. Instructions and a miro board help structure the workshop.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1452065656801-6c60b6e7cbc5?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDF8fHNhaWxpbmd8ZW58MHx8fHwxNjU0MzExNzIx&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/quality-improvement-workshop/) [How to define quality in diverse cross functional teamsWhat is quality in a cross functional team? This workshop provides you with a way of helping a team gain a shared understanding of what quality is.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1542626991-cbc4e32524cc?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fHdvcmtzaG9wfGVufDB8fHx8MTYyMzkwNTY3MA&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/quality-workshop/) ### From the Community Read some great posts this month. Here are some highlights. [How I Contributed as a Tester to a Machine Learning System: Opportunities, Challenges and LearningsHave you ever wondered about systems based on machine learning? In those cases, testing takes a backseat. And even if testing is done, it’s done mostly by developers itself. A tester’s role is not clearly portrayed. Testers usually struggle to understand ML-based systems and explore what contributio…![](https://cdn.infoq.com/statics_s1_20230217092835/apple-touch-icon.png)InfoQShivani Gaba![](https://res.infoq.com/articles/tester-machine-leaning-project/en/headerimage/generatedHeaderImage-1676401530402.jpg)](https://www.infoq.com/articles/tester-machine-leaning-project/?ref=annemariecharrett.com) Here are some tips for handling meetings that deviate, which might be helpful if your coaching session wanders... [Cutting People OffImpatience is a virtue. If impatience is solely your own, sorry, but you’re the asshole. But if impatience is shared, saving your colleagues from a tiresome conversation will make their day. Notice![](https://elizabethzagroba.com/images/avatar.png)Elizabeth Zagroba: Organizational AnarchistElizabeth Zagroba![](https://elizabethzagroba.com/images/posts/2021/shushing.jpeg)](https://elizabethzagroba.com/posts/2021/cutting%5Fpeople%5Foff/?ref=annemariecharrett.com) A book review by Lisa Crispin [Another book review! \_Grokking Continuous Delivery\_ by Christie Wilson - Agile Testing with Lisa CrispinReview highly recommending Grokking Continuous Delivery book by Christie Wilson![](https://lisacrispin.com/wp-content/uploads/2016/11/donkey-144.gif)Agile Testing with Lisa CrispinLisa Crispin![](https://lisacrispin.com/wp-content/uploads/2023/01/GrokkingCD.jpg)](https://lisacrispin.com/2023/01/30/another-book-review-%5Fgrokking-continuous-delivery%5F-by-christie-wilson/?ref=annemariecharrett.com) [Beth Marshall ](https://beththetester.wordpress.com/2023/02/02/chatgpt-for-bespoke-test-data-generation/?ref=annemariecharrett.com)shared this video on how to use ChatGPT to generate test data. And an insightful post from [Lee Hawkins about ](https://therockertester.wordpress.com/2023/02/07/lessons-for-testing-changemakers-in-this-is-marketing-seth-godin/?ref=annemariecharrett.com)being change agents, sometimes less emphasis on facts and evidence and more on compelling reasons is essential. That's it! We've got some new guest writers joining us. I look forward to their fresh perspectives, Until next month, Anne-Marie *Like the Quality Coach Book, [share a testimonial! ](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)* ### How to run a (quality) coaching session URL: https://www.annemariecharrett.com/how-to-run-a-team-based-coaching-session/ Last updated: 2023-02-05T03:51:46.000Z You've finally convinced your team to hold a coaching session on a quality-related topic. Congrats! Now, to turn this opportunity into a successful outcome. Running a task-based, time-boxed coaching session is a great way to embed concepts and learning into a team. Task-based coaching sessions focus on the team performing a specific activity. By doing, rather than discussing, the team gets to experience the concept as opposed to a hypothetical discussion on the topic. Coaching sessions help teams understand the concept, but if you want to embed them into a team's psyche, it requires a consistent application. This means follow-up sessions, tweaks to team processes, and the inclusion of tasks into backlogs. So while you might be tempted to pat yourself on the back after a successful coaching session, realise that you have only started the change journey. Holding a coaching session on a topic is relatively simple. You could use a formula such as this: - Agree on the topic and outcome - Select a small bit of work that can be time-boxed. - Direct them through the task. Answer questions directly and as best you can. - Once the task is completed, hold a short discussion session and explore the topic in more detail. - Agree on the next steps, such as follow-up tasks and further catchup sessions ## Challenges in Coaching Sessions like these look relatively simple to run, but like most things in tech, it hides the skill required to run one successfully. Here are some of the challenges I've experienced; - Keeping the session on track is tricky, especially if there are a lot of questions. - The team maybe have various degrees of experience, and balancing the session to ensure everyone is involved is complex. - Some teams may love the coaching session but failed to incorporate it into their daily habits. - You may find it hard to keep across all that's happening in a coaching session. . Here are some tips to help you get going. I will use learning to use Playwright as an example of a task. ### Planning a Coaching Session - Focus on a topic that will help in a team's current work. If you can link a task to a specific outcome for the team, they will be more motivated to attend and get involved in the session. So in our Playwright example, it might be, "by learning to create Playwright scripts, we can help deliver greater reliability of our features". - Plan beyond the coaching session. What will be required to convert the learning from this coaching session into a team's daily habit? I've observed it can take over a year for a new idea to become adopted into a team's culture. So who in the team can help you ensure success when you're not there? Think Delivery Lead or Tech Lead. - Agree with the team on the coaching outcome. For example, "by the end of the session, we will have set up and created a playwright script". Stick to this outcome and come back to it if the session begins to deviate. - Do a dry run. The last thing you want is to spend the first 30 minutes downloading the latest library dependency. - Think about the nuances of the task in a real life context. What are the challenges that teams will face when adopting this task? Then, think through how you might answer if these questions are asked. In our example, a question might be: "when is a good time to create a Playwright script"? Think where its useful to run a Playwright test and when its not. - Communicate in advance the topic, what they will learn, and the duration, so the team fully understands why and the benefits of the session. ### Running a Coaching Session There can be a lot happening during a team coaching session. Here are some tips to help the session go smoothly. - Keep focused on the outcome and time. This is not easy if there are lots of questions. Answer simple clarifying questions straight away. More complex open-ended questions can be answered during the discussion time. - Encourage pairing in tasks. This encourages people to discuss the topic and avoids people falling behind without you noticing. - Consider a facilitator to help you with those pesky setup questions, such as "I can't log in", that pop up regardless of how planned you are and can threaten to derail a coaching session. - Take notes while the task is being performed. I've used mind maps to track sessions. In particular, note complex questions that could have multiple answers. Then, discuss these topics in the debrief and explore where possible different answers might apply. ### Running the discussion section Discussion is where learning is consolidated, so avoid skipping it. In my experience, people enjoy this part of a coaching session. A discussion can be as simple as how the task went, or you can get more complex and discuss the nuances of the task. Here are some tips on running a discussion. - The objective of the discussion session is to give an insight into the topic's complexities. Time rarely allows you to discuss nuance in detail thoroughly, but it can be enough for people to think twice about the simplicity of the testing tasks. - As a rule of thumb, where there is little experience, and low motivation, be more directive. [Where there's high motivation and loads of experience, encourage exploration of nuance. ](https://www.annemariecharrett.com/situational-quality-coaching/) - As part of your planning, you may have identified follow-up resources and links for further reading. Share those either at the end or after the coaching session. - Right before you end the session, refresh on what was learned - Agree on the next steps. See below for more details. ### Post session work I encourage quality coaches to discuss the next steps on the information learned. Your time and the team's time are valuable; the topic was crucial enough to schedule a coaching session (something that you probably had to fight tooth and nail to get scheduled). Getting the learning [embedded into team habits](https://www.annemariecharrett.com/habits-in-quality/) and ways of working ensures that the session is not wasted. Here are some ways to embed the learning into your team's culture: - Agree on the next small bit of post-coaching work. Keeping it small ensures better chances of the team succeeding. For example, the team commits to writing 3 Playwright tests in the next sprint. - Get work put on their backlog. - Follow up during and at the end of your team's iteration. Pop in occasionally, and set up slack reminders to prompt people about the agreed work. Also, ask if they need any help. - Work to include the activities in the team's ways of working. Using the definition of done help incorporate new rituals and habits. - Once you're confident the concept is embedded in the team's work, you can reduce your involvement. That's it for now! I'm sure I've left out a tonne of complexity here, but hopefully, I've covered the key areas. What about you? Are there other aspects of coaching sessions that you have found helpful? Why not share? ### Quality Coach Newsletter 11 URL: https://www.annemariecharrett.com/newsletter/january-23-quality-coach-newsletter/ Last updated: 2023-01-22T03:12:34.000Z Primarily through interviewing, I’ve discovered many people have different ideas of what a quality coach may be. For example, some software testers call themselves this, as they occasionally coach the team even though their core work is software testing within a team. Some folks who do this type of work call themselves different titles (see the comments!). As a result, at CultureAmp, we doubled down on clarifying the role during hiring. So, what exactly is the difference between a quality coach and a software tester? In [this month's premium post](https://www.annemariecharrett.com/how-do-i-know-im-a-quality-coach/), I offer some ways you can detect the difference. In the discussions, you will see many people perform this type of role, but they call it different names. Life is never dull in tech! ## How do I know I'm a Quality Coach? Sitting within a team & helping teams with software testing doesn't necessarily make you a quality coach. A quality coach thinks and behaves differently from a software tester. Fundamental to the philosophy of quality coaching is that the team owns all aspects of quality. They are accountable for the quality and, by nature, should be empowered to make decisions on quality. > **A quality coach guides, supports and rallies a team to collectively own and improve quality through facilitation, education, experimentation and visualisation. They are a passionate advocate for quality.* It's a bit of a mental shift, so here are eight ways a quality coach behaves differently from a software tester. [Read on...](How do I know I'm a Quality Coach?) ## Related Posts Here are some related posts on quality coaching and hiring. [What is a quality coach? (Definition & nature of role)Defining the term quality coach and explaining this role in software engineering in contemporary organisations![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/01/Quality-Coaching-Model-2022-1.png)](https://www.annemariecharrett.com/what-is-a-quality-coach/) [Quality Coaching Role DescriptionYour company has decided to move to a Quality Assistance model where engineers perform all testing. They want a quality coach to perform a coaching role, so what should this new role look like?![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/11/QualityCoach-1.png)](https://www.annemariecharrett.com/define-the-quality-coach-role/) [Nine tips on hiring Quality Coaches (can you make it ten?)Hiring is tricky at the best of times, hiring a quality coach is trickier because the nature of the role is not yet well understood.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1518893494013-481c1d8ed3fd?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fGhpcmluZ3xlbnwwfHx8fDE2NjQ1MDU3NDY&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/hiring-quality-coaches/) ### Discussions Discussions were a new feature I added to this site. Since October, the discussions have been steadily increasing. I'm enjoying the interaction. So please keep posting me your thoughts and ideas. Also, want to hear my thoughts on a topic? Ask me here in [my suggestions box](https://dzqzm8wjktj.typeform.com/to/i7QBhoAh?utm%5Fsource=xxxxx). ### Next Month Next month, my post will be on how to think through tunnel vision when someone asks you to solve a quality-related problem and they're fixated on one solution like "automate all the things". I show how to use lateral thinking techniques, and Teresa Torres and her [Opportunity Solution Tree](https://www.producttalk.org/2016/08/opportunity-solution-tree/?ref=https://product-frameworks.com) can help us offer alternative solutions. ### From the Community There's no actual theme this month. So instead, these are posts I've enjoyed reading and may be helpful. [Job Search TemplateI’ll start this post by saying that if you’re one of the thousands of employees impacted by tech industry layoffs over the last year - I’m so sorry. I know how much it sucks. I was laid off last May, and I know how hard it is. If you’re still processing, I wrote about that too; I hope it can be some…![](https://angelariggs.github.io/favicon.ico)Quality Advocate{ AR }![](http://angelariggs.github.io/images/metadata.png)](https://angelariggs.github.io/articles/job-search-template?ref=annemariecharrett.com) [Five for Friday – January 20, 2022This was…not one of my favorite weeks. Other than a few long walks with the dog, I’m taking a light weekend to see if I can get my head back on straight. Here are a few things I read th…![](https://angryweasel.com/favicon.ico)Tooth of the WeaselAlan Page![](https://s0.wp.com/i/blank.jpg)](https://angryweasel.com/blog/five-for-friday-january-20-2022/?ref=annemariecharrett.com) [Building Skills Over TimeHolding learning sessions to get everyone up-to-speed.![](https://elizabethzagroba.com/images/avatar.png)Elizabeth Zagroba: Organizational AnarchistElizabeth Zagroba![](https://elizabethzagroba.com/images/posts/2022/butterfly.jpg)](https://elizabethzagroba.com/posts/2022/12%5F30%5Fbuilding%5Fskills%5Fimproved%5Frelationships/?ref=annemariecharrett.com) [The Three CulturesIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjn1l0Ff3vSduBv5EGySe47AmriNoDQtNqndVzNaSFyFNLfbFMYMzoAmPVlP1pmP7y4pKsCq7ubPSMRTxJrmym95TtolYWNiS7kdL2-OFtW5S_1hk3u__1Arf1p9XMaDrt2whFNDHR8Is_UWtAU4HiFMN8oouqowfmOZ_tOI3GOLSxZC9txfsO2Us8/w1200-h630-p-k-no-nu/Screenshot%202023-01-02%20at%2021.11.16.png)](https://visible-quality.blogspot.com/2023/01/the-three-cultures.html?ref=annemariecharrett.com) That's it for this month. With all the uncertainty going around, I'll share a quote from [Angela Riggs' blog](https://angelariggs.github.io/?ref=annemariecharrett.com) (which is incredible and worth a check out). > "👋🏼 While you're here - take a deep breath. Unclench your jaw, your brow. Relax your shoulders. Remember that you are cared for and loved. Have a wonderful day 💖" Anne-Marie *Like the Quality Coach Book, [share a testimonial! ](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)* ### How do I know I'm a Quality Coach? URL: https://www.annemariecharrett.com/how-do-i-know-im-a-quality-coach/ Last updated: 2024-08-25T10:01:16.000Z Sitting within a team & helping teams with software testing doesn't necessarily make you a quality coach. A quality coach thinks and behaves differently from a software tester. Fundamental to the philosophy of quality coaching is that the team owns all aspects of quality. They are accountable for the quality and, by nature, should be empowered to make decisions on quality. > **A quality coach guides, supports and rallies a team to collectively own and improve quality through facilitation, education, experimentation and visualisation. They are a passionate advocate for quality.* It's a bit of a mental shift, so here are eight ways a quality coach behaves differently from a software tester. 1. As a software tester, you champion quality within a team. As a quality coach, you help the team collectively be quality champions. 2. As a software tester, you test for gaps between product expectations and product reality. As a quality coach, you help teams explore these gaps. 3. As a software tester, you look at quality attributes related to the product. A quality coach helps teams explore these quality attributes as early as possible so the team can act on that information. 4. As a software tester, you ask, "how do I know the product is good enough? As a quality coach, you ask, "how does the team know if the feature is the right one to build, if the product is built right and if the product continues to support our customers beyond deployment"? 5. As a software tester, you develop the software testing strategy. A quality coach facilitates workshops for teams to develop their software testing strategy. 6. As a software tester, you decide what should be tested based on risk. As a quality coach, you help the team identify risks. Ultimately the team chooses how much testing takes place. 7. As a software tester, you might look for ways to improve your software testing approach. As a quality coach, you help the team identify a quality improvement program that they act on. 8. As a software tester, your goal is to remain an integral part of the team. As a quality coach, your goal is to become dispensable to the team. The critical differentiator is enablement. A quality coach enables a team to own their decision-making by building up a team's skills. In contrast, a test lead or software tester's work contributes to team output and may coach other team members to help them out. Sometimes the roles naturally morph from software tester to quality coach. For example, you could be a software tester in a team who, through coaching, discovers they've made their software testing role redundant. You then assume the role of quality coach for multiple teams. If you transition from software tester to quality coach, stepping back from being closely linked to the team's work can be difficult for both software testers and teams. You may be aligned with a team but no longer directly contribute to team output. With that change can come a sense of loss and 'not belonging'. It can also be a complex transition for teams who are used to software testers taking on tasks associated with the team output. A quality coach's role is to help a team adjust to that change. A practical way to do this is to identify the tasks a software tester typically does and then discuss how the team will ensure those tasks get completed. I believe neither the role of software tester nor quality coach is 'better' or worse than the other. They're just different. Some people prefer to be software testers; others love being quality coaches. Some contexts work better with a software tester in the team, and others work better with quality coaches. Tech is a big place, with room for everyone and many approaches. Which role do you think you are in? ### December '22 Quality Coach Newsletter URL: https://www.annemariecharrett.com/newsletter/december-quality-coach-newsletter/ Last updated: 2022-12-16T13:19:46.000Z December brings us a guest writer [Deb Sherwood](https://www.annemariecharrett.com/author/deborahs/). Deb is a quality coach at Squiz, where she coaches over ten teams. Understandably she's got a unique approach to her role. It underlies the diversity of approaches a quality coach can take. Read her article on [Five Quality Coaching Tips (when coaching 10+ teams)](https://www.annemariecharrett.com/five-quality-coaching-tips-coaching-10-teams/) ### Some Quality Coach Stats! It's hard to believe that the quality coach book is only one year old! Some stats: - 17 premium articles on quality coaching - Three free articles, [How do you do your testing?](https://www.annemariecharrett.com/how-do-you-do-your-testing/) [AB Testing Podcast](https://www.annemariecharrett.com/quality-coach-ab-testing-podcast/) and [What's your org optimising for? ](https://www.annemariecharrett.com/whats-your-org-optimising-for/) - One guest writer - 501 subscribers - 192 paid subscribers I'm so excited about how the book is going and look forward to including more guest writers next year. ### Related Posts Here are some related posts on quality coaching [Creating a Culture of QualityA culture that is embedded figuratively eats everything around it. Once a culture is defined, it takes on a life of its own. Slowly, bit by bit, more bricks are laid on top of those early foundations, those decisions. And, before you realise it, your culture has been set.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/11/startup-2.gif)](https://www.annemariecharrett.com/creating-a-culture-of-quality-in-a-startup/) [What is a quality coach? (Definition & nature of role)Defining the term quality coach and explaining this role in software engineering in contemporary organisations![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/01/Quality-Coaching-Model-2022-1.png)](https://www.annemariecharrett.com/what-is-a-quality-coach/) [How to explain Quality Coach (to your CTO)I describe the quality coach role in terms of a delivery lead, a product manager, a quality professional and a software developer.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/01/QUALITY-COACH-ROLE.png)](https://www.annemariecharrett.com/quality-coach-explainer-to-cto/) ### From the Community There are some great posts on the quality coach from the community Kim Engel: [Quality Coaching: Preventing production issues](https://isitgoodenoughyet.com/2021/09/04/quality-coaching-preventing-production-issues/?ref=annemariecharrett.com) [Most asked questions on “Quality Coaching”Usually, I receive some common questions when I talk about quality coaching. Here I decided to answer the common questions about quality…![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumSahar Khoshraveshan![](https://miro.medium.com/max/910/1*QfZEjbYB8IvW_AgUibn_DQ.jpeg)](https://medium.com/@saharkhoshraveshan/most-asked-questions-on-quality-coaching-449855f253fa?ref=annemariecharrett.com) [Quality Coach vs Software Tester - Vernon RichardsIn this talk Vernon talks about what the work of a professional coach looks like and how it might manifest itself in the Quality Coach role.![](https://www.ministryoftesting.com/assets/favicon-4b6ba0a4118ce928dfcf3d3230cdbb09347a5a9b8d98f244c79d0d56384758bb.ico)Ministry of Testing![](https://s3.eu-west-1.amazonaws.com/matrix.assets/8l9rquuj25p0v14mghul2jt6lpuc)](https://www.ministryoftesting.com/dojo/lessons/quality-coach-vs-software-tester-vernon-richards?ref=annemariecharrett.com) ## Testimonials I want to thank you, readers, for your support this year. In particular from these readers and their fantastic testimonials. Writing this book has been hard work, but your support makes it worthwhile. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/12/testimonials.png) Want to share a testimonial too? I use [Senja to collect testimonials](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)! See you in 2023! Anne-Marie ### Five Quality Coaching Tips (when coaching 10+ teams) URL: https://www.annemariecharrett.com/five-quality-coaching-tips-coaching-10-teams/ Last updated: 2026-04-13T22:25:27.000Z My name is Deb Sherwood, and I am a Quality Coach at Squiz. I have been at Squiz for nearly 17 years, starting as a trainer and moving into the engineering team as a software tester. Before joining Squiz, I was a software engineer working in an environment where we had thousands upon thousands of automated tests! As a trainer, I got to experience first-hand what it was like to use our product for the first time, and I saw how many different ways a user could use the system to achieve the same things. I lived through the pain of learning something new and the joy when it worked. This experience made me passionate about wanting to produce high-quality products for our customers that meet their expectations. Currently, the engineering team has 45 software and devops engineers…and one quality coach - me! Trying to help this many engineers can be overwhelming. Still, since transitioning from a quality engineer into a quality coach three years ago, I have worked out ways to keep an eye on quality and help the teams without going crazy! This is how I make it work. # 45 Engineers and 1 Quality Coach - How do you make it work? As professionals working in the quality space, we are asked to ensure that the products the teams are building meet a certain level of quality. We generally do this by having a team of people who can embed themselves into an engineering team so that they can educate everyone on what good looks like. We do this knowing we empower them to take on the responsibility for quality for their part of the system. But what happens if the quality team is a team of one - you? How do you ensure all teams reach a certain level of quality with the services they are building without splitting yourself into ten different pieces? How do you make sure engineers know what good looks like? As one quality coach to 10 product teams, I have to ensure quality is everyone’s responsibility and help teams understand there is no one person in charge of quality. Based on this, here are my five top tips on what to do when coaching a large number of teams ## Top 5 Quality Coaching Tips ### Encourage everyone to test from the start You want to encourage teams to test as early as possible, from when an idea is formed to when it hits production. The earlier they test, the earlier any defects found are cheaper to fix. If you wait until the task is in the validation phase, any defects found could be very time-consuming and costly to fix, especially if it has to go back to the design team to re-do the interfaces. ### Write, write, write! Write anything you are trying to communicate on “a piece of paper” (e.g. in a Slack message, on a Confluence page, in a Googe Doc). Write down the recommended practices, suggestions, how to test features, when to perform different types of testing, and anything that seems necessary. That way, not only can it be shared with existing team members, but it can be shared with anyone new starting at the company. This is probably one of the easiest ways to spread the word when working independently. But remember, things can change, and what you want teams to do can also vary, so make sure to periodically review what you have written! ### Help with the refinement of the more significant, more complex features. Being a “team of one”, you can’t be at every refinement or planning session, standup, retro or workshop for every feature for every team. All you would do is attend meetings! So instead, look ahead at what initiatives are being planned for in the coming months and aim to help teams with features requiring many changes to the product. These more significant, more complex features will potentially have a lot of unknowns for the team, especially if they are making changes to systems they may not have built themselves. If you sense there is any doubt around the changes required during the refinement sessions or there are unknowns, encourage the team to take time to investigate it further with spikes or proof of concepts. It is better to spend time investigating unknowns before you embark on changes than to get halfway through and realise you need to build it differently. ### Pair Testing Pair testing is the quickest, easiest way to educate engineers, especially junior engineers with less experience, on what “good” looks like. You can spend hours talking to engineers about testing but showing them real-life examples is how people learn. As a “team of one”, I don’t actively look for pair testing opportunities. Instead, I let them come to me. If an engineer approaches me with questions such as how many tests do I have to write? What should I test for with this piece of code? What should I do when validating a user interface? or if I get a sense of them being not so confident in what tests they have done so far, I ask them to show me exactly what they are testing and start talking through what we need to test. Over time, you will find that the engineer will start learning what they need to look for when testing and won’t rely on you as much to help. Also, sharing your knowledge with the engineers through pair testing ensures that everyone knows what quality is expected. As a result, you don’t have to worry as much about having to know everything that is going on. Instead, you are empowering the team to be responsible for the quality of their service. ### Talk, listen and support When you are only a team of one, people may think you are busy and won’t ask you for help. They may keep things to themselves so as not to burden you. Quality coaches need to be proactive with your listening skills. Take time out now and then to talk to people with whom you don’t currently work every day. Just by taking some time to talk to these people, you may identify issues you didn’t know about. For example, I recently chatted with a group of new engineers who had joined our team working on one of our legacy products. I noticed these engineers were quiet during the planning and refinement sessions. Their lack of knowledge made it hard for them to ask questions. But, learning a legacy system is difficult; it will take time for new engineers to become confident in these systems, and asking questions in these sessions helps build up knowledge. Not only will they learn a bit more about the product through the answer, but the questions themselves often reveal previous assumptions with critical information missing from the acceptance criteria. With this information, the feature could be correctly built, and the product quality would not be impacted. If I had not chatted with this group, I wouldn’t have known this was an issue. So remember to take time out to keep in touch with people you are not actively working with. You never know what you will find out! And that rounds out my top 5 tips for people embarking on this journey. Do you have any tip suggestions to add to this list? ### Quality Coach Newsletter URL: https://www.annemariecharrett.com/newsletter/quality-coach-newsletter/ Last updated: 2022-11-10T09:15:26.000Z This [month in my premium content](https://www.annemariecharrett.com/kent-becks-3x-and-quality-a-quality-coach-perspective/), I talk about the different quality strategies you might use depending on your company's stage. The three phases I look at are startup, growth and enterprise. I based the quality strategy on the 3x model developed by Kent Beck, where 'explore' equates to a startup, 'expand' to growth and 'extract' to an enterprise. It can also be applied to the product lifecycle and how it evolves. It's a beefy article I hope you enjoy it! ### Quality Coach Training Last chance to join my only face-to-face training this year by joining me at Agile Testing Days on November 21st. Discount codes are as follows: Use the promotion code [****ATD2022-AMCha** ](https://agiletestingdays.com/registration/onsite/?ref=annemariecharrett.com)to get a €140 discount for my tutorial and the conference days (Nov. 22-24). [Quality Coach Training at Agile Testing Days](https://agiletestingdays.com/registration/onsite/?ref=annemariecharrett.com) ### Related Posts Here are some related posts on strategy. [Software Development obliges but its options we needIt’s easier to know what you don’t want, then what you want. The cost of software development makes it hard to provide options.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1532920092365-f0ba59b286e9?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDEyfHxvcHRpb258ZW58MHx8fHwxNjI0NjU5MTYy&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/options-not-obligations/) [Testing Strategies must be flexible and adaptTesting Strategies are not designed to remain fixed in stone. As soon as you start to implement you realise the assumptions you made![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/01/rubber-meets-road-2.jpg)](https://www.annemariecharrett.com/emergent-strategy/) [Battleships AhoyI had a great day today. My youngest son, Alex (7) persuaded me to buy him a new game today. Its nothard. I’m easily persuaded. But the game of choice was interesting. It wasBattleships. Now, I remember this game. I played it (and loved it) when I![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1592080464412-acce590eead0?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fGJhdHRsZXNoaXB8ZW58MHx8fHwxNjIzODg2NDE2&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/battleships-ahoy/) ### From the Community There are some great posts on the 3X model from Kent Beck and others. Here are some: [Kent Beck’s 3X — Explore, Expand, ExtractSuccess & Payoff: navigating the path of winning ideas![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)RiverGlide IdeasRiverGlide![](https://miro.medium.com/max/1200/1*rbuWaY8fyo6-zSzCz2Hx5w.jpeg)](https://ideas.riverglide.com/3x-explore-expand-extract-b9aad6402a5a?ref=annemariecharrett.com) [Fast/Slow in 3X: Explore/Expand/Extract“Are we slowing down?” asked the software executive.![](https://cdn-static-1.medium.com/_/fp/icons/Medium-Avatar-500x500.svg)MediumKent Beck![](https://miro.medium.com/max/1200/1*3DYLmSUoH53MvuUc7KgniQ.jpeg)](https://medium.com/@kentbeck%5F7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539?ref=annemariecharrett.com) That's it for November! Don't forget comments are now open, so feel free to discuss! Love my book? Why not share a [testimonial](https://senja.io/p/qualitycoachbook/testimonials?ref=annemariecharrett.com)? See you in December! Anne-Marie ### Kent Becks 3X Model and Quality (a quality coach perspective) URL: https://www.annemariecharrett.com/kent-becks-3x-and-quality-a-quality-coach-perspective/ Last updated: 2026-05-05T05:47:58.000Z In his [article, the product development triathlon, Kent Beck](https://medium.com/@kentbeck%5F7670/the-product-development-triathlon-6464e2763c46?ref=annemariecharrett.com) proposes that as a product/company evolves, [value-maximising behaviour](https://medium.com/@kentbeck%5F7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539?ref=annemariecharrett.com) also changes. The 3X model he uses identifies three distinct phases in a product lifecycle; Explore, Expand and Extract. In 'Explore', we anticipate low payoff and low customer success while we experiment and 'discover' our value add. But on hitting that flex point and discovering value, we hope to expedite payoff and customer success quickly. 'Explore' is our growth phase. And finally, in the 'extract phase', where customer success is static, value is maintained through efficiencies that provide the desired payoff. Kent Beck best describes it as follows: > **"Explore**–the risky search for a viable return on a viable investment. Successful exploration is unpredictable, so the highest expected value strategy is to reduce the cost of experimentation and put a little investment into many, uncorrelated experiments. If you’re lucky, one of these experiments turns out to be unexpectedly successful, which leads to:.. > **Expand**–now things are going nuts (think Pokemon Go or Facebook Live Video). Unanticipated bottlenecks appear. All you have time for is to eliminate the next bottleneck just before it derails you. Once growth becomes routine, it’s time to: > **Extract**–now the shape of the problem and solution spaces are clear. One euro in equals three euros out. Playbooks emerge: here’s how you roll out the service in a new city. Economies of scale matter: delivering the service at lower cost is more profitable." Value is measured through **payoff** and **customer success** and should follow a growth curve that is not linear but s-shaped. Understanding and having reasonable expectations of value per phase allows us to maximise the behaviour that drives such value. According to Jerry Weinberg, [value and quality go hand in hand ](https://en.wikiquote.org/wiki/Gerald%5FWeinberg?ref=annemariecharrett.com)1. By extension, quality will follow a similar trajectory. If we know our product/company's phase, our quality strategy can adopt appropriate behaviour for that context. The rest of the article describes possible quality strategies for each phase. 1 *"Quality is value to some person" Gerry Weinberg -Quality Software Management: Systems Thinking* ## Explore In the explore phase, the focus is on conducting as many cheap experiments as possible to identify value add. When considering a quality strategy, optimise for the following: - Customer Feedback - Low-Cost Strategies - Speed to market This approach doesn't mean we ignore software testing. In this context, delivering value rapidly **is** quality. Therefore, any software testing performed needs to be considered in that context. Startups instinctively do this, delivering quality outcomes without having a software tester or QA on the team. And, of course, achieving quality is more manageable when everyone fits into one room. Here, inherently, you have context and are aware of what is happening and why. You probably wrote the code, and that knowledge allows you to fix and respond faster to incidents. And, your customers, knowing you're in startup mode, might be more tolerant of failure. ### Do Quality Strategies in Explore Quality strategies in the 'explore phase' should be inexpensive and facilitate customer feedback. Invest in habits and rituals that encourage a culture of quality regardless of the product you're building. Think TDD, pair programming, retros, small batches of value, all the good stuff you might think is overkill for the experimental phase. - **Functionality** Good unit test coverage, then exploratory testing behind a feature flag. Exploratory testing aligns with customer value and is a fast, effective way to find bugs. - **Security** Ensure engineers build with security in mind (dependencies, code, data and infrastructure). - **Observability** OpenTelemetry will provide you with observability and the ability to recover from production failures quickly. It's an inexpensive way of building quality into your system. - **SLO's** If you are going to measure anything, let it be an SLO. Make sure you use SLO-triggered alerts focused on customer value. - **TDD** TDD develops that vital software testing muscle into software engineers. Just do it; you're future self will thank you when you have to break up that monolith. - **Vertical Slicing** Get into the habit of teams delivering on vertical slices. When teams expand and grow, these habits will become lifesavers - **Find & Fix** Get into the habit of fixing bugs as you see them. Avoid testing phases and bug-fixing phases. ### Maybe Quality Strategies in Explore - Performance Testing Will the number of subscribers justify the cost of performance testing? If you choose to include performance testing, make it cheap and dispensable. - Security Testing This one is tough. A security leak or a hack can severely impact your reputation. But do you have a reputation? Context plays a massive part here. Consider your product & your clientele. If you choose to perform security testing, I would prefer outsourcing so you can focus on building features. ### Avoid Quality Strategies in Explore Never say never, but I wouldn't be doing the following: - Detailed documented processes. By the time you've finished the documentation of your process, it will likely be outdated. So save this for when you're in the expansion phase. - Large GUI test automation suites. Wait until you know you're value add before investing in GUI end-to-end test automation. Typically there's a high cost to these automated tests. If you must, limit the number, and use the time saved in maintenance on exploratory testing. - A large number of metrics. My definition of waste is collecting large amounts of data that fail to inform decision-making. Be intentional about what you choose to measure. Drop metrics not in use. ## Expand Congratulations! You've discovered your value-add, and you've pivoted. So let the crazy world of growth begin! In the Expand phase, crazy growth means lots of things that used to work well begin to break, and quality begins to suffer. For example, due to the crazy hiring that's going on, software engineers no longer have context and are unfamiliar with the code. The person on-call is no longer the person who built the code makes debugging and fixing harder. Not everyone is in 'the meeting', and decisions are lost. And, those trade-offs you made in the explore phase? Yep, they're coming back to bite. Welcome to the world of tech debt and scaling. In this phase, the only constant is change, and it's happening everywhere. Oh, and you will rarely have sufficient budget to cover *all the thing*s tm. In the Expand phase, intentionality and agility are your friends. In my quality strategy, I'd optimise for the following : - Scaling context, both domain and technical - An emergent quality strategy resulting from experimentation - Practices, rituals and tools that build quality into the system *(note from me: that was a tough list to distil!)* ### Do Quality Strategies in Expand Remember all those practices I encouraged you to optimise for when you were in the explore phase? They're your foundation, and it's time to build on them as everything scales. I've also included them in the quality strategy below. These practices and rituals may be harder to roll out now, but that doesn't mean you shouldn't try. Think of how you can influence people of their value, as the pressure to deliver quickly is in front of people's minds. - **Exploratory Testing** Exploratory testing is a fast, effective way to find bugs, and there will be plenty of those as your systems struggle to scale effectively. Exploratory testing has a side benefit: it builds domain and technical knowledge. Lean into bug bashes. Consider onboarding practices such as sandboxes with intentional errors for software engineers to find. Much more fun and engaging than reading countless confluence pages. - **Test Automation** Naturally, you will be creating unit tests, preferably through TDD. I like to also focus on the API layer in two ways. Contract Testing and Functional Testing. - **Security** Along with building security, it's to be intentional about security testing. Think tools, process, infrastructure and product risk and develop an approach that is lean and agile that works with the product teams. Avoid creating additional bottlenecks in the system by attempting to overlay a top-down approach. - **SLO's** OpenTelemetry and observability tools such as honeycomb allow you to move from the concept of 'perfect software' to fast recoverability. SLO-triggered alerts that wake you up only when customer value is impacted. - **Accessibility Testing** Quality in the 'experiment phase' can be pretty one-dimensional. That is, "did it work" and "did the customer like it"? Now you're a growth company; your product needs to work harder. It should cater for a diverse set of customer needs and customer locations. One crucial quality attribute is accessibility. Do Accessibility testing behind a feature flag in production. - **Usability Testing** Your product was once relatively simple and possibly designed and developed by one team. Now you may have multiple teams working independently on different features. This can become a usability nightmare! Design for usability in mind, get it into those discussions early by encouraging engineering and designers to collaborate and discuss usability early on. Use the concept of local previews to help early identification of design issues. - **TDD** If TDD is not part of your software development practices, it's worth experimenting with this practice. As a quality practitioner watching software engineers use TDD to build and design systems is pure joy, especially if matched with pair programming. - **Pair Programming** Pair programming is excellent for ensuring culture, practices, skills and ways of working are embedded into new hires, consider pair programming. Most people learn from doing, not reading confluence pages on high-level principles. There is so much benefit to discussing how to test something with another person. - **Vertical Slicing** Like TDD, one of these experiments will be a win at some point. Get into the habit of teams delivering on vertical slices. When teams expand and grow, these habits will become lifesavers ### Maybe Quality Strategies in Expand - **Hiring Software Testers** The expand phase might be an excellent time to consider hiring a software tester. Remember that quality is a team responsibility. Adopt a whole team testing approach, where the team takes on software testing as a collective responsibility. Sometimes, a software tester's work can become a bottleneck. You can avoid 'testing bottlenecks' by having software testers involved in all team conversations, allowing them to test early and often, and having social contracts where the team agrees to contribute to any testing work. - **Performance Testing** Scaling should mean that the number of customers is going through the roof. You're systems and architecture designed for startup mode probably can't cope. So, you beef up your cloud storage, memory, and CPU to keep the lights on; consequently, your costs start to go through the roof. Performance Testing can provide visibility of where systems begin to suffer, which is valuable knowledge. But Performance Testing can be expensive, so consider where it will add value. Monitoring latency in both development and production maybe be a more effective strategy. - **Enablement Teams** [Team Topologies](https://teamtopologies.com/?ref=annemariecharrett.com) is your friend. Consider a quality engineering enablement team that works to offer support to product teams in terms of developing test automation templates within repos. Look to embed testability and observability into architecture blueprints. ### Avoid Quality Strategies in Expand In Explore phase, the quality strategy needs to be agile and scale rapidly, so avoid the same approaches. - Define a detailed quality process across all teams In my experience, these processes will give you visible structure, but unless everyone's agreed to follow the process, it will probably lie, ignored in a confluence page somewhere. Instead, focus on localised solutions within teams and camps. It's tempting to look for alignment to provide consistency and repeatability in the hope of some efficiency. Do you want to optimise for efficiency at this point, though? - Large GUI test automation suites. Now you have decided on customer value; surely it's time to put those Playwright tests in, yes? But hold on, not just yet. You still want your software testing to be agile and respond to changes in scale and direction. Lots of test automation is possible, but it comes at a cost in terms of maintenance and slowing you down. So instead, focus on the API level. Think of [Pactflow](https://pactflow.io/?ref=annemariecharrett.com), which offers both contract and functional testing. - **Hiring a junior QA to 'fix' quality** Think strategically about your quality strategy. Expecting them to solve all your quality problems is unfair and unrealistic. Quality is a team responsibility, and sure a tester will help find those bugs, but developers still have to fix them. If you're hiring a junior QA to remove bottlenecks, then I'm sorry to be the one to burst your bubble. All your doing is shifting the problem elsewhere, and soon your QA will become the bottleneck. Alternatives might be to hire a QA per team or consider quality coaching. ## Extract The extract phase of product evolution suggests either market saturation or reaching as far as you can go regarding customer success2. You've demonstrated customer value, and consequently, the rate of change to customer value decreases. The extract phase is where you look for efficiencies to increase business payoff. In your quality strategy, you are optimising for: - Tooling & Framework consistency - Waste identification and reduction - Compliance & Reputation concerns (SOC2 & audits) ### Do Quality Strategy for Extract Phase Efficiency is the word of the day. The 'expand phase' purpose was to scale; in the 'extract phase', the fundamental goal is to identify efficiencies in both technical and internal business processes. You will continue to pay off technical debt and lower risk through technology updates. In the Extract phase, our systems may be the most stable they've ever been. But there is still a risk of failure. While the likelihood of failure is reduced due to fewer features, a large customer base results in a more significant impact. Therefore, in the 'Expand Phase', it makes sense to focus on increased test automation. Our focus is on delivering efficiency through speed and reliability. For example, some strategies to consider are: - **Automation** Identifying manual steps that are repeatable allows the opportunity for greater automation. Obvious optimisations exist in regression testing and manual runbooks, but also consider automating internal business processes that improve efficiencies. - **Playbooks and Ways of Working** Now is the time to embrace ways to keep people informed and aligned on practices, rituals and ways of working. Confluence pages, in the past, may have been localised to a team or a squad. Departments can begin to identify efficiency by creating playbooks and practices aligned across the whole department. And, now that the rate of change has reduced, these artefacts are less likely to become outdated rapidly. - **Metrics** Now that change has reduced, outcomes have become more predictable, and it makes sense to have leading and lagging metrics. DORA Metrics, in particular, are helpful as they track unplanned waste - **Security** Your focus is on repeatable and consistent processes that external companies will regularly audit to ensure compliance. Audits and compliance have probably already been introduced in the growth phase, as it is part of a scaling strategy. - **Enablement Teams** If you haven't done so, think about creating an enablement team focused on developing quality-related blueprints for product teams. Product teams should be able to pick up these templates and blueprints with minimal effort. - **Monitoring and Alerts** Pretty much indispensable in modern engineering architecture. I almost left it out because it seems as apparent as unit testing. *2 it's rare in SAAS companies that we remain in the extract phase for too long. Instead, they circle back to explore new features and new products.* ### Avoid Quality Strategy for Extract Phase There's not much to avoid when you're in the 'extract phase' because these systems can absorb a lot of poor-quality practices. So much is outside your control, and you will have limited opportunity to drive significant change other than something that increases efficiency. Avoid quality strategies that don't align with delivery efficiency. Instead, work to build relationships across departments to ensure that product quality doesn't drop. ### Where does Quality Coaching fit in? In the explore phase, I would encourage a senior software engineer to take on the mantle of a quality coach. This person thinks strategically about the trade-offs required to deliver a quality product. They would also think about where and when is the optimal time to test. In the 'expand phase', I'd consider how experienced teams are in software testing and quality-related activities such as SLOs and monitoring. If a significant effort is required to improve quality, I look to put a software tester on the team to coach the team on whole-team testing. Then, when the team reaches a level of maturity, I'd move to a quality coach model. You could, of course, have a quality coach model straight away, but it's a big ask for the team to step to that level, so be prepared for a long journey of quality improvements. A quality coach model makes perfect sense for the extract phase of a product lifecycle. It delivers the efficiencies required for that stage. In addition, it's well suited for identifying gaps in quality where waste exists. I feel like I've only scratched the surface of this blog post. There is a whole heap of other elements to consider. For example, I haven't even touched on where and when I would focus on data quality or where AI fits into the picture. And, of course, there's your product context to consider. I've predominantly considered a Saas product in a high-tech company. Your context will shape and influence your strategy in ways that may make the above suggestions counterproductive. What would you do differently? Please share! ### 🎃October 22 Quality Coach Newsletter, Halloween edition🎃 URL: https://www.annemariecharrett.com/newsletter/halloween-22-quality-coach-newletter/ Last updated: 2022-10-18T09:57:21.000Z I know two newsletters in one month! How good is that? And since it's the month of Halloween, this edition is "Quality Coach Newsletter 2" and just like any classic Halloween movie, it is the sequel that is the best! There are two bundles of goodness in this newsletter that couldn't wait until November. ## Quality Coaching MasterClass Firstly, I've wrangled a discount for my popular and well-known [one-day quality coach training masterclass](https://agiletestingdays.com/2022/session/quality-coaching-masterclass/?ref=annemariecharrett.com) held at Agile Testing Days in Berlin, Germany, on November 21st, 2022\. This class brings this book to life. It displays the art of facilitation and leadership and how to drive change at a team level. There are still [some seats left](https://agiletestingdays.com/2022/session/quality-coaching-masterclass/?ref=annemariecharrett.com). Use the promotion code [**ATD2022-AMCha** ](https://agiletestingdays.com/registration/onsite/?ref=annemariecharrett.com)to get a €140 discount for my tutorial and the conference days (Nov. 22-24). [Agile Testing Days](https://agiletestingdays.com/?ref=annemariecharrett.com) has 90+ agile testing experts offering more than 100 knowledge-sharing sessions of talks, workshops and keynotes. [Check out the details](https://agiletestingdays.com/?ref=annemariecharrett.com), and r[egister here](https://agiletestingdays.com/registration/onsite/?ref=annemariecharrett.com). It's a great conference and one not to miss! [Quality Coach Training at Agile Testing Days](https://agiletestingdays.com/registration/onsite/?ref=annemariecharrett.com) Not based in Europe or can't attend in person? Agile Testing Days also offers a Virtual pass, which includes a live stream of 10 keynotes and 36 talks and on-demand access for three months to all the recorded sessions. Please note this doesn't have my training workshop, which requires in-house attendance. This pass costs only a fraction of the in-person ticket. For most attendees, it costs €399 to enjoy nearly 50 sessions whenever you want. And for you dear readers, you have **a special discount of €199** using promo code **SAVE200EUR.** All you need to do is [register here](https://web-eur.cvent.com/event/75f0f809-eb83-4080-b1e2-ba4cafbb2d30/regProcessStep1?ref=annemariecharrett.com) for the virtual pass. Want more info? Check out the details [here](https://web-eur.cvent.com/event/75f0f809-eb83-4080-b1e2-ba4cafbb2d30/summary?ref=annemariecharrett.com). [Virtual Ticket ](https://web-eur.cvent.com/event/75f0f809-eb83-4080-b1e2-ba4cafbb2d30/regProcessStep1?ref=annemariecharrett.com) Have you got questions? [Uwe Gelfert](mailto:uwe@trendig.com) is your go-to person to answer all queries and questions. For me? I hope to see you there in person! ## What is your org structure optimising for? I penned some ideas on organisational structures based on the question, ["what is your product leadership optimising for?](https://www.annemariecharrett.com/whats-your-org-optimising-for/) Given how critical senior leadership is crucial to setting strategy and direction? How come we're not intentionally optimising for desired outcomes? Team Topologies goes some way to address this question for product teams, but there's nothing there on department structure. For example, is the role of CTO (Chief Technology Officer) still relevant? What should a CTO be optimising for? How does a CTO interact with a CPO (Chief Product Officer)? What is a good structure for saas companies? These are difficult questions to answer and I don't see people easily giving up existing power constructs, but it doesn't mean we shouldn't explore this space. Optimising our leadership space seems essential to ensure successful outcomes. My open question, which I address in [this post](https://www.annemariecharrett.com/whats-your-org-optimising-for/), "what is your org optimising for?" goes some way to exploring this space. Honestly? I don't feel I have all the answers on this topic. And I'd welcome your ideas. [Check out the blog post ](https://www.annemariecharrett.com/whats-your-org-optimising-for/)and see what you think. That's it! Happy Halloween! 👻🪦🧙 Anne-Marie ### What's your org optimising for? URL: https://www.annemariecharrett.com/whats-your-org-optimising-for/ Last updated: 2026-04-22T00:42:31.000Z 💡 This is a work in progress. The thoughts are a bit rough and not fully formed. I'm sharing because I'm keen to hear other perspectives to help my concepts take shape. Comments welcome. I've got a hypothesis around organisational structures. It's half-baked and not ready for release. I talked about this to a couple of people, who politely nodded at my rant. I don't know if the hypothesis has legs. I thought a community exploration could be helpful. And so I threw this question out on Twitter: > Is it just me or do others see tech org structures as hopelessly outdated? For example, should engineering really still be at VP level when companies are trying to optimise for product and delivery? > > Anyone seen any thinking around this space? > > — Anne-Marie Charrett | Quality Coach Book | (@charrett) [October 8, 2022](https://twitter.com/charrett/status/1578875661288378368?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) Melvin Conway famously said: "Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure." The corollary could be, "have your org structure reflect the system you want to design". [Team topologies](https://teamtopologies.com/?ref=annemariecharrett.com) by Mathew Skeleton and Manuel Pais is built on this hypothesis, though more at teams within a product department. I haven't seen anything or org structures; if you know of content, please let me know! I've observed different specialities optimise for what's important to them. For example; - Engineering tends to optimise for scalability and reliability - Product tends to optimise for discovery and business value - Delivery tends to optimise for consistency and alignment - Designers tend to optimise for customer and business needs Given all this, when a company designs its org structure, it first needs to think about what it's optimising for and then build an org structure with that in mind. In stream-aligned teams, where multiple disciplines work together on vertical slices to deliver an outcome, collaboration and communication are critical to product success. A delivery lead helps us achieve this through developing shared understanding and ways of working that allow time for sufficient absorption of different perspectives. As we are optimising for delivery in stream-aligned teams, it makes sense for a VP of Delivery to oversee the work. Not all teams require multiple disciplines, though. Enablement teams, for example, tend to have one or two specialities. While collaboration and communication are still critical, developing a shared understanding and mental models is more straightforward, as the perspectives tend to be more aligned. Many of these teams need a deep understanding of one speciality. Think platform teams or a complicated subsystem team. Here, there's a need to optimise scalability and reliability, so it makes sense for a VP of Engineering to oversee the work. Here's a sketch ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/10/IMG_0109.jpeg) There's so much to explore in this space; I've only started to scratch the surface. ### October '22 Quality Coach Newsletter URL: https://www.annemariecharrett.com/newsletter/october-22-quality-coach-newsletter/ Last updated: 2022-10-08T04:14:31.000Z ## Nine tips on hiring a Quality Coach This month's [premium content is about hiring](https://www.annemariecharrett.com/hiring-quality-coaches/). Hiring is difficult and time-consuming at the best of times. Hiring a quality coach role can be extra complex. In this premium content, I explore why and suggestions on how to navigate that complexity. I provide nine tips for hiring a quality coach. These tips are based on my hiring staff in multiple companies. Follow these tips and avoid making mistakes I made! Plus comments are now available on all quality coach book articles, so if you have a burning question on hiring, go ahead and ask. ## Let's discuss! As I mentioned, commenting is now available on most free and quality coach posts found on [annemariecharrett.com](https://annemariecharrett.com/?ref=annemariecharrett.com). This means any premium members can now participate in community discussions on the site. If you are already a premium subscriber, go ahead, and ask a question or comment on any of the quality coach book articles. Want to further explore and discuss content in any of the free posts? No problem, go ahead and comment there too! As long as you are a premium subscriber, commentary and discussion are available to you. ## Strong ideas, loosely held While looking for similar content on my blog on hiring, I came across these old posts. While I don't necessarily agree now with some of what I wrote, the challenges I'm trying to solve in these posts still remain today. What thoughts do you have on these posts? Let me know what you think! [Do you know team’s core needs?When leading a team, it’s easy to get overwhelmed by the noise of STUFF. Knowing your core purpose helps you focus your work.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1594434885674-0a15708152bf?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDN8fHNpZ25hbCUyMHRvJTIwbm9pc2V8ZW58MHx8fHwxNjIzODg2Nzcw&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/hows-your-signal-to-noise-ratio-going/) [Please don’t hire meIf you want perfect software and you want me to break your codeIf you’re going to measure me by the number of test scripts I writeIf you want me to tell you its ready to shipIf you wish to have 100% of your product testedIf you![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1584476318078-d38baa6edb77?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDd8fGhpcmV8ZW58MHx8fHwxNjIzODk0ODQx&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/please-dont-hire-me/) By the way, in case you are curious as to why I don't delete old content, even when my thinking has considerably changed? Well, they reflect my thinking at that point in time, and I think that's a useful data point to remember. When new information and new experiences come in, we should allow ourselves to absorb that and change how we think about things. ## Community Posts on similar topics There are way more interesting posts on hiring to share and here are a few below that have caught my eye. [How we do Product, Design and Tech recruitment at MentimeterWe believe in giving everyone a voice - regardless of who you are. So we built a platform that does just that. Our platform is not only our product but also our organization. A platform where people feel safe, where differences are embraced, a place where you can have fun. In order to give everyone…![](https://www.mentimeter.com/_next/static/media/mstile-144x144.0e312e04.png)Mentimeter![](https://images.ctfassets.net/rvt0uslu5yqp/5D78YiB3HJkHpwNvYXktH8/14bef90e4140e93289f64ef9b1431f8b/Screenshot_2022-02-08_at_09.42.32.png?w=1200&h=630&q=90&fm=jpg)](https://www.mentimeter.com/blog/product-and-tech/how-we-do-product-design-and-tech-recruitment-at-mentimeter?ref=annemariecharrett.com) [Doubt builds trust.I don’t trust people who always say yes. “Yes, I can finish that today.” “Yes, I tested it and it works and I didn’t find any bugs.” “Yes, I captured what you said in these notes.” “Yes, I assert I ha![](https://elizabethzagroba.com/images/avatar.png)Elizabeth Zagroba: Organizational AnarchistElizabeth Zagroba![](https://elizabethzagroba.com/images/posts/2017/dog.jpg)](https://elizabethzagroba.com/posts/2017/2017-08-06%5Fdoubt-builds-trust/?ref=annemariecharrett.com) [Hiring manual and automation testersIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://resources.blogblog.com/img/icon18_edit_allbkg.gif)](https://visible-quality.blogspot.com/2021/09/hiring-manual-and-automation-testers.html?ref=annemariecharrett.com) [It’s not all about “years of experience” - Agile Testing with Lisa CrispinI’m happy to see more people talking about job ads for testers with arbitrary requirements like “3 years experience”. In the last several years, I have met many testing and quality professionals who, with only one or two years in the profession, are sharing their valuable insights in conference talk…![](https://lisacrispin.com/wp-content/uploads/2016/11/donkey-144.gif)Agile Testing with Lisa CrispinLisa Crispin![](https://lisacrispin.com/wp-content/uploads/2022/09/TestingSkills.jpg)](https://lisacrispin.com/2022/09/08/its-not-all-about-years-of-experience/?ref=annemariecharrett.com) ## Testimonials That's all for this month! I hope you enjoy these newsletters as much as I do writing them. Really, really like my quality coach book? Why not [give me a testimonial? ](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com)I will place some of these on the website, so please be ok with that! [Give a testimonial](https://senja.io/p/qualitycoachbook/r/uVm11c?ref=annemariecharrett.com) See you next month! Anne-Marie ### Nine tips on hiring Quality Coaches (can you make it ten?) URL: https://www.annemariecharrett.com/hiring-quality-coaches/ Last updated: 2022-09-30T03:17:48.000Z If you're working in a company that is scaling rapidly and using the quality assistance model, at some point, you'll need to hire a quality coach (or two or three...). It can be tricky hiring a quality coach for several reasons: - First, if you are working with a talent advisor (TA), they may not fully understand the role and find it difficult to distinguish between the experienced tester and a quality coach. - Some software testers who call themselves quality coaches don't work with multiple teams. Instead, they sit within a team and occasionally coach people on software testing. While there's nothing wrong with that, it's not a quality assistance model where the team is accountable for all software testing. - Not all quality coaches have the same level of experience. Therefore, avoid assuming that a quality coach who works at a team level is suitable to drive strategy at a senior level. - The pool of quality coaches is not huge, so finding the right skillset will be challenging. The good news is that recently I've been doing a lot of hiring. So I've had an opportunity to learn a few things. 1. Work with your TA to ensure that the role description includes the message that the role works across multiple teams, not within a team. Taking in the adage, repeat and then repeat, have this message repeated numerous times in the hiring process. We include it in the job advertisement, the initial talk track when someone applies, plus we include it as part of our opening statement in an interview. 2. Be clear about what you are expecting [the quality coach to be doing](https://www.annemariecharrett.com/can-quality-coaching-be-a-career/). Take the time to write a job description and your desired experience level. For example, are they expected to work with squad leaders to drive strategy? Or are they expected to work closely with teams, tech leads and delivery leads? When we started hiring, I don't think we had this clearly articulated, but now we're clear on that. 3. Coach your interviewers. The quality coach role is not well understood even among quality coaches! I have sometimes found it challenging to articulate what I'm looking for. This lack of clarity makes knowing what good looks like difficult. Be open about this. Have regular retrospectives to adjust your process as you all learn more about the nature of the role. 4. Hiring is an expensive activity. It's in your interest if your candidates succeed in a job interview. So make it easy for them to demonstrate their best side. For example, if you ask for a case study, be clear about what a good case study looks like and what you are looking for, so the candidate can showcase that. 5. Interviews work two ways; you are being interviewed too! Be pleasant and welcoming. Look at the camera and try and smile once in a while. I've done a lot of interviewing with [Michele Playfair](https://twitter.com/MichelePlayfair?ref=annemariecharrett.com), and she's a great example of how to be welcoming in an interview. 6. Don't hold to a checklist too closely. Our job ad encourages people to apply, even if they don't fill in all the checkboxes. You'll get quite a few resumes from experienced software testers who don't have quality coach experience. In these, a helpful exercise is to identify people who demonstrate quality coach-like abilities. For example, have they handled change management previously? Have they worked closely with developers and collaborated with people outside of testing? Do I see examples of people owning their learning or being able to handle ambiguity and uncertainty? You can always work with people who are motivated to learn and grow. 7. Be inclusive in your hiring process. If you are hiring for a specific team/squad, invite them into the hiring process. Delivery Leads, Tech Leads or Principle Engineers are possible options. I have to confess I haven't done enough of this, but I plan to change that in the future. 8. And, of course, having a bit of reputation helps. My writing and training give me a headstart when it comes to hiring. So if you've worked hard on your reputation and think it might help your hiring, go ahead and use it! 9. Don't be afraid to tweak the hiring process if it's not working for you. Hold regular retros with key participants to explore different approaches and modify the process. That's it; some tips on hiring quality coaches. There's plenty more; I bet you could add another four or five to this list! What do you think? Do you have some tips on hiring in this space that has helped you? And yes, we're hiring at CultureAmp. Check out our [Staff Quality Coach job post](https://www.linkedin.com/jobs/view/staff-product-quality-coach-at-culture-amp-3278796665/?ref=annemariecharrett.com). ### Quality Coach September 22 newsletter URL: https://www.annemariecharrett.com/newsletter/quality-coach-august-22-newsletter/ Last updated: 2022-09-16T21:35:55.000Z ## Make Quality Coach book better Can you believe it's almost a year since I started writing this book? Personally, I'm really happy with the outcome. What about you though? If you are a regular reader, I'd love to hear from you on what you want me to [Keep, Stop, and Start doing](https://forms.gle/No1xGYo2JsYJLDvz8?ref=annemariecharrett.com)! Simply fill in this [short survey](https://forms.gle/No1xGYo2JsYJLDvz8?ref=annemariecharrett.com) to help me sharpen and focus the book and I'll send you a discount code to share with your friends and colleagues. ## Quality Coach book is growing As I said, I'm really pleased with how this book is progressing. But I want it to be better! Plans for next year include inviting guests with experience in quality coaching to write content. All guest content will be paid for by the book subscriptions. In addition, I'm adding comments and the opportunity to discuss posts. I'm excited to be able to turn the book into an opportunity for discussion and get feedback on direct articles. To cover the cost of guest content and hosting software, I'm increasing the new subscriber price from $USD1/month to $USD2/month. Yearly book subscriptions will increase to $USD20/year. This will come into effect on the 1st of October 2022\. Existing subscription prices will remain as is until renewal when they automatically increase to the new price. The 4-week free trial is gradually being phased out and replaced with a 5-day trial. With the changes over, let's talk about this month's content! ## Mapping your Delivery Process ‌This month's [premium content](https://www.annemariecharrett.com/quality-coach-mapping-a-delivery-workflow/) is a workshop to start mapping out a team's delivery process. Mapping out a team's delivery flow is particularly important where you have significant cross-functionality in the team that doesn't lend itself to constant pairing. The temptation is to perform work in silos and meet up at the end. This, though, can lead to a bloated testing phase at the end of each sprint or worse, right before a release. So you want to identify ways to intentionally introduce ways to improve shared understanding and to bring testing in earlier. You can do this in a number of ways, as I describe in the workshop. ## Related Posts [Reshaping Quality in Contemporary OrganisationsTo test well we need to rethink quality and how we can build quality in as opposed to testing for it at the end.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QEModelv3-2.jpg)](https://www.annemariecharrett.com/contemporary-quality-engineering/) [think about testing without a release in mindDon’t get tunnel vision over testing a release. Think holistically about where is the optimal time to identify potential risks to your system![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1559916711-8fb38588b900?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDc3fHxiZWxpZWZ8ZW58MHx8fHwxNjIzNzU3NjU4&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/agnostic-testing-do-you-believe/) [Quality in Software and that Toyota Production ModelMaking problems visible to teams and addressing them as close to the source as possible as well as building quality in.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1567789884554-0b844b597180?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDV8fHByb2R1Y3Rpb24lMjBsaW5lfGVufDB8fHx8MTYyMzgzMjAxMw&ixlib=rb-1.2.1&q=80&w=2000)](https://mavericktester.com/2017/08/04/archive-quality-and-the-toyota-production-model/?ref=annemariecharrett.com) ## Community Content Some great content to share from the community [Unblocking Your Test StrategyIn my new role as Quality Lead for my department, I get to figure out how to infuse everybody’s work with “quality”, and also figure out what that means exactly. One of my colleagues made it easy for![](https://elizabethzagroba.com/images/avatar.png)Elizabeth Zagroba: Organizational AnarchistElizabeth Zagroba![](https://elizabethzagroba.com/images/posts/2021/lightbulb.jpeg)](https://elizabethzagroba.com/posts/2021/unblocking%5Fyour%5Ftest%5Fstrategy/?ref=annemariecharrett.com) [Get Testing Bottlenecks Out of Your PipelinesThough more testing is automated, manual testing activities are here to stay for most businesses. That’s what is often is forgotten during development.![](https://devops.com/wp-content/uploads/2021/10/android-chrome-256x256-1-254x254.png)DevOps.comLisa Crispin![](https://devops.com/wp-content/uploads/2019/05/Testing-Bottlenecks-Pipelines.jpg)](https://devops.com/get-testing-bottlenecks-out-of-your-pipelines/?ref=annemariecharrett.com) [Deactivating the “Somebody Else’s Problem” FieldDeactivating the “Somebody Else’s Problem” Field![](https://www.ministryoftesting.com/assets/favicon-4b6ba0a4118ce928dfcf3d3230cdbb09347a5a9b8d98f244c79d0d56384758bb.ico)MoT![](https://s3.eu-west-1.amazonaws.com/matrix.assets/amu4p0mkga1v52n6lcpzx7gcncos)](https://www.ministryoftesting.com/dojo/lessons/deactivating-the-somebody-else-s-problem-field?s%5Fid=13402445&ref=annemariecharrett.com) That's it from me for this month folks! Thanks so much for subscribing to my book, and see you all in October. ### How do you do your testing? URL: https://www.annemariecharrett.com/how-do-you-do-your-testing/ Last updated: 2023-09-11T10:27:15.000Z One trap I fall into is assuming folks have the same testing knowledge and skill level as I do. Which is crazy and totally unfair. I've been working and pioneering ideas in software testing for my fairly long professional career. Why on earth would I assume that others who have less experience or who work outside this field have the same depth of experience and understanding of software testing that I have? This is why, in the nicest possible way, I often advise quality coaches who are starting with a new team to assume the team knows next to nothing about software testing. Begin with the basics of software testing and then work upwards in knowledge and skill. You'll soon discover if your premise is incorrect and then can adjust accordingly. Here's an example. As an experienced software tester, I push to include my testing as early and as often as possible. I know the benefits that this brings to the quality of the overall product. I offer to take releases early, unfinished even! Finding bugs early increases release confidence and minimises surprises late in the cycle. It's the 'no brains' move any experienced software tester will try and make. Experience tells me many software engineers think differently about when and how to do software testing. Often, they think of any testing outside of unit testing as a phase to be performed once a number of stories are done. And why wouldn't they? This is the process that they've had when working with software testers. Why would it be any different now they are responsible for the software testing? Unsurprisingly, software engineers who own the whole feature lifecycle also think in software testing phases. When they pick up a story, they put their developer hat on writing both feature code & unit tests. Once a number of stories are complete, they assume the mantle of a software tester. They then begin to think about how the testing will be performed. But it doesn't have to be this way. In fact, I'd urge them to think otherwise. To think about testing & development linearly, they fail to benefit from the efficiencies that owning both 'phases' brings. Owning feature delivery means you get to determine how and when you test. Yeah, sure, you can test in phases, but what if there was a better way? What if, before software development, they planned out how and what they would test? How might that change how they develop your software? What if during development, instead of having a story definition of done that ended at unit testing, they expanded it to include testing in production for a whole range of quality attributes? How might that change how they develop software? What if, prior to software development, they outlined the SLOs and critical user journey, identified open telemetry and used that to help provide observability as they developed instead of only in production? How might that change how they develop your software? I could go on, and I bet you could add a range of additional possibilities. Here's my advice. Stop thinking about testing in phases and begin thinking of software testing as an activity. Something performed in parallel to your coding instead of after coding. Think of it like breathing. You don't breathe in 10 times and then out 10 times. You breathe in, and then you breathe out, repeating until you don't. Software engineering is no different. ### Quality Coach: a team approach to mapping "the work" URL: https://www.annemariecharrett.com/quality-coach-mapping-a-delivery-workflow/ Last updated: 2022-08-31T21:50:42.000Z There are many habits that 'high-performing teams' exercise to deliver high-quality products. Twitter, the ultimate truth teller of all topics, gave me this when I asked the question. So I kickstarted the question with these ideas: > my thoughts so far: > > They consistently look for ways to develop a shared understanding > They test early and often using techniques such as pairing, and shoulder checks > They lean to small & frequent delivery of value to production > > — Anne-Marie Charrett | Quality Coach Book | (@charrett) [August 28, 2022](https://twitter.com/charrett/status/1563759438376615936?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > Frequent retros, small experiments, sticking to working agreements > > — lisacrispin (@lisacrispin) [August 29, 2022](https://twitter.com/lisacrispin/status/1564216250611470337?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > Honest conversations > > — Craig Wylie (@TheWylieKyote) [August 29, 2022](https://twitter.com/TheWylieKyote/status/1564240907263791104?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > They have a strong sense of shared responsibility for delivery > > — tobyhede (@tobyhede) [August 28, 2022](https://twitter.com/tobyhede/status/1563775922377228288?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > \- Quality-minded senior developers > \- Code base with few dependencies > \- Teams owning code to production cycle > \- Product management allowing time for testing and maintainance > > Longer version here 😁[https://t.co/XMwRAEXlYX](https://t.co/XMwRAEXlYX?ref=annemariecharrett.com) > > — Areti Panou (@unremarkableQA) [August 29, 2022](https://twitter.com/unremarkableQA/status/1564219284737359872?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > They focus on: > \- Delivering as a whole team > \- Slicing as small as possible(smaller than most think possible) > \- Outcomes not output > \- Progress over perfection > \- Experimenting continuously based on whole team reflection > > — Sponge Bob Test Pants (@RobMeaney) [August 29, 2022](https://twitter.com/RobMeaney/status/1564216906428678145?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) *Apologies if I missed your contribution; Twitter can be a beast with its replies.* **Today, I'm doing a deep dive into early and frequent feedback as a way to improve overall product quality.** In my experience, early and frequent feedback built on a shared understanding of what good looks like can massively impact the quality of what you deliver. Teams that build in early & regular feedback loops maintain alignment right to release. Not only are they more confident about the product as a whole, but they're also less stressed as typically they have "no surprises" releases. There's nothing like a problem discovered before or after deployment to raise your blood pressure! In its essence, software testing is a method of feedback. If performed in isolation, software testing gives you valuable feedback on your work. However, if it's performed with another, it takes that value up a notch. Just like input to one test is useful, and multiple inputs offer better coverage, so does testing with more than one person (oracle) make your testing more robust. And there are a host of other benefits; it builds domain knowledge, develops shared understanding, and develops teamwork and empathy for others' work. Of course, not all work can or should be done in collaboration. There is value in time for self-reflection and independent work. More and more, though, software development is becoming a team activity and working as a team becomes essential to a successful outcome. Perhaps the ideal sweet spot is to identify optimal moments in the delivery workflow to develop a shared understanding and to check the team continues to be aligned. Testing can be an optimal time to validate that you are satisfied with the work and that your team is confident with the outcome. The workshop I'm describing below helps teams identify ways to inject moments of shared understanding and paired testing into a team's delivery process. ## Mapping the Delivery Workflow An excellent place to start is to ask the team to map out their existing delivery workflow. Mapping out your delivery process is helpful for the whole team to understand where they do their software testing and how they collaborate. In addition, mapping this out gives you the starting point to discuss where and what the team can improve. ## Delivery Workflow Workshop ### Preparation Preparation is key in this workshop. You want to identify if this workshop might be helpful to the team at this point. No matter how motivated, stressed teams will find it hard to devote headspace to continuous improvement. I suggest the following; - Talk to delivery leads and tech leads. Would this workshop be something of value to the team? Is it a good time to run such an exercise? Getting buy-in from tech leads and delivery leads means that the workshop outcomes are more likely to be acted on. - A great book on this topic is ["making work visible" ](https://www.amazon.com/Making-Work-Visible-Exposing-Optimize/dp/1942788150?ref=annemariecharrett.com)by Dominica Degrandis - Create an online board based on the [delivery workflow workshop Miro Template ](https://miro.com/app/board/uXjVPbVUsuQ=/?ref=annemariecharrett.com)and share this link in the invite. - Work through your timings and the questions you want to ask. The questions frame the discussion, so think carefully about what you want to ask. You will need the following: 1. [Online Miro Template ](https://miro.com/app/board/uXjVPbVUsuQ=/?ref=annemariecharrett.com) 2. Book 2 x 45 minutes sessions or 1 x 90-minute session with the whole team 3. Provide an overview to the team at least two weeks in advance, outlining the workshop's purpose, the personal benefit, the outcome, and the process used. ## Workflow Mapping Session One *The first part of the workshop aims to identify the team's different workflows and ways of working.* 1. Ask each team member to map their workflow process for the agreed iteration/sprint. 2. Using an agreed coloured dot, ask them to identify where the testing work is done. 3. In the same way, ask them to identify tasks that have work done separately, done in pairs, and done as a team. 4. Have each member talk through their process and explain their thoughts and motivations around the process 5. As a group, identify similarities and differences between the processes and encourage comment and reflection. I prefer to split them to allow the team time to reflect on what they've observed and learned from each. I like to end the first session here, but there's no reason you can't blend the two sessions into one and keep going onto session two. **Facilitator Role:** As a quality coach, your role is to facilitate this discussion and, once the session is complete, tidy and ready the board for session two. Collate similarities, highlight differences, capture observations, suggestions and thoughts and share before the next session. ## Workflow Mapping: Session Two Time to identify and action improvements. Think ahead about where opportunities might exist. If the team becomes stuck, you can suggest some ideas. For example, based on the discussion you heard, think about; - Opportunities to create a shared understanding of the work and its associated risks. Think card elaboration, risk storming and card kickoffs. - Opportunities to receive feedback on work as early as possible. Think pairing and shoulder checks, especially between different specialities. - Social contracts that the team agrees to on quality. Definitions of done, principles of clean code etc. - Opportunities to reflect and continuously improve. ### Session Two The [Keep, Stop, Start](https://www.arielgroup.com/improve-your-teamwork-with-keep-stop-start/?ref=annemariecharrett.com) pattern is useful to help identify specific activities that cover shared understanding and testing. Looking at the new workflow, ask the team: 1. What is helping our quality that we want to keep doing? 2. What is preventing us from doing quality well that we should stop doing? 3. What are new quality-related activities things we want to experiment with doing? *For option 3, frame any new idea as an option or an experiment. Again, no one is setting these ideas down in concrete as must be done. Instead, these are options that a team can experiment with.* Here's a possible list of options. The team may supply other options and suggestions; add those to your list. - Card Elaboration (do we understand the scope of work and what it means?) - Card Kickoffs to identify agreed acceptance tests - Shared review of the definition of done at completion. (have we done what we said we would do) - RiskStorming sessions at the start of the Epic to identify threats to business value - Whole Team Testing Strategy - Paired testing sessions between roles. For example, Designer & Front-End time boxed paired session, front-end & back-end paired session on integration tests. - Group Exploratory Testing Session - Accessibility & Usability Testing Sessions - Missing test automation suites - Retrospective on testing to identify what went well and what we could do better next time. - Shoulder checks to validate testing scope. - Pairing at handover points to check for alignment - Card Elaboration Workshops to generate shared understanding - API Test Automation (Pact) - Agree to a 10% allocation to quality improvement - Stop picking up new stories off the backlog until all of the team do the previous story. - Introduce, revisit the definition of done at story completion, at epic completion ## Finalising the roadmap Time permitting, prioritise the ideas based on impact and effort. Then ask the team to vote on what cards they want to begin with first. Next, focus on the top 1 or 2 ideas and suggest working on these. For each idea, emphasise the experimental nature of the concept and that based on feedback, we can discontinue or tweak or come up with a new idea once there is some data available. What is essential is that the team takes the first small step to move that card forward. Create cards, identify appropriate ownership and add to the team backlog. If you have an iteration manager or delivery lead on the team, work with them to ensure the cards are being addressed and delivered. ## Implementing change within the team. How well you work with the team's iteration manager or delivery lead often determines if this work gets implemented. Talk to them before this workshop and gain some consensus that they will work to implement any outcomes from the workshop. Working with the practice delivery leads to continuous improvement, and building quality into the process is an excellent way of consolidating ideas and ensuring their success. If this option is unavailable to you, ask to attend retros and/or arrange continuous health check catchups with the team to discuss how it's going. Again, be open and flexible to tweaking ideas or reducing the complexity of suggestions. ## A comment on the "flow of work." This workshop focused on a delivery workflow with a diverse cross-functional team. Technical teams with similar roles may find that reviewing a GitHub process or deployment pipeline is a more suitable exercise. ### Quality Coach July 22 newsletter URL: https://www.annemariecharrett.com/newsletter/quality-coach-july-22-newsletter/ Last updated: 2022-08-01T07:39:21.000Z This month's [premium content](https://www.annemariecharrett.com/situational-quality-coaching/) explores the topic of when to coach, train and mentor a product team. This is important, as how you coach one team differs from another depending on where they're at in terms of owning quality. [Situational Quality Coaching (when to coach, train & mentor)Like many things in tech, knowing when to coach, when to train and when to mentor depends on the team, how experienced a quality coach is, and the nature of what is to be learned.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/07/1-4.jpg)](https://www.annemariecharrett.com/situational-quality-coaching/) I look at two key factors, motivation and ability, and explore the teaching style to use appropriate and the types of activities a quality coach might take. ## Heuristics Heuristics are situational in that they encourage us to consider the context in which they are being applied. The following blog posts explore heuristics in software testing. [The Base Camp HeuristicHow you discover those bugs that are not obvious, bugs beyond the low hanging fruit? This post explores bugs using the basecamp heuristic![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2015/10/basecamp-1.jpeg)](https://www.annemariecharrett.com/the-base-camp-heuristic/) [The ‘Do Nothing’ heuristicWhen faced with loads of uncertainty and change sometimes the best thing you can do is nothing. Not panic stricken nothing though..![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2018/11/9984767934_6f14382d86_c-2.jpg)](https://www.annemariecharrett.com/do-nothing-heuristic/) [Indulge the hunch when Exploratory TestingThere is a moment in Exploratory Testing (ET) when you come to a full stop. Mostly, it’s because you are stuck. You simply don’t know what to do next. That moment can happen anytime.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/08/valencia-2.jpg)](https://www.annemariecharrett.com/hunches-in-exploratory-testing/) There are many more; check out my [free blog content](https://www.annemariecharrett.com/)! ## Community content on Heuristics There are some great articles on heuristics written by many in the software testing community. My favourite is this one written by Richard Bradshaw and Sarah Deevy, as it explains what a heuristic is in the context of software testing. [Software Testing Heuristics: Mind The Gap!Read “Software Testing Heuristics: Mind The Gap!” by Richard Bradshaw and Sarah Deery in Ministry of Testing’s Testing Planet![](https://www.ministryoftesting.com/assets/favicon-4b6ba0a4118ce928dfcf3d3230cdbb09347a5a9b8d98f244c79d0d56384758bb.ico)MoT![](https://s3.eu-west-1.amazonaws.com/matrix.assets/cnflii5b75xgrsczrq52os7c3u8a)](https://www.ministryoftesting.com/dojo/lessons/software-testing-heuristics-mind-the-gap?ref=annemariecharrett.com) Then there's Lena Wilberg's book with gorgeous illustrations by Trish Khoo [Would Heu-Risk it?Testing skills demystified through 30 thought provoking lessons, told through a unique format mixing rhymes, theory and stories.![](https://leanpub.com/favicons/mstile-310x310.png)LeanpubLena Wiberg![](https://d2sofvawe08yqg.cloudfront.net/wouldheuriskit/s_featured?1627294864)](https://leanpub.com/wouldheuriskit?ref=annemariecharrett.com) you can purchase [cards](https://store.ministryoftesting.com/products/would-heu-risk-it-single-deck?ref=annemariecharrett.com) too. And Alex's exploration of microheuristics. [Microheuristics – Alex(andra) SchladebeckAlex(andra) Schladebeck](https://www.schladebeck.de/microheuristics/?ref=annemariecharrett.com) [Black Box Software Testing](https://bbst.courses/?ref=annemariecharrett.com) courses run by Altom Consulting offer a great grounding in the concept of heuristics in software testing. The [association for software testing](https://associationforsoftwaretesting.org/bbst-black-box-software-testing-courses/?ref=annemariecharrett.com) offers a community track if you are a member. That's it for this month! Anne-Marie ### Situational Quality Coaching (when to coach, train & mentor) URL: https://www.annemariecharrett.com/situational-quality-coaching/ Last updated: 2022-07-31T00:31:59.000Z Fun fact, a quality coach doesn't only coach; they also mentor, train and facilitate1. This article explores when to coach, train, and mentor a product team on quality. ## Coaching, Mentoring, Training Coaching, Mentoring & training are different teaching methods and valuable parts of your quality coach makeup bag. Like many things in tech, knowing when to coach, when to train and when to mentor depends on the team, how experienced a quality coach is, and the nature of what is to be learned. Imagine you wanted a product team to understand what makes a good test. A mentor might say *"here are some articles I've read on what makes a good test"* A coach might ask a team *"what do you think are the elements of a good test?"* A trainer will deliver a session on *"how to know what makes a good test"* All three methods allow the product team to learn the topic. The level of agency and the level of instruction are the core differences between the methods. When a quality coach teaches, they're instructing a team on how to perform a testing activity. When they mentor, they make content available, with the team choosing to use or not use the content. In coaching, they guide learning through the nature of the questions they ask the team. ![Training, Mentoring & Coaching by Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/07/1.jpg) Training, Mentoring & Coaching by Anne-Marie Charrett ## Benefits of Coaching, Training and Mentoring For a quality coach, teaching methods depend on the team, what they're working on, their abilities and understanding of quality, and how much they buy into owning quality. A quality coach must work with all levels of ability and motivation. Knowing what teaching method is, where it works well, how it benefits the team, and its pitfalls. The table below summarises this information for you. ![Benefits & Gotchas of Coaching, Mentoring and Training](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/07/2.jpg) Benefits & Gotchas of Coaching, Mentoring and Training ## Quality Coaching is situational Knowing where a teaching method works well plays a part in knowing when to coach, train or mentor. How motivated a team is to 'own quality' combined with their testing ability largely determines the type of teaching style a quality coach should use. By loosely applying the situational leadership model that looks to motivation and skill as factors to consider when deciding on appropriate leadership methods, we can create a handy quadrant to help know when to coach, train and mentor and what activities may be useful for that context. The quadrants below offer potential teaching styles and activities depending on the level of motivation and overall team quality-related skills. Let's take an example where a team starts its journey toward owning quality. They're enthusiastic about this opportunity to influence and direct quality in their team. However, they've not performed much testing before. They need guidance on what testing activities to perform and when they take place. This context falls into the lower right quadrant (LaHm-> Low ability, High motivation). A teaching approach is most appropriate where the team learns some basic concepts such as how to create a test strategy. However, if that team was sceptical and reluctant to embrace a whole team ownership concept, the team sits in the low left quadrant (LaLm -> Low ability, Low motivation). Here, a mentoring style with a focus on sharing experiences and content helps explain the why and build credibility on a whole team quality approach. Teams that have a good grounding in quality activities may find a coaching style preferable. Quality Health Checks can also come into play. Where teams are highly motivated, you could even consider having them coach other teams. Listen to your teams to gauge where the enthusiasm exists and use that to build up their ability and skill. ![Situational Quality Coaching by Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/07/Quality-Coaching-Activities.jpg) Situational Quality Coaching by Anne-Marie Charrett ## A word on team motivation Be cautious in how you interpret a team's motivation. There are many reasons why a team may appear unmotivated. It may not be the obvious "our team doesn't want to test". Teams that are under pressure to deliver rapidly may find this extended scope of work daunting. Some may have a fear of 'missing bug', and yes, some will be reluctant to take on testing work as it can be seen as low value, repetitive boring work.2 When motivation is low, try and identify places where even a little enthusiasm exists and start working with the team from there. Test Automation, with its technical emphasis and its promise of reducing boring, repetitive work, can often be a good place to start. Look at the situation from their perspective and begin there. Another approach for low motivation teams is to perform a gap analysis, identify the team's key concerns, and work to mitigate those risks. Remember, it's the team that owns quality, not you. Their ideas may differ from yours, which to a degree, is totally ok. As much as possible, give them agency. Of course, this isn't always possible if the mandate is driven from the top down. ## A word on a team's testing ability Avoid the assumption that low testing ability implies low motivation. There are many reasons why a team may have little testing ability. It could be that that team has lots of junior engineers who haven't been taught testing at university. Or it could be that in past companies, they've had a tester on the team who was reluctant to share knowledge. Past experience is not an indicator of low motivation. ## Final words from a quality coach There are many factors to consider in knowing what teaching approach to take when assisting a team. As we've discussed here, motivation and ability are two key factors, but you also need to consider your own personal experience and abilities and how you perceive yourself in the role of quality coach. Remaining observant and curious will help you better understand the team's context and considerations. And there you have it, situational quality coaching. 1 facilitation is the method used to perform team coaching. During my work I often substitute the word team coaching with facilitation. 2 It's very common for teams to have the perception that testing is boring. And yes, testing CAN BE BORING. But it doesn't have to be. Try exploratory testing as a team which can be fun and engaging. ### Quality Coach June (ish) Newsletter URL: https://www.annemariecharrett.com/newsletter/quality-coach-june-ish-newsletter/ Last updated: 2022-07-16T06:44:14.000Z ## Quality Coach Book ### Actionable & practical tips on being a quality coach [Freshen up your skills](https://www.annemariecharrett.com/#/portal/signup) This month I've published a mammoth workshop packed full of goodies to help you get started on delivering a team test strategy. This article has got everything from miro boards to a slide deck to facilitation advice. ‌‌‌‌‌‌‌‌Not ready to become a premium subscriber? Read some blog posts on different ideas around test strategies. ‌‌‌‌ ## Team Test Strategy Who writes the test strategy if there are no testers on the team? My article this month deals with this exact topic. Plus, it gives you in-depth downloadable material for running your team test strategy workshop. Did I mention that you can adapt it to your own context? How gold is that? Read the latest article [here](https://www.annemariecharrett.com/testing-strategies-are-team-strategies/). [Team Test Strategy Workshop for Quality CoachesThis workshop provides a systematic approach to developing a team test strategy for an epic or large feature. It provides a team with a framework within which they can consider all the factors that impact testing.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/07/Screen-Shot-2022-07-04-at-7.21.10-pm.png)](https://www.annemariecharrett.com/testing-strategies-are-team-strategies/) You'll need to subscribe to premium content to read the full article. And good news! I offer an intro offer where ALL content for free for 4 weeks. If you're fine cruising with the basic member model, there are loads of content to explore on strategies. Here's a taster of some of the posts I've written. [Testing Strategies must be flexible and adaptTesting Strategies are not designed to remain fixed in stone. As soon as you start to implement you realise the assumptions you made![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/01/rubber-meets-road-2.jpg)](https://www.annemariecharrett.com/emergent-strategy/) [How to avoid being fooled in software testingAs software testers, our role is to avoid being fooled by stuff that is potentially fooling others. We try to avoid being fooled by the product![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1610057074806-cc8dad38fa24?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDd8fGlsbHVzaW9uJTIwY2FyfGVufDB8fHx8MTYyMzU2NTg1Nw&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/how-to-avoid-being-fooled-in-software-testing/) The following blog post explains the subtle impact that a shared testing responsibility has on a team. [How does having a software tester in a team impact quality?How does having a software tester in a team impact quality?![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1600626333392-59a20e646d97?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDN8fGJvYmJpbmclMjBhcHBsZXN8ZW58MHx8fHwxNjIzOTc2MjQ5&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/bobbing-for-embedded-apples/) And finally one from the archives, a strategy for sustainability (the strategy holds true, even though the technology is a bit dated :) [Sustainable software testingThe amount of technology has escalated, are we thinking reduce, reuse, recycle? In our software testing let’s test if a system is sustainable![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1546883648-8c5648200abc?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fHN1c3RhaW58ZW58MHx8fHwxNjIzODg2MzMx&ixlib=rb-1.2.1&q=80&w=2000)](https://annemariecharrett.com/sustainable-software-testing/?ref=annemariecharrett.com) Regardless, have a fab month. And see you later in July! Anne-Marie ### Team Test Strategy Workshop for Quality Coaches URL: https://www.annemariecharrett.com/testing-strategies-are-team-strategies/ Last updated: 2025-04-26T21:35:02.000Z ## What is a Team Test strategy? A Team Test Strategy frames and informs a team's testing. It provides clarity on the scope and types of testing to be performed. The scope of a test team strategy can include design and infrastructure considerations. ### Benefits of Team-Based Test Strategies It can be very rewarding for teams to develop testing strategies. The diversity of roles brings a more rounded scope, especially if designers and product owners are in the workshop. New ways to make testing more efficient are discovered. In my experience, my greatest source of learning comes from software developers bringing innovative solutions to the table. Teams learn the subtleties and considerations required to test a feature. As a result, they can begin to better estimate testing time. Any coach will tell you that success is better achieved if teams have a say in the outcomes. A team-facilitated test strategy does this by holding a test strategy workshop. ## Who owns the test strategy? In the Quality Assistance model, where quality coaches assist teams in software testing and quality, the team is the custodian of the software test strategy. > The ultimate goal is for the team to dictate the software test strategy. This online remote-first workshop provides a systematic approach to developing a team test strategy for an epic or large feature. It provides a team with a framework to consider all the factors that impact testing. ## Market a Test Strategy workshop Any new concept or ritual is a form of change1 for the team, so treat it as such. Introduce the idea and what it involves. Talk about its benefits in terms of reduced rework and more accurate test estimation. Share articles and talks on the topic. For example, has another team started using test strategies and found them useful? Get them to speak to the team. *1ADKAR is a good model to help think about change management* ## Plan the Test Strategy workshop Be intentional about your planning. I've broken the planning into three sections: - The Feature/Epic to test - Timing (Duration and when to run) - A well-formulated meeting invite ### Feature/Epic for the workshop Ask the team what feature/Epic they want to use for the workshop. The ideal is a new feature to an existing familiar product. Avoid features that are massively complex and spread across multiple teams. If the team likes and thinks the concept is worthwhile, you can introduce more complex features. ### Timing Considerations Teams will want to know where this session sits within their delivery process. I would recommend somewhere in the planning phase, prior to estimations is ideal. This is because the test strategy will help inform test estimation. Timebox the workshop to two hours. Explain that a test strategy may take time now, but as they improve, the amount o as they improvef time required will reduce. ### Meeting invite The [4P Meeting Management Model](https://www.oreilly.com/library/view/making-the-team/0130143634/0130143634%5Fapp01lev1sec1.html?ref=annemariecharrett.com) is useful to consider when intentionally planning meetings. Purpose: Product: Personal Benefit: Process: I've provided a working example in the Test Strategy workshop pack. ### Test Strategy Workshop Preparation Collate as much data on the new feature as possible and share this at least a week before the workshop. Examples of information could be use cases, stories, persona, design specs, API's, definitions of done, and release process. Being familiar with context will help the team decide on value and risk. ### Workshop Structure The workshop is based on the [Miro Board](https://miro.com/app/board/uXjVOo3y93I=/?share%5Flink%5Fid=575274184554&ref=annemariecharrett.com) [Team Test Strategy for Quality ](https://miro.com/app/board/uXjVOo3y93I=/?share%5Flink%5Fid=575274184554&ref=annemariecharrett.com)coaches 1. Ask the team to review the Feature information, is it up to date? Has anything changed? 2. Given the feature context, ask the team to describe the features' value and concerns they may have. 3. Ask the team to consider how this feature impacts the rest of the system. *This will inform what regression testing to perform.* 4. Use the value and risk analysis to inform the types of testing the team agrees to perform. 5. Prioritise the types of testing. This can be useful if the scope of testing is enormous and the team is on a tight schedule. 6. Identify when and who will perform the testing. Offer to check back with the team at regular points throughout testing. In my team test strategy information pack, you will get slides that run you through this format with facilitation comments in the presenter notes. ## Team Test Strategy Information Pack Here is the information pack to download. It contains: - Facilitation Instructions - Miro Board Link - Meeting Template [Team Test Strategy for Quality CoachesTeam Test Strategy for Quality Coaches.pdf584 KBdownload-circle](https://www.annemariecharrett.com/content/files/2025/04/Team-Test-Strategy-for-Quality-Coaches.pdf "Download") ## FAQ on this workshop Q: What if the team's test strategy differs from my approach? A: As much as possible, empower the team to decide on the testing types. Once that team has experimented with applying the testing strategy, you can hold a retro to explore how it went and what the team could do differently next time. Q: What if the team doesn't know the solution or the technical depth as you described above? A: Outline as much of what you DO know. Then base your test strategy on that. Agree to revisit the test strategy once more information becomes available. Q: My team feels nervous about writing such a strategy. They've never done something like this before. A: If your team feels uncertain and nervous about creating a test strategy, offer to write them the first one so they can see what it looks like. Q: We're doing a second test strategy. Do I need to do the whole modelling again? A: Once you have done a few strategies, you will see areas of your product and technical models that remain static. Consider developing static models you can constantly refer to rather than always re-analyse. Q: As a quality coach I've not created a test strategy before. Does that matter? A: I would be open with the team about your experience in this area. Instead approach the exercise as learning for all of you. Of course, you could always run through the exercise yourself first to familiarise yourself with the experience. ## Final words I've found the key is maintaining curiosity, keeping an open mind and allowing the team to own the decision-making as much as possible. Avoid fixating on your ideas of what the test strategy should include. On the other hand, if the team asks for your opinion, be upfront and offer it. Focus on asking questions that open up the conversation on testing and facilitating to ensure an agreed scope of work. Try not to stress; you don't have to be perfect. Strategies are rarely fixed in stone and often need adjusting as you and your team face reality. So, when the dust settles, have a retrospective to figure out what worked and what to drop. Hopefully, your team will gain some valuable learnings from the experience and have insights you have not considered. Happy learning! Thanks to [Areti Panou](https://twitter.com/unremarkableQA?ref=annemariecharrett.com), [Maaret Pyhäjärvi](https://twitter.com/maaretp?ref=annemariecharrett.com) & [Anne Colder](https://twitter.com/Annosofie?ref=annemariecharrett.com) for feedback on this workshop. ### Quality Coach May Newsletter URL: https://www.annemariecharrett.com/newsletter/quality-coach-may-newsletter/ Last updated: 2022-06-07T08:49:43.000Z Welcome to the May newsletter. I know it's June, but we've had an election in Australia and I was busy saving democracy. This month in my premium content, the quality coach article explores the topic of Quality Improvement. Building on the sailboat retrospective workshop I show you how to prepare and run a workshop based on engineering-focused outcomes. The article is packed with practical tips, questions to ask and even a timer to help you plan the workshop. There's even a custom Miro board for you to use. [Quality Improvement Workshop - Quality Coach BookQuality Coaches, run this workshop to figure out team quality tasks prioritisation using the sailboat analogy. Instructions and a miro board help structure the workshop.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1452065656801-6c60b6e7cbc5?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDF8fHNhaWxpbmd8ZW58MHx8fHwxNjU0MzExNzIx&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/quality-improvement-workshop/) Not a premium subscriber? Try out the [4-week upgrade offer](https://www.annemariecharrett.com/premium) and explore the sailboat workshop and other premium content for free. [Upgrade to Premium ](https://www.annemariecharrett.com/premium) ## Related blog posts I've selected some posts I've written on the subject of quality and its ecosystem in particular in Saas and tech organisations. [Quality needs to be driven by business outcomesBusiness outcomes is what drives your quality engineering strategies. Find out what’s valued and work backwards to work out where to begin.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/RoadToNowherekeynote-2.jpg)](https://www.annemariecharrett.com/quality-engineering/) [Reshaping Quality in Contemporary OrganisationsTo test well we need to rethink quality and how we can build quality in as opposed to testing for it at the end.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QEModelv3-2.jpg)](https://www.annemariecharrett.com/contemporary-quality-engineering/) [Threats to QualityInstead of measuring quality - explore threats to quality and see if you can reduce these. Threats to quality are more than bugs![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/risk-2.png)](https://www.annemariecharrett.com/threats-to-quality/) ## Software testing community Some posts and content by people in the software testing community. [Introduction To Accessibility TestingLearn how to adopt an Accessibilty testing mindset and expand your testing with Deborah Reid![](https://www.ministryoftesting.com/assets/favicon-4b6ba0a4118ce928dfcf3d3230cdbb09347a5a9b8d98f244c79d0d56384758bb.ico)MoT![](https://s3.eu-west-1.amazonaws.com/matrix.assets/flllk028jyn8vnjh2cro79puooo8)](https://www.ministryoftesting.com/dojo/courses/introduction-to-accessibility-testing?ref=annemariecharrett.com) [Sample MoreIdeas and experiences on software testing, software development, conference speaking and organizing.![](https://visible-quality.blogspot.com/favicon.ico)Maaret Pyhäjärvi![](https://resources.blogblog.com/img/icon18_edit_allbkg.gif)](https://visible-quality.blogspot.com/2022/05/sample-more.html?ref=annemariecharrett.com) Have a great month! Anne-Marie ### Quality Improvement Workshop (run by a Quality Coach) URL: https://www.annemariecharrett.com/quality-improvement-workshop/ Last updated: 2023-09-11T10:27:27.000Z ## Finding and fixing gaps in quality A quality coach helps teams discover & fill gaps that impact quality. Call this quality improvement if you like. The focus is less on product quality and more on anything that prevents a team from achieving its engineering objectives that should align with its company-wide strategy. Over time, I've developed ways in which to help teams identify what their gaps are and work towards building the start of a roadmap to help fix that gap. I use a grassroots bottom-up approach as it offers a team an element of autonomy in what they choose to focus on. The emphasis is on experimentation through performing small achievable tasks that uncover a greater understanding of the nature of the problem ahead of us. This approach allows us to pivot our strategy based on what we learn, reducing the impact of opportunity cost. Not every company will be willing to sit with this level of ambiguity and may wish greater clarity on your plan to close the gap. A blend of top-down/bottom-up approaches may suit you better. Work with them on that. The rest of this blog post outlines the workshop and provides some downloadable questions and a miro template to use if you wish to run one. ## Quality Coach Sailboat Workshop **Purpose of the Workshop** The engineering quality workshop is used to identify three achievable team tasks that align with your company engineering objectives. **Output** By the end of the workshop, the team will have three small and achievable tasks that can be placed on the team's backlog. Each task will have an owner and an agreed timeframe by which the owner agrees to feedback on progress and learning. ### Sailboat analogy The quality coach sailboat workshop uses the common sailboat retrospective format but with a twist. This time, the workshop is used to scope work instead of reflecting on work. A massive shoutout to [Abby Bangser](https://twitter.com/a%5Fbangser?ref=annemariecharrett.com) who as it turns out, also used the sailboat retrospective in this way and who sharpened this whole workshop into what you see today. The rest of this blog describes the workshop in detail and provides downloads for you to use for your own workshop. There are five elements: the island, the wind, the rocks, the anchor and of course, the island. Here's what these elements mean: **Island:** The island outlines your engineering objectives. That is what your CTO/Head of Engineering care about and probably what they're being measured on. For example, shipping value rapidly to customers. I'm calling these engineering objectives. **Anchor:** The anchor is what is dragging the team down and preventing us from reaching the island. For example, our monolith prevents us from shipping value early as we have to wait for everything to be done before we can test. **Wind:** The wind is an idea of how we can overcome the anchors. An example could be access to a new capability, such as test coverage. **Rocks:** Risks that could potentially trip us up. For example, a rock could be lack of alignment across the org could lead to frustration in prioritisation. **Boat:** The tasks the team could begin doing that will work towards either removing rocks or implementing one of the wind ideas. ### Engineering objectives It's possible to perform this workshop without speaking to your CTO or knowing your company engineering objectives. As a side note, if you, your team or your engineering department doesn't have clarity on its engineering/product goals, methinks you're gonna need a bigger boat. Knowing engineering objectives allows you to frame your tasks in terms of how it supports engineering and your CTO. This can be useful if the team ends up needing to ask for an additional budget to support this work. Typical CTO/Engineering objectives can be: - Ability to release code at speed - Release with confidence - Shipping value rapidly to customers - Shorten iteration and improvement cycles - Lowering incidents and defects With that knowledge, let's jump into how to prepare and run this remote-first workshop. ### Quality Coach Sailboat Workshop Preparation Begin your preparations well in advance. A minimum of two weeks if you can. **Who should attend**: the whole team, including designers, engineers, tech leads, delivery leads & product owners. **Preparation Steps:** - Research your engineering objectives. Extra points if you can get them prioritised. You could, if you choose, select one objective only and narrow the discussion to that. - Share material with the team on this topic. For instance, share the engineering objectives. You could also help expand the team's concept of quality beyond product quality. I like to share [Martin Fowler's article](https://martinfowler.com/articles/is-quality-worth-cost.html?ref=annemariecharrett.com) on internal quality. - Talk to delivery leads and tech leads. Would this workshop be something of value to the team? Is it a good time to run such an exercise? Getting buy-in from tech leads and delivery leads means that the workshop outcomes are more likely to be acted on. - Create an online board based on the [quality sailboat workshop in Miro](https://miro.com/app/board/uXjVOv-HTOc=/?share%5Flink%5Fid=385834885690&ref=annemariecharrett.com) and share this link in the invite. - Work through your timings and the questions you want to ask. The questions you ask frame the discussion so think carefully what you want to ask. See [my timing breakdown](file:///Users/annemarie/Downloads/Quality-Coach-Sailboat-Workshop---A-Charrett.pdf) for structure and [question suggestions](file:///Users/annemarie/Downloads/Quality-Coach-Sailboat-Workshop---A-Charrett.pdf). [Quality Coach Sailboat Workshop A CharrettQuality Coach Sailboat Workshop - A Charrett.pdf20 KBdownload-circle](https://www.annemariecharrett.com/content/files/2022/06/Quality-Coach-Sailboat-Workshop---A-Charrett.pdf "Download") - Setup a zoom calendar invite for a 120-minute workshop. In the description, explain the workshop's purpose, what the output will be, how the workshop will benefit them and the agenda. - Organise a facilitator to take notes allowing you to observe and participate if required. You could have a slack back channel to converse on. You may be curious why this workshop involves so much preparation. It's because quality coaching work falls into the change management bucket. It requires taking people along a journey in order to be able to absorb the change. Workshop preparation goes to help explain the why and the personal benefits. The [change management model ADKAR](https://www.prosci.com/methodology/adkar?ref=annemariecharrett.com) is useful to consider when performing any type of quality coaching work. ### Quality Coach Sailboat Workshop Instructions: 1. **Icebreaker:** Remote workshops really benefit from icebreakers. Choose one of your favourites or [select from this list.](https://www.thebalancecareers.com/8-virtual-icebreakers-for-remote-meetings-5071396?ref=annemariecharrett.com) 2. **Explain** the sailboat metaphor (see above) and share your miro (or similar) board. 3. **Island:** Introduce the engineering objectives that your company has. Spend time asking questions and discussing these objectives. Possible questions could be: \- Are there any questions or concerns about the objectives? \- Are there objectives that are missing? \- Are these objectives too far-fetched? \- What is your measure of success? \- Which objectives do you think you are close to achieving? \- What areas of your work do you think to relate to each objective? 4. **Anchor:** Next up, work through the anchor element. Ask them to outline what's stopping them from achieving these engineering objectives. Questions such as: \- What is the biggest cause of defects/incidents in the team? \- When has fear stopped or slowed you down while making changes recently? \- Are there areas in which you feel only one or a few people can work? \- What ongoing maintenance tasks are in your schedule, whether daily, weekly, monthly or more? \- What examples of interrupted work have occurred in the last week? \- Are there any trends in this type of work? \- What would become anchors if we were to double the size of the team? Or double our customers? 5. **Wind:** Wind stands for the big or small ideas that are going to help us overcome our anchors. Encourage brainstorming & divergent thinking. Suspend judgement on the suitability of the ideas. The following questions might be handy: \- What are some big or small ideas for overcoming the anchors? \- If you could rewrite or re-architect something, what would make the biggest impact? \- What would you like to automate to reduce ongoing maintenance? \- What new process or tool would you introduce to make your changes safer? \- What new process or tool would you introduce to meet the objectives laid out? 6. **Rocks:** Finally, ask them what risks might impede their achieving these activities. You could ask something like: \- What is stopping us from implementing those improvements tomorrow? \- Are there alignment issues with different departments? \- Is there a tool that hasn't been able to get through procurement? \- Do you want or need more leadership support? \- Are there staffing gaps? 7. **It's time to build the boat.** Ask the team to list possible tasks they could do to move the dial on these goals. Encourage small actionable steps. Here are some sample questions: \- From all those ideas, what 3 tasks will you take back to your team and implement? \- Are there any "wind" ideas that you can spike/implement? \- What rocks can you break up by kicking off a conversation? 8. **Voting Time:** If there are a lot of tasks, ask each team member to vote for their 3 preferred tasks based on the information they have on the miro board. Ask for an owner. Seek agreement from the team on when to meet again to discuss progress. That's pretty much it in terms of running the workshop. Here are some tips I've learned along the way. There are no hard or fast rules here. Keep in mind that you're playing a long game and that the team owns quality (not you). ### Tips on the workshop 1) Allow time for reflection and discussion. Some teams may not have discussed their work as a team in terms of your CTO objectives. 2) If people don't speak up, don't push it. Some teams naturally prefer to reflect on topics later. Always provide the option to write as opposed to speak. End any workshop with an open invitation to reach out and chat. 3) If people are unwilling to take ownership of tasks, close the workshop, thanking people for their time. Again make it clear you are available for further discussion if they would like it. 4) Sometimes, you just have to wait for the right time. If teams are under pressure to deliver product features, as much as they may want to improve things, little will get absorbed if there's no headspace for new thinking. And that's it. The quality coach sailboat workshop. You're free to download and distribute content, but please ensure your attributes are appropriate. Happy learning! [Quality Sailboat Workshop ](https://miro.com/app/board/uXjVOv-HTOc=/?ref=annemariecharrett.com)© 2022 by [Anne-Marie Charrett & Abby Bangser ](https://annemariecharrett.com/?ref=annemariecharrett.com)is licensed under[Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1) ### Quality Coach April Newsletter URL: https://www.annemariecharrett.com/newsletter/quality-coach-april-newsletter/ Last updated: 2022-04-26T11:27:14.000Z Welcome to the April newsletter. This month in my premium content, the quality coach article explores the topic of Example Mapping Workshops, a concept first originated by Matt Wynn. Where Matt describes in his very detailed article, how to run a workshop, my focus has been to use an example story. I also run my workshop online. The article is packed with practical tips, slides and custom Miro boards for you to use. I hope you find it useful! [Example Mapping for Quality CoachesExample Mapping workshop for quality coaches contains instructions and slides using a typical story to help quality coaches get started on example mapping for their teams.![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/04/incomplete.jpeg)](https://www.annemariecharrett.com/example-mapping-workshop-for-quality-coaches/) Not a premium subscriber? Try out my 4-week intro offer where you can explore my quality coach content for free! [Info Offer ](https://www.annemariecharrett.com/intro4) You can unsubscribe at any time, but why would you? As Dave Harrison tweeted: > Just subscribed to [@charrett](https://twitter.com/charrett?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) content for the next year. Prediction: off the charts ROI for my team and my career goals. Best $9 deal on the internet... > > — Dave Harrison (@davadora) [October 17, 2021](https://twitter.com/davadora/status/1449815923196669954?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) ## Related blog posts For April, I've selected some posts I've written on the subject of discovery and/or workshops. [How to define quality in diverse cross functional teamsWhat is quality in a cross functional team? This workshop provides you with a way of helping a team gain a shared understanding of what quality is.![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1542626991-cbc4e32524cc?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fHdvcmtzaG9wfGVufDB8fHx8MTYyMzkwNTY3MA&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/quality-workshop/) [Consider other heuristics than SFIDPOT when testing storiesHeuristics can be really useful to us in testing. Sometimes they help us think of new ways to test, prompting us to ask new questions about the story (or the product) and the context in which we’re testing.![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/12/Screen-Shot-2019-12-31-at-6.41.25-pm-2.png)](https://www.annemariecharrett.com/heuristics-sfdipot/) [Creating a Culture of QualityA culture that is embedded figuratively eats everything around it. Once a culture is defined, it takes on a life of its own. Slowly, bit by bit, more bricks are laid on top of those early foundations, those decisions. And, before you realise it, your culture has been set.![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/11/startup-2.gif)](https://www.annemariecharrett.com/creating-a-culture-of-quality-in-a-startup/) ## Software testing community Some posts by people in the software testing community. [What I learned from giving my first ever workshopHere I share what I learned from giving my first ever workshop including what went well and what didn’t go so well.![](https://nicolalindgren.com/NIC.jpeg)Nicola Lindgren![](https://nicolalindgren.com/colourfulhands.jpg)](https://nicolalindgren.com/2016/10/27/what-i-learned-from-giving-my-first-ever-workshop/?ref=annemariecharrett.com) [You Never Finish Designing a Workshop - A Memoir of Friendship (Part 4)Jerry didn’t die in 2009, of course . He and the indomitable Dani found the medical team that was right for him. Jerry had major surgery and...![](https://quality-intelligence.blogspot.com/favicon.ico)A Memoir of Friendship (Part 4)Fiona Charles![](https://2.bp.blogspot.com/-pIhPA20a4go/W6g-57qUOqI/AAAAAAAAAXg/UDoUZGLmTUQzNDPpihWYlKdM6aOd0u1HwCLcBGAs/w1200-h630-p-k-no-nu/NM%2B%26%2BAZ_10-11-11__0050-2.jpg)](https://quality-intelligence.blogspot.com/2018/09/you-never-finish-designing-workshop.html?ref=annemariecharrett.com) [Agile Testing FellowAgile Testing Fellow is a community of agile testers that are forging new frontiers in agile testings. Take the course and join agile pionners Lisa Crispin and Janet Gregory.![](https://agiletestingfellow.com/assets/agile/favicon/agile-testing-fellow-icon-32-5b8e40318b6105bee152921cd2ee0be9d658fb963c14cd1a2f67c4d3a348d2a5.png)agile-testing-fellow-logo![](https://agiletestingfellow.com/uploads/ckeditor/pictures/25/content_Holistic_testing_-_understanding.png)](https://agiletestingfellow.com/blog/post/build-quality-in-with-shared-understanding-using-the-holistic-testing-model?ref=annemariecharrett.com) [Facilitation - the dinner party principle ](https://medium.com/cazoo/facilitation-the-dinner-party-principle-1e5c20009fe4?ref=annemariecharrett.com) That's all for this month! See you all in May! Anne-Marie ### Example Mapping for Quality Coaches URL: https://www.annemariecharrett.com/example-mapping-workshop-for-quality-coaches/ Last updated: 2022-07-31T00:55:25.000Z ### Discovery Work One of my first tasks as a software tester was to critique requirements. Before any software could be written, and with little context, my instructions were to critique them using the 4c's; clear, concise, correct, complete. Software development could begin only when the requirements had been critiqued and tests outlined. In doing this, we not only prevented mistakes and identified misunderstandings, but we also developed a shared understanding of what we were building that went beyond an agreement on wording. For example, the 4 C's meant we had: - scope agreement - knowledge of critical logic - implicit assumptions identified - possible risks to the success - a reasonable estimate of time required to perform work After leaving this company, I discovered this approach was atypical, which is a shame given the benefits it provided. Reduced ambiguity and better shared understanding, reduced rework, the risk of feature failure and helped teams remain within the "flow of work" as less context switching took place. A bonus was that estimates become more accurate, resulting in improved confidence when delivering customer value. ### Discovery Workshops Fortunately, since then, much work has been done to raise awareness of discovery work and its benefits. There are many [discovery workshops](https://cucumber.io/blog/bdd/example-mapping-introduction/?ref=annemariecharrett.com) such as [OOPSI](https://www.annemariecharrett.com/outcome-over-output/), [example mapping](https://cucumber.io/blog/bdd/example-mapping-introduction/?ref=annemariecharrett.com), and [three amigos](https://www.annemariecharrett.com/3-amigos-in-agile/), each with its strengths. For example, I find OOPSI, created by Jenny Marr, great for complex scenarios such as value streams. Alternatively, Example Mapping by Matt Wynne is ideal for smaller user stories. But, of course, everyone has their own personal preference. ### Example Mapping Example Mapping's strength is its focus on visualisation through examples. This workshop is based on but differs from [Matt Wynne's initial workshop](https://cucumber.io/blog/bdd/example-mapping-introduction/?ref=annemariecharrett.com) in that its format is #remotefirst. Plus, there's an opportunity for self-reflection and discussion after the exercise. ### Example Mapping for Quality Coaches **Participants**: quality coaches, teams wanting to learn about example mapping **Pre Reading:** Share Matt Wynne's blog post on [Introducing Example Mapping](https://cucumber.io/blog/bdd/example-mapping-introduction/?ref=annemariecharrett.com). It explains the concept and provides terminology and instructions on how to run such a workshop with a team. (For the benefits of conciseness I assume you've read this). **Benefits of my workshop:** - Allows participants to experience & learn example mapping in a safe context - Provide time for reflection on example mapping in their work context - Allows teams to reflect and discuss potential benefits and challenges of this approach **Essentials:** You will need: \-Miro with example mapping template (or similar tool) \-Zoom (or similar tool) \-90 minutes \-prepared slide deck **Prework:** - Using [Miro, create an example mapping template](https://miro.com/welcomeonboard/Umx3VFNsZEJRS05oMVptc2N0ejEyeFlUWWROc3ZqUXFVcGtPSlYyWjEwWkhWc0FFUVhPcU9SRTFvN2tvNXFxN3wzMDc0NDU3MzQ5MzM2ODg3NjIz?share%5Flink%5Fid=330646396041&ref=annemariecharrett.com) for a pre-selected story. The story I use has three rules to keep the experience short and sharp. - In slides, provide an overview of the purpose of example mapping, focusing on how it's easy for misunderstandings and mistakes to come about. You can use my slide deck if you like (see below for link). - Allocate the role of the facilitator for each group and provide them with instructions on what they need to do. - Slide of discussion-type questions post-exercise (see below for link). **Exercise Instructions:** - Break up the group into teams no bigger than 5, giving each group its own space on Miro with a story, and blue, green and red card templates to use in the exercise - Each team should have a facilitator that acts as a product manager. - Ask each group to come up with at least 1 example for each rule. - Any questions the facilitator can't answer, are placed on a red card. - Merge the groups - Ask each group to share their examples and place them on a shared board - Ask each group to share their questions and place them on a shared board - Encourage observations on the nature of the examples and the questions wrt to the story. Keep this short. 5 minutes max. ### Discussion & Self Reflection Time for some in-depth discussion providing an opportunity to consider how this type of workshop applies to their context. I encourage people to respond in chat or verbally, depending on their preference and energy levels. The following questions are some self-reflection/discussion questions. I give participants time to read the questions and think about which ones they want to answer. Alternatively, split participants into breakout rooms and get them to discuss three questions with the intent of sharing these insights as one group. ### Discussion & Self Reflection Questions Some possible questions are: 1) What are your thoughts on example mapping? 2) What went well for you? 3) What was challenging for you? 4) How would example mapping work for a product team? 5) What might the challenges be in rolling out such a concept? 6) What might the benefits be? 7) What might be the first next step you could take? Discussions are my favourite part of any workshop as it's where participants apply their experience to their context\*. For example, when I recently ran the workshop, we observed the following: - Often teams may feel they don't "have time" to perform such a workshop. - Don't roll out example mapping just for the sake of it. Instead, ask yourself: "Is there a problem here?" - Quality Coaches can ask open-ended questions without *knowing* the context of the story. - Having a Delivery Lead run the workshop can be helpful, allowing you to participate. - Rollout example mapping as an "experiment" instead of a permanent fixture in a process. - The first time performing this might take longer than the suggested 25 minutes. Manage expectations with teams that this amount of time will reduce as teams become more skilled at using example mapping. ## Teaching Moments I like to end the class with a couple of slides on practical tips. You can download the full detail of the workshops here: [ Example Mapping for Quality Coaches Slides Slides to go along an Example Workshop for Quality Coaches Example Mapping Workshop v2.pdf 1 MB download-circle ](https://www.annemariecharrett.com/content/files/2022/04/Example-Mapping-Workshop-v2.pdf "Download") That's it! Have a go, I'd love to hear how the workshop worked for you! Continue to support my work by maintaining attribution and linking back to my online book. Thank you for your tremendous support, you rock! \*I learned about experiential workshops after attending PSL with Jerry Weinberg, Johanna Rothmann and Esther Derby. \*\* Payroll exercise inspired by Jim Holmes Kudos to [Michele Playfair](https://www.linkedin.com/in/ACoAAAEA4IMB0HaT3OnIhDnVBL97N2Lo8nLM2EM?ref=annemariecharrett.com) who gave me the suggestion to try this out. [Example Mapping Workshop for Quality Coaches ](https://annemariecharrett.com/example-mapping-workshop-for-quality-coaches?ref=annemariecharrett.com)© 2022 by [Anne-Marie Charrett ](https://annemariecharrett.com/?ref=annemariecharrett.com)is licensed under [CC BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1) ### Quality Coach March 2022 Newsletter URL: https://www.annemariecharrett.com/newsletter/quality-coach-march-2022-newsletter/ Last updated: 2022-03-27T19:50:07.000Z Welcome to my regular newsletter where I provide updates and links to content that I enjoy. Premium readers a special thanks. You encourage me to continue to write and share my experiences. It's hard to digest the fact that I've been consistently writing on this blog for 15 years now. In this newsletter, I'll share some of the posts from the past that share a theme with my latest premium blog post [quality coach career paths](https://www.annemariecharrett.com/can-quality-coaching-be-a-career/), plus some other content on the same theme. ## Blog Posts on Career Paths [Quality Coach Career DevelopmentIn a modern engineering organisation what career development does a quality coach have? This was one question at the quality engineering lean coffee![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/02/qaleancoffee-scaled-2.jpg)](https://www.annemariecharrett.com/qa-career-development/) [Raising Female Technology LeadersWe need both a good funnel but also a way to retain female technology leaders who disproportionally leave the profession (and its not to have babies!)![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1536640712-4d4c36ff0e4e?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDUyfHxmZW1hbGUlMjBsZWFkZXJzfGVufDB8fHx8MTYyNDMzNjA3NQ&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/women-in-technology-facts/) [Where have all the good jobs gone?If you follow and believe the twitter conversations, it seems that the main reason for getting ISTQB certification is to pass the screening when applying for work. No ISTQB? No interview! My personal experience has been that yes, on one or two occasions I’ve failed to be interviewed based![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1487528278747-ba99ed528ebc?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDF8fGpvYnN8ZW58MHx8fHwxNjIzNzQ5NTY3&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/software-testing-jobs/) [Four Stages of Testing CompetenceWhat stage of software testing competence are you? Unconscious Incompetence, Conscious Incompetence, Conscious Competence, Unconscious Competence![](https://www.annemariecharrett.com/favicon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1613937167928-3923ee518faf?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDR8fGZvdXJ8ZW58MHx8fHwxNjIzOTgzNzg1&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/four-stages-of-testing-competence/) An article by [Melissa Eaden](https://twitter.com/melthetester?ref=annemariecharrett.com) I've enjoyed reading: [Navigating A Career Path In Software TestingRead “Navigating A Career Path In Software Testing” by Melissa Eaden in Ministry of Testing’s Testing Planet![](https://www.ministryoftesting.com/assets/favicon-4b6ba0a4118ce928dfcf3d3230cdbb09347a5a9b8d98f244c79d0d56384758bb.ico)MoT![](https://d2h1nbmw1jjnl.cloudfront.net/lessons/og_images/000/001/046/original/Navigating_a_Career_Path_in_Software_Testing_OpenGraph.png?1565298353)](https://www.ministryoftesting.com/dojo/lessons/navigating-a-career-path-in-software-testing?ref=annemariecharrett.com) And a plug for [Nicola Lindgren's](https://twitter.com/NicolaLindgren?ref=annemariecharrett.com) new book [Starting Your Software Testing CareerA guide to finding your first role as a Software Tester, suggestions on useful ways to upskill and advice on how to do a great job once you have landed a role.![](https://leanpub.com/favicons/mstile-310x310.png)LeanpubNicola Lindgren![](https://d2sofvawe08yqg.cloudfront.net/startinginsoftwaretesting/s_featured?1644871662)](https://leanpub.com/startinginsoftwaretesting?ref=annemariecharrett.com) That's it for this month. Enjoy your journey.... Anne-Marie ### Quality Coach Career Paths URL: https://www.annemariecharrett.com/can-quality-coaching-be-a-career/ Last updated: 2026-04-13T22:19:58.000Z Companies seeing the benefits of a [quality coach role](https://www.annemariecharrett.com/what-is-a-quality-coach/) also need to put in place structures & career paths to help individuals, teams and management in engineering understand how this new role fits within the existing engineering structure. One element of this is creating quality coaching career paths. Change at the best of times is hard. Clarity on quality coach career paths enables those impacted to make clear and informed decisions on the role. In addition, it provides engineering leadership structures to support career growth. Useful if you don't have a background in quality and your managing quality professionals. There's not a lot of data out there on career paths for quality coaches. Apart from this site, descriptions of [the quality coach roles and responsibilities](https://www.annemariecharrett.com/define-the-quality-coach-role/), even less what a career path looks like, are few and far between. In this article, I share my perspective on this element of quality coaching. ## Quality Coach Role Levels Let's assume that your company has a tiered progressive career path that begins at Tier 1 and goes up to say Tier 6\. This tiered model applies to everyone. For example, delivery leads, engineers, designers, SREs & leadership. In this model, the quality coach role begins at Tier 3, progressing to Tier 4, and peaking at Tier 5\. Here's an example: - Tier 1: Not Applicable - Tier 2: Not Applicable - Tier 3: Quality Coach - Tier 4: Staff Quality Coach - Tier 5: Principal Quality Coach - Tier 6: Not Applicable ## Why no Quality Coach Tier 1 or Tier 2? The Quality Coach role is not junior. You don't put someone straight out of school or university in charge of coaching people on how to write code. Similarly, you don't ask junior quality professionals to coach engineering professionals on software testing. Quality Coaches are experienced individuals who have invested significant time in their craft. They have a combination of domain knowledge, testing experience and technical capability. With experience and confidence under their belt, they're in a position to look at a quality coaching role. ## Why no Tier 6 Quality Coach? My experience is roles beyond Tier 5 goes beyond one speciality. Quality is no exception. You **could** argue for a Tier 6 VP of Quality, but I've yet to see this justification. Instead, you might see a quality coach moving to the VP of a Foundations Squad, providing enablement services encompassing security, reliability, availability, devrel and quality. A squad drives a suite of services, tools and processes to enable product teams to focus on what they want to do well, deliver quality product features. For this article, I've focused on the mid-tiers. ## Quality Coach Career Tiers In the table below, I outline three core Quality Coach levels, T3, T4 & T5, with titles Quality Coach, Staff Quality Coach and Principal Quality Coach. Of course, you can use different titles as you see fit. | Tier | Coaching Focus | Present or Future Work | Scope of influence | Coachingability | | ---- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------- | --------------------------------- | --------------------------------------------- | | T3 | Coach Engineers on Quality Tasks | Work performed is in flow of delivery | Camp | Minimal Coaching Skill | | T4 | Coach Camp Leadership on Quality | Work is in the flow of delivery, plus future-facing | Scope is Camp & Nearest Neighbors | Coaching Proficiency across many specialities | | T5 | Coach QC’s, Senior Engineering, Camp Leadership & Business Create Process, workshops, training content | Predominantly Future Facing | Engineering and beyond | Coaching Upwards | To identify and understand the differences between Tier 3, 4 and 5 Quality Coaches and offer accountability and ownership, I use four core factors. ## Quality Coach Factors When I work out Quality Coach tiers, I use the following factors to determine accountability and ownership. The following sections describe these areas in more detail. ## Sphere of influence When I coach quality professionals to become quality coaches, I describe their goal as **to become dispensable**. By this, I mean, they coach a team until the team maintains a level of quality with minimal intervention. When a quality coach can successfully achieve this goal, they are ready to increase their scope of influence by coaching across several teams or perhaps a squad. The challenges required to coach effectively at this level are different. Instead of day to day involvement, they must begin to work out how to drive quality at a strategic level. There's significant growth required to reach this level, requiring the quality coach to 'leave behind' being in the presence of work, focusing on more abstract concepts. As a quality coach gains experience, the scope of influence increases, from one squad to multiple squads, eventually across all engineering. To avoid 'doing all the things' and not achieving 'any of the things', a Principal Quality Coach prioritises one element of quality to drive and achieve that success. For example, a Principle Quality Coach may focus on creating and driving the test automation strategy across engineering. ## Coaching Focus Quality Coaches who are starting begin by coaching team members. These could be engineers, design, UX, SRE. Whatever makes up the cross-functional team. As their coaching muscle strengthens, who they coach also begins to change. They start to focus on coaching leadership roles. This makes sense. A quality coach is one person, and to effectively coach and influence; they need to coach those who can influence the team. This means quality coaches extend to coaching Delivery Leads and Team Leads. And, Quality Coaches need to [coach upwards](https://www.annemariecharrett.com/coaching-upwards/). They need to learn how to influence and put forward proposals to senior engineering required to influence strategy and budget. As the quality coach gains experience, who they impact matters. A quality coach should also learn to coach other quality coaches through 1:1 coaching and develop workshops to coach and train teams on specific skillsets. ## Flow of Delivery A quality coach begins by coaching teams on software testing activities performed within the 'flow of delivery'. They help engineers understand what makes a good test, develop good acceptance criteria, encourage collaboration across teams when required. They help coach test automation or help expand domain knowledge. The coaching focuses on helping teams develop *software testing muscle*. (I call this software testing muscle because, like any muscle, doing testing is what drives muscle growth.) As the quality coach gains experience, and as teams become less dependent on them, they can begin to think of how to influence the quality of *future work*. Quality Coaches start to explore how to improve quality across squads systematically. For example, systematically looking at ways to build quality in, not patched on at the end. They begin to provide input into leadership discussions on squad planning, what needs to be considered, and ensuring quality at the squad leadership level is everyone's responsibility. At Tier 5, this planning and strategising extends to the whole of engineering and beyond. The quality coach begins to look at support and sales and how quality impacts other dimensions of the organisation. This makes sense; we are delivering service, not products and how we maintain quality is equally as important as building quality products. ## Coaching Ability Coaching is a skilled activity. Exercising coaching skills improves capability. The more you coach, the better you become at coaching. As you diversify who and what you coach on, you become more capable and effective in your coaching. A significant element of coaching skills is encouraging self-discovery. Although it's easy to fall into telling teams what they should be testing, a quality coach helps teams discover their test coverage. The latter requires active listening and resisting to urge to offer solutions. It's also easy to fall into coaching everyone about everything. Given the nature of the role, this is an impossible task. Instead, you have to begin identifying what I call **coaching moments**. Opportunities that appear throughout the day that you recognise where coaching will be supremely beneficial. Situational leadership offers insights into when to coach, train or mentor, but practicing is what makes you confident in your coaching moment. You rarely create coaching moments. Instead, it's about being available, listening, identifying an opportunity and seizing it. ## Context matters! If you take these four elements, combine them with the [quality coach role description](https://www.annemariecharrett.com/what-is-a-quality-coach/) you can create a career path that suits your company. Quality Coaching is a great way to help quality professionals acquire more leadership skills. This is because quality coaching *is* leadership. It's about influencing groups of people, providing appropriate incentives to own quality collectively. And let's face it, if you can do that for quality, you can lead anything in tech. ## One more piece of advice I wrote this article with corporate career growth in mind. The purpose is to assist engineering management in developing quality coach career paths. I've found my career path to be anything but linear. As a humanoid first and quality coach second, my advice to anyone is this. Own your career growth. Understand and be loyal to your path and goals. Take the elements of this role and mould it into a career path that suits you. And be open to changing direction if needs be. And be open to trying new paths that are perhaps outside of who you perceived yourself to be. I've known quality coaches who have become engineering managers, product owners, SREs and directors of quality engineering. Enjoy the journey! ### Quality Coaching on AB Testing Podcast URL: https://www.annemariecharrett.com/quality-coach-ab-testing-podcast/ Last updated: 2023-09-11T10:27:50.000Z As someone who has [created a podcast](https://www.spreaker.com/show/quality-coaching?ref=annemariecharrett.com) in the past, I have the utmost admiration for someone who consistently delivers. The [AB Testing podcast](https://anchor.fm/abtesting/episodes/Episode-155-Quality-Coaching-with-Anne-Marie-Charrett-e1ends4?ref=annemariecharrett.com) is now on episode 155! True commitment. It was a great discussion on quality coaching, credibility and trust, how the ultimate shift left act is to hire engineers who embrace software testing as part of their role. It was such a fun chat, and I could have gone on talking and sparring for hours. Fortunately for you, I didn't. Here it is! I hope you enjoy it. And while you're here, why not sign up for my online quality coaching book with this [intro offer](https://www.annemariecharrett.com/intro4) of 4 weeks of free access? ### How to explain Quality Coach (to your CTO) URL: https://www.annemariecharrett.com/quality-coach-explainer-to-cto/ Last updated: 2023-09-11T10:28:02.000Z At some point, an engineering manager, principal engineer, delivery lead, or product manager is going to ask you "exactly what does a quality coach do?". Be ready for this question. Here's an explainer that frames the role **in their terms.** Why in their terms? When people hear something new, they relate it to their existing knowledge. In this case, probably either that of a QA or an agile coach. This is normal, it's our brain way of adding (or rejecting) new knowledge into our existing brain's mental model of what a quality professional does. I use this to my advantage. I've come up with a way of describing the quality coach role in terms of roles people are familiar with. I describe the quality coach role in terms of a delivery lead, a product manager, a quality professional and a software developer. The following is an overview of how those roles relate to quality. ### Software Tester Knowing how to test software is really useful if you're going to coach others on software testing, especially that concept of risk and how it applies to test coverage. Core knowledge includes: - Being able to identify and assess risk (both technical and business risks) - Skilled at test design - Skilled at software test patterns (heuristics and oracles) - Skilled at test strategy creation - Skilled at test reporting - Skilled at software testing ### Delivery Lead A quality coach requires good knowledge of the delivery process, the rituals being observed. Here are the types of 'delivery lead skills' I look in a quality coach: - The ability to develop ways of working and processes for a team - Collaborate & encourage teams to adopt new approaches - Data led decision making - Facilitate discussions and hold facilitated workshops to gain consensus - Hold retrospectives and encourage learning feedback cycles ### Software Developer Quality coaches assist software engineers to improve their software test automation skills. Here are some of the tasks they might perform: - A testing strategy for test automation - Advice on testability, observability & reliability - Building & maintaining CI/CD pipelines - Product & Test Code Reviews - Injecting quality into the branching strategy ### Product Manager [A Product Manager](https://www.aha.io/roadmapping/guide/product-management/what-is-the-role-of-a-product-manager?ref=annemariecharrett.com) manages the entire product lifecycle and product roadmap. A quality coach has extensive product knowledge and how people interact with that product. - Knowledge of features, systems and integrations - Domain knowledge and competitors - Knowledge of and what our customer looks like - Knowledge of sales and support and how they work to quality It's not just the product knowledge that is essential, as product managers, quality coaches need to be able to: - Have a vision for quality & develop strategies to enable that vision to be implemented - Facilitate workshops that allow for teams to contribute ideas on how to improve and measure quality - Identify quality-related work and develop roadmaps to drive change - prioritise quality-related against existing backlog work - report on progress ### Two Quality Coach Streams Looking at the tasks and skills above, it's clear that having one person able to fill all capabilities is rare. This is why I split to role into two quality coach streams. A technical quality coach tends to work predominantly with software engineers, focused on tooling and helping engineers improve their test automation. Product quality coaches have a focus on the whole product, the product lifecycle and its roadmap, identifying risk early on, and working with product managers to build quality into features. And even within these streams, you will discover people have capabilities in one area compared to another. That is to be expected. And, you might not need all these skills for your particular context. The sliders below show how you can blend the skillsets to suit the context you work in and the state of quality you have at this point in time. ![Quality Coach Slider from Charrett ](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/02/QUALITY-COACH-ROLE.png) Quality Coach Sliders Personally, I like to lean into diversity, having quality coaches with different strengths. That way all aspects of quality can be considered and fit your companies ideology on quality. For me, quality is building the right product, building the product right and the right service to continue an ongoing relationship with your customer. You and your company may have a different view and definition of quality and so a quality coach may look different for you. ### ### ### Moving to a Quality Coach Role URL: https://www.annemariecharrett.com/moving-to-a-quality-coach-role/ Last updated: 2022-07-31T00:56:10.000Z I posted the following on Twitter... > "I'm moving to a quality coach role, how do I ready my team for the transition" is a question I often hear. Anyone got any answers? > > — Anne-Marie Charrett | Number all boxes (@charrett) [January 28, 2022](https://twitter.com/charrett/status/1486963678331035649?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) The perspective in mind was a software tester transitioning to the role of quality coach. The responses though offered many different perspectives (the power of diversity)! By correlating these perspectives to stakeholders impacted by the transition, I was able to identify user stories. I enjoy writing user stories with quality in mind. I find it clarifies the why a lot more, something we often forget to do when we think about quality. ### Quality Professional > " As a software tester I want to ready the team so that I can perform the role of quality coach instead of doing the testing". Some great suggestions were put forward in this space and I'll summarise: - Perform a self-reflection (how ready am I for this transition, what do I know, what do I need to know) [@StuC](https://twitter.com/StooCrock?ref=annemariecharrett.com) - Encourage the team members to try the role of a software tester.[@Lanooba](https://twitter.com/Lanooba?ref=annemariecharrett.com) - Speak to the team on the transition and repeat the reflection at a team level (Follow up a week later to allow people additional time and space to reflect as this may be new territory for them and they won't have immediate answers). [@Magnus](https://twitter.com/Mange046?ref=annemariecharrett.com) - Imagine you were going on holiday for six weeks, what information would the team need to do your job? > Assumpt. is they’ve readied themselves 1st. I’d ask how well they know their own craft to take others on a journey. Once they know what they know and decided what’s important, they can start looking for little seeds to sow in conversation and share a map of things to come. > > — Stu C (@StooCrock) [January 28, 2022](https://twitter.com/StooCrock/status/1486967549338259458?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > I’ve found it helpful for the QC to encourage Devs to try their roles for some time; builds empathy. [https://t.co/VMenSqfPOd](https://t.co/VMenSqfPOd?ref=annemariecharrett.com) > > — Nivia \*always\* uplifts Black & LGBTQIA+ Women (@Lanooba) [January 28, 2022](https://twitter.com/Lanooba/status/1487061201448312840?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > Also, since it's not easy for everyone to think about, and process things like this on the spot, I would have a similar meeting about a week later where the team can bring up expectations and questions that has come up. > > — Magnus (@Mange046) [January 28, 2022](https://twitter.com/Mange046/status/1486965591789481984?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) ### Delivery Lead > "As a delivery lead, I want to know when and when the team and the quality coach will interact, so that the team will know when and where to perform software testing" When there's loads of uncertainty and no one quite knows where to start, focusing on the delivery process allows the team to have practical conversations about when and where software testing should be performed, and when and where a quality coach might check in with the team. This won't uncover all that 'glue' work performed outside of the delivery process that a software tester typically does, and it doesn't help with improving software testing skills. It's the 'Shu' in the [Shu Ha Ri of learning](https://www.annemariecharrett.com/habits-and-shu-ha-ri/), and so makes it an excellent starting point. > Yes, the formal structure and functional agreement on how to operate helps provide guardrails. Thank you! > > — Anne-Marie Charrett | Number all boxes (@charrett) [January 28, 2022](https://twitter.com/charrett/status/1487184114117939200?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) ### Team members > "As a team member, I want to know what how to do software testing well so that I can confidently make decisions about what to test" The more you create and do software testing, the more confident you become in your choices. Software Testers don't have a special magical skill that helps them find bugs, it's years of practice of experimentation. We have a hypothesis, we try out it, and if we're right, we find a bug, or we create a good test. We already know that pairing is a powerful tool when transferring skills and so the suggestion by [Joep Schuurkes](https://twitter.com/j19sch?ref=annemariecharrett.com) got a big + from people. > Transition from doing things yourself to pairing as navigator to pairing as driver. And/or ensemble sessions. So slowly ease off being a team member and move into the quality coach role. > > — Joep Schuurkes (@j19sch) [January 28, 2022](https://twitter.com/j19sch/status/1486966241432686599?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) ### Engineering Manager > "As an Engineering manager I want to understand the nature of the role so that I can assess if they're performing the role well, and can reward appropriately" This is critical for senior management who need to be confident that the role is more than waving your hands around encouraging people to "do more testing". Mark Tomlinson explains it well: > Yeah, I 💯agree Mark. It’s a great point. > > — Anne-Marie Charrett | Number all boxes (@charrett) [January 28, 2022](https://twitter.com/charrett/status/1487183705785651200?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) Creating career pathways, [creating role descriptions](https://www.annemariecharrett.com/define-the-quality-coach-role/) is important to ensure buy-in and that people are properly compensated for a role that requires leadership skills and nuance in its application. ### Who drives the change? A final stakeholder is required. Someone with the capability to speak to what success looks like has the comm skills to speak to people at all different levels of the organisation, has the power to influence and change. I call this person the Head of Engineering, but it also could be an external consultant. Nicola Lindgren touched on this. > I’m assuming the person is currently a tester in the team. > > Would tell them: > Why it’s happening > What will change > How long the transition period is > > Would ask them if they have any concerns > > Would check in after a while to see how it’s going > > — Nicola Lindgren (@NicolaLindgren) [January 28, 2022](https://twitter.com/NicolaLindgren/status/1486966904099123208?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) They have a user story too. ### Head of Quality Engineering (HoQE) > "As a Head of QE, I want to provide support (either directly or indirectly) so that the software tester has the tools and capability to be successful in their transition" 💡 The HoQE performs the role of change agent. It's their job to create a space and framework so that the software tester will achieve a successful transition. A successful transition requires the HoQE considers: - A vision of the future, what does an engineering division with quality coaching look like? - Communications to different groups on the why its impact and the benefits this change will bring. - A roadmap on the steps involved, how long the transition might take for the software tester and the team(s). - Coaching/Support for the software tester as they work through the transition The HoQE creates scaffolding (can be taken down when the structure is complete) for the software tester to apply as they see fit. Scaffolding can include: - a high-level delivery process that identifies touchpoints and rituals related to quality that the software tester can experiment with their team - Strategies for skills-based transferral. Examples could be formal training or guides on how to execute a pairing session. - Reporting methods, quality health monitors etc These guidelines are intended to give the software tester some way of focusing and structuring their work. They are not mandated must do's. Rather the HoQE is providing a set of tools within a toolbox for the software tester to draw upon. How much this is used typically depends on the experience and confidence of the software tester in taking this new role. Like this post? [Subscribe](#/portal/signup) to my quality coaching book [4 weeks free access to quality coaching book](https://www.annemariecharrett.com/intro4) ### What is a Quality Coach? URL: https://www.annemariecharrett.com/what-is-a-quality-coach/ Last updated: 2026-04-20T07:21:44.000Z *Defining the term quality coach and explaining this role in software engineering in contemporary organisations* There have been many articles on the nature of the role. Alister Scott wrote about [quality advocates I think way back in 2013](https://alisterbscott.com/kb/quality-advocate/?ref=annemariecharrett.com). My favourite article to date is from Divya Konnur gave an excellent overview in her article ["As a quality advocate" ](https://medium.com/divya-konnur/as-a-quality-advocate-d43ca12ff1b6?ref=annemariecharrett.com) This post focuses on the definition and the nature of the role. ## Definition of Quality Coach > *A quality coach guides, supports and rallys a team to collectively own and improve quality through facilitation, education, experimentation and visualisation. They are a passionate advocate for quality.* I wrote this definition back in 2017, and I like how it evokes a sense of team ownership, explains key techniques to handle uncertainty and change within a system plus the emphasis on providing information through the concept of visualisation. Buy the quality coach's handbook [![CTA Image](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2026/04/qualitycoachbook.svg.png)](https://leanpub.com/qc/c/40?ref=annemariecharrett.com) Buy the Quality Coach book on [Leanpub](https://leanpub.com/qc?ref=annemariecharrett.com) (ebook) or [Amazon](https://a.co/d/0jFdKyz?ref=annemariecharrett.com) (for hardback or paperback) [40% Discount on Ebook - all languages ](https://leanpub.com/qc/c/40?ref=annemariecharrett.com) ## What a Quality Coach does In my previous book post, I wrote about how you could go about defining the role of a quality coach. This post is the explainer to that model. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/01/Quality-Coaching-Model-2022.png) Anne-Marie Charrett Quality Coach Model 2022 ### Download the Quality Coach Descriptor You can download a full version of the pdf below with complementary examples [Quality Coach Role Model v3.0Quality Coach Role Model.pdf216 KBdownload-circle](https://www.annemariecharrett.com/content/files/2025/05/Quality-Coach-Role-Model.pdf "Download") ### Skills & Traits There are many more skills and traits required for a quality coach. Here are some key ones. | Skills & Traits | Examples | | ------------------- | -------------------------------------------------------------------------------------------------------------------- | | Risk Identification | Being able to identify key risks (technical & business) within a product and feature | | Critical Thinking | What do we mean by X? How do we know it's X? Does it matter? | | Systems Thinking | do I patch over a bug or discover its root cause? do I increase test coverage or invest in improving code quality? | | Listening | Am I performing active listening? Am I providing space for people to be heard? | | Empathy | How would I feel in this situation? What would help me? Allowing voices to be heard, Being the voice of the customer | | Collaborative | Who needs to be in the room? Who needs to be involved in decision making? | | Resilience | Developing tools and strategies to manage conflict and uncertainty | | | Learning to say No | There's more to the quality coach model than tasks and traits though. To be a quality coach requires a different viewpoint. For one, there's[ a mindset of collective ownership ](https://www.annemariecharrett.com/bobbing-for-embedded-apples/)of quality over being the expert in quality. The infographic below displays examples of how the role differs compared to a test lead. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2022/01/QualityLeadVsCoach-4.png) ### Using the Quality Coach Model The idea of creating this model is to generate discussion. It's not intended to be followed blindly. Instead, take the model and use it with a pinch of salt. Don't try and do all these tasks, or expect a quality coach to be able to somehow instantly be able to perform all these tasks. Instead, take the model and interrogate it. Does this model suit our needs? What do we like and can appropriate? What should we drop? What is missing that we need to add? Enjoy and tell us how you go! - Anne-Marie ### Create a Quality Coach Job Description URL: https://www.annemariecharrett.com/define-the-quality-coach-role/ Last updated: 2023-09-11T10:28:31.000Z *For clarity, I'm going to use the term quality coach (QC), though in your world you may prefer Quality Advocate (QA), personally, I find that gets confused with Quality Assurance and often people default to that term.* Imagine you or your company has decided to transition to a [Quality Assistance model](https://www.atlassian.com/inside-atlassian/qa?ref=annemariecharrett.com), the one that has software developers owning their software testing. What does this new world look like? And what does this QC do? How will you know if a QC is doing a good or great job? These are not easy questions to answer making it hard to create job descriptions. This is partly due to the newness of the role, but also QC tasks are difficult to quantify. They don't necessarily have concrete outputs in the form of artefacts. A Quality Coach focuses more on delivering outcomes, one being that a team is able to deliver quality features with **minimal** assistance. A heuristic for a successful quality coach? They're not needed by the team anymore. Regardless, creating a job description is a useful exercise. It helps drive clarity in your thinking about the role and is a useful method to communicate how this role differs from a traditional software tester role. The following is a process I used to help clarify the quality coach role. A good QC Job Description builds on your company's values, your vision for quality plus input from existing team members. ## Know your company values Engineer your job description to give the QC and those around you the most likely chance of doing well. Before researching outside of your company, research within. What company values will influence the nature of this role? Think on how a QC will you demonstrate these values. Also, consider who needs to play a part in the JD process. I sought out HR and Engineering when creating the Job Description. ## Existing Job Descriptions > **If you copy from one book, that’s plagiarism; if you copy from many books, that’s research.** – Prof. Notestein of the Yale faculty Google to your heart's content. Find as many job descriptions as you can, job sites are good sources for this. Be discerning. Look for a variety of contrasting flavours of the role. Highlight what you like, and challenge yourself to be able to explain why you think that particular aspect is important, or why it's suitable for your company. ## Testing Tasks Workshop Run two workshops, one for software testers and the second for team representatives. Keeping the sessions separate, offers safety and permission to voice opinions without self-censorship. Focus the workshop on identifying both **current** and **future** tasks. Break tasks into those [within a flow of work, and those outside flow of work](https://www.annemariecharrett.com/team-topology-quality-engineering/). ### Testing Task Workshop Participants: QA/Software Tester/Quality Engineers **Preparation Work:** Setup a board marked inflow of work and outside flow of work. (agree on what these terms mean). I use the flow of work to describe work performed from epic refinement to working in production. These terms are useful as a lot of tester work is outside the flow of work (and invisible to team members). **Workshop** **Step 1**: Ask the group to identify all the tasks they do **now** inside and outside the flow of work **Step 2:** Offer an opportunity to discuss observations as a result of these two steps **Step 3:** Rate these tasks according to 4 categories: Highly valued, valued, Minimum, and Avoid. **Step 4:** Use [Keep, Stop, Start](https://agile-retrospective-ideas.com/the-start-stop-continue-retro-why-it-sucks-and-what-you-should-do-instead/?ref=annemariecharrett.com) tags to identify what tasks to keep, what tasks to stop plus what additional tasks a QC should start doing. Hopefully, this will generate a lot of discussions. For example, we identified testers doing **highly valued work** that the team felt they should **stop doing.** We also noticed that even though the workshops were separate, both the software tester's and the team representatives had similar ideas about what they considered valuable work. This should give sufficient clarity around the accountability part of the quality coach job description. ## Quality Coach Description The model below provides how I see the core dimensions of the role which can be useful when brainstorming and putting the JD together. ![quality coach role charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/11/QualityCoach.png) Quality Coach Role Description by Anne-Marie Charrett **Lite Version of Quality Coach Workshop** If I was to do this workshop again, I think I'd perform it this way: Have everyone in one workshop. Identify all current quality-related activities (regardless of role). Use Keep, Stop, Start to identify new tasks you should be doing (Keep/Stop/Start implicitly places value on tasks). Finally identify in the new quality assistance model, who will do what task. Let us know how you go! ### Team Topology & Quality Engineering URL: https://www.annemariecharrett.com/team-topology-quality-engineering/ Last updated: 2026-04-25T23:09:48.000Z As director of quality engineering, part of my role is structuring how and where quality sits within a company that's scaling in customer numbers, in terms of architecture and software engineers.[ Team Topologies](https://teamtopologies.com/?ref=annemariecharrett.com) written by Matthew Skelton & Manual Pais suggests reversing Conway’s law and providing structures that facilitate collaboration (with the proviso that not all collaboration is good). In this post I'm exploring how this might apply to a quality engineering practice. ### **Team Topology & Quality Engineering** Almost instantly it feels like the QE practice is an enabling team. One that supports Stream Aligned (SA) teams achieve their goals. Makes sense, especially in terms of test automation and a quality assistance model. But as I dug deeper in the concepts, I realised it was a bit more complicated than that. Yes, test automation fits into that paradigm, but what about exploratory testing? Where should that sit, and how should it be supported? To be able to answer these, I had to look at what is meant by quality, flow of work and cognitive load theory (in particular germane load). ### **Quality is Throughput** Quality relies equally on how stable our value is, & how fast we get that value into the hands of our customers. > **Quality is how fast we deliver value (throughput), how stable that value is (stability) is & our ability to deliver on our promise of quality. – Anne-Marie Charrett** Our ability to deliver value rapidly relies on small batches, staying in the flow of work, minimising rework, & automating what makes sense. These approaches have the added benefit of lowering the risk of any change, also stabilising value. This means we can't exclude how Quality Engineering activities impact our ability to deliver at speed. It's not just about how well we test, it’s also about how well we deliver. Quality is an ecosystem and everything must be considered if we really want to make an impact. ### **Software Testing is Germane Load** Matthew Skeleton's position is that any software testing that benefits from significant domain knowledge should stay in a Stream Aligned Team. > Hi Anne-Marie. Nice question :) Testing is (or should be) an integral part of understanding the domain. So testing is part of the \*design\* of software: testing assumptions, mental models, etc. > > So testing should be Germane cognitive load. > > 1/ > > — Matthew Skelton #BLM 💙🌻 (@matthewpskelton) [October 8, 2021](https://twitter.com/matthewpskelton/status/1446385358107783205?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) Software Testing is predominantly germane load. That is, it's the type of cognitive work required to develop mental models of our systems. This sits well with my understanding of software testing, and so I agree that we can predominantly place software testing into Stream Aligned Teams. **Reducing Cognitive Load** But here is where things start to get tricky. To maintain a flow of work, we need to reduce any cognitive load that distracts from this work. While we can argue that creating & running software testing is part of that flow, there's no avoiding the fact that software testing brings extraneous load with it. Think test environments, test data and test frameworks. When all you want to do is run a test, you end up in hours of yak shaving. To avoid this, we can create a QE Enabling team that focuses on these activities. Many companies are doing this already, so little controversy here. ### **Exploratory Testing is about being distracted** This all works very nicely when we think about automating our tests, but what about Exploratory Testing? Exploratory Testing moves outside the flow of work. It requires focus on that which is distracting. Performing Exploratory Testing is to indulge curiosity, to jump outside stories, to pull on threads of information that flow right across and down into our systems, regardless of bounded context or team scope. It doesn't march to the drumbeat of delivery, instead preferring the unspoken, the unsaid, and the unseen. The impact of exploratory testing on the flow of work is disruptive. It often uncovers rework or unplanned work, and requires context switching. These are exactly the types of activities that slow us down and upset the flow of work. But if we don't perform Exploratory Testing early on, we run the risk of further disruption down the road, longer feedback loops, greater context switching, more handoffs. Here are three approaches to consider. I've created diagrams of each in a link at the bottom of the post ### **Exploratory Testing into the engineer's flow of work** One approach that's very popular is to place all software testing in an engineer's flow of work. This means an engineer is responsible for both the development and testing of a feature, including both test automation and exploratory testing. To succeed with this approach, software engineers are trained to perform exploratory testing. Touch points within the flow of work act as guardrails maintaining the quality of the testing effort. And to minimise bias, software engineers can test each other's code. The benefit of this approach is that it empowers the software engineer to design for and include testability in their solutions. Also, as they begin to build a mental model of typical bugs, they can begin preventing these bugs from appearing in the first place. There's no safety net, no tester waiting to catch bugs in case they're missed, encouraging engineers to think twice before building and shipping code. It takes time for this knowledge to be acquired but it can be worth it. Biggest plus is less handoffs, less rework. ### **Exploratory Testing in a team’s flow of value** By including an exploratory tester in a team and focusing on the flow of value, you acknowledge that a certain number of handoffs will exist, but that the value gained justifies this approach. Plus you get an added bonus.Teams begin to collectively absorb knowledge about risk to the point where they build software with those risks in mind. In this way, the role of the exploratory tester almost becomes redundant. Handoffs, rework and context switching becomes minimal. It does take time for a team to reach this point, though. I've seen this work amazingly well, but I've also seen it create tension and unhappiness in teams. It takes a concerted effort by the whole team to be open to new ways of working, trying and retiring if things don't work, plus a healthy respect for all disciplines. ### **Exploratory out of the flow of work** There is a third concept which I've coined the Eclair Model. ![Eclair Model of Quality Anne-Marie Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/10/eclair-model-of-testing-1.jpeg) Eclair Model by Anne-Marie Charrett Copyright ©2021 Instead of injecting Exploratory Testing into the flow of work, the focus is on performing exploratory work pre- and post-delivery. Exploratory Testing in production consists of monitoring and analyzing data as your customers use the system. Observability is critical here, with latency a key measure for performing root cause analysis. The motivation is to better understand the system and, in doing so, better understand risks. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/10/Screen-Shot-2021-10-16-at-7.04.55-pm-1.png) The Eclair Model in Team Topologies Format It is critical to bring this information back into ideation and discovery, helping product owners and product analysts understand the system as it behaves, using their mental models of risk to identify potential concerns. Pre and post delivery there is room for coaching on system risks. To summarise, the approach could be: **Build the Right Product** \>> Feeding Risk & Data back to the product team **Build the Product Right** \->> software engineers with an enabling team **Support the Product Right** \>> Exploratory Testers >> Monitoring & Analysing in Production ### **What's right for us?** There are a lot of variables that will influence your final choice and approach, including existing cognitive overload in your teams, the level of willingness to learn new skills, and the capabilities of those doing exploratory testing. Speak to the SA teams and ask them what concerns them most, silos or cognitive overload? What is the appetite for observability in production? How open are your product teams to include someone with a testing background? All these will influence what approach works best for you. Here are some other team topology QE structures to consider [Team Topology diagrams of QE structures ](https://docs.google.com/presentation/d/1MaePRDmvzVjRAH-PzTh8m5eyYPzkG6Pu%5FKWbfhIBAqw/edit?usp=sharing&ref=annemariecharrett.com) Many thanks to Fiona Charles for reviewing this post. And thanks to everyone who has signed up to this book! ### **Background Reading** Key concepts are described on the[ Team Topology website](https://teamtopologies.com/key-concepts?ref=annemariecharrett.com). I found this[ book summary from Dan Lebrero](https://danlebrero.com/2021/01/20/team-topologies-summary/?ref=annemariecharrett.com) useful [Jesper Ottosen has already written on how "***testing people"***](https://jlottosen.wordpress.com/2020/06/10/where-does-testers-fit-in/?ref=annemariecharrett.com) might fit into the Team Topology structure. which is also a good read and offers some good insights. [Cognitive Load Theory (CLT)](https://itrevolution.com/cognitive-load/?ref=annemariecharrett.com) and the concepts of intrinsic, extraneous and germane load. ### About that quality coaching book... URL: https://www.annemariecharrett.com/about-that-quality-coaching-book/ Last updated: 2024-03-10T01:34:11.000Z "So Anne-Marie, when is that book on quality coaching coming out?" is the question I dread. The time has come to do something about it. TL;DR online subscription of my book through a [free trial of premium content](https://www.annemariecharrett.com/premium), or go the full tilt for a huge [$9 USD a year! ](https://annemariecharrett.com/portal/signup?ref=annemariecharrett.com) *\[this is now $20 USD/year\]* ## That Book For many years I've talked about writing a book on quality coaching/quality engineering. True fact, I've written 1/3 of this book 3 times, and I still have yet to publish! What that tells me is I'm using the wrong model to write the book. A book feels like a monumental task. It's months of effort with little feedback. It encourages perfection when "good enough" would be better. I've even held off writing some of my content in my blog, wanting to save it for "the book". I realise now that writing "a book" is not going to work for me. Instead I need to publish as I create. Be content with good enough. ## A new approach To break this inertia, I'm introducing a new approach where content will be posted on my blog. It's a 3 tier model where book related content will be available under a paid model. Here's how it works. **Public:** all existing content (June 2021) remains free and accessible to anyone who visits my blog. You will also get to read any new blog posts on content other than book stuff. No signup is required. **Members:** Members is a free subscription model. Members will be informed of posts created through a quarterly newsletter. *\[it's now monthly\]* **Premium Members**: For $1/month *\[now $2/month\]*, premium members will have access to full old and new content. You will receive content through a monthly email providing you with the full content. Not sure which one suits you? Try an [introductory offer to premium content ](https://checkout.stripe.com/c/pay/cs%5Flive%5Fa1gp4fx6LkYTRV3TnENUOwzlEMVTxniCwHEFDp3hHD38K1zVz8kuT3Lm8M?ref=annemariecharrett.com#fid2cGd2ZndsdXFsamtQa2x0cGBrYHZ2QGtkZ2lgYSc%2FY2RpdmApJ3Zxd2x1YERmZmpwa3EnPydkZmZxWjRESkFiaU5vc3JHaWxyV1UnKSdkdWxOYHwnPyd1blppbHNgWl12Z083QUY8Ujd3YzxmRm8yQElnYGlzdCcpJ2N3amhWYHdzYHcnP3F3cGApJ2lkfGpwcVF8dWAnPyd2bGtiaWBabHFgaCcpJ2BrZGdpYFVpZGZgbWppYWB3dic%2FcXdwYHgl) ### Why a paid Model? I'm introducing a paid membership plan because I value this work. It's knowledge and skill that has come from years of working in the industry. I'm proud of my work, and I feel it contributes to the industry. In the past, I've relied on my enjoyment in writing a post, post analytics and sharing on social media to get validation of the value. This time, I want to use paid membership. I get not everyone agrees with this approach and won't sign up. I'm ok with that and I respect that decision. And whatever, it's an experiment, so let's enjoy the experience! ## My commitment to paid members For premium members, my commitment is 12 posts in a year. I plan to post on average once a month, however writing is tough, and sometimes it's incredibly easy. Some months, I may miss a post. Some months, you may get two or three posts. I'll try to be as consistent as possible. There are no refunds for unhappy customers, but if you are dissatisfied with the content, reach out and let me know what you'd like to see. For the truly dissatisfied, all you need to do is cancel your membership at any time. ### More than a maverick tester URL: https://www.annemariecharrett.com/no-longer-a-maverick-tester/ Last updated: 2021-06-21T21:55:10.000Z Some of you may know I've changed the title of my blog from Maverick Tester to AnneMarieCharrett.com. But why the change? These days I write about a lot of things, and some of them are outside of software testing.. I write about quality engineering, leadership and sometimes about women in technology. I still love writing about software testing, but it's only what I am about. In the process of shifting, I'm also going through the mammoth task of updating my 260+ posts, retagging and fixing some of the atrocisous spelling (that ones for you Fiona Charles!). As I'm doing this, I'm reading content that is over 15 years old. Some of it I view fondly, some of it I wince at. I plan to tweet out the ones I like, so if you want some posts from the vault, follow me on twitter. I've also taken out the comments. This was a tough choice. Some blog posts I have a lot of old comments and I value the feedback readers have given to me over the years. But the new platform doesn't support comments and it's kind of refreshing not to expect comments, simply just write and publish. Anyhow I hope you enjoy the new site and subscribe to it. Personally I I love the new format, and have enjoyed the opportunity to travel down a writing memory lane. Below is the first blog post ever - way back in 2006 [Developing a Software Testing ProcessDeveloping a software testing process requires getting buy in and support![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://images.unsplash.com/photo-1563262924-641a8b3d397f?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDR8fGNhbmR5JTIwc3RvcmV8ZW58MHx8fHwxNjI0MzEwOTIz&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/kid-in-a-sweet-shop/) ### Habits and Shu Ha Ri URL: https://www.annemariecharrett.com/habits-and-shu-ha-ri/ Last updated: 2023-09-11T10:29:17.000Z Whatever happened to Shu Ha Ri? It was the bees-knees of learning processes about 4 years ago. Now crickets...or perhaps I'm not moving in the right circles. Anywhooo, had a lunch chat with the lovely Paul Hughes from CultureAmp. (If you're wondering, he ate healthy carrots and tuna, I scoffed down a cheeky carbonara left over). We were talking about the concept of embedding a scaffolding for quality that teams can pull down on as needed. I mentioned the concept of [atomic habits wrt to quality ](https://www.annemariecharrett.com/habits-in-quality/) with the aim of improving quality without the expectation of having highly motivated teams. Cos lets face it, even the best of us are not motivated all the time. Me? I love running, but I hate getting out for those first 100 metres, and when it's cold its super hard to get out there. I've learned to create strategies and structures even when I feel unmotivated. So let's make it easy to adopt habits that help improve quality without having to think twice about it. But as Paul pointed out, the problem with doing stuff without thinking twice is sometimes, you should think twice. For example, when it comes to risk which is pretty context dependent. So how do you encourage people to think about risk slowly but think fast about other things? Perhaps I mused, its ok to not be perfect on the whole risk thing to start with. After all, risk is something you come to respect through experience. Some-one can tell you all about potential risks of not sticking your finger in the electricity socket, but really you only come to appreciate the value of that advice on application. That's where Shu Ha Ri comes into the picture. It's ok to not get it all right the first time. Keep working on it, and in time you will begin to develop a rich mental model of risk. Then you can continue to engineer product – without thinking twice about it. ### Habits in Quality URL: https://www.annemariecharrett.com/habits-in-quality/ Last updated: 2023-09-11T10:29:36.000Z I often get asked as a quality coach, how do you get teams to do more software testing? It's a tricky one, because as quality coach you don't have any direct authority over anyone in the team. You could try and tell them to do it, but in my experience even if they agree in principle, the pressure of daily work means its hard to gain traction and gradually the motivation disappears. Getting them the space in terms of time and permission is crucial. It's unfair to expect team members to take on additional workload without having the necessary time to perform those tasks. But I've found that that is only part of the story. I've seen situations where people do have the time, but prefer to pick up new stories rather than help the team perform testing tasks. Part of the answer, is to tap into what motivates people. The idea, by identifying motivation and aligning quality to that, it makes it easier for the person to adopt change. People though, don't have their motivations branded on their forehead, sometimes they're not aware of what they want themselves! It feels like perhaps a degree in psychology is required to work this out. And, as quality coaches are we really qualified to perform this role? What if there was a way to help people adopt an activity that places less emphasis on motivation? Can we as quality coaches, help people develop habits to work to improve quality? Is there a way to helps teams gradually embed activities such as software testing into their daily work without requiring large amounts of motivation? I'm in the process of reading [Atomic Habit by James Clear](https://jamesclear.com/atomic-habits?ref=annemariecharrett.com) who has the concept of: > Make it easy enough that you can get it done without motivation. > \-- James Clear In this book [Clear describes](https://jamesclear.com/three-steps-habit-change?ref=annemariecharrett.com) how to create good habits by making them "obvious, attractive, easy to adopt and satisfying." Might this work for us a quality coaches? I've used an example of how below using Test Driven Development as a way of improving change. 1. How can I make it obvious? --> use TDD where you create a test first 2. How can I make it attractive? --> Getting a test to pass 3. How can I make it easy? --> create examples of tests, arrange Katas 4. How can I make it satisfying? --> display progress in terms of coverage The goal here is to help embed small habits to generate long term change, so perhaps it's not TDD all the time, but on one story per iteration. Or one test per story. What ever approach that makes it easy for the team to adopt. And again, this is a conversation that you would have with the team, helping them develop an approach. What do you think? Would creating atomic habits helps you as a quality coach? ### It's all one elephant URL: https://www.annemariecharrett.com/its-all-one-elephant/ Last updated: 2024-02-27T20:43:27.000Z Recently, I posted on twitter a representation of how I see the differences between coaching, mentoring and training. The lens I chose to look through was that of direction. How much the person coaching, is actively providing guidance. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2024/02/direction_original.png) > Its just a question of quality - quality strategy [https://t.co/Ph9YJCal6p](https://t.co/Ph9YJCal6p?ref=annemariecharrett.com) cc [@3weststreet](https://twitter.com/3weststreet?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > > — Quality Coach Roadshow Podcast (@qualityengineer) [June 1, 2021](https://twitter.com/qualityengineer/status/1399629628113788929?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) I got some great feedback and input from a lot of people. And, I found this really encouraging, because that means at least the model is semi understandable. In particular, [Lena Wiberg](https://twitter.com/LenaPejgan?ref=annemariecharrett.com)(who even helped me by redrawing my model, see below), [Maaret Pyhäjärvi](https://maaretp.com/?ref=annemariecharrett.com), [Janet Gregory](https://agiletestingfellow.com/blog/post/testers-as-consultants?ref=annemariecharrett.com), [Patrick Prill](https://twitter.com/TestPappy?ref=annemariecharrett.com), [João Proença](https://twitter.com/jrosaproenca?ref=annemariecharrett.com) and [Vernon Richards](https://twitter.com/TesterFromLeic?ref=annemariecharrett.com) all who gave me direct input. I also got some other cool ideas from [Maria Kedemo,](https://mkedemo.wordpress.com/?ref=annemariecharrett.com) J[ames Thomas](https://qahiccupps.blogspot.com/2021/05/the-mentor-in-quality-coach.html?ref=annemariecharrett.com) and [Augusto Evangelisti](https://mysoftwarequality.wordpress.com/author/mysoftwarequality/?ref=annemariecharrett.com) Thank you all. ![](https://charrett.ghost.io/content/images/wordpress/2021/05/Coaching-Direction-1024x452.png) Feedback on Coaching Direction Model (charrett 2021) I put all the feedback into a mindmap so I wouldn’t lose the ideas presented to me. What fascinated me was that they were all good and reasonable points from people I knew well and respected. But also, there were differences in opinion as to what mattered. (In particular about the nature of mentoring versus coaching). My brain went into to overdrive, trying to absorb and reconcile this new information into my existing model. Until bingo! I realised what was wrong about the whole picture. It wasn’t that the model was right or wrong. It wasn’t that the feedback was incorrect. The flaw was in my assumption that only one model could exist. This was crazy thinking! I wasn’t building a test case where the assert was a binary pass/fail. This was way more nuanced. Of course, many perspectives could and can exist, and consequently many models can exist. It re-inforces to me the value in collaboration and getting feedback. Being open to new ideas and perspectives. Even if on first look, these ideas may seem the opposite and the anthesis of what you think. But don’t be afraid, instead pull them apart gently and kindly and you will discover similarities between approaches, models even schools of thought. It’s from these similarities that you can begin to build a new and create a better version. That’s not to say identifying differences is bad. Focusing on what differentiates has value of course. But my experience is, focusing on what unites is way more powerful because it allows us to work through those differences. I’ll continue on working on this model. I think more work can be done to make it better. Next week Vernon Richards and I are having a 9 minute [racket on the topic](https://racket.com/qualitycoach/?ref=annemariecharrett.com). Cheers and happy learning! P.S I just added this new comments plugin. I’d love to hear what you think. Give us a rating or add your thoughts to the conversation! 😍 ### 3 Amigos - a sequel URL: https://www.annemariecharrett.com/new-3-amigos/ Last updated: 2023-09-11T10:31:08.000Z In agile, the 3 Amigos is a collaboration event that takes place[ between QA, Product and Engineering ](https://www.annemariecharrett.com/3-amigos-in-agile/)right before the start of software development. The purpose is develop a shared understanding over what is being built, and what will be tested In this new version, the 3 Amigos still keeps three core roles. But these are now Product Owner, Software Engineer and Support. Why the change you ask? ### Modern Engineering Practises Many companies I work with no longer have the role of QA as in the traditional sense. In these companies, software engineers perform the activity of software testing, often both automated and exploratory. Having a QA in a meeting where no QA exists doesn’t make sense. But that’s not the only reason for the shift. It’s time to acknowledge and formalise the need for operations in these discussions. ### Whole Team Quality Those walking the talk on whole team quality, realise we cannot ignore the impact of ops and customer support to this discussion. Elisabeth Hendrickson’s [blog post on recovery over perfection](http://testobsessed.com/2015/05/i-prefer-this-over-that/?ref=annemariecharrett.com) is now 6 years old…In this post post, Elisabeth talks to how contemporary products demand we focus not only on great software but also the ability to recover from the inevitable failure that will occur. This ideology has a significant impact on how we think about quality and software testing. Instead of thinking only of testing, we in the quality space must be thinking about recovery. We need to be actively having conversations on how we can include operations into all discussion on bug prevention, detection and recovery. We need to be actively having conversations on how we can include operations into all discussion on bug prevention, detection and recovery. This is not necessarily an easy transition (what significant shifts are?). For ‘whole team quality’ to work well, requires a conscious effort to collaborate with individuals and roles outside of our comfort zones. I’m aware this is not an easy task, especially when people are under time pressure. Going the extra mile and having a conversation with someone outside of your remit is bloody hard when you working at full tilt to get product out the door. Yet, it’s vital if we are serious about improving quality. Reframing the 3 Amigos is one formal way we can begin the shift the conversation to be more inclusive of operations and customer support. ### Software as a Service There’s a few reasons this is now more important than ever. The complexity of our systems today, has put to bed the myth of delivering perfect software. We formally recognise, its impossible to deliver 100% bug free software. In addition, we no longer deliver product, instead we’re delivering an ongoing service ([Jeff Sussna](https://twitter.com/jeffsussna?ref=annemariecharrett.com)). We’re deploying frequently, in with a trend to smaller and smaller batches, and, our businesses are loving it. The fear of a release is dissipating with the knowledge that fixes and mind changes can be rapidly turned around. If we decide let go the fear of releasing imperfect software ([conceptually and emotionally](https://www.annemariecharrett.com/good-enough-perfectly-applied/)), we need to make sure our operations and support are able to effectively hand the flow on effect. We need to be able to recover from bugs in production quickly, perhaps even before our consumers are aware the bug exists. This means we have to be able to detect and identify the root cause of a problem quickly. We’re talking observability, being able to see inside a system without having to add anything. Observability like testability needs to be designed in. It requires distributed tracing & appropriate infrastructure to facilitate debugging in production. All this requires we collaborate with operations better. Of course, devops provides us with a partial solution to this. The whole purpose of *devops* is to improve collaboration and share responsibilities for both success and failure. > The primary characteristic of DevOps culture is **increased collaboration [Rouan Wilsenach](http://rouanw.github.io/?ref=annemariecharrett.com)[ (MartinFowler.com)](https://www.martinfowler.com/tags/continuous%20delivery.html?ref=annemariecharrett.com)** But this collaboration does not include the product owner. To develop a complete shared understanding of an upcoming feature, the product owner is key. They hold the vision and the why of the feature. They are the definers of success. Without them existing we wouldn’t be developing software in the first place. It’s time to break down this silo and build a conversation. ### New 3 Amigos The new 3 Amigos facilitates this collaboration. > A conversation prior to software development between 3 key participants, the product owner, the software engineer and the ops engineer needs to take place that seeks to prevent, detect and recover bugs. #### Bug Prevention The prevention of bugs happens in the same way as a traditional 3 Amigos. Missed scope is identified through the use of clarifying questions. Questions like, “where else might this feature be used”, “who else might need access to this feature”? Technical risk is explored too. “Have we thought about security, usability or accessibility?”, “How many people are we expecting to consume this feature, and how will this impact our reliability?” “If a feature is not usable, what will be the impact on customer support, and are we ok with that?” #### Bug Detection Bugs are detected through testing the software. Here we want to come up with an agreed testing strategy that all agree on. Here you can use the 4W’s of software testing to guide. **What** will we test? W**ho** will perform it? **Where** will it be done? And **when** will it happen? Don’t forget to ask about testability too. Ask: “How will we test this”? You might generate an interesting discussion, even change the where and when a test will be executed. #### Bug Recovery And finally we ask about recovery of any bugs that slip through the net. How will we know in production if a problem occurs? How will we quickly recover in production from failure? What measurements are important to us? What tracing is required that enables us to detect such a problem in production? How will we deploy to mitigate the risk? ### What about the Testers? If a software tester or a QA exists within the organisation, then they play a vital role of facilitation and providing a structure around which these 3 Amigos can collaborate. But if there is no software tester, a quality coach takes on this role. It’s worth repeating though, this is not a role of ownership but of facilitation. Instead of directly asking the questions, you coach others to be able to ask these questions. You create the structure and event and help people through the process. ### Challenges with the new 3 Amigos All this doesn’t come without difficulty and challenge. One being a shared language and shared tooling. Put an ops person and a product person in the same room, and though they may have the same intent (a success feature),the terminology these roles use are different. And of course, there’s the question of priority. What matters most to a product owner, may not be top priority for an ops person. Plus, how and what we measure differs in software development and operations ([Mark Tomlinson talks to this on the latest quality roadshow podcast](https://www.spreaker.com/user/charrett/mark-tomlinson-performance-engineering-o?ref=annemariecharrett.com)). Tooling between software development and operations can be different requiring different know how when it comes to debugging in development and operations . Those barriers are slowly coming down. For instance, [Honeycomb](https://www.honeycomb.io/?ref=annemariecharrett.com) encourages the use of their tool in all environments local, shared and production, thus providing a shared context and shared understanding. I feel this is only the beginning of a trend. There is so much opportunity to expand on this collaborative event. For example, imagine a discussion on measuring feature success with the ops team in the room? Or asking questions on the impact of scaling a feature? I plan to expand on this in a second post. And that’s the crux of it. The new 3 Amigos. Let me know in the comments what you think and please give it a try in your company and let me know how it goes. ### The 3 Amigos in agile URL: https://www.annemariecharrett.com/3-amigos-in-agile/ Last updated: 2026-04-13T21:00:11.000Z I’m exploring the 3 Amigos in agile at the moment, as I feel it may be in need of a makeover. But first, the traditional view of the 3 Amigos. I know, there’s already loads of articles on the 3 amigos, but I thought it might be useful to understand my perspective. If you are well versed in 3 Amigos you’re just going to have to wait for the next post, otherwise if you feel like a nit pick or you genuinely want to know my thoughts on 3 Amigos, please read on. Incidentally the earliest write up the 3 Amigos seems to be by[ George Dinwiddie in 2009](http://blog.gdinwiddie.com/2009/06/17/if-you-dont-automate-acceptance-tests/?ref=annemariecharrett.com). I reached out to George who confessed he was the originator of the idea, though at the time it was done within a company in subterfuge so a big deal wasn’t made of it. A similar concept but not called 3 Amigos can be found in the Jim Shore ATDD model by[ Elisabeth Hendrickson](https://www.testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf?ref=annemariecharrett.com) (p17). ## What is the 3 Amigos in agile? The 3 amigos in software development is a collaborative event that takes place prior to software development. It assists in deepening a shared understanding of the feature\* that is about to be developed. *\*for the purpose of this post I’m going to use the word feature, but it could be any piece of work: a story, a task an epic.* The 3 Amigos typically consists of a product owner, a software developer and a tester. These 3 roles provide different perspectives on a piece of work. The product owner is thinking about the impact of the feature, the software developer is thinking the optimal solution when building the feature, and the software tester is thinking a) how to test it, and b) implicit assumptions being made in the scope of work. ## Output and Outcome in 3 Amigos The output of these sessions is often a set of agreed acceptance criteria from which tests can be derived. The outcome is shard understanding on the feature, the why and the context within which the feature resides. ## The Role of Software Tester in 3 Amigos The role of software tester in this event is often to ask clarifying questions. I broadly put my questions into two categories. Business type questions – where I question the feature being designed. For example, I look that downstream and upstream systems have been considered. Or I think how might this feature impact other parts of the already existing system. And, if I don’t already know, I seek to understand the why behind the feature to get a better understanding of desired outcome. The other type of question I ask is about technical risk. These I tend to direct to the software developer. I ask about security, or backend integrations. I ask about already existing api’s and the impact it might have. Knowing the technical risk, helps me decide if additional testing is required. So along with the functional acceptance tests, I can recommend additional types of testing. In this way, I hope to uncover ambiguity and implicit assumptions that may have being made. I’ve also deepened the shared understanding not only of what is being built, but the context within which the feature resides. From a shift left perspective, I’m preventing bugs from being developed reducing rework and preventing nasty surprises later in the delivery lifecycle. I’m sure many software testers reading this are in agreement and do something similar. The approach may be slightly different, and maybe it’s called a different name. What’s important, is that this type of collaboration is happening early on that is generating value. Next up, the new 3 amigos, consisting of a product owner, a software developer and an ops person, why we need it and the value it could potentially bring. Other content on the same topic: [The 3 Amigos in agileI’m exploring the 3 Amigos in agile at the moment, as I feel it may be in need of a makeover. But first, the traditional view of the 3 Amigos. I know, there’s already loads of articles on the 3 amigos, but I thought it might![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2021/04/3Amigos-2.jpeg)](https://www.annemariecharrett.com/3-amigos-in-agile/) ### Supporting the whistleblowers URL: https://www.annemariecharrett.com/supporting-the-whistleblowers/ Last updated: 2024-10-12T23:15:00.000Z ## Whistleblowers I’ve [written before on how software testers](https://www.annemariecharrett.com/inflicting-help/) think differently and play a different role to others in a technical team. In the past, a typical non testing view of the role was gatekeeper. This didn’t turn out so well. The history of quality and software testers is littered with corpses of gatekeepers and independent arbitrators of quality. Corpses that had full accountability without authority to enact, and so died on an altar of “ensuring quality”. Roll on to today. In our enlightened times, “quality is now a team responsibility”, and the physical role of a software tester is disappearing. But the mindset, that [nit picking](https://www.annemariecharrett.com/the-scab-picker/), that inclination to query and ask “but what if” and “but why” is still required and still happens. You may find now, in a company with no software testers, someone else will consciously or unconsciously pick up that mantle. That person often has the title with Devops or SRE, or architect in it. Typically a role that offers a system wide view of the service being delivered. No matter who does it, this mindset is vital. It helps us understand potential risks incurred as we design, develop, release and support. ***I loosely call people in tech with this mindset “whistleblowers”***. Traditionally, whistleblowers point out failings or illegal activity, often in situations where the majority are unable or unwilling to speak out. Whistleblowers in tech raise concerns about potential failures and risks. On the face of it, a whistleblower has the same end goal as everyone else. That is, to give our consumers a secure and reliable experience. One that delights and enables them to do their jobs well. But it goes beyond that. Whistleblowers often think beyond that vision. They think not only of how a feature may be used, but how that feature may be used by many all at the same time. They think about the impacts of failure and how that might impact our ability to respond reliably. The whistleblower mindset looks for risks and is kind of obsessed with failure—in a good way. They’re the ones who raise concerns about tech debt, question assumptions in design meetings, ask questions on standardisation of API errors, or raise concerns about unreadable code. They raise the concerns because they feel this oversight will come back to haunt us all at some point. They raise it now when action can be applied. ## Tension within Teams This mindset can and does create tension within teams, though. As the rest of the team drives to the release cycle, it almost feels like these people swim against the tide of rapid release. The whistleblower opens their mouth, and often, the response in the meeting is a collective eye roll. In the past, I’ve felt that exploring these divisions has been worthwhile. It helps us better understand the tensions that exist. Once we know and acknowledge, we can work to improve. There’s more work to be done. We’ve got to find ways to support these folks' vital work. Just as whistleblowers are supported by law, we in tech must create spaces for our very own whistleblowers—spaces where they feel supported, strengthened, and listened to. Trust me, there’s nothing worse than working in a way that leaves people feeling undervalued, disrespected, and unsupported. ## Focus on Unity One way to improve is to focus on what unites us—what we all have in common. You may be surprised about some of these. ## Quality My experience is that most people are passionate about quality. The nature of that quality differs, though. A software engineer may value the quality of maintainable code, while an ops person values the reliability of a system. A product owner values a compelling feature. So, while there’s a disparity in how that value may play out in a team, there’s no denying that we all value quality to some degree and want to see it improve. We can use that to unite us and appreciate each other's perspectives. ## Valuable Work Many of us want to come to work, feel useful, and somehow contribute to society. Nothing is more demoralising than working on a feature or a product that’s retired before the consumer sees it. If we work our butts off to deliver something, let's at least make sure it gets delivered. ## Outside of Work Many of us have loved ones outside of work, be they family, friends, or a close community. And while we may enjoy our work, there are other things that come before that. Often, we work so we can enjoy those things, and that’s totally okay. ## Our Humanity We all love. We all feel pain. We experience despair and its counterpart, hope. And we do this not in nice, clean linear graphs but more like up and down, round and round, loop the loop way. In us, we have the best of us and the worst. We live and deny that reality all the time. If you are anything like me, you do so on a daily basis. We rejoice in births and cry at deaths. We miss our loved ones and embrace them when they return. Maybe our similarities, not our differences, are what help us find ways to work better together—ways that acknowledge and appreciate our differences. *I updated this to version 2.0 after I published it. I changed the photo and some wording, but the sentiment hasn’t changed.* ### Be your best self URL: https://www.annemariecharrett.com/be-your-best-self/ Last updated: 2021-06-17T01:50:06.000Z Leadership is being your best self. Easy to say, harder to implement. For starters, what the hell does ” be your best self” mean? And why is that leadership? For me, being my best self, doesn’t mean achieving goals. It doesn’t mean going to the gym, eating the right food, studying the correct books. Being my best self is an exercise in self enquiry. It’s asking myself, the [right questions without need for answer.](https://mavericktester.com/2020/11/14/questions-over-answers/?ref=annemariecharrett.com) And when I am in this moment of presence, the need to solve and fix disappears. I’m calm and serene and at peace with myself. I can’t express in words the utter delight these few moments can bring. After years of intense anxiety as a result of a tonne of bad shit happening in tech, I feel at peace. Being content with yourself is at the core of being your best self. Shame, guilt, self flagellation, anger, remorse, indicate to me that I’m somehow out of kilter. And to clarify, these are all powerful and useful emotions. But if not managed well, they can distort your sense of self. And when we’re unable to move on, move past the hurt, we are performing an act of self-harm. Experience has told me how hard it is to move beyond hurt. It requires self forgiveness, self acceptance, massive buckets of self love and more than a pinch of time. But move on I must. To do so is an act of self-love. Leadership is hard, and even more difficult when it comes from place of inauthenticity. Without the confidence of being your best self , words and actions clank in their hollowness and only amplify the disparity between who you feel you are and what you are saying to others. It’s exhausting. Good leadership comes from a place where you are your best self. Reading this you might be asking, “does that mean you’re not leading when in those dark times?” After all, arguably, don’t dark times have to exist if you are leading with authenticity and vulnerability? I think back to [Roosevelts “Arena” speech](https://www.mentalfloss.com/article/63389/roosevelts-man-arena?ref=annemariecharrett.com). That as long as you are daring greatly, you are leading. It may not be a leadership of others, but you are leading by being your authentic self. It takes courage to look inward and accept your flaws without attempting to fix them. But I feel this is what leadership is. It’s about showing up, falling down, then picking yourself up from the dirt with all your flawed glory and continue the great fight we call living. ### The Scab Picker URL: https://www.annemariecharrett.com/the-scab-picker/ Last updated: 2021-06-21T05:32:11.000Z As I child I received the usual number of knocks and bumps, cuts and the inevitable scabs that grew as my body healed itself. I enjoyed nothing more than spending time picking away at these scabs. I wanted to explore and uncover, pick and observe in fascinating as the pink flesh repaired itself. To this day, I’ve got a couple of scars on my knee from cuts I refused to let heal! In reflection, I realise that metaphorically speaking, I’ve continued to do this all my life. I pick at technologies cuts and scabs, uncovering and exploring, probing and questioning. After all, what is the art of software testing but to pick at something that appears solved? When I look at my work in leadership, I see the same pattern. Picking at the assumptions of test management, identifying differences and exposing them to allow new healing. You could even argue that this blog is an attempt to pick away, uncover and better understand my thoughts, values and belief system. I question my bias, my beliefs, my opinions. I’m learning that while this analysis is useful, I should be careful not to correlate it to my self worth and allow it to destroy my somewhat shaky self-esteem. As a child, I used to hide my scab picking in shame. It was a sign of failure. Good children let their cuts heal. Beautiful girls had unscarred skin. Yet there I was compelled almost, to pick, pick, pick. Today, I’m more at peace with my scab picking. I don’t pick my skin anymore (except for the occasional zit), but I do continue to pick away at my ideas. In a way, it's my strength and I treasure the insights this scab picking has brought me. *There is no world scab picking day. I made that up. You are welcome to create the day if you wish and I will celebrate with you.* ### Creating a Culture of Quality URL: https://www.annemariecharrett.com/creating-a-culture-of-quality-in-a-startup/ Last updated: 2023-09-11T10:31:32.000Z ## The Startup Culture Working as a startup is fun. It’s an ecosystem of bubbling hope one minute, deepest despair the next. You pivot so often you feel dizzy. The lead time between decision and result is breathtaking in its brevity. You see impact straight away. Love autonomy? Then startup land is for you. But here’s the funny thing. I’ve experienced from working in, and have being witness to, many less than ideal (some plainly toxic) cultures in startups. Minimal collaboration, minimal testing and minimal transparency. Why is that? Surely with a small company it should be easier to do? As I see it, as a startup, you are in a unique position to build a culture that is different to those you see in many large enterprise organisations. One that for example, encourages autonomy, mastery and purpose. Or one that builds quality in without resorting to heavy restrictive processes. So why with a small company, with no more than ten people am I seeing similar patterns of behaviour that classify as anti-patterns in any other business structure? Why is it, that many startups appear to be slimmed down replicants of the exact culture they are trying to move away from? I believe that companies don’t explicitly set out to mimic these companies, but rather they obliviously evolve into one through trade off and prioritisation. ## Tradeoffs Impact Culture Startup land is all about tradeoff and prioritisation. Why? Because we’re resource poor. We simply don’t have the bandwidth to roll out all the wonderful things we have a vision for. Tough choices have to be made. And sometimes somebody or something loses out. At a superficial level, the impact is in output. Employee policies well intended are delayed until they are absolutely necessary. Diversity and inclusion becomes a nice to have, not an essential and we will ‘get round to it’ at some point. The standard of quality drops and becomes the norm but that’s ok, cos we can fix it quickly. There’s a deeper less obvious impact. It’s easy to be oblivious to it. You’ve heard the phrase: “the standard you walk by is the standard you accept…” In startup land, the standard you walk by is the culture you create. When you begin a startup, you’re not only building a product, you’re building a company and along with it, a culture. Decisions made in the early days, those tradeoffs you make, define and shape the company culture. Is your company all about employee consideration and value, yet there’s little/no discussion on employee benefits? Is your company all about autonomy yet only the founders make decisions? Is your company all about quality, yet you simply don’t have time or the budget to invest in any software testing? This may sound harsh. But the reality is, from day one, you are building the company culture. What you prioritise as a startup, becomes the defining standard. It becomes built into the companies metaphorical bricks and mortar. ## Culture eats and eats and …. A culture that is embedded figuratively eats everything around it. Once a culture is defined, it takes on a life of its own. Slowly, bit by bit, more bricks are laid on top of those early foundations, those decisions. And, before you realise it, your culture has been set. Once that happens, it’s far harder (though not impossible) to reset. Knowing your values helps in this. Brene Brown has some excellent material on this in her book Dare to Lead. You can also find material [on the website.](https://daretolead.brenebrown.com/wp-content/uploads/2018/10/DTL-Read-Along-Workbook-v1.pdf?ref=annemariecharrett.com) ![](https://charrett.ghost.io/content/images/wordpress/2020/11/Screen-Shot-2020-11-24-at-7.47.17-am-1024x962.png) [https://daretolead.brenebrown.com/wp-content/uploads/2018/10/DTL-Read-Along-Workbook-v1.pdf](https://daretolead.brenebrown.com/wp-content/uploads/2018/10/DTL-Read-Along-Workbook-v1.pdf?ref=annemariecharrett.com) ## Knowledge is key Discussing the implications of your decisions and how you can mitigate the impact of these decisions helps too. Ask people to make you accountable on the small things that you might understandably walked past. Becoming knowledgeable helps too. As an expert in technical quality and software testing, I know that having good quality doesn’t have to be compromised on the alter of cost of and speed. It does however require insight and understanding of strategy. Of when and what to invest in, and what to ignore. For example, building quality in does not mean excessive testing it’s about learning and understanding your market and facilitating experimentation. Perhaps some of the key threats to quality for startups are rigidity of approach and blinkered mindset that fail to learn from previous decisions made. As a founder of a growth company all this fascinates and excites me. It challenges me do do and ‘be’ better. Have you we got a long way to go? Hell yeah, but that’s half the fun, right? ### Questions over Answers URL: https://www.annemariecharrett.com/questions-over-answers/ Last updated: 2021-06-15T22:45:32.000Z Growing up, I remember listening to Bob Dylan on the radio with perplexment. He would sing: > “the answer my friend is blowing in the wind” To a twelve year old, this made little sense. How could wind, something invisible, fluid and uncontrollable provide any solution, any answer? And because the world was way too exciting, I pushed the question to the back of my mind and continued in my zeal to make my mark on the world. I ended up in the field of engineering where I discovered my passion for inquiry became a super power. The quest? An answer to a never ending question “How do we know”? (colloquially called software testing ). In particular I was interested in finding answers to: *How do we know if a product is fit for purpose?* *How do we know we have a quality product?* *How do we know if critical bugs exist?* *How do we know if we are on the right track to improving quality?* I’ve dedicated many years to looking for these answers, and helping others look for answers too. Having answers, being right, knowing what is, offers plenty for the anxious of mind and heart. In engineering, we feel we can for a time at least, shut the door on human complexity and focus on binary. Black and white, zero’s and ones. Of course, it’s an illusion, but it does offer respite from the world. Especially now, when so little seems certain. And besides, answers and solutions are cool! Answers build knowledge and understanding . Ask enough and in due course they provide you with credibility and an appearance of trustworthiness. You become someone to trust, an expert in your field of study. But ego hitches a ride along with most answers, enticing us all with an inflated view of our worth. And along with that, we have bias built into every knowledge block we add, building a mental model flawed and potentially able to hurt those we’re simply not aware of. The more we rely on our knowledge and expertise, the more we believe in its worth, the more brittle our mental model becomes. We don’t see that of course, but others do. After some soul searching, I’m forced to acknowledge too that in reality, this search for knowledge and knowing is a veneer. It’s not a drive for knowledge but more a thirst for enquiry that drives me to question what I do. I guess some people might call this a search for truth. The reality again, is that this soul searching hasn’t always led me to pretty places. Shattered illusions lie all around me even as I write this post. At times it’s led to despair, and heightened anxiety as answers seem to become more illusive and ephemeral in nature. Today I feel at peace, so what’s changed? I’ve reframed my search. Instead of looking for answers, I’ve started revelling in the question. Rather than seeking to be whole, I’m exploring the hole. Peace doesn’t come from an answer, a solution. Peace comes from the question. It’s in that moment when the question leaves your lips and floats into the wind. ### Look for the helpers URL: https://www.annemariecharrett.com/look-for-the-helpers/ Last updated: 2021-06-13T06:53:38.000Z - Its not about winners and losers - It’s not about right versus left - Its not about good or bad, right or wrong - Its not about pass or fail, testing versus checking, manual versus automation Its’s about the helpers. [Always look for the helpers](https://youtu.be/-LGHtc%5FD328?ref=annemariecharrett.com). It’s scary at the moment. Hell, everything seems to matter. The consequences of outcomes seems to be huge. And my tiny brain struggles to manage it at times. It’s enough to make me want to curl up under the covers and not get out of bed. What helps me? I look for the helpers. The people who keep going and keep working to make things happen. Here’s a list of my helpers - My awesome husband Andrei - My business partner Deepika - My family in Ireland - Colleagues Catherine Karena, Phil Jostsons - The Women in Testers Slack Channel (too many too mention) - Fiona Charles and Margaret Dineen These are my helpers. People who remain constructive and positive. They help me focus on the future. And when things get low they help me put one step forward at a time. I’m a helper too. Something I can easily forget, so it’s important to remind myself of that fact. In the past the software testing community has had its own divisiveness. At an aspirational level, the context driven testing community was created to improve the art and science of software testing. It was unfortunate that in doing so, it created division. Certification versus Non-Certification. Automation versus Exploratory. Schools of Testing were invented, to formalise paradigms with the (well-intended) purpose of generating debate. Unfortunately, the result was polarisation, division and arguably not a lot constructive debate. It’s taken a long time to heal, but heal we have. All of this is (at least for me) water under the bridge. It’s time to move forward. But if that time taught me anything, it’s the need to focus on construction rather than deconstruction. To look for similarities not differences. To focus more on [synthesis less on analysis](https://medium.com/disruptive-design/tools-for-systems-thinkers-the-6-fundamental-concepts-of-systems-thinking-379cdac3dc6a?ref=annemariecharrett.com). All ‘schools of software testing’ are required to help us deliver quality software. The Len’s of Helpers is helping me do that. By focusing on those who move forward who work to build and to help, there is a path forward. We build the path together, not ignoring our differences, but respecting them and seeing how they can complement each other. There’s so much strength and courage and forgiveness in helpers. It inspires me be a better human being. What about you? What helps you? ### Keynoting Remotely Selenium Conf 2020 URL: https://www.annemariecharrett.com/keynoting-remotely-selenium-conf-2020/ Last updated: 2021-06-21T00:44:18.000Z I had the absolute pleasure to be invited to keynote at SeleniumConf 2020 in Bangalore. I had decided in February to talk about test leadership and how to lead through uncertainty. And that was before COVID-19 came on the scene! It’s the first time I’ve spoken ‘live’ online at a conference and it doesn’t come without its own set of unpredictability and unknowns! It’s hard to speak when you can’t see the audience and you have little interaction. But overall it was fun. I think next time, I will keep the talk shorter, and allow for Q&A. I think speaking remotely like that makes interaction even more important. So shorter talks, longer Q&A is my learning! I didn’t get to the Q&A here are responses to the 4 of the most popular questions. **How do we see future of manual Testing over Automation Testing ?** Personally, I dislike this pitting of manual testing against test automation. For me it’s not one or the other, but instead a range, a blend of the two. Both types of testing provide value. Exploratory Testing is useful in more places than we realise. You can do exploratory testing in unit testing, when creating automated checks, during bug blitzes and even in production. Test Automation is great to give reliability of results and provide some confidence that the system is behaving as we hope it should. It also depends on what you are testing. For instance, if you are testing something brand new, and you have no idea on what to expect, a high amount of exploratory testing may be useful as you don’t have sufficient knowledge to decide on what the asserts are going to be yet. Again if something is changing a lot, exploratory testing maybe better suited until outputs start becoming more predictable. I think there’s going to be interesting manual work being done in the product area. I see the need for a product tester, someone who sits with the product team and helps identify risk(from a consumer perspective) early on. **As Increase Test Coverage will increase testing cost. How can we achieve good test coverage under limited testing cost?** Let risk be your guiding star. What is so important to your company that it must not fail? Make sure you test for that. Make sure you are refactoring your regression test suites. Consider that every test has an end by date. Look for duplication in test effort between levels of abstractions. Are we testing the same thing again and again in a different way, or are we truly testing something different. Ask what could fail in production and we would be ok with that? (Great question to ask in planning sessions) **How Automation testing moving over AI Testing**? It’s useful to think of AI/Machine Learning as a tool in software testing as opposed to a replacement. Yes, its a very shiny new tool, that promises the world, but its still a tool. I’ve not doubt in time, AI will replace some of the simpler activites in software testing. For instance, I’ve seen AI being used in test case duplication and also an attempt to make decisions on prioritisation of tests. There’s no doubt that the concept of AI is attractive and many companies will look to invest in this, but we’re far away from it taking over as the tool of choice. Put it this way, 25 years ago I was promised a test tool that would automated all the things in end to end testing. We still haven’t solved that problem well. These tests are still hard to maintain and are still brittle. Who knows, maybe AI will solve this problem for us! But I’m skeptical its going to be any time soon! That doesn’t mean we shouldn’t explore and better understand what value these tools can bring to our testing. I bet we will discover many ways it will help us, but also it might make our testing more susceptible to errors. **I want to perform software testing so that as organisation we get better Return on Investment?** I’m going to assume you are talking about ROI on software testing here. Short Answer: Don’t. It’s going to get you into all sorts of mess that needs a whole blog post. Deploying faster and more reliably with less errors is what most companies are aiming to do. So focus on that instead. Small frequent batches is how the risk of failure is being managed. That means, when (not if) there is a failure, that failure can be quickly fixed. Because of this approach, we’re measuring different things. Think of software testing in combination with software development as opposed to independent activities that are measured in isolation. Instead, measure deployment frequency, Lead time for changes, Mean time to recover (MTTR) and Change failure rate. (Read State of Devops 2017 for a good beginners guide into these measurements). Oh, and focus on trends, not absolutes. How we did compared to last year, as opposed to is this value good? [Options not Obligationstl;dr We want to provide our consumers and business partners options as opposed to obliging them by providing only one option. By “Designing in options” for your business partners and consumers, you provide them with the ability to take the greater risk while minimising the impact of![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpeg)](https://www.annemariecharrett.com/options-not-obligations/) [The Software MechanicHaving explained the role of a software tester to a non IT person they replied: So it’s like I’m taking my car to a garage to get serviced by a mechanic and all that the mechanic does is to find everything that needs to be fixed,![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/08/mechanics-2.jpg)](https://annemariecharrett.com/the-software-mechanic/?ref=annemariecharrett.com) [13 Low Cost Ideas to start Quality Coaching right away!\*The idea of being a Quality Coach or starting a Quality Coach program can seem overwhelming. Where do you actually start? You might get advice like the one above from the King in Alice in Wonderland gave which can seem profound, but in concrete terms, not very helpful! The scope![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/12/beginatthebeginning-2.jpeg)](https://annemariecharrett.com/13-low-cost-ideas-to-start-quality-coaching-right-away/?ref=annemariecharrett.com) [When the rubber hits the roadAnyone who has attempted to create and then implement a strategy, will know there’s a big difference between what is intended when the strategy is written, and what is realised on implementing a strategy. To the point in software testing, there’s been a push away from![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/01/rubber-meets-road-2.jpg)](https://annemariecharrett.com/emergent-strategy/?ref=annemariecharrett.com) [Threats to QualityIf, as Gerry Weinberg states Quality is “value to some person” …then the corollary stands that risk is anything that threatens that value.  This can be useful because Quality is an amorphous, shapeshifter, notoriously difficult to nail down. Its final judge is not us but our![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/risk-2.png)](https://annemariecharrett.com/threats-to-quality/?ref=annemariecharrett.com) [Emergent QualityIf you work in software development, like I do, you most likely work within a complex system. You also, most likely, work on a complex system. Not sure? Try answering these questions: Is it hard to model your system in all its complexity?Is it hard to work![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://www.annemariecharrett.com/emergent-quality/) [Contemporary Quality EngineeringSome randomish thoughts on quality engineering.  Quality engineering enables visualisation of the state of quality anytime in the delivery lifecycle of a system or service. It does so in terms of its business outcome.  Anne-Marie Charrett  (working definition) Services not Products&…![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/QEModelText-150x150-2.png)](https://www.annemariecharrett.com/contemporary-quality-engineering) ### Outcome over output URL: https://www.annemariecharrett.com/outcome-over-output/ Last updated: 2021-06-20T23:19:30.000Z I discovered the concept of outcome over output in 2014 through Jenny Mar’s work on [OOPSI ](https://jennyjmar.com/2016/04/16/bdd-discovery-and-oopsi/?ref=annemariecharrett.com). This led to [Teresa Torres](https://www.producttalk.org/?ref=annemariecharrett.com) awesome work on outcomes and opportunity This blog post is tagged #qualityhack. A quality hack reminds us not to get overly precious about quality. I know, sounds like heretic talk right? But hear me out. If you work in the quality space, as either a quality coach or a quality engineer, its easy to think that quality and software testing is the be all and end all of software development. Totally understandable why of course. If we want to excel on something, we need to focus on that skill in a deep way. But this immersion into one specific area comes at a cost. It means sometimes we overemphasise the importance of quality when it comes to solving our consumer’s problems and delivering software. TripleO reminds me to think about desirable quality related outcome rather than specific quality related outputs. Below, on the right are typical testing outputs1. On the left are testing related outcomes. Think outcome over output. Instead of having conversations about test coverage and bugs found, try focusing on outcomes. | **Testing Outcomes** | **Testing Outputs** | | ---------------------- | ------------------- | | Confidence to release2 | Test Coverage | | Threats to Quality | Bugs Found | | State of Quality | Bugs Fixed | Why? Because the people who pay for testing do so to get these outcomes. Understanding intent means you can talk to people with benefit in mind. This is useful when you need to advocate for quality. Focusing on outcomes gives us a second benefit. When we distance ourselves from outputs and focus on outcomes, magic begins to happen. The mental space this provides, offers alternative solutions to only testing outputs. ## Outcome: Confidence to release Let’s say the outcome from testing is ‘confidence to release’. We know that performing Software Testing is either going to give or takeaway confidence in the state of quality of our product, so what sort of questions might we explore here? Try these: - Why is confidence to release so important? Confidence to release so that…what? - What’s an example of confidence to release? - Imagine if you could no longer perform software testing prior to a release? How else might you gain confidence? - What safety nets do we have in place so we don’t have to be 100% confident in releasing? - how do we know our confidence to release is improving? - Is it worth trading confidence in release with speed of deployment? What is our limit? How far are we prepared to tradeoff on this? ## Outcome: Threats to Quality I’m talking risk here. Here are some avenues you may wish to explore around risk: - What new product risks exist outside of my expertise? - What business risks exist that I’m not aware of? - What is the impact of these risks? - Are they greater than the product risk? - What new threats to quality am I not considering? - What risks am I fixated on and how I can consider other risks? ## Outcome: State of Quality What about state of quality? Instead of having a discussion about bugs found, what if we had a conversation about the state of quality. - What is quality? What does it mean for us? This release? - What state of quality are we aspiring to? What is good enough? - How will we know we have this state of quality? - Imagine if you could no longer perform software testing prior to a release? How else might we see the state of quality? - Whats our minimum state of quality? - What absolutely must not fail? When we stop being fixated on one solution, when we stop trying to achieve perfection in our software testing we allow alternative approaches open up to us. Next #qualityhack, focusing on quality outcomes. *1The intangibles are required to make these output good . For instance, testing skill is required and has a significant impact on outputs. These are not the focus of this blog post.* *2 I’m using term release loosely here. You could interplay with deliver/deploy too.* ### The Software Mechanic URL: https://www.annemariecharrett.com/the-software-mechanic/ Last updated: 2021-06-25T22:04:20.000Z Having explained the role of a software tester to a non IT person they replied: > So it’s like I’m taking my car to a garage to get serviced by a mechanic and all that the mechanic does is to find everything that needs to be fixed, tell me and walks away? The Software Mechanic To which I muttered, “*there’s a bit more to it than that, but yeah, that one way of looking at what I do.*“ This simple but effective analogy (and his incredulity) has never left me even ten years on. Recently, chatting with [Maaret Pyhäjärvi ](https://twitter.com/maaretp?ref=annemariecharrett.com)on the quality coach podcast, we talked about having a mindset to “get stuff into the hands of the consumer as fast as possible”. She mentioned how she’s encouraging her intern to not only find bugs but fix them too. Find and Fix. Find and Fix. In this way, she shortens the feedback loop and focus on delivering value to the consumer faster. Smashing these two ideas together, the concept of software mechanic is born. Where, instead of focusing on finding bugs, instead we focus on finding and fixing them. Because, fixing bugs is the end game. It’s what we all want, improved quality. We don’t want an endless list of bugs weighing down our ability to move quickly. We want bugs found, fixed and forgotten. And, every bug has a cognitive load associated with it (another[ Maaret](https://twitter.com/maaretp?ref=annemariecharrett.com) gem). Knowing these bugs exist, adds to our list of “things we should be doing”. We try to ignore them. But, like monkeys on our backs, they cling on. They slow down our progress, impede our flow until in frustration we stop. We call these ‘bug fixing days’. Everyone commits to spending at least 1 day bug fixing in order to reduce tech debt. Software mechanics have skin in the game. Skin in the game means you’re invested in the outcome. Being invested in the outcome changes perspective. Instead of focusing on building extensive test automation, the goal becomes fixing bugs and releasing software. It *should* remove some of the friction within teams. Instead of that push/pull between tester and developer, everyone is visibly contributing to the end goal. And similar to a car mechanic, a software mechanic suits an apprenticeship model. Software development requires applied knowledge to achieve competence. Finding bugs, especially bugs that matter, demands we see our system from an outside perspective. The perspective of the consumer and the business. Finding bugs also requires we understand our systems, how the pieces hang together and interact with each other. Experience software developers know this knowledge is gold. Add bug fixing to the mix and you get hands on coding experience, in a safe to fail setting. What do you think? Would you like to be a software mechanic? If you like this post, you might like these: [2020: The year of dumping old heuristicsWhen software testing, it’s handy to use mnemonics/heuristics to refer to. They can be useful as generators of test ideas, or reminders to test in a particular way, or to consider some aspect. What’s a heuristic? Think of a heuristic as a rule of thumb![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/12/Screen-Shot-2019-12-31-at-6.41.25-pm-2.png)](https://annemariecharrett.com/heuristics-sfdipot/?ref=annemariecharrett.com) [Do your bugs only glow when its dark?Have you ever been in the situation where no-one else can find and repeat the bugs you find? Perhaps you have a canny knack of finding unusual bugs, or maybe it’s time to improve and update how you write bug reports! I do a lot of offsite exploratory![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2009/07/bugs-e1623019965964-1.jpeg)](https://annemariecharrett.com/do-your-bugs-only-glow-when-its-dark/?ref=annemariecharrett.com) ### Good Enough (Perfectly Applied) URL: https://www.annemariecharrett.com/good-enough-perfectly-applied/ Last updated: 2021-06-21T06:17:40.000Z *This is a series of blogs posts tagged quality hack. Quality Hack is a phrase I’ve coined to emphasise the importance of focusing on delivering “good enough” software, and embracing the cult of imperfection. If you wish to contribute a post, contact me either on [twitter](https://twitter.com/charrett?ref=annemariecharrett.com), by comment below, or email me@annemariecharrett.com* ## Recovering Perfectionist I’m a recovering perfectionist. For instance, it took me an hour to think and rewrite that first sentence. Why recovering? I’m a perfectionist and I’m aware that this isn’t always healthy. For me, perfectionism is less about ‘being perfect’ and more about ‘being in control’. Its my attempt to make everything work out the way I want. And while perfection can help us achieve a great deal and complete work we are proud of, it can come at a great cost. Aiming for perfection is not great for anyone’s mental health. I’m my own worst critic and an expert at identifying how I screwed up on this or that. Focusing on what is not, rather than what could be. Perfectionism can be poison in relationships too. With high and unreasonable expectations comes inevitable fall out creating distance between those you love. Work wise it can be a problem too. A perfectionist doesn’t stop at good enough leading to stress, high anxiety and burnout. There’s benefits to being a perfectionist. It helps me achieve my goals, giving me clarity. It encourages me to continue, even when the outlook is grim. As a recovering perfectionist I know I needed to seek out alternative viewpoints. Where else but twitter? ## Your views – its good & bad > How does being a perfectionist impact (good or bad) your tech work? Love to hear your answers -signed 'recovering perfectionist' 🤓 (took me 10 mins to craft that tweet). > > — Anne-Marie Charrett (@charrett) [August 2, 2020](https://twitter.com/charrett/status/1289845719113666561?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) I got some great replies! On a positive note, Angie Jones embraces perfectionism, seeing it as a driver to great work. I feel this too. > I embrace my perfectionist traits. They lead to high quality work. > > However, I've grown enough to recognize when perfectionism has become the blocker, and I then listen to reason. > > — Angie Jones (@techgirl1908) [August 2, 2020](https://twitter.com/techgirl1908/status/1290070120694341637?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) Many perceived perfectionism as negative. > My perfectionism leads to a sometimes unfair level of expectation on those I work with. I have to remind myself that I don’t work the same way as others and I need to be patient with others. > > — Shaun Rashid #BlackLivesMatter (@shaunrashid) [August 2, 2020](https://twitter.com/shaunrashid/status/1290072697376931841?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) > My perfectionism comes from low self worth, and is a method to prevent failure. Because my belief is that if I fail at a task, I am a failure. This (obvs) isn’t healthy. > > It prevents me from recovering after mistakes and seeking out second opinions. > > It makes me work in solitude. > > — Clara Behrmann (she/her) (@ChaoticClara) [August 3, 2020](https://twitter.com/ChaoticClara/status/1290143017223954432?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) It’s hard to collaborate when you’re a perfectionist. You’re unreasonable expectations means its rare you and those around you to succeed. Perfectionists tend to isolate themselves from others in order to control the outcome. Not great when software development is a collaborative endeavour. Our achievements are tied so closely to our own worth, we tend to take feedback poorly. We see feedback as a sign of our own personal failure as opposed to an opportunity to learn something new. This makes it hard for us to recover and bounce back over a perceived ‘failure’. Perfectionists tend to be slightly myopic with a fixed view of how things should be. As a result we tend to avoid seeking other people’s point of view, especially if they are different to our own. On the face of it, Software Testing is a great profession for perfectionists. People want great software, and we help identify flawed. Who better to find flaws than perfectionists? ## Software Testing & Perfectionists However we make great software testers!! Who better than to find flawed software than a perfectionist! Who better to advocate for quality than someone with the highest expectations? But dig deeper, and you find that even here, perfectionism can hinder quality more than they improve it. For instance: - We become fixated on doing things in a certain way and are reluctant to open up to new ideas, especially if they come from outside of testing - We sometimes are reluctant to let go and release ‘good enough’ software - We are reluctant to learn new skills for fear of being seen as ‘not good enough’ Bill Matthews had some good insights: > – Failure to launch/publish > – probably over analysis & planning > – difficulty in making some decisions > – not always content with outcomes > – sometimes just delete and redo stuff (like this tweet) > > — Bill Matthews (@Bill\_Matthews) [August 2, 2020](https://twitter.com/Bill%5FMatthews/status/1289857687316860928?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) ## Worse is Better In 1989, Richard P. Gabriel wrote an essay, [worse is better](http://dreamsongs.com/Files/LispGoodNewsBadNews.pdf?ref=annemariecharrett.com) . In contrast to the MIT approach which is to get all things right, Richard suggested an alternative worse-is-better philosophy: - Simplicity—the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. - Simplicity is the most important consideration in a design. - Correctness—the design must be correct in all observable aspects. It is slightly better to be simple than correct. - Consistency—the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. - Completeness—the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardised. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. ## Recovering Perfectionist Tips If you, like me are a recovering perfectionist, you, like me, will have found some tricks and techniques to help you along this journey. For instance you may; - Actively seek out alternative view points to help you balance your ‘one brilliant solution’. - Limit your WIP that forces you to take healthy breaks away from work - Take a fresh look at friends and family outside of tech and make an effort to reconnect - Meditate – breath when that feeling of lack of control falls on you and you panic when you think its not going to be done on time - Mediate and focus on gratitude and the good things around you - Ask for feedback often to help build your resilience muscle Being a perfectionist can be extremely rewarding in that you get so much stuff done. And that can feel great. Like Angie says, it can drive you to achieve truly wonderful things. I bet the pyramids were thought up by a perfectionist. But it can have its drawback and it’s wise to keep those perfectionist tendencies in check. And that should be ‘good enough’ More on [on perfectionism and work ](https://hbr.org/2018/12/the-pros-and-cons-of-perfectionism-according-to-research?ref=annemariecharrett.com) If you like this read another post on perfectionism [Perfect Software Testing for Perfect SoftwarePart of the purpose of Software Testing is to try and achieve perfect software. But perfect software does not (perhaps cannot) exist.![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/tron-2.jpeg)](https://annemariecharrett.com/in-search-of-perfection/?ref=annemariecharrett.com) ### Coaching Upwards URL: https://www.annemariecharrett.com/coaching-upwards/ Last updated: 2021-06-21T05:25:51.000Z I struggle to complete blog posts. [Lena Wiberg](https://twitter.com/LenaPejgan?ref=annemariecharrett.com) suggested we do pair-blogging on a same topic. It’s a great idea. Here’s my version. Lena’s angle is more personal and I love it. You can read it here. Thanks Lena for the suggestion. This topic has been on my mind for a while! ## TL;DR If you want to influence your seniors on software testing try this approach based on the [Elephant and Rider analogy](https://youtu.be/ipalwtgoLq0?ref=annemariecharrett.com). - Appeal to their motivation by placing your position in terms of achieving their success - Make the path ahead easy for them to accept, think about obstacles and how they can be removed - Backup with as much data and research as you can Interested to know more? Read on. As part of the [TestBash Coaching and Management panel](https://club.ministryoftesting.com/t/testbash-home-coaching-and-management-panel/36741?ref=annemariecharrett.com), one question put forward was this: How do you coach upwards? We ended up [talking more about managing upwards ](https://www.ministryoftesting.com/dojo/series/testbash-home/lessons/testbash-panel-coaching?ref=annemariecharrett.com) (pro membership required) and while I liked my answer (see 29 minute mark, but listen to the lot, great nuggets from Pradeep and Aaron in there), it got me thinking about the importance of being able to influence those senior to you. ### Influencing Upwards Being able to influence upwards is always a critical leadership skill, and a quick search on Duck Duck Go shows many articles on how to do that. But influencing upwards to someone who understands your context and your experience is one thing though, influencing seniors on topics they’re not experienced in can be different. And let's face it, when it comes to software testing, many of us now report to someone who doesn’t have a testing or quality focused background. It becomes essential to be able to put forward your point of view and explain in a way that’s digestible for your leaders. And of course, it’s easier to put forward an idea or concept that our tech industry supports. More test automation? Moving to cloud based services? Reducing the number of software testers or buying a new tool? These ideas are less controversial than for example, increasing the number of software testers, or wanting to perform more exploratory testing in the process. These less accepted ideas require sensitive and careful handling if you are going to achieve the outcome you desire. It’s this context I’m going to focus on in this blog post. Successful conversations (don’t call it coaching) like this are not performed off-the-cuff. They need careful thought and preparation. And you need allies. ### Allies By allies I mean people who will support your idea. Look around in your organisation and target people who work well and are respected with your leader. Explain that you want to propose an idea and ask them for some ideas on how to present it and approach making your case. ### Research is key You also need to do some legwork. Research the person you want to engage with, your company vision and the idea/strategy you want to propose. Areas to consider and explore might be: - What is this person’s management style? Are they hands off or a bit of a micro manager? - What is their communication style? Are they a details person, or a TLDR type of person? - What are this person’s aspirations from an organisational perspective and also personally? - What are their ideologies about tech? About Software Testing? What philosophies do they hold? Is it automate all the things? Culture is King? Quality is a team responsibility? - What vision do they have for your organisation? Where do they hope to take your team? - What KPI’s are they accountable for? - Where are their challenges? The goal at this point is to explore without judgement or attempting to influence. This is purely a fact finding mission. Once you have some of this information, you can begin to think about how this information may frame your conversation.For example, this means using their language instead of yours, reframing your ideas so they align with their motivations and aspirations. ### Reframe your idea Here’s the same list as above with added questions to help reframe your ideas. - What is this person’s management style? Are they hands off or a bit of a micro manager? **How might this affect your approach?** - What is their communication style? Are they a details person, or a TLDR type of person? **How might this impact how you provide supporting information and how you follow up?** - What are this person’s aspirations from an organisational perspective and also personally? **Where do your ideas strategy support these goals?** - What are their ideologies about tech? About Software Testing? What philosophies do they hold? Is it automate all the things? Culture is King? Quality is a team responsibility? **How are these ideas similar to yours, how do they differ? How will this impact your idea/strategy?** - What vision do they have for your organisation? Where do they hope to take your team? **How can your idea complement this?** - What KPI’s are they accountable for? **How can you help them achieve their KPI’s?** - Where are their challenges? **How can I help them overcome their challenges?** ### Dealing with Resistance You now have done research, and you’ve tapped into their motivation. Done right? Well not quite because you’re not working inside a bubble. You are probably going to get a response, and how you deal with that response matters too. If the response is positive one and you simply get a “Make it so”, fantastic. High Five ! But most likely you are going to face some sort of response, be it out of curiosity, or due to resistance. ### Collecting Objections How do you deal with resistance and rejection? Again it goes back to being prepared. Think ahead about how your ideas may be rejected? What might they say? How might you respond? Having some idea of how to respond will help you feel more ready to have the conversation. And be prepared for your mind going blank in the heat of the moment. If this happens, try ‘collecting objections’. Collecting Objections means you enter in to the conversation with an open mind of enquiry, instead of a mindset of attempting to persuade. So, when objections arise, instead of attempting to counter argue, you mentally collect them. For instance you could say something like. “Those are good points, would you mind if I have a think about them in our context and get back to you about my thoughts on that?” Another approach is what I call, ‘giving them enough rope’. I do this by letting them speak for as long as they like. I question from a place of curiosity. At some point they’re going to say something I can respond to. And if not, I’ve probably gone some way to to build some rapport. So its all a win. ### Should I Counter Argue? There’s nothing to stop you counter arguing of course. Personally, I find presenting ideas and engaging in dialogue a big confidence booster. But this comes with a big warning label. Safety for both of you is essential. Having a trusting relationship helps, but there’s a reason why many people hire consultants to do this type of work and that is the risk of failure is less. There are still organisations which discourage upward interaction. In these places, putting an idea forward can come at a cost to your standing within the organisation. Fortunately these cultures are in the minority but they still do exist, so if you work in one of these and need your job, please tread with caution. ### Dealing with Rejection If you do put a strategy forward that gets ignored or dismissed try not to take it to heart. It’s not you they’ve rejected, it’s the ideas you put forward. And while both may feel the same, they are different. Instead, try playing the long game. Remember there could be a number of reasons why your idea is turned down and not related to your idea. Go back, ask for an explanation on the grounds you want to improve and understand better. That’s always worked a treat for me. ## Backup with Data Finally, you want to use all that data you have researched to back up your ideas. Some senior people find it risky to take on new or controversial ideas unless they know another organisation has taken this on. See if a similar company to yours has tried this out. Even anecdotal stories help. And if all this feels a little overwhelming, try speaking first at meetups and brown bag sessions. Test out your ideas, encourage Q&A. These are great confidence boosters and will help you be ready for that day you win over people with your fabulous ideas and strategies. Good look, and may the force be with you! Like this post, try these too [Test Management RevisitedThe concept of test management sits awkwardly in agile, mostly because it’s a construct derived from the time when testing was a post-development phase, performed by independent testing teams. These teams were often of significant size, to reduce the time required to perform test execution. A test m…![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/01/TyroTrainImage-2.png)](https://annemariecharrett.com/test-leadership/?ref=annemariecharrett.com) [13 Low Cost Ideas to start Quality Coaching right away!\*The idea of being a Quality Coach or starting a Quality Coach program can seem overwhelming. Where do you actually start? You might get advice like the one above from the King in Alice in Wonderland gave which can seem profound, but in concrete terms, not very helpful! The scope![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/12/beginatthebeginning-2.jpeg)](https://annemariecharrett.com/13-low-cost-ideas-to-start-quality-coaching-right-away/?ref=annemariecharrett.com) ### Inflicting Help URL: https://www.annemariecharrett.com/inflicting-help/ Last updated: 2024-10-12T23:05:29.000Z Pain is our bodies way of telling us to stop doing something. Stop putting your hand on a hot stove, stop hammering your thumb, stop walking into lampposts… Like it or not, our profession, software testing, unwittingly creates pain in others. Shattering illusions does that. Have you seen that look of mild alarm as you approach a software developer? You know the one, that pleads, “please don’t let it be me…”. The pain isn’t only one sided of course. Software testers can feel pain as well when software development runs over and their insufficient time to test. A human response to pain, is to remove or reduce it. Sometimes we do this through changing or own behaviour. Often we try and change the environment around us. For example, if we burn our thumb on a hot stove, we move the thumb away (our behaviour), but we also turn off the stove. In software testing, we do the same. We modify our own behaviours, but we realise that in order for things to work effectively we need to modify other’s behaviours too. Tricky work, when you don’t necessarily have huge amounts of influence on the time. In software testing, we try and remove the pain of ‘not enough testing time’ through the concept of shift left. We try and persuade the team to start testing earlier. To fix our pain, we attempt to inflict help on the team. Sometimes we call this help ‘quality improvement’. Look at shift testing left. We like the concept because it means it solves our pain, our headaches. With software testing starting earlier, we have more time to finish our work and we potentially reduce the number of bugs created. No brainer right? The trouble is, while our pain may reduce, we’ve inadvertently created pain for others. Developers workload has increased. Logically, Shift Left makes sense, and it’s a useful heuristic to adopt. But we don’t work on logic, we’re driven by our emotions. So while logically this means they won’t have to fix bugs later down the track, it doesn’t really feel that way at the time when they consider the additional testing they need to do. Have you ever been with a team that feels they’re doing a good enough job and they don’t see a reason to change? Do you sometimes feel like you're a nurse telling a patient to drink the cod liver oil because ‘its good for you’? Logically the team knows you’re right, but at an emotional level their not feeling the pain you feel and so have little incentive to change. I’ve seen two different ways of handling this situation. First is to have a conversation around responsibility of quality. A consensus of quality being everyone’s responsibility can then lead to discussion of how as a team, the pain should be fixed. I call this strategy path of most resistence. Sometimes, rather than looking at what you feel is the solution understand their pain. Instead of fixing your pain, look to fix their pain. What’s bothering them? What can you do to help out their priorities, as opposed to your immediate concerns? Shifting the focus on the team, allows you to view their concerns. Why is this important? Because once people see you're interested in their pain, they’re more willing to work on yours. The second strategy is much smarter and was taught to me by Anne Colder. It’s called Verwondering. Verwondering is a dutch term that translates badly into ‘being curious’. Instead of trying to fix the pain, get curious about how it's come about in the first place. Ask questions on why the release is late? Do they not have enough time? Why are things so, and has anyone tried to fix the situation? What happened when they did so? What fears are driving these behaviours? Verwondering encourages you as a quality advocate to put aside your ego and your desire for change and genuinely listen to where people are coming from. The Verwondering strategy is particularly useful in the role of quality coach/advocate. Here, you may be in a position where you need to influence without direct authority. Let go the desire to ‘inflict help’. Get curious about your team. Ask for their input. None of this guarantees success but it may help to build a collaborative and supportive environment. And who know, down the track what that may lead to? I think that’s enough inflicting help for one night Like this post? Why not have a read of the following: [13 Low Cost Ideas to start Quality Coaching right away!\*The idea of being a Quality Coach or starting a Quality Coach program can seem overwhelming. Where do you actually start? You might get advice like the one above from the King in Alice in Wonderland gave which can seem profound, but in concrete terms, not very helpful! The scope![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/12/beginatthebeginning-2.jpeg)](https://annemariecharrett.com/13-low-cost-ideas-to-start-quality-coaching-right-away/?ref=annemariecharrett.com) [Test Management RevisitedThe concept of test management sits awkwardly in agile, mostly because it’s a construct derived from the time when testing was a post-development phase, performed by independent testing teams. These teams were often of significant size, to reduce the time required to perform test execution. A test m…![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/01/TyroTrainImage-2.png)](https://annemariecharrett.com/test-leadership/?ref=annemariecharrett.com) [Coaching UpwardsI struggle to complete blog posts. Lena Wiberg suggested we do pair-blogging on a same topic. It’s a great idea. Here’s my version. Lena’s angle is more personal and I love it. You can read it here. Thanks Lena for the suggestion. This topic![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/07/coachingupwards-2.jpg)](https://annemariecharrett.com/coaching-upwards/?ref=annemariecharrett.com) ### The beginning of discovery URL: https://www.annemariecharrett.com/the-beginning-of-discovery/ Last updated: 2021-06-14T04:13:48.000Z [Lisa Crispin](https://lisacrispin.com/?ref=annemariecharrett.com) picked up on this small seemingly innocent sentence about the importance of ‘shallow tests’ in discovery > “These \[shallow\] tests are often essential beginnings to discovery”Anne-Marie Charrett [“Shallow Testing gets a bad rap”](https://mavericktester.com/2018/10/17/bos-series-shallow-testing-gets-a-bad-wrap/?ref=annemariecharrett.com) I’m glad she did, thanks Lisa! The idea that cheap easy confirmatory tests are essential to exploration has been a concept I’ve been working on for a few years now. I’ve shared it with a few testers, but have never put the concepts down on paper. Her tweet has prompted me to do so. And I’m happy, as I get to reference one of my all time favourite software testing books( that don’t mention software testing). That is David Khlar’s book, Exploring Science. In fact, I like this book so much, I’ve adapted his work and [created a workshop on discovery and exploration](https://mavericktester.com/2010/11/14/archive-on-the-road-to-a-big-trak-discovery/?ref=annemariecharrett.com). Typically, when people talk about shallow tests in software testing they mean tests that are cheap to design, execute and observe by the business and confirmatory in nature. Personally, I’m not a huge fan of that term but that’s not the topic of today. *(To find out why back read [“Shallow Testing gets a bad rap”](https://mavericktester.com/2018/10/17/bos-series-shallow-testing-gets-a-bad-wrap/?ref=annemariecharrett.com) and [Black Box Testing](https://mavericktester.com/2018/10/22/black-box-testing/?ref=annemariecharrett.com))* In his book “Exploring Science”, David Klahr examines the process of discovery. To do that, he conducts a series of studies where he gives people a robot (BigTrak) and asks them to identify the purpose of a RPT button. In order to figure out what RPT does, the participants hypothesise, then design and conduct tests, then observe & evaluate results. All the time, Khlar is observing their process. He noticed that participants 1) leant to using a positive test strategy (tests that confirm a hypothesis) and 2) the tests were typically typically cheap, easy to conduct and observe output. In short they used shallow tests. Here’s a summary of what he found and his observations. ## Test Design and Discovery ![regions khlar discovery](https://charrett.ghost.io/content/images/wordpress/2020/02/regions-scaled-e1580550199744-1024x629.jpg) Region 1, Region 2, Region 3 – Exploring Science – David Khlar Khlar analysed the design of the tests. He categorised the tests into three regions. The cheap, easy to observe tests reside in region 1\. Most participants started with tests in this region. The trouble is when they pass, they’re ineffective in evaluating information. That is, it was hard to draw a conclusion from the result. Sure, the result indicates the “hypothesis at hand” is right, but it also confirms unconsidered hypothesis. This made it hard to know if the hypothesis was the right one. Khlar describes these tests as having low discriminatory power. Introducing Region 2\. Tests from region 2 are more effective at providing useful evidence. Essentially region 2 test are better designed with evaluation in mind. Because of that, they had greater discriminatory power. When a test is run using tests in Region 2, we can evaluate if this particular hypothesis is true or not. (*I’m not going into Region 3 today, go to read the book*. ) But here’s the interesting thing. Yes, the tests that passed in region 1 where less effective in evaluation than region 2\. But, when they failed, they provided huge value! In fact, they became the blockbusters of the discovery process. (Ok, I made that up). What is going on? ## Discovery & a Positive Test Strategy Khlar observed that most participants followed a positive test strategy. They reasoned that “my theory is that RPT does X. If I am right and I write program Y, then BigTrak will do Z”. Khlar saw this positive test strategy as beneficial. He writes: > ..a positive test strategy may be a useful heuristic in the early stages of investigation, as it allows the participant to determine types \[variables to you and me\] and instances\[tests\] that are worthy of further investigation. ..Exploring Science — David Khlar. In addition, Khlar observed that these failed tests encouraged participants to re-evaluate their understanding of the RPT button and the nature of the tests they were conducting. In essence, it caused them to double think and go back and assess their understanding. This was important as the toy has over 30 billion distinct programs to chose from for each experiment. Using a positive test strategy that failed, allowed participants to quickly identified key dimensions that impact the experiments narrowing the search space considerably. Khlar also highlights another benefit. He adds: > A positive test strategy provides at least a sufficiency test of one’s current hypothesis. Exploring Science — David Khlar. In short, at the very least, running a test that’s simple to execute and observe and passes, guarantees that at minimum you have everything in place that you need in order to run your experiments. In the case of Big Trak, this would be, yes I understand how the toy operates and yes, the batteries are not dead etc. ## Discovery & Uncertainty An interesting aside, Khlar also cites [Klayman and Ha (1987)](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/KlaymanHa1987.png?ref=annemariecharrett.com) who theorise that when there’s high uncertainty and plenty of unknowns, a positive test strategy is a solid approach to take. (I got lost in the maths here but [take a look](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/KlaymanHa1987.png?ref=annemariecharrett.com)). ## Business Friendly I’m a big fan of cheap, easy to run tests, not just because of all the good stuff above, but because of the value they represent to people who don’t spend all their days in the bowels of tech and experimentation. People outside of tech have plenty of work to do, it’s not on them to understand the subtle differences in different testing strategies. It’s on us, to provide the information in a language they understood and can get their job done. Khlar seems to think so too, suggesting how you portray data is critical for discovery, recommending data representation be included in discovery, along side hypothesis and experimentation. > There is no question that search for an effective representation can play a crucial role in the discovery processExploring Science — Adding a New Space — David Khlar. ## My Thoughts As a software tester, this all makes total sense to me. A huge part of starting to test software involves building a mental model of the system under test. I want to figure out its purpose, its constraints, its idiosyncrasies. I do this not by looking for negative tests, but by drawing on past knowledge, making some simple assumptions, and then running easy to execute tests design that validate my thinking. This is an essential part of the discovery process. These tests come from experience, know how and are not to be hidden under the carpet to be dismissed. Instead, they should be worn with pride, a badge to proudly proclaims your curiosity, your willingness to use past knowledge and acquired heuristics. What’s not to love? ### When the rubber hits the road URL: https://www.annemariecharrett.com/emergent-strategy/ Last updated: 2023-09-11T10:32:46.000Z Anyone who has attempted to create and then implement a strategy, will know there’s a big difference between what is intended when the strategy is written, and what is realised on implementing a strategy. To the point in software testing, there’s been a push away from writing formal strategies. They’re often seen as irrelevant and past their use by date by the time they’ve been written. But strategies in general can be really useful for a whole number of reasons. For instance, they can be used as a focusing tool, to help identify key areas to focus testing on. They’re an excellent analytical tool, challenging you to think about assumptions, constraints and resources. At a broader level, they can be used as a communication tool to justify budget in terms of people and resources. But its not often that a software tester will go to a software testing strategy to figure out what to do next. Thats because software testing strategies may begin with intent, but tend to rapidly evolve into emergent strategies. What’s an emergent strategy? Mintzberg and Water (1985) came up with the term to help identify the gap between the intention and the realisation when it comes to strategies. I found [this video ](https://www.youtube.com/watch?v=X-Qm09MAacI&ref=annemariecharrett.com)useful as background reading. Here’s an overview: ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/01/Screen-Shot-2020-01-12-at-10.21.45-pm.png) An emergent strategy is one that evolves once the rubber hits the road. When you begin testing and discover a whole new set of risks you hadn’t realised before and change direction to accomodate that, your strategy has just become emergent. It’s the strategy that emerges as assumptions get tested, constraints become concrete and context changes. If that is, you act on the information in front of you. When working in complex, uncertain environments, when there’s more questions than answers, it makes sense for teams to be aware of the emergent nature of a software testing strategy. So sure, create that strategy, provide intent. Remember though, dump what proves to be irrelevant, jump onto what emerges as useful. When it comes to quality coaching, we too need to develop strategies. And, because quality has many dimensions that impact it, it makes sense to rely on an emergent strategy as opposed to a predetermined one. I’ll be tackling that topic either here on in my book. ### Test Management Revisited URL: https://www.annemariecharrett.com/test-leadership/ Last updated: 2021-06-17T01:51:08.000Z The concept of test management sits awkwardly in agile, mostly because it’s a construct derived from the time when testing was a post-development phase, performed by independent testing teams. These teams were often of significant size, to reduce the time required to perform test execution. A test manager was often both line manager and the person responsible on projects for test strategy and reporting. Agile, with its focus on cross functional teams, has sounded the death knell for many test managers. Today, you see the test lead role more frequently. This makes sense because the way we develop software has changed and it continues to evolve. Like any other discipline, testing must adapt to its new context. ## Test Leadership While test management is largely irrelevant in this world, there is still a desperate need for test leadership. Why is this? The main reason is that as organisations struggle to become more innovative to respond quickly to market changes, engineering has responded by turning to continuous deployment and cross-functional teams to help meet demand. How testing fits into this picture is proving to be an Achilles heel for many organisations, which struggle to solve the challenge of how to making testing relevant and faster, yet uphold the quality they need to develop trust with their customer base. The truth is, agile or not, most organisations adopt a testing approach constructed not long after the computer came into being—despite the enormous technological advances made in the last 70 years. We’ve developed innovative ideas on how to develop and release software, but when it comes to testing, the only real new idea since 1980 has been to automate test execution, or failing that, to outsource the problem. It’s not that other ideas are not out there. Exploratory Testing and Context Driven Testing have been around a long time, yet while they are slowly gaining credibility and popularity in larger enterprise organisations (think Ebay, Barclays GTC), they are still a long way from becoming mainstream. Organisations need experienced and seasoned testers who have the maturity, vision and courage to drag testing from the dark ages and pull it into the 21st century. Test Management is not going to do that, but Test Leadership might. In the article “What Leaders Really Do” John P Kotter writes: > “Managers promote stability, leaders press for change.” He argues that managers focus on control, budget and planning, while leaders focus on aligning people, vision and motivation.John P Kotter Testing needs leaders, not managers, to deal with these current challenges and help pull it into the 21st century. We need test leaders working within organisations who have a vision of how testing can be better, and the courage to make those ideas a reality. ## Banking, Disruption, XP I’ve applied my ideas in test leadership when I worked first as QA Manager & then Head of Engineering at Tyro Payments one of Australia’s neobanks. I’ll explores the demands for testing in banking, how TP went from test management to test leadership and how that impacts the daily work of testers, how they take decisions, and how testers help teams to increase their test abilities, and how continuous delivery has impacted testing. With good reason is banking a heavily regulated, risk adverse industry. Banks are entrusted with people’s money. Reliability, Security and Performance are key quality attributes and testing reflects this focus. Tyro Payments is a disruptor, a challenger to the traditional banking approach. We align ourselves in the fintech space, but we’re more tech than fin and our culture reflects that. For example, our banking platform is developed in house using agile processes such as XP, pair programming and TDD. Everyone at Tyro Payments is responsible for quality and testing is an activity that all engineers perform. The tester on the team specialises in testing, using their investigative skills, their understanding of potential failure and how it might impact the customer. They experiment to better understand and learn the system. They share this knowledge with the rest of the team, helping the team make informed decisions about quality. This ideology differs to traditional banking testing practice. In most banks, testing is seen as a control, the gatekeeper that ensures quality. At Tryo Payments, we’ve questioned this premise. For us, quality is a team responsibility. Instead we consciously work to build the best software we can given our professional capability and the goals & culture of the organisation we are working in. In this context, software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test \[Kaner 2006\]. These concepts have changed how we view and conduct testing. For example, instead of a fixed upfront test strategy, we allow our test strategy to evolve and adapt as new risks such as bugs found, or new business directives, emerge. This allows us to quickly react to change, keeping our testing relevant to our stakeholders. Another example is our focus on security. While we have a specialised security guild, Security is something everyone is responsible for. All engineers are trained to be aware of current threats and vulnerabilities. This agile approach extends to how we work with regulators. Instead of second guessing what it meant to build a core banking platform, we worked closely with regulators, incrementally identifying through experimentation, the MVP required to obtain a banking license. ## Test Leadership over Test Management We’ve always challenged the premise that the test manager owns tasks such strategic direction, process improvement, hiring etc. Instead we distributed these tasks among the team. Testers had the option to chose areas that interested them. This resulted in them being responsible for recruiting, improving the testing process, internal training, social activities etc. This benefits the testing practice in two ways. It frees up my time, allowing me to focus on coaching and training, but also it provides opportunities for people to acquire new skills. In the past year and a half, we’ve had rapid growth in team size, and made some significant changes to how we test. The team grew from 5 to 23 in just over one year. We embedded the testers into development teams, creating more cross functional teams. Recently, we’ve adopted the Spotify delivery model using tribes and squads. With change and growth comes uncertainty, especially because we were trying out new approaches that many of us had not used before. We weren’t sure how to pair a developer with a tester. We thought it might be a good idea, and certainly we could see some benefits, but until we experimented and tested it out, we wouldn’t know. Training and coaching was an imperative part to helping testers grow from tester to test leader, a skill needed if they were to successfully adjust and embed themselves into the teams. We’ve explored many different ways to coach. We’ve worked out that for coaching to work it needs to be initiated by the tester. That means its optional to anyone who wants it. We’ve also worked out that a lot of the coaching is better performed with both tester and developer. Rarely does a tester work in isolation, so it makes sense for the tester and the developer to both understand the testing concepts. The coaching is experimental in nature, typically focused on a task pertinent to both tester and developer. The style is Socratic to encourage participants to reason through the exercise, making the learning their own. There’s often a facilitated discussion after the task, helping to deepen any learning and also allow for explorations of ideas and concepts. It’s this type of coaching that adds real benefit to how a tester is able to conduct themselves within a team. ## Software Testing Strategy It’s not what the testers do that matters so much as their mindset. Our testers don’t sit passively waiting to be told how and what to test. Instead, they provide input into the team from inception to release, making decisions along with the team on all aspects of testing. They are part of the team, and are treated as such. They give input on testing at planning meetings, while pairing with developers, at daily stand ups and retrospectives. Each cross functional team is its own microcosm and consequently how testing is performed in each team differs slightly. The testers skill set varies too. More and more we’re seeing testers pair with developers, providing input into potential tests. But it’s not always the case. We’ve had testers focus on working closely with our business teams, helping them work through and create business process. We work to maintain close ties to the business so we can listen out for challenges they’re facing and feed that back into engineering teams. What is consistent is that testers needs to be confident and self assured. They need to be able to know when to stand their ground but also when to let go. It’s this nuanced approach and understanding of team dynamics, along with great testing ability that in my opinion differentiates a test leader from a tester. ## Agency in Software Testing We hire testers giving them the autonomy to make any testing decisions they need. Most testers discover that involving the team in this decision making is a lot more powerful than making decisions in isolation. Decision making can be a difficult process when the consequences of the decision have a big impact. Knowing what to consider, and the impact of the decision are two ways a coach can help a tester in this process. One more thing. The result of allowing people to make decisions is that sometimes they will not make the ones you agree with. Any test leader will need to live with that. Decision making is a skill acquired through good and poor decision making. If you allow people to make decisions and then penalise them for poor decision making, the result you will get is disenfranchised testers or worse, testers unwilling to declare their interest in the decision making process. ## Increasing Software Testing Skill We’ve extended training on testing from a pure tester activity to one available to engineering. That means cross functional teams have training and coaching on testing available to them. Training on testing is extended to the whole team so that everyone can participate and discuss testing. At inception, we have test engineers asking questions that prompt further discussion with the business. We help clarify and identify assumptions in stories making them easier to test down the path. Another way is to improve testability. Testability is how easy (or hard) software is to test. One of my favourite questions during planning meetings is ‘how will we test this’? More and more it’s the team that’s working together to improve testing. For example, load testing credit card terminals can be a painstaking process. Often its the test engineer that ends up swiping a credit card again and again in the attempt to load the system. It’s a repetitive task, and pretty ineffective as a solution. The test engineer brought the problem to her team. An innovative solution was developed where credit cards where hooked to a model train, allowing the process to be automated. ## Continuous Delivery & Software Testing We’re still in discovery mode with continuous delivery. We know that Continuous Delivery is going to have a huge impact on how we test but we’re still working out what this will look like. Fortunately, being a tech company we understand the importance of investing in the right infrastructure to support continuous delivery. Being a bank, our risk profile means we want to fully investigate and understand the implications these new concepts have on banking. There’s not a lot of case studies on CD in a banking context! To fully understand the risk, we plan to work with both developers and operations, and to adopt an iterative approach, conducting low risk experiments to understand the impact. We know we will need to test early and often and in production like test environments. We’ve already taken steps in that direction with teams owning production like test environments for testing prior to cutting a release. We working on building an immutable infrastructure, so how we conduct performance testing and exploratory testing in that context is undecided, but options include flags and feature switches to facilitate testing in production, parallel environments for performance testing, the use of synthetics and of course extensive monitoring in production. Another area under consideration is the test data we use. Having ready access to controlled test data is going to play a big part in how effective our testing will be. This test data will need to be diverse in nature to hit lots of different business scenarios, but it also must be relevant to our customers. Understanding how our customers behave through production monitoring tools will play a large part in determining what data is required. But this is only one point in time. In the future, the challenges that Tyro Payments and its team will face will change. Newer technologies such as AI become more prevalent in how we develop and test software. New ways to develop software will emerge, and we will shake our heads as we think of how we used to test in the bad old agile days. Test Leadership has no easy algorithm or set of rules to follow that will ensure success. Being passionate about your vision helps of course, as does courage, when you face inevitable opposition. Empathy, can go a long way to understanding other’s perspectives. Test Leadership is not for everyone but the reality is that for the majority of us working in technology, our biggest certainty is uncertainty. Test Leadership may just help us prepare and perhaps even embrace this future. Postnote: The quality strategy has evolved since this article (originally written for [INFOQ](https://www.infoq.com/articles/test-management-revisited/?ref=annemariecharrett.com)) was written. *I’d like to thank, Andrei Charrett, Lauren Allen, Fiona Charles and Ben Linders for offering valuable feedback on this article.* [Test Leadership is here to stayIn his article “What leaders do”, J.P Kotter makes the following distinction between management and leadership: Managers promote stability, leaders press for change For example: Management involves planning and budgeting. Leadership involves setting direction. Management involves orga…![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/09/dashboard-768x362-1-2.jpg)](https://mavericktester.com/2017/03/07/test-leadership-not-test-management/?ref=annemariecharrett.com) ### Starting Something URL: https://www.annemariecharrett.com/starting-something/ Last updated: 2021-06-22T03:54:56.000Z Your first child. Like many parents, I vividly recall my moment of reality when I realised my life (in a weird and wonderful way) would never be the same again. ![baby shower](https://charrett.ghost.io/content/images/wordpress/2020/01/baby-1024x498.jpg) Being pregnant with my first child now feels like a time of great excitement and also great indulgence. Baby showers, afternoon naps, discussing possible names, pre-natal classes, books on pregnancies and child rearing and yes, obligatory yoga. Lots of advice such as “get the rest while you can, you’ll need it” followed a knowing smirk or laugh. I would indulgently laugh too, for the truth was I had absolutely no idea what I was getting myself into. When my first child was born after a difficult and complicated delivery, I was delighted to discover that breastfeeding for me was pretty uncomplicated. The nurse came in and helped my gorgeous little boy latch on. Once feeding was complete, I snuggled down into bed, content that I could tick the accomplishment of breastfeeding off my list of things “a mother”does. ![](https://charrett.ghost.io/content/images/wordpress/2020/01/shower-1-scaled-e1578346345172-1024x587.jpg) Rest was short lived. Less than 2 hours later, I was woken up to repeat the exercise. Reality set in. I would need to repeat breastfeeding again, and again and again….A full night’s sleep was not on the cards for a long long time. In fact, my life was now devoted to feeding and protecting this little boy. It’s hard to describe that moment. It’s been best described to me as joyless love. A complex contradiction where your heart is going to burst with love, and yet your mourning your life as an individual that will never be the same. (I was diagnosed with Post Natal Depression a little later…) I often feel there are similarities to coaching & raising children. As parents it’s on us to create a space for where our children can grow and thrive. A place where they can question themselves, others and the world around them. A place where they can safely push boundaries, learn consequence and build resilience. And like giving birth, sometimes in coaching we will never be fully prepared on what is ahead of us. No matter how many books, stories, advice, processes and structure we put in place, the process of coaching is ultimately one of discovery both for the coach and those being coached. We learn what we need to coach on, by coaching. This is especially true when there’s a lot of uncertainty and change around. That’s not to say we can’t prepare or that we can’t get help. Preparation and groundwork in setting expectations can be vital. Having someone to coach/mentor you through initial days can make the difference between a successful quality coaching initiative and a failed one. Mostly in tech though, it’s through starting and doing something that we begin to understand and learn. Yes, at some point you may stuff up. I have stuffed up many a time, and sometimes that’s been really hard to handle. Have a mindset that you don’t have all the answers, and it’s ok to not have all the answers. Ask those around you for their input. Above all, be open to learning and discovery. A great example of someone with this mentality is Elisabeth (Lisi) Hocke who pairs with people all over the world to learn. If you can encourage that within yourself and in those around you, you may just find that the answer of ‘where to start’ lies within. P.S My two boys are now 17 and 18\. They are intelligent, articulate, compassionate and positive young men. They are huge source of pride to me. ![charrett](https://charrett.ghost.io/content/images/wordpress/2020/01/xmasday-1024x768.jpg) [13 Low Cost Ideas to start Quality Coaching right away!\*The good news is that where to start begins by getting the team’s input on quality. A quality coach first looks to better understand a team![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/12/beginatthebeginning-2.jpeg)](https://annemariecharrett.com/13-low-cost-ideas-to-start-quality-coaching-right-away/?ref=annemariecharrett.com) ### The Gratitude Jar URL: https://www.annemariecharrett.com/the-gratitude-jar/ Last updated: 2021-06-20T23:54:52.000Z 2019 has been an eventful year for many and the start of a new year is a great opportunity to say throw a slip into a [gratitude jar](https://josierobinson.com/journal/how-to-use-a-gratitude-jar?ref=annemariecharrett.com) to thank to those around you who have supported you in some way. Being the blog author 🙂 I get to write the last gratitude slip. Firstly, my husband and family. Without their support I wouldn’t be able to achieve what I have done which involves co-founding my second business, spoken across 3 continents, 7 countries and even more cities. To my business partner Deepika Loganathan, who is a positive inspiration in my life. To Amrith Shetty, Sahar Khoshraveshan, Trish Khoo and Adrian Chirion, some of our consultants who have worked for us this year do such a wonderful job of being ambassadors to Testing Times. To Madeleine, my sister and bookkeeper who has been through the year from hell, and still keeps my books up to date! To Owen Senior and Divya Konnur who consistently encourage me to write my quality coach book. (Soon folks!) Anne Colder for facilitating my two day quality coach tutorial at short notice, and for her Verdwondering exercise! [Margaret Dineen](https://www.linkedin.com/in/margaret-dineen-a165ba1/?ref=annemariecharrett.com) for co-hosting [quality coach roadshow](https://podcasts.apple.com/us/podcast/quality-coaching-roadshow/id1490494048?uo=4&ref=annemariecharrett.com) with me (next show out in a couple of days!) There’s a heap of others of course, Phil Jostsons, Catherine Karena, David Greenlees, Arushee Aggarwal and Jost Stollmann to name a few. Finally, I can’t go past saying a big thank you to the conferences that have invited me to speak this year. Australia is far away and it requires special dedication to invite me over. Thank you, European Testing Conference, UKSTAR, CAST2019, Agile Automation Days, and Agile Testing Days. Below is a list of women from the women in testing slack channel who wanted to say thanks. What can I say? These wonderful women make community. #### Rachael Kibler Three people! I’m grateful to Maaret Pyhäjärvi for taking a chance on me with the keynote for Agile Testing Days USA and giving lots of feedback in the lead up to it. I’m grateful to Lisa Crispin for pairing with me on a workshop, and all that goes along with it. She is a great cheerleader and partner.And I’m grateful to Amy Richards for being an amazing person this year. She helped me navigate new roles and uncertainty at work, always being kind. #### Areti Panou I am grateful to Anne-Marie Charrett and Lisa Crispin for encouraging me with their kind words and promoting my work. Their contagious enthusiasm for learning and helping is something I really look up to. My special thanks go to Ard Kramer who gave me thorough and thoughtful feedback on my conference proposal, giving me the confidence to submit it. #### Alex Schladebeck I’m grateful to and Gitte Klitgaard for only ever being a telephone call away. To Elizabeth Zagroba for visiting me twice and being a wine-whatsapper. To my awesome team of test consultants and developers. And most of all to this whole slack channel. You are my secret sauce, my cheerleaders and most of my brain xxxx . Forgot to mention Abby Bangser for helping me with observability and Janet Gregory for always writing and checking in. #### Varun Srivastava I am forever grateful to Maaret Pyhäjärvi. You are a feedback fairy. Thanks for all your feedback!! I am thankful to all European Testing conference awesome organizers. You all rock ladies. I have learnt a lot from you folks in past months. And yes Wit slack channel you all are my go to person for any queries!! #### Marit van Dijk I am grateful for Maaret Pyhäjärvi for shining her light on people’s awesomeness and making them show the best version of themselves, including me. I am grateful that I got to travel to different countries and share my experiences with others, amd get to continue to do so next year. I am grateful for Angie Jones who is a constant source of inspiration and a super nice person. I am grateful for Lisa Crispin who doesn’t know how much of an awesome role model she is to the rest of us. I’m grateful to Jasmine Vyas or coming to Swansea with me to do a workshop on software quality. I am grateful to have found this amazing supportive community and all of you in it. I love getting to know all of you better and how we support each other and cheer each other on. #### Arlene Andrews I am grateful to all of you: I can’t call out the number of times I have smiled, cried, learned, taught, or simply “felt home” here. #### Trish Khoo I’m grateful to Catherine Karena who helped me out through some of my hardest times this year. Thank you. #### Lisa Crispin Gosh, I don’t even know where to start! +1 on everyone mentioned so far. Deeply grateful to all you many friends here who support me and make WiT Slack my security blanket and source of energy and inspiration (and to Anne-Marie Charrett & Ale Moreira for starting this Slack? I think it was y’all?) Eternally grateful to Janet for so many things including getting our new book out (with contributions and help from some of you). All of you who have paired with me, both for conferences and helping me learn… Special gratitude to the people who have the courage to share their personal stories so the rest of us can learn to be nicer to ourselves and others. Gitte Klitgaard, Ashley Hunsberger, Alex Schladebeck, Selena Delesie many others, and not to leave out men – Stephan Kamper’s ATD keynote had a big impact on me also, as did Kevin Harris’s, and men like Dan Billings who aren’t afraid to show vulnerability. Thanks to Elizabeth Zagroba, I am taking a longer break right now than I would have otherwise – and I really need it! I would name just about everyone here if I stated naming names – thank you all! #### Trisha Chetani I wanted to take the opportunity and thank to **tech voices** for the support and i also wanted to say thanks Mirjana Kolarov for pairing up with me and giving her time and even WIT slack channel : it a great place to be in and learn from others and get the support and suggestion based on people availability . I appreciate the support from all the testers and the testing community. I’m grateful to Maaret Pyhäjärvi for taking a chance on me with the keynote for Agile Testing Days USA and giving lots of feedback in the lead up to it. I’m grateful to Lisa Crispin for pairing with me on a workshop, and all that goes along with it. She is a great cheerleader and partner.And I’m grateful to Amy Richards for being an amazing person this year. She helped me navigate new roles and uncertainty at work, always being kind. #### Bhavani I’m grateful to Lisa Crispin who has helped me and took time to review my blog posts and publishing & promoting those. I ‘m grateful to Angie Jones for taking time to contribute back to the community #### Emna Ayadi Also, I appreciate the idea of this video within the agile french community done by people involved in the community. [https://www.linkedin.com/posts/jupaquet\_communaut%C3%A9-agile-bonne-ann%C3%A9e-la-minute-activity-6615135187212746752-QK5D](https://www.linkedin.com/posts/jupaquet%5Fcommunaut%C3%A9-agile-bonne-ann%C3%A9e-la-minute-activity-6615135187212746752-QK5D?ref=annemariecharrett.com) I’m thankful to everyone here, WIT slack is becoming my source of inspiration and motivation from technical things to personal things as we have channels for everything ! Special thanks to Areti Panour that make me discover this channel months ago Also I would like to thank women that I met this year Varuna Srivastava at QS TAG conference in Frankfurt and Nishi Grover Garg my best conference friend at Targeting Quality conference in Cambridge. Keep rocking all testers in this community wish you all the best and hope to meet you all next year Hey! I am super grateful for the opportunities I had this year that led me to meet many wonderful people. Found a sweet friend in Emna Ayadi at TQ2019 Canada, chatted with Maaret Pyhäjärvi about many conference talk ideas and got insightful words of advice, found so much to learn here in WIT slack group! And now, I am looking forward to meeting the awesome likes of Jenny Bramble, Lisa Crispin, Heather Reid and Hilary Weaver-Robb next year at TestBash Detroit! It has been a good year and wish for an even greater 2020!! #### Nishi Grover Garg 2019 was a year of change, acceptance and taking big leaps. When taking charge is no longer an option, you just gotta march ahead! I marched ahead in adversity to get out of a rut, got a new job that I am thankful for! Lisi Hocke brought me smiles and Lisa Crispin was super kind to share her feedback on my talk proposals. I took my blog forward, wrote a bunch, learnt many new skills including creating tutorial videos, and most importantly, spoke at my first international conference! May 2020 bring us greater things, more smiles, contentment & whatever our hearts yearn for the most!! #### Jenny Bramble I’m grateful for Ashley Hunsberger who opened up some neat opportunities for me in 2020\. And for Arlene Andrews and her relentless positivity, even when she’s down. For Jenna Charlton and her strength of character and amazing technical knowledge that she’s so willing to share.Gitte Klitgaard and her beautiful spirit+hilarious outlook. Angela Riggs, for being a great conference buddy. Trish Khoo and her amazing ability to put things into words. Also the adventures of Brother and Eli. And really, just everyone in here because you’re all so powerful and unique and interesting. A patchwork quilt of the testing community. #### Jasmine Vyas A bit late but I am thankful to Marit Van Dijk for helping me a lot with public speaking and giving me a chance to do the workshop with her at SwanseaCon this year ! I am also grateful to Maryam Umar for the lovely tiny interaction we had at European Women In Tech this year ! And lastly, grateful to all the lovely souls here on this workspace for all they do. #### Jenna B Charlton I am grateful to this entire community. Without you all I would still wonder if I was the only one who felt the way I do and if I really belong in this industry. Lisa Crispin I am grateful for how warm and kind you are and how you are willing to be vulnerable. I think I probably speak for a lot of us here in saying that you are a role model for me and I have looked up to you for years, and seeing you be so honest and open has helped me feel less alone. Gitte Klitgaard you have such a fun spirit and help everyone feel included! Jenny Bramble, I am so grateful for your friendship and every time we get the chance to see each other we pick up right where we left off the last time. I feel like I’ve known you forever. You’re authenticity inspired me to be fully authentic when I speak. Angela Riggs, getting to know you has been a blast! You are so much fun and I can’t wait to get to know you better. Parveen, you are a treasure. I feel bad that we haven’t gotten much chance to spend time together, but just the little we have I can tell you have a beautiful heart that is a blessing to those around you. Hilary Weaver-Robb I think you are just the bees knees and you’re support has meant the world to me! I’m keeping you and your family in my thoughts and the way you continue to give to the community even with everything going on is inspiring. #### Parveen I am thankful and grateful to this entire community and Women In Tesing slack. I dint knew anyone or had no clue about this whole wonderful world and wonderful people in this community. Thank you Tech Voices(Speakeasy) for helping me to be part of this community. A huge thank you to Abby Bangser for making my dream come true by connecting me to Angie Jones as my mentor. I am so grateful to you for all the support and help throughout to help me find my voice Angie Jones. Thank you for believing in me and helping me to believe in myself. You were always there for me during my tough time. Thank you for continuous inspiration, you are my role model. Actually you showed me the door to this community and to this part of the world. Im grateful and thankful to Maaret Pyhäjärvi who has helped me and believed me and constantly supported me by providing feedback, mentoring and pairing. I am so lucky, grateful and thankful to Lisa Crispin who is so amazing and kind person who was always there to help and support whenever I needed. I am so grateful and thankful to Lisi Hocke for all her inspiration and for amazing pairing conversations. Thank you Trisha Chetani for being so kind and helpful. I never came across someone like you who is so dedicated in helping someone. Jenna Charlton, thank you for being so kind and amazing. Im thankful and grateful to Smita Mishra for being so kind and helpful. Im super thankful and grateful to Cassandra Leung who has inspired me to do something brave which I have never thought I would be able to do it. Im sure I have missed some more amazing people whom Im grateful and thankful to. This year has been very very special to me and it could not have been so special without you all wonderful communities help, support, inspiration and motivation. Thank you all. #### Elisabeth (Lisi) Hocke I am grateful for Anne-Marie Charrett triggering this wonderful initiative! Also: thank you for all your amazing work in the quality world, I value your inspiration more and more every day.Thinking back on the last year, I am truly grateful for the support and encouragement of so many people. Way too many to list them all! I received a lot of support and I can only hope to pay it forward. Here are those people I am especially grateful for when thinking back on the last year.Toyer Mamoojee, my learning partner through thick and thin. We came so far together, it’s really incredible. Thank you for always being there and having a sympathetic ear for me! Your advice and support is invaluable to me. I am even more grateful to have a whole power learning group around us! Many thanks to all those wonderful people.I am very grateful for all those people who reached out to me when I was at my lowest point this year. Many thanks to Toyer Mamoojee, João Proença, Thomas Rinke, Kristīne Corbus, Alex Schladebeck, Simon Berner, Lennart Fridén, and more.Lisa Crispin and Janet Gregory for so much inspiration throughout the years! You are real role models, thank you so much for all you’re giving to the community – your knowledge and your kindness, your experience and your support. We can only hope to become more like you.Patrick Prill for bringing all my talks to a whole new level. Thank you so much for your continuing, constructive and kind feedback – this in addition to your support and encouragement is invaluable to me. I can only hope to pay it forward! Angie Jones, Thomas Rinke, Maaret Pyhäjärvi, Mark Winteringham, José Díaz, Woody Zuill for granting me great opportunities this year and endorsing me publicly. So much appreciated and not taken for granted!All those people who paired with me this year – thank you so so much for sharing your knowledge and experience, helping me grow. I can only hope I could give something back, or pay it forward to other people I pair with.I am super grateful for all those people who spread word around pairing up remotely – like when going on a testing tour. Many thanks especially to Gem Hill and Parveen Khan here!Leandro Leites Barrios for being a great colleague to work with, for being a strong voice advocating for quality and testing even when not identifying as tester yourself, and for promoting my achievements both inside and outside the company. Thank you so much.Anne Colder and Vincent Wijnen for giving me both hope and strength again. On the one hand by giving great advice on how to step up as an ally (many thanks to Thomas Rinke here as well, leading by example!), and on the other hand by showing me how to enjoy my passion again. Thank you so much for our wonderful conversation all around computer games, you cannot even imagine how much energy and joy this gave me back and how much this helped to take better care of myself! #### Abby Bangser It is crazy how much trying to write out specific gratitudes stresses me out! But lemme try…The thing career topic that stands out this year the most for me is gaining experience and confidence with observability via a new job and new conference experiences.This all kicks off because 2 years ago Charity Majors gave this random Londoner the time of day and has since then been a teacher, coach, and cheerleader. I can’t even begin to express gratitude there. From there I am grateful for Melissa (the Tester), Vernon Richards, Lisa Crispin, Martin Hynie, Ben Kelly and Rob Meaney for helping solidify my ideas in endless chats and seemingly ALWAYS sharing and engaging with my posts on Twitter.To Benny and Jon for going on the wild ride of creating a workshop and delivering it *after* we had selected conferences to attend. And speaking of that workshop, Areti Panour and Lisi Hocke, thank you for being the worlds best first attendees (and Anne-Marie Charrett as a future collaborator) by giving us ways to improve and confidence to take it forward.The year is so much more than just observability, but to encompass all of that is just too hard, so I will leave my post here knowing that all of this is rooted in my gratitude for the wider community to be open to new ideas and supportive of every individual to take them forward. #### Janet Gregory Thanks Anne-Marie Charrett for making me think about who and what I am grateful for this year. Mostly this year, there are many little things. Nothing huge or major. Those little things almost pass you by without noticing. Sometimes they are a comment by Gitte Klitgaard here or on twitter that makes me think about being kind more often. Sometimes it’s a chat with one of my mentees that makes me consider how I can express ideas better. Sometimes it’s listening to a talk by someone – for example Elizabeth Zagroba about how we can improve our own skills to make me stop and think. Sometimes it’s by watching someone like Lisa Crispin struggle with trying something but continue to work at it and not giving up. Sometimes it’s listening to people like Alex Schladebeck with such a zest for life which gives me encouragement to live my own life with that same zest. As I get older (and feel that age), I am grateful for the many women around me like Fiona Charles or Isabel Evans that continue to share their ideas and inspire me to do the same. So many little things. So many great people. #### Lena Wiberg I am grateful for Trish Khoo for doing illustrations for my cards, for Lisa Crispin for pairing with me, for myself for daring to do the owasp-workshop without Tomas, for Smita Mishra for always making me feel important when we meet, for Ashley Hunsberger for our great chats, making me feel appreciated and for Gitte Klitgaard for pairing with me on leadership and simply being a wonderful friend 🙂 2019 was a great year. Oh and I’m proud of myself for seeing I needed to slow down. #### Kristine Corbus This was great year for me. Big changes in my family: the youngest started to go to school, biggest became an adolescent, I was a LOT away. Accordingly my biggest gratitude goes to my husband. I am so grateful to have him! We built this family, we follow each our personal dreams (without help from a side) and still manage to be a loving couple.Professionally the biggest move this year was my decision to quit my volunteer activities. Over years I supported so many, that I forgot to take care of myself. I am deeply grateful to people who supported me on my way to make this decision. #### Angela Riggs Gratitude for this community, where it’s okay to be vulnerable and proud, where we can vent and support and celebrate ourselves and each other. #### Mel the Tester So I wrote a blog post instead because I had too many words and didn’t want to spam up this chat. Many thanks to everyone! [Mel’s Gratitude Jar](https://testingandmoviesandstuff.blogspot.com/2019/12/the-gratitude-jar.html?ref=annemariecharrett.com) Many thanks to you all for taking the time out to contribute to the gratitude jar. How about you? Do you have a slip you want to add to the gratitude jar? Feel free to use comments to add. Happy 2020! ### 2020: The year of dumping old heuristics URL: https://www.annemariecharrett.com/heuristics-sfdipot/ Last updated: 2021-06-18T11:36:29.000Z When software testing, it’s handy to use mnemonics/heuristics to refer to. They can be useful as generators of test ideas, or reminders to test in a particular way, or to consider some aspect. What’s a heuristic? Think of a heuristic as a rule of thumb that helps you make a decision about a problem you’re trying to solve. How do we get to the fireworks for New Years Eve? Rule of thumb says its easier to take public transport. But that’s not always the case. Maybe with 10 small children, its safer to go by taxi-bus. Heuristics are great for one you need to make a decision where there’s a whole lot of uncertainty and complexity and you don’t have all the time you want. It stands to reason that the software testing community has been using heuristics since the previous century. In an software engineering profession where complexity and uncertainty rules, they have become a tester’s best friend. Heuristics help simplify decision-making by providing patterns that can be useful in some situations, some times. Notice how I put a whole load of provisos in that sentence? That’s because its useful to treat heuristics with a certain amount of disrespect. Heuristics can’t be applied like a checklist, something you diligently tick off like your shopping list at the supermarket. Think instead of a laundry list\*, only tick the ones you absolutely need because it’s so damn bloody expensive to get clothes cleaned at a hotel. I mean, sure who wouldn’t love their underpants ironed and pressed, but do you really need it? Heuristics can be amazing tools but they can also stop you thinking about other options. Many, many testers are familiar with the San Francisco DePOT heuristic. SFIDPOT\*\* is a mnemonic to describe a set of heuristics to identify product coverage. But here’s the thing. SFDIPOT is not necessarily useful for testing stories because it explores at wrong level of abstraction. Stories are not products, so trying to apply that type of coverage to a slice of a product can prove to be an ineffective method of identifying valuable story coverage. When I work on testing a story, I like to break it down as much as possible. Think of a typical story structure…As I want to do so that I can . To break that down I use the following questions: ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/12/Screen-Shot-2019-12-31-at-6.41.25-pm-1024x470.png) Heuristics for Testing a Story Heuristics can be really useful to us in testing. Sometimes they help us think of new ways to test, prompting us to ask new questions about the story (or the product) and the context in which we’re testing. But they can also bias us, channelling our ideas about testing into narrow ruts that over time make it hard to know any other route. Here’s some questions to ask yourself that may prevent those soft malleable laundry lists to becoming hard concrete checklists: - Ask yourself what has changed outside my frame of reference and how might that impact me and my testing? - Ask yourself, given a difference in context, what ideology could I retire? - Ask others testing (technical and/or product) what they think are good patterns to investigate - Ask team members what product wise concerns them the most - Ask team members what’s stopping them from doing their work optimally? - Ask your head of engineering what information would they ideally like to have? - Ask operations what’s keeping them up at night (literally) I find that there are consistent themes in quality that most companies wish to adopt and retain. For example, we want products that do what they are supposed to do. We want websites that perform under heavy than usual load. Increasingly we want other quality attributes that are becoming essential to contemporary engineering practises. Security is key. Speed to Market is key. Smaller & key. Adopting newer technologies to mitigate risk is key. Sometimes, just sometimes, we in software testing love to challenge others in software engineering about handling uncertainty and complexity, but our own behavior fails to reflect that. How about in 2020 we ask ourselves this question? What ideas from people outside of software testing might I learn about and might be worthwhile embracing? I feel if we can embrace this ideology, then we will bring so much value an benefit into our lovely community. Anyway, that’s it for 2019, I’m off to celebrate the fireworks. Happy New Year! \*Laundry Lists is an idea I got from Gerry Weinberg \*\* SFDIPOT comes from work by James Bach and some others I believe, I tried finding it on the satisfice website but no joy. If someone has a link to the original link, please let me know. Like this post? Here’s a couple of others you may want to read; [The ‘Do Nothing’ heuristicSometimes the thought of making ‘big’ decisions gives us that ‘rabbit in the headlights’ look. ‘Big’ decisions often have outcome can have a significant impact to either ourselves or our company. Lack of information can make these decisions harder to make. …![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2018/11/9984767934_6f14382d86_c-2.jpg)](https://annemariecharrett.com/do-nothing-heuristic/?ref=annemariecharrett.com) [Indulge the HunchHave you ever been in a new city or town and been tempted to take a shortcut that you don’t know will actually be short? A hunch tells you it will be quicker. What do you do? Will you take the risk and go with your gut? Or,![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2019/08/valencia-2.jpg)](https://annemariecharrett.com/hunches-in-exploratory-testing/?ref=annemariecharrett.com) [Sustainable software testingIts time to expand our traditional view of a software testing scope and to start including the word sustainability into software testing. Up to this point, areas of focus have been functionality, performance, maintainability, security, usability etc. As customers become energy conscious, a focus on …![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://annemariecharrett.com/sustainable-software-testing/?ref=annemariecharrett.com) ### 13 Low Cost Ideas to start Quality Coaching right away!* URL: https://www.annemariecharrett.com/13-low-cost-ideas-to-start-quality-coaching-right-away/ Last updated: 2023-09-27T22:15:11.000Z The idea of being a Quality Coach or starting a Quality Coach program can seem overwhelming. Where do you actually start? You might get advice like the one above from the King in Alice in Wonderland gave which can seem profound, but in concrete terms, not very helpful! The scope of quality can appear never-ending, and is highly subjective, making it a topic difficult to discuss and understand fully. Quality also keeps changing, making it hard to know if we are heading in the right direction and if we have it. There’s the added complexity of gaining suitable support in terms of time and budget. Worse, failing to get ‘it right’ can lead to future lack of support setting you backwards not forwards. It’s enough to for anyone to catch a dose of analysis paralysis! There’s good news! Firstly, **it’s not up to only you** to decide where to start, that decision belongs to the team. > *For quality to be a team responsibility, the decision where to start is the teams, not only the quality coaches.* Anne-Marie Charrett Instead, your role at this point, is to generate and facilitate this discussion in a way that helps focus the team. Secondly, sometimes it doesn’t matter where you start, it’s the act of starting. Making this kickoff low cost, means the impact of say pushback is minimised. Plus, the upside is hugely valuable. You begin to learn more about your team, what they value and their concerns. Even the act of pushback is a valuable objection to collect. Conversations like the above can be sufficient to generate and point to potential next steps and act as a guide to what your team is passionate about. > *Want ways to motivate your team about quality? Focus on something they’re interested in!* Author Below are 13 low cost ideas aimed at generating discussion on quality or a related topic. The ideas is to get a better understanding of the state of quality and people’s perception of that. By gathering and sharing this information with your team it may help your team (yes, its not only your decision!) to decide where to start. - Plan a Lean Coffee on Quality/Testing/Infrastructure/SpeedToMarket/ - Pair with a developer/Product Owner - Research and Analyse bugs found - Start collecting data on something you don’t know about - Create a Whiteboard for Quality Improvement - Take someone out for coffee and chat about what bugs them - Ask to to be taught - Suggest the theme for a retro be Quality - Define Terms (Unit, Integration, System, API) - Create a survey for the team - Roles & Responsibilities Workshop on Quality Coach - Ask for personal feedback - Share a blog post on a topic around quality Do you have any low-cost ideas you have found worked for you? Please share! \* *This blog post is an extract of my Quality Coaching book.* [Reshaping Quality in Contemporary OrganisationsTo test well we need to rethink quality and how we can build quality in as opposed to testing for it at the end.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QEModelv3-2.jpg)](https://www.annemariecharrett.com/contemporary-quality-engineering) [Threats to QualityInstead of measuring quality - explore threats to quality and see if you can reduce these. Threats to quality are more than bugs![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/risk-2.png)](https://annemariecharrett.com/threats-to-quality/?ref=annemariecharrett.com) [Quality Engineering where Quality is an emergent propertyQuality Engineering manipulates parts of a complex system to build quality in. Focus on people, tooling, infrastructure, process & outcomes.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://images.unsplash.com/photo-1535231540604-72e8fbaf8cdb?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fGVtZXJnZXxlbnwwfHx8fDE2MjM3OTU4OTE&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/emergent-quality/) low-cost [Quality needs to be driven by business outcomesBusiness outcomes is what drives your quality engineering strategies. Find out what’s valued and work backwards to work out where to begin.![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/size/w256h256/2021/06/icon.png)Anne-Marie CharrettAnne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/RoadToNowherekeynote-2.jpg)](https://www.annemariecharrett.com/quality-engineering/) ### Indulge the Hunch URL: https://www.annemariecharrett.com/hunches-in-exploratory-testing/ Last updated: 2021-06-13T03:34:53.000Z Have you ever been in a new city or town and been tempted to take a shortcut that you don’t know will actually be short? A hunch tells you it will be quicker. What do you do? Will you take the risk and go with your gut? Or, will you stay on the same path, safe in the knowledge you will get there? It most likely depends on a lot of different factors, some dependent on what drives you, others on circumstances you find yourself in. I tend to take shortcuts because; 1. I want to find the optimal path and that might not be the one I am on 2. I want to increase my understanding of the city 3. I find it a fun challenge to explore new cities 4. The unknown is an opportunity for new learning 5. It improves my mental model of the city. 6. Instead of being told, I’m learning for myself 7. It’s fun to do things differently 8. I know it will probably turn out ok (I won’t die) 9. I have the time to be wrong 10. I’m not afraid of getting it wrong 11. I pride myself on being smart 12. I desire to find a better way 13. I’m aware that there are many paths to destinations and I’m not always on the optimal one 14. Not having a map is fun! (for me). 15. I might find a new cafe or art shop that is off the beaten track Of course, this is my list and I wouldn’t expect this is how everyone operates. Everyone’s different. I could chose not to explore, and instead use my smartphone to tell me where to go. But I enjoy relying on my hunches, it gives me confidence and the added bonus of understanding the city. Shortcuts can be a gamble, especially when your time constrained. And what if you end up in a dead end? There are times when acting on your hunches can cost you a missing train, or having to use your terrible spanish to ask for directions, but as a method of better understanding the city and discovering that amazing coffee shop? Priceless. For exploration and learning, gambling on your hunches can pay off very nicely. ### Hunches in Exploratory Testing There is a moment in Exploratory Testing (ET) when you come to a full stop. Mostly, it’s because you are stuck. You simply don’t know what to do next. That moment can happen anytime. It can happens before you begin exploratory testing and you don’t know where to start. It can happen when you run out of testing ideas and your testing comes to a grinding stop. The desert of no ideas is a compelling reason to stop and stamp the exploration as done but it comes with a tradeoff. A critical bug, may just be about to reveal itself before you stopped your testing. What can you do though? Creativity isn’t a tap that you can turn on at will. And once you’re in that boredom rut, its difficult to extract yourself from it. So, how can we prevent ourselves from giving up too quickly? The good news is that Exploratory Testing is a skilled activity. As our skills develop, we begin to identify and work through these tricky periods. And so, instead of giving up, we maintain momentum, perhaps discovering interesting bugs that we may never have revealed themselves. But what drives continued exploration over giving up? What drives one tester to continue exploration while the other stamps the exploration as complete? Experience plays a big part. A seasoned Exploratory Tester knows from experience that pushing through, and changing tactics often provides dividends. But what about exploratory testers who don’t have the experience, are they simply blundering through the system and happening on bugs? How do they discover bugs? Could it be that exploratory testers rely on hunches to drive their testing? For instance, an exploratory tester has a hunch that a bug exists outside a boundary. Until they test they won’t know, but they trust their gut instinct. ### Hunch Makers and Hunch Breakers It stands to reason then, that we want to create conditions when performing our exploratory testing where hunches can be easily generated and can thrive. This will help us work through the times we lose our way while testing. Here are my top hunch breakers and hunch makers, the elements that break or make a healthy hunch. #### Sense of Purpose It helps to have purpose when exploratory testing. Making it your mission to find the most unusual bug that leaves people wondering how you ever came up with the idea of testing for that! #### Sense of Learning Creating a mental model of what you are testing, and building on that model through exploration is what helps generate new test ideas. Provide an environment which encourages learning new things especially in your testing. #### Open to being wrong You can’t explore without a few dead ends. Sometimes you are not going to find any bugs. Have the long view. The end goal of exploratory testing is rich mental model of the system, the bugs are simply one element of that. #### Indulge the Hunch Knowing there is never one path to the end goal opens up opportunities to explore. There are multiple dimensions to our systems simply craving for exploration. The paths are there, are you willing to explore them? Indulge your hunches, feed them plenty of attention and encouragement and before you know it, all those options will begin to open up before you. #### Sense of Curiosity It’s hard to create an environment that indulges curiosity when you have a backlog thats a mile long, and time is scarce, but some things can help. Be systematic and disciplined outside your outside your exploration time will free your mind a bit more during exploration. When you perform exploratory testing, try and stay in the moment, giving yourself permission to fully enjoy the time. #### Sense of Adventure I love the adventure in exploration. It’s fun for me. I get that not everyone has the same sense of thrill in finding bugs. If exploring for nuggets of malfunction is really not your jam, that’s ok. I think it’s unfair and unrealistic for everyone to feel this way. Think of what drives your sense of adventure, and see if you can support exploratory testing using that. At the very least, let us have fun and respect we get a thrill out of our work! #### Confidence in my ability I know I don’t have to get it perfect. I’ve given myself permission to trust my hunches and not worry if they are right or wrong in finding a bug. No bug is simply additional information in my understanding of the system. Over time I’ve come to trust my ability. You will too. #### Time Of course I can’t end without mentioning time. The scarcity of time can make it hard to explore, but it can also make it fun. The thrill of finding something quickly through exploratory testing when exhaustive test automation would never have is always a nice dopamine hit. It’s all a matter of perspective… What about you? What conditions do you require that provoke a hunch or enable you to act on a hunch? Explore some more.. [Exploratory Testing - Anne-Marie Charrett (aka Maverick Tester)An engineer by trade, enjoys geeking out on new ideas and concepts. Say Hi!![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://www.annemariecharrett.com/tag/exploratory+testing/) [Courage in Exploratory TestingExploratory Testing takes software testing skill. It also requires the tester be courageous. Let me explain. Exploratory testing is an approach, not a technique. Exploratory Testing is simultaneous learning, design and execution. What information we learn about a product, helps dictate our tests pro…![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://mavericktester.com/2012/10/16/archive-courage-in-exploratory-testing/?ref=annemariecharrett.com) [Is document a dirty word in Exploratory Testing?I went on James Bach’s Rapid Software Testing (RST) course because some of the concepts and ideas that I had read about exploratory testing and RST appealed to me. I liked the idea that central to testing is a critical and context-driven approach and I also wanted to put![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://mavericktester.com/2008/06/27/archive-is-document-a-dirty-word-in-exploratory-testing/?ref=annemariecharrett.com) ### QA Career Development URL: https://www.annemariecharrett.com/qa-career-development/ Last updated: 2021-06-20T23:11:18.000Z We had the first Quality Engineering Lean Coffee and the following topics: - QA Career Development - How to assess quality practices and maturity of a team - How to attract people to get into a quality career - What can help testers when there is no BS or RS documentation - QA versus Dev Ratio (bottleneck) - How to manage expectations on testing team and cross functional team. The topic that most interested us and that we spent our majority of time discussing was QA career development. The main observations made were: - The role of Test Manager appears to be dead - Many QA’s and testers lean to the technical side as they can move into development - The role of Quality Coach doesn’t seem to have a ‘next level’ - It might be useful to focus on skill sets as opposed to a role (Buffer was cited as an example) - Don’t feel that you have to stay in Quality ‘roles’. There are many paths where you can have an impact on quality. - People have a tendency to put themselves into boxes based on their role. Encourage them to think ‘outside the box’ (I would add here, that also people tend to put testing and testing skills into a box, so be prepared to work on that too). What do you think? Have you worked in a company that has managed to successfully create a career path for Quality folks? I’d love to hear your stories? [Next Lean Coffee Session ](https://www.meetup.com/Quality-Engineering/events/258716338/?ref=annemariecharrett.com)will be on the 5th March 2019 and thanks to Fishburners for hosting at their event. The searchability website has lots of stories about what testers career paths [https://app.jobholler.com/blog/searchability-gabbi/talking-testing-with-anne-marie-charrett](https://app.jobholler.com/blog/searchability-gabbi/talking-testing-with-anne-marie-charrett?ref=annemariecharrett.com) [Four Stages of Testing CompetenceWhat stage of software testing competence are you? Unconscious Incompetence, Conscious Incompetence, Conscious Competence, Unconscious Competence![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://images.unsplash.com/photo-1613937167928-3923ee518faf?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDR8fGZvdXJ8ZW58MHx8fHwxNjIzOTgzNzg1&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/other/four-stages-of-testing-competence/) ### Options not Obligations URL: https://www.annemariecharrett.com/options-not-obligations/ Last updated: 2021-06-25T22:13:05.000Z ### tl;dr We want to provide our consumers and business partners options as opposed to obliging them by providing only one option. By “Designing in options” for your business partners and consumers, you provide them with the ability to take the greater risk while minimising the impact of failure for them. Feeling they have ‘nothing to lose’ (or at least the consequences are significantly lower) in taking a ‘riskier’ option, makes choices easier as opposed to being obliged to take the lower risk option. The concept is based on the work by Nassim Taleb and Kent Beck who have both explored the impact of providing options not obligations. I’ve taken it one step further by introducing optionality as a quality attribute. Optionality being something to ‘design in’ and intentionally removing/reduce the consequence of failure for the people who matter – your business and your consumers. ### nothing to lose Nassim Taleb wrote this [article](https://www.edge.org/conversation/nassim%5Fnicholas%5Ftaleb-understanding-is-a-poor-substitute-for-convexity-antifragility?ref=annemariecharrett.com) UNDERSTANDING IS A POOR SUBSTITUTE FOR CONVEXITY (ANTIFRAGILITY) (his capitals) in which he talks about the concepts of optionality in terms of technological and scientific experimentation. Here, he explains that successful scientific experiments and technological discovery are not through luck, or trial and error, but discoveries that have a great benefit if they succeed and little consequence if they fail. The “We have little to lose” heuristic familiar to many startups. It’s worth reading his article at least once (or for me at least 3 times 🙂 ). > Optionality allows …”, its user to get more upside than downside as he can select among the results what fits him and forget about the rest (he has the option, not the obligation)[Nassim Nicholas Taleb](https://www.edge.org/conversation/nassim%5Fnicholas%5Ftaleb-understanding-is-a-poor-substitute-for-convexity-antifragility?ref=annemariecharrett.com) ### design for optionality When we are dealing with complex systems and a high uncertainty we should aim for high optionality. One way to do this is to remove or reduce obligation for our business partners and consumers. Makes sense but how? ### agile is a form of optionality Compared to the waterfall process, agile is a high optionality approach. The option of providing feedback from small iterations minimise harm. The business is not obliged to take a final package at the end of 9 months, they have the option of providing feedback into the design and delivery process. Their obligation is reduced through delivering small amounts iteratively including feedback. ### optionality depends on context In his discussions on Explore, Expand and Extract, Kent Beck stresses that in the Explore section, where high uncertainty exists, we simply don’t know what experiments will provide the greatest payoff. In this context, the best we can do is perform multiple small experiments that are cheap to throw away. ![Kent Beck Explore Expand Extract](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/20181129_100455-1024x536.jpg) Kent Beck Explore Expand Extract For the Extract section, where uncertainty is reduced, it may be that a lesser degree of optionality is required. We know what our customer wants and the need for multiple options is required less. ### moving from low to high optionality Is this good enough though? Regardless of what stage we are in, we continue to have features that fail to deliver on the value hoped for. Why is that? And importantly what can we do to help increase the chance of success? When a product owner accepts a feature from development, they don’t know for sure if this feature will increase business revenue or not. It could be quite sometime before its value (or lack of) is discovered. The business partners have low optionality. They have two options available to them at this point, accept or reject. The feature may not be the one they want, but to reject it delays their ability to deploy and perform their own experiments on their consumers. Business partners feel obliged to accept the feature as to not do so will cause possible harm to business outcomes. ### ideal optionality In the ideal world, we want to provide our business partners with multiple options. In doing so, we’re reducing the harm to the business. We want to provide our business with a high degree of optionality. However, optionality requires a lot of careful thought and possible architectural support. We need a way to understand optionality. To do that we need to observe and measure how this optionality may be trending. Enter *optionality as a quality attribute*. Some thing to be considerd during design and architecture. We do this by asking the question: *“How can we provide our stakeholders with multiple options so they are not forced to take an option that will cause the business harm? “* ### examples of optionality Optionality is not new. We see this thinking in play already. For example, Google Webmaster has been providing me with the option to ‘switch’ to a new webmaster format. It provides me with the assurance that I can always switch back. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/Screen-Shot-2018-11-30-at-7.00.10-pm-1-1024x133.png) ![Google WebMaster New Version](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/Screen-Shot-2018-11-30-at-7.02.44-pm-1024x410.png) Another example of optionality is A/B Testing which provides two or more options on which feedback can be gathered enable the business stakeholder to chose the optimal design. Providing multiple wireframes at design is another example of high optionality. These are early ‘cheap’ bets with options that can be thrashed with minimum harm to the business Feature flags are a form of optionality in the architecture space. It provides a greater choice when deployment can occur, reducing obligation to go live on a fixed date. ### more ideas on optionality Our goal is to have our business partners to feeling comfortable rejecting options. This provides companies with greater optionality. So how we in development/architecture/product management assist them in that? Do you have an idea? Is your company increasing optionality in some way? Please tell me, I’d really like to hear your stories. *I’d like to thank Janet Gregory, Kent Beck and Rob Meany for proofing this blog post and providing feedback.* ### Threats to Quality URL: https://www.annemariecharrett.com/threats-to-quality/ Last updated: 2021-06-13T03:06:41.000Z If, as Gerry Weinberg states Quality is “value to some person” …then the corollary stands that risk is anything that threatens that value. This can be useful because Quality is an amorphous, shapeshifter, notoriously difficult to nail down. Its final judge is not us but our consumers. I compare quality to a **[Black Hole](https://science.nasa.gov/astrophysics/focus-areas/black-holes?ref=annemariecharrett.com)**. We can’t see it, we infer it exists through observing the impact on nearby matter. In the same vein, we don’t see quality, but we know it exists by how our consumers respond to it. Unlike black holes, we can influence product quality. We do this my focus on what prevents us from producing quality work. By identifying and removing anything that threatens to impact our ability to design, develop and deploy a quality product. One way to identify threats to quality is to ask yourself: “what is preventing me from getting meaningful work done?” The answer is likely to be a threat to quality. Frustrated by flaky tests? Poorly maintained test environments? No version control? In the context of [emergent quality](https://mavericktester.com/2018/12/04/emergent-quality/?ref=annemariecharrett.com), threats would be any practices, processes, technologies, and yes people, that prevent you from achieving the business goals, nested bets and outcomes set out by your team, CTO and/or company. Threats to quality are understandably seen as undesirable and often shoved under the carpet to get ‘real work’ done. Consider identifying and removing threats is part of the real work. It’s how we handle product quality when we no longer have full control of the product. We will always have threats to quality. How we make them visible and how we deal with them in a consistent and measured way may be the future of how we measure quality. [Emergent QualityIf you work in software development, like I do, you most likely work within a complex system. You also, most likely, work on a complex system. Not sure? Try answering these questions: Is it hard to model your system in all its complexity?Is it hard to work![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://www.annemariecharrett.com/emergent-quality/) [Contemporary Quality EngineeringSome randomish thoughts on quality engineering.  Quality engineering enables visualisation of the state of quality anytime in the delivery lifecycle of a system or service. It does so in terms of its business outcome.  Anne-Marie Charrett  (working definition) Services not Products&…![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/QEModelText-150x150-2.png)](https://www.annemariecharrett.com/contemporary-quality-engineering) [Quality is a journey - but do you know your destination?After any decent exposure to software testing, Jerry Weinberg’s definition of quality tends to gain traction and respect. That is “Quality is value to some person”. You like it because of its subjectivity. You may also hate it because of its subjectivity. Remember that bug repor…![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/RoadToNowherekeynote-2.jpg)](https://www.annemariecharrett.com/quality-engineering/) [When the rubber hits the roadAnyone who has attempted to create and then implement a strategy, will know there’s a big difference between what is intended when the strategy is written, and what is realised on implementing a strategy. To the point in software testing, there’s been a push away from![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/01/rubber-meets-road-2.jpg)](https://annemariecharrett.com/emergent-strategy/?ref=annemariecharrett.com) ### Emergent Quality URL: https://www.annemariecharrett.com/emergent-quality/ Last updated: 2025-01-29T20:23:27.000Z If you work in software development, like I do, you most likely work within a complex system. You also, most likely, work on a complex system. Not sure? Try answering these questions: 1. Is it hard to model your system in all its complexity? 2. Is it hard to work out root causes to identified problems? 3. Is it hard to predict how long work will take? If yes to any of these, the chances are, you’re working on a [complex system.](https://en.wikipedia.org/wiki/Complex%5Fsystem?ref=annemariecharrett.com) Complex systems display [emergent behaviour](https://en.wikipedia.org/wiki/Emergence?ref=annemariecharrett.com). An emergent system’s behaviour is created as a result of interactions of its parts. Marriage is an example of a complex system built on two independent complex systems contractually agreeing to become one system. Two persons coming together to form a new system creates a new set of emergent behaviours unique to either individual. Who knew? Bringing this back to quality. Why is it so hard to understand, define and measure quality? If we consider that even our [greatest intellectuals](https://en.wikipedia.org/wiki/Quality%5F%28business%29?ref=annemariecharrett.com) don’t agree on a definition of quality, then perhaps we don’t need to feel so bad about knowing what it is. My hypothesis is that quality is an emergent behaviour. It relies on a whole set of independent systems coming together to create this emergent property. We can never truly know what quality is. It’s constantly changing and morphing into different things. For sure, we can provide examples, but know quality itself? I’m not convinced. And perhaps we don’t need to know. Perhaps instead we focus on creating a space where quality naturally emerges. To do that it needs a collective framework where people, processes, infrastructure product and outcome working cohesively to create a space where quality emerges in a way we want it to. We manipulate quality by manipulating the parts that can impact final product quality. One example of manipulating a part might be psychological safety in a team. Research within [Google](https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/?ref=annemariecharrett.com) has identified psychological safety can have a major impact on team effectiveness. Experience of working with teams has shown me that how a team operates can have an important impact on the emergent quality of a product. There’s more to say on this, but this \*is\* meant to be a short blog post. ![Emergent Quality v3 charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QEModelv3-1.jpg) In summary, we should not forget the consumer in this equation. The consumer has the final say on what quality is (see Peter Drucker quote below). Understanding our consumer starts with better listening. Understanding our own bias that prevents us from listening properly. Consumer’s needs change as their desires and demands change. What worked yesterday, doesn’t necessarily work today. Let’s create an environment that foster’s understanding and willingness to walk with our consumers, and work in a coherent way that works to achieve that. Quality is indeed value to some person at some point in time …. 1. [Peter Drucker](https://en.wikipedia.org/wiki/Peter%5FDrucker?ref=annemariecharrett.com): “Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for.”[\[14\]](https://en.wikipedia.org/wiki/Quality%5F%28business%29?ref=annemariecharrett.com#cite%5Fnote-14) [Contemporary Quality EngineeringSome randomish thoughts on quality engineering.  Quality engineering enables visualisation of the state of quality anytime in the delivery lifecycle of a system or service. It does so in terms of its business outcome.  Anne-Marie Charrett  (working definition) Services not Products&…![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/QEModelText-150x150-2.png)](https://www.annemariecharrett.com/contemporary-quality-engineering) [Quality and the Toyota Production ModelMaking problems visible to teams and addressing them as close to the source as possible as well as building quality in.![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://images.unsplash.com/photo-1567789884554-0b844b597180?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDV8fHByb2R1Y3Rpb24lMjBsaW5lfGVufDB8fHx8MTYyMzgzMjAxMw&ixlib=rb-1.2.1&q=80&w=2000)](https://www.annemariecharrett.com/quality-and-the-toyota-production-model/) ### #NoBlogPost URL: https://www.annemariecharrett.com/noblogpost/ Last updated: 2021-06-23T22:51:25.000Z Today I woke up early determined to return to my blog on the bus series. A couple of reasons why. 1. I’ve found it liberating to not worry over being a perfectionist on writing the perfect sentence, phrase, or point. 2. Loads of people at Agile Testing Days told me how much they enjoyed them. I knew I’d be a little rusty after taking a week or two off, but not to the extent I expected. In total I attempted to write 5 blog posts, this is the sixth. The only one to be published. Here’s what happened. I knew I was going to get stuck, so I went for my go to app that forces me to write content within a fixed time. I did write something, it was on the nature of experimentation. I wanted to refer to a book I had read in the past only to discover I really needed to re-read it to make my point clear. So post number one put to the backlog. The idea of experimentation still rattled in my head. As was the concept of experimenting in terms of business outcomes, a discussion I had had with Margaret Dineen earlier in the morning. Maybe I could combine the two? I created a couple of whiteboards to brainstorm on. Wonderful! I had the idea and concept nutted down. Unfortunately, in the writing, I discovered that really there were two separate blog posts. I quickly created a draft of the second and moved on. For a later date perhaps. In my journey of understanding business outcomes I came across Kent Becks hypothesis on the the 3 E’s (Explore, Expand, Extract). I really like this concept. How can I tailor it to some of the ideas floating (and yes I mean floating) in my head? Not so well, as it turns out Kent Beck publishes on Facebook and, incredibly difficult to understand the timeline of his posts. I really wanted to understand his ideas better ( Success ‘according to who’ was one question I haven’t yet found an answer to…) so I put this blog post in the backlog too. A lead through Kent Beck’s work led me Taleb’s work on convexity bias and optionality. My brain cells and connectors lit up. What if optionality (the ability to select an option as opposed to being obliged to take the only option) became a quality attribute? Bah Boom…blog post on the way Until I again recognised the need to separate ideas and concepts into different blog posts. We have optionality but also convexity bias, I wanted to make points about both. More thought required on this one too. Still, I was learning a lot. Finally, in exasperation, I dived into a partially written blog post on Consumer-Driven Contract Testing. I mean at least finish something! But sigh, it was not to be case.It’s almost ready, but I need the ‘perfect’ title . What can I say? Sometimes I’m a perfectionist about being a perfectionist. So in the meantime, and after a day of research, I have only this blog post to submit to. I had a load of fun reading and researching so the time has not been wasted. Here are the blog posts I’ve been reading (In no particular order) [**Kent Beck Product Development** Triathlon ](https://www.facebook.com/notes/kent-beck/the-product-development-triathlon/1215075478525314/) **[Hypothesis Driven Testing ](https://www.thoughtworks.com/insights/blog/how-implement-hypothesis-driven-development?ref=annemariecharrett.com)** **[Convexity Bias ](https://www.edge.org/conversation/nassim%5Fnicholas%5Ftaleb-understanding-is-a-poor-substitute-for-convexity-antifragility?fbclid=IwAR2Nu92e%5Fj314fhn40vs4PCq80-eZX8wFH6BnBVKvoNT-tiR8w2Rb1td9IQ&ref=annemariecharrett.com)** **[Outcome Based Delivery ](https://www.outcomedelivery.com/?ref=annemariecharrett.com)** **[Beyond Outcomes over Outputs](https://hackernoon.com/beyond-outcomes-over-outputs-6b2677044214?ref=annemariecharrett.com)** Enough! Publish! ### Contemporary Quality Engineering URL: https://www.annemariecharrett.com/contemporary-quality-engineering/ Last updated: 2021-06-21T09:05:13.000Z > Quality engineering enables visualisation of the state of quality anytime in the delivery lifecycle of a system or service. It does so in terms of its business outcome. Anne-Marie Charrett (working definition) ### Services not Products The complexity and the distributed nature of our systems today means we are moving towards a network of services instead of an identified product. Instead of only thinking product quality, think ’emergent quality’. Emergent quality means focusing on the quality of the ecosystem. By doing so, it improves the quality of a system or service. By ecosystem I mean, the pipeline, process, people, provisions (tools) and principles involved in developing a service or system. ![Quality Engineering Model Charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QEModelv3-3.jpg) ### Business Outcomes not Feature Done ![Business outcomes are the destination](https://charrett.ghost.io/content/images/wordpress/sites/10/RoadToNowherekeynote.jpg) Credit Uros Stanisic Nature abhors a vacuum. If we don’t visualise and inform our stakeholders of the state of quality, they will inject their own interpretation of quality into that space and it will be imposed upon you. The finance director will do so in terms of money, the sales director in terms of revenue. Quality Engineering requires we understand and visualise quality in terms of business outcomes not only [our ability to deliver a feature.](https://hackernoon.com/thinking-beyond-projects-71998e2524e7?ref=annemariecharrett.com) ## New Quality Attributes Quality Engineering requires we better understand what quality is before we begin to think about how we can make it visible. What is quality for your organisation? For many organisations, speed has become a quality attribute. It’s no longer “the large eating the small, it’s the fast eating the slow”. I wonder how many in the quality business are thinking about how to visualise and make this information transparent to business? In the context of contemporary deployment practices, there’s a shift from attempting to delivery perfect software to being able to recover from production failure more rapidly. Observability of systems is a key factor in enabling this. Quality is as always shifting, and morphing into something new. How are we in the quality space responding to that? ## And Software Testing? Software Testing provides visibility on the state of quality, it does nothing to fix it. Software Testing is dependent on code being developed. It inherently comes later in the deployment lifecycle. Quality Engineering encourages lateral thinking on how we can know the state of quality of a system or service. Instead of looking to software testing to provide all the answers, it politely asks the question: *“If you were unable to perform software testing, how would you know the state of quality of your system?”* ### Visibility from the start By looking to a diversity of approaches to knowing the state of quality we can begin to see the state of quality consistently from the beginning, throughout and after deployment. ![quality at pace by annemarie charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QualityAtPace.jpg) quality at pace by charrett ### Whole team approach This is not a one person approach, it requires the whole team to be present and involved in understanding and knowing quality. It truly reflects the concept that the whole team be responsible for quality. Think of quality engineering in the context of a team and ask the team to respond to that. What would they consider as a threat to quality? [Blogging on the Bus](https://www.annemariecharrett.com/blogging-on-the-bus-an-imperfect-series/) Other posts on quality engineering [Quality is a journey - but do you know your destination?After any decent exposure to software testing, Jerry Weinberg’s definition of quality tends to gain traction and respect. That is “Quality is value to some person”. You like it because of its subjectivity. You may also hate it because of its subjectivity. Remember that bug repor…![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/RoadToNowherekeynote-2.jpg)](https://www.annemariecharrett.com/quality-engineering/) [Quality and the Toyota Production ModelI saw this tweet the other day prompting this post on quality, visualisation and quality at pace.  Don’t worry @Tracey\_san, I am not going to tweet the entire book. “The Toyota Engagement Equation.” #lean pic.twitter.com/9jQBXBPMt6 — Mark Graban (@MarkGraban) August 3,![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://mavericktester.com/2017/08/04/archive-quality-and-the-toyota-production-model/?ref=annemariecharrett.com) [Observability meet QualtabilityObservability, colloquially known as 011y, meet Qualtability (also answers to q10y). For those of you new to my blog, My name is Anne-Marie Charrett (@charrett on twitter). I’m a quality engineer by trade, a software tester by craft. I’ve always been passionate about pulling things apa…![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://mavericktester.com/2018/08/02/observability-meet-qualtability/?ref=annemariecharrett.com) [Quality WorkshopOne sure way to liven up a meeting is to ask attendees for a definition of quality. My experience has been that this is most entertaining particularly if you have both devops and testing in the room. It turns out that many people feel very passionate about Quality. It also![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/badasstestermarshmallow-1.jpg)](https://mavericktester.com/2017/02/27/archive-quality-workshop/?ref=annemariecharrett.com) ### The 'Do Nothing' heuristic URL: https://www.annemariecharrett.com/do-nothing-heuristic/ Last updated: 2021-06-22T06:33:59.000Z ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/11/Rabbit_in_headlights.jpg) Sometimes the thought of making ‘big’ decisions gives us that ‘rabbit in the headlights’ look. ‘Big’ decisions often have outcome can have a significant impact to either ourselves or our company. Lack of information can make these decisions harder to make. Constant decision making over sustained periods of time, and having to make decision in high pressure situations can also be stressful and lead to ‘decision fatigue’. No surprise then, people have come up with strategies to help us through the decision making process. Mostly these are in place to help us think logically and reason through decisions. Examining the pros and cons of each helps explore the consequences of making a decision. Jerry Weinberg’s rule of 3 encourages you to think of alternatives to pro and con. One strategy I’ve developed is what I call the ‘do nothing’ strategy. Simply put, when faced with a decision chose to ‘do nothing’. Might sound simple, but its bloody hard. Maybe because when we “do” something, it gives us the illusion we’re in control. Doing nothing, implies lack of drive or initiative, perhaps a fear, all viewed through a lens of weakness. But is that really true? “Doing nothing” may simply mean you don’t have any ideas on what to do. You may never have. And that’s not necessarily a bad thing. Perhaps what is more important, is that you come to that conclusion in a mindful way. Taking a decision to ‘do nothing’ can be incredibly positive. It can release a whole tonne of pressure that perhaps is preventing creative problem-solving. Or perhaps the best ‘solution’ is to do nothing. Who knows?. Doing nothing can be a powerful alternative option in your decision making. I think this is particularly true when working in complex or chaotic contexts in which you have little control over. Doing nothing has the benefit of letting you sit back and observe. It allows you to observe people’s behaviours and the decisions they are making. it allows you to wait and see what happens next, which may reduce the number of options you have. Doing nothing, allows you to live in the moment. Once you get over the initial anxiety of doing nothing, you can start to enjoy the moment. You don’t timebox, you put the time in its box. Doing nothing can also be a strategy. See it as a waiting game. Watch what unfolds, collect and use that information to use at your time, not others. Sometimes I think we charge into our decision making because the current uncertainty makes us anxious. We’re in a state of unease, and making a decision, taking action helps us get out of that state. But doing nothing helps us to observe the uncertainty, to meditate in it. That way we learn to deal with uncertainty, as opposed to attempting to reduce it. Being calm and mindful within uncertainty is a powerful tool. We get better at handling uncertainty through breathing and looking around you. So go on, why not give the ‘do nothing’ strategy a try? Other posts on heuristics: [This heuristic is backwardsRecently, I’ve been asked to make some comments on a book. I’m using a technique I ‘discovered’ in my early days of testing. I am calling it the ‘Backwards Heuristic’. In my early days of testing when I had to review documents, I lacked the confidence to speak![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://images.unsplash.com/photo-1474128380020-7d94d977426d?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDI3fHxiYWNrd2FyZHN8ZW58MHx8fHwxNjIzODg3OTMx&ixlib=rb-1.2.1&q=80&w=2000)](https://annemariecharrett.com/archive-this-heuristic-is-backwards?ref=annemariecharrett.com) [The Base Camp HeuristicHow you discover those bugs that are not obvious, bugs beyond the low hanging fruit? This post explores bugs using the basecamp heuristic![](https://annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2015/10/basecamp-1.jpeg)](https://annemariecharrett.com/the-base-camp-heuristic/?ref=annemariecharrett.com) ### No REST for women URL: https://www.annemariecharrett.com/rest-apis-written-by-women/ Last updated: 2021-06-17T05:04:07.000Z There’s plenty of pages giving you links to API Software Testing. Right now in MoT 30 days API Testing Challenge, they are working on collating lots of these which is a great idea. I wanted to contribute using a different approach. I decided to collate and amplify material created by female (and those identifying as female) software craftspeople. Here they are: Postman & API Testing: Amber Race Tooling around – by Jo Ellen Carter [REST-Assured with Cucumber:](http://angiejones.tech/rest-assured-with-cucumber-using-bdd-for-web-services-automation/?ref=annemariecharrett.com) Angie Jones [API Pathways](http://katrinatester.blogspot.com/2015/09/api-web-services-microservices-testing.html?ref=annemariecharrett.com) : Katrina Clokie [Exploratory Testing an API](https://dojo.ministryoftesting.com/dojo/lessons/exploratory-testing-an-api?ref=annemariecharrett.com): Maaret Pyhäjärvi [What Is API Testing and Why Should We Be Using It?](https://simpleprogrammer.com/api-testing/?ref=annemariecharrett.com): Kristin Jackvony [Pair Exploring an API with Thomas:](https://www.lisihocke.com/2018/07/testing-tour-stop-16-pair-exploring-an-api-with-thomas.html?ref=annemariecharrett.com) Lisi Hocke [API Testing Heuristics for Developers:](http://europeantestingconference.eu/slides18/Roy.pdf?ref=annemariecharrett.com) Linda Sarah Roy [Implementing REST sharp in REST API Automated Tests : Hilary Weaver-Robb](https://g33klady.com/2018/10/21/implementing-restsharp-in-rest-api-automated-tests/?ref=annemariecharrett.com) [G33klady’s adventures in Software Testing -REST API category](https://g33klady.com/category/rest-api-testing/?ref=annemariecharrett.com): Hilary Weaver-Robb [She used this one neat trick to model JSON as classes in C#, and her audience was stunned!](https://g33klady.com/2016/10/12/she-used-this-one-neat-trick-to-model-json-as-classes-in-c-and-her-audience-was-stunned/?ref=annemariecharrett.com) : Hillary Weaver-Robb [Testing the UI and API together with my new practice app!](https://g33klady.com/2018/10/07/testing-the-ui-and-api-together-with-my-new-practice-app/?ref=annemariecharrett.com): Hilary Weaver-Robb [Practise Testing App](https://github.com/g33klady/TestingRESTServices?ref=annemariecharrett.com) : Hilary Weaver-Robb [API Design Using Feedback Loops](https://medium.com/capital-one-tech/api-design-using-feedback-loops-37048d3d131e?ref=annemariecharrett.com): Lorinda Brandon [API Testing vs Unit Testing](https://thethinkingtester.blogspot.com/2017/10/api-testing-vs-ui-testing.html?ref=annemariecharrett.com) : Kristin Jackvony [Testing API calls in PHP with Guzzle Mock](https://lornajane.net/posts/2017/testing-api-calls-in-php-with-guzzle-mocks?ref=annemariecharrett.com): Lorna Jane [A variety of API related posts from her blog](https://lornajane.net/?s=api&submit=Search&ref=annemariecharrett.com) : Lorna Jane [10 things I hate about your API : ](https://docs.google.com/presentation/d/1T5rEOvRyDq8Yo2QITGNOYd%5FlylbN0TrX4yyuy7ARUOw/edit?ref=annemariecharrett.com#slide=id.p)Amanda Folson [API Usability Testing](http://blog.pamelafox.org/2012/03/api-usability-testing.html?ref=annemariecharrett.com) : Pamela Fox \[updated\] nineteen links That’s it. Five seven eleven articles, 1 video and 1 github repo. I think we can get this list to at least twenty. So here is my challenge to you all, please contribute by posting a link on API Software Testing you enjoyed and happened to be written by a female. Why I feel posts like this are important : [Women in Tech the facts](https://www.annemariecharrett.com/women-in-technology-facts/) *Featured image is[ Mary Wollstonecraft](https://www.theguardian.com/lifeandstyle/womens-blog/2015/oct/05/original-suffragette-mary-wollstonecraft?ref=annemariecharrett.com)* , *the concept of feminism is attributed to her.* ### Under the Hood - Learning APIs URL: https://www.annemariecharrett.com/api-exploratory-testing/ Last updated: 2021-06-15T08:42:36.000Z New to API’s and want to learn how to test them? Here’s some learning strategies to help you get started on your way. ### Feel the fear…and do it anyway For many, opening up the bonnet of a UI and staring at the underneath and the API and the technical internals can be scary. No wonder, it’s like a whole new world, with a different language. The difference is a bit like visiting a foreign country to living in one. Living in a country means immersing in culture, customs and maybe even a new language. Let's face it, most of us like familiarity. We heave a sigh of relief when we get home. If we do something well and are competent at a job, we feel good about that. And, it’s nice to get respect and recognition from our peers and be known for being skilled at something. Learning something significantly new means mentally leaving that safety and comfort, and replacing it with screwing up. A lot. Be prepared for that. It's perfectly reasonable to feel confused and fearful. They are the signposts telling you the way to new learning. Sometimes, you might even feel a little stupid or worry that others may think you are stupid. Try and focus on the learning. Trust me, most testers of any worth have had to learn new skills. In fact, I find the most interesting testers the ones who are prepared to learn new skills. ### Strip away complexity Some of the challenges in learning to test API’s is the sheer amount of stuff you feel you need to know just to get going. It’s easy to get overwhelmed and I find it takes a while to really feel comfortable with the new material. It’s perfectly normal to feel confused for a while. My suggestion is to try and focus on doing one basic GET request. I would also suggest you start with some basic online resources. Tools that are useful to simplify the complexity are Chrome Developer Tools and Postman or Restlet. When [teaching people ](https://www.testingtimes.com.au/services/academy/?ref=annemariecharrett.com)on how to test an API, I find this approach very useful. 1. Start with the UI focus on what actions you can take at the UI level 2. Use the browser to monitor those actions, observe methods, response codes and payloads. 3. Import those actions into Postman 4. Start playing with retrieving and sending data. Play around with parameters and request payloads ### Rinse and Repeat I find I easily forget information on API’s. I’m not sure why, maybe I’ve too much stuff going on in my head already, or maybe the old grey cells don’t work as well as they used to. Maybe, learning requires a lot of repetition. If so, why not set up a group that meets regularly for a short fixed time (15 minutes \~ 30 minutes), to work on one aspect of an API? Focus on a tool, a website, or one method. ## Mega API Links A few ways to fast-track some of this learning is to make available all the great resources on the web. Here’s some: - Take the [MoT 30 day API Testing Challenge](https://ministryoftesting.com/dojo/lessons/30-days-of-api-testing?ref=annemariecharrett.com) - Read [Danny Daintons Blog Posts](https://dannydainton.com/2017/11/25/just-fiddling-around/?ref=annemariecharrett.com) on Postman - [Waiter/API analogy](https://www.youtube.com/watch?v=s7wmiS2mSXY&ref=annemariecharrett.com) (useful for concepts) A lot of learning about API’s is about confidence. As you begin to grasp the concepts, the language, the intent, your confidence will begin to grow and soar. Before you know it, you have conquered a new context and a new skill. Congratulations! *[More on my API Exploratory Testing class](https://www.testingtimes.com.au/services/academy/?ref=annemariecharrett.com)* ### Lethal Weapon URL: https://www.annemariecharrett.com/lethal-weapon/ Last updated: 2021-06-22T06:44:41.000Z I’ve spent a day testing a scheduler using a semi-automated technique. It’s a task that is cognitively demanding. It requires creating sophisticated test data, loading it into a scheduler, then identifying if the output is as anticipated. Sound’s interesting right? It is. There are lots of different scenarios to test and lots of different dates to consider. The approach is semi-automated, where the output is manipulated into an easy read format. A lovely example of creating an oracle that facilitates easy identification and evaluation of potential problems. Paradoxically, the approach that facilitates a software tester to perform software testing in a ‘smart’ way is also its downfall. Because regardless of the use of tools to reduce the cognitive workload the task is still repetitive and requires a lot of concentration. This is a lethal combination. It’s lethal because this is where humans start to make mistakes. At least this one did. Not just one mistake, but I consistently made simple data entry errors that meant the results where useless. In the end, I abandoned the task and went home. The lesson of the day? Demand that your tasks be automated when instead of being an asset your fallibility becomes detrimental to the software testing you perform. We are all lethal weapons. As software testers, we can be the difference between finding something ordinary, or discovering something wonderful. We can also be the difference between providing so much white noise that valuable information is lost. What type of lethal weapon are you? ### Embrace your inner strange URL: https://www.annemariecharrett.com/embrace-your-inner-strange/ Last updated: 2021-06-15T22:23:45.000Z “*Everybody Wants Some!!”* It’s a nostalgic coming of age movie for male base ballers set in the 1980’s. The following conversation ensued between Jake and Willoughby (both pitchers): **Willoughby:** ..let me tell you something, Jake. It is lonely out on the bump, man. You know, hitters, they got no idea what that’s like. They don’t know the first thing about it, you know? It’s the most important part of the game, hands down, and yet it is a complete mystery to them. **Jake**: Yeah, no shit, but it’s almost like they view us as a necessary evil. **Willoughby:** Well, yeah, man, we kind of are, you know? But that doesn’t make them bad guys. You know, they’re just… They’re a little scared of us. You know? We’re fucking weird, man! We’re different! And the trick is, what’s the trick? **Jake:** I don’t know. Tell me. > **The trick is, you can’t fight it.You gotta accept it. You gotta fucking embrace your inner fucking strange, man.Just be fucking weird, you know? And when you do that, you bring who you are, never who they want.And that, my friend, is when it gets fun.** Likewise, testers and testing are seen as a necessary evil, and it can be lonely if you are the only tester. If that’s the case, look for ways to create a community of testers within your organization. Or look to outside and join one of the many software testing communities out there. There’s going to be times when people don’t understand what you do. Even if people don’t fully understand what you do, they will often respect your work. Lack of understanding doesn’t mean they’re bad people. It might be they fear your mystical testing skills that pull bugs out of software with a mere glance. There are people who either don’t or won’t see the benefit of what you do regardless. You can try to explain and demonstrate what you do, and certainly use what opportunities available to talk and explain testing, but don’t overdo it. If people don’t see a benefit, sometimes it's because they don’t want to see the benefit. Let them be. Not much can be done about these. Let’s face it, too many in software delivery we are a little weird. But rather than trying to ignore it, let’s accept and embrace it even! When we do that we bring our whole selves to our work, not a version of what we think people want. As a tester, there are times you’re going to face pushback, ignorance, and disrespect. I say, pick your self up, don on those red party shoes, let your hair down, turn the music up and let’s get this party going! And that my friend is, as Willoughby says, is when it gets fun! If you like this post you might like [Do your bugs glow in the dark?](https://annemariecharrett.com/do-your-bugs-only-glow-when-its-dark/?ref=annemariecharrett.com) ### Beyond the Black Stump URL: https://www.annemariecharrett.com/beyond-the-black-stump/ Last updated: 2021-06-25T06:33:05.000Z In Australia, the [black stump](https://en.wikipedia.org/wiki/Black%5FStump?ref=annemariecharrett.com) is a metaphor or the edge of European civilisation., an imaginary beyond which point at the country was considered remote and unknown. (Of course that wasn't true it was the home of a civilisation that was thousands of years old). There’s a whole lot of value of testing what we know. It helps create a mental model of what the system does. We can start making sense of what the system is supposed to do and how people want it to behave. It’s a useful building block to help us better understand. If we’re looking for new knowledge about how our system behaves in uncertainty, then we need to look beyond the black stump. Boundary Testing is one way we test beyond what we know. Here are some other ways: - perform the same action multiple times (in rapid succession) - load the system with data and then test - send ‘invalid’ data through a system - reduce the memory, diskspace, bandwidth - turn on logging to maximum capability - Perform a sequence of crazy ‘no user would ever do that’ actions - Combine these tests with other tests You can apply these ideas beyond your ‘product’. Infrastructure is a vital part of product delivery. So how would your pipeline cope in these situations? What if your system went down and couldn’t release. What if every developer went to commit at the same time? Do you have a favourite black stump test? If you liked this post, here's something similar. [Beware the Lotus EatersI realised how limiting my approach to testing was in this scenario. When faced with a problem beyond my immediate capability, instead of figuring out how to fix the problem, I narrowed my model.![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2011/02/lotus.flower.213-2.jpg)](https://www.annemariecharrett.com/beware-the-lotus-eaters/) ### Who moved my risk? URL: https://www.annemariecharrett.com/whose-moved-my-risk/ Last updated: 2021-06-15T03:23:39.000Z We know quality is ‘value to some person’, so it stands to reason that risk is also subjective. If we use risk as a factor to determine what to test, then how you test, what you test and your testing strategy will evolve and change. Is it though? Think of testing within your organisation as a fluid, evolving living organism from a Dr Who movie. It’s changing all the time with a whole range of factors such as: - market demand - new technologies - scarcity of time - the existing state of the product - what your company wants to focus on - new people starting, people leaving - how your company encourages learning - your infrastructure and how well it is maintained It’s easy to get stuck into thinking you are this type or that type of tester. Or that this is the best way to do testing. The reality is that as your skill grows, as the skills of developers grow, what you test \*should\* change. Perform a risk check. Is the testing being done right now, identifying the risks our company cares out? Or, is it finding low risk bugs that no-one seems to value? That may be an indicator to review your testing strategy and maybe focus on risks elsewhere. Maybe your functional testing is at a state that is humming along smoothly, switch your focus to removing pain points. Ask those around you what is causing pain and how can it be removed? Like this blog post? Why not read ... [Five Crimes against TestingFive crimes against testing that I see repeatedly executed. Testing and Quality are the same things Just because you test, it doesn’t mean you have a quality product.  Sounds obvious right? But why then is quality assigned to one person. Why have a Quality Gatekeeper? Testing shines![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/fish-230x220-2.jpg)](https://mavericktester.com/2017/09/18/2017-9-18-crimes-against-testing/?ref=annemariecharrett.com) ### Black Box Testing URL: https://www.annemariecharrett.com/black-box-testing/ Last updated: 2021-06-21T05:36:09.000Z Like many young children, my niece Emily was a little scared of going into the ocean. It was a beautiful Irish June day, and my mother could see she wanted to join all the other children splashing about and having fun. She took her by the hand and led her into the water. ![charrett black box testing](https://charrett.ghost.io/content/images/wordpress/sites/10/deepwater.png) Shallow water can be very deep for some people. There’s been some discussion about [deep and shallow testing](https://www.annemariecharrett.com/bos-series-shallow-testing-gets-a-bad-wrap/). While perhaps these distinctions provide value to people immersed in our craft, the concept of splitting testing to deep and shallow doesn’t make a lot of sense to our stakeholders, the people who matter. Most of us are familiar with some form of risk matrix matrix which categories risk into impact to the business and probability/likelihood of failure. We associate valuable testing with the red high range, yellow should test and low, nice to perform testing. For example, if the impact of the test is low, and the likelihood of a threat to quality being discovered is low, then ‘meh’ test if we have time. ![risk based test management](https://charrett.ghost.io/content/images/wordpress/2020/02/riskmatrix.png) **Risk Based Test Management focuses on prioritising tests in the red square.** Where does deep and shallow testing fit on this matrix? Well if you think of impact to a business user, then surface GUI testing is critical to them, so impact HIGH. The probability of failure? That too is contextual. It depends on the quality of the person coding, the clarity of what’s been asked for. But even if we are pretty confident that there is little probability of failure, it’s still in the ‘should test’ bracket due to the business importance. So business importance trumps probability. ![Black Box Testing ](https://charrett.ghost.io/content/images/wordpress/sites/10/IMG-5123-350x467.jpg) Drawn on the bus! Shallow testing is critical for business people. To call this testing shallow, negates the relationship we have to our customers and our business. If we want to classify our testing, I suggest we do so in terms of how our business perceives it. System Testing, Functional Testing. Black Box and White Box Testing are ways of describing this testing without the inference of trivialness. What do you think? For initial thoughts on shallow and deep testing go to my blog post on [BOB series: Shallow Testing gets a bad rapIn my Exploratory Testing class, I talk about shallow and deep exploration. When you say the word exploratory testing, many think, ‘just playing around’ on the product. And to some extent that’s true, a good true. So when I talked about shallow exploration it seemed to![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/deepwater-550x400-2.png)](https://mavericktester.com/2018/10/17/bos-series-shallow-testing-gets-a-bad-wrap/?ref=annemariecharrett.com) or try something different: [Quality is a journey - but do you know your destination?After any decent exposure to software testing, Jerry Weinberg’s definition of quality tends to gain traction and respect. That is “Quality is value to some person”. You like it because of its subjectivity. You may also hate it because of its subjectivity. Remember that bug repor…![](https://www.annemariecharrett.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/RoadToNowherekeynote-2.jpg)](https://www.annemariecharrett.com/quality-engineering/) ### Software Testers: Simply the best URL: https://www.annemariecharrett.com/software-testers-simply-the-best-bob-series/ Last updated: 2021-06-25T08:13:56.000Z Software Tester’s are a rare breed. We perform a role that can be difficult and not always fully appreciated or recognised. We are often the sceptic on the team, raising difficult questions when no one wants to hear them. We discover unplanned work, we question design, we uncover ambiguity. It’s not always an easy role. Software testers often face conflict and the information provided is dismissed. Folks seem to constantly look for ways to eradicate our role, either through automation or through spreading the activity to others. Along with great analytical, technical and testing skill, we need good business understanding along with good communication and collaboration skills. It requires a strong sense of self-worth and self-preservation. It takes strength and courage to be a tester. Patience and a sense of humour. And while there’s always value in self improvement for anyone, you shouldn’t have to jump through hoops to deliver value. So Software Testers, give your self a pat on the back. You are awesome and you rock! > Testers / QA professionals, take a moment today to celebrate all the value you contribute. Yes, we all need to keep improving. But we're also pretty awesome already. Do something nice for yourself. > > — lisacrispin (@lisacrispin) [October 16, 2018](https://twitter.com/lisacrispin/status/1052199042841800705?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) [Blogging on the Bus: An imperfect seriesI have more draft blog posts than published and I have a lot of ideas I want to write about. I’ve challenging myself to write short imperfect blog posts that I can write on my bus trip to work. That’s about an hour. They will be rough and![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/bus.jpeg)](https://mavericktester.com/2018/10/17/blogging-on-the-bus-an-imperfect-series/?ref=annemariecharrett.com) ### Shallow Testing gets a bad rap URL: https://www.annemariecharrett.com/bos-series-shallow-testing-gets-a-bad-wrap/ Last updated: 2021-06-17T05:23:44.000Z In my Exploratory Testing class, I talk about shallow and deep exploration. When you say the word exploratory testing, many think, ‘just playing around’ on the product. And to some extent that’s true, a good true. So when I talked about shallow exploration it seemed to fit. Different from deep exploration where a systematic approach is used to observe, model, use and evaluate the product. More often, I’m seeing the phrases ‘shallow testing’ and ‘deep testing’. These to me are problematic. Shallow testing used in this way to suggest that simple functional testing (potentially automated) is trivial. Deep Testing, on the other hand, requires going beyond the superficial and delving into the product often at a technical level. An example of each would be, testing at the GUI level,(Shallow Testing), removing the covers and performing testing under the surface(Deep Testing) Right now I’m with a client and I’m performing functional tests that have been written in a test case management tool. I specifically avoid any kind of investigative testing. I perform the test and I pass or fail the test. Is this testing confirmatory in nature? Yes! and what’s more, this is providing huge value to my client. There’s nothing trivial about it and by using the word shallow it dismisses the importance of this type of testing to a stakeholder. There is nothing like a functional test to give confidence to a business user that the product is ready to go. There’s something else. These tests are often essential beginnings to discovery. When you have a largely unknown problem space that needs exploration, we first need to make sense of what we are working with. In David Khlar’s book “Exploring Science: The Cognition and Development of Discovery Processes” a common heuristic was to confirm an initial hypothesis which allowed a springboard to further investigation. So what’s the alternative? Anything similar to shallow will have the same connotation. Perhaps we don’t need a distinction at all? Is it really useful to describe our testing in these terms? Most people want a shippable product and don’t give a flying koala what the software testing is called. What’s more, do you hear developers talk about deep coding and shallow coding? If you really want to classify testing what about the old but familiar black box testing and white box testing? ### Blogging on the Bus: An imperfect series URL: https://www.annemariecharrett.com/blogging-on-the-bus-an-imperfect-series/ Last updated: 2021-06-15T03:25:56.000Z I have more draft blog posts than published and I have a lot of ideas I want to write about. I’ve challenging myself to write short imperfect blog posts that I can write on my bus trip to work. That’s about an hour. They will be rough and not edited but hopefully, you will get a sense of what I want to say and challenge me to be less precious about writing perfect blog posts. ![B line Sydney](https://charrett.ghost.io/content/images/wordpress/sites/10/download.jpeg) B-line in Sydney First post can be read below.. [BOB series: Shallow Testing gets a bad rapIn my Exploratory Testing class, I talk about shallow and deep exploration. When you say the word exploratory testing, many think, ‘just playing around’ on the product. And to some extent that’s true, a good true. So when I talked about shallow exploration it seemed to![](https://mavericktester.com/favicon.png)Anne-Marie Charrett (aka Maverick Tester)Anne-Marie Charrett![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/sites/10/deepwater-550x400-2.png)](https://mavericktester.com/2018/10/17/bos-series-shallow-testing-gets-a-bad-wrap/?ref=annemariecharrett.com) ### Observability meet Qualtability URL: https://www.annemariecharrett.com/observability-meet-qualtability/ Last updated: 2021-06-25T06:37:40.000Z Observability, colloquially known as 011y, meet Qualtability (also answers to q10y). For those of you new to my blog, My name is Anne-Marie Charrett [(@charrett](https://twitter.com/charrett?ref=annemariecharrett.com) on twitter). I’m a quality engineer by trade, a software tester by craft. I’ve always been passionate about pulling things apart to figure out how they work.I was always the one in the house to fix the TV. No big surprise when I did engineering at University. Even less of surprise when I ended up pulling software apart to identify flaws. When asked at University what I understood quality to be, I said it was a mindset. To this day I stand by that definition. It probably explains why I like Jerry Weinberg’s definition of quality: It being value to some person. Observability as defined by honeycomb.io is > “A system that is appropriately observable is a system that is instrumented well enough that you > can ask any question required to support it at the level of quality you want to deliver to your > users.” Both are intrinsically linked. To be able to provide observability in a way that is digestible we need to understand what quality is for our consumers. Without being able to observe systems in all their glory, we won’t know its qualtability. Qualta–whaaa? Qualtability is : > the ability of a system to see that state of quality at any point in time. Ideally we want to be able to observe our systems so at any point in time we can interpret that information to better understand how good (or bad) our quality is. We need to be able to see quality right across software delivery, not only right at the end before release or in production. We need to figure out ways we can observe and infer the state of quality at any point in time. We want to be able to see the state of quality at design, during development and after release. We need tools and techniques to do that, now more than ever. ![agnostic testing quality at pace - copyright charrett](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QualityAtPace-2.jpg) Why now? Because corporate understanding of what quality is constantly changing as it tries to adapt to changing consumer demand. Speed to market has to some degree become a quality attribute. No longer is it “the large eating the small, but the fast eating the slow”. The definition of product is shifting too, to something that is less visible to a consumer’, less easier to test from a consumer perspective. For example a ‘product’ might be a set of API’s with little direct user interaction. Combine with increased system complexity and we are faced with systems that not only are getting harder to test, but there is less time in which to do it diligently. The goal is to have a consistent view of quality at any point in time across the delivery and avoid the hockey stick approach we are all familiar with. We want to apply a diversity of techniques and approaches to see quality at any point in time. We want to avoid lumping our ability to see quality into software testing at the end where we get an almighty surprise. We want to see the state of quality before and after we release, so that to some point we become[ release agnostic](https://www.annemariecharrett.com/agnostic-testing-do-you-believe/). This is what Qualtability is all about. Without observable systems our ability to ask questions of these complex systems becomes limited. It’s with this mismatch and hodge podge set of ideas that I’m setting off to [o11y](https://o11ycon.io/?ref=annemariecharrett.com) tomorrow. I hope to listen and learn from a bunch of smart and forward thinkers in the observability space. I hope to be able to share my expertise in software testing and quality. See you all tomorrow folks! ### How Tech Does Quality URL: https://www.annemariecharrett.com/how-tech-does-quality/ Last updated: 2021-06-17T05:21:01.000Z Ever wondered How Tech does Quality? What are their strategies when it comes to Quality and Testing? How do they increase speed to market without compromising on quality? [Why not come and join me and a panel of Sydney Tech Leaders](https://www.mycause.com.au/events/howtechdoesquality?ref=annemariecharrett.com) on the 13th June 2018 at the Canva Office to find out? [Tickets cost $25 AUD](https://www.mycause.com.au/payment/campaign/2557/174110?ref=annemariecharrett.com) all proceeds go to HeadSpace. ## How Tech Does Quality Panelists Atlassian, OFX, THE ICONIC, GumTree Australia and Canva will discuss their companies approaches to Quality and Testing. Why they work in the way they do, its advantages and disadvantages. They will explore how new trends are impacting approaches to Quality and will share some thoughts on what the future may look like in this space. ![How Tech Does Quality 13th June Canva Anne-Marie Charrett TestingTimes](https://charrett.ghost.io/content/images/wordpress/sites/10/How-Tech-Does-Quality-13th-June-Canva-Anne-Marie-Charrett-TestingTimes-240x300.png) ![How Tech Does Quality 13th June Canva Anne-Marie Charrett TestingTimes](https://charrett.ghost.io/content/images/wordpress/sites/10/How-Tech-Does-Quality-13th-June-Canva-Anne-Marie-Charrett-TestingTimes-240x300.png) Many thanks to my panelists Joel Hynoski, Head of Engineering at Canva, Roisin Parkes, CTO at [GumTree Australia](https://www.gumtree.com.au/?ref=annemariecharrett.com), Wendy Glasgow, CTO at [OFX](https://www.ofx.com/?ref=annemariecharrett.com), Jay Sethi, Server QE Manager, [Atlassian](https://www.atlassian.com/?ref=annemariecharrett.com) Ollie Brennan, Head of Engineering [The ICONIC](https://www.theiconic.com.au/?ref=annemariecharrett.com) ## How Tech Does Quality Panel Questions I’ll be asking the panel questions such as: What does quality mean to your company? What challenges have you faced in trying to achieve this? How has that affected your strategy? What advice would you give other companies on quality? What advice would you give people in the quality space? Crystal ball question: What are the biggest impacts on quality in the future? What questions would you ask? ### Raising Female Technology Leaders URL: https://www.annemariecharrett.com/women-in-technology-facts/ Last updated: 2021-06-22T04:34:27.000Z I was invited to a panel discussion by [Roisin Parkes](https://www.linkedin.com/in/roisinparkes?ref=annemariecharrett.com) alongside [Rohan Smith](https://www.linkedin.com/in/rohanjamessmith?ref=annemariecharrett.com) (Technology Leader – Optiver), [Owen Senior](https://www.linkedin.com/in/owensenior?ref=annemariecharrett.com) (CTO – Ansarada) and [Wendy Glasgow](https://www.linkedin.com/in/wendyglasgow?ref=annemariecharrett.com) (CTO – OFX) in a Launch of the [Female CTO/CIO Meetup in Sydney](https://www.meetup.com/Sydney-Female-CTOs-CIOs-Meetup/?ref=annemariecharrett.com) The mission statement for this group is: > To change the ratio of female to male technology leaders from 1:10 (currently 9%) to 1:3 or greater (> 33%) ![Female CTO/CIO Meetup in Sydney](https://charrett.ghost.io/content/images/wordpress/sites/10/Launch-of-the-Female-CTOCIOs-Group-300x225.jpeg) This post is a combination of discussions from the night and key takeaways from background reading of the [Women in Tech Facts Report](https://wpassets.ncwit.org/wp-content/uploads/2021/05/13193304/ncwit%5Fwomen-in-it%5F2016-full-report%5Ffinal-web06012016.pdf?ref=annemariecharrett.com) ## Women in Technology – the Facts. It didn’t surprise me that women were leaving tech mid-career. Anecdotally, I hear it a lot. But there’s nothing like empirical evidence to bring the message home. **The number of women leaving tech mid-career is double that of men**. What’s more, they’re not leaving to stay at home and mind the kiddies. The majority of women either leave to **work outside of tech** or go to **start their own business**. This suggests that though we may have a pipeline issue in attracting women to technology, we have a bigger retention issue. 85% of women in technology say they love their work. Women aged 25-35 cite ‘dissatisfaction at their tech career prospects’ with lack of role models as one of the reasons why. I’ve included some links and resources that might help. Looking back on my somewhat colourful career, [male allies](https://twitter.com/betterallies?ref=annemariecharrett.com) are very useful. In hindsight, a sponsor may have helped me in some of the tricky growth periods of my career. So consider the concept of sponsorship and that might be used at your workplace. Many thanks to Roisin Parkes for introducing me to the [National Centre for Women in Information Technology(NCWIT](https://www.ncwit.org/?ref=annemariecharrett.com)) website, which is packed with practical tips and advice. ## Women in Technology – Work Place Dissatisfaction The following facts come from the [NCWIT 2016 Infographic.](https://ncwit.org/women-in-it-the-facts-infographic-2016-update/?ref=annemariecharrett.com) 74% of women loved working in tech, yet feel they work in unsupportive work environments. Only 20% of women who leave drop out of the workforce (disputing the anecdotal myth that women leave to raise children) 56% of women leave at the mid-level point – **twice the quit rate for men** ![WorkPlaceDissatisfactionNCWIT](https://charrett.ghost.io/content/images/wordpress/sites/10/WorkPlaceDissatisfactionNCWIT-1.png) ## When Women Leave – where do they go? This I found super interesting as it reflected my personal experience 80% of women who leave their jobs in tech stay in the workforce. A staggering 22% of women who leave tech go on to start their own business. 24% of women abandon their training to work for a different company in a non-technical role. ![WhenWomenLeaveNCWIT](https://charrett.ghost.io/content/images/wordpress/sites/10/WhenWomenLeaveNCWIT.png) ## Women in Technology – The Good News The good news is that there are ways to improve this. Utmost importance is top leadership support, followed by training for management and then transparent data collection. ![GoodNewsNCWIT](https://charrett.ghost.io/content/images/wordpress/sites/10/GoodNewsNCWIT.png) I also like the nod to the concept of Male Allies. I have found useful within my own network. Everyone can take action against our implicit bias. Succinctly put in this call out (again from the NCWIT report): ![NCWIT MinorityGroupsAreNotBroken](https://charrett.ghost.io/content/images/wordpress/sites/10/MinorityGroupsAreNotBroken.png) Male Allies is a systems approach to tackling gender diversity in tech. ## Women in Technology – Actions Read chapters 5 and 6 of the [Women in Tech Report.](https://wpassets.ncwit.org/wp-content/uploads/2021/05/13193304/ncwit%5Fwomen-in-it%5F2016-full-report%5Ffinal-web06012016.pdf?ref=annemariecharrett.com) It’s an excellent easy to read report with lots of practical advice. Males, consider becoming a [Male advocate for gender equality](https://www.fastcompany.com/3046555/the-tricky-and-necessary-business-of-being-a-male-advocate-for-gender-equ?ref=annemariecharrett.com), women consider becoming an advocate for other minority groups. If you are on twitter follow [Better Allies](https://twitter.com/betterallies?ref=annemariecharrett.com) they give great tips on how to develop a culture of inclusion. Consider the guides below (wording and links come from the [NCWIT website](https://www.ncwit.org/?ref=annemariecharrett.com)) ### Critical Listening “Use this guide to help identify common misunderstandings that surface when people talk about how to increase the participation of women. Learn to spot “red flags” that indicate a particular discussion is headed in a direction that may not be research-based or effective.” [http://www.ncwit.org/criticallistening](https://ncwit.org/resources/critical-listening-guide/?ref=annemariecharrett.com) ### Supervising in a box “Employees report that the supervisory relationship is one of the most significant factors in their decision to leave or stay with an organisation. Are you, as a supervisor, adequately prepared for this responsibility? Even if your institution already has a formal training program for supervisors, use Supervising-in-a-Box to create highly productive teams that reduce employee turnover, capitalise on diverse innovative thinking, and ultimately strengthen their bottom lines. The in-a-Box Series provides resources for addressing unconscious bias and institutional barriers that affect five different supervisory job functions. Each box focuses on one job function.” [https://www.ncwit.org/resources/supervising-box-series-full-series](https://ncwit.org/resource/supervising/?ref=annemariecharrett.com) ### Data Collection “Developing a diverse workforce must be treated like any other critical business issue. Use this guide to help you collect important data and develop a strategic plan for increasing the meaningful participation of diverse groups in your organisation” Data Collection Strategy Guide ### I thought this was a blog on software testing? Yes, it is. Software Testers are often the minority group within an agile team. It’s pretty common for teams to have a sole tester. Most testers in tech companies report to delivery or tech leads who typically don’t have any understanding of what makes a good tester. To that end, I’ve experienced and seen testers feeling isolated, having little managerial support and I’ve seen their unique skills being overlooked in performance evaluations and promotion. To me, how testers are valued and supported by a company is a lens on it deals with inclusiveness and diversity. After all, if you fail to recognise the value of diversity of skillsets within a team, what does that say for other forms of diversity? In my next post, I will expand on the topic of the diversity of skill sets and how support testers within your agile team. ### Agnostic Testing - Do you believe? URL: https://www.annemariecharrett.com/agnostic-testing-do-you-believe/ Last updated: 2021-06-15T11:48:20.000Z For a while now, the concept of ‘release’ has seemed perfunctory to me. I remember the first moment when the thought hit me. It was over 10 years ago and agile was gaining traction as the method of software delivery. We were releasing to a two-week cadence As the test manager, part of my role was to drive the testing strategy for each release. As each release came and went, we stressed over how to make our testing as valuable as possible in the short time we had. As each release came and went we inevitably lost time and had too much testing to perform in too little time. As each release came and went, we were left stressed and depleted and with the knowledge that in two weeks we would need to repeat the exercise. It seemed crazy. It was at [that point I ceased to think of release testing](https://www.annemariecharrett.com/that-coverage-problem/) and start focusing on enabling quality testing to happen regardless of release. The cementing of continuous delivery as a preferred method of deployment has further entrenched this idea in my mind as we aim to release multiple times a day. Now instead of one release, we have many small releases. In addition, we contend with increased dependency on external software which itself has its own release cadence. So when we say release, the release of what exactly? The infrastructure software, the database software, the automation software…. the product? Yet we still focus on pre-release product testing. We improve our testing tools, test environments, and testing processes to facilitate greater and faster feedback prior to release. To be fair, we are starting to focus more on [recoverability over perfection](http://testobsessed.com/2015/05/i-prefer-this-over-that/?ref=annemariecharrett.com) and [testing in the wild. ](https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16?ref=annemariecharrett.com) \[[Late addition link by charity majors](https://opensource.com/article/17/8/testing-production?ref=annemariecharrett.com)\]. But,I’m still seeing a lot of emphasis on exhaustive pre-release testing. Putting aside the philosophical and financial considerations of exhaustive testing, I wonder if this fixation on testing everything is blinding us what we really need our software testing for. We have become so focused improving our pre-release testing through better tooling that we are forgetting to ask the question, where is the risk? The risk is often not where we are looking. The history of [black swan](https://en.wikipedia.org/wiki/The%5FBlack%5FSwan:%5FThe%5FImpact%5Fof%5Fthe%5FHighly%5FImprobable?ref=annemariecharrett.com)s tells us this. In my mind, our risk is less related to each release and more related to how those releases behave over time. Time. The one factor we don’t afford could be the one factor that will catch us out. What if we removed the concept of ‘release’ from our testing vocabulary? Instead of testing pre and post-release, we perform testing regardless of release. It becomes agnostic to release. perhaps we could have something like this: ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/QualityAtPace-1.jpg) Testing with this mindset frees up thinking. It breaks the chains and limitations of time, so often a constraint to finding real value in testing. It allows exploration and understanding of the system in ways that we did not have the luxury of performing. We no longer have to test in 3 days or 2 hours instead we perform considered and valuable tests that focus on risks we have yet to fully understand. ### **Contemporary Risks in Continuous Deployment** Below are some questions that may help think about potential risks outside of your releases: How well is our ability to recover from a failed release, corrupted data, integration failure, downtime in one part of your system? How well do we test our release process? Do we architect our feature flags? How reliant on we on external software ‘just working’ – what if there was a failure how would we cope? How dependent are we on serverless or cloud-based architecture? Is that bad? How do we know our ecosystem is healthy? Can we detect symptoms prior to catastrophic events? How do we identify risk in our software when we release multiple times in a day? Is there a better way? Do we have too little/much data to identify potential problems? Can we see these problems easily? What oracles can we use to help us detect health over time? What (new) oracles do we need? Are there other oracles within our organization we can use to help identify potential problems? What rich datasets can we create to expose potential problems? What security and performance tests can we run outside of the releases? ### Final words on Agnostic Testing This doesn’t mean we forget about pre-release testing at all. But it might be time to reconsider our strategy and perhaps our over focus on functionality at the cost of some other quality attributes that might really impact us in a nightmarish black swan moment. ### Finally… Those are only some questions to ask. I bet many of you have additional questions. What do you think? Can add to the conversation? You might be helping someone out! ### Metrics, T-shirts and Quality Engineering URL: https://www.annemariecharrett.com/quality-engineering-metrics/ Last updated: 2021-06-25T06:44:04.000Z I got up early to give an AMA on Quality Engineering with those fabulous people at Ministry of Testing. Turns out when you say Ask Me Anything (AMA)- it really does mean that. My favourite question is – what \*is\* that on your t-shirt? Well, there’s a story on that. A while ago I had placed a question on twitter > some possible heuristics around [#metrics](https://twitter.com/hashtag/metrics?src=hash&ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com). What would you add/takeaway? [pic.twitter.com/yWaNDw3Ed7](https://t.co/yWaNDw3Ed7?ref=annemariecharrett.com) > — Anne-Marie Charrett (@charrett) [July 4, 2017](https://twitter.com/charrett/status/882052526484332545?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) The good folks at Fetchline made me a T-shirt based on some of the responses. > We saw [@charrett](https://twitter.com/charrett?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) tweet on [#metrics](https://twitter.com/hashtag/metrics?src=hash&ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) and this is what our team did!! Hope you all like it! [pic.twitter.com/S8VAChzD7P](https://t.co/S8VAChzD7P?ref=annemariecharrett.com) > > — Fetchline (@theFetchline) [July 5, 2017](https://twitter.com/theFetchline/status/882463272082972672?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) It was this shirt I was wearing during the AMA session. If you missed AMA you can list to the recording (though you need to be a member so hop to it, totally worth it). [Ask Me Anything - Anne-Marie Charrett - Quality EngineeringWatch this insightful Ask Me Anything on Quality Engineering with Anne-Marie Charrett![](https://dojo.ministryoftesting.com/assets/favicon-4b6ba0a4118ce928dfcf3d3230cdbb09347a5a9b8d98f244c79d0d56384758bb.ico)MoT![](https://d2h1nbmw1jjnl.cloudfront.net/lessons/og_images/000/000/626/original/Testing_Ask_Me_Anything_-_Quality_Engineering_Dojo.png?1521986123)](https://dojo.ministryoftesting.com/dojo/lessons/ask-me-anything-anne-marie-charrett-quality-engineering?wvideo=n1206xbdrt&ref=annemariecharrett.com) ### How to avoid being fooled in software testing URL: https://www.annemariecharrett.com/how-to-avoid-being-fooled-in-software-testing/ Last updated: 2024-07-13T21:38:44.000Z As software testers, our role is to avoid being fooled by stuff that is potentially fooling others. For instance, we try to avoid being fooled by the product, we do that by testing with more than one piece of data. We try to avoid being fooled by stories as they are incomplete, ambiguous or out of date. To avoid being fooled we often challenge our assumptions or the team’s assumptions of what we know. With the help of the trainee testers from [Test-Ed](https://www.test-ed.com.au/?ref=annemariecharrett.com) we compiled a list of ways to be avoid being fooled My top ten ways to avoid being fooled. (I’ve deliberately kept these high level as I believe these strategies work across all levels and types of testing). ## Diversify your actions Mix up your actions. Do things you wouldn’t normally do. Try performing the same actions or journey using alternative methods. ## Diversify your test data Are you using the same data all the time? Think about mixing it up. Use tools and methods to help improve the quality of your test data. ## Diversify your oracles How do you know you’ve found a bug? Are you using the same Oracle time over? Consider mixing up your oracles. ## Diversify who is doing the testing We all see different things and have different experiences, so mix up who is doing the testing for different test ideas and different views on what is a problem/or not. ## Diversify your test environment Your test environment most likely is not a replica (yet) of your production environment. Consider using different test environments to expand your knowledge of the system. For example, a constrained test environment may offer interesting information on how your system performs under duress. ## Diversify the starting point Don’t start in the same place every time. Change the state from where you begin your test. ## Question your source material Stories can be incomplete, out of date, hard to test and or ambiguous. Query the story of this is the case. ## Ask Why? It’s fine to follow process if it makes sense. But if you can’t explain why you are doing something one way, you may be fooled. There may be a much smarter way to perform the task at hand, so there’s no harm in asking why something is being done this way. ## Clarify meaning It’s easy to assume that everyone is on the same page when it comes to definitions and meaning of words. If you are unsure of a meaning, chances are you are not the only one, so no harm in asking. ## Diversify your model Functionality is only one dimension of a product. There are many others. Consider the architecture, the business processes, the interfaces between stories/systems etc. The more you “see” the more ways you can test. I bet there are many others ways to avoid being fooled, why not share yours? *I would like to thank Connor, Adrian, Daniel and Hieu the trainee testers from Test-Ed for their assistance in compiling this list.* ### Quality is a journey - but do you know your destination? URL: https://www.annemariecharrett.com/quality-engineering/ Last updated: 2022-06-05T22:41:21.000Z After any decent exposure to software testing, Jerry Weinberg’s definition of quality tends to gain traction and respect. That is “Quality is value to some person”. You like it because of its subjectivity. You may also hate it because of its subjectivity. Remember that bug report you raised only to discover that others had a different view point? Forget about having a fixed mindset to quality. What was ‘quality’ yesterday is no longer ‘quality today’. Quality morphs and moulds itself to the context it's living in. In reality, we never will achieve quality. Quality is too fast for us and horribly intangible to be able to emphatically state “we have quality”. But we can go on a journey to improved quality, and we can monitor how we are progressing. A common question I get asked is “how do we know we have quality?”. Metrics are something that many reach for to understand this answer. It’s understandable go to, but metrics don’t always tell the whole story. Using metrics is like looking through binoculars, it’s only part of the picture. You need a combination of metrics, stories and context and a time machine to get the full picture. (I’m guessing that you need a time machine, I haven’t tested that). Metrics can give you some indication of where you are at, but it doesn’t always tell you if you are going in the right direction. I like to frame the quality story in terms of business outcomes. Business outcomes are goals that your business wants to achieve. For example, it could be the ability to respond rapidly to market demand, it could be reduced cost or maybe its increased sales. I use these business outcomes to help me focus my work . What small step can I take next, that will help my get closer to the desired business outcome? Like a compass it helps direct me on where to go next. This compass becomes especially useful with increased uncertainty. When companies grow and expand, when products are experimental, uncertainty thrives and out comes my handy compass. ![quality engineering journey](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/businessoutcomes.jpg) Quality Engineering 2018 created by Anne-Marie Charrett Here’s a team based roadmap on moving towards the quality you want: So step 1: work out your companies business outcomes. Ask people what they are being measured on, or what their teams are being measured on. Step 2: Think about (in terms of your context) what might threaten those outcomes. For testers, it could be that your test environments prevent you from testing early in the development lifecycle. Or perhaps there’s waste in your automation in testing. Let’s call these opportunities for improvement. Step 3: Get buy-in. In my experience, you get buy-in by doing things people are interested in. And, it’s likely the more senior the person, the more emphasis you want to place on that interest. Buy-in is important. It gives you legitimacy. You get buy in by linking the business outcome the the opportunities you have in mind. Step 4: Start working on reducing those threats, one small step at a time. It’s not going to happen immediately, so prepare people to think long term. Also, think about how you might do small experiments that people are keen to know answers on. Analyse and refactor. The goal is not to achieve the objective but to demonstrate how you are moving to the objective. Step 5: Don’t forget those business outcomes, they are your destination, not the experiments themselves. Speak in terms of those outcomes. Do it repeatedly. Preferably by visualising progress. Step 6: Be pleasant, have fun and treat others with respect. *\[This post has been written iteratively and has some minor changes made to it since the initial release \]* ### Free Online Coaching on software testing URL: https://www.annemariecharrett.com/2018-2-12-online-coaching-on-software-testing/ Last updated: 2021-06-25T06:58:52.000Z \[the offer for free coaching is now closed. Coaching is available but a fee applies\] I’m offering free online coaching on software testing this week and next week. The coaching session is approximately 90 minutes where you will test something for me and we will then review and discuss the results. The coaching session is text-based as I want to keep the transcripts for analysis. I will perform the coaching session through an IM format (Google, Skype, Slack, etc). I may share these transcripts with others, though I anonymize them before I do. If you want to go ahead – click on a time that suits you (remember the times are AEST). ### Five Crimes against Testing URL: https://www.annemariecharrett.com/2017-9-18-crimes-against-testing/ Last updated: 2021-06-25T06:45:48.000Z ![Five Crimes against testing](https://static1.squarespace.com/static/59a16751f43b558cac63ce35/59a1697c87da808b8645e55a/59bf47cac027d8defaa33fa1/1517973076987/fish.jpg?format=300w) Five crimes against testing that I see repeatedly executed. ## Testing and Quality are the same things Just because you test, it doesn’t mean you have a quality product. Sounds obvious right? But why then is quality assigned to one person. Why have a Quality Gatekeeper? Testing shines a light on threats to quality.Testing does diddly squat if no developer fixes the problems, or no delivery manager allocates time for bug fixing and re-testing. ## Testing is easy Nope, testing is not easy. It might appear easy, and perhaps superficial testing is easy. Testing is a skilled activity requiring critical thinking, a solid understanding of context (be that business or technical and typically both), great communication and a host of other skills and traits. ## Testing can be 100% automated No. See above. Yes, you can automate parts of the execution, but humans design and evaluate plus a host of other activities. Critical thinking and problem-solving skills are essential parts of testing. Without them, you might as well automate a fish on a bicycle. ## Metrics In the past, metrics have been the weapon of choice in crimes against testing. Test Case counts, DRE (Defect Removal Efficiency), pass/fail rates have all contributed to poor testing behaviour. Worse, they’ve often inhibited change due to dependencies on these metrics. Many testers have been burned badly by these metrics to the point where it’s stilted the conversation around quality metrics. The crime here is to throw out metrics altogether. Instead, why not have an informed discussion on the merits of metrics and quality? ## Testing is a means to an end, not the end It’s easy to get caught up in discussions on the merits of testing and checking. But ask yourself how this debate is helping your organisation deliver a quality product. Being right semantically is not the end result. Even Testing is not the end result. Your end result is a quality product. If you are a tester or quality advocate in your organisation, do you know what quality means in terms of business outcomes? I bet you’ve seen a few crimes of your own. What would you add? ### Badass Tester Marshmallow URL: https://www.annemariecharrett.com/badass-tester-marshmallow/ Last updated: 2021-06-21T11:46:21.000Z ![](https://charrett.ghost.io/content/images/wordpress/sites/10/2017/08/badass-tester-marshmallow-e1502361869928.jpg) When Keith worked at Barclays he held me up as the pinnacle of what a badass tester was. I found this funny as only the other week I had been called a marshmallow and so the phrase ‘badass tester marshmallow’ was born. Why was I given the name ‘badass tester’? You’ll have to listen to the podcast to find out. [https://api.spreaker.com/download/episode/12436288/qr\_anne\_marie\_charrett.mp3](https://api.spreaker.com/download/episode/12436288/qr%5Fanne%5Fmarie%5Fcharrett.mp3?ref=annemariecharrett.com) I asked [Trish Khoo ](https://designs.hogfish.net/?ref=annemariecharrett.com)to come up with a design for a T-shirt based on the phrase. Now you can get your very own badass tester marshmallow T-shirt. ## Badass Tester Marshmallow T-Shirt ![Badass tester marshmallow](https://ih0.redbubble.net/image.411419666.8597/ra,fitted_scoop,x2000,322e3f:696a94a5d4,front-c,285,143,750,1000-bg,f8f8f8.lite-4u2.jpg) ### A different perspective on Boundary Testing URL: https://www.annemariecharrett.com/boundaries-in-pair-testing/ Last updated: 2021-06-25T22:24:03.000Z The book ‘[Boundaries after a pathological relationship](https://www.amazon.com.au/gp/product/B00NHTXEOK/ref=kinw%5Fmyk%5Fro%5Ftitle?ref=annemariecharrett.com)‘ by Adele Birch has a load of practical advice on boundaries in relationships. As [Trish Khoo](https://trishkhoo.com/?ref=annemariecharrett.com) who recommended it to me said: “even if you don’t think you’ve had a pathological relationship, this is a good guide to setting and enforcing personal boundaries”, and it is. It’s full of practical advice and tips on understanding, setting and managing boundaries. This book applies to work too. Setting boundaries is vital to maintain healthy relationships within your workplace. Thinking about and setting boundaries between yourself, your peers, business partners, your managers and if you’re in a leadership position, people who report to you, will help you better cope when one of these boundaries is violated. When you are a sole specialist on a team, as testers frequently are this becomes even more important. Because unless your team works hard at creating a safe team environment, speaking up as a minority can be difficult and costly. It can be hard to be heard in a retro when your dot has to work against 7 other collective dots focused on other priorities. Work has other challenges too. We are all familiar with the ‘delegator’ who happily shoves responsibility onto other’s shoulders as if its the most natural place for it to reside (it isn’t).Without clear boundaries, many are likely to take on responsibilities that are not actually theirs. There’s and old but wonderful book called the [One Minute Manager meets Monkey](//www.amazon.com/One-Minute-Manager-Meets-Monkey/dp/0688103804) recommended to me by [Graham Lea ](https://www.grahamlea.com/?ref=annemariecharrett.com)on this topic. Worth a read if you’re can’t understand why you seem to have too much on your plate. Without firm boundaries, you can end up carrying the workload, while your team pats themselves on the back at the consistent work flow produced. The book describes different types of boundaries you might want to consider with examples of what these might be. One exercise is to describe the personalities and traits of your ideal partner. This probably isn’t that useful for a work relationship, we don’t get to pick and chose who we work with. Instead of thinking of one partner, replace it with company values. Know what you will or will not tolerate in a working relationship. At some point in your working career some one will intentionally or unintentionally cross one of your boundaries. Knowing what they are, and what you are prepared to tolerate (and not tolerate) will prevent feelings of violation and powerlessness. Being able to uphold your boundaries can be frightening for many of us, but when you manage it (and I believe you will) it’s empowering and liberating. It doesn’t mean that you will be impervious to boundaries being broken. In my experience, some boundaries can only be discovered after being crossed. We are after human, and our boundaries will probably shift as we journey through life. Hopefully, though with a little bit of practise, you will find it easier to maintain healthy boundaries and move to building solid team relationships. I’ll leave you with a mindmap of the lessons I learned from this book and applied to the work context. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/Boundaries-at-Work-by-Charrett.png) *Proviso: I’m not an expert in this field by any means. I’ve written this post based on my own work experiences and the advice may not relate in any way to your context.* ### Quality and the Toyota Production Model URL: https://www.annemariecharrett.com/quality-and-the-toyota-production-model/ Last updated: 2021-06-23T22:41:37.000Z I saw this tweet the other day prompting this post on quality, visualisation and quality at pace. > Don't worry @Tracey\_san, I am not going to tweet the entire book. "The Toyota Engagement Equation." [#lean](https://twitter.com/hashtag/lean?src=hash&ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) [pic.twitter.com/9jQBXBPMt6](https://t.co/9jQBXBPMt6?ref=annemariecharrett.com) > > — Mark Graban (@MarkGraban) [August 3, 2017](https://twitter.com/MarkGraban/status/893227400682758144?ref%5Fsrc=twsrc%5Etfw&ref=annemariecharrett.com) ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/LeadingLearning.jpg) ## **Understanding Quality** “Quality is value to some person” is a Jerry Weinberg quote emphasising the subjective nature of quality. Tapping into an understanding of what your customers uphold, believe in and need goes a long way to creating a great product. It’s not easy to tap into what your customer’s value, but once you do, once you discover that “x-factor” you generate customer loyalty. Michael Bolton added “Quality is value to some person **who matters”**. I and others have added “**at some point in time**” to indicate the transient nature of quality. This is the beauty and terror of quality. Its notoriously difficult to understand, let alone measure and quantify. Often we resort to quality attributes in an attempt to know and measure it. How then does quality relate to the above tweet? What struck me was the underlined phrase: “Its about making problems….visible to workers and management, and addressing them as close to the source as possible” Breaking that down… ## **“Making problems visible….** Understanding and knowing what quality is for your team, your company and customers, makes it significantly easier to recognise problems that threaten its value. The difficulty is in knowing where these problems lie. If we knew where problems existed, their nature and size and their impact, making it visible would be much easier. Software testing helps us identify and shine a light on such problems. It gives us the knowledge we need to “know” if we are reaching the quality our stakeholders want. Poor old software testing though. Perceived as expensive and time consuming with every test having a cost. A cost in thinking about it, developing it, using it, evaluating the output, fixing any bugs related to running it, and retesting. But when performed as an investigation to discover threats to quality, software testing excels. It can discover problems no-one had dreamed about, one reason why many software testers are seen to have super bug finding powers. The reality is, we spend all are days thinking about how things might go wrong. And, like any skilled person it’s become a well honed craft. By broadening the scope of our risk analysis beyond stories and product functionality, software testers can begin to exercise their powers of investigation and experimentation to many other areas. Many already help in story analysis to identify risk, but there are other places that potential problems lie. For example, performance, infrastructure, operations, test environment deployments, build times, bloated regressions test suites, flakey tests are all types of risks that potentially risk investigators can explore. I have often challenged and encouraged software testers on my teams to look beyond their bounded context and think of different types of risk. To create small experiments to investigate if a perceived risk is a real threat, and if it is, hand over to engineering to solve. The vital role of risk investigator starts to become real. By rebranding a software tester to that of [risk investigator](https://bughuntersam.com/wp-content/uploads/2020/06/Sam-Connelly-Tester-Profile-2016.pdf?ref=annemariecharrett.com), we can begin to see how this skill might be useful in the context of the Toyota Production Model where consistent visibility of problems is desired. ## **…to workers and management** It’s not enough for risk investigators to conduct experiments in isolation. That information has to be delivered to many different types of people whose concept of quality will probably differ and even conflict. Having data and being able to portray it in a way that is useful to that team is a real challenge. Conducting small experiments and providing as much technical data to other engineers is one thing. Facilitating senior management decision making is a different ball game (In the article Finishing Exploring, I describe the subtle difference in providing data and supplying valuable information). [Testing CircusRead our free Software Testing Magazine. Download Software Testing Magazine pdf and read software testing articles. Testing Circus is published from India since September 2010 and is one of the most regular software testing periodicals in the world.![](https://testingcircus.com/wp-content/uploads/favicon.png)Testing CircusAjoy Kumar Singha![](https://i2.wp.com/www.testingcircus.com/wp-content/uploads/Testing-Circus-Software-Testing-Magazine-December-2015.png?resize=480%2C320&ssl=1)](https://www.testingcircus.com/?ref=annemariecharrett.com) I’ve always liked the idea of having a UX person create senior management infographic. I explored this concept at Tyro Payments when I was Head of Engineering there. ![Visualizing Data by Anne-Marie Charrett Copyright 2017](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/wordpress/2020/11/Screen-Shot-2017-08-04-at-2.19.10-pm-4.png) For senior management, think about how you can portray information in a visible, colourful and easy to read manner. Use BLUF (Bottom line up front) and KIS (Keep it simple) principles avoiding dense text. ## **“..addressing them as close to the source as possible”** Early Feedback in software testing is not a “new” thing. The sound principle of unit testing has been around since I walked the hallowed aisles of Nortel Networks as a developer and a tester in the early nineteen nineties. What has changed is the technological advances that have enabled us to provide this feedback faster than before, and we want more of it. Long feedback loops introduced by end to end performance testing, or end to end GUI regression testing performed long after code has been written impact delivery. Unplanned work such as fixing bugs we didn’t know of, disrupt this flow. We’ve tried in the past to use automation in an attempt to speed up the feedback loop. That has worked to some degree, but its added additional work (read cost), and the value of some of these automated tests is debatable. Put it this way. If your end to end tests are not finding bugs that could be a problem. But if they are, that could be a problem too! By looking at alternatives to software testing that provide visual indicators of threats to quality throughout the life cycle we can begin to better understand the state of quality throughout delivery. I call this quality at pace. More on that later ### Test Leadership is here to stay URL: https://www.annemariecharrett.com/test-leadership-not-test-management/ Last updated: 2021-06-20T23:52:00.000Z In his article [“What leaders do”](https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj316Sl0MLSAhXHtpQKHSnUAMgQFgggMAA&url=https%3A%2F%2Fhbr.org%2F2001%2F12%2Fwhat-leaders-really-do&usg=AFQjCNHJk95brQjOtTMk0v%5FUbvXacx2yaA&sig2=FETZ5sH4zRIlgpL6oFoUiw), J.P Kotter makes the following distinction between management and leadership: > Managers promote stability, leaders press for change For example: - *Management involves planning and budgeting. Leadership involves setting direction.* - *Management involves organizing and staffing. Leadership involves aligning people.* - *Management provides control and solves problems. Leadership provides motivation.* The left-hand side sounds a whole lot like what test managers traditionally do or have done in the past. But, as organisations move to a more agile methodology, tasks associated with these responsibilities are becoming redundant. For example: ### No more Test Team Testers frequently sit within an agile team alongside UX people, a product manager, developers and operations. Often they report to a senior person within the team. Large independent test teams no longer exist. The need for a test manager from a people management perspective is no longer required. ### No more Big Test Strategy Small agile teams working on small stories reduce the size and complexity of work involved. Any decisions on testing are typically made at a team level as autonomy and decision making is pushed down into the teams. There’s little need for a formal test strategy for work at a team level, and little need for a test manager to develop a large test plan or test strategy that outlines testing and resources required over an extended period of time. ### No more Formal Test Process You have 10 days to think and complete testing for a story. If you’re lucky, five days of that may be actually testing. Who the hell is going to worry about writing test cases and a formal test report? The nearest you get to a formal test process is a Jira Workflow. So bye-bye formal test process. Bye-bye Test Manager to enforce test process. ### No more Formal Testing Metrics Metrics are becoming more team focused. Teams are using metrics such as MTTR (Mean Time to Recover), or LTTR (Lead Time to Deployment). Interesting ideas and I’m glad to see a shift in perceptions of quality. Again though, we don’t specifically need a test manager to report on these metrics. ### No more Gatekeeping Testing has traditionally (and unfairly) been the Gatekeeper to ensuring quality. The business sees the testing department as a method of control. I suspect the entire testing community is heaving a quiet sigh of relief at the demise of this one! Ensuring quality is a fool’s game, as there is no way you can win. It’s akin to forcing someone to sign a prenup to ensure love. Good luck with that. ### No more Test Managers then? Yes and No. The role of test manager as we know it is disappearing. There’s evidence of the demise of these roles in many of the large enterprise organisations I work with. But while there’s less need for test managers that doesn’t mean that the thorny challenge of testing has disappeared. And while deploying in bite-sized pieces reduces risk, it doesn’t it remove entirely. Often the risk is displaced to somewhere we are not used to investigating. Something AWS discovered much to their dismay. > [@awscloud](https://twitter.com/awscloud?ref=annemariecharrett.com) [pic.twitter.com/y70tbprlC8](https://t.co/y70tbprlC8?ref=annemariecharrett.com) > — Creighton Kirkendall (@crkirkendall) [February 28, 2017](https://twitter.com/crkirkendall/status/836665815453687808?ref=annemariecharrett.com) Some of the testing challenges many companies are facing: 1. How do we test large-scale systems and architectures (think Microservices) 2. How can testing be an activity that all perform? 3. How can we develop the testing capability within teams? 4. How can we get better diversifying our thinking in our testing? 5. How can we think about testability as part of systems design and architecture? 6. What part do testers and testing play within our teams? 7. What skill sets do I need testers to have? Is it just one type of skill set? 8. How can you test in production? 9. How can we better understand and provide information on quality? 10. How can we better respond to change, that is either in and out of our control? Let me explain that final point. Software Testing doesn’t have a great reputation for being flexible and adaptive to change. The way we test is deterministic. Think gated process and scripted test cases. This includes test automation which can be brittle with a high maintenance cost. ## Test Leadership Like it or not, change happens. Sure, the extent to which change happens and the nature of that change may depend on the industry and technology you work with. What becomes important though, is how we handle that change. And, how we equip our teams with the ability to adapt to change becomes the task of a test leader. We need confident self-possessed software engineers, equipped with the ability to think critically through whatever challenge crosses their path. We need to help them work together to solve whatever testing problem comes their way. This requires a positive and safe environment where teams become ‘test-infected’ and have a culture of continuously thinking about improving their testing. Test Leaders provide this breathing space for a testing culture to grow. They achieve this by placing an emphasis on vision, strategy and motivation and alignment. Examples of this are coaching, training, knowledge sharing and making information visible to the rest of the organisation. A testing culture that provides this space itself generates test leaders. That’s important, because to some degree every tester is an advocate of quality and that in itself requires a degree of test leadership. The skill set required in test leadership is different to test management. It’s more aligned with coaching, connecting people and driving a shared vision of quality for your company. It requires revisiting ideas on why we test and what software testing actually is and how we can continue to deliver value in a different context. But I don’t see uncertainty going away, in fact, I only see it increasing. And so, neither is test leadership. ### Quality Workshop URL: https://www.annemariecharrett.com/quality-workshop/ Last updated: 2021-07-14T08:37:27.000Z One sure way to liven up a meeting is to ask attendees for a definition of quality. My experience has been that this is most entertaining particularly if you have both devops and testing in the room. It turns out that many people feel very passionate about Quality. It also turns out that many have different ideas on what quality actually is. Who knew? Diversity of ideas are not bad but it can impact a teams understanding of quality. The consequence is that it could possibly hinder a team’s ability to delivery quality product. To help people understand the challenges around quality and to try clarify what quality might be in their context, I developed the following quality workshop. ## Purpose of Quality Workshop a) to get a working definition of quality that most people are comfortable b) to outline a manifestation of quality in terms of quality attributes c) to identify ways in which we can these quality attributes can be acted on ## Who should attend Depends on what your trying to achieve, but if you’re a team delivering product, I would suggest your key stakeholders come along. That may mean product owner, developers, testers, Ops. If you can get your business there too that’s a big plus. ## Tools for Quality Workshop - A set of Quality Attributes (I’ve known these also to be called [Quality Characteristics](https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=21&cad=rja&uact=8&ved=0ahUKEwjL4%5FCEsarSAhUKfbwKHSwDBXYQFgiJATAU&url=http%3A%2F%2Fthetesteye.com%2Fposters%2FTheTestEye%5FSoftwareQualityCharacteristics.pdf&usg=AFQjCNEF6KdxZ6ywSHo5wqBq82Av%5FYpsOQ&sig2=CA8lF151zLimlRqgTQKTuQ), or CFR’s – Cross Functional Requirements) printed out and placed on a wall. - PostItNotes (of course!) - some pens. ## Process for Quality Workshop 1. Ask people to write down on a post-it note their understanding of quality 2. Place the definitions on the wall and ask people to read them (or read them out) 3. Note the diversity (if it exists, it typically does). Bring up the subjectivity of quality and how difficult it is to agree on and quantify. 4. Ask what the implications of this might be throughout the delivery lifecycle (e.g Design, Development, Ops) 5. You can dot vote to try and get some sort of agreement on a working definition of quality\*. *\* My working definition of quality is the Jerry Weinberg one “Quality is value to some person”. If no-one puts this definition up on the board, I like to add it as it encourages a discussion on the subjectivity of quality.* If you’ve got this far without some major outburst or spat, congratulations! Next step is to try and parse what quality might look like. 1. Ask people to read the quality attributes on the wall 2. Ask them to dot vote 3 what they consider to be the most important quality attributes 3. Collect the top 3 quality attributes and put them on a whiteboard 4. Ask the group to identify 3 tasks for each particular quality attribute and to write them on a post-it note.\* 5. Place the post it notes on the whiteboard along side the quality attribute 6. Run through the post-it notes. Discuss the viability of these and how to make these tasks happen. 7. Visualise and share this information to the broader organisation. *\* I avoid using the word ‘testing’ as I want people to think about other factors that influence quality. Testing is important, but testing helps us evaluate quality. Unless its acted upon, it doesn’t help us build quality. Sometimes I like to prime people by providing a couple of non testing examples such as Code Reviews, Monitoring and Security by Design.* I’ve found these sessions generate a lot of discussion and can become quite heated. I wouldn’t run a quality workshop all the time, but its really useful iron out at perhaps an epic or feature level, what quality might be and how a team can work together to implement that vision. Let me know how you get on! ### What Teenagers and MVP have in common URL: https://www.annemariecharrett.com/what-is-mvp/ Last updated: 2021-06-10T18:09:43.000Z Teenage children can be the classic MVP’s (Minimal Viable Products) in action. Here’s why: 1. They tend to be self deterministic 2. They tend to experiment constantly 3. They don’t attempt to predict the future but learn from their experiments 4. They typically have no endstate in mind that they wish to be made explicit 5. They have courage to outline their path determined by their feedback 6. They have faith in the outcome even if the outcome is unknown Ok, so I made a lot of that up. But hear me out… Teenagers can the quintessential examples of MVP’s in progress. If you have one in your house and you want to understand more about MVP. Observe and Learn from them. They can teach you wonderful insights into known, knowns and unknown, unknowns. Even more, you will have insight to the ‘knowns I wish I could now be unknown’. Something I’m not aware the Cynefin model caters for? As a finale, here’s a voyeuristic view into what my teenagers do right now… > A post shared by @nikolai.charrett on Feb 12, 2017 at 1:55am PST — love your work boys… Update: Since I wrote this, I’ve thought a bit deeper on the topic. To some degree we are all MVP’s regardless of age. To some degree we are all completed products, but also we’re often minimum versions of the end state. At least I am. I’m still trying to figure out who I want to be, what I might want to do, and what that might look like. ### Building the Quality Inn URL: https://www.annemariecharrett.com/building-the-quality-inn/ Last updated: 2021-06-17T05:19:01.000Z Building Quality In integral part of moving to a DevOps culture, at least according to the [State of DevOps 2016](https://puppet.com/resources/report/2016-state-devops-report/?ref=annemariecharrett.com). But what exactly does that mean? Sure, the report cites Deming, in particular “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.” And while the concept is not new, and seems to make sense at least at an ideological point of view, what in practice would it look like? This was what [Matthew Santon Rutherford](https://twitter.com/iag%5Fquality%5Fdr?ref=annemariecharrett.com), the Quality Guild Doctor at IAG asked me. He also mentioned that when people spoke of ‘Building Quality In’ it immediately conjured up this image of a run down motel somewhere remote, with a pink flamingo sign, swaying slightly in the wind. We laughed and played around with this image for a while, adding an empty swimming pool and trying to imagine what each room might look like and who its customers might be. I dedicate this series of “Building Quality INN” blog posts to Matthew, who has forever burned this image in my mind. What would your version of Quality Inn look like? Do you have a picture that might represent it? Please share ! ### Nuance on leaving testing to the experts URL: https://www.annemariecharrett.com/nuance-to-leave-testing-to-the-experts/ Last updated: 2021-06-20T22:52:31.000Z ![the buck stops here truman ](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/truman.jpeg) Yesterday I wrote a blog post entitled [“Leave Testing to the Experts”](https://www.annemariecharrett.com/leave-the-testing-to-the-experts) to which Maaret quickly reacted online and by a post where she strongly disagreed with the sentiment. Disagreement is a very useful tool to clarify your thinking, so thanks Maaret!. It’s allowed me the opportunity to explain in more detail, why I think what I do, and to investigate some of the nuances on this topic. Maaret, counter-argued with a convincing description of her egalitarian work place where opinions are offered and accepted in good faith. In truth it left me feeling a little envious, and a commitment to work harder on taking ‘being told’ as “bad communication with good intent”. But I think this post misses a vital point and that is responsibility. Taking on a role³ of tester comes with a responsibility to have testing performed to your best ability. So, if I listen to an opinion and follow it, knowing its wrong, I call that irresponsible. If I hire a tester based on likability over capability, that’s irresponsible. If I fail to highlight risk for fear of upsetting team members? Well, you get the point¹. Perhaps you might say that testing is a collective responsibility, and we all own the decision. After all, in an egalitarian team such as Maarets, doesn’t everyone own quality? Isn’t everyone responsible for testing? Well, yes and no. Let’s explore that a bit by taking the pilot example.It takes a crew to fly a large plane. There’s the engineers, the pilots, the cabin crew and many more. The pilot happily takes on other crew member’s opinions and ideas. Perhaps she listens to the engineer’s advice not to fly above a certain height. Or maybe she nods when a cabin crew member tells her that people like to hear from her voice more often. Perhaps her junior suggests a flight plan for the journey. She hears all this and takes it into consideration, but flying the plane is ultimately her responsibility². Even if part of that decision is to allow the junior to fly the plane for some of the journey. The buck stops with the pilot.The crew is responsible for the whole flight experience, but the pilot is responsible for flying the plane. Similarly, in a team, we’re all responsible for quality, each person may even be responsible for their own bit of testing but ultimately the testing buck stops with the tester. Notice that everyone got to have an opinion? Similarly on a team, many people can perform testing and offer ideas on testing. This can be incredibly invaluable to testing as a whole. For example, developers have a keen insight into technical risk which can really help identify/dismiss areas that require testing. Teams that are test infected and have this testing mindset are often a joy to work with. You don’t get a testing mindset if you’re prevented from exploring ideas, so I agree with Maaret that people should be allowed to offer opinions and experiment.I worked with a team who wanted to implement BDD. I was skeptical. BDD seemed to me a bad fit for the context in which we were developing. There’s nothing like self discovery though and so the team went ahead and tried it out. It turned out to be a dud idea and it was dropped. It’s good to experiment and encourage exploration but there needs to be a proviso here and that is when ***the risk is low and the impact to the company is minimal.*** Back to the pilot. You don’t handover control of a plane to a junior pilot just as turbulent weather conditions hit. You might if they have more experience in flying, but as the senior pilot you will know when to take the wheel and when to allow practise. Someone who knows what they’re doing needs to make these decisions. ***Also performing a small experiment when the risk is low is very different to adopting a strategy company wide.*** Dictatingcucumber as a tool across an organisation is very different to performing an experiment within a team. To clarify, my lament on testing experts is in the context of organisations adopting ‘best practise’ strategies. Maaret talks about everyone on her team ‘tests like an expert’. I think that’s great, her very capable team means she doesn’t have to exercise responsibility. She’s still responsible for the testing though, just as carrying a plane full of pilots doesn’t absolve the actual pilot of responsibility. I’ll end this post with the comment about sales people. Maaret says she constantly offer views to developers and sales people. The truth is I have done that too. I guess everyone feels in some way their idea is good and has value and its nice to have your opinions heard.I remember once querying a company’s sales strategy. I couldn’t understand why we only aligned with partners instead of also focusing on location. I brought this up with the sales manager who listened and then dismissed it explaining why. Personally, I still don’t agree with the approach, but I’m fine with his decision. Why? Because ultimately the buck stops with him. I’m cool with that. Non testers will always have views and opinions on testing. That’s not a bad thing. In fact, part of me is glad they feel responsibility about testing. But it’s a problem when those opinions start impacting my testing in a negative way. Then I’m failing in my responsibility to perform testing to my best ability. You see, the intent of ‘claiming territory’ is to do a job well, the job I was hired to do, not to hold power over people through control.I hope this makes sense. Like I said, I’m grateful to Maaret for her response and the opportunity to deepen my ideas on the topic. *Footnotes* ³I considered adding the word specialist here as the concept still holds. A specialist (of testing) still holds the ultimate responsibility for testing, even if they don’t perceive themselves as a tester. ¹Many of these decisions are nuanced and are rarely black and white. For example, hiring a tester for a team fit is really important, but if you do so over capability you need to be able to back your decision with some sound logic. Context is important here. ²many people inside and outside a team test, so a tester isn’t responsible for doing all the testing, but they are responsible for the strategic direction and process of testing. ### Leave the testing to the experts URL: https://www.annemariecharrett.com/leave-the-testing-to-the-experts/ Last updated: 2021-06-20T01:27:36.000Z Why is it that in a company almost everyone has an opinion and knows the best way to test? What makes so many of these people feel they know how testing ought to be performed? Business people tell me, the tester: > *“You should be writing test cases and reporting against them”* Developers & technical people tell me to: > *” automate the lot using cucumber/PACT/Selenium or some other niche technical tool”* Test Managers (many who have never tested) tell me: > “You should be following a formalised signed-off testing process” I find this quite extraordinary. I don’t tell you, oh developer how to code your program. I don’t tell you oh, sales person, how to sell your product. **So why do you think it's reasonable and perfectly acceptable to tell me how to test software?** Perhaps it's because we all test to some degree. But just because I can build a car or sell one doesn’t mean I can drive it. Just because I know how to drive a car, doesn’t mean I go and tell a rally driver how to race around a track. The truth is, most developers, project managers and business people don’t understand testing in any deep way. Instead they often resort to shallow imitations, an emperors test suite, if you will. That’s partly the fault of the testing profession. We’ve failed to claim our turf and instead tugged our forelock, deferring ideology to those with authority but little understanding. It’s time tester’s to claim some turf back. I suspect (actually I know) for many places it won’t be given up without a struggle. You’re going to need courage backed by confidence in your ability if you want to claim some of the territory. But it’s worth it. With space comes freedom and the autonomy to drive your testing strategy and process in a way that you know will offer value to your organisation and your clients. Now, please get out of my way and leave the testing to the experts! ### The Base Camp Heuristic URL: https://www.annemariecharrett.com/the-base-camp-heuristic/ Last updated: 2021-06-17T21:59:12.000Z The ‘Base Camp’ heuristic is the work required to find any bug. Typically ‘Base Camp’ bugs tend to be low lying fruit and can be found quickly, especially if a tester is experienced. In the world of [Daniel Kahneman](https://www.goodreads.com/book/show/11468377-thinking-fast-and-slow?ref=annemariecharrett.com), these bugs are found using Systems 1 thinking. To discover an ‘Everest’ type bug requires Base Camp intuition plus more. For example, a tester might need to deliberate over the product in detail, question the diversity of the data, the validity of the oracle(s)underuse and the procedure required for testing.It may mean you need to create new tools or find new ways to track the unknown. That means you’re going to need mental training to extend the boundaries of your thinking, determination to continue when the easy answers stop flowing and some tactics to help you refocus and come up with new solutions when you run out of ideas. You may feel dismayed because everyone around you is finding bugs at a rapid pace. You may even encounter scepticism because you appear to be showing no value. But Everest quality bugs are not meant to be easy to find. They require stamina, commitment and courage. It’s rare to find bugs of this calibre without training and serious commitment. Maybe I’m not going to climb Mount Everest every day, but as an aspiration I’d like at least some of my bugs to be of the Everest calibre. How about you? ### Testing Microservices - what do you want to know? URL: https://www.annemariecharrett.com/testing-microservices-what-do-you-want-to-know/ Last updated: 2021-06-10T18:09:44.000Z The following is an outline of blog post on Testing Microservices. Does it sound interesting? Vote below to get me to write it or focus on something else 🙂 Testing Microservices 1) Microservices is a concept a set of patterns, not a set architecture 2) The context in which you testing has a direct impact on how you test 3) Risk changes, allow your strategy to change with it 4) Diversify your testing strategy Should I write this blog post? If you have a question you want me to answer on testing microservices, please add it in the comments. ### No women speakers? No Bother! URL: https://www.annemariecharrett.com/why-im-not-worried-about-women-in-software-testing-conferences/ Last updated: 2021-06-20T00:55:05.000Z That might surprise you if you listened the Eurostar Webinar last week where Fiona Charles and I explored the numbers of women speaking at software testing conferences. If you didn’t hear it [you can now](https://vimeo.com/134959112?ref=annemariecharrett.com) (Spoiler ahead it’s roughly 25%\*) ![FemaleConferenceSpeakers](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/FemaleConferenceSpeakers.png) Considering that there are more women in testing than other technical professions you might be surprised by this. Unfortunately I’m not surprised. Fortunately, I’m not bothered by this. In fact, I’m not even bothered that in 2015 the percentage of women speakers has dropped in some conferences, or that the number of women on program committees for many conferences is a big fat zero. ![Percentage of women on program committees](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/Screenshot-2015-07-31-09.01.15.png) I’m disappointed of course, but I’m not bothered by it. That’s because there are some phenomenal women in software testing and they’re taking the matter into their own hands. Rosie Sherry working with Anna Royzman for example, has dropped the teaser that women makeup \~50% of [TestBashNY 2015 ](http://www.ministryoftesting.com/training-events/testbashny/?ref=annemariecharrett.com)using a merit based selection process. They had a lot of women submitting proposals and I think it’s clear why. What female tester wouldn’t want to speak at a conference run by those two phenomenal and respected women? There’s more though: Maaret Pyhäjärvi & Adi Bolboacă have decided to create a conference that they would want to attend. It’s called the [European Testing Conference](https://europeantestingconference.eu/2020/?ref=annemariecharrett.com) Mieke Gevers & Nadine Raes run [Belgium Testing Days ](http://btdconf.com/?ref=annemariecharrett.com)and there’s typically a high percentage of women speakers (30% this year). I’m sure there are other examples too. It’s simple folks. When you create a culture where women feel welcome to speak, the submissions come flooding in. What does that mean? Well, perhaps women no longer need to be concerned about being underrepresented at dinosaur conferences. Instead, women can focus on conferences that are already offering a healthy environment. Conferences where women are compelled to submit. I suggest that for any conference in software testing, if the trend of women speakers is decreasing or wildly fluctuating, if the percentage is consistently below 25%, then conference organisers need to rethink how they are attracting talent. ![FemaleSpeakersByConferenceTime](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/FemaleSpeakersByConferenceTime.png) In this day and age, I think there is little excuse for poor female representation. Conferences such as CAST have demonstrated it can be done. CAST has high calibre talks and a high percentage of female speakers. Who would have thought? How about you, do you think conferences organisers need to rethink how they attract talent? *\*figures were taken based on information on websites. We may have made errors in counting, but we think they are fairly accurate representation. Please let us know if we’ve made any glaring stuff ups.* ### Agile Australia and Intent based Leadership URL: https://www.annemariecharrett.com/agile-australia-and-intent-based-leadership/ Last updated: 2021-06-15T08:32:53.000Z Today I went to Agile Australia as an attendee. That’s a first for me, usually, I’m speaking. It was wonderful to go with a different purpose, which is to learn from others. Typically, if I’m speaking I’m so focused on ‘my talk’ and getting ready for ‘my talk’ that I don’t feel very open to learning new ideas. I’m glad I went, because I had the opportunity to listen to David Marquet’s (nuclear submarine commander) talk about the abdicating control (not responsibility) to the people who worked for him. In a military organisation I can’t imagine the mindset shift & the struggle his crew must have felt! There were many aspects of the talk I enjoyed, how subtle changes in language was used to help people think differently. For example instead of his crew requesting permission, they informed authority by using the phrase “I intend”. He emphasised the need for constant training and drills to help keep people prepared for when the inevitable mistakes were made. I also liked the concept of pushing ‘authority down’, allowing his crew to control their decision making.The biggest resonator though was his perspective that you can’t change people, all you can do is provide an environment where people can change themselves. After all “When a flower doesn’t bloom, you fix the environment in which it grows, not the flower.” I have this ideology too in building & developing test teams. In 2013 I spoke at Tasting Let’s Test about [building a context driven test team](http://www.slideshare.net/amcharrett/creating-a-context-driven-test-team?ref=annemariecharrett.com). In it, I talk about creating a habitat where testers can thrive and grow, with a focus on coaching to support that work. I’m working hard to create a habitat like that in Tyro Payments. The underlying belief he had was that “people are fine the way they are stop trying to fix them” struck deeply with me. If you start with that premise you come to coaching with a different mindset. And just like I came to Agile Australia with a mindset of learning this year as opposed to speaking, I can approach coaching with intent to listen instead of teach. Instead of focusing on where a person needs to be, you think of were a person is. The spotlight is placed on the person not your perception of that person. Perhaps it’s subtle differences like this that can make all the difference in coaching. Or maybe not. I don’t know. It’s an experiment, but one I’m performing on myself rather than on other people.And I think that’s exactly how we all like to learn. ### Nice girls don't get the Keynote URL: https://www.annemariecharrett.com/nice-girls-dont-get-the-keynote/ Last updated: 2021-06-22T04:26:24.000Z Keynotes are something to be earned and rightly so. Typically a keynote comes from someone who likes to speak, who is good at speaking, and has something interesting to talk about. I know many women testers who meet the above criteria. They have the requisite ‘merit’ required to be a keynoter. They have thoughtful ideas, are good speakers and are well respected in the testing community. So why are they not keynoting? Could it be that to be a keynote takes more than ‘merit’? Could it be that keynoting is also about your place in the community and your connections within that community? My experience as a conference organiser and being on program committees is that ‘who you know’ is equally as important as ‘what they know and how they speak’. I don’t apologise for that. It’s important for me to base my decisions not only on an abstract but on a speaker’s reputation. A keynoter needs to have some of the following: 1) They have interesting topics to talk about 2) They are practiced/skilled at speaking 3) They are involved in some way in the community 4) They network within and outside of their ‘tribe’ 5) They make a point of asking for keynotes I know many practised women speakers with fresh and innovative talks and we are well covered on points one and two. And we’re not so bad at organising and volunteering for conferences & community either, so…. Could it be, points four and five is what’s holding us back? Keynotes are typically by invite. That means, the program committee gets to decide who keynotes. Those on the program committee tend to have a good network. It’s probably one of the reasons they’ve been chosen to be on the program. How are your networking skills? I’m not talking about card swapping nonsense, but ask yourself: do you have a genuine interest in engaging with people who you respect? Importantly, do you know your network will openly advocate on your behalf? Which brings me to point number five… Be open to asking to keynote. Is it just me, or is there’s this weird unwritten rule in our community that prevents us asking to keynote? It seems to me that to ‘make it’ we have to Marlene Dietrich like, sit nonchalantly in the corner waiting to be asked for our moment in the spotlight. Maybe that’s just me and not a general experience. But for those of us who are less direct I’d like to suggest you make it clear to your close network that you want to keynote? What’s more, go direct to the program committee and ask them for a spot. If the say no, ask why not? and what does it take to keynote,? Who knows you might gain some valuable insights into the process. Because no matter what skill you have, or how good you are at speaking, or how charismatic you are, there’s dozens of great speakers who can do what you do. It takes more than merit to get noticed. It takes courage to ask and you need allies who will support you along the way. Have you got what it takes? *If you’re reading this post, and you’ve keynoted in the past with a story to share about how you got to keynote, Speak Easy would love to hear it as it may help us understand what it takes to ‘get there’. I’d post a link to your blog post on the Speak Easy website (or I can post a blog).* *\*Title misappropriated from a book I found useful on this topic [“nice girls don’t get the corner office’](http://books.google.com.au/books?id=nurCAgAAQBAJ&printsec=frontcover&source=gbs%5Fge%5Fsummary%5Fr&cad=0#v=onepage&q&f=false)* ### Paying Attention to Paying Attention to Detail URL: https://www.annemariecharrett.com/paying-attention-to-paying-attention-to-detail/ Last updated: 2021-06-17T02:01:15.000Z One question I often ask a tester in an interview is what they believe are the essential skills that differentiate a good tester from a great tester. One of the common replies is “Paying attention to detail”. But what does that really mean? Start with detail. What do you mean by detail? Mrs Google offers the explanation “an individual fact or item”, but what sort of detail? Visual detail? Detail from a coding perspective? Any detail or only detail that matter? Is it detail as in ‘small stuff’ as in the Devil is in the detail? Also what exactly does “paying attention” mean? Maybe it’s one of these interpretations: - A tester is attentive as in a teacher saying “pay attention!”? As in be alert? - A tester is only observing detail? - A tester is observing detail exists and then noticing they are problems? - A tester is noticing detail without a conscious attempt to observe in a methodical manner? Going deeper, why ‘pay attention to detail’ in the first place? Is it because you’ve been told to, or because the tester genuinely wants to? Your motivation and purpose play important roles in bug finding. For example what’s your ‘attention to detail’ on being told to complete 40 test scripts in one day, compared to your attention to detail if you get made handsomely for finding a bug or winning a prestigious competition? Yes, paying attention to detail is important, but so is understanding what you are doing when ‘paying attention to detail’. In my book, there’s not enough meat on that answer to figure out if someone’s a good fit for my team. I want more. I want my testers to suck the marrow out of that question, to boil it until the flesh falls away from the bone. Professional testers¹ consciously observes systems using a multiple of models. Their maxim is “the more you see, the more you see”. And that’s only the beginning. Following observation comes evaluation. Now testers get to interrogate information by asking (either explicitly or implicitly) is there a problem? Not content with relying on one oracle they may consciously use many different oracles in their evaluation process. They then report this information in a way that’s meaningful to the people who want to hear it. So if you are a tester coming for an interview on my team and I ask you this question, please have fun with it. Show me your testing process, demonstrate it with diagrams and models and show me a bit of your testing flair. All testers pay attention to detail to some degree. What in particular do you pay attention to? ¹ by professional tester I mean someone who makes an attempt to understand and then improve their personal testing process. They tend to develop a unique approach and style to their testing through years doing, thinking, talking & writing about testing. This post is a result of a tweet I made which many testers. An interesting aside, my poor spelling was explained away by many as a purposeful trap designed to snare the unwary tester. It wasn’t, though I’m flattered that you would think that of me. > Testers, its not so much 'paying attention to detail' that makes you skilled in testing, but more knowing how to observe in the first place > — Anne-Marie Charrett (@charrett) [March 18, 2015](https://twitter.com/charrett/status/578068433754988544?ref=annemariecharrett.com) ### Bobbing for Embedded Apples URL: https://www.annemariecharrett.com/bobbing-for-embedded-apples/ Last updated: 2022-07-03T03:11:49.000Z One of my first recollections of physics is the image of Archimedes running down the street, dripping wet from his bath and shouting: “Eureka I found it!” on discovering his principle of fluid displacement to measure the force. Add to that Isaac Newton who quietly sat under an apple tree, musing the day away until he discovered his laws of motion, one which states; *For every action there is an equal and opposite reaction..* Happy days… Many companies want to improve their testing, particularly if that improvement is translated into reduced time or cost. To achieve this, there’s a big trend to embed testers into development teams. There’s no longer ‘us’ and ‘them’ but a harmonious ‘we’. The wall of independence is torn down and replaced by a gleaming whiteboard emblazoned with the banner ‘Quality is a team responsibility. The reality though is that just like Archimedes in his bath, embedding testers into a team of developers are going to create displacement and cause a reaction. This is common sense. Put one tester into a team of multiple developers and it’s going to change the team dynamics. Add to the mix, that the tester will most likely become a point of constraint disrupting what was perhaps a seamless flow of stories into the Done column and it’s no wonder the apple cart gets upset. For example, developers discover they need to get more involved in testing and decision-making. That can be a big mindset change if traditionally developers are used to handing work over to testers (as opposed to receiving it from them). Testers need to change and adapt too. They have to let go of control over all the testing and entrust the developers to help them test. Again big mindset change for testers who traditionally rely on empirical evidence than a developer's word to evaluate quality. Why then, do we seem surprised when we face resistance and/or confusion when these changes are attempted? This is our brave new world. I wonder where we will all end up? Whether a team develops a true and meaningful relationship or simply an uneasy alliance is I guess up to how much both testers and developers are prepared to appreciate each other’s challenges. One way we can help each other out is to be supportive as opposed to defensive when people face the impact of changes and perhaps feel displaced and confused. How much we are prepared to let go of our assumptions and prejudices about each other will also play a big part in how ‘successful’ these experiments are deemed to be. Exciting times indeed! ### How's your signal to noise ratio going? URL: https://www.annemariecharrett.com/hows-your-signal-to-noise-ratio-going/ Last updated: 2022-10-08T03:36:56.000Z It's not only engineers that need to deal with [S/N (Signal to Noise Ratio). ](http://en.wikipedia.org/wiki/Signal-to-noise%5Fratio?ref=annemariecharrett.com) Test Managers have to deal with lots of noise, manage projects, deal with stakeholders, identify potential future risks, maintain test environments, hire testers, and meetings, meetings & meetings. And traditionally, when you sign up for the test manager role, you agree to that. Test Managers deal with the noise so testers can get on with their job – testing. But is this really what is required? Did the reporting, the stats, the work allocation, the test strategy, and did I mention the meetings? It's all STUFF. There's always STUFF to do as a test manager. So if we don't have STUFF to do, we go out and look for STUFF. We roll our eyes at all the STUFF we have to do, but secretly we like it. It makes us feel important and keeps us busy. Recently, I did a peer review with my team. I asked them to review my work anonymously. One question I asked them was, "what should I start doing more of?". The resounding signal was loud and clear. My team wanted me to increase the amount of coaching and training within the team. So I stopped doing STUFF. I dropped optional meetings, distributed recruitment, and worried less about planning for 'the future'. Instead, I test and encourage other testers to pair with me as I do. Or encourage them to invite me over to test with them. That way, I'm sharing my knowledge and expertise. It's been hard to let go of the high-level STUFF, but in some ways, these management-type activities are performed by most managers. However, very few people can train and coach testers. How's your S/N ratio going? ### Hi, my name is Done and I'm conflicted URL: https://www.annemariecharrett.com/hi-my-name-is-done-and-im-conflicted/ Last updated: 2021-06-15T09:28:33.000Z If there is ever one word that highlights the difference between a tester and a developer’s mindset it has to be the word done. Developers¹ tend think of done as a form of sign off. A story is done when the code is complete. For many developers, it’s when the code is complete, tested and deployed. Done is a sign of completion, of moving onto something else. Testers² look at Done as the beginning of a quest, an exploration. Done is to be prodded, probed, explored and dissected. Under what conditions can ‘done’ fail? What data tests the limits of Done? How about if two Done’s are put together, how will they behave? With these two different mindsets it’s no surprise that at times there is conflict and disagreement. Most testers (most people for that matter) shy away from conflict in order to maintain team harmony. Instead, they try to gain agreement upfront on Done. The goal is clarity and scope definition. Make done clear upfront (before coding begins) and it lessens the conflict later. In many companies, conflict is seen as a ‘bad thing’. Being in conflict suggests that you’re not a team player. But conflict is a not always bad. According to the 5 dysfunctions of a team by Patrick Lencioni conflict is healthy indicator of trust and ought to be encouraged. And testers must not forget that our primary role in a team is to raise uncertainty about Done. This has to come ahead of wanting to be everyone’s friend and being accepted. The reality is, if we are doing our job we will be testing the limits of preconceptions of Done. Because as appealing as it is to think of Done in terms of black and white, zero and one, the reality is a lot different. Done is subtle and muted with hidden dimensions and unknown crevices. Exploring and shining a light on these dark corners generates new information. That information helps mould and develop our understanding of Done. The more we test, the better this becomes. Whether this new information turns out to be accepted or rejected is to some extent irrelevant, both contribute to fleshing out our understanding. So sure, have your discussions on ‘Done’ before code is written, but let’s realise that it’s only the beginning not something final written in concrete. Allow testing and testers to expands that understanding. In fact, I would go as far to say that true harmony is having a mutual goal of building our understanding of what Done means. Who knows? Maybe through that mutual goal can real trust and respect be built within a team. ¹ ² generalisations ### A Developer's Ode to a Tester URL: https://www.annemariecharrett.com/developers-ode-tester/ Last updated: 2021-06-18T06:04:19.000Z Oh tester why dost thou despair? The code is right of this we are aware! We verify. We know what we do know No need to doubt and think of all this woe! Instead be bright and bring us certainty, Let Done be Done, thus ends this homily! ### Nobody — calls me — chicken URL: https://www.annemariecharrett.com/disengage/ Last updated: 2021-06-20T01:00:45.000Z One of the morals of the [Back to The Future](http://backtothefuture.wikia.com/wiki/Chicken?ref=annemariecharrett.com) series is being able to walk away from a fight. It took three movies for Marty McFly to learn this self-control. ![Nobody calls me chicken](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/nobodycallsmechicken.jpeg) Walking away from a twitter storm One thing that the scriptwriters failed to predict was the birth of speaking your mind in 140 characters, aka Twitter. If they had, it would be easy to see how Marty might have been pulled in to a twitter diatribe and feel unable to resist responding. It’s easy to engage on Twitter. It’s fun and easy to throw out ideas, thoughts and it’s mildly useful for debate. My personal experience though is that it’s much harder to disengage. I feel compelled to reply to a challenge. It’s as if each tweet directed at me is a personal call to respond (sometimes it is). As much as I want to ignore and avoid, I find myself compelled to return and to respond. My reasoning mind tells me, desist, desist, but my ego overrides this. I must have the final word! There comes a point in any twitter engagement when you realise the conversation is little about debate and more about chest beating. When I’ve come to this realisation, I’ve lost the battle. I’m no longer in control regardless of having the last word or not. There’s little dignity in winning such a battle. We need to learn the art of disengagement, the ability to walk away without feeling somehow less of a person. It’s important to engage, but it’s also important to be able to disengage. I’ve come up with some heuristics to help me battle the McFly syndrome. **Yes, And Heuristic** I got this from Lynne Cazeally's book Create Change. Instead of think ‘yes but’, think ‘Yes and..’. .it goes some way to appearing collaborative, perhaps reducing the antagonism in the twitter conversation. **How about this? Heuristic** Another Lynne Cazeally suggestion. It uses a lot of characters but you can apply the sentiment to help sound more congenial. **Rule of Three Heuristic** Sometimes, attempting to understand other reasons why someone might write something helps you to walk away. Taken from Jerry Weinberg’s rule of three. **Out to Lunch Heuristic** I’ve seen people use this occasionally where they excuse the challenge to go out and walk the dog, feed the kids etc. I haven’t tried it myself but its a method of walking away with some grace. Even better if the reason is valid. **Blank Wall** Simply don’t respond. Oh to have the willpower to apply this, especially in the heat of battle! **Blocking Heuristic.** A crude yet highly effective way of not knowing is someone is responding to you or not. You are now blissfully unaware. The downside is that you will never hear anything that this person has to say. You may consider this a good thing. **Turn off Twitter** The ultimate solution and something a few people have resorted to. Not only does Twitter seem to bring out the worst in people it’s incredibly time-consuming. Ask yourself do you really need it? What tactics do you use to help you disengage from a twitter war? ### Take the 'Crappy Work' Litmus Test URL: https://www.annemariecharrett.com/take-crappy-work-litmus-test/ Last updated: 2021-06-17T00:06:54.000Z We’ve placed a ban on crappy work within my test team. From now on, we declare that the testing team will refuse to do crappy work. The challenge is in knowing how you're doing good work or crappy work? This is why I’ve created this simple 5 minute ‘Crappy Work’™ ² test to help any tester to figure out if you’re doing crappy work or not. ¹ 1) Do I fully understand what I’ve been asked to do? 2) Why am I doing this task? 3) Who will benefit, and I have spoken to them ? 4) Am I doing this task simply because its part of the process? 5) If I think it’s crappy work, how can I make it valuable? I’m sure there are plenty more ‘crappy work’ questions that would be useful to add, but my 5 minutes is up. **Why not share your ‘crappy work’ litmus tests?** ¹ Maverick Tester takes no responsibility if you take this quiz and continue to do crappy work ² It’s a 5 minute quiz because it took me 5 minutes to think it up. It’s trademarked so I can sell you a certificate in passing the ‘Crappy Work’ test, thereby making a whole lot of money out of it. ### How will Continuous Delivery affect network traffic? URL: https://www.annemariecharrett.com/will-continuous-delivery-affect-traffic/ Last updated: 2021-06-15T10:04:14.000Z I was recently in New York and had a chance to walk along the High Line. The High Line is a disused overhead train line converted into a walkway and park. It’s a really lovely walk. I was interested to learn that [the train line had been built in the 1930’s but had become disused by 1980’s.](http://www.thehighline.org/about/high-line-at-the-rail-yards/history?ref=annemariecharrett.com) It’s main purpose had been to transport meat and produce to manhattan from the upper west side. With the advent of trucks the train line fell into disuse. It was about to be torn down when a small group of inspired locals advocated it be turned into a park. The movement grew and now the disused train line is a lovely walk and respite from the busy traffic. I think it’s interesting that the train line fell into disuse in the first place. Why were so many companies eager to drop the train line in place of trucks? My guess is they wanted the ability to freight cargo when they wanted. Rather than delivering in one bulk they delivered smaller amounts more frequently. That way they could become more responsive to their customers needs. That’s what we’re aiming to do with continuous delivery. We want to be able to deliver in a faster way, to be more responsive to our customers needs. I wonder if our existing network will be able to handle it though? Look at the traffic jam that is NYC and it makes me wonder that with the ability over faster and more frequent delivery comes the cost of greater traffic on our networks. Remember, if it was just your company wanting to deliver, of course there’s sufficient bandwidth, but when everyone has the same idea will our current network be able to handle it? I guess only time will tell! ### My Testing Manifesto 2014 URL: https://www.annemariecharrett.com/testing-manifesto-2014/ Last updated: 2021-06-13T03:31:01.000Z It’s my first day in permanent employment for, oh, about 20 years. I feel a little giddy, like someone’s first day of school – nervous but excited. Unlike my first day of school, I have some clear goals and ideas I want to implement. I thought I might outline them here to help remind me of what I want to achieve and also to see how different it turns out. ## Testing Philosophies - Testing is an skilled activity(not a phase) that all, to some degree can acquire. - Testers need autonomy to make decisions, to develop and perform excellent testing. - Quality is something we all care about, though it means different things to different people. - Every test has a cost (design, building, maintaining, reporting) ## Goals for Testing To develop a company wide reputation for excellent testing To develop a test team that is able to handle testing problems with courage, skill and humility. To coach and help develop the skill of testing with whoever may need it To identify where testing is occurring and help augment that To develop and the grow the test team in size, skill and expertise. To engage with and support the testing community ## Personal Goals To acquire knowledge in testing within a continuous deployment, delivery environment To learn more about functional programming To be able to identify how to repair code To work with integrity and within the bounds of what I consider ethical ### Dropping the Ball URL: https://www.annemariecharrett.com/dropping-ball/ Last updated: 2021-06-15T02:27:22.000Z Does the thought of ‘dropping the ball’ fill you with dread ? Perhaps you feel you will let people down, or more importantly yourself? Here’s a thought experiment: What if you actually let the ball drop? Do you know what might happen? Will the sky fall? Are people let down? If so, is that so bad? We all fail at some point in time in our lives. We don’t expect perfection from others, but for some reason expect it from ourselves. But that’s not physically possible is it? Expecting perfection in this way is about as practical as promising perfect software right? So next time you're spreading raspberry jam too thinly consider giving yourself permission to drop the ball. After all as a tester you owe it to yourself to try, don’t you? *Apologies for mixed metaphors 🙂* ### The fine art of being precise URL: https://www.annemariecharrett.com/the-fine-art-of-being-precise/ Last updated: 2021-06-18T00:36:13.000Z Jon Bach this morning wrote a post about how we need to be precise in our thinking. Thank you Jon, its a lovely honest piece with lots of wisdom. But it got me thinking how sometimes precision can let us down too. For instance, we can get fooled into thinking that being precise always matters. There are many situations where vagary(what a wonderful word!) is incredibly useful. When my husbands asks me how my day was, I don’t reply with “What do you mean by day?”, instead I typically respond with ‘fine’ or something equally inane. What’s important here is not the precision of the question or even the precision of the answer. My husband’s not that interested in my day at all but it’s his way of asking “are you ok?”. My answer though perhaps a little short, is important too, though it’s not really the answer that matters, its the tone of my answer that he’s listening out for. You see this vagary in software teams that work closely together. Over time, these teams have developed their own language and don’t feel the need to question every definition. Team members pick up cues from body language and follow unwritten rules without much thought. I see this ability to follow such rules without question as a way of building trust. Often teams that work together for a while just ‘know’. They’ve built up a certain amount of tacit knowledge which doesn’t need to be openly discussed. Unfortunately many of us have, at one point in time, worked in situations where this culture (for want of a better word) is not so healthy. I worked in one such company where open questioning was implicitly discouraged to the point where a developer worked on the wrong story for a whole iteration. I’ve seen many a tester battered and torn from attempting to pull down those unwritten walls of silence and ambiguity. But what’s important here is we recognise that in certain situations its appropriate for us to be loose in our language. In fact, I often hold off from being precise especially if I’m new to a team or client. Instead, I sit and listen, waiting for ambiguity to bubble up and emerge. This intentioned act of silence allows me to witness rather than be told where implicit assumptions may fester. So while being able to be precise is an important testing skill, another important one is the ability to identify when and where precision is most required, and when and where we can allow ourselves to be a little more accommodating. ### Hanging up my boots URL: https://www.annemariecharrett.com/hanging-boots/ Last updated: 2021-06-18T06:17:59.000Z My family and I arrived in Dublin on a cold dark wintry November night in 2008\. At least metaphorically speaking it was. It was right after the GFC and we watched a country and economy wrestle with the prospect of becoming bankrupt. Regardless, Dublin’s IT and entrepreneurial spirit flourished. People who were made redundant invested their expertise into new ventures. There was a sense of familiarity in being in a recession (The common term for the GFC was recession 2.0) but also that the future was very much up to themselves. I decided to start an Irish testers meetup, an opportunity for testers to share their expertise and learn from each other. Our first meetup had 4 testers. It never grew beyond that. I discovered that there was more to running a meetup than post on a blog. I learned that testers cannot thrive on testing alone, and that having a nibble or two and a drink goes a long way to attracting turn out. Having noteworthy speakers also helps. So when I returned to Australia in 2010, and heard of a Sydney Testers Meetup I was keen to join. I discovered a hardy band of testers. Amongst them were Trish Khoo, Marlena Compton and Bruce McLeod. But they had similar problem as I had in Dublin. It was hard to get the word out and attendance was poor. Sponsorship by Softed and getting some few heavy hitting speakers quickly changed that. We had James Bach, Elisabeth Hendrickson, Scott Barber come along and speak. Trish has fantastic ideas about different types of activities. We had games nights and book nights. Julietta Jung came along and brought along enthusiasm and excellent pizza ordering skills. The Sydney Testers Meetup rapidly grew but not without its ups and downs. We’ve lost sponsorship, turned down sponsorship and for a while lived without any sponsorship. We had have committee members move to far away lands. But throughout it all we managed to maintain the spirit of the Sydney Testers Meetup. Today Attribute Testing sponsor the meetup that has a 600 strong membership. It’s time now for me to hang up my boots as organiser of the meetup. It’s been a blast and I’ve loved seeing people become infected by testing. I’m leaving the STM in safe hands. Richard Robinson and Devesh Maheshwari will be taking over as organisers. I wish them the best and look forward to seeing the STM do great things. ### Scientia potentia est URL: https://www.annemariecharrett.com/scientia-potentia-est/ Last updated: 2021-06-25T07:02:23.000Z “Knowledge is power” Jerry Weinberg cites courage as the most important trait in a tester. [Quoting Kipling, Jerry says testers](http://blog.utest.com/testing-the-limits-with-gerald-weinberg/?ref=annemariecharrett.com) need to “keep your head when all about you are losing theirs and blaming it on you.” But I see another type of courage at play in software testing. Testers are foremost learners. Through enquiry, they learn about a system. The information they gather facilitates many kinds of decision making from releasing to designing new features. Observe great testers and you will discover an insatiable desire to learn more, not only about the product, but the world around us, often incorporating what they learn into their testing. For many of us, discovering that our learning is within our control and within our means, can itself be a road of discovery. It takes courage to start that journey, but it also take courage to continue along its path. Young Luke Skywalker found the ‘Force’ early on in life. Yoda helped him connect with that power, but even then, he needed guidance and a reminder to ‘**Use the Force**’ when up against the evil Empire. Some of us need that reminder now and then. We know we have the ability to learn, and we know of its power, but we forget to use it. Especially when things get tough. “Knowledge is power” When things don’t go the way you want, when the pressures of daily life cloud your ambitions and goals, it can be easy to lose site of learning. Here’s what I’ve discovered though, through focusing on learning in these times you gain great strength. Will the actual knowledge you learn help you succeed? Perhaps. What really counts is that through learning comes power in the form of ownership and self belief. You may not be able to control the situation at hand, but through being open to and owning you're learning, you regain a sense of control and a sense of focus. So when the dog bites, when the bee stings and when you’re feeling sad, remember there is solace in learning. It’s not only as an escape, or way of learning how to deal with the situation, but helps you take ownership and responsibility over the next step. Who knows, learning may be the just the ticket you need to recharge those batteries, giving you the juice to continue on your journey or perhaps, dump it for a different destination. *This post was first published on [medium](https://medium.com/p/eddbb97a5eac?ref=annemariecharrett.com). [Mauri Edo ](https://twitter.com/Mauri%5FEdo?ref=annemariecharrett.com)tweeted about it recently and I’ve decided to post it here too because I like it so much.* ### Why waterfall kicks ass URL: https://www.annemariecharrett.com/waterfall-kicks-ass/ Last updated: 2021-06-25T22:10:27.000Z I read a blog post about why [waterfall is NEVER the right approach](https://www.netobjectives.com/blogs/waterfall-never-right-approach?ref=annemariecharrett.com) and I feel compelled to respond to what’s touted as the waterfall mindset. Here’s a copy of the paragraph, but you can read the whole post on the above link to get a better sense of context. > I actually don’t believe adopting waterfall as an approach is *ever* a good choice. Waterfall comes with the following mindset: - we don’t need feedback between the steps of requirements, analysis, design, code, test - we can hand work off - big batches are ok since they enable us to be more efficient - specialised skills working only on their specialty is good - we can understand the work to be done before we do it - written requirements can specify what we need Putting aside for now, the use of absolutes, lets address this *waterfall mindset*: ## 1) we don’t need feedback between the steps of requirements, analysis, design, code, test I’ve worked in both waterfall and agile over the years. In those ‘bad old days’ where no-one appreciated collaboration, we used to extensively review requirements. This meant that testers offered valuable input into requirements before any piece of code was developed. Since the invention of ‘agile’ almost everyone has discovered the 3 amigos, but honestly, this is not an agile concept, it existed way before agile was even thought of. ## 2) we can hand work off Honestly, I don’t understand this sentence. I’m serious. I can think of many reasons why handing work to others is a good thing. For instance, if I’ve got too much work I’m in danger of becoming a bottleneck, and I hand some of my work over to someone else. If that’s a waterfall mindset, its one I like to have. ## 3) big batches are ok since they enable us to be more efficient What do you mean by efficient here? Does it mean quicker, better quality, less waste? Efficient in what? Design, Writing code? Testing? Support? If I wish to carry 20 oranges from point A to point B, is it more efficient to carry them one at a time, or do I get a bag and carry them all together? Try delivering to a customer 1/4 of an IC circuit and request feedback? Sometimes delivering something in one batch IS the the more efficient way to proceed. In waterfall, we did have teams, and work was allocated into smaller isolated tasks. It was rare one person developed the whole product. In fact, when I worked on telecommunication systems in the nineties, the concept of frameworks was being introduced, segregating data from its transportation method, allowing for people to work on separate parts of a system in parallel to each other. ## 4) specialised skills working only on their specialty is good When I started working at Nortel Networks in 1994 it was all waterfall, except we didn’t call it waterfall then, we called it software development. Nortel Networks had a policy that encouraged developers and testers to spend time working in each others ‘specialisation’ area. For six months I became a developer working to deliver software. I was taught C++ and object oriented design principles, so I’m uncertain why you think this is a waterfall mindset? ## 5) we can understand the work to be done before we do it Why is being able to understand work before you begin considered a ‘bad’ idea? I think this phrase is too ambiguous to be able to discuss with any merit. ## 6) written requirements can specify what we need Is it the word requirement, or is it the fact that it’s written that makes this a ‘bad’ mindset? Yes we do have written requirements in waterfall. We also have written user stories in agile, so what is the point? Just because stories are written in confluence doesn’t make them any less written. In the bad old waterfall days, I facilitated workshops with the business and IT teams to determine and understand risk. Lots of verbal collaboration, lots of whiteboard discussions. I’ve worked in ‘agile’ teams were little communication takes place, no stand-ups nothing. In fact, one developer spent a week working on the wrong story without realising it. I’ve worked on some fantastic waterfall projects that blew the socks of some really crappy agile teams I’ve worked with recently. In these waterfall projects, I’ve worked in harmony with great developers and testers, working closely together. We were afforded sufficient time to examine the system as a whole instead of its parts, something that these days appears to be a bit of a luxury. I’ve worked in environments that develop hardware, firmware and software where upfront design and ‘big batch’ systems thinking helped us understand that we were not merely developing code, but we were attempting to solve a problem. It's easy to conflate poor software development practices with waterfall, just as its easy to conflate an agile approach with ‘good’ practice. To me the biggest change since those days are technological ones which allows us develop, integrate and compile it quickly and relatively cheaply. It’s the technology that has allowed us to develop in these small tasks that we are familiar with today. In the early nineties the concept of layering and isolating according to purpose was coming into play but we simply didn’t have the sophisticated systems that allowed us to develop in a way we wanted to. A second important change was the conception of the agile manifesto. To me the agile manifesto is a stroke of genius. People who had the courage to espouse ideology that placed people over process, tools or artefacts. For many, this has changed how we think about developing software. But let's not forget, that the agile manifesto was developed by people who worked in what you call a waterfall environment. It seems to me these people had quite a different mindset than the one suggested above. It seems to me, those who developed the agile manifesto did so with ideas of collaboration and an emphasis on the ‘humanness’ of developing software. Do those ideas come about as a result of what was done badly in waterfall or because of what they saw was working well? I suspect it was a little of both. Don’t get me wrong. Lots of mistakes were made pre agile days. There was an idea of segregation between developer and tester in an attempt to avoid bias from developers. I’m glad we’ve gotten over that idea. But many of the mistakes we made in those days we’re still making now. Most software teams fail to understand testing and attempt to measure it using means that appear to have no direct correlation to quality. Many teams use measurement to lock down estimates as opposed to using them as a source of information for change. Go to an agile conference and count the number of talks on process and methodologies and frameworks. Look at today’s obsession with continuous delivery as a process. What happened to the people folks? It’s easy to understand why. The agile manifesto is bloody hard to implement. Its much easier to point at a tool or a process and say “thats what we do” because it's explicit, it’s easy to see. Programming & testing are human activities and are much harder to identify and talk about. It’s hard to describe and transfer these skills. The best way I know of is to actually perform the tasks. We need a little more humility in acknowledging the great shoulders that agile stands on. It's simplistic to identify in hindsight a ‘waterfall’ mindset. Such a thing did not exist. Instead let's view them as the agile manifesto encourages us to do, to view them as people attempting to deliver quality software just like we are attempting to do today. ### Are you serious? URL: https://www.annemariecharrett.com/serious/ Last updated: 2021-06-17T00:08:37.000Z Seriously, how serious are you about testing? Let's presume you study the craft of testing. Does that make you a serious tester? If you answer yes to this question, congratulations. You are on your way to becoming a serious tester. Now ask yourself this question: “Do you take yourself seriously?” If you want to be taken seriously about testing, you need to take yourself seriously. Note the difference here. Taking yourself seriously is much larger than being a serious tester. Taking yourself seriously means you avoid behaviour and thinking such as: “I will put myself down in front of others to make them feel better about themselves” “I resort to behaving childishly when placed in pressure situations” “I hand over power in order to avoid conflict” “I feel like a fake even though my actions demonstrate otherwise” I know this, because its only recently I realised that I haven’t been taking myself so seriously. When you stop speaking to yourself in such a way and start taking yourself seriously, a wonderful thing happens. You start to believe in yourself. In fact, you have to. You owe it to yourself to do so. I’ve discovered a new strength in this self belief. It means I have courage and strength to stand up for what I want. In doing so, I give myself the respect and honour for all the hard work I have put in. So, let me ask the question again: Do you take yourself seriously? *Expression epitomised in Rage comics following a[ David Silverman interview of Fox News by Bill O’Reilly](http://knowyourmeme.com/memes/are-you-serious-face-seriously?ref=annemariecharrett.com)* ### Are we there yet? URL: https://www.annemariecharrett.com/yet/ Last updated: 2021-06-18T06:11:26.000Z Ever been on a long car journey packed with young kids? I remember these eight-hour drives with six kids crammed into a car driving to our holiday destination. My younger brother, in particular, was annoying, constantly asking questions and irritating his sisters. By far the most irritating question (especially to our parents) was: Are we there yet? This line of questioning would normally begin half an hour into the journey and would be constantly repeated throughout the journey. This potent cocktail of repetitive questioning usually resulted in one of my parents (usually my Dad) exploding in frustration, yelling at us all to be quiet. This was typically followed by a threat of being dumped on the side of the road. (He actually carried out on his threat once, dumping my brother, who unfazed promptly hid in some nearby field, resulting in the whole carload having to search for him.) But it was a fair question for us kids. We had no real sense of time or distance to help gauge how far we had come and had to go. We also were totally bored with no iPods or stuff to entertain us. Singing (very Von Trapp like) took us only so far. Counting number plates helped a little. And remember, we were going on holidays, the mere thought conjured up more excitement than our poor little bodies could hold. The journey was always going to be arduous when faced with a destination the held so much promise. As a parent myself, I have a little more sympathy for my parents. Of course, we have the luxury of allowing our kids to be immersed in some tacky iPod game, distracting them to the point they forget they are going on holidays. But I get it. I get that its really hard to explain to someone with little understanding of distance or time, how long something is going to take. When testers ask me how we know when we are done in Exploratory Testing, I am faced with a similar challenge. How do I help a tester understand when they are done? Pointing them to the excellent list of [Stopping Heuristics on Michael Bolton’s blog ](http://www.developsense.com/blog/2009/09/when-do-we-stop-test/?ref=annemariecharrett.com)helps but how do you apply them? Some of them are easier than others. For example, with the “Time’s up!” heuristic, it's pretty simple to apply. But take something like the Flatline Heuristic. The Flatline heuristic tells us to stop when “No matter what we do, we’re getting the same result.” But as Michael points out, there are hidden risks to this. For example, it may be that there is no new information, but it also may mean we have insufficiently explored the application in depth. In this situation, how do we know what to do? Like many things in testing, there is no clear-cut answer to this. A considered answer requires an understanding of what’s happening around testing, and the implications of the decision being made. Hence the inclusion of the word heuristic. I’ve found a conversation with stakeholders around stopping heuristics \*before\* testing starts a useful exercise. Knowing that you have a time limit on your testing goes a long way to preventing tester angst about when to stop. Include in that conversation a discussion on what ‘done’ means including into that the impossibility of complete testing. Stakeholders who get that bugs may be missed can influence which stopping heuristics you use. Like kids in the back seat, as we test we need to repeatedly ask ourselves the question “are we done yet?”. It may be useful to use our emotions to trigger this question. For example, if I’m bored, does that mean I’m done – or does it mean I need to change something in my testing? If I’m anxious does that mean I’m about to hit some constraint in the form of time? If I’m angry, does that mean my information is being ignored and maybe I need to address that instead of raising a tsunami of bugs? If I’m confused, does that mean I need to explore more? Emotions like these can be useful indicators of when to ask if you’re done. Again Michael Bolton has done lots of work in this area. I’ve also found that in times of deep uncertainty its always a good idea to draw on the “phone a friend” card and ask someone more experienced than you for their opinion. There’s no shame in this, these are tough questions to answer. An outsider may have insight or additional knowledge that you’ve overlooked. Building relationships and credibility with those around will also go a long way to helping you in situations when that significant bug is missed. And as in most of testing, articulating your process and your decision making helps to demonstrate diligence and considered testing. ### Question with sprinkle of humility on the side URL: https://www.annemariecharrett.com/influential-tester/ Last updated: 2021-06-17T21:06:21.000Z Michael Bolton tweeted yesterday: > Testers: let’s not obsess over trying to be influential, and work on being helpful. And let’s be careful to offer—not inflict—help. [#testing](https://twitter.com/search?q=%23testing&src=hash&ref=annemariecharrett.com) > — Michael Bolton (@michaelbolton) [October 16, 2013](https://twitter.com/michaelbolton/statuses/390604017019416576?ref=annemariecharrett.com) Why do testers insist on trying to be influential? I suspect part of the reason is that part of a tester’s job is to recognise problems. Too often , testers see that the \*real\* problem is not the software itself, but the process behind the software and go into bug prevention mode. That sort of change requires influence. Often though, we simply don’t have the authority or the influence to do make change. We may moan and tear our hair out in frustration, but at the end of the day, without the mandate to make change and the influence to implement it, there’s little we can do to change an organisations culture or process. Trying do do so regardless, can lead to a sense of helplessness and even slowly, over time, a sense of powerlessness. I suspect most of us at one time or another have felt like this. It’s not a great position to be in. I know I’ve been there. I tried to change the culture of a company (company no less!) that had some negative ideas about testing and teamwork in general. (I’m talking about this at Eurostar this year). As a consultant, I probably should have known better, but I argued (to myself) that the culture was affecting the tester’s ability to perform their job. It needed to change! We testers are gifted with keen observation skills and the nature of our role sometimes means we get to see and recognise problems that perhaps others don’t. But lets not get away with ourselves. Without a mandate for change, we become close to the schoolyard tale tattler, dobbing in on everyone and despised by all (including often the teacher). I failed to recognise that I hadn’t the authority or the influence to make these sorts of changes. I fell into a classic consultants trap. I really should have known better. It’s not that we \*should\* or \*should not\* ignore these problems. Often these challenges are too complex to be solved with simple answers and probably need to be dealt with on a case by case basis. But I think adopting the tone of helper (or servant) goes a long way to contributing to an answer. In some cases a question sprinkled with a little humility can be more helpful than smothering the problem with large doses of tester sauce. I hope I’ll remember that next time! ### Yu Han on what Software Testing means to me URL: https://www.annemariecharrett.com/software-testing-at-uts/ Last updated: 2021-06-16T20:58:47.000Z *Last year I had the honour of teaching post graduate students the subject[ of software testing ](http://handbook.uts.edu.au/subjects/32571.html?ref=annemariecharrett.com)at the [University of Technology Sydney.](http://handbook.uts.edu.au/subjects/32571.html?ref=annemariecharrett.com) I asked students if they would like to write a post on testing on my blog. Yu Han did, and here it is.* The subject of Enterprise Software Testing demonstrated the existing and interesting aspects of testing. Those lectures and the project in Suncorp are unforgettable experiences. During the classes, I felt that, most of time, I was acting like a child, playing different kinds of games and drawing pictures with colorful pens. But at the end, there would be some serious discussions, analyses and reporting always broke my sanity. Those reflections make me realize that my actions and thoughts were more complicated than I could realise, which encouraged me to keep reviewing what I did and exploring how I thought. By doing that, I better understood the purpose behind those activities, and I am being able to sense the essence of what a good testing could be. I am aware of that my mind prefers to use memory or imagination to fill the gap between the reality and the information once I have received. By linking their similarities, I can better understand the information. But as soon as I came to this stage, my thinking could stop going deeper. I may feel satisfied with the simple explanation, or could be distracted by other information which will draw my attention to something else. Then I may lose the chance to find out the depth meaning of the information or even misunderstand it. Now I am interested in paying more attention on my flow of thinking. By questioning appeared ideas could be a way to slow it down, which may clarify the understanding or identify potential obstacles hiding behind. It could also be possible to bring back those ideas or considerations which were once brought up then been omitted or developed during the incredible thinking speed. Those ideas and considerations could be questionable as soon as I try to challenge them. This could turn out that there are missing facts behind the imagination which I feel reasonable but not actually practical. Once I try to gain the evidence to support those ideas, I could realize they are incorrect or unproved. I may need to confirm them before I go further, especially when the goal is based on such ideas. Like those assumptions made in the Big-Track exercise, our group was needed to test our ideas of what other buttons can do, before we finally test how the targeted button works. We questioned our ideas but hard to move forward until we know which ones were correct. We came up with many hypothesis, but failed to prove them at once in practice. After we had some sort of understanding, we found out that we should confirm those assumptions before we continued, which led us to come up a debugging strategy to process our tests. It appears that questioning the information not only could encourage us to seek the truth but also could inspire us to develop our ideas. In this sense, critical thinking could help one to wisely seek information and to reorganize the information into knowledge for idea development. This now also reminds me the concept of Exploratory Testing. In the previous example, we learned the mechanism, built the tests and proved the ideas all by interacting and exploring with the actual system. It seems that Exploratory Testing could be a natural way to build and run tests while we also need to learn about the system. By understanding how it works, we could come up with how to do the test and find bugs. However, it’s difficult to tell how much time I need to finish the task. Thanks from the experience in Suncorp, I see the efficacy of Scripted Testing. Our team only performed the testing within several hours. We didn’t need to worry about anything else, knowing other parts of the system and even the depth of the targeted section. It did take a couple of weeks for us to learn the background information and to write the strategy and test scripts, but we could save most of the time if now we are going to test another section. It makes me feel that with a good development and a clear testing goal, the job can be easily done by writing and following test scripts. But it is true that I also feel difficult to understand the system by reading documents, having meetings and even watching demonstrations. It seems easier for me to concentrate and memorize such information when I can apply it, which means learning the system by actually using it. I am inexperienced to conclude what a good testing is or which testing method is more superior, but running the system to get reliable information, questioning the information to dig insightful connections, finding actual evidence to support the thinking seem to be the correct manners in testing. Thanks for this subject which let me feel the enjoyment of testing, and provided a real business environment to gain practical experience. I will be happy to get involved in such field and learn more in the future. *I’ll be teaching this subject at UTS again in February next year. The [course](http://handbook.uts.edu.au/subjects/32571.html?ref=annemariecharrett.com) is open to students and practitioners alike .* ### Dear Helen, in response to your job application as a tester URL: https://www.annemariecharrett.com/dear-helen-in-response-to-your-job-application-as-a-tester/ Last updated: 2021-06-18T06:18:40.000Z *I wrote this email to Helen today who emailed me a letter seeking work. I thought it pretty much summarises what Testing Times stands for.* Dear Helen, Thanks for contacting me through my website. Firstly, I want to congratulate you. Not many people bother to read my website properly and send me the information I require, my estimation of you as a tester as increased a notch! *I purposefully ask testers to only send me a cover letter explaining why they want to work for me. Most testers send in a resume.* [Testing Times ](https://testingtimes.com.au/?ref=annemariecharrett.com)is not a typical software testing consultancy. Based on many years of experience, we’ve come to realise that the majority of testing performed is rubbish. Unrealistic schedules, stupid estimations, test strategies and plans that no-one reads or cares about, metrics that make no sense. We’ve decided that enough is enough, and we will only perform quality testing. If this type of consultancy interests you read on. We see ourselves as context driven testers (google and read up) and we believe this is one way to promote quality testing. Be aware, we only work with truly passionate testers. This doesn’t necessarily mean lots of technical proficiency, but we expect you to have studied testing, read blogs and have an opinion on what quality testing is. If this sounds like you, send your resume in! Regards Anne-Marie ### Knowing the unknown URL: https://www.annemariecharrett.com/modelling-software/ Last updated: 2021-06-18T00:40:50.000Z As a teenager, I remember being struck by the poignancy of the tomb of the unknown soldier. I’m not sure which tomb it was, in which city. I don’t recall there being one in Ireland, so perhaps it was in London. I remember feeling sad and perhaps a little understanding of the horror of war crept into me. For such a simple monument, the message was powerful. For me, the tomb itself signified a lot more than missing soldiers. Somehow it symbolises those untold stories. Who was that person, why did they die? Was it painful, did they have a wife, children? it makes me think about history too, and how really its a story told by the victor. We rarely hear the story of the defeated. So many stories untold. Roll on many, many years and I realise that we in software development, particularly in agile, we have many untold stories that only make the light of day when we find bugs in software. We fail to hear the stories that stakeholders wanted to say, but fell aside because of time pressure. We fail to hear stories that stakeholders have not realised exist. We fail to hear stories because some stakeholders weren’t seen as needed. We failed to tell the story because we simply didn’t think it was important enough.It’s a wonder software works at all! Testing to helps us uncover and tell these untold stories. How? Each bug we find, has a story behind it. It may be story of why the bug came into being in the first place. Or the story may turn out to be unimportant. Often not only do we uncover stories, we also end up adding meat the stories that exist. I find this particularly true of agile. The simplistic approach to stories that start with *“As a , I want so that I can ” .* I do understand that the point of these stories is to initiate conversation, but it’s my experience that often conversations are skipped and this skeleton like sentence ends up becoming the story. And as [Allister Scott pointed out](http://watirmelon.com/2012/10/17/where-is-the-story-in-user-stories/?ref=annemariecharrett.com) these stories would totally fail the bedtime story test performed by any 5 year old. Regardless these skeleton like stories then become converted into automated acceptance tests which significantly influences the decision to release or not. Well, in my experience anyhow. As I understand it, one of the reasons for these simplistic stories is to achieve the goal of “dealing with the problem at hand”. By focusing on only what needs to be done now, we avoid over engineering a product. Now believe me, after working on some large scale telecommunications switches in the 80’s and 90’s, I totally appreciate this sentiment. However, the drive to simplicity has I think led to deficiencies in how we model our systems. For example, we fail to recognise that firstly, some systems cannot (and perhaps should not) be modelled from a user perspective. (I’m happy to be proven wrong in this, my experience in testing r&d products and layer3 protocols leads me to believe this is the case though). Also by focusing on only the problem at hand we fail to appreciate the subtleties and impacts of the unknown unknowns. I’d like to see software development attempting to re-address this balance. When I went to Agile Australia lots of people were talking about systems thinking and my first response was “Brilliant!” but it seemed that the systems thinking was focused primarily on business systems, as opposed to products. Perhaps it's me with too narrow a focus, but I’d really like to see more discussion on how we can become better at modelling software in agile.For one thing, let's move away from telling stories ONLY from a user perspective. There are many ways to model a system and greater diversity of models may bring about deeper appreciation and understanding of the problem we're trying to solve. And so to the unknown solider. I’m glad no-one has tried to simplify his story into a sentence beginning with “As a soldier…”. The monument conjured up more questions than answers, questions about the unknown. Questions that can never be answered. He was the unknown solider and it was fitting. I guess one question to ask is this: is the unknown story a fit for agile? The title for this post is inspired by Colin Cherry’s talk at KWST3 about Johari windows. \[thanks for the spelling check Srinivas\] ### Big Trak Robots at KWST3 URL: https://www.annemariecharrett.com/big-trak-robots-at-kwst3/ Last updated: 2021-06-15T10:10:27.000Z I had a fantastic time at KWST3 this year. There were a lot of firsts for me. The first time I was in New Zealand, the first time I had been to KWST and the first time I met Brian Osman, plus a whole heap of other testers. I don’t think I’ve been to such a learning event for a while. It was truly a place of inspiration, introspection and challenge. Brian and Colin have already written about their thoughts and I will add mine too in a different post, but first I want to talk about Robots. Oliver asked me to bring over by Big Trak Robots after seeing them in action at CITCON in Sydney. I split the group into two teams and set them a testing challenge, which involved running experiments in order to determine one of the buttons. What ensued was an hour of fantastic learning, mostly for me, as I watched a group of highly skilled testers apply their minds to the exercise. The testers did some really interesting work. One team started performing fairly complicated tests, which turned out to be a real blessing for them. They then made a model of the functionality and made a hypothesis on what the solution might be. Team Two took a different tactic. They started with simple tests (a common focusing technique and one I often use) but the tests didn’t offer enough information to the testers. In the debrief that followed at the end, we had a discussion about how though simple tests are quick and easy, sometimes they fail to offer sufficient and meaningful information. Team two, recovered by defocusing and both teams offered their solution. There’s so many lessons to learn from this exercise, and depending on the group, different lessons are learned. This was one of the most enjoyable times I’ve run it, I think because the testers were skilled and could apply themselves with confidence. They also were very self-aware and so debriefing was more about letting the testers volunteer information than asking probing questions. Or maybe I’m getting better at handing over the learning to those really in charge. Andrew Robbins and Richard Robinson are running the test lab at Tasting Lets Test and the Robots are going to have their moment in the spotlight there too! See you all there! ### The engineer's curse URL: https://www.annemariecharrett.com/the-engineers-curse/ Last updated: 2021-06-16T23:36:38.000Z Its a rare luxury this week as I have the house to my own. Perhaps those of you with partners and or younger kids will identify with this sentiment! Suddenly life seems to be easy and manageable. I don’t feel responsible for looking after other people and their problems. The challenge to manage a house, be a mother and partner, run a business, organise a conference and oh yeah, do some testing is a lot easier when its only yourself to look after! When I took PSL last year, one of the ‘skills’ I realised I had was running around making sure everyone on the team was being heard and was ok. Another word for this is meddler. How, I thought could the team function without me, unless I was there to keep it together? I guess after reading the first paragraph again work isn’t the only place I fall into meddling. In a moment of retrospection, I feel my desire and ability to solve problems is sometimes more of a curse than an asset. Perhaps in my drive to solve problems, I forget something crucial. That is, often it’s not about solving a problems its about having the conversation. Earlier this year, Michael Bolton introduced me to Marshall McLuhan and his concept that “the message is the medium”. Is it possible then, that solving a problem is not as important as the process used to solve the problem? Or in other words, the conversation you have to solve a problem, is more important than the resolution of the problem you are having? A while back I read David Bohm’s book “On Dialogue”. In it, he encourages groups in dialogue to take the focus off decision making and instead put the emphasis on the process of communication.He encourages participants in the dialogue process to suspend judgement and be open to what emerges from dialogue. In this way a group can develop deeper meaning. For example, instead of trying to create a common terminology, common terminology becomes created. He also talks about the challenge in problem solving. Mostly, what we call ‘problems’ are in reality paradoxes and inherently its impossible to solve such ‘problems’. Bohm believed that the dialogue process(I haven’t tried it) is a way of acknowledging and respecting differences allowing new ideas to emerge. We all have a basic need(well I like to think we do!) to connect and understand each other. To be \*human\* if you will. It's this human need, at a tacit level that perhaps defines who we are, more than any high level problem solving skill dictated by our frontal lobes. As an engineer, I’m taught communication is essential to solve a problem. As a human, I’ve learned that it's about taking the time to include people in your day, to actively listen regardless of the outcome. Just a thought. ### Where have all the good jobs gone? URL: https://www.annemariecharrett.com/software-testing-jobs/ Last updated: 2021-06-15T09:33:01.000Z If you follow and believe the twitter conversations, it seems that the main reason for getting ISTQB certification is to pass the screening when applying for work. No ISTQB? No interview! My personal experience has been that yes, on one or two occasions I’ve failed to be interviewed based on lack of certification. Rather than see this as a negative, I see this as a blessing. After all, if your idea of a tester is that narrow, then I’m probably not suited to your company. On occasion I’ve cited ‘NO CERT’! to justify why I can’t apply for a role. “I’m so sorry, I’m not ISTQB certified…” as I edge my way to the door. I think it’s naive to rely on a certification as a means to getting work. Especially if you are a thoughtful and intelligent tester who cares about the quality of your work, and who wants to be taken seriously in the industry. But forget about certification for one minute. Are you seriously willingly going to put your career into a strangers hand who then decides your fate by a keyword? There are cleverer ways to play this game. Have you not noticed that the way companies recruit is rapidly changing? To get a job that interests you, its not good enough to send in your resume or hold a silly piece of paper with a over ornate stamp on it. Those days are long gone. Now you need passion, you need to keep up to date with whats happening in your field, you need to be committed to keeping yourself relevant. Our family has experienced this first hand when my husband was looking for work last year. He suddenly discovered at the ‘old age’ of 42 that he was unemployable. He is intelligent and personable(yes I am biased) with a first class degree in Electrical Engineering and he had made the assumption that good people always find work. But that’s not enough. Today, if you want a job that’s worthy of you, you need make sure you earn the companies respect. This is not only based on my personal experience, I’ve spoken to many recruiters in the last few months, and all seem to have similar stories. Companies are more reluctant to use recruitment agencies to find their staff. They want recruiters who know and understand the specific skills they are seeking. I’m seeing recruiters leave the industry, or re-invent themselves as specialists in one field. Other ways the industry has changed is that many recruiting companies work for one company and are in effect the procurement arm of the company. Of course, the testing industry has changed significantly too. Now that the major consultancies have successfully sold testing as a commodity, testing (or an excuse for testing) is being performed wherever people are cheapest. The adoption of Agile as a development process and its dependency on automation has also reduced the need for testers (though this is not necessarily a bad thing). The fact is, there are less testing jobs out there. That doesn’t mean there are less quality testing jobs though. While its true that the crumbs from the table need to be shared among more, there is still plenty of meat and gravy at the table. The question is, have you earned a spot there? Here’s a fact. You are not going to earn a spot on this table with a certificate. The path to this table is through credibility and reputation. My first bit of advice is if you want a worthy job, then you need to be worthy. Examine the work that you have done to date. Does it reflect your skill and perhaps more importantly, your ability? What about your attitude? Does your work reflect that of someone who is passionate and who loves testing? You don’t need rockstar status, but you do need to be an eager apprentice. If you have aspirations to get a great testing job, but you’re not prepared to put in the hard work, then why should you deserve a great role? Here’s something I do that has proven to be very useful. When I start a new role, I ask myself two questions. The first is “If I leave, how do I want people to remember me”? and second is “what legacy do I want to leave behind me”? It may sound ruthless to think about an exit strategy when starting a role, but the reality is, NO job is permanent so why treat it as one? So, you are now a worthy tester, the next step is to be able to demonstrate this worthiness and please, put away that tired old resume! I’m talking about blogging, and speaking and contributing to the testing community. Contributing to the community is a great way of meeting local and international people and you learn so much. Regarding speaking, this doesn’t have to be large conferences, there are plenty of small local meetups that offer you a space to speak. No tester meetups near you? Why not create one, or speak at a developer meetup. Thirdly you need to network. I can’t emphasis this enough. This is where the jobs are. You need to consider two types of networking, local and online. Local is essential if you want to find work in your area. This means meeting people face to face at the local meetup. Yes, I know Masterchef is on a Tuesday night and this clashes with the meetup, but hey, do you want a great job or not? Online networking is important too because it allows you to connect with like minded people, plus its a great source of learning. Many jobs come from both online and local networks. You also need to research. Find out the good companies, speak to people through your network (not agencies) about the ‘good places’ to work, and make a plan on how you are going to work there. Having an online presence helps a lot here, but so does face to face networking. And be patient, great jobs don’t just drop off trees and fall into your lap. Yes, ultimately, these jobs don’t come easy. They require hard work, and a willingness to put yourself out there. It comes at a cost to your personal lifestyle. but hey! It’s all about choice. Great jobs are around, but its about seizing the day and making the opportunity instead of relying on an agent to do it for you. This is a good thing. Trust me. As I said at the start, why should you put your fate into someone’s hands? The good news is more than ever before, companies who recognise and value their staff, who recognise and value quality testing, are recruiting in a grass roots way. If you want these types of jobs, it’s easier to get them. Now maybe this all seems like too much work and you know? I can live with that! Seriously, it's your call. But don’t tell me that certificate is mandatory to work in testing, because it's not true. Many companies who ‘get’ testing will hire you without a cert. The question that is probably more pertinent is: “Do they want you?” So get out there, work your butt off and then market your fabulous testing skills. If you stop putting your pearls before swine, one day that dream job will be yours! ### Software Testing at University of Technology Sydney URL: https://www.annemariecharrett.com/software-testing-at-university-of-technology-sydney/ Last updated: 2021-06-17T04:55:47.000Z #### *I no longer teach this class. However, I do teach HSC students wanting to get into tech. See Catherine Karena from [Test-Ed](https://www.test-ed.com.au/?ref=annemariecharrett.com) for details on how you can get experience based training in the tech industry.* I’m lecturing at the University of Technology this year. I’ve revamped it the course from last year, placing more of an emphasis on the testers skill. This is essential if we are going to improve the quality of testing within organisations, and its why large organisations are excited about and want to work with UTS to make this course happen. As far as I’m aware, this is the first course in Australia of this kind. The course is part online part tutorial. There is a big emphasis on learning by doing, with lots of opportunity to practice testing. There’s also an opportunity to work with companies, performing testing and reporting to real stakeholders, giving you a real opportunity to experience what software testing is about. Here’s an overview of the course content: ## Software Testing This course teaches postgraduates the essential skills required in software testing. Learn how to test software in a way that offers stakeholders valuable and insightful information on the quality of the product by asking useful questions of people and the product you are testing. To do that, you will learn the principles of context driven testing, critical thinking skills, test strategy, test planning, collaboration and communication and documentation. ## Subject Objectives - On completion of this subject, the student will have the potential to: - Understand how context drives how software testing is performed - Think critically in software testing - Creating Test Strategies - Know how to model a product for the purposes of software testing - Become proficient in bug finding - Learn how to test effectively - Create test reports that provide relevant information to software testing stakeholders On completion of this subject, the student will improve - Their understanding of what software testing is and how it relates to other roles in product development - Their ability to think critically by asking useful questions. ## Teaching and learning strategies This course is based on the principles of experiential learning with an emphasis of understanding through doing. Each topic will be taught through a practical exercise. Students will have the opportunity to work individually and in groups to complete assignments throughout the course. There will be a final group assessment where students will work in a company to create a test strategy, test software and develop a test report on the software tested. This course is aimed at postgraduate students who wish to learn how to test software in an applied and thoughtful way. Some degree of technical understanding is beneficial but not essential. ## Content This subject will cover the following topics: 1) Critical Thinking in Software Testing 2) Test Strategy: Modelling 3) Test Strategy: Coverage 4) Exploratory & Scripted Testing 5) Oracles and Bug Finding 6) Test Reports and Bug Reporting 7) Testability: Tools in Software Testing 8) Advanced Modelling – State Machines 9) Communication with Stakeholders Though the course is part of the post graduate program, they’ve agreed to allow people to take the module as a course in its own right. If your interested in taking part in this course, go to the[ UTS website](http://www.handbook.uts.edu.au/subjects/details/32571.html?ref=annemariecharrett.com) ### The power of NO URL: https://www.annemariecharrett.com/the-power-of-no/ Last updated: 2021-06-18T05:59:54.000Z I went and visited one of my clients yesterday. Its been a while since I helped them and I wanted to catch up on where they were at. As it turns out, this company has been going great guns, building their testing from zero to three testers. However, growth often means pain, and this particular company had some pain points. I knew there was something I could do to help. They also wanted help in recruitment. Now, this has always been a bit of a sore point for me. While I want to help my clients, I’m not a recruiter. On the other hand, I know many testers who want to do interesting work. Could I add value here? Well, it turns out I could. But it's not the value I’m particularly interested in offering. I’m a consultant, trainer and coach. I advise people on how to improve their testing. Instead, I pointed them to the best recruiter in Sydney, Catherine Karena to help them out on recruitment. They also wanted help in offshoring, so I pointed them to the best offshoring company in India, Moolya. What financial gain have I made out of all this? Nothing. A big fat zero. Yes, that’s right. I made no financial gain from this event. In fact, you could argue I lost money, if I take into the account that I spent an hour of my time speaking with a client. I know, that many will argue that I could have rightly skimmed off the top of these introductions. After all, it's common (add some say good business sense) to add a percentage on top of these deals, in lieu of the introduction. After all, new leads are like gold dust in this industry I got something out of it though, you know it did, because I probably wouldn’t be writing this post if I didn’t. Saying no has given me strength. I’ve put my foot down, and said “value matters”. That feels good. That feels right. Making a fast buck? Meh! Knowing what you stand for? Priceless!! ### How I use modelling in software testing URL: https://www.annemariecharrett.com/how-i-use-modelling-in-software-testing/ Last updated: 2021-07-23T23:11:25.000Z My testing can look like ‘fly by the seat of my pants” testing at times. There’s nothing more I like to do than grab a new product and jump straight into testing. No namby pamby reading of requirements by me! No, I want to get straight to the source of truth. I want to find out what the product \*actually\* does. *(This approach may seem seem rash, but it's not. Its a considered decision, read on).* But this type of testing only takes me so far. I get to the point where my testing starts to be limited. There seems to be nothing new about the information I’m getting and my learning about the product takes an exponential dive down. I take this as a sign to stop and take a step back. I’ve obtained as much information as I can from playing around, but now its time to get my hands really dirty. Its time to start studying and researching the product. I start learning more about the products structure such as the database, the products architecture and the interfaces. I explore the intent of the product and find out who the users are. I start talking to product owners & developers to gain information about the product. I then go back and test more, but this time my testing has taken a different turn. With new information and ‘new eyes’ I’m looking at the product in a different way. I start learning new things again and the curve of learning and finding new information goes up again. All this time I’ve been modelling and testing. In software testing I model a product to understand it. This might be a little different to the way architects model a building. They model to demonstrate to others what the final product will look like, though I can imagine creating a physical model helps to clarify thinking. Modelling isn’t always explicit. We all have a [mental model](http://en.wikipedia.org/wiki/Mental%5Fmodel?ref=annemariecharrett.com) – a representation of the world in our head and testing makes use of it heavily. Sometimes I find it helpful to make the models explicit though. I do this to help me reason through the information. Ordering information through drawing it or writing it down seems to help me recognise gaps in my thinking. When I jump in and test, I’m actually creating a model of what the product does. I prefer to model the product first \*before\* reading requirements etc so I have good understanding of what product really does. My understanding of the product is unfettered by any biases and assumptions that I might gain from speaking to people or reading requirements. Having a solid model of what the product does grounds my testing in the reality of what is. As a tester, I want to bring a different perspective to the table. Once I’ve modelled what the product does, its time to find out more. I model how people perceive the product to be. I read the requirements and any other documentation I can find. I talk to people and create squiggly and messy diagrams on whiteboards that normally only I can read (and sometimes struggle to understand!) All the time I’m modelling to understand the product better. I’m still testing though. I don’t perform modelling in isolation to other cognitive activities. In fact, I test and model, model and test. This might appear counter-intuitive. After all, how can you test without knowing what people want? How will you know if there’s a problem without requirements? That goes back to oracles (you know, those things that help you recognise problems). When I test, I purposefully use a diversity of oracles to help me recognise different problems. When I use “Plunge In & Quit”\* heuristic, I am testing. My oracles of choice are: Previous Testing Experience, Knowledge of Similar Products, World Experience. You don’t have to have explicit requirements to recognise problems. So I model and test, test and model. For example, as I’m creating models, I’m testing them. Think of whiteboard scenario where you are formulating models with a developer. As the model is being created, it's being tested. That’s how gaps get recognised. When I’m testing, I’m challenging my models to see if there’s a problem. I’ve consolidated my thinking on models into this short video. Here’s what I’ve learned so far: 1) Modelling is integral to testing regardless of it being performed consciously or unconsciously 2) You can have mental, formal and physical types of models. 3) Creating formal models can help reason through a product 4) Modelling a product by first “playing around” can help bias your testing in a good way 5) Modelling and testing take place simultaneously. 6) Different Models are a source of new questions to ask the product I’m going to wrap up with George Box’s advice: “all models are wrong, some models are useful” Creating this model of models has proved useful to me, but it's not complete. What are your ideas on modelling and software testing? *\*” The Plunge in & Quit” heuristic was identified and named by James Bach. It’s an approach many experienced testers use to quickly learn about a product.* ### Courage in Exploratory Testing URL: https://www.annemariecharrett.com/courage-in-exploratory-testing/ Last updated: 2025-06-06T23:07:27.000Z Exploratory Testing takes software testing skill. It also requires the tester be courageous. Let me explain. Exploratory testing is an approach, not a technique. Exploratory Testing is simultaneous learning, design and execution. What information we learn about a product, helps dictate our tests providing us with information that we can share with people around us. Exploratory Testing is tester centric, meaning the tester is central to the testing taking place. The tester has the autonomy and the responsibility to make decisions about what to test, how to test, how much to test and when to stop. This may seem blatantly obvious to some, but its surprising the number of test teams where this is not the case. It’s all powerful stuff, generating an environment where the tester must constantly reflect upon the changing project and product environments, enabling the tester to be engaged and mindful as they test. I honestly can’t think of a better approach to software testing. But there is a catch. Exploratory Testing also demands great courage. When you start to take responsibility for your testing it’s not done in isolation. Testing requires interaction with many different people such as developers, project managers, scrum masters, product owners, customer support and business people. We share information that’s not always good news. It’s in the form of bugs found and the possible impact of this information on the business. The resulting consequences of the information we share often leads to delays in releasing, changes in workload, context switching and revising strategies. In scripted testing, testers have artefacts which they measure and count giving an illusion of certainty but really this is smoke and mirror reporting and generally offers little genuine information. “We have reached 78% test coverage, with a DDR of 85%” Exploratory Testing doesn’t have ‘dutch courage’ to rely on. It requires us to have conversations about our information in potentially hostile environments. Sometimes we can feel like the lone fish swimming against the tide of the silent majority. It can be tough and as testers, we need to learn to develop how to speak about our testing, how to tell a story (James Bach and Michael Bolton have both written on this). Here’s a list of ways that have helped a quaking knock-kneed tester like myself discover her backbone: Speak to someone you trust about your concern. Vocalising a fear helps to make it tangible and sometimes gives strength when you discover its a shared concern. Be coached or mentored on how to speak about testing with confidence Take small steps. Speak to people sympathetic to your cause, sound out ideas. See if other people can help. Try not to lose faith, be persistent. Keep your eyes on the goal, even if sometimes you fail to speak out. Emotions are your toolbox. Anger and frustration can be very useful emotions! Use your emotion to give you the courage to speak out. (I learned that at PSL this year..thanks to Jerry, Johanna & Esther) Sometimes you need help. Be humble enough to know that sometimes change is out of your capabilities. See if you can find help through the testing community or see if you can bring someone in to help affect the change. But mostly, it’s about practice. Courage breeds courage. Standing up to little things helps give you the courage to stand up to greater things in the future. Be brave. Be strong. What drives me most of all is that I want to be able to walk away from a situation with my head held high in the knowledge that I may not have changed the world, but I’ve had my say. Now that’s a good days work. ### Growing your own URL: https://www.annemariecharrett.com/online-training-in-software-testing/ Last updated: 2021-06-16T21:03:57.000Z So, I’m sitting here in my office on a beautiful Australian spring day. The sun is shining brightly, the air is slightly fresh sending wafts of scent from the spring flowers. Its a good time to be alive and its a good time to be thinking of growth and change. True to form, I trotted down to the local garden center and bought back a truck load of seeds and ideas on what I can do in the garden. I feel good this year, the potatoes are growing well, and I’ve managed to grow snow peas for the first time. Having invested a good amount of time in the garden, I feel content enough to sit in my office and allow myself to explore ideas on software testing and training. And I’ve come up with the crazy idea, wonderful idea. For some time I’ve wanted to invest in online training in software testing. Its a model that I think will suit me well. I live far far away from the rest of the world and as much I as enjoy meeting new testers from around the globe, continuous travel is not for me. To date, I’ve struggled with the concept of online learning. When I learn, I like to get my hands gritty, experience the stuff I’m wrestling with. With my online coaching, I make sure I include a task of some sort but thats one on one. Is it possible to offer online experiential learning to many people? And then I read about these guys at [Venture Lab](http://venture-lab.org/?ref=annemariecharrett.com). The courses are [highly experiential & require collaboration to succeed](http://news.stanford.edu/news/2012/september/venture-lab-platform-091712.html?ref=annemariecharrett.com). I sniffed a model that I could possibly work with. But I’m taking it one step further. I want to make the students the designers of the course. Its the students who will work out what needs to be learned and how that will be achieved, and how they will know they achieved it. There will be some external structure, perhaps in the form of exercises, some philosophies to abide by, but basically, its the students who will dictate the content & the pace. In fact a lot of these ideas are from the [coaching model I have](https://www.annemariecharrett.com/in-pursuit-of-excellence) worked on holding onto the concept that learning requires real desire from the student, and to do that the student needs to dictate the learning (with the teacher offering space and direction to learn). I see this courses as being a [permission giver.](http://theamericanscholar.org/permission-givers/?ref=annemariecharrett.com) We’re so drilled to think of learning as something we have to sign up for, like it's impossible for us to learn outside a course. In this way, I’m helping overcome that little hurdle and get into some real meaty learning. I’m very excited about these ideas and what will come of them. I’m not sure where they will lead and I guess that’s half the fun! If you want to join me on the crazy, wacky journey, feel free to contact me on Skype at charretts, or else add a comment below. I’ll be adding information on this model as it progresses. ### You little beauty URL: https://www.annemariecharrett.com/you-little-beauty/ Last updated: 2021-06-18T06:01:32.000Z We Aussies are a pretty laid back lot but a software testing event in Adelaide this November has a whole heap of software testers tapping their toes in anticipation for the first Australian Workshop on Software Testing (OZWST) to be held 8th & 9th November in Adelaide. I’m one of the few invitees to this event and its looking to be a couple of days of extreme learning. I see this as an historic event in Australian Software Testing Calendar. For what I believe is the first time ever, Australian software testers are coming together with these objectives: **They want to learn to become better software testers** Sure, many testers want to become better in their craft, but how many are prepared to pay their own to Adelaide to do so? Unlike conferences or summits where companies pay for training, most testers attending are self funded and they’re doing it because they know that this is a unique opportunity to learn and improve their software testing skills through experiential learning. **They want to actively promote skilled software testing** Let's face it, on the whole software testing has a bad image in Australia and we need some serious champions out there who are willing to stare down the grey faceless masses, that either through ignorance and/or stupidity promote mediocre testing. The testers at OZWST mean business; they want to persuade and influence others – and they’re looking to OZWST to help them gain those skills. **They want to build an community of thoughtful testers** Software Testing is a poorly understood skill in Australia, and here is a bunch of testers who want to change that. Its no surprise this event is run by and for[ Context Driven Testers. ](https://context-driven-testing.com/?ref=annemariecharrett.com)By working together as a community, software testers can share war stories, learn from experiences and encourage each other. ### That coverage problem URL: https://www.annemariecharrett.com/that-coverage-problem/ Last updated: 2021-06-15T09:35:27.000Z Thanks mostly to the BBST classes the AST run, I’ve come to understand and appreciate the impossibility of complete testing and the challenges surrounding ‘complete test coverage’. I find 100% testing coverage a pretty meaningless phrase. Imagine trying the calculate the amount of water in a swimming pool by multiplying the length and width of the pool. Ha! we’d snort and sniff at the stupidity of the idea. But when test managers, project managers and testers ask for “complete test coverage” that is in essence what they are asking testers to do. In fact, getting to grips on complete testing is even harder than the pool problem, because at least with a pool, once you know the width, length and depth, the volume can be calculated. In testing though,the number of models we use to design our tests is limited only by our imagination. To try and measure test coverage is a bit like trying to cover a black hole with a tea towel and say you’ve measured it. Trying to test like this in a short space of time is really stressful and it seems the agile solution is to automate regression tests. But really, is this the best solution we can come up with? It seems to me this desire to cover as much functionality as possible ends up in this Wac-A-mole game with testers frantically hitting features as fast as possible in order to be able to say its done. Well, I’m trying a thought experiment at the company I’m consulting at. I’m challenging everyone to drop the idea of coverage and instead focus on some meaningful and valuable testing. I’m doing this because it seems to me, we testers are far too hung up on this coverage problem and we bias our testing to try and solve it. Yes, this may mean that we fail to test all the functionality – quelle horreur! But get this, when do we \*ever\* test all functionality? Dropping the desire to “test everything” is very liberating. We no longer have to fret about trying to test all the functionality in a week (we do weekly releases with multiple hot fix releases). Instead, it’s freed our minds up to reflect and ponder on what is the most beneficial testing to perform given we only have a few days to test. It’s also freed up our toolsmith, allowing them to spend time solving some testing problems through testability instead of frantically creating regression tests. I’m fully expecting some bugs will get released to production, but you know? that’s nothing new! We’re finding bugs in production all the time, they’re called customer support issues. Time will tell if this approach proves to be beneficial or not. It’s a little scary, dropping the regression test safety net, but when safety nets start obstructing your work its time to question its validity. ### Upcoming Software Testing Courses URL: https://www.annemariecharrett.com/upcoming-software-testing-courses/ Last updated: 2021-06-17T01:44:45.000Z I’m heading to[ CAST 2012](http://www.associationforsoftwaretesting.org/conference/cast-2012/?ref=annemariecharrett.com) this year (July 16th – 18th) and so I’ll be in the San Jose/ San Francisco area if anyone is looking for an impromptu workshop on [Exploratory Testing](https://testingtimes.com.au/services/academy?ref=annemariecharrett.com) or Coaching Software Testers around that time. I’ll also be near[ Albuquerque for PSL](http://www.jrothman.com/2011/11/psl-problem-solving-leadership-workshop/?ref=annemariecharrett.com) in August this year (August 24th -August 31st), so if anyone is interested in workshops in those general locales contact me on annemarie@mavericktester.com or Skype me at charretts ### In pursuit of coaching excellence URL: https://www.annemariecharrett.com/in-pursuit-of-excellence/ Last updated: 2021-06-15T03:30:11.000Z When you coach a tester you’re working in an environment that dynamically changes as both the student and coach work through a coaching task. If you look at the diagram below you can see all the different attributes that might change throughout a coaching session. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/coaching5.png) Anne-Marie Charrett & James Bach Also, throughout the coaching session, the student and coach have a mental model of the coach and themselves. They constantly re-evaluate these models as the coaching session progresses. The coaching I do requires that the coach has a testing syllabus that they use to help the student. This is different to life coaching which is non domain specific. Also, our coaching is lot more directive. The relationship between the coach and student is more coach->student than the traditional peer-to-peer relationship you find in life coaching. I see our coaching more like sports coaching, where a coach outside of a game, runs you through drills and challenging exercises to help you improve, often without realising you're in need of improvement. Personally, I’ve experienced good and not so good sports coaches. In my school days I was a bit of a field hockey superstar (I joined the grade A hockey team two years ahead of time, making me the youngest player). My coach however was incredibly overbearing, shouting and yelling at us and telling us how hopeless we were. I’m not sure if we were hopeless or not, but I know we failed to win many games and left the season completely demoralised to the point I gave up hockey for four years. I was persuaded to pick up hockey again and this time we had a different coach. She was quiet, never said too much and let me play my free style. One day she came up to me and be a quietly suggested I move back 1 metre to be able to better angle my shots ( I was in a midfield position). Very quickly I realised the power of such a move, I was in a better position to be able to control the game. I was 16 when that happened and I’ve never forgotten the power of that one statement. For me that’s what coaching is about and its the type of coach I aspire to be. Its directive but the direction is about the skill and how the student is performing that skill. Where its non directional is that I challenge the student to think for themselves. It’s paradox at play but one that works. It's also powerful because it’s watchful, ready to tap into what a student is doing at an appropriate time, using pressure and energy as tools to make direction powerful to the student (just like my second sports coach did). The aim is to help the student feel empowered to achieve more. But the energy is not only in one way. The coach is getting energised by the coaching session too. I’m constantly evaluating my coaching and testing ability. I become a better coach by doing this. My aim is to become the best coach I can be. I can only do this by coaching lots of testers, evaluating the transcripts and also working with colleagues who inspire and want to become better coaches too. I’ve been doing that this week with James Bach. We’ve been working on our book on coaching, identifying ways in which we coach, syndromes that both student and coaches encounter (we need to do more of this) and also finding ways to better evaluate coaching transcripts. I think an aspiration of excellence in any field is such a worthy goal. I was watching [Ron Ben Israel](http://www.youtube.com/watch?v=qWqnDDtcv2g&ref=annemariecharrett.com) who is a master baker of sugar dessert flowers. You can see his passion the how is pursuit of excellence has led him to create masterpieces in sugar. Who would have thought that you could become excellent in such a small field? Excellence I think is different to perfection. Perfection to me sounds more absolute, perhaps a little unrealistic. Excellence however, is within my grasp but also always one step ahead of me. I can be excellent at one point in time, but I can always strive to be more excellent. I think this is a worthy pursuit and a good use of my time and energy. What are you in pursuit of? ### I am the Queen of Defocus URL: https://www.annemariecharrett.com/i-am-the-queen-of-defocus/ Last updated: 2021-06-17T05:13:37.000Z I remember the day I earned the self acclaimed title of Queen of Defocus. I had been testing for about 3 years and had been hired as the \*only\* tester in an R&D lab of about thirty engineers. I also happened to be the only [female engineer](http://flampz.blogspot.com.au/2012/03/why-women-should-study-engineering.html?ref=annemariecharrett.com) at the time, so I was Queen of the Lab regardless. But I become Queen of Defocus when one day I was working on creating a test strategy for a Nationwide Freephone service that was to be designed and built in our lab. I had earlier cottoned on to the idea of white boarding the service and grabbing poor unsuspecting engineers as they passed by to help me figure out how the service worked. This helped me understand the service better and also on occasion I saw engineers go quiet as they realised through my questions that they had overlooked something in their design. (I later discovered James Bach calls this [Inside-Out Analysis](http://www.satisfice.com/articles/hrbt.pdf?ref=annemariecharrett.com)) One day, as I was applying this approach I had a gestalt moment. I realised that I was really really good at asking pertinent questions. Questions not necessarily about the service itself (though I did ask those) but also about how the service was going to be used, deployed, tested, maintained and operated. But what made these questions so valuable? Why were \*my\* questions seemingly able to discover problems other engineers failed to think of? What exactly was I doing? I decided it was the ability to grasp an answer from one question and allow it to connect to some other seemingly significant piece of information to generate another question. To do that, I had to let the information go for a wander in my mind until it connected to another piece of information. I had this visual idea of information wandering through my brain, seeking a neuron to bond with. However it happened it was working. So I became Queen of Defocus partly because of this gift I had to make connections, but also because everyone else was so focused. By focusing so well (and they were some of the brightest engineers in the country) my defocusing ability was allowed to really shine. I was the ying to their yang. Years have flown by (literally, I traveled overseas to Dublin for 2 years) and testers still comment on my ability to hit any situation, ask pertinent questions and make connections. Richard Robinson watched me pull an admin guy’s strategy apart, leaving him with a notepad full of questions to find answers for. But being Queen of Defocus has its downside, it can if you're not careful make you sloppy and shallow in your work. I know this because I’ve fallen into this trap of not paying sufficient attention to detail. I watch out for it now. I’ve learned that not knowing facts can be really embarrassing and I try to avoid that. But mostly, I’m pretty happy letting my mind wander and reflect and ponder on why sun streaming through the window on an Autumn day fills me with joy. I store these moments away open to the possibility that they may prove helpful one day. On days like this, a bit of defocus is bliss! ### Training Testers URL: https://www.annemariecharrett.com/upcoming-workshops/ Last updated: 2021-06-26T00:51:17.000Z I’m having a complete blast at the moment adding the finishing touches to my upcoming workshops in Dublin,Belfast and London. The Dublin and Belfast Exploratory Workshops sold out in a couple of days but there are still some seats on the [coaching testers workshop in London. ](http://www.ministryoftesting.com/training-events/coaching-testers-with-anne-marie-charrett/?ref=annemariecharrett.com)This is shaping up to be a great workshop – its jam packed with exercises and I’m very excited to be able to share with other testers the approaches that James Bach & I have honed over the past years. Then its off to the inaugural Lets Test Conference in Stockholm where I’ll be giving a talk on coaching testers. The Lets-Test conference is shaping up to be a huge event and personally I’m thrilled to be making part of history by speaking there. Hope to catch up with you at one of these events! ### Mary Mary Quite Contrary... URL: https://www.annemariecharrett.com/mary-mary-quite-contrary/ Last updated: 2021-06-18T00:42:57.000Z Mary, Mary, quite contrary, How does your garden grow? With silver bells, and cockle shells, And pretty maids all in a row. Its an old english rhyme that goes eons back. In fact, its actual meaning is [disputed](http://en.wikipedia.org/wiki/Mary,%5FMary,%5FQuite%5FContrary?ref=annemariecharrett.com) over time. Meaning change over time, don’t they? A bit like quality I guess. Closer to today, in the early 1990’s people so enamoured with the concept of a \*mobile\* phone ignored the fact that half the time calls dropped out. After all, compared to a fixed line, the freedom was incomparable so why not put up with being cut off through a tunnel? Roll forward twenty years later, and Vodafone lost a plethora of customers due to call drops outs. Why? We as customers have changed our concept of quality. What people viewed as acceptable soon became intolerant. Testers need to be aware of this. In particular when they focus on regression testing. Do your old tests actually add value? Have stakeholder opinions changed over time? Testers also face a problem that Mary didn’t have to deal with. For Mary, everything was laid out in row, nicely lined up, easy to count. But bugs don’t do that, do they? They grumpy, recalcitrant and downright impossible to find. Thats why we as testers can’t rely on the expected, the norm, the process. We need to be clever. We need to be sleuths. We are the Sherlock Holmes of the IT world, finding clues where no-one thought to look. We need to think harder, deeper and broader than everyone else on the team. We need to catch the peices others haven’t thought of. Here’s my 21st century version of the poem. Mary Mary quite contrary How does your garden grow Until the testers have a look, To be honest, I really don’t know. ### Jumping to conclusions URL: https://www.annemariecharrett.com/jumping-to-conclusions/ Last updated: 2021-06-16T23:41:27.000Z Good testers continuously ask questions about the product, the customer and the project environment and invariably on themselves. No question, no test. When we're satisfied with the explanation we stop asking questions, we stop being inquisitive. For testers, it's essential to keep asking questions for as long as possible. On the other hand, a test manager deals in conclusions in response to deadlines and an expectation from stakeholders. This puts a test manager in the unenviable position where on one hand they need to encourage their testers to question, but on the other they need to be able to satisfy their stakeholders with conclusions. A test manager has to deal with this conflict of inquiry and conclusion in the testing they deliver. If a test manager focuses only on deadlines and delivery, the desire to reach conclusions quickly will filter into the testing they manage. Testers will start feeling the pressure to deliver answers instead of ask questions. Test managers need to be conscious of the impact deadlines and being project driven can have on a tester’s ability to find bugs. If you’re a test manager, be mindful of the impact that deadlines & resulting conclusions may have on your testers. Avoid the temptation to drive testing with the goal of delivering ‘the simple answer’ because stakeholders expect it. Strive for open mindedness and inquiry in testing. Avoid easy explanations and quick conclusions. Or even better, encourage stakeholders to reach their own conclusions about the testing that’s being performed. Now that would be a real victory! ### The School of 1 URL: https://www.annemariecharrett.com/the-school-of-1/ Last updated: 2021-06-18T11:23:57.000Z Like many testers I’ve been watching the unfolding drama of *school* versus *approach* that is taking place in Context Driven Testing community with part dismay, part fascination and part anger. That’s a mixed bag of emotions and it bothers me. Two people that I hold in such high regard are not speaking to each other. People that I have worked with and respect deeply. On a personal level that saddens me. From a professional testing perspective, not so much as good testing will continue to thrive as long as testers are devoted to their craft. But something angers me about this whole debacle. [Lanette Creamer](http://www.satisfice.com/blog/archives/724?ref=annemariecharrett.com#comments) describes this as estranged family but to me it more like when a couple decides to divorce and the friends end up divorcing too. To be fair to both James and Cem, neither have suggested that this is necessary. James has stated he still has a huge respect for Cem. I admire him for that. Similarly, Cem has never suggested that ‘sides’ have to be taken. Why then, do I feel that I’m being put in a position that I have to chose between the two? Emotions aside, this whole debacle has challenged me to try and logically reason about what I think. Where I see myself. I am a Context Driven Tester. I don’t want to test in any other way. I won’t test in any other way. If its an an approach then I’m not going to take any other. I guess according to [this](https://www.satisfice.com/blog/archives/5191?ref=annemariecharrett.com)[ post](http://satisfice.com/blog/archives/5228?ref=annemariecharrett.com), that makes me part of the Context Driven School. Yet I do agree with Cem. The idea of schools is polarising and sometimes I feel uncomfortable when other schools are denigrated publicly. Regardless of schools, I respect thoughtful testers who work in these paradigms. My solution at times like this is to look to myself. Reaffirm what I believe and move on with my work. I will continue to test in a way that I believe is best for me. I will continue to treat testers who I admire regardless of school with respect. I hope that means being able to work with both Cem and James (albeit independently) in the future. Time will prove if thats possible or not. So in the mean time I will continue to study testing, help others test and focus on growing a vibrant testing community in Sydney. If that means I end up in a school of one, then so be it. ### Please don't hire me URL: https://www.annemariecharrett.com/please-dont-hire-me/ Last updated: 2022-10-08T03:28:35.000Z If you want perfect software and you want me to break your code If you're going to measure me by the number of test scripts I write If you want me to tell you its ready to ship If you wish to have 100% of your product tested If you are looking for a tester to only "check" if things look ok If you want your testers to follow test scripts mindlessly If you want training on a test process If you feel you can't test without requirements But if you're looking for a tester who prides herself on the work she delivers, offers as much value to her clients as she can, and has a reputation for excellent testing, then yes, please hire me! I'm available for coaching testers, training testers, consulting and testing. [Contact Details](https://www.annemariecharrett.com/aboutme) ### The Buzz On Testing URL: https://www.annemariecharrett.com/the-buzz-on-testing/ Last updated: 2021-06-15T22:36:36.000Z We’re witnessing a revolution my dear comrades. The tide is turning on drone testing The word is out. Skill Matters! Classes such as Rapid Software Testing (developed by James Bach and Michael Bolton), Just in Time (Rob Sabourin) and Elisabeth Hendrickson Exploratory Testing classes are becoming more popular. They say “Test is Dead” but I say “Bad Test is Dead”. Hurrah! Slowly the realisation that tester’s need skills as such as bug recognition, critical thinking, the art of questioning, influencing and developing strategies to help them effectively test software. I have a theory that the majority of tester training has been focused on process and documentation because it's easy to teach that way. Instead of having to working on skill you simply point to a structure and say “follow that”. It's much more challenging to develop a tester’s skill. Skilled people earn respect and rightly so. We admire a skilled musician – even if the music doesn’t appeal to us. Developing skill is hard work. It’s the accumulation of understanding, practice and application. This takes time and effort. As someone who has worked in the industry for twenty years, I know how hard it can be to allocate time for training. We’re deadline orientated and rightly, a Test Manager’s goal is to complete ‘good enough’ testing with the time and resources available. Coaching is the antidote to this. It allows the tester breathing space to reflect and work on their skill. The coaching I perform focuses on developing skill through understanding & practice. It takes into account the testers skill base, context, aspirations and the challenges a tester is facing in their current work. As opposed to arbitrary training, coaching complements a working environment, and often the problems worked on are those that exist at work. In conjunction with James Bach, I’ve developed systematic approach to coaching a tester’s skill. This approach is a result of coaching hundreds of students, evaluating transcripts and refining the coaching model. It’s this model that I will be teaching in [my workshops ](https://testingtimes.com.au/services/academy/?ref=annemariecharrett.com)on coaching testers. I’ll be holding a workshop in L[ondon on the 4th May](http://www.ministryoftesting.com/training-events/coaching-testers-with-anne-marie-charrett/?ref=annemariecharrett.com), and one in Sydney on the 29th May (with James Bach). Come and join me! ### What drives your learning? URL: https://www.annemariecharrett.com/what-drives-your-learning/ Last updated: 2021-06-25T06:29:09.000Z What drives people to take up my offer of free Skype coaching? Most testers when asked give on of the following reasons: 1) they want to pass an exam 2) They are having difficulty at work and need to get over some particular obstacle 3) They want to test themselves 4) They want a particular question answered 5) They want to know more about a topic 6) They want to learn how to coach other testers 7) They want to become a better tester – topic irrelevant Many come to coaching with a mixture of frustration in their work or because they feel [disillusioned](http://rhythmoftesting.blogspot.com/2011/12/rising-from-ashes-or-finding-motivation.html?ref=annemariecharrett.com). It we seems that for many, testers need drivers and general discontent to push them into learning something more. Few testers come forward wanting to simply learn. It’s not all that surprising. I myself have just completed a gruelling year of full time work. It’s hard to allow yourself time to reflect and pause when you hop from one crisis to another and when you do, its more likely to be related to the challenges you're working on at the time. But I really admire the the testers that come wanting to learn more. Willing to take a punt at contacting someone they’ve never met and ask them to be coached. I salute you! What drives these people? Is knowledge some kind of drug to these people? Do they simply want to know more? Do they want to be the best at what they can do? I think it's important to understand this question as people who want to learn for the pure joy of learning have a major advantage over others. They continue to learn and grow despite the daily challenges around them. It's not the challenge or goal that drives them to learn, it's the learning that drives them to challenge themselves. Common external drivers are completing a project, passing an exam, getting a job promotion and getting external approval from others. But what happens when the inevitable happens and the goal is completed or the challenge disappears? What happens to your thirst of learning? Does it die away? Does that tell you anything? Removing external oracles (those things you judge yourself by) casts your thirst for knowledge in a very different light, but its not a bad light, its an honest one and it belongs to you. I believe we have to own our own learning. Drivers to learning can often be short lived. Have a goal to become a test manager, only to discover you’ve plateaued? I suspect your learning may be driven by goals. Imagine a world where you can tap into this love of learning as some testers do. Imagine learning for the pure enjoyment of discovering something new. Feel the satisfaction of overcoming a hurdle you have set yourself. These testers they have taken responsibility for their learning. They see it as a way to develop and grow themselves. Their oracles to learning are inner satisfaction and self respect. They shine with the confidence of owning their own learning. So do yourself a favour, spend a little time identifying what’s driving your learning and ask yourself “how is that working for me?” *Post Note:* *If you want an example of a tester that learns for the love of learning, read[ Pete Whalen’s post on Rising from the Ashes](http://rhythmoftesting.blogspot.com/2011/12/rising-from-ashes-or-finding-motivation.html?ref=annemariecharrett.com).* ### Speed Kills URL: https://www.annemariecharrett.com/speed-kills/ Last updated: 2021-06-15T09:39:42.000Z Some of my testers have become embedded on a newly formed agile team. Its been a roller coaster ride for sure. Lots of fun, thrills and a few scary points in time where I thought for certain we were not going to make it, or we were heading in the wrong direction. From a testing perspective, we were quietly confident. Our testing is exploratory by nature, and so it lends itself easily to being flexible and adaptable. We’re testing before the acceptance criteria are developed by attending the workshop and asking questions about the upcoming feature, learning why its needed and what problem its trying to solve. And when it comes to testing the feature, we all jump head first into the deep end, swimming with long powerful strokes through the water of doubt and complexity and only surfacing for air to congratulate and high five each other on another completed testing charter. Its been a wet wild ride, but not without some uncomfortable moments. While we’re revelling in the warm waters of upfront information and involvement, we’ve also noticed the cooler waters of reduced timeframes. Shorter iterations has placed a lot of pressure on the testers. There’s a feeling that we’re unable to pause and reflect during our testing, the pressure to be done within the iteration lends to the temptation of minimalist testing. We had to change something to make sure we were testing well enough. So, we slowed down. We made sure we spent time to think critically about our testing, coming up with test ideas, understanding what done meant, and most importantly sharing these ideas with each other (including developers). Now we test like this: We still jump into the deep end, splash out, learn some stuff about the product but before we continue with some serious swimming we stop and confer. We reflect on our learning so far, we discuss our ideas and how we know we are done. Only then do we continue with our swimming, our strokes confident and strong. It's been a revelation for some testers that are new to exploratory testing. They thought the objective was to test as fast as you can without stopping for a breath. We still have the same time pressure on us, but that stop, that moment of pause and reflection has been sufficient to gain confidence in our approach and confident in delivering the best testing that we can. ### Coaching your Test Team URL: https://www.annemariecharrett.com/coaching-your-test-team/ Last updated: 2021-06-18T06:13:08.000Z I’ve implemented coaching within my test team. To me, this is a natural progression from the coaching work I’ve been doing on Skype. It's early days yet, but I can already see the power of this approach to upskilling testers in a team environment. I’ve been working on implementing coaching into my team for a while now. I was a little cautious on how to approach coaching in a work environment because the dynamics are a little different. When I launched the program within the team I made it clear that: **1) Coaching was optional, its not mandatory .** I made this clear because its better that the tester owns the learning. I want them to feel they are in control of their learning. No-one is forcing you to be coached. **2) Coaching is not linked to performance reviews** I know this occurs in some organisations, but for my purposes I wanted to clearly distinguish between the two, so testers could feel they could discuss topics freely. **3) Coaching is focused on tester skill.** I wanted to make it clear I wasn’t a counsellor. This coaching was focused on becoming better tester’s improving skill. What the tester wants to learn and improve is up to them. On the logistics side, I’ve booked a 1 hour session on a monthly basis for each tester. Initially, I blanched at putting this amount of time aside, but after some coaching, I’m convinced it’s worthwhile. Its given me an opportunity to have a chat with testers I’m sometimes not fully engaged with. This is especially the case if a team lead is involved and I’m a bit distant from the tester. It helps me understand how the tester is doing, wether they are enjoying work. It’s given me an insight into what tester’s want to learn about. I’m amazed how practical the questions are. In fact, it sometimes makes coaching a litter harder. The challenge in coaching is not to answer questions but help them discover the solution for themselves. I’ve adapted some of the approaches I use for Skype coaching. For example, I use tasks to help a tester understand the dynamics or complexity of a problem that seems simple. An example of this was one tester who was frustrated at the lack of test procedures within the organisation. She felt sometimes she simply didn’t know if what she was looking at was the right or wrong answer. I can empathise with this, especially, when your a young tester working on a complex and technically challenging product. The simple answer here would have been to suggest she speak to a senior tester or stakeholder to find out more information. But I felt this wasn’t the real problem here. Even if you do have procedures, that doesn’t mean they will provide you with the full information. What happens if something occurred that was outside the procedure. Then what? Does it get ignored? We ran through the calculator exercise, a challenge that Mr James Bach kindly allows me to use in my coaching sessions. This really helped her understand the complexities of testing software and how we can’t rely solely on the information provided to us. Even then our job is remain skeptical of the information we are given. The tester had many questions and the hour flew by quickly. I summarised up what we had gone through, and suggested some further reading on some areas. Time will tell if the coaching is really effective, but I left the coaching session with a clear sense of how powerful coaching an be in this environment . I see this type of coaching in testing teams becoming an effective tool in helping testers self learn. ### Recession Testing is the new Regression Testing URL: https://www.annemariecharrett.com/recession-testing-is-the-new-regressiontesting/ Last updated: 2021-06-16T09:14:01.000Z It's time to retire the idea of Regression Testing folks. Regression testing, at least the way its being performed today is typically a value free, wasteful exercise and falls into the category of “bad testing”. *“Regression testing is any type of software testing that seeks to uncover software errors by partially retesting a modified program.”* In fairness to Regression Testing. I’m not opposed to the above ideology(except for the partially retesting bit, thats stupid). I think it has some merit. The concept that modifications in code add risk which testing needs to address is a sound idea and worth taking into account while testing. But we testers know, that this intent turns out to a different beast. What gets called ‘Regression testing’ in many companies in my view is not very valuable and has a different intention. Regression testing ends up a packaged set of tests ( I wince to call them that, as they typically have the same idea repeated over and over) that get repeated at the end of testing to validate that nothing’s broken. It’s more about maintaining the status quo than any in-depth testing. This to me seems wasteful. It seems wasteful to me to repeat the same tests giving an illusion of repeatability when in reality we know that each test can never be exactly the same and that getting the same result in a test does not mean for certain that the test has passed. It seems wasteful to me to exercise a feature using the same testing idea again and again when a different test idea might offer new information about the system It seems wasteful to me to ask testers to perform tasks that result in the tester disengaging from the activity because its boring. It seems wasteful to suggest that somehow new features need to be tested differently to older features. Why? Bugs are not ageist. It seems wasteful to suggest that somehow regression testing demands less cognitive and skeptical thinking. I think we’re looking at this problem the wrong way. I’d like to suggest a different paradigm. I’d like to offer up the idea of Recession Testing. Where Regression Testing does its best to test as little as possible, Recession testing insists of focusing on value and removing waste, just like we need to do in a Recession in order to be competitive. This means, instead of splitting a product into new and existing features, lets test all parts of a product with equal aggression, equal skepticism. When it comes to regression vs new feature bugs, lets make all bugs equal, not some more equal than others! If we do need to prioritise our work, lets do so on the basis of risk, What are the impact of change on the feature? What is the importance of the feature being tested? If you’re going to test a feature, do everyone a favour and test it like you mean it! Don’t give it some half baked, wishy washy run over, to check that its ok and then give the false assumption that you’ve properly tested it. Put the feature through its paces. The feature deserves your respect and more importantly you deserve to test in a cognitively challenging way. You know it makes sense! *I wrote this post for Kim, one of my amazing testers who wanted to find out more about regression testing.* *I’m sure there are many posts on this topic (if you know of some good ones, do us a favour and add a link in the comments).* ### Crossing the bridge over no-man's land URL: https://www.annemariecharrett.com/crossing-the-bridge-over-no-mans-land/ Last updated: 2021-06-17T02:05:52.000Z Indiana Jones in the Temple of Doom has a “moment of indecision” when halfway across a bridge he realises he’s been cornered by Mola Ram(the baddy) and his henchmen. He looks back and there’s a hoard of lusty savages baying for his blood, no luck there. He looks ahead only to find an equal challenge ahead. What is poor Indy to do? Anyone who has introduced change into a corporate environment will empathize with his situation. You know the decision to break away from the past is the right one, you run eagerly and embrace change, only to find half way through the journey, your path to success becomes blocked. I’ve been working with my test team for a while now moving from a process driven approach to a more of an Exploratory one. Its not been without its challenges. Some concepts I’ve introduced have been welcomed warmly but the reception to others has been a little icy. In particular, I’ve tried to move the team away from a test case management system. This was met with real concern and there was quite a resistance to the idea. This troubled me as while I understood their concerns, I knew the system was limiting the generation of new testing ideas. But how could I overcome this resistance? And really was it worth it? Perhaps the changes I had already made would be enough? The company was already more than impressed with the changes I had made so far. I felt like Indy at the foot of rope bridge, how the hell was I going to solve this one? So I stood at my crossroads and dithered. Oh God, did I dither. I ummhed and ahhed and pondered what to do. . But worse, I knew my indecision was making the situation worse, and that the more I dithered, the harder it would be to rid ourselves of the dust bag of tired and well worn ideas. Indy at this point, decides his only move is to cut the bridge leaving everyone to hang on for their lives. Fortunately, unlike Indy, I had a reliable and trustworthy sidekick. Together, we set up a task force within the team to attack the problem. After some discussion, we decided our approach needed four cornerstones. They were: 1) Creativity. However, we tested, our approach needed to enable us to foster and encourage creativity. With creativity comes new ideas, new models, new tests and so discover new bugs. *We’re covering this one with a number of approaches. One is to improve tester skill through practice and coaching. I’ve also created a folder of ideas for people to draw upon to help trigger new ideas.* 2) Visibility We wanted to be able to provide reporting on any testing we do. The reporting has to be simple yet with sufficient detail to ensure that our stakeholders understand what we have tested and why. *We have our trusty whiteboard which mostly hits the spot. We need to be able to pull up our actual testing including results in an easy to manage way. We’re looking into BBExplorer to handle that.* *We will also track any essential test results on a wiki in the form of a test report at the end of each iteration.* 3) Coverage We wanted to have some way of ensuring that key functionality/key features are always tested. *We most likely will rely on our test case management system for this, but we’re cleaning out all the dead wood and making the tests lighter and less authoritative.* 4) Knowledge We wanted to create a knowledge base. Our system is complex and it requires in-depth knowledge to test some areas. We want to store that information and knowledge. We also have a serious amount of test data we want everyone to be able to access, modify and improve. *We’ll use our internal wiki for this.* What I really like about what’s happened here is that the team came up with a solution to solve the problem. It’s a team decision which has got to mean easier implementation. I think a couple of really powerful things have come out of this. I’m listing them here: 1) Change can be scary. Not changing is worse. Get on with it. 2) Use people around you to help bring about change. 3) Never lose sight of your goal. This reminds me of Scott Barber’s email signature: “”If you can see it in your mind…you will find it in your life.” I feel good. I hope my team does too. We faced a challenge. We examined it, questioned it and overcame it and we’ve all come out sharper, enlightened and positive about the changes ahead. Now that’s what Exploratory Testing is all about. ### On conferences and insomnia URL: https://www.annemariecharrett.com/on-conferences-and-insomnia/ Last updated: 2021-06-16T23:51:07.000Z For me, the sign of a good conference is insomnia the night after the conference. Its as if my brain is unable to let go the new ideas and discussions I’ve had with other testers. Ideas that haven’t had an opportunity to be digested and reflected upon and usually around 2am after the close of a good conference my eyes snap open, my brain alive and alert ready for action. Ideas and discussions from the day merge and meld into a boiling cauldron of fizzling synapse and bubbling endorphins and, as much as I try to breath deeply relax and let it all go, I know deep down its all pointless. I’m going to have to get up and write down my thoughts and ideas. STANZ Melbourne is one such conference and its given be a double dose of insomnia resulting in frenetic writing at 12, 2 and 4 am until finally my brain exhausted became compliant and allowed my poor weary body to sleep. STANZ is sponsored and hosted by SOFTED. These folks at SOFTED really understand and ‘get’ software testing and it shows. As well as hosting this conference and getting some pretty impressive speakers in(I urge anyone who has the opportunity to hear Goranka Bjedov speak to do so) they also sponsor the [Sydney Testers Meetup](http://www.meetup.com/Sydney-Testers/?ref=annemariecharrett.com) by supplying thirsty and hungry testers with drinks and nibbles at networking events. Whats more they host peer workshops. The last one they hosted in New Zealand which was a huge success so much so that next year they hope to host one in Sydney. Watch this space. For me, STANZ gave me two core learnings. The first was Goranka’s talk about the future of quality. I think this was really insightful and gave me much food for thought. The concept that quality is dead and that as testers we need to reflect how this will impact us. I’m not sure yet what this means for me(I need some more 4 am thinking on that one!) but somewhere deep down, this struck a real chord. The second re-enforced to me the power of sharing problems and getting ideas from your network of testers. In 30 minutes, [Trish Khoo ](http://trishkhoo.com/?ref=annemariecharrett.com)had a plethora of new ideas and suggestions for me to take away. Many thanks Trish. Now off to order a double shot espresso…. ### An affidavit of sorts URL: https://www.annemariecharrett.com/an-affidavit-of-sorts/ Last updated: 2021-06-17T05:14:47.000Z The last three months I’ve worked specifically with the goal of my testers taking responsibility for their work. I’m a strong believer that each person is responsible for their own lives. I try to live by it and I expect others to do the same. It's one of the reasons why I endorse and believe Exploratory Testing is so powerful. The tester becomes centre to the testing. The tester is the decision maker responsible for their decisions(good or bad) and must be willing to stand by their choices and defend them where necessary. It's a powerful concept, and I think somewhat alien to the way we are brought up and perhaps bring up our own children. Instead we are protected or we try to protect, wanting to prevent harm to those we are close to. Actually, I think its impossible to totally protect people, much better to teach survival skills. I often hear people saying: “A great test manager removes obstacles so that their team can test” and its true. A good test manager will do that. However, I think a good test manager will also allow their testers to fail. Allow them to make their own decisions and learn to stand by those decisions and then defend them. If we don’t do that, are we really helping testers to learn and grow? I wonder. I’ve had the luxury of procrastination over the past two days. Yesterday, I spent a glorious few hours at the Seattle Art Gallery. It was the perfect antidote to CAST 2011, which was exceptional yet mentally exhausting. I also missed my flight back to Sydney, which meant I had a second day of whiling away hours at Seattle airport. Our brains are so fascinating, aren’t they? Just as I’m about to board the flight, a burst of insight and determination hit me. I guess all that procrastination culminated in my powerful thought. It's this. As we learn and grow as testers and human beings, we constantly need to revisit our beliefs, values and motivations. I realised mine needed a revisit. (Incidentally, my tutorial at CAST was on this topic, another example of “if you want to learn something, teach it!”) I needed to rework my ideas, goals and what was important to me. I needed to put myself in the centre of my testing career. I’m responsible for what I do and what I learn. Me. No-one else. Not mentors, not other testers, not thought leaders. Little ole me. A few testers at CAST really inspired me to be like this. Unfortunately, I don’t know their names or else I would cite them here. But they’re not thought leaders or mentors, they’re context driven testers with a mind of their own. I like that. I’ve always been able to think for myself but sometimes, you just have to up the anti, you know? I don’t know what this will mean for me. I’m not sure where it will lead. What I do know that from this point on, I will continue to own my decisions and I will stand by them, just as I encourage my own testers to do. I guess thats it. It's just something I wanted to share with you all. QED ### Coaching Space URL: https://www.annemariecharrett.com/coaching-space/ Last updated: 2021-06-16T22:15:27.000Z When James Bach gave his keynote on “Cool new things” at CAST 2011, I suspected that our work on coaching might come up. What I wasn’t expecting was a break down of my work and the recognition of the work I had done. So thank you James. I’ve been asked for a copy of the handout that I shared in my talk and James showed in the keynote I’ll post a more in depth analysis when I get back from CAST. ### Where do I go from here? URL: https://www.annemariecharrett.com/where-do-i-go-from-here/ Last updated: 2021-06-20T01:15:58.000Z In two months to this day, I will be giving my tutorial on [Career Management for Software Testers ](http://www.associationforsoftwaretesting.org/conference/cast-2011/tutorials/?ref=annemariecharrett.com)at[ CAST 2011](https://www.associationforsoftwaretesting.org/conference/cast-2011/?ref=annemariecharrett.com), in Seattle, USA. Any self respecting software tester has asked themselves at least once in their career. “Where am I going with all this?” or “Is this role really where I want to be for the next x number of years”? If you look around, its traditional\* to think of a software testing career path as follows: > At entry level as a Tester, you’ll primarily be performing test execution and acquiring niche skills to ensure systems meet performance standards required by the business and end-user.Progressing to Test Analyst and then on to Senior Test Analyst, you’ll work on more complex scenarios, become involved in requirements analysis and test case design as well as execution. As a Test Analyst you’ll also be able to become involved in the specialist areas of Test Automation and Performance and as a Senior Test Analyst you’ll start taking responsibility for junior staff.\* I think that’s a real shame that the role of Test Manager is considered the pinnacle of your career. Why is it that in order to advance your career you have to be seen to me leading people? So, I want to show testers that there are other career paths. In my tutorial we’re going to take a look at some of the typical roles testers in testing; That of a tester specialist, a test manager and a test consultant. But you won’t have to listen to me share about it, I got some fantastic software testers who have agreed to come in a share their own personal experiences. [Karen Johnson](https://www.karennjohnson.com/?ref=annemariecharrett.com) (Test Consultant), [Fiona Charles ](http://www.quality-intelligence.com/?ref=annemariecharrett.com)(Test Manager) and [Markus Gärtner](http://www.shino.de/?ref=annemariecharrett.com) (Software Tester) will be available to discuss the pro’s and cons of their respective roles and understand what skillset you may need to get perform these roles. I’m looking forward to giving this tutorial. Why not join me at CAST 2011? There are still some spots available. \* *sourced from Planit website* ### Keeping the lights on when your battery is running low URL: https://www.annemariecharrett.com/keeping-the-lights-on-when-your-battery-is-running-low/ Last updated: 2021-06-25T22:15:02.000Z Most of when I test I’m thoroughly engaged and involved and enjoying the moment. Then there are those “other” times. Typically for me they happen in the afternoon. My sugar levels get low, I get tired, and I stop testing well. But darn it, there’s so much testing to do! How can I and my team continue to test effectively? The biggest trap to fall into is to continue testing without changing something. Testing’s too important to be performed without full use of mental faculties. Its up to me to ensure I keep alert. Here’s my list: 1) Eat! Sugar levels are low: Have you had lunch??? No….Okay, this is basic, but don’t skip lunch. Your brain needs nourishment for all that cogntive work it has to do in the afternoon. 2) Take a break. It sounds counter-intuitive but by taking a break and doing something completely different, gives my testing brain a break. I like to do something physical,like going for a quick walk. 3) Swap a feature Ask a tester to swap areas with you for a while. A mental change of scenery if you will. 4) Make it enjoyable Find some way to make testing a bit fun for the team. Perhaps 3) Use the Trish Khoo method At the start of a testing iteration, she asks the question “What can I do differently” or “how can I make testing more fun”? What a great approach! There’s other ways to take breaks too. 4) Talk to a tester I have to watch out for this one, as I need to take into account other testers may be “in the zone” but if someone is free its great to have a chat. 5) Talk to your peers Again, timing is the key here. I find this one very invigorating, it also helps me take a step back from my immediate focus and see the “big picture” 6) Tweet, Blog, Share I’m finding this one a bit hard at the moment as the company I’m doesn’t allow skype or twitter. But when I can, I use my phone to keep in touch with testers outside where I’m working. For me its a mixture of making testing enjoyable, taking breaks and mixing things up. What do you do to keep alert while testing? ### How to write about software testing URL: https://www.annemariecharrett.com/how-to-write-about-software-testing/ Last updated: 2021-06-15T11:05:17.000Z Based on the number of requests I’ve had to write articles recently, there seems to be a big demand for testers who can write well about software testing. I’ve been asked by a few different companies to write articles on their behalf. Sometimes I’ve been asked to write posts for someones’s blog. I’ve only done that once with Quick Testing Tips which was a lot of fun. But generally, I find it hard enough to be inspired on my blog, let alone writing for some-one else's! I thought putting down what helps me, might help a few testers out there. Writing well is a great skill for a tester to have. Think of all those persuasive bug reports you will be able to write. It's also a great way to consolidate and refine your thinking. *(A great read on this topic is chapter is Maria Hammeren’s chapter entitled “writing as a method of reflection” in the book Dialogue Skill and Tacit Knowledge.)* ## 1) Write from the heart. Personally, I’m only motivated to write when I have something I feel passionate about. Thats a good thing because you can create a bond with the audience. But it can be unhelpful too if other people are relying on you to write something. Perhaps passionate is the wrong word, but writing posts that resonate with you reach out in some way to your audience. Perhaps it's the choice of words you use, I’m not sure, but your readers will pick up on your sincerity. ## 2) Be yourself That is, don’t try and be the expert unless you have personal knowledge about what you are writing. In practical terms, avoid trying to sound more experienced than you are. Be honest about your experiences.If you do write on a topic (say automation) in a authoritative manner, you had better be able to back it up with fact and substance. An excellent example of someone who does this well is Michael Bolton. I believe in what he writes because he cites references and backs up his statement with examples and facts. Nuff said. ## 3) Give yourself Permission I have James Bach to thank for pointing this one out in a tweet*.* Its so true. [Give yourself permission](https://theamericanscholar.org/permission-givers/?ref=annemariecharrett.com) to write your thoughts. They do count and they are of value. Trust me on this one. A great example of some-one who does this is Lanette Creamer. I admire they way she is so forthright with her ideas. ## 4) Proof Read I tend to write posts 2 or 3 times before I let them loose on the world. Seriously. This is how I work. a) Write down sentiment anyhow, anyway. Don’t worry about what it looks like b) At this point I feel free to explore, sometimes I stray from my originally intended topic to the point where I have a compeltely new article. c) Read the post (try reading it aloud), and rewrite it, move paragraphs around to get a better flow. Cut out paragraphs that prevent a nice flow through the post d) Take a break, do something different e) Come back re-read the post, edit it. check for spelling then send it A trap you can fall into though is over proofing. If you feel really strongly about something, and you leave it to the next day, you may chicken out and decide not the send it. Sometimes posting in the heat of the moment is a good idea. (Hey I never said writing was clear cut!) ## 5) Give credit If you get an idea based on a book you read, share that. If something inspires you, share the link. ## 6) Be Original No-one wants to hear trite stuff that parrots what others say. Believe me. Make your content your own. If you are talking about a hot topic, try and put your own personal spin on it. What are your thoughts on it? Don’t parrots a thought leader, their stuff is far better than yours anyhow. ## 7) Be Precise Often it's a struggle to come up with a precise word that reflects exactly what you want to say. But please, don’t be lazy about it. The english language is diverse and there’s bound to be a word that aptly describes what you want. Use a thesaurus if you have to, or do what I do and wait until the right word comes to you. Your readers will appreciate it. ## 8 ) Why do you write? Here is [Bernard-Henry Levy on his view on writing](http://www.bernard-henri-levy.com/bernard-henri-levy-a-lhonneur-dans-le-wall-street-journal-16325.html?ref=annemariecharrett.com). Great stuff. In particular what drives him to write is interesting: > I am not writing to be loved. There is as much pleasure to being hated as being loved. I write in order to convince. In order to win. In order to change, even just a little, the world. I recently launched an appeal on Twitter supporting those attacking the official websites of the Tunisian regime. An intellectual calling for hacking doesn’t happen very frequently, and there is a stir. I am happy that it succeeded. I care about being heard. Whats your driver? Is it your ego, is it SEO ratings or is it something else? I started writing to get ratings for my website, but now I write for the pure joy of writing, because I get a kick out of crafting a beautiful piece of work. ## 9) Practise The only way you are going to get any good at writing is by practicing. How are you going to practice, thats up to you, but writing a blog is a good start. Don’t aim for perfection, just get out there and write something. I will never forget my first blog post. It was the equivalent of hello world! (I wish I still had it, I would link it here) *\[By the way, when I’m talking about writing, its mostly in the context of articles, blogs etc.\]* ### Put your lips together and blow URL: https://www.annemariecharrett.com/put-your-lips-together-and-blow/ Last updated: 2021-06-21T07:47:19.000Z When I first heard about Tacit Knowledge, I had a vague idea what it was. The word “tacit” sounded a bit like “tactile” so I guessed it was knowledge that you could touch. I was a bit off the mark. Normally, I try to avoid starting my posts with definitions, it reminds me of those dreary debates we had at school where everyone started their discourse by using the dictionary definition. I’m making an exception in this case as I think its important that we all understand what tacit knowledge is, so here is the [wikipedia definition](https://en.wikipedia.org/wiki/Tacit%5Fknowledge?ref=annemariecharrett.com). Tacit knowledge is knowledge you gain by doing. This morning my son had a bit of a crisis going to school. As some of you know, we’ve moved country and continent. For my kids, this means new school, new friends, new environment. It can be a tough challenge for an eight year old. Suffice to say, he needed a bit of cheering up, so I suggested he look on the bright side of life. Cue Monty Python [Bright Side of Life](https://youtu.be/WlBiLNN1NhQ?ref=annemariecharrett.com) Well, it sort of worked especially when I tried to teach him how to whistle. Have you ever tried to teach someone to whistle? Lauren Bacall had a go, in the movie “To have and to have not” But you know what? As Alex found out, if you do put your lips together and blow it doesn’t mean you can whistle! Actually being able to whistle is pretty hard.(I’m sure many of you have memories of trying to whistle in vain!) But why is it so hard? The basic facts were explained and it seems quite simple. What vital piece of information is missing from Becall’s instruction? That my friend is tacit knowledge. Simply put, it's the knowledge you can only learn by doing. And so to software testing. The reason why software testing is so hard to teach is because it requires the student to learn by doing. To learn software testing you must….software test! Yes, you can read and learn the peripheral stuff around testing. For example you can learn what a IEEE829 test process is. You can learn how to write a test plan, how to create a test script, but that is not testing. Testing is the doing bit. The bit where you have to think, judge and act on a testing dilemma. Thats why some companies when interviewing for testers will ask you to test something. They know, intuitively, that testing is about doing, not writing. My Skype coaching sessions on software testing are based around this principle. You won’t find me “sharing my experience” in the sessions because that’s not how you learn about testing. Instead, you get a challenge, puzzle or dilemma that I work through with you. To really understand testing, you must **do** testing but also you must be aware of what you are doing while testing. Why? Because awareness brings about discovery. You discover assumptions you make in testing. You discover conflicting ideas and you discover your bias in testing. From that awareness comes learning and improvement. I think thats pretty damn cool. Now all together… “Always look on the bright side of life…” ### Beware the Lotus Eaters URL: https://www.annemariecharrett.com/beware-the-lotus-eaters/ Last updated: 2021-06-15T11:16:36.000Z I wrote a feature article for Logigear Magazine February Edition entitled Beware the Lotus Eaters. I really enjoyed writing this article, I hope you get something out of it. [Beware the Lotus Eaters](http://www.logigear.com/magazine/exploratory-testing/beware-of-the-lotus-eaters-exploratory-testing/?ref=annemariecharrett.com) *Drawing from the Greek mythology of the lotus eaters, Anne-Marie Charrett warns testers to be weary of enjoying early success too soon upon finding high impact bugs.* Like many professions, the lure of the “low hanging fruit” in software testing is very appealing. In this case, fruit refers to finding high impact bugs quickly. Exploratory Testing (ET) combined with Risk based Testing is a useful strategy for finding these bugs. Of course ET can deliver a whole lot more than that, but the opportunity to demonstrate an immediate impact is often a compelling reason to use Exploratory Testing. Testers are not the only ones who like this fruit; it is also welcomed by the rest of the team, in particular project managers. Some bugs found early in the testing phase are, in general, welcomed by most team players. Consequently, exploratory testers often tailor strategies to find and deliver these types of bugs. This means cheap and easy tests are run first. There is nothing wrong with this. It’s a good and effective strategy. There’s nothing like a few serious bugs at the start of testing to lull a manager out of a false sense of security. It becomes a problem though if it becomes the only model used to perform testing. Testers eat the lotus flower of early success and are seduced and satiated with its bewitching nectar and stop testing. Any inner doubts are squashed with arguments such as “there is no such thing as 100% coverage” or “exhaustive testing is expensive and impractical, so why try?” This is especially true when faced with complex and hard to understand software. It can be a big problem, because Exploratory Testing is tester centric—making the tester in control of how much testing to perform. In general, there are few team members who will object to the decision to stop testing and jump ship. So, testing is declared as “Done Enough.” To have “Done Enough” testing is the poor man’s cousin to “Good Enough” Testing. “Done Enough” testing stops when the tester has had enough. Some bugs have been found and any more testing either requires imagination, technical expertise or some hard work on the tester’s part. “Done Enough” Testing is bad, folks. It reflects poorly on test teams and does little to educate the wider community on the benefits of Exploratory Testing. Exploratory testers (well, any tester for that matter) need to be aware of the lotus flower and continue to test. And while testers may not be able to perform exhaustive testing, it shouldn’t preclude extensive testing. Extensive testing goes beyond early success. Testers don’t dwell on the satisfaction of finding bugs early. They test beyond that. Project managers might be reasonably content (yes, they may have been seduced by the lotus flower, too) but testers need to wake up and keep testing until testing is “Good Enough.” It’s more expensive to continue testing and it is harder to achieve at a reasonable price. This is where automation or tools come in. A good toolsmith can change where tools used effectively will reduce the cost of testing to allow more testing to take place. This results in a better standard of “Good Enough.” I had a firsthand experience of the importance of tools in exploratory testing. Eusebiu Blindu, a Czech tester, recently came up with an interesting online challenge. He created a testing exercise in finding bugs and patterns. The application drew a polygon with the number of sides determined by a number you entered into the field. There was no indication of the limit of numbers this field could take. I decided to test using a variety of numbers as testing every number seemed beyond my capabilities. I took the following numbers: 0 \~ 10, then I jumped to 15, tried a few random numbers to 99, 100, 999 and then 1000 and finally I threw in a couple of negative numbers to see what would happen. I noticed some relationships in the colors, a few irregularities, but beyond that nothing else stood out. So what did I do? Did I read books to find out more? Did I seek outside knowledge, ask someone, or question. Did I try and change my model? Did I examine my assumptions? No, instead I limited my testing. I put the puzzle aside. I decided I had “Done Enough” Until I saw the following tweet: *@jamesmarcusbach “A good exercise for tools. RT @charrett: Eusebiu sets a challenge. Anyone care to answer the call?”* I was surprised; I didn’t think that this puzzle merited a tool. It was a polygon puzzle with only one input. What was the benefit from automating one field? Anyhow, how could you automate the testing of something like this? I contacted James Bach on Skype and asked him what he meant by the tweet. We had a coaching session on the topic. Incidentally, James and I do a lot of IM coaching. In fact, we’re in the process of writing a book on the subject. James explained to me he had tested 1200 inputs. I was impressed; regardless of the time it took to enter so many numbers, how could he remember the differences between each of the polygons? It turned out his solution was to write a Perl script to automatically enter in a number, then take a snapshot of the result and save it in a directory. This was then followed by some deft blink testing. I followed his approach and very quickly, patterns and bugs became apparent. I realised how limiting my approach to testing was in this scenario. When faced with a problem beyond my immediate capability, instead of figuring out how to fix the problem, I narrowed my model. I allowed myself to be seduced by the deadly combination of early success and fear of complexity. I reduced the scope because of the complexity of inputting large inputs. Rather than solve the problem of entering large amounts of inputs, I decided to test less. This was a major flaw in my testing strategy. The lesson I learned was not to be limited by what seems to be impossible or hard. If it’s not possible to achieve (or if it’s too tedious to achieve) through manual means, then find another way of doing it. In this case automate it! Testers need to be able to suspend belief of the impossible and put aside a skewed view of what can and cannot be done. They need to shine torches not only where others don’t want to look but also where we fear to tread Beware the lotus eaters! ### Not a conference but a CASTalyst URL: https://www.annemariecharrett.com/not-a-conference-but-a-castalyst/ Last updated: 2021-06-17T04:57:25.000Z Firstly, apologies for the terrible play on words, its got to be one of the worst pun ever! Put it down to a lack of imagination. I’m going to be busy at CAST 2011 this year as not only am I attending but I’ll be holding a workshop and a track session. The 1/2 day workshop is on Career Management for Software Testers and the track session is on Skype coaching. You can find out more about the details about all the tutorials [here ](http://www.associationforsoftwaretesting.org/conference/cast-2011/tutorials/?ref=annemariecharrett.com)and the track sessions [here](http://www.associationforsoftwaretesting.org/conference/cast-2011/sessions/?ref=annemariecharrett.com). There are some great talks on this year and I’ve earmarked a few, hopefully there not on the same time as me! Any tester who is serious about testing needs to consider going to CAST. It’s a conference that you will not forget. Trust me. I had the opportunity to go to CAST 2010, sponsored by the software testing club and I wrote about the experience here and here It's been six months since then, and on reflection, going to that conference wasn’t an event but more a catalyst to learning and experiencing more about testing. Rebecca Fieldler has on her Skype profile the following quote by Will Durant: ” Education is a progressive discovery of our ignorance.” and I think that sums up nicely my feelings on CAST. It wasn’t so much what I learnt, but the realisation on how little I knew. Since then, I’ve made a real effort to up my game. My book library has exponentially grown and I’ve even read some of them! I made a commitment to myself at CAST 2010 to start speaking a conferences. I’ve spoken at a few conferences since then, and speaking at CAST 2o11 is like coming full circle on that promise. I’m also making more of an effort to keep in touch with other testers I met at the conference, people like Karen Johnson and Fiona Charles. So, you see, what I mean when I say catalyst! I hope to see you there, Anne-Marie *Update: If you feel its the right time for you to start speaking at conferences, CAST is offering an emergent session run my the indomitable Matt Heusser. You can get all the details on this* [*blog*](http://xndev.blogspot.com/2011/02/casting-wide-net.html?ref=annemariecharrett.com) ### The antipodes are calling URL: https://www.annemariecharrett.com/the-antipodes-are-calling/ Last updated: 2021-06-16T09:23:32.000Z I’m heading to Sydney, Australia on 22nd January 2011\. I will be looking for test consulting work preferably through my Australian consulting company [Testing Times](https://testingtimes.com.au/?ref=annemariecharrett.com). What do I offer? I shed light on testing problems often obscured or caused by a testing process. I bring a new perspective often hard to gain when inside an organisation. I do this by thinking outside the square, looking for solutions outside traditional process orientated ideas. **So, if you have a problem that you haven’t yet being able to solve using traditional testing approaches, or you want a testing approach based on excellence and speed\* why not contact me?** I also deliver one day training workshops on testing. These workshops focus on increasing tester skill. I offer a [context driven approach to testing](http://www.context-driven-testing.com/?ref=annemariecharrett.com). These principles are: 1\. The value of any practice depends on its context. 2\. There are good practices in context, but there are no best practices. 3\. People, working together, are the most important part of any project’s context. 4\. Projects unfold over time in ways that are often not predictable. 5\. The product is a solution. If the problem isn’t solved, the product doesn’t work. 6\. Good software testing is a challenging intellectual process. 7\. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products. **What this means to you is that the advice I offer is to ensure you the customer get the best value out of your testing.** If you like that idea then contact me at amcharrett @ testingtimes.com.au *Interesting fact on the word [antipodes](http://en.wikipedia.org/wiki/Antipodes?ref=annemariecharrett.com). “The *antipodes* of any place on Earth is the point on the Earth’s surface which is diametrically opposite to it.” – Wikipedia. So, technically that would mean somewhere in the Pacific Ocean. Though I suspect that not a lot of testing is done there!* ### In search of perfection URL: https://www.annemariecharrett.com/in-search-of-perfection/ Last updated: 2023-09-11T10:33:15.000Z I knew Flynn was in trouble the moment he created a program Clu 2 as his doppelgänger. You see, the purpose of Clu2 was to create the perfect system. Flynn, a programmer failed to understand the struggle between perfection and quality. I’m guessing he didn’t spend a lot of time in the test team! Of course, none of this makes any sense unless you have watched [TRON the Legacy.](http://tron.wikia.com/wiki/Clu%5F2?ref=annemariecharrett.com) Warning! I’m giving a bit of the plot away below… In Tron Legacy, Flynn a programmer realises that he can’t spend all of his time in(yes in) his computer, so he creates Clu 2, a program that will create the perfect system for him. Unfortunately, the perfect system starts to wipe out everything that it sees as imperfect and pretty soon our world as we know it is being threatened. I know, its a pretty silly storyline, still the effects were great and it got the thumbs up from the 7 & 9 yr old critics. What is perfection? Perfection, as I understand it, is to be without fault or defect. A pretty tall ask for software. And Quality? Well, that is value to some person.¹ Both Quality and Perfection are subjective if you think about it. For example, art critics describe the Mona Lisa smile as the perfect smile. But in my mind, that small measly semi grin is far from perfect. So, what is the difference between Quality and Perfection? Perhaps quality is more realistic, more humane? They appear to be related in some way. When some-one says something is perfect, are they perhaps saying that the quality is perfect? Maybe perfection is a state in the quality model? A Utopian ideal that perhaps is something to aspire to as opposed to achieve? At the end of the movie, Flynn realises that perfection(his son) was in front of him all the time (I told you the storyline was dodgy). I guess at that moment in time, blinded by emotion, his son was perfection to him. I suspect though, like any parent with in-attentional blindness that moment quickly passes. So perfection and quality are dependent on time too. I think Markus Gärtner tweeted about that once. How do we deal with these concepts in software testing? Here’s how I think about it: Perfection is a great goal to aspire to, but my expectation is quality.² I think this is a healthy way to look at it. For one thing, it stops me from asking for unrealistic demands from myself and others. I do this by expecting good enough testing³. I guess we all fall into this trap of perfection sometimes. its easy to demand perfection in other or systems yet excuse the imperfect in ourselves. In software testing, we expect perfection from developers yet don’t accept or recognise our own failures. *“What do you mean it's not a bug? Of course it is!”.* Expecting perfection in yourself is another trap and can set you up for some major life disappointments. A more realistic approach I think is to aspire for perfection but try to expect something a bit more realistic?Well, I try anyhow! We need to combine this reality with a good dose of humility about our own failures and failures in others. Then we will begin treating people with respect, a little more understanding, and perhaps then, our software will be more about the people, less about ourselves. Maybe. ———————————————————————————— ¹ Weinberg: “Quality is value to some person(s)” ² Read Secrets of a Buccaneer Scholar” for more on this. ³“Good Enough testing is the process of developing a sufficient assessment of quality, at a reasonable cost, to enable wise and timely decisions to be made concerning the product.. ### Exclusive cartoon - see it here first ! URL: https://www.annemariecharrett.com/exclusive-cartoon-see-it-here-first/ Last updated: 2021-06-16T08:16:40.000Z Here is an exclusive, never seen before cartoon, created especially for the upcoming ebook “If I were a testcase, I would…” As you may know, this e-book contains over 300 memorable and funny responses to the Twitter challenge started by the [Daily Testing Tip](https://dailytestingtip.blogspot.com/?ref=annemariecharrett.com) prompting testers to complete the phrase “If I were a test case I would…” The book will be available for download for free. We are still looking for more sponsors, so please if you or your company wishes to advertise in this book, please check out the advertising details at [Daily Testing Tip](https://dailytestingtip.blogspot.com/p/e-book-advertising.html?ref=annemariecharrett.com) The closing date for advertising is December 10th 2010\. So be quick. All proceeds from advertising will go the Chandru Fund to help raise funds for Chandrashekar B.N (Chandru) , a software tester in our community that has been recently diagnosed with Acute Lymphoblastic Leukaemia. [Cartoon Tester ](http://cartoontester.blogspot.com/?ref=annemariecharrett.com) (Andy Glover) has created some of his memorable cartoons into this great little ebook. Here’s a glimpse of what’s to come….. So if you haven’t joined in the fun why not do so now? If you were a test case, what would you do??? Next Tuesday we will be holding a special #dttip challenge on twitter, so look out for that. So please give generously with your ideas and contribute to the challenge. ### Discovering Big Trak URL: https://www.annemariecharrett.com/on-the-road-to-a-big-trak-discovery/ Last updated: 2021-06-17T00:01:06.000Z Recently, I’ve been reading up on how we approach and report on solving problems. One book recommended to me was Exploring Science by David Klahr. There’s a lot in this book. Khlar performs experiments in his “Discovery Lab” where participants are observed solving and reporting problems. He uses a robotic toy called Big Trak. It’s a self-propelled, self-contained toy that can be programmed to move around the floor. Khlar programs a function (its a repeat function) on the toy. He then asks the participants to figure out the function and report how the program operates. Its been an interesting read and some of the dialogue that happens during hypothesis and testing fits in nicely with the IM Coaching I’m giving. Its one of the reasons James Bach suggested I read the book. These experiments were performed in the late eighties, so I was quite surprised to see Big Trak’s been sold in my local bookstore. I immediately grabbed a couple and brought them home. I handed one out to one of my kids to see if he could figure out how it worked. Here’s the video. I’m going to incorporate these new robotic toys into my Exploratory Workshop if I can just work out how to switch off that really annoying beep sound. ### Battleships Ahoy URL: https://www.annemariecharrett.com/battleships-ahoy/ Last updated: 2021-06-16T23:34:10.000Z I had a great day today. My youngest son, Alex (7) persuaded me to buy him a new game today. Its not hard. I’m easily persuaded. But the game of choice was interesting. It was Battleships. Now, I remember this game. I played it (and loved it) when I was little. Battleships requires a good strategy, not different to a testing strategy in fact. You have to guess where the ships/bugs are. Sure there are some strategies that are effective, (I confused my kids by placing all but one of my battleships on the outer perimeter). You might have some idea of where they might be based on experience, but as one of my kids put it. *You basically have to guess first, and then after that start thinking.* sometimes I perform exploratory testing like that. I just have a go! But that doesn’t mean I perform ET without thought. What my son was trying to say (and incidentally what lots of testers try to say) is that sometimes we have to suspend observation and inference. Sometimes, what gets us going is a best guess. Let's not ignore our best guess, because just like in battleships, even if the first decision …A/9 is a random suggestion, after that you will need a strategy. What the hell, the kids loved the game. I loved playing the game. We all had fun. ### From Little Things Big Things Grow URL: https://www.annemariecharrett.com/from-little-things-big-things-grow/ Last updated: 2021-06-21T00:08:14.000Z One thing that I get occasionally complemented on is my writing. People write and let me know how they appreciate my writing style. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/smallthings.jpeg "From Little Things Big Things Grow") Initially this surprised me, because I do not consider myself a naturally gifted writer. In fact, quite the opposite. Reading and Writing was always a bit of a nightmare for me. I had an elder sister who was extremely talented when it came to English. She naturally ‘ate’ her way through literature and flew through reading the [Famous Five](http://en.wikipedia.org/wiki/The%5FFamous%5FFive%5F%28series%29?ref=annemariecharrett.com) whilst I plodded through the [Secret Seven](http://en.wikipedia.org/wiki/The%5FSecret%5FSeven?ref=annemariecharrett.com). Its not that I couldn’t do it, but I could never do it as well as my older sister and that pained me. Come secondary school, though proficient in English, I still had this niggling sense of inferiority, exacerbated by the teachers at school who consistently expected more from me, “because my sister is so good….”. Then, the thought of writing a school essay on any topic terrified me. I did not feel I was incompetent, I knew I was incompetent. Funnily enough, my essays reflected this skewed view of my own ability. So I did what I normally do when faced with that type of scenario. I gave up. It's a strange old world, and the clock turns around and for one reason or another I started blogging about testing. Me? Writing? My totally creative family were to say, slightly surprised. But, I’ve been blogging for about 3 years now and it looks like I’m not that bad at writing after all. And I am proud of this turnaround, in both my writing skill, and my awareness of my ability. Its demonstrates to me, what I can do if I just give something a go. In fact, I have been asked and I’m in the process of contributing to a book on testing, as well as collaborating with James Bach on a book on IM Coaching. Its a little victory, but I think an important one. *[From Little Things Big Things Grow](https://en.wikipedia.org/wiki/From%5FLittle%5FThings%5FBig%5FThings%5FGrow?ref=annemariecharrett.com) is based on the story of [The Gurindji Strike](https://en.wikipedia.org/wiki/The%5FGurindji%5FStrike?ref=annemariecharrett.com) and [Vincent Lingiari](https://en.wikipedia.org/wiki/Vincent%5FLingiari?ref=annemariecharrett.com). It describes how the [Gurindji people](https://en.wikipedia.org/wiki/Gurindji%5Fpeople?ref=annemariecharrett.com)‘s claim sparked the [Indigenous](https://en.wikipedia.org/wiki/Indigenous%5FAustralian?ref=annemariecharrett.com) land rights movement. The protest led to the [Commonwealth Aboriginal Land Rights (Northern Territory) Act 1976](https://en.wikipedia.org/wiki/Aboriginal%5FLand%5FRights%5FAct?ref=annemariecharrett.com).* *The Act gave Indigenous people freehold title to traditional lands in the [Northern Territory](https://en.wikipedia.org/wiki/Northern%5FTerritory?ref=annemariecharrett.com) and the power of veto over mining and development on those lands. In 1975, 3,236 km² of land was handed back to the Gurindji people.* ### Dublin Software Testing Automation Morning URL: https://www.annemariecharrett.com/dublin-software-testing-automation-morning/ Last updated: 2021-06-15T11:14:47.000Z I went to the Softtest Software Testing User Group networking session last night. About 10 erstwhile software testers gathered together on a wet and windy night to discuss how to help software testers in Dublin. We had some great discussions, a lot around automation tools, but also on the topic of up-skilling at little or no cost. I’m a big believer in this. I think it doesn’t have to cost a lot to keep yourself trained up as a software tester, you only need a willingness to learn. We at Softtest have been throwing the idea around for a while to hold some practical hands on automation testing sessions. The idea is that testers would come (for free) learn a bit about an open source tool (JMeter & Selenium are two considerations), get to ask questions and hopefully get to use the tool a little. We think a Saturday morning would work, and [Softtest ](http://softtest.ie/?ref=annemariecharrett.com)would supply a venue, breakfast and strong coffee. But we would need Volunteers. Software Testers who have open source software testing automation skills willing to come in and share some of their knowledge with others. So are you a Dublin based software tester, with a bit of spare time on a Saturday morning? If your Interested in attending or helping out with your automation skills? Leave a comment or email me at amcharrett@gmail.com ### Personality Traits in Software Testing URL: https://www.annemariecharrett.com/personality-traits-in-software-testing/ Last updated: 2021-06-17T05:17:26.000Z I have lots of little and major projects going on at the moment. One of them is to write a chapter for an up coming book on the cost of testing. My chapter is complete thankfully, but as I was researching my topic, I came across this article on [Personality Traits in Software Engineering](http://ijikm.org/Volume2/IJIKMv2p163-177Sodiya.pdf?ref=annemariecharrett.com). I found it quite enlightening and somewhat entertaining read. Naturally, I was interested in what it had to say on the subject of software testers, in particular, the difference between software testers and developers. Apparently there are the “Big Five” of personality traits. They are Neuroticism, Extraversion, Agreeableness, Conscientiousness and Openness to experience. This study added another personality trait or factor Cognitive Ability. Personally, I question whether you can call that a personality trait, but for the purposes of this post, lets accept that as a given. **Testers on the whole came out pretty well rounded. Here’s the breakdown:** Neuroticism: LowExtraversion: MediumConscientiousness: MediumOpenness To Experience: HighCognitive Capability: HighAgreeableness : HighSo, on average we are an agreeable bunch of people, open to experience (see below) with a high cognitive capability. A hearty clap on the back fellow testers, we all knew we were pretty special. **Developers were pretty similar, but the major difference is they scored low in the openness to experience trait. Here are their scores:**Neuroticism: LowExtraversion: LowConscientiousness: MediumOpenness To Experience: LowCognitive Capability: HighAgreeableness : High So what is openness of experience? Well the paper describes it as: *“This is the tendency to enjoy new intellectual experiences and ideas. Its components include imaginative, curious, unconventional, broadminded and cultured”* I can live with that! So there you have it folks, proof that testers and developers are different and bring different traits to the table. But lets finish this blog post on a positive note. Both developers and testers rate well in cognitive ability and agreeableness and we both scored low on the neurotic scale. Thats a good thing! It means were both pretty smart and easy to get along with people. Lets give both teams the respect they deserve for that. ### *Definitions* **Neuroticism:**– This is the tendency to experience unpleasant emotions relatively easily. Its components are anxiety, hostility, depression, self-consciousness, and impulsiveness.The opposite is emotional stability or self-control.People who are high in this factor have the following features:- - They are faced with effect of decreasing cognitive and performance capacities (Mathews et al., 1991) - They have increasing probability of errors - They are more distracted from the task at hand (Hansen, 1989) - They have tendency to experience greater stress symptoms - They tend to be pre-occupied with their anxieties and worries - There is also evidence that they do not seek active control of the environment (Judge, 1993) **Extraversion:**– This is the tendency to seek simulation and enjoy the company of other people. Its components include warmth, sociable, assertive, energetic, adventurous, and enthusiastic. People who are high in this factor have the following features:- - They are sensitive to monotony (Thiffault & Bergeron, 2003) - They are high sensation seekers and have a greater tendency to take risks (Jonah,1997) - They demonstrate significantly poorer performance on vigilance tasks (Koelega,1992) **Conscientiousness**:- This is the tendency to show self-discipline, to be dutiful, and to strive for achievement and competence. Its components also include self-discipline, consultative, competence, order, dutifulness and thorough. People who are high in this factor have the following features:- - They are always thorough in decision-making style (Clarke & Robertson, 2005) - They follow rules and regulations (Arthur & Doverspike, 2001) - They are interested in goal targeting and systematic approach - They are always interested in providing adequate cost-benefit analysis and contingency planning (West et al., 1993) - They are less vulnerable to cognitive failures **Agreeableness**:- This is the tendency to be compassionate towards others and not antagonistic. Its components include pleasant, tolerant, tactful, helpful, trust, respectful, sympathetic and modest. People who are high in this factor have the following features:- - They are generally easy to get along with (Hough, 1992) - They are salient in situations that involve interaction or cooperation with others (Barrick & Mount, 1991) - They are less aggressive - They are emotionally stable - They are trustworthy and compliance (Clarke & Robertson, 2005) **Openness to experience:**– This is the tendency to enjoy new intellectual experiences and ideas. Its components include imaginative, curious, unconventional, broadminded and cultured. People who are high in this factor have the following features:- - They have positive disposition towards learning (Salgado, 2002) - They tend to be liable to rule violations, experimentation and improvisation (Clarke & Robertson,2005) - They are less suitable for safety critical tasks **Cognitive Ability:**– This is a factor added to the big five factors because of the requirement of SE. It has the following components:- - Abstract level thinking:- This is the ability to conceive an idea or concept without any relation to any practical instance. It can be simply put as theoretical analysis. - Mindset:- A fixed mental attitude or disposition that predetermines a person’s responses to and interpretation of the situation. It typically has to do with the collective responses and interpretation of the situation by individuals. - Analytic:- This is reasoning or capable of reasoning in clear and consistent manner.It is reasoning and or acting from a perception of the parts and interrelations of actions. - Concentration capability:- This is the ability to provide constant and productive undivided attention to events. - Expressiveness:- Ability to present one’s ideas in acceptable forms to others. - Visualisation capability:- The ability to provide a technique or method for seeing the unseen. It is also the ability to use metal model to describe or represent events. *[From “An Improved Assessment of Personality Traits in Software Engineering” (2007) A. S. Sodiya, H. O. D. Longe, S. A. Onashoga, O. Awodele, L. O. Omotosho](http://ijikm.org/Volume2/IJIKMv2p163-177Sodiya.pdf?ref=annemariecharrett.com)* ### Teaching or Learning? URL: https://www.annemariecharrett.com/teaching-or-learning/ Last updated: 2021-06-16T23:16:04.000Z Do you have a focus when giving training? Sometimes, in my eagerness to ‘teach’ I forget to focus on something important. I forget that the lesson is about the student not me. I become more more concerned in my ability to be able to teach effectively. I want the student to come away feeling they have learned something. Noble goals perhaps, but its nothing to do with training. Training is about the student, not the teacher. Much more valuable is to focus on the student and provide a space for learning , giving people the opportunity to learn new things. Focusing on ‘teaching’ is about your ego. It's about you wanting to get something out of the training. I fell into this trap this week. I wanted to ‘teach’ someone about testing. When their conclusion differed to the one I wanted them to come to, I got frustrated. “How”, I thought, “am I going to be able to teach people about testing, if they don’t learn the lesson”? But I’m wrong. Its not about me being successful in teaching. Its about me providing a space for them to learn. In this case, they didn’t see it. That ok. Not everyone is going to learn all the time. Thats ok too. I miss stuff all the time. I don’t get stuff, I miss traps, I fall into traps. I forget to ask questions…often. But thats ok too. Missing stuff, making mistakes is part of what makes us human. Being human is special, it's what we are all about and it's something that we all have in common. (Except for Rob Lambert, I suspect he is an alien). So, go forth and learn. Go forth and create learning opportunities. But you know what? If people don’t learn from you, it doesn’t mean you haven’t taught well. Perhaps its simply that the lesson is for another day. That was the lesson I learned today. ## Addendum I was chatting to [Pradeep ](http://testertested.blogspot.com/?ref=annemariecharrett.com)Soundararajan online about training. I asked him his view on teaching, and learning. He gave some great reasons why perhaps people fail to pick up a lesson. He agreed to let me post them here: \[09/07/2010 18:16:31\] Pradeep Soundararajan: Its not about people getting it always \[09/07/2010 18:16:51\] Anne-Marie Charrett: how do you view it? \[09/07/2010 18:17:33\] Pradeep Soundararajan: Many ways: 1: I think when people don't get it, they are helping us understand that we have probably not got it either. 2: When people don't get it, they may also have made the choice consciously. So, we don’t need to bother when we identify it was their choice to avoid getting it. 3\. When people don't get it, they may require alternatives of explanation. We might want to help them. 4\. Learning is not an activity that can be time boxed for everyone. For some people, they need to go back and face a few contexts to get it. 5\. I have received emails from people who told they got the value of my workshop not immediately but after a year. Thanks Pradeep, these are great insights to share. ### The pain...the pain URL: https://www.annemariecharrett.com/the-pain-the-pain/ Last updated: 2021-06-18T04:00:26.000Z I’m currently experiencing a boundary test. The test is…how much toothache can I tolerate before resorting to as massive overdose of painkillers? I know, I can feel you all wincing in empathy, even if you’ve never experienced toothache, almost everyone can empathise with the pain. But…….. there is relief. I am to visit the dentist tomorrow. This story will have a happy ending. I know I will end up in less pain…eventually. I know the dentist is going to have to ask me questions and perhaps explore pain points. Bad pain points. I also know it's necessary for him to come to some sort of conclusion in order to help me. I know it's necessary, even if its hateful, cringe worthy and expensive. Ok here it comes, testing analogy….. I love to explore. You probably love to explore. But I love (and I suspect you do too) explore the bits I find interesting. I explore those bits that come naturally to me. Bits that I’m good at. I have a tendency (or bias) to ignore the bits I find dull, or that I’m not so good at…painful even. Things such as tedious tasks, like examining behaviour I’ve already looked at. It's important for me to do it though, I know to perform a thorough job, I have to examine areas I feel less comfortable in, areas that I have only checked, not tested. Sometimes though, the pain is too bad. It's time to call in the expert. Someone who will do the job for me. Like a dentist, perhaps? Wish me luck… ### Rapids Software Testing URL: https://www.annemariecharrett.com/rapids-software-testing/ Last updated: 2021-06-16T09:26:58.000Z As some of you know, I’m in the process of creating an Exploratory Testing workshop. It’s been a bit of a wild adventure, but hey, I’m clinging tightly to my oars as I hurtle down the rapids of ET adventure. Have you ever been white water rafting? I have, and here’s a tip, don’t bother going if there is a drought. Trust me, I learned the hard way on the Tully River in North Queensland. Tully is one of the [wettest populated towns in](http://en.wikipedia.org/wiki/Tully,%5FQueensland?ref=annemariecharrett.com) Australia with an average annual rainfall exceeding 4000 mm (13.1 ft). But not the year I went. I went when there was a drought and the water levels on the river had dropped.While the day’s outing was great fun, it never reached the hair raising exhilaration that I had anticipated. It can be a bit like that in testing I guess. If you want to have fun and be challenged, it helps to go where the water is deep. Well I’m in deep testing water and I’m loving it! A day doesn’t go past where I’m not motivated to learn more and to challenge myself. To hell with the life jackets, watch me go! Why? Because I’m learning something that is fundamental to any tester. ## I’m learning how to teach testing. Precisely, I’m learning how to teach testing through [Socratic Examination.](http://en.wikipedia.org/wiki/Socratic%5Fquestioning?ref=annemariecharrett.com) This means, that I’m learning to ask the questions, pose puzzles and push students to struggle through testing principles so they come to a better understanding. If this style sounds familiar, its because James Bach is teaching me this stuff. Its all part of this [new coaching program](http://www.satisfice.com/blog/archives/393?ref=annemariecharrett.com) which I’m aligning myself with. I will also be collaborating with him on a book he’s writing on the topic. My experience on learning to teach suggests to me that this book is much needed. Practice is key to being a good teacher, but having a few strategies and heuristics to guide you along the way is essential too. This book will go some way to demonstrate that. So what have I learned so far? **Lesson 1: A Mental Model** When working with a testing exercise you need a mental model of what you are aiming to teach. Its not an easy task. There is no one strategy or model that fits all students. All students differ in their learning needs and in temperament. what works for one person, may not be suitable for the next, yet your mental model needs to cater for each individual. You need to know your outcome, and where you are taking the exercise and still allow the student capacity to explore and come to some learning outcome. I’ve noticed that James starts his coaching sessions with a mental test. He uses that to observe a tester’s thinking. He then frames his coaching session around a key thought or lesson, allowing the tester to explore, yet always bringing them back to the intended final outcome. All without one powerpoint slide. I’m learning how to do that too. **Lesson 2: Observation.** The coaching sessions may seem unstructured and ‘ad-hoc’, but as I mentioned there is always an underlying model or framework in use. I’ve been observing some of these coaching sessions, and I’m starting to see patterns of behavior. I asked James about this and his comment was this: *Anne-Marie Charrett: When you are having these conversations do you consciously have an idea of the types of patterns you are going to use?* *James Bach: Yes* *James Bach: I’m trying to become more conscious of them and to make them easier to teach* *James Bach: that’s what I’m using you for.* *James Bach: we’ll learn them together* Observing patterns is essential to honing your teaching skills. Only through observation can you identify how you teach, what your natural strengths are or where you are biased. But also identifying patterns, helps you know what pattern (or heuristic) to use next. Naturally, being taught directly by James Bach is helping a lot too. I think confidence in yourself is critical, both as a tester and a trainer. After all, how can you confidently explain your testing story if you have little confidence in yourself or what think you believe? So that comes to lesson 3: **Lesson 3: A Testing Story** Teaching testing gives you confidence in your testing story. Yes, I read and study Exploratory Testing, I use Exploratory Testing. But standing up and talking about Exploratory Testing to me is the ultimate test in what you believe. If you can stand up and talk about testing, its a great boost to your testing story. Well , it is for me anyhow. This confidence comes by first willing to put yourself in a vulnerable position, where you are willing to learn. It was only when I blogged about my difficulties about creating an ET workshop did help arrive. It also comes through practice. I’m doing that too now, by blogging and testing out by challenges on fellow testers. I’ve already asked a few of you to testing challenges on skype or IM. I need to practise my exercises and puzzles against a variety of people. If you want to be part of the fun, skype or IM me. I’m happy for anybody to take up my challenges. I need practice to improve my skills. There’s lots more I’m learning, most of which my mind has yet to digest and formulate into identifiable ideas. But are you starting to see something here? Teaching testing is very similar to testing itself, maybe a bit more intense…. like ET on steroids perhaps. I strongly urge any tester looking to improve their skills to consider this option. Even if you never end up teaching formal workshops, the insights you get about yourself, the confidence it builds in yourself and your ideas in testing will stand you in good stead. **Footnote.** *I value your thoughts, in particular if you disagree, or question what I’ve said. Every discussion on this helps me refine and consolidate my understanding on the subject.* ### Exploring new Territory URL: https://www.annemariecharrett.com/exploring-new-territory/ Last updated: 2021-06-16T08:12:17.000Z I learned something really important about myself today. What all started it off was a discussion I was having with James Bach on Exploratory Workshops. *(You may remember that I blogged about designing an ET workshop recently – well James offered to help out and I wisely accepted his offer)* One comment he made was this: *\[19:49:43\] James Bach: – … you don’t need to prove anyone right or wrong. You can take the attitude that you are just trying to help everyone be clear.* Ok I thought, instead of trying to control the exercise and making sure you prove a point, it would be better to relax, let the exercise take its course and trust the outcome. With some forethought, I felt that while it was a challenge for me, it was doable. I left it at that and moved on to discuss other topics. But my brain had other ideas and at 4 am it woke me up to think more about Socratic Examination. Now, I’ve always been a big believer in goals and sticking to them. I make goals and generally I reach them. Any thing less than success is…well, failure. But I realised (at 4.30 am) that perhaps this idea of ‘not controlling’ is not just for Exploratory Testing or for an ET workshop, but it's a great way to approach your life. Perhaps, just perhaps instead of sticking blindly to goals regardless of outcome, its better to allow yourself to wander, drift….explore even? True, I won’t have the security of knowing my destination………. But possibly, just possibly if I apply this idea to my life, new avenues and paths will appear? *(I know those of you who already live your life like this will be wondering what the fuss is all about, but this is new thinking for me though!)* I’m truly excited about this. It means that my journey is far more important than reaching my destination. Or as Arthur Ashe succinctly puts it: *Success is a journey, not a destination. The doing is often more important than the outcome.* Your path may be less certain, but I suspect a hell of a lot more fun and who knows you too may come up with a new destination? ### reinventing the wheel URL: https://www.annemariecharrett.com/reinventing-the-wheel/ Last updated: 2021-06-18T11:32:58.000Z I liken my experience of creating an Exploratory Testing workshop as similar to recreating the wheel. It would be easy to copy someone else’s version of a wheel, after all there are a lot of great wheels out there. Alternatively, I could create my own wheel. But how do I do that? How do you improve on the wheel? My feelings about holding such a workshop range from massive excitement to extreme anxiety as I grapple will the question, “What the hell am I going to talk about”? I’m not talking about the content, there as been plenty written on Exploratory Testing and I could spend weeks just reading up on other peoples articles, notes etc. If I wanted to, I could re-regurgitate lots of excellent material on the subject. But I have a problem with that approach. In fact I have two problems (maybe even three if you take into account the massive attack of self doubt I had this morning!) with that approach. The first one is this. How do you teach Exploratory Testing? As James Bach writes in his article [Exploratory Testing Explained](http://www.satisfice.com/articles/et-article.pdf?ref=annemariecharrett.com) and something I WHOLEHEARTEDLY concur with (through bitter experience!) is that: > Among the hardest things to explain is something that everyone already knows. We all know how to listen, how to read, how to think, and how to tell anecdotes about the events in our lives. As adults, we do these things everyday. Yet the level of any of these skills, possessed by the average person, may not be adequate for certain special situations. Psychotherapists must be expert listeners and lawyers expert readers; research scientists must scour their thinking for errors and journalists report stories that transcend parlor anecdote. > So it is with exploratory testing (ET) The second problem I have is that *If the workshop is going to be any good, I know it has to come from the heart, my heart.* So even if I was tempted to say take James Bach’s course and deliver it (anyone who takes his course has this permission, as long as credit is given) it would be pointless. Because I know it has to be my story, what my understanding of ET is, not anyone else’s. Its one of the reasons why James’s course is so damn good. His conviction comes through because its HIS story. As an exercise, creating an ET workshop is a great challenge. It demands the ultimate in story telling. There is nothing better to confirm/challenge your beliefs and/or understanding than to articulate it in front of a class. There is also nothing more humbling. It makes you realise how much I have still to learn. As part of my effort in creating this course I’m reviewing familiar documentation again. In particular James’s RST slides.Looking at these slides in a critical way has been very beneficial. Its made me question my depth of understanding of some of its content. Its been a good morning though. I’ve made some baby steps and have got some ideas that I feel I can call my own. I know that the workshop is to be practical, and I have a few ideas in mind on that. The challenge is to use the exercises to teach an ET point. What the workshop(or the wheel) will end up looking like, I’m not yet too sure. One thing I do know is that as time evolves it will become more and more my own story and yes, my wheel. ### Get out your tin whistles URL: https://www.annemariecharrett.com/get-out-your-tin-whistles/ Last updated: 2021-06-16T23:18:06.000Z At last after a year of wrangling, shuffling and even some pleading Michael Bolton in association with Testing Times is coming Dublin to give his wonderful Rapid Software Testing Course. Not that Michael needed persuading to come. He jumped at the opportunity. Mostly because he loves giving this course and helping testers well, develop sense. But I will let you into a little not so well known fact about Michael. He loves Irish Music and his a keen Mandolin player. So we knew we were onto a winner straight away! For those not familiar with Michael Bolton and his course. Rapid Software Testing is “a course, a mind-set, and a skill set about how to do excellent software testing in a way that is very fast, inexpensive, credible, and accountable.” Its written by James Bach and Michael Bolton This course is excellent, its practical and thought provoking! I can personally say that because I’ve taken it. If you have ever asked yourself the question: **“Is there a better way to test this stuff ?”** Then I suspect this course is for you. Some of the issues it addresses are: - Are you finding it difficult to assess how much time and effort you’re going to need to test effectively? - Are you overwhelmed by or uncertain about approaches to test planning, design and execution? - Are you working in an environment where some people aren’t following “the rules”? - Are you having trouble finding the right balance between planning, documentation, and testing? - Are you interested in learning skills and techniques that will help you to become a better tester? - Are you finding that “industry best practices” are infeasible and a poor fit for your organization? - Do you want to get very good at software testing? Even better Skillnet has agreed to partially fund the course, so you are getting this 3 day course at a knock down price of **770 euros**. If you have **any** money in your training budget, this course is the one to go for! ## **Rapid Software Testing Details** - **Date: Monday 13th to Wednesday 15th September 2010** - **Venue: Xilinx, Citywest Business Park** - **In association with [Testing Times](https://testingtimes.com.au/?ref=annemariecharrett.com) & Xilinx** - **Duration: 3 day course (9.00am to 5.30pm)** - **Cost to non-members: €1,700 per person** - **Cost to Software Skillnet Members\* after Grant aid: €770 per person** ***\*Membership to Skillnet is Free*** For more details and booking go to the skillnet website: [Skillnet Rapid Software Testing](http://www.isa-skillnet.com/?ref=annemariecharrett.com) ### Blasting off to CAST 2010 URL: https://www.annemariecharrett.com/blasting-off-to-cast-2010/ Last updated: 2021-06-20T01:32:16.000Z ![Association for Software Testing](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/AST-Logo-1-01-1.png) It’s my first outing to CAST this year. CAST has been on my wish list for a couple of years now, but with moving countries, raising kids, and earning a living I’ve found it hard to make it. This year I decided no more excuses, it was time to go. As well as wanting to attend the conference and meet some great testers, I wanted the chance to complete the BBST Instructors course which is being held as a post conference session. I’ve been assisting in the Black Box System Testing courses for a while now. I find teaching them very satisfying and to boot, I get taught by some great testers on giving courses. The post CAST session is being run by Becky Fielder a long time trainer and Cem Kaner. So as well as being taught by some of the best, I get to meet them too. There is some information here on the [course](https://staging13.associationforsoftwaretesting.org/conference/cast-2010/?ref=annemariecharrett.com). I was looking for sponsorship for this one though. There was no way I was going to be able to make it on my own. Fortunately the Association For Software Testing stepped in and have sponsored me the conference fees. So a **BIG THANK YOU** to the [AST ](http://www.associationforsoftwaretesting.org/?ref=annemariecharrett.com)for that. The[ Software Testing Club](http://softwaretestingclub.com/?ref=annemariecharrett.com) offered to sponsor my accommodation, so another big **THANK YOU to Rosie Sherry** and the crew at the STC. The STC crew work really hard to make a genuine and real experience for many software testers. I’ve had great support from them in so many areas, from mentoring, recruiting, publishing my articles as well as some great discussions on their testing forum. It’s also nice to see people bringing fun into testing. I think sometimes we take ourselves way too seriously. I’m still on the hunt for more sponsorship, so if you know of a company or association willing to support, get them to contact me. I’m happy to wear a T-Shirt at the conference, blog about how supportive they are etc. Another way to sponsor me is to offer me some work! Below, I’ve included information about this year’s CAST. I hope you can make it! --- **Attend CAST 2010** **The 5th annual Conference of the Association for Software Testing** **August 2-4, 2010, Grand Rapids, Michigan, USA** **“Skills in Testing”** ## About CAST CAST reflects the AST’s core mission: to build community amongst scholars, practitioners, and students for the advancement of the practice of software testing. In 2010, CAST aims to leverage peer collaboration to build an enhanced understanding of how various skills influence tester effectiveness. CAST offers a unique opportunity to learn and confer with others that simply isn’t found at other conferences. Each scheduled session allocates time for facilitated “open season” discussions that encourage participants to question and challenge the presentation. What takes place in the hallways, at receptions, and during meals and lightning talks truly sets CAST apart; for many attendees, the greatest value is derived from the opportunity to discuss and delve into the topics that matter to them. **Space is limited Register Today!** More information and Registration: [www.CAST2010.org](https://staging13.associationforsoftwaretesting.org/conference/cast-2010/?ref=annemariecharrett.com) **We can’t wait to see you in Grand Rapids!** ### Bizcamp Talk URL: https://www.annemariecharrett.com/bizcamp-talk/ Last updated: 2021-06-16T23:21:34.000Z I gave a talk at Bizcamp this year on how to get the most out of your software testing. This was an interesting challenge as the I wasn’t speaking to software testers but developers. How could I help developers and small companies test better? I decided to go down the path of identifying typical traps that testers and developers fall into, e.g testing to little, or testing too much and how to try and get your testing just right. I used the analogy of Goldilocks to get my point across. I got lots of questions which was very gratifying. [Bizcamp](http://prezi.com/pqdyfoduyauw/?ref=annemariecharrett.com) on [Prezi](http://prezi.com/?ref=annemariecharrett.com) Thanks to everyone who attended my talk ! Note: Any ideas not my own were faithfully attributed to their rightful owners: [James Bach:](http://www.satisfice.com/?ref=annemariecharrett.com) CRUSPIC STIMPL, Generic Risk List, Focus Defocus Heuristic, Steeplechase Heuristic [Hans Buwalda,](http://www.happytester.com/?ref=annemariecharrett.com) Soap Opera Testing ### Are you a Buccaneer Parrot? URL: https://www.annemariecharrett.com/are-you-a-buccaneer-parrot/ Last updated: 2021-06-20T04:48:44.000Z I’ve had a couple of ‘epiphanies’ this morning and consequently have that weird floaty, happy/anxious feeling that I get at moments like this. I didn’t go to StarEast but I, along with countless other software testers have been watching the virtual show through twitter. Some of it I let go, but a couple of links I’ve clicked on to see what all the fuss is about. Boy, if the two links I clicked on are anything to go by, it would have been a great event to be at. The first seismic changing event for me was listening to James Bach’s clip on what it means to be a buccaneer tester. Now James is a tester that I have mixed feelings about. I went on his RST course a few years ago and really enjoyed it. I loved his FOCUS/DEFOCUS heuristic and its one of my key techniques that I apply when I test. BUT, sometimes I find his style can be overly aggressive, especially when it comes to: oh crap, here I go, CERTIFICATION. But not today. Today he was sublime and this key point hit me: **“We have got to be testing from our own place, not copying like parrots”** This resonated heaps with me as its a trap that I constantly fall into. Now, I pride myself on my software testing skills. I do have a fondness for exploratory testing and have a knack in asking the ‘right’ question when determining context. Here’s the crunch though. I call my approach pragmatic. In other words, I DONT ROCK THE BOAT. So when asked, I will happily manage a team of scripted testers. Why? Because that is the process. That is how things are ‘done’ in that company. This creates a dilemma for me, because it leads me to ask what in software testing do I really believe in? Where is my “own place”? To what lengths would I go to ensure Exploratory Testing was used in a team I led? (I know I would never personally create a test script, or follow one for that matter). This is pertinent to me because I’ve just gone for a test lead role that requires ‘strict adherence to a process’. In order to be able to answer these questions, (and writing this post is helping me decide mine) and as James puts it ‘test from your own place’, you have to know where and what “that place” is. The only way you're going to find it, is by taking a stand, having an opinion, suggesting a new approach and being prepared for people to disagree with you. To quietly agree(or disagree) is not going to help you know what you believe in. It’s funny you know, I’ve always thought that being outspoken is such an ‘American’ thing. We ‘Europeans’ are way too polite to express our views so, well, blunt. Perhaps there is an element of difference in culture, but I don’t think I can hide behind that excuse any more. Here’s the great thing though, when you find ‘your place’ you will be a lot more secure and that is going to help you become a better tester. Why? Because being secure about your place means you don’t have to worry about what other people think. You are less fearful one thing I know for sure: IF YOU FEAR WHAT OTHERS THINK OF YOU, YOU WILL NEVER BE FREE TO LEARN NEW STUFF It kind of goes with Elisabeth Hendrikson’s article that says [“Not knowing answers isn’t sign of weakness; not asking question is](https://1iv3y5147rw9384bl74cgkcm-wpengine.netdna-ssl.com/wp-content/uploads/2011/04/mtpwynt.pdf?ref=annemariecharrett.com)” Being fearful of looking stupid, prevents you from asking the dumb question. By the way, before you pat yourself on the back about being able to ask ‘dumb questions” I believe its easy to ask the dumb question when your experienced in an area, but try doing it in a field where your not so experienced. It can be a real challenge. And it can be a real challenge for experienced testers to ask ‘dumb questions’ when they want to appear knowledgeable. I think for wannabee experts this is a real trap. If you try and spend all your time looking like you have the answers, you put yourself in a situation where you stop asking ‘dumb questions’ Why do I believe all these things, because its what I feel and do sometimes. No often. And its something that it going to change. Now. So thats why James Bach’s Video resonates so strongly with me. Thank you James, you have once again been instrumental in my growth as a software tester. Arghh, what’s that pieces of eight, pieces of eight? ### When the dog bites, when the bee stings.... URL: https://www.annemariecharrett.com/when-the-dog-bites-when-the-bee-stings/ Last updated: 2021-06-15T10:14:24.000Z I wonder if the software testing community has a [collective consciousness](http://en.wikipedia.org/wiki/Collective%5Fconsciousness?ref=annemariecharrett.com) ? So often I go to write a post on something that I’ve been thinking about and wham, some great blogger has posted it before me, expressing in far more succinctly than I ever could. So, really it came to no surprise that the wonderful Matt Heusser wrote a superb piece called Chocolate Rain, Carpe Dieum stuff. I really liked it for two reasons. First he points out that no-one gets where they are because of luck (though some of it helps), its hard work and taking the opportunities that count. Secondly, we are all human. We suffer setbacks, we get insecure about abilities or the future and we want to be respected by our peers and those around us. This resonated deep within me. It’s something I’ve been thinking about for a while. It also got me thinking about what does inspire me? So here is the list of things of some things that inspire me. Some of my favourite things. ## 1) Nelson Mandela. What can I say? The guy is a living legend. Apparently he never actually read out this poem on his inaugural speech in 1994, and only alluded to it in conversation. Regardless, it was through reading about him that I discovered the poem which inspires me to look beyond myself and demand more out of who I am and what I can achieve. “Our deepest fear is not that we are inadequate. Our deepest fear is that we are powerful beyond measure. It is our light, not our darkness, that most frightens us. We ask ourselves, who am I to be brilliant, gorgeous, talented, fabulous? Actually, who are you not to be? You are a child of God; your playing small doesn”t serve the world. There is nothing enlightened about shrinking so that other people won’t feel insecure around you. We were born to make manifest the glory of God that is within us. It’s not just in some of us; it’s in everyone. And as we let our light shine, we unconsciously give other people permission to do the same. As we are liberated from our own fear, our presence automatically liberates others.” Marianne Williamson ## 2) Nature There is nothing like going out for a walk on a beautiful spring morning. Nature inspires me to not give up, to persist even when its tough. Nature reminds me of other important things around me and encourages me to put perspective on whats happening and to appreciate my family more. Interesting back to the topic of collective conscience, Jonathan Bach quoted Bob Dylan [(Last thoughts on Woody Guthrie)](http://www.bobdylan.com/?ref=annemariecharrett.com#/songs/last-thoughts-woody-guthrie) in a recent twitter to Lanette Cream as something to read when feeling ‘tested’. ## 3) Software Testers Well, I call them the social workers of the software testing world, but really they are much more than that. They are people who have given their precious time and themselves to help build our great software testing community. These guys inspire me on a daily basis with their encouragement and the way the share themselves and their time. They are: **Rosie Sherry** : Her tireless work supporting the software testing community, and goes out of her way to help people. **Rob Lambert** : His efforts to make our social community fun and ‘real’. **Scott Barber**: His work with the AST – does the guy ever sleep? **Matt Heusser**: For his work ethic, his ideas, his openness to learning new stuff. **Ajay Balamurugadas**: His work with the weekend testers. I know how hard it is to get these things off the ground. **Jared Quinert**: An Australian tester who organises monthly software testing meetings in Melbourne, Australia. To name only a few. I’m sure there are loads more people around the globe who I’ve left out in this hurried post. Feel free to suggest them. Lots of other things inspire me, but those are the top three. ### Testing a SaaS Platform URL: https://www.annemariecharrett.com/testing-a-saas-platform/ Last updated: 2021-06-16T09:18:25.000Z I thoroughly enjoyed the webinar yesterday by [Joel Montvelisky](http://qablog.practitest.com/?ref=annemariecharrett.com) on Testing on the Cloud. Its of keen interest to many Irish Tech companies, so I was happy to organise on the behalf of SoftTest a webinar for its members. [Softtest ](http://softtest.ie/?ref=annemariecharrett.com)is the Irish Software Tester’s Special Interest Group. I learned quite a bit from this webinar. In particular that the amount of testing is actually reduced by hosting your application in the cloud. Things such as installing on different machines, upgrades and patches to multiple versions etc are not required as really there is only one release that everyone accesses. Obvious when you think about it. He also noted that one of the side benefits of hosting your application on the cloud is that you are able to monitor how your clients are using the application. This becomes an excellent source of data that testers should make benefit of. It can help testers focus their testing on areas that customers really use, instead of relying on second guesses or vague feedback from customer support and sales staff. I’d encourage anyone looking into this area, to take a look at his webinar and slides below. **[Testing a SaaS Platform](http://www.slideshare.net/amcharrett/soft-test-joelmsaastestingonan-agile210410?ref=annemariecharrett.com)** Thanks once again to Joel for speaking, Sogeti for their technology and their excellent marketing guru Michael O’ Connor for assisting and facilitating the webinar. ### Mind mapping your testing strategy URL: https://www.annemariecharrett.com/mind-mapping-your-testing-strategy/ Last updated: 2021-06-16T23:57:57.000Z I recently was asked to do a talk on software testing for a group of iPhone developers. I decided to speak to them at a practical level and talk about how I approach software testing, as I wanted them to understand that there are different ways you can perform software testing other than resorting to heavily documented process and formal test scripts. As part of my preparation I decided to use FreeMind to create a mind map of some of my testing strategies. Like many in the testing community I find I rely heavily on mnemonics to remember heuristics and oracles. I like Parimala Shankaraiah’s post on the [Power of Mnemonics](http://curioustester.blogspot.com/2009/10/power-of-heuristics-and-mneumonics.html?ref=annemariecharrett.com) and decided to create something similar but in a mind map form. Most of the information is not new and has been around the testing community for a while. As I started brain dumping the information, I got really excited about the map. I knew that not only was it helpful for the talk, but for me personally, it provided a great tool to remind me of different approaches I can take to testing. I’ve inserted due credit, but if I’ve left anyone out or got it wrong, please let me know and I can update it. In fact I’m so thrilled with the results, I’m going to share it. So here it is. [https://www.xmind.net/m/YvxE/#](https://www.xmind.net/m/YvxE/?ref=annemariecharrett.com) ### Irish hosted webinar: Testing for the cloud URL: https://www.annemariecharrett.com/irish-hosted-webinar-testing-for-the-cloud/ Last updated: 2021-06-16T21:05:37.000Z As a member of the working committee for Softtest.ie, we have been investigating different ways to communicate with our software testing community. One suggestion was to hold some webinars.I’ve been availing of my contacts in the online networking community to source some testers willing to discuss their experiences in this format. I’m delighted to let you know that [Joel Montvelisky](http://qablog.practitest.com/?ref=annemariecharrett.com) has agreed to talk about his experiences of testing on the cloud. The talk will be held on Wednesday, April 21, 2010 11:00 AM – 12:00 PM BST Testing a SaaS (Software as a Service) Platform on an Agile World SaaS (Software as a Service) products and applications are becoming more common in today’s development Industry, especially as Cloud Computing becomes a household name pushed forward by software players such as Google, Microsoft, Apple, etc. In contrast to regular Web-Based systems, SaaS applications require a different approach to testing than what we are used to from other more traditional projects. In some cases testing a SaaS system is simpler than testing a regular Web-based platforms, but in many others it is a lot more challenging and demanding. It’s made even more interesting by the fact that many of the teams developing SaaS Applications are based Agile Development Methodologies. In this webinar, Joel Montvelisky will provide an overview of the main areas to cover when testing a SaaS Application or Platform based on his own experience at PractiTest (a SaaS QA Management Platform developed by his company). He will give some insights into the type of approaches and ideas that work best, and will also talk about some of the tools and methodologies his team currently uses while testing PractiTest. The seminar is aimed at Test Engineers, Test Leaders, QA Managers, Project Managers, Developers and Development Managers. Please see below a link to the registration page. https://www2.gotomeeting.com/register/506544250 ### Kids, Kittens and Karma URL: https://www.annemariecharrett.com/kids-kittens-and-karma/ Last updated: 2021-06-10T18:11:35.000Z Have I ever written about how competitive I am? Lets just say I like to win. A lot. Best explained by an example I think. In my heyday I was a bit of a runner. Not a bad one, but not the best and I knew it. My favourite race was the 800 meters, a bit shorter than the 1Km, more like a fast sprint. Each year at school we had a sports day where we all got to compete in races against each other. The way it worked at our school, was that you got to choose which race you wanted to run in. So, naturally I chose the 800 meters, but was dismayed to find out a week before that the best runner in my class was running that race too! I mean she could have picked the 1K, 400m or even the 100m. Why the 800 meters? Well, I decided I wanted to win that race, so I convinced my main competitor that for the better good (there were class points system too), she was far better off running the 1K. I remember the look of reluctance on her face as she agreed that it was best that our class win two races instead of having 1st & 2nd in one race. Well I sailed to victory in the 800 meters. I still remember that day, traced with a mixture of guilt and pride (well, it was a neat bit of negotiation). I’m still competitive, but I guess I prefer these days to win on my own merit instead of resorting to nobbling the competition. So where is this all going? Well, I submitted a video to the Eurostar 2010 VideoStar competition. The prize is a speaker spot at Eurostar 2010. (Its got cute kid , but not kittens I promise, I’m saving it for the sequel) Anyhow, now you all know how competitive I am, I wish all my Videostar competitors the very best. I know its hard work to create a video (some of them are great) I look forward to hearing some great talks in EuroStar. Oh, and in my enthusiasm for creating the video, I failed to mention what I was going to talk about, which is software testing and startups, working on the bleeding edge. Of course, if you want to vote for me…… [http://www.eurostarconferences.com/content/videostar-competition.aspx](http://www.youtube.com/watch?v=7mGuF%5F83c-k&ref=annemariecharrett.com) ### Walking the walk, but can you talk the talk? URL: https://www.annemariecharrett.com/walking-the-walk-but-can-you-talk-the-talk/ Last updated: 2021-06-16T09:20:55.000Z In my experience, selling testing is a lot harder than testing. Despite being Irish, “the gift of the gab” eludes me, often leaving me tongue tied and twisted when selling my wares. Its one of the reasons I have got myself a business mentor. His main focus has been for me to understand my ‘product’ and my customers. He’s arguing at the moment, that the word ‘testing’ is not sufficient to draw in my customer base. The reason being, is my customers work in a different paradigm and use different language and so fully fail to comprehend the benefits that testing can provide. We know as testers that testing can have massive benefits right across the company, and that the information and insight (thanks Joe) we provide is useful beyond the IT development lifecycle. For example, we know that marketing can benefit from data resulting from performance testing, that legal teams can benefit from any compliance testing we perform. There is a bit of a trend recently to describe our work in clear terms such as testing and bugs. Where before we perhaps worked in QA, we our now testers. We have ceased to use language such as gatekeepers and milestones. But I wonder in using such limiting language such as testing and bugs does it make it harder to sell testing to these stakeholders? I certainly struggle in finding ways to bridge the language gap between testing and my customers. Words such as Quality and Assurance have in a way become tainted and I try to avoid such terminology, but really where does this leave me? I know for effective communication with my customers (who exist outside the IT world), I need to use their language and describe testing in their terms. I will give you an example. I attended a BizSpark networking event recently where a number of Venture Capitalists were present. One concept I’ve been toying with is to provide independent technical reviews on software products for investors and the like. I know, it sounds a lot like testing, but if I used the word test and bugs, VC’s eyes glaze over. So I speak to them using words such as due diligence, audits and risk management. Does this mean I’m not testing anymore? Am I now selling insurance as opposed to testing? Personally, I don’t see it that way, to me the core is all about testing. It’s just that the context has changed, and so the language has. Perhaps I’m over complicating things here. I’m unsure. I know that placing testing in their context it makes it easier for them to buy into. Is that so wrong? I’d really like to hear people’s thoughts on this, it’s a topic that fascinates. ### Waxing and Waning during Exploratory Testing URL: https://www.annemariecharrett.com/waxing-and-waning-during-exploratory-testing/ Last updated: 2021-07-23T22:57:27.000Z I had this great plan for today where I would observe how I work throughout a day of exploratory testing. Unfortunately, the software is not quite ready for testing, so my plan has been slightly scuppered. Still I suppose this situation is often typical of any testing scenario, so I will still include it into my final analysis. The idea behind this ‘observation’ is I want to have an understanding of how my enthusiasm, concentration change throughout a day of testing. The reason I want to do this is because I’ve notice that often at the end of testing I tend to be less enthusiastic than say at the start. That’s understandable and probably most testers have noticed this wane themselves, especially if the testing goes on for a long time. I attribute many reasons to this, for example, sometimes I leave the boring and tedious tests to the end, or perhaps I feel the majority of ‘interesting’ bugs appear to have been found. It might even be that once the excitement of testing something new has left, I’m left with my own discipline and sheer determination to get through the rest of testing. So, I thought it might be interesting to track my enthusiasm and concentration in exploratory testing. I get to chose what I test and when, so perhaps with me in control of my testing destiny it would be interesting to see how my enthusiasm wanes and waxes. By observing how it changes, I might be able to put into affect some different techniques to use the peak points of enthusiasm and concentration for testing the software and perhaps the times when I’m er a bit less enthusiastic to do documentation etc. The idea is that by observing my testing flow I can plan better how to use my day. I wonder if this is something that all testers would find helpful? I imagine that most testers would differ in their daily ebb and flow. If you observed your concentration levels what would you see? ### Testing my backbone URL: https://www.annemariecharrett.com/testing-my-backbone/ Last updated: 2021-06-16T09:16:35.000Z I’m a nice person. Well, I like to think I’m a nice person anyhow, and some people tell me that’s true too. Especially my kids, they tell me I’m the best Mum in the world. Aw shucks! But sometimes, being nice creates problems because I want people to be nice back to me too. This can be a real problem in software testing when faced with an aggressive and rude developer with little respect for your work. The consequence of being ‘nice’ is that I’m as helpful and co-operative as possible with developers. Generally testers like me raise great bug reports and are very attentive if the developer requires further information. On the down side, at some point in your working life, you are going to face an aggressive and unpleasant developer and to do your job, you are going to have to stand your ground. And then its time for wimpy tester to find her voice and become assertive tester. So I’ve had to come up with some techniques to turn my wimpy ‘nice’ persona into an assertive positive voice. For all you wimpy and not so wimpy testers out there, here they are: 1) Rule Number 1\. It’s all about the software, it's not about you. Focus on your goal and don’t be distracted by outrageous and manipulative statements. Sometimes I imagine the developer yelling and screaming at the software not me. 2) Rule Number 2: Stick to the facts, and backup statements with evidence or in Cem Kaner’s language, find a credible source. 3) Rule Number 3: Don’t be bullied by an aggressive developer, raise your risks and speak your mind. 4) Rule Number 4: Keep a pleasant an even tone in all your discussions. Emotion is not required here. 5)Rule Number 5: Focus on the commonalities. You both want the software to be delivered successfully. Work as a team even if it doesn’t feel like a team. Remember the goal is not to get the developer to like you, its to get good software delivered. At the end of the day, you are responsible for raising bug reports and identifying risks. If some developer is determined to be aggressive, that’s their call, but if you stand your ground at least then you can complete your work with a clear conscience. ### So you want to be a software test consultant? URL: https://www.annemariecharrett.com/so-you-want-to-be-a-software-test-consultant/ Last updated: 2021-06-16T08:15:28.000Z Today, I’ m handing out some pointers that may or may not help you on your path to becoming a software test consultant. Some of these I’ve gained through bitter experience, others are more hindsight on things I ought to have done. So, without further ado, here are my tips. ## 1) Dreams are not goals Its easy to have a dream about setting up a test consultancy, and actually, it’s really easy to setup a company, print some business cards and your dream is realised! But unless you have short and long term goals, your business won’t go far. I set quarterly and yearly goals for myself and my business. ## 2) What does success mean to you? I think this is essential to understand. What is driving you to run your own business? Money, freedom of choice in your work, flexibility? Knowing what will make you happy when you achieve your goals and dreams is essential to having a successful business. For me, my initial goal was to work for myself and not have to answer to anyone! It has changed over the years to include flexibility to spend time with my younger children. At times, this has meant my business has not been highly profitable, but it has always been successful. ## 3) Know your market and your products. Who are you targeting your testing at? Any particular sector? Any particular size of company? Ask yourself what products/packages would they be interested in? Ask your market what products/services they would be interested in? All this ought to be in your business plan. In my view a business plan is the equivalent of your testing strategy and approach, and its a very personal document. It helps you through knowing your market and your products, your rates etc. ## 4) How much should I charge? There is no easy answer to this, which is why spending hours googling websites like mine is not going to help you. The general advise is that you should charge enough to cover your expenses and how much you need to live on. So, if you estimate on working 40 weeks of the year, and you need a salary of $100,000 yr to live on, you have company expenses of $20,000 /yr then you will need an hourly rate of $75\. This may not be the final rate you charge, but you know its your minimum rate. That’s helpful to know if a client is trying to offer a lower rate. I went for a tender recently and lost out. I asked why and they mentioned that my rate was too high. I was disappointed naturally, but I knew that I had offered the right rate for me and I would not have lowered my rate just to get this piece of work, the risks were too high. There’s a whole other heap of things that contribute to your daily rate, such as knowing who your market is, and what they will take. Bear in mind rates are very fluid, and in times like recessions they often move down very quickly. Personally, I think you just have to go out there and try out a few numbers with potential clients. You will soon learn what’s acceptable and what’s not. So, get off your butt, find a customer and charge a rate. If you don’t get the work, ask them why? Was the rate too high? No-one said this was going to be easy! ## 5) Marketing Yourself I have to mention something about marketing etc, because a) its so important, and b) it can be very time consuming. What are the best methods to promote yourself? Like any good tester, I’m going to say it depends! There many ways to promote yourself on-line and off-line. I have gotten work from both online and through knowing people. Each country differs in what works best. For example, in Australia, a lot of my work came through the internet, so having a good online presence was essential. In Ireland though, it’s more who you know and going out and meeting people is more important. Be very careful how much time you're spending on the internet twittering, blogging etc, your time may be better spent meeting people or speaking to people on the phone. This is a big trap and one I constantly fall into! Writing articles and speaking at presentations are other ways of promoting yourself and its a good way to start seeing yourself as a provider and not a consumer. ## 6) The baby years. Realise that though you may plan to work 40 hours a week, you may end up working less than that, especially in the first couple of years. So what do you do? Either you need a little nest egg which you can rely on for two years, or else you are going to have to supplement your business through short term contract work. In fact, I think its a good way to transition from permanent to running your own business as it helps you learn about other consultancy type skills such as understanding the tax system, raising invoices, working by the hour, dealing with clients and learning market rates. These are all skills which you may not have come across in your permanent role and will be helpful in running your own business. At the same time, you are still assured of an income. ## 7) Always be on the look out for new clients. This is a real challenge when it comes to working for yourself and I think is one of the biggest challenges to running your own business. Marketing and selling your work to new clients is essential if you want to keep the work coming in and takes an enormous amount of effort. But how do you fit this in when working for a client five days a week? I don’t have any easy answers to this and I still struggle with balancing my sales activities with my paid work. Paid work has to come first, potentially leaving only evenings and weekends for marketing and sales type activities. If you value you family life, you can try working 4 day weeks and leaving one day (or 1/2 day) for admin activities. Another idea I had, but I haven’t tried is to outsource your marketing and sales to another freelancer. I don’t know if this approach works, but sometimes I’ve been sorely tempted to try something like this out! ## 8 Use your network. Everyone knows that in order to find clients you have to network. I remember being a bit overwhelmed at the thought of having to find this ‘network’ of people to source work from. How in the hell to I meet these ‘people’ who had work? I realised after a while, that I didn’t have to look anywhere as I already had a network! My network was my family, friends and people I had worked previously for. So, when I started looking for work, I turned to these people first. Let them know you have started working for yourself and could they pass the word that you are available? It doesn’t matter if they are non IT people, you just never know where your next piece of work is going to come from. Also, ask them if they know of someone who may be able to help or give advice? (People love giving advice!). The key is to start talking to people you know, and people who your network knows. A great place to start is with companies you’ve worked with. These people know you, and what you can do. You also have the advantage of knowing their systems etc. Don’t be afraid to go back and ask for any work they may have. If you can make it part time even better as that way you can focus on building your business. One of my first jobs came this way. ## 9) Work smart I will let you in on a little secret. I have a business mentor. I suggest you go out and find one yourself. A mentor is an excellent way of guiding you through some of the pitfalls in starting up your own business and can help you with the all important and essential business plan. I got my business mentor through an enterprise network, look around your local area and see if there is something equivalent. *Footnote. I am not offering any business mentoring, so please don’t ask.* and finally ## 10) It's your path. It’s good to get advice and ask for help. However, no-one is going to give you a template or process for success. You are going to have to make it up as it goes along. That’s half the fun of running a business. I liken it to raising kids. It doesn’t matter how many self help books you read on how to raise your children, in the end, they are only guidelines. You are the one who is going to make to decision on what to do. Are you prepared for that? If you want it all mapped out for you, stick to your permanent job. That’s about it! I’ve listed some related articles I’ve written on the topic below: [Presentation: It includes some stats on where I get work etc](http://www.slideshare.net/amcharrett/startups-and-software-testing?ref=annemariecharrett.com) [Article I wrote for the STC On being a successful consultant](http://www.slideshare.net/amcharrett/twelve-traits-of-a-tip-top-test-consultant?ref=annemariecharrett.com) I could go on, but I think I’ve addressed the main points. If you have any more questions on this topic, feel free to ask in the comments below. If you think you’d be interested in this topic at a conference let me know that too! Please don’t post asking for work, that you will have to find on your own! Good luck on your venture. ### It's time to grow up and ditch the security blanket URL: https://www.annemariecharrett.com/newsletter/its-time-to-grow-up-and-ditch-the-security-blanket/ Last updated: 2021-06-20T01:05:15.000Z One of the hardest parts of working as a software tester is keeping on top of new technologies, techniques in testing and development and software testing tools. I can sometimes feel quite intimidated at the amount of information that I need to absorb in order to keep on top of the game. ![Linus Security Blanket](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/linus.gif) Gavin Davies writes about this feeling of intimidation in his post [Software Development: Doing It Scared](http://www.boxuk.com/blog/software-development-doing-it-scared?ref=annemariecharrett.com) and how we naturally are tempted to retreat to a place of safety. As he points out though, it doesn’t get the job done. He gives some tips on overcoming these feelings, I pass them on to you here: ## 1) Cut it down to size. If you have a task that’s overwhelming, cut it down to smaller manageable tasks. I like to set these tasks to dates as it helps keep me focused. ## 2) Get Help. There are lots of places where you can go and ask for help online (my personal favourite is the [Ministry of Testing](https://ministryoftesting.com/?ref=annemariecharrett.com)). Try and keep your questions specific and put some context in the question to help those answering it. One word of caution though, whilst there is no such thing as a dumb question, your question may have been already asked. Do everyone a favour and search first to see if your question has already been adequately answered. Also, ask your colleagues and team members for help. ## 3) Remember your existing skills. Remind yourself that you are already skilled in some aspects of testing. Once you have learned your new technology/skill, you will be able to quickly ramp up and apply the new skill to what you already know. It will get easier! There’s a bit more on what not to do in the post, which is good reading. Gavin ends with this worthwhile point: “Software can seem overwhelming. The more we learn, the more we realise how much there is to learn – more than one person can possibly know. As software developers, we will always face fresh challenges. Nevertheless, a life worth living will take you out of your comfort zone time and time again and positive thinking, teamwork, good practise and organisation can help tackle daunting tasks.” Happy learning! ### Is it Nerdy to Test on the weekend? URL: https://www.annemariecharrett.com/is-it-nerdy-to-test-on-the-weekend/ Last updated: 2021-06-10T18:12:07.000Z I’m talking about the European [Weekend Tester Sessions](http://weekendtesting.com/?ref=annemariecharrett.com) that have just started up. This was an entirely different kind of testing. The kids were screaming and running in and out of the house as I sat down on my computer on a beautiful and warm Saturday afternoon to join in with a group of people loosely called the european weekend testers. I shrugged off that feeling that perhaps testing on the weekend was a slightly nerdy concept and opened up Skype in preparation for a couple of hours testing. Of course, there was completely nothing nerdy about the whole thing. Only a great bunch of people wanting to share and explore. Some testers such as Phil Kirkham, Anna Baik and Thomas Ponnet I already knew from the softwaretestingclub, but I didn’t know everyone. Ajay Balamurugadas our facilitator, was one of the original organisers of the Bangalore Weekend Testers. We were set a mission, warned about some ‘traps’ and then basically were left to work our way through a problem. After the testing, there was time for discussion on how the testing went and what each tester learned from the experience. Some great insights in particular on test management and how testing could have been planned more appropriately. I liked getting to know everyone better. Perhaps it was the fact it was a weekend, but it seemed that everyone was very relaxed and easy going. Plenty of jokes were cracked and the whole experience was fun. I felt I got to know other testers a bit more. I liked this a lot, as normally I work alone, so I guess this is the closest I get to working in a team environment. Anna describes the event perfectly in her quote “But I will say it’s the perfect antidote to 6+ months of project deathmarch. Testing is fun again!” Many thanks to Anna Baik and Markus Gartner for starting up this chapter. ### Back To Basics: Automated Testing URL: https://www.annemariecharrett.com/back-to-basics-automated-testing/ Last updated: 2021-06-15T11:19:36.000Z Automating parts of testing has always existed since people have tested software. In my early days of testing the concept of separating testing into manual and automated testing never really existed. Well not where I worked anyhow. We tested, and sometimes we used tools to help us test. In conformance testing we used protocol analysers and executable test scripts to verify conformance to ETSI protocols. When testing Intelligent networks we used call generators and created SQL scripts to load data into databases. There was never a big divide between automated and manual testers. I think this chasm only started happening with the introduction of capture and replay tools that offered the potential of allowing not so technical users the opportunity to reduce the amount of time required for regression testing. When I talk about automated testing, I’m referring to the use of any tool that will help me test better. If in the process, I end up testing more efficiently then that’s a bonus. Lots of tester’s think this way too. Most of the time though, when the term ‘automated testing ‘ is used, it refers to coded scripts that help speed up regression testing and is seen as a superior substitute to manual testing offering added benefits of faster testing and consequently greater coverage. There is no doubt that automating your testing can deliver great benefits in improved testing, greater efficiencies (have you ever tried to manually perform load testing?) and in some cases cost and time savings. But automated testing isn’t always the elixir or panacea that we think and if anyone approaches automated testing with a cost cutting goal in mind, I’d encourage them to perform a cost-benefit analysis before engaging down this path. I’ve discussed the benefits already, here are some typical costs that you might face: 1) The development time for automating the tests. The time involved for automating tests can be quite extensive, especially if you’ve never automated tests before. If your automating tests inside a project, can the project afford the trade-off between delayed results (initially) and the longer term gains of repeatable and maintainable tests? 2) Maintaining Test Scripts Factor the cost of keeping automated test scripts up to date and relevant. If the software you’re testing has plenty of code changes, it can be safe to expect similar effort in keeping the test scripts up to date. 3) Do you have the necessary skillset? Do the testers have the skills to build an automated test framework? Do they know what tools to use and how much these tools will cost? If programming will be used (as opposed to capture replay tools) do the testers have the competence in the languages needed? If the testers need to learn new languages, are projects aware that a ramp up time will be required and that this may affect timelines? 4) How do you decide what to automate? Knowing the best area ‘s to automate is an art in itself. What is the best strategy for test automation? Which areas are best left to manual testing? The cost of getting this wrong involves starting from scratch again. Automation can provide real savings and leave testers to go off and do more interesting stuff (while their tests are running), but needs to be implemented with intelligence and keeping the above factors in mind. Many thanks to Evan Phelan for his input into this post. ### Always look on the bright side of life.. URL: https://www.annemariecharrett.com/always-look-on-the-bright-side-of-life/ Last updated: 2021-06-26T01:52:19.000Z And what better way, than to download the [new Tester Types E-Book.](http://thesocialtester.co.uk/wp-content/uploads/2013/08/testertypes.pdf?ref=annemariecharrett.com) Its a light hearted look at some of the types of testers out there and I guess we could all do with a bit of a laugh now and then. I big hearty thanks to Rob Lambert and Rosie Sherry for writing and putting this together. So, why not download it, grab yourself a cuppa and enjoy a read. Oh and Happy New Year to you all. ### Four Stages of Testing Competence URL: https://www.annemariecharrett.com/four-stages-of-testing-competence/ Last updated: 2021-06-18T02:36:37.000Z I have [Chris Ashton](https://en.wikipedia.org/wiki/Four%5Fstages%5Fof%5Fcompetence?ref=annemariecharrett.com) to thank for this little piece of inspiration. He refers to levels of competence in a recent post of his. I was intrigued by the reference and went off to check out what the levels of competence are all about. The[ “conscious competence”](http://en.wikipedia.org/wiki/Four%5Fstages%5Fof%5Fcompetence?ref=annemariecharrett.com) is a model that describes how we progress through four psychological states in learning. They are: - Unconscious Incompetence - Conscious Incompetence - Conscious Competence - Unconscious Competence I adore these terms and I can easily relate all but the last state to moments in my testing career. In particular the first one! ## **Unconscious Testing Incompetence** My keenest recollection of unconscious incompetence was at my first job, compliance testing ETSI standards. I wrote an official report for the standards body, bound it and was ready to send it off. It didn’t occur to me to read through the document to check it was in order. Fortunately, someone else did and found sections of the document were completely illegible. ## **Conscious Testing Incompetence** Things progressed, I learned how to critique my own work, and was put in charge of a new test team. I learned abourt IEE829, documented tests scripts, how to write a bug report and ISO9000\. I felt I had arrived. I now had a wealth of information on top of which I could construct my testing. I have order and reproducibility and I got hung up about process. The process became more important than the testing. It didn’t occur to me that most of the bugs I found where when designing my test scripts, and executing them was really just a formality. I started to get bored with testing though, and set my goals on greater and loftier achievements. I wanted to be a test manager! ## **Conscious Testing Competence** Well, I ended ditching my career as test manager to because guess what? Yes, I got bored. So I went back to the drawing board and rethought a) what I wanted out of my career and b) what really where my goals in life? I had always wanted to setup a testing consultancy, so that was what I went about doing. I feel that I’m in a state of conscious testing competence now, not always though. Sometimes I pop back into unconscious incompetence, and on rare occasions I jump into unconscious testing competence. I can say that because I’ve learned a lot about how to test well and I try to implement that. I’ve made a conscious decision to keep my testing skills keen and relevant, and I find the only way for me to do that is to keep testing. I’m putting myself on courses and training myself up where I need to. I’ve learned that I will always have much to learn about testing. There are always new tools and new techniques to try out. ## **Unconscious Testing Competence** Ah, the holy grail!I see glimpses of this sometimes, but there is so much more to learn about testing and its such a broad field, that I doubt I will ever achieve this for all areas of testing. Sometimes I do feel that exploratory testing is “second nature” to me but to be able to teach it to others? Maybe not so well. I find it hard to believe that I ever felt that I knew everything there was to testing. What arrogance! So, what testing competence are you? ### Software Testing Training of a different kind URL: https://www.annemariecharrett.com/software-testing-training-of-a-different-kind/ Last updated: 2021-06-17T04:58:27.000Z Ever dreamed of being personally trained by Cem Kaner? How about Doug Hoffman? No? Ok, maybe Scott Barber is more your style? Any tester would, but it would be expensive? I mean these guys would typically charge thousands for this kind of training. Besides, they’re all in the states, so airfare, accommodation. Your company would never pay for it, right? Especially not now the training budget is cut. Well, I’m being personally trained by these great testers, right now and even better, I’m doing it for FREE. No that’s not an acronym for Footnote Really Exorbitantly Expensive,(I know its not very good, come up with a better one and let me know !) it really is FREE. I’m on the bug advocacy course run by the [association of software testing. ](http://www.associationforsoftwaretesting.org/?ref=annemariecharrett.com)(note, the website is currently going an upgrade, but you can still become a member etc). It’s an online course that’s free to all members. Yes you do have to be a member. Yes it does cost money. $85 US dollars for a year. So, if you want to split hairs, you could argue the course costs $85\. So what? Anyhow, I wanted to talk about this course, because its content is really excellent. First of all, lets deal with the title. Why BUG ADVOCACY? Because our focus as tester’s is not about raising bugs, but ensuring they get fixed. Its true! Think about it. That way, not only does the software improve, but we as testers gain credibility too. So, in order for us to get our bugs fixed, we need to make sure we sell them well and we anticipate and preempt any objections people may have about our bug report. Its about communication effectively and communicating to the right person. Its about creating the ultimate bug report. There is a lot more than that in the course. I suggest you take the course and find out for yourself. The recommended hours per week is 6\. I would suggest you allocate more time. The course content is practical and you are given assessments that involve commenting on actual bug reports. Some of the assessments can take longer if you allow them too. You work with testers around the world, some I knew of because of their blogs. Personally, I’ve learned as much from other testers feedback as I have from the trainers. Make no bones about it though, its a demanding and challenging course and if you are just looking for a piece of paper for your resume, this perhaps is not the course for you. On the other hand, if you’re looking to improve your software testing skills and having a highly respected certificate matters to you, then I suggest you join the AST and take some of their courses. It doesn’t matter what environment you work in, agile or waterfall, process or exploratory, the skills you learn on this course are relative to all testers out there. So, if your company doesn’t have a large training budget (or even if it does) this is the perfect solution. Your testers get some really great training, and you get kudos to boot. *Note: This is my own personal opinion, I get nothing out of posting this on my blog.* ### All the leaves are brown, and the sky is grey.. URL: https://www.annemariecharrett.com/all-the-leaves-are-brown-and-the-sky-is-grey/ Last updated: 2021-06-18T00:32:59.000Z It was my birthday recently, and I got a brand new Digital SLR as a present. Now my expertise on photography goes as far as knowing that DSLR stands for Digital SLR. Say no more. Having this camera though, now means I can’t blame bad photos on the equipment. In Ireland at the moment, its the last of the autumn leaves which is my favourite time of the year. All those crispy days and beautiful golden colour. I’ve been in Australia for so long, days like this are a real treat. So inspired by the beauty around me, I set off in true Ansell Adams fashion to photograph the local park. I started down the usual path, and took some average to terrible shots, nothing spectacular. For some reason, I decided to turn around and look behind me. It was then that I noticed some true beauty. I started clicking away. It got me thinking how I tend to always look ahead at things. Often I forget that the best can be simply found by turning around and looking at the same thing with a different perspective. I think this happens in software testing too. In trying to solve a problem, my thinking is often straight ahead, down the traditional path. Perhaps occasionally, if I looked behind me, I would have a different perspective and find a better answer to my problem? Anyway, enjoy Dublin in November! ### Bug Tracking Tools Explained URL: https://www.annemariecharrett.com/bug-tracking-tools-explained/ Last updated: 2021-06-17T00:03:07.000Z Like it or not, all software has bugs.You may not know about them but they are there..lurking in the darkness, ready trip up one of your innocent user who has just gone and purchased your software. That’s why you employ a software tester. A software tester’s job is to find as many of the bugs and report them to you and the rest of the team before they can do untold damage to you and your software’s reputation. You can report bugs in as many ways as there are to communicate. You can write the bugs up in an email, on a piece of paper, in a spreadsheet ([see my previous post on spreadsheets](https://www.annemariecharrett.com/in-defense-of-the-humble-spreadsheet/)). You can even directly speak to the relevant person and directly show them the bug. Or you can use a bug tracking tool. So why do you need to track a software bug and whats so great about a bug tracking tool? ## Software Bug Workflow Well, just as a normal bug goes through several stages in its life such as egg, nymph, larvae and finally adult, so to does a software bug go through its own lifecycle or workflow. Redmine the opensource software I use as my online bug tracking tool, uses the word workflow so I’ll use that term in this post. Typically a simple bug workflow goes **new** is when a tester creates a bug report **open** is when a developer accepts the bug report as valid **fixed** is when a developer indicates that the bug is fixed **tested** is when a tester indicates the bug has been tested **closed** is when a tester accepts the bug has been fixed and the report is now closed This is a very simple workflow. Alternatives to the workflow can happen when for example, bugs are rejected by the developer or a bug fails test and the tester places the bug back to open state. In fact, it can get quite complicated if you let it. Most bug tracking tools will let you modify or create your own stages and workflows, but if you're new to the concept of a bug tracking tool, it's better to select a simple existing workflow and use that for a while to get used to what works for you. Redmine, lets you chose a preexisting work-flow. **A bug tracking tool then allows a tester to create a bug report and monitor its progress as it goes through its workflow** So whats the big fuss? Why not just use a spreadsheet or email? I’ve personally benefited a lot from bug tracking tools. Here are some ways they’ve helped me. ## Benefits of a bug tracking tool 1) Its easy to keep track of one bug, but keeping track of many bugs is hard work. A tool helps you easily find out what bugs are still open, fixed, closed. Bug tracking tools normally allow you to sort and filter your bugs and create reports on the bugs. 2) You can track other stuff about bugs, such as how important they are and who is fixing them. This can help you prioritise which bugs are important and require urgent fixing. 3) You can start seeing clusters of bugs which indicates there may be underlying issues in parts of the code 4) Lots of people can see the status of the bugs, not just the tester and the developer. The overall bug status can be quickly reviewed by many avoiding nasty surprise syndrome (NSS) at the end of development/testing. 5) Sometimes not all bugs are fixed in the current release but will be fixed and tested in a future release. This means long after software release the bugs still need to kept open and tracked. A bug tracking tool ensures that these bugs are not overlooked in the future. 6) A bug tracking tool can centralise information. Often a bug tracking tool can be used to track new features as well as issues and can act as a document repository. Redmine offers many additional features such as document repository and wiki. 7) A bug tracking tool can improve productivity by increasing bug awareness and responsiveness. It is also handy when a project is scattered geographically and works across different time zones. As I’ve mentioned in[ previous posts](https://www.annemariecharrett.com/bug-tracking-tools-explained/), there are many open source options bug tracking tools out there, so if budget is an issue there is no need to spend a lot of money on an top end commercial tool. And of course, a tool is only as good as the developer and tester using it and will fail miserably if no one is willing to use it, so perhaps if your thinking of adding such a tool to your testing toolbox, speak to the rest of your team first to find out what they are looking for in a tool. ### Is automation the new documentation? URL: https://www.annemariecharrett.com/is-automation-the-new-documentation/ Last updated: 2021-06-23T22:45:39.000Z Have automation tools become the new templates in software testing? The cornerstone on which all our testing hangs on? Its starting to look that way. Think about it. The traditional method of testing was to use a software testing process identifiable by test templates. These templates were (and in many cases still are) the focal point of all testing. Then some new thinkers introduced concepts such as Exploratory Testing and Context-Driven Testing, placing the tester central to the testing exercise. It rocked the testing world. Then along came agile with its focus on automation. This has lead to a heavy emphasis on automation instead of the individual behind the tool. Traditionally the majority of time in testing was spent writing heavy onerous documents, instead now, we are writing automated test scripts. What has gone wrong? I was surprised at the emphasis on tools in an agile testing talk I went to, as I am surprised at the interest in automation tools by all testers. My feelings about automation are best described by this post by ~~Kevin Pang where he writes:~~ > **The difference between a good developer and a bad developer isn’t whether they use duct tape, it’s how well they can recognize whether a situation calls for it**. There is a similar problem in automation testing. Automation in itself is not a good or bad thing, its knowing when to use it. That’s whats been overlooked in this whole agile testing excitement. The skills required to be a good tester are being overlooked in favour of good automation skills. Instead of “are you a good tester”, you are being asked “what automation tools you know”. I can understand why, its easier to quantify automation tool experience than quantifying what makes a good tester. We need take more care about what we discuss in Agile testing. The emphasis on what tools is too heavy and a rebalance is overdue. More emphasis needs to be put on how a testers creates a strategy for automation, not just the type of tool they use. It’s time to reset the balance and put the tester centric to the testing effort. ### Some days Scarlett, I just don't give a damn... URL: https://www.annemariecharrett.com/some-days-scarlett-i-just-dont-give-a-damn/ Last updated: 2021-06-18T03:57:14.000Z It doesn’t happen all the time, but some days its just hard to be motivated and inspired. Today is one of those days. Perhaps its because it's a grey day, or that yesterday in Ireland was a public holiday and its hard to get motivated after a break, but today it’s hard to get the creative and testing juices flowing. I sometimes get like this whilst testing too. Catherine Powell wrote a post on [‘just do it’](http://blog.abakas.com/2009/10/just-do-it.html?ref=annemariecharrett.com) that helps me in these situations . Other strategies that I use are: ### 1) Break the work into small chunks Then tick off the work as you go, you will start to feel that you are achieving something. Get up and move around between each piece of work. ### 2) Keep plowing through Yes, you’re uninspired, fed up and have a strong urge to go AWOL. However, this is just a feeling, keep working through, keep testing. It will get better. ### 3) Change environment If you can, try and test somewhere different to where you normally test. Move rooms or use a different PC. It’s surprising what a difference this can make ### 4) Play some music I normally don’t play music while I test as I find it too distracting, but if the going is tough, then on go the earphones. I know, not the most inspiring post in the world, but as as I said, it's one of those days. ### Rediscover your inner tester URL: https://www.annemariecharrett.com/rediscover-your-inner-tester/ Last updated: 2021-06-16T09:25:37.000Z [Linda Wilkinson](http://www.practicalqa.com/2009/09/thats-way-uh-huh-uh-huh-i-like-it.html?ref=annemariecharrett.com) *(Link no longer valid)* in a recent post called on ‘Experts’ to come down off their ivory towers, and get back in touch with the rest of the ‘hoi polloi’. ![](https://charrett.ghost.io/content/images/wordpress/2009/10/ivory-tower.jpg) *A photo by Billie Ward.* It got me thinking about how in one way or another, we all have an Ivory Tower in testing which we can brag about. Your Ivory Tower (if its anything like mine!) is a nice place to be in. We can sit back and feel comfortable there, we know what we are doing and people treat us with certain level of respect. No-one decided in advance to build these towers, but over the years, as we have specialised, it has become an area we have decided to call our own. Some Ivory Towers I’ve come across in software testing are: ### The Methodology Tower Over the years one process or methodology dominates and closes our minds to new approaches such as Agile or Exploratory Testing. Or, we are so won over by Agile, that we fail to explore other avenues that may be of benefit. ### The Trainer’s & Speaker Tower After many years of testing at the trenches, the experience acquired is used to help other testers by training and speaking in conferences. Gradually, the speaker/trainer looses touch with the tester on the front and starts finding it hard to identify with issues testers face on a daily basis. ### The Management Tower Climbing up the corporate ladder, the Test Manager spends most days, managing people and projects. Their goals and challenges differ from the tester on their teams. They too start to loose touch on the real issues that testers face. ### The Manual/Automation Tower As a tester, perhaps whilst performing other tasks, perhaps you have decided to specialise in only certain areas? Manual testers, when did you last try out automation or performance testing? There is nothing wrong in specialising, or having a niche. But in building these towers, how far have you wandered from the path of testing? You know, the actual testing, where you sit down in front of an application and well look for bugs? In narrowing your skillset, I think you narrow your mindset, and consequently lose out on all the benefits that testing have to offer. Puzzles and writing articles are good ways keep up your cognitive skills, but really nothing beats testing a product to remind of the real issues everyday testers face. Try getting your teeth stuck into a good testing problem, and remind yourself of the pleasure and heartache that testing can bring. Puzzles and forum discussions will never replace or use the sheer number of skills you require in testing such as communication, negotiation, cognitive and written skills. So, if you really want to get in touch with your inner tester get out and test. That doesn’t mean you have to give up your training or test management or whatever area you have chosen to specialise in, but there is no reason why you can’t contribute to some open source testing, or volunteer to assist a charity in their software testing. If you can’t see your way to doing that, try keeping the tester in you alive by going for the many testing challenges that seem to be popping up. I really like the Weekend Tester’s created by Ajay Balamurugadas. They set themselves challenges and applications to test as a way of improving their testing skills. Matt Heusser is another person who set a challenge on his blog. Go on, I dare you to step outside and sniff the air outside your Ivory Tower and rediscover your true inner tester. \[updated January 2020 to rectify spelling mistakes and redo the image which had got corrupted\] ### Changing the Goal Posts URL: https://www.annemariecharrett.com/changing-the-goal-posts/ Last updated: 2021-06-17T00:10:25.000Z I got a chance to watch some Gaelic Football recently as my two sons have started playing hurling and gaelic football. Hurling is a fairly ferocious sport where everyone goes for the ball with hands and sticks. Gaelic Football gives the appearance of being a far kinder sport. However, the Australian version (aka Aussie Rules), is a much more physical and aggressive game. One thing that differs between the Irish and the Australian version is the goal posts. In Aussie rules points are scored when you kick through one of four poles, Gaelic, you kick into or over a pole. Little differences but really important to know and get right. [Adam Goucher had a nice post ](http://adam.goucher.ca/?p=1260&ref=annemariecharrett.com)this week on communication and letting your team know where the goalposts are. Well I have had a similar goalpost problem. Except in mine, the goalposts changed. How I scored the goal had changed, and no-one had told me. I have a very nice client (he’s a client, so he has to be nice, well in this case he actually is very nice) but new to the software development, and a grappling with some of the basics do’s and don’t to mostly people in IT take for granted. It’s the basic advice they require most. Like, letting people know when things change, so I can relate to Adams comments. I spent a good amount of time before the project, understanding who the stakeholders were, and the mission of the testing effort. I explained to them the many different types of testing I could perform, such as Usability, Performance, functionality, Installation and Configuration. It was decided to narrow the scope to robustness, it was a prototype after and all and as long as the screens did not crash, that would be satisfactory. The day before delivery to their customer, there was a review. The stakeholders were dismayed at the state of the screens and the way the functionality worked. But I spluttered, “you told me you didn’t want Usability Testing” What a frustrating experience. They had changed the goalposts! The experience left me angry and frustrated. I had approached the whole exercise well. I had involved the stakeholders, I had worked out their mission. Why did the customer have to go and change their minds? I suddenly felt empathy developers whose requirements continuously change. It then struck me that in a way I was the problem. I was being too inflexible and rigid in expecting an inexperienced customer not to change their minds. I’ve resolved to be far more open in my approach to what’s required (for this project). As long as the customer understands the financial implications of such decisions who am I to argue? After all is not the customer always right? ### Damn it all, it's just not cricket..or is it? URL: https://www.annemariecharrett.com/damn-it-all-its-just-not-cricket-or-is-it/ Last updated: 2021-06-20T02:17:47.000Z After fifteen years of living in Australia, some things have rubbed off on me. One of the them is cricket. I have to confess I have spent many a sun drenched day watching the cricket whilst imbibing the odd beverage here and there. One thing that I have noticed in the game, is the impact of the new ‘unknown’ player. It surprises me the impact the unknown can have on the game. Michael Clark (or Clarky to his mates) on his debut in Bangalore went out and scored 151 runs (thats a lot btw). *Here comes the testing bit…* Fergal O’Riordan, pointed out a similar result in his software testing teams. When testing is all but hung up and dry, he enlists a new tester. This tester must be new to the team, and never worked on the application before. He finds that doing this dramatically increases the number of bugs found in that day. He breaks the bugs down as follows: - The majority are known issues, but previously where not considered to be bugs. The new tester didn’t know that and raised them. Changed circumstances and attitudes now regard these bugs as valid. - Most of the other bugs were also known issues, but were either seen as not relevant to the stakeholders or were being dealt with in future releases - a small number were new and relevant bugs that required fixing. So why is it that a new tester is able to have such an impact? He puts it down to the following reasons: 1) These bugs have been seen before but previous experience led testers to believe they were of no relevance to the stakeholders 2) A new set of eyes brings a fresh perspective and outlook to the testing Doing something different, unpredictable can bring benefits to your team, no matter what the ‘sport’ is. So there you go, who would have thought that the world of testing and cricket had something in common? Tea break! ### The Irish post - QTT now published URL: https://www.annemariecharrett.com/qtt-post-is-now-up/ Last updated: 2021-06-15T09:42:42.000Z Some people asked me to let them know when my first post on QTT is up. Well its up now. You can find the post here [Quick Testing Tip By Anne-Marie Charrett](https://dailytestingtip.blogspot.com/?ref=annemariecharrett.com) I hope you enjoy it. Anne-Marie ### Softtest Talk on Automated Testing in Agile Environment URL: https://www.annemariecharrett.com/softtest-talk-on-automated-testing-in-agile-environment/ Last updated: 2021-06-15T09:45:52.000Z [Softtest Ireland](http://www.softtest.ie/?ref=annemariecharrett.com) does a great job of holding free talks for software testers in Ireland. They held a talk yesterday on the following: ### **Automated Testing & Development in an Agile Environment** The two speakers were: [**Sebastien Lambla** ](http://serialseb.blogspot.com/?ref=annemariecharrett.com)from CaffeineIT is a “developer passionate about all things Agile” . He spoke about “In the life of a lean feature” and, **Ken Brennock** from Sogeti Ireland, talking about “Individuals and Interactions over processes and tools” The attendance was great, the room was packed and there was a real interest in what these speakers had to say. It was a mixed bunch of testers and test managers. Some were considering moving to Agile, others were already in the process, some like me were there to listen and perhaps pick up a few tips. ### In the life of a lean feature I found Sebastien Lambla’s talk a real challenge and I consider this to be a good thing. I like it when I hear something that I totally disagree with. In this case, it was the concept of a “Cross Competency Team” where you ‘trust your team to be good enough to do everything”. So the example given was, a developer goes and assists with release management if work is backing up. I did not like the sound of that! So I asked the question “does that mean in times of need, a release manager helps out in development”. The answer was in theory yes, **if** they had the skills. And this is where I have the problem with the idea. Because in my view, a tester has special skills too which sets them apart from the rest of the team. They are testers because they think differently, have a different perspective and bring something special to the team that most other members don’t have. But, when the chips are down and the feature is late, does the whole team help out in testing? Or are only those who have the necessary testing skills allowed to test? I suspect not! I’m guessing (or I’m hoping) that I am missing the point about Cross Competency Teams, mostly due to ignorance. Probably, the intention or goal is to promote the concept of “the whole team getting the feature over the line” and that in reality, the developers would be perhaps helping out by using their strengths to supplement the tester instead of substituting the tester. So, for example, the tester would hand over a bunch of code that had to be automated, leaving them to focus on perhaps exploratory testing. Anyhow, onto the next talk. ### Individuals and Interactions over processes and tools The title of Ken Brennock’s talk was about “Individuals and Interactions over processes and tools” which I thought was ironic considering he was talked mostly about tools and little about how a testing individual can contribute in an agile environment”. Still his talk was very useful. He used the waterfall process to demonstrate the types of tools to be used in Agile testing. This perhaps was not a talk for the real agile devotees, but it provided some very useful and practical tips on moving from Waterfall to Agile. I liked how he focused on test data and test environment. He said, that when moving to Agile the priority for testers is to focus on automating the test environment and test data. I think this is so true. One agile team I know of, made sure the developers first created the install and configuration scripts before any other code was written. This way the test team could start creating the test environment and nutting out these issues, which most testers know can be an area of considerable pain. Ken is giving this talk again in webinar format on Wednesday 7th October. For both talks, I thought it was a shame that for a talk to testers, so much was focused on automation. I guess thats what a lot of people want to hear, but I still think there is room to discuss the value testers can provide in exploratory testing in an agile environment. All in all, I feel I have gained much from these talks, many thanks to Softtest Ireland for organising such a good event. Incidentally, the membership to Softtest Ireland is free to all software testers. ### How many 70's references can you pick up? URL: https://www.annemariecharrett.com/brag-fest-on-test-software-test/ Last updated: 2021-06-15T09:00:05.000Z OK, I’m really not one to get into bragging, but I just can’t help tell you all about this one, because I am so excited!‌‌I’ve been asked to be a weekly contributor to [QuickTestingTips.com](https://dailytestingtip.blogspot.com/?ref=annemariecharrett.com) (QTT to those in the know). I feel, honoured, excited and challenged. **Honoured**: I get to post along side people I admire, like Jonathan Kohl. I respect Jonathan because he backs up his thoughts with experience. **Excited**: Its something new, something I have never done before. **Challenged**: I want to be able to bring something to TPP that is appreciated and welcomed. I love that challenge. Thats it! No analogy to testing, no words of advice, just simple elation. Can you feel it ? !! ### Holding the cat by the tail URL: https://www.annemariecharrett.com/diversify-your-software-testing-skills/ Last updated: 2021-06-15T11:22:01.000Z I thought Jack Margo’s interview by[ UTest](http://blog.utest.com/testing-the-limits-with-jack-margo-svp-of-developer-shed-part-1/2009/09/?ref=annemariecharrett.com) was very interesting. What caught my eye was the following statement: > *The days of specialists a*re mostly killed from the recession…you have to be flexible and know multiple disciplines to exist in today’s dev environment. In web development alone, you need to be proficient with XML, DHTML, JS, a DB flavor, an OS flavor, a programming language and some semblance of UI Design to even handle front-end. I have friends who knew only HTML or only PERL. They are struggling to say the least It made me think the same applies to us as software testers. Have specialists in software testing being killed by the recession? Is it necessary for software testers to be ‘flexible’ and know ‘multiple disciplines’? Personally, I think so. Its not good enough these days to be a ‘manual tester’ or an ‘automated tester’. Instead you need to be able to do both. I don’t think that means you have to be ‘expert’ on both, but it does mean you have to have knowledge of both and a good knowledge in one area. That’s why I’m excited about Nathan Bain and the [free automated testing sessions](http://www.meetup.com/agiletesting/?ref=annemariecharrett.com) he’s starting up. As he puts it: > *Come to meet fellow testers, share stories and experiences about tools and techniques which may, or may not, have solved testing problems on other Agile projects.* > *This is also a place of learning, where live demonstrations of tools will be given for FREE – no more expensive training courses for simple (and free) open-source testing tools.* What a fantastic opportunity to learn about automated testing! To complement this, Rob Lambert has setup some free [Exploratory Testing Sessions.](http://thesocialtester.posterous.com/southampton-exploratory-testing-session-any-t?ref=annemariecharrett.com) Both organisers have mentioned that these sessions could also be performed online. I am not going to miss out on either opportunities. I would encourage those interested to sign up to both, either to contribute so others can learn, or learn from someone else. BTW: two quotes were in contest to head this post. The first one was by Mahatma Gandhi: *“Live as if you were to die tomorrow. Learn as if you were to live forever.”* The other was: *“If you hold a cat by the tail you learn things you cannot learn any other way.”* *Mark Twain* I love both for different reasons, but I thought the second one appealed to me as a tester, hence the title 🙂 ### Test Tools for Covert Operations URL: https://www.annemariecharrett.com/test-tools-for-covert-operations/ Last updated: 2021-06-16T21:42:14.000Z I have one of my clients to thank for this tip. I was performing some software testing recently on a product that had both a software and hardware element to it. The unique setup of the laptop, and peripheral equipment meant I that there was only one test environment available. I was fortunate not to live to far away, but the developer lived in England and so would have to upload any fixes and new versions remotely. The client insisted we use [LogMeIn ](http://logmein.com/?ref=annemariecharrett.com)for the remote access. Now, I like my software test environment to be stable at least for some fixed period. That way, I know that I’m not testing a moving target. So when I heard that both the developer and I were to have remote access, I was a bit concerned as the developer could upgrade software at any time without telling me. Then I had a stroke of luck. As any tester worth their salt would do, I immediately started checking out the LogMeIn software. I noticed that under Preferences, there was an Advanced Settings. So, I clicked on that. To my delight, I found a ‘Screen Record’ option which allowed be to enable recording of anything that happens on the remote machine. To a control freak like me, this was complete heaven. It was a way to not only know if an upgrade occurred, but also I could learn how the developer ‘tweeked’ the system. I did at times feel like I was on some covert operation until I fessed up and told him I had it enabled. Anyhow, if you ever in the same situation where perhaps your developer is not the most communicative, I heartily recommend you look at this free application. ### It's all about the context URL: https://www.annemariecharrett.com/context-driven-vs-context-aware/ Last updated: 2021-06-10T18:12:28.000Z Kem Caner in his post on [what is context-driven testing](http://www.satisfice.com/kaner/?p=45&ref=annemariecharrett.com) writes on the difference between *context-driven* and *context-aware:* *“Similarly, some people create standards, like IEEE Standard 829 for test documentation, because they think that it is useful to have a standard to lay out what is generally the right thing to do. This is not unusual, nor disreputable, but it is not context-driven. Standard 829 starts with a vision of good documentation and encourages the tester to modify what is created based on the needs of the stakeholders. Context-driven testing starts with the requirements of the stakeholders and the practical constraints and opportunities of the project. To the context-driven tester, the standard provides implementation-level suggestions rather than prescriptions.”* He then goes on to write: *“Context-driven testing is an approach, not a technique”* You know, I read this about six months ago and whilst I appreciated the difference between the two, I didn’t understand what the big deal was. Consequently, I’ve been a bit dismissive and slightly irritated by some of the discussions held regarding the differences. I couldn’t understand the need to differentiate. As long as ‘context’ is taken into account during testing, who cares what it’s called? (I suspect you know where this post is heading….) Of course, I now realise that I was wrong and it does matter. Because, the difference is all about attitude. Context-driven testing is an attitude that refuses to confine and constrict software testing to one approach, goal or technique and asks the tester to come to each test exercise without prejudice, assumption or pre-conditioning. That doesn’t mean that once the context is understood, any previous learning doesn’t come into play, it’s just that for context-driven testing, you are purposefully open minded about how you will test. With context-aware, some methods have already been pre-determined. This doesn’t matter if it’s a standard, a checklist or a template, a decision has been made before the testing starts to use some approach. In fact, a context-driven tester and a context-aware tester may both end up testing a product using the same techniques. The difference would have been, a context-driven tester makes a decision on the approach after talking to stakeholders whilst the context-aware tester has already decided on approach and technique before speaking to a stakeholder. I’m still to be convinced about the Unicorn Question though……… ### In search of the ultimate bug tracking tool URL: https://www.annemariecharrett.com/software-testing-bug-tracking-tool/ Last updated: 2021-06-15T10:08:42.000Z As many of you know, I’ve been on the hunt for a bug tracking tool for a while now and I’m glad to say the hunt is over. I needed this bug tracking tool to meet some key criteria. 1) It had to be easy to install. Startups don’t always have a reputation of up front planning and I wanted a tool I could recomend that was quick and easy to install. 2) It had to be open source. I didn’t want to pay for a bug tracking tool unless I had too. My clients feel the same way. 3) I wanted to embed the bug tracking tool into my website [Testing Times ](https://testingtimes.com.au/?ref=annemariecharrett.com)and then provide it as a service for my clients who don’t have or want a bug tracking tool. 4) It had to be easy to use and secure. I wanted each client to have access to only their project. TRAC got the heads up for being open source, but was too hard to install in comparison to YouTrack, which beat it hands down. YouTrack only provided a temporary license though and I had trouble getting my hosting company to support Apache Tomcat. The effort to install something I may have to pay for later, made me feel it was pointless to pursue. Tails was interesting and looked great, and if I **had** to pay for a tool, their pricing structure suited my needs. There is no messy install as it’s a hosted service but that meant that I wouldn’t be able to embed it onto my site. Practitest had similar issues for me, and also the pay per month/user pricing structure didn’t suit my needs. I was at a bit of a loss until [BHARATH](http://sbharath1012.blogspot.com/?ref=annemariecharrett.com) suggested Redmine. Redmine is an open source tracking tool that’s easy to install, easy to configure and secure. It ticked all the boxes and it’s now sitting on my website. You can take a look at it at http://bugs.testingtimes.ie if you like. I have created a public project called Testing Times for those who want to investigate a bit further. The real test of course will be my clients, their reaction and how much they use it. So a hearty thanks to Bharath and a sigh of contentment from me. ### A CIO's pain....a software tester's gain? URL: https://www.annemariecharrett.com/a-cios-paycut-a-software-testers-gain/ Last updated: 2021-06-16T21:49:26.000Z “In April, the CBA announced it would replace the traditional measurement of IT performance – the service level agreement – with customer feedback reports which impact employee remuneration directly.” so the IT news reports. As a result, CIO Michael Harte accepted a reduced paypacket following a June outage. The full article can be read here [Commbank CIO takes pay cut over Netbank outage](http://www.itnews.com.au/News/155279,commbank-cio-takes-pay-cut-over-netbank-outage.aspx?ref=annemariecharrett.com) My first initial thought was “great, maybe more testers will be hired to make sure crappy software isn’t released” followed swiftly by “I wonder if any software testers had their wage packages affected because they didn’t find the June bug?” I’d be interested to see what the Commbank test team makes of this! ### Pre Software Testing Checklist for Startups URL: https://www.annemariecharrett.com/pre-software-testing-checklist-for-startups/ Last updated: 2021-06-14T04:08:41.000Z Most Startups will not use large amounts of documentation unless it adds value. In an environment where the one thing you can rely on is change, sometimes it doesn’t pay to put too much detail down in formal software test plans. That’s why I am in such a fan of checklists. A software test checklist is like a cheatsheet for testers. It’s a list of reminders to make sure you’ve covered all the basics. Nothing fancy, I prefer a one sheet, but I’ve seen checklists two or three pages long. Lots of people in software testing loves checklists. It’s our way of ensuring we don’t forget stuff, well at least that’s why I use them. They work really well with Startups who either don’t have the time, need or inclination to load themselves down with lots of methodologies and process. The first checklist that I am in favour of handing to my Startup clients is the Pre Assignment checklist. My Pre Assignment Software Testing Checklist provides Startups with a list of essential to do items. Most of my Startup work is short assignments between 3 \~ 5 days as time and budget are limited. So, if they can’t supply these things before I start, I politely suggest that they’re wasting my time and their money. *Proviso:* *The assumption in this checklist is that I’m software testing on-site and the assignment is a short term one. Otherwise some of this stuff I would be responsible for. For long term assignments part of these may be written into the software testing assignment.* So here it is in its full glory with added explanations for clarity. ## **Pre Assignment Software Testing Checklist** ### **Software Test Goals** - What do you want to get out of the software test effort? Confidence, Knowledge? Software that works better? The sheer nature of software testing means that a software tester can provide you lots of interesting information apart from bugs found. For example, if it’s knowledge, A software tester can collect lots of data on performance and reliability which may be helpful in marketing your product. ### **SoftwareTest Reporting** - Who is going to see this report? *A good software tester can write the same information differently depending on who is going to read the report. For example, you may want a report written in word format for business purposes. If its a developer, then perhaps they have a favourite defect tracking tool they want to use.* - What sort of reporting do you want? *How often do you want a software tester to update you? Daily, Weekly or just at the end?* ### **Test Strategy** - Do you have a long term software testing strategy in mind? *Perhaps you wish to automate your testing in the future, or you want to introduce a process, if you let the software tester know up front, they can perhaps include some structure for you to keep once the software testing is complete.* ### **Software Test environment** - Determine the Software Test Environment *Has a decision been made on the system requirements? Software Testing ought to use this as the default test environment. Make some decisions on the following:* - *Operating System* - *Browser* - *Printer* - *Machine* - *Any other supporting software* *Don’t forget to decide on a version number for the software* - Assign Machine *The developer’s machine won’t do, sorry. You might have a machine in mind, but have*: - *Started it up recently?* - *Made sure no-one else is using it?* - *Does it require updating?* *My point is don’t assume that the box you ha*v*e earmarked is available.* - Setup Software Test Environment *I know it works fine on your machine, but its worth ensuring it installs on the test machine.* - *Install all the support software the system needs* - *Install the correct version of the support software* - *DO NOT install the product to be tested if installation and configuration is to be tested* - Test the Setup *Start up the software that has been installed to make sure it works properly* **Finally and maybe most importantly!** ## **Software Test Support** **Ensure:** - support by development is available to support the tester *Don’t give the developer a two week holiday for working so hard to complete the software on time. He still needs to support the tester when bugs are found* - IT support is available if necessary *If your luck enough to have an IT team, make them aware of the software testing work that is going on and ensure someone is there to help if necessary* This type of work is often overlooked in the eagerness to get the testing started. If you want you’re software testing to start on time and keeping within budget than completing this software testing checklist is essential. Here’s a link to a scaled down version. ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/PreAssignmentChecklist-1.png) Feel free to download it, but please leave the reference to Testing Times in either the header or footer. ### 50 Beta Testers. Not enough, or better than most? URL: https://www.annemariecharrett.com/50-beta-testers-not-enough-or-better-than-most/ Last updated: 2021-06-16T21:01:58.000Z Two software testers talked about the Joe Stump story this week. One was Elizabeth Hendrickson and the other UTest. The two attitudes to the same story are very different. Let me compare two of the views: First [Elisabeth Hendrickson](http://testobsessed.com/2009/09/01/not-exhaustively-tested/?ref=annemariecharrett.com) **“Problem #2: Thinking that “50 Beta Testers” and “200 Unit Tests” Constitutes Exhaustive Testing** *Having beta testers and unit tests is a good and groovy thing. But it’s not sufficient, as this story shows. What appears to be missing is any kind of rigorous end-to-end testing.”* *……….* *“So even the most cursory Exploratory Testing by someone with testing skill would have been likely to reveal the problem.”* Now [UTest](http://blog.utest.com/a-new-way-that-bugs-can-bite-you/2009/09/?ref=annemariecharrett.com) *“Not to lay blame at Stemp’s feet. We, of all people, know that bugs happen. Plus he mentions utilizing 50 beta testers and 200 unit tests, so they’re doing more testing than many. But IF these showstopper bugs had been caught in the initial version or even in the 2nd version of Chess Wars, then Chess Wars wouldn’t have its nose pressed up against the window of the App Store, waiting for the powers-that-be to bless the new version.”* Whilst both blogs encourage more testing, I think I prefer Elisabeth’s attitude to the whole thing. It’s hard to know if 50 beta testers is sufficient or not without the context (last phrase included to avoid references to Unicorn Question in any comments..you know who you are…). Regardless, the attitude that if you *‘do more testing than many’* somehow vindicates the fact that showstopper bugs were found is I think a misguided one. As Elisabeth rightly pointed out in her post, good exploratory testing would have picked up this bug and any good tester knows to test for these things. I hark back to my post on other approaches to testing for Startups. There are better ways to test! Let's not fall into the pitfall of accepting a lower level of testing as sufficient. Just because Startups use Beta Testing as the preferred modus operandi , doesn’t necessarily make it a good approach. ### YouTrack, a new issue tracking tool URL: https://www.annemariecharrett.com/youtrack-a-new-issue-tracking-tool/ Last updated: 2021-06-16T21:41:07.000Z I noticed that there is a new bug tracking application on the scene. It’s called [YouTrack](http://www.jetbrains.com/youtrack/?ref=annemariecharrett.com) and describes it self as: *“web-based, keyboard-centric issue tracker”* and *“The Fastest Bug and Issue Tracker”* “Wow”! Sounds like just the tool for a Maverick Tester! I’ve been on the hunt for a decent bug tracker for my website, so I thought I would try this one out. The download and install was true to its word, it was fast and immediately a login page appeared in my browser. Fantastic! I had spent many hours installing TRAC and in comparison this was a cinch! I’m now the proud owner of YouTrack on my laptop. There’s a few things seem nice, one is the use of tags and the ability to create users under projects only, which will be handy for me as I don’t want my clients to be able to see other project content. I did have a grin at the roles though, there was admin, developer (of course), observer (??) and reporter (?!). I think that we testers will fall under the “reporter” role. This application is under Beta, and JetBrains are asking for people to raise bugs as they see it. Hopefully, the beta testing is a bit more successful than Joe Stump, of blundermove.com ([see Elisabeth’s Hendricksons great post on this](http://testobsessed.com/2009/09/01/not-exhaustively-tested/?ref=annemariecharrett.com)). Or they have performed some solid system testing (by their “reporter” )prior to this beta release. I’m going to try and install it on my web server in the next two days, and I intend to use it for a current client I have. The major downside I see to YouTrack is the fact that it’s only a temporary license. I don’t want to invest large amounts of energy into a product that turns out to be excessively expensive. For startup’s TRAC or Bugzilla which is open source may still be more worthwhile. Anyone else used YouTrack? ### Software Testing Industry Benchmarks URL: https://www.annemariecharrett.com/software-testing-industry-benchmarks/ Last updated: 2021-06-15T11:13:39.000Z There is a bit of a discussion on “industry norms” on the yahoo based software testing group run by James Bach and Cem Kaner. It’s about the problems with trying to compare your company’s software testing against industry norms. One of the comments made by James Bach was: *“But, nobody is studying industry norms except grad students in CS who* *use badly designed surveys to poll non-randomly selected people who* *then either make stuff up or simply don’t know the answers to the* *questions on the survey. I’ve been polled that way four or five times.”* One Australian company that **is** trying to make some sort of benchmark is K J Ross & Associates. They’re asking for industry participation into a survey on software testing. My thoughts on this are, that whilst it’s something to be applauded, in the end, people tend to use data to justify a decision than to be drive a decision. So what exactly is the benefit of such a survey? I’d like to hear K J Ross’s thoughts on this! Do “industry norms” have a place in business? I’ve worked in enough large and bureaucratic organisations to know that some things just don’t get done without some data to backup a decision. I don’t necessarily agree or disagree with this, I just use it to my benefit. Perhaps this is just me, I’m not an evangelistic software tester, I don’t have a new way to software test, or a new technique to revolutionise the testing industry. My goals a more basic, and perhaps I lack the vision and drive to see something like this change. I work with what I have, not with what I want to have. I think that’s “good enough”. ### Straight up, no ice.... URL: https://www.annemariecharrett.com/straight-up-no-ice/ Last updated: 2021-06-16T23:38:16.000Z You know the way sometimes, a post, or even a comment on a post gets you thinking. A recent comment by Phil Kirkham on Georgia Motoc’s blog got my subconscious brain working overtime. So much to the point where I feel compelled to put finger to keyboard and write about it. I had always been a fan of positive praise before negative feedback. As the bearer of bad news (like many software testers), I though this was an effective way of cushioning the impact of what I wrote or said. So, when Georgia Motoc wrote a post on feedback discussing the ‘Praise Sandwich’ I was surprised how negative Phil was on the approach. However his comment and his link (indirectly to a [post by Art Petty ](http://artpetty.com/2009/05/07/why-i-hate-the-%e2%80%9csandwich%e2%80%9d-technique-for-delivering-feedback/?ref=annemariecharrett.com)) really got me thinking of how I communicate with developers. It made me realise that the positive feedback I was providing was more for my benefit than for the software developer. Here is some Art’s original post: **5 Reasons Why the Sandwich Technique is a Truly Bad Practice:** - *It is a crutch that is solely for the benefit of the giver, not the receiver.* - *It obfuscates the real message.* - *It confuses the receiver by watering down the key message.* - *It destroys the value of positive feedback by linking it with the negative. Don’t forget that positive feedback is a powerful tool for reinforcing the right behaviors and the sandwich technique devalues this tool.* - *It is insulting to the receiver and borderline deceitful. “Bob, you did a great job on XYZ, but .” It’s like a pat on the back followed by a sucker punch followed by another pat on the back.* I have a real reason why I have changed my attitude to this: When I’m on a short term assignment (which is often) I don’t have time or the need to cultivate deep relationships with software developers. What is important is that the bugs I find are communicated in a clear and concise manner. That’s what I am paid for. The praise sandwich is not necessary and more importantly it does not provide best value to my client. This is something I learnt on James Bach’s course and has stuck with me. What ever you do ask yourself, “Is what I’m doing right now adding value for my customer”. ### Software Test Reports for Startups URL: https://www.annemariecharrett.com/software-test-reports-for-startups/ Last updated: 2021-06-16T23:20:14.000Z My test reports have deviated a lot since the early days of testing. Nowadays, first and foremost I provide an opinion of the software. I make sure I highlight both positives and negatives that I see in the product. Naturally, I provide a list of bugs I find, but I also provide a list of suggestions on the software, for example new features or ways to improve the Usability. I find when testing, new ideas often come to me about features. I’m happy to provide them with a list. They can take it or leave it. Finally, I list some recommendations on testing for the next release. Why all the effort? I do this because my clients love it! I provide more than just a list of bugs. I see it as adding more value. Contact me for this Software Test Report Template I wonder though, is this still testing, or have I morphed into a new area of work? My test reports have deviated a lot since the early days of testing. Nowadays, first and foremost I provide an opinion of the software. I make sure I highlight both positives and negatives that I see in the product. Naturally, I provide a list of bugs I find, but I also provide a list of suggestions on the software, for example new features or ways to improve the Usability. I find when testing, new ideas often come to me about features. I’m happy to provide them with a list. They can take it or leave it. Finally, I list some recommendations on testing for the next release. Why all the effort? I do this because my clients love it! I provide more than just a list of bugs. I see it as adding more value. Here’s the template pdf version:: [Software Test Report Template](http://www.testingtimes.com.au/blog/documents/Testing%20Times%20Software%20Test%20Report%20Template.pdf?ref=annemariecharrett.com) I wonder though, is this still testing, or have I morphed into a new area of work? ### Hackers, Blogs and PC's.... Oh My!!! URL: https://www.annemariecharrett.com/hackers-blogs-and-pcs-oh-my/ Last updated: 2021-06-16T21:20:27.000Z What a week! My ‘problem’ antennas have been twitching this week. It started off with my blog and user access. ‘Hedosnorrenny’ had decided to become a contributor to my blog. Without me asking. There he (or she?) was, proudly displayed in my WordPress ‘users’. So, methinks, time to perform some extra security. With all this Gumblar about, you can’t be too careful.. I download some malware software and start scanning. Problem number 2 pops up. Every time my scan runs, it freezes on one particular dll. Uh Oh, virus? No No my friends…it’s bigger than that… It’s hardware failure!!! Hooray, at least I know it’s not my antivirus sofware! My Dell laptop M1530 which is only just over one year old (and so out of warranty) decided to pack in its hard disk. I can understand this. After all, with a 320 GB capacity, that’s a lot of hard yakka. So, I grin and bear it in true Testing Time’s fashion and replace the hardware. Fortunately, I’m good citizen material and have recently backed up my data. So, new hard drive and away I go….until…. Problem number 3… Of course, when Wordpress announce a new upgrade for security reasons, I immediately think, fab, this might fix my user registration issue, so upgrade I go. Then I discover that all my blog links don’t work, neither do my catalogues. Is there no end to this mess? Fortunately, because of my good citizen material(see above), I have a backup and roll back an old version and presto…back in business. I look back on my week of failure and reflect, what could I have done better? I don’t think I could have prevented the hardware failure, and the hacker? I think I am pretty secure about my access, but I’m willing to admit I still have a lot too learn. WordPress upgrade failure? Completely my fault. I’m a software tester! What did I think I was doing, upgrading before testing? I really ought to have known better. So, yes I’ve learnt a lot this week. Keep your access 100% secure and test before you upgrade. I’ve now got a test site for my wordpress, and any upgrades will be well tested before it has to perform in public. Basic stuff right? I can’t believe I keep falling into these traps…. Any advice to wordpress users, backup often and have a test site that replicates your real site. Hmm, I think I’ve heard that advice before somewhere…. ### Do your bugs only glow when its dark? URL: https://www.annemariecharrett.com/do-your-bugs-only-glow-when-its-dark/ Last updated: 2021-06-18T11:35:28.000Z Have you ever been in the situation where no-one else can find and repeat the bugs you find? Perhaps you have a canny knack of finding unusual bugs, or maybe it’s time to improve and update how you write bug reports! I do a lot of offsite exploratory testing in very aggressive timelines and consequently I have to admit, I sometimes start making basic mistakes. My common mistakes are: 1) I don’t write the bug report up straight away 2) My bug reports are not detailed enough 3) I underestimate the time it takes to write up defects 4) I don’t use a defect tool You can imagine, when you’re working offsite without even meeting the developer, this can lead to all types of complications. So I need to put myself in that poor developers shoes and make my bug reports as clear, concise and as detailed as possible. I think it’s tempting when there is little formalised structure in testing to overlook writing a disciplined bug report, but it’s worthwhile to you and the customer. I mean what’s the use of paying someone to find bugs when no-one else can find and fix them? Anyhow to prevent myself repeating such unforgivable mistakes, I have developed a set of guidelines to follow. **Offsite Exploratory Testing Guidelines to Bug Reporting** 1) In the estimate to the customer, make sufficient time to write your bug reports as you go. It’s impossible to know how many bugs you are going to find but you can do a bit of math. If you’re planning three days of testing, and you find 100 bugs @ 10 mins average, then that’s two days of your testing filled up with just writing up reports. 2) Agree on a detailed bug report with your customer. Try if you can to get agreement with the developer. Try and include as much background information as you can. There has been a load written on what constitutes a good bug report, so I won’t repeat it here. 3) Don’t delay; write up the bug report straight away. This is hard when you’re in the middle of some exciting analysis and you really just want to keep testing in the timeframe you agreed on. But trust me; it takes longer to write them up at the end, when you have to review heaps of cryptic phrases in Session Tester or in your notebook. A capture tool may be helpful in recording data, but if you leave reviewing to the end, it will add additional time and effort to the testing 4) Encourage customers to use a defect tracking tool. It saves everyone a lot of headache and heartache. There’s lots of open source defect tracking tools out there. TRAC and Bugzilla are the two most common. ### Black and White and Red all over.... URL: https://www.annemariecharrett.com/black-and-white-and-red-all-over/ Last updated: 2021-06-15T08:38:44.000Z There’s an add on telly about this guy who writes his book on a Remington typewriter and then the post office sends it and suddenly its in the window of a bookshop. It think the ad is for the Irish Post Office. Regardless, there is a moment when the author looks into the bookshop window and glows with satisfaction and pride on the achievement. That’s a bit how a feel like today. I just have had my first article published in [T.E.S.T magazine](https://www.softwaretestingnews.co.uk/july-2009/?ref=annemariecharrett.com) and I’m on the front cover no less. It’s about one of my favourite topics, software testing and startups. It’s these types of achievements along with getting work, that keep me working as a independent test consultant because, working on your own can be really tough! It’s a constant act of self promotion, bookkeeping, customer liaison and oh, occasionally I get to do some software testing. There was a post on the software testing club recently on ‘what are the things to consider when outsourcing?” I think the things to be considered are those outside of your area of expertise. Software Testing is only a small percentage of what you will do in order to be successful at freelancing or working as an independent. Anyhow, back to the article. As I was reading it, I felt a mixture of pride, satisfaction and surprise. I didn’t realise I could write so well….maybe it’s to do with the fact its a published article, or maybe its because the self satisfaction is putting a rosy tint on the whole thing. I don’t know….I don’t really care. Now leave me alone whilst I bask in my halo of self content….. ### Will video kill the written bug? URL: https://www.annemariecharrett.com/will-video-kill-the-written-bug/ Last updated: 2021-06-16T09:11:31.000Z I’ve recently finished some remote testing using exploratory testing techniques. I decided to test out a couple of new (to me) techniques. The first one was using Session Tester to track my effort. The other was creating short videos of difficult to articulate bugs. First a bit about my testing approach. When I start this type of work, I tend to dive head first, perform analysis along side bug reporting. I then take a step back, work out a plan and get the client OK, then go back to testing. Finally, I write a report which includes recommendations, suggestions and naturally bugs. The reason I work this way, is I often get little up front information on the application, so I find the best approach is the “use it to learn it” approach. I tend to give myself a day to work out the application, and report back to my customer my intended plan. Anyhow, I liked using Session Tester. It was handy to document the work as I went. However I found that it was hard to track my “tasks” with my bugs. I used my own numbering system which I could then link the bugs and notes. However, when I went to write up my report at the end of the testing, I found my notes were incomplete and sometimes hard to understand. Very frustrating when working to tight deadline. Fortunately, as a backup to all my work, I always have SpectrePro running as I test. I do this because if a client comes back with a question, its handy to be able to go back and review the work I did. So, SpectrePro had captured not only the application under test, but SessionTester with relevant notes and bugs. It was very helpful to review the SpectrePro video in combination with the SessionTester notes and bugs I’d written. Another concept I tried was to use FastCapture to capture video of any really difficult bugs. FastCapture allows you to capture your steps and add commentary to it. So if you're good at describing what you are doing whilst you test, this is an excellent method to really explain to a client and or developer the problem you encountered. Watch out for the heavy breathing though! My clients really like the video idea and wants me to explore it further. I don’t know if its something I would do for all bugs as its quite resource heavy (on my time and file size) however, its something I am going to pursue. Will video supercede the written bug? Perhaps not. Like the radio star of the eighties, I don’t think the written bug has anything to worry about. However as an additional testing and communicating resource, it has its place in the naughties. ### Challengers are you ready? URL: https://www.annemariecharrett.com/challengers-are-you-ready/ Last updated: 2021-06-15T10:55:48.000Z So far the Gladiators have stolen the show. ISTQB and the other warriors of testing certification have dominated the testing world. It’s not the only profession where this is happening. Network Engineers working now need Cisco certification in order to get jobs, regardless of their depth of knowledge. In Ireland, solicitors now don’t need a degree, but pass an exam in order to practise. It seems every where people are needing to be labelled in order to find work. So its refreshing that a group of men and women are fighting back. The challengers are now on the stage. Are we ready to back them? I’m talking about the Association of Software Testing ([http://training.associationforsoftwaretesting.org](http://training.associationforsoftwaretesting.org/?ref=annemariecharrett.com)) which is providing free online software testing training if you become a member of their organisation. Membership cost only $85 (there is a range of memberships). Try and get a ISTQB course for that price! I’ve just completed the BBST (Black Box System Testing) Foundation Course. I would highly recommend this course to anyone, experienced or inexperienced. This course is like no other. It really challenges you to think deeply about what, why and how you test. The course is very interactive, you need to be prepared to give an opinion and provide feedback. What I got out of the course was that it’s given me confidence on critiquing other tester’s work. It has also challenged me to be more technical in my testing investigations. It was a great course, and though very demanding, I was sad that it came to an end. One word of warning though, to get the most out of the course, I would give allocate plenty of time for it, preferably more than the 8 hours suggested. One of the main reasons why I decided to take this course, was because I wanted to see if I could recommend or offer to testers I know an alternative to ISTQB. I’d also challenge any tester out there who has an opinion on Certification to take the course and then write a post about it. Challengers are you ready? ### Dublin Software Testers Meetup URL: https://www.annemariecharrett.com/dublin-software-testers-meetup/ Last updated: 2021-06-16T23:51:41.000Z A reminder to anyone in Dublin or if you are in Dublin in Business, to come along to the Dublin Software Tester Meetup. Details are: Time: June 16, 2009 from 7:30pm to 9:30pm Location: the Library Bar, Central Hotel Street: Exchequer Street, City/Town: Dublin, Ireland Website or Map: http://www.pininthemap.com/pp1efb30208acdac9d7 Event Type: social, networking, for, software, testers Organized By: Anne-Marie Charrett I’m looking forward to seeing you there! ### I have a dream..a software testing dream URL: https://www.annemariecharrett.com/i-have-a-dreama-software-testing-dream/ Last updated: 2021-06-17T05:11:04.000Z [Tester Tested ](http://testertested.blogspot.com/2009/05/testing-experience-magazine-voice-of.html?ref=annemariecharrett.com)wrote a post on the amount of ISTQB advertising (direct and indirect) a testing magazine had. His main point was, if its a Professional Magazine for all testers why does it lean to ISTQB all the time? Talk was made of lawyers and being sued for blogging about it. Whilst I valued the point of his post (many thanks Pradeep), it made me sad. It made me reflect on how divided we are in the testing community. In an area that obviously needs great minds to promote the benefits and value of testing, we instead waste them on picking holes in each others ways of doing things. Why don't we use our energy on focusing on the real bad guys, like the CEO’s and CIO’s who don’t value the benefit of testing and place software testing under development in the company structure? Why can’t we complement each other on the positive steps that are being taken in the testing world, instead of resorting to suing each other for defamation? Don’t get me wrong, I understand the concept of critical thinking and the need to challenge each other, but with that goes the responsibility of building people up too. My mum had a saying “for every one criticism, give ten encouragements” (or something like that!) Criticising ISTQB testers alienates the thousands of testers out there who are certified. This us versus them mentality only further divides our community and testers inside it. Not everyone who is ISTQB certified did so because they wanted to. Not every ISTQB certified tester is unable to test in an intelligent way. Many ISTQB testers need to take the certification to get a job. Many ISTQB certified testers may be interested in exploring other testing avenues if their certification was not sneered at in blogs written by ‘experts’ who ought really to know better. Our focus ought to be on educating and encouraging all testers to examine all testing ideas and make up their own minds on they believe. After all, it is the tester who is central to testing, not the testing expert. What in the world do developers, marketing and project managers think of us, squabbling between ourselves on the right and wrong of different types of testing. To these people, testing is all the same thing, they dont understand the finer points of context driven testing Vs IEE 829. I know, I know this is all very naive of me, but are we not mature enough now to put or differences aside, respect each others opinions and work together on promoting the importance and benefits of testing to those outside the testing industry? I have a dream where we are building up testers to test better regardless of creed……. ### In defense of the humble spreadsheet URL: https://www.annemariecharrett.com/in-defense-of-the-humble-spreadsheet/ Last updated: 2021-06-14T04:20:05.000Z I wrote a post a while ago on [scoping out your tests](https://www.annemariecharrett.com/software-test-templates-scoping-out-your-tests/). In it I described how I use Excel spreadsheets to scope out and estimate what I need to test.Judging by the comments I got back then, Excel spreadsheets in software testing have the ability to divide the software testing community. I was once in the ‘down with EXCEL in testing’ tribe. Now I’m in the ‘Excel is cool” camp. I used to hate spreadsheets in large organisations. They created havoc on my test methodology. Every every project has their own version of the template that is an improvement on the original design. Not only that, but every tester within the project had their own version on their PC. There was no way of really knowing how many bugs had been found. I couldn’t understand why testers didn’t just use test management tools like Test Director. Why didn’t testers see the benefits these tools could bring? That was until I started freelancing with startups. Oh my, did things change. Suddenly I was in an environment where there were no resources to invest in expensive test tools. “No Problemo” I thought, “I am an independent free thinking tester, I will investigate some open source tools and put forward those as suggestions”. Ha!! Even when I did find a tool that was liked, there was little time to invest in installing and configuring a tool. Furthermore, I knew the minute I left, nobody was going to maintain the scripts etc, so really was there any point in wasting my time installing such applications? So I turned back to the humble spreadsheet and started estimating, scoping and tracking my results in it. I would send updates to my clients regularly, and sometimes I would even add some pretty metrics to make people feel good about my testing. Now that you can upload spreadsheets online, much of the issues with version control disappear. It works for me. The great thing about spreadsheets is not its flexibility, its power and its ease of use. The great thing about spreadsheets is this: Everybody knows EXCEL and has the it on their PC. It's available to everyone, needs no training, maintenance or configuration. People understand and are familiar with spreadsheets. That means the time I would normally need to spend installing a tool, configuring , maintaining and training people on a tool, now can be used in testing. And believe me when your given 3 days to test and report on an application, that additional time really counts! So Viva the humble spreadsheet, and long may your silvery squares compute. ### Software Testing & Startups Talk in Dublin and Belfast URL: https://www.annemariecharrett.com/software-testing-startups-talk-in-dublin-and-belfast/ Last updated: 2021-06-17T00:04:28.000Z If anyone is interested there will be a softtest event this month (May) in Dublin and Belfast. I am giving a talk on software testing and startups. Here’s the abstract ## Software Testing in the world of Start Ups This presentation offers a glimpse into software testing in the world of startups. It looks at the constraints and benefits facing software testers in this unique environment. It examines what it takes to be a software tester in a startup. It will also be a bit of a myth buster session, looking at some of the myths around testing in startups. It closes by asking are we as a software testing industry doing enough to help startups improve their software. ## Dates Belfast : 26/05/09 4.30 pm, Venue is the Radisson SAS. To register your attendance email Nicola.McManus at momentumni.org Dublin: 27/05/09 4.30 pm, Venue is the Holiday Inn, Pearse Street. To register your attendance email Anna.Donegan at ibec.ie ## Agenda 16:30 – 17:00 Registration 17:00 – 18:00 Professionalism in Testing, John McArdle 18:00 – 19:00 Software Testing in the World of Start Ups, Anne- Marie Charrett, Testing Times 19:00 Close I think you might need to be a member of softtest which is free, go to the [softtest ](http://www.softtest.ie/?ref=annemariecharrett.com)website for more information I look forward to seeing you there! ### Date set for Dublin Software Testers Meetup URL: https://www.annemariecharrett.com/date-set-for-dublin-software-testers-meetup/ Last updated: 2021-06-16T23:48:39.000Z Put the 16th of June into your diary. Is the inaugural meetup for the Dublin Software testers. The venue is the [Library Bar, Central Hotel, Exchequer Street](http://www.pininthemap.com/pp1efb30208acdac9d7?ref=annemariecharrett.com). Its on the first floor. Time is from 7.30 pm This is a social event for software testers, a chance to get together and chat. You can talk testing, or not. For more information go to the software testing club events page. If you want to visit and join the online version of the group, go to the software testing club.Its free to join, has over 3000 members and is a great online source of information and assistance. http://www.softwaretestingclub.com/group/Irishsoftwaretesters I look forward to meeting you all online and in person! ### Dublin Software Testing Group URL: https://www.annemariecharrett.com/dublin-software-testing-group/ Last updated: 2021-06-16T23:49:39.000Z Online networks are great for sharing knowledge and meeting fellow testers. In particular, I am a fan of the [software testing club](http://softwaretestingclub.com/?ref=annemariecharrett.com) . However, even better is a face to face meet. Thats why I’m setting up a Dublin monthly software testers group. The aim is to meetup and talk about, well anything you fancy. To quote a member: “a get together to give out about our unfeeling brethern in the rest of the IT world and a few pints for good measure. What more could you ask for? If you’re interested in attending, leave a comment here, or go to the online version of the group at Irish Software Testers Group Looking forward to meeting you online and in person Anne-Marie ### This heuristic is backwards URL: https://www.annemariecharrett.com/this-heuristic-is-backwards/ Last updated: 2021-06-16T23:59:17.000Z Recently, I’ve been asked to make some comments on a book. I’m using a technique I ‘discovered’ in my early days of testing. I am calling it the ‘Backwards Heuristic’. In my early days of testing when I had to review documents, I lacked the confidence to speak out in review meetings. I quickly found out (rightly or wrongly) that to make a decent impression in a review, salient points had to made quickly before any team member came up with the same point. The main reason for this, most people had only read the first three chapters of a document, because they either a) lost interest in the document b) ran out of time or c) were not given suitable notice about the review. Consequently, beyond the first few chapters, most people had few or any real comment to make. In fact, review meetings often turned into an intensive discussion on the ‘introduction’, or the’ intended audience’. So, I came up with a cunning plan, which I now call my backwards heuristic. What I did was always started reviewing documents from the last chapter to the first. My thought process was, most people never read the last chapters, so if anything was going to be missed, it was there. I was on a winner, by reviewing any document from the last chapter to the first, I most always had something to comment about that was unique and worth discussing. What’s more, it often took me less time to come up with something worthwhile, then if I had read the document from start to finish. It's only now that I have gotten round to calling it ‘the backward heuristic’, mostly because I’m reviewing James Bach’s course on RST. However, perhaps this has been discussed by other people before? Or does it take a truly devious tester to think up such methods ### Better than Beta? You Betcha! URL: https://www.annemariecharrett.com/better-than-beta-you-betcha/ Last updated: 2021-06-17T00:11:20.000Z Software testing has gone through a few renaissances in the last twenty years or so. From the dark ages of the waterfall process, there has emerged new theories, schools and test tools. We even have online clubs and networks. One noticeable difference between then and now is testing was traditionally part of development. Now, most larger companies recognise the need for some form of testing team. So don’t you think it’s strange when it comes to software testing, startups still remain in the dark ages of developers testing their own code and then skipping straight to a beta test? The rationale is that it’s an easier, faster, cheaper approach than employing a software tester. I ashamed to say that until recently I bought into this misconception. Its only when I started doing some research into beta testing, that I discovered the amount of work and effort it took to. So I’m doing a Mythbuster session. ## Myth 1: Beta Testing is easy Beta Testing is hard work. Like any major task it needs planning and effort. Successful Beta Testing takes lots of planning and lots of effort. Upfront analysis into the number of Beta testers required and how they will be sourced. How much time is necessary for the Beta Testing, how many releases will you have (yes, you need more than one!). How will Beta testers sign up and will their feedback need to be secure? How will you keep track of the bugs found, and how much time will you need to support the effort? There is no point having feedback from 200 Beta testers but not having the time to analyse the information, let alone fix the problems. What tools will you need to keep track of the Beta test? These are just some questions that will need to be answered before you can begin your beta testing phase. A couple developers talk about their experiences of Beta Testing..[Joel Spolsky – founder of FogCreek Software ](http://www.joelonsoftware.com/articles/BetaTest.html?ref=annemariecharrett.com)and[ ](http://www.joelonsoftware.com/articles/BetaTest.html?ref=annemariecharrett.com)[SyneRyder Journal](http://www.namesuppressed.com/syneryder/2004/betapostmortem.shtml?ref=annemariecharrett.com)[](http://www.namesuppressed.com/syneryder/2004/betapostmortem.shtml?ref=annemariecharrett.com) ## Myth 2: Beta Testing is Quick The length of time beta testing takes depends on the complexity of the software being tested and the number of releases you plan to have. Typical estimates range from four to ten weeks depending it seems on your experience of Beta Testing. One constant that remains, is that beta testing always takes twice as long as you estimate. That’s because one of the difficulties with Beta Testing is your dependence on people who don’t owe you anything and in that sense are under no obligation to meet any of your deadlines. ## Myth 3: Beta Testing is Free The greatest myth of all. The man hours spent in planning, setting up, monitoring makes beta testing a time consuming task. Time far better used by a developer in turning the software into a great product. The end result is your developer is distracted and performing tasks that many software testers can perform quicker and cheaper. On top of that, testers know how to test software really well, something you can never guarantee from a Beta tester. ## Software Testers do it better Software testing has really matured in recent years, and there are many ways to provide quality testing that meet the unique demands that startups face. Software testing does not necessarily equate with streams of documents and restrictive process. You only have to look at techniques such as Rapid Software Testing by James Bach and open source tools to know that there are many alternatives to traditional software testing. There are so many good software testers out there, available for hire on a freelance basis, it makes these age old myths about software testing and startups, a bit passed their use by date. It’s time for startups to do themselves a favour. Hire a software tester, even for a couple of days. It’s worth every cent… ### A scrum in Croke Park URL: https://www.annemariecharrett.com/scrumming-in-croke-park/ Last updated: 2021-06-15T09:46:29.000Z I’m attending the SQS conference on Software Testing in Croke Park, Dublin. I thought it was appropriate to go to an Agile Testing session involving Scrum amongst other techniques in the same hallowed ground where not to recently a game of Rugby was played out between England and Ireland. As our trainer Mike Scott was English, we tried not to gloat too much. I won’t bore you with lots of analogies on how Agile is similar to rugby, besides after a day of Agile, I can’t think up too many, I’m sure someone out there can…. But here is what I enjoyed about Agile and its techniques I liked the concept of the balloon pattern and testing so early that no code has yet been written, only your installation packages. I think thats really smart. You can iron out all your installation and configuration issues up front. I like the concept that we as testers need to ask lots of questions and not make assumptions, though I think this is not unique to Agile. A course on Rapid Software Testing by James Bach also stresses this point. However, Agile demands intelligence in testing, where perhaps more traditional methods are less exacting? There seemed to be a heavy dependency on Test Driven Development (TDD) which I am a big supporter of, though I do question the use of 100% Acceptance Test Automation. I think in every software testing exercise there is room for both manual and automated testing. Its a question of intelligently planning out what percentage ratio works best for that particular project or environment. Is Agile faster and cheaper as its sometimes portrayed? I suspect not, but it does offer a customer greater flexibility and visibility and I like the sound of that! ### I'm glad I'm not a piece of software URL: https://www.annemariecharrett.com/im-glad-im-not-a-peice-of-software/ Last updated: 2021-06-26T00:49:33.000Z I joke about my personal development lifecycle (PDLC) as my work in test management often requires consistency & repeatability in the form of a test process. In comparison my own PDLC is often very erratic and ill behaved. In fact its not really a typical lifecycle at all except perhaps that I was born and one day I will die. My family and I have recently decided to spend some time in Ireland. In November, we are uprooting our family in Melbourne, Australia and dumping ourselves back into a very sodden, green sod of turf known as Ireland. We are doing this without any certainty in jobs, schools, long term accomodation etc and its making me extremely nervous. To make it all the more uncertain, the world has decided to have a global financial crisis. My faith that all will work out is being severely challenged! As I continue along my PDLC, my outlook on life has changed. What would have once been an adventure is now looking like a torturous test. So I repeatably breath my mantra, “it will work out, I will find work in Ireland” . Who says life is dull? Anyhow, back to software testing and lifecycles. I suppose the difference between software and people is that we own our lifecycle and thankfully we get to choose how our life turns out. We can choose to make it unpredictable and we can behave outside a given setup of expectations. So even though my life at the moment is in turmoil, it's my turmoil. I’m glad I’m not a piece of software that has to follow a rigorous testing process, in order to live up to someone’s expectations. ### Observations on Offshoring your Software Testing URL: https://www.annemariecharrett.com/observations-on-offshoring-your-software-testing/ Last updated: 2021-06-16T23:43:04.000Z Have you noticed that there is something about having people nearby that instills a sense of confidence in the work being performed? There is something about having a tester in the same country as you that generates security. So it was with a bit of reluctance that I took on a job that had an offshore element to it. I was surprised to discover the quality of the work that came back from the offshore team. They found many bugs outside their scope of work. Their testing was thoughtful and thorough. However, one of the hardest things I found I had to deal with is the lack of visibility on the testing. I am utterly dependent on the only tangible evidence provided to me through test scripts and defects in the shared test management system. I don’t get to see the testers in action… So, despite the knowledge that good testing is being performed, I am still very uneasy when badly written test scripts are created, or if the process is not followed. I don’t know, perhaps this says more about myself than the testing being performed. After all, I personally have never been a fan of extremely detailed test scripts. Perhaps the lack of contact and visibility brings out the micro-manager in me, turning me into a process Nazi. So am I being unfair? Perhaps. It’s made me realise how important it is to be accurate and succinct in your reporting, especially when a client has little visibility on your work. ### If you want to be a millionaire - phone a friend URL: https://www.annemariecharrett.com/if-you-want-to-be-a-millionaire-phone-a-friend/ Last updated: 2021-06-17T01:57:30.000Z I was asked to quote for a job recently on some testing in an area that I had little experience in. After confidently replying to the customer “no problem, I’ll have a quote to you by the end of the day…”, I started googling furiously, trying to gain some understanding of at least what I was meant to be quoting on. By the end of the day I was in a complete sweat. I was going round in circles trying to figure out what I ought to charge for this piece of work. As the sun set, so did my desperation and I decided it was time to “phone a friend”. Recently I had entered into some loose agreements with fellow consultants. Perhaps “partnering” is the correct word. Basically the idea is that, if I have too much work, or work I don’t typically perform comes my way, I pass it onto fellow consultants, and they vice versa. So, in my hour of need, I rang on of them and I tell you what, it was like a miracle. As it turned out, my ‘partner’ happened to be an expert in this area and was quite happy…nay excited to quote and do the work if necessary. What a fantastic result! Not only did I get to keep the professional relationship with my client I also get to help out another consultant. I really learnt something from this experience and that was not be afraid to ask for help. In hindsight, I had been hesitant to ask for help because I thought it reflected poorly on me, I didn’t want to appear to be inadequate in front of either my client or a colleague. Now I know, if I want to become a millionaire.. I need to be able to “phone a friend”……… ### Engineers make awful sales people URL: https://www.annemariecharrett.com/engineers-make-awful-sales-people/ Last updated: 2021-06-16T21:10:18.000Z I had an interesting conversation today about the ability of engineers to be able to sell their services. As a one-woman band type consultant, I don’t have the luxury of a sales force that markets my wares in an enticing way. I rely heavily on referrals and the fact that I do a great job in software testing. When I am asked for a quote, I like to base my estimates on value. What is the best value that I can provide at a reasonable price? I think like an engineer. However, I’m told that the best way to sell software testing is to focus on risk. How can you NOT afford to test? I need to think like a sales person. So, are engineers in general good analysts but bad sales people? ### Is document a dirty word in Exploratory Testing? URL: https://www.annemariecharrett.com/is-document-a-dirty-word-in-exploratory-testing/ Last updated: 2021-06-16T23:05:24.000Z I went on James Bach’s Rapid Software Testing (RST) course because some of the concepts and ideas that I had read about exploratory testing and RST appealed to me. I liked the idea that central to testing is a critical and context-driven approach and I also wanted to put intelligence back into testing. I was curious though, as on some blogs I read it appeared that exploratory testing and traditional testing were mutually exclusive. You are either a champion of traditional testing techniques and provided multiple test documents or you’re in the maverick camp which threw out all documentation and just ‘tested’. I was relieved to learn that for rapid software testing, this is just not true. I was relieved because I LIKE DOCUMENTS. I like them because in certain circumstances I find them helpful. Because I have to confess, sometimes I forget to test parts of an application. Even worse, sometimes I don’t want to test the hard areas. A document gets me to test all areas and to test the parts that I really don’t want to test. It helps me remember the results of what I’ve tested because sometimes I need to know that information. What James Bach reminded me, was that the ultimate goal of testing is very simple. It’s to test an application with intelligence and thoughtfulness. The goal is not to create endless documents on testing. Instead, documents can sometimes be handy tools to assist you in testing. I don’t think I will ever totally give up on my documents. They are my friends. However, I will make sure that in future, these friends can stand the test of relevance, accuracy and brevity. ### Celebrate your wins in software testing URL: https://www.annemariecharrett.com/celebrate-your-wins-in-software-testing/ Last updated: 2021-06-17T02:08:24.000Z Too often software testers are the bearers of bad news: “There is a major defect that will stop us rolling out to production on time” “We have to increase the budget to ensure that the system is properly tested” The more I roll software testing concepts to companies, the more I’ve realised the importance of celebrating your wins. **If you don’t who else will?** Small wins are just as important as big ones. I don’t wait for a software testing process to have all the bells and whistles of metrics before I start shouting about the great benefits that testing has provided. For example; I was rolling out a software testing process that was new to the client. At every meeting (in particular the senior ones), I declared: “In addition to completing the system testing, we found seven existing production defects” I wanted people to know that we have good testers in their company, and also that they were providing a good service. As testers I think we need to be smarter about how we promote our services. ### 6th Software Test Managers Forum URL: https://www.annemariecharrett.com/6th-software-test-managers-forum/ Last updated: 2021-06-18T05:55:32.000Z One of my goals this year is networking and freshening up my software testing skills. So, I decided to go along to the 6th Software Test Manager’s Forum sponsored by K.J Ross and Associates What a great success this event was. I thoroughly enjoyed the opportunity to meet up with test managers to discuss problems and listen to how others have solved similar test problems. The approach was relaxed yet everyone was enthusiastically involved. There was also a good representation of test managers from across many business sectors. I got a insight into trends in the software testing industry – such as: - Get used to it, Agile is here to stay - Learn how to test SOA - Time for us Test Managers to learn how to Market Testing. to name just a few. I would definitely recommend any test manager to go to this great event next year. ### Get Success to drive your software testing consultancy URL: https://www.annemariecharrett.com/get-success-to-drive-your-software-testing-consultancy/ Last updated: 2021-06-17T01:58:41.000Z If you want your software testing consultancy to succeed, first ask what sort of success you want. You probably have some ideas on this. For example, you may want to run an exclusive software consultancy with a reputation for excellence, or make a million before you're 30, or as I do, you want to work for yourself , have a reputation for excellence and balance work and lifestyle. Whatever the definition, this can become great parameters for your future business decisions. I’ll give you an example of what happened to me. Recently, I’ve had the opportunity to review my goals for my consultancy. At the moment, the company is dependent on me, myself and I. That makes me director, test consultant, accountant, marketing manager and sales person.. not to mention cleaner etc. My income is good, and in software testing, there’s a plethora of opportunities and directions someone like me can take. For example, I could outsource additional testing to a different company, take on a couple of software contractors, perhaps concentrate on being a test consultant with a great reputation . So, I went back to my definition of success and used this to redefined by companie’s goals within the parameters I had initially set. It helped me throw out some options, and refocus my energy on becoming a consultant with an excellent reputation. My goal is to have customers knocking on the door with software testing problems to solve. However, it also important to me to be at home for my young kids in the afternoon. So, yes I have to accept that some of the options for me are not possible, however I’m living within my parameters and so yes I am a success. Small Footnote: Of course, you may find out that you redefine your goals within your existing parameters and find you're not happy with the result. I suppose its a good indicator to review your definition of success. Perhaps it’s changed since you started your business? ### How I setup a software testing consultancy URL: https://www.annemariecharrett.com/how-i-setup-a-software-testing-consultancy/ Last updated: 2021-06-17T01:56:30.000Z One question that keeps popping up into my inbox is …..I want to setup a software testing consultancy…any advice? Ohhh yes. Heaps of advice. I don’t know if it will do anyone any good, but I have heaps of advice. However before I start down that path, I thought a far better and honest approach would be to share with whoever is interested how I started my consultancy business. So, a bit of history. ## Setting up a Test Consultancy in Australia By 1998 I had worked on some great testing areas such as European Compliance Testing, R&D for some companies who really knew about testing… Nortel and IBM to name drop a few. But to be honest, the corporate path never interested me. So with a decision I took totally lightly I setup a company. Easy Peasy. It cost me $600 Australian dollars and there it was, AMH Solutions Pty Ltd. I got loads of work, mostly through contracting and though I would have preferred to work directly with a customer, I never gave the issue much thought. Then I had kids. ## Determine your Test Consultancy Success I still really wanted to work, but I decided that considering my new found responsibilities, part time or freelance would be preferable. I figured that running a consultancy was ideal, if I could just find the work. The first thing I did was go back to my old companies I had worked for. I explained I wanted freelance or part-time work and what do you know, within three weeks I was employed running a test management role for three days a week. So things ticked along. I got additional work through word of mouth. I also contacted a few agencies and they kept me on the books for short term work only. I got some great jobs through that. ## The Best thing about a Test Consultancy For most of the time, I have really enjoyed it. One thing I have never regretted is working for myself. I love it. I enjoy the challenge and the freedom that it provides me. I get to set my own goals, where I want to be and what direction I want my company to take. I define my own success. I am happy. ### Freelance Testers - a smarter, cost effective way for startups URL: https://www.annemariecharrett.com/freelance-testers-a-smarter-cost-effective-way-for-startups/ Last updated: 2021-07-14T08:34:47.000Z ITnews had an article recently on startups. It examines what to look for in a startup, and also how to minimise the risks. Here’s an excerpt: ‘A startup’s immaturity will be reflected in the quality and capabilities of its product. As you would when considering an established vendor, a CIO must conduct technical due diligence….You can minimize these risks in several ways. First, do extensive pilot testing, and start with a small deployment’ A good freelance software tester can provide real benefit to startups by verifying and/or validating software at a reasonable price. This builds confidence in a product and is useful for promotional purposes. Its also useful to demonstrate third party verification of technical claims when seeking additional funding. This is how a freelance software tester can reduce cost yet still provide a quality service. ## Freelance software testers are ‘on-demand’ The nature of software testing demands flexibility as the testing effort often fluctuates throughout a software development life cycle. At the beginning of an SDLC, test planning, scheduling and scoping of tests takes place. It can be a very busy time for testers, scoping out whats to be tested, prioritising tests, planning and creating test cases, organising the test environment, the list can go on.. However, there’s often a lull after the initial frantic test planning. This is where all test cases are written, the test environments is ready, and testing is ready to start. The trouble is, often the software to be tested is not. Even when the software testing starts, it can be a start, stop, start affair as major problems are found and require fixing. These are not necessarily related to code, but can be in installation, configuration etc. A tester isn’t always needed but should be on call for when testing does begin. It goes without saying that a software tester is available during the test execution phase, and perhaps due to time demands, needs to test beyond normal work hours. A freelance software tester works only when its needed, this is a big saving in cost. This way you can still afford a quality software tester at a lesser price. ## Freelance software testers listen to the customer A good freelance tester, will be a good listener. By understanding the demands on a business, a freelance software tester is able to adapt the testing to meet the needs. This can be a great cost saving, as needs are met first and foremost. See my post on [Pre Assignment Questions for Startups ](https://www.annemariecharrett.com/pre-software-testing-checklist-for-startups/)for the types of questions a freelance software tester should ask. ## Freelance software testers are flexible in approach A good freelance software tester understands the three key demands placed on any software project, namely, cost, time and quality. They have the liberty to be flexible in approach to testing in order to balance quality against its natural enemies; time and cost. If time is an issue, a freelance tester is able to prioritise the testing to ensure key functionality is tested. Budgets can be effectively managed by using ‘on-demand’ testing and fast-tracking planning where possible. ## Freelance software testers need to you succeed Like any other freelancer, reputation is paramount. A freelance software tester’s reputation is built on getting excellent customer referrals. They don’t rely on big marketing budgets or a platoon of sales people for their next job. They need their client to succeed and be profitable. That way, not only does word spread, but they get repeat business. It’s in our interest to ensure that you have the best quality product to sell. Of course many of the attributes I have described in this article can be found in software testers everywhere. However, a freelancer has the added advantage of passing these cost savings on directly to the client, without the commitment of long term contracts. *The full ITnews article can be found at http://www.itnews.com.au/News/59326,opinion-startup-fundamentals.aspx* ### How to kickstart a freelance software testing project URL: https://www.annemariecharrett.com/how-to-kickstart-a-freelance-software-testing-project/ Last updated: 2021-06-18T05:51:38.000Z Starting a freelance software testing project is similar in many ways to any other project. It requires rigorous planning, well thought out tests, and excellent communication. As a freelancer however, you may feel more responsible in making sure that your client is happy with your work. This way, you have a better chance of getting more work from them. ## Think first then ask Before you start anything, you want to clarify with your client as much as possible. This means you can provide them the biggest return for their money. Clarify: - Why did they hire you? What do they expect to get out of this piece of work? A report to take to customers?, confidence their application? Information about their application? - Your test approach Provide guidance here. Give a basic approach on how you intend to test the application. Then get some feedback on it. - Application Get as much information on the application they want you to test. - test environment Ask who will be responsible for the test environment (They may be expecting you to own it). If the client is to maintain the environment, what access will be provided to you? - the test scope Never assume the type of testing your client wants. Spell out what you intend to test. A spreadsheet is good for this. Briefly list the areas you think require testing and send this to your client. - Test Tools Ask your client if they use any test tools? If not suggest the ones you are most comfortable with. - reporting Give the client some idea of how and what you will be reporting. Is a weekly email sufficient or do they want daily communication. This will have an impact on the cost of the work involved. - schedule Do they have a schedule or time frame in mind when this testing has to be completed? If the time frame is fixed, this may be the deciding factor in how much testing you can do - budget Talk to the customer about money. Be upfront about payment conditions, when you expect to be paid and how. I like to base my quote following most of this information exchange. Its an upfront cost I wear as I like to provide accurate quotes to my client that are tailored to meet their needs and provide greatest benefit to them. Your quote can be fixed price or time and materials. Fixed price is great when the effort is quantifiable. Otherwise you can go for time and materials. This can be an hourly or daily rate. Deciding on your rate is tricky and will require you to do some investigating. If you have a friendly recruitment agent, they may be able to provide you with some pointers. If you really have no idea how much be upfront with your client and ask them what their budget is and then work out what you can provide for that. Once you have agreed on the scope of work, the schedule, the cost put it in writing. Include risks and assumptions such as; Assumptions - You will receive the application on time - You will be paid thirty days after completion - Completion of the project is delivery of a final report - No retesting is involved in the cost Risks - What happens if the project is abandoned, will you be paid for the work you do? - If the testing takes longer than you expected, how will this be managed? - What happens if requirements change halfway through testing? ## Be prepared…. Make sure you have everything you need to test. If you are testing remotely, do you have suitable bandwidth, hardware, software to support the testing required. Do this as early as possible, as it may take time to setup the test environment. Have a process for backing up your testing nightly. Be meticulous about this. I think it's unfair to ask a customer to pay for you to ‘learn as you go’. So, know the basics of software testing. Have templates ready for all stages of your testing, this will also help with your branding. Now all thats required is to start your test approach. Above all; - keep communicating with your client, - be upfront on any issues that arise - Be knowledgeable and provide guidance - Don’t forget to ask the customer their opinion. Good luck on your project *This blog is the result of an email requesting advice on starting a freelance software test job.* ### Reality bites URL: https://www.annemariecharrett.com/reality-bites/ Last updated: 2021-06-18T05:53:46.000Z Who doesn’t love the internet? As a small business owner of a software testing consultancy, its a great way to promote myself along side the bigger companies. However, I’m discovering the major minus side to promoting on the internet. That is, its too absorbing. I can’t resist reading those cursed google stats every day. I check how many people read my blog and from which country they are. Then, I recently re-discovered that the best way to promote myself is to meet people…..in the flesh, face to face… you know, where you shake hands and make eye contact. They weren’t virtual people in second life, but real ones that you can touch, have a drink with. I went to a networking event recently and got more contacts in two hours, then my weeks of stressing over web visitor numbers. A side bonus was the encouragement I received which renewed my determination in making my business succeed. So here’s my new resolution. Shut down the computer, walk out of my office and starting talking to people. Who knows where or what it will lead me to? ### Take the Test... URL: https://www.annemariecharrett.com/take-the-test/ Last updated: 2021-06-17T02:10:02.000Z Want to review your software testing process? Here are some guidelines that I use to review a company’s test process. ## Stakeholder support Before examining software testing in detail, assess your financial and managerial support. Any good review exposes shortcomings and to act on these changes will require good managerial and financial support. One way of getting the support you need is to present a business case outlining the benefits software testing brings to your business. Software testing because its ‘good process’ is insufficient justification. An accurate and persuasive business case from a business perspective is required. Common software testing benefits to business are: - Confidence in the software’s ability to behave as expected - Confidence in the system’s robustness - Risk Mitigation - Tangible knowledge on the systems performance - Overall cost reduction in the software delivery lifecycle - Increased customer satisfaction Align these benefits with any company mission statement and it will re-enforce your case. ## Software testing process A software test process delivers reproducibility of results, repeatability of tests and the consistency across multiple projects. A software test process is the cornerstone for many testing teams. Review the effectiveness of your software testing process to determine if improvements can be made. Here are some ways in which you can review your test process; ● Perform test process reviews on completed projects. Create a questionnaire on the software testing process used and ask developers, testers, managers and if possible your customers to provide some feedback and suggestions on improvements. ● Review the test templates and examine how they where used. Discuss the templates with testers to discover ways to improve the templates. If your software testing process is informal, discussions with developers, business and managers will help identify and formalise what is perhaps an informal and ad-hoc activity. ## Skill and resources Consider what resources you have available to perform your testing. Dedicated resources have the advantage for the following reasons; ● they can focus full time on testing, reducing the test execution time compared to a resource who is performing both testing and business as usual activities ● A dedicated resource has more experience in scoping out the test effort. They are familiar with the pit holes and understand the need for proper planning and setup. ● A dedicated resource provides an independent and impartial view, taken from a user’s perspective. This often helps find critical defects before the user does. Dedicated resources may initially seem as an additional cost but they improve the effectiveness of testing and reduce delays in testing caused by lack of resources or inefficient planning. If testers are included in your resources, examine their skill set and determine ways to improve their knowledge of testing. For example, look at training courses or training on testing tools. ## Testing Tools Testing tools are an excellent way to facilitate reproducibility, repeatability consistency and uniformity. The catch is that to reap the benefits, they require total team participation and be kept up to date. Automated test tools improve efficiency and reduce time though do not necessarily reduce the resource effort. This is because automated test scripts like any software requires maintenance. Testing tools need to be assessed with your testing requirements in mind, so careful thought is required before purchasing any tool like this. Typical types of testing tools that are available are; ● defect tracking tools ● automation tools ● performance loading tools ● test script repository An essential testing tool is the defect tracking tool. Defects are the key method of communication between developer, tester, manager and customer. Also, a central repository that holds all defects are their status facilitates the sharing of this knowledge. A test script repository is helpful for tracking the test effort and the results as well as centralising where test scripts are kept. ## Collaboration Testing affects developers, business, support and infrastructure and naturally testers themselves so it’s essential to examine ways to improve testing collaboration. Review how communication is performing throughout your software testing process. Effective methods of communication are daily or weekly meetings, defect reviews, documentation such as reports and emails, though not too many! One method to improve collaboration is to get all parties involved in improving the software testing process. Their input and feedback on the software testing process will help make the process relevant to them and so increase the chance of testing success. ## Test environment Look at your test environment and review it for the following; **Security** Check how much control testing has over the test environment. Test results can be compromised if the test environment is open to all and it’s possible to make code or configuration changes without a tester’s knowledge. **Suitability** Having your testing environment mimic as closely as possible the end user or production environment increases the confidence that the software will behave as expected. **Planning** Some of the major delays in testing are caused by initial setup problems in the test environment. Good planning reduces the risk of something going wrong. Review how you plan your test environment and ensure that the test environment is ready when you’re ready to start testing. In conclusion, a software testing process is only useful if it’s in use. If you do require changes, make sure their relevant to your business. ### The pure joy of innovation... URL: https://www.annemariecharrett.com/the-pure-joy-of-innovation/ Last updated: 2021-06-17T00:12:51.000Z I went along to a networking event last night, run by the Innovic – http://www.innovic.com.au/home/ in Melbourne. A great event and that wasn’t just the cocktails! I got the opportunity to meet interesting people involved in all aspects of innovation in Melbourne. I think every once in a while its good to get your head out of your own space and realise that there are some exceptionally creative and clever people out there. It reminds me why I provide software testing services to such a small and not so lucrative area of the market . I get the opportunity to work with people who design, incubate and serve great designers and developers. Its inspiring to meet people so passionate about what they do. I think software testers can provide real benefit to startup companies by providing that all essential third party independent perspective before it gets to the first customer. After all, first impressions count for an awful lot these days. It was also interesting the note the power of personal contact. Sometimes I get so caught up with online promotion, I forget that talking and communicating one on one can be more effective than endless hours of online promotion, and its a lot more fun. Try shutting down the computer now and then and meet up with some like minded individuals. Who knows what you may get out of it…. So, why do you software test? ### How low do you go? URL: https://www.annemariecharrett.com/how-low-do-you-go/ Last updated: 2021-06-26T13:26:18.000Z A survey\* sponsored by the Australian Computer Society, found the following percentage allocation for software testing: **5%** allocate more than 40% of the initial development budget to testing **25%** allocate between 10 -19% of the initial development budget to testing **25%** allocate between 20 – 29% of the initial development budget to testing **14%** allocate between 30 – 39% of the initial development budget to testing **12%** allocate less than 10% of the initial development budget to testing I’ll leave you to make up your own mind about these stats. \* *A preliminary survey on software testing practices in Australia by S.P Ng, T. Murnane, K. Reed, D. Grant and T.Y Chen* ### Sustainable software testing URL: https://www.annemariecharrett.com/sustainable-software-testing/ Last updated: 2021-06-16T23:32:21.000Z Its time to expand our traditional view of a software testing scope and to start including the word sustainability into software testing. Up to this point, areas of focus have been functionality, performance, maintainability, security, usability etc. As customers become energy conscious, a focus on sustainability will become more important. Some ‘sustainable’ test heuristics could be: Sustainability: *how energy efficient is the application under development*? Peripherals: *how well does the application perform using energy efficient peripherals* Monitor:*Does the application function properly under “minimal power configuration”* Switching Off: *How well does the application function when peripherals are switched off* Virtualization*: How well does the software function in a virtual environment* Printing: *What alternatives does the application provide to printing (e.g PDF )* ### Getting ROI from your freelance software tester URL: https://www.annemariecharrett.com/getting-roi-from-your-freelance-software-tester/ Last updated: 2021-06-18T05:48:58.000Z Development houses have a right to expect a lot from a freelance tester. Firstly, without the endless budget of some larger companies, they can ill afford time and money caused by improper scoping and testing. Secondly, they have recognised the advantage of having an independent review of the product and that in its own right deserves to be appreciated. In order to get the best return on investment from their tester, communication of priorities and expectations must be passed onto the tester. With knowledge, testers can focus their effort on what developer priorities instead of what they suspect is their priorities. I’ve created a short questionnaire to clarify to developers what a tester needs. It contains some of these areas: 1) What do you as a developer value most? Consistency, Quality, Breadth of testing, 2) What specifically do you want tested in web testing? 3) What technology are you using? 4) What testing has already been performed? 5) Do you have any specs of any sort? 6) Is this new software, or updated software 7) What sort of feedback do you want? Defect reports, results? *Note: These questions have been created with web testing in mind, but can be changed for any type of testing* Here’s an example of what I use: ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/PreAssignmentChecklist.png) Having this information upfront helps everyone because: 1) There is an agreed understanding of the scope of testing 2) Quotes can be validated through the questionnaire 3) More upfront information maximises your return on investment allowing focus on customer driven testing 4) It provides an insight into the software testing process The above information is used to create tests in a spreadsheet which I use to track defects and results. Ping me for an example With this document you have the benefit of evidence of testing which can be useful for contractual purposes. It also assists in future upgrades, streamlining the next round of testing. Like what your read? Please feel free to use the ideas I have here. Do us a favour though, leave a comment, or digg the post. Thanks !! ### Software Test Templates - scoping out your tests URL: https://www.annemariecharrett.com/software-test-templates-scoping-out-your-tests/ Last updated: 2021-06-26T00:45:32.000Z I wrote a blog recently “[the value of a software testing process](https://annemariecharrett.com/the-value-of-a-software-testing-process/?ref=annemariecharrett.com)” in which I questioned the traditional benefits of software test scripts based on the re-use and repeatability theory. My approach to any rapid change software development is to make a some basic assumptions 1) The code is going to change quickly 2) The person who coded won’t necessarily be there for the next release 3) The person who tested the last time, won’t necessarily be there for the next release 4) Test documentation helps to provide structure and is excellent as a guide to ensure adequate coverage 5) Testers are able to think outside the square and aslo be able to fill in the gaps in a test I use one spreadsheet (if possible) to track the following information; a) test script number b) test link (if available which is a reference to requirements etc) c) test purpose – a clear concise description of what I am planning to test d) test results – Pass or Fail e) defect number – I assign a number of use the defect tracking system f) test estimate – the time I anticipate it will take to test this functionality I use the document to first scope out what I want to test, a quick and dirty overview of what I am planning. I also use it to estimate how long testing is going to take. This is helpful if I am ever asked to substantiate my estimates. Once all stakeholders are in agreement onto the scope, I create a concise and descriptive purpose of each test. This is in essence my test script. I use the same spreadsheet to enter results, defect numbers and to calculate simple metrics such as the pass rate. I have uploaded an example below; ![](https://storage.ghost.io/c/e2/0b/e20b1dc7-7596-416c-bbad-2be3126c3a68/content/images/2021/06/TESTSPEC-EXAMPLE-3.png) I hope you you find this post useful. Please feel free to use the ideas I have here. ### Benefits of Software Testing URL: https://www.annemariecharrett.com/benefits-of-sofware-testing/ Last updated: 2021-06-13T06:20:25.000Z **Looking at the benefits of software testing from a business perspective can be quite a challenge if your a blue-hat, IT type of person as I am. To sell testing effectively though, its helpful to view testing from the perspective of the person who ultimately gets to make the decisions.** So here goes! The way I see it, business is about Profit and Loss. I’ve split up business as follows ; 1) Business want make money through sales 2) Business want cost cutting to improve the profit margin ## Business want to sell things If business is about selling products or services, how in business terms can software testing help sell a product? I’ve come up with the following possibilities; 1) Software testing discovers if critical functionality works. This is helpful to know when your trying to sell something (I’m assuming!) 2) Software testing makes sure that your product doesn’t negatively affect interacting systems. I suspect this helps encourage repeat sales. 2) It provides tangible results which can be used to sell the product. For example, you can use your proven high performance as a selling point 3) It demonstrates delivery from a contractual perspective through acceptance testing 4) It gives confidence to those selling the product. There is added benefit in knowing the product your selling works. 5) Certification can provide business a selling point. If your system conforms to a technical standard, it may help your product to be perceived as reliable. ## Business want to save money How can testing help save a company money? 1) Early fault detection reduces the cost of fault detection. The earlier a defect is found, the less development rework and re-test is required, minimising its implementation cost. The Baziuk Study (1995) estimates the relative cost to repair a defect found in Operations to be between 470 – 880 times the amount found in the Requirements phase of the lifecycle\* 2)It delivers efficiencies in the software development process through metrics such as root cause analysis . These detect possible areas of improvement for software development. 3) Software testing is the source of information such as defect reports, metrics and results that assist IT perform their roles efficiently. Project managers rely on metrics to report on progress, operations, on tangible results to extrapolate future hardware requirements and developers on defect reports to fix their code. As is plainly obvious, I do not a heavy background in business, so I’d be most interested in comments from those who have! And testers, how have you helped your company save money through testing? \*National Institute of Standards and Technology, May 2002 ### Benefits of a software testing club URL: https://www.annemariecharrett.com/benefits-of-a-software-testing-club/ Last updated: 2021-06-10T18:14:48.000Z I’ve discovered Rosie Sherry’s excellent software testing club at [http://club.drivenqa.com/](https://ministryoftesting.com/?ref=annemariecharrett.com) Its great because you can setup your own local group and since I live in Australia I set up one for the ANZACS. I think we need a logo or picture though? Anyone any ideas? my two (aussie) cents for the day…. ### The value of a software testing process URL: https://www.annemariecharrett.com/the-value-of-a-software-testing-process/ Last updated: 2021-06-16T20:56:48.000Z Does a software testing process provide a best approach to testing? Coming from a background in engineering I have always been a firm believer in the benefits of a sold and dependable testing process which includes test planning, design, building, execution and reporting. So, how come I find it hard to convince others of its merits? After much soul searching, I’ve come down to the conclusion and it’s this. A rigid and formal testing process doesn’t work in many of today’s software projects. For example, some of the benefits of a software testing process are to provide re-usability and repeatability of results Re-use is cited as one of the benefits of a software testing process as it reduces long term cost both in resources and time. For example, test scripts once written can be used again in future releases reducing the upfront resources. But, in my experience, I’ve rarely used the same test script twice. This is because each time a new release is planned, its markedly different to the previous one. Add into the mix, new developers, new testers and soon the amount of flux necessitates re-starting the test planning, design and building from first principles. I question the value of re-use when it ends up costing similar or more in time and resources. Another benefit of a solid testing process is the repeatability of the results. Again though, if your code change is that significant, you will have to question the validity of the expected result. If resources are required to confirm or update the expected results, I’d have to argue time may be better spent in beginning again. This is especially true if the software tester is new to the project and requires analysis time to fully understand a product and its environment. In summary,I believe that where rapid change exists, you need an adaptable approach and is lighter on documentation In industries with little change there is much benefit to a repeatable, re-usable approach, but where rapid change exists, I think spending lots of energy on paper documents which in the end will only get used once is a waste of time and cost. Testing is essential, just that the process to perform testing must always be up for review and change too! my two (Aussie) cents for the day…. ### Kid in a sweet shop URL: https://www.annemariecharrett.com/kid-in-a-sweet-shop/ Last updated: 2021-06-21T21:29:37.000Z I have the dream job at the moment …. I think. I’ve been asked to create a testing methodology for a company that wants to implement a software testing processes. Fantastic! I thought to myself, just what I’ve always wanted to do. So I busily set about talking to people and finding out what they wanted and finally 3 months later we had this lovely document with templates which sits pride of place on my desk. And thats the problem, its about the only place where you can find it. I did a couple of things, like creating a test office(they don’t have a test team..yet) with representatives from each department. I also did some training with the test office and for each department on an individual basis. I then went away and left them to their own devices. Funnily enough, I got a call back 2 months later asking for more assistance! So I came back and found the following problems 1) Some people just don’t get it. Not everyone, but a large enough group don’t seem to understand the point and to them its just another bit of paperwork to get through (or not as seems to be the case). 2) They don’t seem to have time to implement it.One of the things I said at the start was that it was going to take more time to test in a structured way and to prepare for it, but the reality is that despite additional budgeting they still don’t seem to have the time to perform the necessary tasks such as test preperation. 3) They feel its just too much work to introduce testing concepts such as creating a test plan, test scripts and reporting, so they don’t do it. I haven’t had much success on the defect tracking front either (excel spread sheets) Its getting to the point where senior management are wanting results (no big surprise there!). So I feel a bit like a kid in a sweet shop with all these different things to work on but I’m not too sure where to start. This is what I have come up with: 1) Go to basics. Use minimum documentation (I’m thinking one spreadsheet) to take note of test script objectives, test log, defects and test report. Get them to use that and start taking some metrics down. This will demonstrate that a) there is some form of process working and b) the metrics may prove valuable in the future. 2) Get project managers to track actual effort against the project schedule to start tracking the test preparation, execution and reporting effort. 3) Go to the senior manager and ask him what he wants to get out of the process (what are his goals). Then work out the problems associated with the goals, work out some actions and try and benchmark against those goals. Thats about it so far, I’d value anyones comments on this one! my two (aussie) cents for the day…. ### The right people for the right job URL: https://www.annemariecharrett.com/the-right-people-for-the-right-job/ Last updated: 2021-06-16T21:07:25.000Z I want to share my ideas on software testing. Software testing is in my blood, which a lot of people are really happy about because then they don’t have to test or test as much anyhow. To be perfectly honest, thats how I like it. My soapbox topic this week to my client has been “make sure you use people who like testing software to perform any testing tasks”. I have seen clients trying to save money by getting business or support to perform testing. This ‘cost cutting’ exercise often results in low quality testing and delayed projects. Experience is required to understand what testing is trying to achieve. If you don’t get the concepts of a structured process its hard to be expected to pick up these skills immediately. Also, more often than not, every excuse as to why the job can’t be done is thrown at you, which ends up delaying the project. You wouldn’t normally ask a developer to system test, so why ask a production support person to? Get the right person for testing and you will save yourself and everyone else around you a lot of heartache and more money at the end to celebrate the success. my two (aussie) cents for the day….