Основные принципы в тестировании ПО

Порой, тестируя большое количество новых фитч тестировщики забывают даже о самых важных принципах в тестировании и тем самым делая много стратегических и поведенческих ошибок в тестировании ПО.
В этой статье напомню общеизвестные и основные принципы о которых не следует забывать, когда тестируете какое либо приложение или новую фитчу

Принципы в тестировании ПО

Основные принципы в тестировании ПО

Из множества принципов, которые наверно для себя выделил каждый тестировщик занимающийся тестированием ПО есть основные по мнению сообщества тестировщиков, которые и хотелось бы выделить:

1) Исчерпывающее тестирование невозможно ни одним из тестировщиков. Думаю что все понимают что протестировать все возможные случаи и комбинации просто невозможно, конечно если это не тривиальный случай.
Все случаи просто не могут быть включены в тест сьют, так как это заняло бы у нас очень много времени и в конце концов не стоило бы нам таких усилий. Если каждый тестировщик сядет и тщательно продумает все сценарии и если отдать эту фитчу для тестирования другому тестировщику, то он как правило находит еще кучу возможных сценариев и кейсов, которые можно включить. Поэтому в тестировании ПО принято проанализировать продукт или новую фитчу после чего сфокусировать усилия в тестировании на более рисковые и приоритетные случаи и участки нашего продукта.

2) Скопление багов. Если брать продукт и разбить его по модулям, то в процессе тестирования можно заметить что основная часть багов лежит в одном или нескольких модулях продукта, следовательно можно отметить эффект скопления багов. Как правило такое можно наблюдать в совершенно разных продуктах. Для того чтобы эффективно протестировать наш продукт, следует распределить свои усилия в тестировании по реальной плотности багов в модулях продукта, если же тестируем впервые, то пропорционально ожидаемой плотности. Со временем тенденция с накоплением багов может изменятся от модуля к модулю. Это следует отслеживать и перераспределять усилия в дальнейшем тестировании.

Читать дальше →

Баг репорт (Bug Report) или заведение бага в тестировании ПО?

Допустим такую ситуацию когда ты нашел баг в каком-то софте и у тебя сразу же постает вопрос че с этим делать. Конечно ты можешь подойти к разработчику и сказать о баге и описать на пальцах как его воспроизвести, но это плохая практика так как разработчик ПО может сидеть в другой комнате, офисе или даже в другой стране и количество багов может быть настолько велико что их можно не запомнить и потом упустить. И если отвлекать разработчика по каждому мелочному багу и если их поднакопилось то это совсем не кошерно выходит потеря времени и отрыв от задач разработчика – не лучшее решение. Поэтому возникает само собой адекватное решение — документирование найденных багов с возможностью общего доступа к ним. Обычно в it компаниях баги документируют в баг-трекинговых системах.

Существует различное множество баг-трекинговых систем, которые позволяют нам не только создавать задачи, менять их статусы но и создавать баг репорты. Самые распространенные на сегодняшний день это Redmine, Bugzilla, Mantis, JIRA

Пример того как выглядит список баг репортов в JIRA:
Список Баг репортов в JIRA

Давайте разберем частый вопрос на собеседованиях, какие поля нужно заполнять в баг репорте и какие вообще существуют? Ответом на этот вопрос будет то что количество полей могут совершенно отличатся от компании к компании. Но в тоже время существуют общепринятые наиболее часто используемые поля которые нужно заполнять при заведении бага.

Сутью нашего бага будет то что мы не можем залогиниться в админ панель админ юзером, который был только что создан, следовательно что все новые админы не могут залогиниться когда вводишь корректные юзер и пароль в текстовые поля. Ниже объяснения и описания каждого из полей.

Читать дальше →

Что такое Тест Сьют или Тестовый Набор (Test Suite) ?

Что такое Тест Сьют и для чего он нужен?
Тест Сьют это набор тест кейсов, которые объединены тем что относятся к одному тестируемому модулю, функциональности, приоритету или одному типу тестирования. Каждый тест сьют состоит из более чем одного тест кейса и зачастую выполняется всей «пачкой» в процессе тестирования.
тест сьют, test suite
Тест кейсы объединяют в тест сьюты для большего удобства при проходжении тест кейсов, проходя их последовательно от модуля к модулю, от одного типа тестирования к другому а не сумбурно, бросаясь из одного угла в угол, оставив не проверенным большую часть модуля или общей функциональности.

Что такое Юзкейс (Use Case) или "Сценарий Использования" в Тестировании ПО?

Юзкейс (Use Case) — это перечень действий, сценарий по которому пользователь взаимодействует с приложением, программой для выполнения какого-либо действия для достижения конкретной цели. Тестирование по юзкейсам проводится для того чтобы обнаружить дополнительные логические дыры и баги в приложении, которые сложно найти в тестировании индивидуальных модулей, частей приложения отдельно друг от друга. Юзкейс тестирование может проводится как часть Приемочного тестирования. Для удобства визуального восприятия Use Case часто рисуют в виде диаграмм с переходами.

