С чего лучше начинать автоматизацию?

общие вопросы
#1

Философско-юмористический эпос с открытым вопросом.

По приоритету

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

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

По частоте запусков

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

В первую очередь необходимо автоматизировать те модули приложения, которые меняются чаще всего разработчиками, так, разработчики смогут заметить проблему ещё до того как она попадет в сборку для QA. Следовательно, каждая сборка будет значительно стабильней.

По сложности сценариев

В первую очередь, нужно автоматизировать длинные бизнес-сценарии (end to end). Они, во первых, очень важные, а во вторых обеспечивают огромное покрытие как кода так и бизнес требований за один раз.

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

По типу тестов

В первую очередь, автоматизация тестирования должна начинаться с модульных тестов (unit test). Ведь они быстрые, и по идее, должны помогать разработчику писать код и ничего не сломать.

В первую очередь, нужно начинать с системных (UI / WebDriver / User Acceptance) тестов. Ведь одним таким тестом можно покрыть огромный участок кода, а также интеграционных тестов. Только в случае интеграционных тестов мы можем быстро выяснить, что код все таки правильно читает и записывает данные в базу данных и возвращает правильный результат при запросе от фронт-энда.

*Поспорить либо дополнить список можно внизу. *

Структура и организация тестов (Аннотация @Test)
#2

Ага, ну все, можно разводить срач в комментах.

Теперь по делу. В перечне отсутствуют, на мой взгляд, основные пункты, по которым и определяется, с чего начать автоматизацию. Это:

  1. Нужна ли нам автоматизация и для чего?
  2. Что именно мы хотим автоматизировать
  3. Кто должен реализовать автоматизацию и кто за это отвечает
  4. Место автоматизированного тестирования в общем цикле разработки
  5. Какую выгоду мы ожидаем получить от этого?

А уже исходя из этих пунктов можно работать с определением всех вышеперечисленных.
А вообще, вот достаточно уже старые посты по данной тематике:
http://blog.shumoos.com/archives/92
http://blog.shumoos.com/archives/138

#3

Я постараюсь ответить с точки зрения человека, который мало сталкивался с автоматизацией и только-только хочет начать.

1. Нужна ли нам автоматизация и для чего?
Конечно да, для того чтобы сократить время на тестирование и повысить качество продукта.

2. Что именно мы хотим автоматизировать
Тесты, которые проверяют работу нашего приложения, чтобы не делать это руками.

3. Кто должен реализовать автоматизацию и кто за это отвечает
Тестировщики и разработчики

4. Место автоматизированного тестирования в общем цикле разработки
В ходе разработки нужно гонять тесты

5. Какую выгоду мы ожидаем получить от этого?
Повысить качество продукта за счёт снижения количество багов, найденных на поздних этапах разработки.

#4

А мне больше нравится такой вброс: “Существую системы, которые невозмножно автоматизировать и мы (те, кто это говорит) пишем именно такую”.

2 лайка
#5

Скорее
Невозможно == достаточно сложно.

Я видел такой вариант, что приложение сделано на каком-то древнем UI фреймворке на Java и грузится как апплет. И средст автоматизации пользовательского интерфейса, кроме как «по картинкам» не существует.

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

1 лайк
#6

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

#7

Я считаю, что общие ответы человека, который мало понимает в автоматизации и человека опытного, в общем – не должны отличатся.

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

#8

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

#9

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

И с этой общепринятой теорией сложно поспорить, потому что как-бы все правильно и логично сказано… но… на самом деле, на практике понимаешь, что нет. Эта теория слишком категорична и не всегда полно соответствует реальности.

Способны ли тестировщики повысить качество продукта?
Да. Косвенно. Да, мы проводим те эксперименты над продуктом, и добываем ту информацию, которая и влияет на решения менеджмента и разработчиков. Не стает ли продукт более качественным, когда программист исправляет баг, заведённый тестировщиком? На мой взгляд – да, стает.

