Many of our new clients are in the process of implementing agile and many of them have no experience in agile. They hear a lot about it, read many papers and articles and are ready to dive in, but we usually recommend a staggered or gradual approach. For those implementing agile who are used to waterfall, the most benefitial approach is to try to borrow some practices from agile and implement those pieces first.
- Test automation is a key part of agile, The QA team can help write lots of tests (after code is developed, in a waterfall fashion), including unit, integration and regression:
- For unit testing, developers often don’t do enough unit testing to start with. QA can supplement their unit tests with unit tests on core functions and infrequently changing functions. Otherwise maintaining the unit tests can become a big burden of the developer/testers.
- For integration, this is very valuable because this directly represents what the software is supposed to do. It can take a lot of time to setup and run integration in an automated way. Developers may be too busy with writing code and complete functionalities so they don’t like or don’t invest enough time in writing test codes.
- Regression, specifically on bugs filed, most developers will fix a defect and move on. Let QA write tests targeted for those defects to make sure they don’t get reintroduced later on. Many teams don’t do this, but its very critical.
- Tests (being run automatically) should integrated into the build process. If new code breaks tests, then it should not be checked in. Make CI (continuous integration) part of the process. This will be a huge step in the agile direction.
- Break projects into sprints/chunks where a sprint can be 2-8 weeks. Don’t get stuck on 2 weeks like all the articles you read. The idea is to be very responsive to customer requirements, taking baby step approaches. If a requirement changes in the middle of development you don’t waste a lot of effort.
Don’t get stuck on implementing agile in a certain way. Be agile about agile. Be agile towards user requirements and have the test team talk to developers and product managers to make sure everyone is getting what they think they want.