By Arik Aharoni, Testuff CEO
In this post, I want to highlight three fundamental challenges that exist in almost every company developing a software product, particularly when it comes to testing. I’m not offering solutions here — the goal is simply to expose the problems.
Because once you understand the root of a problem, it’s much easier to evaluate whether any proposed solution actually helps — or just adds another layer of complexity on the road to releasing a “bug-free” product.
1. Most Companies Don’t Conduct Manual Testing Effectively
Test suites are outdated, test cases aren’t maintained, and manual testing is usually minimal or incomplete.
This may sound blunt, but it comes from over 30 years of experience as a developer, a manager, a certification consultant, and the creator of a test management system. I have worked with dozens of companies, and the pattern is strikingly consistent.
In many companies, especially startups, testing begins with a few basic manual checks during early development. Some unit tests may be added, perhaps a small layer of automation, and then everyone hopes customers won’t encounter too many issues once the product is live.
This isn’t a result of negligence. It’s usually due to limited time, constrained resources, and a lack of long-term focus on sustained testing beyond the initial development phase.
Some may argue that manual testing is becoming obsolete with the growth of automation and AI-based tools. I believe that view is mistaken. Manual testing remains essential, especially for exploratory testing, user interface evaluation, and usability assessments. While automation handles repetitive, predefined tasks efficiently, it cannot replace the human ability to think critically, adapt, and identify unexpected issues.
Exploratory testing allows skilled testers to act like real users, navigating the far corners of an application. This kind of testing often reveals defects that automated scripts miss. Manual testers also gain deep domain knowledge, which is crucial for meaningful validation. Although AI tools may one day bridge this gap, they still fall short of the insight that experienced human testers provide today.
That is why the fact that most companies perform little or poor manual testing is a problem that needs to be addressed. The solution lies in showing teams how to implement effective manual testing practices that are aligned with the development cycle, easy to maintain, and clearly demonstrate their value by improving the overall quality of the product.
2. The QA Team Is Expected to Approve the Release, But Rarely Has Time to Test Properly
Whether it’s an internal QA team, a founder acting as QA, a dedicated hire, or an outsourced vendor, one thing is almost always true: the QA function is expected to give a clear “go” or “no-go” decision before each release.
However, testing requires time, and time is often the one thing QA teams do not have. This leads to a frustrating and familiar cycle:
- Development is rushed, and code quality declines
- Test coverage is limited, and automation does not catch everything
- There is not enough time to test thoroughly, but the team is still expected to approve the release
- As a result, QA gives the green light, even when confidence is low
In practice, we ask QA to ensure the quality of the release without giving them the time or resources to properly evaluate the risks.
Although this may seem like an unsolvable problem, there are a few practical steps that can improve the situation.
The first step is to create a reliable set of manual sanity tests for the most critical areas of the application. These tests should not be detailed, step-by-step instructions like those used in automation. For example, instead of writing “Click login with an empty username and check for an error message,” a sanity test should state, “Log in, place an order, verify it appears in the cart, edit the quantity, and delete the item.” An experienced tester understands what the correct behavior should be and can validate it quickly.
These sanity tests should be designed to take no more than one to two hours to complete. They must be executed before every release. If there is no time to run them, there should be no release.
The second step is to integrate testing earlier into the development process. As features are being developed, testers should have enough time to validate them using unit tests, automation, and exploratory manual testing. Each time a defect is found, it must be documented. A corresponding test, manual or automated, should be created to reproduce the issue. Most importantly, this test must be successfully passed before the release is approved.
By implementing a consistent sanity testing routine and ensuring that known defects are covered by reliable tests, teams can significantly improve release quality, even when time is limited.
3. There Is No Up-to-Date Documentation, and Manual Tests Become the Only Source of Truth
In small systems, the logic behind the product often exists only in the mind of the original designer. There might be early specifications, screen mockups, or a list of initial requirements, but as the product evolves, this documentation usually becomes outdated or disappears entirely.
In larger systems, the situation is often even more complex. It is rare to find a single, reliable source that describes how the system is supposed to behave from both a business and user perspective.
In many cases, the only place where expected behavior is documented at all is in the manual test cases. That is, if those tests exist and are maintained. Although documenting APIs has become easier with modern tools, these specifications are typically technical. They do not explain business logic, workflows, or real user scenarios.
So how can this be improved? There is no perfect formula, but some practical steps can make a significant difference.
The first recommendation was already mentioned earlier: each time a defect is discovered, a corresponding test should be created to reproduce and validate it. This gradually builds a meaningful and accurate set of tests that reflect actual application behavior.
Another helpful step is to involve the customer support team. Every time a customer asks a “how to” question, the answer should be reviewed and, when appropriate, added either to the application’s online help or to the QA documentation. This ensures that real user needs are captured and maintained in a central place.
Manual test cases should focus on core functionality and not get lost in unnecessary details. For example, a test that says “Check that a user cannot purchase more than their current balance, and confirm that the balance updates correctly after a purchase” is more useful than one that simply describes where to click. When business-specific rules are involved, for instance, “VAT is applied only to non-UN citizens”, this logic should be clearly included as a test condition.
With time and consistency, a well-structured set of manual test cases becomes a reliable reflection of how the application is meant to function. Even in the absence of formal documentation, it can serve as a valuable and practical source of truth for the entire team.
So what has improved in the last two decades?
There’s been huge progress in tooling:
- Manual test management tools are simpler, cheaper, and easier to adopt
- Automation frameworks are more accessible
- Development environments and collaboration tools are dramatically better
- Languages and tooling are more server/client-aware and cloud-ready
- CI/CD pipelines, build automation, and deployment processes are mature and widely adopted
But despite all this, the core issues remain unchanged. The pressure to release faster and more frequently keeps growing, while the time available for proper testing, especially manual testing, keeps shrinking.
Reflections on Testing Realities
The challenges discussed here, including ineffective manual testing, limited time for QA to properly assess releases, and the lack of reliable documentation, are not the result of laziness or carelessness. They are symptoms of deeper habits and pressures that shape how teams build and ship software.
Solving them does not depend on new tools alone. It requires a shift in mindset that prioritizes thoughtful testing, early QA involvement, and clear, maintainable knowledge about how the product should behave. These improvements take time, but they begin with awareness and honest discussion.