четверг, 27 декабря 2012 г.

Пирамида автоматизации тестирования в agile

В книге "Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд" Лайзы Криспин и Джанет Грегори рассказывается о пирамиде автоматизации тестирования в agile. Эта пирамида показывает идеальный вариант распределения количества автотестов по категориям. Вот что пишется об этой пирамиде в книге:

Каждый уровень характеризует количество тестов на уровне.
Unit tests – пишутся разработчиками, таких тестов самое большое количество.
API Layer  - на нем происходит тестирование бизнес-логики. Тестируется функциональность не через пользовательский интерфейс, а через API. Эти тесты пишутся на языке предметной области (domain-specific), чтобы они были понятны и разработчикам, и заказчикам. Можно использовать различные таблицы для формирования входных данных. Функциональные тесты работают напрямую с продакшн кодом, без GUI или какого-то другого слоя между ними.
GUI тесты – пишутся, когда код уже написан. В общей массе тестов их должно быть меньше остальных ( тестов нижних двух уровней пирамиды). Тестируется тонкий GUI с малым количеством или отсутствием бизнес-логики. На этом уровне не надо тестировать бизнес-функциональность. Например, можно проверить, что кнопки работают, выполняют ожидаемые действия, появляются корректные сообщения об ошибках. Какие-либо тесты, где необходимо тестировать именно пользовательский интерфейс, или когда без пользовательского интерфейса не обойтись.
Ручное тестирование (manual testing) – usability и exploratory testing. Проводится при наличии пакета регрессионных автоматизированных тестов.

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




12 комментариев:

  1. > если мы внедряем автоматизацию на уже существующем продукте

    Это примерно как начинать тестирование на продукте, который ет 5 никто не тестировал.

    > Потому что тестировщик-автоматизатор все таки работает на уровне пользовательского интерфейса

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

    А вообще обычно получается мороженка. Что очень плохо: http://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/

    ОтветитьУдалить
    Ответы
    1. Тем не менее, бывает такое, что люди приходят к пониманию того, что нужна автоматизация, когда продукт уже выпущен, мир не идеален, и тут уже кроме UI-тестов ничего не остается. Когда UI достаточно стабилен, лучше уж такие, чем ничего. :(

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

      Удалить
    2. Да, иногда поздно. Но это как мертвому припарка, обычно. Стабильного интерфейса недостаточно (к тому же он редко таковым бывает). В итоге при такой запоздалой автоматизации мы получаем фиговое testability даже с точки зрения GUI тестов. И до кучи все начинает решаться наращиванием базы GUI тестов где надо и где не надо под предлогом того, что других вариантов нет. А они всегда есть - рефакторинг, заготовки тестовых требований к архитектуре следующих версий и так далее. Плохое testability это технический долг. И его нужно ликвидировать.

      Что касается API тестов, то их писать легче, чем городить огород из костылей вокруг GUI написанного без учета того, что его будут автоматически тестировать. Но чтобы это понять нужно начать их писать. И тут мы натыкаемся на проблему, аналогичную той, по которой люди боятся говорить по английски

      Удалить
  2. Абсолютно солидарен с Сергеем. Автоматизация после релиза не работает: попытка догнать уходящий поезд. Ну и тесты через UI это тоже, еще те себе тесты. Картинка с мороженкой 5+, так и получается в итоге.

    ОтветитьУдалить
    Ответы
    1. > Автоматизация после релиза не работает
      Мне кажется работает, пусть и не настолько эффективно, как если бы она внедрялась с началом разработки. И конечно же все зависит от того, кто и как эту автоматизацию осуществляет. Есть такая книжка "Experiences of test automation" Dorothy Graham, где собраны примеры того, как разные люди осуществляли автоматизацию тестирования своих продуктов, так вот там в первой же истории рассказывается пример как всем известная Lisa Crispin успешно внедрила автоматизацию регрессионного тестирования в продукт, релиз которого уже был выпущен.

      Удалить
    2. Автоматизация после релиза работает, если правильно определить, что и как автоматизировать. А если автоматизировать не думая, то оно и до релиза работать не будет.

      Удалить
    3. О дааа, я согласна, но это можно сказать вообще про любую область, не только про тестирование :)

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

      Удалить
    5. Это про legacy системы (не в том смысле, что системы без юнит-тестов, как считают радикальные авторы. В смысле, что релизы уже были, а покрытие тестами не полное). Надо покрыть старое, чтобы убедиться, что новое старое не ломает.

      Удалить
  3. Прежде всего не забываем, что эджайлные авторы имеют свою специфику
    1) они живут консалтитнгом, тренингами, сертификациями, книгами - "волка ноги кормят", посему пишут и говорят зажигательно. Но любая система - это модель. Пирамида Кона, квадранты Марика (из этой же книги), пирамида акцептанс тестов из Continuous Delivery, ch. 8 - это идеалы.
    2) Подавляющее большинство эджайлистов вышли из джавы и приложений для крайслера (Бек?), банков, страховых и т.д. - т.е. экраны рабочих мест или браузер, БД в полном распоряжении, реже - сетевые коммуникации.

    По теме: у нас в направлении исторически сложилось так, что софт - это администрирование винды и сетей, реже никсов. Отличия от "эджайлистов"? Больше зависимостей от инфраструктуры, конфигураций, внешних воздействий.

    Отсюда вытекают выводы:
    1) GUI тесты обязательно. Как проверить, что будет с приложением пока оно ждёт отклика из облака. Понятно, что кнопки жмутся. Но это не всё. Приложение должно дождаться, не скончаться и не скукожиться при ожидании.
    1.1) наши программеры часто не особые спецы в UI, зато контролы надо ставить сложные (наши продукты выводят в GUI разнообразные концепции администрирования). Очевидно, что научить программеров работать с третьесторонними контролами можно через багфикс (а баги получать через автотесты GUI).
    2) API - у нас юнит-тесты пишутся не на всех проектов (да, увы). Поэтому плотное тестирование API ут помогает. Как? Если переставив пару строк кода, всё валится - очевидно, что нет юнит-тестов на инициализацию. Но тесты API тоже могут это найти.
    3) юнит-тесты на продакшн-код не про нас - их должен писать автор кода, само собой.

    Для Windows-продуктов мы покрываем GUI и API прямо (GUI, API) или косвенно (API, через свои либы) через пауэршелл. Пауэршелл поддерживает keyword-driven testing (пример: Click-Button, Click-Next, Create-SuchAnObject), поэтому мануальщики тоже быстро оказываются при деле.
    ну вот всякие никсы, маки, мобильники обычно требуют своих подходов, тестирование чуть дороже выходит...

    ОтветитьУдалить
    Ответы
    1. В никсах-то чем дороже? Да, конфигураций может быть больше, но зато скриптуется легче и разворачивается сильно быстрее. Или у вас там гуй какой-то тяжкий?

      Удалить
    2. Нет, насколько я помню, в никсовых проектах или не было гуя, или был вэб гуй.
      Не так удобно, как пауэршелл, потому и дороже, что в одном месте шелл (команды же разные на разных осях), в другом питон. Помнится, сделал генерилку файлов на C++, надо было , так один и тот же код в линуксе работал в десять раз быстрее, чем в аиксе.

      вроде бы в соседнем отделе сейчас есть что-то гуёвое на никсах, кликают джавой (где могут). Но тоже дикое разнообразие способов доступа, хочется единой среды.

      Удалить