Кисель в Айти | Python разработка
13.02
Вы знали, что существует флоу, в котором просто нет тестировщиков? Совсем. Меня такой подход сильно удивил. И речь именно о крупных проектах, которые не жмутся за каждого человека в штате.
Мне удалось чуть нагуглить про этот подход. Вот что заявлено в преимуществах: - Полное покрытие тестами любого кода естественным процессом. - Не размывается ответственность. За баги в проде попадает по шапке именно тому, кто сделал фичу, а не тестировщику, который её пропустил. - Быстрее проходит цикл разработки. Сами сделали, сами протестировали, отдали ПМу на “показ”. Меньше движений и согласований.
Вроде и здраво, но я в эту схему не верю. Огромное преимущество отдельного тестировщика в том, что он эту фичу не делал и не в курсе всех тонкостей. Бонусом к этому идут отличия в подходах и мышлении. Мы все мыслим по-своему. Могут отличаться проверки и их последовательность, а это всё повышает шансы найти больше неочевидных ошибок. И давайте не забывать огромное количество инструментов, которые придумали специально для тестирования.
И даже если каждый разработчик допинал все свои фичи до релиза, то кому же проводить регресс тестирование? А там может быть и 1000 пунктов, запросто. Многие кейсы просто так не прокликаешь. Нужно подготовить правильное состояние в БД или еще что-нибудь. Конечно можно поднатужится всей командой и пропасть на 3-4 дня. А в процессе еще и ходить на самого себя заводить задачки. Как то не вкусно.
В общем "эволюция" в обратную сторону, никак еще не могу назвать такие эксперименты. Как только проекты начали расти в сложности и размерах, всё тестирование было выведено в отдельный процесс. А здесь попытка всё упростить и придумать свой велосипед. Давайте еще весь CI/CD на разработчиков повесим. Будем 1 день писать код, 2 дня тестировать и 4 дня выкатывать.
Пошли бы работать в такую команду? 💻
еще контент в этом сообществе
еще контент в этом соообществе
Кисель в Айти | Python разработка
13.02
войдите, чтобы увидеть
и подписаться на интересных профи