Первая статья, как вступление:
Критичные процессы в тестировании программного обеспечения (ПО)
Рэкс Блэк: Президент и главный консультант компании
RBCS, Inc., Bulverde, TX
Ключевые слова (теги): Тестирование ПО, критичный процесс тестирования,
управление тестированием, проекты разработки ПО,
проекты сопровождения и поддержки ПО,
автоматизация тестирования, ручное тестирование.
Аудитория: Руководители тестировщиков, ведущие тестировщики, менеджеры проектов,
тестировщики, руководители разработчиков, менеджеры конфигураций.
Перевод с английского: Андрей Пунин (anairguru@gmail.com).
Оригинал: http://www.rbcs-us.com/software-testing-resources/library/basic-library
Введение
Как профессионалу в области тестирования с почти двадцатилетним опытом в области компьютерных технологий, мне приятно видеть новую статью, посвященную нашей области, в журнале “Journal of Software Testing Professionals”, и я имею честь внести свой вклад, как редактор. Первой задачей в этой роли мне было предложено написать самому , а также сотрудничать с другими специалистами в области тестирования, чтобы получить цикл статей, отвечающих на вопрос: “Что мы подразумеваем под критичными процессами в тестировании, которыми профессионалы в этой области должны владеть и управлять, чтобы добиться успеха?”. В каждой из этих статей мы будем подробно рассматривать один такой критичный процесс, предлагать практические советы: что уже работает и предостерегать от того, что может создать проблемы.
Содержание цикла
Давайте начнем с определения: что такое этот цикл статей, и чем он не является?,- рассмотрим понятие “критичные процессы тестирования”. Процесс- это набор задач и активностей (действий для решения этих задач), некоторые из которых могут происходить одновременно, а некоторые- последовательно, друг за другом. Задачи и активности связаны желаемыми результатами, но в то же время не обязательно связаны с необходимыми техниками и требуемыми знаниями и навыками. Например, процесс автоматизации тестирования включает оценку объема работ, оценку и выбор инструментов и автоматизацию самих тест кейсов (написание скриптов). Одна их предстоящих статей будет посвящена этому процессу. Конкретные активности, посвященные автоматизации, думаю, оставим для других статей в этом журнале.
Как я уже упоминал выше, критичный процесс- это процесс, которым вы, как профессионал в области тестирования, должны владеть для достижения успеха. Процесс становится критичным когда:
Вы часто повторяете этот процесс. Определенная, формализованная обработка повторяющихся процессов приводит к последовательному и эффективному выполнению ваших повседневных обязанностей. Например, процесс записи дефекта в баг трекинговую систему происходит постоянно, во время выполнения тестирования.
В процесс вовлечены коллеги или кто-либо из руководства организации. Успешная работа над хорошо видимым коллегам или руководству процессом, создает репутацию компетентного, надежного сотрудника, которому можно доверить ответственное дело. На примере процесса автоматизации тестирования мы должны предоставить оценку объема работ, которая убедит руководство потратить тысячи доллларов на инструменты автоматизации тестирования, вместо выделения сотен человеко-часов на эти же объемы работ при ручном тестировании.
Последствия невыполнения процесса неприемлимы. Успешный профессионал в области тестирования является экспертом в управлении рисками качества. Например, для определения потенциальных неудач проекта, кто-то должен анализировать риски качества, которые могут оказывать критическое влияние на реакцию заказчика, и корректировать надлежащим образом процессы тестирования.
В заключении, чтобы получить этот цикл практичным и содержательным, я выделю процессы, которые большинство профессионалов, определит как часть их текущей работы. Специализированные темы, разумеется, найдут свое место в журнале, но мы будем сохранять эти темы и статьи в центре общих интересов.
Я также буду использовать этот критерий при определении, какие из критичных процессов относятся к области тестирования ПО и поэтому находятся в рамках содержания этого цикла. Прежде чем дискутировать об определениях “процесса тестирования ПО”, давайте согласимся, что некоторые критичные процессы, которые “противостоят” многим из наших коллег, занятых тестированием, обязаны быть, в некотором смысле, критичными для процесса тестирования. Тем не менее давайте исключим процессы, общие для всех профессионалов, участвующих в разработке ПО. Под этим определением я буду включать статьи об измерении покрытия кода тестами и об управлении передачей релизов в тестирование, но я буду исключать описание поддержания хороших взаимоотношений с вашим менеджером или равномерного применения корпоративных персональных политик. Хорошая мысль- вероятно критичный процесс для тест менеджера не является критичным процессом для всего процесса тестирования ПО.
Типы и зависимости критичных процессов
Я классифицирую процессы тестирования ПО как внутренние (в которые вовлечены люди только из команды тестирования) и совместные (в которые вовлечена еще одна или более команд). Я использую слово “совместные” вместо ”внешние” потому, что команды в эффективных компаниях принимают чужую работу, как позитивное “руки прочь”. Они не подбрасывают незавершенные или некачественные результаты работы через “организационные стены”. Совместные процессы могут заключать в себе принятие результатов работы от другой команды, предоставить результаты своей работы другой команде или и то и другое. Совместные процессы могут повлечь за собой последовательность работ, соединяющую множество команд.
Например (см. Рисунок 1), на котором изображено упрощенное количество процессов (стрелок) и команд (окружностей), вовлеченных в процесс разработки ПО. На этой иллюстрации выполняемые тесты- внутренний процесс, так же как и запись их результатов. Предоставление отчетов об ошибках- совместный процесс, при котором осуществляется доставка данных команде разработки от команды тестирования посредством выполнения процесса тестирования (выполнения тестов). Предоставление результатов о ходе тестирования (статусе процесса)- совместный процесс, в ходе которого тест менеджер сообщает команде менеджмента о ходе тестирования и оцененное с помощью чартов и метрик, понятных для команды менеджмента, качество продукта на текущий момент. В конце, выделим многостадийный совместный процесс, предоставления ПО команде тестирования, который я разбил ниже на несколько совместных подпроцессов, показанных круглыми скобками (стрелками) (имеется ввиду нижняя ветвь- Прим. перевод).
Так как организация тестирования представляет собой организацию, где сходится множество результатов и где достигнута независимость оценки качества, я предполагаю, что совместные процессы наиболее критичны с точки зрения организации.
Также необходимо отметить, что множества независимых процессов, влияют друг на друга. Например, качество результатов процесса сообщения об ошибках влияет на качество результатов всего процесса тестирования, предоставляемых для менеджмента. Качество таких отчетов, в том смысле, что они добавляют свою погрешность в организации и формируют восприятие тестирования, как хорошего вложения средств, влияет на способность тест менеджера в будущем обосновывать запрошенные для выполнения работ ресурсы. Эти ресурсы- необходимые условия для работ по обеспечению качества при выполнения тестирования, включая отчеты об ошибках. На данном рисунке процесс включает все пять команд и показывает, как результаты тестирования определенного релиза могут влиять на внутреннее содержание последующих релизов. Возникает большое количество таких отчетов-петель, и мы посмотрим, как ими управлять.
Рисунок 1.
Выбор критического процесса
Разрешите мне предположить несколько критических процессов, в качестве анонса следующих статей, которые будут содержать несколько следущих ежеквартальных изданий журнала.
Планирование и оценка объемов работ по тестированию. Планирование объема работ- это не то же самое, что и написание тест кейсов. Тестирование включает много логистических и организационных факторов, о которых тест менеджер должен подумать до того, как тест кейсы будут написаны. Планирование также включает сбор фактов от многих участников и оценку поддержки коллегами и руководством вашего плана. Мы посмотрим на различные процессы и стандарты, которые существуют для планирования тестирования и которые помогут подобрать правильные для вашей организации.
Риски оценок и риски управления качеством. Тестирование- это прежде всего задача управления рисками, но иногда мы не понимаем критичных рисков качества, пока не начнем тестировать. В будущей статье мы поговорим о путях выстраивания наших систем тестирования совместно с заказчиками, пользователями, и другими заинтересованными сторонами, чтобы быть уверенными, что мы тратим наши ресурсы на правильное тестирование.
Тестирование релизов сопровождения ПО. В то время, когда тестирование разработки получает больше всего обратной связи, процесс тестирования релизов сопровождения позоционируется как процесс с набором труднореализуемых, но быстрых изменений. Срочный патч для критического бага требует больше различных методов, подходов тестирования, чем регулярный релиз по расписанию. Поэтому гибкие процессы обязательны. Мы представим наборы методов, включая дискуссии о сильных и слабых сторонах каждого их методов.
Измерение и увеличение тестового покрытия. Как мы можем оценить контрольный показатель по достижении которого, можно будет судить о достаточном покрытии кода тестами? Мы обычно измеряем покрытие в строках кода, при помощи спецификаций, требований, но существуют другие показатели. Статья будет содержать опрос сообщества профессионалов в тестировании об их техниках.
Распределение объема тестирования. С появлением аутсорсинга, офф-шор вендоров и многофункциональных ИТ практик, как частей разработки ПО (больших и маленьких), какая-либо организация имеет возможности увеличивать тестовые возможности своих партнеров и свои собственные. Также тестовые лаборатории, контракторы и консультанты предоставляют ресурсы для заполнения недостающих ваших собственных ресурсов. Статья будет содержать материалы о том, как координировать различные группы тестировщиков, вовлеченных в процесс и определенных для достижения результатов каждым из них, а также коммуникации и обмен информацией между ними.
Динамическое распределение приоритетов в тестировании. Большинство тестировщиков соглашаются, что они не могут выполнить все их тесты за отведенное время. Иногда слишком мало времени отведено на разработку тестов, приводящее к необходимости прокрытия многочисленных тестовых условий малым количеством тест кейсов. Давайте посмотрим на пути разработки эффективных тест кейсов и приоритезируем эти пути для достижения высокоуровневого риск менеджмента независимо от сроков.
Распределение ролей в команде тестировщиков, этапы их привлечения в тот или иной процесс в мастштабах всей организации. Процесс тестирования не должен напоминать собой “детский футбол”: когда множество людей бегает за мячем на большом поле и пытаются ударить по мячу. Благодаря использованию этапов (стадий) тестирования каждая команда занимает правильную позицию в тестировании продукта. Достигнув уверенности, что команда остается на правильных этапах (стадиях) тестирования (и только тестирования), заботливый тест менеджер сохранит свою команду эффективной. Статья будет содержать обсуждения фокусирования на нужных объемах работ тестирования, включая сложные межведомственные отношения и менеджерские рассуждения о том, как тест менеджер должен организовать остальных для выполнения определенных видов тестирования.
Сбор требований и спецификаций. Вы когда-нибудь замечали, что тестируйте приложение при существенном или полном отсутствии информации о том, как приложение должно себя вести при различных условиях? Метод “научного тыка”, расспросы коллег, сравнение вашего приложения с конкурентными и прием во внимание пожеланий заказчика- это все части единого процесса решения таких проблем. Мы посмотрим и на другие пути решения этих проблем.
Развитие и поддержка тестовой системы. Статический набор тестов страдает от того, что доктор Борис Бейзер называет “парадоксом пестицида”: этот набор может стать менее эффективным, так как разработчики учаться избегать ошибок, которые находятся тестами (и, разумеется, исправляют существующие ошибки – Прим перевод.). Мы будем изучать процессы, которые постоянно улучшают наборы тестов, добаляют новые тесты, устраняют устаревшие тесты и апдейтят существующие тесты в соответствии с изменяемыми требованиями и условиями.
Построение тестового репозитория. Тестовые системы состоят из тестовых условий, тест кейсов, тестовых инструментов, наборов тестов и других объектов. В неоднородных условиях эти объекты распростроняются на различные Ос`и, языки программирования и даже на различные команды тестирования. Вы можете построить или купить систему, которая бы позволила вам управлять этими разрозненными частями? Давайте посмотрим на техники построения и использования таких самописных инструментов и на коммерческий софт для управления тестированием.
Управление релизами и конфигурациями в управлении тестированием. Тестируемый софт не должен просто появляться магическим образом в тестовом окружении, так же как и тестовые среды не должны магическим образом конфигурировать себя вокруг доставленного кода. Плавное течение софта от разработчиков к команде тестирования в лабораторию тестирования, с четким контролем результатов установок, требует тотального менеджмента и эффективных коммуникаций, часто в бытро меняющихся условиях. Будущая статья рассмотрит ключевые моменты в этих областях вместе с примерами менеджмента релизов и конфигураций, сделанных корректно и наоборот- недостаточно верно.
Как я упоминал выше, вы можете не иметь ответственности за все эти процессы, но эти процессы имеют прямое влияние на успех вашей организации. Эти кросс-функциональные процессы имеют такое же влияние на менеджмент, как техническая подкованность и поэтому я рассматриваю их с особым интересом. Также у меня есть специально отобранные неприметные и невзрачные процессы для примеров. Потому что скучный - не значит не имеющий значения. Вы можете не получить апплодисментов от вашего менеджера, что релизы по плану поступают в тестовые лаборатории, но отсутствие управления таким процессом должно заострить внимание на направильном подходе к процессу.
Обращение к участникам:
Авторы этой серии статей, включая и меня, будут базировать свои эссе на реальных случаях, на опыте реальных проектов, а также на опросах сообщества профессионалов в области тестирования. Эта серия статей будет использовать коллективный опыт группы людей, работавших над сотнями проектов. Каждый проект учит чему-то профессионала в управлении критичными процессами. Более того, у некоторых из них имеются анекдотические случаи, а также множество данных, чтобы поделиться ими. Благодаря “руководящему” подходу каждая статья будет предоставлять набор действий, который вы можете применить, чтобы улучшить ваши процессы тестирования.
Как и у ваших коллег- профессионалов в тестировании, у вас также может быть ваш собственный набор методов и идей. Как читатель этого журнала вы можете судить о том, какой же процесс является критичным. Следуя руководствам и правилам журнала вы можете публиковать свои аннотации к статьям. Если вы “боретесь” с критичными процессами и хотите учиться у своих коллег- дайте мне знать. Я за всестороннее общение с читателями. Мой e-mail написан ниже.
Эта серия статей о том, как мы, как профессионалы в тестировании, можем быть успешными в наших наиболее важных ролях. Я призываю каждого к участию в дискуссиях, особенно если вы хотели бы поделиться мыслями, решениями и предупреждениями о критичных процессах.
Об авторе:
Рэкс Блэк (Rex_Black@RexBlackConsulting.com) – президент и главный консультант компании “Rex Black Consulting Services Inc.” (http://www.RexBlackConsulting.com) – международной консультационной компании в областях тестирования и обеспечения качества. Он и его компания предоставляет помощь их клиентам в применении, передаче знаний, а также наборе персонала для работы над процессами тестирования и обеспечения качества. Его книга “Управление процессами тестирования” была публикована в июне 1999 года издательством “Microsoft Press”.
Сообщения
Комментариев нет:
Отправить комментарий