Sharing some test heuristics that you can use in different apps your testing!
For more presentation slides related to testing and automation, visit us at qeisthenewqa.com
13. Divide and conquer data
Inputs and Outputs
Boundary values
Typical values
Convenient values
Invalid values
Best representatives
Domain
14. User
Involve the users
Categories and roles of users
What do each user do?
Real user data or real user to test
Simulate a real user
15. What can it do?
What it isn’t supposed to do?
Function
16. Do one thing after another
End-to-end
Don’t reset the system between actions
Vary timing and sequencing
Parallel threads
Flow
17. Overwhelm the product
Sub-systems to be overloaded or “broken”
Challenging data
Large or complex data structures
High loads
Long test runs
Low memory conditions
Stress
18. Compelling story
Meaningful and complex interactions
Someone who matters might do something that matters with the
product
‘ ‘ ‘‘ ‘
‘
‘ ‘‘ Scenario
20. Risk
Imagine a problem
Problems the products could have
Which ones matters most?
How do you detect them?
List of problems and how to reveal them
Consult experts, docs and past bugs
21. Automatic Checking
Check a million different facts
Look/develop tools that can perform lots of actions and check lots
of things
Partially automate test coverage
Partially automate oracles
Change detector
Test data generator
What can make human testing more powerful
24. Function
Everything that the product does
Application Transformation Error-handling
Calculation Startup / Shutdown Interactions
Time-related Multimedia Testability
25. Data
Everything that the product processes
Input Persistent Big / Little
Output
Sequences /
Combinations
Noise
Preset Cardinality Lifecycle
26. Interfaces
Every conduit by which the product is accessed or expressed
User Interfaces API / SDK
System Interfaces Import / Export
27. Platform
Everything on which the product depends (and is outside your
project)
External
Hardware
External
Software
Internal
Components
28. Operations
How will the product be used
Users Common Use
Environment Disfavored Use
Extreme Use
36. Reply
Sender
Timestamp
List
Links
Language
Length
SMS Test - Karen Johnson
RSTLLL
37. Inputs
Store
Location
Interactions/Interruptions
Communications
Ergonomics
Mobile App Testing - Jonathan Kohl
I SLICED UP FUN
Data
Usability
Platform
Function
User Scenarios
Network
Something that helps you solve a problem without guarantee
GENERAL COVERAGE
Code structures
Hardware components
Text files, sample data, help files
Paper docs, web links and content, packaging, license agreements
Application
Calculation
Time-related - Settings, reports, scheduled jobs, time zones
Transformations - font, insertion of images, withdrawing money
Startup / Shutdown - initialization and exiting product
Graphical display and audio
Error handling - detect and recover from errors as well as error messages
Interactions between functions within the product
Testability - functions that can help test the product - diagnostics, log files asserts, test menus
Input
Output
Preset - default values
Persistent - stored internally and expected to persists (option settings, view modes, contents of docs)
Sequences / combinations - word order, sorted vs unsorted data, order of test
Cardinality - zero, one, many, min, max, open limit
Big/Little - variation of size and aggregation of data
Noise - data/state that is invalid, corrupted, produced in an uncontrolled or incorrect fashion
Lifecycle - transformations over the lifetime of a data entity as it is created, accessed, modified or deleted
UI - element that mediates exchange of data w/ user
SI - interface with something other than a user, such as other programs, hard disk, network
API / SDK - programmatic interfaces or tools intended to allow the dev’t. Of new applications using this product
Import / Export - functions that package data for use by a different product, interpret data from a different product
External hardware - hardware components and configs that are not part of the shipping product - system, servers, memory, keyboards, Cloud
External Software - OS, concurrently executing applications, drivers, fonts
Internal Components - libraries, embedded components
Users - attributes of various users
Environment - attributes of physical environment - light, noise, distractions
Input / Output - when input provided and output is created, timing relationship (delays, intervals)
Fast / Slow - fast/slow input, fastest, slowest, combinations
Changing Rates - speeding up, slowing down, spikes, bursts, hangs, bottlenecks, interruptions
Concurrency - more than one thing happening at once (multi-user, time-sharing, threads, semaphores, shared data
Capability. Can it perform the required functions?
Reliability. Will it work well and resist failure in all required situations?
Usability. How easy is it for a real user to use the product?
Performance. How speedy and responsive is it?
Installability. How easily can it be installed onto its target platform?
Compatibility. How well does it work with external components & configurations?
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 will it be 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 publish the product in another language?
Mission - purpose of project
Info
Dev relations - how you get along
Familiarity: The system is not consistent with the pattern of any familiar problem.
Explainability: We expect a system to be understandable to the degree that we can articulately explain its behaviour to ourselves and others.
World. We expect the product to be consistent with things that we know about or can observe in the world.
History: The present version of the system is consistent with past versions of itself.
Image: The system is consistent with an image that the organization wants to project.
Comparable Products: The systemis consistent with comparable systems.
Claims: The system is consistentwith what important people say it’s supposed to be.
Users’ Expectations: The system is consistent with what users want.
Product: Each element of the system is consistent with comparable elements in the same system.
Purpose: The system is consistentwith its purposes, both explicit and implicit.
Statutes: The system is consistentwith applicable laws.
That’s the HICCUPPS part. What’s with the (F)? “F” stands for “Familiar problems”:
Recent - user stories, defect reports, data model changes
Core - roots of the product
Risk - features that rely on other services/components
Configuration - think about the environment
Repaired - retest previous defects
Chronic - areas of the product that frequently have issues