Андрей Кузнецов: «Подводные камни» в процессах обеспечения качества ПО

Целью доклада является акцентирование внимания на некоторых нюансах в управлении процессами обеспечения качества, которые помогут избежать многих проблем :

  1. Учёт бизнес-целей разрабатываемого продукта
  2. Переработка готового продукта без спецификации
  3. Обеспечение качества при резком уменьшении ресурсов
  4. Особенности анализа статистики
  5. Доклад основывается на личном практическом опыте, а также опыте коллег по QA.

Идея доклада родилась давно, когда накопилось некоторое количесвто стандартных и не очень ситуаций, разрешение которых на тот момент не казались очевидными. Ясность пришла с опытом и теперь удалось часть из них подвести под единую тему, так как каждый случай в отдельности, является лишь маленьким частным примером процесса обеспечения качества.

Любое управление процессами – это планирование с последующим аудитом исполнения этого плана, и соответствующими корректировками. Сложности возникают тогда, когда во время исполнения, возникают проблемы, которые серьёзно идут вразрез с этим планом, в результате чего, приходится чем то жертвовать (зачастую именно качеством). Есть масса нюансов, которые несомненно описаны с теоретической литературе, однако в России, стране, где современные методы обспечения качества ПО, внедрены относительно недавно, зачастую этим нюансам не уделяют должного внимания. Маленькое отступление: говоря «недавно», хочу сказать, что наши кадровые агенства, которые занимаются поиском инженеров по качеству для иностранных компаний, пытаются убедить их снизить требованию по опыту «в годах». (Если в западной Европе, при поиске Senior Software QA Engineer нормой является 7-10 лет, но у нас это конвертируется в 4-5) Не стану говорить о банальных вещах, о том, какие конекретно процессы задействованы в обеспечении качества, а перейду сразу к сути тех самых нюансов и, связанных с ними проблем.

Учёт бизнес-целей разрабатываемого продукта

Какой главный критерий качества разрабатываемого продукта? На эту тему сломано много копий и написано множество текста. Лично моё мнение, что главный критерий того, что продукт получился качественным – это то, что заказчик остался им доволен. А доволен он может быть только тогда, когда достигнуты его бизнес-цели. Парадоксально то, что очень часто (а возможно что и в большинстве случаев) бизнес-цели остаются вне поля зрения команды разработчиков. Либо потому что они в принципе не открываются заказчиком, по принципу – «меньше знаешь, лучше спишь» (я работал на таком), либо потому что считается, что бизнес-целями занимаются аналитики на стороне заказчика, а нам это ни к чему. Команда сосредотачиваетсчя на конкретном ТЗ – формах с кнопочками и логикой, не зная толком для чего это нужно заказчику и, как вы наверно знаете, вполне успешно и вовремя сдаёт такие проекты. Однако есть нюанс. Порой из-за незнания бизнес-целей команда попадает в просак там, где этого, казалось бы, никак не могло случиться.

Пара примеров:

  1. Сторона заказчика в отпуске, команда бьётся над критическим багом (не работает целый блок приложения). Тратит на это неделю, и 50% ресурсов. После чего выясняется, что баг конечно критический, но так как затрагиваемый им функционал, не важен с точки зрения бизнес-целей, то его можно было просто отключить, и заняться другими вещами.
  2. Обратная история, когда при планировании, как кажется, банальная задача задвигается в самый низ списка, а потом выясняется, что без неё весь проект не имеет смысла. Итог – сдвиг сроков очередного релиза.

Резюмирую: бизнес-цели, поставленные заказчиком, очень желательно знать. По крайней мере, это должно быть в голове QA группы. Отдельно хочу отметить – нужно добиться, чтобы эти цели проговорил именно заказчик, ибо порой даже его интонация имеет значение, чтобы понять – что ему действительно важно, а что не очень.

Переработка готового продукт а без спецификации

Есть готовый продукт, и довольно весомый по фунционалу, и стоит задача перевести его на новую платформу, или добавить некие изменения. К нему есть спецификация, которой 10 лет, она написана на китайском и с миллионом исправлений. Как получить новый качественный продукт на выходе? Да, мы получили общие представления во время планирования, но для обеспечения качества нужны детали. Тут важно соблюсти компромис между сроками и качеством, и обязательно, согласовать это с заказчиком. Мы можем договориться о том, что критерием качества будет то, что новые приложение будет работать точно так же как и старое. Собественно так обычно и делают, но тут может возникнуть свой «подводный камень» – старое приложение в неторых местах уже работает НЕПРАВИЛЬНО. Базы старых багов может не быть, либо конкретно этот уже не был записан, по разным причинам. Опять же – компромисс. Но этот компромисс, должен быть зафиксирован документально, чтобы потом не было претензий, что новое приложение работает с ошибками. В случае откзаза заказчика, подписывать такую договорённость, нужно начать планировать полное исследование старого продукта, вместе с бизнес-аналитиками и, если это возможно, тестировщиками с той стороны. Как правило, после оценки такого исследования, заказчик на компромисс соглашается. Хочется также отметить, из личного опыта, что при использовании методики сранения (старый – новый продукт), хорошей практикой является частая смена области проверки для тестироващиков внутри команды, это помогает избежать эффекта «замыленного глаза», т.к., в большинстве случаев, 99% функционала действительно работает одинаково.

