Manual Testing
Skilled human testers still find the problems that scripts cannot anticipate: confusing flows, unclear messages, awkward edge cases and requirements that do not quite make sense. Renvric provides manual testing built on charters, risk-based test design and clear defect reports, aimed at new features, usability and areas not yet worth automating.
Start your project
Where human testing earns its place
Automation checks what someone already thought to check. A person testing a product learns as they go, notices that two screens disagree, and asks what happens if the user does something nobody planned for. That judgement is hard to script and is exactly where many serious defects hide.
- New or recently changed features whose behaviour is still settling.
- Usability and workflow problems, such as steps that make sense to developers but not to users.
- Exploratory sessions to probe unfamiliar or high-risk areas before automation is designed.
- One-off checks, such as a data migration, a configuration change or an urgent hotfix.
- Devices, browsers and combinations that do not justify an automated rig.
Exploratory testing with charters
Exploratory testing is not random clicking. Each session has a charter, a short statement of what to explore, with what resources and for what kind of risk, for example: explore the refund flow with expired cards to discover how failures are communicated. Sessions are time-boxed, usually sixty to ninety minutes, and end with notes on coverage, questions and defects.
A debrief with the product owner or developer turns those notes into decisions: fix now, clarify the requirement, or add an automated check. Session-based management gives exploratory work the visibility that managers need without scripting it into rigidity.
Designing test cases that are worth keeping
Equivalence classes and boundaries
Inputs are grouped by expected behaviour and tested at the edges, such as the minimum, maximum and just beyond each limit.
Decision tables
Combinations of conditions, such as customer type, region and promotion, are laid out so that no rule is missed or duplicated.
State transitions
Orders, accounts and approvals move through states, so tests cover permitted and forbidden moves, including going back.
Use-case scenarios
End-to-end journeys written from a user's goal, with preconditions, steps and an observable expected result.
Share the outcome you need and Renvric will recommend the smallest useful next step.
Writing and maintaining test cases
A test case should state its purpose, preconditions, steps and expected result in language another tester can follow. Long scripts rot quickly, so Renvric favours short, focused cases for stable behaviour and charters for everything else. Cases are linked to requirements or user stories for traceability, and reviewed each release so retired features do not leave dead tests behind.
Defect reports that get fixed
- A title that names the symptom and the area, not just that something is broken.
- Exact steps, environment, build version and data used, so a developer can reproduce it first time.
- Expected and actual results, with screenshots, video or logs attached.
- Severity, the technical impact, kept separate from priority, the business urgency; the product owner decides priority.
- Regular triage with developers to confirm, defer or reject items and keep the backlog honest.
An illustrative scenario
For example, a team building an insurance claims portal adds a feature letting users upload photos. Automated tests confirm the upload endpoint accepts valid files. A manual tester tries a very large image on a slow connection, rotates a phone mid-upload, switches language, and notices that the confirmation message disappears before it can be read. None of that was in a script.
Working alongside automation
Manual and automated testing are partners, not rivals. Manual work discovers risks and stabilises new behaviour; once a check is stable and repeated, it moves to automation and frees testers for fresh exploration. See test automation for that side, and regression testing for how repeated checks are protected over releases.
Common questions
When is manual testing still the right choice?
Manual testing suits new features, usability review, exploratory investigation, one-off changes and combinations that are not worth automating. It is also the fastest way to learn about an unfamiliar product. It is a poor fit for checks repeated every release, which should move to automation once they are stable and their expected results are clear.
What is exploratory testing and what does it find?
Exploratory testing is simultaneous learning, test design and execution guided by a charter. It tends to find problems scripts miss: inconsistent behaviour between screens, unclear error messages, unexpected state combinations and requirement gaps. Sessions are time-boxed and documented, so findings are traceable and can later become automated checks or clarified requirements.
How are manual test cases written and maintained?
Cases state purpose, preconditions, steps and expected result, and are linked to requirements or stories. Techniques such as boundary analysis and decision tables shape them. They are kept short, reviewed each release and retired when features change. Where a team prefers lightweight documentation, charters and checklists replace detailed scripts for lower-risk areas.
How do manual and automated testing work together?
Testers explore new behaviour and report what matters. When a check proves stable, repeated and deterministic, it is automated and added to the regression suite. Humans then concentrate on fresh features and risks. The two share one test strategy and one defect process, so nothing is tested twice without reason.
How is manual testing reported?
Reports show planned and completed work, defects by severity and area, open risks and questions, and a view against agreed exit criteria. Daily updates suit active release periods, while weekly summaries suit steady work. Defects live in your tracker, such as Jira, so developers see them in the tools they already use.
More services to explore
Reporting covers progress against the plan, defects by severity and area, risks and open questions, shared in whatever format your team already reads. Renvric usually starts by agreeing scope, environments and exit criteria, then runs a first cycle on your highest-risk area. Related options include QA staffing if you want testers embedded in your own team, and user acceptance testing for business sign-off.