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

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

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

Понять что автоматизированно а что нет поможет общение в команде

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

Спасибо :) Вопрос у меня не из разряда «что выбрать», а я хочу понять, как мир дошёл до жизни такой :) А почему у вас bdd не взлетело? И, так понимаю, есть наверняка какие-то фундаментальные отличия bdd от «классического фт», назову это безграмотно так

есть нет желания юзать бдд - TestRail, TestLink, TFS прекрасно справляются с задачей по определению заавтоматизированных тест кейсов

есть нет желания юзать бдд - TestRail, TestLink, TFS прекрасно справляются с задачей по определению заавтоматизированных тест кейсов

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

Некоторые вообще автотесты держат в отдельном репо от приложения

Некоторые вообще автотесты держат в отдельном репо от приложения

и чем это плохо?

Некоторые вообще автотесты держат в отдельном репо от приложения

и правильно делают?

я больше скажу, у меня несколько реп с автотестами)

Получается такая штука: 1) запилил фичу в приложении 2) написал тест-кейсы 3) автоматизировал тест-кейсы Получается 3 места, которые должны жить синхронно друг другу. А теперь представим, что над приложением работает 10-20 команд

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

разработчики тоже должны писать полностью рабочий код без багов, да?

но ведь в реальности это не_совсем_так

Получается такая штука: 1) запилил фичу в приложении 2) написал тест-кейсы 3) автоматизировал тест-кейсы Получается 3 места, которые должны жить синхронно друг другу. А теперь представим, что над приложением работает 10-20 команд

неправильный подход) подход должен быть в порядке 2) 3) 1)

Получается такая штука: 1) запилил фичу в приложении 2) написал тест-кейсы 3) автоматизировал тест-кейсы Получается 3 места, которые должны жить синхронно друг другу. А теперь представим, что над приложением работает 10-20 команд

и да, 10-20 команд пилят вот прямо одно и то же место, прямо одну и ту же строчку и потом мерж конфликты правят? так?)

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

разработчики тоже должны писать полностью рабочий код без багов, да?

Не очень понял сравнение

и да, 10-20 команд пилят вот прямо одно и то же место, прямо одну и ту же строчку и потом мерж конфликты правят? так?)

Конечно же нет

неправильный подход) подход должен быть в порядке 2) 3) 1)

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

Не очень понял сравнение

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

Некоторые вообще автотесты держат в отдельном репо от приложения

А у некоторых приложение - это несколько репо, для каждого из которых еще отдельные репы с тестами.

И ничо, полет нормальный.

и сабмодули в репах)

Спасибо :) Вопрос у меня не из разряда «что выбрать», а я хочу понять, как мир дошёл до жизни такой :) А почему у вас bdd не взлетело? И, так понимаю, есть наверняка какие-то фундаментальные отличия bdd от «классического фт», назову это безграмотно так

не взлетело, потому что, опять же на мой взгляд : 1. Не все понимали что нужно в тесты помещать, а что - нет. В результате в тесты помещали все подряд user-стори и тесты разростались, становились более чувствительными к изменениям, при это покрывали не весь функционал "поверхностно", а только частный, но зато "глубоко". 2. Возникли трудности с огранизацией процесса актуализации тестов: не всегда у тестировщика есть время на отладку и правку тестов до релиза функционала. Тестировщик находится, обычно, на одном из последних этапов жизненного цикла фичи и получает фичу в тестирование за малые сроки до релиза. Хорошо если в это время удастя полное тестирование вложить. Написание end-to-end тестов вложить в такое время сложнее. Т.е. в результате: новые фичи выезжали без покрытия тестами в прод, а тут уже bdd говорить не приходится 3. Банальное не умение и не желание учится кодить: то есть АТ живут на нескольких энтузиастах, кто умеет кодить и поддерживает тесты. А кто-то их даже не всегда запускает перед релизом - это тоже к проблеме процессов скорее, что не обязательно запустить этот прогон. Собственно корень проблемы 3 в том, что тесты гоняются долго, и на коротком тестовом промежутке не всегда есть время прогнать тесты и оценить их результаты, а тем более исправить. Плюс, в нашем случае, данный подход плохо решал задачу ведения документации, потому что АТ реализовывались либо с запозданием, либо не реализовывались вообще. В результате получилось что АТ ради АТ, которые живут на нескольких энтузиастах.

Так может оно вам было и не нужно?

Всем доброго дня) Есть ли аналоги AntEater для манки тестинга на iOS? Нужно прокликать все экраны с целью найти проблемные и зафиксировать вылет, если все плохо

Всем Привет) можете посоветовать курсы по написанию интеграционных тестов на c#? только недавно начала писать их, не до конца понимаю логику написания. Заранее спасибо!

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

Приходила, но до реализации пока не дошло. Т.к. есть TMS, к которой как бы привыкли, но по сути она не нужна, если все тесты гоняются автоматически. В таком случае она становится лишним звеном, которое требует синхронизации с кодом тестов. Если же ручные тесты всё же есть и они нужны, то может TMS - это и не плохо, если не сильно мешает. Хранение сценариев в коде удобнее с точки зрения актуализации, но нужно при этом правильно делать. Не хранить сценарий как docstring, например, а делать Steps, которыми оперируют тесты и по которым генерится документация (тестовые сценарии). Это не BDD, не надо путать. И не надо для этого использовать BDD-фреймворки. А вот Allure как раз для этого должен подойти. Но опять же. Это если с нуля делать. А если легаси, то там может такой переход быть очень непростым. Поэтому проще потерпеть TMS :)

подскажите кто рабоатет с селениумом что значит вот эта ошибка: WebDriverError: no such session?

подскажите кто рабоатет с селениумом что значит вот эта ошибка: WebDriverError: no such session?

на хроме запускаешь?

на хроме запускаешь?

да на хроме только через node js

а ОС какая?

а ОС какая?

ubuntu 16.04

https://stackoverflow.com/questions/43165844/selenium-no-such-session-error-in-chromedriver

может поможет то что под -UPDATE--

если нет еще можно глянуть правильно ли вызывается ChromeDriver.Close()

если нет еще можно глянуть правильно ли вызывается ChromeDriver.Close()

я его всегда закрываю

@RichardGears

ВЖУХ!

если нет еще можно глянуть правильно ли вызывается ChromeDriver.Close()

не помогло мне это нифига

“proposals”: [],

Вжух?

А testlink кто-нибудь использует?

+

Умер Джерри Вайнберг, дедушка современного тестирования https://en.m.wikipedia.org/wiki/Gerald_Weinberg ?

Всем доброго дня) Есть ли аналоги AntEater для манки тестинга на iOS? Нужно прокликать все экраны с целью найти проблемные и зафиксировать вылет, если все плохо

https://github.com/zalando/SwiftMonkey

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

Всем привет! Подскажите, пожалуйста, нужно провести перфоменс тестирование сервиса, в котором обязательная регистрация, кто-то знает какими инструментами это можно проверить?

jmeter, gatling

пробовал, но там походу нельзя этого сделать, если сразу форма регистрации

или может я не знаю как это делать)

в чем проблема? почему нельзя?

Сделать можно все) вам надо повторить все запросы регистрации с сохранением всех возвращаемых данных. Куках, сессии итд

ну, походу ошибался, буду пробовать в jmeter

спасибо за подсказки

в чем проблема? почему нельзя?

так как кажого пользователя нужно регистрировать

да, конечно

так как кажого пользователя нужно регистрировать

ну так а проблема то в чем?

ну либо такие варианты: -сначала регаем 1 пользователя, затем гоняем все на нем. -регаем или подсовываем пул из учеток и гоняем на них

на одном я пробовал, но не знал как загнать 100500 пользователей

не буду же я их все регистрировать руками)

поэтому и спрашиваю, о альтернативном варианте

повторите процесс регистрации в начале

все запросы с сохранением логина пароля и прочего при необходимости

буду пробовать, спасибо

не буду же я их все регистрировать руками)

подготовить csv файл с необходимыми для регистрации данными, и брать данные для регистрации из него

ок, спасибо за помощь

через бд загнать 100500 пользователей, скормить гатлингу /jmeter-у их креды

на одном я пробовал, но не знал как загнать 100500 пользователей

если сервис требует сессию авторизованную, то может стоить попробовать собрать информацию (токены) которая будет подписывать сессию? например какой-нибудь хедер запроса "authorization Bearer 23cb5d7f32e85f72a3", где число - аксес токен пользователя или же передавать его через параметр в самом URI.

берешь заходишь в БД, делаешь селектом по пользователям получаешь их 100 живых токенов, дампишь их в .csv файл или текстовый. Далее в JMeter изучаешь как итерировать по этому списку, чтобы тестировать метод API от разных пользователей