Тестирование ПО. Перевод презентации курса MVA

1. Шаптала Максим | Компьютерная академия Шаг

2. Тестирование ПО
01 | Основы тестирования ПО
1.1 Тестирование ПО
1.2 Программные и железные компоненты
1.3 Основы программирования
1.4 Управление жизненным циклом
04 | Управление проектами тестирования
4.1 Основные контр. точки тестирования
4.2 Agile подход
4.3 Работа в распределенной команде
4.4 Отчеты о тестировании
02 | Методологии тестирования ПО
2.1 Техники тестирования
2.2 Уровни тестирования
2.3 Типы тестов
05 | Работа с багами
5.1 Выявление программных дефектов
5.2 Журналирование багов
5.3 Управление багами
03 | Разработка тестов ПО
3.1 Пользовательское централизованное
тестирование
3.2 Тестируемость ПО
3.3 Разработка плана тестирования
компонентов
3.4 Тестирование фитч
3.5 Область тестирования
06 | Автоматизация тестирования ПО
6.1 Автоматизация тестирования
6.2 Стратегия автоматизация тестирования
6.3 Написание автоматизированных тестов
6.4 Управление тестовыми скриптами
Содержание курса

3. 04 | Управление проектами
тестирования

4. 1. Основные контрольные точки тестирования
2. Agile подход
3. Работа в распределенной команде
4. Отчеты о тестировании
Обзор

5. 4.1 Контрольные точки
04 | Управление проектами тестирования ПО

6. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Описание основных контрольных точек
– Process fundamentals
– Тема включает:
 Входные критерии
 Подписи

7. Основные вопросы
В чем разница между входными и выходными критериями?
Какой термин используется для описания перечня задач
утвержденных во время проекта?
Как называется когда человек или команда официально
одобряют прогресс по проекту?

8. Управление процессом
Процесс связан с деятельностью которая предусмотрена
проектом.
В Microsoft® Visual Studio® и Microsoft Team Foundation Server
описывается процесс разработки ПО, которому должны
следовать члены команды разработчиков.
Предоставляется веб портал который выступает в роли
хранилища информации связанной с проектом.

9. Фазы
Используемая терминология для описания фаз
разрабатываемого проекта будет зависеть от используемой
модели разработки.
 Например, agile модели связаны с итерациями или спринтами, в
тоже время этап или версия, вероятнее всего, будет
использоваться в модели водопада.
В общем случае, фаза включает следующее:
 Деятельность, включающую пользовательские истории и задачи
которые составляют фазу.
 Входные критерии
 Выходные критерии

10. Контрольные точки
Через равные промежутки времени, команда разработчиков
может провести оценку качества и хода выполнения проекта.
Часто, эти контрольные точки назначаются в конце одной или
нескольких фаз.
Есть два типа контрольных точек:
 Внутренние ориентированы на процесс и обеспечение
конкретных целей для команды.
 Внешние ориентированы на клиента или, возможно, на
организацию вне команды разработчиков, например,
маркетинговый отдел.
Контрольные точки могут быть привязаны к определенной
дате в календаре, а не к прогрессу в проекте.

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

12. Визирование
Подпись чего-то означает утверждение или одобрение.
При разработке ПО, несколько различные лица могут иметь
право визирования:
 Клиент может подписаться под пользовательскими требованиями
или под релиз-кандидатом.
 Тест-менеджеры могут подписать план теста или набор тестов.
 Проект-менеджер может подписать версию или спринт.

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

14. Вопросы раздела
 В чем разница между входными и выходными критериями?
 Какой термин используется для описания перечня задач
утвержденных во время проекта?
 Как называется когда человек или команда официально
одобряют прогресс по проекту?

15. 4.2 Agile
04 | Управление проектами тестирования ПО

16. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Agile
– Scrum
– Kanban
– Управление спринтами

17. Основные вопросы
Приведите два примера гибкой разработки с применением
agile подхода?
Как называются фазы в agile?
Какая техника планирования минимизирует узкие места?

18. Agile
Agile это набор ценностей, принципов и практик которые включают в
себя итеративную разработку, разработку через тестирование и
мгновенную обратную реакцию.
Итеративный потому, что ценится короткий цикл разработки и быстрые
релизы (или, как минимум, отзывы) пред началом следующего цикла.
 В противовес с походом принятым в разработке по методу водопада, по
которому существует одна фаза планирования, одна фаза разработки и т.д.
Agile может быть рассмотрен как набор принципов и убеждений;
существует несколько методологий управления и разработки которые
базируются на понятиях agile.

19. Отзыв в Agile разработке
В моделях agile, клиент рассматривается как часть команды, а не как
внешняя сущность.
Клиенты или заказчики тесно вовлечены в планирование, и их отзыв
является неотъемлемой частью развития ПО.
 В то время, как традиционные модели сфокусированы на внутренней
разработке при которой клиенты или конечные пользователи знакомятся с
приложением только в конце разработки, agile полагается на получение
постоянных отзывов от клиентов.
По этой причине, agile требует меньше времени ни планирование и
начало реализации проекта. Это обусловлено тем, что при agile
подходе планируется одна фаза разработки за раз.

20. Документирование в Agile разработке
Традиционные модели разработки уделяют много внимания
документированию кода.
В связи с тем, что при agile разработке код может
изменяться быстро и часто, то на документирование
делают меньший акцент.
Вместо этого, в agile моделях тесты выступают как часть
документации.
Модульные тесты являются критически важными для
понимания того как моды работают, и могут быть обновлены
во время развития проекта.

21. Scrum
Scrum это agile производный (или реализация) который сосредоточен
на том, как управлять разработкой в команде.
В scrum, команда разработчиков гибкая и само организовывающаяся
разработчики находятся в постоянном общении и обмене мнениями
относительно управления в проекте.
Как и в других agile подходах, scrum ценит скорость, итеративные фазы
разработки, которые называются спринтами (sprints).
Scrum команда понимает, что требования клиента могут часто меняться,
поэтому короткие спринты позволяют команде эффективно отвечать на
изменяющиеся задачи в проекте.

22. Спринты
Спринты это базовая фаза разработки, и команда
разработчиков будет завершать множество спринтов на
протяжении крупного проекта.
Название подразумевает короткий период времени. Scrum
разработчики ограничены длительностью спринта исходя из
времени, а не на выходных критериях – часто спринт длится
меньше, чем месяц.
В случае, если спринт завершен, команда получает отзыв от
клиента и планирует следующий спринт, который будет
включать новые фитчи (или изменение фитч, если надо).

23. Экстремальное программирование (XP)
Экстремальное программирование это agile
программирование или инженерная методология в которой
делается акцента на разработку через тестирование и
применение парного программирования.
В парном программировании, один программист
сосредоточен на написании кода для обеспечения заданных
требований, в то же время другой просматривает код и
обеспечивает устранение ошибок и повышение качество
исходного кода.
XP часто используется в сочетании с scrum, хотя они иногда
отличаются в терминологии. Например, в XP вместо спринтов
используются итерации

24. Управление Спринтом/Итерацией
Спринтам предшествуют плановые митинги, на которых
команда (включая клиентов) определят какие задачи должны
быть решены.
Часто, спринт сфокусирован на решении одной или более
пользовательских историй.
 Истории разделяют на задачи, и разработчики сосредоточены на
выполнении этих задач в отведенное время.
В конце спринта, команда проводит ретроспективу митингов
для оценки их производительности, и только потом
начинается планирование следующего спринта.

25. Во время спринта
Microsoft® Visual Studio® предоставляет различные инструменты
для отслеживания и управления прогрессом во время спринта.
Team Foundation Server (TFS) будет отслеживать изменения в
backlog, или списке задач пока они не будут завершены.
Отчеты предоставляют информацию о прогрессе для каждой
пользовательской истории (основанной на завершенности ее
задач) и будет накапливать статистику по покрытию кода и
результатам тестирования.
Основываясь на этих данных, TFS может рассчитать скорость
команды, или количество историй, которые могут быть завершены
перед завершением спринта.

26. Kanban
Kanban это модель планирования, которая позволяет реализацию
точно в срок путем управления рабочим потоком для устранения
перегрузок команды разработчиков.
Изначально был разработан в Toyota® для минимизации узких мест на
линиях сборки.
 В разработке, позволяет минимизировать узкие места и причины простоя
когда одна команда ушла далеко вперед или осталась далеко позади.
Обращается внимание на разработку точно в срок, когда фитчи
добавляются только тогда, когда они необходимы.
Visual Studio включает инструмент называемый Kanban доска для
помощи в направлении усилий программистов и минимизации уких
мест.

27. Вопросы раздела
 Приведите два примера гибкой разработки с применением
agile подхода?
 Как называются фазы в agile?
 Какая техника планирования минимизирует узкие места?

28. 4.3 Работа с
распределёнными
командами
04 | Управление проектами тестирования ПО

29. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Коммуникация
– Риск менеджмент
– Управление расписаниемSchedule Management
– Процесс развертывания

30. Основные вопросы
Что такое распределенная команда?
Для каких целей компании используют распределенные команды?
Какие проблемы сопровождают разработку в распределённых
командах?

31. Необходимость общения
Общение это центральный компонент успешной разработки. В
аgile предусмотрены ежедневные совещания (митинги).
Дополнительно, случаи неформального общения между членами
команды, такие как дискуссия во время обеденного перерыва или
в комнатах отдыха вносят существенный вклад в развитие проекта.
Хотя общение по телефону и веб-конференции могут быть
включены для удаленного общения команды, распределенная
команда нуждается в неформальном общении по проекту.
Основная причина в том, что распределенные команды
сталкиваются с большими трудностями и низкой
производительностью является сложность удаленной комуникации

32. Распределенные группы в сравнении с
локальными группами
Распределенная команда это группа в которой один или все
члены команды на работают в том же месте.
Хотя некоторые распределенные команды могут включать лиц
со всего мира (иногда их называют глобально
распределенным командами), члены команды иногда могут
находиться на небольшом расстоянии друг от друга.
В общем случае, распределенные команды связаны с
технологиями коммуникации такими, как телефонная связи или
видео конференции.

33. Риски связанные с распределенными командами
Опрос проведенный в 2008 году установил что
распределенные agile команды успешны на 23% меньше, чем
локальные команды.
Различные исследования установили, что в командах
разработчиков в которых делается акцент на личное общение
увеличивается продуктивность и, в конечном счете,
сокращается время на разработку

34. Инструменты общения
Технология делает общение простым даже через огромные
расстояния.
Большинство команд использует видео или веб-конференции на
базе Skype™ для общения с удаленными членами во время
митингов. Способность видеть друг друга помогает в общении (т.к.
невербальное общение также важно) а также строить отношение в
группе.
Microsoft® SharePoint® Workspace представляет быстрый и
эффективный способ обмена файлами.
Команды могут также использовать вики знания основанные на
простом в поддержке хранилище информации.

35. Преимущества распределенных команд
Компании используют распределенные команды по разным
причинам:
 Воспользовавшись неиссякаемым источником талантов. Иногда
команды не могут найти тех разработчиков, которые им нужны
локально.
 Сокращение расходов. Наем членов команды из другой местности
или страны может быть более дешевым. Позволяя локальным
членам команды работать из дома (“удаленная работа”) также
может сократить расходы.
 Достижение новых рынков. Компании желающие разрабатывать
продукт для удаленного рынка могут получить преимущество от
наличия членов в команде с этого региона или рядом с
пользователем

36. Visual Studio в распределенной разработка
Microsoft® Visual Studio® и Team Foundation Server (TFS)
предоставляют инструменты которые могут сократить проблемы
взаимодействия распределенных команд.
Руководство процесса создает портал который хранит
документацию по проекту, простой доступ (и редактирование)
одновременно для локальных и удаленных членов команды.
К рабочим элементам можно добавлять файлы, позволяющие
членам команды распространять диаграммы, изображения и
другие документы.
Уведомления и оповещения могут отправляться команде в целом и
отдельным разработчикам.

37. Вопросы раздела
 Что такое распределенная команда?
 Для каких целей компании используют распределенные команды?
 Какие проблемы сопровождают разработку в распределённых
командах?

38. 4.4 Отчеты о
тестировании
04 | Управление проектами тестирования ПО

39. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Определение соответствующего статуса и составляющих отчета.
– Определение периода отёчности для достижения основных этапов
проекта.
– Определение соответствующих получателей для различных типов
отчётов.

40. Основные вопросы
Что такое диаграмма сгорания?
Как данных с предыдущего спринта могут быть полезны для
планирования последующего спринта?
Какая метрика описывает степень изменения исходного кода?

41. Отчеты и панели мониторинга
Во время разработки, членам команды необходимо отслеживать их
собственный прогресс, равно как и прогресс команды в целом.
Поскольку быстрый темп agile разработки требует гибкости и
информированности, отчётность является особенно важной.
Microsoft® Visual Studio® и Microsoft Team Foundation (MTF) предоставляет
весьма гибкие опция для формирования отчетов.
Термин доклад, в общем, относится к представлению данных на основе
определенного поиска или заданного критерия. Традиционно отчеты
печатались, но они могут также быть просмотрены на экране, отправлены по
почте или добавлены на веб-сайт.
Панель мониторинга предоставляет динамический обзор проекта используя
простые визуальные данные и диаграммы.

42. Полезные метрики
Сгорания: представляет завершенную и оставшуюся работу за
определенный промежуток времени; помогает установить
время завершения или количество работы которая может быть
завершена в заданный период времени.
Скорость: измеряет проделанную работу в единицу времени.
Например, проделанную работу на итерацию.
Прогресс ошибок: количество действующих и решенных
ошибок во времени; полезно для обзора прогресса команды
направленных на решение ошибок.
Рабочее задание: количество работы (в часах или задачах)
назначенное каждому члену команды.

43. Полезные метрики. Продолжение
Прогресс плана тестирования: диаграмма сгорания
результатов тестирования за определенный период времени.
Текучесть кода: измеряет как много строк кода командой
добавлено, удалено или модифицировано; показывает степень
изменения файлов с исходным кодом во времени.

44. Планирование спринта
Перед спринтом, команда изучает невыполненные задачи и
пользовательские история для определения приоритетных и
основные этапы.
Данные сгорания с предыдущих спринтов помогают
установить управляемые сроки и этапы.
Невыполненные задания (Backlog) и отчеты историй
устанавливают задачи или проблемы требующие внимания и
позволяют установить приоритеты.
Отчеты о рабочих заданиях помогают команде в
распределении ролей и балансировке рабочей нагрузке.

45. Отчеты во время спринта
Выгорание (или степень сгорания) является важным
показателем во время спринта.
Он показывает общий прогресс и позволяет установить
находится ли команда на пути достижения к своей цели.
Отдельные члены могут использовать Моя информационная
панель (My Dashboard) в Team Foundation Server для
отображения:
 Все назначенные задания
 Назначенные ошибки и тестовые случаи
 Ближайшие события (собрания, крайние сроки)
 Обзор последнего прогресса

46. Успешный отчет выгорания

47. Неудачный отчет выгорания

48. Ретроспективный отчет
После завершения спринта, команда изучает данные для того,
что бы проверить нуждается ли какой-либо процесс в
изменении приоритета для начала в следующем спринте.
Члены команды могут изучить прогресс каждого разработчика
или пары и прогресс тестирования для оценки
производительности команды.
Затем процесс продолжается; команды рассматривают
диаграммы выгорания и прогресс задач для определения циле
для следующего спринта.

49. Вопросы раздела
 Что такое диаграмма сгорания?
 Как данных с предыдущего спринта могут быть полезны для
планирования последующего спринта?
 Какая метрика описывает степень изменения исходного
кода?

50. Дополнительные ресурсы
MSDN Software Testing Resources
Process Guidance & Process Templates for TFS http://msdn.microsoft.com/en- us/library/hh533801.aspx
Planning and Tracking Project http://msdn.microsoft.com/en- us/library/dd286619.aspx
Work Items and Workflow (Agile) http://msdn.microsoft.com/en- us/library/dd997897.asp
Agile Principles and Values http://msdn.microsoft.com/en- us/library/dd997578.aspx
Testing Methodologies http://msdn.microsoft.com/en- us/library/ff649520.aspx
Scrum http://msdn.microsoft.com/en- us/library/dd997796%28v=VS.100%29.aspx
Open Distributed Agile Development http://download.microsoft.com/download/ 4/4/a/44a2cebd-63fb-4379-
898d- 9cf24822c6cc/distributed_agile_developme
nt_at_microsoft_patterns_and_practices.pd
Collaborating within a Team Using Team
Project Resources
http://msdn.microsoft.com/en- us/library/ms242904(v=vs.100).aspx
Distributed Scrum http://msdn.microsoft.com/en- us/library/jj620910.aspx
Burndown and Burn Rate Report (Agile) http://msdn.microsoft.com/en- us/library/dd380678.asp
Excel Reports (Agile) http://msdn.microsoft.com/en- us/library/vstudio/dd997876.aspx
My Dashboard (Agile) http://msdn.microsoft.com/en- us/library/dd420561.aspx