Важную роль в разработке ПО с открытым исходным кодом играют сообщества, объединяющие людей с различными знаниями, умениями, навыками, уровнями участия и т. д. Если принять во внимание изменчивость этих факторов и традиционную для Open Source высокую частоту выхода релизов, то обеспечение качества становится очень серьёзной практической проблемой.

Так считает Прити Томас — инженер по контролю качества проекта Pulp компании Red Hat. Она уверена, что эта задача может быть решена только совместными усилиями разработчиков и пользователей. Также эксперт отмечает четыре важнейших принципа, которые должны при этом соблюдаться.

Во-первых, необходимо интеграция инструмента непрерывного контроля качества в процесс разработки. В частности, проект Pulp использует решение Jenkins для запуска автоматизированных тестов и мониторинга результатов. Как правило, все необходимые операции производятся по ночам, а после успешных испытаний ночные сборки становятся доступными сообществу.

Подобная операция позволяет на раннем этапе выявить наиболее простые и часто встречающиеся проблемы. Например, регрессии или внесение заведомо недопустимых изменений в сборки, делающие их неработоспособными.

Это позволяет значительно облегчить работу тестеров, избавляя их от необходимости реагировать на достаточно тривиальные ошибки. А если принять во внимание, что тестированием часто занимаются добровольцы, то непрерывный автоматический контроль устраняет недостатки, искать которые им попросту неинтересно.

Во-вторых, средства автоматизированного контроля должны быть открытыми и достаточно гибкими, чтобы позволять разработчикам применять собственные тесты. Так, в проекте Pulp применяется распространяемое на условиях свободной лицензии решение Pulp Smash.

При необходимости любой разработчик может дополнить существующий набор собственными тестами, что позволит ему обнаружить ошибку на самом раннем этапе и максимально оперативно внести изменения в свою часть кода. Таким образом, практикуемый в быстроразвивающихся проектах принцип «release early, release often» (выпускай раньше, выпускай чаще) требует значительно меньших ресурсов.

В-третьих, целесообразно проведение специальных тестовых дней, что позволяет привлечь в сообщество новых участников. При этом сама процедура должна быть максимально формализована начиная от чётко документированных шагов тестирования и заканчивая способом размещения результатов в единой базе.

В частности, такой способ активно используется в проекте Fedora. Тестовые дни начинаются сразу после выхода альфа-версии, и связанные с этим дискуссии проходят на специальном канале IRC.

В-четвёртых, полезно привлекать сообщество для сортировки ошибок, в процессе который разработчики выясняют приоритеты исправления различных недостатков приложения. В этом заключается главное отличие метода от тестовых дней, цель которых — простое обнаружение проблем, но не ранжирование их по важности для пользователя.

В рамках этой процедуры участникам предоставляется возможность не только высказаться о степени важности исправления той или иной ошибки, но также предлагается протестировать обновления или даже самим попробовать устранить недостатки. И результаты порой превосходят самые смелые ожидания — в частности, в течении Foreman’s Bug Day было исправлено более ста различных ошибок.