You’re testing a certain part of a product. To mitigate risks, what heuristics do you use to help you make connections between other parts of the product?
Some helpful ideas from replies to this question on LinkedIn.
I use a few things: what else relies on this? What does this rely on? What configurations can affect this? How isolated is this change? How familiar is the developer with the system? Who is going to use this? Why are they going to use this?
That would be my standard list of questions I keep in mind when I’m testing. The rest is keeping an eye out for those “Hmm, that’s odd” moments that can lead to interesting results. – @katepaulk
Use the product. For real. Do a tour test. Oddly enough I’ve seen lot of folks who get focused on only their part. Review with developers in desk check changes in code to identify dependencies. Challenge still faced though is when part of code is changed that is dependency, is to identify where else it is used. That nut I’ve not yet cracked. Cases where change then affected something totally unexpected is a real thing I’ve experienced. Even after trying to identify fall out in desk check. (I know, these are not named after nifty heuristic names) – @finnish
How about you? What heuristics do you use to help you make connections between the various parts of a product? How do you mitigate the risk of having an impact on another part of the product without knowing it?
Function: What other functions does this interact with or call on?
Data: What is the output of this function?
Interfaces: What does it use to interface with the system? (non-user interfaces)
Platform: What hardware does this run on?
Operations: What do users of this part of the product also use?
Time: Does this happen concurrently with another process?
The problem with explaining an exploratory process is that the experience of doing it changes the experience of doing it. And it depends what you’re looking at and in what order. Connecting the database with the rest of the system is different from connecting a function that uses database data to the database. There’s also how you connect it - the data from the database appears on the screen so they are connected. But they also use some drivers and third party systems and data formats and caching and system calls and all sorts of other factors that are involved in that “connection”. It might even be that things are connected indirectly - when you call me my phone rings but it’s more than our handsets that are involved.
So it depends on what a connection really is and what a part really is, which I suppose depends on the necessities of circumstance.
I basically do a tour test. I was lead tester on one of our main products for 10 years and even after ten years, for every new feature, I would look through the menu items to remind me of what the other features of the product were and think about how this new feature would interact with it and I would also open up the preferences (we have a lot) and reread through all of them.