In a closed source environment, all testing activities are performed internally in the company. All tests (with the exception of unit tests performed by developers) are developed, executed, and controlled by the internal QA group. In contrast, in open source development, a significant amount of testing is performed by community users, independently from testing activities done by the internal QA group.

Having an independent community testing effort taking place in parallel and alongside the internal process presents the internal QA organization with both advantages and challenges. On one hand, it provides opportunities to leverage feedback from the community in early testing stages; prioritize testing activities and focus based on that feedback; and achieve results with fewer resources, and in less time, than that required by the QA organization in a closed source environment.

On the other hand, it introduces a new set of challenges that do not exist in the closed testing environment. The QA team is required to offer a unique angle to testing, one that is not covered by the community. As such, it needs to redefine the overall ‘added value’ and contribution QA provides to the quality of the product and the development process in general.

This talk will focus on the similarities and differences between the closed and open source testing models; the different roles, activities, and responsibilities an internal QA department has in each; the added value an internal QA department brings to an open source development environment; and the challenges it faces in leveraging community testing internally.