что такое тестовые артефакты
Артефакты, необходимые для тестирования
Дисклаймер. Данная статья не является претензией на объективность, а отражает только мое сугубо личное мнение. Также прошу обратить внимание на то, что мое мнение не является статичным и может меняться. Статья написана только для того, чтобы не отвечать много раз на одни и те же вопросы, а просто дать ссылку.
Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).
Я выделяю несколько артефактов:
1. План тестирования (Test plan)
2. Тестовый сценарий (Test-case)
3. Наборы тестовых сценариев (Test script or Test suite)
* Набор тестовых сценариев для Smoke-test
* План приёмосдаточных испытаний (ПСИ)
4. Описание дефектов
5. Отчет о тестировании
Описание дефектов и отчет о тестировании в данной статье не рассматриваются, так как это уже результаты и поэтому про них напишу отдельно.
Есть как минимум два общепринятых понимания этого документа:
1. Документ описывающий кто, что, когда и как будет тестироваться
2. Документ описывающий все необходимые для проверки приложения тесты.
Говоря план тестирования, я подразумеваю именно первый вариант толкования.
Для того чтобы посмотреть пример плана тестирования можно:
* Взять книгу Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
* Взять RUP
* Погуглить
* Дождаться когда я изложу пример в одной из следующих статей
Тестовый сценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.
Хорошая практика — написание тестовых сценариев на основании вариантов использования (Use cases).
Тестовый сценарий является как атом мельчайшей частичкой для ниже описанных документов (но его как и атом можно разбить на условия, входные данные, шаги, результаты)
* Атомарный тест
* Тестовый вариант
* Вариант тестирования
* Тестовый случай
Наборы тестовых сценариев
Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test script)), так и независимыми (Test suite).
Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.
Набор тестовых сценариев для Smoke-test
Если честно, то я не знаю адекватного перевода на русский данного термина. Иногда используется перевод “Дымчатое тестирование”, но он вызывает у меня стойкое отвращение.
Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.
Хорошая практика — прием билда в тестирование на основании прохождения Smoke-test. Также зачастую в качестве такого теста используют ежедневную сборку с обязательным прохождением unit тестов.
Комментарий: Ежедневная сборка без unit тестов не может считаться как Smoke test. Это называется: “Ух ты компилицо”
План приёмо-сдаточных испытаний (ПСИ)
Документ, включающий в себя набор определенных тестовых сценариев, после положительного прохождения которого заказчик подписывает акт приемо-передачи (сдачи-приемки).
В общем случае подмножества тестов выглядят так как на рисунке.
Выше я перечислил те артефакты, которые считаю важными для проведения тестирования. Но это не значит что при любом тестировании необходимо использовать все из них. Да и детализация каждого из артефактов в каждом конкретном случае может различаться.
Кросспост с личного блога
Основные определения и понятия тестирования ПО
Чтобы с головой погрузиться в новую профессиональную область, важно изучить язык, на котором говорят её представители. Ведь специальная лексика не только описывает инструменты или процессы, с которыми тестировщики работают ежедневно, но и облегчает общение с коллегами на около рабочие темы.
К примеру, вы уже могли слышать фразу «это не баг, а фича». Объяснить её далёкому от информационных технологий собеседнику не так просто: в отличие от бага, который является ошибкой, фича ― это не дефект, а заранее и сознательно придуманная опция, которая служит изюминкой. Слишком долго, не так ли?
Использование подобных словечек поможет вам проявить свои знания на собеседовании и найти общий язык с HR, уже работающим в ИТ-индустрии человеком. Итак, какие же понятия и определения будут полезны каждому начинающему QA-специалисту?
Базовые термины
Баг (bug) ― это ошибка или дефект программного обеспечения. Он проявляется, когда фактическое поведение системы отличается от ожидаемого. Дефекты могут быть критическими и влиять на использование ПО или незначительными, когда их присутствие незаметно для пользователя.
Тестирование (testing) ― это исследование поведения программного продукта, основной целью которого является выявление багов. Понятия контроль качества (quality control, QC) и обеспечение качества (quality assurance, QA) часто используются в качестве синонимов, но это ошибка. Ведь тестирование нацелено на поиск ошибок в уже готовом ПО, а обеспечение качества задаёт условия, в которых дефекты появляться не будут.
Подробно об отличиях данных явлений мы рассказали в нашей статье.
Тестовое покрытие (test coverage) ― это совокупность тестов, которые проявляют работоспособность той или иной функциональности ПО. Чем больше проверок, тем шире тестовое покрытие, тем больше возможностей отследить поведение системы в различных условиях и выявить критические или незначительные дефекты.
Верификация (verification) ― оценка ПО или его компонентов с точки зрения соответствия всем заявленным к нему требованиям.
Валидация (validation) ― это проверка работоспособности функциональности приложения.
Релиз (release, RTM) ― выпуск программного продукта на рынок, например, размещение мобильного приложения в App Store или Google Play.
Артефакты ― это документы, которые используют в процессе тестирования. Подробнее о том, какими они бывают, расскажем далее.
Артефакты
Спецификация (specification, спек) ― детализированное описание работы приложения, которое включает технические свойства.
Баг-репорт (bug report, отчёт об ошибке) ― описание действий или условий, которые привели к выявлению дефекта. О принципах составления безупречного баг-репорта мы уже рассказали в одной из наших статей.
Подобные отчёты создают в баг-трекинговой системе (bug tracking system, система отслеживания ошибок). Это программа для описания и контроля дефектов. Наиболее распространённой является Jira. Новичку привыкнуть к работе в этой системе непросто, но освоить азы вы сможете с поддержкой опытного преподавателя-практика на базовом курсе от QA Academy.
План тестирования (test plan) ― в этом документе содержатся все данные о проводимой проверке: описание программного продукта, стратегия тестирования, сроки выполнения поставленных задач, используемые в процессе инструменты и оборудование, оценка потенциальных рисков и прочее.
Чек-лист (checklist, контрольный список) ― перечень параметров, которые нуждаются в проверке.
Тест-кейс (test case, тестовый случай) ― своего рода сценарий или описание последовательности шагов при проведении тестирования.
Тестовый набор (test suite) ― несколько тест-кейсов, которые объединены по типу тестирования или другим признакам.
Типы тестирования
Мануальное (ручное) ― непосредственная проверка работы ПО тестировщиком.
Автоматизированное ― оценка качества программного продукта с применением программных средств (автотесты).
Тестирование производительности (performance testing) ― анализ работы приложений под различными нагрузками.
Функциональное тестирование (functional testing) ― проверка возможности ПО в заданных условиях решать необходимые пользователю задачи.
Тестирование безопасности (security testing) ― определение безопасности ПО: защищено ли оно от атак хакеров, несанкционированного доступа к данным и т. д.
UX-тестирование (usability testing, юзабилити-тестирование) ― исследование логики и удобства использования ПО.
Подробнее о различных подходах оценки качества ПО вы узнаете из нашего материала по классификации видов тестирования.
Ещё несколько полезных слов
Фиксить (от англ. to fix — исправлять) — вносить правки, исправлять ошибки.
Локаль (от англ. locale — место) — региональные настройки или параметры ПО.
Билд (от англ. to build — строить) — финальный вариант программного продукта или его элемента, который готов к тестированию.
Асайнить (от англ. to assign — назначать) — закреплять за кем-то задачу или часть работы.
В аттаче (от англ. to attach — приложить) — добавлять к письму или сообщению документ. Например, отправить на почту письмо с CV в аттаче означает, что было отправлено письмо с приложенным к нему резюме.
Букать (от англ. to book — бронировать) — резервировать.
Бэкапить (от англ. backup — дублирование) — создавать резервные копии документов или данных на случай их потери или удаления.
Дебаджить, дебажить (от англ. to debug — отлаживать) — настраивать или регулировать работу.
Тул (от англ. tool — инструмент) — программа, которая используется при тестировании.
Фича (от англ. feature — особенность) — некий аспект ПО, который служит его характерной особенностью.
Резюмируем
Мы постарались собрать самые важные слова и понятия, которые будут полезны на старте карьеры в QA. Они облегчат понимание профильной литературы и общение с коллегами. Поможет обогатить лексику регулярное чтение статей про тестирование, тематические блоги и литература.
Но быстрее всего пополнить словарик вы сможете в процессе живого общения во время рабочего процесса. Чтобы уже через несколько месяцев вы смогли реализоваться в QA, записывайтесь на курсы Академии сегодня!
Тестовая документация и анализ требований
В преддверии старта курса «Game QA Engineer» публикуем текстовую расшифровку онлайн-интенсива, который провела Надежда Чертовских — руководитель отдела QA в компании BeresnevGames и преподаватель OTUS.
Цели интенсива:
познакомиться с основными видами тестовой документации;
проанализировать документ от game-дизайнера;
попрактиковать составление чек-листа.
Для начала давайте обсудим такой животрепещущий вопрос: почему сегодня на курсе «тестировщик игр» мы обсуждаем документацию?
Как тестировщик, который целый день только в игры играет и сообщает разработчикам об обнаруженных ошибках, связан с документацией? Какая вообще работа у тестировщика игры? Какие у тестировщика могут быть документы?
Существует распространённое заблуждение, что тестировщик игр целый день только и делает, что в игры играет. Но на самом деле это не так. Тестировщик в геймдеве точно такой же тестировщик, как и в любой другой сфере, и работает точно по такому же принципу, но продукт у него не web-страничка, не application на операционной системе, а игра (мобильная, консольная, десктопная).
Тестирование может быть автоматизированным и ручным
На интенсиве мы поговорим в целом об артефактах тестирования, с которыми работает тестировщик:
План тестирования (Test Plan)
Тест-кейс (Test Case)
Баг-репорт (Bug Report)
Отчёт о тестировании (Test Report)
Из этого мы можем сделать вывод, что тестировщик не только читает требования, которые подготовили к продукту, но и сам генерирует документы.
В ходе интенсива мы более подробно поговорили о 6 типах документов, которые перечислили выше, обсудили, какие из них полезные, какие используются чаще, какие меньше и составили чек-лист по требованиям.
План тестирования
План тестирование (далее ПТ) или тест-план – это большой документ, который чаще всего описывает весь объем работ по тестированию проекта либо части проекта (например, релиза или предрелизного билда). ПТ описывает, что будет тестироваться, в какие сроки, какими инструментами, какая команда, обязанности и ответственности каждого члена команды. Также часто в ПТ включается стратегия тестирования, график релизов на несколько ближайших спринтов. В зависимости от команды бывает разная степень детализации ПТ и его могут делать разные люди в команде. В каких-то компаниях ПТ делает менеджер, в каких-то middle-тестировщик, либо senior-тестировщик, либо тимлид отдела тестирования.
Всё, что мы далее обсудим по документам, которые генерирует тестировщик, может отличаться от компании к компании, от команды к команде. В зависимости от команды и компании форм-фактор всех документов может быть либо уже обговорён и установлен, либо, если вы приходите первым QA специалистом на проект, то вы сами устанавливаете, как удобно вам.
Форм-фактор у тест-плана может быть разный (схема, интеллектуальная карта и т.д.) и зависит от того, как команде будет удобнее взаимодействовать с документами.
Чаще всего ПТ требуется именно для людей, которые принимают решения по проекту, чтобы они поняли, что в следующий момент мы делаем: релизим билд или нужно подвинуть сроки, добавить к тестированию, убавить к каким-то другим срокам. И лучше всего не делать ПТ огромным, чтобы человек, который будет его читать, смог осилить весь объём. Если посмотреть примеры тест-планов в интернете — часто это одностраничная схема, чтобы все в общем и целом понимали, какой объем тестирование предстоит. Обычно план тестирования делается до начала тестирования и до момента релиза.
Таким образом План тестирования:
описывает стратегию тестирования, цели, график, оценку, результаты, а также ресурсы необходимые для тестирования;
имеет разную степень детализации;
имеет разный форм-фактор;
составляется не более, чем на 2-х страницах;
составляется до начала тестирования.
Пример тест-плана с сайта с сайта www.guru99.com
Тест-кейс
Тест-кейс можно сравнить с рецептом — это последовательность шагов, которые приводят к какому-то результату. Тест-кейс лучше не делать избыточным. Тестировщики чаще всего хорошо знают свой проект, поэтому досконально писать тест-кейс нет необходимости. Тест-кейс должен быть краткий и понятный, так чтобы другой тестировщик, либо другой специалист в команде смог быстро пройти по нему и проверить, что все происходит так, как нужно.
Тест-кейсы можно формировать в последовательный сценарий, чтобы проверить, как игрок пройдет по этому функционалу от начала до конца.
Тест-кейсы можно группировать в смысловые блоки.
Например, если в игре запускается какой-то ивент, формируется набор тест-кейсов для проверки этого ивента.
Тест-кейсы лучше писать по требованиям гейм-дизайнерского документа. Но, если функционал уже готов, а требований тест-кейсов по нему не написано, можно написать уже по факту. Лишним не будет.
Составляющие тест-кейса:
идентификатор (уникальный номер, по которому вы сможете найти этот тест-кейс и на него сослаться);
название сценария (какое-то краткое, но ёмкое);
ссылка на требования ГДД;
предусловия (опционально, если они требуются для тест-кейса);
фактический результат (опционально).
Пример тест-кейса
Чек-лист
Чек-листы можно сравнить со списком покупок, который мы формируем на проверку. Например, чек-лист на Smoke-тест, чтобы проверить, что игра запускается и весь функционал, который должен в игре отрабатывать отрабатывает, иконка приложения соответствует иконке нашего приложения. Также чек-лист может быть составлен на регрессионное тестирование и даже на тестирование требований.
Чек-листы чаще всего составляются без детализации и их можно скомпоновать в наборы и проверять тоже для любого функционала либо нового, либо регрессионного.
Чек-листы лучше сразу писать по требованиям (геймдизайнерскому документу) перед стартом тестирования функционала или по итогу.
Небольшой пример из игры нашей студии: есть поле для ввода имени питомца и есть несколько условий на этом поле: имя питомца должно состоять из более чем 2 символов и только в этом случае кнопка из серой неактивной станет зеленой активной и можно будет питомца наименовать. Мы начинаем формировать чек-лист к этому полю если количество символов больше 2 то кнопка принять становится активное, если меньше 2 не активно. Первые 2 пункта чек-листа, которые можно проверить.
На скриншоте мы видим, как игрок из Китая захотел назвать питомца очень коротким ёмким именем и, к сожалению, не смог это сделать и обращался в тех. поддержку. В результате ему пришлось выдумывать более длинное имя.
Ссылка на mindmap чек-лист для мобильной игры:
Баг-репорт
Баг-репорт оформляется, когда баг уже локализован и его можно повторить. Если баг плавающий, нужно пытаться его повторить или занести в систему, где фиксируются баги, как плавающий баг. Ключевой момент, что баг можно повторить и воспроизвести, только тогда его заносят в систему с багами, где хранятся баг-репорты. Если создать и оформить какой-то баг, и разработчик не сможет его воспроизвести, то тут появится множество вопросов.
Поэтому лучше всего сразу проверить на нескольких устройствах, если это возможно и посмотреть на разных операционных системах, на разных разрешениях экрана, то есть максимально локализовать проблему.
В баг-репорте обязательно должны быть:
Подробное описание проблемы – что, где, когда случилось.
Важность дефекта, который указывает тестировщик, а уже приоритет по исправлению этой ошибки указывает менеджер либо команда из разработчиков.
Условия воспроизведения – версия игры, версия операционной системы и другие уникальные условия, которые могут помочь разработчику быстро найти баг, устранить и передать задачу на тестинг.
Алгоритм воспроизведения – пошаговые предусловия предусловия, которые необходимы для воспроизведения бага.
Доказательства – скрины, видео, логи с устройств.
Скриншоты из разных систем, в которых баг-репорт можно вести. В разных компаниях в разных командах условия могут быть абсолютно разные, и где хранятся баг репорты — также зависит от компании.
Отчет о тестировании
Отчет о тестировании пишется, когда функционал уж проверен и релиз либо предрелиз показывает итог проделанной работы.
Отчет о тестировании может быть представлен как текст, таблица, график или диаграмма, если это позволяет инструмент.
Составляющая отчёта о тестировании:
Кто тестировал (состав команды).
Когда тестировал (даты проведения тестов).
Как тестировал (процесс тестирования, описание применяемых методов и технологий).
Какие возникли проблемы и как решились.
Инструкция
Инструкцию можно писать до, во время или после тестирования. Инструкцию никогда не поздно написать. Это помогает как новичкам, так и коллегам, которые работают в одной команде. С помощью инструкции можно быстро сориентироваться в проекте.
Например, вышел новый функционал. Лучше написать инструкцию, как этот функционал проверить, как переключаться, если проверка нового функционала подразумевает переключение между версиями или предусматривает какой-то сложный алгоритм проверки. Это экономит время на объяснения, когда требуется делегировать задачу либо в команду пришел новый человек и нужно его обучить.
Также инструкция помогает выгрузить старое и не потерять. Скорость выпуска релизов в геймдеве довольно высокая и часто есть необходимость вернуться к старому функционалу, который ранее уже тестировался, но прошло какое-то время и тестируется новый функционал, а нужно вернуться к проверке того старого. Поэтому лучше всего, чтобы было прописано, как тестировать, где тестировать, что и куда переключать. Лучше всего все в картинках, гифках или видео. Сегодня современные инструменты всё это позволяют сделать быстро и без проблем. Также ели есть возможность сохранять какие-то состояния проекта, состояния продукта, то лучше где-то всё это фиксировать и выкладывать в общем доступе.
Инструкции лучше писать сразу. Это позволяет избежать множество проблем в дальнейшем.
Где хранить:
Google Docs, Google Sheets
Zephyr, Test Management for Jira
Геймдизайнерский документ (ГДД, диздок)
В геймдизайнерском документе гейм-дизайнер пишет требования к продукту или к отдельному функционалу.
Детализация у геймдизайнерского документа может быть разная. Форм-фактор также может быть разным.
Существует несколько способов проверки требований к игре: по принципу Что? Где? Когда? или по принципу проверки на полноту, однозначность, непротиворечивость, тестируемость, необходимость, осуществимость.
После того как геймдизайнерский документ готов лучше всего, если его прочитают и вместе обсудят специалист по тестированию, разработчик и сам гейм-дизайнер.
Тестировщику в этом случае следует задавать следующие вопросы: не противоречит ли те требования, которые гейм-дизайнер написал, функционалу, который сейчас есть, не будут ли нововведения противоречить наративу, функциям и механикам, которые есть в игре сейчас.
Требования геймдизайнерского документы должны пониматься всеми однозначно, что исключает какого-либо двоякого толкования.
Важно смотреть на полноту содержания: все ли условия предусмотрены, все ли сценарии, которые могут возникнуть у игрока в связи с новым функционалом продуманы.
Разработчик смотрит на возможность реализации ГДД.
Также необходимо продумать, как новый функционал будет тестироваться, после того как разработчик его реализует.
Практическая часть интенсива. Мы попробуем сформировать чек-лист и вопросов гейм-дизайнеру по новому продукту на основе ГДД.
На картинке мы видим 3 скрина игры.
скрин – изображение и кнопка Play, при нажатии на которую, мы попадаем в игровой mod
скрин – на старте есть какое-то количество жизней и шагов
скрин – при проигрыше попадаем на экран проигрыша, где написано итоговое количество набранных за игру баллов и кнопка сыграть ещё.
Итоги интенсива:
Узнали, какие бывают виды документации у тестировщика игр.
Обсудили зачем тот или иной документ нужен.
Попрактиковались в создании чек-листа.
Список материалов для самостоятельного изучения:
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса: