ОБЗОР РОССИЙСКОЙ СИСТЕМЫ УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ TEST IT

Тест-планы

Главная

Переходим на вкладку тест-планы. Она выглядит так: 

На главной странице по умолчанию отображаются все активные тест-планы. У каждого есть название, а у статуса прохождения кейсов — графическое отображение. Также имеется поиск.

Тест-план можно редактировать, дублировать и архивировать, а если нужно восстановить. При создании или редактировании помимо стандартного названия и описания есть возможность указать следующие данные: 

• дата начала и окончания;

• время прохождения тестов;

Создание тест-плана

Создадим набор тестов. Для этого нажмем на кнопку «Создать набор тестов», расположенную в левом боковом меню.

Открыто окно создания набора тестов. Здесь мы можем разными способами найти нужные нам кейсы.

Фильтрация реализована именно по названию тест-кейсов. Искать по названию подраздела не выйдет. Зато касательно разделов и подразделов на помощь придет выбор секции.

Еще можно добавить разные фильтры: например, все неавтоматизированные кейсы или кейсы с самым высоким приоритетом.

Когда мы выбрали все необходимые кейсы, можно сохранить тест-план, нажав на дискетку. Тест-план собран — давайте взглянем, как он выглядит.

В верхней части экрана расположен информационный блок. В нем мы можем: 

• увидеть название, дату создания, автора;

• заблокировать прохождение тест-плана;

• просмотреть журнал изменений;

Далее у нас идет разделение на 3 экрана: 

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

Планирование

Теперь спланируем тест-план. Для начала укажем конфигурацию по разным браузерам.

Чтобы конфигурации появились в этом списке, необходимо предварительно добавить конфигурации во вкладке «Конфигурации». После выбора конфигураций в тест-плане появятся дополнительные колонки, соответствующие выбранным конфигурациям. 

Распределим наши тест-кейсы между коллегами. У Test IT есть возможность равномерного распределения тест-кейсов между всеми участниками. Для этого нужно нажать на кнопку «Распределить» и выбрать людей.

Не надо думать, кому и что отдать. Система сделает все сама. Получилось вот такое распределение:

Если есть желание указать конкретное распределение, то так тоже можно сделать: например, все кейсы по любимому браузеру можно отдать одному человеку, чтобы страдал только он)

После назначения все участники получат уведомления.

Итак, тест-план собран, участники назначены, конфигурации определены. 

Пожалуйста, только не пытайтесь выставить статус тест-кейсу на вкладке «Планирование», как это делала я. Ничего не получится, потому что на этой вкладке только информативный значок) Возможности выставить статус пройденному кейсу здесь нет.

Выполнение

Переключимся на вкладку «Выполнение». Как тестировщик я первым делом хочу увидеть все кейсы, которые назначены именно мне. Для этого в Test IT есть фильтр, где можно выбрать нужного участника, и отобразятся кейсы, назначенные только ему.

С точки зрения восприятия лично мне не хватает цветового разделения блоков. Предусловия, шаги и постусловия словно сливаются в одну страницу. Но любую секцию можно свернуть. Я свернула предусловия, и восприятие текста стало получше. Если в тест-плане вы свернете какие-то секции, то в следующем кейсе они также будут в свернутом состоянии. Что же интересного мы можем увидеть в карусельке прохождения тестов? 

В самом верху отображается справочная информация: 

• время на прохождение;

• секция из которой тест-кейс;

• название тест рана;

Выставить тест-кейсу статус прохождения можно тремя способами: в правом боковом меню, в предусловиях или в постусловиях. О третьем способе расскажу чуть позже.

У бокового меню 3 вкладки:

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

После идут статусы. Возможности добавить определенные статусы я не нашла. Однако мне не хватило в этом списке такого статуса как «Перепройти». Было бы удобно, если бы статусы можно было добавлять. После статусов идут поля для указания комментария, ссылки и загрузки вложения. 

Прикрепленная ссылка Jira потом отображается в тест-плане в разделе выполнение. В разделе «Планирование» ссылки не будет видно. Кликнув по ней, вы перейдете по ссылке в новой вкладке. В самой Jira результат прохождения теста не отображается.

Если в карусельке вернуться на пройденный тест, то будет отображаться кнопка «Перепройти тест». Это то, что касается проставления результатов каждого отдельного теста. А что если мы хотим проставить результат сразу нескольким тестам?

Отчет

