Похожие презентации:
Тестирование и его связь с жизненным циклом ПО
1. Занятие 2
Тестирование и его связьс жизненным циклом ПО
2. Цикл разработки ПО
Цикл (процесс) разработки ПО(software development life cycle) – это путь от идеи до поддержки
готового продукта. Чем более отлажены каждая из стадий цикла и
координация между ними, тем эффективнее работает компания, тем
выше качество и тем счастливее пользователи/клиенты.
it-courses.by
3. Жизненный цикл ПО
Формирование и анализ требований
Проектирование
Реализация
Тестирование продукта
Внедрение
Эксплуатация и сопровождение
it-courses.by
4. Когда начать тестировать?
it-courses.by5. Формирование и анализ требований
Тестирование требований на вменяемость/ осуществимость
Тестирование функциональной спецификации
Выделение модулей приложения
Обдумывание предварительных тестовых сценариев на основе
требований
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.by12. Эвристики
Эвристики – это способы решения проблемы или принятия решения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.by25. Модель разработки ПО
Структура, систематизирующаяразличные виды проектной
деятельности, их взаимодействие
и последовательность в процессе разработки ПО.
Выбор той или иной модели зависит от масштаба и сложности
проекта, предметной области,
доступных ресурсов
и множества других факторов.
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.by33. Waterfall. Принципы
Переходит от одной стадии
к другой строго последовательно
Нельзя приступить к следующему
этапу, пока полностью и
исчерпывающе не сделан
текущий
Тестирования
подключается с середины
Переходов назад,
вперёд или
перекрытия фаз - Нет
it-courses.by
34. Agile
Гибкая методология разработки (англ. гибкий) –серия подходов к разработке ПО,
ориентированных на использование
итеративной инкрементальной разработки,
динамическое формирование требований
и обеспечение их реализации
в результате постоянного взаимодействия
внутри самоорганизующихся рабочих групп,
состоящих из специалистов различного профиля
it-courses.by
35. Итеративный подход
Итеративный подход (англ. повторение) в разработке ПО –это выполнение работ параллельно с непрерывным анализом
полученных результатов и корректировкой предыдущих этапов
работы.
it-courses.by
36. Инкрементальный подход
Инкрементальный подход (англ. увеличение) в разработке ПО –это постепенное прирощение (увеличение) функционала небольшими
частями от релиза к релизу
it-courses.by
37. Маленький, но жизнеспособный
it-courses.by38. Наглядно
it-courses.by39. 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.by49. Scrum. Основные понятия
Резерв Проекта (Product backlog) - это список требований кфункциональности, упорядоченный по их степени важности, подлежащих
реализации. Элементы этого списка называются «пожеланиями
пользователя» (user story) или элементами резерва (backlog items)
Зачастую история имеет следующую структуру:
«Будучи пользователем <тип пользователя> я хочу сделать <действие>,
чтобы получить <результат>»
Резерв проекта открыт для редактирования для всех участников скрам
процесса
it-courses.by
50. Scrum. Основные понятия
Резерв спринта (Sprint backlog) - содержит функциональность,выбранную владельцем проекта из резерва проекта.
Все функции разбиты по задачам, каждая из которых оценивается
скрам-командой.
Каждый день команда оценивает объем работы, который нужно
проделать для завершения спринта.
it-courses.by
51. Scrum. Процесс
it-courses.by52. 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.by56. 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.by63. Сравнение моделей разработки ПО
МодельПреимущества
Недостатки
Тестирование
Waterall
У каждой стадии есть
чёткий проверяемый
результат.
В каждый момент
времени команда
выполняет один вид
работы.
Хорошо работает для
небольших задач.
Полная
неспособность
адаптировать проект
к изменениям в
требованиях
Крайне позднее
создание
работающего
продукта
С середины проекта
Максимальное вовлечение заказчика.
Много работы с
требованиями
Тесная интеграция
тестирования и
разработки
Минимизация
документации
Сложность
реализации для
больших проектов
Сложность
построения
стабильных
процессов
В определённые
моменты итераций
и в любой
необходимый
момент
Agile
it-courses.by