Способна ли автоматизация увеличить качество продукта?
Да. И тут я бы хотел говорить не о тех мифических процессах, которые влияют на качество продукта, а привести конкретный пример: при достаточном уровне покрытия кода авто-тестами, программист и вся команда становится более уверенна в том, что при добавлении новой фичи «слева», что-то «справа» не отвалилось и до сих пор работает. Авто-тесты – это инструмент. Он может быть хорошим или плохим, как любой другой инструмент. Но, влияет ли он на качество? – Да.

Как я говорил – автоматизация – это инструмент. Он сам может быть хорошим или плохим. Например, не самым лучшим решением будет, например, использовать QTP и VisualBasic для тестирования RESTful сервисов на Java.

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

#10

Вот именно, что косвенно. И в этом заслуга не отдельно автоматизации, а тестирования в целом.

А надо бы поговорить, так как эти “мифические процессы” в себя включают и модуляризацию архитектуры системы, и системный анализ, и управление изменениямиб планирование и много чего еще. Мало того, что эти процессы выявляют проблемы на еще более ранних стадиях, чем тестирование, так еще эти процессы так или иначе позволяют оптимизировать затраты на то же тестирование в разы лучше, чем автоматизация. Поэтому, когда определяются цели автоматизации тестирования, нужно учитывать тот факт, что некоторые вещи намного эффективней достигаются другими процессами. И уже когда их возможности исчерпаны, вот тогда уже можно говорить и об автоматизированном тестировании.

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

Ключевое выделено. Какая это польза от автоматизации, которая может привести к повышению качества продукта? Вот поэтому я и выделил цели и пользу от автоматизации в виде отдельного пункта. То есть, от автоматизации должна быть какая-то выгода, которая впоследствии позволит в том числе и повысить качество разрабатываемого программного продукта (но не только), а не наоборот.

#11

Николай, по моему мнению, ваш текст выглядит убедительным, мы с вами вместе оперируем такими словами как «косвенное влияние», вы ещё упоминаете «побочное влияние тестирования».

Это выглядит логично. Впрочем, как и Математические парадоксы, которые выглядят тоже очень логично. Я уверен, что они поставили в ступор ни одного учёного, иначе бы небыли такими известными.

Поэтому, я не хочу даже пытаться опровергнуть ваши логические утверждения, во-первых, потому, что этим оружием, логикой, вы владеете гораздо лучше, а во вторых, некоторые мнения описанные вами я слышал и от других людей, читал в книгах, и полностью их не принимаю.

Хочу привести в пример игру Бильярд, по правилам которой, игрок не может забить кием шар в лузу напрямую, для этого он должен использовать отдельный шар.
По сути, говорят, что «игрок забил шар в лузу», но по факту, он ведь сделал это косвенно! А забитый шар Б оказался побочным эффектом от удара кием по шару А.

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

Баг, заведённый тестировщиком – это и есть тот первый шар, который ударит шар продукт-овнера, который ударит шар разработчика. И если первый удар был точным, то шар разработчика попадёт в лузу (пропущенный баг будет пофикшен и продукт будет содержать меньше ошибок).
И тут не важно как тестирование влияет на процесс улучшение качества: прямо или побочно. По крайней мере мне не важно. Ведь влияет же.

Про «мифические процессы»:
Ну, я согласен, что тестирование и автоматизация тестирования – это не единственный способ повышения качества продукта. Но – это способ (хоть и не единственных), который повышает качество системы. И ненужно ждать того, пока другие процессы себя исчерпают. Все можно делать параллельно. Одно другого не исключает.

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

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

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

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

И ещё немного парадоксов, которые, к слову, были высказаны авторами с долей иронии, и в целях лёгкого троллинга:

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

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

#12

А зря. Эти суждения так или иначе основаны на опыте и на понимании того, что именно делается теми или иными процессами.

Ключевое выделено. По правилам допустимо именно такое действие и только выполнив его можно засчитать очки. Так что, когда говорят, что «игрок забил шар в лузу», то и подразумевают, что он выполнил необходимые действия согласно правилам.

