Home

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

Не все проекты по разработке ПО обречены на успех. На самом деле, как гласит множество исследований, большая их часть провальна отчасти или полностью. К примеру, исследование Standish Group выявило, что две трети изученных ими проектов по разработке ПО не достигли успеха. Другой опрос 2016 года от Innotas показал, что 55% респондентов участвовали в провальном проекте в этом году. Если вы работаете в разработке ПО, то реальность такова, что шансы не в вашу пользу.

Как инженер по разработке ПО и обеспечению качества, я пережил достаточно провальных проектов. Некоторые из них умерли, потому что у компании кончились деньги. Другим не удалось добиться значительного успеха, и компания решила сконцентрироваться на чем-то еще. Во многих случаев команда, работающая над проектом, остается преданной ему и продолжает работу, не осознавая, что бизнес медленно ползет в сторону могилы.

Однако если пристально посмотреть на недели и месяцы, прошедшие перед смертью проекта, можно обнаружить ранние знаки, которые могли бы предупредить команду, что впереди опасность. Некоторые из них легко заметить – лидеры отделов покидают компанию, или же в организации начинаются сокращения. Однако иные сигналы прячутся в повседневной работе команды, и их трудно заметить, пока не становится слишком поздно.

Все это также верно для работы над проектом по тест-автоматизации. Эти проекты проваливаются так же часто, как и любой другой проект по разработке, и часто намекают, что встали на скользкую дорожку в никуда. Если распознать эти сигналы заранее, то это поможет компании избежать камеры смертников. Ниже – ряд распространенных сигналов, которые могут означать, что ваша автоматизация движется к провалу.

Сигнал 1: Компания стремится автоматизировать все

Как только компания узнает о преимуществах тест-автоматизации, то стремится дать автоматизации зеленый свет и автоматизировать все. Привлекательность обладания полноценным автоматизированным набором тестов, покрывающим все приложения, не дает людям увидеть недостатки такого типа тестирования. К сожалению, они становятся очевидными только после того, как команда потратила значительное время и средства на создание системы, проблем от которой больше, чем выгоды.

Автоматизация может повредить тестированию и усилиям по улучшению качества по множеству причин. Ряд основных проблем избыточной автоматизации:

• Отсутствие концентрации на самом значимом, попытка сделать слишком много вместо того, чтобы автоматизировать то, что принесет наибольшую пользу.
• Чем больше вы автоматизируете, тем больше времени занимает прогон тестов и разбирательство с неминуемо возникающими падениями.
• Чем больше у вас тестов, тем сложнее поддерживать базу кода, обеспечивающую их, в долгосрочной перспективе.

Если ваша команда или организация желает автоматизировать все на свете, то лучше остановиться и распланировать, что нужно автоматизировать в первую очередь. Работа над небольшими участками полезна сразу на нескольких уровнях. Во-первых, она позволяет приоритезировать самые важные для тестирования секции вместо того, чтобы распыляться на каждую мелочь. Во-вторых, она дает команде шанс показать, как работает автоматизация, и выявить потенциальные проблемы до того, как кинуться в нее с головой.

Сигнал 2: Компания хочет полностью избавиться от ручного тестирования

Одна из причин, по которой компании стремятся автоматизировать все – это желание снизить зависимость от ручного тестирования. Это может быть вызвано экономическими причинами (нежелание инвестировать в чересчур большое количество тестировщиков), или же у компании нет менеджеров, способных управлять этими командами. Иногда ручное тестирование воспринимается как нечто замедляющее процесс разработки и релиза продукта.

В чем бы ни была причина, желание устранить ручное тестирование означает, что компания толком не понимает, что автоматизация может и не может сделать. Как уже упоминалось выше, команды-новички в автоматизации полагают, что она решит все их тест-проблемы, и иное тестирование более не понадобится. Однако автоматизация – не панацея, она не заменит ручного тестирования.

Один из лучших инструментов для компаний, желающих снизить или полностью устранить нужду в ручном тестировании – это образование. Компания должна понимать, что тест-автоматизация не может справиться со всем на свете. Конкретные примеры областей приложения, проблемных в плане автоматизации, смогут вам помочь. Ключевой момент тут – объяснить, почему сбалансированный подход к тестированию повысит качество куда лучше, нежели однонаправленная атака.

Сигнал 3: Не уделяется внимание долгосрочной поддержке

Я часто рекомендую командам, стремящимся начать автоматизировать, просто начать. Вместо того, чтобы тратить время на мудрствования по поводу инструментов и стратегий, зачастую лучше выбрать подходящий путь и начать внедрять тесты. Быстрая петля обратной связи выявит дыры в планировании и повысит шансы команды на создание полезной автоматизации.

Однако раннее экспериментирование не означает, что команда не должна принимать во внимание поддержку, создавая первый набор тестов. Вполне нормально написать код на выброс и временно автоматизировать тест-кейсы как можно раньше, чтобы укрепиться в выбранном решении. Но как только компания нашла подходящие ей инструменты и стратегии, нужно предотвратить превращение набора тестов в кошмар для поддержки.

Неважно, сколько времени вы тратите на организацию тест-набора и работу с ним – вам все равно нужно будет поддерживать его, потому что приложение, которое он обеспечивает, продолжает развиваться. Иногда кажется, что создание чистого, упорядоченного кода тестов – это пустая трата времени, но это окупится. Команды, не уделяющие внимания созданию поддерживаемых тестов, вскоре обнаружат, что тратят кучу времени на исправление сломанных тестов, или просто забрасывают работу над тест-набором.

Сигнал 4: Тестировщики не взаимодействуют с другими членами команды

Большинство тестировщиков, с которыми я общался, работали или работают в QA-командах, не взаимодействующих с другими командами в компании. В крупных компаниях это имеет смысл – это позволяет убедиться в межпроектном высоком качестве и стабильности. В небольших коллективах отдельная команда тестировщиков также может помочь своим "свежим взглядом", замечая проблемы, просочившиеся сквозь пальцы разработки.

Проблема с отделением качества в обособленный коллектив в том, что этот отрыв от коллектива уничтожает коммуникацию между командами, особенно в случае, если в существующих командах разработки QA не представлено. К сожалению, это часто происходит во множестве организаций. Работа выполняется и передается через условную стену в QA (зачастую в последнюю минуту), без контекста, позволяющего увидеть полную картину того, что нужно сделать. Это ведет к созданию низкокачественного продукта и сваливанию вины на тестировщиков, которые позволили этому произойти.

Вовлечение команды обычно начинается в начале проекта и в идеале включает как минимум одного тестировщика, активно участвующего в процессе разработки. Учет мнения QA и наличие человека, смотрящего с точки зрения качества, выявит проблемные области, которые с шансами упустят разработчики и менеджеры продукта. несмотря на то, что отдел QA в высокой степени ответственен за качество проудкта, тестирование – это командная игра. Тестировщики не должны быть единственными ответственными за поиск багов, проблем удобства использования и прочих загвоздок.

Сигнал 5: Никто не знает, что нужно автоматизировать

Создание устойчивого автоматизированного тест-набора обычно вырастает из нужды в глубоком покрытии существующих приложений. Когда команда создает новые функции и модифицирует имеющиеся, становится все дольше и сложнее тестировать как свежедобавленные секции, так и стабильность работы существующей функциональности. Автоматизация снижает нагрузку на команду, помогая покрывать регресс, пока остальные концентрируются на более важных задачах.

Чтобы получить от тестов максимум, нужно, однако, знать, какие области наиболее важны для автоматизации. Как упоминалось ранее, нельзя автоматизировать всю на свете функциональность приложения, поэтому нужно выбирать, на чем концентрироваться. Если команда не знает, что должно быть покрыто автоматизацией, это приведет к тест-набору, замедляющему процесс разработки и не дающему никакой выгоды. Это также приводит к сложности в оценке усилий тестирования и создает рассинхронизацию между разными членами команды, потому что у каждого свое представление о том, что важно, а что нет.

Автоматизация наиболее эффективна, если она нацелена на участки высокой ценности. У каждого приложения есть критичные сценарии, которые должны работать во что бы то ни стало, или секции, часто ломающие существующие функциональности при внесении изменений. Если ваш бизнес полагается на эти функции и нуждается в их бесперебойной работе, важно направить ваши тест-усилия на них, прежде чем разбираться с чем-то еще. Планируйте покрывать эти секции в первую очередь, даже если автоматизируются только они – это поможет вам куда больше, нежели создание рандомных тестов, которые могут быть бесполезными.

Заключение

Неприятная реальность такова, что большая часть проектов по разработке ПО приводит к провалу. Если вы работаете над проектом тест-автоматизации, то с большим шансом его судьба будет аналогична судьбе бесчисленного множества прочих проектов. Зачастую провал ощущается как неожиданность и застает всех врасплох. Однако в ретроспективе вы наверняка найдете симптомы, подтверждающие, что ваш проект был на пути к могиле задолго до того, как кто-то обратил на это внимание. В ходе моей карьеры инженера по разработке и тестированию ПО я видел, как компании повторяли ошибки автоматизации снова и снова, и это снова и снова приводило к неудаче.

Сигналы о том, что ваш проект обречен, выглядят по-разному. В некоторых обстоятельствах компания недостаточно изучила возможности автоматизации и стремится автоматизировать все на свете, избавившись от ручного тестирования. В других случаях тест-команда концентрируется на сиюминутных проблемах вместо того, чтобы смотреть в будущее, и получает набор тестов, к которому все брезгуют прикоснуться. Более распространенная проблема возникает, когда у тестировщиков нет контакта с другими членами команды. И, наконец, если команда не понимает, что именно автоматизировать – она получит набор тестов, который никому не нужен.

Распространенное мотивирующее выражение, приписываемое Тони Роббинсу, звучит так: "Успех оставляет улики". Успех – не единственная вещь, оставляющая за собой следы. Провал тоже оставляет улики, и они могут быть куда важнее для поддержания здоровья и успеха вашего проекта. Если вы заметили одну или несколько из перечисленных проблем в своем проекте – стоит уничтожить их, чтобы не носить цветы на могилу своей автоматизации.

Обсудить в форуме