Я 8 лет занимаюсь тестированием. Ручным и автоматизированным, в роли тестировщика и тест-менеджера, как сотрудник компании и как представитель аутсорса. И почти на всех проектах сталкиваюсь с одной и той же проблемой: руководители проектов не понимают, зачем им нужно тестирование.
Если задать среднестатистическому РМ'у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».
Но ведь приходя в парикмахерскую вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?
В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)
Упс… Если исходить из этого подхода, то во всех компаниях с тестированием всё в порядке. Баги находятся, фиксятся, проверяются… И что, тестирование всегда полезно? Всегда раскрывает весь свой потенциал?
Что-то мне подсказывает, что нет. Тогда в чём отличия между теми редкими случаями, когда «с тестированием всё отлично», и преобладающим большинством?
Попробую привести ещё одну иллюстрацию. Вы никогда в жизни не ходили на массаж. Вы заходите в салон (а что, все ходят, почему бы и вам не сходить?) и заказываете получасовой сеанс. У вас есть фиксированный бюджет и есть требования: «помассируйте меня». Невнятного вида дама невнятно возится с вашими вполне внятными плечами, кайфа никакого, вы выходите из салона и думаете «эх, массаж — фигня полная». Но ведь ваше требование «помассируйте меня» было выполнено! Может быть, дело в некорректности требования? У вас болела спина, и вы хотели, чтобы боль прошла? Или не хватало растяжки? Или хотелось релакса? Чем точнее требования, тем больше у исполнителя шансов их удовлетворить. Но если вы не можете сформулировать, что хотите, то и исполнитель не сможет сделать то, что нужно, и вы не сможете объективно оценить результат.
Упс… Простой пример из практики. Команда тестирования своевременно находит дефекты, команда разработки не располагает временем их исправить, продукт неизменным выходит на рынок, клиенты говорят «отстой»… Что, тестирование было плохим?
Или давайте наоборот. Тестировщики тщательно исследуют продукт, используя его и в хвост и в гриву, не находят ни одной ошибки, он выпускается на рынок, пользователи довольны, шапки летят в воздух, цветы отправляются на адрес фирмы-разработчика… Тестировщики молодцы или нет?
В общем примеров можно привести много. Но вывод почти всегда один: тестирование на качество никак не влияет. Так же как ваша стрижка не влияет на вашу успешность. «Эй, парикмахер, постригите меня так, чтобы я сдал экзамен!». Никакой логики, правда? В тестировании то же самое. Тестирование предоставляет информацию, в определённый бюджет, в определённом формате, с определённой скоростью… Но тестирование никак не влияет на качество, даже если очень хочет.
Что же тогда может предоставить тестирование?
Все наши результаты, вся наша работа описывается формулой из четырёх переменных: тестовое покрытие, предоставляемая информация, скорость и бюджет.
Давайте сначала рассмотрим эти пункты, а потом перейдём к самим формулам.
Это % возможных пользовательских сценариев, условий, настроек, входных параметров и т.д., который был проверен группой тестирования. Чем выше этот процент, тем больше найдено багов, тем меньше пропущено. Тем больше багов можно исправить при желании и возможности.
При этом, тестовое покрытие и количество тестов, а так же затраченные на тестирование ресурсы, связаны очень косвенно. Квалифицированные тестировщики имеют целый арсенал техник и инструментов, позволяющих «впихнуть невпихуемое», aka оптимизировать тестовый набор, aka обеспечить максимальное покрытие при минимальном количестве тестов.
Покрытие можно и нужно измерять: traceability matrix, code coverage, % пропущенных дефектов и масса других метрик вам в помощь.
Годами живёт мем о тестировщике, с паникой в глазах говорящем «ничего не работает!». А если попросить объяснить подробнее, он отвечает: «ну совсем ничего!». Возможно, он обеспечил хорошее тестовое покрытие, но, увы, адекватную информацию не предоставил. Какая же информация может быть нужна проекту от тестирования?
Если группа тестирования не предоставляет внятной информации о продукте и проекте (а это её основная функция!), то принимать решения очень сложно.
ОК, покрытие хорошее, информация чёткая… Только поздно. Или долго. Или долго, и поэтому поздно.
Все вы явно сталкивались с ситуацией: до релиза 3 дня, находится критичный баг. Разработчик получает по голове, начинает исправлять, и тут оказывается, что багу этому без недели полгода, и вообще-то его можно было найти значительно раньше. И что этот баг 2 месяца назад был бы исправлен за полчаса, а теперь на него полпродукта завязано, и возиться придётся неделю.
Мало кто берётся анализировать проекты по ТОС, и мало кто замечает, что тестирование иногда удлиняет релизы в несколько раз. Вот замените тестирование на своевременное, и получите релиз в два раза быстрее.
Обычно это незаметно, и кажется, что баги — источник всех бед… А ведь иногда найти их раньше = сократить затраты на весь цикл разработки!
Или другой аспект скорости тестирования: время, требуемое для проверки сборки. К примеру, готовимся к релизу. Получаем RC (релиз кандидат). Тестированию нужна неделя, чтобы убедиться в его работоспособности, РМ соглашается, выделяет неделю, на пятый день находится критичный баг… 10 минут на фикс, и снова 5 дней, и снова на пятый находится критичный баг… Сталкивались? Звучит знакомо?
Пожалуй, это самый простой пункт из всех. Естественно, он относителен. 1000 рублей — это много или мало? Для батона хлеба, пожалуй, много, для поездки на Бали, пожалуй, мало. Поэтому бюджет — это те деньги, которые вы готовы платить, но не за «тестирование», а за конкретные и понятные результаты этого самого тестирования.
А дальше вот что. Чтобы принести проекту максимум пользы, вы должны точно знать, что ему сейчас нужно. Чтобы знать что нужно, вам необходимо анализировать его показатели, что именно за пределами нормы: сроки, качество или бюджет. И уже после этого создавать вашу уникальную формулу с требованиями к тестированию. При этом, будем честны: «сократить сроки» или «увеличить покрытие» — это всё те же «помассируйте меня».
Нужны точные показатели. Зачем? Чтобы оценивать изменения. Чтобы следить, правда ли они влияют на показатели всего проекта в целом (будем честны, покрытие само по себе вам не нужно!). Чтобы контролировать процесс.
Заметьте, я нигде не говорила «юнит-тесты», «автоматизация», «тест-дизайн» и т.д. Все действия вносятся в процесс только по результатам определённых целей! Нужно повысить скорость тестирования сборки? Внедряем автоматизацию. Нужно повысить скорость нахождения дефектов? Модульные тесты. Качество отчётности? Модерацию дефектов. В тестировании сотни подходов, инструментов, решений, которые можно комбинировать исходя из ваших целей. Но сами по себе инструменты вторичны.
Поэтому, КАК тестировщик/тест-менеджер/тест-аутсорсер будет достигать ваши цели — это его головная боль. Но никто лучше внимательного к своему проекту РМ'а не скажет, что этому проекту нужно!
Если задать среднестатистическому РМ'у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».
Но ведь приходя в парикмахерскую вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?
В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)
Зачем вообще формулировать какие-то ожидания от тестирования?
Камон! Тестирование — это всякие там нажимания на кнопки, хорошо если автоматизированные. И так понятно, какие цели! Нужно находить баги, и чем больше, тем лучше. Какие ещё могут быть цели у тестирования?
Упс… Если исходить из этого подхода, то во всех компаниях с тестированием всё в порядке. Баги находятся, фиксятся, проверяются… И что, тестирование всегда полезно? Всегда раскрывает весь свой потенциал?
Что-то мне подсказывает, что нет. Тогда в чём отличия между теми редкими случаями, когда «с тестированием всё отлично», и преобладающим большинством?
Попробую привести ещё одну иллюстрацию. Вы никогда в жизни не ходили на массаж. Вы заходите в салон (а что, все ходят, почему бы и вам не сходить?) и заказываете получасовой сеанс. У вас есть фиксированный бюджет и есть требования: «помассируйте меня». Невнятного вида дама невнятно возится с вашими вполне внятными плечами, кайфа никакого, вы выходите из салона и думаете «эх, массаж — фигня полная». Но ведь ваше требование «помассируйте меня» было выполнено! Может быть, дело в некорректности требования? У вас болела спина, и вы хотели, чтобы боль прошла? Или не хватало растяжки? Или хотелось релакса? Чем точнее требования, тем больше у исполнителя шансов их удовлетворить. Но если вы не можете сформулировать, что хотите, то и исполнитель не сможет сделать то, что нужно, и вы не сможете объективно оценить результат.
Какими могут быть ожидания от тестирования?
Тестирование нужно для того, чтобы повышать качество продукта. Ну это же очевидно!
Упс… Простой пример из практики. Команда тестирования своевременно находит дефекты, команда разработки не располагает временем их исправить, продукт неизменным выходит на рынок, клиенты говорят «отстой»… Что, тестирование было плохим?
Или давайте наоборот. Тестировщики тщательно исследуют продукт, используя его и в хвост и в гриву, не находят ни одной ошибки, он выпускается на рынок, пользователи довольны, шапки летят в воздух, цветы отправляются на адрес фирмы-разработчика… Тестировщики молодцы или нет?
В общем примеров можно привести много. Но вывод почти всегда один: тестирование на качество никак не влияет. Так же как ваша стрижка не влияет на вашу успешность. «Эй, парикмахер, постригите меня так, чтобы я сдал экзамен!». Никакой логики, правда? В тестировании то же самое. Тестирование предоставляет информацию, в определённый бюджет, в определённом формате, с определённой скоростью… Но тестирование никак не влияет на качество, даже если очень хочет.
Что же тогда может предоставить тестирование?
Все наши результаты, вся наша работа описывается формулой из четырёх переменных: тестовое покрытие, предоставляемая информация, скорость и бюджет.
Давайте сначала рассмотрим эти пункты, а потом перейдём к самим формулам.
1. Тестовое покрытие
Это % возможных пользовательских сценариев, условий, настроек, входных параметров и т.д., который был проверен группой тестирования. Чем выше этот процент, тем больше найдено багов, тем меньше пропущено. Тем больше багов можно исправить при желании и возможности.
При этом, тестовое покрытие и количество тестов, а так же затраченные на тестирование ресурсы, связаны очень косвенно. Квалифицированные тестировщики имеют целый арсенал техник и инструментов, позволяющих «впихнуть невпихуемое», aka оптимизировать тестовый набор, aka обеспечить максимальное покрытие при минимальном количестве тестов.
Покрытие можно и нужно измерять: traceability matrix, code coverage, % пропущенных дефектов и масса других метрик вам в помощь.
2. Предоставляемая информация
Годами живёт мем о тестировщике, с паникой в глазах говорящем «ничего не работает!». А если попросить объяснить подробнее, он отвечает: «ну совсем ничего!». Возможно, он обеспечил хорошее тестовое покрытие, но, увы, адекватную информацию не предоставил. Какая же информация может быть нужна проекту от тестирования?
- Качественно описанные баги в баг-трекере
- Статистическая информация о продукте для прогнозирования релизов и принятия решений по процессам
- Метрики качества для принятия решений о релизах
- Оценка самого тестирования: какое покрытие, что проверено, насколько достаточно тестирование и т.д.
Если группа тестирования не предоставляет внятной информации о продукте и проекте (а это её основная функция!), то принимать решения очень сложно.
3. Скорость тестирования
ОК, покрытие хорошее, информация чёткая… Только поздно. Или долго. Или долго, и поэтому поздно.
Все вы явно сталкивались с ситуацией: до релиза 3 дня, находится критичный баг. Разработчик получает по голове, начинает исправлять, и тут оказывается, что багу этому без недели полгода, и вообще-то его можно было найти значительно раньше. И что этот баг 2 месяца назад был бы исправлен за полчаса, а теперь на него полпродукта завязано, и возиться придётся неделю.
Мало кто берётся анализировать проекты по ТОС, и мало кто замечает, что тестирование иногда удлиняет релизы в несколько раз. Вот замените тестирование на своевременное, и получите релиз в два раза быстрее.
Обычно это незаметно, и кажется, что баги — источник всех бед… А ведь иногда найти их раньше = сократить затраты на весь цикл разработки!
Или другой аспект скорости тестирования: время, требуемое для проверки сборки. К примеру, готовимся к релизу. Получаем RC (релиз кандидат). Тестированию нужна неделя, чтобы убедиться в его работоспособности, РМ соглашается, выделяет неделю, на пятый день находится критичный баг… 10 минут на фикс, и снова 5 дней, и снова на пятый находится критичный баг… Сталкивались? Звучит знакомо?
4. Бюджет
Пожалуй, это самый простой пункт из всех. Естественно, он относителен. 1000 рублей — это много или мало? Для батона хлеба, пожалуй, много, для поездки на Бали, пожалуй, мало. Поэтому бюджет — это те деньги, которые вы готовы платить, но не за «тестирование», а за конкретные и понятные результаты этого самого тестирования.
Ну и что дальше?
А дальше вот что. Чтобы принести проекту максимум пользы, вы должны точно знать, что ему сейчас нужно. Чтобы знать что нужно, вам необходимо анализировать его показатели, что именно за пределами нормы: сроки, качество или бюджет. И уже после этого создавать вашу уникальную формулу с требованиями к тестированию. При этом, будем честны: «сократить сроки» или «увеличить покрытие» — это всё те же «помассируйте меня».
Нужны точные показатели. Зачем? Чтобы оценивать изменения. Чтобы следить, правда ли они влияют на показатели всего проекта в целом (будем честны, покрытие само по себе вам не нужно!). Чтобы контролировать процесс.
Заметьте, я нигде не говорила «юнит-тесты», «автоматизация», «тест-дизайн» и т.д. Все действия вносятся в процесс только по результатам определённых целей! Нужно повысить скорость тестирования сборки? Внедряем автоматизацию. Нужно повысить скорость нахождения дефектов? Модульные тесты. Качество отчётности? Модерацию дефектов. В тестировании сотни подходов, инструментов, решений, которые можно комбинировать исходя из ваших целей. Но сами по себе инструменты вторичны.
Поэтому, КАК тестировщик/тест-менеджер/тест-аутсорсер будет достигать ваши цели — это его головная боль. Но никто лучше внимательного к своему проекту РМ'а не скажет, что этому проекту нужно!
