Прошлая часть: Жизненный цикл ПО и роль тестировщика в нем
И снова здравствуйте.
В прошлой части мы разобрали «кто такие тестировщики» и «этап тестирования в жизненном цикле ПО». Теперь мы разберем роль тестировщика в еще одной популярной методологии разработки ПО – Agile (гибкая методология). Почему мы это сделаем? Да по причине того, что она более ярко описывает фактические обязанности тестировщика и показывает, как инженер по тестированию задействован в каждом из этапов ЖЦ. «Что делается?» проще понять если понимать «Зачем это делается?» Итак, определение Agile или гибкой методологии из интернета:
Agile - обобщающий термин для целого ряда подходов и практик, основанных на ценностях «Манифеста гибкой разработки программного обеспечения» и 12 принципах, лежащих в его основе.
Выделяют 4 основные ценности Agile:
· Приоритет людей и взаимодействия перед инструментами и процессами.
· Работающий продукт важнее доскональной документации.
· Взаимодействие с заказчиком полезнее точного соблюдения условий договора.
· Готовность к переменам эффективнее слепого следования изначальному плану.
Снова «ничего не понятно, но очень интересно». По запросу Agile вы найдете в поисковиках что-то вроде этого:
Если простыми словами – ребята, работающие по гибким методологиям, якобы «За всё хорошее, против всего плохого». И с людьми они взаимодействовать хотят (но инструментами всё еще пользуются и частенько долго их выбирают), и хотят качественное ПО больше, чем писать документацию (как будто в каскадной методологии всем так нравится печатать документацию), и к переменам они готовы…
Почему же эту методологию применяют:
- Бизнес хочет прибыль. Желательно, чтобы она была «еще вчера». Если продукт выпустить на рынок в виде минимальной жизнеспособной версии (Minimal Viable Product или MVP) – вы можете обогнать конкурентов, даже сделав функциональность не в полном объеме.
- Не каждый продукт должен быть досконально протестирован. Если у одного из ста тысяч пользователей в специфической ситуации зависнет приложение по доставке продуктов из магазина – никто не умрёт (воспринимайте слово «умрёт» буквально).
- Работа в коротких временных циклах и над меньшими по объему задачами - удобнее. Аналитик лучше помнит свои требования двухнедельной давности, чем трёхмесячной. Разработчик лучше помнит код, который писал 2 недели назад, а не месяц.
В чем отличие от каскадной методологии
Если в каскадной методологии каждый этап шел строго за предыдущим, то в Scrum (методика управления проектами, основанная на принципах Agile) всё немного иначе. Проще будет изобразить ту же картинку на шкале времени:
Большой отрезок времени разбивается на маленькие, в рамках которых итеративно будет происходить разработка нового функционала и доработка старого. Эти отрезки времени называют «спринты». Обычно они длятся в районе 2-4 недель и, по итогу спринта, получается конкретная версия программного обеспечения – релиз.
Как видно с картинки – теперь вся команда в рамках спринта взаимодействует как единое целое. На примере спринта №2 рассмотрим кто чем занят из команды разработки (на примере основных активностей):
Системный аналитик:
- Проводит аналитику и формирует требования по задачам, которые на него запланировали в начале спринта №2, чтобы разработчик их взял в работу в спринте №3.
- Консультирует разработчика и уточняет требования по задачам, которые разработчик не успел завершить в спринте №1.
- Консультирует разработчика и уточняет требования по задачам, по которым он пишет код в спринте №2.
- Консультирует тестировщика и уточняет требования по задачам, которые тестировщик не успел протестировать в спринте №1.
- Консультирует тестировщика и уточняет требования по задачам, которые тестировщик начал тестировать в спринте №2.
- Анализирует совместно с бизнесом обратную связь от пользователей по результатам доработок из спринта №1.
Разработчик:
- Пишет код по задачам, которые на него запланировали в начале спринта №2.
- Консультирует тестировщика по нюансам тестирования задач, которые тестировщик не успел протестировать в спринте №1.
- Консультирует тестировщика по нюансам тестирования задач, которые тестируются в спринте №2.
- Исправляет дефекты по задачам, которые тестировщик не успел протестировать в спринте №1.
- Исправляет дефекты по задачам, которые были переданы в тестирование в спринте №2.
- Иногда экстренно готовит хот-фиксы по результатам внедрения релиза из спринта №1.
Тестировщик:
- Уточняет требования у системного аналитика по задачам, которые не успел протестировать в спринте №1.
- Консультируется с разработчиком по нюансам тестирования задач, которые тестировщик не успел протестировать в спринте №1.
- Тестирует задачи, которые не успел протестировать из спринта №1, попутно заводя дефекты.
- Уточняет требования у системного аналитика по задачам, которые на него запланировали в тестирование в спринте №2.
- Консультируется с разработчиком по нюансам тестирования задач, которые на него запланировали в тестирование в спринте №2.
- Тестирует задачи, которые на него запланировали в тестирование в спринте №2, попутно заводя дефекты.
- Перепроверяет исправленные дефекты.
- Участвует в локализации проблем, возникающих в результате внедрение релиза из спринта №1.
Инженер по сопровождению:
- Участвует / проводит приемо-сдаточные испытания версии релиза (ПСИ или может встретиться аббревиатура UAT - User Acceptance Testing), который получился в результате работы команды в спринте №1.
- Устанавливает релиз в промышленную эксплуатацию.
- Участвует в разборе проблем, которые возникают при установке / эксплуатации релиза спринта №1.
- Занимается мониторингом работы релиза спринта №1 в промышленной эксплуатации.
Для понимания «чем будет заниматься команда в спринте №3» - в каждом из пунктов, перечисленных ранее, прибавьте единицу ко всем номерам спринтов.
«Что нам даёт эта картина?» спросите вы. Во-первых, мы видим какие коммуникации происходят между членами команды разработки. Во-вторых, мы видим, что работа тестировщика не ограничивается лишь тем, что проводится тестирование программного обеспечения. Тестировщик еще прикладывает руку к тестированию требований, работе с дефектами, локализации проблем в промышленной эксплуатации и целой куче коммуникаций с коллегами по команде. На самом деле активностей гораздо больше, но для общего понимания нам пока что хватит.
Внимательный читатель задастся вопросом «Если Scrum так хорош и дает столько плюсов – почему же его не используют везде». Это хороший вопрос, и я вскользь уже отвечал на него. Например, вы не можете сделать MVP программного обеспечения для какого-то медицинского оборудования или ПО для управления самолетом, потому что результатом такого MVP могут быть крайне страшные последствия. И для определенного ПО лучше подойдет разработка по каскадной методологии, т.к. в требованиях будут учтены все возможные нюансы перед этапом написания кода. Но есть программное обеспечение, где такие жесткие согласования не обязательны и ПО осознанно могут установить в промышленную эксплуатацию, зная о некритичных проблемах в нём, ведь эти проблемы будут исправлены уже в следующем спринте.
Следующая часть: Требования и тестирование требований
Поддержать или поблагодарить можете:
Лайком;
Комментарием;
Подпиской на канал;
#Блог_тестировщика #QA #Тестирование_ПО #Тестирование_с_нуля
