A typical software project lifecycle includes such phases as requirements definition, design, code and fix. But, are you shipping software applications with minimal to no requirements and little time for testing because of time-to-market pressures? Build it, ship it, then document and patch things later.
‘Time-to-market’ products can lack detailed requirements for use by testing because of their huge pressures for quick turnaround time. You don’t want to slow down development, or testing, by having to create detailed documentation. At the same time, the test effort needs to be useful and measurable. So, how can this product be tested to achieve adequate effective coverage and overall stability of its functionality?
A Starting Point
Effective ad-hoc testing relies on the combination of tester experience, intuition, and some luck to find the critical defects. Adequate test coverage involves a systematic approach that includes analyzing the available documentation for use in test planning, execution, and review. Ad-hoc testers can greatly benefit from up-front information gathering, even when they don’t have time for formal testing processes and procedures. Ad hoc testers must still understand how the software is intended to work and in which situations.
Ask developers, testers, project managers, end users, and other stakeholders these basic questions to assist with clarifying the product’s undoubtedly complex tasks:
- Why is the system being built?
- What are the tasks to be performed?
- Who are the end users of the system?
- When must the system be delivered?
- Where must the system be deployed?
- How is the system being built?
Also, the risks of the system need to be identified. (See “Risk Based Testing – Targeting the Risk” for more on this) Correlate these risks against the time available to prioritize the test focuses.
With this information you are well on your way to being able to define an applicable strategy for your upcoming test effort.
User Scenarios
User Scenarios (sometimes called Use Cases) define a sequence of actions completed by a system or user that provides a recognizable result to the user. A user scenario is written in natural language that pulls together from a common glossary. The user scenario will have the basic or typical flow of events (the ‘must have’ functionality) and the alternate flows. Creating user scenarios/use cases can be kick-started by simply drawing a flowchart of the basic and alternate flows through the system. This exercise rapidly identifies the areas for testing including outstanding questions or design issues before you start.
Benefits of creating user scenarios:
- Easy for the owner of the functionality to tell/draw the story about how it is supposed to work
- System entities and user types are identified
- Allows for easy review and ability to fill in the gaps or update as things change
- Provides early ‘testing’ or validation of architecture, design, and working demos
- Provides systematic step-by-step description of the systems’ services
- Easy to expand the steps into individual test cases as time permits
User scenarios quickly provide a clearer picture of what the customer is expecting the product to accomplish. Employing these use cases can reduce ambiguity and vagueness in the development process and can, in turn, be used to create very specific test cases to validate the functionality, boundaries, and error handling of a program.
Checklists
Are there common types of tasks that can be performed on the application? Checklists are useful tools to ensure test coverage of these common tasks. There may be a:
- User Interface checklist
- Error and Boundary checklist
- Certain Features (eg: Searching)
Benefits of creating checklists:
- Easy to maintain as things change
- Easy to improve as time goes by
- Captures the tests being performed in a central location
Checklists used in conjunction with User Scenarios make a powerful combination of light-weight test planning.
Matrices
A test matrix is used to track the execution of a series of tests over a number of configurations or versions of the application. Test matrices are ideal when there are multiple environments, configurations, or versions (builds) of the application.
Benefits of using test matrices:
- Easy to maintain as priorities and functionality change
- Simple to order the functional areas and the tests in each areas by priority
- Clear progress monitoring of the test effort
- East to identify problem areas or environments as testing proceeds
Test matrices provide a clear picture of what you have done and how much you have left to do.
Summary
If you have minimal to no requirements there are still ways that effective testing can be achieved with a methodical approach. You can quickly outline a methodology for yourself that considers the basics of:
- Describing the application in terms of intended purpose
- Identifying the risks of the application
- Identifying the functionality of the application with basic and alternate flows
- Identifying and grouping common tests with checklists
- Identifying how testing records will be traced
- Revisiting and refining each of the above as the project and testing effort proceeds
