In the days of waterfall, software Testers created test scripts from the mounds of requirements and rigidly and methodically executed those test scripts against the functionality that the development team delivered. The bug remediation process was often a sizable endeavor that took place in a large way as we approached milestones and immediately before we had to deliver software. In many cases, development stopped, and developers sat around and waited for Testing results for hours or sometimes days. The testers and developers often did not work together as a cohesive group and in the case of larger projects with dozens of team members, the communication between testers and developers was routinely done late in the process and was not very effective.

With Agile, testers and developers not only work closely together during development, they communicate openly and can foster a great deal of synergy. The “us versus them” mindset that often crept into waterfall development is gone and the two roles work together to develop and deliver the best products possible. We no longer “throw the software over the wall” for the QA group to pick apart, but we utilize our own individual roles, skill sets, understanding of the problem domain, and unique insights into not just the product we are developing but the problems and processes that our customer lives with everyday.

Continuous Testing and Perpetual Quality

Testing in an Agile environment is continuous. Developers test rigorously as they develop, and often turn to the testers and business analysts to provide functional expertise. In other words, though testing is done continuously, the routine interaction between developers and testers often puts the testers in an advisory role as well. Since the development team often publishes or deploys new functionality into the development/test environment(s) on nearly a daily basis, verification and feedback from the testers is immediate.

Testing and Quality Assurance under Agile is not a phase at the end of a development effort. Rather, it is seamlessly woven into the process and is an integral part of the total endeavor. There is no separation between developing and testing – testing is just an ongoing activity that ensures the validity and correctness of the functionality that is being developed.

Agile Testers are Involved!

In an Agile environment, testers are actively involved in discussions with the customer and the creation of user stories. Along with the business analysts, they develop an intimate knowledge of the true needs of the customer and are directly involved in the software design strategy from the standpoint of testing. Beyond this, they actively participate in the segregation and decomposition of user stories  and the estimation of the overall development and testing efforts for each.

In contrast to the days of waterfall where testers were often viewed as bottlenecks and impediments, with Agile they actively propel the team and the effort forward with their insights, understanding of the customer’s needs, and they do all of this with a keen eye on not just the act of testing, but the testability of the functionality created.

Agile Testers Become Subject Matter Experts (SMEs)

As we stated in the previous section, with Agile, testers are actively involved in discussions with the customers. This includes senior management, functional management, and the people who are in the middle of the day-to-day operations of the business. The testing practice within an Agile environment places the testers in an advisory role in a way that waterfall never could have. This means that part of the normal, continuous interaction between developers and testers includes testers providing subject matter expertise in many situations. Therefore, testers should take it upon themselves to be SMEs. In fact, the testers and the business analysts should collectively possess nearly the entire body of knowledge of the functional personnel with whom they gleaned the user stories that drive development. That sounds like a tall order but it is necessary to ensure the effective delivery of acceptable products. It allows the Agile development team to be as self-supporting as possible while providing a basis from which software that truly meets the needs of the customer can be developed.

What Makes a Good User Story?

A good user story is complete, accurate, detailed, and from the standpoint of QA, it is testable! Though this may sound nonsensical because after all, don’t we already know that? We should know that, but it is important to explicitly make the statement. A good user story is testable.

Must Haves – Continuous Integration and Automated Testing

Continuous Integration is a concept that calls for every developer to continuously integrate his/her changes into the master Code base. This obviously necessitates a suitable source control repository such as Microsoft Team Foundation Server (TFS), and there are many others that serve the purpose very well. Regardless of the chosen source control tool, the process dictates that every change be compiled/built against the latest code base prior to any changes being checked in. Each developer must adhere to this, and it’s pretty simple.

Beyond that, automated builds should be implemented. The build server(s) should be configured to get the latest version of the code base and compile/build the code periodically throughout the day or at least based on a pre-defined schedule. Once the latest code has been retrieved, the build server(s) should then execute any prescribed automated tests. If the code coverage is high enough, problems that would go unnoticed for days or weeks can be uncovered very quickly to facilitate rapid remediation. The topic of code coverage is pretty important because the purpose of automated tests is to holistically ensure the integrity of the code base at all levels. This cannot be done unless the code coverage is as close to 100% as realistically possible.

As the software we build becomes more complex and we have multiple layers that are ideally loosely-coupled, the need for automated unit testing becomes paramount. With unit testing, individual tests have extremely narrow focus. As we move up the layer stack, we don’t deviate from this but we understand that when we reach the business logic layer (BLL), we may have dozens of business services with potentially hundreds or thousands of methods, each of which relies upon some lower-level object or objects. If we build our unit tests from the bottom up, consider all the possible scenarios and outcomes, and we orchestrate our automated tests to exercise all layers of our code from the bottom up, our code coverage approaches 100%. The daily or periodic execution of these batteries of tests ensures that the integrity of our application’s layers remains in tact as we move through development. Remember, Continuous Integration requires us to always know that our code base is sound.

Automated testing tools and cohesive automated testing methodologies are critical to the delivery of quality software under Agile. Developers must have a sense of ownership in every piece of functionality they develop. Unit testing is vital to their development process and code coverage should be very high. I don’t want to go too deeply into the specifics of automated testing in this post, but it is important to recognize its importance with regard to Agile.

Finally…

In summary, within an Agile environment, testing is not a phase at the end of the development initiative. Instead, it is an integral part of the overall development effort. It is executed daily by developers who not only write unit tests for their code, but who diligently test all functionality they build. Testing and QA in general is sewn into the fabric of the overall initiative and testers work directly with the developers on a daily basis, not just specifically as QA providers, but as SMEs and advisers. Testers in the Agile environment work directly with the customer and serve a very important role in combination with the business analysts. With Agile, our overall view of testing changes dramatically from the days of waterfall and we live by the concept of perpetual quality.

Filed under: Agile Tagged: Agile, Agile Development, Agile Methodology, Agile Project Management, Agile Testing, Automated Testing, Build Server, Coded UI Tests, Continuous Integration, QA, Software Quality Assurance, Team Foundation Server, Testing, Testing with Agile, TFS, Unit Test, Unit Testing