Тест-план пройден, результаты выставлены, задачи заведены. Теперь можем перейти во вкладку «Отчет». Отчетность по пройденному тест-плану выглядит так:

Сверху отображается общая информация и диаграмма распределения тестов по результатам. Ниже идет диаграмма распределения тестов по специалистам со статусами. Далее отображены дефекты со ссылками на задачи и указанием конфигурации. В самом низу есть еще один блок — «Результаты прогонов тестов».

Узнайте больше о тестировании и инструментах

Как обучать тестировщиков стандартам процессов тестирования

Как повысить качество покрытия релизов тестами. Инструкция Lamoda Tech

Гибридный подход к тестированию против парадокса пестицида. Кейс Lamoda Tech

Test IT завершила первый этап разработки грантового проекта РФРИТ

Вроде успеваем, или Как релизиться в срок

ПСБ внедрил систему управления тестированием ПО Test IT

Система управления тестированием

Test IT создана тестировщиками для тестировщиков. Удобно для инженеров, прозрачно

для руководителей.

Enterprise или Cloud — выбирайте под ваши потребности.

Нагрузочное тестирование (Load testing)

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

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

Для нагрузочного тестирования создается тест-сценарий, который имитирует действия пользователя на сайте, например:

1. Пользователь открывает главную страницу магазина.

2. Пользователь ищет товары по определенным категориям.

3. Пользователь добавляет товары в корзину.

4. Пользователь оформляет заказ.

Тест-сценарий запускается под разной нагрузкой, например, с одновременным выполнением скрипта на 100, 500 и 1000 пользователей. Анализ результатов тестирования помогает определить, как много пользователей приложение может обрабатывать одновременно, не замедляя работу и не выходя из строя.

Кто пишет тесты:
нагрузочные тесты обычно пишутся командой QA-инженеров.

Тестирование на производительность (Performance testing)

Тестирование на производительность проверяет производительность продукта при различных нагрузках и условиях использования. Цель – убедиться в том, что продукт может обрабатывать большое количество запросов сохраняя скорость и стабильность.

Отличие между тестированием на производительность и нагрузочным тестированием заключается в целях тестирования.

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

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

Пример.
Как пример теста на производительность используем пример нагрузочного тестирования. Те же условия, тот же тест-сценарий, но главное отличие будет в фокусе тестирования, т.е. в том, на какие показатели будут смотреть тестировщики.

Тестирование на производительность и тестирование на нагрузку могут быть взаимосвязаны и часто проводятся вместе.

Кто пишет тесты:
тестирование на производительность обычно пишет команда QA-инженеров.

Дашборд

Переходим во вкладку дашборд. Он будет полезен для просмотра и анализа какой-либо информации, а также сбора статистики.

Информация представляется в разных форматах с помощью виджетов. Используя их, можно как угодно настроить интерфейс вкладки:

• круговая или линейчатая диаграммы;

Под каждый виджет можно настроить свой фильтр и параметры отображения. 

Например, на скриншоте видны настройки виджета «Тенденция». Таким образом для любого виджета мы можем указать название, формат отображения данных, тип данных, будь то тесты или результаты прохождения тестов, либо автотесты, а также указать критерий для группировки данных. 

Продукты и его особенности

Команда

Функциональное тестирование (Functional testing)

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

Функциональное тестирование проверяет отдельные функции и возможности приложения, а интеграционное тестирование проверяет взаимодействие компонентов системы в целом.

Пример.
Веб-приложение для онлайн-бронирования номеров в отеле. Функциональное тестирование поможет убедиться в том, что приложение работает корректно и выполняет свои функции.

Возможный сценарий тестирования:

1. Пользователь открывает веб-страницу приложения и выбирает нужную дату заезда и выезда.

2. Приложение отображает свободные номера в отеле на выбранные даты.

3. Пользователь выбирает номер и вводит свои данные для бронирования.

4. Приложение подтверждает бронирование и отправляет подтверждение на электронную почту пользователя.

Кто пишет тесты:
функциональные тесты обычно пишутся командой QA-инженеров.

ПРИМЕЧАНИЕ:
Пара слов о End-to-End(E2E) тестировании, это тестирование, которое позволяет проверить работу всей системы или приложения с точки зрения пользователя от начала до конца (от “end” – начала, до “end” – конца).

