Как тестируют в Google - страница 30

Замечу, что в Google выполняется очень много ручного тестирования, как сценарного, так и исследовательского, но даже оно проходит под зорким присмотром автоматизации. Технологии записи преобразуют ручные тесты в автоматизированные, которые снова прогоняются на последующих сборках, чтобы отловить регрессионные баги и дать тестировщикам возможность переключиться на новые проблемы. Мы автоматизируем отправку баг-репортов и распределение задач ручного тестирования[12]. Например, если автоматизированный тест не проходит, система определяет последнее изменение кода, которое считает наиболее вероятной причиной, отправляет сообщение его авторам и автоматически заводит баг. Максимально приблизить автоматизацию к человеческим возможностям – это техническое задание для следующего поколения инструментов тестирования, создаваемых в Google.

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

Другие тесты требуют знаний, выходящих за рамки кода, и зависят от внешней инфраструктуры. Например, у нас есть тест, который возвращает данные из удаленного хранилища (с сервера баз данных или из облака). Для тестирования нам нужна либо сама база данных, либо ее имитация. В индустрии уже выработались инструменты для этого: тестовая оснастка (harness), тестовая инфраструктура, подставные объекты (mocks) и имитации (fakes). В мире идеального процесса разработки эти макеты сразу существуют для любого интерфейса, с которым имеет дело разработчик, и каждый аспект любой функции можно протестировать в любое время. Но не увлекайтесь, мы находимся в воображаемом мире.