Крупные банки, страховые, ритейл и даже промышленность последние 5-6 лет говорят о себе, как об ИТ-компаниях. Но если для fin-, ed-, food-стартапов приставка tech и скорость работы — это их свойства с рождения, то для крупного бизнеса — 4 месяца на выпуск релиза с блокирующими и критическими ошибками на продуктиве — это печальная реальность, с которой компании ведут неравный бой.
Решить эту проблему можно за счет автоматических тестов. При должной автоматизации проверить новый компонент можно моментально после завершения работы, а значит программист сможет сразу же исправить ошибки, которые будут выявлены за несколько секунд вместо нескольких дней, и, главное, еще до тестирования и старта продуктивной эксплуатации.
Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?
На этапе разработки, даже разработчик(а бывает, что еще и системный аналитик) точно не знает, правильно ли были интерпертированы спецификации на компонент, что, в свою очередь, вызывает последующие его изменения, с целью приведения к требуемой форме и содержанию.
Автоматические тесты, в свою очередь, пишутся в тот момент, когда функционал максимально стабилен, так как они должны отталкиваться от технической части реализованного функционала (не напишет специалист тест, если у него нет понятия о том как компонент будет сверстан или его эндпоинтах и бизнеслогике). В описаной вами парадигме компанию можно загнать только в большие траты на ФОТ, так как сотрудники будут бесконечно адаптировать сценарии под изменяющееся поведение компонента. Ведь, я напомню, трудоемкость автоматизации и поддержания сценариев в актуальном виде достаточно высока.
Даже в случае проведения исключительно регрессионного тестирования, имеют место быть трудозатраты, связанные с актуализацией кодовой базы сценариев, с целью убрать побочные эффекты от изменений, затрагивающие существующие сценарии, например.
Так что, даже если "секунды" были гиперболизацией, то все равно, до фазы тестирования вам(нам/всем) ничего не светит.
Мммм, ну лаааадноооо... )
>>Подскажите, пожалуйста, кто же и на какой стадии разработает эти автоматические тесты, которые в секунду найдут ошибки в новом (sic!) компоненте?<<<<
Ну так то разработать могут как разработчики, так и тестировщики (в некоторых случаях и мануальные) ровно в тот момент, когда разработчик приступает к написанию кода (т.е. в параллели пишется и сам код, и автотесты на него) - ведь тут не обзательно речь только о Unit тестах. Никто же не говорил, что это обязательно UI тесты. Для API автоматизация ложится легко, поддерживается просто, а окупается очень быстро. И да - применимо далеко не всегда, да и подсчет ROI перед автоматизацией никто не отменял. Но! Важно тут не вырывать один кусочек из контекста. К сокращению времени, а значит, и затрат, приводит именно комплекс мер, а не просто автоматизированные тесты (речь в статье шла и об авторазвертывании, и об автоматической подготовке данных, и о гибких методологиях), - там, где он целесообразен. Принцип необходимости и достаточности никто не отменял.
>>>>На этапе разработки, даже разработчик (а бывает, что еще и системный аналитик) точно не знает, правильно ли были интерпертированы спецификации на компонент, что, в свою очередь, вызывает последующие его изменения, с целью приведения к требуемой форме и содержанию<<<<<
В любом случае, и тестировщик, и разработчик опираются на спецификацию. Да, в ней тоже бывают ошибки - и они выявляются на этапе тестирования документации - т.е. также заранее, а не после того, как код уже был разработан и пришел в тестирование. Как простой пример - вот есть xsd. Никто не мешает нам сгенерить из нее xml (или проверить генерируемую нашей системой xml - в случае, когда наша система - инициатор вызова) и проверить обработку этой xlm в нашем api на соответствие спецификации еще на этапе кодирования. Все это просто и заранее можно автоматизировать.
>>>>Автоматические тесты, в свою очередь, пишутся в тот момент, когда функционал максимально стабилен, так как они должны отталкиваться от технической части реализованного функционала (не напишет специалист тест, если у него нет понятия о том как компонент будет сверстан или его эндпоинтах и бизнеслогике). В описаной вами парадигме компанию можно загнать только в большие траты на ФОТ, так как сотрудники будут бесконечно адаптировать сценарии под изменяющееся поведение компонента. Ведь, я напомню, трудоемкость автоматизации и поддержания сценариев в актуальном виде достаточно высока.<<<<<
Утверждения в большинстве своем верны для UI тестов. Поэтому - подход с умом.
Если у крупной компании нет автоматизированного тестирования, а только ручное - что-то там не так с руководством. Автоматизация тестов - не панацея, а лишь способ срезать косты на ручное тестирование, умнее и грамотнее разработчиков она не делает, все равно будут ошибки в релизах. Чтобы уменьшить Time-To-Market надо либо оптимизировать процессы, либо нанять более квалифицированных людей, либо резать количество новых фич.
Проблема больших компаний в первую очередь в чрезмерном количестве людей в подразделениях. Есть эффективное количество людей на проект, это крайне емкое количество (на минуточку рассчитывается индивидуально, но как правило 3-7 человек). Как ни парадоксально, но если добавить людей, быстрее продукт не будет готов. Напротив, сроки увеличатся.
Именно поэтому стартапы выпускают продукты и фичи быстро, а большие компании долго. Дальше организационная история, плюс выбранная система управления проектом. Ибо вотерфольная разработка априори дает большой срок. А гибкая методология (к слову, не всем подходит, а еще меньше умеют с ней работать) позволит клепать фичи хоть каждые 1-3 недели.
ИМХО. Статья ради пиара.
Все в этой жизни либо ради пиара, либо ради лени :)
Большие = неповоротливые, маленькие = юркие - это аксиома еще из 6 класса биологии, согласен. Автоматизация хоть как-то позволяет играть большим если не наравне, то +- рядом с мелкими ребятами ))
Что-то суммы на графике смешные. Вопрос к автору.
Дана некая ИС, не очень большая, примерно 50 человеко-лет, возрастом 4 года. Обслуживается 3 командами спецов, в сумме - 24 человека. Легаси, спагетти, куча фреймворков - всё там есть, документация сделана "для галочки", некоторые компоненты совсем не документированы. Автотестов считайте, что нет, усё ручками.
Вопрос: сколько времени и денег (верхние и нижние границы) понадобится на то, чтобы покрыть автотестами хотя бы 10-15% "золотых" сценариев продукта?
@Вася Бездомный а в чем смех? Про задачку - хотите оценку с точностью - нужна нормальная постановка задачи - с описанием технологий, интерфейсов и проч., все остальное будет так же примерно, как с цифрами на графике, куча дополнительных вводных, которые влияют на ответ. Каждая система уникальна и находится на разном уровне зрелости. У какой-то системы внедрение автотестов не даст большого эффекта, потому что например часть работ уже была автоматизирована. А у системы на подобии той, что в примере, как раз должен быть весьма ощутимый эффект. Опять же почему-то при упоминании автоматизации все видят только автотесты. А речь-то шла и об автоматизации сборки, и подготовки данных - эта история про автоматизацию/совершенствование самих процессов разработки и тестирования в целом, а не про автотесты