Компания «Точка качества» продолжает беседовать с международным экспертом в сфере тестирования программного обеспечения Шринивасом Кулкарни. Мы продолжаем тему автоматизации тестирования. С первой частью нашей беседы можно познакомиться в статье,
опубликованной 6 июня.
Это вторая часть интервью со Шринивасом Кулкарни, международным экспертом в сфере тестирования программного обеспечения, популярным блоггером. С первой частью нашей беседы можно познакомиться в посте, опубликованном 6 июня. Основной тезис Шриниваса звучит так: автоматизация тестирования является наиболее недооценённой концепцией в тестировании программного обеспечения. И сегодня мы продолжим обсуждать эту тему.
ТК: Можете ли вы привести конкретный пример положительного результата использования автоматического тестирования для бизнес-процессов из вашего опыта или, может быть, слышали о таком (где удалось сэкономить бюджет, ускорить время выхода продукта на рынок или что-то подобное)?
Ш.К.: Как я уже говорил, если автоматизация делается «правильно», то она увеличивает производительность и эффективность квалифицированных тестировщиков. И конкретные примеры положительных результатов автоматизации, на мой взгляд, должны быть связаны именно с этими условиями. Автоматизация в мире IT-услуг способна приносить большой доход.
Есть производители инструментария автоматизации, консультанты и разработчики автоматизации, которые, собственно, и составляют ее “коммерческое уравнение”. Если автоматизация осуществляется с помощью дискреционных расходов – потраченные деньги должны быть коммерчески оправданы. И вот здесь начинаются проблемы, мы скатываемся в область манипулирования, политики, личных мотиваций, пристрастий из разряда «любит/не любит» и т.д. Я очень скептически отношусь к таким понятиям в автоматизации тестирования, как ROI, сокращение времени цикла тестирования, быстрота выхода на рынок. Эти термины слишком расплывчаты, часто зависят от нескольких параметров, неподконтрольных тестированию.
Например, если кто-то утверждает, что они сократили время цикла обязательного тестирования – вот как я проверяю это. Прежде всего, сама идея времени цикла часто не ясна: речь идёт только о процессе тестирования? И как обозначить начало и конец цикла испытаний?
Испытательный цикл представляет собой предварительную конструкцию, разработанную для удобства, и эта конструкция может меняться от проекта к проекту. И даже в пределах данного определения цикла испытаний – что конец цикла испытаний — означает начало выпуска продукта? Часто конец одного цикла испытаний дает разработчикам букет из ошибок, которые необходимо исправить, а далее требуется дополнительное тестирование. До тех пор, пока вы рассматриваете круг тестирования, где к концу цикла мы имеем ноль новых багов,– конец цикла не означает ничего для выпуска продукта.
Выпуск продукта в конце цикла испытаний является рискованным бизнес-решением заинтересованных сторон и производится из соображений по оси бизнес/рынок. Автоматизация, тестирование или даже развитие команды – никак не помогут, если руководители решили выпустить продукт для достижения каких-то конкретных бизнес-целей. Этим я хочу сказать, что эффективность и успех автоматизации необходимо измерять на другом уровне – уровне тестера, а не на бизнес-уровне. Время цикла тестирования – это параметр, продиктованный, прежде всего, бизнесом.
Тот же аргумент относится и к «быстрому выходу на рынок». Я рекомендую оценивать успех автоматизации по тому, насколько она увеличила продуктивность и эффективность тестировщика. Если пойти выше, на уровень бизнеса заинтересованных сторон – картина становится более размытой, и многие параметры выходят из под контроля тестирования. Это влияет на процесс принятия решений об автоматизации, и, зачастую, маркетинговые убеждения преобладают над критическим мышлением.
Таким образом, когда вы слышите слова типа ROI, о том, что вы экономите деньги за счёт автоматизации – сделайте шаг назад и включите критическое мышление. Не принимайте их как должное. Дьявол кроется в деталях.
ТК: Каковы типичные, наиболее распространённые ошибки в процессе реализации автоматизации тестирования?
Ш.К.: Одна большая ошибка – рассматривать автоматизацию как волшебную палочку, которая решит любые проблемы, связанные с тестированием. Я часто советую командам не использовать автоматизацию, когда времени меньше, чем реально требуется для тестирования.
А ведь для менеджеров автоматизация часто подается именно как инструмент, который используется, когда не хватает времени. Это неправильный способ использования автоматизации. Я еще не видел реального примера, когда бы автоматизация скомпенсировала отсутствие времени для тестирования.
Ещё ошибки часто бывают связавны с непониманием, а подходит ли в данном случае автоматизация. Если вы плохо тестируете, при этом ещё и используете автоматическое тестирование, то такие процессы могут вызвать худшие результаты. Джеймс Бах в своей знаменитой статье об автоматизации (Test Automation snake oil) составил список самых безумных предположений о тестировании.
Для примера рассмотрим тестирование в виде последовательности действий. Если вы позволяете людям (консультантам/продавцам) принизить значение тестирования, то таким образом вы даёте им свободу, чтобы продать что-нибудь «автоматическое».
Вы не можете полностью автоматизировать тестирование, так как тестирование является познавательным процессом, который осуществляется принципиально человеком, но эффективность такого процесса может быть повышена за счет использования различного инструментария. Хорошая автоматизация берет начало в хорошем тестировании. Вы должны прояснить, что такое хорошее тестирование для вас, а потом спросить себя, как автоматизация помогает в этом процессе. Жаль, что многие продавцы преподносят свои тулы, как заменитель тестировщика, и при этом сообщество воспринимает это на веру.
Следует быть осторожными на маркетинговом поле, которое окружает автоматизацию. Необходимо включать критическое мышление, когда вы слышите о таких маркетинговых требованиях, как скорость автоматизации, простота в использовании, быстрая окупаемость инвестиций и оценить целесообразность каждого из этих требований в контексте вашего проекта, компании и отрасли.
Наиболее заманчивыми эти маркетинговые истории кажутся «нетехническим пользователям». В данном случае нетехнические пользователи – это те, кто может тестировать, но не может писать или поддерживать код..
Подвожу итог: как же всё-таки избежать ошибок?
- “Станок” не может осуществить тестирование – это делают люди. Нет такого понятия, как автоматизированное тестирование. Тестирование не может быть автоматизировано, но его качество можно повысить за счет средств автоматизации.
- Автоматизация для нетехнических пользователей – это оксюморон (как водонепроницаемое полотенце).
- Избегайте безскриптовых инструментов автоматизации, если это возможно.
- Остерегайтесь маркетинговых подач, которые сопровождают автоматизацию, следите за фразами вроде “сокращение времени цикла”, “более быстрое время выхода на рынок”. Это ловушки.
ТК: Кто по-вашему тестировщик-автоматизатор? Он скорее недо-разработчик или пере-тестер? Как проверить способности к автоматизации тестирования? Разработчики могут столкнуться с проблемой мотивации,а для тестеров — их технический уровень не всегда достаточно хорош.
Ш.К.: Для тех, кто хочет быть автоматизатором – разработка программного обеспечения и навыки программирования хотя бы на одном языке является обязательным требованием. Вполне возможно, что тестер имеет такие навыки и может быть эффективным автоматизатором. Одним из них является способность понимать/расшифровать код софта и возможность обновления/изменения кода. Сейчас обычный среднестатический тестировщик не может писать или понимать код. Это нужно менять.
Провайдеры IT-услуг регулярно бы выдавали премию инженеру-автоматизатору, который был бы не просто квалифицированным тестером, но имел и навыки программирования. Насколько и как глубоко тестировщик должен знать программирование зависит от контекста проекта/компании/домена.
Нет одной-единственной технической планки, которая бы подходила каждому автоматизатору. Хороший атоматизатор будет иметь сбалансированное сочетание навыков тестирования и навыков программирования, будет умело их использовать для повышения эффективности и производительности тестирования.
В будущем вполне может не быть конкретной роли «Автоматизатор» – тестер или разработчик будут создавать и поддерживать систему автоматизации. Соответственно отпадёт необходимость в повышении квалификации для разработчика (тестирования) и тестера (софта), они могли бы в паре идти к единой цели. Интересные времена впереди.
