Роль Automation QA в гибких методологиях

управление
#21

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

Также не во всех фирмах есть нормальная аналитика и нормальные ТЗ.

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

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

#22

Могу еще добавить, особенно в случае тестирования API есть смысл тестировать только авто-тестами. То есть сразу писать код/скрипт/feature file который и будет тестировать функционал API, а не играться сначала вручную, а затем, как часто бывает, если есть время - автоматизировать. Конечно, нужен качественный и легко поддерживаемый фреймворк.

1 лайк
#23

Во истину - пчёлы против мёда :smiley:

3 лайка
#24

Тогда отличный вариант - язык Gherkin.
Который по сути заменит тест-кейсы.

#25

Да ну, ей богу, вчерашний день прям какой-то :slight_smile:

У этого подхода столько слабых мест и данный подход не дает развиваться новому поколению автомтаизаторов… Набирают 4 человека мидл автоматизаторов и 5 мануальных. Мануальщики кейсы фигачят, а те автотесты пишут… (это если мы говорим о таком подходе, когда по кейсам автотесты пишут ребята)…

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

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

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

Думаю везде все очень по разному, но предполагаю, что данный подход тоже найдет свое место в IT-мире… :slight_smile:

#26

Не совсем. Gherkin - это язык BDD. Да, BDD может существенно облегчить написание тест-кейсов, но это далеко еще не сами тест-кейсы. У нас BDD использовали бизнес-аналитики для написания своих историй, на базе которых разработчики создавали прототип, а “сценаристы” из QA писали тест-кейсы на строго формализованом языке (в какой-то степени это можно назвать псевдокодом). Когда прототип становился частью программы, автоматизаторы уже получали четкий, однозначный план, по которому писался собственно код внутри фреймворка тестирования.

#27

Я соглашусь, что при определенных условиях такой подход будет отлично работать :slight_smile:

#28

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

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

Было бы здорово посмотреть на что-то подобное в больших компания, таких как GlobalLogic, Epam, но наверное на такую аферу не пойдет заказчик и не смогут ему обьяснить, что по тем или иным причинам можно отказаться от документирования тестирования (тест-кейсов), оставив только хорошие чек-листы :slight_smile:

Да и сколько это по цене выходит:

  • 3 мидла автоматизатора
  • 4 мидла мануальных
  • разрабы

или

  • 1 мидл автоматизатор
  • 5 или 6 мидла мануальных развивающихся в автоматизации
  • разрабы

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

А сзади синьор автоматизатор хвосты подтягивает, конспектирует себе, что обсудить с тем или иным тестировщиком надо, указать на плохой код, попытаться заставить юзать ООП, а не быдлокодить… Ну и конечно главное составляющее - это хороший и качественный фреймворк в основе, в котором можно переиспользовать клики и прочую лабуду или тесты для API…

Если говорить об API уровне из пирамиды, то в таком подходе можно генерировать разного рода тесты побыстрому на базе уже написанных: с кучай данных для нагрузочного и прочих вещей…

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

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

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

Если в один прикрасный день все разбегуться, то придется взять только одного мидла или синьора автоматизатора, и несколько мидлов мануальных, и снова отправить их на курсы… Что значительно проще, чем искать при памяти 3-4-ех мидлов автоматизаторов…

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

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

#29

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

#30

Вам досталась роскошь… Конечно так идеально в спринты попадать :slight_smile: Каждый проанализировал требования, каждый сделал свой кусок работы и передал его следующим ребятам, а следующие уже подправили согласно реалиям проекта…

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

Предположу, что скорей всего митинги были между:

  • мануальщик + тест-кейс-команда
  • тест-кейс-команда + разработчики

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

#31

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

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

#32

да конечно, все это есть, но все же наверное от этого стоит как-то отходить :slight_smile:

Возможно конечно я размышляю о какой-то утопии, но возможно, такой бы подход проканал во многих компаниях…

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

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

А автотест будет прогонять подобное из раза в раз, и поддерживать этот автотест будут заставлять упавшие репорты, после автотеста…

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

#33

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

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

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

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

#34

В текущих реалиях нынешней работы я не могу не согласиться, что API тесты для веб проекта являются в пирамиде, пожалуй, самым важным звеном. Требования к API и автоматизация его тестирования позволяют всем эндпоинт разработчикам, будь то мобильные приложения или веб клиент в браузере - получать стабильный код, с которым можно работать. Но это если думать в разрезе программы. В разрезе продукта важно иметь чеклисты, которые помогут регрессионно выполнять тестирование. И вот тут возникает момент, когда а) регрессия не требует ежедневного выполнения, т.к. процесс построен так, что каждая отдельно взятая фича тестируется и моментально улетает в продакшн (8-10 фич в день для проекта, в котором заняты 10-12человек), б) регрессия от этого собственно не уменьшается, и раз в обозначенный период чеклисты нужно обновлять. В реалиях такого пофичного релиза, coverage api 95%+ я считаю, что регрессию продукта (читай, UI тесты) переводить в полностью автоматический вид с ручного - зачастую утопия. Куда важнее подумать над процессом быстрого, надежного, безопасного деплоя, сокращения времени на ошибки в репродьюсе багов и вообще devops составляющую: среды тестовые и боевые. В этом случае автотестам я бы выделил роль проверки базовой функциональности на бою, как единственному гаранту доказать product value без положения “наши тестовые среды на 99% соответствуют реальным”.

1 лайк
#35

Правильно сомневаетесь ). HP ALM - наверное крутая штука, которую мы готовить не умеем, но по мне - очень неудобная система. Связка Jira + Testrail получше будет.