Будни тестировщика

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

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

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

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

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

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

Ниже будет приведено несколько примеров дефектов. Обратите внимание, что сообщение о дефекте представляет описание дефекта, а не то, как он может быть исправлен. В первом примере существует множество путей, позволяющих решить проблему дефекта - сообщение по умолчанию для экрана ошибки "HTTP 500 Internal Server Error" можно изменить таким образом, чтобы к нему добавить фразу "Нажмите кнопку Назад, чтобы попробовать снова", или в программный код может быть добавлена проверка на нулевой указатель, и поэтому исключение никогда не возникнет, или внутри обработчика исключений может сработать дополнительный обработчик ошибок...

Для некоторых дефектов поля могут быть намеренно оставлены пустыми. Например, если дефект сравнительно простой и для него нет какой-то дополнительной информации, то в поле "Заметки" можно проставить "Нет". Во многих случаях, когда ожидаемое поведение очевидно, в соответствующем поле также можно проставить "Нет"; если наблюдаемое поведение "система вылетает", то для большинства обозревателей очевидно, что ожидаемое поведение будет "система не вылетает". Лучше написать "Нет", "N/A" или какой-то другой знак, благодаря чему у изучающих сообщение о дефекте не возникнет впечатления, что тестировщик просто забыл заполнить какие-то поля...

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

В поле "Решение" описывается, как избежать дефекта или по крайней мере смягчить его. Предположим, что дефектом является ситуация, когда в пароле не получается использовать специальные символы. Тогда решением станет выбор только алфавитно-цифровых. Важно заметить, что решениями не всегда являются хорошие решения; в них может не задействоваться определенный функционал. Например, если в текстовом редакторе не работает функция подсчета слов, решением может стать отказ от использования подсчета или применение другой программы (например, wc –w в UNIX). Это может вызвать дискомфорт и недовольство у пользователя, но позволит получить доступ к функциональности...

Связанным с полем "Влияние" является поле "Серьезность", которое содержит начальное впечатление сообщающего о дефекте о том, насколько серьезна проблема. Это может быть описано либо в качественном отношении (т. е. "Это реально, реально плохо. Реально, реально, реально плохо" или "Если честно, это совсем не проблема"), либо при помощи стандартизованной шкалы количественно. Последнее гораздо популярнее, но обычно у каждой организации имеется свой подход. Это может быть нечто совсем простое вроде цифровой шкалы, где "1" означает очень незначительную мелочь, а "10" оказывается непреодолимой проблемой...

Тестировщику необходимо понимать, какое влияние дефект окажет на пользователей. Это должно быть разъяснено в поле "Влияние". Будьте осторожны, чтобы не впасть в разглагольствования и не сделать этот раздел чересчур общим. Скажем, фон в игре во время прыжка игрока меняется с голубого на фиолетовый. Фактически описание влияния должно быть таким: "Пользователь увидит изменение цвета фона, но на игровой процесс это не повлияет". Версия с разглагольствованиями может выглядеть так: "Пользователь возненавидит эту игру и всех, кто ее делал, потому что тупой фон меняет тупой цвет, когда тупой пользователь делает что-то тупое"...