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