What are standalone and embedded browsers, and why do I need to know about it? Good question!

Both types of browsers are commonly used during testing, and we have also integrated them into our TestNOW app.

Embedded browsers or in-built browsers, also known as web browser components, a software modules or components integrated into an application or system. It allows users to access and interact with web content directly within the application without opening a separate, standalone web browser.

Embedded browsers are commonly used in various applications, such as desktop software, mobile apps, and even devices like smart TVs. They provide a way to seamlessly incorporate web browsing capabilities into an application’s user interface, enabling users to view web pages, submit forms, and interact with web-based content without leaving the application environment.

However, standalone browsers, like Chrome, Firefox or Safari, when we open them directly, are different from in-built browsers in terms of capabilities and functionality. Therefore we should avoid testing on them.

You can see the differences when you compare the Academy shown above to the one below.

It can be challenging to distinguish between them, but as professional testers (or becoming one!), It’s crucial to recognise the distinction between embedded and standalone browsers and always test on the latter.

So, here are the indicators to differentiate between standalone browsers and embedded browsers:

REMEMBER: Always test on standalone browsers to ensure the correct environment has been tested and avoid unnecessary rejections.

To produce attachments, the best way is to keep a designated browser window for testing to avoid having unnecessary browser tabs open or showing bookmarks.

However, if you need to retain specific tabs or bookmarks in the browser but wish to conceal sensitive information while reporting bugs, you can follow this professional method for hiding their contents:

It is best to avoid using hand drawings or excessively colourful marks when identifying bugs in attachments. Overly highlighting everything can hinder the purpose of identifying the bug quickly.

REMEMBER: Report faster by saving time by blurring out information that is not needed; keep a designated browser window for your testing!

The steps of a report, as discussed in the second podcast episode about mastering bug reporting: ❝Mastering the Steps of a Bug Report❞, should be written like the steps of a recipe; whoever follows them will get to the same point where the bug is triggered or not.

As per Academy: ❝The first step must contain an indication to access the URL of the landing page provided by the customer in the Access section if you test a website or an indication to open the app (with its name) if you test a mobile app. All further steps should describe your actions from the initial step up to the point when the bug occurs – what buttons you press, what links you follow, and what you enter. Your last step must describe the action that you perform that triggers the bug. Remember that "observing" is not an action taken by the user.❞

This paragraph contains all the necessary information. However, let’s review some examples from our article.

Can you spot what is wrong in this last example?

HINT: The first step does not contain an action to access the URL provided. The third step does not give the actions the mentioned elements need to trigger and has too many actions in a single step. Lastly, the second and fourth steps are redundant and do not help to understand what action should be taken on the website.