Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Пирамида автоматизации и другие геометрические фигуры


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

Продолжить обсуждение из Можно ли обойтись без page object паттерна:

Именно потому, что “Пирамида” набила всем оскомину, самое время ее обсудить.

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

 - Вот есть пирамида. 
(Все: кивают головой) 
- Это практически стандарт в тестировании 
(Все: кивают головой)
- Вот перевернутая пирамида. Люди говорят что это плохо. 
(Все: кивают головой)
- Значит давайте (*безумная идея тут*)

И тут я подумал, а может быть пирамида так притягательна не из-за глубокой идеи, а из за геометрической формы?

В этой теме я приглашаю придумать и обсудить геометрические идеи в автоматизации тестирования.
Но, для справки приведу пирамиду (треугольник) автоматизации
Ссылки:

Пирамида правильная:

Идея: пишите больше юнит тестов, потому что они “дешевые”, быстрые и должны быть фундаментом.
Потом интеграционные, ну а UI и мануального тестирования должно быть совсем мало.

Пирамида перевернутая:

Идея: ну вот, начали с UI автоматизации и теперь не можете остановится. Напишите хоть немного юнит тестов.
Часто используется в негативном контексте с примером длительного ожидания завершения прогона UI тестов.

Квадрат автоматизации

Вот пошло мое творчество :slight_smile: Хотя может эта идея у кого еще есть.

Идея в том, что все виды тестирования должны иметь равные права и быть независимыми.
Добавляйте тесты по требованию и в зависимости от контекста. Т.е. если вы считаете что вам необходим юнит-тест в каком-то труднодоступном месте – напишите его. А если вы считаете, что некий функционал уже перекрыт UI тестом – то оставьте как есть. Но, не должно быть пропорции: 1 UI тест = 3 интеграционных = 9 юнит тестов.
UI тесты отлично подходят для happy path сценариев. Интеграционные и юнит тесты для редких случаев, которые действительно сложно (и медленно) покрыть UI тестами.

Инь Янь автоматизации

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

Пирамида тестирования – вид сверху

Говорит, что UI тесты – самые важные (центральные). Просто потому что в итоге, нашем приложением будут пользоваться люди, в большинстве случаев через UI.
Конечно, есть случаи когда в продукте нет UI, например если продукт – это API сервис либо библиотека.
Тогда центральными становятся интеграционные и API-тесты.
Юнит тесты имеют самый низкие приоритет и служат лишь в помощь.
Я напомню, что юнит-тест – это тест конкретного класса или метода или функции.

Если вы используете несколько классов в одном тесте и сроете целые тестовые сценарии – то это уже интеграционный тест по определению.

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

Единственное о чем я не спорю – это о важности наличия и юнит и интеграционных и UI и “исследовательско-мануальных тестов”, но не стоит загонять их в рамки геометрической фигуры.

Или стоит? Если да – то предложите свой вариант.


(Igor) #2

Высокоуровневые тесты дорогие, долгие и их надо очень много, чтобы протестировать все варианты работы системы. http://www.slideshare.net/khroliz/qa-automation-33691614 - тут рассказываю, почему так. Идея не моя, честно скопирована.

Если не ставить во главу угла “Просто потому что в итоге, нашем приложением будут пользоваться люди, в большинстве случаев через UI.”, а проверку работоспособности системы, то результат становится качественно другим. Никто не отрицает, что UI надо тестировать и его как раз-таки можно тестировать отдельными тестами, без backend’a (http://artkoshelev.github.io/posts/frontend-code-quality/).

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


(Sergey Korol) #3

Мне интересно, а почему многие игнорят масштабирование? Постоянно слышу о том, что UI тесты долгие, гоняются часами, потому их должно быть мало и т.п. Может вы просто не умеете их готовить? (с)

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

Вот доклад на тему грида. Как люди укладываются в 15 минут, беря во внимание масштабность приложения.


(Igor) #4

@ArtOfLife гриды и прочая паралелизация не меняет экспоненциальную сложность изначальной задачи. Параллельные запуски в какой-то момент могут понадобится даже для юнит-тестов. Тут пример: http://sqadays.com/ru/talk/19004


(Sergey Korol) #5

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

Ибо тут я пожалуй возражу, сославшись на один из основных принципов тестирования, - exhaustive testing is impossible. Конечно, при такой постановке нас никакие гриды не спасут, тут не поспоришь. Но как же оптимизация входных данных, анализ метрик, применение уже давным давно сформировавшихся техник (equivalence partitioning / boundary value analysis) и т.п.?


(Igor) #6

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

Одно и то же можно действительно проверить разными способами. Можно, конечно, триггер на базе данных проверить через UI (подгрузив javascript, картинки, задействовать web и application сервера), но зачем?


(Sergey Korol) #7

Так никто ж и не говорит, что юнит тесты - это плохо. Мой concern касался распространенного заявления о том, что UI тесты - это всегда долго и дорого. Конечно, если рассматривать примеры на IE8 браузере и приложение с Java Applets на борту, то проще наверное вообще забить на UI тесты. Но технологии то не стоят на месте. Современные сайты строятся на каких-нибудь крутых JS движках с тенденцией отделения UI от backend. Ну напишите вы миллион юнит-тестов, ну протестируете вы вэб-сервисы. Но как вы будете тестировать комплексное взаимодействие компонентов между собой? Integration tests? Но ведь когда мы доходим до уровня UI, разве component integration не превращается в system integration? И к чему мы в итоге приходим? Все к тому же webdriver’у. Я уже молчу о внешних браузерных компонентах, к которым вы никак не достучитесь при помощи юнит-тестов.

Мне кажется, что эти извечные холивары совершенно бессмысленны. Применение того или иного подхода ну очень сильно зависит от тестируемого приложения. Так что лично для меня это весьма странно - придумывать какие-то подходы, хорошо работающие в рамках отдельных компании, но выдавая их, при этом, за world best practices, к чему якобы всем нужно 100% стремиться. Все это очень условно и depends on…


(Igor) #8

Я не говорю, что их вообще не нужно писать, да и пирамида их содержит. На самом почётном месте - на верхушке! :slight_smile: Они нужны, но нужно понимать, что они дороже и дольше unit и API тестов и их использование должно быть обосновано. И использовать их нужно тогда, когда нужно, а не тестировать всё подряд через UI.


(Denis Veselovskiy) #9

@ArtOfLife
А можете подробнее рассказать\описать о том как организовано у вас маштабирование?
Кол-во тестов, vm-ok, grid-ов, время прогона при разном наборе vm и т.д.
Наверняка многие найдут что то полезное для себя )


