Связь Автоматизированых и Мануальных тестов

Перенесено из темы:

по предложению @Ayia

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

Количество ручных сценариев должно всегда расти. Правильно ли это?
С точки зрения вида сверху-вниз, все идет очень хорошо. Каждый спринт, количество сценариев увеличивается. Тестировщики пишут новые сценарии. Месяц назад было 300, сейчас уже 400… через пол года будет уже 800… По сути, это создает ситуацию, когда ненужные сценарии нельзя удалять. Следовательно, увеличивается процент шлака: вместо того, чтобы удалять ненужные тест-кейсы (те, которые не приносят пользы), их наоборот увеличивают и… принимается решение автоматизировать этот шлак, вместо того, чтобы его вывести. Тогда метрика один тест в час, превращается в метрику один шлокотест в час.

И на противовес: автоматизировать лучше те сценарии, которые оказывают наибольшее влияние на продукт.
На меня очень повлияла вот эта презентация (я видел еще старую версию). В ней высказываются идеи, как выявить те участки продукта, которые действительно важны, и нуждаются в автоматизации:
How to Narrow Down What to Test

На своем проекте, я провел небольшое исследование и для себя выявил, что именно самые простые тест-кейсы находят наибольшее количество багов. Именно позитивные CRUD сценарии.
Но, этот показатель может зависит от специфики проекта. Собственно, у меня как-раз по большей части – CRUD приложение.
Очень полезно посчитать статистику по баг-трекеру по критичным и серьёзным багам. Именно эти области и нуждаются в автоматизации.
Кроме того, если это возможно, то лучше поставить себе первоочередную техническую цель по покрытию кода приложения. Мне помогли инструменты для C#/.NET – OpenCover; Для JavaScript – JSCover. Именно благодаря им я понял, что при помощи очень простых сценариев можно покрыть до ~80% кода (70-80%%). А это – обеспечит очень классное смоук тестирование, которое быстро находит JavaScript ошибки и крэши сервера.

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

Кто согласен с тем, что самая большая польза от мануальных тестов, это по сути то, что они позволяют понять, что-же все таки делает автоматизация?
Действительно, проблема с тем, чтобы объяснить, что-же все таки делает автоматизация – существует по сей день, и еще нет такого решения, которое бы устраивало всех.
А решение, залинковать мануальный тест к автоматизированному – это, как бы, универсальное. И доступно практически всем, даже если ваши мануальные тесты – в Excel, а автоматизация – на QTP. Тут, мы умалчиваем, что при таком подходе – возникает проблема синхронизации: либо мануальный сценарий изменится, а автоматизированный нет – либо наоборот.
Я упомянул, что нет такого решения, которое бы устроило всех… Но, это не значит, что решений нет вовсе. Но, об этом – позже.
А пока, хотелось бы поделится еще одним докладом, прозвучавшим в бородатом 2010-м, на конференции SQA Days:
Автоматизация тестирования модели разграничения прав доступа к функционалу

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

А почему бы не генерировать мануальные сценарии из кода автоматизации?
По сравнению с бородатым 2010-м, сейчас уже такие подходы на слуху у многих. Да, есть свои проблемы… но кто говорил, что это простой путь?
Есть известный все Cucumber, который позволяет писать тесты на языке… хм… приближенном к понятному.
Но, на основе этого инструмента, появился Relish https://www.relishapp.com и сейчас, те же люди работают над https://cucumber.pro
И для меня, генерация мануальных тестов на основе автоматизации – интересна, и я работаю над ее воплощением.
Тут я описал очень простой пример, как это может работать, с выводом текста в консоль, но никто не мешает использовать такой подход и для генерации файлов с мануальными сценариями:
How to Create an App from Scratch | AppMaster

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

3 лайка

