Описание ошибок тестирования

Аэробная выносливость оценивается с помощью сит-теста (Патент № 1729485), представляющего собой циклическое движение «сесть-встать» на стуле, в течение 3-х минут в темпе, задаваемом метрономом. Высота сидения (стула) подбирается в соответствии с ростом испытуемого таким образом, чтобы угол, образуемый бедром и голенью в положении сидя составлял 90 градусов. Рекомендуемая высота стула в зависимости от роста обследуемого приводится ниже:

Увеличение высоты сидения обеспечивается за счет плоских накладок толщиной по 5 см.

Проведение теста. После небольшого отдыха (около 5 минут без помех, отвлекающих звуковых и световых раздражителей) измеряется пульс (ЧССпок). Если ЧССпок оказывается более 100 ударов в минуту, то тест не проводится (следует обратиться к врачу).

ЧСС можно измерить на сонной, височной или лучевой артерии. При измерении на лучевой артерии накладывают чуть выше лучезапястного сустава второй, третий и четвертый пальцы. Измеряется количество ударов за 6 с и полученное значение умножается на 10 для получения значения пульса за минуту. При наличии электронного пульсометра процедура измерения ЧСС упрощается.

В темпе, задаваемом звуковым сигналом (таймер, метроном), необходимо садиться и вставать со стула в течение 3-х минут. Темп циклических движений – 27 полных циклов (сесть-встать) для мужчин и 26 – для женщин. При отсутствии метронома можно ориентироваться по часам – за 1 секунду встать, за 1 секунду сесть. В течение 1 минуты совершать 30 циклов. В конце третьей минуты следует остановиться и стоя вновь произвести измерение ЧСС (ЧССнагр) за 6 с и полученную величину умножить на 10. После этого сесть и отдыхать 1 минуту (не разговаривая), в конце ее провести третье измерение ЧСС (ЧССвосст) за 6 с и полученную величину умножить на 10.

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

Индекс = (ЧССпок + ЧССнагр + ЧССвосст – 200) : 10

Оценка уровня аэробной выносливости для людей в возрасте 21 год и старше:

(72 + 132 + 76 – 200) : 10 = 8,0

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

Исходя из уровня общей выносливости, можно выбрать соответствующий режим тренировки. В данном случае это развивающий режим с интенсивностью нагрузки 70% от ЧСС максимальной, продолжительностью одного занятия 40-50 минут, количеством занятий в неделю – 3-4, энерготратам в одном занятии – 300-400 килокалорий.

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

Видео «Технология проведения сит-теста»

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

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

Качественное описание вместо количественного

«Ошибка повторяется редко»

Очень часто я встречал такую ситуацию, когда тестировщик в описании ошибки использует именно такие слова. Чем это плохо? Когда мы говорим: «часто», «редко», «иногда» и т.д., то не можем объективно донести информацию до читающего. У каждого человека есть свое «часто» в голове и оно может очень сильно отличаться от вашего. Следовательно, описание ошибки может быть неправильно воспринято.

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

Что же произошло?
Оказывается, что для меня редко — это 3 раза из 10. Т.е. из 10 пользователей только у 3-х будет проблема. Вроде бы не очень много? Но если увеличить цифры до 1000 пользователей, то получим 300 падений приложения. А это уже совсем другое дело. Зная это, разработчик мог заранее принять меры к исправлению проблемы. Но он не знал о цифрах и подумал, что “редко” это всего лишь в одном случае из 100.

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

Общий заголовок

«Ошибка на главной странице»

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

Для качественного заголовка можно также использовать принцип «Что? Где? Когда?». То есть заголовок должен отвечать на вопросы: Что произошло? Где произошло? При каких условиях или когда?

Эмоции в описании

«Когда я нажимаю на эту кнопку, то вообще ничего не работает!»

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

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

Объемное и неструктурное описание ошибки

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

Сложно читается? Мне точно да.

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

Если структура есть, но описание все-равно громоздкое, то проверьте, нет ли в вашем тексте лишних неинформативных слов. Баг-репорт — это технический документ и должен содержать максимум полезной информации. Для написания таких документов советую прочитать книгу «Пиши, сокращай».

Баг-репорты часто возвращаются к вам с уточняющими вопросами

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

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

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

На этом цикл подошел к концу. Напомню, что предыдущие статьи можно почитать тут:
Назначение отчета https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-naznachenie/
Шаблон отчета об ошибке https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-shablon-otcheta-ob-oshibke/
Приоритет и Серьезность https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-prioritet-i-sereznost/

1. Классификация ошибок

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

Для классификации
ошибок мы должны определить термин
«ошибка».

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

Итак, по времени
появления ошибки можно разделить на
три вида:

– структурные ошибки
набора;

– ошибки компиляции;

– ошибки периода
выполнения.

Структурные
ошибки
возникают непосредственно при наборе
программы. К данному типу ошибок относятся
такие как: несоответствие числа
открывающих скобок числу закрывающих,
отсутствие парного оператора (например,
try
без catch).

Ошибки
компиляции
возникают из-за ошибок в тексте кода.
Они включают ошибки в синтаксисе,
неверное использование конструкции
языка (оператор else
в операторе for
и т. п.), использование несуществующих
объектов или свойств, методов у объектов,
употребление синтаксических знаков и
т. п.

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

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

В теоретической
информатике программные ошибки
классифицируют по степени нарушения
логики на:

– синтаксические;

–семантические;

– прагматические.

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

– пропуск необходимого
знака пунктуации;

– несогласованность
скобок;

– пропуск нужных
скобок;

– неверное написание
зарезервированных слов;

– отсутствие описания
массива.

Все ошибки данного
типа обнаруживаются компилятором.

Семантические
ошибки
заключаются в нарушении порядка
операторов, параметров функций и
употреблении выражений. Например,
параметры у функции add
(на языке Java)
в следующем выражении указаны в
неправильном порядке:

GregorianCalendar.add(1,
Calendar.MONTH).

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

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

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

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

Ошибка
адресации
– ошибка, состоящая в неправильной
адресации данных (например, выход за
пределы участка памяти).

Ошибка
ввода-вывода
– ошибка, возникающая в процессе обмена
данными между устройствами памяти,
внешними устройствами.

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

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

Ошибка
обращения к данным
– ошибка, возникающая при обращении
программы к данным (например, выход
индекса за пределы массива, не
инициализированные значения переменных
и др.).

Ошибка
описания данных
– ошибка, допущенная в ходе описания
данных.[2]

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #