Сообщений в теме: 44

[SALar]

 

Еще из интересного - совсем недавний доклад на онлайн-марафоне: 

Посмотрела доклад с SQAdays, но все равно не поняла, почему не стоит начинать автоматизацию с регресса... Если продукт уже давно на рынке, занимает свою вполне определенную нишу, есть огромный штат ручных тестировщиков и еще более огромная тестовая регрессионная модель, которую прогонять вручную всё сложнее и сложнее из за объемов (к тому же, это скучно - одно и тоже из раза в раз), то почему бы не взять команду автоматизаторов и не загрузить их автоматизацией наиболее важных и наиболее автоматизируемых тестов? Если не начинать в этом случае автоматизацию с регресса, то с чего её начинать? Или вообще не начинать и забить на регресс? :)

 

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

[Little_CJIOH]

 

Посмотрела доклад с SQAdays, но все равно не поняла, почему не стоит начинать автоматизацию с регресса... Если продукт уже давно на рынке, занимает свою вполне определенную нишу, есть огромный штат ручных тестировщиков и еще более огромная тестовая регрессионная модель, которую прогонять вручную всё сложнее и сложнее из за объемов (к тому же, это скучно - одно и тоже из раза в раз), то почему бы не взять команду автоматизаторов и не загрузить их автоматизацией наиболее важных и наиболее автоматизируемых тестов? Если не начинать в этом случае автоматизацию с регресса, то с чего её начинать? Или вообще не начинать и забить на регресс? :)

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

Забить совсем? Лично мое мнение, что старый функционал должен проверяться по конкретным пользовательским сценариям. А живой человек или автомат это делает должно определятся частотой деплоев. Если раз в месяц то определенно человек, если раз в день - определенно автомат.

На днях обсуждали с супругой моду на автоматизацию тестирования, она мне процитировала кусок из "Как тестируют в Google" который я категорически не помню. Говорит что там написано, что: "такой подход не сработает нигде и ни у кого кроме Google, но если вы зададитесь вопросами, которые мы тут озвучим, честно на них ответите, то в итоге получите свое тестирование с Го и Гейшами." Очень сильно удивлялась когда я сказал что не помню этой цитаты и не помню никого кто делясь впечатлениями о книге говорил бы про принципы, а не про конкретные практики.

[SALar]

 

 

Посмотрела доклад с SQAdays, но все равно не поняла, почему не стоит начинать автоматизацию с регресса... Если продукт уже давно на рынке, занимает свою вполне определенную нишу, есть огромный штат ручных тестировщиков и еще более огромная тестовая регрессионная модель, которую прогонять вручную всё сложнее и сложнее из за объемов (к тому же, это скучно - одно и тоже из раза в раз), то почему бы не взять команду автоматизаторов и не загрузить их автоматизацией наиболее важных и наиболее автоматизируемых тестов? Если не начинать в этом случае автоматизацию с регресса, то с чего её начинать? Или вообще не начинать и забить на регресс? :)

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

Забить совсем? Лично мое мнение, что старый функционал должен проверяться по конкретным пользовательским сценариям. А живой человек или автомат это делает должно определятся частотой деплоев. Если раз в месяц то определенно человек, если раз в день - определенно автомат.

На днях обсуждали с супругой моду на автоматизацию тестирования, она мне процитировала кусок из "Как тестируют в Google" который я категорически не помню. Говорит что там написано, что: "такой подход не сработает нигде и ни у кого кроме Google, но если вы зададитесь вопросами, которые мы тут озвучим, честно на них ответите, то в итоге получите свое тестирование с Го и Гейшами." Очень сильно удивлялась когда я сказал что не помню этой цитаты и не помню никого кто делясь впечатлениями о книге говорил бы про принципы, а не про конкретные практики.

 

 приложить максимум усилий, чтобы...

[leftCh]

Спешу  поделиться с уважаемым сообществом. Читаю книгу

 

Джерард Месарош Шаблоны тестирования xUnit Рефакторинг кода тестов

 

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

[leftCh]

“Мы начали автоматизацию с регрессионного тестирования.” Это приговор. Больше можно ничего не изучать и не спрашивать.

 

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

А на новые проекты автоматизаторов не зовут, ибо что там автоматизировать, ручные тестировщики пока справляются )
 

[clipsa]

 

“Мы начали автоматизацию с регрессионного тестирования.” Это приговор. Больше можно ничего не изучать и не спрашивать.

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

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

Но вот с тем, что данная задача "поручается людям не обладающим соответствующей квалификацией" - не соглашусь, возможно так бывает "обычно" или "зачастую", но не всегда и везде :)

