Dispute like a pro!
Bug Dispute is an opportunity to request a final review of your bug reports by Dispute Managers if you believe your bug report was rejected or downgraded without any reasonable reason.
However, consider that you should dispute only bugs you are sure about to avoid getting a Dispute block, and always review the information provided to see if you overlooked or misunderstood test cycle information before submitting a dispute.
Let's take a look at some examples!
A good Bug Dispute should contain an official greeting, an (a) explanation of why you contacted the Dispute Managers, (b) why you think the bug report was rejected, (c) additional proof such as attachments and logs about the reported behaviour, and a (d) proposed solution.
Example of a Good Bug Dispute
On the other hand, a negative Bug Dispute would include inappropriate language and failure to follow our reporting rules and guidelines. Being professional and avoiding rude or unprofessional communication is key.
Example of a Bad Bug Dispute
Other mistakes testers make when submitting Bug Disputes are needing more knowledge of the platform's rules and Bug Report Quality standards, sending incomplete or insufficient information, addressing the wrong person, or making false claims.
❝Remember that we see the history of every single bug report. The path of truth and hard work is the only guarantee that we will consider you for possible promotions in the future. If you want to make your career with us, make sure that you are taking the right steps in that direction.❞
ADVICE: Disputing a bug report should be considered a last resort. By following our reporting standards and thoroughly documenting your reports, you can consistently go the extra mile and avoid the need to dispute. In fact, doing so can even earn you likes, along with a bonus.
Search Results Page
The features Search Results Page (SRP) and Search are independent but work together!
A search feature is implemented via algorithms that retrieve items (products on web shops) from a database via specific criteria rendering them on the feature search result pages. These products may or may not meet the query users entered, and it is our job to verify if the users get what they are looking for.
To do that efficiently, we must understand that everything we see on a Search Results Page depends on the algorithm implemented and what information is considered to find the items.
These algorithms consider various information from the items we want to find that can be spotted on the product detail pages of such items. Here is the list of the most common factors:
Product Title: The product’s title is crucial as it provides a concise description and helps search algorithms determine the relevance of the product to the search query.
Product Description: The description provides detailed information about the product, including its features, specifications, and benefits. Search algorithms analyse the description to understand the context and relevance of the product to the user's search.
Product Category and Attributes: The categorisation and attributes assigned to a product are essential for search algorithms to understand its nature and match it to relevant search queries. For example, if a user searches for a ❝laptop,❞ the algorithm should prioritise displaying laptop products rather than unrelated items.
Keywords: Search algorithms analyse the keywords used in the product detail page, including the title, description, and attributes. These keywords help determine the relevance of the product to specific search queries.
Customer Reviews and Ratings: User-generated content, such as customer reviews and ratings, can play a significant role in search algorithms. Positive reviews and high ratings indicate the product's quality and popularity, influencing its position in search results.
Price and Availability: Search algorithms may consider the product’s price and availability. Users often search for products within specific price ranges or prefer items currently in stock.
Images and Videos: Visual content, such as product images and videos, can enhance the product detail page and provide additional context for search algorithms. Algorithms may analyse image tags, alt text, and video descriptions to understand the content better.
Brand and Seller Information: The reputation and authority of the brand or seller can be considered by search algorithms. Established brands and trusted sellers may have higher visibility in search results.
Now that you know how search algorithms work and link to them how items (products) are rendered on a Search Result Page, let's analyse the following scenario on BANANA MOON, one of the environments used for training, and some of you've already tested!
On this website, users are looking up for ❝Hat Summer❞ and the SRP is populating with bikini suits.
The first thought is that something might be wrong with the search feature since the user's query has no relationship with bikinis.
However, if we consider what has been explained before, we must go further to figure out why this item is retrieved by the search algorithm (and many other items on the page!).
One step further!
On the SRP, we click on the first odd item named: ❝HAPPYBAY YELLOW❞ and try to find any trace of the two terms entered. Note that the URL shows https://www.bananamoon.com/us/catalogsearch/result/?q=Hat+Summer; indicating that it'll be retrieved items related to the term ❝Hat❞ and ❝Summer❞ as is adding one to another.
On the Product Detail Page of this item, after clicking on the ❝DESCRIPTION +❞ tab, the user finds the keyword summer as part of the Banana Moon Summer Collection that the bikini item belongs to, explaining why it's part of the items on the SRP.
Therefore, the behaviour that initially looked odd now has a reasonable explanation, and we can dismiss the possibility of a bug to continue testing the environment.
ADVICE: It’s always worth going the extra mile when it comes to work. This could mean a few simple clicks to move from guesswork to professional testing knowledge, but it can make all the difference in setting you apart from the rest.
The reminder of the week!
Device selection! Yes, this common mistake is easily avoidable by double-checking either the test cycle page or the bug form before submitting the report.
On the Desktop, you can identify the requested devices on the right panel:
On our mobile app, testNow, upon tapping on the ❝i❞ button at the top of every test cycle view:
How to avoid this simple but terrible mistake?
❝Before you hit the button Submit Bug, double check if you picked the correct bug type, severity, device and browser. If you select the wrong device and browser, you won't be able to change it after you submit a bug. You would need to delete it and resubmit it (if it wasn't reviewed by TL already).❞
ADVICE: Double-check, triple-check, even quadruple-check if necessary. It’s always better to be safe than sorry.