From manual to automated testing: where to begin

These days you’re hard-pressed to find someone in software development that doesn’t think test automation is a good idea. The general consensus is that automating tests helps ensure quality over time and assists in shortening the feedback cycle.

For the good ol’ functional tester this means a lot has changed rapidly. When I started out, Agile and test automation weren’t a thing yet. Maybe someone knew how to fire off a set of calls through a SOAP API, and capture the responses for (manual!) assertion. But that was pretty much as far as automation went back then. For all other things, you had your test scripts in Excel, based on technical and functional designs. Every 3 months or so, you got the chance to click through the newly delivered software and find as many bugs as possible within the 2 weeks timeframe you were given.

Fast forward to Agile and 2-week sprints and all of a sudden testers are required to work alongside developers. Since stuff gets delivered every 2 weeks, you better automate your regression tests. Manually clicking through all corners of your application every sprint is a good way to lose your mind pretty quickly.

The transition from a functional tester to an automation tester can be characterized by one keyword: technical.

You need to pick-up on certain technical skills in order to be successful at automating tests. There are a lot of tools out there and most of them require you to have at least a basic understanding of coding concepts. Some, mostly commercial offerings, are marketed with the promise: “no setup or programming skills required”. It’s a very appealing proposition if you don’t have any coding skills yet. It’s also bullshit.

If you limit yourself to “no coding required tools” you will always be constrained by the options they offer. Tools should accelerate and support the testing process, not constrain it.

Test automation is a technical skill and as such it’s expected of an automation tester to be able to write code.

On the other hand, you don’t have to go all-in as well and start learning something heavy like Java or C#. In fact, I would strongly advise against that. Basically, all Java tutorials start out with installing and setting up a full-fledged IDE like Eclipse and going over concepts as object-oriented programming, packages, and classes. All are things you don’t need when automating tests and that only complicate matters and discourage people that are willing to learn and make the next step.

The main thing to keep in mind is that the goal of learning to code is to get knowledge about the programming fundamentals like variables, data types, if-else statements, arrays, loops, functions, etc. You’re not going to build fully functional applications anytime soon (if ever), so don’t focus on that while learning to code.

Since we’re talking about functional or E2E testing here I can highly recommend Cypress.io for starting out once you learned some coding fundamentals. Installation is very easy and setup configuration is almost nonexistent. You can read a more elaborate how-to over here. Under the hood, Cypress is all JavaScript so if you started to learn to code with JavaScript you are getting a head-start with this combination. Below is some example code to visit a website and verify if the title is correct.

describe('Wehkamp homepage', () => {
  it('should have the correct title', () => {
    cy.visit('www.wehkamp.nl');
    cy.title().should('eq', 'wehkamp - meer tijd voor elkaar');
  });
});

As mentioned before, Cypress is basically JavaScript with Mocha as a testing framework (that’s the ‘describe’ and ‘it’ part), and Chai as assertion library (‘should eq’). Now, let’s say your application is build using Angular. You can use Cypress but Google also supplies a tool specifically geared towards Angular apps. It’s also built around JavaScript and can use Mocha and Chai and, as a bonus also supports multiple browsers: Protractor.

describe('Wehkamp homepage', () => {
  it('should have the correct title', () => {
    browser.get('www.wehkamp.nl');
    expect(browser.getTitle()).to.equal('wehkamp - meer tijd voor
    elkaar');
  });
});

The syntax is a little different, but again, it’s just JavaScript with a testing framework and assertion library on top. If you’re not working with Angular apps but you do want cross-browser or mobile support, webdriverIO is a great option.

describe('Wehkamp homepage', () => {
  it('should have the correct title', () => {
    browser.url('www.wehkamp.nl');
    expect(browser.getTitle()).to.be('wehkamp - meer tijd voor
    elkaar');
  });
});

And again, the syntax is a little different but overall things look pretty similar. So let’s take it one step further. You want to automatically test a REST API. No problem, here’s an example using Postman and Postman BDD:

describe('Get customer info', () => {
  it('should return a 200 response', () => {
    response.should.have.status(200);
  });
});

This should look pretty familiar by now. Yup, it’s the Mocha framework with Chai for assertions, all powered by JavaScript. But now it’s used for automated API testing.

Most of these tools overlap in functionality. It heavily depends on what you want to accomplish with your tests and the underlying technique of your application, which one is best suited for your needs. But as you can also clearly see, once you learned some basic JavaScript and get familiar with testing frameworks and assertion libraries you can pretty quickly switch between tools. This allows you to cover a broad spectrum of automated testing without diving too deep into the technical side of things.

After all, you’re a tester and not a developer.

Thank you for taking the time to reading this story! If you enjoyed reading this story, clap for me by clicking the 👏🏻 below so other people will see this here on Medium.

I work at Wehkamp.nl one of the biggest e-commerce companies of 🇳🇱
We do have a Tech blog, check it out and subscribe if you want to read more stories like this one. Or look at our job offers if you are looking for a great job!