[Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений] Стратегия тестирования краткосрочного проекта
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
За пять лет работы в «Аркадии» — компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, — мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая — с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.Небольшие проекты у нас скорее редкость, и к ним не очень подходят стратегия и тактика тестирования, применяемые для длительных проектов. В этой статье я расскажу, как составляю стратегию тестирования в краткосрочных проектах и внедряю её на практике.Как всё начинаетсяИногда к нам обращаются заказчики, которым нужно быстро разработать небольшой программный продукт. Например, новый сайт или приложение для смартфонов. Работы по такому проекту не очень много, и всё должно быть готово через несколько месяцев.У заказчика есть представление о будущих пользователях и какая-то основа для проекта. В роли такой основы может выступить старый сайт — он долго служил верой и правдой, но сейчас устарел. Пользоваться с мобильных устройств им неудобно, а ведь именно с них, судя по имеющейся у заказчика статистике, идёт большая часть пользовательского трафика. Десктопной версией сайта фактически пользуются только администраторы, наполняющие его контентом.Поэтому заказчик хочет перевести мобильных пользователей на нативное приложение, содержащее основные возможности для пользователей. Функции, нужные только для контент-менеджеров, будут доступны в десктопной версии сайта.Или другой пример. Есть работающий сайт, который заказчика устраивает. К сайту заказчик хочет разработать мобильное приложение, в которое нужно добавить несколько небольших новых фич.Вся эта основа для проекта попадает к нашей команде. На краткосрочных проектах она невелика и состоит из менеджера проекта, двух-трёх программистов, UX/UI-дизайнера и тестировщика.Когда и как начинается тестированиеТестирование на краткосрочном проекте начинается с “Shift left”, то есть со «сдвига тестирования влево» относительно традиционного места в хвосте производственной цепочки, состоящей из определения требований, анализа и проектирования, кодирования, тестирования и развертывания.Принцип “Shift left” заключается в том, чтобы начинать тестирование не в конце процесса разработки, а с его ранних этапов: тестирования концепции, требований и документации.
Источник картинки: https://devopedia.org/shift-left Ниже приведён набор вопросов, который поможет тестировщику сориентироваться на старте краткосрочного проекта.Вопросник: тестирование концепции Целевая аудитория и условия использования ПО Что выясняем Пример Откуда берём информацию Что за программный продукт мы делаем? Краткое описание продукта? Основные функции? Приложение с упражнениями по английской грамматике, 5 упражнений в деньОпрашиваем заказчика Для кого разрабатываем продукт? Кто целевая аудитория приложения? Для школ. Ученики 5-9 классовВ каких условиях будут пользоваться будущим ПО? Типы устройств? Тип подключения к сети? С мобильных устройств, стабильный Wi-Fi в классе Материальная база тестирования — на чём тестируем Что выясняем Пример Откуда берём информацию ПлатформыiOS
Android
Windows Определяется из ответов заказчика на предыдущие вопросы + смотрим статистику по целевой аудитории Операционные системы (конкретные) iOS versions
iOS 13
iOS 12 Android OS versions
Pie
10
Oreo Устройства, на которых должно работать ПО (список устройств) iPhone ..
Samsung Galaxy ..
Huawei .. Интеграция с тем, что уже есть Что выясняем Пример Откуда берём информацию Системы, с которыми приложение должно интегрироватьсяАккаунт на десктопной версии сайтаКоманда заказчика, технические специалисты, документация по системам, тестирование системСпособы и инструменты для проверки того, что ничего и нигде не было потеряноAPI Опросив заказчика и изучив основу проекта, мы получаем детальное представление о концепции того софта, который нужно разработать. Всё это заносится в трекер задач и в вики проекта.Тестирование требованийПосле того как концепция проекта сложилась, мы переходим к тестированию требований. Откуда эти требования вообще берутся? У нас они приходят от заказчика, фиксируются менеджером проекта и сразу идут в работу. Поэтому тестирование требований идёт параллельно с тем, как программисты пишут код, а UX-дизайнер разрабатывает прототип. Задача тестировщика на этом этапе — создать максимально целостное и непротиворечивое описание продукта и его работы. То есть описать ожидаемое поведение.Описывая ожидаемое поведение, тестировщик закладывает базу для чек-листов, выявляет противоречия и пустые места. А затем находит ответы, задавая вопросы программистам и заказчику. Так мы отлавливаем часть багов ещё до того, как софт попадает на проверку. Иногда даже до того, как программист напишет код. Тестировщик берёт требования в том виде, в котором они есть. Допустим, это будут user stories (пользовательские истории).1. User storyUser story (пользовательская история) состоит из заголовка, представляющего собой основной сценарий использования и дополнительных сценариев с конкретикой. Схема User story : As a <role> I want <functionality> so that <benefit> Как <роль>, я хочу <функциональность>, чтобы <получить выгоду / достичь цели> Пример User story : Как пользователь, я хочу иметь доступ к упражнениям с 9 утра до 9 вечера Дополнительные сценарии могут быть описаны в критериях приёмки (acceptance criteria). О том, как их можно конкретизировать, я расскажу позже.Acceptance Criteria Acceptance Criterion 1 Как пользователь, я могу просматривать упражнения дня с 9 утра до 9 вечера Acceptance Criterion 2 Как пользователь, я могу создавать ответы на упражнения дня с 9 утра до 9 вечера Acceptance Criterion 3 Как пользователь, я могу редактировать ответы на упражнения дня с 9 утра до 9 вечера Acceptance Criterion 4 Как пользователь, я могу отправлять ответы на упражнения дня на проверку с 9 утра до 9 вечера 2. Глоссарий проектаПоскольку пользовательские истории пишутся человеческим, а не техническим языком, важно удостовериться, что:а) понятия, упомянутые в истории, понимаются одинаково всеми участниками разработки. Например, под словом «упражнения» команда разработки и заказчик имеют в виду одно и то же;б) если в описании одного явления используются синонимы — например, «упражнения», «домашняя работа», «задания» — то речь идёт об одном и том же явлении. И тут нам поможет составление глоссария проекта. Используя контент-анализ, я смотрю по текстам пользовательских историй, какие синонимы используются для обозначения одного явления. Выписываю их себе в табличку-глоссарий. Потом сверяю своё понимание слов с таким же у заказчика и программиста, который уже взял задачу. Пример глоссария Понятие и все слова, которыми мы обозначаем это понятие Определение понятия Пример Упражнения, набор упражнений, задание, домашняя работа Набор упражнений, которые учащийся должен сделать за день (с … по …) 5 упражнений по грамматике до 23:59 в данном часовом поясе 3. Умолчания и дополненияПосле того как с определением понятий мы разобрались, время переходить к восстановлению умолчаний и сокращений. В обычной коммуникации люди редко используют такие тяжеловесные предложения, а в тестировании оно пригождается.Исходный текст с умолчаниями Умолчания восстановлены «меняем в админке» «меняем в админка-тесты-курс-семестр-тест-папка с настройками-xml» «атрибут А» «атрибут А класса Б» После восстановления умолчаний задаём вопросы для получения дополнительной информации:Понятие и все слова, которыми мы называем понятие Определение понятия Пример Вопросы Упражнения, набор упражнений, задание, домашнее задание Набор упражнений, которые учащийся должен сделать за день Ежедневные упражнения по грамматике, которые должны быть сданы сегодня До какого точно времени учащийся должен отправить задания? Сколько упражнений в ежедневном наборе? 4. Acceptance Criteria — основа для чек-листаТестируя требования таким образом, мы получаем двойную выгоду: а) конкретизируем Acceptance Criteria; б) закладываем основу для чек-листа. Далее переходим к созданию основы чек-листа. На этом этапе выкидываем обороты типа «система должна…» и «также ожидаемо…» и «отжимаем» текст от «воды» до списка требований по пунктам.Исходный текст Текст без «воды» Система должна давать учащимся возможность выполнять упражнения ежедневно во временной промежуток с 9 утра до 9 вечера - упражнения доступны с 9:00 утра до 9:00 вечера - упражнения недоступны с 9:01 вечера до 8:59 утра Таким образом я обрабатываю как позитивные, так и негативные требования — в том же порядке, в каком они встречаются в пользовательской истории. Потом сортирую: негативные требования идут в конец списка Acceptance Criteria, а позитивные — в начало.После того, как были конкретизированы Acceptance Criteria, переходим к тест-дизайну. Тест-дизайн и тестирование прототипаЗаголовок user story становится заголовком для группы проверок. Acceptance Criteria становится заголовком отдельного чек-листа или интеллект-карты, куда мы выписываем и ранжируем проверки.Что получается в результате Исходная User Story Чек-лист User story As a <role> I want <feature> So that <benefit> Как пользователь, я хочу иметь доступ к упражнениям с 9 утра до 9 вечера User role can do <> to get ... Пользователь имеет доступ к упражнениям с 9 утра до 9 вечера Acceptance Criterion 1 Given <initial context> When <event occurs> Then <ensure come outcomes> Checklist ... 1. Задания можно просмотреть с 9 утра до 9 вечера 2. Задания можно выполнить с 9 утра до 9 вечера 3. Ответы на задания можно отправить на проверку с 9 утра до 9 вечера 4. Ответы на задания можно отредактировать с 9 утра до 9 вечера 5. Задания недоступны для просмотра и выполнения с 9 вечера до 9 утра Создание тест-кейсов на краткосрочных проектах, как правило, нецелесообразно. Специфика тест-кейсов заключается в том, что это подробное описание шагов, ожидаемой реакции системы и конечного результата. Это полезно, когда продукт большой, сложный, разработка идёт долго, в команду регулярно приходят новые люди. Тогда тест-кейсы пригодятся при подключении к разработке новичков, а для старых сотрудников — при проверке сложной функциональности с неочевидными шагами.В краткосрочных проектах продукт небольшой, команда тоже, и всё очень быстро меняется. При использовании тест-кейсов слишком много времени уйдёт на их написание и поддержку. Их постоянно придётся переписывать, а времени и так мало. А вот чек-листы и интеллект-карты, по которым производится тестирование, — оптимальный выбор документации в условиях ограниченного времени.Пример интеллект-карты 
Источник картинки: автор статьиДля того, чтобы создать максимально эффективные проверки, при их разработке используем техники тест-дизайна. Например, разбиение на классы эквивалентности, анализ граничных значений, таблицы решений. В параллель с тем, как тестировщик пишет чек-листы, UX/UI-дизайнер создаёт прототип. Тестировщик проверяет интерфейс прототипа, корректирует чек-листы, обсуждает найденное с командой.Далее следует демо прототипа заказчику. По результатам демо команда собирает обратную связь, фиксирует полученную информацию в задачах в трекере и на страницах вики проекта. При необходимости прототип отправляется на доработку, после которой проводится повторное тестирование, демо и дальнейшая разработка программного продукта. Специфика тестирования в краткосрочном проектеВ краткосрочной разработке нет привычной нам рутины: «планирование спринта — спринт — демо — ретро», но есть промежуточные дедлайны. Однако есть пользовательские истории, описывающие функционал разного приоритета, который, согласно этим приоритетам, реализуется. Тестирование идёт параллельно с написанием кода.Чтобы начать тестирование продукта, нужно развернуть и настроить тестовое окружение, собрать и установить билд, подготовить необходимые тестовые данные. И только после того, как все эти шаги пройдены, тестировщик приступает к тестированию.Начинаем с позитивных кейсов. Мы хотим убедиться, что если пользователь делает всё как надо, он получает ожидаемый результат. Пример позитивного кейса <Пользователь может делать задания с 9:00 утра до 8:59 вечера> Затем мы проверяем негативные кейсы — «что у юзера ни в коем случае выйти не должно». Пример негативного кейса <Задания недоступны для просмотра и выполнения с 9:00 вечера до 8:59 утра> До релиза тестировщик проверяет как функционал, описанный в отдельных пользовательских историях, так и весь продукт целиком. Смотрит, корректно ли происходит установка, обновление, удаление продукта. Даёт обратную связь программистам, фиксирует баги в трекере, дорабатывает чек-листы.Баги в трекере наряду с чек-листами помогают поддерживать и сопровождать продукт. Заказчик знает, какие дефекты есть в продукте, и может выбрать, какие из них исправлять в первую очередь.Жизнь после релиза И вот наш продукт становится доступен конечным пользователям. От них приходят первые отзывы и первые баги. Это нормально, поскольку исчерпывающее тестирование на начальном этапе недостижимо, и какие-то ошибки всё равно будут. Специфика заказной разработки такова, что техподдержка находится со стороны заказчика, который и передаёт баги команде. Как правило, баги от пользователей не имеют подробного описания и требуют детального расследования. Задача тестировщика на этом этапе разработки — воспроизводить баги, пришедшие от пользователей, при необходимости привлекая к этому программистов, и тестировать фиксы, созданные программистами. Перепроверяя фикс, тестировщик добавляет проверки в чек-листы, углублённо тестирует функционал вокруг бага. Иногда таким образом тестировщик находит связанные баги, которые команда успевает починить до того, как их обнаружат пользователи. Обновлённые чек-листы, наряду с другой информацией, которую тестировщик заносил в трекер, в будущем сэкономит время команде, пришедшей на поддержку проекта, и позволит быстрее разобраться в проекте.Да и самому себе оставить памятку — дело нелишнее. Краткосрочность краткосрочностью, но иногда маленький проект становится основой большего. И через какое-то время использования софта приходит заказ на написание дополнительного функционала.ЗаключениеТестирование в небольшом проекте стартует одновременно с разработкой и начинается с определения целевой аудитории и условий использования ПО. На основе полученных данных команда определяется с устройствами, платформами и операционными системами для проверки продукта, продумывает интеграцию с существующими системами.Далее следует этап тестирования требований, во время которого тестировщик создаёт максимально целостное и непротиворечивое описание продукта и его работы. Здесь идёт работа с user story и acceptance criteria, на основе которых тестировщик составляет чек-листы и интеллект-карты со списком конкретных проверок.Следующими этапами тестирования будут: тестирование прототипа от UX/UI-дизайнера, тестирование отдельных функциональностей от программистов и тестирование готовых версий. Использование трекера задач на всех этапах проекта важно не только для длительного проекта, но и для краткосрочного, так как помогает поддерживать и сопровождать продукт, что особенно ценно при передаче проекта заказчику.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, JavaScript, Google Chrome, Тестирование веб-сервисов] Внедрение E2E-тестирования с Puppeteer и Jest
- [Тестирование IT-систем, Анализ и проектирование систем, ERP-системы] Опыт знакомства с MDM решением компании Юнидата (UniData)
- [Программирование, C++, Тестирование веб-сервисов, Конференции] Как достичь полной автоматизации в Automotive тестировании и особенности Move конструктора: узнаем 25 февраля
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Карьера в IT-индустрии] Инхаус, фриланс, аутсорс компания: куда приземлиться тестировщику, чтобы не разлюбить профессию и расти как на дрожжах
- [Тестирование веб-сервисов] Чек-лист тестирования WEB приложений
- [Информационная безопасность, Тестирование веб-сервисов] SQL-инъекции' union select null,null,null --
- [Тестирование IT-систем, Программирование, Тестирование веб-сервисов, Карьера в IT-индустрии] Перспективы разработчика в автоматизации тестирования ПО
- [Тестирование IT-систем] Как мы реализовали параллельный запуск Cucumber-сценариев на разных хостах
- [Разработка веб-сайтов, TDD, Тестирование веб-сервисов, ReactJS] Кому с Redux жить хорошо
- [Тестирование IT-систем, Производство и разработка электроники, Процессоры] Тестирование процессора Intel Core i9-11900K и анализ результатов PassMark
Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_testirovanie_vebservisov (Тестирование веб-сервисов), #_testirovanie_mobilnyh_prilozhenij (Тестирование мобильных приложений), #_zakaznaja_razrabotka (заказная разработка), #_testirovanie_po (тестирование по), #_testdizajn (тест-дизайн), #_rabota_s_trebovanijami (работа с требованиями), #_strategija_testirovanija (стратегия тестирования), #_user_story, #_acceptance_criteria, #_blog_kompanii_arkadija (
Блог компании Аркадия
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_testirovanie_vebservisov (
Тестирование веб-сервисов
), #_testirovanie_mobilnyh_prilozhenij (
Тестирование мобильных приложений
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:08
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 За пять лет работы в «Аркадии» — компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, — мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая — с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.Небольшие проекты у нас скорее редкость, и к ним не очень подходят стратегия и тактика тестирования, применяемые для длительных проектов. В этой статье я расскажу, как составляю стратегию тестирования в краткосрочных проектах и внедряю её на практике.Как всё начинаетсяИногда к нам обращаются заказчики, которым нужно быстро разработать небольшой программный продукт. Например, новый сайт или приложение для смартфонов. Работы по такому проекту не очень много, и всё должно быть готово через несколько месяцев.У заказчика есть представление о будущих пользователях и какая-то основа для проекта. В роли такой основы может выступить старый сайт — он долго служил верой и правдой, но сейчас устарел. Пользоваться с мобильных устройств им неудобно, а ведь именно с них, судя по имеющейся у заказчика статистике, идёт большая часть пользовательского трафика. Десктопной версией сайта фактически пользуются только администраторы, наполняющие его контентом.Поэтому заказчик хочет перевести мобильных пользователей на нативное приложение, содержащее основные возможности для пользователей. Функции, нужные только для контент-менеджеров, будут доступны в десктопной версии сайта.Или другой пример. Есть работающий сайт, который заказчика устраивает. К сайту заказчик хочет разработать мобильное приложение, в которое нужно добавить несколько небольших новых фич.Вся эта основа для проекта попадает к нашей команде. На краткосрочных проектах она невелика и состоит из менеджера проекта, двух-трёх программистов, UX/UI-дизайнера и тестировщика.Когда и как начинается тестированиеТестирование на краткосрочном проекте начинается с “Shift left”, то есть со «сдвига тестирования влево» относительно традиционного места в хвосте производственной цепочки, состоящей из определения требований, анализа и проектирования, кодирования, тестирования и развертывания.Принцип “Shift left” заключается в том, чтобы начинать тестирование не в конце процесса разработки, а с его ранних этапов: тестирования концепции, требований и документации.  Источник картинки: https://devopedia.org/shift-left Ниже приведён набор вопросов, который поможет тестировщику сориентироваться на старте краткосрочного проекта.Вопросник: тестирование концепции Целевая аудитория и условия использования ПО Что выясняем Пример Откуда берём информацию Что за программный продукт мы делаем? Краткое описание продукта? Основные функции? Приложение с упражнениями по английской грамматике, 5 упражнений в деньОпрашиваем заказчика Для кого разрабатываем продукт? Кто целевая аудитория приложения? Для школ. Ученики 5-9 классовВ каких условиях будут пользоваться будущим ПО? Типы устройств? Тип подключения к сети? С мобильных устройств, стабильный Wi-Fi в классе Материальная база тестирования — на чём тестируем Что выясняем Пример Откуда берём информацию ПлатформыiOS Android Windows Определяется из ответов заказчика на предыдущие вопросы + смотрим статистику по целевой аудитории Операционные системы (конкретные) iOS versions iOS 13 iOS 12 Android OS versions Pie 10 Oreo Устройства, на которых должно работать ПО (список устройств) iPhone .. Samsung Galaxy .. Huawei .. Интеграция с тем, что уже есть Что выясняем Пример Откуда берём информацию Системы, с которыми приложение должно интегрироватьсяАккаунт на десктопной версии сайтаКоманда заказчика, технические специалисты, документация по системам, тестирование системСпособы и инструменты для проверки того, что ничего и нигде не было потеряноAPI Опросив заказчика и изучив основу проекта, мы получаем детальное представление о концепции того софта, который нужно разработать. Всё это заносится в трекер задач и в вики проекта.Тестирование требованийПосле того как концепция проекта сложилась, мы переходим к тестированию требований. Откуда эти требования вообще берутся? У нас они приходят от заказчика, фиксируются менеджером проекта и сразу идут в работу. Поэтому тестирование требований идёт параллельно с тем, как программисты пишут код, а UX-дизайнер разрабатывает прототип. Задача тестировщика на этом этапе — создать максимально целостное и непротиворечивое описание продукта и его работы. То есть описать ожидаемое поведение.Описывая ожидаемое поведение, тестировщик закладывает базу для чек-листов, выявляет противоречия и пустые места. А затем находит ответы, задавая вопросы программистам и заказчику. Так мы отлавливаем часть багов ещё до того, как софт попадает на проверку. Иногда даже до того, как программист напишет код. Тестировщик берёт требования в том виде, в котором они есть. Допустим, это будут user stories (пользовательские истории).1. User storyUser story (пользовательская история) состоит из заголовка, представляющего собой основной сценарий использования и дополнительных сценариев с конкретикой. Схема User story : As a <role> I want <functionality> so that <benefit> Как <роль>, я хочу <функциональность>, чтобы <получить выгоду / достичь цели> Пример User story : Как пользователь, я хочу иметь доступ к упражнениям с 9 утра до 9 вечера Дополнительные сценарии могут быть описаны в критериях приёмки (acceptance criteria). О том, как их можно конкретизировать, я расскажу позже.Acceptance Criteria Acceptance Criterion 1 Как пользователь, я могу просматривать упражнения дня с 9 утра до 9 вечера Acceptance Criterion 2 Как пользователь, я могу создавать ответы на упражнения дня с 9 утра до 9 вечера Acceptance Criterion 3 Как пользователь, я могу редактировать ответы на упражнения дня с 9 утра до 9 вечера Acceptance Criterion 4 Как пользователь, я могу отправлять ответы на упражнения дня на проверку с 9 утра до 9 вечера 2. Глоссарий проектаПоскольку пользовательские истории пишутся человеческим, а не техническим языком, важно удостовериться, что:а) понятия, упомянутые в истории, понимаются одинаково всеми участниками разработки. Например, под словом «упражнения» команда разработки и заказчик имеют в виду одно и то же;б) если в описании одного явления используются синонимы — например, «упражнения», «домашняя работа», «задания» — то речь идёт об одном и том же явлении. И тут нам поможет составление глоссария проекта. Используя контент-анализ, я смотрю по текстам пользовательских историй, какие синонимы используются для обозначения одного явления. Выписываю их себе в табличку-глоссарий. Потом сверяю своё понимание слов с таким же у заказчика и программиста, который уже взял задачу. Пример глоссария Понятие и все слова, которыми мы обозначаем это понятие Определение понятия Пример Упражнения, набор упражнений, задание, домашняя работа Набор упражнений, которые учащийся должен сделать за день (с … по …) 5 упражнений по грамматике до 23:59 в данном часовом поясе 3. Умолчания и дополненияПосле того как с определением понятий мы разобрались, время переходить к восстановлению умолчаний и сокращений. В обычной коммуникации люди редко используют такие тяжеловесные предложения, а в тестировании оно пригождается.Исходный текст с умолчаниями Умолчания восстановлены «меняем в админке» «меняем в админка-тесты-курс-семестр-тест-папка с настройками-xml» «атрибут А» «атрибут А класса Б» После восстановления умолчаний задаём вопросы для получения дополнительной информации:Понятие и все слова, которыми мы называем понятие Определение понятия Пример Вопросы Упражнения, набор упражнений, задание, домашнее задание Набор упражнений, которые учащийся должен сделать за день Ежедневные упражнения по грамматике, которые должны быть сданы сегодня До какого точно времени учащийся должен отправить задания? Сколько упражнений в ежедневном наборе? 4. Acceptance Criteria — основа для чек-листаТестируя требования таким образом, мы получаем двойную выгоду: а) конкретизируем Acceptance Criteria; б) закладываем основу для чек-листа. Далее переходим к созданию основы чек-листа. На этом этапе выкидываем обороты типа «система должна…» и «также ожидаемо…» и «отжимаем» текст от «воды» до списка требований по пунктам.Исходный текст Текст без «воды» Система должна давать учащимся возможность выполнять упражнения ежедневно во временной промежуток с 9 утра до 9 вечера - упражнения доступны с 9:00 утра до 9:00 вечера - упражнения недоступны с 9:01 вечера до 8:59 утра Таким образом я обрабатываю как позитивные, так и негативные требования — в том же порядке, в каком они встречаются в пользовательской истории. Потом сортирую: негативные требования идут в конец списка Acceptance Criteria, а позитивные — в начало.После того, как были конкретизированы Acceptance Criteria, переходим к тест-дизайну. Тест-дизайн и тестирование прототипаЗаголовок user story становится заголовком для группы проверок. Acceptance Criteria становится заголовком отдельного чек-листа или интеллект-карты, куда мы выписываем и ранжируем проверки.Что получается в результате Исходная User Story Чек-лист User story As a <role> I want <feature> So that <benefit> Как пользователь, я хочу иметь доступ к упражнениям с 9 утра до 9 вечера User role can do <> to get ... Пользователь имеет доступ к упражнениям с 9 утра до 9 вечера Acceptance Criterion 1 Given <initial context> When <event occurs> Then <ensure come outcomes> Checklist ... 1. Задания можно просмотреть с 9 утра до 9 вечера 2. Задания можно выполнить с 9 утра до 9 вечера 3. Ответы на задания можно отправить на проверку с 9 утра до 9 вечера 4. Ответы на задания можно отредактировать с 9 утра до 9 вечера 5. Задания недоступны для просмотра и выполнения с 9 вечера до 9 утра Создание тест-кейсов на краткосрочных проектах, как правило, нецелесообразно. Специфика тест-кейсов заключается в том, что это подробное описание шагов, ожидаемой реакции системы и конечного результата. Это полезно, когда продукт большой, сложный, разработка идёт долго, в команду регулярно приходят новые люди. Тогда тест-кейсы пригодятся при подключении к разработке новичков, а для старых сотрудников — при проверке сложной функциональности с неочевидными шагами.В краткосрочных проектах продукт небольшой, команда тоже, и всё очень быстро меняется. При использовании тест-кейсов слишком много времени уйдёт на их написание и поддержку. Их постоянно придётся переписывать, а времени и так мало. А вот чек-листы и интеллект-карты, по которым производится тестирование, — оптимальный выбор документации в условиях ограниченного времени.Пример интеллект-карты  Источник картинки: автор статьиДля того, чтобы создать максимально эффективные проверки, при их разработке используем техники тест-дизайна. Например, разбиение на классы эквивалентности, анализ граничных значений, таблицы решений. В параллель с тем, как тестировщик пишет чек-листы, UX/UI-дизайнер создаёт прототип. Тестировщик проверяет интерфейс прототипа, корректирует чек-листы, обсуждает найденное с командой.Далее следует демо прототипа заказчику. По результатам демо команда собирает обратную связь, фиксирует полученную информацию в задачах в трекере и на страницах вики проекта. При необходимости прототип отправляется на доработку, после которой проводится повторное тестирование, демо и дальнейшая разработка программного продукта. Специфика тестирования в краткосрочном проектеВ краткосрочной разработке нет привычной нам рутины: «планирование спринта — спринт — демо — ретро», но есть промежуточные дедлайны. Однако есть пользовательские истории, описывающие функционал разного приоритета, который, согласно этим приоритетам, реализуется. Тестирование идёт параллельно с написанием кода.Чтобы начать тестирование продукта, нужно развернуть и настроить тестовое окружение, собрать и установить билд, подготовить необходимые тестовые данные. И только после того, как все эти шаги пройдены, тестировщик приступает к тестированию.Начинаем с позитивных кейсов. Мы хотим убедиться, что если пользователь делает всё как надо, он получает ожидаемый результат. Пример позитивного кейса <Пользователь может делать задания с 9:00 утра до 8:59 вечера> Затем мы проверяем негативные кейсы — «что у юзера ни в коем случае выйти не должно». Пример негативного кейса <Задания недоступны для просмотра и выполнения с 9:00 вечера до 8:59 утра> До релиза тестировщик проверяет как функционал, описанный в отдельных пользовательских историях, так и весь продукт целиком. Смотрит, корректно ли происходит установка, обновление, удаление продукта. Даёт обратную связь программистам, фиксирует баги в трекере, дорабатывает чек-листы.Баги в трекере наряду с чек-листами помогают поддерживать и сопровождать продукт. Заказчик знает, какие дефекты есть в продукте, и может выбрать, какие из них исправлять в первую очередь.Жизнь после релиза И вот наш продукт становится доступен конечным пользователям. От них приходят первые отзывы и первые баги. Это нормально, поскольку исчерпывающее тестирование на начальном этапе недостижимо, и какие-то ошибки всё равно будут. Специфика заказной разработки такова, что техподдержка находится со стороны заказчика, который и передаёт баги команде. Как правило, баги от пользователей не имеют подробного описания и требуют детального расследования. Задача тестировщика на этом этапе разработки — воспроизводить баги, пришедшие от пользователей, при необходимости привлекая к этому программистов, и тестировать фиксы, созданные программистами. Перепроверяя фикс, тестировщик добавляет проверки в чек-листы, углублённо тестирует функционал вокруг бага. Иногда таким образом тестировщик находит связанные баги, которые команда успевает починить до того, как их обнаружат пользователи. Обновлённые чек-листы, наряду с другой информацией, которую тестировщик заносил в трекер, в будущем сэкономит время команде, пришедшей на поддержку проекта, и позволит быстрее разобраться в проекте.Да и самому себе оставить памятку — дело нелишнее. Краткосрочность краткосрочностью, но иногда маленький проект становится основой большего. И через какое-то время использования софта приходит заказ на написание дополнительного функционала.ЗаключениеТестирование в небольшом проекте стартует одновременно с разработкой и начинается с определения целевой аудитории и условий использования ПО. На основе полученных данных команда определяется с устройствами, платформами и операционными системами для проверки продукта, продумывает интеграцию с существующими системами.Далее следует этап тестирования требований, во время которого тестировщик создаёт максимально целостное и непротиворечивое описание продукта и его работы. Здесь идёт работа с user story и acceptance criteria, на основе которых тестировщик составляет чек-листы и интеллект-карты со списком конкретных проверок.Следующими этапами тестирования будут: тестирование прототипа от UX/UI-дизайнера, тестирование отдельных функциональностей от программистов и тестирование готовых версий. Использование трекера задач на всех этапах проекта важно не только для длительного проекта, но и для краткосрочного, так как помогает поддерживать и сопровождать продукт, что особенно ценно при передаче проекта заказчику. =========== Источник: habr.com =========== Похожие новости:
Блог компании Аркадия ), #_testirovanie_itsistem ( Тестирование IT-систем ), #_testirovanie_vebservisov ( Тестирование веб-сервисов ), #_testirovanie_mobilnyh_prilozhenij ( Тестирование мобильных приложений ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:08
Часовой пояс: UTC + 5