/ FCC CUTS

Mnemonics


What are “Mnemonics”?

Mnemonics are rhymes or acronyms, these are used to help memorise long, complicated or complex things. Generally it’s easier to memorise a rhythm or acronym and then use that to fill out the information that is associated with that rhyme or acronym. It is used as a memory aid.

In testing, mnemonics can be used as a starting point to work through ideas on what areas might be impacted by a new feature or a change. They help with asking the right questions and help with identifying the areas and functions that need testing. They can help come up with ideas on where you might find “oracles”, which can be used to identify if the application is functioning as designed.

Below shows a list of some popular testing mnemonics used. These are only a few that I think work well with testing, you can find a lot more testing mnemonics on the internet. I encourage you to search and read through the extensive list that is available. Testing mnemonics are quite personal, as it has to be something you can remember. The best way to use mnemonics is to come up with your own mnemonic that can be applied to your area of testing.

Examples:

SFDIPOT

A famous mnemonics is San Francisco Depot, created by James Bach

  • Structure(what the product is): What files does it have? Do I know anything about how it was built? Is it one program or many? What physical material comes with it? Can I test it module by module?
  • Function(what the product does): What are its functions? What kind of error handling does it do? What kind of user interface does it have? Does it do anything that is not visible to the user? How does it interface with the operating system?
  • Data(what it processes): What kinds of input does it process? What does its output look like? What kinds of modes or states can it be in? Does it come packaged with preset data? Is any of its input sensitive to timing or sequencing?
  • Interfaces(Every conduit by which the product is accessed or expressed): 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 other programs, hard disk, network, etc. System Interfaces: any interface with something other than a user, such as 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(what it depends upon): What operating systems does it run on? Does the environment have to be configured in any special way? Does it depend on third-party components?
  • Operations (how it will be used): Who will use it? Where and how will they use it? What will they use it for? Are there certain things that users are more likely to do? Is there user data we could get to help make the tests more realistic?
  • 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

Note: this was changed from SFDPOT to SFDIPOT read more about the change on Michael Boltons blog site DevelopSense

HICCUPPS

The next popular Mnemonic used is HICCUPPS. This is used to gather Oracles (Oracles can be a way of knowing if the software is design, functioning or returning the correct results), created by James Bach

  • History: We expect the present version of the system to be consistent with past versions of it.
  • Image: We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
  • Comparable Products: We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
  • Claims: We consider that the system should be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals…) or in conversation (meetings, public announcements, lunchroom conversations…).
  • Users’ Desires: We believe that the system should be consistent with ideas about what reasonable users might want.
  • Product: We expect each element of the system (or product) to be consistent with comparable elements in the same system.
  • Purpose: We expect the system to be consistent with the explicit and implicit uses to which people might put it.
  • Statutes: We expect a system to be consistent with laws or regulations that are relevant to the product or its use.

Mobile Testing

COP FLUNG GUN

Testing a mobile device? they have a great mnemonic created by Pradeep Soundararajan

  • Communication: It’s a primary function of a mobile device. This model suggests to check how your app behaves when faced with interruptions such as call, SMS, voice messages etc.
  • Orientation: Check your app behavior during orientation changes. Test how the app functions on orientation change when filling up a form, with keyboard on, while scrolling etc. Also look for ergonomic and usability tests.
  • Platform: A tester needs to be well-versed with the platform he is testing on. Key here is to use that platform’s standard apps. Testers can test things like how the app behaves in rooted/unrooted/jailbroken phones, in various screen sizes and OS versions etc.
  • Function: Check that the app does what it is suppose to do in terms of requirement. Along the way, test scenarios like data entry in forms, change in settings, app interactions.
  • Location: This aspect suggests never to test mobile app sitting in one place. Check the Geo location tracking and its settings, whether it follows tracking guidelines, app behavior when moved out of data connection etc.
  • User scenarios: It’s about thinking real scenarios of how a mobile device and the application would be used by people. Think from an end users perspective and check how power users and novice users would use the app.
  • Network: Mobile applications depend heavily on network. A tester needs to check how the app behaves when moving between Wi-Fi, GPRC, 3G etc and other network related scenarios.
  • Gestures: If your app supports custom gestures, test them properly. Also check for some standard gestures such as swipe, multi touch, pull to refresh etc.
  • Guidelines: As adherence to guidelines is required for app store approval, check that your app follows these guidelines. You also need to track any changes in these guidelines.
  • Updates: This aspects suggests to check one version lower than latest and explore it. After that you can update to latest version to check the app behavior. As updates are frequent in mobile apps, this aspect is critical to the testing of an app.
  • Notifications: Check if the app notification is behaving properly. Test notifications in different scenarios like in locked screen, over various network conditions, in sleep mode etc.

API Testing

ICEOVERMAD

A mnemonic for testing APIs – created by by Ash Winter

  • **Integration: **How will consumers integrate with the service? When will consumers integrate with the service? Is it intended to be rendered on a browser? Output into a file and then consumed?
  • Consumers: Who will be consuming the service? Is the end user a human or a machine? What problem does the service solve for each consumer?
  • Endpoints: What form does the endpoint take and how is it reached? Is it a single endpoint, multiple endpoints or routed through a load balancer. What level of security is applied?
  • Operations: What business functions does the service perform? Can they be mapped to current functions performed via a user interface for example? Are the operations descriptively named and readable for both human and machine? Do the operations handle sensitive data?
  • Volume: Will the service be used at high volume concurrently or sparingly with single high value requests? Are the single transaction sizes an issue? How will API sessions be managed? Is the target architecture clustered?
  • Error Handling: How will the service handle server side errors? How will the service handle client side errors? Are errors informative and/or verbose? If database connectivity is lost is that handled?
  • RESTful: does the service have the characteristics of a RESTful service? Is this desirable in context?
  • Modularity: How are the components of the service distributed? How do they interact? Can they exist on their own? Can they fail over to one another?
  • Authentication: how do users authenticate within the service? What permissions are applicable and how does that change the operation of the service? What levels of security are used? Is data sent or received encrypted?
  • Definitions: What defines the inputs and outputs to the service? Is a WSDL, WADL, XSD, XSLT or Other used? What limits does this impose on the service? Which HTTP methods are used and for what purpose?

Exercise – Getting Started with Mnemonics

Have a go at creating your own Mnemonic. Review already existing Mnemonics, pick out some of the definitions that you find useful in your day to day testing, then add some more, the difficult part is going to be naming your mnemonic.

You will find it a lot easier to remember the mnemonic when you have created it.

Articles on Mnemonics

2012 – Few Hiccupps – James Bach

2001 – SFDPO – James Bach

2009 – Testing Mnemonics – Quality Perspectives Inc.

2015 – Cop Flung Gun – Pradeep Soundararajan