Пример Юзкейсов (Use Cases)
для разных типов пользователей онлайновой системы:

Юзкейс

Перед тестированием любого приложения или программы стоит поинтересоваться у заказчика чтобы тот предоставил хотя бы несколько Юзкейсов пользователей, какой набор сценариев используется чаще всего и отталкиваясь от этого составить тест кейсы таким образом, чтобы все сценарии были покрыты и имели наибольший приоритет и которые стоит покрыть автотестами в первую очередь.

Читать дальше →

Что такое Тест кейс (Test Case)?

Тест кейс это что?

Что такое Тест кейс (тестовый случай) — это самая маленькая часть тест документации, это ситуация которая проверяет конкретно взятое условие из требований. Одно условие может проверятся несколькими Тестовыми Случаями (позитивными и негативными). Набор тест кейсов объединяются в тест сьюты

Так тестовый сценарий выглядит в системе для хранения кейсов TestRail:
Тест кейс

Из каких основных полей состоят тест кейсы:

  • ID
  • В это поле записывается номер кейса или номер вместе с какой-то аббревиатурой к примему «PD_Sync_123»служит для их уникальной идентификации среди других кейсов.
  • Summary
  • Cюда записывают краткое описание проблемы. Summary (описание) должно содержать ответ на вопрос что произошло и при каких условиях работает не верно.
  • Steps
  • Здесь описывают шаги, для того чтобы востроизвести баг. Степы рекомендуют максимально сокращать, то есть найти кратчайший путь для воспроизведения бага и описать в степах, и очень важно чтобы они оставались максимально понятными для разработчиков.
  • Expected Result
  • В этом поле описываем ожидаемый результат после хождения по шагам или возможно после конкретных шагов, что бывает реже.
  • Pass/Fail
  • Поле служит для проставления статуса каждому тест кейсу. Если ожидаемый результат совпадает с реальным, то проставляем pass, в противном случае ставим fail. Возможно еще несколько статусов в зависимости от процессов и правил в IT компании
Возможны дополнительные поля для комментариев, ссылок на Баг репорт, Предусловий которые мы должны выполнить перед тем как воспроизводить по Шагам.

Пример Тест Кейса

Простой наглядный пример проверки успешного входа в систему Администратора при условии что его логин и пароль = 'Login' и '12345'.
Можно написать такие Тест Кейсы:

ID
Summary
Steps
Expected Result
Pass/Fail
1Administrator Log in (Positive)1. Open the login page
2. Type 'Login' in the Name field
3. Type '12345' in the Password field
4. Submit
Administrator should be logged in successfullyPassed OR Failed(Поле до стадии выполнения остается пустым или Not tested)
2Administrator Log in with Incorrect password, correct username (Negative)1. Open the login page
2. Type 'Login' in the Name field
3. Type '11111' in the Password field
4. Submit
Administrator should NOT be logged in. «User or Login is incorrect» message is displayedPassed OR Failed(Поле до стадии выполнения остается пустым или Not tested)
3Administrator Log in with Correct password, Incorrect username (Negative)1. Open the login page
2. Type 'Login1' in the Name field
3. Type '12345' in the Password field
4. Submit
Administrator should NOT be logged in. «User or Login is incorrect» message is displayedPassed OR Failed(Поле до стадии выполнения остается пустым или Not tested)

Что такое Граничные значения (Boundaries) и Эквивалентные классы (Equivalence partitioning) в Тестировании ПО?

Эквивалентные классы

Эквивалентный класс включает в себя определенное количество каких-то значений, которые предположительно будут обрабатываться и выдавать на выходе один и тот же результат для всех представителей этого эквивалентного класса.

Чтобы легче было понять давайте предположим что есть простой скрипт или программа, которая предлагает нам ввести возраст человека в текстовое поле вместимостью в 2 символа и что ниже находится кнопка для отправки данных. Результат данной программы должна быть стоимость мед страховки в зависимости от той цифры, которую мы введем. В соответствии с функциональной спецификацией все возраста разделили на четыре категории. Первая это Дети (включает от 0 до 12 лет), Вторая категория это Подростки (включает от 13 до 17 лет), Третья категория это Взрослые (включает от 18 до 59 лет), и последняя Пятая категория это Пенсионеры (включает от 60 до 99 лет). В зависимости от категории к которой относится человек, будет вычисляться стоимость мед страховки:
  • Дети — 10 у.е. в месяц
  • Подростки — 20 у.е. в месяц
  • Взрослые — 30 у.е. в месяц
  • Пенсионеры — 40 у.е. в месяц

В данном случае все входные данные мы можем разделить на 4 эквивалентных класса. Как изображено на изображении ниже.

Equivalence-partitioning

Вопрос: Сколько же тест кейсов нам нужно для проверки всех эквивалентных классов и какие именно?

Читать дальше →

Критерии выхода, завершения тестирования (Exit criteria). Когда остановиться тестировать?

Критерии завершения тестирования это один из часто задаваемых вопросов на собеседованиях на должность тестровщика ПО. Давайте разберем какие же основные факторы влияют на принятие решения о завершении тестирования тестировщиком.

Часто новички в тестировании отвечают на данный вопрос — буду тестировать пока не найду все баги :)
А возможно ли это? Нет конечно, никто не может гарантировать отсутствие багов, даже если это приложение было протестировано несколькими опытными тестировщиками. Исчерпывающие тестирование невозможно и об этом гласит один из принципов тестирования

Следует выделить 3 основных критерия для остановки, завершения тестирования:
  • Время
  • Бюджет
  • Все тест кейсы пройдены, найденные баги исправлены и перепроверены
Критерии выхода из тестирования

1) Время — В ходе тестирования могут находиться баги с разным приоритетом серьезности, попадаются баги блокеры, которые блокируют дальнейшее прохождение по тест кейсам, время на исправление и перепроверку багов может затянуться. Так как продукт или новую фитчу обещали к определенной дате то проджект менеджер вместе с тим лидом или тестировщиком принимает решение какие баги все таки стоить исправить, а какие можно отложить до следующего релиза в порядке приоритета и серьезности багов. Таким образом тестирование завершается по истечении времени.

Читать дальше →

Уровни Тестирования (Testing Levels) в Тестировании ПО

В Тестировании ПО можно выделить 4 типичных уровня Тестирования:

Уровни Тестирования (Testing Levels)
Модульное Тестирование (Unit Testing)
— модуль это наименьшая функциональная часть программы или приложения, которая не может функционировать отдельно а только лишь в сочетании с другими модулями. Тем не мение после разработки этого модуля мы уже можем приступить к тестированию и найти несоответсвия с нашими требованиями. Модульное тестирование заключается в тестировании этого отдельного модуля, как части программы, подразумевая что это только модуль и он не может существовать самостоятельно и являтся частью приложения, программы

Интеграционное Тестирование (Integration Testing)
— следующий уровень тестирования, который проводится после Модульного тестирования. После того как отдельные модули нашего приложения были протестированы, нам следует провести Интеграционное Тестирование, чтобы убедиться что наши модули успешно функционируют в связке друг с другом. Иными словами тестируем 2 и более связанных модуля, с тем чтобы проверить что интергация прошла успешно и без явных багов

Читать дальше →

Что такое Тестирование Черного Ящика (Black box testing) ?

Черный ящик (Black box testing)
Что такое тестирование Черного Ящика — это стратегия или метод тестирования, базируется только лишь на тестировании по функциональной спецификации и требованиям, при этом не смотря во внутреннюю структуру кода и без доступа к базе данных. Фактически мы знаем какой должен быть результат при определенном наборе данных, которые подаються на вход. Результат проверяем с юзер интерфейса на уровне простого пользователя. На данный момент такая стратегия является наиболее часто применима в IT компаниях.

black box testing

Серый ящик (Grey box testing)
Чуть меньшее количество тестировщиков тестируют стратегией серого ящика, который подразумевает частичный доступ, например к структуре баз данных или наборов параметров, которые принимают сервисы.

Белый ящик (White box testing)
Наименьшая часть тестировщиков, способны анализироваь чужой код и заниматься написанием тестов даже не запуская программу или приложение а только базируясь на коде, эта стратегия называеться белым ящиком. Может использоваться в дополнение к черному и серому ящикам. Таких специалистов на рынке очень мало, и они скорее всего бывшие разработчики ушедшие в тестирование или увлекающиеся программированием.

Читать дальше →

Критерии качества требований программного обеспечения

Требования к приложению или новой фитче имеют очень высокую важность с точки зрения тестирования ПО. Но так как требования не всегда могут быть описаны документально то основным критериям качества требования является сам факт наличия этих требований к ПО. Сами же требования должны удовлетворять критериям качества, которые распишем ниже.
Требования к требованиям
Всего критериев качества требований можно выделить девять:

Корректность
Бывает что в требованиях допускают ошибки при составлении таковых. Это можно обнаружить проанализировав требования целиком, найдя еще одно место где есть расхождения с предыдущим значением, к примеру некорректная необходимая процентная ставка по кредиту в банковском приложении, но если это место уникально то такую неточность тестировщику может оказаться распознать проблематично и только пользователь или тот кто детально введен в курс дела по точности данных, может распознать и исправить ее.
Корректность требований
Недвусмысленность
Точность формулировки в требованиях может по-разному интерпретироваться тестировщиками, разработчиками и другими участниками проекта. Проблема возникает из-за того что требования пишутся на «естественном языке» и разные члены команды, относящиеся к разным группам настолько привыкли к своей интерпретации слов или фразы что им уже сложно предстать что это для кого-то другого имеет совершенно другой смысл.
Полнота
Часто в требованиях забывают описать валидации на поля или единицы измерения в каких будет показываться значения или даже целые секции, которые могут быть пропущены по невнимательности.
Непротиворечие
Конфликты в описании одного и того же функционала в разных частях требований зачастую находятся посредством механического анализа. Одна часть требований может гласить что на какое-то действие нужно выполнять то-то, в тоже время как в другой части требований можно найти что та же самая функциональность должна выполнять что-то другое.

Читать дальше →