Или влияет, но не существенно. Вся проблема в том, что если мы ставим какую-то цель, то вполне логично периодически проводить оценку того, достигнута ли она, чтобы принять решение о том, оправдано ли было то или иное усовершенствование. А теперь представим, что у нас есть цель повысить качество и мы для етого внедряем автоматизированное тестирование. Что в итоге можем получить? Можем получить то, что со временем число багов не уменьшилось, а даже наоборот, число выявляемых багов осталось на том же уровне. То есть общий показатель качества как мера соответствия между заявленными требованиями и фактическим поведением по-прежнему остается тем же, либо изменился незначительно. Может такое быть? Вполне, особенно, если объем работ постоянно растет, а численность команды остается примерно неизменной. Или не налажены процессы, которые именно направлены на минимизацию новых ошибок. В итоге получается, что автоматизация тестирования была неоправданной? Даже если принять во внимание, что удалось сократить время на тестирование в разы и при этом со всем этим справляется меньшее количество людей? Нет. Просто мы в данном случае от автоматизации почему-то ожидаем того, что должны делать другие процессы. И в итоге мы можем сделать неверные выводы.

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

Вооот, вот это уже оно. Автоматизация тестирования внедряется для:

  1. Экономии затрат (время, деньги) при последующих проведениях рутинных операций
  2. Для повышения качества самого тестирования за счет того, что некоторые операции без дополнительных программных средств либо крайне затруднительны (например, обработка больших объемов данных) либо практически невозможны (например нагрузочное тестирование при большом количестве подключений)

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

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

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

#13

И вот об этом:

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

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

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

#14

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

  1. Негативно повлиять на процесс разработки
  2. Оказаться нейтральной (в этом случае, затраченные ресурсы не окупают результат)
  3. Быть полезной и существенно улучшить процесс разработки

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

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

Вот я не говорю, что придёт автоматизация и принесёт качество в продукт. Каждый из процессов и активностей делает свой вклад в качество продукта. Автоматизация может повысить качество продукта, в итоге, путь не на +100%, но на какую-то часть.
Я согласен, что нужно понимать чего ожидать от внедрение автоматизации, для этого нужно и инструмент и подход правильный выбрать и стратегию развития.

Тогда вопрос: а зачем мы раньше тратили столько денег на тестирование? Если тестирование не влияет на качество продукта, то может быть стоило просто раньше отказаться от этой убыточной активности? (Впрочем… я хоть и иронизирую, но иногда так реально и поступают).

Или может быть так:
Автоматизация может рационализировать процессы тестирования, следовательно сделать (возможно) эти процессы более качественными, в свою очередь, более качественные процессы дают более качественный результат. Результат – это продукт.

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

#15

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

Но вы это изначально поставили как цель. У автоматизации тестирования такой цели нет. Об этом и весь последний флейм.

Для этого нужно понимать, зачем все это делается.

А для того, чтобы это понимать, нужно понимать, что такое тестирование вообще. Из определения: “Тестирование программного обеспечения - это процесс эксплуатации ПО с целью установить соответствие фактически наблюдаемых характеристик ожиданиям или заявленным требованиям”. То есть, тестирование - это своего рода измеритель качества. Если вам нужно именно как-то изменить качество, то тестирование для этого не нужно. Оно этим не занимается. Точно также вольтметр не влияет на изменение характеристик электрического тока, а только измеряет одну из них. Зато тестирование позволяет измерить это самое качество и установить сам факт изменения качества в лучшую или худшую сторону. Так что отказ от тестирования на основании того, что оно не влияет на качество продукта - это как раз пример того, что может случиться, если о процессах судить по характеристикам, которые к ним не относятся. Вот поэтому важно правильно озвучивать цели и ожидания, чтобы не возникали подобные казусы.

#16

Николай, тут все разногласие в том, что вы высказываете свои мысли в рамках отдельных процессов и активностей определений, по типу:

