Как стать автором
Обновить

Комментарии 44

1) Мысли правильные
2) Написать каркас тестов + интеграцию с jenkins(teamCity) — трудоемко и сложно.
3) Расширять тесты — легко (там вообще хватает начальных навыков Java + базовое понимание html/css/js + Rest API)
__

Но как правило, если человек более менее начинает разбираться в тестах, он переходит в разработку на Java. Ибо там платят гораздо больше, чем в QA (если ты не тот самый чел, который делает пункт 2)
Хм. По-моему как раз каркас пишется сравнительно несложно, в сети куча мануалов и best practices, если нет особых заморочек специфичных для проекта, то < недели с минимум опыта. Расширять сложнее в плане дизайна тестовых сетов, надо постоянно отвечать на вопросы «надо ли это автоматизировать вообще или быстрее/дешевле оставить на мануале» и «какие конкретно кейсы автоматизировать».

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

Мне, например, хочется в DevOps потом двигаться больше. В будущем, прикрутить свои тесты к CI/ CD было бы здорово. Да и вакансий таких все больше появляется.

Мы на курсе по автоматизации как раз учим тому, как написанные тесты для Android и iOS прикрутить к Jenkins. Приходите, если будет интересно. Ссылка есть в профиле.
К сожалению (или счастью), у меня бэкенд на Go + gRPC. Там своя атмосфера (:
Java-разрабов пруд-пруди, а вот толковых qa-специалистов на рынке мало, и их готовы брать на высокие ставки. Не согласен с вашим «как правило» )
НЛО прилетело и опубликовало эту надпись здесь
Ручная проверка никуда не денется

В некоторых отраслях возможно. Но в тоже время при текущей модели разработки приложений, а именно очень частые релизы, обилие встроенных инструментов телеметрии и обратной связи, то в какой то мере можно сказать что сейчас многие ошибки отлавливаются на реальных пользователях и тут же достаточно быстро развертывается исправление.
Я думаю, зависит от приложения. Всякий «интертеймент» — возможно, и правильно!
А как насчет банковского софта, например? Там на живых пользователях не получится экспериментировать.
Ручная проверка никуда не денется. Так или иначе, когда мы видим перед собой новую фичу или целый продукт, мы будем изучать его руками. Нам все равно необходимо разобраться с тем, как он устроен, какие кейсы считать приоритетными и вообще, работают ли они сейчас.

Для меня это не «ручное тестирование», а скорее «фаза анализа». И её действительно придётся делать всегда.

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

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

Ну и в третьих уже сейчас часто встречается что «фазу анализа» делает один человек, а само «тестирование»(ну или как минимум итерации начиная со второй) другой/другие.

И поэтому с моей точки зрения рано или поздно автоматизация заменит ручное тестирование.

Непонятно что вы вкладываете в слово "заменит".


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

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

Тогда за качество будут отвечать разработчики. Может у них получиться выпустить продукт хорошего качества? Конечно может!

Но я говорил скорее о том, что если все же тестирование необходимо, возможно ли его полностью передать автоматике? И склоняюсь к тому, что без определенной экспертизы — нет, нельзя.
Пусть люди из будущего на Хабре из будущего думают об этой дилемме :)
Тем более хороший код — это не самое главное в автотестах.

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


Вам будут нужны много доработок по тестируемости приложения — без них вы не сможете сделать тесты с 99,99% стабильностью и они будут только мешать. Разработчики могут вносить правки в приложение, а тестировщики не могут (плохо кодят + не знают код продукта).


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


Без хорошего кода ваши автотесты далеко не уйдут ;)

Позвольте с вами не согласиться.

А иначе зачем мы здесь? :)

Работать с большой кодовой базой это сложно. Разраьотчики это умеют, а тестировщики — нет.

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

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

Без хорошего кода ваши автотесты далеко не уйдут ;)

Как бы круто не были написаны тесты, если они не проверяют реальные юзер-кейсы в достаточном объеме, то, особенно на «немаленьком продукте», их ценность мала. И потому именно покрытие первично, так как оно решает бизнес-задачу. А качество кода вторично. Я это имел в виду.

Вот Вам пример простой (бесплатной) формы с учетом проверенных кейсов, на которой можно оценить все их разнообразие, требующее проверки: ссылка.

О каком количестве этих кейсов подумает человек, не занимающийся тестированием?
Про код тестов я с вами не согласен. Даже у многих разработчиков навыки поддержки больших кодовых баз не очень хороши. При том, что они full time работают с кодом. Тестировщикам еще сложнее приобрести эти навыки, потому что кроме кода, у них много других дел и нет опытного наставника-разработчика. А проблемы в больших кодовых базах с тестами — такие же злобные, как в продакшн коде.

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

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

И я сравнивал это, конечно, с альтернативой — хороший код, но плохое покрытие. Потому что сравнивать это с хорошим кодом И хорошим покрытием как-то глупо. :)
Выбирая плохое качество кода в тестах, вы также получаете:

  • Долгую поставку фич. Например, потому что тесты писать сложнее и сложнее. Или потому что они нестабильные, надо возиться с их падениями.
  • Озлобленных инженеров. «на фичу ушел день, а только на написание тестов еще три дня» — такое бесит людей. Еще людей раздражает писать плохой код, потому что они начинают себя с ним ассоциировать :)
  • Длинный цикл обратной связи для разработчиков. Если программисту сложно проверить, как работает его код — он попросит тестировщиков. И о багах в основном сценарии узнает не сразу, а через много времени. Это тоже сильно удлинняет время поставки фич.


Я думаю, что менеджеров проектов должны волновать такие вещи. Как минимум, на долгих проектах.

Хорошее качество обеспечить можно и с ручным тестированием. Между хорошим кодом с плохим покрытием и плохими тестами с хорошим покрытием я бы выбрал первое.

