What tests should we do to our software and for what?

The tests are not optional." This, which seems to many a truism, remains one of the pending issues in the world of software application development today. Yes, incredibly, there are still many “metal” colleagues who are not aware that programming without tests is not only like doing stunts on the trapeze without a safety net, but also a source of errors, bad practices, and anxiety.
And for this reason, I want to review the basic foundations of the tests that we should apply, each one in need, to our developments.

Why test?

To make even the newest reader understand it, testing is the way to make sure that what you want our program to do, do, and do without error.
The construction of software implies knowledge, experience, talent, intellectual capacity, and an artistic point. In other words, it is a very difficult task, and there is still a long way to go before that changes for the better. In fact, complexity is tending towards growth in a way, as in everything related to the Front-End in Javascript, to the absurd.

Having overcome, decades ago, the human capacity for apprehension and memorization; which necessarily implies that failures and errors are inevitable if we try to avoid them with only our human capacities.

Testing is not optional. Software without testing is a bomb about to explode


Who has not passed that he has left his code half a year in a drawer, and when he turns to touch it, have the feeling that someone else has written it? We don't recognize our own creature. And let's not talk when we are integrated into a team, or receive the " gift " of supporting or evolving a legacy code. For this reason, tests are essential, since they allow us to guarantee that the applications fulfill the functionalities expected of them and the quality expectations (not only of code); helping to find those errors or defects that have not yet been discovered; reducing the cost of development, the cost of ownership for users; and build customer confidence by avoiding annoying regression errors.

you may learn how to test software Software Testing & quality assurance training

That is not to mention the feeling of incremental security that is obtained the closer we are to a deployment, since the more code we have, the more tests assure us (in the form of a thick mesh) that everything works correctly.

DevOps

The arrival of Agile methodologies, from the 90s of the last century, was a shock in the organization and execution of tests within Waterfall processes. In the latter, it could be generalized, the tests were mainly manual; meticulously defined in voluminous test plan documents; and that they were carried out only after the coding of the software was completed.

Xtreme Programming, on the other hand, placed a lot of emphasis on automation and the concept of prevention-oriented testing in the late 1980s; thus marking the future Agile philosophy. For this reason, we currently use test frameworks that allow most tests to be carried out automatically in all areas of the application.

Manual and automated tests are complementary


And even more so when it is intended to adopt the concept of Continuous Integration, as an essential part of DevOps, where the own construction and validation of the Build through all kinds of automatic tests is an inherent part of the process. This being even more critical at high levels of maturity where we would apply automated or even continuous deployment.

The importance that the tests have gained has been such that the way of coding the software itself has also undergone profound changes. The birth of TDD (test-oriented development) and its way of subordinating the code to tests, implies that making testable software is an essential requirement in the quality code.

And, although we did not get to use this advanced development technique (which is not easy at all), the goal of being able to automatically test our code has reinforced important practices in object-oriented programming such as SOLID.

Tortoise And Hare

We have the first major division in the world of testing between automated and manual.
As the name implies, the former depends on a testing tool that implies, in almost all cases, a language or a subset of the language itself. That is, if I do them in nUnit, it will be very difficult to pass them to MS Test.

Manual testing requires human interaction. The tester takes on the role of the user role that has to be validated and performs all those operations that it has defined in a test plan, or it searches for "tickling" the system to get there were no "luser" has reached previously...
As you can see, both types of test execution are complementary and important to guarantee quality software.

Automation is fast and can test many subtle variations in the data; You can also easily repeat tests as software evolves; And because it is run by the system, it avoids the fatigue and mistakes that sometimes accompany repetitive tasks.

Instead, although manual tests generally take longer to run (as they are performed by one person), they often require much less setup time. It is a good choice for tests that only need to be run occasionally, or in cases where the cost/time of automation setup outweighs the benefits.

Post a Comment

0 Comments