Оно включает в себя проверку основных сценариев использования приложения – от взаимодействия пользователя с интерфейсом до проверки корректности ответа сервера. Также при E2E тестировании проверяются функциональные возможности приложения, такие как формирование отчетов, работа с базами данных и другие.

Таким образом, E2E тестирование можно рассматривать и как функциональное и как интеграционное.

Стандарты, относящиеся к тестированию

Интеграционное тестирование (Integration testing)

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

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

ВАЖНО:
Корректность обработки ошибок – это часть любого вида тестирования.

Интеграционное тестирование выполняется как вручную, так и автоматизированно с использованием специальных инструментов, таких как Postman или SoapUI.

Пример.
Приложение для онлайн-оплаты, которое включает в себя: веб-интерфейс, API для обработки платежей и базу данных для хранения информации о платежах. Интеграционное тестирование поможет убедиться в том, что компоненты работают корректно вместе.

Один из возможных сценариев тестирования:

1. Запрос на создание нового платежа отправляется через веб-интерфейс.

2. API для обработки платежей получает запрос и создает новую запись в базе данных.

3. Веб-интерфейс получает уведомление о создании нового платежа и отображает его в списке платежей на странице.

4. Пользователь проверяет, что новый платеж отображается на странице, и подтверждает его.

Кто пишет тесты:
Интеграционные тесты обычно пишутся командой QA-инженеров.

Клиенты и партнёры

Уже пользуются

Все тесты в одном окне

Ручные и автотесты в едином интерфейсе с прозрачной отчётностью

Лёгкая интеграция

Интеграция с таск-трекерами, с системами CI/CD, AQA фреймворками

Гибкость и отзывчивость

Регулярные обновления, техподдержка на русском, бесплатный пробный период

Чек-лист

В системе есть возможность создать чек-лист.

Как мы помним, чек-лист — это кратко описанная последовательность действий, которые нужно проверить. В нем отсутствуют ожидаемые результаты. Тест-кейсы же пишутся максимально подробно, чтобы было понятно любому человеку в команде. В них всегда отражен ожидаемый результат. Мы в командах используем чек-листы для проверки больших пользовательских сценариев. А теперь давайте посмотрим как чек-лист выглядит в Test IT:

В чек-листах есть те же функциональности, что и у тест-кейсов. Различие только в том, что нет предусловий, ожидаемого результата в шагах и постусловий. Но есть волшебная кнопочка «Преобразовать в тест-кейс».

Один взмах волшебной палочкой
клик, и чек-лист превратился в тест-кейс. 

Тестирование «белого ящика», «чёрного ящика» и «серого ящика»

Статическое и динамическое тестирование

Модульное тестирование (Unit testing)

Модульное тестирование выполняется на уровне отдельных блоков приложения. Это может быть тест, который проверяет корректность работы отдельной функции или React-компонента.

Пример.
Функция на JavaScript принимает два числа и возвращает сумму. 

Пример модульного теста, который проверяет работу этой функции:

   function sum(a, b) {									
  return a + b;										
}																								
describe('sum', function() {								
  it('should return 4 when 2 and 2 are passed', function() {		
    expect(sum(2, 2)).toEqual
;							
  });												
												
  it('should return 10 when 7 and 3 are passed', function() {		
    expect(sum(7, 3)).toEqual;							
  });												
												
  it('should return -3 when -5 and 2 are passed', function() {		
    expect(sum(-5, 2)).toEqual(-3);						
  });												
});	  
  

Кто пишет тесты:
модульные тесты обычно пишет сам автор кода.

ПРИМЕЧАНИЕ:
я написал обзорную статью

на библиотеку React-testing-library, в ней подробно рассказывается, как покрыть unit-тестами React-компонент.

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing)
— проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования
— проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Для чего проводится тестирование ПО?

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

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

• Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
  .

  Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.

• Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible)
  .

  Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).

• Принцип 3 — Раннее тестирование (Early testing)
  .

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

• Принцип 4 — Скопление дефектов (Defects clustering)
  .

  Большая часть дефектов находится в ограниченном количестве модулей.

• Принцип 5 — Парадокс пестицида (Pesticide paradox)
  .

  Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.

• Принцип 6 — Тестирование зависит от контекста (Testing is context depending)
  . Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
• Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
  . Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA — Quality Assurance)
