Comments 5
А вам не кажется, что приаеденные примеры - это юнит-тесты и это не дело тестировщиков (по QA automation), а дело самих программистов. Если же тестировщики пишут такое за программистов, это неверно построенные процессы в команде. Конечно, моё имхо.
То есть, я бы добавил в теги unit testing и убрал бы все теги с QA.
Привет. У нас в командах широко применяется практика T-shape. Плюс в целом пишутся нативные тесты. Поэтому куа не запрещается писать юниты (скажу больше, куа даже правят простенькие баги, а разработка тестирует задачи). Возможно у вас или у кого-то в команде действительно куа не пишут юниты и в целом это тоже подход, который имеет место быть.
Не возможно, а так вообще-то задумано и так правильно.
Привет. Вклинюсь в обсуждение. Есть современный тренд на то, что разработка и тестирование все больше интегрируются друг в друга. И как результат можно получить следующие вещи:
1. Разработка -> куа
Существуют команды без куа, его обязанности распределяются по команде. Если нужна какая-то помощь в процессах, то может приглашаться какой-то сторонний куа для консультации
2. Куа -> разработка
Как следствие роста требований и интересу к автоматизации тестирования порой уже недостаточно просто быть ручным тестировщиком или уметь писать UI-автотесты, во многих компаниях уже даже включают исправление багов как возможный артефакт подтверждения квалификации. Разработка, конечно, должна писать Unit-тесты на свой код, но зачастую покрывает не все возможные кейсы, в таких случаях подобные кейсы вполне может дописать куа. Это будет считаться нормальной практикой.
Разработка в QAA - нормально и логично, за счёт уменьшения объёма имплементации фич. Хотя и имеет большой недостаток - автор фичи обычно тестирует свою работу формально, быстро и неполно. Сторонний человек гораздо лучше для этой цели.
QAA в разработку - возможно, но очень плохо. Обычно есть один тестировщик на 5 разработчиков (грубо). Все они делают ошибки. Чтобы иметь возможность замечать недостаточное покрытие юнит-тестами у каждого, тестировщик должен не только хорошо знать язык разработки и полностью понимать, что понаписали пятеро, но и глубоко вникать в код каждого и быть в курсе. То есть, это некий суперпрограммист-тестировщик, который знает код каждого разработчика. Не знаю таких случаев и не вижу их смысл.
Если тестировщик фиксит баги разработчиков, то это ещё более неверный случай. 16 лет назад я работал крутым программистом, который фиксил баги остальной группы из 5 разработчиков. Баги, обнаруженные клиентами в нашем продукте. Это было очень глупо и очень неэффективно, потому что я постоянно тратил время на вникание в чужой код. То есть, автору кода надо было бы в 10-20 раз меньше времени на ту же работу. Но какое-то высокое начальство, которое уже давно забыло или никогда не знало, что такое программирование, решило, что так будет лучше. Фирма, кстати, называлась IBM.
Моки, стабы и фейки: в чем разница и когда что использовать?