что такое артефакт в тестировании
21. Перечислите основные артефакты тестирования ПО.
Тестовые артефакты — это используемые или создаваемые во время тестирования документы, модели и т.п. Например, вот основные из них:
1. План тестирования. Определяет стратегию тестирования на каждой итерации. Т.е. описывает цели и задачи тестирования, перечни тестов, метрики и критерии тестирования.
2. Сценарий тестирования (тестовый кейс или тестовый случай). Основной документ тестировщика, содержащий краткое описание входных данных, условий и последовательностей выполнения действий и ожидаемого результата.
3. Тестовые данные. Наборы тестовых входных данных и ожидаемых результатов.
4. Тестовый скрипт. Программная реализация теста или же описание ручного тестирования.
5. Набор тестов. Это сценарии тестирования, объединённые в наборы или пакеты. Используются как способ группировки тестов с похожими задачами или как набор сценариев, которые должны выполняться по порядку, так как, последующий использует результаты предыдущего сценария.
6. Список идей тестов. Используется в RUP для анализа и проектирования системы сценариев, существенно упрощая разработку необходимых наборов тестов. В основном смысл в том, чтобы проверить каждый сценарий различными способами. В RUP список идей тестов, представлен как документ группы тестирования, где каждый может внести изменение.
7. Результаты тестирования. Все результаты тестирования проведённых по ходу работы над всем проектом. На основе анализа этих результатов и сравнений с ожидаемыми результатами, выполняется оценка качества тестируемого продукта.
8. Дефекты. Важные артефакты процесса тестирования, которые описывают найденные ошибки и инициализируют процессы исправления
Основные определения и понятия тестирования ПО
Чтобы с головой погрузиться в новую профессиональную область, важно изучить язык, на котором говорят её представители. Ведь специальная лексика не только описывает инструменты или процессы, с которыми тестировщики работают ежедневно, но и облегчает общение с коллегами на около рабочие темы.
К примеру, вы уже могли слышать фразу «это не баг, а фича». Объяснить её далёкому от информационных технологий собеседнику не так просто: в отличие от бага, который является ошибкой, фича ― это не дефект, а заранее и сознательно придуманная опция, которая служит изюминкой. Слишком долго, не так ли?
Использование подобных словечек поможет вам проявить свои знания на собеседовании и найти общий язык с 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, записывайтесь на курсы Академии сегодня!
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (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) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Артефакты, необходимые для тестирования
Дисклаймер. Данная статья не является претензией на объективность, а отражает только мое сугубо личное мнение. Также прошу обратить внимание на то, что мое мнение не является статичным и может меняться. Статья написана только для того, чтобы не отвечать много раз на одни и те же вопросы, а просто дать ссылку.
Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).
Я выделяю несколько артефактов:
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. Это называется: “Ух ты компилицо”
План приёмо-сдаточных испытаний (ПСИ)
Документ, включающий в себя набор определенных тестовых сценариев, после положительного прохождения которого заказчик подписывает акт приемо-передачи (сдачи-приемки).
В общем случае подмножества тестов выглядят так как на рисунке.
Выше я перечислил те артефакты, которые считаю важными для проведения тестирования. Но это не значит что при любом тестировании необходимо использовать все из них. Да и детализация каждого из артефактов в каждом конкретном случае может различаться.
Кросспост с личного блога
Артефакты
Подскажите пожалуйста!
Тест кейс и тест сценарий, это же одно и тоже?
В тестировании ОЧЕНЬ плохо с терминами. Попробуй только договорись со всеми, как и что называть! Я постараюсь сейчас объяснить, но вообще глоссарий можно посмотреть здесь: http://www.rstqb.org. 5,0&sitelang=ru
При этом кейсы обычно небольшие, чтобы было удобно отслеживать их статусы, быстро проходить, считать статистику и т.д. Но для тестирования продукта может потребоваться много-много кейсов, ещё и в определённой последовательности. Когда мы из этих кейсов набираем какую-то последовательность, она и будет тест-сценарием. К примеру, сценарий из 50 тест-кейсов, проверяющих какую-то функциональность продукта.
А зачем вам вся эта терминология? Это всё в теории бессмысленно, а на практике такие вопросы обычно не возникают.
У меня тут есть вопросы на собеседование на QA.
Кто может расскажите в двух словах про crash-тестирование.
Это тестирование, чтоб поломать систему?
Тестирование прочности?
Кто может расскажите в двух словах про crash-тестирование.
Это тестирование, чтоб поломать систему?
Тестирование прочности?
«Crash testing» redirects here. => Destructive software testing is a type of software testing which attempts to cause a piece of software to fail in an uncontrolled manner, in order to test its robustness.
Неспецифичный термин. Есть негативное тестирование, есть fail & recovery тесты, есть стресс-тестирование. С краш-тестированием лично я не сталкивалась, скорее всего, имеется в виду что-то из того, что я перечислила. А по этим терминам можете в глоссарии посмотреть.
Во например, проверяю я функциональность какую-нить, пишу для этого тест кейс «нажать то-то, ввести то-то». Я же этот тест кейс пишу ДО того как собственно проверяю, и вот в середине его вдруг появляется баг, я о нем сообщаю программисту, он переделывает. Вот как мне это регистрировать. Ну вот Баг, тест-кейс не доделан, мне нужно новый тест-кейс создавать или писать рядом, что вот тут был баг, поэтому я его прохожу заново?
1. Пишете тест-кейс, в котором описано, как функция должна работать
2. Выполняете кейс
3. Если PASSED, то все ОК, если FAILED, то пишете баг.
У меня создается впечатление, что вы путаете собственно тест-кейс как набор шагов для проверки и тест-кейс как единицу выполнения тестирования.
Если тест не пройден, то писать только из-за этого новый тест-кейс не нужно.
Но если в ходе исправления ошибки меняется функционал приложения, то тогда тест нужно обновить.
Я это в основном к тому, что возможно мне когда-нибудь надо будет предстать на собеседовании перед потенциальным работодателем, и я буду говорить, что имею опыт работы с документацией, но пока что получается, что я изобрету эту документацию для нашей компании, а от меня буду ожидать чего-то другого. не хочется изобретать велосипед.
ОР: баланс аккаунта пополнен на введенную сумму.
И к файлу с тест-кейсом гиперссылками прицепленны +100500 файлики уже с конкретными примерами.
Так можно или ересь?)
Я бы предложил сделать так:
Создайте Excel-файл, в котором будут храниться тест-кейсы. В нем вы не будете отмечать правильно/неправильно, а просто опишете шаги для проверки определенной функции
В другом файле создать список для проверки: номер кейса, заголовок, результат.
Первый файл будет всегда один и тот же, а вот второй будет меняться при каждом прохождении тестов.
Это поможет снизить количество переписываний одного и того же.
Все это может быть не очень удобно — возможно, через некоторое время вы задумаетесь, не установить ли вам Bug tracking system и Test management system 🙂
В аттаче к посту — примеры, иллюстрирующие мою мысль.
А конкретные примеры нужны только в некоторых случаях, например, если проверяются граничные значения, вот там важно, вводим мы 10, 100 или 100.1, и это надо указывать в тест-кейсе.
Стопицот примеров логинов и сумм, если они не принципиально важны в данном контексте, писать не надо 🙂
Прикрепленные файлы
Freiman, спасибо огромное. поняла, попробую делать теперь так.
О багтрекере уже вовсю думаем, но я пока не разобралась какой лучше))
Пока что хочется как-то стандартизировать ручной процесс, чтобы самой понимать что к чему) Приятно, что раз я это все делаю, то и заточено будет под меня)))
Фрося, ну у нас не присваивается каждый раз новый номер, просто исправляется ошибка и файлик плагина пересохраняется) Так не правильно?
Спасибо большое за ответы. Очень приятно, что мои глупые вопросы не остаются без внимания. ))
))) может и Ваш вариант правилен. От проекта зависит.
А теперь я хочу задать очень тупой вопрос.
При приеме на работу мне сказали, мы делаем то-то то-то, надо, чтобы ты это тестировала, и, желательно, (барабанная дробь) автоматизировала.
Я прочла много статей, где основной мыслю является «Сначала сделайте полный порядок в ручном тестировании и только потом занимайтесь автоматизацией».
Порядок я сейчас стараюсь навести, читаю мануалы и все такое.
НО призрак автоматизации таки маячит.
И засим у меня вопрос.
Это чего такое?
Все ответы в инете даются с учетом того, что имеется хотя бы интуитивно понятное определение этого дела.
А я в упор не понимаю как это.
Что это.
Куда это.
Это надо писать какие-то скрипты? Это программы повторяющие мои ручные действия?
на чем писать, в чем писать, что за програмы?
*мне стыдно за эти вопросы, но когда-то придется их задать)
А теперь я хочу задать очень тупой вопрос.
При приеме на работу мне сказали, мы делаем то-то то-то, надо, чтобы ты это тестировала, и, желательно, (барабанная дробь) автоматизировала.
а чем мотивировали желательность автоматизации? Какую цель хотят достичь с помощью автоматизации?
Это надо писать какие-то скрипты? Это программы повторяющие мои ручные действия?
если вы автоматизируете функциональное тестирование, то, в общем-то, да. Программы, повторяющие ваши действия.
на чем писать, в чем писать, что за програмы?
все зависит от того, какое приложение вам нужно протестировать. Что у вас за продукт? Это сайт? Офисное windows-приложение? java-игра для телефона? софтина для айпада?
*мне стыдно за эти вопросы, но когда-то придется их задать)
ничего стыдного в этом нет.
хорошо, что Вы думаете и пытаетесь найти ответы на возникающие у Вас вопросы 🙂
Еще пара слов.
Автоматизация нужна не всегда.
Вопрос «Автоматизировать или нет?» довольно сложен, и однозначного универсального ответа нет. Можно автоматизировать, когда временные затраты на разработку и поддержание тестов будут меньше, чем если бы все проверялось руками стопицот раз.
У вас проект молодой, значит, в нем много чего будет часто и очень сильно меняться, а это значит, что и затраты на поддержку автоматических тестов будут значительными. В результате быстрее будет проверить руками 🙂
а чем мотивировали желательность автоматизации? Какую цель хотят достичь с помощью автоматизации?
Ну наверное, чтобы проверялось быстрее и точнее, ибо проектов много и на каждый мало времени
если вы автоматизируете функциональное тестирование, то, в общем-то, да. Программы, повторяющие ваши действия.
все зависит от того, какое приложение вам нужно протестировать. Что у вас за продукт? Это сайт? Офисное windows-приложение? java-игра для телефона? софтина для айпада?
Это плагины для торговли на форекс, на базе платформы MetaTrader4
а чем мотивировали желательность автоматизации? Какую цель хотят достичь с помощью автоматизации?
Ну наверное, чтобы проверялось быстрее и точнее, ибо проектов много и на каждый мало времени
я вижу два варианта, которые могли бы помочь:
1. вы прогоняете один тест, но на большом объеме данных — например, на всех доступных торговых инструментах
2. вы автоматизруете регрессионное тестирование (если оно у вас вообще есть).
Если Вас это не устраивает, и вы хотите улучшить свою работу — то вы двигаетесь в верном направлении 🙂
баг-трекинга в Excel вам уже недостаточно, значит, надо смотреть Bug Tracking System. Приличное, простое в установке и использовании средство — Mantis. А заценить все многообразие этого главного инструмента тестировщика можно, например, тут. Для хранения тест-кейсов и лога работ используется Test Management System, одна из популярных — TestLink, ибо бесплатная и интегрируется с популярными баг-трекерами, в том числе и Мантисом.
Внедрение BTS окажется намного полезнее, чем автоматизация 🙂
В качестве инструмента я советую http://www.autoitscript.com — хотя бы потому, что он бесплатный 🙂 когда-то писал на нем тесты, вполне нормально.
Потом забросил это дело, т.к. времени на их поддержку тратилось очень много, а эффекта было мало.
Можно посмотреть на http://www.qaliber.net, но я им не пользовался.