DEV Community: Paradith

Imaging having The Witcher on your dev team...

Paradith — Fri, 31 Oct 2025 08:43:08 +0000

Influence doesn’t have to look like volume or certainty. It could look like curiosity, with an edge of empathy and wisdom. We know testing can feel overwhelming sometimes, especially when deadlines loom. Heuristics like W.I.T.C.H.E.R help me focus without losing creativity.

And I am so curious - when it comes to making testing easier. I also love a heuristic. Does not mean I always remember them. Here’s an exploratory testing heuristic using the acronym W.I.T.C.H.E.R

W.I.T.C.H.E.R Heuristic

W — Workflows

Explore common and edge workflows, identify typical user journeys and uncommon paths. Test each step, transitions, and decision points.
Integration points - check interactions between different system components and third-party services. Ensure data consistency and flow.
Error Handling - validate how the system handles errors, including user errors, system errors, and edge cases.

I — Inputs

Variety of inputs - test with different data types, lengths, and special characters. Include valid, invalid, and boundary inputs.
Data formats - ensure the system can handle different formats like JSON, XML, CSV, etc.
Input sources - test inputs from various sources such as forms, files, databases, APIs, etc.

T — Time

Time-based conditions - check how the system behaves at different times, such as leap years, time zones, and daylight saving changes.
Performance testing - assess the system’s response time, throughput, and load handling capabilities.
Timeouts and delays - verify handling of network delays, server timeouts, and user session timeouts.
Prioritisation - consider how much time you have for exploratory testing and prioritise accordingly.

C — Context

User context - understand different user scenarios, roles, and permissions.
Environment context - test across various environments like development, staging, and production.
Business context - ensure alignment with business rules, workflows, and objectives.

H — Heuristics and History

Common heuristics - use known heuristics like RCRCRC (Recent, Core, Risky, Configuration, Repaired, Chronic).
Historical data - analyse past bugs, user feedback, incident reports, and logs.
Exploratory testing - continuously adapt testing based on findings.

E — Edge Cases & Exceptions

Boundary conditions - test limits like max/min values, empty states, and overflow scenarios.
Exception handling - validate how the system responds to unexpected inputs or system failures.
Rare scenarios - include unusual user behaviors or uncommon configurations.

R — Risks & Regulations

Risk-based testing - prioritise areas with higher business or technical risk.
Compliance checks - ensure adherence to legal, security, and privacy standards (e.g., GDPR, PCI-DSS).
Security considerations - validate authentication, authorisation, and data protection mechanisms.

In my experience, heuristics like this aren’t about perfection - they’re about sparking ideas when you’re stuck or under time pressure. Use them as a compass, not a map. And if you’ve got your own favorite heuristics or testing hacks, I’d love to hear them. If you try it, let me know what worked, or what didn’t. We learn best together.

Cannibalism in Open Source...

Paradith — Fri, 31 Oct 2025 08:28:34 +0000

Just like in cooking, where chefs 'consume' each other's recipes to create new culinary masterpieces, or in fashion, where designers 'integrate' styles to evolve trends. Cannibalism happens in Open Source too - and it's all done with love... or is it?

Unsung Testing Heroes: Bugs Squashed Before They Could Strike

Paradith — Wed, 30 Oct 2024 13:36:31 +0000

We often hear about high-profile software failures that make headlines. These incidents can have significant consequences, from minor inconveniences to major security breaches. However, the unsung heroes of the software development process are the testers who diligently work to identify and eradicate bugs before they reach production.

Why are these pre-production bug finds so crucial?

Cost effective: fixing a bug in the early stages of development is significantly cheaper than addressing it after a product is released.
Enhanced user experience: by preventing bugs from reaching end-users, testers contribute to a smoother, more valuable and enjoyable user experience.
Strengthened brand reputation: a product with fewer bugs reflects positively on the company’s commitment to quality and reliability.
So, what are some of the most satisfying bugs we’ve found in testing?

While I cannot provide specific examples from proprietary projects due to confidentiality, I can share hypothetical scenarios that mirror real-world bug discoveries I have seen or learned about in my time:

The Stealthy Security Flaw

A seemingly innocuous piece of code that, if exploited, could have compromised sensitive user data.

Real world inspo… the Heartbleed vulnerability, a serious security flaw in the OpenSSL cryptographic software library, allowed attackers to steal sensitive data from millions of servers.

Hypothetical example… a tester might discover a similar vulnerability in a web application, where a seemingly harmless function could be exploited to expose sensitive user information, such as passwords or credit card details.

The Performance Bottleneck

A hidden inefficiency that was slowing down the application and impacting user experience.

Real world inspo… early versions of popular websites like Google or Facebook suffered from slow load times and poor performance due to inefficient algorithms and database queries.

Hypothetical example… a tester might identify a poorly optimised database query that was significantly slowing down the loading time of a critical page, impacting user experience and potentially leading to lost revenue.

The Edge Case Nightmare

A rare scenario that could have caused the system to crash or behave unexpectedly.

Real world inspo… the Mars Climate Orbiter mission failure in 1999 was caused by a mix-up between metric and imperial units of measurement (the math wasn’t mathing).

Hypothetical example… a tester might find a bug in a financial application that causes incorrect calculations under specific, rare conditions, such as leap years or daylight saving time transitions.

The User Interface Blunder

A confusing or misleading design element that could have led to user frustration and errors.

Real world inspo… many software applications have suffered from confusing or inconsistent user interfaces, leading to user errors and frustration.

Hypothetical example… a tester might identify a poorly designed form that could mislead users into entering incorrect information, leading to data entry errors and system failures.

While these bugs might not make headlines, they represent the tireless efforts of testers to ensure software quality. It’s important to remember that even the smallest bug can have significant consequences, and that diligent testing is essential to prevent such issues from reaching production.

By sharing these stories, we can celebrate the importance of testing and inspire others to strive for excellence in their work. Let’s take a moment to acknowledge the value of pre-production bug finding and the hard work of the testing community.

Staff Quality Engineer, awesome woman in tech, UN Women Delegate and I believe in the value of curiosity and empathy in testing. I do all my own stunts, love food, travel, my friends, family, music and art. Feel free to comment below or share.

Engineer...Horror!

Paradith — Mon, 28 Oct 2024 11:39:56 +0000

Welcome to a... Developer's Haunted House!

Instill fear in the hearts of your engineering teams...share developer stories around the camp firefox...do you have the ultimate horror experience told by devs..or was it an urban legend... SHARE in the comments!

Room 1: The Phantom Requirement, where suddenly you’re informed of an undocumented feature that “has always been part of the spec” … on the day of release.

Room 2: The Merge Conflict Monster, a room where every attempt to resolve merge conflicts creates more conflicts, spiraling into an endless loop of commits and despair...mwuah hahahahaaa

Room 3: The Legacy Code Crypt, where ancient, undocumented code lies, full of variables named var1, temp, and finalFinal. Legend has it that anyone who touches it vanishes...

Room 4: The Vanishing Stack Trace, where error messages mysteriously disappear or return “Unknown Error” with no other clues. Debugging tools are powerless here... (or are they...)

Room 5: The Infinite Build Loop, where the build keeps failing, and each attempt to fix it adds five more errors. A slow, oh so painful... eternity... spent... in build purgatory.

Room 6: The Inconsistent Environment, where code runs perfectly in Dev but breaks in QA, Staging, or Production, despite every setting being “identical.” Or so they say...

