Victor Ronin's IT blog

Несколько мыслей о том, что должно делать QA подразделение с ошибками и тестированием.

— То, что можно автоматизировать – нужно автоматизировать

Тут все просто. Если что-то может делать машина, то пусть она это и делает, на то мы существа и наделенные ленью.

Обратная сторона медали, если что-то автоматизируется плохо — нельзя тратить кучу времени пытаясь таки это автоматизировать.

— Все ошибки должны быть в системе багтрекинга

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

— Ошибки должны иметь настолько дотошное описание, чтобы человек с улицы мог их повторить.

Экономия 30 секунд на описании ошибки выливается потом, в несколько часов попыток ее повторить, обсуждения с тестерами и т.п.

Кстати, это должно включать версии тестируемого продукта и детали, на какой конфигурации все тестировалось.

— Ошибки должны быть приоритезированы

Иногда QA это делают сами, иногда с менеджерами, иногда с разработчиками. Но в конечном итоге, ошибка типа «программа не устанавливается вообще», должна быть выше приоритетом, чем «показ лишнего пикселя в диалоге, которые запустит 1 из 1000 пользователей».

— Раз в некоторое время система контроля ошибок должна прочищаться

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

Этот мусор зачастую тяжело отделить каким-то автоматическим фильтром и приходится постоянно его видеть.

— QA отдел (из своего названия) должен гарантировать, что все крупные баги должны быть найдены

Один их самых плохих признаков, когда при втором проходе тестирования той же версии продукта, находятся серьезные дефекты.

— Тестирование должно быть планированным и эффективным

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

Ну, и как добавок к статье, скажу, что внутри фирмы обычно QA занимает одну из двух позиций:

— отделение неформально подчинено программистам

То есть программисты и сами могли бы протестировать, но работу эту сбрасывают на QA отделение так как труд тестеров стоит дешевле и у них не такой «замыленный» глаз.

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

— отделение программистов неформально подчинено QA

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

Тут складывается обратная ситуация, обычно тестировщикам удается «задавить» программистов и продукт перешлифовывается.

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