QA — для пограничных случаев

При нынешнем масштабе Basecamp — миллионы пользователей и около дюжины человек в продуктовой команде — у нас один специалист по обеспечению качества, QA. Он подключается ближе к концу цикла и ищет пограничные случаи за пределами основной функциональности.

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

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

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

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

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