Принято считать, что серьезной ИТ-компании не обойтись без отдела тестирования. Воплощая принцип разделения труда, тестировщики более эффективно вылавливают баги, разгружают разработчиков, повышают качество продукта и его ценность.
Мы привыкли к маркировке Q.A. Passed (от англ. Quality Assurance, обеспечение качества — процесс, который обеспечивает соблюдение необходимых методов, процедур, стандартов во время разработки продукта для достижения максимально идеального результата. — РБК Pro) на разной электронике и ожидаем, что с ИТ-продуктами контроль будет работать так же. Но разработка — это не конвейерное производство. Мировой опыт говорит о том, что в запутанных средах критерии оценки определяются для каждой фичи — это явно выходит за пределы компетенции обычных тестировщиков. С их привлечением размывается ценность продукта, растут его себестоимость и сроки разработки, внутри команды начинаются конфликты из-за неправильно разделенной ответственности. Разберем детально, почему так происходит.
Тестирование в запутанной среде
«Запутанные среды» — это понятие из фреймворка «Кеневин» (термин используется для объяснения эволюционной природы любых сложных систем. — РБК Pro), который делит все среды на четыре типа: простые, сложные, запутанные и хаотичные.
В линейных (простых и сложных) средах тестировщики достаточно строго следуют регламенту. Там все понятно: достаточно сверить план и факт, «прозвонить» детали или воткнуть прибор в розетку. Результат тестирования однозначен: продукт либо соответствует регламенту, либо нет.
