As designer, we know that user tests are crucial for creating a successful application, a product that covers the users needs, keeps the user frictions as low as possible and, for the B2C market, increases the conversion rate. Keeping in mind that this kind of tests are incredibly important for a product designer, we should also be aware they are not the only ones that a digital product requires.
Indeed, when we design within a continuous delivery environment, we should consider to not testing only the finished product but also taking care of the intermediate versions built sprint after sprint. Each of this version is a step on the path toward the next release and if we want to make this path smoother and safe(and if we care enough about our designs) we should run tests on it.
As I recently had the chances to work with the Mikamai's and the Wizkey's team and to gain some experience in testing the software, I'd like to share here my insights.
This is an article written from a product designer perspective and I will not write about technical approaches or tools. Instead, I'll write about how E2E test can help a designer creating better products and increase his/her contribution within the agile team.
Testing is the new religion.
Modern software development thinks very highly of tests, and indeed the Agile methodologies impose several tests. Many of them are "automated" which means they are automatically run by a script. They don't need a human being clicking around the screen, instead they need a human being writing the script.
The most interesting for a Designer is the end-to-end test, where the two 'ends' are the user behavior and the expected result, respectively. In synthesis, we perform a user flow on the app, targeting a specific feature, and we check whether the result is the one expected. For example, if we click the "logout" button we expect the session terminates with a logout page loaded, if this doesn't happen, the test fails.
Pretty simple, no? It's actually so simple that it can be automated.
"Automation is cost cutting by tightening the corners and not cutting them."
-Haresh Sippy-
What is an automated end-to-end test.
Imagine a dumb bot programmed to open the application and to interact with it, performing a specific user flow at an incredible speed. Then, it checks if the result is the expected one and more specifically it checks if the UI shows what it's expected to show. If it doesn't, it tells us where it found the error.
The video below is a screencast of an E2E test suite we ran at Wizkey. It's made of various tests that cover some user flows, starting from the shortest ones (e.g. logging in). When a test is successfully completed the console shows a green tick with the name of the test.
Considering the bot takes few minutes to test all the main product features and that it can be launched at any moment on every version of the product, it becomes clear how useful it is.
A designer's job.
The main reason of the fast growing adoption of E2E tests is the wide range of effective tools available today. In the recent past, tools like Cypress, Test Cafè, Puppeteer and many others, made the E2E testing more accessible and less expensive. The game changer is that some tools now provide a clickable user interface with which we can create an automated test even with very basic coding skills. This opens a door to all the not-devs people that work in the team, like product owners and of course, designers.
But why we should get our hands dirty with this tech sauce?
Every team has a different organization but an undeniable truth is that the designers know more the user flows than the others, because they are the ones who designed all of them. As they are often close to the business team, they have a wide and forward-looking view on the product. They can better understand which user flows are the most important and what are the key points they should not do compromises on.
In a scenario where the product is being built from scratch, we can use E2E test to advocate user needs: we can write a test to highlight a specific Acceptance Criteria that we consider essential for the usability, to make sure it will be implemented in a certain way. Hopefully, this will make it a shared interest of the team and it will not end up being half forgotten within the sprint hurry.
"Any fool can know. The point is to understand."
― Albert Einstein
The most interesting part is that to write a test we probably need to have the development environment installed on our computer: to create a test, run it and then push it to the git repository. The only fact to contribute to the code base will help us tremendously in understanding the product mechanics. In fact, we can learn a lot by talking with a developer about a failed test: we can discover technology constraints, opportunities, and even come out with new solutions.
Moreover, the first reason why I suggest every designer to have a look to the E2E tests, is because by creating a common ground with developers, we'll improve our communication. All this will make us a better and more incisive designers. I'm not talking on learning to code and be able to pair programming with a developer, I'm talking on building bridges.
Writing a test and using a git client to push our 3-lines-commit to the project repository is also a try in creating a common ground.
Conclusions
Digital Product Design is a very multidisciplinary field and more and more specialized roles are emerging. We can't master all the aspects of it, but we can develop several side skills that can help us in doing some good design and to communicate well with our team.
For sure, learning to write an e2e test tremendously increases our ability to understand the product we are designing, to find *feasible solutions and it creates a common ground within the agile team.
"Study hard what interests you the most in the most undisciplined, irreverent and original manner possible."
― Richard Feynmann
Top comments (0)