Rosie Sherry
Rosie Sherry
CEO & Founder of the MoTaverse
She/Her
I've been working in the software testing and quality engineering space since the year 2000 whilst also combining it with my love for education and community. It turns out quality, community and education go nicely hand in hand.
I'm here for community as a service and building the best possible tech community out there.
🎓 MoT-STEC qualified
🎂 MoTaBirthday | November 23, 2014
Open To
Teach
Speak
Mentor
Podcasting
Write
CV Reviews
Meet at MoTaCon 2027
Wherever you find yourself copying and pasting, ask whether AI can do it for you. Start small. Learn. Iterate.
In my last How I use AI post, I wrote about replacing spreadsheets with vibe-coded in...
4 Nov
The great thing about humanity is that we love to talk.The terrible thing about humanity is that we love to talk.Yes, I say that in jest, but we must apply our critical thinking skills to industry ...
30 Oct
Spreadsheets are great, until they are not. With spreadsheets scattered everywhere, they are where data goes to die.More recently I've been raising a 'red flag' mote to myself whenever I see a spre...
26 Oct
On my wish list, for quite a while, has been to get better at going to other meetup type events, and conferences too, to be honest. I feel like I have the headspace to do so now.Last week Simon Tom...
26 Oct
Explore AI product risks in part 7 of the AI Risk List from the MoTaverse, focusing on system safety, failures and limitations.
27 Oct
Explore the sixth part of the AI Risk List from Ministry of Testing, focusing on socioeconomic and environmental impacts.
22 Oct
Explore how AI makes community work more human, the case for building data over features, and how bad bots and data centres complicate the picture.
4 Nov
Louise Woodhams, automation and test lead at ZapMap, on finding small joys in testing while burnout, AI pressure and job worries mount.
4 Nov
Zero, One, Many Heuristic
The Zero, One, Many heuristic, also called the count heuristic or 0, 1, Many, is a test design rule of thumb that tests a feature with none, exactly one and many of something. It applies to anything that can be counted, such as records, transactions, users, files or attached devices.
Why it matters: Code that handles collections often has special cases for empty lists and single items, and those cases are easy to get wrong. Testing with zero, one and many quickly covers the values where bugs cluster, without needing an exhaustive set of quantities.
In practice: The tester identifies the things in a feature that can be counted and tries each with zero, one and several instances. The heuristic combines well with others. For example, it can be applied to dependencies, where one object has many others, or to configurations, such as the number of monitors, mice or printers connected. Many can mean a handful, or a large number that tests limits and performance.Examples:
Viewing a customer account with zero, one and many invoices to check how the list, totals and empty state behave.
Deleting the last line item on an invoice, then reading the invoice to see whether it still displays correctly.
Running a report with zero, one and many simultaneous transactions in progress.
Common pitfalls:
Skipping the zero case because it seems trivial, when empty states often cause crashes, divide by zero errors or confusing screens.
Choosing a small number for many, such as two, which misses problems with pagination, sorting or performance.
Is the Zero, One, Many heuristic the same as boundary value analysis? They are related. Boundary value analysis looks at the edges of any range, while Zero, One, Many focuses on quantities of things and the special cases around empty and single collections.
Web3
Web3, also written Web 3.0, is a model of the internet built on decentralised infrastructure, where applications run on blockchains rather than on servers owned by a single company. In a Web3 application the frontend may still sit on a web server, but the backend logic and data live on a blockchain controlled by its network of users.
Why it matters: The shift from central ownership to a shared blockchain changes what testers need to focus on. Code deployed to a blockchain is very hard to change, so a bug that reaches production may have no rollback. Security and smart contract correctness carry more weight than in a traditional web application.
In practice: Testing a Web3 application still includes the familiar layers: unit, integration, functional, usability and performance testing. On top of that, testers typically:
Test smart contracts directly, including deployment, transactions and gas fees.
Use a wallet plugin against a local blockchain to practise real transactions.
Run security checks for known attacks such as double spending, plus penetration testing before go-live.
Check interoperability across networks and protocols.
Examples:
Checking that a token transfer deducts the right amount from a wallet and that the blockchain records the new block.
Seeing what happens when a user switches networks, adds accounts or imports tokens in the middle of a flow.
Testing the validation message shown when a request exceeds the token balance in a wallet.
Common pitfalls:
Assuming that because blockchains are hard to tamper with, the application built on top of them is secure too.
Treating a release like a Web2 deployment and relying on being able to roll back a faulty smart contract.
What is the difference between Web2 and Web3? In Web2, one organisation owns the frontend, backend and database on its own servers. In Web3, the backend and data sit on a blockchain shared by its users, and only the frontend is hosted centrally.
Do testers need to learn blockchain to test Web3? A working understanding helps a great deal, especially of transactions, wallets and smart contracts, because many of the most serious bugs live there.
Web Spider
A web spider, also called a web crawler or simply a spider, is a tool that automatically explores a website by following its links, forms and resources to build a map of every URL it can reach. In security testing, tools such as OWASP ZAP use a spider to discover pages before scanning them for vulnerabilities.
Why it matters: A security scanner can only test the pages it knows about. Functional test suites rarely visit every URL in an application, so forgotten admin pages, old endpoints or rarely used flows can go unscanned. Spidering widens coverage and often reveals parts of a system the team did not realise were still exposed.
In practice: The spider starts from a target URL and follows links, sources and anchors found in HTML, JavaScript and CSS, adding each one to a site tree. Settings such as maximum depth and maximum number of child pages limit how far it goes. A traditional spider parses static content, while an AJAX spider drives a real browser to explore JavaScript-heavy applications. The spider itself does not test anything: the resulting tree is handed to passive and active scanners.Examples:
Running a spider after an automated regression suite to find pages the tests never opened, before scanning them.
Using an AJAX spider on a single-page application where links are generated by JavaScript.
Limiting crawl depth on a large content site to keep the scan within the time available in a CI/CD pipeline.
Common pitfalls:
Letting a spider loose on a site with links that delete or change data, such as "remove" buttons, which can damage test environments.
Expecting a spider to reach pages behind logins or complex forms without configuring authentication or seeding it with known URLs.
Is a web spider the same as a scanner? No. A spider discovers what exists by crawling. A scanner then examines what was found for vulnerabilities, and the two are usually run one after the other.
Weasel Words
Weasel words are vague or noncommittal words, such as could, should, may, might or ideally, that make a statement sound definite while leaving its meaning open. In requirements, specifications and user stories they are a common source of ambiguity, because different people read them in different ways.
Why it matters: Ambiguous requirements are one of the easiest places for bugs to start. If a specification says a field "should" be validated or a page "may" load quickly, developers, testers and stakeholders can each assume something different, and the mismatch only shows up once the software is built.
In practice: Testers read requirements, acceptance criteria and design documents looking for words that hedge or soften commitments. When they find one, they ask what it means in concrete terms: is this mandatory or optional, under what conditions, and how will we know it has been met? The answers are written back into the requirement, often as measurable acceptance criteria. Similar warning signs include fudge such as "this will be resolved later" with no owner or date, and oversimplified terms like "performant" or "user friendly".Examples:
A story says the system "should send a confirmation email", and the tester asks whether a failed email must block the order or not.
A requirement says results "may be cached", prompting a conversation about when stale data is acceptable.
A specification says the page "could support" mobile, and the team agrees which devices and screen sizes are actually in scope.
Common pitfalls:
Accepting soft wording in early drafts and never coming back to clarify it before development starts.
Replacing a weasel word with another vague term, such as changing "should be fast" to "must be fast", without defining what fast means.
Why are words like should and may a problem in requirements? They leave it unclear whether something is mandatory, optional or conditional, so people build and test against different expectations.
How do you fix weasel words in a user story? Ask what the word means in practice, then rewrite it as a specific, testable statement or acceptance criterion that everyone agrees on.
Row Count Check
A row count check, sometimes called a record count reconciliation, is a data migration test that compares the number of rows in each table of the source database with the corresponding table in the target database. Matching counts suggest no records were lost or duplicated during the move.
Why it matters: Data migrations are high-risk projects, and lost or duplicated records may not be visible through the application straight away. A row count check is cheap to run across every table and catches large problems fast, such as a failed batch, a filter applied by mistake or a table that was skipped entirely.
In practice: Testers run a count query against each table in the legacy and destination databases, ideally using a copy of production data, and compare the results side by side. Any mismatch is investigated before further testing continues. Because a matching count does not prove the content is correct, teams follow it with deeper data validation that compares the values themselves to confirm data integrity and accuracy between source and destination.Examples:
A script lists row counts for every table in the old and new databases and highlights any table where the numbers differ.
A customer table shows 120 fewer rows after migration, revealing that records with null postcodes were rejected by the target schema.
A count that is higher in the destination exposes a migration job that ran twice for one table.
Common pitfalls:
Treating matching row counts as proof of a successful migration, when values inside the rows may still be truncated or wrongly mapped.
Comparing counts while the source database is still receiving new records, which produces mismatches that are not real defects.
Is a row count check enough to validate a data migration? No. It is a quick first check, but it should be followed by data-level validation that compares values, data types and mappings between source and destination.
Can row count checks be automated? Yes. A simple script or database tool can run the counts for every table and report differences, making it easy to repeat after each migration run.
Comments
(316)
New Chapter at work
Bug congrats!
Do you practice CUWI (Community Unscripted With Intention)?
It's coming full circle!
TWiQ and TWiC is community unscripted, ftw.
Also, we're in the process of organising a MoT Brighton social, no agenda, just good people and conversation.
Empathy, care and joy in building
I most definitely approve of this type of AI modfication of images, very nice :)
I was in the Pacific Northwest Software Quality Conference 2026 in Portland to present Lynqa
Great to hear.
I'm curious how you've experienced people reacting to a third way of testing, of course it's inevitable, or at least it seems. In the past, the mental mode of thinking about it was either manual or automation. Now it's manual, automation or agentic.
I guess, I'm wondering if it's too much to ask teams to manage all modes, or how can we simplify our approach or thinking around this. It's certainly interesting (and also overwhelming) to think and plan for.
The 99 second talk I didn't get to do at MoTaCon
Love to see this happening.
Next year we will ensure we don't run out of time! :|
