DEV Community: Oswin Losper

CROSS BROWSER TESTING

Oswin Losper — Tue, 16 Aug 2022 17:20:35 +0000

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.

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.

The Importance Of CI In Your Project

Oswin Losper — Fri, 22 Apr 2022 07:13:42 +0000

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.

Challenges Of Automation Testing

Oswin Losper — Wed, 13 Apr 2022 06:03:36 +0000

I think it's safe to say that in todays world, client and stakeholders expect software application they use everyday to provide them with rich experiences. The days of simple applications with a few form fields and store basic data are gone. We live in a world where we have real-time applications with nice designs and multiple services on the cloud.

Because of this applications can become very complex with a lot of moving parts. With this, testing has also become much more complex, with multiple pieces of functionality working differently and stores information in different locations.

Developers and tester needs to make sure that all of the pieces of the puzzle of their applications works well together. Usually these complicated applications are being tested manually, but let's be honest we are humans after all and we do get tired and this is prone to mistakes. One way to get over this mistake is to implement automated end-to-end testing. Along side other automated tests like unit and API testing, end-to-end tests are essential part of the software development lifecycle.

What is end-to-end testing

End-to-end testing, or E2E testing, is to make sure the whole work flow on an entire application works from start to finish. Unlike other kinds of testing, end-to-end testing goes through the whole functionality, not just a certain part. Applications that interact with different services or require complex actions, this type of testing simulates real world scenarios and validates what your customers see.

Benefits of end-to-end testing and Automation

End-to-end tests provide a few benefits over other forms of testing. These tests will simulate a real word scenario that your customers will also experience under normal circumstances. Other tests do not simulate a real world scenario but only a section of the functionality that a user experiences. This kind of coverage helps to ensure that third-party services that aren't in your control work as intended. And thanks to the rise of low-code or code-less testing tools, the barrier to entry for creating end-to-end testing is much lower.

Some teams perform these complex tests manually, going through each step to cover their acceptance criteria. As mentioned earlier, this process take time and this can lead to tiredness and mistakes set to creep in and can even rush to tick all the boxes on the acceptance criteria and just forget to do their work, however more and more businesses are now leveraging the power of automation testing to free them from doing the same stuff over and over again.

Because automated tests does simulate real world scenarios quicker then a human would perform these steps, the entire team can get quicker feedback if something went wrong in there application.

This is just a few benefits of end-to-end automation. For more on this, few my blog post on benefits of automation testing.

Challenges of end-to-end testing

As saying the goes in the perfect world, I think we all want that, but we do live in the real world. With that everything that sounds good also does have its flaws, and its no different for automation testing either, as much as we want it to solve all our testing problems, it doesn’t come with its own sets of challenges. It's important that, when you do start your automation journey that you understand the challenges and have plans in place to fix them.

I have worked with companies that told me, they want to automate everything without thinking of the challenges that lays ahead and if these challenges are not planned for, your automation dream wil soon turn into a nightmare.
Below are challenges most testers face with end-to-end testing and also a few tips on how to overcome each to make you turn into an E2E testing hero.

Challenge #1: Flaky Tests

End-to-end testing has an earned reputation for unstable, flaky tests that fail irregularly. It’s very frustrating, if you run your test suite and everything passes, only to see a test fail for no reason the next day but they passed yesterday and there were no code changes.

End-to-end testing does consist of a lot of moving parts and needs to validate different components through a test run, it is difficult to isolate whats causing the issue. This inconsistency leads to a lot of lost time trying to figure out the root cause of the flakiness since it’s nearly impossible to replicate the failing scenario. And worse of all, flaky tests leads to teams accepting them, ignoring potential issues and decreasing the value of automation tests.

The main challenge of tackling an unstable test suite is to find a solution. You can take a few steps to minimise inconsistent tests. Keep in mind there is no one-size-fits all quick fix for this.

Keep track of test failures: On most automated test suites with flaky tests, you’ll often see the same test cases fail. The tests will give you ideas or clues that can help you iron out the instabilities in the application or the test suite.

Make the most of your testing tools: Most end-to-end tools has build in features that can re-run failing tests. For instance, if you run your test against a live API, you will most probably get time-outs, and you don't want these to be marked as failed. For example, TestCafe has a build in feature called quarantine mode, if a test fails it will run the test again and if it passes on the second attempt it will mark it pass or unstable.

Don’t ignore flaky tests: Ignoring a flaky test will not make the problem go away, it will lead to acceptance of flaky tests and this can lead to actual problems being ignored as well. We all would like to have more time in the day, but set time aside for investigate flaky tests before the problem gets worse.

Challenge #2: Slow Tests

Besides flaky tests, another top complaint is that end-to-end tests are slow and will slow down building times. As mentioned before end-to-end test goes through the entire stack and test every component, both internal and third party. Its just plain unfair to compare end-to-end testing with the speedy unit tests that only test a partial section of your application.
Even with saying that it doesn't make the end-to-end tests go faster, because a slow test suite can drastically slow down the effectiveness of software development and testing teams.

For instance, a lot teams now rely on successful test runs in the continuous integration system before merging code or deploying new features. Having to wait for these build can grind your work to a stand still.

Speeding up your tests can rely on different factors, your architecture of your application, any dependencies or third party services and network connectivity to mention a few. Your strategy will vary according to the application. The following are some steps you can follow to speed up your tests.

Mocking and stubbing functionality: Most applications these days connect to multiple external services or have to perform complex calculations. You can avoid the overhead of these time consuming functions by using mocks to simulate the behaviour of the functionality.

Set up the correct data as needed: Your tests can spend too much time setting up the applications initial state and cleaning things up after a test run. Take time to review the best way to ensure your test has what it needs - nothing more and nothing less.

Build your test to run concurrently: Most end-to-end testing tools like TestCafe, allow you your tests in parallel with one another or use multiple browsers. Your test scenario have to run independently from one another.

Challenge #3: Long-Term Maintenance

One very important aspect of end-to-end testing, is that businesses under estimate the amount of maintenance goes into end-to-end testing. Lot of businesses think, that once you are done with an application feature, the end-to-end testing doesn’t need maintenance, very easy mistake to make but its wrong.

As you add more testcases to your test suite, over time your team may will begin to struggle to keep the test under control. It will become very difficult to add new test cases without effecting existing ones.

A mistake many testing teams make is to automate everything and not thinking about the management of the tests down the road. The focus to automate everything, this mindset leads them down a road where the tests become more detrimental than helpful. To avoid falling into this trap, here a few thing to consider before you begin your end-to-end tests.

Define your test suite structure from the start: At the start of your end-to-end journey take the time to plan test suite structure, for example: you directory structure, helper files, page object models and so on. The time you spend in setting these up will pay of in the long run.

Reorganise as soon as the opportunity presents itself: When you feel some of your files or code could be organised in a better way, do it as soon as you can to keep your test suite tidy at all times. It's quicker to refactor and rearrange your tests while you're working on them.

Know your tools: Knowing what your testing tools can and can't do, this will help shape your decisions on how to write your tests in the best way possible for long-term use.

Challenge #4: Demonstrating Value

Like mentioned above, companies under estimate the amount of time and effort needed to implement end-to-end automation testing. Yes, we do have advanced automated testing tools these days. Each project has its own set of needs, so it's not as simple as deciding to build an automated test suite. Teams need to plan their strategies, choose how to allocate resources and find time to start.

Sadly, many organisations are unaware of how automated testing can help the long term health of their projects. These companies look primarily for a return on their investment.
Since it's difficult to immediately see value of end-to-end testing at the start of a project, it can lead to the organisation abandoning its efforts too quickly without anything to show for it. Also the primary focus is making management loose focus on the long term of their project that they don’t take the time to understand what end-to-end testing is. This leads to management question end-to-end testing value.

With some early preparation work you can begin to show the benefits of what you creating. If you're in a situation where you feel like you need to produce results and demonstrate the value of end-to-end testing, you can take a few measures to show that your work is helping everyone involved in the project:

Make your results visible to the teams: Show the entire team that your end-to-end test suite is working by displaying test run results using tools like Slack, emails, dashboards or any other place the team can see them quickly and effortlessly.

Make your results visible to the teams: Almost all testing tools can generate a well organised report that show how your tests performs.

Keep track of how your tests improve your project: Come up with a list of valuable metrics you can measure for the project, like defects found before a release, development velocity and so on. Once you have a list of metrics, take a baseline measurement and see how they improve over time as your end-to-end test suite expands.

Conclusion

End-to-end testing is a vital part of an application. It complements other forms of testing, such as unit testing or functional testing, by providing additional coverage and exercising the system as a whole. An end-to-end test can uncover issues that other isolated tests might not expose and works best if you have an application with different services interacting with each other.

However, the total amount of coverage provided by end-to-end tests also means increased complexity in managing them. The tests can be unstable and slow, requiring extra attention to keep them running smoothly. It's also challenging to demonstrate immediate value since they take longer to put into action. By following the tips listed in this article, you'll reduce these issues and provide a boost in quality across the entire project.

Automating end-to-end tests can be tricky and hard to show your organisation that they're working. You'll need more time to plan, implement and execute. Once running, you'll also have to ensure they're working for your needs instead of slowing everyone down. But when done right, these tests will save your team countless hours of manual testing and make your application and team better for it.

Maintaining Automation Tests

Oswin Losper — Fri, 28 Jan 2022 05:19:17 +0000

By now most companies (hopefully) must have automation testing or is in the progress to implement automation testing to their project. The benefits of automation testing is clear, refer to my article about, Benefits of Automation Testing.

Automation testing testing will help your organisation build better software quickly and efficiently, regression bugs will be found quickly. 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 maintain your automation tests, in order for it to keep up with 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.

Why maintaining your Automated Tests is important

If you do maintain your automation tests, it will reduce the risks and difficulties for everyone involve on the project. Tests that are not kept up to date increase the possibility of false positives, flakiness and slow test runs. These problems will slowly compound until it eventually reaches a point that its so much and no one either has the time to fix them or no one wants to deal with them. This is where a lot of companies lose trust in automation testing and test become a lot less valuable and is more of burden.

Flipping the switch to a well-maintained test suite. It can help developers and testers to deal with inevitable test automation issues that pop up. Tests will be easier to follow, update and to expand. If tests does fail due to a false positive or because of flakiness, it will take much less time to fix the problem. Well maintained test suites can also have additional benefits across a company. Tests can become a good source of documentation about the project self. New developers and testers can see how the project is supposed to run and behave, help with onboarding quicker.

Easy ways to maintain your automated tests

Maintaining your automated test suite doesn’t have to be an endless and exhausting task.

The best way to keep a high level of quality in your automation strategy is to have a mindset of maintainability while working on the tests. You might get away with building your test suite fast and deal with maintenance later, but it’s always more manageable while you’re in the middle of the work.

Creating an organised test suite from the start will save countless hours and plenty of frustration in the future. The following tips will help you keep your testing work organised and tidy.

Only test what is needed

The most common mistake made by companies is that they try to replace manual testers and therefor try to automate every possible thing. As good of an idea it might sound like, its not. It doesn't mean because you can automate most of your testcases, you should. Some test cases don’t provide enough value to invest the time needed to write and maintain.

Every test that is added to a test suite, requires additional time and resources and the more tests you add the more additional risk and maintenance are required. When new test are added it will also add to total execution time of test runs.

The more tests your have, the more you and your team will need to maintain your test suite. Best is to keep your automate test suite lean to get the most out of each test run

If you’re not clear about what your team should focus on testing, be on the lookout for these places in the application under test:

Features or parts of an application that often break for users: Focus on parts of your application that have a high defect rate, this can increase your applications quality.

Journeys that are difficult to test manually: Test cases sometimes can have very long journey and this can be 'boring' for manual testers and things might slip through. Automate long journeys to avoid human error.

Features that is critical for business rules: It’s very important for areas that contain high value business logic and values to work reliable, to automate these and set up alerts or reports to notify if something goes wrong.
Split your test journeys in to small test cases.

Testing like integration or end-to-end testing, allows you to automate long test journeys with steps from start to finish, and we all know we want to automate everything or as much as we can.

And it is a good idea to cover as much as you can, but also keep in mind, to many long test will make your test suite unreliable and difficult to fix.

In automation all steps you take to run a test has the potential to fail, whether is because of a timeout (if you run against a live api), a change in the application or a unexpected problem. The more steps in a single test makes it more likely to fail. You might regret writing a test that has to many checks at certain spots and figuring out what went wrong becomes a time-consuming process.

Instead of trying to long tests, focus on keeping your test small and specific to what you want to test. If you have shorter tests, it will be easier to debug and fix if needed.

Don't repeat yourself

A very important skill for test automation engineers is to to minimise and eliminate any redundancy throughout the codebase

Most developers are familiar with the Don't Repeat Yourself concept, that states, duplication in logic should be eliminated. I am a believer that this concept should be applied to automation testing as well. However a lot of companies are not taking up this approach because automation testing code is not treated as production code because its not client-facing.

If you have the same set of code twice in your suite, it will slow your team a lot, especially if changes are required on all of those lines. This is a also one of the main reasons that tests can be unreliable and that your test suite is not scalable. So the more re-usbale code you have - you can make a change in one spot and it will fix the issue through out your suite.

To avoid the headaches and hassles caused by code duplication, you should build your test suite keeping the DRY Principle in mind.

Remove test that are doesn't bring any value

Software applications and test suites are living, breathing system. The codebase changes frequently and many reasons, like new feature getting implemented and older feature are being removed, to mention a few.
Changes in an application wont live forever, and it’s the same for test automation. Test can eventually outlive their usefulness and weigh down the rest of the tests, often showing up in the form of a sluggish and broken test suite.

Many automation testers dislike deleting tests from their codebase, especially tests that they’ve written and business also plays a part in this. Sometimes they focus more on test coverage rather than the value of the tests.

Test automation engineers feels a certain closeness to the thing they created and don't want to let go, even when its clear a test doesn't bring value anymore. Instead of removing the test they prefer to comment it out or mark it as pending, hoping the test will somehow make a return and bring value to the test suite in future again.

Below are a few good test that qualify for removal from your test suite

Test that is covering redundant scenarios: If you have test cases that does have long flows to complete, you may not need dedicated test cases for them. For example, if you user journeys included authentication with a login page, there is no need for specific login test case

Tests that cover soon-to-be deprecated functionality: If there are plans to remove certain functionality within a system, it's a good idea to begin removing test cases that is related to that functionality.

Low-value functionality that can be tested manually: Many applications have sections that, while necessary to verify occasionally, aren't as essential to ensure they work at all times. Some examples are submitting "Contact Us" forms, ensuring static pages load properly, and checking content for localisation.

