Testing is not a crime
13 Nov, 2018
Test or Life
We all like to deliver a perfect finished product to our customer, which meets all his requirements, without any problem and icing on the cake with an avant-garde design.
To achieve this ultimate result, we must go through a crucial step that some people avoid like an H1N1 virus outbreak: the verification, qualification, test or recipe phase, which, by the way, will avoid saying “In doubt, we deliver…”, the day before the precious one is delivered to users.
The types of tests are multiple, here we will select the main ones in a project phase, we will specify the actor who is in charge of performing them, the environment on which they are played and the time at which they are performed:
– Unit tests
Who? Agency / Development Team
When? After completing a development, often automated in continuous integration
Where? On the development workstation
– Integration tests
Who? Agency / Development Team
When? After completing a set of developments that allow the full testing of a user functionality on a dedicated environment
Where? On a dedicated environment isolated production, called recipe
– Functional tests
Who? Agency / Functional team / UX
When? After validation of the integration of the functionality on the dedicated environment
Where? On a dedicated isolé production environment, called recipe environment
– Acceptance tests (also called Recipe)
Who? Clients / End Users
When? After validation of the functional tests
Where? On a dedicated isolé production environment, called pre-production
In UX, for functional tests, what makes sense is end-to-end testing because it provides something interesting: checking the expected front-office, their interactions with the back-office and possible web services interfaces, by putting yourself in the user’s shoes.
How is it going?
In the form of a use scenario, the test will tell a story that makes sense for the user, let’s take the following example in the case of an online store:
– Paul the Internet user accesses the shop myshop.com
– He searches for the ABC article in the promotional articles page
– He consults the product sheet
– He changes the color of the product
– He adds the product to his basket
– He consults his basket and modifies the quantity of the item ABC
– He chooses the delivery method: pickup in store
– He pays for his basket with his PayPal account
These use cases can be found in the A.G.I.I.L.E. method to describe and specify a user requirement, which allows a very relevant parallel to be drawn between the project specification and functional test phases.
The test phase consists of several scenarios that will constitute a test plan, or acceptance booklet.
On the tool side, a good spreadsheet allows you to do the job, but new tools are trying to change habits and bring a new approach to development/testing: by integrating the user need as close as possible to the developer, by offering automation, reports, a configuration interface and many other features.
We will retain 2 of them which seemed very interesting to us and will be used in different situations depending on the project to be carried out: Cypress and Behat*.
It is an open source web application testing tool that runs directly in the browser, on the client side, like Selenium.
As it works in the tested application, Cypress has native access to each of the objects, from the window, the document, through the DOM, all these elements are manipulable in your tests.
Maintaining control over the application being tested, network traffic and native access to each host object opens up new possibilities. Cypress allows you to modify any aspect of the application’s operation:
- Imitate the browser or application functions and force them to behave as required in a test case.
- Display data-stores to modify the application status directly from the test code.
- Test how the application reacts to errors by returning HTTP error codes.
- Modify DOM elements.
- Control components by calling methods directly from the test code to control them.
- Check the time so that the timers automatically activate without having to wait for the required time.
It executes most of its commands in the browser, so there are no network delays. The commands execute and control the application as quickly as possible.
To manage complex user interfaces, it is possible to use assertions to indicate the desired state. He will then wait for the application to reach this state before moving on to the next step.
The Cypress interface shows live command execution, assertions, network requests, page loading or URL changes.
During the test execution, it takes screenshots of the application and allows to go back in time to the state it was in when the commands were executed. It is also possible to record the test in video.
Cypress will keep a history, a trace of the execution and the results obtained, which allows it to be consulted and shared with project members for analysis.
With a little practice, this tool is a time-saver, in the maintenance of tests, in their automatic execution and also on the report of the results, allowing to precisely point out the technical errors that can be better handled by the development team.
From our point of view, the important thing when you are in the testing phase of an application is to be able to appropriate and fully understand the user’s need, hence the usefulness of describing simple scenarios, oriented towards the end user.
However, their description, and especially their results, must be sufficiently accurate when errors are detected in order to provide as much information as possible to the implementation team in order to help them more easily correct the anomaly, regardless of the tool used.