Большой плюс тестов внутри проекта это то что, если какое то изменение в коде проекта требует фикса тестов, чтобы они были актуальны, это разработчику будет сделать проще. Также не всегда тесты могут быть в отдельном проекте, например при автоматизации приложений под Android используя espresso возможна только в тесной связке с кодом приложения.
Согласен, писать Unit-тесты и тестировать свой код это хорошая практика, но не всегда так. В проектах где высокое качество кода описаный выше подход будет иметь одну эффективность, в проектах где качество кода ниже ценность данного подхода будет выше. Про замыливание глаза также согласен, но хорошей практикой является что PR разработчика проверяют его коллеги, в данной подходе они будут еще проверять код тестов. Также в результате прогона тестов будет сформирован отчёт с детальным описание шагов, который в свою очередь проверит тестировщик и если нужно подсветит моменты на которые нужно дописать тесты.
Любой необкатанный процесс нужно встраивать поэтапно и контролировать каждый этап. Например если при новом подходе какой то показатель качества начинает падать, нужно делать анализ ситуации и вносить корректировки. Внедрить ради того чтобы что то внедрить, это спорная практика
Интересный вопрос, всегда можно найти эксперта :D Как правило чтобы разбирать в тестировании необязательно самому всегда руками тестировать, хотя на первых этапах без этого конечно никуда.
Также нужно понимать, что для функционального тестировщика всегда найдётся что тестировать
Всё так, но всё же кажется что разработчиков и PM недооценивают, они тоже могут генерить интересные сценарии. Другой вопрос что нам нужно основной упор делать не на хитрость сценариев, а на то с чем может столкнуться пользователь. Если в этом месте возникнут трудности, тестировщик всегда может помочь сфокусировать внимание на главном(:
Всё зависит от разработчика, бывают разработчики которые консультируют тестировщиков о том как нужно тестировать, бывают те кто вообще не умеют тестировать, их могут консультировать тестировщики(:
Также новая функциональность может быть разная по сложности тестирования, к примеру если добавляется новый фильтр в приложение и нет ни одного теста на другие фильтры — в этом случаи могут возникнуть вопросы по тестированию. И наоборот, если добавляется новый фильтр и уже есть тесты на все остальные фильтры — в этом случаи написать тесты будет просто. Чем больше кодовой базы в автоматизации, тем проще писать последующие тесты на новый функционал(:
В такой парадигме жизнь тестировщика не упрощается, меняются задачи которые он решает, на его стороне остаётся экспертиза в тестировании.
Но в данном случаи речь речь не про облегчение или усложнение жизни или уход от регресса, как правило регресс можно просто покрыть автоматизаций, были бы свободные руки и желание. Речь о процессе в целом, в данном случаи нужно оценивать общий профит или его отсутствие, а не конкретного звена :D
То что не каждый разработчик умеет тестировать это правда и одна из основных сложностей, по этому на тестировании остается валидация тестов. Как это работает, разработчик пишет тесты и отдаёт в тестирование человкочитаемый отчёт c подробными шагами, с этой задачей отлично справляется Allure. Тестировщик смотрит на покрытие, и если тестов недостаточно то отправляет на доработку. С каждой итераций качество тестов растёт, а количество переоткрытий из-за багов уменьшается.
Про Unit-тесты, хорошее замечание, но как показывает практика часто они вовсе отсутствуют.
Спасибо что подсветил этот момент, так как мы исходили из формулы 24/7 что конечно не правильно(:
Также нужно понимать, что для функционального тестировщика всегда найдётся что тестировать
Также новая функциональность может быть разная по сложности тестирования, к примеру если добавляется новый фильтр в приложение и нет ни одного теста на другие фильтры — в этом случаи могут возникнуть вопросы по тестированию. И наоборот, если добавляется новый фильтр и уже есть тесты на все остальные фильтры — в этом случаи написать тесты будет просто. Чем больше кодовой базы в автоматизации, тем проще писать последующие тесты на новый функционал(:
Но в данном случаи речь речь не про облегчение или усложнение жизни или уход от регресса, как правило регресс можно просто покрыть автоматизаций, были бы свободные руки и желание. Речь о процессе в целом, в данном случаи нужно оценивать общий профит или его отсутствие, а не конкретного звена :D
Про Unit-тесты, хорошее замечание, но как показывает практика часто они вовсе отсутствуют.