Работая на разных проектах компаний, на разных их стадиях я сталкивалась с проблемами, о которых и хочу рассказать. Надеюсь, кому-то это поможет увеличить эффективность работы, повысить качество, возможно, даже получить улучшение по цене продукта, за счёт выявления багов на более ранних стадиях.
Представим что у нас только-только начинается проект. На проекте есть только ПМ, который начинает оценивать сроки разработки. Здесь и начинаются первые проблемы…
Время на тестирование сильно ограничено
При оценке времени на проект ПМ (хотя нужна экспертная команда) даёт нереально маленький срок на тестирование, так как не владеет необходимыми знаниями в этой области. Например, при плане на 5 мес разработку, на тестирование после code freeze’a отводится 2 недели. Можете представить сколько багов может сделать команда из трёх разработчиков за 5 месяцев? =) А сколько итераций тестирования — багфикса потребуется чтобы получить стабильно работающую версию?
Предложение: включить в команду, оценивающую трудозатраты, QA-лида или группу ведущих тестировщиков, имеющих опыт тестирования схожих задач.
Тестирование проекта проводится в дополнительное время, выделенное на риски разработки
ПМ, рассчитывая трудозатраты, оставляет буфер времени в конце проекта, на непредвиденные ситуации и другие риски. Чтобы при оценке, сроки не показались клиенту слишком затянутыми, тестирование планируется проводить именно в этом буфере (возможна и другая мотивация). В итоге: программисты затягивают разработку, используют временной буфер, из-за чего время на тестирование сокращается.
Предложение: тестирование не риск! Нужно чтобы ПМ планировал качество и отражал это в содержании проекта, которое является частью контракта. Но это конечно надо всю «консерваторию» исправить.
Со следующей проблемой я столкнулась совсем недавно:
«Мёртвая лошадь»
После некоторого времени упорного труда (например, месяца 3), команда разработчиков выдаёт первые версии продукта, которые можно начинать тестировать. Уже есть UI c основными экранами и кнопками, но функциональность ещё не полностью реализована. Тестировщики пробуют систему — и тут на них сыплется немыслимое количество эксепшенов и багов, больших и маленьких, серьёзных и не очень. Что делать? По логике — прекращать тестирование и отдавать «продукт» разработчикам. Очевидно, что цепь разработчик добавил кнопку — разработчик проверил кнопку короче цепи, в которую включен тестироващик.
В реальности, тестировщики строчат по 20 багов в день, на разработчиках висит по 55 открытых багов — заняты все! =)
Предложение: ввести правило для разработчиков проводить «приёмочное» тестирование своей работы. Не нужно проводить сложные многоходовые тесты, но лозунг «да ладно, тестеры приберутся» предлагаю забыть.
Предположим, что наш проект уже прошёл стадию активной разработки и сейчас продукт уже более менее стабильный, новые версии отдаются клиенту для просмотра, или ещё хуже, для активного использования.
Тестирование выкидывается из итерации разработки
Собирается новый билд с «багфиксами» и change request’ами. Но так как разработчики столкнулись с непредвиденной проблемой и затянули выдачу релиза, а клиенту обещали обновления ещё вчера, билд отдаётся на тестирование и одновременно(!) ставится на production среду.
Предложение: не выкидывать тестирование из итерации разработки. Нужно планировать релизы.
«Замыливание глаза»
Тестировщики начинают пропускать баги по причинам, не связанным с ленью. Такое происходит по двум причинам:
1) На ранних стадиях разработчики ворчат по поводу «пустяковых» проблем, вроде: «Сейчас полно серьёзных багов, а вы ерунду постите». Тестировщики слушаются, и привыкают к таким багам так, что не видят их на более поздних стадиях.
Предложение: тестировщики, не слушайте вы их, пишите в багтрекер всё что найдёте. Только придётся ускориться, чтобы успеть всё запостить.
2) За короткий промежуток времени выдаётся несколько версий, более менее стабильного продукта. При необходимости каждый раз начинать smoke-тестирование заново, не успев закончить предыдущую итерацию, создаётся впечатление что весь функционал уже проверен, всё работает.
Предложение: делать «освежающие» паузы между итерациями, не собирать лишний раз билд из-за незначительных обновлений.
Причины проблем
Так или иначе, но все вышеперечисленные мной проблемы сводятся к тому, как менеджер проектов, да и вся фирма, относятся к контролю качества и планированию. Да, качество стоит времени и денег, а их всегда не хватает. Всегда хочется верить в лучшее, что “у нас и так пока все неплохо, зачем нам что то проверять?” или “один разочек можно и не проверять”. Чтож, верьте во что хотите, но тогда уж сами себе признайтесь в своих верованиях – напишите план управления качеством, одна страница, не более. В нем напишите, во что вы верите, какого уровня качества будете добиваться, какими средствами, за что отвечают разработчики, за что – тестировщики, как будете выпускать релизы. Такой честный документ упростит отношения внутри команды и снимет множество вопросов. Честность – первый шаг к успеху командной работы.
Recent Comments