Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Как организовать автоматическое тестирование

management
Теги: #<Tag:0x00007fedbfdf98c8>

(toyen) #1

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

Буду рада всем идеям. Может кто-то сталкивался с подобной ситуацией?

 


Внедрение автоматизации для Web в команду
(Mykhailo Poliarush) #2

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

значит, надо рассматривать не только себя, как автоматизатора, а и разработчиков

как ваш ПМ и разработчики относятся к тому, что помогать выполнять автоматизацию для проекта?

 

тут есть большая проблема в том, что вы и наверное остальные в команде думают, что это только ваша ответственность

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

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

 

если процесс разработки автоматических тестов будет общей ответственностью и частью процесса

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

то вопросов, как и когда, делать автоматизацию не будет возникать

 

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

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


(apetrovskiy) #3

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

 

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


(ArtemIljin) #4

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


(toyen) #5

1.  "как ваш ПМ и разработчики относятся к тому, что помогать выполнять автоматизацию для проекта?" - на это нету времени у разработчиков.

2. "тут есть большая проблема в том, что вы и наверное остальные в команде думают, что это только ваша ответственность" - так и есть.

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

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


(toyen) #6

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

2. "Я бы выкинул "написание тест-кейсов". - я использую написание тест-кейсов для трудного функионала, в котором очень легко запутатся. И что-бы как-то систематизировать работу


(toyen) #7

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

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


(Mykhailo Poliarush) #8

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

так как тестировщик один на проекте


(Mykhailo Poliarush) #9

а что означает, "когда разработчики смогут увидеть?"

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

а автоматизация лишь способо достичь этой цели

 

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

и не только вы а и вся команда должна это понимать,

если команда понимает "почему? и зачем?", то не надо будет разработчикам доказывать пользу от этого,

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


(Mykhailo Poliarush) #10

ну тогда, давайте подумаем что мы можем сделать:

1. сократить количесво тестирования, которые вы делаете (например, на основании рисков) и это время тратить на автоматизацию

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

3. переработка. Тратить свое личное время. "как только команда увидить пользу" вы сможете просить офиц. выделенное время

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

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

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

что еще?!


(Mykhailo Poliarush) #11

а на счет биллинга активности по автоматизации - это отдельная тема

ваша задача, чтобы команда и ПМ понимали, что это необходимость (если она есть)

а дальше если ПМ понимает это, то он сам сможет это продать под каким-то соусом вашему клиенту


(Sergey Korol) #12

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

Могу лишь предложить посмотреть интересное видео в тему: http://vimeo.com/41524702.

Серебряная пуля автоматизированного тестирования (SQADays-11) from Stas Fomin on Vimeo.


(apetrovskiy) #13

да это вообще современная тенденция - создавать тест-кейсы или из кода, или автоматически.

Coded UI генерит тест-кейсы (видел на видео, у меня пока нет новой студии, а старый Coded UI падает на 8 :))

тесткомплит тоже генерит лог (клик туда, клик сюда - микро-тест-кейсы)

даже для селениума я видел ролик про плагин, который генерит подобный лог с кликами и пр.

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

 

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

Юзер логинится, логинится, логинится ... правильно, неправильно, с неправильными символами, с пустым именем, с инжекцией :), копи-пейстом - это всё шелуха, надо вывести наружу один или несколько результатов:

"нормальный логин" - OK

"невалидный логин" - OK

"бэйсик аутентикейшн" - OK


(apetrovskiy) #14

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

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


(toyen) #15

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


(toyen) #16

Спасибо, это интересно. Думаю, будет полезно


(toyen) #17

всем спасибо за помощь


(Mykhailo Poliarush) #18

отпишитесь, что собираетесь делать

ну и дальнейние развитие событий

интересно! :)


(ArtemIljin) #19

Параллельно с автоматизацией рутины, старайтесь выделить регрессию. Придётся прокачивать аналитические скилы, тратить время. Но всё это пойдёт в + вам в карму! :)


(toyen) #20

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