All Quality is Contextual

The late Tip O'Neill, former Speaker of the House, famously said, "All politics is local." This highlights the importance of understanding the unique needs and concerns of individual communities in politics. Similarly, in Quality Assurance (QA), we can say, "All quality is contextual."

This principle means that the effectiveness of QA processes, tests, and standards depends on the specific context of the project, application, or business needs. Just as local concerns shape political decisions, the unique environment and requirements of each product guide QA priorities and strategies.

What Does "All Quality is Contextual" Mean?

• Subjectivity of Quality: Quality is subjective and varies widely. A sturdy tool might be perfect for a construction worker, while a tech-savvy user might want a sleek, feature-rich device.
• Purpose and Function: The main function of a product determines its quality. A chef's knife for professional use is judged differently than one for home cooking.
• Cultural and Temporal Shifts: Quality standards change over time and across cultures. What was once top-notch craftsmanship might not meet today's standards.
• User Perspective: Individual needs and expectations shape how quality is perceived. One user might value a smartphone's battery life, while another prioritizes the latest camera technology.
• Economic Factors: Budget affects quality expectations. A durable, affordable product might be high quality for someone with limited resources, while someone with more money might seek premium features and aesthetics.
• Environment of Use: The intended environment impacts quality assessment. Outdoor gear built for rugged conditions is judged differently than gear for casual urban use.

Practical Implications for QA

• Tailored Testing Strategies: Develop QA strategies that address each project's specific needs and context.
• Risk-Based Testing: Focus testing on areas with the highest risk and potential impact based on the product's context.
• User-Centric Approach: Involve users throughout the QA process to ensure quality is assessed from their perspective.
• Contextual Documentation: Clearly document the context and assumptions behind QA decisions and test results.

By embracing "All quality is contextual," QA teams can move beyond generic checklists. They can create more effective, efficient, and valuable testing strategies that truly meet each project's unique needs.

The `document.designMode` Trick

In the ever-evolving landscape of web development, Quality Assurance (QA) professionals play a pivotal role in ensuring that applications not only function correctly but also provide a seamless user experience. While automated testing tools and frameworks are indispensable, sometimes the most effective solutions lie hidden within the very code we test. Today, we'll delve into a nifty JavaScript trick involving document.designMode and explore other cool techniques that every QA expert should have in their toolkit.

The Magic of document.designMode

What is document.designMode?

document.designMode is a property in JavaScript that allows developers to enable or disable the ability to edit the content of a webpage directly. By setting document.designMode = "on";, the entire document becomes editable, transforming static content into a live, modifiable interface.

How to Use It in Chrome DevTools

1. Open Chrome DevTools: Right-click on any webpage and select "Inspect" or press Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (macOS).

2. Navigate to the Console: Click on the "Console" tab within DevTools.

3. Enable Design Mode:

   document.designMode = "on";

4. Edit the Page: Once activated, you can click on any text on the page and modify it directly. This change is temporary and only exists in your current browser session.

Why is This Cool for QA?

• Quick Mockups: Simulate text changes to test how different content lengths or phrases affect the layout without altering the source code.
• UI/UX Testing: Instantly visualize how design tweaks impact user experience, aiding in rapid feedback cycles.
• Bug Reproduction: Easily manipulate page content to replicate issues reported by users, facilitating quicker diagnosis and resolution.

How Cool Is That?!

Absolutely! This simple trick can save QA professionals countless hours by allowing real-time editing and testing of web pages without diving into the codebase.

iPhone Announcement: 17 Years Later

Ah, 17 years ago, the world changed forever. Steve Jobs held up the original iPhone, and we all collectively gasped, cheered, and promptly Googled "What is multi-touch?" Fast forward to today, and iPhones have gone from sleek communication marvels to pocket-sized powerhouses that can run augmented reality, 4K video editing, and, if rumors are true, predict the weather better than your local meteorologist. But for those of us in the world of Quality Assurance, the journey has been just as transformative.

The Early Days of Mobile QA:

When the first iPhone launched, QA teams were navigating uncharted territory. Testing mobile apps was like herding cats - except the cats were hidden bugs, the app stores had no clear submission guidelines, and the devices were limited to a few screen sizes (remember when 3.5 inches was revolutionary?). QA engineers often had to physically borrow phones from their coworkers to test compatibility. Emulators? Primitive. Automation? Practically nonexistent.

