Введение

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

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

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

Риск возникновения сбоя есть всегда, однако для уменьшения рисков и существует такой процесс как тестирование.

Что такое тестирование

Говоря простым языком, тестирование — это процесс проверки чего-либо на качество, будь то новая плита на кухне или приложение в телефоне. Используя их, ты неосознанно запускаешь процесс тестирования. Можно ли установить плиту на твою кухню? Включается ли она и нагревает ли сковороду? Если всё работает так, как заявлено, то можно считать, что тестирование проведено успешно, качество хорошее, проблем не обнаружено.

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

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

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

Но если быть точным, QA (Quality assurance) — это совокупность методов и действий, обеспечивающих и повышающих качество не только самого продукта на выходе, но и качество работ, проводимых при его создании, т. е. QA ориентировано больше на процесс. Тогда как тестирование — это выполнение работ по обнаружению дефектов, т. е. не тестирование равно качеству, а QA равно качеству. Цель QA — предотвратить возможные ошибки в ПО, повышая тем самым качество, а цель тестирования — найти и исправить ошибки в ПО. С ними рядом всегда есть Quality Control — процесс, контролирующий выполнение запланированных действий и методов.

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

Наш курс — о тестировании программного продукта, так вот, давайте обсудим, как получается продукт и почему, собственно, тестирование необходимо. Рассмотрим простой пример: в компании существует отдел бизнес-аналитики, отдел разработки и тестирования. В основном это три главных составляющих при создании продукта.

Логично, что всё начинается с идеи, будь это просто идея, возникшая в чьей-то голове, или требование рынка. Затем эта идея обмозговывается, и по ней проводится аналитика. На этапе аналитики принимается решение, каким образом будет реализовываться продукт, тут же прописывается документация продукта (требования, спек (от англ. specification)). Затем наступает фаза разработки, когда программисты-разработчики перекладывают требования на код. После этого продукт передаётся в руки тестировщиков, которые проверяют его качество. И уже по окончании тестирования продукт передаётся заказчику в пользование, это так называемый релиз или выпуск (release, golive). Этот этап еще называется “выход в прод” (от англ. Production).

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

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

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

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

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

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

Более того, цели могут варьироваться в зависимости от контекста тестирования, уровня тестирования и модели жизненного цикла. В дальнейшем в курсе мы рассмотрим эти цели.

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

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

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

И последнее в этом уроке.

В тестировании есть принципы, которые следует знать и понимать, они являются общим руководством для тестирования.

• Тестирование показывает, что дефекты есть. Однако, оно не доказывает отсутствие дефектов. Тестирование всего лишь уменьшает риски появления дефектов, проверяя компоненты и системы продукта.
• Полное тестирование невозможно. Представьте себе форму ввода суммы перевода, где возможно перевести сумму до ста тысяч рублей. Возможно, кому-то сто тысяч тестов на проверку каждого возможного значения покажутся посильным трудом, однако это не имеет смысла. Бывают случаи с ещё большим количеством возможных значений. Так вот, протестировать все значения невозможно, да и не имеет смысла.
• Раннее тестирование. Тестирование должно начинаться настолько рано, насколько это возможно. Тут вроде бы все понятно: чем раньше подключим тестирование, тем более повысим качество разработки.
• Скопление дефектов. Существует такой феномен: большинство дефектов скапливается в небольшом количестве компонентов ПО. Этот принцип помогает спланировать тестирование, делая фокус на такие компоненты.
• Парадокс пестицида. Этот принцип заключается в том, что один и тот же набор тестов со временем приносит всё меньше и меньше результатов, т. е. не находит дефектов, поэтому необходимо со временем улучшать и изменять тесты, условия выполнения для них и набор входных данных.
• Тестирование контекстно зависимо. Это значит, что тестирование различных продуктов будет отличаться, например тестирование медицинского оборудования тестируется иначе, чем коммерческое приложение.
• Заблуждение об отсутствии дефектов. Если большинство дефектов найдено и исправлено, неверно полагать, что их больше нет. И это не значит, что продукт построен идеально, отвечает ожиданиям пользователя или он прост и удобен в использовании.

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

