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

Практика организации
тестирования при
хаотичной разработке
приложений
Елена Цыганова
В 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
Неполноценная среда тестирования
Решение: использовать виртуальные машины
 Есть все базовые комбинации ОС и платформы
 Снапшоты позволяют быстро и просто сделать много
вариаций среды
 В снапшотах хранятся все сборки, отданные
пользователям
 Задел для автоматизации и ночных тестов
Решаем проблему конфигурационного тестирования.
Можно проверить ошибку именно в той сборке и той
среде, в которой она проявляется у пользователя (по
крайней мере максимально приблизить условия).
Изначальный список виртуалок
Одна и та же среда тестирования для нескольких
проектов
Решение: виртуальные машины, механизм снапшотов
 Есть все базовые комбинации ОС и платформы
 Снапшоты позволяют быстро и просто сделать много
вариаций среды
Решаем проблему влияния продуктов друг на друга.
Тестирование выполняется в среде разработки
Решение:
соглашение с разработчиками – тестировать только на
собранном продукте, но иногда не выполняется;
решение разработчика «у меня не повторяется»
принимать только после повтора на собранном продукте;
на чистой виртуальной машине
Дополнительный плюс: разработчики «примеряют»
роль тестировщиков на себя. Идея «отдать что-нибудь
и пусть смотрят» перестает работать.
Не принимается во внимание мнение тестировщиков о
стабильности продукта
Решение:
сообщать о стабильности продукта команде;
составлять списки неисправленных ошибок и рассылать
их;
напоминать разработчикам об ошибках в их
функциональности
 У объекта «сборка» в базе ошибок есть атрибут – решение
тестировщика
 Вместе со сборкой заказчику отсылаются списки
неисправленных и исправленных ошибок и решение
тестировщиков о стабильности продукта
 Работают ежемесячные напоминания – списки
неисправленных ошибок разработчика
Предоставляем информацию о стабильности продукта
команде.
Предоставляем информацию о стабильности продукта
заказчику.
Замечания по сборке
Решение тестировщика
Список неисправленных
Напоминания и тестирование
«в контексте» имеют свои
плоды
Что изменилось
Сегодня:
Отдел тестирования принимает активное участие в
разработке технического задания и создании
спецификаций.
В любой момент мы можем сказать, что именно
протестировано, какие найдены проблемы.
Мы можем анализировать ресурсы и результаты
тестирования.
Команда заинтересована в развитии отдела
тестирования, так как он приносит видимый результат, он
полезен.
Заказчик заинтересован в отделе тестирования, так как
получает объективную картину о состоянии продукта.
Спасибо за внимание!
Вопросы?