Some Recent  Posts

Becoming An Automation Tester | Oswin Losper

BECOMING AN AUTOMATION TESTER

Some Recent Posts

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.


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

Automation Testing Types | Oswin Losper

AUTOMATION TESTING TYPES

Posts

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.

#### 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 or popular one.

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.


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.

Selecting A Automation Tool | Oswin Losper

SELECTING A AUTOMATION TOOL

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.

#### **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:

#### **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 initialization 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/"**](https://www.oswinlosper.co.za/%22)

    **)**

    : 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.

![](https://preview--oswin-losper-e862f.stackbit.dev/images/terminal.png)

#### **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 "./pagemodels/homepage_model";***

***fixture("Oswin Losper Home Page")***

***.page(***

***"***[***https://www.oswinlosper.co.za/***](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.

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

Why I Chose TestCafe | Oswin Losper

WHY I CHOSE TESTCAFE

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.

> Automated testing can increase business efficiency, decrease the time spent on testing by personnel.

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.

##### COMPLETE MORE TESTING IN A SHORTER TIMESCALE.

Testers can do more for less and projects can be delivered more quickly; helping to increase operational efficiencies

##### 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.

##### TESTS CAN BE REPEATED EXACTLY.

Any tester can run a script created by another tester, without having to have the expert knowledge of the originator. Repeating an automated script delivers more consistent results.

##### 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.


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.

BLOG POSTS

BECOMING AN AUTOMATION TESTER

AUTOMATION TESTING TYPES

SELECTING A AUTOMATION TOOL

WHY I CHOSE TESTCAFE

BENEFITS OF AUTOMATION TESTING