More and more software development projects are using the Agile Development Model as opposed to the Waterfall Development Model. Agile does help Designers and Developers deliver software projects on time with higher quality code, but where does that leave the Software Tester? I came across a whitepaper written by James Lyndsay entitled "Testing in an agile environment" from his website that would shed some light on the subject.
Of the many benefits that the Agile Model has, a cornerstone is its insistance on Test Driven Development (TDD). The Designer will have the scenario or user story that the software will address. From that, test cases are written to validate each step in completing the user story, then code is written to satisfy the test. One of the points stressed throughout the paper was the use of unit tests in the code that both the Developer and Tester would have responsibility to maintain. This would increase the amount of communication and collaboration between Development and Test because Test would not have to wait for Development to finish first before looking at the code; such is the case in the Waterfall Model. By having Developers and Testers working so closely on a project, the Designer has an easier time of ensuring the customer's expectation are still being met, lest the project follows this path.
In addition, security design decisions can be implemented from the beginning and verified as the code is being written. As stated before, there is a reduction of documentation, but that fact may be a benefit as counter-intuitive as that may sound. The test documentation instead of living separately from the code, it lives with the code in the form of unit tests. Tests outside of the unit test do need to be documented and recorded, but they should live as close to the code as possible.
There are caveats to this approach, but one that stood out in my mind is the concept of "decision fatigue". That is, since the Tester is involved early on in the development process and the Tester does have the ability to voice and direct change in the product, the Tester may feel overwhelmed at the weight of the consequences of decisions being made. Before, all Testers had to do was follow a specification from the Designer to verify the Developer's work. Now, that same Tester can directly influence the Developer's work or make a change in the Designer's plan. A solution offered by Lyndsay is for the Tester to keep the big picture in mind and what the primary business case the customer wants to solve with the software to direct the decision making.