Между хорошим кодом с плохим покрытием и плохими тестами с хорошим покрытием я бы выбрал первое.

Ваше право. Мои аргументы тут исчерпаны. :)

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


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


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


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

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


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

Вот из этого видно, что Вы юнит-тесты никогда не писали. Они пишутся на API класса, а при рефакторинге API не меняется, соответственно, тесты переписывать не нужно.
Более того, при рефакторинге юнит-тесты гарантируют, что ничего не сломалось — ибо поведение класса для внешнего мира не изменилось.

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

Ну типа, а если проект меняется? Добавляется совершенно новая фича? Обратно нанимать отдел тестирования, чтобы обучить нейронку? :)
Как насчёт оставить пару-тройку «QS-инженеров» для таких случаев, а всех остальных заменить на «нейронку» или какой-то другой вариант автоматизации?

П.С. Я совсем не отрицаю необходимость грамотных QSников, но почти во всех фирмах где я работал 50-75% от всех тестировщиков были простые «кликеры» которые тупо тестировали по готовым тесткейсам…
Видимо, в тех случаях, о которых говорите Вы, это было дешевле. Не знаю, тут надо на более определенных примерах смотреть и рассуждать.

Я совсем не отрицаю необходимость грамотных QSников

Именно о них и речь. Грамотные тестировщики против грамотных фул-тайм автоматизаторов. Как только мы говорим, что по одну из чаш весов «кликер» или «быдлокодер», сравнение уже не корректно. Квалификации должны быть соизмеримы для сравнения. Согласны?
Если честно, то я до сих пор вообще не проводил грани между «грамотными тестировщиками» и «грамотными фул-тайм автоматизаторами». Для меня «грамотный тестировщик» подразумевает под собой, что он при необходимости умеет и автоматизировать. Ну или как минимум может этому научиться :)

П.С. И наверное опять есть некая путаница в понятиях и разные люди понимают разное под «ручной тест» или «тестировщик».
Для меня «грамотный тестировщик» подразумевает под собой, что он при необходимости умеет и автоматизировать.

Суть моей статьи в одном предложении. Спасибо! :)

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

Это не всегда люди ленивые или глупые. Порой проблема кроется в самой компании. Даже в крупных есть разделение на тех, кто занимается автоматизацией фул-тайм, и тех, кто должен заниматься только ручным тестированием и в автоматизацию не лезть никогда, ни за что. Отчасти из-за этого последним и кажется, что автоматизация тестирования — это что-то вроде левел-апа в карьере, следующего витка развития и что-то элитарное. И именно с этим стереотипом хочется бороться или как минимум высказываться против него.
Лайк!) Полностью согласен) Сразу видно что эту статью писал человек у которого есть необходимые знания и компетенция в тестировании, потому что все всегда начинается с ручного тестирования и тест-дизайна, организации методологий эффективной работы и включения тестирования в цикл… Кто бы там на своих конфах что не говорил, но я точно знаю, когда что-то начнет валиться и разваливаться, все быстро побегут искать тестировщиков))
:)

Отличная статья. Полностью согласен с автором, автотесты не заменят ручного тестирования.

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

Хм. Я вижу противоречие. Т.е. автоматизация не заменит ручное тестирование, но заменит ручных тестировщиков. Ок, а кто же будет проводить ручное тестирование? :)
Ок, а кто же будет проводить ручное тестирование? :)

Можно делать как в геймдеве — выпускать платную бета-версию, чтобы получать фидбэк от пользователей непосредственно)
автоматизаторы. Просто сначала щупаешь фичу глазами, потом пишешь на нее автотесты. Очень удобно
Щупаешь фичу глазами, а она уже в проде и не работает. Удобно. :)
не очень поняла, почему в проде? Это нормальный процесс: разработка — тестирование — прод.
UI-тесты на фичу зачастую (не всегда, а зачастую) пишут ПОСЛЕ релиза фичи.
А почему?
Навскидку, один из примеров — дорого. Бывают сервисы, которые активно выпускают новые фичи. Часто релизятся (например, в компании, где я работаю, релизы два раза в день). Проводится много А/Б-тестов на фичи. Все это покрывать UI-тестами быстро не получится. Да и смысла большого нет. Чаще всего покрывается фича в уже устоявшемся состоянии, когда все метрики по ней были собраны и было принято решение о том, как будет работать ее итоговая версия. Конечно, если от нее не решили отказаться. :)
с одной стороны, это весомый аргумент
с другой, я полтора года пишу тесты перед мерджем ветки в мастер, это позволяет как минимум не думать о регрессе вообще. Но у меня нет UI.
Как я и сказал — ситуации бывают разные, процессы бывают выстроены по-разному. Так что не всем подойдет флоу, чтобы автоматизатор руками тестировал фичу вместо ручного тестировщика…
Да и в целом это просто замена исполнителя, а я выше хотел больше про процессы писать.
Первый раз всё равно внимательно всё щупается и проверяется. А вот потом особо внимательно уже никто все «старые» фичи не тестит. И тогда полезно иметь хотя бы автотесты чтобы заметить что в новом релизе вдруг сломали что-то из «старых» фич.

Никакого противоречения. Активность "я руками потыкал" с разной степенью интеллектуальности проводится абсолютно всеми. Ну кроме тех исключительных товарищей, которые коммитят вслепую.
А по поводу "ручных тестировщиков" можно начать препарацию типа "отдельный специалист-тестировщик" или "тестировщик, который владеет исключительно навыками ручного тестирования". По обоим пониманиям существует интересная позиция, вытекающая из принципов Modern Testing (если кратко, оба варианта — вымирающие, ибо будущее за unified engineering и test coaches). Есть и другие позиции, как писала, споров валом на эту тему))

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории