Oct 3, 2018
Top management typically sees test automation as the solution to reduce effort and cost of testing on increasing software deliverables. While it is true that testing automation services can provide a rapid return on system quality, the job to build automated testing is not. There are some known problems that need to be avoided in addition to those mentioned above.
Give way too much to proprietary testing tools.
Many commercial test tools provide simple features to automate capture and playback of manual test cases.
Although this approach sounds good, it encourages testing through the user interface and results in the fragility and difficulty of maintaining the tests. The cost and constraints that commercial tools put on those who can access test cases is an overhead that tends to hamper collaboration and teamwork.
In addition, storing test cases outside the version control system creates unnecessary complexity.
Alternatively, open-source testing tools can often solve more automated testing problems, and test cases can easily be included in the version control system.
There needs to be a balance and a correct evaluation for each project when using commercial tools or open-source tools.
Worship the UI so that all tests run through it.
Although testing automation services provide a high level of confidence, they are expensive to build, slow and difficult to maintain.
Testing at the lowest possible level of code is a practice that encourages developer-to-tester collaboration, speeds up test execution, and reduces test automation costs.
Automated unit tests should be the largest test effort followed by integration, system, functional, and acceptance tests. UI tests should only be used when the focus of the tests are user screens or there is no practical alternative.
Create jealous and non-cooperative testing.
Test Driven Development (TDD) is a development approach that is both a modeling activity and a test practice.
The process of defining test cases (or executable specifications) is an excellent way to ensure that there is a common understanding among all involved as to the real requirement as to what is being developed and tested.
Practice is often associated with unit testing, but it can also be applied to other types of testing, including acceptance testing.
Frustration with fragile tests that break intermittently.
Unreliable testing is one of the main causes for teams to ignore or lose confidence in automated testing.
Once confidence is lost, the value initially invested in automated testing is drastically reduced. Correcting failing tests and solving problems associated with brittle tests should be priorities for eliminating false positives.
Think automated testing will replace all manual tests.
Testing automation services is not a substitute for manual exploratory testing. A mixture of types and levels of testing is necessary to achieve the desired quality and mitigate the risk associated with defects.
6. Avarice (Greed)
Many automated tests that do not map the quality of the system.
The test effort must match the desired quality level of the system. Otherwise, there is the risk that little or no correct functionality will be tested. It is important to define the required quality and then combine the test effort to fit.
This approach can be done in collaboration with those involved in the projects to ensure there is a common understanding of the risks and potential implications.
- (no comments)