The software testing fraternity has always been greatly fascinated with test automation. Their fascination has expanded its self to an extent where you think of it like magic, which can fix all their software issues or simply like a golden nugget which will get their client super satisfied. In reality, the situation is a bit different than how easy breezy it might seem. It is to be rightly understood that manual and automatic testing are two sides of a coin. The testing team which tosses a coin to balance it on edge would turn out victorious. Before one can achieve that much-desired balance between software and manual testing, the gist of both these celestial bodies of the testing universe needs to be understood.
The right perspective
Let’s get into a discussion where we count and analyze the two sides of the seesaw. On one side there is automated testing which reduces the human workload and shortens your time to market, they are the supreme input and highly valuable human perspective which would take the quality of the user experience to another level.
If you talk about automated testing, it is generally seen as a power battery which was once clicked would set the whole application software bug free. But it is not the case. It has to be rightly understood the part and the test suite which can appropriately be planned for automated testing. One can write automated testing scripts and run them alongside the code of the application, but that would not solve the ultimate problem. It can help you test the mechanical use cases thoroughly, but it won’t be able to add a human touch and quick feedback to eat.
An automated test plan can rightly tell you where your software shows a glitch, but it will check the use cases under specific scenarios. And those scenarios are self-confined into human generated situations and boundaries for test input values. What is that the test team leader could not figure out some of the most critical test cases?
The real consequences would be that a test report is generated for all the services and subsystems of the software and specific class of test cases remains untouched throughout.
You may like to watch a video on Manual Testing vs Automated Testing with example
How to strike the balance note?
As we discussed earlier, striking the right balance would happen only when we do automated or manual testing with their pros and cons on the side of the weighing machine each.
To understand the kind of approach to be followed while making your checklist to automate test, one need to carefully analyze the field of effect of a particular use case and the test plan for it. If the test affects a broad base of your users or a certain set of functionalities, right update to be automated as the risk of failure brings an adverse effect for a small fraction of users among all.
To summarize this broadly, automation should be applied in test cases which need to be executed in bulk that would consume invaluable time. These are precisely the patches and features which need to be checked manually. Resting the manually would not only ensure their total integration within the system but also help you analyze the kinds of test failures which are most likely to occur once automated.
So it is like a game of a sensible mind for all automate or manual testing services providers to first analyze what is there to be automated and what needs human attention through manual testing.
Just go through a PowerPoint Presentation on it by QA Source