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

Ну дык, поистязал себя пару лет, а потом берешь и переходишь на новую работу с зарплатой 1.5x

теперь вы начальник транспортного цеха, угу

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

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

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

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

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

Профессионалов везде крайне мало

жаль

А все от лени :))) "Это меня не касается, пусть другой ктонить сделает" - вот так все входящие в айти и думают

"Я уже отсиживаю на работе по 8 часов целых полгода, пора менять бейджик на мидол"

Можно все делать и ничего не с делать, уже 5 часов пора домой, не успел

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

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

сижу я уже 15 лет, побывал на всяких позициях тестирования, окопался в автоматизации.

сижу я уже 15 лет, побывал на всяких позициях тестирования, окопался в автоматизации.

и как ощущения?

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

Уже спорно

Уже спорно

конкретнее.

сижу я уже 15 лет, побывал на всяких позициях тестирования, окопался в автоматизации.

Автоматизация это на 80% разработка та же.

и как ощущения?

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

даже немного освоил навык ментальных карт

пострение)

Предугадывание тоже нарабатывается широтой знаний

конкретнее.

Низкий порог уже спорно, много кинулись в it через qa и появился выбор, до 300 резюме на вакансию, но правда выбрать толковое что-то тяжело

Предугадывание тоже нарабатывается широтой знаний

не, именно, чтобы через ведение, как у бабки ванги

)

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

Потому что они 15 лет в разных проектах шишки набивали.

Низкий порог уже спорно, много кинулись в it через qa и появился выбор, до 300 резюме на вакансию, но правда выбрать толковое что-то тяжело

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

это я тоже могу, но не то

сидишл такой

Автоматизация это на 80% разработка та же.

а остальные 20% ?

и гадаешь перед компом

а остальные 20% ?

чай с кофе попить, да бублик слопать

а остальные 20% ?

А на 20% тестирование :)

чай с кофе попить, да бублик слопать

??

А на 20% тестирование :)

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

автотесты очень затратны по времени, это факт

их поддержка еще накидывает сверху, если постоянно что-то пилится

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

Одно слово: Бекенд.

что же за инструменты то у Вас, если чуть чих не в ту сторону, так жопа?

Чем больше автотестов, тем больше времени на их поддержку и апдейт.

Да и пусть редизайн, логика тестов остается жЫ) поправил чутка и вперед, ну если, конечно все грамотно спроектировано, слои и все такое…а и иначе да, бекэнд

Да и пусть редизайн, логика тестов остается жЫ) поправил чутка и вперед, ну если, конечно все грамотно спроектировано, слои и все такое…а и иначе да, бекэнд

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

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

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

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

http://software-testing.ru/library/testing/testing-automation/2388-true-automation

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

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

http://software-testing.ru/library/testing/testing-automation/2388-true-automation

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

не продолжай, брат, я понимаю твою боль

почему аксептанс тесты на апи уровне...............

ето как вообще

почему аксептанс тесты на апи уровне...............

Надо узнать что под этим подразумевал автор картинки

да

потому что если апи, то еще понятно

а если аксептанс, то я не согласна

Всё же сфера тестирования все ещё не устоялась и многие термины трактуются по разному

Ну энто из просторов интернета, копипаст, первой попавшейся..

да ну, в исеб все ок с терминологией

Общая идея просто так

блин, обсуждение сферического коня в вакууме

ERROR: S client not available

Всё же сфера тестирования все ещё не устоялась и многие термины трактуются по разному

шта?

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

а почему один тест такой длинный

почему не разбить его на несколько поменьше

у нас в проекте считается плохим тоном все наваливать в один тест

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

потому что фейлится в одном месте и дальше не идет

считай с нуля пишешь этот тест

алсо насчет xpaths - почему не договориться с девами не трогать их

алсо насчет xpaths - почему не договориться с девами не трогать их

их не трогают, ре дизайн - и все по новой

больше времени тратится на написание запросов к базе и вот правке этих locate к элементам на странице

может, лейблы использовать?..

у нас в проекте считается плохим тоном все наваливать в один тест

у всех проекта разные )

я понимаю, но есть хороший опыт в проекте, есть плохой

я делюсь

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

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

поменяют, блять, структуру основой таблицы - и все тесты легли)

пффф а\б тест внезапный )

так же кладет все великолепно

а вообще, если не ходите на митинги - то начните ходить. меньше внезапностей будет и можно будет слово своё вставить.

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

все дело в грамотной организации

ставьте грамотные сроки, давайте заранее таски - и все будет гуд :) ну и я считаю, что qa должны знать, что делают разрабы и что будут делать

воу воу.... у нас все меняется динамично, разработка в 3 городах.

Длинные тесты очень затраты в сопровождении, вот, например, дебажить их не алло вообще, как вариант, разбивать на более мелкие проверки.. конечно, если есть такая возможность. И помнить, один тест - одна проверка.

Мощный у вас проект)

Так и я про то, нет возможности, от того и боль.

carprice.ru сопровождаем

А на каком тех. стеке вертится все? Интересно просто…

А на каком тех. стеке вертится все? Интересно просто…

автотесты на php + codeception + docker под jenkins