Тестирование и его связь с жизненным циклом ПО

1. Занятие 2

Тестирование и его связь
с жизненным циклом ПО

2. Цикл разработки ПО

Цикл (процесс) разработки ПО
(software development life cycle) – это путь от идеи до поддержки
готового продукта. Чем более отлажены каждая из стадий цикла и
координация между ними, тем эффективнее работает компания, тем
выше качество и тем счастливее пользователи/клиенты.
it-courses.by

3. Жизненный цикл ПО

Формирование и анализ требований
Проектирование
Реализация
Тестирование продукта
Внедрение
Эксплуатация и сопровождение
it-courses.by

4. Когда начать тестировать?

it-courses.by

5. Формирование и анализ требований

Тестирование требований на вменяемость/ осуществимость
Тестирование функциональной спецификации
Выделение модулей приложения
Обдумывание предварительных тестовых сценариев на основе
требований
it-courses.by

6. Проектирование

Тестирование документов,
описывающих архитектуру
(product architecture)
и дизайн (product design)
Тестирование плана проекта
it-courses.by

7. Реализация

Тестирования кода и модульное тестирование
Тестирование результатов итерации
Регрессионное тестирование
it-courses.by

8. Тестирование продукта

Тестирование готового
приложения
Приемочное тестирование
it-courses.by

9. Внедрение

Тестирование совместимости
продукта с существующей
инфраструктурой заказчика
(типы серверов, окружение…)
Сбор и обработка
обратной связи
о приложении
от пользователей
it-courses.by

10. Эксплуатация и сопровождение

Обработка отчетов об ошибках от пользователей
во время эксплуатации
Верификация исправления ошибок
Обработка запросов новой функциональности
Тестирование новой функциональности
it-courses.by

11. Когда прекращать тестирование?

it-courses.by

12. Эвристики

Эвристики – это способы решения проблемы или принятия решения
it-courses.by

13. Время вышло

Эвристика «Время вышло!».
Для многих специалистов по тестированию это
наиболее распространенная эвристика.
Мы останавливаем тестирование,
когда заканчивается
выделенное на него время.
it-courses.by

14. Пиньяты

Эвристика пиньяты
Мы прекращаем ломать
программу, когда начинают
выпадать конфеты
= мы останавливаем тестирование,
когда видим первую достаточно серьезную проблему.
it-courses.by

15. Мертвая лошадь

Эвристика «мертвой лошади»
В программе слишком много ошибок,
так что продолжение тестирования
не имеет смысла. Мы знаем,
что все изменится настолько,
что сведет на нет результаты
текущего тестирования.
it-courses.by

16. Задание выполнено

Эвристика «Задание выполнено»
Мы останавливаем тестирование, когда найдены ответы на все
поставленные вопросы.
it-courses.by

17. Отмена задания

Эвристика «Отмена задания»
Наш клиент сказал: «пожалуйста, прекратите тестирование».
Это может произойти по причине перерасхода бюджета,
или вследствие отмены проекта, и по любой другой причине.
Какова бы ни была причина,
нам поручили остановить тестирование.
(«Время вышло!» может быть частным случаем
«Отмены задания», в том случае,
если предпочтительнее, чтобы не мы сами,
а заказчик принял решение
о прекращении тестирования)
it-courses.by

18. Я зашел в тупик

Эвристика «Я зашел в тупик!»
По какой-то причине мы
останавливаемся, поскольку
обнаруживаем препятствие.
У нас нет информации,
которая нам требуется (например, люди заявляют,
что не могут тестировать без достаточного количества
спецификаций). Есть блокирующая ошибка, и мы не можем перейти
в ту область продукта, которую необходимо протестировать. У нас нет
необходимого оборудования или инструментария, у команды нет
квалификации, требуемой для выполнения некоторых тестов
it-courses.by

19. Освежающая пауза

Эвристика «освежающей паузы»
Вместо прекращения тестирования
мы приостанавливаем его.
Мы можем остановить тестирование
и сделать перерыв, когда мы устали,
нам стало скучно или пропало вдохновение.
Мы можем сделать паузу на то,
чтобы выполнить исследования, разработать планы, поразмыслить.
Идея заключается в том, что нам нужен перерыв,
после которого мы сможем вернуться к продукту.
it-courses.by

20. Привычного завершения

Эвристика «Привычного завершения»
Есть протокол, задающий определенное количество идей для
тестирования, или тест-кейсов, или циклов тестирования.
Agile-команды, например, часто применяют такой подход:
«когда выполнены все приемочные тесты, мы знаем,
что продукт готов к поставке»
Эвальд Руденриджс приводит пример
этой эвристики в статье
«Когда прекращать тестирование».
Он говорит, что он останавливается,
«когда выполнено определенное количество
тестовых циклов, включая регрессионное тестирование»
it-courses.by

21. Больше нет интересных вопросов

Больше нет интересных вопросов
Не осталось вопросов, ответы на которые были бы достаточно
ценными, чтобы оправдать стоимость продолжения тестирования.
Эта эвристика используется в основном как дополнение к другим
эвристикам. Она помогает принять решение о том,
есть ли какие-то риски, если остановить тестирование.
Даже если одна эвристика советует нам
прекратить тестирование, нужно проверить,
есть ли интересные вопросы, серьезные риски
в других областях. Если они есть,
то лучше продолжить тестирование.
it-courses.by

22. Уклонения/безразличия

Эвристика уклонения/безразличия
Тестируемое приложение может быть первой версией, которую, как
мы знаем, скоро заменят. Некоторые люди прекращают тестирование
по причине лени, злого умысла или отсутствия мотивации.
Иногда бизнес-критичность выпуска
нового релиза настолько высока, что никакая
мыслимая проблема не остановит выход
программы, и поэтому никакие новые
результаты тестирования
не будут иметь значения.
it-courses.by

23. Методологии разработки

«Колхоз» против «Процесса»
it-courses.by

24. Как построить процесс?

it-courses.by

25. Модель разработки ПО

Структура, систематизирующая
различные виды проектной
деятельности, их взаимодействие
и последовательность в процессе разработки ПО.
Выбор той или иной модели зависит от масштаба и сложности
проекта, предметной области,
доступных ресурсов
и множества других факторов.
it-courses.by

26. Основная задача методологий

Быстрота выполнения работ и четкая координация команд
Качественное исполнение и контроль качества
Сокращение издержек
it-courses.by

27. Отличия от Кустарного производства

Большой объем параллельных проектов
Большая предсказуемость объема работ
и результата
it-courses.by

28. Методология описывает

Роли
Активности
Артефакты
Фазы и критерии их начала/окончания
it-courses.by

29. Типичные роли

Руководитель проекта (Project Manager)
Архитектор (Architect/Designer)
Бизнес-аналитик (Business Analyst)
Разработчик (Developer)
Тестировщик (Test Engineer/Tester)
it-courses.by

30. Waterfall

Каскадная модель (англ. водопад) – модель процесса разработки ПО,
в которой весь процесс выглядит как поток,
последовательно проходящий фазы
анализа требований,
проектирования,
реализации, тестирования,
интеграции и поддержки
it-courses.by

31. Waterfall

Переход
от одной фазы
к другой происходит
только после
полного
и успешного
завершения
предыдущей
it-courses.by

32. Стадии разработки по Waterfall

it-courses.by

33. Waterfall. Принципы

Переходит от одной стадии
к другой строго последовательно
Нельзя приступить к следующему
этапу, пока полностью и
исчерпывающе не сделан
текущий
Тестирования
подключается с середины
Переходов назад,
вперёд или
перекрытия фаз - Нет
it-courses.by

34. Agile

Гибкая методология разработки (англ. гибкий) –
серия подходов к разработке ПО,
ориентированных на использование
итеративной инкрементальной разработки,
динамическое формирование требований
и обеспечение их реализации
в результате постоянного взаимодействия
внутри самоорганизующихся рабочих групп,
состоящих из специалистов различного профиля
it-courses.by

35. Итеративный подход

Итеративный подход (англ. повторение) в разработке ПО –
это выполнение работ параллельно с непрерывным анализом
полученных результатов и корректировкой предыдущих этапов
работы.
it-courses.by

36. Инкрементальный подход

Инкрементальный подход (англ. увеличение) в разработке ПО –
это постепенное прирощение (увеличение) функционала небольшими
частями от релиза к релизу
it-courses.by

37. Маленький, но жизнеспособный

it-courses.by

38. Наглядно

it-courses.by

39. Agile. Понятия

Agility – ловкость, проворность
Visibility – наглядность
Release – выпуск, версия
Iteration – итерация, повтор
Values – стоимость, оценка
Unity – сплоченность, единство
Simplicity – простота
Transparency – прозрачность
Adaptability – адаптируемость
Velocity - скорость
Burn up – разгорать
it-courses.by
Goals – цели
Estimation – прогнозная оценка
Retrospective – взгляд в прошлое
Refactoring – доработка кода
Collaboration – взаимодействие,
переговоры
Integration – слияние
Vision - вИдение

40. Преимущества итеративного подхода

Снижение воздействия серьёзных рисков на ранних стадиях проекта,
что ведет к минимизации затрат на их устранение
Организация эффективной обратной связи команды с потребителем/
заказчиками и создание продукта, реально отвечающего их
потребностям
Акцент усилий на наиболее важных и критичных направлениях проекта
Непрерывное итеративное тестирование
Раннее обнаружение конфликтов и потенциальных багов
Более равномерная загрузка участников проекта
Эффективное использование накопленного опыта
Реальная оценка текущего состояния проекта
Затраты распределяются по всему проекту, а не группируются в конце
it-courses.by

41. Принципы Agile

Agile - семейство процессов разработки, а не единственный подход
в разработке программного обеспечения,
и определяется Agile Manifesto
(http://agilemanifesto.org/iso/ru/manifesto.html )
it-courses.by

42. Agile-манифест

1. Люди и взаимодействие
1. процессов и инструментов
2. Работающий продукт
2. полной документации
3. Сотрудничество
с заказчиком
важнее
4. Готовность к изменениям
it-courses.by
3. условий контракта
4. следования
первоначальному плану

43. Пояснение принципов Agile-манифеста

1.
Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного
программного обеспечения
2.
Приветствие изменений требований даже в конце разработки
(это может повысить конкурентоспособность полученного продукта)
3.
Частая поставка рабочего программного обеспечения
(каждый месяц, неделю или чаще)
4.
Тесное общение заказчика с разработчиками на протяжении всего проекта
5.
Проектом занимаются мотивированные личности, которые обеспечены
нужными условиями работы, поддержкой и доверием
6.
Рекомендуемый метод передачи информации — личный разговор
(лицом к лицу)
it-courses.by

44. Пояснение принципов Agile-манифеста

7.
Работающее программное обеспечение - лучший измеритель прогресса
8.
Все члены команды должны иметь возможность поддерживать постоянный
темп на неопределённый срок
9.
Постоянное внимание к улучшению технического мастерства и удобному
дизайну
10. Простота - искусство не делать лишней работы
11. Лучшие технические требования, дизайн и архитектура получаются у
самоорганизованной команды
12. Постоянная адаптация к изменяющимся обстоятельствам
it-courses.by

45. Scrum

Scrum (от англ. scrum «схватка») - методология управления проектами,
активно применяющаяся для гибкой разработки ПО.
Scrum чётко делает акцент на качественном контроле процесса
разработки.
it-courses.by

46. Scrum. Основные понятия

Скрам (Scrum) - это набор принципов, на которых строится процесс
разработки, позволяющий в жёстко фиксированные и небольшие по
времени итерации, называемые спринтами (sprints), предоставлять
конечному пользователю работающее ПО с новыми возможностями,
для которых определён наибольший приоритет.
Новые функции ПО, которые должны быть реализованы в очередном
спринте определяются в начале спринта на этапе планирования и не
должны изменяться на всём его протяжении. При этом строго
фиксированная небольшая длительность спринта придаёт процессу
разработки предсказуемость и гибкость.
it-courses.by

47. Scrum. Основные понятия

Спринт (Sprint) - итерация в скраме, в ходе которой создаётся
функциональный прирост ПО. Жёстко фиксирован по времени.
Длительность одного спринта от 2 до 4 недель.
it-courses.by

48. Scrum. Основные понятия

it-courses.by

49. Scrum. Основные понятия

Резерв Проекта (Product backlog) - это список требований к
функциональности, упорядоченный по их степени важности, подлежащих
реализации. Элементы этого списка называются «пожеланиями
пользователя» (user story) или элементами резерва (backlog items)
Зачастую история имеет следующую структуру:
«Будучи пользователем <тип пользователя> я хочу сделать <действие>,
чтобы получить <результат>»
Резерв проекта открыт для редактирования для всех участников скрам
процесса
it-courses.by

50. Scrum. Основные понятия

Резерв спринта (Sprint backlog) - содержит функциональность,
выбранную владельцем проекта из резерва проекта.
Все функции разбиты по задачам, каждая из которых оценивается
скрам-командой.
Каждый день команда оценивает объем работы, который нужно
проделать для завершения спринта.
it-courses.by

51. Scrum. Процесс

it-courses.by

52. Scrum. Роли

По Scrum в производственном процессе есть определенные роли,
разбитые на 2 группы: свиней и кур. Эти названия были использованы
из-за шутки:
Свинья идёт по дороге.
Курица смотрит на нее и говорит: «А давай откроем ресторан!»
Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь
его назвать?»
Курица думает и говорит: «Почему бы не назвать 'Яичница с беконом'?».
«Так не пойдёт», - отвечает свинья, «ведь тогда мне придётся
полностью посвятить себя проекту, а ты будешь вовлечена только
частично»
it-courses.by

53. Scrum. Роли

Свиньи - основные роли. Вовлечены в проект полностью
Куры - второстепенные роли. Вовлечены в проект частично
it-courses.by

54. Scrum. Свиньи

Свиньи полностью включены в проект и в скрам-процесс.
Скрам-мастер (ScrumMaster) - проводит совещания (Scrum meetings) следит за
соблюдением всех принципов скрам, разрешает противоречия и защищает
команду от отвлекающих факторов. Данная роль не предполагает ничего иного,
кроме корректного ведения скрам-процесса.
Владелец продукта (Product Owner) - представляет интересы конечных
пользователей и других заинтересованных в продукте сторон.
Скрам-команда (Scrum Team) - кросс-функциональная команда, состоящая из
специалистов разных профилей: тестировщиков, архитекторов, аналитиков,
программистов и т. д. Команда является единственным полностью вовлечённым
участником разработки и отвечает за результат как единое целое. Никто кроме
команды не может вмешиваться в процесс разработки на протяжении спринта.
it-courses.by

55. Scrum. Свиньи

it-courses.by

56. Scrum. Куры

Пользователи (Users)
Клиенты, Продавцы (Stakeholders) - лица, которые инициируют проект
и для кого проект будет приносить выгоду. Они вовлечены в скрам
только во время обзорного совещания по спринту (Sprint Review).
Управляющие (Managers) - люди, которые управляют персоналом.
Эксперты-консультанты (Consulting Experts)
it-courses.by

57. Scrum. Project Manager?

Scrum Master? А кто это?
it-courses.by

58. Scrum. Встречи (Meetings)

4-8 часов
Планирование спринта (Sprint Planning Meeting) - в начале каждого Спринта
Из резерва проекта выбираются задачи, обязательства по выполнению которых
за спринт принимает на себя команда
На основе выбранных задач создается резерв спринта. Каждая задача
оценивается в идеальных человеко-часах. Решение задачи не должно занимать
более 12 часов или одного дня. При необходимости задача разбивается на
подзадачи. Обсуждается и определяется, каким образом будет реализован этот
объём работ
(первая часть совещания) Участвует владелец проекта и скрам команда:
выбирают задачи из резерва проекта
(вторая часть совещания) Участвует только команда: обсуждают технические
детали реализации
it-courses.by

59. Scrum. Встречи (Meetings)

15 мин
Ежедневное совещание (Daily Scrum meeting):
Начинается точно вовремя
Все могут наблюдать, но только свиньи говорят
Проводится в одном и том же месте в течение спринта
В течение совещания каждый член команды отвечает на 3 вопроса:
Что сделано с момента предыдущего ежедневного совещания?
Что будет сделано с момента текущего совещания до следующего?
Какие проблемы мешают достижению целей спринта?
it-courses.by

60. Scrum. Встречи (Meetings)

4 часа
Обзор итогов спринта (Sprint review meeting) проводится после
завершения спринта:
Команда демонстрирует инкремент функциональности продукта всем
заинтересованным лицам (demo)
Все члены команды участвуют в демонстрации (один человек на
демонстрацию или каждый показывает, что сделал за спринт).
Нельзя демонстрировать незавершенную функциональность.
it-courses.by

61. Scrum. Встречи (Meetings)

1-3 часа
Ретроспективное совещание (Retrospective meeting) проводится после
завершения спринта:
Члены команды высказывают своё мнение о прошедшем спринте
Отвечают на два основных вопроса:
Что было сделано хорошо в прошедшем спринте?
Что надо улучшить в следующем спринте?
Выполняют улучшение процесса разработки (решают вопросы и
фиксируют удачные решения).
it-courses.by

62. процесс

it-courses.by

63. Сравнение моделей разработки ПО

Модель
Преимущества
Недостатки
Тестирование
Waterall
У каждой стадии есть
чёткий проверяемый
результат.
В каждый момент
времени команда
выполняет один вид
работы.
Хорошо работает для
небольших задач.
Полная
неспособность
адаптировать проект
к изменениям в
требованиях
Крайне позднее
создание
работающего
продукта
С середины проекта
Максимальное вовлечение заказчика.
Много работы с
требованиями
Тесная интеграция
тестирования и
разработки
Минимизация
документации
Сложность
реализации для
больших проектов
Сложность
построения
стабильных
процессов
В определённые
моменты итераций
и в любой
необходимый
момент
Agile
it-courses.by

64. Waterfall and Agile

it-courses.by

65. Waterfall and Agile

it-courses.by

66. Scrum. Расширение

it-courses.by