Test IO Community

Now, we can change the <a href="https://academy.test.io/en/articles/2541949-bug-report-requirements#h_cb7d8f65fb" rel="nofollow noopener noreferrer" target="_blank">report environmen</a>t, 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:

Standalone browsers have a complete interface with navigation controls, bookmarks, and settings, while embedded browsers have a simplified interface.

Standalone browsers show the full URL, while embedded browsers may hide or modify it.

Standalone browsers have their own brand, while embedded browsers align with the host app’s branding.

Standalone browsers offer extensive settings, while embedded browsers may have limited access.

Standalone browsers support multiple tabs, while embedded browsers may have different multitasking approaches.

- Standalone browsers have a complete interface with navigation controls, bookmarks, and settings, while embedded browsers have a simplified interface.
- Standalone browsers show the full URL, while embedded browsers may hide or modify it.
- Standalone browsers have their own brand, while embedded browsers align with the host app’s branding.
- Standalone browsers offer extensive settings, while embedded browsers may have limited access.
- Standalone browsers support multiple tabs, while embedded browsers may have different multitasking approaches.

<code>ℹ️ More insights on these browser types on our Academy: <a href="https://academy.test.io/en/articles/8314654-15-greenhorn-newsletter#h_57e0eb3c65" rel="nofollow noopener noreferrer" target="_blank">Standalone Browser vs Embedded Browsers</a>.</code>

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, <code>https://store.nba.com</code>, isn’t the same as <code>https://global.nbastore.com</code>, where the bug was found.

It’s a common mistake, especially when starting, but don’t worry! With practice, experience, and reading our article ❝<a href="https://academy.test.io/en/articles/8133889-understanding-the-structure-of-urls-for-manual-exploratory-testing" rel="nofollow noopener noreferrer" target="_blank">Understanding the Structure of URLs for Manual Exploratory Testing</a>❞, you’ll never repeat this mistake!

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

Just a heads up from our Academy article ❝<a href="https://academy.test.io/en/articles/2541899-devices" rel="nofollow noopener noreferrer" target="_blank">Devices</a>❞ that reminds us not to forget an essential point.

<code>💡 How do you know if your browser is updated? Check this out: ❝</code><a href="https://www.wikihow.com/Update-Your-Browser" rel="nofollow noopener noreferrer" target="_blank">6 Simple Ways to Update Your Web Browser</a><code>❞.</code>

Browsers

Test Your Knowledge: Testing Environment

Reminder of the week!