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

Собственно говоря, сам смог придумать только следующий выход на текущий момент:

1. Выгрузить каждый Simple Controller из хранилища как Test Fragment.

2. Поместить их в одноименную папочку Action Storage =)

3. И в каждом конкретном тесте обращаться через Include controller к конкретному файлу хранилища.

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

А как у вас сделано?

Доброго дня всем!

Я как прилежный ученик начал создавать архитектуру тестов используя Parameterized Controller => Module Controller => Simple Controller, последний из которых находится в отдельной группе Action Storage, тем самым получив единое хранилище действий. С течением времени, объем этого хранилища да и само число тестов выросло до неудобного и возник вопрос разнесения их как-то друг от друга. Так вот, можно ли как-то вынести это хранилище отдельно от тестов и обращаться к нему через Include controller? Или это делается как-то по другому?

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

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

оуууу!! Шикарно! Спасибо, сработало!

Только что попробовал через  token=(\b\w{32}\b)

В дебагере ответ

http://regexr.com/3el1c

Доброго дня! Помогите, пожалуйста, разобраться и авторизоваться таки =)

Авторизация выглядит примерно след образом:

1. Отправляю логин, пароль пост запросом.

2. Сервак генерирует токен и переадресовывает на гет запрос авторизации с этим токеном (скрины 136 и 137).

И так как во всех дальнейших запросах используется этот самый гребанный токен, то мне необходимо его научиться вытаскивать. По советам в скайп-чате, для этого я использую Regular Expression Extractor таким вот образом заполненный (сам токен выделяю как-то так \b\w{32}\b) 

Но по факту этот самый токен не выделяется. Что я делаю не так?

Идеальный диалог!..

В целом картина получилась следующая:

Когда пришел, то процесс ставил как по учебнику: были смок тесты, были тесты для регресса, были тестовые сценарии полноценные и прочее. Но с течением времени, раб процесс показал, что все это только съедает время, причем в гигантских количествах, и не дает толком никакой ценности. Сейчас же, есть полный перечень функционала, разбитый на подфункции. Они же и являются ЧЛ высокого уровня. Когда разрабатывается новый функционал, то при проверки смотрится только этот новый функционал и взаимосвязанные вещи. Все остальное не смотрится практически вообще.

Благодаря такой "оптимизации" мы смогли проработать 2 года без увеличения штата и автотестов при постоянном росте проекта.

Сейчас же, если внедрить автоматизацию, то, да, будет постоянно висеть простынка о состоянии работоспособности ядра. И получается что данная информация будет даже более полезна разработке, чем нам. Нам же, в свою очередь, останется только смотреть на продукт со стороны интерфейса. Мне нравится эта перспектива! =)

Спасибо всем за умные мысли! Пойду теперь дальше на подумать

Подводя итог всему сказанному:

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

Если вам хочется ускорения процесса - озадачьтесь малой автоматизацией и инструментами

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

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

 

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

Эффективность считается исходя из того, какая цель и какой ценой достигается. Некоторые цели достигаются эффективнее ручным тестированием, некоторые автоматическим.

Спасибо большое за подитог! Пойду еще наподумать

 

 

Покажите, что и как вы выиграете от автоматизации

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

 

 

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

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

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

http://software-test...who-is-a-tester смотрел кто выступление Алексея? Меня очень зацепил этот доклад (особенно вторая его половина) и как-то он во-время оказался для меня.

И для себя я из него вынес две фундаментальные мысли:

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

2. Современная тенденция разработки направлена на ускорение внедрения функционала и получение фидбека о его качестве. В связи с чем и тестирование должно ускориться в разы.

И оба эти пункта без автоматизации не решить. По этому да, автоматизации быть =)
Осталось только понять какой и в какой степени...

 

 

От нас то вы чего хотите? 

Наверное хотел какого-то аргумента или пинка, что направил бы мои размышления в "нужное" русло =)

Что-то мне кажется что это на данном этапе будет тупиковый шаг, не? Скажет он, что да, документация на апи есть, поставить тесты будет не проблема, первые тесты будут через 3 месяца. Язык берите джава, ибо продукт написан на джава+JS. Достаточно будет одного архитектора и перевести пару ручных в подчинение к нему, что кодить умеют.

Но это же в целом не ответит на вопрос развивать процесс через ручное или через автотесты. Чего именно от консультанта в конечном итоге добиться то можно?

Доброго дня!

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

Так вот.

Дано: неограниченный бюджет и достаточно гигантский продукт.

Задача: выбрать по какому пути развиваться дальше.

https://bz.apache.or...ug.cgi?id=59386
Поставил ошибку в результате...

Да, предложенный вариант помогает, спасибо!

 

 

 

А серверную часть, нижний уровень, предполагается проверять также, вручную, или речь про автотесты? Или просмотр кода? Или про что?

Да любым из способов. Все же здесь от времени зависит, ведь так?

А если отойти от АПИ и брать БД ? С одной стороны вписывать какие-то значение руками в БД, а проверять только то, что можно сделать через пользовательский интерфейс, а с другой вписывать какие-то значения и смотреть как это отразится в интерфейсе. Можно ли это разделить на верхний и нижний уровни?

Доброго дня всем!

Возник тут вопрос, в ходе очередной дискуссии =)

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

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

Рассудите нас, пожалуйста, так кто же прав? =)
И как процесс тестирования в данном разрезе выглядит у вас?

В итоге я сбился полностью как лучше поступить =)

В итоге буду искать автоматизатора и просить пока выделить разработчика в помощь! =)

Фига какая тема...

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

Мой план действий был примерно таков:
1. Понять как общаются веб-клиент с сервером.

2. Попробовать упростить жизнь рекордером (как пример, Selenium IDE).

3. Понять что такое вообще автоматизация в масштабе (форум, статьи, доклады).

4. Начать изучать язык программирования (я брал Питон, по советам от сюда http://software-test...chshe-nachat-i/ ). Начал изучать с курсов на stepic.org, ибо бесплатные. Здесь все просто, главное не лениться =)

5. Потом записался на курс ПДТПитон у Баранцева. Дорогой собака, но вник что такое автоматизация, как разбивать архитектуру и в целом уже могу как тут выше писали, автоматизировать рутину при том грамотно.
6. Углубление в понятие "селениум". Попробовал углубитсья, записался на еще один курс от Баранцева (не помню как точно называется, чтото типа разработка тестов на Питон с селениум). По факту оказался курс сложным, не осилил =)
7. И вот сейчас планирую углубиться в автоматизацию не через веб-интерфейс (еще пока не нашел подходящий курс).

Как-то так.

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

 

 

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

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

В общем, всем спасибо за мнения! Если будут какие еще аргументы - велком =)

Похоже на то, что придется искать опытного, что бы он меня учил =)

Вот только по веремени это может же занять слишком много времени...

Автоматизировать нужно бекэнд через апи и ВС интерфейсы.

 

Доброго всем!

 

Возник принципиальный вопрос: искать до упора автоматизатора который полностью впишется в тематику проекта или расти своего? Подскажите у кого как по опыту было?

 

Есть человек, который будет обучать автотестера ?

 

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

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