Manual testing is the foundation of testing - it’s always a start point. Why? Because it is simple, easy and fast. And that's what we expect from it. At least at the beginning. It gives us the answer to what we want to know in the first place - whether the application works.
It is not without significance that manual tests are performed by people and how much we gain from it. In addition to checking functionality, we also have information about UX, GUI, and loading time. Because only a human being, not a machine, can empathize with the end-user. User for whom this app was designed, who will use it most often and for whom it must work perfectly. If the end-user is not satisfied, then what is the point of writing such an app?
Secondly, clicking through all layers of the application will let to know it from every angle. This allows to build specific test cases and create accurate documentation - which in the future can be very useful.
When manual testing is not enough
However, the testing process does not end there. At least when our team works in agile methodology and we have to carry out regression tests. I know, I’ve been there. Manual testing is powerful enough when we need to test simple features and not worry about their effect on each other.
But a complex application cannot be tested well this way. The dependencies between the features result in edge cases, which we must be especially careful about.
In an ideal world, it should be like this: I have a new feature to test. I want to see if it works and also does not cause regression. To achieve this, I test this particular feature and again the entire application (at least the most sensitive areas). Click by click.
On a large scale, this is a very tedious work, which also involves risk. One time I just may skip something. After all, time goes by, the list of tickets does not become shorter, and the work must be done.
What can I do to be better? Start automation testing!
Performing manual regression testing once again, I felt that I was not effective. I knew there was a way to do it better, faster and at least just as accurately - the answer was automation. The most important thing for me was finding the right tool. In an ongoing, complex project, there is not always enough time for long-term learning of new tools (especially during working hours). Time is the essence. So what should be the right tool?
It should be relatively easy to use. It does not require devoting extra hours to its learning or installing additional frameworks and libraries. The less effort the better.
Have detailed documentation - this will help solve most of the problems right at the start. It really saves you a lot of time when you don't have to search the entire internet to find the answer.
Ideally, if its use simply gave pleasure and fun - but that's my private opinion.
For me, Cypress turned out to be such a tool. I've tried it and use it ever since.
What I’ve gained with test automation with Cypress
Cypress guides you step by step - from the installation process to writing tests. If you don't know something, you'll find it in the documentation. It is priceless when without much effort you can find all the information in one place, and with examples of use. How to install it, how to write the first test and how to use individual commands - all there. Cypress won me over with its simplicity.
The graphical presentation of the test run is really great. Cypress shows how long the test lasts and clicks on the elements in our eyes - everything can be seen on screenshots and logs that can be opened and viewed later. This makes it extremely easy to track and fix bugs. A nice addition is a tool for locating elements on the page and copying their path along with the get command.
In the end, we get the result: success or failure and the duration of the test. If we want to go into details, we can use Devtools - we'll get information about what command was carried out, on what element, with what result.
It took me a day to get acquainted with Cypress and write my first, simple test. That gave me the greatest pleasure. Especially, that this was my first experience with automated testing.
Cypress was not an obstacle to overcome, but a tool to achieve success. It pulled me into the subject of test automation, which I have been developing since then. Besides that - it just made my job a lot easier. I don't waste time repeating the same activities. Cypress does it for me. And a well-written test allows me to catch bugs and report them quickly. I have more time for careful testing of new features.
Sure, Cypress also has its limitations - like any tool. For me, however, it is irreplaceable. Thanks to it, writing automated tests has become a pleasure for me and I just want to do it!
I can't help mentioning the most important benefit. A stable, well-tested application means a high-quality product and a satisfied customer. After all, that's what we care about the most, right?