DEV Community: Paradith

The Harness Is Now the Product

Paradith — Mon, 08 Jun 2026 13:30:22 +0000

Has AI engineering just changed (again)?

For the past year, most of us building with AI have been focused on one thing: getting better outputs from models.

We tweaked prompts.
We experimented with temperature.
We added examples, instructions, formatting tricks. I mean my god I have never seen so many copy/pasta prompting articles in my life.

And for a while, that worked. But recently, something has shifted.Across very different companies like LangChain, Anthropic, Cognition, Arena, Hugging Face... the same pattern is emerging.The real engineering work is no longer in the prompt.It has moved up the stack into what surrounds the model. That “something” is what many are now calling 'the harness'. Despite the name it is not a sequel to The Substance...(or is this an early warning sign movie buffs?).

What the harness actually is
At its core, the harness is not a library or a framework. It’s a control loop.Instead of treating the model as a one-shot function, the harness wraps it in a system that continuously manages its behaviour. A typical harness includes:

Task planning (what are we trying to do?)
Context assembly (what does the model need to know?)
Execution (call the model or tools)
Evaluation (was the result good enough?)
Safety and validation (is it allowed and correct?)
Observability (what happened, step by step?)

This is the key difference, the output is no longer just text. It’s also traces, metrics, and outcomes. The system doesn’t just produce an answer. It learns whether that answer was acceptable, and what to do if it wasn’t.

Why this changes how we build

What’s happening here is subtle but important.
We’re no longer building AI features.We’re building AI systems that manage uncertainty. And that requires a different mindset. In traditional software, we assume determinism. If the code is correct, it behaves consistently.

With LLMs, that assumption breaks. The same input can produce different outputs. The model can hallucinate. It can partially complete tasks. It can fail in ways that look plausible.The harness exists to deal with that reality. It doesn’t try to make the model perfect.It builds a system that makes imperfect components reliable.

The clearest way to understand this change is we are moving from generating answers to controlling outcomes.

In the prompt era, success meant “Did the model give a good answer this time?”

In the harness era, success means “Does this system consistently produce good answers across many cases?”

That’s a fundamentally different problem. And it’s one software engineers are already very good at solving, just in other domains.

What engineers need to do differently
The shift to the harness isn’t about learning new tricks. It’s about applying familiar engineering discipline to a new kind of system.
First, we need to stop thinking in single prompts and start thinking in loops. Instead of asking once and accepting whatever comes back, we design flows where the system can evaluate its own output and try again if needed. Patterns like “generate, critique, refine” or “plan, execute, evaluate” become the norm.

Second, evaluation becomes a first-class concern.In traditional systems, tests validate behaviour. In AI systems, evaluations define behaviour. Without a way to measure output quality, you don’t really know what your system is doing. This means building datasets, defining scoring rules, and running continuous checks—not as an afterthought, but as part of the core system.

Third, observability becomes essential. When something goes wrong, you need to see:

what the model was given
what it produced
what decisions the system made

Execution traces in AI systems play the same role that logs and stack traces play in distributed systems. Without them, debugging is guesswork.

Fourth, we need to embrace non-determinism instead of fighting it.
Rather than relying on a single output, harness-based systems often generate multiple candidates and then select the best one using scoring, heuristics, or even another model. It’s less like calling a function and more like running a small experiment and choosing the best result.

Finally, we design for failure from the start. We assume outputs may be wrong, tools may be misused and steps may be incomplete.So we add validation, fallbacks, retries, and sometimes human intervention.

A familiar pattern in disguise...If this all feels familiar, it should.What we’re building now looks a lot like distributed systems with retries and circuit breakers - data pipelines with validation and monitoring AND search systems with ranking and evaluation.

The difference is that the core computation the model is probabilistic. The harness brings it back into the world of engineered reliability.

I think the reason so many companies are independently arriving at the same idea is that eventually, everyone hits the same limits.Prompts stop scaling.Complex pipelines become fragile and the cost of unreliability becomes real. The harness is the natural response to those constraints because it gives you feedback loops, measurable quality and controllable behaviour (they hope).

In other words, it lets you build something you can trust.

If there is one idea to hold onto, the model is not your product.
The system around the model is your product. And just like in traditional computing, the real innovation and the real differentiation happens in that layer above.

I kinda love that we’re finally moving out of the phase where AI feels like magic and into a phase where it starts to feel like engineering again.The teams that succeed won’t be the ones with the cleverest prompts. They’ll be the ones who build strong feedback loops, reliable evaluation systems, observable pipelines and robust harnesses.Because in the end, users don’t care how impressive a single response is.

They care whether the system works.

Reframing Quality Beyond Code: "May the bridges I burn light my way"

Paradith — Wed, 03 Jun 2026 08:33:11 +0000

Quality Engineering and software leaders are traditionally tasked with answering a deceptively simple question: Is this software good enough to ship? For years, the industry answered this through regression testing, automation suites, and staging environments designed to prevent bugs. However, recent insights into R&D data are supporting an important paradigm shift - one that has been challenging us to expand our definition of "quality" from merely ensuring the product is built right to ensuring we are building the right thing..

When analysing engineering throughput, an organisation's experimentation data can look alarming to some on the leadership team. We have all seen those confused faces opening THAT email. If a significant percentage of new features or ideas don't end up fully launched to production, it might look like an engineering bottleneck/waste of time. But from a modern quality perspective, that gap represents the ultimate safety net.

The Three-Tiered Quality Ledger

Velocity is a painful word to some engineers, but in Leadership to really understand the value of engineering velocity, we need that data. We need to move away from binary "pass/fail" or "deployed/abandoned" metrics. Instead, we should anchor our measurement by classifying each completed experiment into one of three outcomes: shipped, rolled back, or informed a decision. If we only measure the "Shipped" bucket, we are severely miscalculating the ROI of our engineering efforts:

Shipped: The clear wins that drive measurable value and user satisfaction.

Rolled Back: The features that hit "guardrail metrics" or triggered negative user feedback, allowing us to safely retreat.

Informed a Decision: The ambiguous, flat, or null results that nevertheless provided critical data to redirect the team's next strategic move.

Shifting from "Bug Hunting" to "Harm Prevention"

The most hopeful part of this framework is the strategic value of the rollback.

In traditional QA/Testing models, letting a feature reach production only to roll it back because it caused user friction or metric regression would be considered a post-mortem-worthy failure. But in a mature experimentation culture, this is intentional, controlled harm prevention.

When an A/B test or progressive roll-out reveals that a feature degrades user engagement or causes a silent regression on a core KPI, the delivery platform has done its job. It has protected the broader user base from an unmitigated product degradation. Organisations without this structured experimentation capability still ship changes at the same rate—but their regressions accumulate silently, resulting in a gradual, unexplained erosion of overall product quality. I see this in old large enterprise companies all the time.

As Quality leaders we can focus and advocate for these three focus areas:

Establish guardrail metrics: Quality cannot just be about system uptime, crash rates, and API load times; it must include user behaviour. If a feature deployment drops a core business metric, that is a quality defect.
Celebrate the rollback rate: A healthy rollback rate means your experimentation safety net is successfully catching product and usability defects before they impact your entire audience.
Measure organisational learning velocity: Work with product management to track how many null or negative tests actually changed a team’s roadmap. If we ran a test, it failed, and we chose not to spend the next two quarters building a dead-end feature, that is a massive engineering efficiency win.

Real-Time Action with AI

When you’re looking at this delicious data, AI could be the key to shifting it from a retrospective reporting tool into a real-time safety net. In the "Rolled Back" bucket, it takes the pressure off the team by automating anomaly detection and instant root cause analysis. We shouldn’t have engineers manually watching dashboards for metric regressions during a roll-out EVER. Instead, use AI to establish a deep baseline of normal user behaviour, so the moment a progressive deployment triggers a micro-deviation, it can act as an automated kill-switch—safely reverting the change and immediately tracing the blast radius right back to the exact feature flag responsible.

Where it really could change the game though, is the "Informed a Decision" bucket. Flat, null, or ambiguous results are notoriously hard to parse, and teams can spend weeks debating what a neutral test actually means. AI could solve this bottleneck by synthesising massive, disparate data streams cross-referencing test results with qualitative data like user session replays, support tickets, and sentiment. By automatically uncovering hidden user patterns or causal factors that a person would easily miss, AI translates inconclusive data into a clear, actionable direction for the next sprint. It stops us from guessing and helps us actually learn.

Operational Example:
[Context Ingested by your AI]
Imagine an LLM core integrated directly into your pipeline to automate that "Rolled Back" safety net.

Raw application error logs (Last 5 minutes)
Live feature flag states: {"enable_checkout_v2": "treatment_alpha", "loyalty_points_tier": "control"}
Recent Git deployment diffs for the microservice

System Prompt:

Analyse the provided logs and deployment context. If a metric regression is correlated with an active feature flag, pinpoint the root cause line, determine the blast radius, and output a valid JSON command to disable the faulty flag.

The Response: Because most AI can ingest thousands of lines of log data and code simultaneously, it bypasses hours of manual triage and immediately returns a clean, actionable payload:

{
  "incident_status": "CRITICAL_REGRESSION",
  "correlated_flag": "enable_checkout_v2",
  "blast_radius": "Mobile Web / UK Users",
  "root_cause": "NullPointerException in payment_gateway.py at line 142 caused by unhandled currency symbol formatting in the new UI layout.",
  "action": "TRIGGER_ROLLBACK",
  "api_payload": {
    "flag_id": "enable_checkout_v2",
    "state": "OFF"
  }
}

The pipeline parses that JSON, instantly hits the feature flag API to kill the variant, and posts the exact root cause directly into the team's Slack channel. Huzzah!! Production is saved in seconds without a single engineer having to open a dashboard. _If I could be bothered I would make a smug meme for this bit. _

At the end of the day, true quality assurance isn't about setting up speed bumps; it’s about protecting the user experience while keeping the engineering engine running as fast as possible, and —it’s a lot more fun to build this way. By ditching the rigid, bottleneck-heavy QA models of the past and just grouping our outcomes into "shipped, rolled back, or informed a decision," we move away from defensive, block-by-default testing. Instead, we get to champion a progressive delivery model where experimentation actually becomes our ultimate safety net.

For the data geeks:
LaunchDarkly (2025) The State of Feature Management and Progressive Delivery.

Microsoft Research (2023) The Science of Experimentation at Scale: Lessons from Experimentation Platforms.

Split Software (2024) The State of Impact-Driven Development and Quality Engineering.

Capgemini, Sogeti and OpenText (2025) World Quality Report 2025-26.

Continuous Delivery Foundation (2024) State of Continuous Delivery Report.

2024 State of DevOps Report: User-Centric Design and Technical Stability.

Web Testing Automation in 2026 _ TL;DR for Testers

Paradith — Wed, 13 May 2026 09:07:32 +0000

Web Testing Automation in 2026
TL;DR for Testers

Testers Collaborating

The Big Shift In 2026, web testing success isn't about more automation - it's about smarter, self-healing, user-centric automation.
Modern web apps (SPA, PWA, SSR) are dynamic, async, and fragile to test. Traditional automation (Selenium-style scripts) break too often and drain team time. On average teams spend 30–40% of testing effort fixing broken tests, not adding value.

👉 Key takeaway:
Testing is moving from script maintenance → intent-based, AI-driven automation (does not mean it is a good thing - do your own research).

🧠 What "Modern Web Testing" Really Means
It's no longer about checking elements - it's about validating real user journeys:

Login → Configure → Purchase → Pay
Across UI + APIs + backend + integrations
In unstable, asynchronous environments

👉 Think: "Can the user complete their goal?", not "Did the button render?"
🧱 The 3 core testing layers
Focus your strategy here:

✅ End-to-End (E2E)

Full user journeys
High value, but fragile & slow

🔗 Integration / API

Validate system interactions
More stable than UI

⚙️ Unit (implied best practice)

Fast, reliable foundation

👉 Guidance: Minimise E2E, maximise lower-level tests (stability + speed).
🚨 Why your tests keep failing
Common root causes:

Dynamic DOM → unstable selectors
Async rendering → timing issues
Caching (PWAs) → testing wrong version
Hydration delays (SSR) → false failures

👉 Result: Flaky tests ≠ real bugs
🤖 Automation Evolution
Old World

Script-based tools (Selenium, Cypress, Playwright)
Rigid, brittle, maintenance-heavy

*New World
*

AI-powered agents
Understand intent
Adapt to UI changes
Self-heal broken tests

👉 Shift from:
"Click this selector" ➡️ to
"Complete checkout flow successfully"

🧠 What AI Changes for Testers
AI automation can:

Generate tests from requirements
Auto-fix broken selectors
Prioritise meaningful scenarios
Reduce maintenance drastically

👉 Outcome:

Less time fixing tests
More time on test strategy & quality insights

✅ Best Practices (2026 ready)

Test user journeys, not UI details

Focus on business-critical flows

Reduce fragile UI dependency

Push coverage toward APIs + lower layers

Keep E2E lean

Only test what truly requires UI

Embrace AI-assisted testing

Especially for:
Maintenance
Test generation
Flaky test handling

Design for resilience

Avoid brittle selectors
Handle async behaviour properly

Focus less on maintaining brittle tests and more on validating what actually matters…your users' ability to succeed. Focus less on maintaining brittle tests and more on validating what actually matters - your users' ability to succeed. Start small:
Prioritise critical user journeys
Reduce reliance on fragile UI checks
Experiment with AI-assisted tools

Because the teams that win won't be the ones with the most tests. They'll be the ones with the most reliable signal on product quality. Teams that embrace AI-driven, intent-based testing will spend less time fixing tests and more time improving product quality. In 2026, testing isn't just a QA concern it's a competitive advantage.

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.