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

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

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

3 Ч то такое хаотичная разработка? Нет: Четких сроков сдачи продукта заказчику Требований заказчика Документированного плана разработки продукта Спецификаций Определенной методологии Но есть: Примерная оценка длительности проекта от опытных разработчиков Недокументированные требования – в головах у членов команды и заказчика Документированные, хотя и запутанные требования – ГОСТы по строительству и машиностроению Итеративная разработка продукта, svn, база ошибок,..

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

5 Компания «Магма-Компьютер» создана в 1994 году. В 1996 г. в ней появился отдел разработки ПО. В 1998 году был выпущен первый программный продукт – ShapeSearch. В 2007 году компания вошла в группу компаний CSoft, в связи с чем стала называться «СSoft Омск». На сегодняшний день у компании следующие сферы деятельности: продажа и внедрение программного обеспечения для САПР; разработка программного обеспечения; курсы по работе с программными продуктами Autodesk и CSoft Development (НОУ ДПО "Магма"); внедрение системы управления проектами на базе TDMS; разработка библиотек стандартных компонентов; техническая поддержка САПР. Н емного о компании,..

6 …о продуктах... Пересекающийся функционал Часть продуктов выходит в виде надстроек к другим платформам Сборки одновременные, но не всегда и не ежедневно

7 …и о команде На данный момент штат компании составляет 40 человек, из них 29 активно участвуют в разработке программного обеспечения. Сегодня наша команда это: 18 разработчиков; 5 тестировщиков; 3 менеджера проекта; 2 человека, которые пишут справку, руководства пользователя и прочую документацию; 1 системный администратор. Из 18 разработчиков 10 работают в компании более 5 лет, многие из них – с момента появления отдела разработки. Команда самоорганизованная, профессиональная, между членами команды существуют доверительные отношения.

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

9 В ыявление проблем. П ути решения

10 Автоматизировать «нечего» Нужны специалисты в предметной области При желании можно найти хороших специалистов со сложным сочетанием навыков и знаний Необходимость повышения уровня компьютерной грамотности В дальнейшем – поиск «автоматизаторов» Нет команды тестирования Решение: создать команду тестирования знает работу БТИ «машино строитель» начальник «строитель»«аналитик» Хорошее знание предметной области Более охотное согласие руководства на прием сотрудника

11 Нет документированных требований Решение: составлять «карандашные» требования на новый функционал; создать и регулярно обновлять в svn базу спецификаций; формат спекцификации – документ Word Существующие инструменты довольно сложные Требования есть в головах у членов команды Большой объем «старого» функционала при недостатке времени Мы знаем «как сделано», но теряем «как надо было сделать» (что для старого функционала не очень актуально – он обкатан как пользователями, там и командой). В Word удобно ставить пометки на полях. «Привычный» редактор и отдельная ветка уже существующего хранилища – не требуют освоения новых систем и дополнительных расходов на покупку софта.

12 В svn есть механизм одновременной работы и версионность. При желании можно дополнить информацию любыми видами документов – таблицами, ГОСТами в любом формате, электронными письмами. Ветка svn, посвященная ТЗ и спецификациям

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

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

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

16 Требования обсуждаются без привлечения тестировщиков Решение: привлекать тестировщиков к обсуждению ТЗ фичи на старте; создавать и поддерживать спецификации совместно с тестировщиками По итогам обсуждения ТЗ составляется спецификация, параллельно с кодированием фичи ТЗ хранится, но, как правило, в дальнейшем не меняется Когда изменять спецификацию? - Об этом может сказать рассылка изменений в сборке Тестировщики в курсе изменений в функциональности. Тестировщики участвуют в анализе функциональности.

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

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

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

20 Нет цели тестирования в итерации. Невозможно отследить, что именно протестировано Решение: работа по чек-листу с приоритетами; цели тестирования в итерации – результат анализа списка изменений и чек-листа Вместо тест-плана – приоритезированный чек-лист. Отказ от «тяжелых», трудно поддерживаемых документов Приоритеты выставляет менеджер проекта Задача в итерации – протестировать изменения в сборке и очередную часть нетестированного функционала с наивысшим приоритетом из оставшихся Неизвестно, какие именно тесты выполнял тестировщик в рамках тестирования чека (здесь мы теряем контроль, но полагаемся на профессиональность). Больше вариантов тестов за счет отсутствия перечисленных шагов – творческий поиск багов. Более гибкое определение приоритета тестов в пределах одного набора – с учетом масштабности изменений.

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

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

23 Нет тест-кейсов Решение: тестировать по спецификации Каждый пункт спецификации содержит исходные данные и ожидаемый результат Тестировщик сам выбирает наиболее важные в текущей итерации пункты Нельзя сказать, какие именно тесты проводятся в итерации, за исключением тех, которые приводят к нахождению ошибок. Требуется высокий профессиональный уровень тестировщика, хорошее понимание предметной области. Творческий поиск ошибок – за счет отсутствия шагов. «Живая» спецификация – благодаря постоянной работе с документом он всегда находится в актуальном состоянии.

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

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

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

27 Не проводится системное тестирование Решение: постепенно «обходить» все функции по чек- листу Помимо изменений в задачи на итерацию входит тестирование нетестированных ранее фич из чек-листа Список задач пополняется исходя из имеющегося времени на тестирование – до следующей сборки Когда заканчиваются задания, полученные на основе списка изменений, а время еще остается, тестировщик выбирает из нетестированных ранее функций функции с наивысшим приоритетом В ранее протестированном функционале могут возникать новые ошибки, например ошибки интеграции. Что-то мы можем не протестировать вообще. У нас есть информация о том, какую функцию и в какой сборке мы смотрели. Если все функции протестированы, круг открывается заново. Мы можем точно сказать, на что именно нам необходимо дополнительное время.

28 Тестирование не укладывается в сроки Решение: приоретизировать задачи; анализировать результаты тестирования по чек-листу; сообщать о выполненных и невыполненных задачах (в качестве аргумента для увеличения сроков тестирования) Приоритет расставляет менеджер проекта Тестировщик тестирует наиболее приоритетные задачи из имеющихся в итерации Если тестировщик не выполняет все задания – разбираться: возможно, сборку пересобрали тут же; однократная нехватка времени – задействовать свободного специалиста; непонятность функционала – привлечь разработчика и / или менеджера; стабильное «неуспевание» – дробить зоны ответственности (или другое) Чек-лист с результатами тестирования прикладывается в базу ошибок и доступен для всех пользователей

29 «Покрытие» тестирования – отношение количества выполненных заданий к общему количеству заданий в итерации. В идеале равно 1 Самые важные функции тестируются в первую очередь. Анализ результатов дает возможность подтянуть слабые места. Мы можем сказать, сделали ли мы все, от нас зависящее, чтобы уложиться в сроки.

30 Неполноценная среда тестирования Решение: использовать виртуальные машины Есть все базовые комбинации ОС и платформы Снапшоты позволяют быстро и просто сделать много вариаций среды В снапшотах хранятся все сборки, отданные пользователям Задел для автоматизации и ночных тестов Решаем проблему конфигурационного тестирования. Можно проверить ошибку именно в той сборке и той среде, в которой она проявляется у пользователя (по крайней мере максимально приблизить условия).

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

32 Одна и та же среда тестирования для нескольких проектов Решение: виртуальные машины, механизм снапшотов Есть все базовые комбинации ОС и платформы Снапшоты позволяют быстро и просто сделать много вариаций среды Решаем проблему влияния продуктов друг на друга.

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

34 Не принимается во внимание мнение тестировщиков о стабильности продукта Решение: сообщать о стабильности продукта команде; составлять списки неисправленных ошибок и рассылать их; напоминать разработчикам об ошибках в их функциональности У объекта «сборка» в базе ошибок есть атрибут – решение тестировщика Вместе со сборкой заказчику отсылаются списки неисправленных и исправленных ошибок и решение тестировщиков о стабильности продукта Работают ежемесячные напоминания – списки неисправленных ошибок разработчика Предоставляем информацию о стабильности продукта команде. Предоставляем информацию о стабильности продукта заказчику.

35 Решение тестировщика Замечания по сборке

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

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

38 Ч то изменилось Сегодня: Отдел тестирования принимает активное участие в разработке технического задания и создании спецификаций. В любой момент мы можем сказать, что именно протестировано, какие найдены проблемы. Мы можем анализировать ресурсы и результаты тестирования. Команда заинтересована в развитии отдела тестирования, так как он приносит видимый результат, он полезен. Заказчик заинтересован в отделе тестирования, так как получает объективную картину о состоянии продукта.

39 С пасибо за внимание! В опросы?