Потому что человеческий фактор и вот это всё.

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

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

Так а в чем проблема то? Вот во время тестовой миграции нашлись такие данные. Значит нужно добавить условия миграции

в моей ситуации они сломают стейджинг

Окей, кажется надо покурить, структурировать это в моей голове и более подробно описать вопрос из моей головы. :)

Добрый вечер! На сколько сильно предпочитаема java чем python для куа инженера в компаниях? С java знаком немного, в основном, с университетских времён. Питон сейчас изучаю, и он мне нравится своим стилем синтаксиса, да и М. Лутц хорошо написал книгу по нему, стоит ли его бросить и нацелиться полностью на java? Я так понимаю, с java на много больше вакансий, и они денежней)

Python твой друг

не бросай его

потом перекатишься в ML

О кстати, а на Kotlin пишет кто тесты ?

потом перекатишься в ML

Спасибо, а что за ML?

Machine Learning

Ну, это для тех, кто математику изо всех сил знает, имхо.

Добрый вечер! На сколько сильно предпочитаема java чем python для куа инженера в компаниях? С java знаком немного, в основном, с университетских времён. Питон сейчас изучаю, и он мне нравится своим стилем синтаксиса, да и М. Лутц хорошо написал книгу по нему, стоит ли его бросить и нацелиться полностью на java? Я так понимаю, с java на много больше вакансий, и они денежней)

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

Я сейчас 90% времени пишу на джаве, но если нужны быстрые прикладные штуки , то накидываю на питоне

Ещё что-то, это java, например?)

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

Лучше то, что нужно в данный момент )

Если хочется что-то поднять на текущем месте, то лучше питон (порог входа ниже).

Хотя если есть джава разрабы, то можно и джаву, они подхватят

Короче нет "лучше". Все индивидуально )

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

Если внутри банка, то скорее всего будет джава или Шарп)

Внутри банка куав нет)

Если уходить куда-то на автоматизатора сразу, то первое место скорее всего будет что-то галерное и там тоже скорее всего будет джава)

Ясно, спасибо)

Касательно некосинсентности данных: https://www.youtube.com/watch?v=WPCz_U7D8PI возможно кому-то будет полезно

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

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

Я бы сказал, что стартовать проще с Пайтона. Ниже порог вхождение, меньше кода и примочек для решения типовых задач и прочего. Это, пожалуй, единственная разница. Формально, если в голове уляжется способ решения задач на одном языке, то пересесть на другой будет не особенно-то болезненно (хотя костылей придется пособирать). Главное стараться понимать что вы делаете и как это работает, а не становиться специалистом одного фреймворка. Вакансий что с пайтоном, что с джавой хватает. C# и JS, на мой взгляд, меньше, но тоже при желании вполне можно найти.

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

Ну и отдельное дополнение: начало пути QA инженера довольно редко связано с автоматизацией.

Спасибо большое за совет!

К слову, если у кого-то есть видеоматериалы/курсы, которых нет в открытом доступе, по изучению автоматизации будь то Java или Python, не важно. Был бы благодарен за шеринг

Шарить закрытые материалы - не очень хорошая практика, вам не кажется?

На них там создатели контента денежку на хлеб зарабатывают, и всё такое.

Да ладно. Доказали ж, что пиратство на продажи не влияет почти

Да ладно. Доказали ж, что пиратство на продажи не влияет почти

Пруф на исследование в контексте наукоемких знаний, а не фан-контента, пожалуйста.

Есть кто на PL SQL пишет? База Oracle? Нужна небольшая помощь

Есть кто на PL SQL пишет? База Oracle? Нужна небольшая помощь

Покажь что нужно. Попробую помочь

Куда там ) некоторые на работе ещё )

Пруф на исследование в контексте наукоемких знаний, а не фан-контента, пожалуйста.

https://telekomza.ru/2013/10/16/snizhenie-aktivnosti-fajloobmena-ne-podnimaet-prodazhi-licenzionnoj-muzyki/

https://telekomza.ru/2013/10/16/snizhenie-aktivnosti-fajloobmena-ne-podnimaet-prodazhi-licenzionnoj-muzyki/

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

Это нормально, потому что настала эпоха стриминга и вот этого всего.

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

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

Я просил пруф про то, что пиратство не вредит продажам контента.

Пиратство - чуть более широкий термин, чем пользование файлообменниками.

Я просил пруф про то, что пиратство не вредит продажам контента.

Так там и есть про продажи))) но тебе тут же понадобилось про "уменьшение потребления контента"))

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

Так там и есть про продажи))) но тебе тут же понадобилось про "уменьшение потребления контента"))

Нет, мне не интересно про "уменьшение потребление контента".

Мне интересно про "Пиратство не вредит продажам контента".

Все понятно, да))

Вы как-то отошли от темы тестирования в сторону правового поля по пиратству.

Продажа и потребление разные вещи просто)

ваш КЭП

Можешь ещё раз прочитать ветку диалога и станет всё понятно.

Вы как-то отошли от темы тестирования в сторону правового поля по пиратству.

Сорян, бомбануло за копирайт.

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

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

Всем привет. Подскажите версию подходящую версию geckodriver(selenium) для Firefox 55 или 56

