рактика организации тестирования при хаотичной разработке приложений

П

Елена Цыганова В 2004 г. с отличием окончила Омский государственный университет путей сообщения по специальности «Информационные системы». С 2005 года занималась тестированием СПДС GraphiCS 3.0, MechaniCS 4.5 и 5.0, Genius MechaniCS 2006, TDMS 3.0 (всего более 10 проектов) в ООО «Магма-Компьютер» (ЗАО «СиСофт Омск), по сути, начиная тестирование в компании (в команде тестировщиков тогда было два человека). С конца 2005 года являюсь руководителем отдела тестирования этой компании.

Что такое хаотичная разработка?Нет:

Четких сроков сдачи продукта заказчику Требований заказчика Документированного плана разработки продукта Спецификаций Определенной методологии

Но есть:

Примерная оценка длительности проекта от опытных разработчиков

Недокументированные требования – в головах у членов команды и заказчика

Документированные, хотя и запутанные требования – ГОСТы по строительству и машиностроению

Итеративная разработка продукта, svn, база ошибок,..

О чем это выступлениеДумаю, есть много компаний, не придерживающихся

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

Компания «Магма-Компьютер» создана в 1994 году. В 1996 г. в ней появился отдел разработки ПО. В 1998 году был выпущен первый программный продукт – ShapeSearch. В 2007 году компания вошла в группу компаний CSoft, в связи с чем стала называться «СSoft Омск».

На сегодняшний день у компании следующие сферы деятельности: продажа и внедрение программного обеспечения для

САПР; разработка программного обеспечения; курсы по работе с программными продуктами Autodesk

и CSoft Development (НОУ ДПО "Магма"); внедрение системы управления проектами на базе

TDMS; разработка библиотек стандартных компонентов; техническая поддержка САПР.

Немного о компании,..

…о продуктах...

Пересекающийся функционал

Часть продуктов выходит в виде надстроек к другим платформам

Сборки одновременные, но не всегда и не ежедневно

…и о команде На данный момент штат компании составляет 40

человек, из них 29 активно участвуют в разработке программного обеспечения. Сегодня наша команда это:

18 разработчиков;5 тестировщиков;3 менеджера проекта;2 человека, которые пишут справку, руководства

пользователя и прочую документацию;1 системный администратор.

Из 18 разработчиков 10 работают в компании более 5 лет, многие из них – с момента появления отдела разработки. Команда самоорганизованная, профессиональная, между членами команды существуют доверительные отношения.

Как все начиналось Багтрекер для разработчиков Молчаливые сборки Отсутствие документирования в принципе Команда тестирования из одного человека Отсутствие взаимодействия в распределенных

командах

Результаты тестирования не учитываются ни командой, ни заказчиком

Выявление проблем.

Пути решения

Автоматизировать «нечего»

Нужны специалисты в предметной области

При желании можно найти хороших специалистов со сложным сочетанием навыков и знаний

Необходимость повышения уровня компьютерной грамотности

В дальнейшем – поиск «автоматизаторов»

Нет команды тестированияРешение: создать команду тестирования

знает работу БТИ

«машиностроитель»

начальник

«строитель» «аналитик»

Хорошее знание предметной области

Более охотное согласие руководства на прием сотрудника

Нет документированных требованийРешение:составлять «карандашные» требования на новый функционал;создать и регулярно обновлять в svn базу спецификаций;формат спекцификации – документ Word

Существующие инструменты довольно сложные Требования есть в головах у членов команды Большой объем «старого» функционала при недостатке

времени

Мы знаем «как сделано», но теряем «как надо было сделать» (что для старого функционала не очень актуально – он обкатан как пользователями, там и командой).

В Word удобно ставить пометки на полях.

«Привычный» редактор и отдельная ветка уже существующего хранилища – не требуют освоения новых систем и дополнительных расходов на покупку софта.

В svn есть механизм одновременной работы и версионность.

При желании можно дополнить информацию любыми видами документов – таблицами, ГОСТами в любом формате, электронными письмами.

Ветка svn, посвященная ТЗ и спецификациям

Пример ТЗ (менеджер чертежей)

«Карандашное» ТЗ

Фрагмент спецификации «в работе»

Требования обсуждаются без привлечения тестировщиковРешение:привлекать тестировщиков к обсуждению ТЗ фичи на старте;создавать и поддерживать спецификации совместно с тестировщиками

По итогам обсуждения ТЗ составляется спецификация, параллельно с кодированием фичи

ТЗ хранится, но, как правило, в дальнейшем не меняется Когда изменять спецификацию? - Об этом может сказать

рассылка изменений в сборке

Тестировщики в курсе изменений в функциональности.

Тестировщики участвуют в анализе функциональности.

Тестировщики не информируются об изменениях в функциональностиРешение:создавать в базе ошибок задания на тестирование;рассылка списков изменений, сформированных по комментариям разработчиков в svn

Разработчик, заливая код в хранилище, оставляет комментарий

Комментарии по изменениям, вошедшим в сборку, собираются и рассылаются в виде анонса

Тестировщики по этому анонсу составляют список задач на итерацию

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

Тестировщики в курсе изменений в функциональности.

Тестировщики получают дополнительную информацию о важности изменений и методах тестирования (чему и как уделить особое внимание).

Задание на тестирование (база ошибок)

Рассылка – анонс сборки

Нет цели тестирования в итерации. Невозможно отследить, что именно протестированоРешение:работа по чек-листу с приоритетами;цели тестирования в итерации – результат анализа списка изменений и чек-листа

Вместо тест-плана – приоритезированный чек-лист. Отказ от «тяжелых», трудно поддерживаемых документов

Приоритеты выставляет менеджер проекта Задача в итерации – протестировать изменения в сборке

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

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

Больше вариантов тестов за счет отсутствия перечисленных шагов – творческий поиск багов.

Более гибкое определение приоритета тестов в пределах одного набора – с учетом масштабности изменений.

Фрагмент чек-листа

Отчет по сборке в чек-листе

Нет тест-кейсовРешение: тестировать по спецификации

Каждый пункт спецификации содержит исходные данные и ожидаемый результат

Тестировщик сам выбирает наиболее важные в текущей итерации пункты

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

Требуется высокий профессиональный уровень тестировщика, хорошее понимание предметной области.

Творческий поиск ошибок – за счет отсутствия шагов.

«Живая» спецификация – благодаря постоянной работе с документом он всегда находится в актуальном состоянии.

Живая спецификация. Мое виденье фичи после исследования и мастер-класса

разработчика

Живая спецификация. Дополнения менеджера

Живая спецификация. Изменения разработчика

Не проводится системное тестированиеРешение: постепенно «обходить» все функции по чек-листу

Помимо изменений в задачи на итерацию входит тестирование нетестированных ранее фич из чек-листа

Список задач пополняется исходя из имеющегося времени на тестирование – до следующей сборки

Когда заканчиваются задания, полученные на основе списка изменений, а время еще остается, тестировщик выбирает из нетестированных ранее функций функции с наивысшим приоритетом

В ранее протестированном функционале могут возникать новые ошибки, например ошибки интеграции.

Что-то мы можем не протестировать вообще.

У нас есть информация о том, какую функцию и в какой сборке мы смотрели. Если все функции протестированы, круг открывается заново.

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

Тестирование не укладывается в срокиРешение:приоретизировать задачи;анализировать результаты тестирования по чек-листу;сообщать о выполненных и невыполненных задачах (в качестве аргумента для увеличения сроков тестирования)

Приоритет расставляет менеджер проекта Тестировщик тестирует наиболее приоритетные задачи

из имеющихся в итерации Если тестировщик не выполняет все задания –

разбираться: возможно, сборку пересобрали тут же; однократная нехватка времени – задействовать свободного специалиста; непонятность функционала – привлечь разработчика и / или менеджера; стабильное «неуспевание» – дробить зоны ответственности (или другое)

Чек-лист с результатами тестирования прикладывается в базу ошибок и доступен для всех пользователей

«Покрытие» тестирования – отношение количества выполненных заданий к

общему количеству заданий в итерации. В идеале равно 1

Самые важные функции тестируются в первую очередь.

Анализ результатов дает возможность подтянуть слабые места.

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

Неполноценная среда тестированияРешение: использовать виртуальные машины

Есть все базовые комбинации ОС и платформы Снапшоты позволяют быстро и просто сделать много

вариаций среды В снапшотах хранятся все сборки, отданные

пользователям Задел для автоматизации и ночных тестов

Решаем проблему конфигурационного тестирования.

Можно проверить ошибку именно в той сборке и той среде, в которой она проявляется у пользователя (по крайней мере максимально приблизить условия).

Изначальный список виртуалок

Одна и та же среда тестирования для нескольких проектовРешение: виртуальные машины, механизм снапшотов

Есть все базовые комбинации ОС и платформы Снапшоты позволяют быстро и просто сделать много

вариаций среды

Решаем проблему влияния продуктов друг на друга.

Тестирование выполняется в среде разработкиРешение:соглашение с разработчиками – тестировать только на собранном продукте, но иногда не выполняется;решение разработчика «у меня не повторяется» принимать только после повтора на собранном продукте; на чистой виртуальной машине

Дополнительный плюс: разработчики «примеряют» роль тестировщиков на себя. Идея «отдать что-нибудь и пусть смотрят» перестает работать.

Не принимается во внимание мнение тестировщиков о стабильности продуктаРешение:сообщать о стабильности продукта команде;составлять списки неисправленных ошибок и рассылать их;напоминать разработчикам об ошибках в их функциональности

У объекта «сборка» в базе ошибок есть атрибут – решение тестировщика

Вместе со сборкой заказчику отсылаются списки неисправленных и исправленных ошибок и решение тестировщиков о стабильности продукта

Работают ежемесячные напоминания – списки неисправленных ошибок разработчика

Предоставляем информацию о стабильности продукта команде.

Предоставляем информацию о стабильности продукта заказчику.

Решение тестировщика

Замечания по сборке

Список неисправленных

Напоминания и тестирование «в контексте» имеют свои

плоды

Что изменилось Сегодня:

Отдел тестирования принимает активное участие в разработке технического задания и создании спецификаций.

В любой момент мы можем сказать, что именно протестировано, какие найдены проблемы.

Мы можем анализировать ресурсы и результаты тестирования.

Команда заинтересована в развитии отдела тестирования, так как он приносит видимый результат, он полезен.

Заказчик заинтересован в отделе тестирования, так как получает объективную картину о состоянии продукта.

Спасибо за внимание!

Вопросы?