“Yikes! The AUT just shut itself down… maybe I clicked the close button without realizing it. Oh well.”
“Rad! Awesome error! …I’ll worry about it later because I promised the devs I would finish testing the feature changes by close of business today.”
“Man, that’s a nasty error…I think I overheard some testers talking about a data refresh. I’m sure the data refresh is causing this error. I’ve got other things to worry about.”
“Dude, I keep seeing this annoying bug. Fortunately, I know the workaround. I’m sure another tester has already logged it. Moving on...”
Note to self,
Stop assuming system errors and strange behavior have already been logged or are due to some QA environment maintenance. What if everyone else is assuming the same thing? Problems get annoying, even for testers (shhhh, don't tell anyone). It feels great to ignore seemingly lesser problems in order to focus on seemly greater problems. But I am being paid to keep track of all problems. Nobody said it was easy.
(That's a picture of a stale hamburger bun. My wife hates when I store bread on top of the refrigerator)
Think about your AUT. Is it possible for a user to see something on their screen that has been altered since the last time their screen refreshed? If so, you’re in luck. You can execute some stale data tests that may be fruitful.
Think of an item that can be edited. Let's call it "ItemA".
- UserA opens the UI, and sees ItemA.
- UserB opens the UI, and modifys ItemA. (now UserA is looking at a stale item.)
- UserA attempts to modify ItemA.
Much of this will depend on how locking is handled by your AUT. However, if you’re creative enough with various types of updates to ItemA, you’ll probably find some unhandled scenarios. For example: can you drag and drop ItemA? Can you delete it? Does ItemB reference a stale version of ItemA (mess with ItemB then)?
If you are able to find a bug with this technique, please share your test as a comment.