Если бы вы могли получить то, что хотите, какую бы идеальную систему для управления процессом обеспечения качества, вы бы пожелали?
Примерно так прозвучал вопрос, когда я проходил собеседование на свою текущую работу. Этот вопрос мне показался очень и очень интересным. И очень и очень недостижим - когда я думаю об этой системе сейчас.
Думая об автоматизации процесса обеспечения качества, я все чаще размышляю о том же, о чем думал уже почти три года назад, когда работал в группе, которую можно было бы назвать отделом АСУ, если бы нас не было всего два человека. Мы пытались централизовано управлять автоматизацией, в то время как каждое подразделение предприятия считало своим долгом делать это самостоятельно.
Когда я только пришел на работу, централизованно можно было только собрать совещание. Когда я уходил, проектировщики могли выгружать из своей системы данные технологам в их систему. Наши экономисты уже автоматически формировали отчетность, в том формате которую требовали бухгалтеры и финансисты. Централизовано работала электронная почта с одним доменом и службой 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.
Моя система была бы модульной и позволяла бы внедрять себя поэтапно. Строилась как конструктор.
Моя система могла бы расширяться пользователями и иметь свой собственный язык программирования, либо позволяла дописывать себя на любом языке, либо встраивать плангины. Либо позволяла делать и то и другое и третье.
И наконец, моя автоматизированная система управления качеством программных продуктов (АСУ КПП) ровно в шесть часов и одну минуту вечера включала бы тригер и вежливым сообщением посылала меня домой к семье, а сама засыпала бы до восьми утра.
Хочу полноценную систему документооборота с архивом.
Хочу систему управления требованиями в том же виде, что и в Word или Wiki, но если я помечаю абзац как требование - это требование начинает жить своей жизнью: с версионностью, историей изменений, приоритетами и подтверждениями.
Хочу чтобы эти требования без циничного копи-паста оставляли свой след в системе разработки тестовых сценариев. Т.е. хочу чтобы существовала система для создания тестовых сценариев. Похожая на Excel таблицы, но каждый тестовый сценарий мог бы существовать своей, особой жизнью и также - с историей, версионностью и обратной связью к требованиям. Как это прекрасно получать traceability matrix автоматически...
А представьте, как прекрасно выглядят деревья тестовых сценариев с различными тегами (или категориями, или ярлыками).
А когда вы выбираете тестовый сценарий для редактирования - вы получаете Wiki систему с скриншотами и возможностью самореализации.
А если вам нужно узнать среднее время для прохождения помеченных вами или выбранных системой автоматически тестовых сценариев '=sum(...' уходит в прошлое. Ведь для этого есть специальная колонка!
Не хочу проходить мимо генерации регрессионных тестов. У нас же будет система баг трекинга! Она сейчас есть у всех, но эта система будет знать все о требованиях и тестовых сценариях не от человека, а от своих ближайших соседей по цеху - тех, что мы с вами уже обсудили. И эта система баг трекига сама расскажет какое требование было нарушено. Только укажите теги и ярлыки. Или покажет какой тестовый сценарий признан удачным (ведь тестовый сценарий удачен, если найден баг). А еще она анализирует ключевые слова описания бага и строит семантическую сеть, и даже готова предсказать, в каком месте (в какой фиче), предположительно ожидать новые баги. Ведь система все помнит и история учит - все идет по кругу: если ты обнаружил багу здесь и здесь, попробуй вот этот сценарий - он вкусный!
О да, моя система могла бы многое. Если бы вы спрашивали о фиче1, вам бы предлагали фичи, который рассматривались с этой фичей раньше (фича66, фича121).
Моя бы система на вопрос о environment ошибке предлагала бы контакты суппортеров и workaround. Более того, она сама бы рассылала сообщения суппортерам. Ты звонишь по контакту, а он, какое чудо, занимается твоей проблемой уже почти три минуты.
Моя система позволяла бы расчитать время на разработку фичи. Предлагала бы несколько шаблонов расчетов, не забывая тактично спросить - есть ли у меня особое мнение о поправочном коэффициенте или, быть может, я тупо хочу сам вбить (например 366 человеко дней) свою оценку.
Моя бы система умела считывать данные из системы версионного контроля и присылать свое мнение, почему данная фича должна быть протестирована в первую очередь.
Моя система сама рассылала бы QA Daily Report и табель.
Моя система сама бы расчитывала показатели: сколько багов найдено и пофикшено, сколько багов пофикшено в текущем релизе, сколько багов на душу населения команды мы прос...ли и получили outages от бизнеса.
Моя система была бы идеальна...
Именно поэтому бы ее никто и не смог использовать.
Каюсь, для меня идеальный процесс - это горизонт. К нему нужно стремиться, но дойти не удаться. Можно в любом, сколь угодно, идеальном процессе найти сбой и бутылочное горлышко. Любой процесс живет и нужно чутко реагировать, менять "серебрянные пули", подходы и, к сожалению, в некоторых случаях людей. Поэтому идеальная система для построения идеальных процессов - это зло. Лучшее - враг всего хорошего. Хотя, чувствую, здесь я могу и ошибиться.
Далее. Представьте, сколько времени понадобиться на ее поддержку. Это не один модуль. Это практически модуль для каждого этапа в жизненном цикле продукта. Системные администраторы, технические писатели, даже тестировщики и программисты должны будут вносить свою постоянную лепту в базу знаний данной системы. А сколько понадобиться серверов для нее? А сколько лицензий. Идеальные системы стоят дорого...
И все таки, если уж понеслась такая ярмарка...
Моя система управления процессом обеспечения качества была бы OpenSource.
Моя система была бы модульной и позволяла бы внедрять себя поэтапно. Строилась как конструктор.
Моя система могла бы расширяться пользователями и иметь свой собственный язык программирования, либо позволяла дописывать себя на любом языке, либо встраивать плангины. Либо позволяла делать и то и другое и третье.
И наконец, моя автоматизированная система управления качеством программных продуктов (АСУ КПП) ровно в шесть часов и одну минуту вечера включала бы тригер и вежливым сообщением посылала меня домой к семье, а сама засыпала бы до восьми утра.
