1. ЖИЗНЕННЫЙ ЦИКЛ ПО
1.1. Идея
1.2. Формирование и анализ требований
1.2.1. На этом этапе необходимо подумать о требованиях и протестировать требования. А именно протестировать требования на вменяемость и осуществимость. Подумать о функциональной специфике. Обдумать предварительные тестовые сценарии на основе тех требований что уже есть
1.2.1.1. С этого этапа тестировщик уже может подключаться к работе
1.3. Проектирование
1.3.1. Можно протестировать/создать тест план. Протестировать какие-то доки которые описывают архитектуру продукта
1.4. Реализация (когда разрабы пишут код)
1.4.1. Тесты результатов итераций. Регрессионное тестирование
1.5. Тестирование продукта
1.5.1. Полный тест готового продукта. Приемочное тестирование
1.6. Внедрения
1.6.1. Протестировать совместимость продукта с существующей инфраструктурой заказчика. Посмотреть какие сервера, какое окружение. Сбор обратной связи
1.7. Эксплуатация и сопровождение
1.7.1. Обработка отчетов об ошибках от пользователей во время эксплуатации.
1.8. Прекращение тестирования
1.8.1. Вышло время
1.8.2. Слишком много ошибок, что продолжать тестировать не имеет смысла
1.8.3. Когда задание выполнено
1.8.4. Отмена задания
1.8.5. Зашли в тупик. Из-за отсутствия, к примеру, какой-то информации
1.8.6. Нужно передохнуть. Человек может устать
1.8.7. Когда в тест плане было обозначено количество тестов
2. ТЕСТИРОВАНИЕ ТРЕБОВАНИЙ Это позволяет снизить трудоемкость и сроки реализации всего тестирования. К тому же могут быть неполные требования, неправильные требования. Двоякие требования. Например один разраб понял так , а другой разраб понял так, а тестировщик вообще проверял совсем другое. Это позволяет трудоемкость снизить, сроки реализации продукта снизить
2.1. ПРОБЛЕМЫ
2.1.1. Требования непонятные
2.1.1.1. Сорвались сроки
2.1.2. Неполные требования
2.1.2.1. Будет сделано не то, что нужно
2.1.3. Требования часто изменяются
2.1.3.1. Сделано не то, что нужно было или команда не знает, что делается сейчас
2.1.4. Требования неверно трактуются
2.2. КАКИЕ БЫВАЮТ ТРЕБОВАНИЯ
2.2.1. Прототипы, дизайн
2.2.2. software requirements specification (Спецификая)
2.2.3. User Story Мне как потребителю нужен крупнейший магазин книг где я могу купить любую книгу в любое время
2.2.4. User Case
2.2.4.1. Действующие лица (администратор)
2.2.4.2. Цель (изменить статус учетной записи пользователя на активную)
2.2.4.3. Предисловие (учет запись пользователя неактивна)
2.2.4.4. Успешный сценарий Шаг1. Админ выбирает пользователя и активирует разблокировать Шаг2. Система переключает учет.запись в статус активный и отправляет сообщение пользователю на мыло.
2.2.5. Текстовое описание
2.2.6. Требования озвучены голосом (например кто-то на митинге озвучил голосом, все согласились, а потом об этом забыли)
2.3. ХАРАКТЕРИСТИКИ ДЛЯ ТРЕБОВАНИЙ
2.3.1. Полнота (завершенность) Если в требовании что-то говорится, то оно должно полностью описывать то, что оно описывает. Например: Поменять анимацию. Анимацию чего? Какую анимацию? Где?
2.3.2. Недвусмысленность
2.3.3. Непротиворечивость
2.3.4. Реализуемость
2.3.5. Тестируемость
2.3.6. Необходимость
3. ВИДЫ ТЕСТИРОВАНИЯ
3.1. ПО ОБЬЕКТУ ТЕСТИРОВАНИЯ
3.1.1. Функциональное
3.1.1.1. Функциональное тестирования
3.1.1.1.1. (функции сервиса)
3.1.1.2. Тестирования GUI
3.1.1.2.1. (Графический интерфейс пользователя) элементы интерфейса, какой-то hover
3.1.1.3. Тестирование безопасности
3.1.2. Нефункциональное
3.1.2.1. Тестирование интерфейса
3.1.2.1.1. (цвет, размер) UI
3.1.2.2. UX
3.1.2.2.1. (user usability) Удобства того чем вы пользуетесь
3.1.2.3. Локализация
3.1.2.3.1. (текст например) не должно быть ошибок например Региональные особенности (сайт на нескольких языках)
3.1.2.4. Конфигурационное
3.1.2.4.1. (например запуск сервиса на каком-то устройстве) Запустится ли на андроиде или на каком-то компьютере
3.1.2.5. Тестирование совместимости
3.1.2.5.1. совместимость с разными браузерами, совместимость устройства с различной периферией (со смарт часами или наушниками)
3.1.2.6. Тестирование инсталляционное
3.1.2.6.1. Например если работа не с веб, а с ОС какой-то. То есть можно без проблем установить сервис, использовать, удалить.
3.1.2.7. Тестирование производительности
3.1.2.7.1. нагрузочное тестирование, тестирование стабильности. Чтобы сервер не упал к примеру
3.1.2.8. Тестирование помехоустойчивости
3.1.2.8.1. К примеру тест игры на телефоне и произошел звонок. По идем игра должна свернуться, поговорить по телефону и вернуться без проблем в игру.
3.1.2.9. Тестирование документации
3.2. ПО СТЕПЕНИ АВТОМАТИЗАЦИИ
3.2.1. Ручное
3.2.2. Автоматизированное
3.3. ПО МЕТОДУ отличается от уровня доступа к коду
3.3.1. Черный ящик
3.3.1.1. Нет понятия , что происходит на стороне кода
3.3.2. Белый ящик
3.3.2.1. Полный доступ. Я понимаю, что происходит в коде и могу изменить код самостоятельно
3.3.3. Серый ящик
3.3.3.1. Какой-то доступ есть
3.4. ПО КРИТЕРИЮ ИЗМЕНЕНИЙ
3.4.1. Смоук тесты
3.4.1.1. Например сайта auto.ria К примеру создали новый раздел (авто). Минимально просмотреть что дали и выполняются ли основные функции. В таком случае смоук тест выполнен и можно брать в работу то, что дали.
3.4.2. Регрессионное тестирование
3.4.2.1. К примеру протестировали сервис авто и добавился новый сервис (доставка). Он работает, но надо снова протестировать авто на предмет того, что могло что-то поломаться в нем после добавления нового сервиса.
3.4.3. Тестирование билда (сборка продукта)
3.4.3.1. Полное тестирование продукта
3.4.4. Санитарное тестирование
3.4.4.1. Тестирование какой-то маленькой штучки, какого-то бага который был и затем исправили.
3.5. ТЕСТИРОВАНИЕ ПО УРОВНЯМ
3.5.1. Модульное тестирование (module testing)
3.5.1.1. Тестируется целый раздел (модуль)
3.5.2. Интеграционное тестирование (integration testing)
3.5.2.1. Взаимодействие между разделами (модулями). Например игра и очки как-то между ними перебрасываются
3.5.3. Системное тестирование (system testing)
3.5.3.1. К примеру настало время проверить все модули и взаимодействие между ними
3.5.4. Уровень критического пути
3.5.4.1. авто - мерседес - год - цена - показать телефон
4. МЕТОДОЛОГИЯ РАЗРАБОТКИ нужна для того, чтобы работа была структурирована и у всех сотрудников было понимание, что они делают, как они работают и за каким этапом оно идет.
4.1. Waterfall (каскадная модель или модель водопада)
4.1.1. В этой модели весь процесс выглядит как поток, который последовательно проходит фазы.
4.1.1.1. Проектирование
4.1.1.2. Дизайн
4.1.1.3. Кодирование
4.1.1.4. Тестирование
4.1.1.5. Поддержка
4.1.2. При таком методе тестирование подключается с середины процесса.
4.1.3. Мы переходим к следующей стадии строго последовательно. Нельзя приступить к след. этапу пока полностью не завершиться предыдущий этап.
4.2. AGILE
4.2.1. Scrum Гибкая методология (когда говорят о Agile, то чаще всего подразумевают Scrum)
4.2.1.1. ИТЕРАТИВНЫЙ ПОДХОД
4.2.1.1.1. Когда идет работа и параллельно с этим идет непрерывный анализ результатов работы. Таким образом можно скорректировать предыдущие этапы работы.
4.2.1.2. ИНКРЕМЕНТАЛЬНЫЙ ПОДХОД
4.2.1.2.1. Продукт увеличивается поэтапно. Сперва маленький функционал (базовый), затем функционала становится больше. Например какая-то игра с каждый обновлением становится все больше и больше
4.2.1.3. СПРИНТ (понятие)
4.2.1.3.1. Все строится на том, что процесс разработки происходит в жесткие, фиксированные сроки. Результатом каждого спринта должен быть конечный результат который можно показать.
4.2.1.4. БЭКЛОК ПРОДУКТА
4.2.1.4.1. Это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней.
4.2.1.5. ЕЖЕДНЕВНЫЕ МИТИНГИ
4.2.1.5.1. Что сделана с момента пред. ежеднев. совещания?
4.2.1.5.2. Что будет сделано с момента текущего совещания до след совещания?
4.2.1.5.3. Какие проблемы мешают достижения цели спринта
4.2.1.6. SPRINT REVIEW MEETING
4.2.1.6.1. Нужно подвести итоги завершения спринта
4.2.1.7. РЕТРОСПЕКТИВА
4.2.1.7.1. Высказывание своего мнения о завершенном спринте Отвечают в основном на 2 вопроса: 1) Что было хорошо сделано в предыдущем спринте 2) Что надо улучшить в след.спринте
4.2.2. AGILE MANIFEST
4.2.2.1. Люди и взаимодействия, важнее процессов и инструментов
4.2.2.2. Работающий продукт, важнее полной документации
4.2.2.3. Сотрудничество с заказчиком важнее условий контракта
4.2.2.4. Готовность к изменениям, важнее чем следование первоначальному плану
4.2.3. Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. ... Эджайл и скрам помогают организовать процесс работы в команде так, чтобы выпускать интересный пользователю продукт регулярно и часто.