Although this sounds feasible, it isn't realistic for several reasons:
- The granularity and objectives of white-box unit tests developed in TDD serve a different purpose from downstream black-box testing.
While the overall objective of a unit test is designed to prove that the code will do what is expected, the aim of regression testing is to ensure that no unexpected effects result from the application code being changed. These two objectives are not synonymous - e.g. checking that an attribute has a valid date format, is not the same as checking that for a given input, the value of the field contains an expected date.
3. "Developers write the tests using open-source tools, so we no longer need testers, or automation tools"
Professional testers fulfill a different and equally valid role from their development colleagues.
It is widely recognized that traditional test automation tools have failed to live up to the hype of the vendors. Original Software's roots are as providers of products that improve the productivity of the database testing environment. It was because there were no adequate tools to provide User interface testing that we extended our solutions into this market sector; our heritage is aligned to effective testing rather than screen-scraping automation. When we developed TestDrive, we did it with the benefit of twenty years hindsight of missed opportunities from the traditional vendors.
Often, TDD projects have at least as much test code as application code and, therefore, are themselves software applications. This test code needs to be maintained for the life of the target application.
4. "Unit tests remove the need for manual testing"
Manual testing is a repetitive task; it's expensive, boring and error-prone. While TDD can reduce the amount of manual effort needed for functional testing; it does not, remove the need for further black-box testing (manual and automated).
By automatically capturing the tester's process and documenting their keystrokes and mouse-clicks, the tester will have more time for the interesting, value-added activities, such as testing complex scenarios that would be difficult or impossible to justify automating. Though manual testing is a time-consuming (and therefore expensive) way to find errors, the costs of not finding them are often much higher.
5. "User Acceptance Testing is no longer necessary"
Within agile development, acceptance testing is often positioned as working with the customer to resolve "incorrect requirements", rather than correcting functionality that does not map to what the user needs. When the user initially defines their requirements, they do it based on their initial expectations. When they see the system "in the flesh" they will invariably come up with different, or additional, requirements. While agile methods might reduce the frequency of this happening, it is unreasonable to expect the approach to resolve them entirely, so there should be no expectation that user acceptance testing will be obviated. This is especially true when it comes to the business user signing off approval of the User Interface, since they may have envisaged something different from the developer; which brings us to...
6. "Automation is impossible"
Automation in the early stages of an agile project is usually very tough, but as the system grows and evolves, some aspects settle and it becomes appropriate to deploy automation - automation that can cope with changes by using approaches such as self healing scripts.
To begin with, almost all testing from a user and QA perspective will be manual but this testing effort and design can be beneficial later if captured and re-used.
Knowing the right time to automate is tough, so using technology that proactively supports early