Deleting old test doesn’t mean that you work was not helpful to a project. It means that the project has evolved (which is good) and that the test suite should also evolve with the project. If you notice at anytime that automated test is no longer helpful or doesn’t bring any value, delete it and do not look back, it will improve the performance of your test suite and keep your test suite is good spot and maintenance will also be much more easier.

Fix Broken Tests, don’t delay

Im sure this goes for every daily activity out in the world, delaying until you get time to fix something, however, in the real world, you will never get time.

Ignoring broken test and to continue adding new test cases on top of them is one of the biggest mistakes teams make with their automatic efforts.

When deadlines are coming into the discussion, companies prefer to stay on course to meet the deadline to complete their milestones rather than taking the extra time to fix the broken tests. While the team might think they are speeding up their workflow, they are actually doing the opposite.

Poor code begins to slide into the code base and then the quality starting to slip, slowing down their future efforts for automation more than if they had taken the extra time to fixes the issues promptly.

One of the important keys to a highly maintainable test suite is to fix any problems quick instead of dragging the issue out. Fixing a flaky test quickly that someone pushed into the code base is much more easier than fixing a flaky test six months down.

You will most probably forget about details of that test case and spend a few hours just trying research what the test case was about, then you have to switch context back to your current work flow. It can leads to laziness once a team decide to live with flaky tests in their test suite and it almost impossible to change that state of mind once you start.

If your team is in the habit of ignoring issues in your test suite while adding new functionality, even if there is flaky tests, put a stop to it immediately and change the mentality as soon as possible. Try to establish a work flow cycle where fixing current flaky tests is a priority over adding new ones just for the sake to increase visibility.

This doesn’t mean that if a test breaks, the whole team needs to switch focus and fix the broken tests, make sure some is taking responsibility to get the the build back to a stable state quickly and not ignoring or delaying the problem.

Conclusion

A successful automation suite, starts with long term maintenance in mind. No matter how much time you invest in automation testing, you and your team needs to plans proper maintenance for your test suite. And as in life doing the small stuff like organising and refactor or cleaning up tests feels like a waste of time but will pay off in the long run.

Teams that don’t pay attention to writing maintainable tests from the start will soon find out that fixing broken tests six months down the line will waste a lot of time and the wisely leads to companies abandoning the automation project, saying it doesn’t work.

Maintaining you automated test suite doesn’t have to be a time-consuming process. You can keep your test suite in good condition by planing maintenance and establishing good practices as you go forward with your automation strategy.

Focus on testing only what’s essential and removing tests when they’re no longer valuable. Organise your tests into logical groups and avoid unnecessary duplication with patterns and techniques like the Page Object Model. If your test suite breaks, fix it before proceeding to prevent the situation from getting worse.

Keeping your tests lean and tidy will give you the speed and flexibility to tackle problems and improve your test suite with little to no friction. No one is immune to getting test failures due to always-changing applications. But with a bit of care from the start, a well-maintained test suite can help your organisation develop and deliver high-quality applications with ease for years to come.

What you need to know to become an automation test engineer

Oswin Losper — Fri, 19 Nov 2021 06:45:17 +0000

QA used to consist of two types of testing, namely, manual testing and automation testing.

Manual testers main task was to do regression testing while automation tester was only focussed on writing code and scripts.

The connection between the two was a rare thing, expect when the automation engineers wanted to explore additional test cases to automate.

However in the world we live today, its different. Yes, both manual and automation testing is still important, I am still of the believe that automation is not there to replace manual testing, however the gap between manual and the automation world is getting smaller and smaller.

Its important for manual and automation to work together, but most importantly, to make sure that both sides understands each other tasks. This is a strategy we implement at my current workplace, Wyzetalk, ever since we switched to this approach, workflow has been much more beneficial for all parties involved.

When applying for new jobs, some companies requires that candidates to have experience in both manual and automation testing. This leaves the questions, where do I start to become a automation tester? What skills do I need for this?

I was in the same boat years ago. I started of as a web designer, had no experience in automation testing. Thankfully, like all problems, it not a hard problem to solve, however it requires action on your part.

There are 2 main focus areas to become a successful automation engineer. Keep in mind that requirements can depend on the role and can have additional requirements, but below is a list of basic requirements.

Development Languages

Number one, you need to know a specific language. Like mentioned above, this can depend on the role you are applying for, but most of the time when you know the popular languages like Java or Javascript, it should be enough

You dont have to be a experienced developer but it would be good if you have enough knowledge to write automation tests and scripts. I would recommend the basic fundamentals.

Classes, objects, and methods
Inheritance
Strings, Integers
Interface concept and how to use it
Polymorphism
Arrays (single and multi-dimensional)
Override and overload
Access modifiers
Date class
Role of constructors

These should be enough to start writing automation code.

Framework for UI Automation testing

Unit testing allows us to verify that different modules of our application are operating in the correct manner, but we also need to test applications from a UI end-to-end point.

In a previous article I wrote about, I dive deeper into what you must consider in selecting a automation tool, below is a brief breakdown of breakdown in performing tests on a UI framework:

Creating a new project in your favorite IDE
Setting up dependencies in a build management system
Creating a base class for the framework
Setting up global properties for your project
Implementing the page-object model for your project
Writing test cases for your project
Grouping your test cases
Wiring up a tool for generating reports and screenshots for failed test cases
Running your test cases efficiently by using an automation tool
Analyzing the result of executed test cases

Conclusion

After you finished the framework, one important thing that people are not doing in the automation testing world, is to manage the automation suite, this must to be done in order for the automation tests to bring value and longevity to the quality of your project

The specifics of writing UI automation code would depend on a platform (e.g mobile or desktop) and other factors, but this is basically what you need to focus your attention to.

In a nut shell, write test and report on results of test cases.

I hope this article will give you a better understand of what you need to do to make the switch to be a automation test engineer.

Automation Testing Types

Oswin Losper — Fri, 29 Oct 2021 10:19:24 +0000

In the software testing world, there are two types of testing — manual and automated testing.

The aim for both is to execute test cases and take the outcome and compare with them expected results.

Manual testing is the type of testing that requires more human interactions to make sure is doing what it is supposed to do

Manual testing works very good for specific tests cases, but using manual testing takes up a lot of time and has proved to be ineffective over time when a human needs to do the same stuff over and over again.

In the software development world we life in today there are consistent and successive delve-meant cycle and deployments going out, all of this requires a repetitive tests that needs to run to ensure new updates doesn’t break the system.

This is where automation testing comes in. It takes the repetitive side away from the human. Since automation has became a very important step in the development life cycle, many different types of automation has been introduced and with this many robust testing tools have allowed automation testers to simply write new scripts and replay test-suites over and over.

This goes with saying, it frees up a lot of time, valuable resources and boost business productivity.

Below is a list of the most popular types of automation tester that any testers should know and be well prepared for it before starting your automation journey.

Different Types of Automation Tests

Type of testing

There are 2 main types, functional and non-functional:

Functional: is a type of software testing that validates the software system against the functional requirements/specifications. The purpose of Functional tests is to test each function of the software application, by providing appropriate input, verifying the output against the Functional requirements

Non-functional: is defined as a type of Software testing to check non-functional aspects (performance, usability, reliability, etc) of a software application. It is designed to test the readiness of a system as per nonfunctional parameters which are never addressed by functional testing. A good example of non-functional test would be to check how many people can simultaneously login into a software.

Below is a list of the most popular types of automation tester that any tester should know and be well prepared for it before starting your automation journey.

Smoke Tests: Smoke tests are a type of Functional test that only covers the most important features of software to ensure that it could be further tested without “catching fire,” hence the name Smoke Tests.

Integration Tests: Integration tests take all the individual pieces and functionalities of software and test them together as a whole to guarantee smooth operation between all of them.

Regression Tests: Regression tests run a combination of Functional and Non-functional tests to check if the software has “regressed” after changes has been made

Security Tests: Security tests cover Functional and Non-functional tests that screen the software for any vulnerabilities. They reveal weaknesses and any potential exploit in a system.

Performance Tests: Performance tests are often Non-functional tests that help testers evaluate criteria like responsiveness and stability as the software handles load and stress.

Acceptance Tests: Acceptance tests are Functional tests that determine how acceptable the software is to the end users. This is the final test a solution must pass before it could be released.

Phase of testing

Unit: As the name implies, this phase the individual components of a software. Unit testing is the very first phase of testing, usually done by developers before handing the software off to testers, but it could also be automated.

API: Application Programming Interface (or API for short) acts as the “middleman” between all of the systems that your software uses, and thus, is then tested after the development process to ensure smooth integration between systems and software. This phase of testing is fairly flexible; it could be conducted either before or after the UI phase, this can be done by either the development or the testing team.

UI: Last but not least, User Interface (UI testing) is what the end users see and interact with and, this is usually tested at the very end of the process. This phase of testing is run by testers after the UI of the application has been drafted for the most authentic replication of user experience possible. This is where the business logic of the software is examined and optimised.

Selecting a automation tool

Oswin Losper — Fri, 22 Oct 2021 07:16:26 +0000

Today there are lots of different options to choose from, be it a laptop, phone or tablet. In the world we live in today, we have so many options that sometimes the choices we make are not necessarily the right ones but the popular ones. For automation tools it's no different.

Depending on what your needs are, your automation testing tool must be compatible with many different aspects of your team and company.

The best automation tool available on the market does not guarantee the best outcome for your team, it has to be the right one.
Importance of Test Automation

I'm seeing a lot of different opinions on whether automation testing is needed or whether manual testing is falling behind. Regardless of the opinions, I think the importance of automation testing is still sometimes overlooked because companies are not adopting proper procedures for it.

In the world we live in, the software market demands good quality applications at speed. With that being said the application must reach production in a shorter time, but the quality needs to be better. The growing demand has added to the growth of automation tools by allowing QA teams to execute faster and more accurate test cases.

