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

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

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

Тестирование

Оно выполняется с целью выявления ошибок, неполадок vs нежелательного поведения программного продукта.

Определение слова “тестирование” имеет много значений. Рассмотрим основные:

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

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

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

Цели тестирования

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

Цели

• Проверка, все ли указанные требования выполнены. Что это значит? У каждого продукта есть техническое задание (ТЗ) в том или ином виде. Именно оно определяет, как будет выглядеть программа. ТЗ задает соответствующие требования, а мы, как тестировщики, должны проверить, что все требования из ТЗ не только реализованы, но и работают правильно.
• Создание уверенности в уровне качества объекта тестирования. Напрямую тестирование не влияет на качество продукта.
• Предотвращение дефектов. Тестирование — не только поиск багов на уже реализованном продукте. Существует также тестирование на более ранних этапах, например, тестирование документации. Заранее протестировав тоже ТЗ, тестировщик может указать на потенциальные проблемы, которые могут появиться в результате разработки программы.
• Обнаружение отказов. Здесь все просто. поиск багов в программном обеспечении (ПО) является неотъемлемой частью тестирования.
• Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения. Тестировщики не влияют напрямую на исправление, но могут показать текущее состояние продукта, выраженное в количестве багов, путем оформления баг-репортов.
• Снижение уровня риска ненадлежащего качества программного обеспечения (например, пропущенные сбои в работе). Чем лучше тестирование, тем меньший риск пропуска критичных багов. А значит, что риск возникновения ненадлежащего качества ПО уменьшается.

Техники тест дизайна, о которых пока нигде не слышал: ????

Илларион

    О техниках “Разговорчики-driven”, “Analytics-driven”, “Bug-driven” я пока нигде не слышал.

    ️ Интервьюеры могут быть отличниками, которые ограничиваются только книжными понятиями и не выходят за рамки (thinking out of the box). Поэтому будьте аккуратны с озвучиванием этих техник интервьюеру, особенно, если у вас проблемы с объяснением и примерами)) Не ограничивайте себя существующими техниками, думайте, фантазируйте.

Разговорчики-driven (talks-driven)

Собираем в одной комнате/звонке одного или нескольких программистов, менеджеров, клиентов, тестировщиков и тд. И начинаем допрос о конкретной функции или всей системе.

    Если фантазия не работает, то задаем Wh-вопросы:

what, when, where, who, whom, which, whose, why and how – что, когда, где, кто, кому, какой, чей, почему, как

    Для продвинутых: сначала собираем всех по одному, а потом по несколько человек. Не выпускаем, пока не получим все ответы и не решим какие тесты проектировать.

Аналитика-driven (analytics-driven)

    Если на проекте используется аналитика, например при кликах на кнопки или при открытии страниц отправляются ивенты (events) в систему для аналитики, то можно использовать данные аналитики для составления тест кейсов.

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

Баг-driven (bugs-driven)

    Принцип тестирования №4 Скопление дефектов (Defects clustering) гласит, что “большая часть дефектов содержится в небольшом количестве модулей”.

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

    Дополнительно можно посидеть над найденными багами и подумать “а может ли аналогичный баг быть в другой части системы?”.

Как проверить, работает ли тест

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

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

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

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

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

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

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

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

Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы: 

• Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе. 

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

• Техники серого ящика позволяют тестировать продукт, когда специалист частично знает его внутреннее устройство. Для выполнения тестирования «серого ящика» не нужен доступ к исходному коду. 

Как пишутся тесты

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

Вот пример сбора требований. Допустим, что у нас есть функция , которая обрезает строку, если она длиннее N символов. Каким требованиям она должна соответствовать?

• если передать ей строку из 5 символов и = 10, функция должна вернуть строку без изменений
• если передать ей строку из 11 символов и = 5, то функция должна обрезать строку до

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

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

На каждое требование мы пишем отдельный тест – это позволит при ошибке понять, что именно сломалось. Тесты обычно пишут в стиле Arrange, Act, Assert. Мы сначала подготавливаем и настраиваем нужные компоненты (Arrange), выполняем действие (Act) и проверяем результат (Assert).

class TruncateTest extends \PHPUnit\Framework\TestCase
{
    public function testShortStringRemainsAsIs()
    {
        // Act: вызываем функцию
        $result = truncate("hello", 10);
        // Assert: проверяем, что возвращенный результат совпадает с ожидаемым
        $this->assertEquals("hello", $result);
    }

    public function testLongStringIsTruncated()
    {
        $result = truncate("hello world", 5);
        $this->assertEquals("hello…", $result);
    }
}

Метод из PhpUnit проверяет, что фактический результат совпадает с ожидаемым, и выдает ошибку, если это не так. В PhpUnit много assert-функций на все случаи жизни.

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

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски. 

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

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

3. Анализ результатов и составление отчетов.  

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

Композиция теста

Шаг 1. Напишите SMART-цель

Прежде всего, необходимо сформулировать цель, ради которой будет проводиться тестирование. Хорошо, если цель будет должна строиться на методике SMART.

S (Specific)	Конкретная
M (Measurable)	Измеримая	Какая шкала теста будет использоваться? Есть ли промежуточные цели? Пояснения к примеру: Нужна шкала с уровнями «Высокий, средний, низкий» и отдельной оценкой по каждому отдельному разделу и с рекомендацией по повторному изучению разделов.
A (Ambitious)	Амбициозная	Какой истинной цели служит тест? Соотносится ли она со стратегическими или другими целями более высокого уровня? Пояснения к примеру: Настоящая цель теста – помочь авторам создавать качественные тесты, которые будут служить стратегическим задачам организаторов и участников тестирования.
R (Realistic)	Реалистичная	Достижима ли цель, согласована ли она, обеспечена ли ресурсами? Цель не должна быть слишком простой или слишком сложной. Пояснения к примеру: Цель, безусловно, достижима, если прохождению теста предшествует чтение основного материала. Также авторы должны быть мотивированы создавать качественный контент, иначе они потратят впустую свое время и время участников.
T (Time-bound)	Определенная во времени	Когда тест будет готов, когда будет проведено первое тестирование? Пояснения к примеру: Тест должен быть готов к такому-то числу, такого-то месяца и года. Первое тестирование будет проведено тогда-то.

Шаг 2. Создайте тест

После того, как Вы записали SMART-цель, Вы можете приступить к работе в StartExam:

1. Создайте шкалу оценивания (Проекты -> Шкалы) Шкала оценивания – это балльная или процентная градация результатов с названием каждого уровня, например:

2. Создайте Анкету для участников (Проекты -> Анкеты), включив в нее минимальные данные, которые Вам необходимо знать об участниках, например:

3. Создайте новый тест в Вашем проекте (Проекты –> Тесты), указав:

1. Название теста
2. SMART-цель в качестве описания теста
3. Анкету (Тест -> Авторизация)
4. Шкалу оценки (Тест -> Результаты)

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

Шаг 3. Разработайте модель теста

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

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

В Системе StartExam перейдите в Контент теста и создавайте вложенные друг в друга секции теста (разделы). Степень вложенности секций определяется Вами, однако любые две секции, находящиеся рядом на одном уровне должны иметь схожую значимость и охват с точки зрения цели теста. При соблюдении этого правила Модель теста и сам тест будут выглядеть гармонично.

Далее, используя настройки секций в StartExam, укажите, какие секции должны перемешивать свои элементы, а какие – нет. Как правило:

1. Если секция состоит из других секций (верхние уровни), ее содержимое, т.е. вложенные секции логично показывать по порядку. В этом случае именуйте подобные секции с номерами в начале (например, 01, 02, …), чтобы они показывались в нужном Вам порядке.
2. Если секция будет состоять из тестовых заданий (нижние уровни), ее содержимое, т.е. тестовые задания логично перемешивать. В этом случае укажите сразу, сколько элементов должно выбираться. Это поможет увидеть, сколько необходимо разработать тестовых заданий по данной теме, а также поможет придать необходимый «вес» данному разделу в Вашей Модели.

Каждая секция может быть иметь один из следующих типов:

Название типа	Название секции видно участникам в процессе тестирования и в результатах	Могут ли задания данной секции перемешиваться с заданиями соседних секций	Чаще всего это
Отдельная секция	Да	Нет	Секции верхнего уровня
Невидимая секция	Нет	Нет	Секции нижнего уровня
Зависимая секция	Нет	Да	Фиктивные секции

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

Требования к основным характеристикам дидактических тестов

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

