Роль автоматизированного тестирования в Web-проекте


(Yuriy) #1

Просматривая видеозапись выступления Андрея Дзыни "Разворачиваем инфраструктуру для автоматизации функционального тестирования веб приложений" я обратил внимание, что на диаграмме "Жизнь проекта" тестирование занимает четвертую позицию, что вполне объяснимо.

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

Не сочтите за труд, подтвердите или опровергните эту точку зрения.


(Дмитрий Жарий) #2

 

Юрий, 
Автоматизация тестирования – это понятие довольно обширное. 
Скажем, если взять юнит тесты, которые пишут разработчики. При подходе Test-driven Development, тест пишется еще до написания кода приложения. При так подходе получается, что функционал автоматизируется еще его появления. Ну, а после,  юнит тесты служат для увеличения уверенности разработчиков в том, что новые изменения не сломали ничего старого. 
 
Тестируя приложения мануально, мы используем самые различные инструменты.  Например, для реверс инжениринга базы данных я использую самописный  Sql Change Scanner и MS SQL Server Profiler. У меня есть несколько скриптов на Perl, которые анализируют состояние базы данный, парсят логи приложения и бьют тревогу, если что не так. Это инструменты мониторинга, которые я использую в мануальном тестировании. Но, ведь это тоже полу-автоматизирует мое тестирование, ведь 
 
Самое сложное тестирование – это тестирование через UI. Потому что как раз UI слой обычно бывает очень нестабильный, и пока он не стабилизируется – с тестами головной боли очень много. Приходится тратить много времени на поддержку. Так что, если есть возможность автоматизировать приложение без вовлечения UI тестов – лучше сделать так, а сам UI потом мануально прокликать. Но, если ваш UI слой стабильный, то и проблем с ним будет мало. Обычно UI автоматизацию и откладывают в такой далекий ящик по этой причине. 
 
Кроме того, я ничего не знаю о стратегии вашей автоматизации. Кто выбирает тесты? По каким критериям? Насколько эффективны эти тесты? 
 
Но, опять же. Отнеситесь с осторожностью к моим словам. Я не знаю полностью ситуации на вашем проекте. И в зависимости от различных факторов, мои слова могут быть верны или не верны.  
 

(Yuriy) #3

> Самое сложное тестирование – это тестирование через UI. Потому что как раз UI слой обычно бывает очень нестабильный, и пока он не стабилизируется – с тестами головной боли очень много.

Дмитрий,
Почему тестирование через UI, является сложным и в чем причина его нестабильности?

 


(Дмитрий Жарий) #4

 

Нестабильность в том, что сам UI приложения обычно очень нестабильный и подвержен изменениям. 
Кроме того, UI тесты при тестировании функциональности заставляют делать огромные обходные пути. 
Давайте сравним два варианта: 
Есть приложение, которое на странице профиля пользователя отображает его любимое число Фибоначчи. 
В коде есть функция Fib(n), которая возвращает n-e число Фибоначчи. Для того, чтобы протестировать правильно ли она работает, достаточно написать код типа:
 
var ExpectedFibNum = 2;
var ActualFibNum = fib(3);
Assert.AreEqual(ExpectedFibNum, ActualFibNum);
 
И всё. Функциональность протестирована.  И очень просто добавить еще несколько похожих тестов или сделать такой тест Data Driven.
Тут под Fib может быть прямое обращение к Rest API приложения, вызов хранимой процедуры, запуск  коммандлайновой утилиты и получения результата. 
 
А что если делать тот же самый тест через UI?:
1. Залогинится 
2. Пойти в настройки пользователя и задать Любимое число n
3. При этом, искать div в span под input для заполнения формы
4. Найти AJAX иникатор загрузки чтобы понять, завершился процесс сохранения или нет
5. Пойти в профайл пользователя. Найти текст у span в ячейке таблицы с нужным числом
6. Проверить ожидаемое и актуальное значение
 
А представляете, что на одном из шагов айдишники поменяются?
А если вы получите ElementWasNotFoundException, то это баг приложения или кода автоматизации?
Как бы мы не пытались подсластить пилюлю UI тестирования, отловом JavaScript ошибок, созданием скриншотов при ошибке, использованием PageObject… все равно UI тесты будут отнимать значительное время на поддержку и создание. 
И это просто необходимо всегда учитывать. 
Я не хочу сказать, что от UI тестов нужно отказываться, тут я лишь попытался проиллюстрировать насколько они сложнее для поддержки и анализа. 
 

(Mykhailo Poliarush) #5

дело в том, что автоматизация указана на 4ме месте, потому что докладчик опирается на личный опыт.

а личный опыт у него это разрботка с помощью гибких методологий

соответсвенно, тут вопрос больле методологический чем конктретный, потому что автоматизация тестирования в agile среде играет очень большую роль

потому, что там есть краткие итерации, потому что там нету много времени, потому что количество фич растет, а выделенной роли тестировщика и тем более автоматизавтора нету

поэтому это общекомандная практика для того, чтобы обеспечить успешный процесс для этой методологии

 

как у вас это делается не знаю, это вам лучше видно, но факт остается фактом, автоматизация должна применяться там где это нужно.

у вас это нужно в самом конце, когда уже много сделано,

а некоторые автоматизирует, как только появляется описание фичи и до того, как код готов


(Yuriy) #6

