Have you heard of this term above –
7 deadly sins. If you’re a fan of mythology or if you’re a fan of Full Metal Alchemist – both the original one and Brotherhood, then you know what I’m talking about.
Do you remember how these sins made life worse and hell for the two brother? It was so annoying to seem them come at them one after the other. You’d just wish that they vanish one for all, but it never happened – although they got rid of them one by one.
And that is what my crux is all about. In today’s world too, in gargantuan world of test automation, there are 7 deadly sins which have crept in. These sins will make life hell for any SDET/QA/Test Automation engineer or QA teams. But what are they?
Let’s find out.
Flawed comparison between manual testing and automation
Automated tests are not a replacement for manual exploratory testing. A mixture of testing types and levels is needed to achieve the desired quality mitigate the risk associated with defects. This is because testing is not merely a sequence of repeatable actions. The automated testing triangle originally described by Mike Cohn explains the investment profile in tests should focus at the unit level and then reduce up through the application layers.
Trying to replicate manual testing exactly in automated testing, rather than taking advantage of automation’s capabilities to test more thoroughly and with greater accuracy.
Overloading automation with too many tests or running tests too frequently, leading to slow or unreliable test results.
This sin happens when there’s an overload of automation with too many tests or running tests too frequently, leading to slow or unreliable test results. It’s important to strike a balance between the number of tests and their frequency of execution to ensure that the automation effort is efficient and that the test results are reliable.
Loving the UI so much that all tests are executed through the UI
Although automated UI tests provide a high level of confidence, they are expensive to build, slow to execute and fragile to maintain. Testing at the lowest possible level is a practice that encourages collaboration between developers and testers, increases the execution speed for tests and reduces the test implementation costs.
Automated unit tests should be doing a majority of the test effort followed by integration, functional, system and acceptance tests. UI based tests should only be used when the UI is actually being tested or there is no practical alternative.
Automation is answer to all problems.
Believing that automation can solve all testing problems, without recognising its limitations or potential failures. Pride is characterized by an overestimation of automation’s capabilities.
Test automation is not a panacea, and it can’t solve all testing problems. It has limitations and potential failures. Over-reliance on automation can lead to false confidence, and when automation fails, it can be difficult to identify the root cause of the issue. Being aware of automation’s limitations and potential failures is crucial in developing effective automated testing.
Automate Each and Everything
Trying to automate everything in one go without evaluating which tests are most critical or which ones will provide the most value to the project.
This sin occurs when there’s an attempt to automate everything in one go, without any prioritisation. It may seem like a good idea to automate as much as possible to save time, but it can lead to a lot of unnecessary work, waste of resources, and may not provide the most value. Prioritising which tests should be automated based on criticality, importance, and frequency of execution can ensure that the most important tests are covered and that the automation effort is efficient.
Failing to properly maintain test automation suites.
Being too lazy to maintain test automation scripts, resulting in outdated or brittle tests that are no longer valid.
This sin is characterised by a lack of effort or diligence in maintaining automated test scripts, resulting in outdated or brittle tests. Maintaining automation scripts is crucial, as the application under test is constantly evolving, and the tests should be updated accordingly. Failing to update the tests can lead to false positives and negatives, and make the automation effort ineffective.
Reacting angrily to automation failures or faults, rather than using them as learning opportunities to improve the testing process.
Wrath in test automation happens when there’s an angry reaction to automation failures or faults.
Automation failures are not uncommon, and they should be treated as learning opportunities to improve the testing process. Getting angry and reacting impulsively can lead to missed opportunities to learn and improve.