Сказки про ссоры разработчиков и тестировщиков когда-то были правдой, но сейчас таких конфликтов почти не встретишь. Спокойная совместная работа над выпуском ПО, ориентация на общие цели, бла-бла-бла…
Но если присмотреться внимательнее, то под видимостью продуктивного сотрудничества зачастую скрывается абсолютное непонимание разработчиков: «зачем эти тестеры вообще нужны??». Это непонимание нередко является взаимным, и несмотря на кажущуюся миролюбивость, оставляет в совместной работе лишь видимость продуктивности.
1. Квалифицированных тестировщиков мало.
Это вызывает вполне ожидаемое негативное отношение со стороны разработчиков к преобладающему большинству тестировщиков, которых невозможно отнести к числу «квалифицированных».
2. Тестирование далеко не всегда приносит пользу.
Вообще, оценить эффективность тестирования сложно. Не каждый проект может похвастаться понятными и измеримыми целями тестирования. Поэтому, тестеры часто считают «чем больше багов, тем лучше». Но найденные дефекты — это ещё не польза!
3. Тестирование часто «отвлекает время» у разработки.
Чтобы глубоко вникнуть в продукт, его архитектуру, правильные тестировщики неизбежно докапываются к разработчикам. Ну а кто это любит? :)
4. РМ'ы зачастую подливают масла в огонь, считая «есть баг? надо фиксить!»
Но не всё нужно фиксить, и тем более не всё нужно фиксить сейчас. Многие разработчики, которые это понимают, вместо споров с РМ'ами предпочитают прятать дефекты.
5. Некоторые разработчики расстраиваются наличию ошибок.
Тоже, в принципе, логично. Я старался, старался, а тут бац — ошибки! Осознанно мы понимаем, что это правильно и что так мы сделаем софт лучше, но подсознательно неприятно и хочется не допустить повторения.
В итоге получается замкнутый круг. Из-за перечисленных выше пяти причин (и возможно не только их) разработчики считают, что тестирование им нафик не нужно. В итоге они не поддерживают тестирование так, как стоило бы. В итоге тестировщики не могут сделать свой максимум, и это всё приводит к повторению всё тех же причин.
В стандартной схеме, когда разработчики пишут-пишут, а потом дают тестировщикам продукт на тестирование (продукт!), есть большая засада. К примеру, три месяца, полгода разработки прошли, прежде чем оформилось что-то, похожее на пользовательский продукт. Этот продукт тестируют тестировщики. Заводят газионны дефектов, которые непонятно как локализовать (и разработчики, матюгаясь на плохие баги, подолгу выясняют, что и где не так). Локализовывать сложно, фиксить сложно, а что самое ужасное — баги появляются и появляются. Завтра релиз? А вот вам ещё 10 критикалов! Начинается холодная война :) Ушли в релиз? А баги всё находятся и находятся.
И мнение в бесполезности тестирования подтверждается, и всё идёт по кругу.
На самом-то деле, при отсутствии понятных целей тестирования, в вышеописанном развитии событий нет ничего удивительного. Но бывает и по-другому. К счастью :)
Любой проект хочет зарелизиться как можно быстрее, как можно успешнее и как можно качественнее. Конечно, информация о дефектах в продукте помогает оценить статус продукта, но зарелизиться быстрее и успешнее? Врядли.
А что помогает?
1. Формализация целей тестирования.
А зачем оно надо? Что хочется получить в результате?
Если изначально подходить с идеей «ну, от тестинга пользы нет», то её не будет. А если вникнуть, почесать репу, побрейнштормить, порисовать майнд-мепы, то всегда можно придумать как оно правильнее всего должно быть именно у вас. Но здесь залог успеха — не просто видимость конструктива, а действительно плотное сотрудничество разработки и тестирования.
2. Тестирование с первых дней разработки.
Это та штука, от которой бегает почти любой разработчик. А зря. Логика разработчика обычно следующая: «у меня пока нет готового продукта, не надо ничего тестить!». Но баги в готовом продукте находить сложнее, позже, дольше, и фиксить их тоже сложнее! Как только появляется первый компонент с хотя бы чуть-чуть стабильными интерфейсами, его надо тестировать!
Что ещё даёт компонентное тестирование?
3. Infosharing.
То есть, деление информацией. По максимуму. Если кто-то где-то когда-то сказал, что эффективнее тестировать софт, не зная, как он устроен — вас обманули. Тестировщики НЕ знают, что влияет на выполнение той или иной операции. Опции UI? Без проблем. Но обычно, помимо них, есть ещё масса факторов, которые знают только разработчики.
Что делать?
ДЕЛИТЬСЯ И НЕ ЖАДНИЧАТЬ!
Спрятанный маленький дефект сегодня — риск большого геморроя завтра.
4. Выработать общий подход к дефектам.
Конечно, если разработчик не хочет сегодня переключаться на какой-то там багфикс, то он сделает всё, чтобы баги спрятать. Звучит старомодно, сейчас так не делают? Неправда, делают. Это естественный процесс :)
Зато, если разработчики знают, что баги в BTS (bug tracking system) — это лишь информация, но далеко не всегда сигнал к действию, то и расстраивать их наличие не будет.
При этом, для тестирования иногда фикс некоторых багов очень важен. Их принято называть Blocker'ами (это дефекты, которые могут быть и не очень критичными с точки зрения пользователя, но препятстсвуют тестированию какой-то существенной части функционала). Вот их правда фиксить надо, важно, и желательно быстро.
5. Не мерять результат попугаями.
Иногда руководство проекта хвалит тестеров, которые нашли критикал за пару часов до релиза. Много багов? Молодцы. Разработчиков руководство тоже зачастую пытается померять, к примеру, KLOC'ами. Но ни количество кода, ни количество багов не приближают нас к релизу, иногда — наоборот! Что действительно является показателем эффективности совместной работы?
Только релиз. Своевременный и качественный.
А это значит, что дефекты, строки кода, средняя критичность и прочая лабуда — это формализм, который помогает руководству чувствовать себя у руля, глядя на графики.
p.s. В одной компании, где я работала, в один прекрасный день ввели оценку разработчиков по количеству написанных строк кода. В следующем месяце суммарно было почти в два раза больше закоммиченного кода. Только представьте себе его качество :)
Формализм концентрирует внимание на циферках и удаляет от результата.
6. Обеспечение testability продукта.
Нам (мы = весь проект, а не только тестеры!) очень важно иметь возможность оперативно тестировать наш софт. А для этого иногда приходится постараться. Фиксить блокеры? Создавать дополнительные интерфейсы для тестирования? Обещать стабилизацию интерфейсов и всячески выполнять своё обещание?
Это важно! Очень…
В эффективном тестировании заинтересованы все участники проекта. Оно позволяет экономить затраты на разработку и багфикс, нивелировать проектные риски, повышать качество продукта, избавлять разработчиков от лишних задач… Вообще, если на проекте правильное тестирование, то суммарное количество найденных дефектов обычно только ниже!
НО!
Тестировщики далеко не всегда могут обеспечить это самое «правильное» тестирование без помощи, поддержки и понимания со стороны разработчиков и РМ'ов.
Чтобы это происходило, нам надо больше общаться. Узнавать, кто какие результаты ждёт от тестирования, какие цели ставит. Кому что нужно для помощи, кому что не нравится в текущем процессе.
Открыто обсудив такие вопросы, мы можем сделать тестирование и проект в целом значительно эффективнее, и главное препятствие на этом пути — не заказчики, не инструменты, не технологии, а всего лишь непонимание.
Но если присмотреться внимательнее, то под видимостью продуктивного сотрудничества зачастую скрывается абсолютное непонимание разработчиков: «зачем эти тестеры вообще нужны??». Это непонимание нередко является взаимным, и несмотря на кажущуюся миролюбивость, оставляет в совместной работе лишь видимость продуктивности.
Почему такое происходит?
1. Квалифицированных тестировщиков мало.
Это вызывает вполне ожидаемое негативное отношение со стороны разработчиков к преобладающему большинству тестировщиков, которых невозможно отнести к числу «квалифицированных».
2. Тестирование далеко не всегда приносит пользу.
Вообще, оценить эффективность тестирования сложно. Не каждый проект может похвастаться понятными и измеримыми целями тестирования. Поэтому, тестеры часто считают «чем больше багов, тем лучше». Но найденные дефекты — это ещё не польза!
3. Тестирование часто «отвлекает время» у разработки.
Чтобы глубоко вникнуть в продукт, его архитектуру, правильные тестировщики неизбежно докапываются к разработчикам. Ну а кто это любит? :)
4. РМ'ы зачастую подливают масла в огонь, считая «есть баг? надо фиксить!»
Но не всё нужно фиксить, и тем более не всё нужно фиксить сейчас. Многие разработчики, которые это понимают, вместо споров с РМ'ами предпочитают прятать дефекты.
5. Некоторые разработчики расстраиваются наличию ошибок.
Тоже, в принципе, логично. Я старался, старался, а тут бац — ошибки! Осознанно мы понимаем, что это правильно и что так мы сделаем софт лучше, но подсознательно неприятно и хочется не допустить повторения.
Что получается в итоге?
В итоге получается замкнутый круг. Из-за перечисленных выше пяти причин (и возможно не только их) разработчики считают, что тестирование им нафик не нужно. В итоге они не поддерживают тестирование так, как стоило бы. В итоге тестировщики не могут сделать свой максимум, и это всё приводит к повторению всё тех же причин.
В стандартной схеме, когда разработчики пишут-пишут, а потом дают тестировщикам продукт на тестирование (продукт!), есть большая засада. К примеру, три месяца, полгода разработки прошли, прежде чем оформилось что-то, похожее на пользовательский продукт. Этот продукт тестируют тестировщики. Заводят газионны дефектов, которые непонятно как локализовать (и разработчики, матюгаясь на плохие баги, подолгу выясняют, что и где не так). Локализовывать сложно, фиксить сложно, а что самое ужасное — баги появляются и появляются. Завтра релиз? А вот вам ещё 10 критикалов! Начинается холодная война :) Ушли в релиз? А баги всё находятся и находятся.
И мнение в бесполезности тестирования подтверждается, и всё идёт по кругу.
Что тестирование может дать разработке такого вкусного и полезного?
На самом-то деле, при отсутствии понятных целей тестирования, в вышеописанном развитии событий нет ничего удивительного. Но бывает и по-другому. К счастью :)
Любой проект хочет зарелизиться как можно быстрее, как можно успешнее и как можно качественнее. Конечно, информация о дефектах в продукте помогает оценить статус продукта, но зарелизиться быстрее и успешнее? Врядли.
А что помогает?
1. Формализация целей тестирования.
А зачем оно надо? Что хочется получить в результате?
Если изначально подходить с идеей «ну, от тестинга пользы нет», то её не будет. А если вникнуть, почесать репу, побрейнштормить, порисовать майнд-мепы, то всегда можно придумать как оно правильнее всего должно быть именно у вас. Но здесь залог успеха — не просто видимость конструктива, а действительно плотное сотрудничество разработки и тестирования.
2. Тестирование с первых дней разработки.
Это та штука, от которой бегает почти любой разработчик. А зря. Логика разработчика обычно следующая: «у меня пока нет готового продукта, не надо ничего тестить!». Но баги в готовом продукте находить сложнее, позже, дольше, и фиксить их тоже сложнее! Как только появляется первый компонент с хотя бы чуть-чуть стабильными интерфейсами, его надо тестировать!
Что ещё даёт компонентное тестирование?
- Простой багфикс. Не надо подолгу локализовывать проблемы, сразу видно, где что не так.
- Нахождение прячущихся дефектов. В большом продукте со сложной архитектурой дефекты на нижнем уровне всегда просто спрятать: не давать вводить что-то в UI, к примеру. Но если уровнем ниже живёт баг, не видимый пользователю — значит, в продукте бага нет! Зато, есть риск, что он появится завтра :) Что мешает словить его сегодня и нивелировать риски?
- Снижение периода стабилизации ПО. Как обычно выглядит график сходимости дефектов на проекте? Критичность заводимых дефектов начиная с какого-то момента снижается, а их количество растёт. Это период «разблокировки» функционала для тестирования. У нас не открывается окно в программе? Блокер. Но мы не можем найти 10 дефектов на этой форме. Починили? Но не работает поле ввода и ещё ~9 проблем в окне. Критикалы. Починили? Нашли 10 небольших ошибок в текстовом поле. И т.д. Рекурсия. Ошибок всё больше, но они всё меньше. А пока ошибок мало, но они страшные, тестировщики плюют в потолок в ожидании фикса. Половина разработчиков тоже плюют в потолок, потому что на них нет багов, а мы находимся на этапе «багфикса». Компонентное тестирование позволяет добрую половину из них находить сразу. А значит — багфиксить, когда удобно, и оценивать реалистично свои планы.
3. Infosharing.
То есть, деление информацией. По максимуму. Если кто-то где-то когда-то сказал, что эффективнее тестировать софт, не зная, как он устроен — вас обманули. Тестировщики НЕ знают, что влияет на выполнение той или иной операции. Опции UI? Без проблем. Но обычно, помимо них, есть ещё масса факторов, которые знают только разработчики.
Что делать?
ДЕЛИТЬСЯ И НЕ ЖАДНИЧАТЬ!
Спрятанный маленький дефект сегодня — риск большого геморроя завтра.
4. Выработать общий подход к дефектам.
Конечно, если разработчик не хочет сегодня переключаться на какой-то там багфикс, то он сделает всё, чтобы баги спрятать. Звучит старомодно, сейчас так не делают? Неправда, делают. Это естественный процесс :)
Зато, если разработчики знают, что баги в BTS (bug tracking system) — это лишь информация, но далеко не всегда сигнал к действию, то и расстраивать их наличие не будет.
При этом, для тестирования иногда фикс некоторых багов очень важен. Их принято называть Blocker'ами (это дефекты, которые могут быть и не очень критичными с точки зрения пользователя, но препятстсвуют тестированию какой-то существенной части функционала). Вот их правда фиксить надо, важно, и желательно быстро.
5. Не мерять результат попугаями.
Иногда руководство проекта хвалит тестеров, которые нашли критикал за пару часов до релиза. Много багов? Молодцы. Разработчиков руководство тоже зачастую пытается померять, к примеру, KLOC'ами. Но ни количество кода, ни количество багов не приближают нас к релизу, иногда — наоборот! Что действительно является показателем эффективности совместной работы?
Только релиз. Своевременный и качественный.
А это значит, что дефекты, строки кода, средняя критичность и прочая лабуда — это формализм, который помогает руководству чувствовать себя у руля, глядя на графики.
p.s. В одной компании, где я работала, в один прекрасный день ввели оценку разработчиков по количеству написанных строк кода. В следующем месяце суммарно было почти в два раза больше закоммиченного кода. Только представьте себе его качество :)
Формализм концентрирует внимание на циферках и удаляет от результата.
6. Обеспечение testability продукта.
Нам (мы = весь проект, а не только тестеры!) очень важно иметь возможность оперативно тестировать наш софт. А для этого иногда приходится постараться. Фиксить блокеры? Создавать дополнительные интерфейсы для тестирования? Обещать стабилизацию интерфейсов и всячески выполнять своё обещание?
Это важно! Очень…
Выводы
В эффективном тестировании заинтересованы все участники проекта. Оно позволяет экономить затраты на разработку и багфикс, нивелировать проектные риски, повышать качество продукта, избавлять разработчиков от лишних задач… Вообще, если на проекте правильное тестирование, то суммарное количество найденных дефектов обычно только ниже!
НО!
Тестировщики далеко не всегда могут обеспечить это самое «правильное» тестирование без помощи, поддержки и понимания со стороны разработчиков и РМ'ов.
Чтобы это происходило, нам надо больше общаться. Узнавать, кто какие результаты ждёт от тестирования, какие цели ставит. Кому что нужно для помощи, кому что не нравится в текущем процессе.
Открыто обсудив такие вопросы, мы можем сделать тестирование и проект в целом значительно эффективнее, и главное препятствие на этом пути — не заказчики, не инструменты, не технологии, а всего лишь непонимание.
