Ускорение Time to Market: реально ли выпускать обновления в 3-5 раз быстрее?
Для многих компаний проблема выпуска новых версий ПО — это настоящая боль, которая связана с длительным и затратным тестированием, устранением багов и огромными потерями времени. Поэтому сегодня мне хочется рассказать про ускорение Time to Market и о тех бизнес-выгодах, которых можно достичь за счет улучшения процессов разработки ПО и автоматизации…
Решить эту проблему можно за счет автоматических тестов. При должной автоматизации проверить новый компонент можно моментально после завершения работы, а значит программист сможет сразу же исправить ошибки, которые будут выявлены за несколько секунд вместо нескольких дней, и, главное, еще до тестирования и старта продуктивной эксплуатации.
Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?
На этапе разработки, даже разработчик(а бывает, что еще и системный аналитик) точно не знает, правильно ли были интерпертированы спецификации на компонент, что, в свою очередь, вызывает последующие его изменения, с целью приведения к требуемой форме и содержанию.
Автоматические тесты, в свою очередь, пишутся в тот момент, когда функционал максимально стабилен, так как они должны отталкиваться от технической части реализованного функционала (не напишет специалист тест, если у него нет понятия о том как компонент будет сверстан или его эндпоинтах и бизнеслогике). В описаной вами парадигме компанию можно загнать только в большие траты на ФОТ, так как сотрудники будут бесконечно адаптировать сценарии под изменяющееся поведение компонента. Ведь, я напомню, трудоемкость автоматизации и поддержания сценариев в актуальном виде достаточно высока.
Даже в случае проведения исключительно регрессионного тестирования, имеют место быть трудозатраты, связанные с актуализацией кодовой базы сценариев, с целью убрать побочные эффекты от изменений, затрагивающие существующие сценарии, например.
Так что, даже если "секунды" были гиперболизацией, то все равно, до фазы тестирования вам(нам/всем) ничего не светит.
Мммм, ну лаааадноооо... )
>>Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?<<<<
Ну так то разработать могут как разработчики, так и тестировщики (в некоторых случаях и мануальные) ровно в тот момент, когда разработчик приступает к написанию кода (т.е. в параллели пишется и сам код, и автотесты на него) - ведь тут не обзательно речь только о Unit тестах. Никто же не говорил, что это обязательно UI тесты. Для API автоматизация ложится легко, поддерживается просто, а окупается очень быстро. И да - применимо далеко не всегда, да и подсчет ROI перед автоматизацией никто не отменял. Но! Важно тут не вырывать один кусочек из контекста. К сокращению времени, а значит, и затрат, приводит именно комплекс мер, а не просто автоматизированные тесты (речь в статье шла и об авторазвертывании, и об автоматической подготовке данных, и о гибких методологиях), - там, где он целесообразен. Принцип необходимости и достаточности никто не отменял.
>>>>На этапе разработки, даже разработчик (а бывает, что еще и системный аналитик) точно не знает, правильно ли были интерпертированы спецификации на компонент, что, в свою очередь, вызывает последующие его изменения, с целью приведения к требуемой форме и содержанию<<<<<
В любом случае, и тестировщик, и разработчик опираются на спецификацию. Да, в ней тоже бывают ошибки - и они выявляются на этапе тестирования документации - т.е. также заранее, а не после того, как код уже был разработан и пришел в тестирование. Как простой пример - вот есть xsd. Никто не мешает нам сгенерить из нее xml (или проверить генерируемую нашей системой xml - в случае, когда наша система - инициатор вызова) и проверить обработку этой xlm в нашем api на соответствие спецификации еще на этапе кодирования. Все это просто и заранее можно автоматизировать.
>>>>Автоматические тесты, в свою очередь, пишутся в тот момент, когда функционал максимально стабилен, так как они должны отталкиваться от технической части реализованного функционала (не напишет специалист тест, если у него нет понятия о том как компонент будет сверстан или его эндпоинтах и бизнеслогике). В описаной вами парадигме компанию можно загнать только в большие траты на ФОТ, так как сотрудники будут бесконечно адаптировать сценарии под изменяющееся поведение компонента. Ведь, я напомню, трудоемкость автоматизации и поддержания сценариев в актуальном виде достаточно высока.<<<<<
Утверждения в большинстве своем верны для UI тестов. Поэтому - подход с умом.