Как сделать отличный тест

Как начать писать тесты за 10 шагов по 10 минут

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

1. Выбираем фреймворк для тестов

Не вздумайте начинать писать собственный фреймворк с нуля — оно вам надо? Тратить неделю на выбор оптимального фреймворка (да, я видел такую оценку времени на это в планах) — тоже глупо. Вот вам рецепт: набирайте в Гугле best test framework for %language% site:stackoverflow.com. Открываете первые 5 ссылок. Закрываете те из них, где рейтинг вопроса или первого ответа около нуля. Из оставшихся вкладок можно смело брать любой рекомендованный фреймворк из первой тройки с максимальным рейтингом. С вероятностью в 99.5% он вам подойдет. Поскольку на данный шаг вы пока потратили минуты 3, то оставшиеся 7 можно потратить на то, чтобы перейти на сайт фреймворка и посмотреть примеры его использования. Скорее всего, там всё будет просто и понятно (иначе он не был бы в топе рекомендаций). Но если вдруг нет — выберите другой по тому же алгоритму.

2. Пишем Hello world!

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

3. Подключаем фреймворк к Hello world!

О подключении фреймворка к проекту наверняка очень хорошо написано на сайте фреймворка. Или на stackoverflow. Или на Хабре. Вот я, к примеру, когда-то описывал подключение Google Test. Обычно всё сводится к созданию нового проекта консольного исполняемого приложения (в скриптовых языках — отдельного скрипта), подключению к нему фрейворка парой include (import\using), подключению к проекту тестируемого кода (включением самих файлов с кодом или подключением библиотеки) — ну и всё. Если вы не верите, что этот шаг можно сделать за 10 минут — откройте Youtube, напишите в поиск название своего фреймворка и пронаблюдайте 20 видеороликов примерно одинакового содержимого, которые это доказывают.

4. Разбираемся с возможностями фреймворка

Для начала нам нужно выяснить:

  • Как написать один юнит-тест
  • Как запустить юнит-тесты

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

Вот, к примеру, пару тестов для нашего Hello world! на упомянутом выше Google Test:

5. Подключаем фреймворк к настоящему проекту

Мы уже умеем подключать фреймворк к проекту. Помните, делали на шаге №3? Всё получилось. Теперь давайте сделаем это для боевого проекта. Положите все необходимые файлы фреймворка себе под SVN\Git\TFS\чего-у-вас-там. Сделайте тестовый проект. Подключите к нему фреймворк. Включите сборку тестового проект в процесс сборки вашего продукта. Проверьте сборку в дебаг и релиз-конфигурациях. Комитните тестовый проект, запустите сборку на билд-сервере. Всё должно быть ок. Не нагружайте пока ваших коллег появлением тестового проекта — во-первых, вы ничего не сломали, во-вторых, хвастаться вам тоже пока нечем.

6. Тестируем что-нибудь простое

Вы помните, каким образом мы выше вынесли из Hello world! часть функционала во внешний код? Обратите внимание, какими получились эти функции: они не зависят ни от глобальных переменных, ни от состояния каких-то объектов, ни от внешних данных из файлов или баз данных. Резальтат зависит только от переданных аргументов. Найдите в своём проекте что-то аналогичное. Наверняка ведь у вас есть какие-нибудь функции конвертации чего-то куда-то, сериализации\десериализации, упаковки\распаковки, шифрования\дешифрования и т.д. Не думайте пока о том, насколько нужный и полезный функционал вы тестируете. Ваша задача — написать простой тест, но для боевого проекта. Запустить, увидеть «1 тест успешно пройден».

Читайте также:  Как сделать сбербанк платинум

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

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

7. Тестируем что-нибудь посложнее

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

8. Пишем тест на баг

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

9. Первый раз TDD

