Unveiling the Hidden Gems of TestLink

As a seasoned QA engineer with over a decade of experience, I’ve relied on TestLink to manage manual regression testing for years. This web-based test management system is a powerhouse for organizing test cases, tracking execution, and generating insightful reports.

While TestLink’s core functionality is robust, its true potential shines when you tap into its lesser-known features. In this blog post, I’ll share some hidden gems from the TestLink 1.8 User Manual that can elevate your testing game, drawing from my hands-on experience and the manual’s insights.

Why These Features Matter

TestLink is a fantastic tool for manual regression testing, but mastering its hidden features unlocks its full potential. Keyboard shortcuts and bulk assignments save time, custom fields and keywords provide flexibility, and advanced reporting aligns testing with business goals.

Tips for Getting Started

• Explore the Manual: Start with Test Specification (Page 9) and Import/Export (Page 41).
• Experiment Safely: Use a sandbox project before applying features in production.
• Engage the Community: Visit forums like www.teamst.org for updates.

By diving into these hidden features, you’ll transform TestLink from a reliable test case repository into a strategic asset for your QA process.

Have you discovered other TestLink tricks? Share them in the comments—I’d love to hear how you’re making the most of this versatile tool!

Note: All references are based on the TestLink 1.8 User Manual provided.

The Unsung Hero of MVP Success

When you hear "Minimum Viable Product" (MVP), you might picture a scrappy, bare-bones version of an app or tool - just enough to get it out the door and into users' hands. The idea is to test the waters, see if your concept has legs, and iterate based on real feedback. But here's the kicker: if your MVP doesn't work, you're not testing product-market fit - you're testing how much frustration your users can stomach before they hit "uninstall."

Enter Quality Assurance (QA), the unsung hero that can make or break your MVP's shot at success. In a recent episode of QA in a Box, host Chris Ryan and his CTO co-star unpack why QA isn't just a nice-to-have - it's a must-have, even for the leanest of MVPs. Let's dive into their insights and explore why rigorous QA could be the difference between a launch that soars and one that flops.

Four Tips for Writing Quality Test Cases for Manual Testing

Is Your QA Team Following Dogma or Karma?

As QA teams grow and evolve, they often find themselves at a crossroads: Are they focusing on rigid, dogmatic practices, or are they embracing a more fluid, karmic approach that adapts to the moment? Let's dive into this philosophical tug-of-war and explore what it means for your QA team - and your software.

Dogma: The Comfort of the Rulebook

Dogma in QA is the strict adherence to predefined processes, checklists, and methodologies, no matter the context. It's the "we've always done it this way" mindset. Think of the team that insists on running a full regression test suite for every minor bug fix, even when a targeted test would suffice. Or the insistence on manual testing for every feature because automation "can't be trusted."

There's a certain comfort in dogma. It provides structure, predictability, and a clear path forward. For new QA engineers, a dogmatic framework can be a lifeline - a set of rules to follow when the chaos of software development feels overwhelming. And in highly regulated industries like healthcare or finance, dogmatic adherence to standards can be a legal necessity.

But here's the catch: Dogma can calcify into inefficiency. When a team clings to outdated practices - like refusing to adopt modern tools because "the old way works" - they risk missing out on innovation. Worse, they might alienate developers and stakeholders who see the process as a bottleneck rather than a value-add. Dogma, unchecked, turns QA into a gatekeeper rather than a collaborator.

Karma: The Flow of Cause and Effect

On the flip side, a karmic approach to QA is all about adaptability and consequences. It's the belief that good testing practices today lead to better outcomes tomorrow - less technical debt, happier users, and a smoother development cycle. A karmic QA team doesn't blindly follow a script; they assess the situation, weigh the risks, and adjust their strategy accordingly.

Imagine a team facing a tight deadline. Instead of dogmatically running every test in the book, they prioritize high-risk areas based on code changes and user impact. Or consider a team that invests in automation not because it's trendy, but because they've seen how manual repetition burns out testers and delays releases. This is karma in action: thoughtful decisions that ripple outward in positive ways.

The beauty of a karmic approach is its flexibility. It embraces new tools, techniques, and feedback loops. It's less about "the process" and more about the result - delivering quality software that meets real-world needs. But there's a downside: Without some structure, karma can devolve into chaos. Teams might skip critical steps in the name of agility, only to face a flood of bugs post-release. Karma requires discipline and judgment, not just good intentions.

