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

[leftCh]

Собственно навеяно этим http://blog.shumoos.com/archives/268
Чтобы там ответить нужно регистрироваться, а мне лень   напишу здесь, тем боле что автор текста, по всей видимости ярый противник автоматизации, наверняка отпишется Я на самом деле не очень поняла, почему уважаемый SALar против именно автоматизации регресии )

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

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

А вот что должно быть, чтобы автоматизация взлетела

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

            - Определение способов оптимального взаимодействия тестируемой и тестирующей программ

            - Как сделать чтобы "изменения тестов не отставали от изменения кода"

            - Как упростить работу по определению причин падения тестов

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

            - Как распараллеливать тесты, как создавать нагрузку на приложение

            - Этапы создания автотестов, критерии успешности этапа

            - Как интегрировать ручное тестирование и автотестирование

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

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

[Freiman]

Я с некоторых пор тоже со скептицизмом отношусь к автоматизации.
Особенно если она через гуй и регрессионная.
Геморроя много, выхлоп крайне незначительный. И тут уж ни инструменты, ни фреймворки не помогут.

Пока вы не разобрались со стратегией тестирования, все тактические вопросы бессмысленны.

[leftCh]

Я с некоторых пор тоже со скептицизмом отношусь к автоматизации.
Особенно если она через гуй и регрессионная.
Геморроя много, выхлоп крайне незначительный. И тут уж ни инструменты, ни фреймворки не помогут.

Пока вы не разобрались со стратегией тестирования, все тактические вопросы бессмысленны.

 

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

• Не знаю как вы, а я больше доверяю, в предрелизном тестировании критичных мест, программе, чем человеку. Человек может не выспаться, лениться, ему уже надоели одни и те же тесты, он не понял смысл проверки и решил что все нормально, он находится в поиске другой работы и ему уже все равно… Человек это сложно :) Программа — это просто :)
• При хорошем и единственно правильном подходе автоматизация должна ускорять и выпрямлять работу ручных тестировщиков, предоставляя им некоторые ценности, упрощающие проверку новых задач
• Ручные тест кейсы, когда их много - это тоже проблема, они тоже требуют поддержки. Что теперь вообще отказаться от любой документации тестирования? На некоторых проектах очень легко забываются детали того, как оно должно работать, часто эту информацию можно найти в тестах.
• Да и просто автоматизация развлекает тестировщиков и повышает статус проекта в их глазах :)

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

[Little_CJIOH]

А теперь представьте, что это автоматизатор у вас: "не выспался, задолбался молотить однообразные тесты, не понял смысл проверки, находится в поисках другой работы и ему все пофиг"

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

[clipsa]

Будет интересно увидеть обещанную SALar'ом майндмапу на эту тему, пока что не очень понятно из чего такие выводы, имхо - сколько проектов, столько и мнений :)

 

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

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

И да, мы автоматизируем наши регрессионные тесты, коих великое множество :)

 

Такой подход уже даёт свои позитивные плоды - у нас полностью автоматизированы смоук-тесты (порядка 100 ручных тестов, что соответствует порядку 300 автотестов). Если раньше смоук-тесты проходились вручную за 6-8 ч/дней (6-8 человек за день-полтора), то теперь эти же тесты проходятся автоматически за пару часов ночью никому не мешая, а утром 1 человек может разобрать результаты прохождения этих тестов примерно за час. 

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

[leftCh]

А теперь представьте, что это автоматизатор у вас: "не выспался, задолбался молотить однообразные тесты, не понял смысл проверки, находится в поисках другой работы и ему все пофиг"

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

 

Автотест проходит ревью. Так что плохих автотестов можно избежать. А ручной тестировщик, тестирующий регрессию, никак по сути не контролируется. Регрессионные тесты находят мало багов, 100% успешный запуск — обычная ситуация. И до определённого времени можно их не делать, просто проставляя Passed

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

А если он пишет детальные тест кейсы, то пусть тогда уж лучше пишет код, по трудоемкости одно и тоже

[Freiman]

Автотест проходит ревью. Так что плохих автотестов можно избежать. А ручной тестировщик, тестирующий регрессию, никак по сути не контролируется. Регрессионные тесты находят мало багов, 100% успешный запуск — обычная ситуация. И до определённого времени можно их не делать, просто проставляя Passed
Вообще ручной тестировщик, не пишущий детальные тест кейсы непонятно ведь чем занимается, разве нет?
А если он пишет детальные тест кейсы, то пусть тогда уж лучше пишет код, по трудоемкости одно и тоже

