Ex ante: Кажется, есть много путаницы в том, что считается проверкой того, что нет. Конечно, каждый разработчик должен тестировать свой код по мере его создания, он / она должен проверить, работает ли он. Она / он не может передать это тестеру, пока он / она не подумает, что это сделано и достаточно хорошо. Но разработчики не все видят. Они могут не распознавать ошибки. Эти ошибки могут быть обнаружены только позже в цикле разработки, когда проводится тщательное тестирование. Вопрос в том, должны ли разработчики проводить такого рода тестирование или нет, и, по моему скромному мнению, на это нужно смотреть с точки зрения руководителя проекта:
Разработчики могут быть тестерами, но они не должны быть тестерами . Разработчики склонны непреднамеренно / неосознанно избегать использования приложения таким образом, чтобы это могло его сломать. Это потому, что они написали это и в основном проверяют, как это должно быть использовано.
Хороший тестер, с другой стороны, пытается замучить приложение. Его / ее основное намерение состоит в том, чтобы сломать это. Они часто используют приложение так, как его не могли бы представить разработчики. Они ближе к пользователям, чем разработчикам, и часто у них другой подход к тестированию рабочего процесса.
Кроме того, использование разработчиков в качестве тестировщиков увеличивает затраты на разработку и не приносит такой же выгоды для качества продукта, как наличие специального тестировщика. Я бы не позволил разработчикам перепроверить свои работы, если бы я смог сделать это лучше с помощью тестера за дешевизну. Только если бы обратная связь между разработчиками и тестировщиками стала слишком дорогой, разработчики могли бы перепроверять код друг друга, но, по моему опыту, это редко бывает, и это сильно зависит от процесса.
Это не означает, что разработчик должен быть неаккуратным и оставить все тестеру. Программное обеспечение должно быть подкреплено модульными тестами, а технические ошибки должны быть сведены к минимуму перед передачей программного обеспечения тестеру. Тем не менее, иногда у вас есть исправления, проблемы или другие ошибки, которые не мог предвидеть ни один разработчик, это нормально. Также интеграционное тестирование должно проводиться в основном разработчиками. Основная задача тестера - убедиться, что требования выполнены.
В такой небольшой команде (а также в зависимости от размера приложения) я также вижу тестировщика в гибридной роли, пишущего юнит-тесты и тесты пользовательского интерфейса. Вы обязательно должны нанять один .
Но более важными, чем тестер, являются регулярные зависания / ветки. Не представляйте ничего, что не было должным образом проверено. Когда вы добавили функцию или что-то изменили, все, что ее окружает, должно быть проверено снова. Вы получите плохую репутацию, только если ваша компания этого не сделает. Не выпускайте что-то нестабильное Когда клиент хочет получить программное обеспечение к определенной дате, тогда прекратите разработку достаточно рано и протестируйте его должным образом, чтобы у вас было достаточно времени для исправления ошибок. Часто лучше отклонять запросы функций в последнюю минуту, чем плохо их реализовывать или выпускать без надлежащего тестирования.