How to Test without Specification

Project specification or simply spec is a document that describes and specifies the project goals, system functionality, requirements for software, UI, and the development procedure, acceptance criteria, marketing plan, particularities of the system maintenance, budget, and the timeline. It is the basis of every software development procedure, and according to the specification, QA team performs the software quality assessment.

But not every project has the documentation available. Why? Because of different reasons. For example, limited budget, small project size, dynamic requirements, close deadlines and so on. Can the project with no or minimal specification omit the testing stage? No, QA services are obligatory for each software product. Testing without specification is possible and I’m going to share with you all hows and whys.

Each member of a project team, e.g., managers, analytics, developers, has a certain vision of software purposes including both business and functional ones. A QA team should gather all available information about the product goals, its target users and location, development model and current stage of product development, release date. All these aspects are already defined but not written in one document. So testers should gather every piece of information step by step to get a clear vision of project specifics. It is a very effective practice to ask the customer for a demo that will clarify the system logic and its expected functionality.

Apart from that, any supporting documents can be used as a specification. This can be FAQ, user stories, help files, backlog, outdated test cases, previous product versions, etc. Due to experience in testing, the QA team can predict the core functionality and system behavior under certain conditions. For instance, every e-shop has a product catalog search with filters and shopping cart.

In order to minimize the risks, the QA team should determine the most critical system areas that will be checked during risk-based testing. Based on high-risk areas and priorities, a QA team can proceed to the preparation of test documentation.

The checklist will help to detect possible gaps in testers’ vision of the product functionality. A proper checklist ensures a wide test coverage.

If a project is not complex, then a QA team performs testing according to the written checklists and do not prepare separate test cases. But if a project is complex and large, then a QA team prepares test cases that include a list of steps to check certain user scenarios and expected result.

When testers complete checking, they prepare Test Summary Report that provides the analysis and general overview of checking activities. The report includes the testing scope, e.g., number of tested and not tested items; metrics, e.g., number of executed test cases, passed/failed tests, status and severity of detected issues; conducted software testing types, e.g., system testing, regression testing.

But to detect product issues does not mean to improve the quality. Both testers and developers should analyze the most buggy areas of the product and find out the reasons of issues occurrence. In this case, continuous learning of the product will be very helpful. And the information received at the very beginning of the project is not enough. The testers should always update their knowledge of the system by communicating with developers, marketing department, stakeholders and other project team members.

The most critical data that should be shared with all project team members is the information about users, specifics of workflow, product attributes, and properties. Besides, planned system changes, further processes, marketing materials, analysis of competitors’ solutions are also important.

So the absence of project specification is not a verdict and a QA team is able to ensure an effective quality evaluation due to constant and well-established communication.

Source: QATestLab