Maire Grant

Fire Classifiction: Arson or Accidental?

Tue, 04 Nov 2025 00:00:00 -0500

Can fire cause be determined from images from the scene?

I’m an avid true crime watcher and a tester who works hard trying to notice the unnoticeable. I experimented with Jupyter notebooks in uni but haven’t attempted anything in this area for a long time.

I decided I wanted to attempt to classify images based on existing image models and a custom data set, set it up, gather data and develop this skill set more. The subject I settled on was fires - I wanted something niche that way the possibility of stumbling onto something useful could be greater.

Fires

Accidental or Arson?

I wanted to try and determine if there were any differences that could be detected of property on fire or fire damaged that would indicate the cause of the fire. I focused on mostly exterior photos, photos of damaged properties trying to get as many photos of the subject actively on fire as I could to try to enable analysis of the smoke and flame colour.

Some patterns between arson vs accidental fire cause include multiple points of extreme damage, hints of multiple points of origin, unusual spread distribution. Darker smoke may suggest accelerants.

I searched through news websites, google to find images where it was reported that the cause was suspected arson or accidental. It was harder than I thought to gather images I wanted to build a large dataset whilst also having the information available on whether the cause was arson or accidental.

In the end I gathered initially 80 images and then grew this to a still very small 157 images in total but the classification may be subject to human error or misreporting on the sources. Disclaimer any marked as arson also include being described suspected arson there may be some small inaccuracies, my classification is based on the image source and news site.

I used the 70:15:15 ratio to distribute test, train and validation data over my classified dataset. I set up a Google Colab notebook. The first step was to install libraries required such as split-folders, numpy, tensorflow, and Keras. Keras’s ImageDataGenerator was used. The images I gathered were all different sizes and file formats, an Extract, Transform, and Load (ETL) process resized the images, converted them all to the same format (even though they could likely be handled this was to rule out discrepancies).

ResNet50 was the base model used for this project. I set the base_model.trainable to false to “freeze” the main layers. GlobalAveragePooling2D was used for classification and condensing. 2 classification categories were specified: {‘accidental’: 0, ‘arson’: 1}.

A 0.5 dropout was set to prevent overfitting due to having a smaller dataset to try to prevent over reliance. Predictions are created converting the output to probability distribution giving the probability of being either accidental or arson. I started training on a small number of epochs at 15. The results were plotted using matplotlib.

Here are some example results from different runs:

As we can see the results are not very reliable in the first instance. The data set is quite small. I undertook this project to start learning principles and to learn the process so getting high and accurate results are not the goal here.

After the initial training stage, I wanted to be able to pass in single unclassified images to test the results using the .predict() model to see how the results would fare given my setup is very prone to overfitting.

I would then classify the images properly after and tweak to check for improvements. As the dataset grows I can rerun and monitor the results.

On top of increasing the amount of images in the data set, other things could be looked at such as combining with metadata such as was there forced entry detected, time of day, weather etc.

It’s hard to say how much can be inferred from exterior photos alone. The results were inaccurate, when 6 new images were fed into predict classification, 4 were wrong and 2 were right. It predicted accidental every time so it is hard to know if it got the 2 right or it was a matter of change picking accidental each time.

So can fire cause be determined from images from the scene?

Potentially but not from this model as it is too unreliable. Something like this should only be used a supplementary aid should a dataset large enough garner more accurate and reliable results. Additional sources of investigation will always be needed such as checking the scene for accelerants, signs of forced entry and other indicators.

Playabout with the code here: https://github.com/mairegrant/fireClassification/blob/main/Fire_Classification_Arson_Accidental.ipynb

The Bug Detection Roller Coaster: A Carnival of Code and Shadows

Sat, 25 Oct 2025 00:00:00 -0400

The Bug Detection Roller Coaster: A Carnival of Code and Shadows

The carnival gates creak open slowly in the warm twilight fog, the park is abandoned. Offside is a rickety wooden tracked roller coaster with graffiti over the booth. As the gates crawl further apart the sound of electricity and old code humming quietly with secrets can be heard. The sign flickers on — “Bug Detection” — a ride of iron and whispers, the fluorescent orange bulbs glittering like blinking eyes. Dishevelled paper streamers and faded flags hang off decorative Victorian style lampposts.

