It is tempting to start testing as soon as a build is shared. Open the application, try a few things, find some bugs and get moving. Sometimes that is exactly what the situation demands. But when we have even a little time to prepare, a few good questions can save hours of confusion later.
These questions are not meant to become another document that everyone fills in and nobody reads. They are conversation starters. The answers help a tester understand what matters, where problems may hide, and what kind of evidence the team will need before making a release decision.
Testing without context may still find bugs. Testing with context is more likely to find the bugs that matter.
1. Why are we building this, and for whom?
I like to begin with the story behind the product or change. Not the ticket title, but the actual reason for doing the work. If I do not understand the problem we are trying to solve, it is easy to spend time checking details while missing the purpose.
- What problem does this product, feature, or change solve?
- Why is it needed now?
- Who will use it, and in what situation?
- Are there different user types, roles, permission levels, or subscription plans?
- What is each user trying to accomplish?
- Which user journeys are most frequent, valuable, or sensitive?
- What would make users consider the experience successful?
A payroll administrator, an occasional customer, a screen-reader user, and an internal support agent may interact with the same system in completely different ways. Knowing those differences changes the tests we design and the priority we give them.
2. What exactly is included?
“Test the feature†can mean many things. We need to know what changed, which existing areas may be affected, and what the team has deliberately left out. Scope does not have to be perfect at the beginning, but it should be discussed.
- Which modules, screens, services, APIs, jobs, reports, or notifications are involved?
- What are the main business rules and acceptance criteria?
- How do the modules interact with one another?
- What happens before and after the new functionality is used?
- Which existing workflows could be affected by this change?
- What is explicitly outside the current scope?
- Are there known limitations or unfinished parts?
- Are requirements, designs, or technical decisions still changing?
Examples are very helpful here. A sentence such as “users can cancel an order†sounds simple until we ask about shipped orders, partial payments, discount vouchers, inventory, notifications, refunds, and audit history. The interesting behavior is often hiding behind the short sentence.
3. What does quality mean for this product?
Quality is not one fixed standard that can be copied from every other project. For one product, speed may be the biggest concern. For another it may be calculation accuracy, accessibility, privacy, reliability, or ease of recovery. We need to learn what the stakeholders are most worried about.
- What are the agreed quality criteria?
- Which failures would cause the most harm to users or the business?
- What level of performance is expected under normal and peak usage?
- Are there security, privacy, legal, contractual, or regulatory obligations?
- What accessibility standard or user needs must be supported?
- How reliable must the service be, and how quickly should it recover?
- Which defects would block the release, and who makes that decision?
It is also worth asking what is allowed to fail. That question can feel strange, but every release contains trade-offs. A team may accept a minor visual problem while refusing to accept any risk of data loss. Making that difference explicit helps testing focus on the right things.
4. How does the system work behind the screen?
A small change in the interface may trigger a long chain of activity in the background. We do not need to know every line of code, but we should understand enough of the system to identify useful test conditions.
- Where does the data come from, where is it stored, and where does it go?
- How is data validated, transformed, synchronized, or deleted?
- Which third-party services or systems does the product depend on?
- What happens if an integration is slow, unavailable, or returns unexpected data?
- Are there queues, caches, scheduled jobs, background processes, or eventual consistency?
- Are feature flags, configuration values, or permissions controlling the behavior?
- Is any framework, library, or platform-default behavior being used?
Default framework or third-party behavior should not simply be removed from consideration. We may not need to test the external product itself, but we do need confidence that our system has configured and integrated it correctly. The boundary is important.
Questions about test data
- What data is required to exercise the important scenarios?
- Can realistic data be created safely in the test environment?
- Does the data include personal, confidential, financial, or regulated information?
- Which boundary values, historical states, invalid combinations, and unusual volumes matter?
- How can the data be reset so tests remain repeatable?
5. Where and how will we test it?
The expected environment affects both coverage and effort. “It works on my machine†is useful information, but it is not a test strategy.
- Which browsers, operating systems, devices, screen sizes, and locales are supported?
- Does the product need installation, upgrade, migration, or uninstallation testing?
- How closely does the test environment resemble production?
- Which environment differences could affect the result?
- Are the required hardware, software, networks, accounts, certificates, and permissions ready?
- Are logs, metrics, traces, audit records, and useful error messages available?
- Which tools or specialist skills are needed?
- Can tests run independently, or will teams compete for shared environments and data?
Observability deserves special attention. When a test fails, seeing only a generic error message can turn a five-minute investigation into half a day of guessing. Good logs and traces do not merely help developers; they make the product far more testable.
6. What can change, fail, or go wrong?
Happy-path testing tells us that the system can work. Risk-focused testing helps us understand how it behaves when real life interferes.
- What are the biggest product, technical, operational, and business risks?
- What happens when users make mistakes or perform actions in an unexpected order?
- What happens when the network is slow or disappears halfway through an operation?
- Can requests be repeated, interrupted, submitted concurrently, or processed out of order?
- What happens if only part of a multi-step operation succeeds?
- How are errors communicated to users, support teams, and operations?
- Can failed operations be retried safely?
- How will backup, restoration, rollback, and disaster recovery work?
Past incidents and support tickets are excellent sources of test ideas. They show where assumptions have already failed once. I would rather learn from an old production issue than recreate the same lesson in a new release.
7. What is expected from testing?
This question prevents a lot of misunderstanding. Some teams expect testers to verify acceptance criteria. Others expect exploratory testing, regression, automation, performance checks, release reporting, or all of these together. The available time may not support every expectation.
- What decision should the testing help stakeholders make?
- Which types of testing are expected for this release?
- What test documentation or evidence is required?
- What should be automated now, later, or not at all?
- How will defects be reported, prioritized, fixed, retested, and closed?
- How much regression testing is appropriate?
- What time, people, skills, and tools are actually available?
- Who owns the final release decision?
If the requested work is larger than the available time, the answer should not be to quietly test everything less thoroughly. Discuss priorities. Protect the critical journeys and serious risks first, then make the remaining gaps visible.
8. How will the product be released and supported?
A feature can behave perfectly in a test environment and still fail during deployment or in the first hours after release. Testing should connect with the way the product will actually reach users.
- How will the change be deployed, enabled, monitored, and rolled back?
- Will it be released to everyone at once or gradually?
- Are data migrations, configuration changes, or cache resets required?
- What should be checked immediately after deployment?
- Which metrics or alerts would show that something is going wrong?
- Who will respond if a serious issue appears?
- What information will support teams and users need?
Not every question needs an answer
This list is deliberately broad. A two-line internal change does not need the same discussion as a payment platform migration. The point is not to ask every question in every meeting. The point is to notice which questions matter for the change in front of us.
Sometimes an unanswered question becomes a test idea. Sometimes it becomes a risk, an assumption, or a reason to ask for more time. And sometimes the question reveals that the team has not yet agreed on what the product should do. Finding that out before test execution is already useful testing work.
Share you thoughts
To share your thoughts, you can simply fill in the form below and send me an email with your favorite email client/app.