Что такое тестер программного обеспечения?
Тестеры программного обеспечения проходят под разными именами в зависимости от прихоти работодателя. Они могут быть известны как инженеры-тестировщики программного обеспечения, специалисты по функциональному тестированию или просто тестировщики. Название имеет мало отношения к задачам, выполняемым человеком, занимающим эту должность.
Искаженное определение тестирования программного обеспечения распространялось с тех пор, как эта концепция была впервые представлена. В нем говорится, что основной задачей тестировщика программного обеспечения является поиск ошибок или дефектов в тестируемой программе. Это восприятие вводит в заблуждение по нескольким причинам. Во-первых, по определению, если тестировщики не могут найти какие-либо недостатки или дефекты в программе, они не выполняют свою работу. На практике тестеры могут обнаружить много дефектов в разрабатываемом приложении; однако цель состоит в том, чтобы в конечном итоге они устранили все расхождения. На данный момент они не могут продолжить работу.
Во-вторых, подход к задаче в качестве обязанности по обнаружению ошибок мгновенно делает отношения тестера и разработчика антагонистическими. Если работа тестировщика состоит в том, чтобы найти ошибку, то разработчик будет защищаться. Вместо этого две роли должны работать для достижения общей цели. Антагонистическая среда не способствует положительным результатам.
Проверка против проверки
Подход тестера должен заключаться в проверке и валидации тестируемого программного обеспечения. Термины проверки и подтверждения могут показаться похожими, но при применении здесь они совершенно различны. Проверка заключается в том, чтобы доказать, что приложение работает правильно и выполняет работу, которую разработчик намеревался. Если программист намеревается предоставить сумму чисел, введенных пользователем, запись 1, 2 и 3 должна привести к результату 6.
Валидация, с другой стороны, подтверждает, что программа выполняет задачу, запрошенную клиентом. Взяв предыдущий пример, предположим, что клиенту требуются только нечетные числа для использования в пакете поиска сумм. Запись 1, 2 и 3 приведет к новому результату 4; то есть 1 и 3.
Подтверждение подтверждает, что продукт выполняет задачу должным образом; проверка гарантирует, что продукт выполняет правильную задачу.
Более реалистичный пример
Предположим, что у нас есть ситуация со следующими требованиями: при запуске приложения появится окно, содержащее поле идентификационного номера и кнопку «Просмотр». Как только пользователь вводит идентификационный номер и нажимает кнопку «Просмотр», отображаются данные, содержащие личную информацию (например, имя, возраст, адрес, номер социального страхования и т. Д.) О человеке. Однако, прежде чем это произойдет, необходимо проверить уровень авторизации пользователя. Если пользователь не авторизован для просмотра такой информации, данные не будут отображаться, и пользователь будет уведомлен соответствующим образом.
Разработчик может подумать: «Это достаточно просто. Я проверю разрешения пользователя на авторизацию и, если он не авторизован, просто отключу кнопку «Просмотр», чтобы сделать ее непригодной для использования. Проблема решена.
Войдите в тестер программного обеспечения. В качестве пользователя она входит в систему без необходимых разрешений для просмотра личных данных. Она вводит идентификационный номер и пытается нажать кнопку «Просмотр». Ничего не произошло. «Ну, — думает она, — программа, кажется, работает правильно в этих условиях, поскольку конфиденциальные данные не отображаются. Но не должен ли пользователь каким-либо образом уведомляться о том, что запрос был отклонен? »
Тестировщик передает проблему разработчику и объясняет ее позицию. Разработчик отвечает, что его подход намного проще, поскольку требует меньше кода (следовательно, он более рентабелен). Тестировщик отвечает, что, хотя она понимает аргументы разработчика, требуется больше.
Вместе они представляют свое дело клиенту, который подтверждает, что должно появиться сообщение о том, почему пользователю было отказано в доступе. Теперь у разработчика есть право заново открыть код и внести необходимые изменения.
Обнаружение дефектов на этом уровне намного экономичнее, чем обнаружение той же самой ошибки после доставки системы. Эмпирическое правило гласит, что каждый уровень, на котором обнаружен дефект, стоит в десять раз дороже, чем на предыдущем уровне. Другими словами, тестеру стоит в десять раз дороже найти и инициировать исправление ошибки, чем если бы разработчик обнаружил свою собственную ошибку. А выявление проблемы на местах обойдется в сто раз дороже.
Работа в команде — это успех
Когда тестировщики и разработчики работают в команде, успех гораздо выше, чем при самостоятельной работе. Очевидно, что на ранней стадии между ними необходимо установить совместимые и уважительные рабочие отношения. Это не только создает хорошую основу для достижения целей, но и создает более приятную рабочую среду.