Automated testing

Why opt for automated testing?

A web application consists of many – often complex – functionalities that are built using code. Obviously, this code is extensively tested before the application is put into use. When adding new functionality or new pages, it’s efficient to reuse parts of this code in slightly modified form.

When reusing code, the original functionality may have become corrupted. This type of regression bug may seem easy to solve, but ultimately, an application will become too comprehensive to test everything manually from scratch for every adjustment you make.

So, our Scrum teams use automated tests, which are faster and more thorough – an automated test doesn’t ‘forget’ anything. This means we deliver better quality software faster.

Pick your ideal team right away

Our autonomous teams consist of experienced, committed experts who want nothing more than to join hands and book success. Do some preliminary work by getting to know them now and pick the ideal team that will go the extra mile for you.

Unit tests, integration tests, and behavior tests

You can test at several levels. It’s possible to test individual components or the bigger picture. A unit test is used for classes of methods: individual pieces of code. An integration test is used for functionality. A functionality in an application is formed by the integration of classes/methods that communicate with each other.

These two tests are used for either front end or back end. The next step is to test at the user level. Does the application work as expected? This is called a behavior test – or, for web applications, a browser test.

To perform these three types of tests, we use PHPUnit, a test framework for the PHP programming language. In addition, we use Laravel Dusk for the behavior test.

Writing test plans

The written test plan is a detailed, human representation of behavior tests that can be used for the website or application. Describing them means we can subsequently automate them.

For every test plan, we first define:

The desired OS/browser combinations (for example, ‘Windows 10 combined with Microsoft Edge 15’)
The user roles that need to be tested (for example, ‘visitor’ or ‘admin’)

Then we write out the following for every test: the URL where it will be performed, the active role, the action(s) that will be carried out, and the expected test result. And of course, every website or application update’s test plan is extended with the new functionalities or components that should be tested.

Code coverage

So, the code of an application is tested in an automated way at several levels. Once you’ve ‘covered’ 80%-90% of the application, the code coverage is good, as not all code is equally important for testing purposes. The final 10%-20% barely add any value.

PAQT always has insight into the code coverage

Our specialists always know how thoroughly the application has been tested. An application will not go live with a coverage that is too low

Monitoring

An application at PAQT is continuously monitored before, but also after going live. This is how we ensure sustainability

Incidentally, we discuss the required percentage with the customer. It is included in the Definition of Done, in which we determine when an application is ‘finished.’ The percentage that represents sufficient quality depends on the type of application and project.

Just to be clear, code coverage is an indication of how much code has been tested and says nothing about the quality of the tests. For example, you can use this test to see if the application works when a user does what they’re supposed to do. Testing expected behavior is also referred to as the ‘happy path.’ It doesn’t provide insight into what happens if the user does something unexpected. And you will want to be prepared for that scenario, too!

Need advice? We are happy to help you.

Tell us about your ambition and start today!

Start today