Что Тут
Ну так то разработать могут как разработчики, так и тестировщики (в некоторых случаях и мануальные) ровно в тот момент, когда разработчик приступает к написанию кода (т.е. в параллели пишется и сам код, и автотесты на него)
Разработка автотестов - это уже этап тестирования, так же как написание тестовых сценариев - ранний этап тестирования мануального. Помним тезис в статье о том, что несколько секунд и до этапа тестирования?
Для API автоматизация ложится легко, поддерживается просто, а окупается очень быстро.
Если не секрет, как много лет опыта в сфере тестирования у вас, что вы так очень уверенно высказываетесь о легкости автоматизации сценария одновременно с разработкой компонента?
Куда API автоматизация будет ложиться, если автоматизатор не знает эндпоинтов API этого компонента и его контракта (который, кстати, может еще и измениться)? На этапе тестирования, бывает, выясняется, что бэкенд и фронтенд не смогли по этому контракту договориться, сидя в одном кабинете и работая над одной фичей, а вы хотите аналогичной вовлеченности человека или группы людей, которым еще пачку таких компонентов надо описать в сценариях.
Но! Важно тут не вырывать один кусочек из контекста
В статье этот "кусочек" является финальным аргументом в блоке о последствиях недостаточной автоматизации. Действительно, совсем маленький кусочек, почти вырвал из контекста.
Утверждения в большинстве своем верны для UI тестов. Поэтому - подход с умом.
А можно аргументы услышать о том, что утверждения о трудоемкости автоматизации и актуализации сценариев применимы в большей степени для UI тестов?
Я, если честно, не совсем понимаю зачем вы написали такой длиный и отвлеченный ответ на простой, по сути, мессадж - автотестирование не будет работать так, как было описано в вышеупомянутой цитате.
Разработчик написал компонент, прогнал тесты и через секунду понял, что все хорошо/плохо без стадии тестирования - так не бывает. А если так попытаться сделать, то это будет или дорого или assert(true).
Это такая же несбыточная мечта бизнеса, как и та, где в бдд подходе все стейкхолдеры успешно пишут автотесты на функционал. Я видел истории (не)успеха и первого и второго в рамках нескольких компаний и опыта коллег. Хотя те, кто это продавали вполне достигли коммерческого успеха, тут бесспорно.
Решить эту проблему можно за счет автоматических тестов. При должной автоматизации проверить новый компонент можно моментально после завершения работы, а значит программист сможет сразу же исправить ошибки, которые будут выявлены за несколько секунд вместо нескольких дней, и, главное, еще до тестирования и старта продуктивной эксплуатации.
Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?
На этапе разработки, даже разработчик(а бывает, что еще и системный аналитик) точно не знает, правильно ли были интерпертированы спецификации на компонент, что, в свою очередь, вызывает последующие его изменения, с целью приведения к требуемой форме и содержанию.
Автоматические тесты, в свою очередь, пишутся в тот момент, когда функционал максимально стабилен, так как они должны отталкиваться от технической части реализованного функционала (не напишет специалист тест, если у него нет понятия о том как компонент будет сверстан или его эндпоинтах и бизнеслогике). В описаной вами парадигме компанию можно загнать только в большие траты на ФОТ, так как сотрудники будут бесконечно адаптировать сценарии под изменяющееся поведение компонента. Ведь, я напомню, трудоемкость автоматизации и поддержания сценариев в актуальном виде достаточно высока.
Даже в случае проведения исключительно регрессионного тестирования, имеют место быть трудозатраты, связанные с актуализацией кодовой базы сценариев, с целью убрать побочные эффекты от изменений, затрагивающие существующие сценарии, например.
Так что, даже если "секунды" были гиперболизацией, то все равно, до фазы тестирования вам(нам/всем) ничего не светит.
коэффициент полезности разный.
на этом и схожих ресурсах есть статьи/блоги, пиарящие свою компанию. только вот статьи одних компаний читают с упоением (мосигра, например), а статьи других остаются без какого-то внимания (эта, например) или улетают в минуса.