Комментарии 44
2) Написать каркас тестов + интеграцию с jenkins(teamCity) — трудоемко и сложно.
3) Расширять тесты — легко (там вообще хватает начальных навыков Java + базовое понимание html/css/js + Rest API)
__
Но как правило, если человек более менее начинает разбираться в тестах, он переходит в разработку на Java. Ибо там платят гораздо больше, чем в QA (если ты не тот самый чел, который делает пункт 2)
Иначе можно получить портянку автотестов, которые выполняются часами и проверяют, что система правильно складывает 2+2
Мне, например, хочется в DevOps потом двигаться больше. В будущем, прикрутить свои тесты к CI/ CD было бы здорово. Да и вакансий таких все больше появляется.
Ручная проверка никуда не денется
В некоторых отраслях возможно. Но в тоже время при текущей модели разработки приложений, а именно очень частые релизы, обилие встроенных инструментов телеметрии и обратной связи, то в какой то мере можно сказать что сейчас многие ошибки отлавливаются на реальных пользователях и тут же достаточно быстро развертывается исправление.
Ручная проверка никуда не денется. Так или иначе, когда мы видим перед собой новую фичу или целый продукт, мы будем изучать его руками. Нам все равно необходимо разобраться с тем, как он устроен, какие кейсы считать приоритетными и вообще, работают ли они сейчас.
Для меня это не «ручное тестирование», а скорее «фаза анализа». И её действительно придётся делать всегда.
Но во первых это совсем не обязательно «делать руками». То есть даже если сейчас другого инструментария нет, он вполне себе может появиться позже.
А во вторых само тестирование начинается уже после этого. И его можно либо делать вручную(то есть десятки и сотни раз одни и те же телодвижения), либо каким-то образом автоматизировать и сэкономить себе кучу времени и нервов.
Ну и в третьих уже сейчас часто встречается что «фазу анализа» делает один человек, а само «тестирование»(ну или как минимум итерации начиная со второй) другой/другие.
И поэтому с моей точки зрения рано или поздно автоматизация заменит ручное тестирование.
Непонятно что вы вкладываете в слово "заменит".
Например: возможно ли создать программу, решающую задачи клиента в приемлемом для него качестве, при этом тестирование которой вручную не выполняется на хоть сколько-нибудь регулярной основе и в команду разработки которой не входят выделенные QA, занимающиеся ручным тестированием? Конечно, да.
при этом тестирование которой вручную не выполняется на хоть сколько-нибудь регулярной основе
Тогда за качество будут отвечать разработчики. Может у них получиться выпустить продукт хорошего качества? Конечно может!
Но я говорил скорее о том, что если все же тестирование необходимо, возможно ли его полностью передать автоматике? И склоняюсь к тому, что без определенной экспертизы — нет, нельзя.
Позвольте с вами не согласиться.
А иначе зачем мы здесь? :)
Работать с большой кодовой базой это сложно. Разраьотчики это умеют, а тестировщики — нет.
Я бы не был столь категоричен, оценивая навыки тестировщиков программировать. Это не настолько элитарный навык, чтобы его невозможно было освоить за год или два на приемлемом для работы с большой кодовой базой тестов уровне.
Вы все верно говорите, для описанной Вами задачи потребуется и много тестов, и их стабилизация. И без помощи со стороны разработки обойтись будет сложно. Ну, никто и не предлагал запираться в пещере и писать тесты втихую. :)
Без хорошего кода ваши автотесты далеко не уйдут ;)
Как бы круто не были написаны тесты, если они не проверяют реальные юзер-кейсы в достаточном объеме, то, особенно на «немаленьком продукте», их ценность мала. И потому именно покрытие первично, так как оно решает бизнес-задачу. А качество кода вторично. Я это имел в виду.
Вот Вам пример простой (бесплатной) формы с учетом проверенных кейсов, на которой можно оценить все их разнообразие, требующее проверки: ссылка.
О каком количестве этих кейсов подумает человек, не занимающийся тестированием?
Просто как менеджер проекта, например… между плохой кодовой базой тестов, но богатым покрытием и наоборот я выберу именно первый вариант. Да, будут проблемы с допиливанием, рефакторингом, внесением изменений и расширением. Особенно если никто в команде этого не умеет. Но это проблемы внутренние, пользователи о них ничего не знают. Зато благодаря покрытию продукт тестируется хорошо и наружу выйдет качественным. И это увидит пользователь.
И я сравнивал это, конечно, с альтернативой — хороший код, но плохое покрытие. Потому что сравнивать это с хорошим кодом И хорошим покрытием как-то глупо. :)
"Последние всегда писались и должны писаться разработчиками,"
Как только появляется слово должен, или слово обязательно, тема из раздела аналитики переходит в раздел религии, особенно для начинающих, читающих статью авторитета и складывающих как мартышки на задворки бессознательного все эти" должен" и" надо обязательно", не рассматривая все плюсы и минусы и не анализируя. Особенно этим грешат американцы, которым все нужно перевести в технологию, чтобы не страдало их квадратное мышление.
Преимуществом юнит тестов называется быстрота проверки. Но куда вы торопитесь? Вам нужно релизить через секунду после каждого изменения? Вы не в состоянии подождать 10 минут прогон функциональных тестов? А если вы захотите сделать рефакторинг модуля, вы четырежды подумаете, поскольку придется юнит тесты переписывать, при том что логика самого функционала не поменялась ни на йоту.
Так что в каждом конкретном случае нужно думать и анализировать ситуацию на проекте в целом, а не зомбировать незыблемыми заповедями.
Вы спорите с утверждением, что "юнит-тесты должны писаться", хотя автор написал, что "если на проекте пишутся юнит-тесты, то это должны делать разработчики, а не тестировщики".
А если вы захотите сделать рефакторинг модуля, вы четырежды подумаете, поскольку придется юнит тесты переписывать, при том что логика самого функционала не поменялась ни на йоту.
Вот из этого видно, что Вы юнит-тесты никогда не писали. Они пишутся на API класса, а при рефакторинге API не меняется, соответственно, тесты переписывать не нужно.
Более того, при рефакторинге юнит-тесты гарантируют, что ничего не сломалось — ибо поведение класса для внешнего мира не изменилось.
А что с применением всяческих там нейронных сетей для автоматизации труда ручного тестирования? Ну типа, сетка глядит-глядит на то, как человек все прокликивает, а потом начинает сама прокликивать.
П.С. Я совсем не отрицаю необходимость грамотных QSников, но почти во всех фирмах где я работал 50-75% от всех тестировщиков были простые «кликеры» которые тупо тестировали по готовым тесткейсам…
Я совсем не отрицаю необходимость грамотных QSников
Именно о них и речь. Грамотные тестировщики против грамотных фул-тайм автоматизаторов. Как только мы говорим, что по одну из чаш весов «кликер» или «быдлокодер», сравнение уже не корректно. Квалификации должны быть соизмеримы для сравнения. Согласны?
П.С. И наверное опять есть некая путаница в понятиях и разные люди понимают разное под «ручной тест» или «тестировщик».
Для меня «грамотный тестировщик» подразумевает под собой, что он при необходимости умеет и автоматизировать.
Суть моей статьи в одном предложении. Спасибо! :)
Да, именно так и должно быть, кмк. Но увы, рынок сейчас устроен иначе. Есть те, кто по разным причинам занимается только ручным тестированием.
Это не всегда люди ленивые или глупые. Порой проблема кроется в самой компании. Даже в крупных есть разделение на тех, кто занимается автоматизацией фул-тайм, и тех, кто должен заниматься только ручным тестированием и в автоматизацию не лезть никогда, ни за что. Отчасти из-за этого последним и кажется, что автоматизация тестирования — это что-то вроде левел-апа в карьере, следующего витка развития и что-то элитарное. И именно с этим стереотипом хочется бороться или как минимум высказываться против него.
Отличная статья. Полностью согласен с автором, автотесты не заменят ручного тестирования.
Ну вот и до хабра дошла эта тема. Правда вопрос-то обычно стоит немножно по-другому.Не "заменит ли автоматизация ручное тестирование", а "заменит ли автоматизация ручных тестировщиков". И если первая формулировка имеет очевидный ответ "нет", то вот вторая рождает мильон споров.
Ок, а кто же будет проводить ручное тестирование? :)
Можно делать как в геймдеве — выпускать платную бета-версию, чтобы получать фидбэк от пользователей непосредственно)
Никакого противоречения. Активность "я руками потыкал" с разной степенью интеллектуальности проводится абсолютно всеми. Ну кроме тех исключительных товарищей, которые коммитят вслепую.
А по поводу "ручных тестировщиков" можно начать препарацию типа "отдельный специалист-тестировщик" или "тестировщик, который владеет исключительно навыками ручного тестирования". По обоим пониманиям существует интересная позиция, вытекающая из принципов Modern Testing (если кратко, оба варианта — вымирающие, ибо будущее за unified engineering и test coaches). Есть и другие позиции, как писала, споров валом на эту тему))
Заменит ли автоматизация ручное тестирование?