Содержание
-
2
-
4
-
4
-
5
-
-
7
-
8
-
12
-
15
Тестирование – вид практического исследования проводимый с использованием различных методик применяемых при психологическом и педагогическом исследовании.
Тестирование по методикам в проектной (исследовательской) работе
Под методикой исследования следует понимать совокупность способов и приёмов организации и проведения исследования, а также этапы их применения и порядок интерпретации полученных в ходе исследования данных.
Особенности проведения тестирования при выполнении проектной работы
При подготовке и проведении тестирования во время выполнения проектной работы существует ряд особенностей, которые необходимо учитывать:
- Главное — необходимо уметь работать с методиками, понимать основы их применения и как правильно обрабатывать полученные результаты, иначе выводы, сделанные на основе неверных результатов, также будут неверны, соответственно и вся практическая часть в проектной (исследовательской) работе.
- Подобранная для применения методика (методики) должна соответствовать задачам проектной (исследовательской) работы, а также соответствовать возрасту участников.
- Если проектная работа выполняется школьником (или несовершеннолетним) и участниками будут также несовершеннолетние, для правильного проведения следует привлечь педагога.
- В том случае если план работы над проектной (исследовательской) работой предполагает проведение 3-х этапов исследования (констатирующий, формирующий и контрольный) и проектная работа выполняется школьником (или несовершеннолетним) следует утверждать у руководителя (куратора) занятия, которые будут проводиться с участниками тестирования.
- Перед проведением тестирования обязательно следует ознакомить испытуемых с правилами заполнения опросных листов, иначе данные могут быть неверными или совсем не подлежать интерпретации.
- Следует сохранять все результаты тестирований (опросные листы) до полной защиты проектной работы, это позволит при необходимости проверить правильность представленных в проекте данных.
Как правильно работать с методиками можно узнать у человека, который обладает такими знаниями, найти в книгах или ознакомится с этим в интернете.
Каждая методика имеет описание, в котором указана как цель её применения, так и если она рассчитана на определённый возраст он также указывается.
Желательно также утвердить перечень методик, которые будут применяться в ходе тестирования.
Разработка перечня занятий и их проведение с испытуемыми является основным этапом работы при выполнении проектной (исследовательской) работы, состоящей из 3-х этапов исследования, от правильности подобранных занятий зависит итоговый результат.
Структура практической части проектной работе с результатами тестирования
Варианты структурирования второй главы с анализом исследования по методикам
При выполнении проектной (исследовательской) работы в практической части, которой предполагается анализ проведённого тестирования следует придерживаться следующей структуры:
1 Вариант – в том случае если предполагается проведение тестирования и разработка рекомендаций на основе полученных результатов:
- параграф 2.1 (первый параграф второй главы) – описание (характеристика) методик (методики) используемых при проведении тестирования, а также характеристика участников тестирования и база исследования (организация где будет проходить исследование, например, МОУ СОШ № #).
- параграф 2.2. (второй параграф второй главы) – анализ полученных во время тестирования результатов, с обязательными самостоятельными выводами.
- параграф 2.3 (третий параграф второй главы) – рекомендации, разработанные по результатам проведённого тестирования, рекомендации напрямую зависят от темы проектной (исследовательской) работы, а также результатов тестирования.
При указании участников тестирования даются обобщённые данные об участниках.
Желательно полученные после интерпретации результаты представить в тексте работы, а исходные результаты сведённые в таблицы, представить в приложении к проектной работе, таким образом, будет понятно, что работа выполнена самостоятельно, и кроме того можно убедиться в правильности результатов.
В качестве рекомендаций могут быть представлены занятия, игры, советы и т. д.
Вариант 2 – в том случае если выполнение практической главы проектной работы подразумевает проведение исследования, состоящего из 3-х этапов (констатирующий, формирующий и контрольный):
- параграф 2.1 – в этом параграфе даётся характеристика методик (методики), которые будут использованы на констатирующем и контрольном этапах исследования, а также характеристика участников исследования и база исследования, организация где проводится исследование (например, МОУ СОШ № #).
- параграф 2.2 – в этом параграфе представляются результаты исследования по выбранным методикам, даётся характеристика полученным результатам и определяются проблемы участников исследования, которые должны быть решены в соответствии с темой проектной (исследовательской) работы.
- параграф 2.3 – в этом параграфе представляются разработанные занятия, упражнения, игры и т. д. которые будут проводиться с участниками исследования, следует давать полную характеристику (описание), например, если разработаны игры, следует описать: ход, правила.
- параграф 2.4. – в этом параграфе представляются результаты проведённых занятий, игр, упражнений разработанных и представленных в параграфе 2.3. В данном параграфе помимо простого представления полученных результатов следует представить сравнение «До» и «После», которое поможет наглядно отразить произошедшие изменения.
Особенностью данного варианта выполнения исследования с использованием методик также может быть не просто исследование из 3-х этапов, но также разделение испытуемых на 2 группы (контрольную – группа с которой разработанные занятия, игры, упражнения не проводятся и экспериментальную – группа с которой проводятся разработанные занятия, упражнения, игры) и помимо анализа изменений произошедших в экспериментальной группе, её также сравнивают с контрольной, чем выявляют эффективность (неэффективность) предложенных рекомендаций.
Какой из вариантов выполнения практической главы проектной (исследователькой) работы выбрать
Более лёгким является Вариант 1, поэтому обучающимся в школе и коллеже (кроме специальностей медицинской направленности) рекомендуется выбирать его.
Вариант 2 является прерогативой обучающихся в высших учебных заведениях, так как только они могут полноценно провести апробацию разработанных рекомендаций, а также уже имеют достаточный уровень знаний для работы как с методиками, так и с участниками эксперимента.
Способы обработки тестирования по методикам для выполнения практической главы
Для анализа полученных в ходе проведения исследования по методикам данных могут быть использованы:
- Специализированные программы – рассчитаны на определённые психологические или педагогические тесты.
- Программы для анализа статистических данных: Minitab, Matlab, Excel и другие.
- Онлайн-сервисы, в интернете на сегодняшний день можно найти сервисы, позволяющие проанализировать результаты проведённого тестирования.
Варианты представления (примеры) тестирования с использованием методик в проектной работе
Для примера будет использована проектная (исследовательсткая) работа и магистерская диссертация по психологии, так будет нагляднее различие и, соответственно, понятнее, почему Вариант 1 ранее описанный более подходит для выполнения в школе.
Данное мнение является личным мнением администрации сайта и не является обязательным к выполнению.
Рассмотрим подробно структуру практической главы проектной (исследовательской) работы школьника, в которой проводится анализ данных тестирования с использованием методик:
План главы – план состоит из 3 параграфов:
- характеристика методик и участников исследования;
- анализ результатов проведенного исследования;
- разработанные рекомендации.
Пример плана проектной работы с проведением тестирования
Пример параграфа 2.1, в котором дана характеристика участников представлен на рисунке ниже.
Пример параграфа 2.1 проектной работы с проведением тестирования
Пример параграфа 2.2 с результатами и выводами сделанными по результатам проведения исследования с использованием методик представлен ниже.
Пример параграфа 2.2 проектной работы с проведением тестирования
Как видно из представленных примеров результаты тестирования представляются в обобщённом виде, кроме того, после каждой диаграммы представлены выводы, сделанные автором на основе полученных результатов согласно их интерпретации.
Параграф 2.3 – в примере в данном параграфе представлены рекомендации, разработанные на основании полученных в ходе исследования результатов, школьные работы не предполагают апробации (внедрения разработанных рекомендаций), поэтому дальнейшее исследование является нецелесообразным.
Пример параграфа 2.3 проектной работы с рекомендациями на основании тестирования
Дальнейшее исследование может проводиться лишь при непосредственном участии руководителя (куратора) или иного педагога, который будет проверять, какие занятия и как проводятся и, соответственно, будет нести ответственность за проводимый педагогический (психологический) эксперимент.
Практическое исследование в виде тестирования по методикам (эмпирическое исследование) проводимое в высших учебных заведениях имеет более сложную структуру, рассмотрим её подробнее:
Параграф 2.1 – в нём описывается организация и планирование эмпирического исследования указывается:
- цель его проведения;
- объект;
- предмет;
- задачи эмпирического исследования;
- кто является участниками, а также база исследования;
- диагностические методики (методики, которые были использованы при проведении исследования).
Пример данного параграфа из магистерской диссертации приведён ниже.
Примеры параграфа 2.1 с тестированием из магистерской диссертации
Параграф 2.2 – в данном параграфе представляются данные констатирующего этапа эксперимента, все результаты представляются в обобщённом виде, исходные (первичные) результаты обычно приводятся в приложении (приложениях).
Обобщённые данные, приведённые в виде таблиц и диаграмм, представляются с самостоятельно сделанными выводами, на основании которых разрабатываются рекомендации.
Пример параграфа 2.2 из магистерской диссертации приведён ниже.
Примеры параграфа 2.2 с тестированием из магистерской диссертации
Параграф 2.3 – предполагает описание проведения занятий (игр, упражнений) корректирующих выявленные отклонения в параграфе 2.2 с участниками исследования. Все проводимые занятия (игры, упражнения) описываются подробно, так чтобы при необходимости их могли повторить.
Пример параграфа с формирующим этапом эксперимента из магистерской диссертации приведён ниже.
Примеры параграфа 2.3 с тестированием из магистерской диссертации
Данный этап эксперимента является формирующим.
Параграф 2.4 – описание контрольного этапа эксперимента.
В данном параграфе представляются результаты повторного исследования по выбранным методикам после проведения с участниками исследования корректирующих занятий (игр, упражнений).
Пример параграфа 2.4 из магистерской диссертации приведён ниже.
Пример параграфа 2.4 с тестированием из магистерской диссертации
В магистерских работах, в которых проводится тестирование по методикам, в обязательном порядке в приложении представляются первичные данные (пример представлен ниже).
Пример приложения с исходными данными в магистерской диссертации с тестированием
Представленная структура практического исследования в работах, выполняемых обучающимися в высших учебных заведениях, является примерной и может отличаться в зависимости от темы работы, требования методического пособия и пожеланий научного руководителя, при этом вся указанные данные отражаются в работе.
Алгоритм выполнения тестирования по методикам в проектной (исследовательской) работе
Для выполнения практического исследования с применением методик (психологических, педагогических) желательно придерживаться следующего алгоритма (этапов):
- Выполняется введение и теоретическая часть – данный этап является первым независимо от типа практического исследования в проектной работе.
- Поиск диагностических методик (или методики) – на данном этапе необходимо подобрать методики, которые будут подходить под тему исследования. При необходимости подобранные диагностические методики следует утвердить у руководителя (куратора).
- Поиск участников исследования – на данном этапе следует подобрать группу (или две) подходящих под исследование людей: по возрасту, полу, семейному положению и т.д.
- Проведение диагностического тестирования – на данном этапе проводится само тестирование с применением выбранных ранее методик, все результаты сохраняются по каждому испытуемому, далее их следует представить в приложении.
- Анализ полученных в ходе тестирования данных – все полученные результаты следует проанализировать и сделать выводы на их основе.
- Разработка рекомендаций – на данном этапе на основе полученных в ходе тестирования результатах разрабатываются рекомендации (например, корректирующие занятия, упражнения, игры). Если для выполнения практического исследования в проектной работе необходимо внедрение (проведение занятий, упражнений, игр) разработанных рекомендаций их желательно утвердить у руководителя (куратора).
- Внедрение разработанных рекомендаций (формирующий этап эксперимента) – на данном этапе проводятся корректирующие занятия (упражнения) с участниками исследования. Если в эксперименте принимают участие 2 группы, то разработанные занятия проводятся только с экспериментальной группой.
- Повторная диагностика – на данном этапе проводится повторная диагностика по выбранным методикам, для определения эффективности разработанных рекомендаций, данные по участникам так же сохраняются по отдельности.
- Анализ полученных результатов и их сравнение с полученными до и после формирующего этапа эксперимента.
- Подготовка практический (исследовательской) части проектной работы – на данном этапе подготавливается вторая глава проектной (исследовательской) работы, то есть текстовая часть со всеми полученными результатами и самостоятельными выводами.
Ошибки при подготовке практического исследования с тестированием по методикам
При выполнении практической части с анализом результатов тестирования можно допустить следующие ошибки:
- Неверно выбраны методики – это самая грубая ошибка, исправить её можно лишь выполнив исследование заново с применением подходящих методики.
- Не представлена характеристика выбранных методик, выборки и базы исследования – всё это должно располагаться в первом параграфе второй (практической) главы.
- Не представлен самостоятельный анализ результатов проведения исследования по методикам, представлены только результаты, сведённые в таблицы или рисунки (диаграммы) – выполнение практической главы с проведением исследования по методикам подразумевает не только выявления умения обучающегося правильно применять и интерпретировать результаты методик, но и умение их анализировать и делать самостоятельные выводы.
- Отсутствуют результаты исследования, помимо анализа необходимо предоставить первичные данные, которые обычно сводятся в таблицы и прикладываются к работе в виде приложений.
- Отсутствует описание занятий, которые проводились с испытуемыми на формирующем этапе эксперимента – в том случае, если исследование подразумевает данный этап, в работу обязательно должны быть включены задания с подробным их описанием (выделяются в отдельный параграф).
- Отсутствует контрольный этап эксперимента или не проведено сравнение – в том случае, если подразумевается формирующий этап эксперимента, обязательно следует привести данные, к чему он привёл, для этого проводится контрольный этап и его результаты сравниваются с констатирующим этапом.
Фундаментальная теория тестирования
Время на прочтение
15 мин
Количество просмотров 728K
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (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, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
- Проектная документация — включает в себя всё, что относится к проекту в целом.
- Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.
Этапы тестирования:
- Анализ продукта
- Работа с требованиями
- Разработка стратегии тестирования и планирование процедур контроля качества
- Создание тестовой документации
- Тестирование прототипа
- Основное тестирование
- Стабилизация
- Эксплуатация
Стадии разработки ПО — этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широкого круга пользователей.
Программный продукт проходит следующие стадии:
- анализ требований к проекту;
- проектирование;
- реализация;
- тестирование продукта;
- внедрение и поддержка.
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Атрибуты требований:
- Корректность — точное описание разрабатываемого функционала.
- Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
- Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
- Недвусмысленность — требование должно содержать однозначные формулировки.
- Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
- Атомарность — требование нельзя разбить на отдельные части без потери деталей.
- Модифицируемость — в каждое требование можно внести изменение.
- Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.
Дефект (bug) — отклонение фактического результата от ожидаемого.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
- Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
- Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
- Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
- Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
- Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
- Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
- Вложения (Attachments) — скриншоты, видео или лог-файлы.
- Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
- Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
- Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
- Окружение (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: финальная версия программы, которая готова к использованию.
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
- Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
- Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
- Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
- Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
- Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
- Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
- Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
- Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
- Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
- Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
- Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
- Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
- Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
- Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
- Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
- Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
- Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
- Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
- Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
- Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
- Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Техники тест-дизайна
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
- Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
- Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
- Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
- Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
- Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
- Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
- Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
- тестирование, основанное на анализе внутренней структуры компонента или системы;
- тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
- Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.
Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
- тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
- тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
- Что необходимо протестировать?
- Как будет проводиться тестирование?
- Когда будет проводиться тестирование?
- Критерии начала тестирования.
- Критерии окончания тестирования.
Основные пункты тест плана:
- Идентификатор тест плана (Test plan identifier);
- Введение (Introduction);
- Объект тестирования (Test items);
- Функции, которые будут протестированы (Features to be tested;)
- Функции, которые не будут протестированы (Features not to be tested);
- Тестовые подходы (Approach);
- Критерии прохождения тестирования (Item pass/fail criteria);
- Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
- Результаты тестирования (Test deliverables);
- Задачи тестирования (Testing tasks);
- Ресурсы системы (Environmental needs);
- Обязанности (Responsibilities);
- Роли и ответственность (Staffing and training needs);
- Расписание (Schedule);
- Оценка рисков (Risks and contingencies);
- Согласования (Approvals).
Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
- Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
- Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
- Ожидаемый результат (Expected result) — что по факту должны получить.
Резюме
Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.
Форматы
Отображать тест план можно разными способами:
- В виде традиционного документа с использованием Microsoft Excel или Microsoft Word.
- Используя методики визуализации с помощью майнд-карт, таблиц, диаграмм, коротких схем.
- Прибегнуть к помощи профессиональных инструментов – систем для управления процессами на проектах.
Преимущества схематических тест планов:
— Позволяют визуально представить запланированный процесс,
— Просты в использовании,
— Гибкие к внесению изменений,
— Содержат самую основную информацию, что позволяет в значительной степени сократить время на планирование.
Рекомендации по написанию
Что должен содержать хороший тест план:
- Что надо тестировать?
Описание объекта тестирования: системы, приложения, оборудования.
- Что будете тестировать?
Список функций и описание тестируемой системы и её компонент в отдельности.
- Как будете тестировать?
Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования.
- Когда будете тестировать?
Последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки.
- Критерии начала тестирования:
Готовность тестовой платформы (тестового стенда), законченность разработки требуемого функционала, наличие всей необходимой документации и т.д.
- Критерии окончания тестирования:
Результаты тестирования удовлетворяют критериям качества продукта: требования к количеству открытых багов выполнены, выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF), выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB) и т.д.
Ответив в своем тест плане на вышеперечисленные вопросы, можно считать, что у вас на руках уже есть хороший черновик документа по планированию тестирования.
Далее, чтобы документ приобрел более менее серьезный вид, можно дополнить его следующими пунктами:
- Окружение тестируемой системы (описание программно-аппаратных средств).
- Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.).
- Риски и пути их разрешения. Риски могут быть связаны с недостатками, связанными с персоналом. Например, недостаточная квалификация персонала или недостаточное количество тестировщиков.
Структура
Обычно детальный тест план занимает от пары страниц до нескольких десятков. Это если мы говорим о его визуализации в виде документа. Общая структура тест плана не зависит от его объема или формата визуализации. Достаточно заменить слово «страница» из структуры ниже на слово «ветка» и мы сможем с легкостью перенести данную структура на майнд-марту.
Структура тест-плана:
1-я страница:
— шапка (логотип и адрес компании),
— название,
— версия,
— год.
2-я страница:
— история документа, которая представляет собой таблицу изменений. Эта таблица содержит столбцы: дата, версия, описание, автор.
3-я страница:
— содержание.
4-я страница и далее:
— введение,
— виды тестирования,
— операционные системы, браузеры,
— функционал приложения,
— критерии начала тестирования,
— критерии выхода из тестирования,
— характеристики оборудования.
Предпоследняя страница:
— сколько человеко-часов планируется на различных этапах (дата начала и окончания). Например, на тест-дизайн, выполнение тестов, анализ тестирования, отчеты.
Последняя страница:
— выводы и рекомендации.
Также в тест план могут входить следующие данные:
— команда исполнителей,
— контактные данные,
— жизненный цикл бага,
— риски тестирования,
— ссылки на документы или стандарты,
— толковый словарь,
— расписание,
— обязанности,
— риски.
Рецензия и утверждение
Для увеличения ценности тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде «процедуры утверждения». Примерный список участников проектной группы:
- Ведущий тестировщик,
- Тест менеджер (менеджер по качеству),
- Руководитель разработки,
- Менеджер проекта.
Каждый из перечисленных участников проекта перед утверждением проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать тест план более полным и качественным.
Шаблоны и примеры
Каждая методология или процесс диктуют свои форматы оформления планов тестирования.
Шаблоны ниже помогут понять, какой формат больше подходит для вашего проекта и как вообще составлять тест план. А готовые решения, возможно, натолкнут вас на какие-то мысли или помогут лучше понять смысл составления данного документа.
Обычный документ
Шаблоны, которых можно придерживаться:
- Test Plan Template RUP
- Test Plan Template IEEE 829
Готовые примеры:
— Тестирование интернет-магазина 1
— Тестирование интернет-магазина 2
— Тестирование программы Блокнот
Майнд-карта (mind map)
Несколько примеров, как именно можно использовать майнд-карту
Дашборд
Подобный структурный вид позволит понять, что конкретно мы намерены тестировать. С помощью цвета можно привлечь внимание к определенным областям.
Excel или другая таблица
В таблице можно запросто отобразить любые списки тестов или описание сценариев, с которыми мы намерены работать на данном проекте.
Доска для записей – Trello
Тут не только можно будет прописать все задачи, но и следить за ходом их выполнения.
Итог
Создание тест плана повышает качество продукта за счет перечисления деталей и списка проверок, а также позволяет проанализировать, насколько успешно были проведены все этапы тестирования.
Нет четкого шаблона, по которому необходимо писать тест план. Можно взять за основы шаблоны, которые рассмотрены в статье. А можно создать свой собственный.
Какой шаблон или вид вы бы не выбрали, главное только то, что тест-план должен выполнять свою задачу. А именно, описать весь объем работ по тестированию и быть понятным и читабельным.
Тест по Основам
исследовательской деятельности
1.
Методы исследования делятся на:
А) формирующие и
констатирующие;
Б) теоретические и
эмпирические;
В) творческие и
шаблонные;
Г) диалектические
и исторические.
2. К теоретическим методам исследования относятся:
А) контент-анализ;
Б) наблюдение;
В) анализ;
Г) моделирование.
3.
Среди теоретических методов найдите эмпирический:
А) анализ;
Б) синтез;
В) наблюдение;
Г) абстрагирование.
4. Синтез – это:
А) эмпирический
метод психолого-педагогических исследований;
Б) метод научного
исследования, в основе которого лежит процесс соединения или объединения ранее
разрозненных вещей или понятий в одно целое;
В) это понятие,
означающее представление о чем-либо в более совершенном виде, чем это есть на
самом деле;
Г) метод научного
исследования явлений и процессов, в основе которого лежит изучение составных
частей, элементов изучаемой системы.
5. Дедукция —
это:
А) метод мышления;
Б) оценочная
практика;
В) метод исследования;
Г) метод
качественно-количественного анализа.
6. Метод мышления,
в котором осуществляется переход от частного знания к более общему, называется:
А) интерпретация;
Б) интериоризация;
В) индукция;
Г) идеализация.
7. К теоретическим
методам относятся:
А) наблюдение;
Б) эксперимент;
В) синтез;
Г) анкетирование.
8. Специально
созданный человеком письменный предмет, предназначенный для передачи или
хранения информации, называется:
А) флэшка;
Б) документ;
В) жесткий диск;
Г) USB—
диск.
9.
Гипотеза – это
А) предположение или догадка, утверждение, не предполагающее
доказательство;
Б) утверждение, предполагающее доказательство;
В) предположение или догадка, утверждение, предполагающее
доказательство.
10. Проект – это:
А) самостоятельная творческая исследовательская деятельность,
направленная на достижение поставленной цели или проблемы;
Б) общественное представление чего-либо нового, недавно
появившегося, созданного;
В) это развернутое устное изложение какой-либо темы, сделанное
публично;
11. Практико –
ориентированный проект — это:
А) сбор информации о каком-нибудь объекте, явлении;
Б) доказательство или опровержение гипотезы;
В) решение практических задач заказчика проекта;
12. Метод исследования — это…:
А) способ достижения какой либо цели, решения конкретной задачи,
совокупность приёмов и операций практического и теоретического освоения;
Б) точка зрения, с позиции которой рассматриваются или
воспринимаются те или иные предметы, понятия, явления;
В)
инструмент для добывания фактического материала;
13. Укажите преимущество
подгрупповых проектов:
А) автор проекта получает наиболее полный и разносторонний опыт
проектной деятельности на всех этапах работы;
Б) у автора есть возможность обогащаться опытом других, видеть
более эффективные стратегии работы;
В)
формируются навыки сотрудничества, умения проявлять гибкость, видеть точку
зрения другого, идти на компромисс ради общей цели;
14. В план исследовательской
работы не входит:
А)
титульный лист;
Б)
список литературы;
В)
основная часть;
Г)
введение.
15. Методы
исследования, основанные на опыте, практике:
А)
эмпирические;
Б)
теоретические;
В)
статистические;
Г)
все варианты верны.
16. Метод исследования, который предполагает
организацию ситуации исследования и позволяет её контролировать в процессе всей
работы:
А)
наблюдение;
Б)
эксперимент;
В)
анкетирование;
Г)
все варианты верны.
17. Метод письменного опроса респондентов:
А)
тестирование;
Б)
анкетирование;
В.
Моделирование.
Г.
Все варианты не верны.
18. Для
чего создают папки:
А) для удобства;
Б) для красоты;
В) чтобы скрыть
информацию.
19. Как
называется страница презентации?
А) слайд;
Б) кадр;
В) сцена.
20. Что
можно вставить на слайд презентации?
А) рисунок
Б) звук;
В) текст;
Г) всё
вышеперечисленное
21. К
электронным носителям информации НЕ относится:
А) флеш-накопитель;
Б) лазерный диск;
В) монитор.
22. Для
создания презентаций используется программа:
А) PowerPoint;
Б) Excel;
В) Word.
23. Вам
нужно, чтобы все слайды были оформлены одинаково. Вы выберете в меню вкладку:
А) вставка;
Б) дизайн;
В) вид.
24. Что такое презентация PowerPoint?
А) прикладная программа для обработки электронных таблиц;
Б) устройство компьютера, управляющее демонстрацией слайдов;
В) текстовой документ, содержащий набор рисунков, фотографий,
диаграмм;
Г) демонстрационный набор слайдов, подготовленных на
компьютере.
25. Выполнение команды Начать показ слайдов презентации программы Power Point осуществляет
клавиша …
А) F5
Б) F4
В) F3
Г) F7
26. Метод исследования,
предполагающий, что обследуемый отвечает на ряд задаваемых ему вопросов:
А)
манипуляция;
Б)
опрос;
В)
тестирование;
Г)
эксперимент.
27.
Важнейшие выводы, к которым пришел автор исследовательской работы:
А)
приложения;
Б)
введение;
В)
заключение;
Г)
основная часть.
Ответы и критерии оценивания
1 |
Б |
2 |
В |
3 |
В |
4 |
Б |
5 |
А |
6 |
В |
7 |
В |
8 |
Б |
9 |
В |
10 |
А |
11 |
А |
12 |
А |
13 |
В |
14 |
А |
15 |
А |
16 |
А |
17 |
А |
18 |
А |
19 |
А |
20 |
Г |
21 |
В |
22 |
А |
23 |
Б |
24 |
Г |
25 |
А |
26 |
Б |
27 |
В |
17 Августа 2020
17 856
В избр.
Сохранено
Обзор сервисов для онлайн-тестирования
Мы рассмотрели популярные онлайн-конструкторы тестов, попробовали их в работе, оценили интерфейс и функционал. Рассказываем об общем впечатлении от сервисов, а также их плюсах и минусах.
1. Online Test Pad
Позволяет создать как простые тесты, так и опросы, кроссворды, «диалоги» — тесты, оформленные в виде общения с виртуальным экзаменатором.Также внутри сервиса есть система дистанционного обучения и тестирования, где можно создавать группы учеников, давать им уроки и задания, вести журнал успеваемости.
При создании теста нужно выбрать его тип: психологический, личностный или образовательный. В конструкторе 17 типов вопросов, сервис позволяет провести даже интерактивный диктант.
Доступ к тесту можно предоставить по ссылке, его можно встроить на сайт с помощью html-кода, разослать приглашения по электронной почте или опубликовать для общего доступа.
Услуги сервиса предоставляются бесплатно, однако при прохождении теста участники будут видеть рекламу. Убрать ее стоит 10 копеек за каждое прохождение теста, при этом на балансе нового клиента при регистрации уже есть 5 рублей. Пополняется баланс банковской картой или переводом с Яндекс.Кошелька.
Так выглядят «диалоги», которые предлагает сервис Online Test Pad
Плюсы: много типов вопросов, чат с техподдержкой в личном кабинете, интуитивно понятный интерфейс.
Минусы: устаревший дизайн тестов; нет полного предпросмотра теста; плохая адаптация под разные девайсы.
Фишки: возможность создать сертификат, который получат участники теста после его прохождения; установка ограничения по времени прохождения теста; функция «ручной проверки» теста; возможность добавления комментариев.
Почему стоит выбрать: подойдет для дистанционного обучения и проверки знаний учеников, сотрудников.
2. Let’s test
Сервис специализируется исключительно на онлайн-тестах. Позволяет настроить доступ к тестированию по паролю или предварительной регистрации и контролировать, кто будет его проходить.
Конструктор содержит всего шесть типов вопросов, однако самостоятельно разобраться в функционале и интерфейсе не так просто. Можно обратиться в службу поддержки и увидеть презентацию работы сервиса на примере своего же теста. Также нет возможности самостоятельно настроить дизайн, для брендирования теста своим логотипом нужно оформлять заявку.
Сервис платный. Есть пробный период — 5 дней, а далее необходимо выбрать наиболее подходящий тариф. Цена минимального тарифа — 2 000 рублей в месяц. Можно отметить большой выбор способов оплаты для физлиц. Если работать с сервисом как юрлицо, тариф оплачивается переводом на банковский счет.
Плюсы: изолированная система тестирования, помощь в настройке теста.
Минусы: устаревший дизайн конструктора, неинтуитивный интерфейс, нет возможности самостоятельно настроить дизайн теста, нет функции предпросмотра.
Фишки: можно импортировать вопросы из файла, отправлять сертификаты о прохождении, предоставлять доступ к тесту по специальному паролю.
Почему стоит выбрать: подойдет, если вашей организации важно получить собственную, изолированную систему тестирования.
3. Anketolog
Сервис специализируется в первую очередь на онлайн-опросах, но также позволяет создавать тесты. Причем вы можете разработать тест самостоятельно или доверить это специалистам сервиса.
Конструктор прост и понятен в использовании. Для создания анкет доступно 18 общих типов вопросов, однако в тестах можно использовать всего 4. В них можно добавить не только текст, но и мультимедиа. Сервис позволяет самостоятельно настроить дизайн теста, также можно создавать разные страницы завершения в зависимости от результатов теста.
«Анкетолог» предлагает много вариантов сбора ответов на тест: можно отправить общую или индивидуальную ссылку, сделать рассылку по e-mail или sms, вставить тест на сайт с помощью HTML или QR-кода, поделиться в соцсетях или воспользоваться онлайн-панелью респондентов. Ответы на тест собираются в личном кабинете в реальном времени, но их также можно выгрузить в разных форматах.
Сервис предлагает несколько тарифов: от бесплатного до профессионального тарифа, включающего комплекс услуг специалистов.
Плюсы: настройка дизайна анкеты с помощью CSS; настройка логики вопросов, онлайн-панель респондентов, где можно найти участников для тестирования; множество вариантов сбора ответов; возможность переложить работу на специалистов.
Минусы: при создании теста можно использовать ограниченный набор типов вопросов.
Фишки: доступ к тесту по qr-коду, добавление промокодов в тест, возможность настроить индивидуальные страницы завершения.
Почему стоит выбрать: если нужно найти участников для тестирования, быстро получить ответы, а также если вы ищете специалистов, которые сами разработают тест, соберут и проанализируют данные.
4. Конструктор Тестов.ру
Простенький конструктор, где вы можете не только разработать тест, но также пройти и вдохновиться множеством других: есть тесты на сообразительность, IQ или знания правил дорожного движения.
Созданный тест становится доступен для других пользователей и отображается в указанной категории на сайте. Получить ответы можно также с помощью прямой ссылки, добавив HTML-код на сайт или поделившись тестом в соцсетях.
Для прохождения теста регистрация не требуется. Кроме того, вы не сможете увидеть результаты участников тестирования — здесь просто нет такой функции. Однако сервис предлагает расширенный функционал для учебных заведений. Учителю необходимо добавить класс, логины и пароли ученикам, а также сами тесты. После проведения тестирования учитель сможет увидеть результаты в личном кабинете.
«Конструктор Тестов. ру» полностью бесплатный, включая функционал для учебных заведений, однако содержит рекламу. В целом же это скорее развлекательный сервис, чем профессиональный инструмент.
Плюсы: множество готовых тестов, которые могут вдохновить на создание своего.
Минусы: устаревший дизайн, реклама, нет статистики по ответам, нет никаких инструкций по работе с сайтом.
Фишки: функционал для работы с учениками.
Почему стоит выбрать: если вы хотите создать развлекательный тест для коллег и клиентов или же протестировать обучающихся.
5. ClassMarker
ClassMarker — англоязычный сервис, однако благодаря удобному интерфейсу разобраться в нем реально, даже если вы не знаете языка.
В конструкторе 7 типов вопросов, есть специальный банк, куда сохраняются все созданные вопросы для повторного использования в других тестах. Для классификации анкет можно создавать собственные категории. Также вы можете предоставить доступ к тесту своим коллегам и работать над ним вместе.
Собрать ответы можно с помощью размещения HTML-кода теста на сайте, отправки ссылок участникам. Также вы можете контролировать доступ к тесту, создав индивидуальные регистрационные коды или пароли для пользователей. Статистика результатов отображается в личном кабинете, вы можете посмотреть ответы как по тесту в целом, так и отдельно по каждому участнику, однако выгрузить их нельзя.
Есть 30-дневная пробная версия. Далее необходимо выбрать один из множества тарифов, цены на которые варьируются от 20 до 1000 долларов. Для оплаты можно использовать банковские карты.
Плюсы: приятный и удобный дизайн, позволяет проводить закрытые тестирования.
Минусы: английский язык интерфейса, высокая цена, нет возможности выгрузить результаты теста.
Фишки: банк вопросов, библиотека типографских символов.
Почему стоит выбрать: если нужно протестировать учащихся, сотрудников и если не пугает язык интерфейса.
6. Testix
Тоже англоязычный конструктор тестов, однако с возможностью переключиться на русский язык. Его основная фишка — работа с готовыми шаблонами.
Их 7 типов: викторины, тесты на личность, игры на развитие памяти, панорамы для Facebook (можно загружать фотографии и добавлять на них комментарии), фотоистории, хронологии, Zoom-карты. Все шаблоны очень красивые, также вы можете изменить их дизайн — добавить логотип компании и корпоративные цвета.
Для сбора результатов можно использовать HTML-код, чтобы вставить тест на свой сайт, или же сгенерировать ссылку на него. У сервиса нет внутренних инструментов для аналитики, но взамен он предлагает подключить Google Analytics.
Конструктором можно пользоваться бесплатно — есть тариф для блогеров, небольших интернет-изданий. Кроме того, есть тариф «Образование» для музеев, образовательных проектов и некоммерческих организаций, также бесплатный. Цена за платные тарифы с расширенным функционалом начинается от 5900 рублей в месяц.
Плюсы: готовые шаблоны, позволяющие сделать действительно интересные тесты, приятный и удобный дизайн.
Минусы: нет возможности посмотреть результаты теста.
Фишки: коллекция шаблонов, чат с техподдержкой в окне конструктора, возможность подключить Google Analytics.
Почему стоит выбрать: если нужно сделать интересный развлекательный тест.
7. Qzzr
Еще один англоязычный конструктор тестов. Как и многие другие, позволяет добавить в вопросы не только текст, но и мультимедиа. Также поддерживает функцию перевода теста на десятки других языков, интеграцию с CRM-системой, платформами автоматизации маркетинга или управления данными.
Главной особенностью сервиса является возможность полностью адаптировать дизайн теста под любой сайт, даже менять шрифты.
Чтобы воспользоваться сервисом, нужно выбрать тариф. Цена основного и самого доступного — 24,99 $ в месяц. Если приобрести подписку на год — обойдется в 16,67 $ в месяц. Также основной тариф позволяет воспользоваться 14-дневной пробной версией, однако для этого вам придется сразу ввести данные банковской карты.
Плюсы: возможность адаптировать тест под дизайн сайта.
Минусы: английский язык, нельзя воспользоваться пробной версией без привязки банковской карты.
Фишки: интеграция с CRM, платформой автоматизации маркетинга или платформой управления данными, возможность перевода на десятки языков, возможность изменить шрифт текста в тесте.
Почему стоит выбрать: если вы хотите с помощью теста привлечь новых клиентов.
8. Testograf
Несмотря на название сервис специализируется на онлайн-опросах и формах. Здесь нет отдельного конструктора тестов, вопросы для тестирования находятся в конструкторе анкет. От обычных вопросов они отличаются тем, что к вариантам ответа можно добавлять баллы.
Дизайн конструктора несколько устаревший, но удобный. Весь процесс разработки анкеты разделен на этапы: создание, логика, настройки, дизайн. Вам нужно лишь следовать этим шагам. Конструктор также предлагает богатый функционал для дизайна анкеты.
Для сбора ответов можно распространять ссылки на тест, использовать email- и sms-рассылки, а также добавить на сайт виджет, всплывающее окно или встроить тест с помощью iframe. В качестве дополнительных услуг сервис предлагает поиск добровольных респондентов в интернете (в соцсетях, на форумах). Результаты теста обрабатываются автоматически, также их можно выгрузить в разных форматах: Word, Excel, PDF и CSV и пр.
Сервис платный, цена одного тестирования в течение двух месяцев — 4990 рублей. Годовая лицензия — 24990 рублей за одного сотрудника, годовая лицензия PRO+ — 49990 рублей. Также есть тестовый режим, где можно бесплатно попробовать создать тест и оценить функционал конструктора. Оплатить тарифы можно через расчетный счет, а также банковской картой и электронным кошельком.
Плюсы: конструктор прост в использовании, широкий функционал для дизайна анкет, есть настройка логики вопросов.
Минусы: устаревший дизайн конструктора, неочевидный путь к созданию теста.
Фишки: распространение теста с помощью pop-up и iframe.
Почему стоит выбрать: если нужен простой конструктор и профессиональный инструмент для анализа данных.