Heuristic Test Strategy Model Checklist

Leave a Comment / Blog, checklist, Testing / By
glenn-carstens-checklist

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.

Heuristic Test Strategy Model

  • 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
  • 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?
  • 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).
  • 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?

Thanks for going through the list.

Do share comments if you have any ideas and help me improve in the same.

 

☕Buy me a coffee
☕Buy me a coffee