Наймите уже нормальных тестировщиков, которые будут проверять, а не протыкивать :)

Про детальные тест-кейсы - это был сарказм или вы серьезно?

[leftCh]

Такой подход уже даёт свои позитивные плоды - у нас полностью автоматизированы смоук-тесты (порядка 100 ручных тестов, что соответствует порядку 300 автотестов). Если раньше смоук-тесты проходились вручную за 6-8 ч/дней (6-8 человек за день-полтора), то теперь эти же тесты проходятся автоматически за пару часов ночью никому не мешая, а утром 1 человек может разобрать результаты прохождения этих тестов примерно за час. 

 

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

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

[leftCh]

 

Наймите уже нормальных тестировщиков, которые будут проверять, а не протыкивать :)

Про детальные тест-кейсы - это был сарказм или вы серьезно?

 

Серьезно. Подскажите мне способ как узнать не от клиента, хорошо тестировщик проверил фичу или нет, в условиях ограниченных ресурсов на тестирование.
И как отличить проверяльщиков от протыкальщиков на этапе собеседования?  
И еще один вопрос, предположим вы все таки узнаете от клиента о пропущенном критичном или очевидном баге, увольнять тестировщика или подождать пока еще парочку пропустит? <-- тут сарказм

 

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

[clipsa]

 

 

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

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

У нас хватает своих эффективных менеджеров, которые всё уже давно просчитали :)

[SALar]

Собственно навеяно этим http://blog.shumoos.com/archives/268
Чтобы там ответить нужно регистрироваться, а мне лень   напишу здесь, тем боле что автор текста, по всей видимости ярый противник автоматизации, наверняка отпишется Я на самом деле не очень поняла, почему уважаемый SALar против именно автоматизации регресии )

 

Я не против автоматизации регрессии.

Там же написано:

 

 

 

Не нужно мне приписывать то, чего я не говорил. Я ясно написал, что с нее нельзя начинать.

На эту тему я делал доклады на конфетке, SQADays 15 и 18 и т.д. Со временем я понял, что материал сложный и та концентрированная подача, которую я делал не подходит для широкой аудитории. Особенно высока концентрация была на конфетке. 

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

 

 

Конфетки больше нет (кажется?), но почему бы не провести онлайн конференцию на узкую тему "Стратегия тестирования" с отдельным блоком "Стратегия автоматизации"? Люди готовые мне помочь есть, дело за слушателями. И в качестве бонуса. Материал конференции будет в значительной степени формироваться на основе предварительно заданных вопросов.

[clipsa]

 

Конфетки больше нет (кажется?), но почему бы не провести онлайн конференцию на узкую тему "Стратегия тестирования" с отдельным блоком "Стратегия автоматизации"? Люди готовые мне помочь есть, дело за слушателями. И в качестве бонуса. Материал конференции будет в значительной степени формироваться на основе предварительно заданных вопросов.

 

 

Думаю, было бы интересно. 

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

[SALar]

 

Думаю, было бы интересно. 

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

 

В двух словах смотри доклад на SQADays-18 http://sqadays.com/ru/talk/38135

 

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

[clipsa]

Сергей, спасибо! Посмотрю, потом, возможно, еще вопросы появятся :)

[clipsa]

Сергей, немного офтопа - давно хотела спросить, вы где-то преподаёте? У вас такой голос и тон как у преподавателя :)

[Freiman]

Да, доклад на SQADays кажется несколько "скомканным".

Сергей, а не могли бы вы чуть подробнее рассказать про подход test-first?
Разработчики ядра тогда у нас работают без простоев. Но не увеличит ли это общее время разработки?

[SALar]

Сергей, немного офтопа - давно хотела спросить, вы где-то преподаёте? У вас такой голос и тон как у преподавателя :)

Первое образование - педкласс. Общий стаж преподавания более 3000 часов. Тренинг, который веду с 2005: http://school.system...s/use-case-bas/ Время от времени даю тренинги по тестированию, анализу, управлению, ...

 

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

 

Да, доклад на SQADays кажется несколько "скомканным".

Сергей, а не могли бы вы чуть подробнее рассказать про подход test-first?
Разработчики ядра тогда у нас работают без простоев. Но не увеличит ли это общее время разработки?

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

[Freiman]

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

Извините, этот момент мне кажется непонятным.
Тестировщики разрабатывают тесты параллельно с программированием. Это функциональные тесты системного уровня или же модульные, интеграционные?

[clipsa]

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

Спасибо! Этот доклад у меня лежит в "на посмотреть", никак не доберусь :)

 

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

[Сергей]

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