1. Содержание теста должно отвечать требованиям федеральных стандартов. Поэтому, тесты строятся по большим разделам конкретной учебной дисциплины, либо, исходя из дидактических целей обучения. Возможно, также, применение смешанного подхода к построению тестовых заданий;
2. Чтобы полноценно и успешно пройти аккредитацию и получить лицензию, учебное учреждение должно проектировать тесты таким образом, чтобы они позволяли реализовывать контрольную проверку знаний на основании объективного оценивания. Тесты должны быть гибкими. Хорошо, если тестирование ориентировано на преемственность в обучении т.е. один и тот же тест должен выполнять функцию контроля знаний на определенной ступени обучения и быть вступительным экзаменом на отборе учащихся на другие образовательные ступени и уровни;
3. Разработка шкал подведения итогов для оценивания нормативных и критериальных тестовых заданий в соответствии с логикой построения учебной информации по конкретной дисциплине;
4. Дидактический тест должен быть направлен не только на контроль знаний, но и на разработку перспективных направлений развития тех или иных знаний, умений, с учетом особенностей индивидуального развития учащихся;
5. Тест должен иметь оптимальный временный лимит, отведенный на выполнение каждого задания;
6. Грамотное представление тестовых вопросов и заданий. Вопросы теста должны быть составлены грамотным языком, понятным для конкретной возрастной категории учащихся, на который он ориентирован;
7. Тест должен строится в простой и доступной для восприятия форме. У учащихся не должно возникнуть сложностей с пониманием инструкции к тесту и того, что от него требуется т.е. необходимо избегать двусмысленности и размытости в формулировках заданий;
8. Тест должен полностью соответствовать содержанию образовательной программы и по сложности соответствовать временному периоду его изучения, полноценности и объему, изученного;
9. Дидактический тест должен отвечать своему целевому назначению т.е. он должен соответствовать тому, что планируется измерять;
10. Тест должен быть надежным т.е. результаты выполнения тестовых заданий должны рационально отражать динамику освоения учебной программы.

Рисунок 2. Дидактические требования к тестам. Автор24 — интернет-биржа студенческих работ

Как различаются форматы в онлайн-тестировании?

В любых конструкторах тестов вы можете встретиться с такими форматами вопросов:

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

Дополнительные инструменты

Skipfish

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

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

PhantomJS

Также, для PhantomJS есть плагин ghostdriver (WebDriver), который позволяет подсоединиться к программе извне и управлять ей. Он использует протокол Selenium, и с его помощью PhantomJS можно управлять из codeception.

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

Статьи по использованию PhantomJS с codeception наверно нетрудно нагуглить.

Selenium

Selenium сервер написан на Яве, потому она понадобится чтобы его запустить. Поддерживаются браузеры Firefox, IE (6-11), Safari на OS X, Opera 12 (старая Опера), Chrome.

Selenium дает наиболее полноценное тестирование, так как вы можете запускать код в конкретной версии браузера (например, IE) под конкретной ОС. Но его настройка сложнее чем других инструментов, и он требует больше ресурсов. Когда выполняется тест, браузер должен быть запущен и вы не можете пользоваться компьютером, так как один лишний клик может сорвать выполнение теста. По этой причине для тестов обычно поднимают сеть вирутальных машин, в которых тесты и выполняются.

Так как настроить окружение для запуска тестов сложно, есть коммерческие сервисы (например saucelabs) которые за плату выполняют selenium-тесты на нужных браузерах и возвращают результат. Они предоставляют API с помощью которого тесты можно запускать автоматически и умеют отслеживать изменения в репозитории, тестируя код при каждом новом коммите.

Тесты в браузере содержат подвохи: например, когда вы программно нажимаете кнопку, браузеру нужно время, чтобы выполнить привязанный к ней яваскрипт, обработать изменения в DOM, перерисовать экран. Если ваш скрипт не будет дожидаться этого, а попробует сразу после нажатия кнопки проверить изменения на экране, он может их не увидеть. В некоторых статьях вы можете увидеть совет вроде «делать паузу N мс после каждого шага», но это плохие советы. Во-первых, нет гарантий, что действие выполнится за эти N мс, во-вторых, это сильно тормозит тесты. Лучше, как советует Яндекс, в таких случаях периодически проверять появление определенного элемента на странице.

Также, не так просто проверить, что элемент видим. Ведь в CSS много свойств (, , ), которыми можно его скрыть, плюс он может быть помещен за пределами экрана.

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

Также, Selenium содержит плагин к фаерфоксу (Selenium IDE), который позволяет записывать действия пользователя и генерировать из них тест (то есть повторять эти действия позже), но он, как я понимаю, довольно слабый и генерирует тяжелочитаемый код на своем странном языке. Гораздо лучше управлять Selenium из codeception и писать тесты на PHP.

Статьи:

Тестирование JS кода

Zombie.js

Вот пример теста, тестирующий позитивный сценарий успешной регистрации на некоем воображаемом сайте (код я не проверял, так что могут быть небольшие ошибки). Этот код запускается под Node.JS:

const Browser = require('zombie');

// В тесте мы будем отправлять запросы на адрес http://example.com/signup
// однако эти запросы будут обслуживаться установленным локально 
// сервером на порту 3000 с адресом localhost:3000
Browser.localhost('example.com', 3000);

// describe описывает сценарий теста, 
// причем блоки describe могут вкладываться друг в друга
describe('Пользователь заходит на страницу регистрации', function() {

  // создаем объект, имитирующий браузер
  const browser = new Browser();
  
  // Действие, выполняемое до теста - переход на нужную страницу
  before(function(done) {
    browser.visit('/signup', done);
  });

  describe('пользователь заполняет и отправляет форму', function() {

    before(function(done) {
      browser
        .fill('email',    'tester@example.com')
        .fill('password', '123456')
        .fill('password-confirm', '123456')
        .pressButton('Зарегистрироваться', done);
    });

    // it описывает конкретное требование и код для его проверки
    it('регистрация должна быть успешной', function() {
      browser.assert.success();
    });

    it('пользователь должен увидеть приветственное сообщение', function() {
      // Уведомление должно вывестись в элементе с классом notification 
      // (используется CSS-синтаксис селекторов)
      browser.assert.text('.notification', 'Вы успешно зарегистрированы');
    });
  });
});

Jasmine

describe("Math.sqtr() это функция", function() {
    it("вычисляет квадратный корень", function() {
        expect(Math.sqrt(9)).toBe(3);
    });
    
    it("возвращает нуль, если попытаться найти корень из нуля", function () {
        expect(Math.sqrt()).toBe();
    });
    
    it("возвращает NaN при попытке вычислить корень из отрицательного числа", function () {
        expect(Math.sqrt(-9)).toBe(NaN);
    });
});

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

Вот результат выполнения этих тестов в браузере, где Jasmine выводит список пройденных проверок:

Jasmine расширяемый и вы можете дописывать свои проверяльщики (matchers) и свой код для вывода результатов в удобном вам виде.

16. Defect / Error / Bug / Failure ????

Bug (defect)

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

Например, когда никак не контролируется ввод пользователя, в результате неверные данные вызывают краши (crash) или иные «приколы» в работе программы. Либо программа построена так, что изначально не соответствует тому, что от неё ожидается.

Error (ошибка)

— действие, которое привело к неправильному результату.

Пример 1 — ввод букв в поля, где требуется вводить цифры (возраст, количество товара и т.п.). Error: “поле должно содержать только цифры”.

Пример 2 – регистрация с уже существующим в системе емейлом. Error: “этот емейл уже используется”.

Failure

— сбой (причём необязательно аппаратный) в работе компонента, всей программы или системы.

То есть, существуют такие дефекты, которые приводят к сбоям. И существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Оценка тестов после их внедрения

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

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

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

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

Автоматизировать процесс тестирования вы можете с помощью платформы «АнтиТренинги». Сервис позволяет создавать тесты с автоматической проверкой, что помогает сэкономить до 90% вашего времени.

Требования к тестированию

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

Сюда можно отнести следующие критерии:

Критерии

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

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

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

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

Непротиворечивость тестирования. Описание не должно содержать внутренних противоречий. То же самое касается «несоответствий» техническому заданию и иным документам.

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

Приоритет требования представлен количественной оценкой степени важности.

Атомарность. Описание нельзя разделить на более мелкие без потери завершенности

Каждое требование описывает всего одну ситуацию.

Модифицируемость тестирования. Указывает на простоту внесения изменений в отдельные описания или их наборы.

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

Описание не может быть необязательным. Это – явное противоречие самому замыслу требований к тестированию.

Оценка тестов до внедрения

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

Хороший тест точный и надежный

Хороший тест одновременно надежный и точный. Это специальные термины, используемые для описания тестов/тестовых вопросов.

Точный – это значит, что если ученик проходит такой тест, то он действительно достиг учебной цели.

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

Больше информации о надежности и точности тестов найдете здесь.

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

Задайте себе вопрос: «Каковы будут последствия для моих учеников, если они  пройдут или не пройдут этот тест?»

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

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

Итак, сопоставьте важность знаний/навыков с последствиями теста.

Практичные тесты

Иногда тест может быть не идеальным. Возможно, он будет не «в значительной мере точным» или хорошо оценит достижение большинства учебных целей, но не все

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

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

Бета-тестирования

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

• Заключительную проверку
• Бета-тестирование с небольшим количеством учеников

Заключительная проверка теста

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

Вот несколько вещей, на которые стоит обратить внимание:

• Цель обучения соответствует оценке (вы правильно используете тест на «знания» или «на основе задач», вы проверяете правильные знания или успеваемость и т. д.)
• У вас есть правильное количество тестовых заданий (по крайней мере один для каждой учебной цели, больше для наиболее важных целей и несколько тестовых заданий, если навык должен применяться в разных обстоятельствах)
• Тестовые задания полностью соответствуют желаемому результату на практике: эффективность, сложность, одинаковые обстоятельства и т. д.

Бета-тестирование с небольшим количеством учеников

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

Обратите внимание на следующее:

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