Asia's Largest Forum for the Software Testing Community

The Distributed Agile Model

Agile methodology emphasizes collocation of Agile team members, because they can meet face-to-face daily to discuss status across the entire project, show one another the exact steps required to reproduce a bug, understand at first hand why the business analyst feels that the acceptance tests are not validating the business logic, etc. Splitting an Agile workgroup into two or more groups, whether they are within the same building or on opposite sides of the globe, therefore seems “anti-Agile”, and we might expect them therefore to fail. However, we have seen “distributed Agile” work, where Agile guidelines are adjusted so that its other advantages, e.g. continuous integration, short cycles, guaranteed delivery of working code, etc., are realized despite the loss of high bandwidth in communication.

Exploratory Testing: The State of the Art

“Exploratory testing” as a term was coined by Cem Kaner in the 1980s, but skilled testers were doing exploratory testing well before the term was defined, and anyone who tests anything does exploratory to some degree. In late January 2006, ten skilled testers met in Palm Bay, Florida for the Exploratory Testing Research Summit (ExTRS), a peer conference on the Los Altos Workshops on Software Testing (LAWST) model.

Achieving more with less

Conference Plenary at STeP-IN SUMMIT 2010 (February 2010)

Shishank Gupta, Delivery Manager, Independent Validation Solutions, Infosys Technologies

Quality Assurance (QA) teams are usually looked upon as the entity to define the predictable state to stop testing and move into production. Often the mechanics behind this prediction lean towards intuition and general knowledge of the application, as opposed to formula-based discrete numbers which are more objective. To predict accurately one needs a sound knowledge of domain, past quality levels and defect semantics. Further, QA teams often find themselves with their backs to the wall with inflexible schedules and budget constraints. So, if QA teams are to answer the question “How much testing is enough?”, they need quantitative and scientific data that not only convinces them, but also the larger application development community.