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




Ваша репутация - это истории, которые о вас рассказывают

Мастер историй. Пол Смит




вторник, 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.

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

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

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

понедельник, 28 декабря 2009 г.

У каждого проекта должна быть своя модель процесса разработки.



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

Agile, XP, CMM...

Фреймворки, методы, методологии...

Стандарты, манифесты, спецификации...

Мне, человеку участвовавшему в конечном счете проектов, понятно стремление людей внедрять новое. Есть в этом стремлении что-то похожее на отношение рыбаков к тем, кто ловит на другом берегу. Так как известно клев лучше. Но согласитесь, тут кроется какая то засада - есть многое, что можно внедрить, есть успешные внедрения, но не понятно - почему у одних получается, у других нет. Внедряют, вроде бы, одно и то же. Или команды читают другие книжки?

У меня не было опыта внедрять что-то целиком. Собственно и полномочий таких тоже не было. Я можно сказал внедрял "серебряные пули" в отдельно взятом процессе, подконтрольному мне. Сначала в системное администрирование и поддержку. Потом в разработку. Теперь в тестирование и обеспечение качества.

Собственно весь жизненный опыт в ИТ вопит во мне: дело не в методологиях. Дело - в командах, где все это внедряется. Дело в людях. В зрелости людей. В их понимании конечных целей.


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

У каждого проекта должна быть своя модель процесса разработки.
У каждой модели - свое время.

Нужно дозреть. Проекту. Процессу. Команде. Специалисту...

Внедрять новое - это конечно замечательно.  Новое бодрит кровь, делает нас вновь молодыми ;). Но всему свое время.

В садике - игрушкам.

В зрелом возрасте маразму.

Надеюсь, вашему проекту это не грозит.

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

Если вы учите человека чему либо, он этому никогда не научиться.


Бернард Шоу был сто раз прав. Обучение чему либо, без практики это то, что сейчас губит высшее образование и знания вообще.

Первый месяц на новой работе я потратил на обучение. Мне думалось, что все изучу сам (были еще индийцы, но отсутствие активной разговорной практики английского, да плюс еще витиеватый восточный акцент... ну вы понимаете). Прочитаю и все-все пойму. Ведь документации много. А я читаю много и даже на английском. Не может быть, чтобы я прочитал и ничего не понял!

Прошел месяц. Документации оставалось все еще много. Ко мне подошел team lead Юра.
-Читаешь?
-Ага, изучаю - ответил я.
Юра кивнул головой.
- И когда закончишь.
Вот тут до меня, спустя месяц чтения, наконец стал доходить сокровенный смысл того, что я делаю. Я тупо читаю документацию. Я изучаю поведение графического интерфейса по бумажке. Мне вспомнились лекции, которые нам читали в университете. MS Word рисуемый на доске. Программный код программы распечатываемый на бумажке (100-200 страниц 10 шрифтом)...

Мудрые восточные люди (Интернет предлагает вариант, что это были китайцы) придумали: Я слушаю – и забываю, я вижу – и запоминаю, я делаю – и понимаю. 

Бернард Шоу остановился только на обучении. Мне кажеться он даже прав - в обучении ты можешь и слышать, и видеть, и делать...и даже ломать ;). Но именно практика делает из студента специалиста, а из специалиста профессионала.

Выношу цитату Шоу как недельную. Ибо уже вторник, но до конца недели еще есть время.

Если вы учите человека чему либо, он этому никогда не научиться.

Бернард Шоу

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

If you want to get a high quality product out of test...


Доброго дня суток.
Целый месяц прожил без Интернет. Это было мучительно, больно, скучно и тоскливо. Но я выстоял. А куда деваться если в новой снимаемой квартире его нет.
В итоге цитата недели висит уже месяц. Застоялась однако. Запашок.

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

Много времени мне кажется отводиться на препирательства. Придумывание оправданий и попыткой померятся пузом. Цитата прошлого месяца была: Все отвечают за качество. В продолжение цитирую Мелкософтных:

If you want to get a high quality product out of test, you have to put a high quality product into test

Во истину так, ибо каждый отвечает за качество своей работы.