Что Мы называем кросс-тестированием
История возникновения термина "кросс-тестирование" в моем уже старом проекте следующая...
Проект-менеджер в очередной раз выразил свое неудовольствие - команда тестирует слишком много, и поэтому медленно (звучал комментарий, что мы вчетвером тестируем медленнее чем предыдущая команда из 2-х индусов!). Проект-менеджер предложил быть умнее и гибче (Agile) применить подход, названный им кросс-тестированием, а на деле оказавшийся тестированием нескольких близких функций одновременно одним тестировщиком (или группой тестировщиков).
Я выяснил, что в других параллельных проектах люди с подобным подходом сталкивались. никак этот подход не называли, но просто использовали его, когда приходило время и было удобно. И я решил оценить силы нашей команды, попытаться понять достоинства, недостатки и возможность использовать кросс-тестирование в отдельно взятом проекте.
Среди плюсов, конечно, стоит выделить выигрыш по времени. Совмещение в тестировании нескольких фич означает, что у них есть "общий путь" - шаги, которые можно выполнить, как для одной фичи, так и для другой. Ожидаемые результаты, конечно же должны отличаться. В зависимости от длины общего пути и получается полезный выигрыш во времени. В идеале, если обе фичи имеют одни и те же шаги - мы вдвое сокращаем время тестирования!
Как сладко звучит.
Потери времени от синхронизации тест планов
Понятное дело мы должны иметь хоть какой то тест план для каждой фичи, чтобы понять длину общего пути и вообще возможность этот самый путь создать. Т.е. кроме создания тест плана у нас появляются затраты времени на совмещение двух тест планов в один единый - Кросс-Тест План.
Размер времени зависит от размеров фич. В некоторых случаях это просто копирование-вставка. В иных - более интеллектуальный и более длительный процесс. Это один из немногих случаев когда Размер Имеет Значение ;)
Фичи могут быть готовы к тестированию в разное время
В жизни мы сталкиваемся с тем, что каждая фича имеет приоритет. Не факт, что фичи начнут разрабатываться одновременно и они будут готовы к тестированию в одном билде. Далеко не факт. В жизни случаются простои тестирования, поскольку вообще тестировать нечего до следующего билда (тестировщики наконец имеют шанс отдохнуть, обновить документацию, ну или попить чаю с печенюшками). Кросс тестирование предлагает ждать некоторым тестировщиками выхода следующего билда. Конечно же это нонсенс.
Баги дробят кросс-тест планы
Баги есть в любой программе, и они ставят под сомнение полезность кросс-тестирования в принципе В идеальном кросс-тесте мы не находим баги. В жизненном - баги имеют обыкновение появлятся веером. Итак, если мы кросс-тестируем две фичи, и в одной находим дефект, который признан критическим и подлежит исправлению, мы обязаны кросс-тест план разбить на две части обратно. В итоге мы теряем то время, которое было потрачено на создание кросс тест плана. Все бы ничего, но совмещая 3,4...n фич риски потери времени растут пропорционально (конечно же есть программисты, которые не делают критических багов, я допускаю их существование, но мне они не встречались). Если фич в тестплане несколько то кросс-тест план необходимо актуализировать - и мы имеем дополнительные потери времени.
Распределение задач между тестерами
На самом деле укрупнение и разделение обязанностей - это задача управления. Единственный минус укрупнения фич в кросс-тестировании это риск, что в определённых условиях некоторые тестировщики могут оказаться загруженными, в то время как другие страдают от безделья. Это не столько связано с кросс-тестированием, сколько вообще с распределением задач. Решение видится простым - разделять кросс-тест план на нескольких человек.
Но возникает вопрос - зачем кросс-тест план составлялся?
Повышение сложности сценариев тестирования
Среди минусов кросс-тестирования я бы выделил еще повышение сложности сценариев. В связи с тем, что в кросс-тест плане ожидаемых результатов становится больше - растет нагрузка на внимание и мышление тестировщика. В моем проекте тест сценарии вообще слабоформализованы. Я бы сказал классических тест сценариев у нас нет - есть чек листы и список ожидаемых результатов. Еще есть план, знания тестировщика и заметка от программиста какие области желательно покрыть. Поскольку это есть в нашем проекте - это может быть и в других проектах тоже.
Мой общий вывод по поводу применения кросс-тестирования в функциональном/приемочном тестировании - это один из способов выиграть во времени, но способ это имеет определенные ограничения.
1. Совмещать для кросс-тестирования следует небольшие фичи.
2. Метод очевидно хорошо работает в небольших командах, но в больших может привести к непропорциональному росту затрат на поддержание кросс-тест плана в адекватном состоянии (мне говорили, что в одном из проектов выделялся отдельный человек на поддержание кросс-тест плана, и кстати та команда работала по Agile ;))
3. Очевидно что кросс-тестирование неплохо работает с хорошо формализованными тест сценариями, но очень рискован с мало формализованными чек листами.
4. Затраты на кросс-тестирование повышаются с каждой итерацией тестирования.
Среди плюсов, конечно, стоит выделить выигрыш по времени. Совмещение в тестировании нескольких фич означает, что у них есть "общий путь" - шаги, которые можно выполнить, как для одной фичи, так и для другой. Ожидаемые результаты, конечно же должны отличаться. В зависимости от длины общего пути и получается полезный выигрыш во времени. В идеале, если обе фичи имеют одни и те же шаги - мы вдвое сокращаем время тестирования!
Как сладко звучит.
С чем мы сталкиваемся в жизни...
Потери времени от синхронизации тест планов
Понятное дело мы должны иметь хоть какой то тест план для каждой фичи, чтобы понять длину общего пути и вообще возможность этот самый путь создать. Т.е. кроме создания тест плана у нас появляются затраты времени на совмещение двух тест планов в один единый - Кросс-Тест План.
Размер времени зависит от размеров фич. В некоторых случаях это просто копирование-вставка. В иных - более интеллектуальный и более длительный процесс. Это один из немногих случаев когда Размер Имеет Значение ;)
Фичи могут быть готовы к тестированию в разное время
В жизни мы сталкиваемся с тем, что каждая фича имеет приоритет. Не факт, что фичи начнут разрабатываться одновременно и они будут готовы к тестированию в одном билде. Далеко не факт. В жизни случаются простои тестирования, поскольку вообще тестировать нечего до следующего билда (тестировщики наконец имеют шанс отдохнуть, обновить документацию, ну или попить чаю с печенюшками). Кросс тестирование предлагает ждать некоторым тестировщиками выхода следующего билда. Конечно же это нонсенс.
Баги дробят кросс-тест планы
Баги есть в любой программе, и они ставят под сомнение полезность кросс-тестирования в принципе В идеальном кросс-тесте мы не находим баги. В жизненном - баги имеют обыкновение появлятся веером. Итак, если мы кросс-тестируем две фичи, и в одной находим дефект, который признан критическим и подлежит исправлению, мы обязаны кросс-тест план разбить на две части обратно. В итоге мы теряем то время, которое было потрачено на создание кросс тест плана. Все бы ничего, но совмещая 3,4...n фич риски потери времени растут пропорционально (конечно же есть программисты, которые не делают критических багов, я допускаю их существование, но мне они не встречались). Если фич в тестплане несколько то кросс-тест план необходимо актуализировать - и мы имеем дополнительные потери времени.
Распределение задач между тестерами
На самом деле укрупнение и разделение обязанностей - это задача управления. Единственный минус укрупнения фич в кросс-тестировании это риск, что в определённых условиях некоторые тестировщики могут оказаться загруженными, в то время как другие страдают от безделья. Это не столько связано с кросс-тестированием, сколько вообще с распределением задач. Решение видится простым - разделять кросс-тест план на нескольких человек.
Но возникает вопрос - зачем кросс-тест план составлялся?
Повышение сложности сценариев тестирования
Среди минусов кросс-тестирования я бы выделил еще повышение сложности сценариев. В связи с тем, что в кросс-тест плане ожидаемых результатов становится больше - растет нагрузка на внимание и мышление тестировщика. В моем проекте тест сценарии вообще слабоформализованы. Я бы сказал классических тест сценариев у нас нет - есть чек листы и список ожидаемых результатов. Еще есть план, знания тестировщика и заметка от программиста какие области желательно покрыть. Поскольку это есть в нашем проекте - это может быть и в других проектах тоже.
Общие соображения по поводу применения кросс-тестирования в функциональном/приемочном тестировании
1. Совмещать для кросс-тестирования следует небольшие фичи.
2. Метод очевидно хорошо работает в небольших командах, но в больших может привести к непропорциональному росту затрат на поддержание кросс-тест плана в адекватном состоянии (мне говорили, что в одном из проектов выделялся отдельный человек на поддержание кросс-тест плана, и кстати та команда работала по Agile ;))
3. Очевидно что кросс-тестирование неплохо работает с хорошо формализованными тест сценариями, но очень рискован с мало формализованными чек листами.
4. Затраты на кросс-тестирование повышаются с каждой итерацией тестирования.
На самом деле мне так и не удалось получить реальные результаты пользы/вреда кросс-тестирования, не всегда получается: код выдается в разное время, фиксировать выигрыш по времени очень сложно, сравнивать статистики "с" и "без" - в нашем проекте практически невозможно.
Где реально работает кросс-тестирование
А работает кросс тестирование у нас в регрессии. Если стоит выбор - совмещать или нет - мы совмещаем. В одном регрессионном тест сценарии мы прогоняем от 2 до 10 тест сценариев. Выигрыш огромный. Почему кросс-тестирование работает в регрессии, но не работает в приемочном тестировании? У меня есть несколько мыслей.
Регрессия нам знакома, а новый функционал нам приходится изучать. Конечно даже прогоняя чек листы регрессии мы смотрим на приложение под разным углом. Этим мы и отличаемся от индусов - мы находим баги которым нескольких лет (московской команде тестировщиков меньше года, а приложение в поддержке уже почти 10 лет). Но во время приемочного тестирования, по большому счету, мы видим функционал в первый раз. "А что если", "а вдруг вот так", "ммм, а что тут".... Количество таких вопросов в регрессии и в новом функционале отличаются в разы.
PS. Нашему менеджеру я ответил, что мы конечно же используем это самое кросс-тестирование. И не наврал. Мы это делаем. Постоянно. В регрессии.
Комментариев нет:
Отправить комментарий