Tester's Weekdays

К сожалению, в своей практике я все чаще сталкиваюсь с фатальными последствиями допущенных на этапе тест дизайна ошибок. Тест дизайнер не доглядел, пропустил несколько важных проверок, а в итоге все оборачивается пропущенными дефектами. Они всплывают в самый неподходящий момент и приводят к серьезным негативным последствиям как для отношений с заказчиком, так и для проекта в целом. Все мы люди и ошибается каждый из нас, кроме лентяев, им в этой жизни везет больше. Избежать всех ошибок не выйдет, но сократить их количество на этапе составления тестов возможно. На мой взгляд, главный и самый эффективный метод - разделить процесс тест дизайна на две части: проектирование и оформление.

На долю каждого из нас выпадает "удача" выполнять работу в условиях частичной или полной неопределенности. Рано или поздно приходится сталкиваться с проектами, в которых формализованные требования отсутствуют от слова "совсем". Причины могут быть разными: некогда думать и писать, в команде нет аналитиков, в команде есть аналитик и совершенно случайным образом это невеста руководителя проекта, совсем недавно получившая повышение (но это, конечно, выдумка, в жизни так не бывает :). Все эти причины объединяет одно - какими бы глупыми и несправедливыми они ни были, приложение придется поставлять заказчику, придется его тестировать и разрабатывать тесты. И вот тест дизайнер берется за задачу, вот чистый лист и... наступает ступор.

По "счастливому" стечению обстоятельств в основном я занимаюсь тестированием молодых проектов. Назвать этот процесс "выполнением работы" не поворачивается язык, скорее это похоже на постоянную борьбу за выживание в условиях нехватки ресурсов (как времени, так и сотрудников), отсутствия документации, отсутствия процессов, постоянного неожиданного расширения контента поставки срочными задачами и т.д. В таких "спартанских" условиях умелое использование методологий разработки тестов выходит на передний план, т.к. необходимо сократить до минимума затраты на создание и поддержку тестовых сценариев. При этом важно поддерживать приемлемое качество последних, чтобы они не оседали мертвым грузом потраченного впустую времени, а приносили реальную пользу команде тестирования. В этой статье я расскажу о своем опыте применения методологии "Таблицы принятия решений" (Decision Table, далее я буду использовать сокращение DT). Вся необходимая теория изло...