Test types that require the same repetitive actions, like regression testing, need to be automated.

Regular changes in software will increase the cost in terms of time and manual testers to run these tests manually all the time. Therefore, automating tests is the smarter and more efficient choice.

Choose the right tool for you, not the best.

Regardless of the advantages test automation has, they don't work the same for all companies or projects. Choosing the wrong tool might be detrimental for you in regards to the time, effort and financial resources wasted.

Choosing the right tool takes time and effort at first, but it is a must for your team to automate tests efficiently in the long run. The success of automation testing lies in identifying the right tool for different needs and demands.

Types of Automation Testing Tools

Open-source automation tools

These tools are free platforms that allow users to access and use their source code. Users can opt to fully adopt the code or modify it to suit their testing needs. This type of tool is free of charge and developed by the community. Open-source tools are the top choice for many automation testers with a programming background due to its free access and the ability to customize advanced test cases.

Commercial automation tools

Commercial tools are produced to serve commercial purposes and usually distributed via subscription plans. Users must purchase a paid license to use the software. Compared with open source software, this kind of tool usually has more premium features and thorough customer service that completes the whole testing process for companies or enterprises.

Custom framework

There are specialised projects that a single open-source software or fixed commercial testing tool cannot fulfill the requirements. They are mainly due to differences in their testing processes and testing environments. In such cases, teams need to develop customized software on their own. The custom framework is much more complicated than the two other solutions and can be deployed by technical experts.

How to Select the Right Automation Tool for Your Project?

Get to know your needs.

Before you proceed with the selection process, consider whether test automation is the right direction for your team.

So when is Test Automation necessary?

When there are a lot of repetitive test cases to be done.
When there are frequent regression testing
When the team has to simulate a vast number of test cases in a quick time frame.
When the UI is stable

The criteria for Automation Testing Tool

Does your team possess the necessary skills to use the tool?

Automation testing is much more technical than manual testing. Many of the automation tools, especially the open-source types, does require some level of coding knowledge to write and execute test scripts.

What features to look for?

Requirements will vary from team to team, there are some key factors that you should always take into consideration when choosing a suitable automation tool.

Supported platforms
Applied application under tests
Development languages
CI/CD integration capabilities
Reporting functionality

How difficult is script maintenance and re-usability?

A significant factor that escalates the total cost for test automation is script maintenance. Pre-written scripts in automation testing are fragile by nature. The ideal automation tool should come with capabilities to reduce such effort. On the other hand, script re-usability saves you and the team a great deal of time for similar test cases as you can reuse test scripts.

How are the integration capabilities?

The selected automation tool must be able to integrate to CI/CD pipelines and external platforms to ensure the testing continuity.

Summary

The process of selecting an automation tool can be challenging but rewarding in the end. Once you get the right tool that fits your teams, you will be able to use test automation and get the best results with less resources needed. And Remember, Choose the right tool for you, not the best or popular one.

Why I Chose testCafe

Oswin Losper — Tue, 28 Sep 2021 05:34:09 +0000

Choosing a framework to run your automation test against can be tricky. This can cause a lot of uncertainty. There are a lot of good tools out there to write and run end-to-end tests.

Choosing your automation tool does depend on your product or project and what you want to get out of automation testing.

When I started at Wyzetalk, it was no different. I had to go through the same as a lot of automation testers, R&D, the right approach for automation testing and which tool will bring the most value.

One of our main goals for choosing a tool was for everybody in QA and in the Dev team to pick and run tests in multiple browsers and had to be open source.

One of the challenges we faced was, Wyzetalk offers a white label product, meaning the same set automation tests need to run for all versions of our products.

The tool I found that checked all the boxes was TestCafe

During the time using TestCafe, it has proven to be a great addition to our testing. Below are a few reasons why I chose TestCafe as our end-to-end testing framework.