(Sergey Korol) #10

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

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


(Александр Таранков) #11

Ещё пара геометрических фигур :wink:

Паутина тестирования

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

Гора (куча) тестирования

Ну а это паутина тестирования - вид сбоку :smile: Потому что это не пирамида, а настоящая гора!


(Евгений Бухгаммер) #12

На больших проектах юнит тестирование и интеграционное тестирование позволяют раньше выявить, что заявленная фича не отвалилась. UI тесты же тестируют готовый продукт. Безусловно, UI тесты могут позволить протестировать юзабилити, через правильно оформленный юзкейс и придуманный сценарий, но по моему скромному мнению, в проектах, где задействованы десятки человек, ежедневные\ежечасные сборки, от 1 до 3 мерджей в мастер ветку проекта в сутки - все упирается в конечном счете в танцы вокруг кода, но не продукта. И чем его меньше, тем лучше. Безусловно, юниттесты и интеграционные тесты не панацея, но они в меньшей мере увеличивают общую кучу кода при производстве при заявленном качестве ( давайте за качество тут возьмем N багов в 1.X.05 версии продукта(мажорный апдейт) при Y затратах на тестирование ), а чем меньше кода - тем меньше и новых ошибок и в большей мере увеличивают уверенность - что фундаментально ошибок нет. Под фундаментально - подразумевается сама бизнес логика. Может, я не “делец”, но убежден, что бизнес логика превалирует над юзабилити и user experience. И если бы меня как Software developer in Test спросили, что бы я хотел - больше UI тестировщиков, или unit test coverage достигающий 100% по ключевым фичам продуктов - я бы был обеими руками за второе.

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


(Sergey Korol) #13

Т.е. чем больше багов вы нашли, тем качественней стал ваш продукт? :wink:


(Евгений Бухгаммер) #14

Testers don’t break products, just illusions people have about them

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

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

И еще одна штука под конец:

There are two types of program design: the one which is so SIMPLE that it, evidently, has no drawbacks.
And the 2nd one, which is so COMPLICATED, that it has no evident drawbacks.

Вот такая игра слов. А найденные баги - всего лишь путь истины от второго дизайна программы к первому.


(Sergey Korol) #15

А как это связано с моим вопросом?

Ок, пойдем по другому пути. Ну нашли вы допустим 50 багов в версии 1.X.05. И что дальше? Релизнете их на продакшен или будете фиксить? А 50 - это много или мало? Какой северити у найденных багов? Какой импакт на продукт в целом? Успеете ли все пофиксить? Каковы риски? А какой у вас test coverage? Все ли было покрыто при тестировании? Какова эффективность устранения дефектов? Какова плотность дефектов во времени? Делаете ли вы что-то чтобы ее снизить, или в каждой версии зарываетесь в багофиксах?

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


(Евгений Бухгаммер) #16

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

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

Не понял я поэтому вашей иронии с качеством багов, точнее, понял буквально :slight_smile: и буквально ответил.


(Sergey Korol) #17

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


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

Хочу поделится серией статей про юнит тесты, с прагматичным мнением, которое я разделяю.

Если коротко, то:

  • Моки – это зло (и причина почему тест не может выловить реальный критикал баг)
  • Если проблему сложно решить на данном уровне – поднимитесь на уровень выше
  • Чем меньше кода в самом тесте – тем лучше

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


(Евгений Бухгаммер) #19

Why Most Unit Testing is Waste

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

Да, тестировщики могли читать код каждого коммита. Но знают ли они досконально, как продакшн код работает? Да, программисты в открытом таске в Редмайне\Багзилле могли бы описать для себя и тестировщика детали того, как именно был зарезолвен баг\добавлена фича. Да, этот баг мог пойматься на UI тестировании, но не поймался…потому что регрессионные, функциональные тесты работают нон-стопом на всех системах, а до последней системы, где нужный баг приключился - просто не дошло. Потому что мало времени.

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

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

Пишу ли я юнит тесты для своих UI тестов? упаси господь. разве только использую тестовые фреймворки для генерации отчетов и читаемых логов.

Вот читаемые логи на каждый метод - это добро :slight_smile: