I was particularly keen on the aspects of software quality and Agile. Agile enables organizations to be more responsive to ever changing market demands. Agile enables organizations to have much faster cycle times, providing more of an iterative approach to delivery than in the traditional waterfall. With this comes features that better match the current market needs, faster delivery to market and in some cases improved quality.
Most of these organizations were fully in process with Agile software development but were playing "catchup" with testing. QA plays an interesting role in Agile environments. Many of these Agile practitioners went through the realization that QA no longer plays the same role that they did previously. Now that product owners are much more involved in the process, QA plays less of a role in determining whether the release meets requirements. QA instead plays more of a role on the delivery team - working closely with engineers to ensure that the proper tests are built and that the project passes all of the tests. Setting up the right acceptance tests are a critical role for the QA engineer. The goal of the developer is to write code that will pass the acceptance tests that are generally written at the beginning of the project.
The role of the developer also changes significantly. In order to meet quality needs, all agreed that test driven development (TDD) was the way to go. They also lamented about the challenges, such as developer resistance to writing and performing tests.
The biggest recommendation for testing was to automate tests as much as possible. Given the rapid cycle times, there is little time for traditional testing. Automating the test enables organizations to include testing within the sprint and deliver a production ready project at the end. Organizations that were in process of building good automation had to resort to follow on sprints after the sprint for testing. They would schedule a mini-sprint where developers and QA would test what was created in the prior sprint to make sure the quality was at a releasable state. Of course with a good test framework in place, developers and testers could automate their tests as they were "sprinting" so that during the next iteration, they could perform the same test without any manual intervention.
Static analysis also plays a big role here. Static analysis (or source code analysis) enables organizations to bring automated testing right to the developer. By analyzing their code before checking in their code, they can find potentially critical problems during the earliest part of the development cycle. Minimizing the time between coding and detection of problems makes developers makes them more efficient. Static analysis is an ideal automated testing tool because it requires no testcases and can generate a lot of good bugs in a short amount of time. Several leading organizations make it a requirement that all static analysis reports are at least looked at and fixed. Fixing a static analysis defect also usually takes a trivial amount of time.
Continuous integration was also another area of discussion. With multiple sprints on the same codebase going on in parallel, performing a system test on the entire system was a challenge for many organizations. Ensuring continuous integration enabled organizations to gain more efficiency from testing, especially with the fast cycle times many of these organizations have established and results in better code earlier.
Almost half of all software development organizations have moved or are moving to Agile. Building quality into the development process becomes even more paramount in an Agile process -- but it's not nearly as easy as it sounds. It's a long road to get there, fraught with not just tools issues but political and process issues -- but it's an integral part of making Agile work.
Posts
No comments:
Post a Comment