testomat.io управление авто тестамиОпишите , пожалуйста, как в идеальном мире должна строиться работа Automation QA - при разработке через Agile (Scrum/Kanban ) .
P.S.
Двухнедельные спринты. Небольшая команда.
Не смотрел со стороны руководства, но со стороны работника почему-то всегда казались эти “срамы” какой-то фигней. Возможно, я просто не понимаю ту проблематику, которую призваны решать с помощью данной методологии. Скорее всего она из области “руководитель прямиком из 19 века управляет ИТ-компанией как швейной фабрикой”. И для перевоспитания таких руководящих личностей и требуются какие-то методологии и обучающие выездные семинары, скрам мастера, тренера и т.д.
Из всех методологий более-менее понравился канбан. Да и тот, наверно, у нас (там где он бывал) проходил в извращенной форме и мы его даже не осознавали (может это и не канбан был вовсе). Просто работали над задачей до завершения. Без сроков. Задача сделана. Идем к следующей. Но может это нам просто так повезло тогда. Да и руководство было подковано в вопросах разработки.
Нет, какие-то сроки конечно были, но не как во многих других местах, где задачи прилетают непонятно откуда и все с грифом “Срочно! Сделать вчера!”. Как-то так.
Есть к примеру решение строить разработку по гибким методологиям - “видимый результат” каждый спринт и контроль ситуации - из-за митингов.
Для dev команды все ясно.
Но как построить automation процесс - так что бы идти с командой в ногу. Если это возможно .
Когда начался спринт - что правильно делать? Писать документацию? Писать BDD (TDD) тесты ?
ну у нас примерно так и было, новый спринт, строишь примерный тест план (для себя), что должно быть протестировано, затем накидываешь BDD (в бехате я делал) ну и потом когда уже разработчики чтото блее менее работающее собрали, пишешь тесты на свой BDD. И паралельно с этим тестишь мануально всё что готово (вёрстка или какието функции отдельные)
1 лайк
это же все зависит от команды 
К примеру, если в команде есть:
- мануальные тестировщики
- разработчики
- автомтаизаторы
тогда пока пилят фичу, к ней готовятся мануальные тестировщики, уточняют требования, возможно пишут кейсы, потом тестируют ручками (допиливают свои тест-кейсы). А уже после, когда фича готова, и кейсы на фичу готовы - автоматизаторы допиливают свой фреймворк (если надо) и пишут тесты по кейсам мануальных тестировщиков… Вроде так как-то.
Если тестировщик в команде мануальный и он же пишет тесты, тогда все становится куда сложнее, ему надо протестировать, написать (или не писать кейсы) и потом на эту фичу нафигачить еще автотестов GUI или API.
Вот из-за этого походу BDD тесты и появились. Мол есть мануальные тестировщики, которые могут даже не знать языка программирования, смогут генерировать тесты, и один человек, который ответственный за фреймворк…
Скрам - это же фреймворк, дали кучу вещей, которые можно юзать, кто-то из них взял самые необходимые, пример: спринты, ретроспиктивы, скрам-митинги и прочее и используют, могут и переиспользовать… Поэтому ко всем приходит скрам со своей интерпиртацией. Так как это фреймворк, а не методология…
Прикольная кстати штука, но зачастую, у скрама есть один большой минус - в неумелых руках весь процесс базируется не на качестве продукта, а на количестве фич и закрытых вовремя спринтов…
1 лайк
наверное BDD - это самое ОНО для таких ситуаций ) а вообще - критерий что один автоматизатор и n<5 девелоперов (мануальных нету ).
Есть жесткие критерии - это скрам . Вот интересно - каково правильно это все сочетать ) что бы не выпадать с общей команды и показывать результат равномерно по спринту.
P.S. Наверное еще можно вначале мокать - писать тесты - а потом просто переносить все на реальный енв.
Ну во первых, надо сделать как-то так, чтобы фреймворк был очень грамотным, и в нем можно было переиспользовать код, чтобы написание тестов сводилось к минимальной затрате по времени. Наверное это самое главное, и еще один главный момент - это выделять в спринте время на юнит тесты разработчику и на автотесты - автоматизатору. Если заказчик или PM, кто там у вас, выделит на это время спринта. Тогда с подобной проблемой может и не столкнетесь…
Остальное уже по ходу дела. По сути, ваши автоматизаторы ведь не напишут автотесты без грамотных тест-кейсов… А грамотные тест-кейсы не напишутся сами, пока не протестируется фича вручную, и не изменяться сами кейсы. Следовательно сначала кейсы и тестирование, а после уже автоматизация…
Если же сам мануальный тестировщик сам и тестирует мануально и пишет автоматизацию, тогда на кейсы (ИМХО), можно подзабыть, но думаю такое вам не позволят… Скажут - “как же это без кейсов, где же такое видано, а если новый кто-то придет, а если кто-то забудет что-то где-то”…
Если заказчик хочет тесты + кейсы + автоматизацию, значит он должен выделить на это время (деньги), следовательно, если будет время, то и в спринты сможете вкладываться…
У нас проект не большой. Мобильная прилага для iOS и Android. Работаем по Scrumban’у. Один маниуальщик, один автоматизатор, 4 девелопера. Тесты пишутся до начала разработки какой нибудь фичи, на этапе уточнения акцептанс критерий. Когда девелоперы берут стори в разработку, то видят, что будет тестироваться. Это помогает и понять, что надо, и писать юнит тесты (потому что видят, что для тестирования важно). Когда все запилино, я начинаю автоматизировать тесты к сторе. Иногда даже получается приступить, пока девелоперы еще не закончили (например пока они пилят юнит тесты). По идее мануальщик после меня даже не трогает то, что уже автоматизировано, тестит только оставшееся. Но в реальности по новым фичам все таки пробегается, причем приступает тоже примерно вместе со мной. На выходе, при мерже в мастер - сторя (новая фича) полностью покрытая тестами на всех уровнях, а значит тесты всегда актуальны и релизится можем сразу.
Конечно, у веба могут быть немного другие реалии, но уверен, что при правильном балансе разработчиков, мануальщиков (практически BA в данном подходе) и автоматизоторов (чтоб не сильно задерживать стори при автоматизации) такой подход идеален. Подход, когда разработали, потестили, слили в мастер, потом автоматизировали, имеет много неудобств. Но все конечно зависит от проекта.
Ну если речь идет об идеальном мире и месте UI автоматизации в нем, то тогда вам там будет нечего делать на позиции Auto QA, ибо в идеальном мире разработчики сами и пишут автотесты.
Но т.к. мы живем в далеко неидеальном мире, при относительно вменяемом скраме, велика вероятность того, что ваша автоматизация будет всегда отставать минимум на 1 спринт, пока работа над какой-либо фичей не будет завершена.
При наличии неплохого бекграунда и опыта, в целом, поначалу будет весьма легко, даже не смотря на то, что вы скорее всего будете единственным автоматизатором в скрам-тиме. По мере расширения функционала, вы начнете осознавать, что пары рук вам все же не хватает. Особенно если приходится выполнять функции не только QA, но и DevOps в одном флаконе.
Ключевым фактором здесь все же является ваш скилл. Вы должны быть хорошо подкованным в теории тестирования, программировании, специализированных тулах, системном администрировании. Скрам в целом подразумевает, что команда - самодостаточная. Никто не будет бегать над вами и говорить, что делать, а потому у джунов в одиночку тут не будет шансов. Только под хорошим менторством.
В глобальном масштабе вашей основной задачей будет являться предоставление быстрого фидбека команде о текущем состоянии разрабатываемого продукта. Наряду с ручными тестировщиками, за вами будет всегда последнее слово относительно промоута / релиза билдов, т.к. только вы сможете предоставить объективную оценку качества ПО.
Локальных задач будет весьма много: написание / саппорт тестов, анализ результатов / баг репортинг, поддержка фреймворка (если свой) / automation инфраструктуры, code review, документирование используемых решений, активный collaboration c членами команды для решения ежедневных проблем / вопросов, ведение automation метрик, участие в спринт ревью, планировании, рефайнментах, ретроспективах, дейли стендапах и т.п.
Умение справляться с таким объемом задач во много зависит от ваших скиллов и опыта. Именно поэтому в скрам тимы обычно набирают middle+ level, но все же больше склоняются к senior+. Автоматизаторов с небольшим опытом как правило берут либо от безысходности, либо в целях экономии средств в ущерб качеству, либо в паре с кем-то более опытным.
Но опять-таки, все это о более или менее вменяемых процессах. Скрам скраму - рознь. И если честно, я встречал единицы проектов, где бы работали “по учебникам”. Чаще всего можно встретить команды, у которых от скрама только стендапы присутствуют; где AQA-инженеры занимаются автоматизацией ради автоматизации, а заказчики даже не понимают, зачем она им нужна. Так что в данном вопросе все очень условно.
1 лайк
Ну все же есть какой-то наиболее удобный, из опыта, паттерн, по внедернию автоматизации в спринты, когда:
- двухнедельные спринты
- разработчики не пишут автотесты
- небольшая команда
- тестировщик тестирует вручную и пишет автотесты
- в проекте используются (тест-кейсы или чек-листы) или в проекте не используются (тест-кейсы или чек-листы)
Совсем идеальный скрам - это когда все члены команды могут переключаться с роли на роль. Иначе говоря, все - разработчики, и они же под конец спринта пишут тесты, поэтому никто не простаивает.
Но обычно так не бывает.
Вот близкий к идеальному случай, но из жизни, сам видел и участвовал:
- К началу спринта есть требования и акцептанс-критерии (пишет аналитик или тим-лид, общающийся с заказчиком).
- Читаем требования все вместе и пишем BDD, только это надо делать быстро.
- Разработчики тем временем что-то начали писать. Пусть даже не совпадает с BDD, но в целом правильно.
- Делим BDD на ручные и автоматизируемые кейсы.
- Разработчики тем временем читают BDD, понимают свои ошибки или наоборот, нам говорят, что поправить, и что будет работать не так.
- Всё отлично, BDD согласовали, разработчики с головой в разработке, мануальщики дизайнят более детальные кейсы, а автоматизаторы занимаются отладкой (о чем ниже). Одновременно помогают мануальщикам описывать кейсы под автоматизацию так, чтобы шаги нормально интерпретировались фреймворком.
- Пишутся заглушки под новые тестовые шаги. То, что уже понятно, автоматизируется полностью.
- По окончании спринта разработчики сдают работу по акцептансам. (Тестирование отстает! Иначе нельзя всерьез протестировать!)
- Начинается следующий спринт, снова участвуем в написании новых BDD и планировании!
- Ну, а теперь можем дописать автоматизацию на то, что было непонятно, как делать в предыдущем спринте, и всё это отладить.
- Отладка идет в параллели с написанием заглушек и тестов на текущий спринт.
- К концу спринта мы имеем автотесты на предыдущий спринт, которые проходят (или не проходят из-за багов в продукте). Спокойно можно добавлять их в регрессию.
а после пятого спринта автотесты на какой по счету из спринтов - уже реализованы? Из практики
Зависит от того, какой это тестировщик по профилю - manual или automation.
Все равно все очень условно, и зависит от скилла всей команды, а не одного человека. Если UI-щики дико говнокодят и не особо идут на контакт, то ваша автоматизация будет построена из целого “лего” костылей, что будет максимально афектить ваш workload.
Если у вас не хватает скилла в программировании, тот же самый “костыль-фреймворк” будет подставлять вам подножки каждый божий день.
Если заказчик не понимает, зачем нужна UI автоматизация, то вместо реально необходимых e2e сценариев, вы будете проверять какой-нибудь usability, подсвечивать элементы во время выполнения, останавливать тесты, ожидая user input и т.п. - т.е. делать ровно то, что не представляет абсолютно никакого business value.
В принципе, о любой роли можно нечто подобное написать, но факт остается фактом. Работая по скраму, вся команда должна понимать что они делают, зачем они это делают, и как все это сделать наиболее эффективно. И если хотя бы одно звено регулярно выпадает, весь механизм может вскоре накрыться.
2 лайка
Грубо, 80% из написанного ранее работает, что-то нужно выкинуть и переделать, т.к. приложение поменялось.
Фишка в том, что приложение меняется не само по себе, а в рамках спринта, и переделка старых тестов относится к задаче на новый спринт, так что всё получается синхронно.
А если не успеваете - одно из двух: или планирование неадекватное, или кому-то лень поднапрячься
Разработчики тоже не боги, они не могут что-то писать и менять слишком быстро, поэтому при правильно подобранном количестве автоматизаторов всё получается.
2 лайка
При такой методике разработки - “гибкой” методике - автоматизаторы вступаю поздно, практически к началу второго спринта.
В основном они занимаются регресс тестами. На готовые фичи пишут автотесты и гоняют их каждый день.
Видел проекты где ведутся эти самые тест-кейсы и сам их множество написал, но так и не осознал для себя сколько-нибудь большой ценности в них. По мне так это деньги на ветер. Чек-листы и матрицы состояний - наше всё. Этого хватит с головой и избавит от лишней бюрократии и волокиты. Да и при регрессе удобнее в распечатанной таблице карандашом галочки ставить. Вместо этого заводят кучу подробных ненужных тест-кейсов, которые устаревают через полгода, а времени и сил на поддержку всего этого “богатства” у вас не остается, т.к. нужно и новые вещи выпускать и патчи и т.д.
Самый сок это было готовить тесты для “автоматизации”. За время пока я ручной тест разукрашивал и подробности в него всякие вносил и проверял, что нигде не ошибся в описании и потом еще объяснял автоматизатору, что и где и как он понял не так, так вот за это время я успевал сам сделать несколько автотестов.
BDD - отличная штука. Но вот когда нужно что-то более серьезное тестировать, то не всегда понятно как её применять. Особенно, когда есть какой-то функционал из 20-30 бизнес-требований, у которых от 2 до 10 состояний. Все это дает несколько десятков миллиардов комбинаций тестовых случаев. Как тут BDD нам поможет? Или когда нужно сложную математику задействовать. В BDD это непонятно как запихивать. Да, даже тот же игропром. Вот не понимаю, как они там успевают тестировать. Я в этой области не работал, но мне кажется почему-то что там не балуются кейсами. Слишком уж затратное это дело, да и цена ошибки не столь фатальна.
Ну на самом то деле, я против тест-кейсов Как по мне то лучше пусть тестировщик автотесты пишет (API, UI), чем кейсы Как не крути, но мне кажется каждый тестировщик мануальный должен уметь автоматизировать и писать те самые автотесты. Не очень мне нравится подход - сначала кейсы написать, а потом по ним автоматизацию писать… Да и ваще кейсы писать, толку от них только во время итерации и потом когда кто-то новый приходит, но по факту та, чтобы все это поддерживать, надо нереальное количество времени тратить…
Именно из-за вот этих всех прослоек и поисков точечных специалистов и получается, что автоматизация - дорого и долго. А на самом то деле, если есть грамотный фреймворк + человек, который отвечает за фреймворк, он же в курсе всего, и парочка мануальных тестировщиков, которые умеют писать автотесты и тогда все куда быстрее должно быть и проще…
Вот правильно сказал @ArtOfLife, каждый в команде должен все уметь и автотесты писать и тестировать… Тогда можно друг другу помогать…
1 лайк
Что-то вы напутали.
Даже если будут миллиарды комбинаций, самих обрабатываемых в ПО состояний будет гораздо меньше.
Тестировщик не должен гонять все миллиарды, надо анализировать тестовые случаи.
Вот у меня на работе процесс состоит из 12 шагов, на первом шаге заполняются 30 полей. Но на процесс влияют только 3-5 полей от силы. Их и проверяешь.
Вполне возможно, что я и напутал что-то. Я не исключаю мысль об ошибочности своих суждений и выводов, а также ошибках в своей работе. А вот на чем базируется ваша уверенность, что из 30 полей на результат влияют только 3-5? Зачем тогда эти другие поля?
Про состояния я имел ввиду именно, что маршруты кода, которые исполняются. По сути граф с множеством вершин, где они имеют множество путей. Например, для интернет-магазина это может быть состояния клиента: авторизован/неавторизован/авторизован через соц.сеть, оплата при получении/оплата картой/яндекс.деньгами и т.д., товар по промоакции/без промо, с доставкой/без доставки, доставка почтой/курьером и т.д. А вот перебирать все типы товаров и суммы тут действительно не имеет особого смысла, хотя и тут строго говоря эквивалентность их должна быть доказана, а не браться с потолка. Я то как раз прекрасно понимаю, что перебор всего и вся недостижим и тестирование - это всегда баланс между желаемым и достижимым. По сути у автоматизации главная проблема никогда не лежала в рамках самой разработки, а лежит в области аналитики и построения правильной тестовой модели.
Простите, что так резко написал, Михаил ))).
Насчет моей уверенности - я ведь имею доступ к исходному коду. Знаю спецификацию. Видел ТЗ ).
Влияющих полей и комбинации их, на самом деле немного.
Все маршруты прохождения заявки известны: входы и выходы. Граф не бесконечен.