Free and open-source
testCafe is an open-sources project that is owned by DevExpress and its free (Let's be honest, business would like that)

No Selenium WebDriver needed
Selenium is the standard when it comes to testing automation for web apps. However , it does come with issues. It lacks necessary features like automatic waits for dynamic content or needs extra set up for mobile browser testing. TestCafe runs its tests via a web proxy, and the tool contains tons of features out of the box.

Tests are written in JavaScript
If you're building a modern web application, your team is most probably familiar with JavaScript. With TestCafe, your entire team can write and maintain the end-to-end test suite without having to learn a new programming language.

Lots of built-in functionality
As mentioned, TestCafe has a ton of features ready to use without additional setup. Among the main features it includes are the ability to test with different browsers and configurations, run tests concurrently, and independently manage user roles.

Browser Support
TestCafe detects all browsers running on your machine and provides the option for to use all browsers to run your tests on, because of this, no needs to install and manage web drivers.

Debugging
UI tests are not easy to create. You have to pick the exact elements to interact with, run the test multiple times, and make changes until you have a reliable test. This means that whatever tool you use should support good debugging methods. TestCafe has you covered in this department. It has a debug mode where you can continue execution step-by-step to see what happens at each point of the test. You can also open the developer tools to investigate during the test run. There’s also a live mode where browsers remain active while you work on tests. They’ll automatically rerun once you make code changes

Reliability
If you ask any automation tester who has had experience using Selenium, they will tell you how much time they spent carefully placing the right waiting mechanism in place to ensure tests don’t break. TestCafe has mechanisms for automatic waits for actions, selectors, assertions, page loads and redirects. This leads to more reliable tests.

Running test concurrently
Running your test suite concurrently using different browsers. For instance, you can tell TestCafe to run the tests in Chrome and MS Edge at the same time.

Continuous integration pipeline integration
TestCafe integrates easily with CI providers. Since it doesn’t need you to configure any external web drivers or libraries like Selenium does, the only prerequisite is to have the required browsers installed in the CI server.

There are other tools out there with these features e.g, the Cypress framework and Nightwatch. It all depends on what you need for your company or project so take the time to explore alternatives.

Below is a demonstration on how easy it is to get testcafe up and running

Getting Started

TestCafe is using javascript for its primary language. I would recommend taking a basic javascript course before starting.

Before we start, you do need to have a few prerequisites. Your dev environment must have node.js and npm.

Before beginning your end-to-end testing journey, you need to decide where you want your source code to be, you can either choose to have it in the same repo as your project or inside a separate repo. There is no right or wrong answer here, it all depends on how your team works.

So, to get started you run, npm install testcafe (please note, node.js and npm must be installed). This command will install testcafe inside the directory of your choice.

You can install testcafe globally by running npm install -g testcafe

And there you go testCafe is installed, now we can start writing tests

To start, let's do a basic test, we will load www.oswinlosper.co.za and see if an element exists on the website.

Open the file, and inside we'll write our first test:

import { Selector } from 'testcafe';

fixture `Oswin Home Page`
   .page `https://wwww.oswinlosper.co.za`;

test('Check if main page loads', async t => {
   const header = Selector('header')
       .withText('Why I Chose TestCafe.')
   await t

   .expect(header.exists).ok();
});

Let's break the test down:

import { Selector } from "testcafe": In the first line of our test, we're importing the Selector function provided by TestCafe. This function is one of the main functions you'll use for identifying elements on the current page. You can use the Selector function to get the value of an element, check its current state, and more.

fixture("Oswin Home Page"): TestCafe organizes its tests with fixtures. This function, automatically imported when running the test, returns an object used to configure the tests in the file. The object is used to set the URL where the tests begin, run hooks for test initialisation and teardown, and set optional metadata. Here, we're setting a descriptive name for the tests to help identify the group during test execution.

page("https://www.oswinlosper.co.za/"): The page function allows you to specify the URL that loads when each test run starts.

test("Check if main page loads", async t => { ... }): The test function provided by TestCafe is a function that has two main parameters - the name of the test, and an async function where we'll write our test code. The async function from the parameters includes a test controller object, which exposes the TestCafe Test API.

const subtitle = Selector("header").withText(...): Here we're using the Selector function previously mentioned. We're using the function to tell TestCafe to look for an 'header' element on the page that contains specific text. In this example, this is the heading of this article. We'll store this select in a variable to use it later in our assertion.

await t.expect(header.exists).ok(): Finally, we have our assertion for the test. This assertion checks that the selector we specified previously exists on the page using the exists function on the selector. We verify that the test passes with the ok() function, which is part of TestCafe's Assertion API.

It's important to have an async function for the test. This allows TestCafe to execute its test functions without having to wait for a page to load or an element to appear.

Run the test

You can run the test from a terminal by calling a single command where you specify the target browser and file path.
TestCafe allows you to run the tests on more than one browser, we'll just run it on Chrome. All you need to do to run the test is use the following command:

testcafe chrome test.js

When you run the command, TestCafe will open up your browser and set up the web proxy for the test to run. It will open up the website and execute the steps inside the test. The results will then be displayed in the terminal

Cleaning up test by re-using code

With time, as your test suite grows bigger and bigger, selectors will take up a large amount of space in your tests.

The example above is fairly simple, so keeping selectors inside the test won't be a problem, but as the tests get bigger with more features this can become a hindrance.

Another issue with Selectors, you have to use them in multiple places. For example, if the front end devs make a change to an element, you will have to change selectors everywhere, even if the selectors are used in different files and that can be a very painful process.

To handle these issues, TestCafe recommends using the Page Model pattern.

The Page Model pattern allows you to abstract the selectors from the tests. Instead of writing the selector in the test, you define the selector separately and refer to it when needed. This way, you can keep all of your selectors in one place. If the element changes in the application, you only need to update it in a single place.

It also helps improve the readability of your tests. For example, instead of writing a selector for an input field like input[type='text'], you write a more descriptive name like loginPageModel.emailInput. Anyone reading the test should have a clear idea about that element immediately without having to look it up.

import { Selector } from "testcafe";
class HomePageModel {
  constructor() {
    this.header = Selector("header").withText(
      "Why I chose TestCafe"
    );
  }
}

export default new HomePageModel();

This code is a plain JavaScript class. Inside the class constructor, we'll create class properties for each element selector that we want to use. These properties are what we'll access inside our tests, as we'll see soon. Finally, after defining our class, we export a new instance of the class, so it's ready to use in our tests.

Once we create our page model class, let's put it to use in the home page test:


import homePageModel from "./page_models/home_page_model";

fixture("Oswin Losper Home Page")
.page(
  "https://www.oswinlosper.co.za/"
);

test("Check if main page loads", async t => {
  await t.expect(homePageModel.header.exists).ok();

});

There was a bit of cleanup that happened in this test. The main change was importing our newly created page model class, creating a new instance set as homePageModel.

With this in place, we can access our selectors through the page model's properties. The code where the selector was previously specified is gone, and replaced, we call the selector with homePageModel.header. Since we're no longer calling the Selector function, the import function that we had previously is gone.

Summary

This article is a quick summary of how easy and useful it is to install TestCafe and to run end-to-end tests using TestCafe. No need to install multiple dependencies.

As for writing tests, it's straightforward. The example above barely scratches the surface of what TestCafe can do. It's a powerful tool that has a lot more functionality. Some of the more useful functions are below:

Running your tests in headless mode (when running in a pipeline). Chrome and Firefox allow you to run TestCafe tests in headless mode, meaning that the browser runs without any UI. This functionality is crucial for running tests on a continuous integration service, where there's no graphical interface.

Lots of different actions for interacting with your application

TestCafe has many useful ways to debug tests, like taking screenshots and videos, client-side debugging using the browser's developer tools, and pausing tests when they fail so you can interact with the page for investigation.

The Benefits of Automation Testing

Oswin Losper — Thu, 16 Sep 2021 12:28:17 +0000

The Benefits of Automation Testing.

Web applications today are getting more complex on a day to day basis. Stakeholders and clients have much bigger expectations of what web applications need to do these days. The days are gone having simple informative websites. Today a much more complex page with real time responses seems the new normal.

With that being said, web pages today consist of a lot of moving parts therefore testing needs to be up to date all the time, and this makes end-to-end testing more valuable than ever.

Bigger web applications means developers also need to work on test coverage but this mostly takes shape in the form of unit and functional tests, but unit and functional tests usually check certain parts of code in isolated instances.

But these parts often have to interact with other areas of an application. These kinds of tests won't point out if there's an issue with how two or more parts of the system work together.

This is where end-to-end testing comes in, they give the confidence that the entire application is functioning and working well together, with all these moving parts, not to mention end-to-end testing can also check that all your third party services are working.

Usually, manual testers will test the entire application and if any, third party services. But like most applications today, they are big and very complicated and it takes up a lot of time and resources for manual testers, this is where automation testing comes in.

Keep in mind that automation testing should not replace manual testing, but just regression testing. It's very important to find a balanced testing approach. A balance automation testing approach can free up the manual tester and they can focus and spend their time on other high-value work like exploratory testing.

Manual testing should be minimized at all costs. Test automation increases overall software development efficiency. I thought I would share some benefits I have picked up along the way in the years of doing automation testing.

Faster Feedback Cycle
With manual testing, feedback on new features can take a while. Automation helps to reduce the feedback cycle. Test automation is very useful because it helps you identify problems or bugs early in the development phase, which increases the team’s efficiency.
Team Saves Time
By automating your test it also improves communication with other departments and product owners who rely on the results of these tests. These departments can easily check reports generated of the automated tests and see what’s happening, and let's be honest, business like to see green on charts.
Higher Test Coverage
Manual testing puts a limit on how many tests they can do on a daily basis. Automation allows you to spend time writing new tests and adding them to your automated test suite. This increases your test coverage, so that more features can tested and therefore you will get a higher test coverage.
Reusability of Test Suite
To start, building your automated test suite is a challenge. But, once you have figured out your suite, it’s very easy thereafter to reuse tests for other use cases or even other projects. The advantage is that you can easily hook up another project or app to your automated test suite.
Faster Time to Market
Newly developed features can be continuously tested and validated with test automation. This reduces the feedback and testing cycle and allows your business to bring products to the market faster.
Less Stress on QA Team
By implementing an automated testing strategy, you allow your QA team to spend time on tasks other than manual testing.
Quickly Determine the Stability of Your Build
Test automation helps you to determine the stability of your build. Often, smoke testing is used to validate stability, but smoke testing is slow and requires manual input from the testing engineer such as setting up databases with test data. The goal is to be able to release a build as fast as possible and automatically validate its stability.
Human Error
Manual testing opens up the opportunity for humans to make mistakes. Especially for complex scenarios, it makes sense to use test automation to avoid mistakes. You can still make mistakes, even with test automation. However, the rate of mistakes is significantly lower when using test automation for your test suite.