Hello!
I had a problem with the Specflow 02 post (I deleted the draft unintentionally and I use Shift + Delete) so it’s like a post that takes more time and work, and I’m still rewriting it. I decided to bring this discussion back to the blog, previously I commented a bit on other posts, but now I have a little more knowledge in the routine of tests (automated and manual) so I can comment in a less superficial, address some positives and negatives of each effort.
Now without further enticement, let’s go to the post:
Our competitors:
Manual Testing
Our Orthodox Fighter
The manual test is (usually) our gateway to the world of QA.
Constant training, routines, tumbles, learning is molding us into an increasingly efficient athlete (tester), we have the vision of combat, we know how to react to unforeseen events and our reflexes increase with each blow that we take!
You cannot become an athlete without training, you cannot become a tester without testing. Of course, we have people with the very strong intuition that is easier than others, but the training can compensate and make anyone a real professional!
But even a professional can get exhausted and be knocked out in a multi-round fight.
The manual test is a skill that is improved over time, it requires a continuous effort to be an expert. We are learning where errors usually happen, we learn to take a more critical look at the impact of a bug in the system, we can analyze the UX (user experience) of the application, we even learn how much effort a function requires from developers, we have been able to study the coverage of the testing area and improve it.
But we have a problem with continuous work and re-work. Let’s think about an application with 10 screens and about 10 functions on each screen. If we ignore integrations and different scenarios, let’s do as few scenarios as possible. We would have at least 100 tests, and we can do them without any problem.
But let’s say there’s going to be a change in that application, and that can break it down. We have to do the same 100 tests and some new tests and with a new change, we’ll have to run the same 100 tests, (the new tests are not new) and more new tests and so on.
In addition to tiring the analyst (no one likes to keep repeating the same scenario all the time), may have a problem of addictions (the person enters the automatic and does not realize that an icon is no longer there) has the problem of time, thinks that every test spends a minute, every time you have regressive you will spend at least 100 minutes just to repeat old tests, using a time that could be better spent on improvements to the project.
That is, it is a process that guarantees a lot, professionals are always improving (at least they should) and have a closer view of the user, but in the long run can become a process that uses a lot of time and effort.
Automated Testing
Technology in favor of technology (and yes, most of us know that robot can play ping-pong)
The terror of many who were unprepared, a machine that knocks their opponents with their agility and precision, is tireless and even with their repetitive movements, impresses who is watching the fight.
Few still can deal with it. It is not all the fights that manage to put her in the ring either for lack of investment or people who know how to handle it, not to mention that it can often be defeated because it has not been maintained between fights.
There is resistance from some competitors who say that the participation of machines in human combat should not be allowed.
And here folks, we have the automated tests and at first glance, they can scare you a lot, but does not despair by looking better you can see many advantages in them.
First point of emphasis, it already reaches the greatest weakness of the manual test “Retests“, instead of running the same 100 tests every time it has a regression, let the automated do this, it will not tire, it will not stay inattentive and it will be much faster than the tester that will make the scenarios in hand (which can even do something else while the tests run).
But do not fall for the boring marketing that some ticket sellers do, do not just press play on a button for the tests to happen. Someone has to go there and put their hands on the code, prepare the tests, one by one and this also requires time, effort and technical knowledge (best used if there is also knowledge about QA), and even if you do not have to run all the tests with every change in the project, you need to maintain the tests and this also requires time, take much less time than running each test manually (even because it types faster, validates faster, does everything faster, without losing the quality of the validations made).
A big problem with the automated system is that it validates the functionality, but not how they interfere with the user, and also do not investigate the cause of the problem. They can only say that it happened without telling that any unforeseen causes the test to break example a timeout, while a tester knows how to deal with unforeseen events and when he finds a mistake, he can investigate its cause and where it may reflect.
In other words, you gain a lot of agility in the long run, but at the same time you need a preparation to have automated tests in the project, but the test does just what it was programmed for, which is a great limitation, after all, we test applications For humans, not machines and humans see things other than machines. (Do not believe me if you’re told the opposite)
RESULT
IT DEPENDS!
I do not believe manual testing> automated testing and nor vice versa.
Each has its strengths and best meets different needs, both have a cost of time and money and both can fail.
The question is how, where and when to take advantage of each type of test, and understand that automated testing serves to help the team (tester and developer) ensure the quality of the application, they are no substitute for manual testing.
We cannot replace a person’s experience, let alone his learning curve, this is something that the machine will not be able to do (even if we improve the automated tests, this responsibility belongs to whoever codifies the same. An improvement of the person which reflects in a tool), and it is of no use for a person to want to do something as fast as a machine, especially without losing the quality of what is being done.
We are in a moment where we must realize that the learning curve of a tester, will pass through automated tests, this is included in the agile development.
Instead of hitting the VERSUS key, let’s enjoy and fight side-by-side.
And we’ll learn how to make the best decisions, see where an automated or manual test goes, without unnecessarily increasing the cost of the project, making life easier for everyone, including the customer!
