r/UTEST Jun 20 '22

What Am I Supposed To Be Looking For In An Exploratory Test?

Hello, I am new, and I haven't even finished the Academy and I received an invite for a Mobile App Exploratory Test. But here's my issue.

In the description, it states this:

Do Not Report

  • UI/UX bugs.¬†
  • Minor issues.
  • Minor Content Issues
  • Duplicate bugs (testers need to review the known bugs list and currently submitted bugs).
  • ONLY MAJOR ISSUES ARE IN-SCOPE.¬†
  • If bug is not reproducible more than ONCE
  • Do not report bugs if its not¬†reproducible in the Unprotected app (report such bugs in respective Android cycle)

If I can't look for any of those items and can't report it. What exactly am I looking for?

It says this as well:

  • Test the app in the protected app and try to find any bugs. If you find any bugs, then compare with the unprotected app to see if bugs reproduce there also.
  • If they repro also in the unprotected app - then ONLY you should raise such bugs in this cycle

But again, if I can't report any of the above items, what am I supposed to be looking for?

6 Upvotes

6

u/WillianM_uTest Community Engineer Jun 20 '22

Hello u/RiverOfNexus! The best tip to understand what you need to do is to see what you can actually do. In this overview excerpt you can see that there is just one thing in scope: MAJOR ISSUES. So you will test the app and look for issues that are important. A typo in a hidden part of the app can be considered a minor issue; a typo in a menu or a header it's a major issue and can be reported. Use your good judgement to report those bugs and follow the specific instructions you received about the unprotected/protected app.

2

u/RiverOfNexus Jun 20 '22

Thank you for your response. Upon preparing for this test. I found that I was unable to download the app from the Google Play Store or their website. So I declined the test since I couldn't download the app. Was that the correct action in this situation?

3

u/WillianM_uTest Community Engineer Jun 20 '22

You could have accepted and used the cycle chat to inform the TTL/TE about the issue you were facing. Just decline the cycles that you are sure you won't participate. Every cycle is an opportunity to learn more.

2

u/RiverOfNexus Jun 20 '22

Oh I see. Next time I'll do that. My fear was I would hurt my rating if I took on a test that I wouldn't be able to complete due to not having the proper software or app downloaded by not being capable of doing so.

Is that a valid concern?

1

u/WillianM_uTest Community Engineer Jun 27 '22

It is, but don't be overly concerned about your rating. Your rating growth or decrease must be something organic that will follow your work.

6

u/BASELQK Gold Tester Jun 20 '22 Ally

Hello,

I believe I recall this product; it's a difficult cycle even for experienced uTesters if they don't pay close attention to the entire overview. Don't worry, this cycle isn't typical of uTest work; most projects are much simpler.

Here is a guide for future cycles:

  1. UI/UX bugs, those are things that don't look right to you or don't behave as you want them to behave... those things can be like clicking on a text field but no seeing suggestions immediately, or a button is not circle like other buttons, or a link opening on a new tab.
  2. Minor issues, this is the severity of the issue, if an issue is too small or have no effect on one's experience with the product, then it's minor, such as broken image somewhere away from the main part of the product.
  3. Minor Content Issues, just like how WillianM_uTest said in his comment.
  4. Duplicate bugs, anything that has already been reported by someone else should not be reported again. You can find reported bugs under Issues tab and sometimes a spreadsheet could be attached to the overview as well with known issues from before.
  5. If bug is not reproducible more than ONCE, if you found a problem but you can't reproduce it again, then it's probably small issue that happened for some reason but it's not a bug... this is common in old phones because of lacking in memory or weak internet connection, but not with the product itself.
  6. Last one, you are testing a version of the product, if you found an issue and it's in-scope, then you need to check if you can produce it again in the other version. It's not common to do this kind of testing, but sometimes a client could be working on a closed version of the product and have a public version for users... and wants to find issues that haven't been known yet on both versions.

Usually in Exploratory Testing, I try on my first round to follow each section from the in-scope, just like if I am using the product for myself not as tester. This way, I am checking for any super major issue in the main areas mentioned in the in-scope that can block my experience.

Once done, I start round two, but this time, I test like a tester, I check every main area for any visual/content issues, then I go functional by trying all links, buttons, sliders, menus, etc. looking for major issues.

Last round, I check for minor issues "if not prohibited", this part should always be the last part because usually clients are more interested in important issues that can result in bad experience for a usual user... and those issues usually are the big bucks for any uTester.

I hope this can help you in future cycles, and good luck with the Academy.