testomat.io управление авто тестамиСтатья является модификацией более ранней версии, опубликованной в журнале “Windows Tech Journal”(10/96) и протоколами 14й Международной Конференции в Тестировании Программного Обеспечения, соответственно. Автор благодарит ST Labs за поддержку.
Ситуация 1. Во время разработки продукт передается от одного
разработчика к другому. Каждый новый разработчик обнаруживает, что документация
к продукту уже устарела и процесс разработки нарушен. После анализа в течение
месяца каждый объявлял о неудачном проектировании и настаивал на необходимости
написания больших объемов нового кода. По прошествии еще нескольких месяцев
разработчик уходил или продукт передавался другому человеку, и весь процесс
повторялся заново.
Ситуация 2. Программисты быстро реализовали проект без достаточного понимания того, какие же задачи он должен был решать. Спустя много месяцев после завершения, при анализе результатов обнаруживается, что система в эксплуатации и обслуживании стоит дороже, чем проведение того же процесса, который система автоматизировала, вручную.
Ситуация 3. 100000$ было потрачено на внедрение современного набора инструментов для разработки. Вскоре обнаружилось, что данные инструменты не настолько мощные, портативные, надежные, чтобы использовать их для достижения значительных успехов в разработке. После ближайших двух лет попыток заставить их работать, инструменты были заброшены.
Ситуация 4. Продукт был разработан для автоматизации набора бизнес - задач. Но задачи были изменены настолько, что проект совсем отдалился от графика и результаты работы системы автоматизации стали недостоверными. Периодически, сотрудники отдела разработки освобождались от работы над проектом, чтобы помочь решить задачи вручную, от этого они еще больше отдалялись от разработанной системы автоматизации.
Ситуация 5. Программа, состоящая из нескольких сотен почти независимых функций, вводится в эксплуатацию сразу после поверхностного тестирования. Незадолго до запуска, большая часть функций была неактивна, так как находилась в состоянии отладки. Почти год прошел c того момента, когда хоть кто-то заметил, что эти функции вообще отсутствуют.
Эти небольшие эпизоды из моей собственной практики, но я уверен, что они знакомы многим. Это распространенные жалобы на то, что многие программные продукты проваливаются. И это не должно нас удивлять – со стороны, программы кажутся очень простыми, но ведь проблема в деталях, не так ли? Опытные разработчики программного обеспечения отлично это знают, и к началу нового проекта подходят настороженно и скептично.
Автоматизация тестирования также непроста. Рассмотрим еще раз ситуации, приведенные ранее. В основном, каждый из этих случаев был попыткой автоматизировать тестирование. Девять лет я управлял группами по тестированию программного обеспечения и занимался автоматизацией тестирования (имейте ввиду, в компаниях богатых и разбирающихся в разработке программных продуктов). Наиболее важным открытием для меня стало то, что проекты тестирования программного обеспечения настолько же близки к краху, как и любые другие программные продукты. По сути, в моем опыте, они проваливались чаще, в основном, потому что большинство организаций не уделяло такой же заботы и профессионализма для тестовых продуктов, как делалось это в текущих проектах.
Странно, что почти все эксперты по тестированию, практикующие тестировщики, менеджеры по тестированию, и, конечно же, компании, продающие инструменты для тестирования, рекомендуют автоматизировать тестирование с таким чрезвычайным энтузиазмом. Хотя, возможно, «странно» не совсем правильное слово. В итоге, инструменты для автоматизации проектирования и разработки были огромной прихотью, и инструменты для тестирования просто другая сторона таких продуктов. От объектно-ориентированного до «безпрограммистского» программирования, идеалистическая пропаганда не новость в нашей индустрии. Так, может, высокое качество общедоступной информации и анализа автоматизации тестирования не такое уж удивительное, а скорее, просто знак незрелости данной области. Как сообщество приверженцев автоматизации, возможно, мы еще в фазе восхищения идеей автоматизации тестирования, но еще не разобрались в подводных камнях. Поспешу согласиться, что автоматизация – это отличная идея. Мне нравиться что-то автоматизировать гораздо больше, чем выполнять какие-либо другие задачи. Большинство тестировщиков, работающих полный день, и, наверное, все разработчики мечтают, что можно будет нажать большую зеленую кнопку и позволить лаборатории верных роботов сделать всю тяжелую работу по тестированию, тем самым освобождая их самих для более возвышенных занятий, как, например, сетевые компьютерные игры. Не смотря на это, если бы достигли этого Шангри-Ла, мы все равно должны были бы продолжать действовать с осторожностью.
Эта статья является критическим анализом «скриптового и проигрывательного» стиля автоматизации регрессионного тестирования приложений с графическим интерфейсом.
Разоблачение классического аргумента за автоматизацию
«Автоматизированные тесты выполняют последовательность действий без участия человека. Этот подход помогает избежать человеческого фактора при выполнении работы, и быстрее предоставляет результаты. Поскольку большинство продуктов нуждается в серии повторяющихся тестов, со временем автоматизация тестирования позволяет сэкономить средства. Зачастую, компания пересекает точку самоокупаемости выполняемых работ уже после двух или трех запусков автоматизированного теста.»
Это цитата из официальной статьи об автоматизации тестирования, опубликованная одним из ведущих разработчиков инструментов для тестирования. Аналогичные утверждения можно встретить в рекламах и документациях к большинству коммерческих инструментов для регрессионного тестирования. Иногда они также сопровождаются впечатляющими графиками. Вся идея сводится только к этому: компьютеры быстрее, дешевле и надежнее, чем люди, поэтому автоматизируйте.
Это рассуждение основано на многих безрассудных предположениях. Давайте оспорим некоторые из них.
Безрассудное предположение №1
Тестирование – это «последовательность действий»
Более удобный способ воспринимать тестирование как последовательности взаимодействий вперемешку с оцениванием. Некоторые из этих взаимодействий являются предсказуемыми, а некоторые могут быть определены исключительно в терминологии. Как бы то ни было, многие другие являются комплексными, неоднозначными и изменчивыми. Также бывает полезно концептуализировать основную последовательность действий, которая уже содержит заданный тест, то есть постараться уменьшить количество действий, проводимых наугад, и получить более узконаправленные и неглубокие серии тестов.
Ручное тестирование, с другой стороны, это процесс, который легко адаптируется к изменениям и справляется с новыми трудностями. Люди в состоянии обнаруживать сотни шаблонов проблем одним взглядом, и мгновенно отличить их от незначительных отклонений. Люди могут быть даже не осведомлены о стоимости своей работы, но в совокупности «последовательности действий» каждая трата должна быть строго запланирована. Тестирование может казаться простым набором действий, но хорошее тестирование – это интерактивный, исследовательский процесс. Именно поэтому автоматизацию лучше всего применять для узконаправленного диапазона тестирования, а не для всего процесса.
Если вы намереваетесь автоматизировать все необходимые проведения тестов, то, скорее всего, вы потратите очень много средств и времени на создание пропорционально небольшого количества тестов, которые будут игнорировать многие интересные проблемы, но при этом и находить много «ошибок», которые будут скорректированы всего лишь правильной работой с программой.
Безрассудное предположение №2
Тестирование подразумевает выполнение одних и тех же действий снова и снова.
Если определенный тест кейс был выполнен один раз, и не было обнаружено проблем, остается очень малая вероятность, что по данному тест кейсу еще когда-нибудь найдется ошибка, разве что будет допущена новая во время работы над системой. Когда тест кейсы разнообразны, хоть обычно тесты и выполняются вручную, существует вероятность обнаружить ошибки как новые, так и старые. Изменчивость – одно из главных преимуществ ручного тестирования над скриптовым или «проигрыванием сценариев». Когда я работал в Borland, группа аналитиков исследовала ошибки, найденные ручным тестированием и автоматизированным, и оказалось, что около 80% ошибок были найдены именно в результате ручных тестов, несмотря на то, что несколько лет вкладывались инвестиции в автоматизацию. Их обоснованием было, что ручное тестирование более изменчивое и больше ориентировано на новый функционал и специфические области с нововведениями, где наиболее вероятно обнаружение ошибок.
Часто повторяемые тесты уменьшают вероятность обнаружения всех важных ошибок, по той же причине просто следование по чужим стопам уменьшает шансы придумать что-то радикально новое.
Безрассудное предположение №3
Мы можем автоматизировать действия, необходимые для проведения тестирования.
Некоторые задачи могут быть простыми для людей, но оказаться сложными для компьютеров. Наверное, самое сложная часть автоматизации – это интерпретирование результатов тестов. Для приложений с графическим интерфейсом очень сложно автоматически заметить все категории существенных ошибок, при этом не зацикливаясь на незначительных.
Проблема автоматизируемости состоит в том, что присутствует высокая степень неопределенности и изменений в ходе типичной работы над проектом. В коммерчески-ориентированных проектах обычно используется инкрементальный подход к разработке, который практически полностью гарантирует, что продукт будет изменяться, почти до завершения работы над проектом. Этот факт, в паре с частым отсутствием завершенных и подробных спецификаций, делают автоматизацию разработки чем-то наподобие езды через густой лес в семейном седане: вы можете это делать, но вам придется ехать очень медленно, много раз возвращаться и спотыкаться.
Даже если мы имеем определенную последовательность действий, которые в принципе, могли бы быть автоматизированы, мы сможем это сделать, только если имеется подходящий инструмент для работы. Информацию о различных инструментах получать непросто, но, даже, несмотря на это, наиболее критичным аспектом в инструментах для регрессионного тестирования является невозможность их оценить до тех пор, пока мы не создадим или не рассмотрим автоматизацию набора тестов промышленного масштаба с использованием данного инструмента. Вот некоторые факты, которые необходимо оценить при выборе инструмента для тестирования. Отметьте, насколько много из них вы не сможете оценить даже после внимательного изучения инструкций пользователя или просмотра рекламного демо-ролика:
- Возможности: Поддерживает ли инструмент весь наиболее важный для нас функционал, особенно в областях оценивания результатов тестов и менеджменте наборов тестов?
- Надежность: Будет ли инструмент работать долгое время без сбоев или же в нем самом множество ошибок? Многие инструменты для тестирования разрабатываются маленькими компаниями, которые уделяют очень мало внимания тестированию своих продуктов.
- Маштабируемость: Кроме примитивных примеров и демо-роликов, работает ли инструмент в промышленной обстановке без ошибок? Может ли он управлять большими наборами тестов, которые длятся часами и днями, и вовлекают в работу тысячи скриптов?
- Изучаемость: Можно ли освоить инструмент в течение короткого периода времени? Существуют ли тренинги или книги, чтобы облегчить этот процесс?
- Простота эксплуатации: Имеет ли инструмент функционал, который тяжело использовать или легко ошибиться при попытке им воспользоваться?
- Производительность: Достаточно ли быстро работает инструмент, чтобы позволить частые сохранения наиболее важных моментов при разработке тестов и выполнение тестов в сравнении с ручным тестированием?
- Совместимость: Поддерживает ли инструмент определенную технологию, которую необходимо тестировать?
- Ненавязчивость: Насколько хорошо инструмент имитирует реального пользователя? Будет ли поведение программы во время теста с использованием автоматизации или без нее одинаковым?
Безрассудное предположение №4
Автоматизированный тест выполняется быстрее, поскольку не нуждается во вмешательстве человека.
Все автоматизированные наборы тестов требуют участия человека, даже если просто надо получить результаты или исправить ошибочные тесты. Также может оказаться необычайно тяжело начать запуск комплексного набора тестов без толчка и заминок. Обычными виновниками проблем являются изменения в тестируемом продукте, проблемы с памятью, или с файловой системой, или с сетевым окружением, а также ошибки в самом инструменте для тестирования.
Безрассудное предположение №5
Автоматизация уменьшает вероятность человеческих ошибок.
Действительно, некоторых ошибок удается избежать. А именно, когда сотрудникам поручают одновременно выполнять большой список заданий как умственного, так и физического характера. Но количество других ошибок растет. Каждая ошибка, оставшаяся незамеченной при сравнении сгенерированных мастером файлов результатов, так и останется незамеченной после каждого запуска этого набора тестов. Или по недосмотру во время отладки случайно можно деактивировать сотни тестов. Команда dBase в компании Borland однажды обнаружила, что около 3000 тестов в их наборе тестов были внесены в отчет как успешно пройденные, при этом никто не обратил внимания на то, какие действительно проблемы существовали в продукте. Чтобы устранять такие ошибки, автоматизированные тесты должны регулярно сами тестироваться или же пересматриваться. Соответствующие недочеты в стратегии ручного тестирования, с другой стороны, намного легче распознать, используя базовые тестовую документацию, отчеты и практики.
Безрассудное предположение №6
Мы можем оценить стоимость и прибыль ручного тестирования в сравнении с автоматизированным.
Правда состоит в том, что ручное тестирование и автоматизированное – два совершенно разных процесса, точнее, два способа выполнить один и тот же процесс. Их динамика отличается, и типы ошибок, которые они пытаются обнаружить, также отличаются. Соответственно, напрямую их сравнивать по стоимости или по количеству обнаруженных ошибок, бессмысленно. Кроме того, существует много скрытых и особенных факторов, вовлеченных в реальное сравнение. Поэтому лучший способ оценить процесс – в контексте серии реальных проектов по разработке программного обеспечения. Именно поэтому я рекомендую расценивать автоматизацию как одну из частей многообразного поиска наилучшей стратегии тестирования, а не деятельность, которая доминирует в процессе тестирования, или остается единственным способом проведения тестов.
Безрассудное предположение №7
Автоматизация приведет к «значительной экономии затрат на рабочую силу».
«Обычно компания пересекает точку самоокупаемости выполняемых работ уже после двух или трех запусков автоматизированного теста.»
Эта непринужденная оценка могла возникнуть из практических результатов или в изобретательных умах рекламных работников. В любом случае, это не соответствует действительности. Стоимость автоматизированного тестирования состоит из нескольких частей:
- Стоимость разработки автоматизированных тестов;
- Стоимость управления автоматизированными тестами;
- Стоимость внесения изменений в автоматизацию, когда тестируемый продукт изменяется;
- Стоимость всех остальных новых задач, которые последуют за автоматизацией.
Всю суммарную стоимость автоматизации надо оценить совместно со стоимостью всего ручного тестирования, которого, возможно, также потребуется немало. В действительности, в моем опыте никогда не было такого, чтоб автоматизация уменьшила необходимость ручного тестирования настолько, что тестировщики оставались бы без работы.
Таким образом, эти затраты на работу зависят от множества факторов, включая технологию, которую надо тестировать, используемые для тестов инструменты, опыт разработчиков автоматизированных тестов, а также качество набора тестов.
Написание единичного тестового скрипта не потребует много усилий, но на создание качественного теста могут понадобиться недели или месяцы работы. Это процесс принятия решения, какой инструмент приобрести, какие тесты автоматизировать, как отслеживать вклад автоматизации во всем процессе тестирования, и, конечно, как использовать инструмент и собственно, написание тестовых приложений. Качественный подход к этому процессу (то есть поиск того продукта, который действительно дает хорошие результаты), часто требует месяцы рабочих дней, и еще дольше, если разработчики автоматизированных тестов не имеют опыта работы либо с автоматизацией тестов, либо с определенным инструментом и технологией.
А как насчет текущих эксплуатационных расходов? Большинство анализов стоимости автоматизации тестирования полностью игнорируют особенные новые задачи, которые возникают ввиду автоматизации:
- Все планы тестов должны быть аккуратно задокументированы;
- Все тестовые приложения также должны быть протестированы и иметь документацию;
- Каждый раз после запуска набора тестов кто-то должен внимательно изучить результаты и отсеять мелкие недочеты от реальных ошибок;
- Необходимо оценить влияние радикальных изменений в продукте, которые должны быть протестированы, на существующий набор тестов. В соответствии с результатами должен быть написан новый тестовый код;
- Если над набором тестов работает несколько сотрудников, то необходимо проводить совещания, чтобы скоординировать разработку, последующее обслуживание и эксплуатацию набора тестов;
- Существует серьезная проблема с переносом разработанных однажды тестов на новую платформу, или даже на новую версию той же платформы. Я знаю, что многие наборы тестов стали неработоспособными при переносе их на Windows 95, и уверен, что немалое количество их также не смогли работать и на Windows 2000.
Все эти задачи регулярно встречаются в буднях тестировщиков. Большинство команд, занимающихся тестированием графического интерфейса, с которыми я работал, пытались так или иначе сделать всех тестировщиков вовлеченными как в автоматизированное тестирование, так и в ручное. И каждая команда, в конечном счете, отказывалась от этой идеи в пользу специалистов по автоматизированному тестированию или даже целых команд. Написание тестового кода и проведение качественного согласованного ручного тестирования настолько разные деятельности, что человек, их выполняющий, в любом случае будет фокусироваться на чем-то одном, в ущерб другому. Также, поскольку разработка автоматизированных тестов является программированием, то необходим и талант программиста. Некоторые тестировщики не могут это освоить.
Так или иначе, компании с серьезным отношением к автоматизации в итоге нанимают отдельный штат сотрудников только для решения задач автоматизации, и далее уже подсчитывают стоимость общей стратегии.
Безрассудное предположение №8
Автоматизация не может навредить процессу тестирования в целом.
Я оставил напоследок самую тяжелую из всех проблем, которые могут возникать при планировании стратегии автоматизации: очень опасно автоматизировать что-то, что мы не понимаем. Если мы не получаем абсолютно ясной стратегии перед началом автоматизирования, то в результате будем иметь огромное количество тестового кода, который никто полностью не понимает. Как только разработчики наборов тестов займутся другими задачами, а остальные будут заняты поддержкой, наборы тестов переходят в пользование команде тестирования. Сотрудники, занимающиеся поддержкой существующих тестов, боятся отбрасывать старые тесты, даже если они уже кажутся бессмысленными, потому что со временем может оказаться, что они тоже очень важные. Итак, набор тестов постепенно обрастает все новыми версиями тестов, становясь все более таинственным оракулом, наподобие старого гималайского гуру или говорящего дуба из диснеевского фильма. Никто не знает, из каких же тестов состоит весь тестовый набор, или что значит для продукта «пройти весь набор тестов», и чем больше этот набор становится, тем меньше вероятность, что кто-нибудь попытается в нем разобраться.
Такая ситуация случалась и со мной (и даже более одного раза, прежде чем я усвоил урок), и я видел и слышал, как такое же случалось и с многими другими менеджерами тестирования. Многие даже не подозревали, что это проблема, пока однажды менеджер разработчиков не спросил, что же данный набор тестов покрывает, а что нет, и никто не смог дать точного ответа. Или в какой-то момент, обычно самый неподходящий, вся тестовая система выходит со строя, и не будет никакой возможности ее восстановить вручную. Ироничность ситуации состоит в том, что, проводя тестирование в полной уверенности в профессиональности выбранного подхода, в результате тестирование получается сделанным вслепую и нелепо.
Ручное тестирование также может страдать от неразберихи, но когда тесты создаются динамически исходя из небольшого набора принципов или документов, то в данной ситуации намного проще пересмотреть или уточнить выбранную стратегию. Да, ручное тестирование проходит медленнее, но оно намного более гибкое, и может справиться с хаосом незавершенности и изменений продукта и документаций.
Осмысленный подход к Автоматизации
Несмотря на все проблемы, описанные в статье, я верю в автоматизацию. Мало того, я являюсь консультантом по автоматизации. Так же, как может существовать качественное программное обеспечение, может существовать и качественная автоматизация тестирования. Чтобы создать качественный автоматизированный тест, надо быть очень аккуратным. Этот путь усеян ошибками. Надо все время держать в уме следующие ключевые принципы:
- Сохранять четкое различие между автоматизацией и процессом, который автоматизируется. Тестовый процесс должен быть представлен в такой форме, чтоб его легко было анализировать и быть основой для автоматизации.
- Думайте о вашей автоматизации как о базовом наборе тестов, который может использоваться в дополнение к ручному тестированию, а не для замены его.
- Бережно подбирайте ваши тестовые инструменты. Собирайте информацию от других тестировщиков и организаций. Ознакамливайтесь с пробными версиями понравившихся тестовых инструментов перед их покупкой.
- Тщательно продумайте при покупке или разработке инструментов способы влияния менеджмента тестирования. Хорошая система менеджмента может действительно помочь сделать набор тестов более удобным для анализа, пересмотра и внесения изменений.
- Удостоверьтесь, что результаты каждого запуска набора тестов отображены в отчете о ходе тестирования, который содержит информацию о том, какие тесты были пройдены успешно, а какие – нет, в сравнении с уже найденными ошибками. Отчет также должен содержать информацию о сделанных изменениях или улучшениях в автоматизированных тестах. Я считаю такой отчет обязательным материалом для анализа того, насколько автоматизация рентабельна.
- Удостоверьтесь, что тестируемый продукт является достаточно зрелым, чтобы усилия для технического обслуживания автоматизированных тестов при внесении изменений в продукте не перевесили выгод от автоматизации.
Однажды, несколько лет назад, вечером началась сильная буря, как раз в середине работы автоматически запущенного прекрасного набора тестов, созданного моей командой. Когда мы пришли на работу на следующее утро, мы обнаружили, что наш набор тестов автоматически перезапустил себя, восстановил сеть, нашел место, в котором произошел сбой, и завершил тестирование. Мы приложили много усилий, чтобы сделать наши тесты настолько стрессоустойчивыми, и, конечно, пришли в восхищение. Причина оказалась в том, как мы позже выяснили в процессе анализа скриптов из набора тестов, что из почти 450 тестов, лишь около 18 из них действительно были полезными. Это долгая история, как такое случилось (в основном, из-за древовидного сценария), но закончилось все тем, что мы имели набор тестов, который, с большой вероятностью, не мог найти ничего важного в продукте, который мы тестировали. Я рассказал эту историю другим менеджерам, которые не придавали значения подобным ситуациям. Они думали, что с ними такое произойти не может. Итак, это случится, если попытка автоматизировать тестирование отдалит вас от самого процесса тестирования.
И все же. Автоматизация тестирования – отличная идея. Секрет, как сделать ее хорошим капиталовложением, это думать в первую очередь о тестировании, и только во вторую очередь об его автоматизации. Если тестирование является целью в понимании качества программного обеспечения, то автоматизация – лишь средство для достижения этой цели. Вы можете знать о ней из рекламы, но это только одна из многих стратегий, которые поддерживают эффективное тестирование.
Джеймс Бач (j.bach@computer.org, http://www.jamesbach.com/) является независимым консультантом по тестированию и проверке качества программного обеспечения, который имеет опыт в программировании, тестировании, менеджменте качества ПО в Силиконовой Долине и в мире разработки коммерчески ориентированного ПО. Он работал в Apple, Borland, в паре начинающих и в нескольких консалтинговых компаниях. В настоящее время является редактором и автором колонки Software Realities в журнале Computer magazine. Основываясь на своих моделях Достаточно Хорошего качества, испытания тестов, исследовательского тестирования, и эвристического создания тестов, он сфокусировался на объяснении проектов по разработке ПО, и помощи отдельным тестировщикам ответить на вопросы «Что я здесь делаю? Что я должен делать сейчас?»