Room 7: The Requirements Time Warp, where every requirement change from the past six months comes back to haunt you just as you thought it was final. (Anyone else singing rocky horror's "lets do the time warp"? just me?...)

Room 8: The Dependency Dungeon, where upgrading a single library cascades into dozens of conflicts, and every fix creates three more issues. There’s no end in sight.

Room 9: The Testing Time-Sink, where you write tests for everything, only to find they’re broken after the next “minor” update and need endless refactoring.

Room 10: The Performance Poltergeist, where everything works fine until you load real data, and suddenly your app grinds to a halt, leaving you helpless and surrounded by a sea of metrics.

Welcome to a developer's nightmare! Hope you brought your debug wand and a backup sanity plan... 🕯️👻

Things Ru Paul probably didn’t say about software testing or quality…

Paradith — Fri, 25 Oct 2024 11:59:03 +0000

“If you can’t love yourself how in the hell are you gonna love somebody else?”

I read Ru’s quote like this — relationships don’t work unless you love yourself too. RuPaul reminds us of the importance of self-confidence and self-belief. Testers need to trust their abilities and judgment to effectively identify and report defects, also to instil trust in what they are talking about. A lack of confidence can lead to hesitation, mis-aligned risk storming and missed issues.

“We’re all born naked and the rest is drag.”

According to Ru, drag has very little to do with someone assigned something. Drag is whatever we adapt to in life, be it to fit in or stand out. To Rupaul, drag is everything. Drag is anytime. We put on an outfit and choose how to present ourselves to the world. We should see this as a reminder — that the foundation of software testing is not just the code. Regardless of the language, the tools or methodologies used, the ultimate goal is to ensure the quality and value of the underlying product.

“When you become the image of your own imagination, it’s the most powerful thing you could ever do.”

Yes, curiosity.

Yes creativity!

Drag can be anything. Whatever you’ve always dreamed for yourself, when you make it a reality, that is a personal victory. This highlights to me the importance of creativity and innovation in testing. By thinking outside the box and considering unexpected scenarios, testers can uncover defects that might otherwise be missed. When was the last time you used or updated your ‘Personas’?

“I feel like you’re being sabotaged by your inner saboteur.”

Sometimes we’re our own worst enemy. The challenges of overcoming biases and assumptions during testing can be hard, and we can sabotage our own teams software delivery. It’s essential to be aware of personal biases and to actively seek out alternative perspectives.

“What it says on your driver’s license isn’t really who you are — you are something much greater than that.”

Is it the certification that defines you — or what you learned along the way? You can be whoever and whatever you want to be. Don’t let labels , job titles or certifications define you or hold you back from achieving your career or learning goals. You can achieve anything and not have a piece of paper or digital image to show your success is authentic.

Software testing is also about more than just following a script or a certain path. Testers should be adaptable and able to think critically to assess the quality of the product from different angles.

“The overall commentary on what I’m doing is saying, ‘Hey look! I get to create whatever persona I want to, and it’s all up to me. And the truth is, we are all basically the universe — pretending to be humans for a brief moment of time.’”

Testing is a creative process!! Life is too short to be caught up or live as someone you don’t want to be. Not one of us knows what we’re doing. We’re all exploring as we go, just as everyone before us has done. So why not apply that to work? Testers have the opportunity to explore different scenarios and perspectives to uncover defects — how great is that?

“Fulfillment isn’t found over the rainbow — it’s found in the here and now. Today I define success by the fluidity with which I transcend emotional land mines and choose joy and gratitude instead.”

I know it’s hard out there for alot of us with quality mindsets and the people who are testers at heart. We are all living here for just a moment of expression in the universe. So we might as well make the most of that moment and shine.

Gratitude is scientifically proven to increase happiness. It’s important to find satisfaction in the day-to-day work of testing. By focusing on the positive aspects of the job, remembering to thank your collaborators, people that you learn from or who inspire you — we testers can maintain a healthy and productive mindset and career.

“The key to navigating this life — don’t take it too seriously. That’s when the party begins.”

Stop letting people tell you — that you have imposter syndrome. Life is so short, it’s meant to be celebrated, so commit to enjoying it. While it’s important to take testing seriously in most instances, it’s also essential to maintain a sense of humour and proportion. A lighthearted approach and great planning can help to alleviate stress and improve your problem-solving abilities. Can you make learning or testing fun, do you have a community of practice or community that can support you?

“It’s very easy to look at the world and think, this is all so cruel and so mean. It’s important to not become bitter from it.”

Testing can be challenging, but it’s important to maintain a positive attitude and avoid becoming discouraged. The tech world can be harsh and also living in a time where there is so much hate in the world. But we can’t let that get us down. Don’t give the “haters” your time, keep focusing on yourself and always be proud of who you are!

“You know, the matrix says, ‘Pick an identity and stick with it. Because I want to sell you some beer and shampoo and I need you to stick with what you are so I’ll know how to market it to you.’ Drag is the opposite. Drag says, ‘Identity is a joke.’”

We’re born naked, the rest is drag. Instead of picking just one identity and having that define you, drag tells you identity is flexible, fun, and you can be whoever you want to be, some times it takes practice. So give yourself a reminder that testing should be about exploring different perspectives and challenging assumptions. You can focus on Security testing one sprint, QTR or year, then change your focus to Performance testing and that’s ok! It’s important to avoid becoming too rigid in our thinking or only following what certain people prescribe.

I'm a Staff Quality Engineer at heart, awesome woman in tech, UN Women Delegate and I believe in the value of curiosity and empathy in testing. I do all my own stunts, love food, travel, my friends, family, music and art.

Comments are welcome but please note I am neurodiverse, dyslexic and just having fun sharing what I know. Thank's for reading yall!

Why feedback and flexibility should drive team success

Paradith — Tue, 22 Oct 2024 10:59:15 +0000

As an experienced software tester and quality leader, I've seen teams fall into a familiar trap: expecting new joiners to adapt to existing workflows and processes without question. It often puts the burden on fresh eyes to challenge the status quo when they're at their most vulnerable - unfamiliar with the team's dynamics and possibly hesitant to speak up. We can't rely on new members to shoulder the responsibility for driving change when they're just getting started.

Instead, teams need to foster a culture where feedback is encouraged from everyone, especially new team members. It's easy for long-standing members to become accustomed to inefficiencies or blind spots, whereas new joiners can often spot these issues immediately. Their perspectives are fresh and often vital in improving team performance.

Rather than waiting for new hires to bring up these inefficiencies themselves, a better approach is to proactively invite feedback. Scheduling regular one-on-ones, use anonymous surveys (this does not work in small startups), or creating an open culture where speaking up is encouraged can go a long way. As experienced professionals, it's also important that we are transparent about our own struggles, so newcomers don't feel like they're the only ones grappling with issues.

The best teams I've worked on actively sought out these insights, continuously evaluating their processes with each new addition. This approach not only makes the team stronger but also empowers the new members to feel confident that their input is not just welcome but necessary.

Adding a person to a team might completely change what the team needs. I've seen first hand how adding even one new member to a team can dramatically shift its needs. It's not just about onboarding someone into existing roles and workflows; it's about recognising that their presence alters the dynamics and could require an overhaul in how the team operates. Their experience, skills, and even their working preferences can transform the team's trajectory.

For instance, if you bring someone on board with deep expertise in test automation, you might realise that your testing strategy needs to evolve to leverage their skills. Or, if a junior engineer joins, it may highlight the necessity for more in-depth documentation or increased mentoring efforts. In these scenarios, clinging to "the way we've always done it" is a fast track to missing out on potential improvements.

It's about being adaptable. Team composition isn't static, and as professionals, we have to stay fluid, redistributing responsibilities, reassessing priorities, and adjusting the focus based on the changing needs of the team. This flexibility ensures that we're always working towards making the team function at its best, even as its composition evolves.

Teams cannot be directly compared
There's a common fallacy I've seen across many organisations: trying to compare one team's performance to another's. This is not only unproductive but often misleading. Every team operates under different conditions - different goals, tech stacks, levels of seniority, and individual personalities. Metrics like velocity or points completed per sprint can only tell you so much, and they're rarely useful when comparing across teams.

Instead, a more effective approach is to look at how a team performs over time relative to itself. Has the team improved? Have processes become more efficient? How have team members grown? Does the team feel safe? This is a much more insightful way to gauge a team's health and progress.

Adding people power late to a project could also delay it further. This wisdom highlights just how complex and unique team dynamics can be. Each team has its rhythm, and its particular strengths and weaknesses. Trying to make one team match the performance or process of another just doesn't work.

Conclusion
Teams aren't immutable; they're constantly being redefined, especially with new members. As experienced testers, we should recognise that these changes bring fresh needs and opportunities for growth. It's on all of us to create environments where feedback flows freely, and the team adapts as it grows. By staying open and flexible, we can not only improve our workflows but also foster a culture that values continuous improvement and individual contribution.

Ultimately, the key to success in team dynamics is understanding that change isn't something to resist; it's something to embrace. When we do, we make room for a more effective, resilient team that can consistently deliver quality results.

TVP - Thinnest Viable Platform

Paradith — Mon, 21 Oct 2024 14:27:23 +0000

What is a TVP?

A TVP is the smallest set of features necessary to support your internal developer platform's core functions. It's about striking a balance between providing value and minimising long-term maintenance costs. Unlike the Minimum Viable Product (MVP), which focuses on initial validation, a TVP emphasises sustainable growth and scalability.

Key Differences Between MVP and TVP

Focus - MVP is about initial validation, while TVP is about long-term sustainability
Scope - MVP often involves a limited set of features, while a TVP aims to provide a foundation for future growth.
Maintenance - TVP prioritises features that are easy to maintain and update over time.

The Importance of a TVP for Software Testers

As a software tester, understanding the TVP concept is essential for several reasons.

Prioritising test cases - A TVP helps you focus on testing the core functionalities of the platform, ensuring that critical features are thoroughly validated.
Efficient test coverage - By understanding the platform's core components, you can design more efficient test cases that cover the most important areas.
Long-term test strategy - A TVP provides a framework for developing a long-term testing strategy that aligns with the platform's evolution.

Key Considerations for Building a TVP

Continuous refactoring - Regularly review and refactor the platform to ensure it remains lean and efficient.

Avoid feature creep - Resist the temptation to add unnecessary features that can complicate maintenance.

Prioritise core functionalities - Focus on testing the core features that provide the most value to developers.

Monitor platform usage - Gather data on platform usage to identify areas where improvements can be made.

By adopting a TVP approach, software testers can play a vital role in ensuring the long-term success and maintainability of internal developer platforms. By focusing on core functionalities and minimising unnecessary complexity, testers can help teams deliver high-quality platforms that meet the evolving needs of developers.

Get Curious not furious

Paradith — Wed, 16 Oct 2024 20:01:11 +0000

Reading interview notes, from interviewing others not long ago, I came across a great question from a candidate applying for a quality engineering role at my old company. This lovely person asked “what exactly do you do?”.

I love this question.

"In my capacity as a Staff Quality Engineer and Quality coach I create and promote a quality mindset within the engineering team and the business. I work with stakeholders to discover or determine quality goals, explore the product to gain context, but also establish and support Observability to get the right data and better context of what is happening with our Products Health. Looking at what happens after a story/feature has been shipped, “shifting right” as well as “shifting left”. It’s about collaboration and exploration."

Well that’s the elevator pitch over 😛

Thanks for your support Paul Mescal, it is as always...appreciated.

What I didn’t mention is that testing is at the heart of everything I do. I am also a testing advocate. So as you can guess my testing and quality mindset can be beneficial at anytime in the SDLC. I am curious. Curious and then curious some more. I ask questions all the time. Even if it is just internally. Even if it annoys the f*ck out of people - I have Curiosity aligned with purpose (knowing oneself within the context they work).

You see it all starts with an idea.

Quality engineers, software engineers, testers, we collaborate around the ideas and data to form requirement artefacts. We collaborate to think about requirement and product risks. We use these artefacts to stem architecture design, platform design, code design etc. To break up the work, slice it based on event mapping and risk storming. We write the code. We have operational and non operational software that we can assess. We deploy the software to production. We keep observing, supporting and maintaining that software in production and then we do it all over again for the next feature ideas or iteration on that product. This is a simplistic view of what we do but it works.

We talk about shifting left because we want to prevent bugs not break things. So we get curious before you get furious (we've all seen the tester vs developer memes). We pause before judging and taking offence when people don’t understand the points we raise, we stay engaged with the people and the world we need to influence. Why amp up your anger when you can work your wonder, as I always say to my imaginary mate Paul.

Thanks for reading.

If you enjoyed this brain dump, please click to follow or share to help others find it. Feel free to leave a comment also — I am open to insight, learning and discussion.

F.A.I.L — First action in learning

Paradith — Tue, 15 Oct 2024 18:49:06 +0000

Experimentation, especially when there are little to no proof points, allows us to know what’s possible. Failure is a natural part of any process, and we need to normalise it, so we feel more comfortable to accept, learn, and move forward — personally and professionally.

F.A.I.L — First action in learning.

So let's move forwards, we know pivotal creative and technical evolution is both personally and globally essential.

What exactly is ‘creative evolution’? For me it means growing with, and expanding, culture, community and experimentation. The only constant in life is change and that’s the truest statement for any business, community and individuals. It’s imperative for survival and success to evolve with the world we live in or want.

This isn’t an easy task when things never stay the same and only wins are recognised.

Everything from trends, tech advancements and economic shifts impact our creative evolution. It feels like all I see on my socials are people celebrating success with something they learned, career changes, dabbling in AI, getting new jobs, dealing with administration or redundancy and more.

All these influences inform our behaviours and so are integral to creative evolution, regardless of whether that’s to embrace it, reject it or something in between. And if there’s anyone out there who wants to grow creatively, pay attention to what’s happening outside of your comfort zone, lead with culture, lean in to what makes you different, learn from those who are stronger than you and embrace collaboration to make you better.

You might need W.A.T.E.R for your Exploratory Testing journey

Paradith — Tue, 15 Oct 2024 18:09:37 +0000

Exploratory Testing is…already something written about by lots of people. But for the benefit of those just learning about exploratory testing, a Product Manager or someone who wants to be part of an interview for a software role, lets recap — have a wee sip.

Let’s step back to Testing itself. Testing involves thinking, understanding and learning while a ‘test’ is simply an instance of understanding at a given moment in time. Testing is continuous and inherently human while tests simply allow us to externalise and encode our understanding at a specific moment in time.

Exploratory Testing involves far less documentation. We don’t document each and every test case. Instead we use our experience, our Oracle, part of our ‘toolbox’ if you will as experienced quality advocates and testers.

While automation testing speeds up repetitive cases, exploratory testing excels at identifying subtle bugs, user experience challenges, and unforeseen behaviours. Aligned with the Agile nature of continuous development cycles, this confluence improves testing coverage, accelerates defect identification, and fosters innovation.

W.A.T.E.R
I use a W.A.T.E.R acronym, to help people I collaborate with remember the fundamental principles that make exploratory testing a valuable and effective approach in software quality.

W — Wide Coverage
Exploratory testing aims to cover as many areas of the application as possible. Testers explore various features, functions, and user paths to ensure that the parts of the system their oracle knowledge tells them to cover, which might be missed in scripted/fallible testing.

A — Adaptive Approach
Exploratory testing is highly adaptive. Testers continuously learn and adapt their testing strategies based on their findings. This flexibility allows testers to pivot and focus on areas that seem more error-prone or that reveal unexpected behaviours.

T — Time-Efficient
Exploratory testing can be more time-efficient compared to traditional testing methods. Without the need for detailed test case documentation beforehand, testers can start testing immediately. This efficiency is particularly beneficial in agile environments where quick feedback is crucial.

E — Experience-Driven
The success of exploratory testing heavily relies on the tester’s experience and intuition, we sometimes call this their Oracle experience. Skilled testers use their knowledge of the application, the domain, and common software issues to guide their testing efforts. Their experience helps in identifying critical issues that automated tests might overlook.

R — Realistic Scenarios
Exploratory testing often involves simulating realistic user scenarios whilst also considering real life experiments that might be going on across your engineering domains. Testers interact with the application as real users would, uncovering usability issues and ensuring the application behaves as expected under real-world conditions. This approach helps in finding bugs that affect the end-user experience or will be detrimental to Product Health or Value.

I then follow it up in my head, seeing an image of a super hero, hands on hips, with a bubble saying:

With Advice (Oracle Knowledge), Tools, Exploration of Resources with Charters, Uniqueness Prevails.

Because all testers are heroes in my head…

I'm an awesome woman in tech and I believe in the value of curiosity and empathy in testing. I do all my own stunts, love food, travel, my friends, family, music and art.

'Takiwatanga', a kinder way to describe Autism

Paradith — Fri, 11 Oct 2024 08:17:40 +0000

Last week I learned the Māori word for ADHD/ADD is "Aroreretini" from a resilience councillor. Which translates to "attention goes to many things". That feels so much more apt and more accepting.

In the UK/US we call it a "disorder". It feels like it especially when people don't make the time to support you or work with you to put things in place to help you be treated equal. I have had to witness this for decades now with my twin brother.

Some say that the term #ADHD is disempowering, and that ADHD is actually more about having an abundance of attention rather than a deficit.

Many forget also that ADHD can present differently for different people, and can be both challenging and a strength.

People with Neurodiversity do have value, we pay attention to a lot of things and yes sometimes we have blips. This is why I especially like 'Takiwatanga' meaning "in their own time and space" used to describe autism.

Not just because it makes me think of Doctor Who but because it just makes more sense. The words people use and the language we use to interact with each other matters so much, it can do such and good and yet so much damage.

What a W.I.T.C.H!

Paradith — Mon, 08 Jul 2024 17:53:05 +0000

Exploratory testing using a Witch.

Erm - pardon?

I love a heuristic. Does not mean I always remember them, so take my advice — i’m not using it.

Here’s an exploratory testing heuristic using the acronym W.I.T.C.H.

W.I.T.C.H Heuristic

W — Workflows

Explore common and edge workflows: Identify typical user journeys and uncommon paths. Test each step, transitions, and decision points. If you have enough experience, then hell yeah — use your Oracle knowledge!
Integration points: Check interactions between different system components and third-party services. Ensure data consistency and flow.
Error Handling: Validate how the system handles errors, including user errors, system errors, and edge cases.

I — Inputs

Variety of inputs: Test with different data types, lengths, and special characters. Include valid, invalid, and boundary inputs.
Data formats: Ensure the system can handle different formats like JSON, XML, CSV, etc., if applicable.
Input sources: Test inputs from various sources such as forms, files, databases, APIs, etc.

T — Time

Time-based conditions: Check how the system behaves at different times, such as leap years, time zones, and daylight saving changes. Yes it’s 2024 but you might be surprised how often hidden third parties do not cope with time changes.
Performance testing: Assess the system’s response time, throughput, and load handling capabilities.
Timeouts and delays: Verify the handling of network delays, server timeouts, and user session timeouts.
How much time do you have to do your exploratory testing? What is the priority based on that.

C — Context

User context: Understand different user scenarios, roles, and permissions. Test features specific to each user type.
Environment context: Test across various environments like development, staging, and production. Ensure compatibility with different operating systems, browsers, and devices.
Business context: Ensure alignment with business rules, workflows, and objectives. Validate against business requirements and user expectations.

*H — Heuristics and History
*

Common heuristics: Use known heuristics like RCRCRC (Recent, Core, Risky, Configuration, Repaired, and Chronic) to guide testing. There are so many available online or via Ministry of Testing.
Historical data: Analyse past bugs, user feedback, incident reports and anomaly detection logs — well any logs. Focus on areas with frequent issues or something you think is strange...
Exploratory testing: Continuously adapt testing based on findings. Use exploratory charters to guide and document testing sessions.

I am a Staff Quality Engineer, awesome woman in tech, UN Women Delegate and I believe in the value of curiosity and empathy in testing. I do all my own stunts, love food, travel, my friends, family, music and art.

If you enjoyed this story, please share to help others find it. Feel free to leave a comment — I am open to insight, learning and discussion.