Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Exploratory testing using heuristics

•Download as PPTX, PDF•
•
Michelle Lagare, CSM
Michelle Lagare, CSM

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

1 of 39
Exploratory Testing Using Heuristics
Michelle Lagare QE Is The New QA QE Transition Coach
Exploratory testing, anyone?
Simultaneous learning, test design and test execution - James Bach
Why Exploratory Testing?  Keep up with dev’t. pace  Tester is an integral part of test process  Core of Agile Testing
Advantages  Keep up with dev’t. pace  Tester is an integral part of test process  Core of Agile Testing
Disadvantages ✘ Demands testing expertise ✘ Tester should have system’s domain knowledge ✘ Difficult to reproduce steps ✘ Harder to spot conflicting requirements
“HEURISTIC is a fallible method of solving a problem or making a decision - James Bach & Cem Kaner
Test Design Thru HEURISTICS
“There are different heuristics and we can come up with our own heuristic sets to make it more suitable to the project we’re testing
Test Heuristics in Mnemonics
General Test Techniques Heuristics - DUFFSSCRA
Divide and conquer data Inputs and Outputs  Boundary values  Typical values  Convenient values  Invalid values  Best representatives Domain
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
What can it do? What it isn’t supposed to do? Function
Do one thing after another  End-to-end  Don’t reset the system between actions  Vary timing and sequencing  Parallel threads Flow
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
Compelling story  Meaningful and complex interactions  Someone who matters might do something that matters with the product ‘ ‘ ‘‘ ‘ ‘ ‘ ‘‘ Scenario
Challenge every claim  SLA  EULA  Ads  Specs  Manuals Claims
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
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
Product Element Heuristics - SFDIPOT
Structure Everything that comprises the physical product Code Non-executable files Hardware Collateral
Function Everything that the product does Application Transformation Error-handling Calculation Startup / Shutdown Interactions Time-related Multimedia Testability
Data Everything that the product processes Input Persistent Big / Little Output Sequences / Combinations Noise Preset Cardinality Lifecycle
Interfaces Every conduit by which the product is accessed or expressed User Interfaces API / SDK System Interfaces Import / Export
Platform Everything on which the product depends (and is outside your project) External Hardware External Software Internal Components
Operations How will the product be used Users Common Use Environment Disfavored Use Extreme Use
Time Any relationship between product and time Input / Output Changing Rates Fast / Slow Concurrency
Quality Criteria Heuristics - CRUSSPICSTMPL  Capability  Reliability  Usability  Security  Scalability  Performance  Installability  Compatibility  Supportability  Testability  Maintainability  Portability  Localizability
Project Environment - CIDTEST  Customer  Information  Developer Relations  Test Team  Equipment & Tools  Schedule  Test Items  Deliverables
Test Oracles - MB & JB FEW HICCUPPS  Familiarity  Explainability  World  History  Image  Comparable Products  Claims  User’s expectations  Product  Purpose  Statutes & Standards
 Recent  Core  Risk  Configuration  Repaired  Chronic Regression Testing - Karen Johnson RCRCRC
 Paths / Files  Time and Date  Numbers  Strings  General Data Type Attacks - Elisabeth Hendrickson
 Navigation  Input  Syntax  Preferences Web Test - Elisabeth Hendrickson
 Reply  Sender  Timestamp  List  Links  Language  Length SMS Test - Karen Johnson RSTLLL
 Inputs  Store  Location  Interactions/Interruptions  Communications  Ergonomics Mobile App Testing - Jonathan Kohl I SLICED UP FUN  Data  Usability  Platform  Function  User Scenarios  Network
Create your own Test Heuristics Mnemonics!
Q&A Michelle Chua - Lagare michelle@qeisthenewqa.com @qeisthenewqa qeisthenewqa.com

More Related Content

Exploratory testing using heuristics

Editor's Notes

  1. Something that helps you solve a problem without guarantee
  2. GENERAL COVERAGE
  3. Code structures Hardware components Text files, sample data, help files Paper docs, web links and content, packaging, license agreements
  4. 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
  5. 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
  6. 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
  7. 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
  8. Users - attributes of various users Environment - attributes of physical environment - light, noise, distractions
  9. 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
  10. 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?
  11. Mission - purpose of project Info Dev relations - how you get along
  12. 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”:
  13. 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
  14. GENERAL COVERAGE