specific function performs correctly, is the cumulative impact of changes still acceptable to the business users?"
However, in today‘s environment it is unacceptable to think of these testing stages as discrete serial activities. Often they will need to be run in parallel as we get a new 'code drop'. As the size of the project team increases (along with testing effort), it is no longer acceptable for the tests to be considered "self-documenting". Whenever the number of participants increases, the project's risks become exposed to its members' different interpretations of the requirements–the definition of what constitutes "success" can be misconstrued.
As the size of the project increases, so would the amount of test code that needs to be developed. Any test code developed needs to be supported for the life of the application–effectively doubling the ongoing maintenance effort.
As the size of the testing workload increases the project needs to add test automation to its armory, to minimize the human intervention and elapsed times for each of these testing cycles.
Myth Ten: "Developers and Testers are like oil and water"
Since the dawn of time there has often been a "them and us" tension between developers and testers. This is usually a healthy symbiotic relationship which, when working correctly, provides a mutually beneficial relationship between the two groups resulting in a higher quality deliverable for the customer.
The discussion should be focused on:
- Software delivery that meets business objectives (fit for purpose, on time and on budget), not who owns which part of the process.
- What can testers contribute to the requirements gathering phase to ensure they are involved in the TDD process?
- How can testers maximize reuse of the assets created during the development phase?
- Is there a role for the ―traditional tester‖ in TDD, or should they (like the developers) be acquiring new skills to enable them to adapt to the new paradigm?
- How can developers and testers find mutual benefit in exploiting new advances in software development and testing tools?
Just as improvements in developer's software tools and methods have enabled a shift in development approaches, next generation technology for test automation is similarly reframing the opportunities for testers to automate earlier in the delivery cycle without incurring the heavy burden of script maintenance so often associated with traditional automation tools.
Agile projects are in fact an excellent opportunity for QA to take leadership of the agile processes; who else is better placed to bridge the gap between users and developers, understand both what is required, how it can be achieved and how it can be assured prior to deployment? QA should have a vested interest in both ―the how‖ and ―the result‖, as well as continuing to ensure that the whole evolving system meets the business objectives and is fit for purpose. But it requires QA professionals to be fluid and agile themselves, discarding previous paradigms and focusing on techniques to optimize a new strategy to testing.
|The Reality of Software Testing in an Agile Environment||115.15 KB|