Цитата недели




Подвиг это всегда результат чьей то некомпетентности или безответственности

Шпаргалки для боссов. Тимур Горяев




вторник, 29 декабря 2009 г.

Идеальная автоматизированная система управления качеством программных продуктов



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

Примерно так прозвучал вопрос, когда я проходил собеседование на свою текущую работу. Этот вопрос мне показался очень и очень интересным. И очень и очень недостижим - когда я думаю об этой системе сейчас.

Думая об автоматизации процесса обеспечения качества, я все чаще размышляю о том же, о чем думал уже почти три года назад, когда работал в группе, которую можно было бы назвать отделом АСУ, если бы нас не было всего два человека. Мы пытались централизовано управлять автоматизацией, в то время как каждое подразделение предприятия считало своим долгом делать это самостоятельно.

Когда я только пришел на работу, централизованно можно было только собрать совещание. Когда я уходил, проектировщики могли выгружать из своей системы данные технологам в их систему. Наши экономисты уже автоматически формировали отчетность, в том формате которую требовали бухгалтеры и финансисты. Централизовано работала электронная почта с одним доменом и службой Active Directory. Централизованно же мы закупали ПО и лицензии. Пытались влиять, опять же централизованно, на закупку/распределение компьютеров. На внутреннем веб-сайте с использованием IIS+IE+Active Directory   работала система одного окна для поисковых систем по архиву, внутренним базам данных. Было чем гордиться. Почти  пять лет я потратил на автоматизацию и объединение разрознненых систем и процессов.

И вот то же самое начало я вижу и сейчас (про то же самое я, кстати, читал и в How We Test At Microsoft): отсутствие централизации в процессе обеспечения качества, и самое главное - отсутствие единого продукта для автоматизации работы специалистов  по обеспечению  качества (и тестировщиков).

Что же мы имеем:

Excel - незаменим при построении тестовых roadmap-ов, собственно тестов и даже для создания документов.

Word - тоже полезен для создания документов. Отчеты, спецификации,... (если бы не корпоративные политики давно бы использовал только Open Office Write и Calc, кстати говоря).

Jira - наше все: баг трекинг, трекинг фич, планирование релизов, оценка времени и регистрация информации по проектам, накопление статистики, формирование репортов. Наверное Jira можно использовать и как систему хранения документации (версии, история), но это, как мне кажется, тяжелое решение.

MS Project - диаграмму Гантта никто не отменял.

HP Quality Center - хранить тесты, планировать регрессионные тесты...ну хоть что то же нужно автоматизированно готовить - хотя бы регрессионные тесты.

Confluence/TWiki/Sharepoint/ - коллективный разум должен хоть что-то после себя оставлять в виде файлов, ссылок, статей и картинок.

Тузлы для автоматизации, программирования, статического анализа, хранения кода... Это уже детали.

А как же все это связано? Специалистами. Вся эта кирпичная крошка густо замешана на опыте, знаниях, воспоминаниях специалистов.  Плюс еще конечно техзадания, спеки, тест планы. Но сколько храниться в головах специалистов...А сколько еще предстоит узнать...

А что бы я хотел иметь?

Я бы хотел иметь систему. Одну. Чтобы я мог сам построить workflow.  Чтобы я видел версию документа не в SharePoint, а мне приходило оповещение, поскольку я в роли тестировщика указан в данном проекте.

Хочу полноценную систему документооборота с архивом.

Хочу систему управления требованиями в том же виде, что и в Word или Wiki, но если я помечаю абзац как требование - это требование начинает жить своей жизнью: с версионностью, историей изменений, приоритетами и подтверждениями.

Хочу чтобы эти требования без циничного копи-паста оставляли свой след в системе разработки тестовых сценариев. Т.е. хочу чтобы существовала система для создания тестовых сценариев. Похожая на Excel таблицы, но каждый тестовый сценарий мог бы существовать своей, особой жизнью и также - с историей, версионностью и обратной связью к требованиям. Как это прекрасно получать traceability matrix автоматически... 

 А представьте, как прекрасно выглядят деревья тестовых сценариев с различными тегами (или категориями, или ярлыками).

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