[leftCh]

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

Но вот с тем, что данная задача "поручается людям не обладающим соответствующей квалификацией" - не соглашусь, возможно так бывает "обычно" или "зачастую", но не всегда и везде :)

 

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

[clipsa]

 

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

Но вот с тем, что данная задача "поручается людям не обладающим соответствующей квалификацией" - не соглашусь, возможно так бывает "обычно" или "зачастую", но не всегда и везде :)

 

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

У нас уже порядка 1,5 тыс. автотестов, в каждом тесте от 1 до 5 проверок примерно. Разработкой и поддержкой занимается команда специально выделенных автотестеров, плюс, со стороны "ручных" тестеров есть 2-3 человека поддержки - они говорят нам что нужно автоматизировать, предоставляют тестовые данные для автотестов, занимаются поддержкой стендов и пр. и они же принимают автотесты и занимаются их регулярными запусками.

 

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

[leftCh]

(тут был тролинг, убрала, а если серьезно)

 

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

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

 

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

 

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

[clipsa]

(тут был тролинг, убрала, а если серьезно)

 

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

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

 

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

 

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

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

[Freiman]

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

[Molechka]

Автоматизация на уровне веб-интерфейса (и любого другого гуя) в любом случае - костыли. 

 

Почему?

[Freiman]

 

Автоматизация на уровне веб-интерфейса (и любого другого гуя) в любом случае - костыли. 

 

Почему?

 

Потому что он для этого не предназначен.

Попробуйте автоматизировать GUI и API. Эффективность автоматизации API будет значительно выше. Почему? Потому что он как раз и создавался для взаимодействия с другим ПО, а пользовательский интерфейс - нет. Поэтому приходится городить костыли, потому что отсутствует более удобный способ.

[Сергей]

Эффективность что и как тестировать - это отдельная тема. Но автоматизацию гуи ещё никто не отменял так же как и ручное тестирование. Кому-то все равно придется это делать, особенно если кроме гуи никак не подступиться к приложению.

[Freiman]

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

Ну вот в этом и загвоздка - "кроме гуи никак не подступиться" :)

Мы это делаем не потому, что это реально круто-удобно-хорошо, а потому что других способов нет.

[Сергей]

Согласен, Сизисоф труд.

[a.ribakov]

Мы это делаем не потому, что это реально круто-удобно-хорошо, а потому что других способов нет.

 

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

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

[DmitriyQA]

Считаю что надо сделать все чтобы автоматизация взлетела. Ибо на своременном большом проекте без нее никак. Так что надо учится на ошибках своих

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

[Little_CJIOH]

Кстати. Предлагаю обсудить реальную ситуацию. Есть некая система для работы с финансовой информацией и принятия решений исходя и нее. Сама система представляет из себя ~40 подсистем со сложными зависимостями друг от друга, 3 подсистемы для загрузки информации из разных сопрягаемых систем. все это Oracle, PL/SQL. Для взаимодействия с пользователем собственный сервер приложений ( с++, oracle pl/sql), фронтенд - Apache + ангуляр. Во всем этом добре еще примерно 20 подсистем разрабатываемых другими отделами, которые обеспечивают GUI в который встраиваются ваши формы.

От предшественника вам досталось 4 схемы с разными конфигурациями системы, соответствующие им 4 схемы сервера приложений. фронтенд с сервером приложений, который оперативно переключается между схемами. 2 схемы с кусками обезличенной клиентской базы 5-годовалой давности, представляющие 2 системы из которых грузятся данные. 3-й способ загрузки - API.

Все это в каком-то состоянии, актуализация - ручками, совпадение версий подсистем в схемах и фронтенда ручками.

Система энтерпрайз уровня, то есть вся бизнес-логика настраивается через ГУИ: справочники, маски, связки, пользовательские атрибуты.

 

Автоматизация тестирования - must have, это политика партии.

С чего начнете автоматизацию всего этого бардака?

Релизы раз в 3 месяца, у вас есть мануальшик, который помогает продраться через текучку + аутсорсер-автоматизатор, который будет только автоматизацию пилить по вашему заданию.

[Vla8islav]

 

С чего начнете автоматизацию всего этого бардака?

Релизы раз в 3 месяца, у вас есть мануальшик, который помогает продраться через текучку + аутсорсер-автоматизатор, который будет только автоматизацию пилить по вашему заданию.

// голос с дивана

Сперва попробую написать несколько ключевых тестовых сценариев на protractor-е с привлечением мануальщика. Постараюсь выяснить, какие части системы - самые критичные и какие меняются чаще всего. Дальше - по обстоятельствам.