Гайка — крепёжное изделие с резьбовым отверстием, образующее соединение с помощью винта, болта или шпильки.
Винт — крепёжное изделие для соединения деталей с внутренней резьбой или без неё.

При этом, ни гайка и ни винт, как бы только очень отдалённо влияют на всю конструкцию, несмотря на то, что являются ее составной частью.

Я смотрю на роль гайки в рамках всей конструкции целиком. И да, качество отдельной гайки может сильно повлиять на качество всей конструкции.

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

Николай, может быть я на ваше поле свой мяч (с бильярдным шаром и гайками) переброшу?

Вот у вас, потенциальный заказчик спрашивает: «мы бы ещё автоматизацию внедрили, только не знаем как это нам поможет и с чего мы можем начать?»

Каков будет ваш ответ на те 5 вопросов?

(@dzhariy пытается перевести дискуссию ближе к первоначальной теме)

#17

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

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

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

Когда от заказчика приходит подобный вопрос, то тут есть 2 варианта ответа, в зависимости от того, что мы хотим получить от заказчика:

  1. Если вы хотите развести его на еще немного (или много) денег или пристроить с десяток людей на новые позиции, то можно и порассказывать ему сказки про увеличение качества и много чего еще, лишь бы денег дал
  2. Если это нужно для ваших процессов или же ваш заказчик это ваша же компания или ваш собственный бизнес, то тут уже не “заказчик” должен приходить с вопросом, а нужно ли нам это и с чего начать. Это уже технические специалисты должны сказать, что с этого можно поиметь. Причем, скорее всего придется оперировать не такими абстрактными понятиями, как скорость, качество, технологичность и прочее, а нужно использовать что-то более-менее понятное и ощутимое, как стоимость и прибыль. Ведь внедрение таких процессов - это всегда затраты. И они должны вернуться.

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

Автоматизация нужна, если:

  1. Основные операции, которые надо выполнять во время тестирования либо трудноосуществимы либо невыполнимы в принципе, без программных средств
  2. Разработка, внедрение и поддержка решения по автоматизации тестирования обходится не дороже, чем в случае его отсутствия
  3. Объемы работ по тестированию превышают возможности команды тестирования. При этом все другие способы оптимизировать нагружку на команду уже вычерпаны.
  4. Ожидается постоянное увеличение объемов тестирования, при этом бюджета на постоянное увеличение команды нет

Основные цели:

  1. Экономия затрат на тестирование
  2. Оптимизация затрат на разработку в целом
  3. Повышение качества тестирования (как минимум покрытие) за счет проверок, которые либо трудновыполнимы либо невыполнимы без привлечения программных средств

Тут возможны варианты в зависимости от проекта и с какой частью имеем дело, но в целом включаются следующие опции:

  1. Сборка (включая статические проверки)
  2. Развертывание (и сопутствующие проверки)
  3. Модульное/компонентное тестирование
  4. Интеграционное тестирование
  5. Системное тестирование
  6. Приемочное тестирование

Разработчики:

  1. Сборка (включая статические проверки)
  2. Развертывание (и сопутствующие проверки)
  3. Модульное/компонентное тестирование

Разработчики либо выделенная команда тестирования:
3) Модульное/компонентное тестирование
4) Интеграционное тестирование
5) Системное тестирование
6) Приемочное тестирование

Автоматизированное тестирование проводится на стадиях:

  1. Реализация: сборка, модульное тестирование + развертывание
  2. Тестирование: развертывание,компонентное, интеграционное, системное тестирование
  3. Приемка: развертывание + приемочное тестирование
  4. Поставка: развертывание + приемочное тестирование
    На основании результатов тестирования на каждой из стадий принимается решение о переходе сборки на следущую стадию или о возврате на доработку.

Возможны несколько вариантов:

  1. Минимизация затрат на разработку
  2. Стандартизация и повторяемость процессов
  3. Дополнительная прибыль за счет предоставления услуги автоматизированного тестирования, как сопутствующей поставке продукта