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

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 и CSoftDevelopment (НОУ ДПО "Магма"); • внедрение системы управления проектами на базе 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. Спасибо за внимание!Вопросы?