Striking the Balance

So, is your QA team following dogma or karma? The truth is, neither is inherently "right" or "wrong" - it's about finding the sweet spot between the two.

• Audit Your Dogma: Take a hard look at your current processes. Are there sacred cows that no one's questioned in years? Maybe that 50-page test plan made sense for a legacy system but not for your new microservices architecture. Challenge the status quo and ditch what doesn't serve the goal of quality.
• Embrace Karmic Wisdom: Encourage your team to think critically about cause and effect. If a process feels like busywork, ask: What's the payoff? If a new tool could save hours, why not try it? Build a culture where decisions are tied to outcomes, not just tradition.
• Blend the Best of Both: Use dogma as a foundation - standardized bug reporting, compliance checks, or a core set of tests that never get skipped. Then layer on karmic flexibility - tailoring efforts to the project's unique risks and timelines.

A Real-World Example

I heard of a QA team that swore by their exhaustive manual test suite. Every release, they'd spend two weeks clicking through the UI, even for tiny updates. Dogma ruled. Then a new lead joined, pushing for automation in high-traffic areas. The team resisted - until they saw the karma: faster releases, fewer late-night bug hunts, less late night testing, and happier devs. They didn't abandon manual testing entirely; they just redirected it where human intuition mattered most. The result? A hybrid approach that delivered quality without the grind.

The QA Crossroads

Your QA team's philosophy shapes more than just your testing - it influences your entire product lifecycle. Dogma offers stability but can stifle progress. Karma promises agility but demands discernment. The best teams don't pick a side; they dance between the two, guided by one question: Does this help us build better software? So, take a moment to reflect. Is your QA team stuck in the past, or are they sowing seeds for a better future? The answer might just determine whether your next release is a triumph - or a lesson in what could've been.

Overcoming Failures in Playwright Automation

Life, much like a marathon, is a test of endurance, grit, and the ability to push through setbacks. In the world of software testing, Playwright automation has become my long-distance race of choice - a powerful tool for running browser-based tests with speed and precision. But as any runner will tell you, even the most prestigious marathons come with stumbles, falls, and moments where you question if you'll make it to the finish line. This is a story about my journey with Playwright, the failures I encountered, and how I turned those missteps into victories.

The Starting Line: High Hopes, Hidden Hurdles

When I first adopted Playwright for automating end-to-end tests, I was thrilled by its promise: cross-browser support, and fast execution. My goal was to automate a critical path for an e-commerce website. The script seemed straightforward, and I hit "run" with the confidence of a marathoner at mile one.

Then came the first failure: a weird timeout error. The test couldn't locate the "Add to Cart" button that I knew was on the page. I double-checked the selector - .btn-submit - and it looked fine. Yet Playwright disagreed, leaving me staring at a red error log instead of a triumphant green pass. It was my first taste of defeat, and it stung.

Mile 5: The Flaky Test Trap

Determined to push forward, I dug into the issue. The button was dynamically loaded via JavaScript, and Playwright's default timeout wasn't long enough. I adjusted the script with a waitForSelector call and increased the timeout. Success - at least for a moment. The test passed once, then failed again on the next run. Flakiness had entered the race.

Flaky tests are the headace of automation: small at first, but they'll increase in size you if ignored them. I realized the page's load time varied depending on network conditions, and my hardcoded timeout was a Band-Aid, not a fix. Frustration set in. Was Playwright the problem, or was I missing something fundamental?

Mile 13: Hitting the Wall

The failures piled up. A test that worked in Chrome crashed in Firefox because of a browser-specific rendering quirk. Screenshots showed elements misaligned in Webkit, breaking my locators. And then there was the headless mode debacle - tests that ran perfectly in headed mode failed silently when I switched to testing in CI. I'd hit the marathon "wall," where every step felt heavier than the last.

I considered giving up on Playwright entirely. Maybe Pytest, Selenium or Cypress would be easier. (Even Ghost Inspector looked good!) But just like a champion marathoner doesn't quit during the race, I decided to rethink my approach instead of abandoning it.

The Turnaround: Learning from the Stumbles

The breakthrough came when I stopped blaming the tool and started examining my strategy. Playwright wasn't failing me - I was failing to use it effectively. Here's how I turned things around:

1. Smarter Waiting: Instead of relying on static timeouts, I used Playwright's waitForLoadState method to ensure the page was fully interactive before proceeding. This eliminated flakiness caused by dynamic content. (Huge Win!)

    await page.waitForLoadState('networkidle');
    await page.click('.btn-submit');

2. Robust Selectors: I switched from fragile class-based selectors to data attributes (e.g., [data-test-id="submit"]), which developers added at my request. This made tests more resilient across browsers and layouts.
3. Debugging Like a Pro: I leaned on Playwright's built-in tools - screenshots, traces, and the headed mode - to diagnose issues. Running npx playwright test --headed became my go-to for spotting visual bugs.
4. CI Optimization: For headless failures, I added verbose logging and ensured my CI environment matched my local setup (same Node.js version, same dependencies). Playwright's retry option also helped smooth out intermittent network hiccups.

Crossing the Finish Line

With these adjustments, my tests stabilized. The login flow passed consistently across Chrome, Firefox, and Safari. The critical path testing hummed along, and the user login - a notorious failure point - became a reliable win. I even added a celebratory console.log("Victory!") to the end of the suite, because every marathon deserves a cheer at the finish. (Cool little Easter Egg!)

The failures didn't disappear entirely - automation is a living process, after all - but they became manageable. Each stumble taught me something new about Playwright's quirks, my app's behavior, and my own habits as a tester. Like a marathoner who learns to pace themselves, I found my rhythm.

The Medal: Resilience and Results

Looking back, those early failures weren't losses - they were mile markers on the road to learning Playwright capabilities. Playwright didn't just help me automate tests; it taught me resilience, problem-solving, and the value of persistence. Today, my test suite runs like a well-trained runner: steady, strong, and ready for the next race.

So, to anyone struggling with automation failures - whether in Playwright or elsewhere - keep going. The finish line isn't about avoiding falls; it's about getting back up and crossing it anyway. That's the true marathon memory worth keeping.

ISO 14971 Risk Management

In the world of medical device development, risk management is not just a regulatory requirement - it's a critical component of ensuring patient safety. ISO 14971, the international standard for risk management in medical devices, provides a structured approach to identifying, evaluating, and controlling risks throughout the product lifecycle. While traditionally applied to hardware, this standard is equally essential in Software Quality Assurance (SQA), especially as medical devices become increasingly software-driven.

In this blog post, we'll explore the key principles of ISO 14971, how it applies to software development, and why integrating risk management into SQA is crucial for compliance and safety.

Understanding ISO 14971 in Medical Device Development

ISO 14971 provides a systematic framework for manufacturers to identify hazards, estimate risks, implement risk control measures, and monitor residual risks throughout the medical device lifecycle. The standard is recognized by regulatory bodies like the FDA (U.S.) and MDR (EU) as the primary guideline for medical device risk management.

The core steps of ISO 14971 include:

1. Risk Analysis - Identifying potential hazards associated with the device (including software).
   
2. Risk Evaluation - Assessing the severity and probability of each identified risk.
   
3. Risk Control - Implementing measures to reduce risks to an acceptable level.
   
4. Residual Risk Assessment - Evaluating the remaining risks after controls are applied.
   
5. Risk-Benefit Analysis - Determining if the device's benefits outweigh the residual risks.
   
6. Production & Post-Market Monitoring - Continuously assessing risks after product deployment.

Since software plays an increasingly vital role in medical devices, ISO 14971 explicitly requires manufacturers to evaluate software-related risks, making it an essential part of Software Quality Assurance (SQA).

How ISO 14971 Relates to Software Quality Assurance

Software Quality Assurance (SQA) focuses on ensuring that medical device software meets regulatory and safety standards while minimizing errors and failures. Because software failures can directly impact patient safety, ISO 14971's risk-based approach is crucial in SQA.

Key Ways ISO 14971 Supports SQA in Medical Devices

1. Identifying Software-Related Risks

Software in medical devices can present unique risks, including:
- Incorrect data processing leading to wrong diagnoses or treatments
- Software crashes that disable critical functions
- Cybersecurity vulnerabilities leading to data breaches or device manipulation

Using ISO 14971's risk assessment methods, SQA teams can identify these hazards early in development.

2. Integrating Risk-Based Testing in SQA

ISO 14971 emphasizes risk reduction, which aligns with risk-based testing (RBT) in SQA. Instead of treating all software components equally, RBT prioritizes high-risk areas (e.g., critical safety functions) for more rigorous testing.

For example, a software bug in an infusion pump that miscalculates dosage could have life-threatening consequences, requiring extensive validation and verification.

3. Risk Control Measures in Software Development

ISO 14971 recommends implementing risk control measures, which in software development may include:
- Fail-safe mechanisms (e.g., automatic shutdown on error detection)
- Redundancy (e.g., backup systems for critical functions)
- User alerts and warnings (e.g., error messages guiding corrective actions)

4. Regulatory Compliance & Documentation

Regulatory agencies require comprehensive documentation to prove compliance with ISO 14971. For software, this includes:
- Software Hazard Analysis Reports
- Traceability Matrices (linking risks to design & testing)
- Verification & Validation (V&V) Evidence

SQA teams must ensure every risk-related software decision is documented, making audits and approvals smoother.

5. Post-Market Software Risk Management

Software risks don't end at release - ISO 14971 mandates continuous monitoring. SQA teams must establish:
- Bug tracking & risk assessment updates
- Incident reporting mechanisms
- Software patches & cybersecurity updates

By aligning with ISO 14971, software teams can proactively address risks throughout the product's lifecycle, reducing regulatory and safety concerns.

Final Thoughts: ISO 14971 and the Future of Software Quality Assurance

As medical devices become more software-dependent, ISO 14971's risk management framework is essential for ensuring software safety and reliability. By integrating risk-based testing, robust control measures, and continuous monitoring, SQA teams can align with international regulations and safeguard patient health.

For medical device manufacturers, embracing ISO 14971 in software quality assurance isn't just about compliance - it's about building safer, more reliable medical technologies.

The Boston Massacre & Software Quality Assurance

History is full of moments where a lack of communication led to disaster. One of the most infamous? The Boston Massacre of 1770, where a chaotic mix of confusion, fear, and misinterpretation led British soldiers to open fire on a crowd, killing five colonists. While this tragic event changed history, it also serves as a powerful analogy for software quality assurance (QA).

When communication breaks down, whether on the streets of colonial Boston or in a modern software project, the result is chaos. In this post, we'll explore the eerie parallels between the Boston Massacre and software failures caused by poor QA practices - and how you can avoid your own "Massacre Moment."

Miscommunication: The Spark That Lights the Fire

The Boston Massacre began with confusion. Tensions were high between British soldiers and the colonists. A lone sentry was confronted by an angry crowd. Reinforcements arrived, but in the mayhem, someone yelled "Fire!" - whether it was an order or a frightened exclamation is still debated. The result? Gunfire erupted, lives were lost, and history was changed forever.

Now, imagine a software team working with unclear requirements. Developers assume one thing, testers prepare for another, and users expect something else entirely. The result? Bugs, broken features, and angry customers. The digital equivalent of firing into a crowd.

QA Lesson #1: Communicate like your app depends on it - because it does.

Clear requirements are your best defense against project chaos. Make sure expectations are documented, confirmed, and understood by everyone.

Structure Saves the Day

If there had been clearer protocols for handling civil unrest, the Boston Massacre might have been avoided. Similarly, a structured testing process prevents software projects from descending into confusion.

Without test plans, test cases, and well-documented testing strategies, teams rely on gut instinct - just like the soldiers did that night in Boston. That's no way to build stable software.

QA Lesson #2: Structure your QA process.

• Write test plans and strategies.
• Maintain a test case repository.
• Implement a clear defect tracking system.

Without structure, you're one miscommunication away from disaster.

Automation: A Powerful Tool - But Keep It Fresh

Think of test automation like the British Redcoats: powerful, structured, and disciplined. But without proper upkeep and adaptation, automation scripts can become outdated, missing key bugs just like a rigid formation fails in guerrilla warfare.

Just as soldiers had to adapt to colonial resistance tactics, testers must continually update automation scripts to account for new features, changing user behavior, and evolving tech stacks.

QA Lesson #3: Automate smartly, but don't snooze on it.

Automation is only as good as its maintenance. Review and refresh test scripts regularly.

Regression Testing: Your Time-Travel-Proof Safety Net

The aftermath of the Boston Massacre shaped the American Revolution. Its impact didn't end when the gunfire stopped - just as a single software bug can ripple through an entire system long after a release.

Regression testing is your historical safeguard against repeating past mistakes. Just as historians analyze past events to prevent future conflicts, QA teams must re-run critical tests to ensure that today's fixes don't introduce yesterday's bugs.