Мне кажется нужно писать код “как документацию”. Следуя правильным практикам код будет достаточно понятен даже досаточно умному Manual QA посидевшему на выходных и розбравшемуся с синтаксисом инструмента. А заказчику и не нужно смотреть в “документацию по мануальным сценариям” так как его должно только конечное качество беспокоить, а его то уж правильно организованая команда должна обеспечить по умолчанию:)
В результате мы будем иметь все непокрытые мануальные тесты отдельно, и все покрытые - будут собственно представлены самими автотестами.
В любом случае не плохо бы иметь полную функциональною карту приложения хотя бы с примерным обозначением покрытия автотестами.

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

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

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

Так что мое имхо: оставьте кесарю кесарево - пусть мануальщики изучают требования и пишут тесты, а автоматизаторы их автоматизиуют.

И напоследок реальный пример. Проекту более 5 лет. Решают поднять автоматизации. Дают одного-двух человек. Кол-во тестов давно перевалило за 10К. На проекте 10 manual qa. Проект настолько большой, что, что бы узнать всяческие подробности в определенной области, нужно обращаться к определенному специалисту. Автоматизаторы не знакомы с проектом, и он для них просто набор ui элементов. От них требуется составить план автоматизации. Ваши варианты?

Этот вариант обусловлен соответсвующими условиями на проекте. Я просто не допущу таких услвоий на своем проекте если буду на нем с самого начала. Если же упрусь в “неадекватный менеджмент и палки в колеса” сверху - уйду, или не прийду сразу. Мой подход таков - что чистые мануальщики, или по крайней мере такие “по духу”, то есть те кто даже не собирается использовать автоматизацию - не QA инженеры. Мне кажется нужно рассматривать технологии и подходы не только с позиции - уже все плохо, значит этот подход плохой… ІМХО, подход хорошый там где с самого начала все будет “правильно”. А если уже все плохо, то подход просто не работает для этой “исключительной ситуации”. Соглашусь конечно с тем что при наших реалиях эти “исключительные ситуации” становяться стандартом.

На данный момент не пойду на такой проект работать:) Или пойду но если на проекте поменяют подход к разработке, например:

  • девелоперы начнуть писать аксептенс тесты на новые фичи, не говоря уже о юнит тестах (допустим говоря об этом - исключим десктоп приложения :))
  • мануальщики возьмуться в свободное от работы время учить автоматизацию, и в рабочее - применять

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

Вопрос не в этом. Вам дали много сантиков, девы уже давно пишут юнит тесты, а мануальщики по ночам читаю книги по java и умеют пользоваться Selenium IDE. Можно ли в данном примере обойтись без связи автоматизированных и мануальных тестов при составлении плана автоматизации и его реализации?

ЗЫ: не понятно зачем смешивать роли и специализации? Дев никогда не напишет тест лучше qa, qa никогда не напишет авто-тест лучше автоматизатора, который, чаще всего, более qa чем разработчик. Конечно выгоднее иметь вот такого монстра дев-autoqa-qa в одном лице, но я таких не встречал, да и наверное и платить ему придется в три раза больше.

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

Хм… Что то я наверное упустил))))) или не понял…
Ладно начнем сначала…
ИМХО:

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

Почему смешивать) Аксептенс тесты - не сложные. Их девы напишут без проблем. Что они и делают и имеют в этом успех (в который раз цитирую http://blog.codeborne.com/2012/12/5.html).
Это как раз при стандартном раскладе дел - автоматизаторов используют как “девов” в случае написания аксептенс тестов - то есть там где особо “кюейного” ума не надо, или в случае написания фреймворков - где уже обычно “автоматизаторского опыта” не достаточно - и девы тоже справятся быстрее.
Настоящие автоматизаторы - это действительно монстры, которых мало, но какими нужно стремиться стать. Автоматизаторство - это не роль. Это скил, который нужен Тестировщикам тогда когда они хотят повысить свою продуктивность, и не только в “замене” своих рутинных действий, но и в расширении инструментов для поиска багов. Вот пришел я на проект где до этого было налажено только менюел кюей - и я нахожу такие баги которые до этого никто не замечал. Пускай большинство из них минорные, но и довольно серьйозные мейджоры попадаются. А все потому, что автоматизация позволяет мне - освободить мозг от уже известных рутинных сценариев - придумал, автоматизировал (если с самого начала, то есть без авралов - “как документацию”, то есть как чистый читабельный и DRY код), забыл (до следующего падения теста), и готов к дальнейшему полету фантазии:) Те тестировщики которые занимаются програмированием и используют его на практике (во время тестирования а не во время рутинного бездумного автоматизирования мануальных тест кейсов), более точные и структурные. Они меньше пропускают багов, потому что сам процес програмирования приучает к системности и структурности. Именно поэтому я не понимаю мануальщиков которые не учат и не используют автоматизацию. Для мене это значит, что они не хотят лучше делать свою работу.

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

