Understanding Behavior-Driven Development in SQA Testing

Pytest vs Playwright vs Cypress

# test_google.py
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager
def test_google_title():
    driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()))
    driver.get("https://www.google.com")
    assert driver.title == "Google"
    driver.quit()
                    

// tests/google.spec.ts
import { test, expect } from '@playwright/test';
test('Google title test', async ({ page }) => {
  await page.goto('https://www.google.com');
  await expect(page).toHaveTitle('Google');
});
                    

// cypress/e2e/google.cy.js
describe('Google Title Test', () => {
  it('should have the correct title', () => {
    cy.visit('https://www.google.com');
    cy.title().should('eq', 'Google');
  });
});
                    

Generating and Testing QR Codes for Inventory Management in QA

Sample Sheet that I created. I used PhotoScape to combine the images and added the text below the QA Code.

#!/usr/bin/python3
import datetime
import qrcode
# List of QR Code data (product IDs)
qr_codes = [
    "22001185000-TV825862",
    "46002897000-AV301140",
    "46002897000-AV320052",
    "46003686000-TS062286",
    "46200239000-HRB3019056",
    "46039182000-HRC0994569",
    "22031593000-0hfg7ddw502291r",
    "46003251000-BA30816015",
    "46002566000-VT5575px;32991",
    "22010473000-zt600331",
    "46200240000-MLSVTXLHQ-7",
    "46200240000-HRC2167455",
    "46074803000-MM0O05JGX-0",
    "46074803000-HRB2539864",
    "46088955000-kc1008395"
]
# Function to generate and save QR codes
def generate_qr_codes(codes):
    for i, code in enumerate(codes):
        # Create QR code instance
        qr = qrcode.QRCode(
            version=1,
            error_correction=qrcode.constants.ERROR_CORRECT_L,
            box_size=10,
            border=4,
        )
        qr.add_data(code)
        qr.make(fit=True)
        # Create an image from the QR Code instance
        img = qr.make_image(fill='black', back_color='white')
        # Save the image to a file
        img.save(f"{code}.png")
# Generate and save QR codes
generate_qr_codes(qr_codes)

Managing a Remote QA Team

During my time leading a distributed QA team across the U.S. and India, I had the opportunity to work with a dedicated and talented group of engineers. While the collaboration across time zones was productive and often inspiring, it also revealed some key challenges — especially around maintaining consistent quality standards.

Great Team, But Growing Pains

The engineers I worked with overseas were skilled and enthusiastic, always delivering on their assigned tasks. However, I noticed a pattern — they sometimes became complacent with their testing. The definition of “done” didn’t always include deep scrutiny or thinking beyond pass/fail criteria.

One Bug That Changed Everything

There was a particular moment that crystallized the issue for me. I discovered a bug where a critical button wasn't visible in smaller-resolution browsers. When I brought it up, the team admitted they had seen it — but chose not to report it because, in their words, “it wasn’t breaking anything.”

That moment shifted our entire approach. I reminded the team that just because something isn’t technically broken, doesn’t mean it isn’t a problem. If users can’t see a button, they won’t click it — and that’s a functional failure, not just a UI glitch.

Raising the QA Standard

In response, I introduced “UX flags” to our testing process and implemented #UXflags in Jira tickets. I began holding weekly bug retrospectives. We focused on thinking like the end user — questioning visual hierarchy, accessibility, and usability in every test run. Over time, I saw a major shift: the team became more proactive, caught edge cases independently, and started reporting issues from a user-first mindset.

Takeaway

Managing a remote QA team goes far beyond assigning tickets. It requires cultivating a culture where quality is everyone’s responsibility — not just checking boxes, but caring about the final product. That button bug may have seemed minor, but it taught us a major lesson: high-quality software comes from high-quality thinking.

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.