Не могу подобрать

https://github.com/mozilla/geckodriver/releases

Там же пишут для каких версий

0.19.0 например для 55 и выше

Пробовал. Браузер открывается. Но далее происходит проблема при инициализации firefoxProfile. Спасибо. Попробую версию selenium другую.

На текущий момент стоит 3.0.1

Всем привет! Поделитесь опытом и советами) Отказывались ли вы полностью от ручного тестирования (в плане каждой таски, понятно, что часть задач потребует рук) в пользу автоматизации? Хотим поменять распределение очень ограниченых ресурсов тестировщиков. Два года назад тестеров небыло вообще, сейчас 2 - один все время на ручном. По итогу автоматизация идет медленно, болото ручного съедает все время. На днях появиться 3й человек на автоматизацию, но ресурсов все равно не хватает.

Было бы интересно тоже послушать. Нас 6 человек и все равно ручное съедает все время)

ох уж эти надежды на повсеместную автоматизацию.

По моему опыту, хоть и небольшому, автоматизация только добавляет проблем =)

у меня в планах - в текущий проект ввести одного автоматизатора для написания "ядра". а дальше тестировщики сами пишут кейсики и скармливают ядру для прогона, объединяя в сеты.

По моему опыту, хоть и небольшому, автоматизация только добавляет проблем =)

хахаха))) а ручками регрешн прогонять не добавляет?)

хахаха))) а ручками регрешн прогонять не добавляет?)

Регрешн ручками добавляет уныния, но не проблем =)

Наверное, есть люди, кто готов на ручном сидеть по 5 лет, но по мне таких крайне мало - по итогу текучка?(меня тошнило через год) Насколько живуч вариант 90% времени заниматься автоматизацией и перед релизом активный регрес\сплошняк руками?

Наверное, есть люди, кто готов на ручном сидеть по 5 лет, но по мне таких крайне мало - по итогу текучка?(меня тошнило через год) Насколько живуч вариант 90% времени заниматься автоматизацией и перед релизом активный регрес\сплошняк руками?

Автоматизация никогда не заменит ручное тестирования полностью. Автоматизация требует значительных усилий на поддержку существующего кода. Особенно если тестируемый продукт активно развивается и меняется с каждым релизом :) Мне кажется вариант с 90% - из разряда фантастики, учитывая небольшое количество тестировщиков.

опять холивар)

опять холивар)

ну почему бы и нет, в споре рождается истина)

Наверное, есть люди, кто готов на ручном сидеть по 5 лет, но по мне таких крайне мало - по итогу текучка?(меня тошнило через год) Насколько живуч вариант 90% времени заниматься автоматизацией и перед релизом активный регрес\сплошняк руками?

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

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

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

Автоматизация никогда не заменит ручное тестирования полностью. Автоматизация требует значительных усилий на поддержку существующего кода. Особенно если тестируемый продукт активно развивается и меняется с каждым релизом :) Мне кажется вариант с 90% - из разряда фантастики, учитывая небольшое количество тестировщиков.

я больше про смену приоритетов и времени. У нас монго что меняется, но очень огромный "регрес"

CI

Наверное, есть люди, кто готов на ручном сидеть по 5 лет, но по мне таких крайне мало - по итогу текучка?(меня тошнило через год) Насколько живуч вариант 90% времени заниматься автоматизацией и перед релизом активный регрес\сплошняк руками?

Есть люди. Но это не значит, что в ручном тестировании негде развиваться. А ещё есть люди, которым не надо развиваться, потому что их всё устраивает.

Вариант с 90% (и больше) абсолютно реален. Но недавно http://www.developsense.com/blog/2017/11/the-end-of-manual-testing/ Джеймс Бах написал очень замечательный пост: нет "ручных" и "автоматизированных" тестировщиков. Есть "тестировщики", есть задача - а как вы её решаете - зависит от задачи и вашей головы

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

везде своя жизнь. у нас релиз раз в 2 месяца, например, и подходы несколько иные.

Господи, на харош. мануал тестинг уже умирает лет 10 как. Это как капитализм, который загнивает несколько сотен лет.

Господи, на харош. мануал тестинг уже умирает лет 10 как. Это как капитализм, который загнивает несколько сотен лет.

поддержу. и про развитие в ручном - тоже поддержу.

Я не оспариваю, но более-менее конкретные примеры бы почитал, для более ясного представления)

разница в зп процентов на 30-40, а то и 50 :D

поддержу. и про развитие в ручном - тоже поддержу.

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

Есть люди. Но это не значит, что в ручном тестировании негде развиваться. А ещё есть люди, которым не надо развиваться, потому что их всё устраивает.

В ручном всегда есть где развиваться :) Идеального тест-анализа и тест-дизайна никогда еще не видел :)

вот

ну и я не знаю, регрешн руками гонять это просто какое-то неэффективное использования своего времени

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

если для вас ручное - это не более чем клик-клак, то всё, приехали.

разница в зп процентов на 30-40, а то и 50 :D

Это "у нас". Просто менталитет + "умение себя продать".

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

ну и я не знаю, регрешн руками гонять это просто какое-то неэффективное использования своего времени

Дык наверное смотря что проверяется в регрешене