mocker.spy

March 12, 2025 by cryan.com

Testing interactions with external services or complex internal functions can be tricky. You want to ensure your website behaves correctly without relying on the actual implementation, which might be slow, unreliable, or have side effects. That's where pytest-mock's spy comes in!

What is mocker.spy?

mocker.spy lets you wrap any callable (function, method, etc.) and record its calls. You can then assert how many times it was called, what arguments it received, and what values it returned. This is incredibly useful for verifying interactions without actually mocking the underlying implementation.

Why is it cool for website testing?

Imagine you have a website that:

• Logs user activity to an external analytics service.
• Sends emails for password resets.
• Interacts with a third-party API for data retrieval.

Instead of actually sending data to analytics, sending real emails, or hitting the live API, you can use mocker.spy to verify that these interactions occurred as expected.

A Practical Example: Tracking Analytics Events

Let's say your website has a function that logs user interactions to an analytics service:

# website/analytics.py
import requests
def track_event(user_id, event_name, event_data):
    try:
        requests.post("https://analytics.example.com/track", json={
            "user_id": user_id,
            "event_name": event_name,
            "event_data": event_data,
        })
    except requests.exceptions.RequestException as e:
        print(f"Error tracking event: {e}")
   

And your website's view function calls this:

# website/views.py
from website.analytics import track_event
def process_user_action(user_id, action_data):
    # ... process user action ...
    track_event(user_id, "user_action", action_data)
    # ... more logic ...

Here's how you can test it with mocker.spy:

# tests/test_views.py
from website.views import process_user_action
from website.analytics import track_event
def test_process_user_action_tracks_event(mocker):
    spy = mocker.spy(track_event)
    user_id = 123
    action_data = {"item_id": 456}
    process_user_action(user_id, action_data)
    spy.assert_called_once_with(user_id, "user_action", action_data)

By incorporating mocker.spy into your website testing strategy, you can create robust and reliable tests that give you confidence in your website's functionality. Happy testing!

ISO 14971 Risk Management

March 11, 2025 by cryan.com

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.

September 22, 2000 Commericals

March 10, 2025 by cryan.com

Assorted commercials from September 22, 2000 from my VHS collection

• Will & Grace - promotion before the third season starts on October 12, 2000.
• COVAD - What would you do with faster Internet?
• Power Mac G4 Cube - Announced in July 2000. This is one of the early commercials on network TV.
• IBM Thinkpad - What can't you say about the IBM Thinkpad?
• Schick Xtreme III - Featuring Andre Agassi
• KTVU FOX 2 - The Original 10o'clock News Promotion with Dennis Richmond
• Nissan XTerra - Going off road is easy on the Nissan Xterra
• Ortega Skillet Fajitas - Easy way to make Fajitas.
• Toyota Tacoma - Featuring Steve Young going camping with pizza delivery guy.
• Levi's 569 - Loose Straight Jeans
• Verizon Wireless - Launching a new wireless company - started on April 4, 2000.
• Homedepot - featuring the Delta Faucets
• Gateway Computers - People have rights.

Surviving a Dance Competition at the DCU Center

March 9, 2025 by cryan.com

This past weekend, the 2025 competition season kicked off at the DCU Center in Worcester, Massachusetts. If there's one thing I've learned from years of attending dance competitions, it's that preparation is everything - from snagging the best seats to knowing where to find snacks after a long day. Here are some key takeaways from the weekend.

Food Rules? More Like Suggestions.

The DCU Center has a strict no outside food or drinks policy - likely to boost vendor sales. But at $6.25 for a bottle of water, you can't blame people for sneaking in their own supplies. While staff were stationed at the doors, they weren't checking bags, so dancers (wisely) packed their own snacks. The real impact of this rule? It mainly prevented outside food delivery.

Pro tip: Bring snacks for the ride home - you'll thank yourself later when exhaustion hits and everything is closed.

The Best Seats Came With an Unexpected Obstacle

Arriving early paid off, and we grabbed front-row seats. A massive photographer's stand plopped right in the middle of the first three rows. Not ideal for spectators hoping for an unobstructed view, but hey, at least the pictures probably turned out great. Getting early helps get the best spot. IF your dancers dance later in the day, simply arrive early so that you can slowly move up front.

Let There Be Light? or Not

The seating area was dark - so dark that trying to keep track of scores felt like a scene from a spy movie. Scribbling notes blindly wasn't working, so I made a mental note to invest in a light-up pen. (Spoiler alert: Amazon has a ton of great options under $10.) Consider this my pro tip for future competition parents - trust me, you'll need one.

The Elevator Bottleneck and a Smart Exit Strategy

With only one elevator leading to the third floor, getting out at the end of the day was a slow-moving process. To speed things up, I took the dance bag to the car as soon as the final performance wrapped up. This way, everyone else could take the stairs without lugging extra gear, making our exit much smoother.

Final Thoughts
Competitions are long, tiring, and filled with unexpected challenges. But with the right game plan - and maybe a well-timed snack - you can make the day a whole lot easier. Bring your own water (if you dare), grab seats early, invest in a light-up pen, and always have an exit strategy. Here's to a great season ahead!

incompetech.com

March 8, 2025 by cryan.com

Royalty-free music is a type of music that can be used in videos, presentations, and other projects without having to pay royalties to the composer. This type of music is often used by businesses and individuals who need to create professional-looking videos or presentations.

There are many different genres and tempos of royalty-free music available. Some of the most popular genres include classical, rock, pop, and jazz. There are also a variety of tempos available, from slow to fast.

Benefits of Using Royalty-Free Music

There are many benefits to using royalty-free music, including:

• It is affordable.
• It is legal.
• It is easy to find.
• It is available in a variety of genres and tempos.

If you are looking for high-quality, royalty-free music, I recommend checking out incompetech.com.

Website Description

https://incompetech.com/music/royalty-free/music.html

Copy as Markdown

March 7, 2025 by cryan.com

I've noticed that when I paste text from Chrome into DayOne, it strips away formatting like bullet points and headers, leaving the entry looking messy. To address this, I use a Chrome extension called "Copy as Markdown." It simplifies the process by preserving most of the original formatting - think clean bullet lists and bold headers - making my DayOne entries more organized and visually appealing. It's not flawless (it works about 80% of the time), but it's reliable enough to save me effort.

The only drawback is that I have to right-click and select the extension from a menu each time. This extra step can feel tedious, especially when I'm pasting multiple items in a row. Still, for now, it's a solid workaround.

Simply right click to copy the selected content as Markdown.

Extension Info

The extension allows you to copy selected text on a page as Markdown with support for features including the following

• Ability to copy links, images, and selected text as Markdown.
• Linked images, will have options to individually select link or images.
• Formatted text such as Italic, bold, strike-through, and inline code.
• Unordered and ordered lists, with task lists support.
• Tables, with respect to GFM.
• Fenced code blocks, with language detection using info strings.

Note: When copying links and images, Chrome doesn?t let you extract images alt text or anchors text content to be used in Markdown, instead the links themselves are used as link title. Firefox doesn?t have this limitation though.

XPath with Playwright page.locator

March 6, 2025 by cryan.com

Playwright page.locator method is designed to find elements dynamically, with built-in support for multiple selector types - including CSS, text, and yes, XPath. While CSS selectors are great for straightforward queries, XPath shines when you need more flexibility or when dealing with complex DOM structures.

Here's why XPath might be your go-to:

• Structural Navigation: XPath lets you traverse the DOM based on relationships (e.g., parent, sibling, child) rather than just classes or IDs.

• Attribute Precision: Target elements by any attribute, not just class or id.

• Text-Based Selection: Easily find elements containing specific text, even partial matches.

• Dynamic Pages: XPath can handle scenarios where CSS selectors falter, like when class names are auto-generated or unpredictable.

Playwright's page.locator makes XPath a first-class citizen, so let's see it in action.

Getting Started with page.locator and XPath

The syntax for using XPath in page.locator is simple: prefix your XPath expression with xpath= or use the double-slash shorthand //. Here's the basic structure:

await page.locator('xpath=//tag[@attribute="value"]').click();

Playwright will evaluate the XPath expression and return a Locator object, which you can then interact with (e.g., click(), fill(), textContent()).

Practical Example

Let's walk through a real-world scenario where XPath and page.locator save the day.

Targeting an Element by Attribute

Imagine a login form with a button lacking a unique ID or class:

<button type="submit" data-test="login-btn">Sign In</button>

With XPath, you can target it by its data-test attribute:

const { test } = require('@playwright/test');
test('click login button', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.locator('xpath=//button[@data-test="login-btn"]').click();
});

The //button[@data-test="login-btn"] means "find any <button> element with a data-test attribute equal to login-btn."

When to Avoid XPath

While XPath is powerful, it?s not always the best choice:

• Simple Selectors: Use CSS for #id or .class?it?s faster and more readable.
• Dynamic IDs: If attributes change frequently, text-based or role-based selectors (role=) might be more stable.
• Maintenance: Complex XPath expressions can become brittle if the DOM structure shifts.

Naming Screenshots Dynamically in Pytest

March 5, 2025 by cryan.com

When running UI tests, capturing screenshots can be an invaluable debugging tool. However, managing these screenshots can quickly become chaotic if they are not properly labeled. One effective way to make screenshots easier to organize and track is by incorporating the test name into the filename. This ensures that each screenshot can be traced back to the exact test that generated it.

Capturing the Current Test Name in Pytest

Pytest provides an environment variable called PYTEST_CURRENT_TEST, which contains information about the currently executing test. We can extract the test name from this variable and use it to generate meaningful screenshot filenames.

Here's an example of how to do this in a Selenium-based test:

import os
import time
from datetime import datetime
def test_full_page_screenshot_adv(browser):
    browser.set_window_size(1315, 2330)
    browser.get("https://www.cryan.com")  # Navigate to the test page
    # Extract the current test name
    mytestname = os.environ.get('PYTEST_CURRENT_TEST').split(':')[-1].split(' ')[0]
    # Create a timestamp for unique filenames
    log_date = datetime.now().strftime('%Y-%m-%d-%H-%M')
    # Define the screenshot path
    screenshot_path = f"{mytestname}-{log_date}.png"
    # Capture and save the screenshot
    browser.save_screenshot(screenshot_path)
    print(f"Screenshot saved as {screenshot_path}")

How It Works

1. Retrieve the Current Test Name:
   • The environment variable PYTEST_CURRENT_TEST holds information about the currently running test.
     
   • Using .split(':')[-1], we extract the actual test name from the full test path.
     
   • Further splitting by spaces (split(' ')[0]) ensures we only get the function name.
2. Generate a Timestamp:
   • The datetime.now().strftime('%Y-%m-%d-%H-%M') function creates a timestamp in the format YYYY-MM-DD-HH-MM to ensure unique filenames.
3. Save the Screenshot:
   • The test name and timestamp are combined to form a filename.
     
   • The screenshot is saved using Selenium's save_screenshot() method.

Why This Matters

• Easier Debugging: Knowing which test generated a screenshot makes debugging test failures much simpler.
• Organized Test Artifacts: Each screenshot is uniquely named, reducing the chances of overwriting files.
• Automated Report Integration: The structured filenames can be linked to test reports, making them more informative.

Final Thoughts

By incorporating the test name into the screenshot filename, you can quickly identify which test generated a particular screenshot. This small tweak can save time when reviewing test results, especially in large automation suites.

Try implementing this in your test framework and see how much easier it becomes to manage your UI test screenshots!

The Boston Massacre & Software Quality Assurance

March 4, 2025 by cryan.com

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.

KRONT-TV News on April 14, 1997

March 3, 2025 by cryan.com

Brief segment of the April 14, 1997 Sports and in the Circular File.

Sports Segment (April 14, 1997):

• Tim Wakefield and the Boston Red Sox defeated the Oakland A's at Fenway Park. Notably, there were no seats on the Green Monster at the time.
• Tiger Woods attended the opening of an All Star Cafe in Myrtle Beach, South Carolina.
• An interview with his Stanford golf coach revealed Woods practiced putting on the basketball court. (Donald Trump makes a brief appearence.)

Wildlife Segment:

• A brief feature on the rare blue lobster.

Circular File:

• Milo? Forman is considering directing a new film about Andy Kaufman.
• Introducing a new beer flavored with hemp seeds.
• New research involving monkeys.