Step right up — for this is no ordinary ride. No, this is a plunge into the uncanny valleys of software testing. You know you shouldn’t, but your feet take you to the direction of the car whispering towards you in the fog and soon you are strapped and on your ascent. The climb is slow and then faster and then slow again, there is a chill in the air now. Below the tracks bugs of all shapes and sizes scuttle around hurriedly into the shadows before it is too late, but they have been spotted, and they are everywhere. Every click, the roll of the track pulling you into a black velvety darkness.

You are plunged downwards in one quick movement into the valley of familiarity where everything looks… ordinary. Where have the bugs gone? The code hums to you, a soft lull. White noise in the background. Bugs crouch in the corners, grinning like porcelain dolls with cracked faces and sharp teeth. You struggle to see them behind the glamour now even though you’ve seen it a hundred times. This is the trick. This is how they hide.

The track twists into a loop. The car jolts faster now, the sticky, sickly smell of candyfloss and popcorn permeate your senses and suddenly you are upside down. Your thoughts are too, spiralled and anchored to old assumptions, tangled whispers of “it’s fine, it’s always been fine, that’s just how it works, it’s always been that way…” The mirrors here are cruel, they show you what you expect to see and not what is really there. The bugs are laughing now. They scuttle around faster, vibrating with energy, laughing in metallic tones. They laugh; they laugh because they know you have stopped looking.

You close your eyes; the ride will be over soon. The track rises, high above the abandoned theme park. You open your eyes as the track rises into the mist. Up here the air is thin and cold, but you can see everything. You’ve learned the patterns, the secret doors, the sigils, their names. There they are — the ghost bugs. Ancient, clever and stitched into the bones of the system. They don’t want to be found. The car rattles to a halt. The carnival isn’t finished with you. Your knuckles are white on the cold iron bar, and you can feel it, etched into the cool metal. The bugs are still there. They have retreated for now, but they are there, in the bolts, in the shadows, in the hum of the tracks. As you step off the only thing you know for sure is that you will be back and you will ride again.

I recently visited Japan and we passed by Fuji-Q Highland, guilty of not doing enough research beforehand we skipped it due to time constraints and afterwards was met with FOMO (thanks TikTok) when I learned that Takabisha is the second steepest roller coaster in the world and the park is famous for being some of the highest, fastest and steepest coasters in the world.

Channelling that FOMO + excitement for Halloween I combined my inspiration to talk about something I love almost as much as roller coasters — finding bugs. Recently joining a new team I’ve been met with the common adages and coming in as a set of “fresh-eyes” really struck a chord with me this time.

I know the value of fresh-eyes on an application but how do we maximise the effect of this phenomenon?! Bug detection rate starts high when testers have “fresh eyes” and this gradually declines over time as the tester becomes familiar with the domain, bug detection then stabilizes before typically gradually increasing due to deeper insight.

As domain knowledge and system familiarity increase then bug detection can be seen to start plateauing. This might look something like this where 0 represents the business-as-usual defect logging rate.

The fresh-eyes phase is high for the first few weeks due to a combination often of novelty, unbiased perspective, determination to learn (feeling inspired) and questioning logic to ascertain understanding. The time frame above is hypothetical as onboarding and complexity will differ from project to project.

How does this work? Novelty triggers “system 2 thinking” (deliberate and analytical) before mental shortcuts take over and dominate. Having a lack of domain familiarity means that testers question logic and assumptions, hence finding more issues. Over time pattern recognition techniques and habituation reduce anomaly detection unless this is countered by structured techniques.

We can typically think of the “fresh-eyes” effect wearing off as a series of stages.

“Fresh-eyes” phase — high defect rate

Decline phase — defect rate lowers as testers become accustomed to quirks
Stabilization phase — defect rate drops to a normal level that others may have been targeting before
Deep insight — as domain knowledge and logic grows bugs detection starts to trend upwards again albeit at a slower rate.

To think of this in terms of formula for observability and testing we can map to the following two parts. Domain knowledge and bug detection rate.

Domain knowledge:

Domain knowledge (time)

Starts at 0 when time t=0 (tester knows nothing about domain).

Grows fast at first as learning is fast in beginning due to novelty.

Slows down and approaches 1 (a plateau) as time progresses because there is a limit on how much domain knowledge can grow.

Use exponential as learning curves often follow this pattern with rapid early growth and then diminishing returns.

0.3 here is representative of the growth rate but a bigger number means that domain knowledge grows faster and reaches plateau faster. A smaller number here represents slower learning. 0.3 domain growth gives a curve that knowledge grows quickly in the first few weeks and then slows down which is typical of onboarding patterns.

Bug Detection Rate:

Bug Detection Rate (time — in weeks here)

0.8 is the starting bug detection strength which is often high in the beginning (this differs for every application)

0.4 is the decay speed, a larger number represents a faster drop in bug detection and a smaller number represents a slower decline.

0.2 is the size of the late-phase bump (how much improvement that additional domain knowledge brings).

0.1 is the width of this bump — a larger number is a narrower bump which is a short improvement while a smaller number giving a wider bump is a longer improvement phase.

t-10 = the centre of the bump around week 10 in this example

In short we are focusing on the variables of

how fast knowledge grows how fast early bug detection fades how wide the late improvement phase is the values substituted are hypothesized parameters to illustrate the concept

To put this metric detection into practice and to validate as a study against real-world data we should collect:

Defects found per tester per time unit (e.g weekly or sprint based) Severity distribution (critical vs minor to monitor if fresh eyes finds more obvious issues early) Defect discovery date (to plot detection rate over time) Defect type (UI, functional, integration etc to monitor if later phases with higher domain knowledge garner more systematic bugs).

As domain knowledge is harder to quantify, we can use proxies such as:

Time in project (weeks since onboarding) Training completion percentage (if applicable) e.g courses, documentation read Code coverage or feature coverage (how much of the system the tester has explored) Peer review scores or knowledge assessments (optional but could be used for calibration)

Compare predicted vs actual bug detection rates. Adjust parameters in line with organisational differences.

I liked the analogy of the roller coaster above to describe the 4 phases of bug detection from the fresh-eyes phase to deep insight. Another reason I liked the roller coaster analogy is because we can get on a second time but we can never re-emulate that first time, we know what to expect, we aren’t shocked, it loses some of the magic from the second time onwards and are chasing the thrill and adrenaline of that first time. That is what I am trying to emulate in testing — finding a way to get as close to that first ride magic as possible.

How can we try to replicate stage 1 “fresh-eyes” bug detection rate?

Rotate testers across projects to introduce fresh eyes periodically helps cash in on this benefit but there may be some time loss to consider due to increased questions, knowledge transfer and onboarding. Session-Based Test Management (SBTM): Time-boxed exploratory sessions to promote curiosity. This can be combined with paired exploratory testing and bug hunts / bug bounty initiatives (optionally can be incentivized). Leverage AI and LLMs to help simulate fresh eyes — ask questions and prompt test scenarios in ways that can help simulate the fresh-eyes scenario. Apply checklists, automation and structured testing to counter cognitive biases. Enforce psychological safety so testers feel comfortable raising questions around logic and reporting defects.

Disclaimer: Some image and graphics in this article are generated by AI: Microsoft Co-Pilot for illustrative purposes and not my own artwork.

Find the article on LinkedIn here: https://www.linkedin.com/pulse/bug-detection-roller-coaster-carnival-code-shadows-maire-grant-bbbve and on Medium here: https://medium.com/@mairegrant/the-bug-detection-roller-coaster-a-carnival-of-code-and-shadows-74a0e47251eb

Velo AI: Can It Really Generate Weeks of Testing in Minutes?

Tue, 30 Sep 2025 00:00:00 -0400

I took Velo.AI for a spin to see if it lives up to its bold claim that it can “generate weeks of testing work in minutes.” Spoiler alert — it has got potential, but it’s not quite the silver bullet (yet).

Evaluation Approach

To give this a fair shot I used Strava as an example as it has an open API specification and is used among hobbyists as well as having some complex functionality. Supporting mocked artifacts including requirements documentation and architecture diagrams were generated using Copilot and fed into Velo AI as inputs. This allowed for a realistic simulation of the tool’s workflow in a typical modern development environment.

What It Does Well

Requirements Validation Surprisingly solid. It flagged 19 gaps from vague prompts I provided and even suggested technical formats like GeoJSON and GeoJSON LineString which left me impressed. This can translate to a saving in time for devs and QAs alike on Spikes.

Test Scenario Generator 93 scenarios generated in about a minute? Impressive. Covered boundary and negative testing, performance, edge cases, and risk-based testing. They still required manual work to expand them.

This feature provides value by:

Supporting legacy system analysis, where existing test assets may be incomplete, outdated, or undocumented Supplementing exploratory or regression testing with additional test perspectives that may catch overlooked edge cases. The auto-generation capability reduces manual effort, promotes test standardization, and could enhance onboarding for new testers or test leads by giving them a clear, automated view of what needs coverage. This is useful in large or distributed teams where test design quality may not be consistent.

API Test Case Creation

Generated solid test cases from OpenAPI specification. Covered boundary, security, and performance — ideal for fast-paced teams.

From a business standpoint, this functionality offers value

Accelerating test design for APIs where documentation exists but test coverage is not yet built Automation Scripting Supports Selenium, Playwright, Appium, JMeter, and more. Great for stubbing out frameworks or quick proof-of-concept pieces.

The tool clearly would be capable of selecting multiple test cases and scenarios from the bottom bar and pulling through to write a lot of unit tests at one time but this doesn’t necessarily save time by the time they are ported, pulled into the code base, tweaked and edited if needs be. It saves a lot of time, yes — but there are other tools that can be integrated into the IDE that would provide more of a time saving by removing the need to port code in and out of a tool.

Competing solutions embedded directly into IDEs (e.g., GitHub Copilot, CodeWhisperer, or JetBrains tools) may offer greater real-time productivity gains, particularly in mature development pipelines.

What I did like was the range of testing including mobile and performance testing — the ability to generate performance test scripts for JMeter. Gatling and mobile testing offerings for Appium and Android and iOS mobile native testing on top of the usual suspects Selenium, Playwright, Cypress and REST Assured for API Testing.

This is something that could be used to stub tests for framework selection from getting a barebones project up and running with a specific purpose, it could save time, you could do a lot even with the free trial especially as it is not time limited.

From a strategic QA perspective, this breadth allows test teams to:

Rapidly prototype and evaluate automation frameworks for different platforms Stub out baseline automation projects to accelerate implementation timelines Explore performance and mobile testing use cases without deep upfront setup For teams evaluating frameworks or building proof-of-concept automation suites, this capability can reduce setup time and improve ROI on resource-constrained projects. The absence of a time limit on the trial version allows testers to explore this functionality before committing to adoption.

Room For Improvements

UI & Workflow

Clunky in places. Artifacts section disappeared between sessions, and exporting code was a bit of a pain.

Test Case Maintenance

More tests ≠ better tests. High volume might mean high maintenance.

Unit Testing

Decent starter code, but lacks IDE integration — GitHub Copilot still wins here.

Test Automation Scripting

Code export is manual and fragmented -users must download individual files or copy/paste code snippets from the read-only, line-limited code viewer. There is no option to download a .zip folder and lack of this introduces unnecessary sticking points for integration into CI/CD pipelines and local IDEs.

No in-browser editing reduces efficiency that could be leveraged customizing generated scripts before exporting them.

Business Value?

Speed-to-Test Yes, especially for new features or weak requirements.

Standardization

Can help align test strategy across teams.

Cost Efficiency

Maybe — if used strategically and not as a crutch. I used the free trial with credits and it was open use allowing me to use all the functionality — free trials as they should be — giving free reign.

Strategic Positioning and Tooling Landscape

Velo AI enters a crowded space of AI-powered test generation tools like BrowserStack, Testim, and Tricentis — all leveraging similar OpenAI-based tech. While its core capabilities aren’t unique algorithmically, Velo AI aims to stand out by:

Streamlining workflows (though not always smoothly)

Optimizing prompts for domain-specific testing Consolidating multiple testing functions to reduce context switching That said, similar results could be achieved using in-house or open-source LLMs at lower cost, especially if your team already uses approved tools with scripting capabilities.

Key Takeaways

Out of all the features of this tool I found the test automation scripting the most valuable for productivity and speed-to-value as a supplementary tool for moving fast and supporting manual testers moving towards automation.

Without getting into the whole “vibe coding” movement; tools like this are useful but shouldn’t replace understanding the fundamentals of writing code.

My concern would be that if we dropped tests written this way into a framework and the logic of how they work isn’t understood by those maintaining these tests long term leading to longer debugging time — this needs to be weighed into the true time saving cost-benefit and any savings may be offset.

An application I can see this being useful is for multi browser and device support, having the same set of tests and needing it written in another flavour or syntax e.g for both web testing and mobile testing requirements — spitting out and translating the same tests without having to context switch between coding syntax and losing time there.

A team combining this functionality with foundational knowledge and coding standards would likely see greater returns, as opposed to teams that treat it as a plug-and-play solution. Velo AI’s automation scripting offers value when used strategically as a catalyst for delivery speed and cross-platform efficiency but not as a replacement for skilled development practices. For best results, it should be integrated into automation initiatives focusing on maintainability, team enablement, skills, long-term scalability and sustainability.

Verdict

Velo AI is a solid toolkit for testers who know their craft and want a boost but not a replacement. Use it at project kick-off, during refinement, or when scoping out automation frameworks. Don’t expect this or any market tool to replace your intuition or experience.

So, yes — Velo AI really can generate weeks of testing (assistance) in minutes but it is up to us to oversee the quality of the output and use the tool to maximise efficiency.

My Scoring

Ease of use rating — 6/10 Intuitiveness — 5/10 Value rating — 6.5/10 Features and Functionality Rating — 7/10

Overall Score: 6/10 Great for experimentation. Worth a trial to see if you or your team finds value. Just don’t forget your critical thinking hat! 🎩✨🕹️

Slow Testing Checklist

Sun, 15 Jun 2025 00:00:00 -0400

“The Slow Testing Checklist”

Following up from the last post, I created the following checklist that testers can ask themselves to align with slow fashion principles in order to try to enable and deliver more robust and long-lasting systems.

Slow Testing

Tue, 10 Jun 2025 00:00:00 -0400

What is fast tech - what can we learn from fast fashion in tech?

By now we are all aware of the repercussions of fast fashion and over consumerism but what learnings can we apply from this to software development and is it too going in the same direction?

Overproduction and Overconsumption

We have seen the rise of micro-trends in fashion, with more means than ever before of influencing and advertising to people. These micro-trends mean new products are being pushed out as fast as possible and that people are consuming beyond their means.

Tech companies often release new models of devices incrementally even if little to nothing has changed knowing that people will buy these new products even if their existing devices still work. Mass hype around product launces such as regular Apple events create a fan followed culture that supports an unsustainable consumption, making having the latest smartphone or device a trend or status symbol as much as it is for purpose.

Upon the purchasing of a new smartphone, most of its carbon impact is locked in before the device is turned on - it costs around 60 kgCO2e to manufacture, package and ship the product, equivalent to approximately 350 km driven in an average petrol car. [1]

A consistently changing landscape of frameworks, languages and methodologies come with a cost associated and rework leads to increased time and electronic waste. (e.g., going from jQuery to Angula to React … and so on). Engineers are prompted to keep up to date and to chase new tools in some cases instead of mastering the fundamental underlying principles and over maintaining legacy systems.

Many companies often add additional features that are not necessary, at times to to show that changes are occurring but without consideration for the impact or actual user need in turn increasing complexity and decreasing maintainability.

Disposability

In fast-fashion clothes are not built to last, unsustainable techniques are used and the by-product is that they are thrown away after a few years (or less), so too, software products are developed and discarded at an ever increasing speed leaving artefacts behind that consume resource, bloat our systems and encourage a mindset of speed over sustainability.

This results in duplication and a promotion of throwaway culture. This poses the question, when is keeping up to date necessary and when does it become following trends?

A lack of perceived consequence means that care is not taken. Speed, novelty and short term wins are valued over longevity, sustainability and thoughfully crafted designs. Throwaway systems become the norm, more MVPs than necessary are produced that cannot be maintained.

Software begins to focus on speed over quality craftsmanship.

Burnout

It is no secret that fast fashion can create harsh and undesirable working conditions putting employees and skilled individuals under pressure to deliver faster. The same principle applies to software teams in high pressure environments being pressured to deliver faster and keep up with growing demands and unrealistic expectations.

Automation in the form of machinery for manufacture and AI tools and automation in software devalue skilled individuals. As a tester I love to “move fast and break things” in the right context and with purpose but this can bleed into an emphasis on speed over stability that we are becoming familiar with.

Environmental and Ethical Impact

Fast fashion has a massive impact on the environment. So too, environments that are always up (even when they don’t need to be) have a negative environmental impact. Software relies on massive energy consumption overheads which under the hood can lead to questionable practices (think data and crowd labour).

Slow Fashion

The opposite of fast fashion is slow fashion where high quality, thoughtful materials, ethics, sustainability, integrity and stability and long-term impact are prioritised over en-masse production.

Examples of “Slow” Thinking in a Tech World

Don’t reinvent the wheel, use open source when you can

Sustainable design practices, less is more mentality (where applicable), systems that don’t promote overconsumption of media and information, digital clutter.

Longevity focused softwares - Maintain and improve the existing systems over rewriting if it is possible.

Green computing practices - Reduce e-waste, energy use and in turn reduce carbon emissions.

Actions - How can I apply the principles of “slow-tech” in my everyday role?

As a tester how can I implement these practices in my day-to-day to try and make a difference?

Quality Over Speed

Don’t just do enough to get it out the door, test with purpose and intention. Treat testing as a craft and keep slow fashion principles in mind, e.g. for performance, scalability.

Promote regular exploratory and regression testing, search for negative scenarios and edge cases.

Challenge unrealistic timelines for testing that impact ability to test thoroughly and with full coverage.

Flag potential tech debt early on or anything that may be detrimental to the system making it unreliable.

Reduce and Reuse

Reuse libraries, paradigms, test data and artefacts among team members and teams to reduce maintainability and time to create.
Can we share documentation and principles that help us to align?

Champion Craftsmanship and Inclusivity

Quality over quantity. Treat testing as the craft and skill that it is. Take care in crafting thoughtful test scripts and test automation that requires less maintenance and can be scaled.

Shift left, look at pull requests, unit tests, UI/UX designs from a testing perspective, are we building testable code and systems or are we using testing as a tick box.

Consider accessibility, usability and edge cases early in order to reduce rework for unconsidered non-functional requirements.

Write code with future requirements in mind so that less rework is needed.

References and Further Reading

[1] https://www.carbontrust.com/news-and-insights/insights/smart-phones-smart-choices-harnessing-purchasing-power-to-reduce-the-carbon-impact-of-our-phones

Avoiding the Rewrite Trap - Camille Fournier - https://skamille.medium.com/avoiding-the-rewrite-trap-b1283b8dd39e

The True Cost of Rewrites - Doug Bradbury https://8thlight.com/insights/the-true-cost-of-rewrites

A Slow Fashion Lifestyle https://stplwear.com/blogs/journal/6-principles-of-a-slow-fashion-lifestyle?srsltid=AfmBOore597GuEcKiBnvvgKKhMCxoC9Tze-qvNmGhx8GogCwnCotYtL1

The Principles of Sustainable Software Engineering https://learn.microsoft.com/en-us/training/modules/sustainable-software-engineering-overview/

Freelance Testing & QA

Sat, 24 May 2025 00:00:00 -0400

Today I am reflecting on freelance testing in QA. My experience with freelance QA testing is limited in part due to opportunity and being conscious of my testing responsibilities in full time employment.

I have had the opportunity to take part in user surveys, UAT testing for Bosch and at Queen’s University where I took part in testing with pizza and Amazon vouchers. I would love the opportunity to work with more brands for collaboration in the e-commerce and tech space even on a voluntary basis in order to expand my skillset.

I am thankful for the learning opportunities these present, trying to pick up a new domain and think on my feet. Previously I had a mini twitter ‘Bugs in the Wild’ series where I would post about bugs I found in everyday life and not in a ‘bug bounty’ quest, although as a tester every day is a bug bounty quest. This series looked at some bugs in ASOS and Goodreads to name a few.

I would like the oppotunity in my career to explore new domains having had insight to a range of different domains, this is the experience I want to ascertain, I want to become a jack-of-all-trades and yes, this comes with the ‘master of none’ caveat but to specialise in just one area and domain would be detrimental to feeding exploration and creativity. The intersections of my hobbies and interests has always been one of my strengths, to attune a “think outside the box” approach. If you happen across this blog and want input to your system, website, mockups - please get in contact with me via Linkedin or email.

Microsoft Learn: Embrace Responsible AI Principles & Practices

Tue, 13 May 2025 00:00:00 -0400

Today I gained the badge for ‘Embrace responsible AI principles & Practices’ on Microsoft Learn. A module involved in looking at principles of responsible AI, AI Governance and the practices Micrsoft have in place with centralised and decentralized governance as well as their Aether (AI, Ethics and Effects in Engineeering and Research) Committee.

My Microsoft Learning Account

Friday Podcasts

Fri, 09 May 2025 00:00:00 -0400

What am I listening to this week?

Friday Podcast Episode Roundup

It’s Friday and what a week it has been - thanks to the apparance of the sun! That means one thing - time in the garden and as much time outside as possible with the headphones popped on for walks!

So what have I been listening to this week?

Ministry of Testing - This Week In Testing TWiT-89 Testers like to talk
The Final Girls: A Horror Film Podcast - Machines 03 . Frankenstein and the origins of tech horror
The AI Daily Brief (Formerly the AI Breakdown): Artifical Intelligence News and Analysis - 7 Lessons for Enterprise AI
Quality Talks Bitesize - Interviews: The Good, The Bad & How To Prepare with Eamon Droko
The Stack Overflow Podcast - Using AI to find patient zero in marketing campaigns
The Final Girls: A Horror Film Podcast - Machines 01 . Introduction

Playwright 2025 User's Event

Wed, 07 May 2025 16:28:42 -0400

I virtually attended the Playwright User’s Event 2025 to keep up to date with the recent advancements in Playwright and within the automation community. It’s always nice to famaliarise myself with others in the space as there is so much to learn from everyone.

It’s great to hear about advancements on how AI is driving testing and assiting with our automation but I always appreciate the emphasis on the basics and the importance of exploratory testing.

I am waiting on the recorded sessions to be rolled out via email so I can catch up on the sessions I missed.

Conversations with Priti Gaikwad - Testrig Technologies

Thu, 24 Apr 2025 00:00:00 -0400

I recently had the pleasure of connecting with Priti Gaikwad on LinkedIn and have been checking out some of the test automation articles at Testrig Technologies: QA & Software Testing Company

📚 I had a read through:

Playwright for Mobile Testing the Ultimate Guide to Performance & Quality
Playwright Commands Every Tester Must Know for Faster Automation
Automating Web Testing with Playwright Best Practices & Pitfalls
What is Big Data Testing and Its Essential Types

There were concepts that were new to me and this highlights how important it is to be upskilling and learning as we might learn something that we can add to our testing toolkit or that will become part of a solution to a problem we approach!

Things I learned from these articles:

Use of the slow mo command in Playwright for debugging
Names for terms like Veracity, Variety and Velocity Testing (I was aware of the concepts but would refer to them by the concept description and not a term and using a shared term saves time!)
More about advanced network interception on Playwright, I haven’t had much hands on experience with using network interception in Playwright for mocking and simulating errors with APIs (but would like to)! ⏱

Check out the articles if you are interested in all things automation - there is alot of valuable content and I look forward to reading more in future and keeping up to date! The Big Data testing article I found to be a great reference for the different types of testing to consider and I can see myself sharing this in future for reference!

➡️ Side note: I watched this video essay by Cinzia DuBois / Lady of the Library on Youtube about digital hoarding of information called Why Do We Hoard Information We’ll Never Use? – Books, articles, and intellectual FOMO.

I found it really interesting, I pin/bookmark/save so many articles to read later and it has changed the way I think about consuming media and prioritising content I have saved because I likely saved it for a reason!

If you are like me this is your sign! Pick up one of those articles, go to your bookmarks and saved articles, videos, watchlists or podcast episodes and give them a read / watch / listen. Let me know in the comments anything you pick up or want to share!

Microsoft AI Skill's Fest Guiness World Record

Tue, 08 Apr 2025 00:00:00 -0400

I participated in the Microsoft AI Skills Fest which coincided with AI Month in Version 1. I participated in Building applications with GitHub Copilot agent mode which was my first forray into using GitHub Copilot agent mode and I was suitably impressed and giving the whole ‘vibe coding’ thing a go.

This was a fun event as it is my first time being part of a Guiness World Record - I missed the chance to particpate in my local area previously when 33 schools took on an attempt to form the largest human Olympic rings as part of the Olympic torch relay in 2012.

I was happy to see that Microsoft did in fact get the results validated that they earned the GUINNESS WORLD RECORDS™ title for the most users to take an online multi-level artificial intelligence lesson in 24 hours, with a total of 126,151 participants. One of which being myself. I would have missed this opportunity if not for the buzz around AI in my current role embracing the advancements AI can provide.

Microsoft - Fundamentals of Generative AI

Tue, 25 Mar 2025 00:00:00 -0400

On the 25th March 2025 I completed the module - Fundamentals of Generative AI. A free module on Microsoft Learn ahead of AI Learning initiatives in AI Month in Version 1 (April 2025).

Check out my learning profile here for more an overview of my Microsoft Learning modules and badges - Microsoft Learning Profile

Playwright Live - Community updates and More: March

Fri, 21 Mar 2025 00:00:00 -0400

I virtually attended the Playwright Live Community Updates and More March event on 21st March 2025 looking at the latest community updates, new and experimental features and improvements hot off the press.

A great session as always with Debbie O’Brien and Ben Fellows. Excited for the functionality that the new MCP server will bring for us! AI, Aria snapshots and the MCP server were covered among other topics in this session.

Link to the Playwright Live Community Updates for March session

AI-Informed Testing: Testers.ai's Jason Arbon & XBOSoft (Webinar)

Thu, 20 Mar 2025 00:00:00 -0400

I attended the AI-Informed Testing Webinar session live with Jason Arbon & XBOSoft.

I checked in last to see some of the work Jason Arbon is doing with AI in testing in this video webinar with Philip Lew, XBOSoft and testers.ai and I did like the extension highlighting test scenarios in gherkin syntax for a given page in the browser. Always interesting to see what others are working on and new tools and technologies!

This kind of thing is quite exciting as given a screenshot test cases are generated helping us to streamline testing, help not to miss edge cases and to identify missing requirements earlier on. We could look at doing this at the prototype level so that we are shifting left and thinking about quality being baked in as early as possible and really focusing on TDD principles early on! Excited to see what AI will bring to testing as we advance in this industry!

Philip Lew highlighted the importance of the 80/20 pareto principle in automation and ROI with automation and increasing results with a reduction in effort in (manual) testing. I liked the graphic below - I’m sure we can all relate to the following problems as testers.

Check out the link here: Webinar Recording Link

TAU Course - Continuous Testing with Azure DevOps for testing

Fri, 07 Mar 2025 00:00:00 -0500

Brushing up on Continuous Testing with Azure DevOps for testing, I found this course by Bushra Alam very clear to follow and very useful for beginners, refreshers and people of any skill level!

Topics covered include adding tests, publishing results, extracting test artifacts, project configurations, tasks groups, parallel test execution, handling failing and flaky tests and multi stage pipelines.

You can check out the roadmap for Azure DevOps updates and improvements from Microsoft here: Azure DevOps Roadmap

Some upcoming features around Azure Test Plan improvements worth keeping up to date on, excited to see how the test runs can integrate more seamlessly around Test Plans and Test Cases.

A ‘new test run experience’ to include pipeline-based filtering in order to make it easier to connect test results to specific builds and artifacts is planned for 2025 Q2. Worth checking out to see what features may provide value to you and your team!