• Требования включают много различных понятий: спек (specification), ТЗ (техническое задание), пользовательская история (user story, “юзер-стори”). Все они, по сути, являются документом, на который опирается тестировщик и другие участники процесса при работе. В этих документах описаны условия выполнения тестов, поведение продукта при различных манипуляциях.

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

Спек (specification) — документ, который определяет, в идеале полным, точным и поддающимся проверке образом, требования, дизайн, поведение или другие характеристики компонента или системы.

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

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

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

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

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

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

А что если что-то пошло не так, и пользователь не попал на страницу блога?

Тогда возникает дефект.

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

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

• В такой ситуации, чтобы исправить проблему, тестировщик должен заявить о ней, для чего он заводит баг-репорт (bug-report). Это документ, в котором описан дефект и указан его приоритет для исправления.

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

Помимо этого, есть статическое тестирование, осуществляемое без выполнения каких-либо функций в программе. Например, если бы требования звучали так: “Пользователь с учётными данными после ввода их на форме авторизации нажимает на кнопку Войти”. Возникает неопределенность: что должен получить пользователь после нажатия на кнопку? Если тестировщик не обратит на это внимание, то разработчик сможет закодировать программу так, как ему вздумается, и этот результат может отличаться от нужд заказчика.

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

На основе требований тестировщики составляют тест-кейсы (Test case). Это набор действий и входящих данных, а также условий, в которых должен проходить тест, и ожидаемого поведения приложения.

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

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

В этой части мы с вами обсудим стадии тестирования от планирования до завершения.

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

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

Давайте познакомимся с каждым этапом.

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

Итак, что же всё-таки необходимо учесть при планировании?

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

Контроль тестирования нужен для понимания правильности действий, координации команд и принятия мер, если процесс отклоняется от плана.

Создание или проектирование тест кейсов — это трансформация требований в конкретные тесты, а именно тест-кейсы, которые содержат в себе:

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

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

При работе с требованиями важно учитывать следующие аспекты:

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

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

Перед выполнением тестов происходит настройка окружения, подготовка входных данных. Затем начинается само выполнение тестов, запись результатов, выходных данных, сравнение результатов: ожидаемого и фактического, создание баг-репортов. После исправления дефекта происходит так называемый ре-тест (re-test, “повторный или подтверждающий тест”), позволяющий убедиться, что дефект исправлен.

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

Психология тестирования

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

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

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

Давайте рассмотрим уровни независимости тестирования:

1. Тестирование за собой, т. е. проверка своей же работы.
2. Тестирование другим человеком из своей же команды, например другой разработчик перепроверяет твой код (выполняет review).
3. Тестирование, которое могут провести люди из другой группы в твоей организации.
4. И, наконец, тестирование, которое может быть проведено совершенно независимой группой, например команда тестирования из аутсорса.

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

В чём преимущества независимого тестирования? Оно помогает сфокусироваться на проверке качества продукта, не смешивая человеческие отношения в группе.

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

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

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

1. Не злорадствуй — ты тоже не идеален.
2. Не обвиняй — в ошибке, вероятно, виновата группа, а не кто-то один.
3. Используй конструктивную критику при обсуждении и заведении дефектов — не критикуй конкретного человека.
4. Объясни, что, найдя такую ошибку, мы можем исправить или обойти её, чтобы продукт стал качественнее и лучше.
5. Объясни риски — к чему может привести такая ошибка.
6. Расскажи, как необходимо это исправить.
7. Начинай с взаимодействия, а не с конфликта — мы работаем в команде, и у нас есть общие цели.
8. Убедись, что тебя правильно поняли и наоборот.

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

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