Обеспечение качества при резком уменьшении ресурсов

Произошёл форс-мажор, не важно почему, факт что он случился и команда тестировщиков уменьшилась в 2 раза, при том же объёме работ. Достаточно много опять же написано о подобных ситуациях и способах их резрешения. Однако форс-мажор на то и мажор, что написать легко – сделать трудно. В такой ситуации достаточно логичным кажется срочное перераспределение оставшихся ресурсов на самых важных направлениях – т.н. main-функционале. И это разумеется првильно, «подводный камень» тут кроется в слове «срочное». Хорошо есть оставшиеся тестировщики уже и так работают на этом направдении, а если нет? В случае когда это случается в середине итерации, есть соблазн всё таки как то довести её до конца, а уже потом, в рамках стандартной процедуры спланировать уже новую итерацию, с учётом ресурсных изменений. Возможно что в ряде случаев всё так и пройдёт гладко, однако, в такой ситации гораздо менее рисковано, как можно скорее завершить текущую итерацию и начинать планировать заново. Был случай на практике, когда решили идти по первому пусти, мотивирую это тем, что в противном случае мы потерям 2 дня разработки на новое планирование – итогом была потеря как минимум недели. Кстати это очень хорошо было видно по собранным метрикам, о которых мы сейчас поговрим отдельно.

Особенности анализа статистики

При управлении процессами обеспечения качества, очень важна обратная связь – понимание, что всё идёт так, а не иначе, в соотвествии с планом или нет. На основе анализа происходят корректировки, оценка эффективности команды, в том чиле и QA-группы. В большинстве случаев, пректная статистика, в которой в первую очередь отражено качетво продукти на текущий момент, анализируется на более высоком уровне, нежели группа разработки. Руководство компании таким образом анализирует состояние проекта, не вдаваясь в технические подробности и вот тут порой возникают нюансы, о которых хочется поговорить.

Так, думаю, многим известно, при анализе собранной статистики в первую очередь смотрят не на количественные характеристики, а на динамику – ползёт график вверх или вниз и как долго. Так вот, именно такой динамический анализ порой может натолкнуть инспектора, не вовлечённого непосредственно в процесс, на некоторые неверные выводы, если оценка динамики даётся в рамках «хорошо или плохо поработали». Касается это процентных метрик. Допустим мы считаем процент пройденных тест-кейсов от всех существующих. Проект стартовал с нуля и количество тест-кейсов увеличивается от итерации к итерации. Соответственно на первой мы может увидеть 100%-ое покрытие (все 10 кейсов проверяны!), на 5ой – 50%, а на последней 10%-ое (ибо кейсов стало уже 10000). График может идти постоянно вниз, при том, что работу тестировщики выполняют в одинаковых объёмах на всех итерациях, за исключением возможно самых первых. «Всё хуже и хуже работает QA отдел – надо что то делать…». Понятно что в такой ситуации нужно просто объяснить эту ситуацию, жоговорившись о приемлимом проценте покрытия в течении одной итерации, но иногда, как уже упоминалось, статистика анализируется за пределами команды и принимаются соответствующие решения. Это лишь один простой пример, неправильного анализа, но приведён он с целью донести мысль о том, что должно быть однозначное понимание у всех групп, участвующих в анализе. Возможно нужно разграничение – статистика видимая лидеру QA, и статистика видимая например заказчику – это разные вещи. Это не значит что нужно мухлевать, подгоняя цифры или что то утаивая – этого как раз не должно быть ни в коему случае, это значит что мы распределям наши знания максимально удобным для всех сторон образом, чтобы каждый мог получить тут информацию, которую он может однозначно понять.

Тут можно возразить – методы оценки у всех могут быть разные, поэтому нужно предоставлять всю имеющуюся информацию, всем сторонам. На это могу сказать, что целью любого проекта является создание качественного продукта (т.е. как сказано выше, продукта, которым доволен заказчик), а не сбор статистики. Статистика нам помогает – но не пишет программы.

Заключение – ради чего всё это писалось

Я специально не упоминал в докладе о существующих спецификациях типа IEEE, SMMI или ИСО – во-первых потому что для доклада это скучно, а мы тут не скучать собрались, а во-вторых потому, что подобные спецификации говорят о том «как?», оставляя за кадром «почему?». За свою 6и летнюю практику я посетил массу различных тренингов по управлению качеством, но те моменты о которых я попытался здесь рассказать, не были на них озвучены ни разу. Возможно потому, что кто то считает эти моменты само-собой разумеющимися, но мне это таковым не кажется. Надеюсь кому то эти знания помогут избежать трудностей в работе.

Источник: testitquickly.com