Как обычно выглядит ваша работа при разработке нового функционала? Наверное, вы сначала думаете. Потом проектируете то, что будете делать — набрасываете названия интерфейсов, классов, потом названия методов, наполняете их реализацией, запускаете, отлаживаете. Отлично, менять почти ничего не надо. Просто в тот момент, когда у вас уже есть интерфейсы, классы и названия методов, но еще нет их реализации — напишите для них тесты. Простенькие — вызвали метод — проверили результат. Обратите внимание, как уже на этом этапе вы заметите нелогичность некоторых имён, недостаток или излишество аргументов в методах, ненужные или отсутствующие зависимости и т.д.. При этом сейчас пока что это исправить — почти ничего не стоит (ведь реализация ещё не написана). Подправили архитектуру, дописали тесты, запустили — увидели кучу проваленных тестов. Отлично, так и должно быть. Написали реализацию, запустили тесты — увидели большинство из них пройденными, исправили ошибки, добились успешного прохождения всех тестов — отлично, дело сделано. Вы чувствуете, как хорошо стало, какое моральное удовлетворение вы получили? Оно слегка напоминает удовольствие от получения какой-то ачивки в игре. А почему? А потому, что его можно измерить! «Код проходит 18 тестов при тестовом покрытии в 90%» — это звучит круче, намного круче чем «ну, фича вроде бы реализована, я так потыкал немножко, кажется, не падает». Это даёт право гордится. Идешь домой — и чётко понимаешь, что-то за день сделал полезное, это «что-то» измеримо, ощутимо, реально.

10. Прикручиваем запуск тестов к CI-серверу

В тестах мало смысла, если их не запускать. Запускать их вручную — долго и бессмысленно. Наверняка у вас есть билд-сервер с каким-нибудь TeamCity или CruiseControl, где собирается ваш продукт. Так вот, большинство хороших билд-серверов сразу, из коробки, поддерживают запуск тестов и даже парсят их логи и рисуют красивые отчёты. Соответствие тут, конечно, не «все совместимы со всеми», но если вы взяли тестовый фреймворк по совету в начале статьи — шансы на то, что всё заработает очень высоки. К примеру, упомянутые мною TeamCity и Google Test прекрасно дружат между собой.

Послесловие

Дотошный читатель может заметить, что пункты начиная где-то с седьмого-восьмого скорее всего не впишутся в заявленные в заголовке «10 минут на шаг». Что тут можно сказать? Считайте, что я, нехороший человек, вас слегка наколол. Однако, если вы на практике с праведным негодованием прошли эти пункты, то:

  1. У вас уже есть проект, к которому прикручены тесты. Они запускаются, работают, их больше нуля и они уже приносят вам пользу.
  2. Вы получили опыт во всём этом деле.
  3. Во второй раз у вас получится серьёзно быстрее.

Вот и решайте, стоило оно того или нет.

Где-то пункта после 8-го — хорошее время чтобы представить тестовый проект вашей команде. Объясните в 2-3 абзаца что и как, покажите простенький пример теста, заметьте, что, мол, «feel free to add your own tests», но особо не напирайте пока. Если у вас писать тесты было не принято, скорее всего первым впечатлением будет осторожный скепсис и непонимание. Это быстро лечится после второго-третьего упоминания на совещании о том, что, мол «а этот баг мы нашли благодаря тесту» или «а вот тут написан тест и мы сразу узнаем, если оно сломается снова». Программисты — народ рациональный, они поймут и подтянутся.

Источник

Как создать онлайн-тест в iSpring Suite

← Предыдущий урок
Это шестой урок из цикла «Марафон: как создать онлайн-курс». Для полного погружения в тему, лучше начните с первого.

Читайте также:  Топ донатеры как сделать

В этой статье вы узнаете как быстро создать свой первый электронный тест. Для это вам понадобится бесплатная пробная версия программы iSpring Suite. Вы сможете создать неограниченное количество тестов. Скачать iSpring Suite→

Онлайн-тест — главный инструмент для проверки знаний в дистанционном обучении. Однако при разработке теста часто возникает вопросы:

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

В этой статье основатель студии по разработке электронных курсов New York Александр Виноградов подробно разберет как сделать качественный онлайн-тест в конструкторе iSpring Suite, чтобы провести тщательную «диагностику» знаний сотрудников.

Редактор iSpring Suite позволяет создавать 14 типов тестов, разрабатывать уникальный дизайн для заданий, добавлять озвучку к текстам:

Шаг 1. Определите тип теста

Александр Виноградов,
основатель студии по разработке электронных курсов New York

Работа над тестом очень похожа на разработку электронного курса. Стартовая точка та же — поставить цель.

Чего вы хотите добиться, создав тест? Ответив на вопрос, легче определиться с типом практического задания.

По целям тесты в электронном курсе делятся на два типа:

  1. Обучающие — помогают закрепить изученный материал. Обычно такой тест ставят после каждой главы в курсе в качестве небольшой практики. Условия тепличные: нет ограничения по времени, штрафов за неправильный ответ. На решение задачи дается несколько попыток, после каждой ошибки пояснения — почему ответ не верный.
  2. Аттестационные — помогают «просканировать» знания сотрудника. Обязательные условия: ограничения по времени, одна попытка на ответ, нет пояснений к каждой ошибке. Тест показывает, удалось ли курсу попасть «точно в цель» – чему по факту вы обучили сотрудников.

Шаг 2. Выберите типы вопросов

Обычно при составлении тестов в iSpring Suite используют арсенал из 11 оценочных вопросов:

Верно/Неверно — пользователь должен определить, верно или ложно утверждение в вопросе. Это самый простой вариант задания.

Выбор одного ответа — пользователю нужно выбрать один правильный ответ из предложенных вариантов.

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

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

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

Числовой ответ — нужно ввести число в поле для ответа. Здесь нет никаких подсказок, как и в типе вопроса «Ввод строки». Угадать правильный ответ невозможно.

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

Перетаскивание слов — нужно вставить слова из банка слов на место пропусков в тексте. Это тип вопроса, аналогичный «Вложенным ответам».

Заполнить пропуски — нужно заполнить пропуски, встречающиеся в тексте. Это усложненная версия «Вложенных ответов» и «Банка слов». Такой тип вопроса подойдет, если нужно проверить, к примеру, насколько хорошо сотрудник заучил определенное правило.

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

Оптимальное задание содержит от 4 до 10 условий. Соответствия можно провести между: понятиями и определениями, текстом и изображением, списком авторов и цитатами, датами и событиями.

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

Чтобы тест был максимально точным и правдивым, он должен соответствовать правилу 30/40/30.

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

Шаг 3. Продумайте текст вопросов

КПД теста во многом зависит от того, насколько грамотно сформулированы задания. Не забывайте, что сотрудник, который держит экзамен — один на один с проверочным материалом. Если он не поймет вопрос, посоветоваться не с кем — придется отвечать наугад. А это уже минус к объективности конечного результата. Потому важно тщательно проработать каждое задание. Вот несколько рекомендаций:

  • Не усложняйте. Вопрос должен быть простым и четким. Постарайтесь не писать длинных сложноподчиненных предложений с деепричастными оборотами. Максимальное количество слов: 20.
  • Избегайте повторов и двойного отрицания по типу «не/не». Пример: «Программа Paint не является программой для работы с электронными таблицами. Варианты ответов: Да-Нет». Сложно понять, что от тебя хотят: и в задании, и в ответе есть отрицание.
  • Выжигайте кислотой неточные факты, цифры и слова по типу «примерно», «сколько-нибудь», «хотя бы». «Чему примерно равно значение постоянной Пи?». Ну, примерно, трём. Глупый вопрос порождает глупые ответы.
  • Начинайте открытые вопросы со слов: «что», «сколько», «когда», «для чего», «как», «почему».
  • Избегайте невольных подсказок, когда текст вопроса наводит на правильный ответ.

Шаг 4. Проработайте варианты ответа для каждого задания

На этом этапе к каждому сформулировану вопросу нужно подобрать правдоподобные дистракторы — варианты ответа, призванные сбить с толку и отвлечь внимание. На что обратить внимание:

  • Используйте простые формулировки без сложных оборотов.
  • Правильные ответы и дистракторы должны совпадать по содержанию, структуре и общему количеству слов.
  • Не используйте варианты ответов из рода «ни один из перечисленных» и «все перечисленные», особенно для типа вопросов «Одиночный выбор».
  • Для вопросов типа «Пропуски» избегайте вариантов, в которых можно допустить ошибку: «Москва» и «москва», «Кэрролл» и «Кэррол». Ведь если сотрудник напишет нужное слово, но не стой буквой, тест это не засчитает. Итоговая оценка окажется необъективной.
