testomat.io управление авто тестами
Успешная автоматизация тестирования зависит от целого ряда факторов. Технические аспекты уже давно известны и хорошо понимаются инженерами автоматизаторами уже десятилетия, но вот человеческие аспекты не так уже много и обсуждались. Преодолеть и изменить какие-то конкректные подходы, которые тестеры разрабатывали для автоматизации десятилетиями, может оказаться сложной задачей.
Технические аспекты
Для того, чтобы понять человеческие факторы в автоматизации тестирования, мы должны пересмотреть технические факторы. Самая основная вещь - это автоматизация тестирования как таковая, или на самом деле разработка софта. Для того чтобы автоматизировать шаги теста, нам необходимо иметь разработанный софт, который будет поддерживаться вместе с кодом, который уже находится в эксплуатации и который также тестируется.
В основном, автоматизированный тест состоит из двух частей: тестовые данные и код, который управляет тестируемым приложением. Тестовые данные обычно поддерживаются в отдельной формате или даже в отдельном репозитории. Фактический код автоматизации может строиться через уже существующие фреймворки, такие как FitNesse или RobotFramework или же могут использоваться фреймворки, которые создаются непосредственно в компании для нужд проектов.
Тестовые данные
Поддержка тестовых данных - это критичная часть автоматизации тестирования. В самом плохом случае, изначально полученные тестовые данные должны быть адаптированны к каждому изменению в программном продукте, а также строится другая система, которая использует автоматизированные тесты. В итоге мы получаем эффект второй программы при автоматизации тестирования. Самым обычный случай - это тестовые данные, которые написанные в таких терминах как и система оперирует сущностями. Например, тест для авторизации пользователя на веб-сайте может выражаться в тестовых данных как "open browser FireFox", "load login page," и "enter in the first text field username.". Это связывает тестовые данные с деталями реализации интерфейса с эффектом, что когда либо поменяется пользовательский интерфейс и тесты тоже необходимо будет изменить.
Аналитики знают простую технику чтобы обойти эффект второй системы. Описания вариантов использования и спецификации фокусируются на цели для пользователя или функциональных требованиях в терминах чего необходимо достичь, чем предписывают конкретную реализацию, которую необходимо сделать. Решением эффекта второй системы, следовательно, будет создание тестовых данных с точки зрения цели для пользователя. Если смотреть на вышеупомянутый пример, то это может выглядеть как "login as user 'user' with password 'very secret.'". Такой тест в последствии будет независимым к изменениям в пользовательском интерфейсе. Эта зависимость передвигается в исполняемый код, который знает как выполнить необходимые действия над тестируемым приложением.
Код автоматизации
Код автоматизации - это код, который связывает тестовые данные и взаимодействие с тестируемым приложением. Этот код может строиться с помощью уже построенных фреймворков или же разработанных в компании. Сейчас фреймворки также запускают тесты и делают отчет по прогону тестов.
Как указывалось выше, код автоматизации зависит от самого приложения. Потому, код должен разрабатываться похожими методами разработки, как и само приложение. В идеале, тестируемое приложение и код автоматизации должны использовать один и тот же исходный код в репозитории, для того чтобы изменения в каких-то классах сразу же имели отображение в коде автоматизации. Также код автоматизации может становиться все более сложным с временем и его также необходимо комментировать и тестировать.
Человеческие факторы
Elfriede Dustin сказал в 2005 году в интервью "50 процентов моей аудитории имеют инструменты автоматизации, которые никак не используются и пылятся на полках". Для того, чтобы избежать такого эффекта, необходимо чтобы автоматизация как процесс учитывала как человеческие факторы так и технические.
Знания и навыки
Знания и навыки каждого тестировщика - критичны, потому как автоматизация тестирования может изменить характер работы тестировщика. Некоторые тестировщики не уверены в своих способностях программировать что-то, может быть стоит просто потренироваться, или в частности использовать какие-то языки программирования, которые используются в работе.
С негативной стороны, разработчики автоматизации могут также ошибаться и делать дефекты в коде автоматизации, что произведет к тому что тесты не будут проходить, там где они должны проходить и наоборот. Потому, тестирование самой автоматизации тоже критично. В дополнение, обычный тестировщик может чувствовать угнетение, так как он всего лишь ответственный за подготовка тестовых данных, а разработчик автоматизации ответственный за код автоматизации и все остальное. Это чувство может быть преодолено командной работой и тесным общением между участниками команды.
Взаимодействие
Самый тяжелый фронт, наверное, это взаимодействие с разработчиками ПО и бизнес-пользователями. Тестировщики могут свободно работать с бизнес-пользователями над определением тестовых сценариев для их проектов, но такая штука как "независимое тестирование" гласит - "тестировщики не должны говорить с разработчиками" и это становиться четкой гранью между разработчиками и тестировщиками. Вы должны разбивать эти виртуальные стены.
Как сказал Peter M. Senge в The Fifth Discipline, общая ментальная модель должна быть разработана на ранних стадиях. Это означает что программисты вместе с аналитиками, и тестировщиками должны садиться вместе и разрабатывать общую модель правил для проекта. Тестировщики могут быть вовлечены на ранних стадиям проекта, обсуждение требований или взаимодействие с заказчиком. Может быть их участие не даст больших плодов, но это жизненно необходимо для формирования общей ментальной модели проекта.
Но эта ментальная модель не должна быть фиксированной на протяжении действия проекта. Изменились требования, команда должна или пересмотреть текущую модель или же разработать новую. Взаимодействие всей команды помогает поддержать такую ментальную модель на протяжении жизни проекта. Потому что неявные и дружелюбные коммуникации помогают улучшать текущую модель проекта, например разместить независимых тестировщиков возле программистов поможет улучшить вашу автоматизацию.
Фокус
Фокусировать тестовые данные на варианты бизнес-использования может показаться простым советом. К сожалению, для тестировщиков которые не знают о автоматизации, это означает изменение их мышления. Просто когда работаешь с ручными тестами, тестировщик знает что тестировать и как тестировать. Если тестировщики делал это десятилетиями, то тестовые данные будут отображать стиль ручного тестирования, к которому привыкли тестировщики. Эти выливается в высокую стоимость поддержки, так как тестовые данные необходимо менять вместе с изменениями с разрабатываемым приложением. Потому, для каждого исправления дефекта, все тесты должны быть просмотрены и некоторые должны быть адаптированны под изменения. Фокусирование на бизнес-правилах может быть препятствиям для тестировщиков, которые делали только ручное тестирование несколько лет. Для успешной автоматизации, эти тестировщики должны быть перемещены из их зон комфорта. Они должны иметь четкие инструкции как фокусироваться на тестовых данных.
Недвусмыслиммые тестовые результаты
Наконец, тестовые результаты должны быть недвусмысленны. Когда тест проходит или не проходит, значит все должно быть четко, что пошло не так. Gerald Weinberg сказал в Perfect Software ... and Other Illusions About Testing, точное определение ошибки - это ответственность, которая лучше выполняется конкретными разработчиками. Потому, тестовые результаты должны быть надежны.
Для того, чтобы получить недвусмысленные тестовые результаты, сами тесты должны писаться четко, фокусируясь на бизнес-правилах. Один путь достичь этого - это фокусироваться на продукте который построен в терминах целей пользователя. В дополнение, когда тест включающий несколько бизнес-правил падает, тестировщик который смотрит результаты должен смотреть глубже для того чтобы понять, одно бизнес-правило работает или два не работают или же проблема находится в коде автоматизации. С тестовые набор в несколько тысяч тестов может быть сотни упавших тестов, потому тестировщик будет больше времени проводить в поисках причин ошибок. Это больше анализ результатов, а не тестирование. В долгосрочной перспективе, этот порочный круг видет к тому, что автоматизация объявляется не эффективной.
Потому, разработчика автоматизации должны тренироваться в том как строить свои тесты, фокусируясь на атомарности. Потому что двусмысленные тестовые результаты обрекают автоматизацию тестирования, а ее успех в основном определяются качественно написанными тестами.