Несколько мыслей о том, что должно делать QA подразделение с ошибками и тестированием.
— То, что можно автоматизировать – нужно автоматизировать
Тут все просто. Если что-то может делать машина, то пусть она это и делает, на то мы существа и наделенные ленью.
Обратная сторона медали, если что-то автоматизируется плохо — нельзя тратить кучу времени пытаясь таки это автоматизировать.
— Все ошибки должны быть в системе багтрекинга
Нету большего врага QA и Dev подразделения, чем ошибки, которые передаются как предания — наскальной живописью, сказками и т.п.
— Ошибки должны иметь настолько дотошное описание, чтобы человек с улицы мог их повторить.
Экономия 30 секунд на описании ошибки выливается потом, в несколько часов попыток ее повторить, обсуждения с тестерами и т.п.
Кстати, это должно включать версии тестируемого продукта и детали, на какой конфигурации все тестировалось.
— Ошибки должны быть приоритезированы
Иногда QA это делают сами, иногда с менеджерами, иногда с разработчиками. Но в конечном итоге, ошибка типа «программа не устанавливается вообще», должна быть выше приоритетом, чем «показ лишнего пикселя в диалоге, которые запустит 1 из 1000 пользователей».
— Раз в некоторое время система контроля ошибок должна прочищаться
Обычно, за несколько лет, в ней накапливаются сотни ошибок, которые никто и никогда не будет исправлять, более того, которые даже уже повторить нельзя, так как программа кардинально изменена.
Этот мусор зачастую тяжело отделить каким-то автоматическим фильтром и приходится постоянно его видеть.
— QA отдел (из своего названия) должен гарантировать, что все крупные баги должны быть найдены
Один их самых плохих признаков, когда при втором проходе тестирования той же версии продукта, находятся серьезные дефекты.
— Тестирование должно быть планированным и эффективным
Всегда должен быть план, что будет тестироваться, как будет тестироваться. Сколько времени на это отведено. И за это время QA должно найти как можно больше серьезных багов.
Ну, и как добавок к статье, скажу, что внутри фирмы обычно QA занимает одну из двух позиций:
— отделение неформально подчинено программистам
То есть программисты и сами могли бы протестировать, но работу эту сбрасывают на QA отделение так как труд тестеров стоит дешевле и у них не такой «замыленный» глаз.
Проблема этой схемы, что тестеры в такой ситуации фактически не имеют права голоса и получается, что зачастую программистам удается «задавить» авторитетом тестеров и продукт выходит с крупными дефектами.
— отделение программистов неформально подчинено QA
Обычно это происходит, когда QA назначают ответственных за выпускаемый продукт. То есть, только когда QA менеджер говорит, продукт нормального качества, то продукт выходит в свет.
Тут складывается обратная ситуация, обычно тестировщикам удается «задавить» программистов и продукт перешлифовывается.
Нормальная ситуация, когда эти два отдела работают отдельно и менеджеры отделов решают когда выпускать или не выпускать продукт. Зачастую ситуация с перекосом в одну сторону происходит, если существует всего один менеджер, которые управляет обеими отделами. В таком случае его субъективное мнение клонит равновесие в одну из сторон.
