нет кнеш, но юая там мало

пони

Посмотрите какого года выпуска его книга.

кстати, я могу ошибаться, но Алименков на XPInjection давненько писал об ошибочности мнения, что нельзя всё автоматизировать

Посмотрите какого года выпуска его книга.

какая из? ))

Есть новое издание Канера, на инглише. Но оно тоже не сильно полезно

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

я бы такую теорию читала после практики

когда что-то не получается, а ты не понимаешь, почему

Угум. Как минимум после полугода проекта

Посмотрите какого года выпуска его книга.

Ну старенькая) Но она на мой взгляд всё равно полезна для прочтения

Угум. Как минимум после полугода проекта

Читал её после 2-х лет работы в АТ, уже не сильно актуально было

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

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

Тесты бекенда не могут быть слишком нестабильными))) иначе это не бекенд)))

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

так что и автоматизирование тестирование может быть разное

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

Такое возможно, хотя маловероятно

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

Есть такоей знакомый – после каждой задеплоенной им фичи по 3-10+ хотфиксов. Зато без тестирования!

Тесты бекенда не могут быть слишком нестабильными))) иначе это не бекенд)))

в жизни - легко) тесты потеряли актуальность, из-за чего стали падать. а так как "сроки не позволяют" ими заняться, то в команду сборки временно (хаха) добавляется какой-нибудь ключ "skiptests=true" :)

Это не то) при такой философии сами разработчики немного куа. Гугл пытаются такое в своем extreme programming реализовать)

Но вообще очень зависит от личной ответственности разработчиков. Если "да тестеры проверят. Фигак фигак и в Fixed" – это одно. Если "аа! тестеров нет! Надо вычитать код трижды! И дать вычитать другим!" – это другое.

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

почему вы такое решили?

то есть как вы сделали такие выводы?

автоматизация даёт более информативные отчёты

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

Это не то) при такой философии сами разработчики немного куа. Гугл пытаются такое в своем extreme programming реализовать)

XP - это ваще то то из чего вырос эджайл

автоматизация даёт более информативные отчёты

Нет, скорее эти отчеты проще получить, ибо код

Ручное тестирование поддаётся такому же анализу, но все на это ложат(как и я) ибо нужно релизить пофастику обычно)))

Техники анализа это наверное самое сложное в менеджменте куа)

Нет, скорее эти отчеты проще получить, ибо код

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

анализ результатов прохода тестов - это и есть тестирование по сути, обсуждали не так давно

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

На прошлой работе почти все такие зайчики были ❤️

анализ результатов прохода тестов - это и есть тестирование по сути, обсуждали не так давно

в istqb это этап общего процесса

но бордов много, да

в istqb это этап общего процесса

в istqb и исследовательское тестирование описано так http://istqbexamcertification.com/what-is-exploratory-testing-in-software-testing/ )))

а что там не так?

isqbt такой бред

как законы читаешь

http://www.satisfice.com/blog/archives/664 - бах не согласен :)

хотя он там немного о другом, но ему не понравилось )))

спасибо, почитаем

и канер тоже ругался

не так, как на ISO стандарт по тестированию, но тоже плотно обое приложились

заслуженно приложились

до того как поругались из-за автоматизации )))

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

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

и сразу на проде)

Кто-то имеет опыт работы со связкой cucumber+gradle? Нигде нет ответа на один вопрос

почему вы такое решили?

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

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

системы высокоточные, модули для рассчётов редактирования ДНК по crispr/cas9

ох там и команда, наверное

кандидатов

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

любопытно p.s. не писал, по крайней мере в этом чате :)

потому что тесты дизайнятся без математических рассчётов

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

кандидатов

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

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

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

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

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

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

Ахахахахах

Кхм, простите

Мне понравилась концепция)

Зато скорость написания наверное повышается в разы за счет набитой руки?)

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

Мы так делали только в том случае, если каким то макаром умудрялись повторно упустить его

Зато скорость написания наверное повышается в разы за счет набитой руки?)

я не набил, уволился

Мы так делали только в том случае, если каким то макаром умудрялись повторно упустить его

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

ERROR: S client not available

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

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

ну, насчет помогло - не могу судить, я недолго проработал там тестов много, выполняются быстро (там пользовался виртуальный браузер canoo web test и watir ruby gem), запускали на каждой версии все веб-приложения, относительно простые, некоторые даже без js тесты все юайные

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

о. Ватир.

фантом, что ли

Годнота.

вот это экзотика

ну мне руби понравился в целом, ага

puts 'Кроссавчег!'

вот это экзотика

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

ну мы для UI юзаем Ruby + Capybara+ Cucumber —> в целом годно

Ну, стандартный стек.

Ребят, насколько перспективна и востребована в СНГ и вообще в мире связка Selenium + Python для автоматизации?

та нормально

особенно вон парни из WARGAMING любят питонщиков автоматизаторов

к примеру

Спасибо за ответ

нз

никто больше не замечал, сейчас растет спрос на php автоматизаторы?

no

У меня этот спрос всегда есть

Но маловато таких

но автоматизаторы на java дорогие. потомучто джава сложнее питона и пхп. и такая же фигня с зарплатой девелоперов

ну хз я приверженец java

хотя пыху знаю относительно конечно

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

какая пхп

JS тогда уже

js болото

магия

глубокая яма)

какой смысл сейчас пхп под автоматизацию. Может паскаль еще или бейзик?)