QA Lesson #4: Regression testing is your insurance policy.

• Run automated regression tests with every deployment.
• Maintain a historical log of major defects to prevent reoccurrences.
• Test like a historian - know what went wrong before to prevent history from repeating itself.

Final Thoughts: Don't Let History Repeat Itself

The Boston Massacre teaches us a critical lesson: miscommunication has consequences - whether in battle or in software. QA isn't just about catching bugs; it's about preventing confusion, ensuring structure, and maintaining order in the software development lifecycle.

So before your project descends into a colonial-style brawl, take a lesson from history: communicate clearly, structure your testing, maintain automation, and never skip regression testing.

Because if you don't, your next release might just be a historical disaster.

DummyAPI.io

I'm always on the lookout for ways to sharpen my automation skills and make testing more efficient and reliable. Recently, I came across DummyAPI.io - and it's a game-changer for API testing and automation practice!

This free mock API service provides realistic data (users, posts, comments, and more), making it an excellent resource for honing REST API testing skills. Whether you're using Playwright, Postman, or Python Pytest's requests library, this API lets you:

• Practice API validation with real-world-like endpoints
• Simulate CRUD operations for automation testing
• Refine Playwright's APIRequestContext for fast, reliable tests
• Debug and optimize API workflows before hitting production

For those QA Engineers diving deeper into API automation with Playwright, DummyAPI.io is a great sandbox to experiment with mock responses, authentication, and error handling - without worrying about backend infrastructure.

https://dummyapi.io/

A Hardware Store Horror Story with Life Lessons

Sometimes, the simplest errands turn into unexpected adventures - and not the fun kind. A recent trip to Lowe's for a case of road salt taught me more about patience, business ethics, and quality than I ever expected from a hardware store run. What started as a quick grab-and-go spiraled into a frustrating saga I've dubbed The Road Salt Rumble. Here's how it went down - and what it taught me about life, work, and the pursuit of quality.

Round 1: The Barcode Betrayal

Picture this: It's a chilly winter day, and I'm at Lowe's self-checkout. I've got my case of road salt, barcode in sight, ready to scan and roll out. I swipe it across the scanner - beep-beep - and… error. No big deal, right? I try again - beep-beep - error again.

Cue the self-checkout overseer, swooping in with a look that says, "Rookie." He informs me, "Oh, you have to scan each container inside the case." Excuse me? The case has a barcode plastered on it - why doesn't it work? Why am I suddenly doing inventory for Lowe's at their self-checkout? I'm annoyed, but I nod. Fine. Let's do this.

Round 2: The Salt Spill Showdown

The employee grabs his box cutter, slices open the case like he's auditioning for an action movie, and pulls out a container. Then - whoosh - salt spills all over the floor. A gritty avalanche right there in aisle 12.

Now, if you accidentally break something that belongs to someone else, what's the decent thing to do? Maybe a quick "Oops, my bad!" or "Let me grab you a new one"? Not this guy. He glances at the mess, then at me, like I'm the one who should mop it up. No apology. No accountability. Just silence.

I could've let it slide, but I wasn't about to haul home a busted container. So, I trek back to the shelf, grab a fresh one, and head back to the scanner. The salt's still on the floor, by the way - foreshadowing the chaos to come.

Round 3: The Price Tag Plot Twist

When I return, the employee has scanned everything without a word - no "Thanks for grabbing another" or "Sorry about the spill." Just a blank stare. Then I see the total on the screen, and my jaw hits the floor. It's way higher than it should be.

Here's the kicker: I thought I was buying a case of road salt at a bulk price. Nope. They charged me for each individual container, barcode or not. Was this a sneaky bait-and-switch? Why even put a barcode on the case if it doesn't mean anything? I paid, shook my head, and headed out, but not before glancing back at that open, spilled case. It was still sitting there, untouched. They didn't clean it up. Worse, I'd bet they'll slap it back on the shelf, shortchanged salt and all, for the next unsuspecting customer.

That was it for me. Lowe's lost a little piece of my loyalty that day.

Lessons from the Hardware Aisle

This wasn't just a retail rant - it was a crash course in quality that applies far beyond the store. Here's what I took away:

• Details Are Everything
  I assumed the case price was clear. It wasn't. The signage was vague (at least to me), and I paid the price—literally. In life or work, skipping the fine print can cost you. Whether you're testing software or buying salt, assumptions are a shortcut to disaster. Double-check the details, or you'll miss the bug—or the markup.
• Own Your Messes
  That employee spilled my salt and acted like it was my problem. No accountability, no care. It's a small thing, but it sends a big message: "We're here to move product, not serve you." In any field—QA, business, or just being a decent human—when you mess up, own it. Fix it. Ignoring a spill doesn't make it disappear; it just trips up the next person.
• Trust Is Fragile
  I walked into Lowe's as a regular customer, happy to shop there. I left wondering if I'd ever go back. One sloppy experience can unravel years of goodwill. Whether you're selling hardware or software, trust is your currency. Make people feel valued, or they'll take their business—and their faith—somewhere else.

Quality Isn't Just a Checkbox

This whole fiasco reminded me of what I preach in QA: quality isn't optional. It's in the details you catch, the responsibility you take, and the trust you build. Lowe's fumbled all three, and it turned a mundane errand into a cautionary tale. But here's the upside: we don't have to follow their lead. Whether you're debugging code, designing a product, or just navigating life, you can choose to be the one who cares. The one who reads the fine print, cleans up the spill, and earns trust one small win at a time. Next time I need road salt, I might try a different store. But the lessons from this rumble? Those are sticking with me.

What do you think - ever had a store experience that taught you something unexpected? Let me know in the comments! And if you enjoyed this tale, share it with someone who could use a laugh - or a nudge to double-check the barcode.

The $10 Haircut Story

Today, we're diving into a classic debate that stretches across industries: Quality vs.Price.

Now, I know some of you out there love a good deal. Who doesn't? But today, I want to tell you a story about a barber, a $10 haircut, and what it truly means to provide value.

So grab a coffee, take a break from debugging that stubborn test case, and let's talk quality!

The Barber Story

Picture this: There's a barber in town. Let's call him Joe. Joe has been cutting hair for years in his cozy little shop. His customers love him - not just because he gives great haircuts, but because of the experience. The warm conversation, the attention to detail, the sense of community. His window proudly displays his price:

Haircuts, $20.

One day, Joe walks up to his shop and notices something new across the street. A flashy new barber shop has opened, and their sign reads:

Haircuts, $10.

Ten bucks?! Half the price? Joe watches as people who normally would have come to him start heading across the street. The place is loud, the vibe is fast-paced, and people are rushing in like it's Black Friday at a department store.

But here's where it gets interesting

After a while, Joe notices something. Customers are walking out of that shop looking less than thrilled. Some glance at their reflections in passing windows with a look of regret.

Joe ponders his next move. Does he drop his prices? Does he start blasting EDM music and offer speed cuts? Nope.

Instead, the next day, Joe puts up a brand-new sign:

We Fix $10 Haircuts.

Brilliant. Instead of chasing price, Joe doubled down on value.

And just like that, his loyal customers - and some of those disappointed bargain-hunters - came back, knowing that quality, not price, is what matters most.

Quality vs.Price in QA

This story isn't just about haircuts - it's about quality versus price in everything, including software testing and QA.

How many times have you seen a company chase the cheapest option only to realize later that it cost them way more to fix the mistakes?

Let's break it down:

Cheap Testing:

• Rushed test cycles
• Lack of proper coverage
• Minimal documentation
• "Just ship it" mentality

Quality Testing:

• Thorough test plans
• In-depth validation
• Risk-based testing
• Long-term reliability

I can't tell you how many times I've seen teams get excited about a cheap or fast solution, only to end up paying for it in bug fixes, lost customers, and damage control later.

For example, the CTO selected a cheaper logging tool, and as a result, it lacked functionality other tools had, such as custom dashboards and the ability to link search queries to the current active log file - making it harder to diagnose issues efficiently.

These cost-cutting decisions often lead to: - Increased time spent troubleshooting - Higher maintenance costs - Poor customer experiences

Pay Now or Pay Later

The reality is simple: You can pay for quality upfront, or you can pay for it later - but you will pay for it.

Just like in the barber story, cutting corners might seem like a good idea at first, but in the end, you'll need someone to fix the $10 haircut (or in this case, the buggy, rushed software release).

So the next time someone asks, "Why does testing take so long?" or "Can we use a cheaper alternative?" - just remember Joe's sign: We Fix $10 Haircuts.

Choose quality. Always.