Standalone Browser vs Embedded Browsers
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:
User Interface: Standalone browsers have a complete interface with distinct navigation controls, address bar, bookmarks, tabs, and settings. Embedded browsers often have a simplified interface that blends with the host app's design, lacking comprehensive controls.
URL Display: Standalone browsers typically show the full URL in the address bar, while embedded browsers may hide or modify it for a seamless experience, displaying truncated or altered URLs.
Branding and Context: Standalone browsers have their own brand and are separate applications. Embedded browsers align with the host app's branding and context, indicating integration within the app.
Access to Browser Settings: Standalone browsers offer extensive settings for customisation, privacy, and extensions. Embedded browsers may have limited or no access to browser-specific settings, using the host app's settings instead.
Multitasking and Tab Management: Standalone browsers support multiple tabs and provide tab management features. Depending on the host app’s design, embedded browsers may have different multitasking approaches or lack support for multiple tabs.
REMEMBER: Always test on standalone browsers to ensure the correct environment has been tested and avoid unnecessary rejections.
Blurring Out Attachments
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!
Master Bug Report Steps
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.
Good exemplary steps
Enter any search query in the top-right search bar (e.g. “San Francisco”)
Click on “Search Now” or hit the enter key
Scroll down and click on "Sort by"
Select the option "Sort by price: High to Low"
Bad exemplary steps
Observe
Search > Sort > High to low
Observe
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.