Настроить эксперимент можно в «Яндекс Аудиториях». Подробнее о процессе написано в блоге «Яндекса». К количественным метрикам можно применить метод статистического анализа и понять, достоверны ли итоги сплит-тестирования.

Интеграционное тестирование направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования. Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции. Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.

Требования

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

Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит. Сценарий использования — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы). Таблицы принятия решений — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения. Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Инструменты интеграционного тестирования

Есть пункт "Залогинься с правами администратора" — отлично, но как это сделать? Увидев этот пункт, я пойду искать кого-нибудь, кто в курсе, есть ли тестовый пользователь с такими правами и какие у него логин и пароль. Пункт "Нажми на кнопку "Войти" в правом верхнем углу экрана" содержит много подробностей про пользовательский интерфейс. Если кнопка в новой версии программы переедет в другое место, то придется вносить исправление и в тест-кейс.

Чем меньше в документации зависимость от UI (user interface, пользовательский интерфейс), тем лучше. Исключение составляет дымовой тест, проводящийся после обновления PROD-системы . Тестовый набор для этого создается отдельно и тщательно выверяется. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций).

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

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

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

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

Пять советов по управлению ожидаемыми результатами проекта и их отслеживанию

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

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

Санитарная проверка (Sanity check)

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

Плавающие баги: основные ошибки и как охотиться.

Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Тривиальная - ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие шрифта и оттенка и т.д. Minor - часто ошибки GUI, которые не влияют ожидаемый результат на функциональность, но портят юзабилити или внешний вид; либо незначительная функциональная ошибка, не нарушающая бизнес-логику тестируемой части приложения. Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться).