Oswin Losper | QA Engineer

QA Engineer

Hi, name is Oswin, most of my time is being spend on doing automation testing using TestCafe or Cypress automation framework. Before this I did testing on a small scale when I was working as a senior designer & team lead.

In my spare time I enjoy watching Rugby, Football, American Football, hanging out with friends and do some gaming.


Hi, I'm Oswin Losper

Recent Posts

Browsers today have become much more consistent in how they render web applications. The days where developers had to almost to double the amount of work, thanks to the sometimes contradicting behaviour between web browsers, is a thing of the past. However, still different devices and different browsers versions can cause your app not work consistently well or not work in certain parts at all for some users.

Web developers must ensure that their application work well for all user that access the app. This is where cross browser testing comes into play.

![](/images/Cross-Browsing-Banner.jpg)

#### What is Cross Browsing Testing? 

Safe to say that the name kind of gives it away. Cross browser is testing of websites or web application (yes, there is a BIG difference) that take place across various browsers to ensure the behaviour and functionality works as intended.

Cross browser testing is more then simply open us a website or web app in different browsers. This testing includes validating the functionality with the devices and operating systems and verifying how a website or application work under different scenarios that a user can come across in the real world.

Different version of a browser, device or operating system can expose inconsistencies in your app. Some issues are very small inconveniences, like a misaligned text field, styling seems different, but also, some issues can make your app unusable, like a JavaScript error that prevents the site from loading altogether.

It’s impossible to test every possible combination of browser, operating system, device and scenario, it’s still worth the time to validate your web app across the most commonly used web browsers and devices like PCs and smartphones.

#### How to perform Cross Browsing Testing? 

As with most testing strategies, most business handle cross browser testing in two ways: with manual testing and automated tests.

#### Can Cross Browsing Testing Be Done Manually? 

The short answer to this is yes. Organisations can have a few members of a QA team load up their web applications on different operating systems and browsers. They go through various test scenarios to verify that the app works as intended no matter where or under which conditions it’s accessed. Some teams follow a script or have a series of test cases that they go through, while others do more exploratory testing without a set plan. 

Keeping in mind that manual testing only keeps high level of quality for your web applications. As with all manual testing, it can take a lot of time to complete and can be prone to human error. Plus, no one wants to perform the same mundane, repetitive tasks over and over every single day. After a while, this work takes a mental toll on testers, leading to bugs slipping through the cracks.

#### Automate Cross Browsing Testing.

With automated testing, teams can eliminate the boring parts of manual testing. By using tools that automatically go through the same scenarios, automated cross browser testing bypasses the repetitious work of manual testing and free up QA to perform other kinds of high-value work to get the most out of your team’s testing time.

The downside of automated testing is that the scripts can only reveal issues in their area of coverage. If your web application doesn’t have any automated tests going through certain parts of the application, bugs can remain uncovered in those sections until someone stumbles upon them. 

Automated tests also usually do only what they’re told, eliminating the benefits of exploratory testing that a human tester brings to the table.

#### The Best Approach Is Both.

Some teams prefer going all in either manual or automated testing but the ideal approach is a mix of both. Start with manual, like mentioned above exploratory testing to determine the sections with high risk and importance to the business - the areas where your organisation stands to lose customers or money if they stop working. 

With a list of test scenarios to guide you, begin sprinkling in automated tests to handle the most critical and tedious test cases. This balanced plan will give you the best of both worlds.

#### Ways To Build a Cross Browser Test Suite.

Testers have a lot options for creating cross browser test suites.

Documenting scenarios can help QA establish the various test cases needed for manual testing purposes and which browsers to target. The documentation can be as formal as a test plan defined at the start of a new project or as informal as a shared spreadsheet that anyone can modify.

For teams going the automated route, software developers and QA engineers can code a fully functional cross browser test suite, provided the team has the technical ability to do this.

Teams with limited programming knowledge aren’t left behind when it comes to automating tests. A growing segment of the QA world is the rise of low-code or codeless testing tools. These tools allow anyone to easily create automated tests without any coding experience, like recording the steps taken in a web application and replaying it in the future.

#### Top 5 Cross Browser Testing Tools

These days, there’s no shortage of excellent tools to get started with cross browser testing. Just to list a few great choices if you’re looking to get started on a low-code/codeless testing environment:

##### TestCafe Studio

My personal favourite, TestCafe Studio by DevExpress is a cross platform tool powered by TestCafe, an open-source framework focused on end-to-end testing for web applications. It supports most major browsers, including browsers for mobile devices, with almost no configuration required.

##### Test Studio

Test Studio by Telerik is a Windows-based testing application covering desktop and web applications. It provides a full suite of tools with different kinds of automated testing, including web application test recording, cross browser testing and automating test.

##### Ghost Inspector

Ghost Inspector is an online service that captures recorded actions and assertions of a web application through a browser extension, which it then executes on its servers. One issue with this is, the service is currently, available only for Chrome and Firefox.

##### Selenium IDE

Selenium IDE is a recording and playback tool based on the widely used Selenium testing framework. Like Ghost Inspector, Selenium IDE works as a browser extension for Chrome or Firefox and provides a ready-to-use IDE to test your web application.

##### Katalon Studio

Katalon Studio is a cross platform testing tool that uses Selenium under the hood for executing web application tests. Out of the box, it supports test recording functionality across most major browsers.

#### Should Cross Browser Tests Always Be Recorded?

A lot of organisations have concerns about whether they should rely on low-code/codeless testing tools to record their cross browser tests or if they should code them from the ground up. Both options work well, depending on your team and business needs.

As mentioned earlier, teams with fewer technical resources on hand can get started quickly with a low-code or codeless solution. The benefit of this strategy is that anyone can fire up the web browser and record a helpful test that the tool can replay to ensure the application behaves as expected.

Keeping in mind that your web application and cross browser test suite will expand, these tools might start to show signs of growing pains. Depending on the low-code/codeless service used, you might start to get limited as to what the tool can do. For instance, it may become challenging to reuse components or handle complex UIs or find specific selectors on a page. In those cases, coding will often improve the testing experience by allowing testers to refactor and organise test cases in more efficient ways then low-code/codeless testing tools will be able to do.

With that said, it doesn’t mean that low-code and codeless tools will always hit these kinds of limitations. Most modern low-code/codeless testing tools allow editing the tests in different ways, letting testers record their tests and access the underlying code for any necessary modifications. When seeking a low-code or codeless testing tool, the ability to switch between both modes effortlessly should be a key factor to guide your decision.

Regardless of the tool of choice, the most important thing is to have coverage of cross browser testing. It will make development easier by detecting issues quicker and making sure your customers have a smooth experience.


Cross Browser Testing

CROSS BROWSER TESTING

Some Recent Posts

RECENT POSTS

We all know that test automation can work wonders for your business. It can help to reduce cost, save time and effort, get quicker feedback and thereby directly contributing to increased productivity. But in order to get good results from automation testing, you need to avoid mistakes because they can result in wastage of automation efforts.

To make your test automation strategy successful, you have to avoid some common mistakes & failures. With that in mind, here’re some of the common problems with automation testing that you need to avoid to build a long-term successful test automation strategy.

#### Going for 100% test coverage with automation.

It’s necessary to understand the importance that not everything can can be automated. One of the main benefits of test automation is to free up time for testing that must be done manually, i.e. regression or exploratory testing. In other words, it’s about applying testers’ skills to where they provide the most value. 

Automation testing is not there to replace manual testing but rather to help manual testers to free up their time. Sometimes, automating those tests brings minimal returns, or human intervention is required to execute those tests. 

As far as test automation is concerned, there are plenty of ways to go about setting up your test automation suite. You could use a test frame work for testing for cross browser testing & testing functionalities involving any browser interaction. If your team is not skilled with test frameworks like TestCafe, Cypress or Selenium, you can even opt for Play & Record testing to achieve some automation level.

Test automation takes time, and going big from the beginning is not recommended. It would help if you asked the following questions to yourself and your team before moving to test automation:

*   What pain points encountered in manual testing does test automation solve?

*   What kind of tests should be automated (Regression, Sanity, Functional, etc.)?

*   What is the test automation team’s skill-set, and is there any training required before jumping on the test automation bandwagon?

*   Which type of tests should be part of the CI/CD pipeline?

Just automating all manual test cases is one of the major reasons for automation testing failures since that task is ideally not achievable!

Plan for gradually automating your test suite. I recommend starting out by focusing on the flows that are easiest to automate. In most cases, you will find that it’s the relatively simple and very repetitive flows that, by far, take up most of your testing time.

#### Testing for multiple things in one test case.

A test case that is built to verify more than one aspect can fail in multiple ways, for that very reason. This means that if the test case fails, it must be manually inspected to figure out which aspect failed. Sometimes businesses wants to check multiple assertions or validations in one test in order to expand coverage or save time and effort, but the longer a test is running, it increases the chances for timeouts.

Build test cases so that they logically only test one aspect. This way, there is no doubt about what goes wrong when a test case fails. Instead of bundling up multiple tests in one test case, it is best practice to build reusable components with your test. This way, it is easy to reuse the logic contained in other test cases, and the time required to create a new test case is minimised.

#### Using a tool that is not a good technical fit

When looking for a test automation platform, make sure it fits your technical requirements.

A common mistake is to choose a tool based only on your current challenges and automation objectives. This comes with the risk of being stuck with a tool that is not a good technical fit for your business in the long run. I have experienced where management want to use automation frameworks because it’s popular or because other big corporate companies are using them. This a where the advice of an experienced automation engineer is very valuable.

Solution: Implementing test automation is a long term strategic choice and should be handled as such. When evaluating automation tools, look across your business and identify all the applications and technologies that could be potential targets for automation. Identify the scenarios where test cases need to move between technologies, e.g. both web and desktop applications, and select an automation platform that has matching capabilities. And don’t forget cross browsing compatibility. 

#### Inadequate Infrastructure

This is one of the major factors for automation testing failure. Whether you are developing web products for the end-consumers, it would involve interaction with the web browsers. During the early stages of product testing, your team might be using a manual testing approach, which has many limitations. You cannot attain good test coverage since the number of tests may be limited or may not challenge the test infrastructure.

Take the case of cross browser testing; your team can verify your product against limited combinations of web browsers, operating systems, and devices. You can test on browsers installed on your system or machines connected to the network, but you can still not cover the entire spectrum of web browsers (and their different versions). The scenario will change when you shift the focus to automation testing or automated cross browser testing.

When you shift to automation testing, the number of tests being executed will increase significantly. To get the most out of automation, the test infrastructure on which the tests are executed should be responsive but having a responsive test infrastructure comes at a cost. The cost will rise as the product development & test phase progresses; not investing in the infrastructure will hamper the throughput of testing, leading to automation testing failure. 

Your management team should take a conscious decision on whether to have a local test infrastructure or shift to a cloud-based testing where you can leverage the advantages of parallel testing for improved test efficiency.

#### Test Automation In Silos

It is a wrong notion that testing is a separate task. Testing and development should be done hand-in-hand. It should be a part of the development cycle and continuous integration process, i.e., Continuous Integration/Continuous Delivery pipeline. One of the major reasons for an automation testing failure is that the test teams work in silos and have little or no interaction with the other teams in the project. For more on Continuous Integration, read my blog post on the Importance of Continuous Integration For Testing.

Wouldn’t it be a disaster if significant changes happen in the product’s UX when the test team is simultaneously testing that particular product flow?  It will eventually end up in duplication of work and cause an immense amount of frustration within the test team.

Test automation should be a part of the build-test-deploy pipeline. Whether your project uses the traditional water-flow or kanban model or CI/CD for product development & testing, automation testing should be considered a part of the development. 

Automation tests should be integrated into the continuous delivery pipeline, and tests should be executed regularly. Another cause for an automation testing failure is that automation tests are considered necessary during the later stage of product development. 

Doing so would lead to the discovery of critical bugs (functional, non-functional, performance, etc.) at a later point in time. This can delay the product release, which can eventually hurt the business of your business. 

Automation testing has to be part of the planing and should be included into the SDLC. The more you test, the beter chances of generating the best results out of test automation.

#### Flawed Planning And Execution

Shifting gears to test automation involves careful planning and sound execution. You need to have a test plan or strategy in place. The test plan should highlight what you plan to achieve through test automation and expected test coverage. There might be other projects in your business where test automation tools were used. While it is important to understand & document those learnings, you cannot follow a one size fits all approach.

There are many open-source tools, and you might be tempted to use those tools since there is no cost factor involved. Before choosing any open-source tool, you need to look at the tool development history, feedback from existing users, and the current state of development. There is no point in using a deprecated tool since the tool will become unusable one day. 

Since web browsers are an integral part of any website/web application, you should choose a cloud-based cross browser testing platform like TestCafe. Choosing the right automation tool is the key automation plans. You do not want to regret choosing the wrong or inefficient tool during later stages of testing. Below are some of the things that need to be kept in mind while selecting the automation tool.

*   What is the kind of throughput when multiple tests are executed in parallel?

*   Does the automation tool support popular code tracking & bug tracking tools like, Jira, GitHub, Slack, GitLab.

*   How simple is it to integrate the tool in the CI/CD pipeline?

*   What frameworks and programming languages are supported by the tool?

*   What are reporting mechanisms supported by the automation tool and the usefulness of the report’s information?

*   What sort of tests need to be automated?

*   What kind of web browsers, operating systems, and devices would be crucial for test automation?

*   What is the responsibility of every engineer involved in test automation, and what is the kind of skill set required for test suite development?

*   What programming language and test framework will be used mainly for enabling test automation?