Если мы знаем аргументы функции и ожидаемый результат (например, уже упоминаемая функция вычисления числа Фибоначчи), то тесты мы можем написать раньше кода реализации. А возможно ли написать тесты, когда Web-страница еще не создана?
 


(Дмитрий Жарий) #7

Возможно, Вам будет интересен этот доклад:

Николай Алименков: TDD c помощью функциональных тестов на WebDriver


(Mykhailo Poliarush) #8

не только возможно, но и продвинутые команды так и делают :)


(Yuriy) #9

> Возможно, Вам будет интересен этот доклад: "Николай Алименков: TDD c помощью функциональных тестов на WebDriver"

Спасибо Дмитрий, за ссылку на хороший доклад по моему вопросу.

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

 

 


(Дмитрий Жарий) #10

 

Могу сказать, что такой подход вполне возможен. Вот только зависит он от нескольких факторов.

Вариант, если в команде  два и меньше автоматизатора:

Самые важные из которых, прозвучали в докладе.

1.       Первое и основное – это хорошая коммуникация между разработчиками и тестировщиками:

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

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

c.       Вы должны быть в курсе технических деталей и планов разработки.
 

2.       Разработчикам должна быть выгодна автоматизация тестирования. Как? Все зависит от проекта. На некоторых проектах чем больше багов пофиксил разработчик  – тем лучше, ведь сколько работы-то проделано.  В других ситуациях, разработчики стремятся уменьшить количество багов после сдачи в тестирование.  Тут они не только сами тестируют свой код, но и могут помочь в разработке приёмочных тестов.  И ведь исключительно в своих интересах, просто чтобы быть уверенным, что код работает.
 

3.       Разработчики должны писать, править и понимать результаты прогона приёмочных авто тестов.  Логи автоматизации понятны. Разобраться почему «элемент не найден» – не лень.

В таком режиме, сами разработчики смогут писать тесты перед реализацией функционала. С учетом этого, они будут заинтересованы в создании более простой верстки страницы и более тестируемого функционала. 

С учетом такой слаженной работы – использование техники создания тестов перед реализацией фичи более чем реально.

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

 

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

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

В таком режиме, с учетом уже развитого фреймворка – на мой взгляд, создание тестов перед  добавлением нового функционала также вполне реально.

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

 

Если разработчикам непонятно что делает автоматизация, менеджеры до сих пор не могут понять что это такое и зачем оно нужно, и вообще автоматизацией занимается даже не отдельный человек, а мануальный тестировщик, который не разбирается в программировании хотя бы на уровне Junior Developer и может потратить лишь 2 часа в день… в этом случае уж извините… 


(Yuriy) #11

Спасибо. Все так четко и понятно описано.

Методика TDD подразумевает написание тестов перед созданием кода. Существуют ли методики позволяющие создавать тесты и код паралельно для Web-проектов?


(Дмитрий Жарий) #12

 

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


(Yuriy) #13

>> Существуют ли методики позволяющие создавать тесты и код паралельно для Web-проектов?

> ... т.е. автоматизация уже готового функционала.

Дмитрий, я имел в виду, немного другое, когда тесты и функционал пишутся одновременно и нет необходимости ожидать сначала написания тестов до кода, как в TDD, или ожидать написание кода до создания тестов, как происходит в большинстве случаев.

 


(apetrovskiy) #14

Для этого надо иметь скилл "думать перед кодировать", а это большая редкость! Поэтому у нас заранее автоматизируют то, что не зависит от команды - внешние датасорсы, воздействия и т.д. Потом логику (когда стало примерно понятно, что сляпали), а уже после юзер или вэб-интерфейс. Так сказать, чем ближе к коду продукта, тем непредсказуемее :)


(Дмитрий Жарий) #15

 

Я придерживаюсь правила золотой середины :)

До того, как функционал готов, должны быть известны мануальные тесты. Эти тесты обязательно должны иметь приоритет. Именно самые высокоприоритетные тесты необходимо автоматизировать.

Например, создание пользователя – это первоприоритетный тесткейс. Успешное сохранение поля email – имеет первый приоритет,  потому что на этих данных завязана связь с пользователем.

Если поле «отчество» не сохранится – это имеет низкий приоритет.

Лично я считаю, что автоматизация UI тестирования до создания функционала – это процесс рискованный, потому что не известно какова будет реализация, и с каким Div’ом в Span вы провозитесь полдня.   

Зато, если у приложения есть API (например REST или Webservice – то можно автоматизировать при помощи создания заглушек. )

Или если вы тестируете комманд-лайн интерфейс, и протокол взаимодействия известен, то написать тесты перед реализацией не сложно.

Если новая фича не сильно влияет на UI приложения: «Для премиум пользователей, вместо привет Вася, мы выводим Привет дорогой Вася», и у вас уже есть наработанная декларация элементов страницы, то в таком случае  можно автоматизировать UI до появляния фичи.

Тут все зависит от контекста ситуации в которой вы находитесь. Просто попробуйте несколько подходов и решите который из них правильный. 


(Yuriy) #16

> ...чем ближе к коду продукта, тем непредсказуемее :)

Да, Вы, правы. Я столкнулся с такой ситуацией и она мне почему-то совсем не нравится.

 


(apetrovskiy) #17

Привыкнете! Иногда без смены команды и/или менеджмента (смотря кто сильнее) такая ситуация неисправима ;)


(Mykhailo Poliarush) #18

перемены всегда тяжело воспринимаются всеми

просто кто-то к этому готов, а кто-то нет

а что вам в этом процессе не нравиться?