Heuristic Test Strategy Model is designed by James Bach.
I am created a checklist reading and going through the document as per my understanding.
This checklist can be helpful while testing so that you do not miss on any important points.
-
General Test Techniques Checklist General Test Techniques Checklist
Function Testing : Test what it can do
- Test what it can do Identify things that the product can do (functions and subfunctions).
- Determine function success criteria Determine how you’d know if a function was capable of working.
- Test each function individually Test each function, one at a time.
- Verify expected function behavior See that each function does what it’s supposed to do and not what it isn’t supposed to do.
Claims Testing : Challenge every claim
- Identify reference materials with claims
- Analyze and clarify claims
- Test each claim
- Ensure alignment with specifications
Domain Testing : Partition the data
- Identify processed data
- Select test data types
- Test data combinations
- Test data range
User Testing : Involve the users
- Identify user categories and roles
- Define user actions and values
- Gather real user data or simulate users
- Ensure diverse user testing
Stress Testing : Overwhelm the product
- Identify vulnerable subsystems
- Identify related data and resources
- Select challenging test conditions
Risk Testing : Imagine a problem, then look for it
- Identify potential product problems
- Focus on critical risks
- Plan detection methods
- Design tests for risk mitigation
- Consult experts and documentation
Flow Testing : Do one thing after another
- Perform connected activities
- Maintain system state
- Vary timing and sequencing
Tool-Supported Testing : Use tools to make testers more powerful
- Look for or develop testing tools
- Utilize tools for test coverage
- Employ tools for automated oracles
- Use automatic change detectors
- Apply automatic test data generators
Scenario Testing : Test to a compelling story
- Consider product context
- Design tests with complex interactions
- Create scenario-based tests
- Test what it can do
-
Project Environment Checklist Project Environment Checklist
Mission : Your purpose on this project, as understood by you and your customers.
- Define project purpose Why are you testing? Are you motivated by a general concern about quality or specific and defined risks?
- Identify key stakeholders Do you know who the customers of your work are? Whose opinions matter? Who benefits or suffers from the work you do?
- Understand customer needs Maybe the people you serve have strong ideas about what tests you should create and run. Find out.
- Negotiate project conditions Have you negotiated project conditions that affect your ability to accept your mission?
Information : Information about the product or project that is needed for testing.
- Identify project resources Whom can we consult with to learn about this project?
- Gather engineering documents Are there any engineering documents available? User manuals? Web-based materials? Specs? User stories?
- Review product history Does this product have a history? Old problems that were fixed or deferred? Pattern of customer complaints?
- Stay updated on project information Is your information current? How are you apprised of new or changing information?
- Research comparable products/projects Are there any comparable products or projects from which we can glean important information?
Developer Relations : How you get along with the programmers.
- Establish rapport with developers Have you developed a friendly working relationship with the programmers?
- Identify developer overconfidence Does the development team seem overconfident about any aspect of the product?
- Address developer defensiveness Is there any part of the product the developers seem strangely opposed to having tested?
- Maintain effective communication Can you communicate quickly, on demand, with the programmers?
- Solicit feedback on test strategy What do the developers think of your test strategy?
Test Team : Anyone who will perform or support testing.
- Identify test team members Do you know who will be testing? Do they have the knowledge and skills they need?
- Seek advice from experts Are there people not on the “test team” that might be able to help? People who’ve tested similar products before and might have advice? Writers? Users? Programmers?
- Assess team skills Are there particular test techniques that someone on the team has special skill or motivation to perform?
- Evaluate potential contributions from non-testers Who is co-located and who is elsewhere? Will time zones be a problem?
- Consider team location and time zones Are there people not on the “test team” that might be able to help? People who’ve tested similar products before and might have advice? Writers? Users? Programmers?
Equipment & Tools : Hardware, software, or documents required to administer testing.
- Ensure availability of required hardware Do you have all the physical or virtual hardware you need for testing? Do you control it or share it?
- Utilize automated checking tools Do you have tools that allow you to control and observe product behavior automatically?
- Employ analytical tools Do you have tools to create test data, design scenarios, or to analyze and track test results?
- Use matrices & checklists for tracking Are any documents needed to track or record the progress of testing?
- Access engineering data Do you have access to engineering data coming back from the field?
Schedule : The sequence, duration, and synchronization of project events
- Allocate time for test design How much time do you have? Are there tests better to create later than sooner?
- Plan test execution timing When will tests be performed? Are some tests performed repeatedly, say, for regression purposes?
- Coordinate with development milestones When will builds be available for testing, features added, code frozen, etc.?
- Review documentation availability When will the user documentation be available for review?
Test Items : The product to be tested.
- Define scope of testing What parts of the product are and are not within the scope of your testing responsibility?
- Ensure availability of product Do you have the product to test? Do you have test platforms available? Will you test in production?
- Address interoperability needs Are any third-party services required for your product that must be mocked or made available?
- Stay updated on product changes Is the product constantly changing? How will you find out about changes?
- Assess product testability Is the product functional and reliable enough that you can effectively test it?
- Plan for future releases testing What part of your testing, if any, must be designed to apply to future releases of the product?
Deliverables : The observable products of the test project.
- Determine report content What sort of reports will you have to make? Will you share your working notes, or just the end results?
- Clarify purpose of deliverables Are your deliverables provided as part of the product? Does anyone else have to run your tests?
- Follow test documentation standards Is there a particular test documentation standard you’re supposed to follow?
- Decide on report media How will you record and communicate your reports?
- Define project purpose
-
Product Elements Checklist Product Elements Checklist
Structure : Everything that comprises the physical product.
- Code The code structures that comprise the product, from executables to individual routines.
- Hardware Any hardware component that is integral to the product.
- Service Any server or process running independently of others that may comprise the product.
- Non-executable files Any files other than multimedia or programs, like text files, sample data, or help files.
- Collateral Anything beyond that is also part of the product, such as paper documents, web pages, packaging, license agreements, etc.
Function : Everything that the product does.
- Multi-user/Social Any function designed to facilitate interaction among people or to allow concurrent access to the same resources.
- Calculation Any arithmetic function or arithmetic operations embedded in other functions.
- Time-related Time-out settings; periodic events; time zones; business holidays; terms and warranty periods; chronograph functions.
- Security-related Rights of each class of user; protection of data; encryption; front end vs. back end protections; vulnerabilities in sub-systems.
- Transformations Functions that modify or transform something (e.g., setting fonts, inserting clip art, withdrawing money from account).
- Startup/Shutdown Each method and interface for invocation and initialization as well as exiting the product.
- Multimedia Sounds, bitmaps, videos, or any graphical display embedded in the product.
- Error Handling Any functions that detect and recover from errors, including all error messages.
- Interactions Any interactions between functions within the product.
- Testability Any functions provided to help test the product, such as diagnostics, log files, asserts, test menus, etc.
Data : Everything that the product processes and produces.
- Input/Output Any data that is processed by the product, and any data that results from that processing.
- Preset Any data that is supplied as part of the product, or otherwise built into it, such as prefabricated databases, default values, etc.
- Persistent Any data that is expected to persist over multiple operations. This includes modes or states of the product, such as options settings, view modes, contents of documents, etc.
- Interdependent/Interacting Any data that influences or is influenced by the state of other data; or jointly influences an output.
- Sequences/Combinations Any ordering or permutation of data, e.g., word order, sorted vs. unsorted data, order of tests.
- Cardinality Numbers of objects or fields may vary (e.g., zero, one, many, max, open limit). Some may have to be unique (e.g., database keys).
- Big/Little Variations in the size and aggregation of data.
- Invalid/Noise Any data or state that is invalid, corrupted, or produced in an uncontrolled or incorrect fashion.
- Lifecycle Transformations over the lifetime of a data entity as it is created, accessed, modified, and deleted.
Interface : Every conduit by which the product is accessed or expressed.
- User Interfaces Any element that mediates the exchange of data with the user (e.g., displays, buttons, fields, whether physical or virtual).
- System Interfaces Any interface with something other than a user, such as engineering logs, other programs, hard disk, network, etc.
- API/SDK Any programmatic interfaces or tools intended to allow the development of new applications using this product.
- Import/export Any functions that package data for use by a different product, or interpret data from a different product.
Platform : Everything on which the product depends (and that is outside your project).
- External Hardware Hardware components and configurations that are not part of the shipping product, but are required (or optional) for the product to work: systems, servers, memory, keyboards, the Cloud.
- External Software Software components and configurations that are not a part of the shipping product, but are required (or optional) for the product to work: operating systems, concurrently executing applications, drivers, fonts, etc.
- Embedded Components Libraries and other components that are embedded in your product but are produced outside your project.
- Product Footprint The resources in the environment that are used, reserved, or consumed by the product (memory, filehandles, etc.).
Operations : How the product will be used.
- Users The attributes of the various kinds of users.
- Environment The physical environment in which the product operates, including such elements as noise, light, and distractions.
- Common Use Patterns and sequences of input that the product will typically encounter. This varies by user.
- Disfavored Use Patterns of input produced by ignorant, mistaken, careless, or malicious use.
- Extreme Use Challenging patterns and sequences of input that are consistent with the intended use of the product.
Time : Any relationship between the product and time.
- Input/Output When input is provided, when output created, and any timing relationships (delays, intervals, etc.) among them.
- Fast/Slow Testing with “fast” or “slow” input; fastest and slowest; combinations of fast and slow.
- Changing Rates Speeding up and slowing down (spikes, bursts, hangs, bottlenecks, interruptions).
- Concurrency More than one thing happening at once (multi-user, time-sharing, threads, and semaphores, shared data).
- Code
-
Quality Criteria Categories Checklist Quality Criteria Categories Checklist
Capability : Can it perform the required functions?
- Sufficiency The product possesses all the capabilities necessary to serve its purpose.
- Correctness It is possible for the product to function as intended and produce acceptable output.
Reliability : Will it work well and resist failure in all required situations?
- Robustness The product continues to function over time without degradation, under reasonable conditions.
- Error handling The product resists failure in the case of bad data, is graceful when it fails, and recovers readily.
- Data Integrity The data in the system is protected from loss or corruption.
- Safety The product will not fail in such a way as to harm life or property.
Usability : How easy is it for a real user to use the product?
- Learnability The operation of the product can be rapidly mastered by the intended user.
- Operability The product can be operated with minimum effort and fuss.
- Accessibility The product meets relevant accessibility standards and works with O/S accessibility features.
Charisma : How appealing is the product?
- Aesthetics The product appeals to the senses.
- Uniqueness The product is new or special in some way.
- Entrancement Users get hooked, have fun, are fully engaged when using the product.
- Image The product projects the desired impression of quality.
Security : How well is the product protected against unauthorized use or intrusion?
- Authentication The ways in which the system verifies that a user is who he says he is.
- Authorization The rights that are granted to authenticated users at varying privilege levels.
- Privacy The ways in which customer or employee data is protected from unauthorized people.
- Security holes The ways in which the system cannot enforce security (e.g., social engineering vulnerabilities).
Scalability : How well does the deployment of the product scale up or down?
- Deployment How well does the deployment of the product scale up or down?
Compatibility : How well does it work with external components & configurations?
- Application Compatibility The product works in conjunction with other software products.
- Operating System Compatibility The product works with a particular operating system.
- Hardware Compatibility The product works with particular hardware components and configurations.
- Backward Compatibility The products works with earlier versions of itself.
- Product Footprint The product doesn’t unnecessarily hog memory, storage, or other system resources.
Performance : How speedy and responsive is it?
- Speed and Responsiveness How speedy and responsive is it?
Installability : How easily can it be installed onto its target platform(s)?
- System Requirements Does the product recognize if some necessary component is missing or insufficient?
- Configuration What parts of the system are affected by installation? Where are files and resources stored?
- Uninstallation When the product is uninstalled, is it removed cleanly?
- Upgrades/patches Can new modules or versions be added easily? Do they respect the existing configuration?
- Administration Is installation a process that is handled by special personnel, or on a special schedule?
Development : How well can we create, test, and modify it?
- Supportability How economical will it be to provide support to users of the product?
- Testability How effectively can the product be tested?
- Maintainability How economical is it to build, fix or enhance the product?
- Portability How economical will it be to port or reuse the technology elsewhere?
- Localizability How economical will it be to adapt the product for other places?
- Sufficiency
Thanks for going through the list.
Do share comments if you have any ideas and help me improve in the same.