А если вам нужно узнать среднее время для прохождения помеченных вами или выбранных системой автоматически тестовых сценариев '=sum(...' уходит в прошлое. Ведь для этого есть специальная колонка!

Не хочу проходить мимо генерации регрессионных тестов. У нас же будет система баг трекинга! Она сейчас есть у всех, но эта система будет знать все о требованиях и тестовых сценариях не от человека, а от своих ближайших соседей по цеху - тех, что мы с вами уже обсудили. И эта система баг трекига сама расскажет какое требование было нарушено. Только укажите теги и ярлыки. Или покажет какой тестовый сценарий признан удачным (ведь тестовый сценарий удачен, если найден баг). А еще она анализирует ключевые слова описания бага и строит семантическую сеть, и даже готова предсказать, в каком месте (в какой фиче), предположительно ожидать новые баги. Ведь система все помнит и история учит - все идет по кругу: если ты обнаружил багу здесь и здесь, попробуй вот этот сценарий - он вкусный!

О да, моя система могла бы многое. Если бы вы спрашивали о фиче1, вам бы предлагали фичи, который рассматривались с этой фичей раньше (фича66, фича121).

Моя бы система на вопрос о environment ошибке предлагала бы контакты суппортеров и workaround. Более того, она сама бы рассылала сообщения суппортерам. Ты звонишь по контакту, а он, какое чудо, занимается твоей проблемой уже почти три минуты.

Моя система позволяла бы расчитать время на разработку фичи. Предлагала бы несколько шаблонов расчетов, не забывая тактично спросить - есть ли у меня особое мнение о поправочном коэффициенте или, быть может, я тупо хочу сам вбить (например 366 человеко дней) свою оценку.

Моя бы система умела считывать данные из системы версионного контроля и присылать свое мнение, почему данная фича должна быть протестирована в первую очередь.

Моя система сама рассылала бы QA Daily Report и табель.

Моя система сама бы расчитывала показатели: сколько багов найдено и пофикшено, сколько багов пофикшено в текущем релизе, сколько багов на душу населения команды мы прос...ли и получили outages от бизнеса.

Моя система была бы идеальна...

Именно поэтому бы ее никто и не смог использовать.

Каюсь, для меня идеальный процесс - это горизонт. К нему нужно стремиться, но дойти не удаться. Можно в любом, сколь  угодно, идеальном процессе найти сбой и бутылочное горлышко. Любой процесс живет и нужно чутко реагировать, менять "серебрянные пули", подходы и, к сожалению, в некоторых случаях людей. Поэтому идеальная система для построения идеальных процессов - это зло. Лучшее - враг всего хорошего. Хотя, чувствую, здесь я могу и ошибиться.

Далее. Представьте, сколько времени понадобиться на ее поддержку. Это не один модуль. Это практически модуль для каждого этапа в жизненном цикле продукта. Системные администраторы, технические писатели, даже тестировщики и программисты должны будут вносить свою постоянную лепту в базу знаний данной системы. А сколько понадобиться серверов для нее? А сколько лицензий. Идеальные системы стоят дорого...

И все таки, если уж понеслась такая ярмарка...

Моя система управления процессом обеспечения качества была бы OpenSource.

Моя система была бы модульной и позволяла бы внедрять себя поэтапно. Строилась как конструктор.

Моя система могла бы расширяться пользователями и иметь свой собственный язык программирования, либо позволяла дописывать себя на любом языке, либо встраивать плангины. Либо позволяла делать и то и другое и третье.

И наконец, моя автоматизированная система управления качеством программных продуктов   (АСУ КПП) ровно в шесть часов и одну минуту вечера включала бы тригер и вежливым сообщением посылала меня домой к семье, а сама засыпала бы до восьми утра.

Комментариев нет:

Отправить комментарий