Читайте также:  Как сделать ангела фигурку

Шаг 5. Продумайте параметры тестирования

Настройки тестирования зависят от цели: обучить или устроить жесткий экзамен.

Настройка баллов

При создании теста часто возникает вопрос — какой проходной балл выставить. Универсального рецепта нет. Отталкивайтесь от цели.

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

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

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

В каком типе теста использовать: обучающий и аттестационный.

Случайная выборка вопросов

Оптимальная длина теста — 25-30 вопросов. Но лучше сделать, что называется, «с запасом» — общий банк заданий должен быть в 3-4 раза больше. К примеру, в тест включаем пул из 75 вопросов, а сотрудники в случайном порядке получают лишь 25-30. В итоге у каждого пользователя тест отличается по содержанию — сложно будет списать у товарища.

Как сделать тесте iSpring Suite случайную выборку вопросов из общего банка, смотрите в коротком видеоуроке.

Ограничение по времени

Чтобы сотрудники не списывали, выставите также время на прохождение теста. Я обычно выделяю на задания от 10 минут до получаса — все зависит от сложности теста.

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

В iSpring Suite вы можете ограничить время на выполнение всего теста или отдельных вопросов:

Количество попыток

Если вы хотите провести максимально точную «диагностику» знаний сотрудников, введите одну попытку на ответ — тогда будет сложно решить задание методом «тыка». Сделать это можно в несколько кликов:

Ветвление

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

Суть: когда пользователь ошибается, то попадает на слайд с дополнительной информацией по теме вопроса. Если отвечает правильно — переходит к следующему заданию. Как настроить ветвление, смотрите здесь:

Обратная связь

Вспомните тесты в школе или институте. После проверки преподаватель раздавал тетради, где красной пастой были зачеркнуты неверные ответы. Часто хотелось спросить: «А почему здесь неправильно?».

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

За счет такого подхода тестируемому проще понять, что неверно в его ответе и какой вариант правильный. Чтобы настроить обратную связь в iSpring Suite, потребуется пара минут:

Шаг 6. Озвучьте и оформите вопросы

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

Дизайн вопросов

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

Озвучка вопросов

К каждому вопросу в тесте можно добавить аудиофайл или записать звук прямо в iSpring Suite, а после отредактировать с помощью встроенного редактора:

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

Подробное руководство о работе с тестами в iSpring Suite вы можете прочитать здесь.

Когда запускать тесты

После каждого модуля в курсе. Я рекомендую делать так в объемных курсах с большим количеством информации.

Вот курс компании «Ёрд» — «Тактическое управление». Он учит руководителей правильно выстраивать работу с подчиненными.

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

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

По итогам курса. Итоговый тест должен быть в каждом курсе. Иначе как вы измерите пользу от электронного тренинга.

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

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

Как и по каким метрика оценивать результаты тестирования, подробнее читайте в статье «12 отчетов в СДО, которые помогут повысить эффективность обучения».

Тесты в цифрах

Более 80% зарубежных компаний при помощи тестов оценивают соискателей и сотрудников.

69% компаний России тесты помогают при найме персонала. Остальные используют их для оценки квалификации действующих сотрудников.

$500 миллионов — объем рынка тестирования в российских и зарубежных компаниях. Рынок складывается в основном из услуг внешних рекуртеров, подбирающих заказчикам сотрудников при помощи тестов, и компаний, эти тесты создающие. Среди них Multi-Health Systems, Captevrix, Hogan Development Survey.

Источники: Harvard Business Review, The Wall Street Journal, SHL Russia & CIS, РБК.

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

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

А если у вас есть идеи как можно улучшить текст — расскажите нам. Мы будем рады доработать материал!

Быстрый конструктор курсов и тестов

Поможет создать интерактивные курсы и тесты в рекордно короткие сроки. Без дизайнера и программиста.

Источник

Поделиться с друзьями
Ответ и точка