*   What is the key focus of test automation, i.e., GUI testing, functional testing, Stress testing, etc.?

*   What kind of CI tools are used for the execution of the builds?

*   What are the target test coverage and some blueprints/plan to attain the test coverage requirements?

There are many other points that need to be considered, but these will depend on your project’s nature & scale. Once you have the answer to the questions above, you might be able to solve 90% of the problems with automated testing.


#### Not Doing Maintenance.

If automation testing is implemented correctly, it will allow companies to ship new features or new products to clients much more frequently and with more confidence.

However, most of those benefits rapidly decrease or even goes away if you don’t take the time to maintain your tests.

Maintenance has to be part of your automation suite, unless your codebase never changes you will have to keep on working and maintaining your automation tests, in order for it to keep up with the latest code as you applications evolves. Work that is been done during the software development process, will effect your existing tests in one way or another. Automation engineers might have to adjust existing ones.


#### Conclusion

Test automation is not rocket science, and the success will largely depend on the test planning & execution. It would be best to avoid automation testing failures discussed above, overlooking these points can result in the loss of the entire test automation task. 

Avoiding an automation testing failure is more of the right mindset needed for project planning, development, and testing – the key pillars of any software product.


Why Your Automation Tests Are Failing | Oswin Losper

WHY AUTOMATION TESTS ARE FAILING

In our ever changing world we live in today, when you take on a new project, a new hobby or just even when you enjoy something, you would want to get the most out of it. It’s the same with automation testing. If you do have an automation suite in your project and you don't have continuous integration (CI) on it, then you not getting the most value out of your automation testing.

#### Learn why it is important for you and your business to implement CI in your project.

A lot of businesses these days are embracing automation testing, and with good reason, I might add. Automation testing help developers and testers to be more effective during the software development process. With automation, teams don’t have to spend their days going through testcases manually, this can lead to quicker turn around times and also help catching issues quickly before the project reach the customers.

However, some companies does have access to an automated test suite, but don’t run them as frequently as they should. They only use the automation test suite on occasions, then on the other occasions they still execute tests manually. These companies are missing out on a big opportunity to get the most value out of their automation test suite. 

Automation can be a very valuable tool that can validate the state of your application at any given time. But if these tests don’t run continuously, their value diminishes rapidly, especially at companies where automation engineers needs to proof the value of automation.

In order to get the most value our of your automation test suite, you will need run them regularly. Ideally, you want to use your automated test suite to ensure that your application still behaves as expected when changes were made to it. And like mentioned above, in the ever changing world we live in today, applications changes occurs frequently. To get the most value, your team can get this automation up and running with a continuous integration system in place.

### What Is Continuous Integration?

Continuous Integration is a development practice to help manage and automate workflows when changes occur in a project. Typical uses for continuous integration environments is building software application, deploying new change and of course running automated tests. 

Continuous integration system plays an important part of a healthy software development pipeline, saving teams a lot of time and effort through the development cycle. Like most things today, there  are plenty of CI services available, from environments you can host on your own to cloud systems.

Most of them are easy to start up and do not require a full time devops team. Most testing tools today can integrate fairly easy with most CI systems, helping you go from local testing to continuous integration testing seamlessly. 

If for some reason your company are still unsure about continuous integration, here are some reasons why may want to consider implementing a CI pipeline in your project.

##### You Will get Faster Feedback Loops

Doesn't matter the size of your project, you will inevitable get bugs. As a project gets bigger, you will add more complexity to it, ever changing requirements and many other issues that increases the probability of errors. It's impossible to avoid mistakes all the time. As good software developers and testers know that the key isn't preventing errors but the time you take to recover from them quickly and efficiently as possible.

When bugs are discovered, it's cheaper to fix to them right away rather than waiting to fix them months down the line. No matter where you are in a project, fixing bugs quickly makes a huge difference in time and money wasted.

The reason being why it's cheaper to fix bug straight away, is that the more time passes between code changes and discovering a bug, the more difficult it is for the developer to go back and find the root cause of it. The work wont be fresh in their mind, so they will have to spend time remembering what they did before.

Also, adding to this, other developers might have worked on the same section in the codebase at a later stage, so on top of the above, the developer will also have to figure out additional changes to the code in an attempt to fix the bug. 

This might seem like a small thing, but I have seen companies ignore bugs until a later stage than months down the line, business justifies the bugs in the project.

By using continuous integration with a well-built automated test suite, this will eliminate most of these issues, because the team will quickly see how a recent change in the project has cause a defect and investigate to fix it quickly. 

If an issue has been found using an automated test suite with continuous integration, an alert can be send to the developer and they can take much more quicker to fix the bug rather than the bug being discovered later down the line. Early detection can help reduce how much effort your developer and tester spend on issues.

##### You'll Increase Accountability With Your Team

Let's be honest, I'm sure all automated testers would love to have an automation test suite that just works, that doesn’t have failing tests, but realistically at some point you will get tests that fail. The failure can be due to recent changes in the code base or it can be a intermittent failure that no one can track down, regardless of the reason, its good to notify the team immediately and in a prominent place, if you don't have reporting in place so that the whole team can see it.

Unfortunately, a lot testers prefer to take the easy way out and push failing tests one side to silent the failure alerts. They either mark the failing tests as pending, delete the result or even silence the notifications. It begins with what seems to be a justifiable moment, like we need to get this build out to the client or management want to see visibility on tests. These decisions usually goes with *'I will fix that next week when I have time’*. Then the inevitable happens, you never get time to fix it and before you know your whole automation test suite losses value.

I hear a lot and have experienced where the health of a project is the sole responsibility of the QA team, in order to have a successfull project all stakeholder within the team has a responsibility to the health of a project. It might be easier for developers and testers to check the state of an application because they are hands on with the project, but for designers and project managers, it might be more difficult for them. If you don't have a way to make the projects health visible to these team members you missing out on a good opportunity to have other contribute with a fresh set of eyes.

You can avoid this problem my using continuous integration to run your test automatically for you. Most continuous integration systems allows you to send alerts when an issue arises. Your continuous integration can send a messages to Slack when a test fails. You can also add additional service to generate reports on a test run, this will help the non technical people in the team to understand the status of the project. This can allow everybody in the team to contribute to the project.

##### You'll Give Testers More Time for High-Value Tasks.

For many testers, they're consist of doing a lot of repetitive tasks daily. Everyday they open up the application they are responsible to test, doing the same steps, clicking buttons, filling in the same forms and checking validations, the same did the day before.

This can become a dull routine. Automated tests can free them up form this cycle, letting continuous integration take care of the repetition. 

The main benefit of having automated tests and setting up a CI service isn't to liberate testers from tedious work, its to free them up to spend more of there work day to do more higher value testing tasks, like more exploratory testing, which can pick up bugs that automated testing wont find and also documentation of testing procedures, test cases and test plans.

Automated tests are very good tool to handle regression testing, ensuring new changes don't break the application, but this will only be able to cover the areas you have planned or wrote scripts for. If there is new features, that was done by the developer and no automation tests for the new feature there will be a gap that is not checked. Continuous integration wont cover for those scenarios, therefor testers time is best spend on the new features that has not automation tests and not the old features. No continuous integration system can go beyond what's defined in the test suite.

A common mistake a lot of companies make, is *‘they want to automate everything’* . They switch all they focus onto automation and ignore all types of other testing. Automation testing wont solve all testing problems teams have. As a project gets bigger and bigger, automation coverage wont cover everything. Freeing up the team to go beyond what continuous integration does will undoubtedly improve the health of your project.

##### You Can Automate More the Just Tests

Yes, this article is mainly focussed on implementing continuous integration to handle the repetitive testing work that most companies are facing with todays software development. 

The most common use case for a continuous integration service is to set up automation testing. However, with that said, if you only using continuous integration for your automation tests, you are only touching the surface.

In modern software development projects, teams have plenty of workflows that can take advantage of continuous integration. These are a few tasks that continuous integration can handle automatically for teams:

*   Building binaries for mobile applications on different platforms like iOS and Android and send it to beta testers.

*   Package web application to docker images, ready to distribute internally or in a public container registry.

*   Run a complete set of tests and, on success, automatically deploy the latest code changes to production.

Continuous integration can help your company perform repetitive tasks that computers can handle better and quicker.

#### Conclusion

A well set up continuous integration environment plays an important part of the modern testing teams. It can help eliminate the repetitive aspects of manual testing and ensure you get the most value out of your automation testing.

Continuous integration can also help the whole teams including the business to get better insight of the project health status and valuable metrics, like graphs and statistics. (We all know business people like graphs).

Developers can also get much more quicker feedback on their new commits and thus reducing tons of effort and time in the development process. Tester will have more time to work on more high value testing scenarios. 

With a continuous integration process in place your entire team will benefit. This will go onto and benefit your customers as well with faster updates, fewer bugs. 

At the end of the day continuous integration wil result in a beter product for everyone.


Home | Oswin Losper

Hi, I'm Oswin Losper

Recent Posts

CROSS BROWSER TESTING

WHY AUTOMATION TESTS ARE FAILING

THE IMPORTANCE OF CI IN YOUR PROJECT