С моей точки зрения нужны. Причин много, контр-причин не вижу.

Количество 10K, т.е. для наглядности, 10 000 тестов – мне лично ни о чем не говорит. Моя практика показывает, что огромное количество тестов равносильно их отсутствию, потому что «это месиво» не осилить.

Другое дело, если из этих 10 000 есть 200 первоприоритетных (если на проекте ведется пиритизация тестов). Тогда можно взять каждый по отдельности, прочитать, выяснить, почему его считают первоприоритетным. Я уверен, что автоматизатору необходимо пару месяцев на то, чтобы вначале ознакомится с продуктом, исследовать продукт, исследовать серьезные баги в баг-трекере, побыть тем самым мануальным тестировщиком, чтобы понять, как это работает изнутри.

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

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

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

Но, в большинстве случаев – все очень далеко от описанного выше.

И да, я не говорю, что если все не так – то от автоматизации следует отказаться. Просто, риск провала – очень велик, но не 100%. И даже в случае провала – можно вынести ценный опыт, и начать заново (на этом или другом проекте).

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

Я предлагаю обсудить пример, как мы понимаем сценарии. Тут я привожу пример детального сценария и хочу спросить, как бы он выглядел на вашем проекте? Может быть, мы понимаем под мануальными сценариями – разные вещи.

Зайти в лес  с лукошком 
Проверить, что в лесу есть деревья, среди них: Яблоня, дуб, груша
Зайти в лукошко
Проверить: кнопка  «Оформить заказ» в лукошке должна быть недоступна
Подойти к яблоне
Проверить, что на яблоне растут яблоки
Нажать на кнопку «Добавить» возле яблока
Зайти в лукошко
Проверить, что в лукошке одно яблоко
Нажать на кнопку “Добавить” возле яблока
Проверить: кнопка  «Оформить заказ» в лукошке должна быть недоступна
Выйти из лукошка
Подойти к дубу. Нажать на кнопку Add возле неизвестного гриба
Проверить сообщение: «Неизвестный гриб не может быть добавлен лукошко»
Зайти в лукошко
Убедится что в нем нет грибов
Выйти из леса

Конечно есть, и по областям разделение, и по фичам, и по приоритетам (smoke, bat, extended, regression). Так должна ли быть связь? Как без нее планировать, считать метрики?

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

Нету столько времени, есть неделя что бы составить долгосрочный план, и есть две недели, что бы показать заказчику, что план работает и через месяц на проекте будет daily build smoke test.

[quote=“dzhariy, post:10, topic:3453”]
Я предлагаю обсудить пример, как мы понимаем сценарии.
[/quote]Под сценарием я понимаю набор тест-кейсов
Comment | #TC | #REQ | Step | Expected Result | Actual Result

Ваш вариант на эту таблицу так просто не ложится.

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

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

На практике так и получается, что иногда несколько проверок целесообразнее объединить в один кейс. А иногда, мануальный кейс заавтоматизировать в полной мере – невозможно (или очень трудоемко). Тут главное, чтобы команда понимала все возможности и ограничения. Мануальные сценарии всегда можно использовать как идею для автоматизации, но они всегда будут рассинхронизированы с автоматизацией. Именно поэтому, я и предлагаю, чтобы авто-тесты сами генерировали мануальные тесты в принятом на проекте формате, для того, чтобы было видно что же действительно делает автоматизация.

Поделитесь пожалуйста списком причин…

А я поделись списком контр. Хотя не все они и “контр”… Так, мысли на тему одним словом)

  • Бывает тесты не достаточно детальные чтобы их можно было бы “в тупую” автоматизировать
  • например, если очень сжаты сроки, и довольно большой проект. В бой идут Иследовательское тестирование с документацией “сценариев” в виде “функциональных карт” и чеклистов… Последние - нужны однозначно и без них никак… И здесь “связь” будет проявляться как минимум в проставлении галочек “автоматизировано”… Но сами по себе - не послужат готовыми “степами” для автоматизации. Вспоминаю Димын пример с лесом, лукошками и яблоками - вот как раз такого типа тесты у меня на проекте - это среди тех, которые “не чеклисты”, типа “детализированые” - и такой детализации мне иногда не хватает. Много времени уходит на то чтобы понять “как тут идентифицировать деревья - по плодам, или по форме листьев?”. А бывает еще хуже, в степе написано - “Проверить что есть плодовые деревья” :smile: Дима, ты извини вдруг что, я уверен что у тебя в примере имеются ввиду как раз те яблони которые только одним способом идентифицируются))) Я просто как примером воспользовался)))
  • Допустим есть время на написания детальных “сценариев для автоматизации”. Вопрос - кому их писать? Дело в том, что в силу того, что часто автоматизация может быть не очевидной, или иметь свои особенности и нюансы в силу имплементации самого продукта - намного проще будет обдумать и написать сценарий сразу автоматизатору, потому как одну работу может прийдется делать дважды) Ведь, мануальщик может что то “не учесть”.
  • Вопрос теперь в том где хранить этот “сценарий”. Как по мне - при хорошо и понятно написаном коде - достаточно хранить его только в виде кода, и обозначить “автоматизированось” функционала на функциональной карте. Те моменты которые автоматизировать не удалось - можно добавить в базу мануальных тест кейсов - если это нужно и важно, или оставить в виде чеклистов - все зависит от сложности как функционала, так и проекта в целом на всех уровнях…

Знаете, ребята, мне кажеться что у нас немножко не правильный подход вести дискусии) Особенно учитывая то что мы на форуме))) У меня складывается впечатление, что мы сидим каждый в своем болоте и начинаем расказывать другим - что надо делать вот так то (а решили мы так потому что у себя мы так работаем)… И я сам так кричал не один раз…
Может сменим немножко акценты? Будем делиться мыслями в стиле

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

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

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

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

Потом, я подумал о важности этой проверки в контексте проекта, и понял, что сделал правильно.
А к вопросу, как отличить яблоню от груши, я часто пользуюсь доступом в базе данных. Тут следует переспросить у разработчика, где они хранят внутренний ID элемента (это может быть внутри HTML или в URL страницы, иногда бывает и в глубинах JavaScript кода, к которому тоже можно получить доступ из Вебдрайвера). Эту информацию я использую для формирования SQL запросов к базе.

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

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

  1. Позволяет быстрее вникнуть в приложение.
  2. Увеличивает степень “абстракции” автоматизатора: больше концентрируемся на написании скриптов, а не на изучении приложения.
  3. Оценить степень [сложности|автоматизируемости] [области|уровня тестирования].
  4. Получать количественные метрики - сколько уже автоматизировано, сколько осталось, за какое время будет сделано и т.д.
  5. В случае [не валидного|фейла] тест-кейса привлечь ответственного за него мануальщика. Ему будет в разы легче разобраться в причинах, если авто-тест основан на его тест-кейсе. На текущем проекте мануальщики самостоятельно запускают тесты и анализируют результаты.
  6. Упрощает взаимодействие между auto и manual qa. Например: мы выпустили патч, нужно запустить тесты по X фиче в Y области.

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

На небольших проектах, либо в командах, где каждый может быть и автоматизатором и мануальщиком и девом, возможны любые ротации и схемы при достойном качестве продукта, особенно если автоматизация присутствует на проекте “с рождения”. Но, увы, я в таких не работал: подавляющее большинство qa - это гуманитарии со всеми вытекающими, а девов заставить присвоить “вменяемый” id контролу можно только через баг трекер. А вот более сложные схемы автоматизации видел.