Модели разработки и тестирование требований Flashcards
Какие знаешь модели разработки?
Каскадная (Водопад) - последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей.
V-модель - подобие Каскад, только тестирование идет одновременно со стадией разработки.
Инкрементная (создание по кусочкам) - базовый функционал на первом этапе, а затем последовательное добавление новых функций.
RAD-модель - быстрая разработка приложения. Компоненты параллельно разрабатываются несколькими командами, а затем соединяются в один рабочий прототип. Временные рамки одного цикла строго ограничены.
Agile-модель (гибкая) - после каждой итерации заказчик может наблюдать результат и понимать удовлетворяет он его или нет.
Итеративная/Итерационная модель - реализация функционала по частям с последующей доработкой. Сначала набросок, затем уточнение.
Спиральная модель - как инкрементная по кусочкам, но анализ рисков обязателен.
В чем отличие водопадной модели от agile?
Каскадная (Водопад) - последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей.
Agile-модель (гибкая) - после каждой итерации заказчик может наблюдать результат и понимать удовлетворяет он его или нет.
Какие знаешь agile церемонии?
Планирование спринта
Участники: команда разработчиков, мастер Scrum , владелец продукта
Когда: в начале спринта.
Продолжительность: обычно час в неделю итерации, например двухнедельный спринт начинается с двухчасовой встречи по планированию.
Agile фреймворк (структура): Scrum. (Команды Kanban также планируют, конечно, но у них нет фиксированного графика итераций с формальным планированием спринта)
Цель (намерение): планирование спринта настраивает всю команду на успех на протяжении всего спринта. Приходя на встречу, владелец продукта будет иметь приоритетный бэклог (отставание) продукта.
Обсуждается каждый пункт с командой разработчиков, и группа коллективно оценивает прилагаемые усилия. Затем команда разработчиков сделает прогноз спринта с указанием объема работы, которую команда может выполнить из списка необходимых требований (backlog). Этот объем работы становится списком необходимых требований (backlog) спринта.
Ежедневные летучки (stand up)
Участники: команда разработчиков, мастер Scrum, владелец продукта
Когда: один раз в день, обычно утром.
Продолжительность: не более 15 минут.
Agile подход : Scrum и Kanban.
Цель (Намерение): Летучка предназначена для быстрого информирования всех о том, что происходит в команде. Каждый член команды ответит на следующие вопросы: Что я закончил вчера?Над чем я буду работать сегодня?
Я заблокирован чем-нибудь?
В отчете о том, какую работу вы выполнили вчера перед своими сверстниками, существует неявная ответственность. Никто не хочет быть членом команды, который постоянно делает одно и то же и не прогрессирует.
Итерационное ревью
Присутствовавшие: команда разработчиков, мастер Scrum , владелец продукта и могут присутствовать заинтересованные стороны проекта
Когда: в конце спринта или вехи.
Продолжительность: 30-60 минут.
Agile подход: Scrum и kanban. Как и при планировании, обзор для команд kanban должен быть согласован с основными этапами работы команды, а не с фиксированным ритмом.
Цель (Намерение): Итерационный обзор - это время, чтобы продемонстрировать работу команды. Они могут быть в обычном формате, таком как «демо пятницы», или в более формальной структуре собраний. Это время для команды, чтобы отпраздновать свои достижения, продемонстрировать работу, завершенную в течение итерации, и получить немедленную обратную связь от заинтересованных сторон проекта. Помните, что работа должна быть полностью наглядной и соответствовать качественной шкале команды, которую следует считать завершенной и готовой для демонстрации в обзоре.
Ретроспектива
Участники: команда разработчиков, мастер Scrum, владелец продукта
Когда: в конце итерации.
Продолжительность: 60 минут.
Agile подход: Scrum и Kanban. Scrum-команды делают спринт-ретроспективу, основанную на фиксированном ритме. Kanban команды также могут извлечь выгоду из случайных ретроспектив.
Цель (Намерение): помогают команде понять, что работает хорошо, а что нет.
Ретроспективы используются, чтобы выяснить, что работает, чтобы команда могла продолжать сосредотачиваться на этих областях, что не работает, и используют время, чтобы найти креативные решения и разработать план действий.
Непрерывное улучшение - это то, что поддерживает и стимулирует развитие в Agile команде, и ретроспективы являются ключевой частью этого.
Чем отличается scrum и kanban?
scrum:
Одна универсальная команда
Время делится на Спринты(отрезки)
Число задач ограничено общим весом
Измерение показателей по общему весу задач за Спринт - следят за повышением производительности.
Итерация - 2 недели
kanban:
Может быть несколько узкопрофильных команд
Итерация может быть любой длины
Число задач ограничено весом по каждому статусу отдельно
Измерение показателей по среднему времени прохождения задачи по доске - время выполнения должно быть минимальным.
Что знаешь о жизненном цикле ПО?
Жизненный цикл разработки ПО (SDLC):
1. Сбор и анализ требований
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
2. Документирование требований
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
3. Дизайн
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
4. Разработка ПО
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
99% заказчиков ошибаются именно в этом месте. В ходе разработки клиент отклоняется от оговоренного тз и хочет добавить ещё фич в продукт. В результате вместе с ростом скопа фич, увеличиваются сроки и бюджет на разработку, деньги заканчиваются, а готово только 50% продукта.
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
5. Тестирование
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
6. Внедрение и поддержка
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т.д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Что такое требование?
Описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.
Какие бывают требования?
Функциональные - что система должна делать.
Нефункциональные - Иначе говоря, как будет работать система и почему именно так.
Как будешь тестировать программу, если для продукта нет документации?
Если нет (или мало) стандартных документов (требований, спецификаций, описаний функций), что бывает если руководство слишком фанатично соблюдает эджайл или в небольших командах, тестировщики пользуются “подручными средствами”.
- Самостоятельное изучение продукта
- Стандарные методики черного ящика
- Попробовать сформулировать из косвенных источников, то есть так называемых неявных требований (регламентов, старых тестовых данных, и так далее)
- Предыдущие версии приложения
- Старое доброе ад-хок-тестирование
- А также плотнее работают с разработчиками и бизнес-аналитиками.
Чем отличаются функциональные и нефункциональные требования?
Функциональные:
Бизнес-требования. Что система система должна делать с точки зрения бизнеса(заказчика).
Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы.
Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
Нефункциональные:
Бизнес-правила. Они определяют почему система работать должна именно так, как написано.
Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами.
Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
легкость и простота использования (usability)
производительность (performance)
удобство эксплуатации и технического обслуживания (maintainability)
надежность и устойчивость к сбоям (reliability)
взаимодействия системы с внешним миром (interfaces)
расширяемость (scalability)
требования к пользовательским и программным интерфейсам (user and software interface).
Что ты проверяешь, когда тестируешь требования?
Завершённость
Атомарность
Непротиворечивость
Недвусмысленность
Выполнимость
Обязательность и актуальность
Прослеживаемость
Модифицируемость
Проранжированность
Корректность и проверяемость
Какие используешь техники тестирования требований?
Взаимный просмотр
Вопросы
Тест-кейсы и чек-листы. Хорошее требование — проверяемое.
Исследование поведения системы. Тестированию подвергается набор требований.
Рисунки (графическое представление)
Прототипирование. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется, что реализованное в прототипе (возможно, с небольшими доработками) устраивает заказчика.
Почему важно тестировать требования?
- экономят деньги при изменении требований;
- позволяют понять, что и с соблюдением каких условий система должна делать;
- предоставляют возможность оценить масштаб изменений и управлять изменениями;
- являются основой для формирования плана проекта, в том числе плана тестирования;
- помогают предотвращать или разрешать конфликтные ситуации;
- упрощают расстановку приоритетов в наборе задач;
- позволяют объективно оценить степень прогресса в разработке проекта
