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

[baranceva]

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

 

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

 

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

 

"Какие тесты автоматизировать" – неверный вопрос

 

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

 

Это два раздельных и очень различных типа тестирования, имеющих разные цели. Они не взаимозаменяемы – они дополняют друг друга (см. "Горькая правда об автоматизации", "Не-ручной неавтоматизированный тестировщик").

 

Учитывая это, неверно говорить о том, "какие тесты автоматизировать" – такой вопрос предполагает, что мы автоматизируем то, что уже делаем вручную.

 

Читать статью полностью...

[DReeborn]

Мне совсем не понятен бросок камня в сторону регресса. Автоматизация не заменит человека, это и так понятно, но она является подушкой для тестировщиков. И где ей лучше всего если не в регрессе? Где ещё лучше реализуются плюсы автоматизации как не в рутине?

[TatyanaV]

Я тоже не согласна. Есть вещи, которые ДОЛЖНЫ оставаться неизменными вне зависимости от каких либо не связанных с ними доработок системы, и которые критичны для проверки. 

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

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

[Сергей]

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

[Spock]

 

 

Мне совсем не понятен бросок камня в сторону регресса. Автоматизация не заменит человека, это и так понятно, но она является подушкой для тестировщиков. И где ей лучше всего если не в регрессе? Где ещё лучше реализуются плюсы автоматизации как не в рутине?

автор утверждает что вот это “Automate your regression” не имеет смысла

 

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

[SALar]

Мне совсем не понятен бросок камня в сторону регресса. Автоматизация не заменит человека, это и так понятно, но она является подушкой для тестировщиков. И где ей лучше всего если не в регрессе? Где ещё лучше реализуются плюсы автоматизации как не в рутине?

Естественно  Ладно, не естественно. Но если немного подумать, то автоматизировать надо те тесты, которые находят ошибки. И начинать автоматизацию поиска ошибок естественно (ладно, надо немного подумать), надо не с регрессионного тестирования.

 

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

 

PS. Приходите на посиделки. Обсудим досконально.

[TatyanaV]

"Автоматизировать надо те тесты, которые находят ошибки"...

Хм... Т.е. если тест перестал находить ошибки (всё пофиксили ) - он больше не нужен? Или всё же нужен, чтобы убедиться, что ошибки не вернулись? 

А если тест не находит ошибок сейчас, но это функционал, который крайне критичен (его поломка может привести к серьезным финансовым потерям организации) - его не надо автоматизировать, т.к. он "не находит ошибки"? Ждём пока начнёт находить? Так организация уже успеет на этом деньги потерять. Или всё же лучше критичный функционал проверять изначально?

[Сергей]

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

[TatyanaV]

Так статья об автоматизации в целом, а не о том, с чего "начинать".

[Spock]

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

 

писать юнит тесты, компонентные тесты, добавлять АПИ тесты, ну и потом е2е тесты. в итоге регрессионный скрипт вместе со всеми регрессионными тестировщиками станут просто лишними и никому не нужными

[TatyanaV]

Ситуации бывают разные, но все меряют по себе.

У нас лишнее => у всех лишнее.

Нам не нужно => никому не нужно.

Слишком однобоко, как мне кажется.

[Spock]

 

Ситуации бывают разные, но все меряют по себе.

У нас лишнее => у всех лишнее.

Нам не нужно => никому не нужно.

Слишком однобоко, как мне кажется.

ну так и расскажите про свою ситуацию, а так это просто "труизм", сказать что "у всех ситуации разные", это никакой не аргумент

[TatyanaV]

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

При этом неверно принятое решение - может привести к серьезным финансовым потерям. 

Проверки не абстрактные, а вполне конкретные, и их не две-три, а достаточно много.

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

[Spock]

 

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

При этом неверно принятое решение - может привести к серьезным финансовым потерям. 

Проверки не абстрактные, а вполне конкретные, и их не две-три, а достаточно много.

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

смотрим:

у вас есть критический функционал, то есть например есть список фич отсортированный по критичности

вот для начала процесса автоматизации можно и добавить тесты для критического функционала (если на проекте автоматизация практически отсутствует). тесты добавлять используя список фич

 

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

[TatyanaV]

Вы опять пишете про "начало". Нужны ли ручные тесты перед автоматизацией, с чего начинать, что надо делать "сразу" и т.д.

Статья (и я тоже) - об автоматизации в целом. 

 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

Я ничего не писала о том, с чего надо начинать, я не про это вообще пишу.

 

п.с.: Я работаю в банке и, к сожалению, не могу расписать подробнее, могу лишь сказать, что это весьма далеко от того "списка фич" с пропадающими кейсами, который представили себе Вы. И они не "отсортированы по критичности" - они одинаково критичны, неработоспособность ЛЮБОЙ из этих проверок - блокирующая проблема.

[TatyanaV]

del

[Spock]

 

 

Я возразила против тезиса о том, что регрессионный тест вообще не надо автоматизировать. 

тезис о том, что "ручной регрессионный тест не надо автоматизировать" правилен

 

так как автоматизировать надо "тестирование фич", а не "ручные тесты которые тестируют только видимую часть фичи"

[SALar]

А вообще о том, "что надо, что не надо" замечательно написал Деминг.Книга "Выход из кризиса", главы 1 и 15.

 

К сожалению тестировщики не читают книг величайшего специалиста по качеству. И в итоге... Ну, вы поняли. 

[DReeborn]

 

 

 

Мне совсем не понятен бросок камня в сторону регресса. Автоматизация не заменит человека, это и так понятно, но она является подушкой для тестировщиков. И где ей лучше всего если не в регрессе? Где ещё лучше реализуются плюсы автоматизации как не в рутине?

автор утверждает что вот это “Automate your regression” не имеет смысла

 

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

 

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

"Прокликивание кнопок" тоже кейс и тоже имеет место быть, и чтобы не делать из тестеров манки-тестеров, почему не дать эту работу автотесту? Этот кейс идеально подходит под автоматизацию и плохо подходит для ручного тестирования, в чём же подвох? Разве автоматизация таких "прокликов" не даст людям больше время на творчество, что наверное и есть главной целью автоматизации как таковой?

З.Ы. Я могу быть не прав, т.к. нов в этой области, поэтому прошу объяснить если я в чём то ошибаюсь.

[Spock]

 

 

"Прокликивание кнопок" тоже кейс и тоже имеет место быть, и чтобы не делать из тестеров манки-тестеров, почему не дать эту работу автотесту? Этот кейс идеально подходит под автоматизацию и плохо подходит для ручного тестирования, в чём же подвох? Разве автоматизация таких "прокликов" не даст людям больше время на творчество, что наверное и есть главной целью автоматизации как таковой?

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

 

например:

наше приложение это форум. Есть требование: удалять чужие сообщения может только пользователь с правами модератора. 

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

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

 

вроде всё прокликали, что могло пойти не так?

 

в результате оказывается что используя РЕСТ АПИ любой пользователь может удалять чужие сообщения! так как контроль доступа на бэк-энде сломался либо его забыли имплементировать вообще, и только на фронте кнопка появлялась или исчезала, а бэкэнд оказывается всегда исполняет команды

 

а как надо было?

 

надо было автоматизировать не ручные тесты, а требование "удалять чужие сообщения может только пользователь с правами модератора", тогда были бы созданы юнит и/или АПИ тесты про права доступа, плюс е2е тесты про кнопку