Every test plan felt like a high-stakes scavenger hunt. Did the app crash when you received a call? What happened if your cat pawed the screen mid-game? These were the burning questions we faced.

The BrowserStack Era:

Fast-forward to today, and tools like BrowserStack have become indispensable. With the explosion of device types, screen sizes, and operating systems, it's no longer practical to have a drawer full of devices (though some QA engineers probably still do). BrowserStack lets you simulate tests on an array of devices and operating systems, saving you from the logistical nightmare of sourcing a Samsung Galaxy A51 running Android 11 at 2 a.m. because "It's crashing for that one user in Tokyo."

Thanks to platforms like this, QA has evolved from reactive testing to proactive strategizing. Now, we're not just asking, "Does it work?" but also, "Does it perform? Is it secure? Does it load fast enough to avoid a one-star review?"

Story Time: The iOS 18.2 Saga

Last year, I got a little overexcited about Apple's latest iOS update, 18.2. Who wouldn't be? Darker Dark Mode, emojis that blink - it was a QA engineer's playground. I updated my personal device the minute it dropped and casually decided to test our company's website.

Surprise! CSS files that once made our site look sharp were suddenly throwing tantrums. Buttons misaligned, fonts replaced with Comic Sans (okay, not really, but it felt like it). It turns out BrowserStack hadn't yet updated to support iOS 18.2, which meant we couldn't immediately validate fixes on their platform. Thankfully, my impulse to "tinker first, debug later" saved the day.

Moral of the story? Sometimes, being a little too eager to update your device can reveal surprises even the best tools haven't caught up to yet. It's also a reminder that human intuition and exploration remain irreplaceable in QA.

Innovations Driving Mobile QA Today:

Mobile QA has seen incredible advancements over the years:

• Automation Frameworks: Tools like Appium and XCUITest have made regression testing faster and more efficient.
• AI in QA: Artificial intelligence is starting to predict and identify potential issues before a human even clicks "Run Test."
• Performance Testing: Ensuring apps perform under all conditions, from slow networks to extreme battery saving modes.
• Accessibility Checks: QA teams are prioritizing inclusivity, ensuring apps work seamlessly for everyone, including users with disabilities.

Looking Ahead:

Seventeen years after the first iPhone, mobile QA has become more sophisticated, efficient, and yes, even fun. The tools we have today allow us to focus on improving user experience instead of just putting out fires. But as technology evolves, so do the challenges. Foldable phones, AR/VR integration, and who knows what else are just around the corner.

One thing is certain: as long as there are users, there will be bugs. And as long as there are bugs, there will be QA engineers ready to squash them - sometimes with the latest tools, sometimes with sheer determination, and occasionally with a trusty early iOS update.

So here's to the iPhone, the 17 years of innovation it's inspired, and to us - the QA warriors who make sure that innovation works as intended. Let's raise a virtual glass (or an iPhone) to many more years of evolving together!

The Top QA Insights of 2024

As the year draws to a close, it's the perfect time to reflect on some of the most impactful topics we explored on QA Tuesdays. This year, we delved into the challenges, strategies, and nuances of Quality Assurance, aiming to empower QA professionals to elevate their craft. Here are the four standout blog posts from 2024 that resonated with readers and sparked meaningful discussions.

1. Why You Shouldn't Use Excel as a Test Case Repository

Published February 6, 2024
Excel might be a familiar and quick option for managing test cases, but it has significant limitations when it comes to collaboration, version control, and scalability. This post highlighted the drawbacks of relying on Excel and explored alternatives like dedicated Test Management tools that streamline QA processes. If you're still using spreadsheets for test cases, this is a must-read.

2. Not All Bugs Are Worth Fixing: Why Some Are Left Behind

Published December 17, 2024
Not all bugs are created equal, and some just aren't worth the effort to fix - whether due to low risk, high effort, or minimal impact. This post explored the strategic decision-making process behind leaving certain bugs unresolved, offering practical insights into prioritization and resource management in QA.

3. Test Ideas in 5 Words or Less

Published August 13, 2024
This post challenged readers to simplify and focus their test ideas, capturing them in just five words. It was a fun yet practical exercise in creativity and clarity that demonstrated how constraints can fuel innovative thinking. The feedback from readers showed that this approach helped sharpen their testing strategies.

4. Heuristics in QA

Published January 30, 2024
QA is as much about intuition and experience as it is about processes. This post introduced readers to heuristics in QA - rules of thumb that guide exploratory testing and decision-making. From "Consistency Heuristic" to "Proximity Heuristic," we explored practical ways to apply these principles in day-to-day testing.

Looking Ahead to 2025

As we gear up for another year of QA Tuesdays, I'm excited to dive into new trends, challenges, and tools shaping the future of QA. Thank you for joining me on this journey to build better processes and create higher-quality software.

Which of these posts was your favorite? Is there a topic you'd love to see explored next year? Drop a comment or send me a message - I'd love to hear your thoughts!

Here's to another year of excellence in Quality Assurance!

Happy New Year!

New Podcast: QA in a Box

I'm thrilled to announce the launch of my podcast, "QA in a Box"!

This podcast is designed for QA professionals who are passionate about enhancing their skills, tackling complex testing scenarios, and staying inspired in their work. Each episode is packed with practical insights, actionable strategies, and real-world examples to help you navigate the evolving landscape of Quality Assurance.

What to Expect
Whether you're dealing with challenging testing situations or looking for ways to level up your QA game, "QA in a Box" is your go-to resource. Tune in to discover tips and tools that can make a real impact in your daily workflow.

Recent Episodes
"Five Answers QA Gives to Dev When Testing Changes"
Learn how to effectively communicate with Development teams and bridge the gap between QA and Dev. This episode is full of practical advice for fostering collaboration and ensuring seamless testing.

"Zero Downtime in QA"
Explore strategies for maintaining high-quality standards, even during downtime. This episode dives into optimizing processes when there's "nothing to test" and turning idle moments into opportunities for growth.

Get Involved
I'd love to hear your feedback and ideas for future topics. What QA challenges do you want me to address next? Let me know in the comments or reach out directly - I'm always looking for ways to make this podcast even more valuable for the QA community.

Listen Now
Find the podcast and join the conversation here: QA in a Box

Thank you for your support, and I look forward to embarking on this journey with you!

Not All Bugs Are Worth Fixing: Why Some Are Left Behind

As a Quality Assurance (QA) professional, you may have encountered the disheartening situation where bugs you identified and reported were ultimately left unfixed. It can feel like your hard work is undervalued or that you're failing to uphold the quality standards expected of you. But here's the truth: not all bugs are worth fixing.

This concept is not a failure of QA but rather a strategic decision that balances the cost of fixing a bug against the value it brings to the product or the user experience.

The Cost-Benefit Analysis of Bugs

When deciding whether to fix a bug, Product/Dev teams consider factors like:

• Severity: How significantly does the bug impact the user experience or functionality?
• Frequency: How often is the bug encountered by users?
• Cost to Fix: How much time and resources are required to resolve it?
• Risk of Fix: Could fixing the bug introduce new issues?
• Deadlines: Is there sufficient time to address the bug without delaying the release?

For example, a minor cosmetic issue on a low-traffic page might not be prioritized if the team is racing against a critical deadline. Fixing such a bug could consume resources better spent addressing more impactful issues.

Reporting Bugs Still Matters

Even if a bug is unlikely to be fixed, QA's role in identifying and reporting it is still critical. Reporting ensures:

1. Documentation: Bugs are logged and available for review later, potentially in a less time-sensitive release cycle.
2. Trend Analysis: Patterns of similar bugs could highlight a deeper issue in the codebase.
3. Awareness: Developers and stakeholders have visibility into the product's imperfections, enabling informed decision-making.

It's important to understand that the decision to leave a bug unfixed is often made by weighing business priorities and resource constraints. This doesn't diminish the value of your work as a QA.

Shifting the Perspective

QA teams can sometimes become frustrated when their bug reports are not acted upon. During my time leading QA discussions, I've found it's helpful to remind teams that:

• Your job is to find the bugs. Fixing them is a separate process driven by different priorities.
• You are protecting the customer. By finding bugs before customers do, you ensure a better experience even if every issue isn't resolved.
• Bugs are like insurance policies. Even when bugs aren't fixed, their documentation can serve as a reference in future discussions about code quality and prioritization.

Why It's OK for Some Bugs to Stay

It's perfectly OK for all bugs not to be fixed. Software development operates within constraints, and addressing every issue simply isn't feasible. But when QA does its job thoroughly, the team has all the information needed to make the best decisions for the product and the users.

At the end of the day, QA's mission is clear: find the bugs before customers do. Even the smallest bugs are worth reporting because their discovery reflects the thoroughness and dedication of your team.

So the next time a bug you reported is left behind, don't be discouraged. Celebrate the fact that you found it first. That alone is a win for quality.

PlayWright URL Scraping

While experimenting with Playwright this week, I put together a script that grabs all the URLs from a website and writes them to a file. Here's the code that I finally came up with:

test('Extract and save my URLs from cryan.com', async ({ page }) => {
  // Navigate to the target URL
  await page.goto('https://www.cryan.com');
  // Extract all  tags with href attributes
  const links = await page.$$eval('a[href]', (anchors) => anchors.map((a) => a.getAttribute('href')));
  // Remove any relative URLs or empty strings
  const filteredLinks = links.filter((link) => link?.startsWith('http') && link.trim() !== '');
  // Save the unique URLs to a file
  const uniqueLinks = [...new Set(filteredLinks)];
  await fs.promises.writeFile('/Users/cryan/Desktop/url.txt', uniqueLinks.join('n'), 'utf8');
  // Assertions to validate extracted URLs
  expect(uniqueLinks.length).toBeGreaterThan(0); // Assert at least one URL found
});

Five Answers QA Gives to Dev When Testing Changes

As QA testers, we play a pivotal role in ensuring that the software our developers create meets the highest standards of quality and functionality. During the testing phase, developers often approach us eagerly (or nervously) to ask, "Did it pass?" Over the years, I've found that our responses typically fall into five distinct categories. Each answer tells its own story about the state of the code?and what's next.

Here's a light-hearted but insightful look at the five answers QA gives to developers when we test changes:

1. "No, there are issues."

This is the classic QA response, and often the most dreaded. When we give this answer, it means we've encountered bugs or inconsistencies that need to be addressed before the code is ready.

Why we say it:
Our role is to be the gatekeeper of quality. We don't stop at saying "No"; we provide detailed feedback, logs, and replication steps so developers can tackle the issues efficiently.

What Devs Should Know:
A "No" from QA isn't a personal critique?it's an opportunity to refine and improve the product.

2. "Yes, but you'll have to wait until bugs are fixed."

This answer signals that the primary functionality works as expected, but there are secondary issues or edge cases that still need attention. While the fix might not be critical to the current release, it's worth addressing.

Why we say it:
We want to ensure you're aware of minor bugs that could grow into larger problems later. Testing is about more than checking boxes; it's about foresight.

What Devs Should Know:
This "Yes, but" approach keeps progress moving while acknowledging the need for future iteration.

3. "Yes, but not what you expected."

This one stings a bit for everyone involved. When we say this, the code works, but the outcome deviates from the intended functionality or doesn't align with user stories or design specs.

Why we say it:
Sometimes, code technically "works" but misses the mark in terms of business requirements or user experience. QA looks beyond the "happy path" to ensure the product aligns with the vision.

What Devs Should Know:
Think of this as a second chance to revisit the user story or refine the implementation. Collaboration between QA, Dev, and Product at this stage is key to success.

4. "Yes, and here's more!"

This is the QA equivalent of a standing ovation. Not only does the code pass testing, but we've also discovered unexpected benefits, optimizations, or overlooked strengths.

Why we say it:
We want to celebrate wins with you! Maybe the new feature performs better than anticipated, or we found ways to leverage it beyond the original scope.

What Devs Should Know:
Cherish these moments. They're proof that all your hard work is paying off?and QA noticed.

5. "Yes, I thought you'd never ask."

This answer is delivered with a mix of relief and satisfaction. It means the code is perfect?or as close as it gets. All scenarios passed, edge cases handled, and performance met expectations.

Why we say it:
This is our way of telling you: "Well done!" A flawless release is rare, but when it happens, it's a moment of pride for the whole team.

What Devs Should Know:
Take a bow, share the success, and let's prepare for the next challenge!

Final Thoughts

Each of these answers reflects a different facet of the QA/Dev relationship. While it's fun to categorize them, the reality is that our responses are a stepping stone for collaboration and improvement. At the end of the day, QA and Dev share the same goal: delivering exceptional software to users.

So, the next time you ask us, "Did it pass?"?brace yourself. Whatever our answer, you'll know it's backed by rigorous testing, an eye for quality, and a shared commitment to excellence.

Crafting the Perfect User Experience: The Disney World Approach to Holistic Testing

Imagine holistic testing like planning the ultimate Disney World experience!

Just as Disney meticulously designs every aspect of a magical day - from the moment you enter the park to the last firework - holistic testing looks at the entire user journey from start to finish.

Let's break it down with a Disney World analogy:

A holistic testing approach is like being a Disney Imagineer who doesn't just check if one ride works, but ensures the entire park experience is seamless. It's not just about making sure Space Mountain's track is safe, but also checking:

• Can guests easily find the ride?
• Is the queue management smooth?
• Are the signs clear?
• Do the special effects work?
• Is the ride accessible for guests with different abilities?
• How does the ride fit into the overall park experience?

In software, this means testing isn't just about checking if a button clicks, but understanding the entire user journey:

• Can users easily find what they need?
• Does the website work on all devices?
• Is the experience smooth from login to checkout?
• Are all features working together harmoniously?
• Can users with different abilities use the product?

Just like Disney creates a magical, interconnected experience where every detail matters, holistic testing ensures every part of a digital product works perfectly together, creating a smooth, enjoyable "ride" for users.

How QA Saved the Day: Navigating Risky Pre-Holiday Releases with Confidence

The week before Thanksgiving can be a challenging time in software development. Product leads are often eager to meet their monthly targets, pushing for feature releases even when the timing may not align with QA best practices. This case study recounts a real-world scenario where QA successfully navigated a difficult political landscape to delay the release of a high-risk feature.

The Situation

A product team was eager to push a feature update in the pre-Thanksgiving release. However, a critical issue emerged: the feature's code would not be ready by the established code freeze date. The Tech Lead assured the team they would perform a rigorous code review to ensure quality, but this promise came with a significant caveat: the Tech Lead would be unavailable for much of the Thanksgiving week.

This posed two major risks:

1. Customer Impact: If a unique issue arose, there would be limited support to troubleshoot and resolve it during the holiday week.
   
2. End-of-Month Reporting: Thanksgiving coincides with a busy reporting period for many customers. A failure in reporting functionality would disrupt critical business operations for users who rely on accurate, timely data.

The Decision

As QA, our role was not to simply test and approve code but to assess the broader implications of shipping an incomplete feature. We conducted a release risk assessment and outlined the risks of pushing the feature:

1. The incomplete code would likely introduce instability, given the reduced availability of team members to support post-release fixes.
   
2. The potential for reporting issues posed a reputational risk to the company.
   
3. Customers had no immediate expectation for the feature, reducing the urgency to release it.

Despite pressure from the Tech Lead and Product Leads, we escalated the concerns to the VP of Engineering.

The Outcome

The VP of Engineering supported QA's recommendation to delay merging the new feature. This decision ensured the following:

• The feature shipped in the post-Thanksgiving release, with ample time for thorough testing and code review.
  
• The delay had no measurable impact on the overall project schedule.
  
• Customers experienced no interruptions or issues during the Thanksgiving week.

The Tech Lead later acknowledged that delaying the release was the right call, given the complexity of the feature and the risks involved.

Key Takeaways

1. Use Risk Assessments to Advocate for Quality: Clearly articulate the risks of rushing a release, especially when they affect critical customer workflows or coincide with challenging timelines like holiday periods.

2. Balance Business and Technical Priorities: While Product Leads may push for releases to meet goals, it's essential to weigh those goals against the potential impact on customers and the company's reputation.

3. Escalate When Necessary: When a decision involves significant risk, involve leadership to ensure all perspectives are considered and that the final decision aligns with the company's values and priorities.

4. Delays Aren't Always Bad: In this case, the delayed feature had no negative impact on the project schedule or customer satisfaction. Taking the time to get it right paid off in the long run.

This case underscores the importance of QA's role as a gatekeeper, not just for software quality but for the overall success of the product and customer experience. By staying firm and focused on the bigger picture, QA can navigate even the trickiest political landscapes to ensure the best outcomes for all stakeholders.

Does your QA team have a plan for handling high-pressure release situations? Share your strategies or lessons learned in the comments!