Now, we can change the report environment, which is great. But what if we find a bug and it’s not the browser’s fault?

This can happen because we have different types of browsers that look like regular ones but are part of an application’s interface.

So, for example, let’s say we encounter a problem like this:

It isn’t straightforward to tell whether the screencast is showing a browser that’s on its own or one that’s embedded somewhere. Right?

To not mess up, keep an eye out for these signs:

ℹ️ More insights on these browser types on our Academy: Standalone Browser vs Embedded Browsers.

So you’re all set to start testing, and when you accept the invitation, you get some info that looks like this:

Would this screencast be okay if you submitted or watched it?

Take your time to answer this question, but the answer is NO.

Here’s the deal: The website you thought you were testing, https://store.nba.com, isn’t the same as https://global.nbastore.com, where the bug was found.

It’s a common mistake, especially when starting, but don’t worry! With practice, experience, and reading our article ❝Understanding the Structure of URLs for Manual Exploratory Testing❞, you’ll never repeat this mistake!

💯 Don’t forget to check out the ❝Tips for Navigating Websites Using URL Structure❞ section - it’s really helpful!

Just a heads up from our Academy article ❝Devices❞ that reminds us not to forget an essential point.

💡 How do you know if your browser is updated? Check this out: ❝6 Simple Ways to Update Your Web Browser❞.