и контроль качества (QC — Quality Control)
— эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC
(Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

• проверка готовности ПО к релизу;
• проверка соответствия требований и качества данного проекта.

QA
(Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

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

Верификация и валидация
— два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.

Верификация (verification)
— это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.

Валидация (validation)
— это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

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

1. Проектная документация — включает в себя всё, что относится к проекту в целом.
2. Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.

Этапы тестирования:

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

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

Программный продукт проходит следующие стадии:

1. анализ требований к проекту;
2. проектирование;
3. реализация;
4. тестирование продукта;
5. внедрение и поддержка.

Требования

Требования
— это спецификация (описание) того, что должно быть реализовано.

Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.

1. Корректность
   — точное описание разрабатываемого функционала.
2. Проверяемость
   — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
3. Полнота
   — в требовании должна содержаться вся необходимая для реализации функциональности информация.
4. Недвусмысленность
   — требование должно содержать однозначные формулировки.
5. Непротиворечивость
   — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность
   — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
7. Атомарность
   — требование нельзя разбить на отдельные части без потери деталей.
8. Модифицируемость
   — в каждое требование можно внести изменение.
9. Прослеживаемость
   — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug)
— отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report)
— документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

1. Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
   
2. Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
3. Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
4. Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
   
5. Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
6. Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
   
7. Вложения (Attachments) — скриншоты, видео или лог-файлы.
8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
9. Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
10. Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
11. Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity)
показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

• Блокирующий (S1 – Blocker)
  

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

• Критический (S2 – Critical)
  

  критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.

• Значительный (S3 – Major)
  

  не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.

• Незначительный (S4 – Minor)
  

  часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.

• Тривиальный (S5 – Trivial)
  

  почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority)
показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

• P1 Высокий (High)
  

  Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.

• P2 Средний (Medium)
  

  Не критичная для проекта ошибка, однако требует обязательного решения.

• P3 Низкий (Low)
  

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

Существует шесть базовых типов задач:

• Эпик (epic)
  — большая задача, на решение которой команде нужно несколько спринтов.
• Требование (requirement )
  — задача, содержащая в себе описание реализации той или иной фичи.
• История (story)
  — часть большой задачи (эпика), которую команда может решить за 1 спринт.
• Задача (task)
  — техническая задача, которую делает один из членов команды.
• Под-задача (sub-task)
  — часть истории / задачи, которая описывает минимальный объем работы члена команды.
• Баг (bug)
  — задача, которая описывает ошибку в системе.

Тестовые среды

• Среда разработки (Development Env)
  – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
• Среда тестирования (Test Env)
  – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
• Интеграционная среда (Integration Env)
  – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
• Предпрод (Preprod Env)
  – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
• Продакшн среда (Production Env)
  – среда, в которой работают пользователи.

Основные фазы тестирования

• Pre-Alpha:
  прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
• Alpha:
  является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
• Beta:
  практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
• Release Candidate (RC)
  : возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
• Release:
  финальная версия программы, которая готова к использованию.

Основные виды тестирования ПО

Вид тестирования
— это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

Тест-дизайн
— это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Автор книги ” A Practitioner’s Guide to Software Test Design
“, Lee Copeland, выделяет следующие техники тест-дизайна:

1. Тестирование на основе классов эквивалентности (equivalence partitioning)
   — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
2. Техника анализа граничных значений (boundary value testing)
   — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
3. Попарное тестирование (pairwise testing)
   — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
4. Тестирование на основе состояний и переходов (State-Transition Testing)
   — применяется для фиксирования требований и описания дизайна приложения.
5. Таблицы принятия решений (Decision Table Testing)
   — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
6. Доменный анализ (Domain Analysis Testing)
   — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
7. Сценарий использования (Use Case Testing)
   — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Тестирование белого ящика
— метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

• тестирование, основанное на анализе внутренней структуры компонента или системы;
• тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
• Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика
— метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

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

Согласно ISTQB, тестирование черного ящика — это:

• тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
• тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

• Что необходимо протестировать?
• Как будет проводиться тестирование?
• Когда будет проводиться тестирование?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Основные пункты тест плана:

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

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case)
— это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

• Предусловия (PreConditions)
  — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
• Шаги (Steps)
  — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
• Ожидаемый результат (Expected result)
  — что по факту должны получить.

Резюме

1. ISO/IEC TR 19759:2005 ( SWEBOOK
   )

4. ANSI/IEEE standart 610.12-1990 Glossary of SE technology NY:IEEE, 1987
5. Sommerville I.
   Software Engineering, 8th ed. Harlow, England: Pearson Education, 2007

