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 manual testing but provides a path to evolve this into automation is key.
Myth Seven: "Developers have adequate testing skills"
If testing was easy everybody would do it and we‘d deliver perfect code every time.
An independent testing team serves as an objective third-party, able to see "the big picture‖, to validate the functionality and quality of the deliverable. While developers tend towards proving the system functions as required, a good tester will be detached enough to ask "what happens if...?" When you include business user testing as well, you are more likely to have a system that is fit for purpose.
Finally, and I'm sure this point will be disputed, most developers don't actually want to spend much time first writing tests and then developing code to prove the tests work. Using the collaborative process described below, the developer gets ample assistance in describing the functional tests and can focus on writing lean, accurate and robust code.
Myth Eight: "The unit tests form 100% of your design specification"
Whichever development method you use, before you develop code you have to think about the requirements. While TDD ―done well‖ may identify a fair percentage of the design specification, there are still concerns about gaps between the unit tests. There are other equally viable approaches. The argument, that you need TDD to prove the requirements are captured accurately, isn't substantiated by history.
Defining test cases to check the accuracy and succinctness of the requirements is nothing new. The V-model, for example, is a valid approach to understanding testing requirements–and by implication, functional requirements. Like TDD, the V-model and most other models, fall down when the practitioner‘s approach is rigid, while development processes are fluid. Software engineering is not like mechanical engineering and trying to force conformity is wasted effort. Whichever approach you chose, correct thinking challenges each user requirement by asking "how would I test that?" The important factor here is that test cases are challenged before they are committed to code, otherwise you'll be doing a lot of recoding and calling it "refactoring".
When the requirements are refined through collaboration, the developer receives a more robust specification that is less likely to change because it has been openly appraised from several people's perspectives.
Myth Nine: "TDD is applicable on every project"
As the size of the project increases, the time required to run the tests also increases. This can be addressed by partitioning either/both the project and/or the tests. Either route results in tests that run at different frequencies depending upon their relevance to the current coding effort. This approach introduces the need for test planning and execution management. To achieve this efficiently, in addition to white-box testing, you need to be thinking about:
Integration Testing–"Which tests do I need to run to ensure the new code works seamlessly with the surrounding code"
System Testing–"Does the functionality supported by the new code dovetail with functionality elsewhere in this system, or in other systems within the process flow?"
Regression testing–"How often do I need to run a regression test to ensure there are no unforeseen impacts of the new code?" Automated regression testing provides a safety net that can affirm agile development techniques.
User Acceptance Testing–"While TDD (in collaboration with business users) should ensure that a