Разработчик в тестировании работает с тем же кодом, что и разработчик, но занимается скорее повышением качества и тестовым покрытием, чем добавлением новых фич или повышением производительности.
Chrome и Chrome OS (кстати, сейчас эту должность занимает один из моих бывших подчиненных), поэтому видел организацию тестирования в Google только с одной стороны. Мне нужно было узнать еще много всего о тестировании в Google.
К сожалению, нет. Идея с поощрением не сработала. Разработчики поняли, что для создания нормальных тестов им нужно писать две-три строки кода юнит-тестов на каждую строку тестируемого кода. Вдобавок тесты тоже нужно сопровождать, и в них самих могут заводиться баги. Стало очевидно, что одними разработчиками в юнит-тестировании сыт не будешь. Нам нужны были интеграционные тесты, системные тесты, тесты пользовательского интерфейса и прочие полезные штуки. Нам предстояло еще много узнать о тестировании и многому научиться, причем сделать это надо было быстро. Очень быстро!
Я пришла в тестирование в 2006 году маленьким тестировщиком на большой аутсорсный проект. Сначала я научилась тестировать, заводить баги и общаться с разработчиками и менеджерами. Со временем я стала писать тесты, научилась планировать и управлять тестированием. У меня появилась своя команда.
Команды разработчиков испытывали сильное давление. Google начал покупать компании со своими веб-приложениями (YouTube, Google Docs и прочие), которые только усиливали нагрузку на нашу внутреннюю инфраструктуру. Проблемы, с которыми я сталкивался в тестировании, не уступали проблемам, с которыми сталкивались разработчики при написании кода. Я пытался решить проблему тестирования, которую просто невозможно было решить отдельно от разработки. Рассматривать тестирование и разработку как обособленные дисциплины или даже как разнородные задачи было в корне неверно, и мы не могли решить ни одну из проблем. Улучшение команды тестирования стало бы всего лишь временным успехом.
Мы считаем, что тестировщику достаточно 18 месяцев работы над одним продуктом, а потом он может (если, конечно, хочет) перейти в другую команду. Конечно, есть и ложка дегтя — команда теряет накопленный опыт. Но это компенсируется появлением тестировщиков с широким кругозором, знакомых с разными продуктами и технологиями.
Любой инженер, независимо от своей роли, может заниматься любыми типами тестов. Их можно проводить в ручном или запускать в автоматическом режиме. Реальный опыт говорит, что чем меньше тест, тем скорее он будет автоматизирован.
На заметку
Вместо того чтобы разделять тестирование на модульное, интеграционное и системное, мы делим все тесты на малые, средние и большие, исходя из их охвата, а не размера.