Vu Lam is CEO of QASymphony. He has over eighteen years of software industry experience, including founding two outsourcing companies and building a nationwide infrastructure connecting Vietnam’s banks, stock brokerages, and commercial entities. In this Sticky ToolLook interview, he discusses testing in the agile world.
Sticky ToolLook: What are some ways in which bug reporting and test documentation differ for agile organizations compared to “traditional” organizations?
Vu Lam : With respect to test documentation, one significant difference is that in traditional organizations, testers usually design detailed test cases based on available requirement specifications before actually executing any of them, usually weeks or months later. In an agile setting, testers tend to adopt exploratory testing, where they combine test design, execution, and emerging learning. Test cases are still designed, but they are created in the minds of testers when they test instead of being written down beforehand. In a sense, this is similar to the way agile developers design their software. That is, they rely more on emerging design happening during coding and refactoring rather than following the instructions of design documents.
Why does this make sense for agile teams? Changes. Teams adopt agile processes for that exact reason: Changes are inevitable in their project. Think about it. There is no point in rigidly executing a test case if it is already out of date by the time you test. Besides the overhead of documenting it and keeping it up to date, it simply does not make sense.
Regarding bug reporting, there is no fundamental change to the process. Most testers in an agile team still resort to bug-tracking systems to manage bugs, and they still need to submit well documented bug reports that help developers reproduce and fix the bugs. However, testers on an agile team have to rely on multiple communication mediums with developers more often, rather than collaborating via a non-verbal or non-visual medium constrained by a complicated defect-resolution workflow. On some teams I have been a part of, we even used the same tracking system to manage both user stories and bugs. On yet other teams, we treated outstanding bugs of a sprint just like user stories. Simplification, however, requires the team to approach bug fixing just like any other task in an agile project: It must be driven by the value it brings to the business.
Sticky ToolLook: Agile organizations focus on communication, often aiming for regular, face-to-face feedback. What are some of the communication challenges specific to a testing team at an agile organization, and how can teams overcome those challenges?
Vu Lam : I know many testers are more comfortable dealing with use case specifications, test cases and emails, etc. than doing face-to-face communications. Sometimes, this is simply their working style. Unfortunately, more often than not, this is due to a lack of understanding about agile processes and a tendency to stick with old habits. To get over these, testers have to educate themselves as much as they can about the values and principles of agile development and understand that they, too, have to embrace these values and principles for agile development to work. Regular, face-to-face communication is just one of the principles of agile development that testers have to adopt.
Yet, with global teams, face-to-face communication is not always possible. While local teams can and need to practice it, distributed teams have to learn how to maximize effectiveness and rely on other communication venues such as phone, IM, collaboration tools, visual correspondence, and documentation of ideas and test results.
Sticky ToolLook: How should a global organization handle agile? That is, if teams (or