6. Стандартный глоссарий терминов, используемых в тестировании программного обеспечения, версия 2.3, под ред. Erik van Veenendaal // International Software Testing Qualifications Board (ISTQB), 2014
8. Software and systems engineering Software testing Part 1:Concepts and definitions
    // ISO/IEC/IEEE 29119-1:2013(E). — 2013-09-01. — . — doi
   : 10.1109/IEEESTD.2013.6588537
   . Архивировано
   18 декабря 2016 года.
   
   

Тесты

Далее проваливаемся в наш проект и попадаем на вкладку тесты. Выглядит она вот так:

В боковом меню — структура проекта. Рядом отображаются все тест-кейсы с названиями разделов и указанием вложений.

Все колонки, кроме ID и Тип, можно менять местами. Также можно выбрать, какие конкретно колонки мы хотим отображать. Это очень удобно — я настроила визуальный интерфейс под себя. 

Есть строка поиска, чтобы найти конкретный кейс.

Чтобы добавить новый тест-кейс или чек-лист, нужно нажать на кнопку «+», выбрать создание тест-кейса/чек-листа, ввести данные и сохранить.

В Test IT есть возможность поработать с группой тест-кейсов (групповое редактирование). Когда выделяете несколько кейсов или целую секцию, появляется меню для работы с ними. Таким образом выделенные кейсы можно: 

• экспортировать в XLSX.

Тест-кейс

Посмотрим, как выглядит сам тест-кейс. Когда мы проваливаемся в него, он сразу открыт в режиме редактирования.

Тест-кейс состоит из четырех разделов, не считая бокового меню: предусловия, шаги, постусловия (то, что необходимо сделать после прохождения данного тест-кейса) и входные параметры. Интересно отметить, что в предусловиях теста мы можем указать не просто шаг, но и ожидаемый результат, если необходимо.

В разделе «Входные параметры» указываем тестовые данные: в самом шаге создаем параметр при помощи %, а значение — в разделе.

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

Отдельное внимание стоит уделить возможности редактировать текст так, как тебе хочется:

• сделать шрифт курсивом или жирным;

• подчеркнуть или зачеркнуть что-либо;

• добавить ссылку или картинку (скриншот);

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

Все изменения, внесенные по тест-кейсу, фиксируются в журнале изменений. В нем отображается, кто, когда и какие изменения вносил. Зеленым цветом выделены сами изменения.

Кстати, чтобы выйти из просмотра журнала изменений, нужно снова кликнуть на значок журнала. Одна кнопка отвечает за включение и выключение просмотра — не слишком очевидно.

Администрирование

В Test IT достаточно гибкая система администрирования, у нее есть несколько разделов.

В разделе «Пользователи» можно добавлять и удалять пользователей, у которых есть доступ к системе. В группах — добавленных пользователей разбить по группам, например, site_qa и mobile_qa. В разделе интеграции — создать интеграционное взаимодействие со сторонней системой, например, в нашем случае это Jira. На данный момент вариантов немного: Jira и Azure devOps. 

В следующих разделах можно присвоить пользователям проектные и системные роли. В разделе подключений — создать AD/LDAP подключение. Далее указаны текущие лицензии и возможность добавить новую. В разделе «Атрибуты» можно добавить свои атрибуты. Причем это могут быть проектные атрибуты или глобальные, а также шаблон атрибута. Любой проектный атрибут можно превратить в глобальный.

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

С администрированием разобрались 🙂 Ну, и напоследок.

Нашей команде очень понравилась темная тема, но есть еще и другие.

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

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

Автоматизированное тестирование (Automated testing)

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

Автотесты имеют ряд преимуществ перед ручным тестированием, например:

• Эффективность и экономия времени:
  выполняются быстрее, чем ручные, и могут работать 24/7 без остановки.

• Повторяемость:
  можно повторять бесконечное количество раз с одинаковой точностью и результатами.

• Объективность:
  исключается влияние субъективного мнения и человеческих ошибок.

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

Пример:
примером может быть любой из приведенных выше, если это тестирование было автоматизировано.

Кто пишет тесты:
Автоматизированные тесты обычно пишутся командой QA-инженеров.

Профиль

У каждого пользователя есть страница личного профиля. В ней отображена основная информация:

• общая сводка по пройденным тест-поинтам;

• данные об уровне пользователя (ачивки).

Нашей команде очень понравились ачивки. При выполнении разных активностей вы достигаете определенного уровня: