О, это совсем жесткий случай. На 99% приложениях даже не могу придумать, какая часть аудитории отвалится, если что-то не работает при этом режиме… но всегда есть 1% какой-нибудь специфики.
Спасибо!
Мы на курсе по автоматизации как раз учим тому, как написанные тесты для Android и iOS прикрутить к Jenkins. Приходите, если будет интересно. Ссылка есть в профиле.
Для меня «грамотный тестировщик» подразумевает под собой, что он при необходимости умеет и автоматизировать.
Суть моей статьи в одном предложении. Спасибо! :)
Да, именно так и должно быть, кмк. Но увы, рынок сейчас устроен иначе. Есть те, кто по разным причинам занимается только ручным тестированием.
Это не всегда люди ленивые или глупые. Порой проблема кроется в самой компании. Даже в крупных есть разделение на тех, кто занимается автоматизацией фул-тайм, и тех, кто должен заниматься только ручным тестированием и в автоматизацию не лезть никогда, ни за что. Отчасти из-за этого последним и кажется, что автоматизация тестирования — это что-то вроде левел-апа в карьере, следующего витка развития и что-то элитарное. И именно с этим стереотипом хочется бороться или как минимум высказываться против него.
Просто как менеджер проекта, например… между плохой кодовой базой тестов, но богатым покрытием и наоборот я выберу именно первый вариант. Да, будут проблемы с допиливанием, рефакторингом, внесением изменений и расширением. Особенно если никто в команде этого не умеет. Но это проблемы внутренние, пользователи о них ничего не знают. Зато благодаря покрытию продукт тестируется хорошо и наружу выйдет качественным. И это увидит пользователь.
И я сравнивал это, конечно, с альтернативой — хороший код, но плохое покрытие. Потому что сравнивать это с хорошим кодом И хорошим покрытием как-то глупо. :)
Видимо, в тех случаях, о которых говорите Вы, это было дешевле. Не знаю, тут надо на более определенных примерах смотреть и рассуждать.
Я совсем не отрицаю необходимость грамотных QSников
Именно о них и речь. Грамотные тестировщики против грамотных фул-тайм автоматизаторов. Как только мы говорим, что по одну из чаш весов «кликер» или «быдлокодер», сравнение уже не корректно. Квалификации должны быть соизмеримы для сравнения. Согласны?
Я думаю, зависит от приложения. Всякий «интертеймент» — возможно, и правильно!
А как насчет банковского софта, например? Там на живых пользователях не получится экспериментировать.
Работать с большой кодовой базой это сложно. Разраьотчики это умеют, а тестировщики — нет.
Я бы не был столь категоричен, оценивая навыки тестировщиков программировать. Это не настолько элитарный навык, чтобы его невозможно было освоить за год или два на приемлемом для работы с большой кодовой базой тестов уровне.
Вы все верно говорите, для описанной Вами задачи потребуется и много тестов, и их стабилизация. И без помощи со стороны разработки обойтись будет сложно. Ну, никто и не предлагал запираться в пещере и писать тесты втихую. :)
Без хорошего кода ваши автотесты далеко не уйдут ;)
Как бы круто не были написаны тесты, если они не проверяют реальные юзер-кейсы в достаточном объеме, то, особенно на «немаленьком продукте», их ценность мала. И потому именно покрытие первично, так как оно решает бизнес-задачу. А качество кода вторично. Я это имел в виду.
Вот Вам пример простой (бесплатной) формы с учетом проверенных кейсов, на которой можно оценить все их разнообразие, требующее проверки: ссылка.
О каком количестве этих кейсов подумает человек, не занимающийся тестированием?
Конечно да. Но тут Вы говорите о возможности отказаться от тестирования:
при этом тестирование которой вручную не выполняется на хоть сколько-нибудь регулярной основе
Тогда за качество будут отвечать разработчики. Может у них получиться выпустить продукт хорошего качества? Конечно может!
Но я говорил скорее о том, что если все же тестирование необходимо, возможно ли его полностью передать автоматике? И склоняюсь к тому, что без определенной экспертизы — нет, нельзя.
Все верно. Только Selenide — это фреймворк на Java, который использует Selenium. Мои слова Вашим не противоречат. :)
Более того, Selenide навязывает Java для использования. Может быть человек хочет писать на Python, например? Зачем его ограничивать Selenide? А вот Selenium ему все равно понадобится. Такие дела.
Безусловно. Но тут я собрал пока только то, что начинается с Selen… так как созвучные, но разные по сути инструменты сбивают с толку сильнее, чем инструменты с отличающимся названием. Ну, так по всяком случае мне показалось. :)
Вы правы. Надо будет переписать тест, чтобы ходил в нашу песочницу вместо Инстаграма. Лишь бы зеленым был. А настоящие пользователи, ради которых мы тесты пишем — да и хай на них. Перестанет приложение логинить их через настоящий Инстаграм, скажем, что у нас в тестах все ок, покажем Вашу запись…
— Алло, это пожарная? У нас тут здание девятиэтажное горит!
— Ну не знаем, у нас напротив такое же девятиэтажное здание и оно не горит…
Спасибо!
Ваше право. Мои аргументы тут исчерпаны. :)
Суть моей статьи в одном предложении. Спасибо! :)
Да, именно так и должно быть, кмк. Но увы, рынок сейчас устроен иначе. Есть те, кто по разным причинам занимается только ручным тестированием.
Это не всегда люди ленивые или глупые. Порой проблема кроется в самой компании. Даже в крупных есть разделение на тех, кто занимается автоматизацией фул-тайм, и тех, кто должен заниматься только ручным тестированием и в автоматизацию не лезть никогда, ни за что. Отчасти из-за этого последним и кажется, что автоматизация тестирования — это что-то вроде левел-апа в карьере, следующего витка развития и что-то элитарное. И именно с этим стереотипом хочется бороться или как минимум высказываться против него.
Просто как менеджер проекта, например… между плохой кодовой базой тестов, но богатым покрытием и наоборот я выберу именно первый вариант. Да, будут проблемы с допиливанием, рефакторингом, внесением изменений и расширением. Особенно если никто в команде этого не умеет. Но это проблемы внутренние, пользователи о них ничего не знают. Зато благодаря покрытию продукт тестируется хорошо и наружу выйдет качественным. И это увидит пользователь.
И я сравнивал это, конечно, с альтернативой — хороший код, но плохое покрытие. Потому что сравнивать это с хорошим кодом И хорошим покрытием как-то глупо. :)
Именно о них и речь. Грамотные тестировщики против грамотных фул-тайм автоматизаторов. Как только мы говорим, что по одну из чаш весов «кликер» или «быдлокодер», сравнение уже не корректно. Квалификации должны быть соизмеримы для сравнения. Согласны?
А как насчет банковского софта, например? Там на живых пользователях не получится экспериментировать.
А иначе зачем мы здесь? :)
Я бы не был столь категоричен, оценивая навыки тестировщиков программировать. Это не настолько элитарный навык, чтобы его невозможно было освоить за год или два на приемлемом для работы с большой кодовой базой тестов уровне.
Вы все верно говорите, для описанной Вами задачи потребуется и много тестов, и их стабилизация. И без помощи со стороны разработки обойтись будет сложно. Ну, никто и не предлагал запираться в пещере и писать тесты втихую. :)
Как бы круто не были написаны тесты, если они не проверяют реальные юзер-кейсы в достаточном объеме, то, особенно на «немаленьком продукте», их ценность мала. И потому именно покрытие первично, так как оно решает бизнес-задачу. А качество кода вторично. Я это имел в виду.
Вот Вам пример простой (бесплатной) формы с учетом проверенных кейсов, на которой можно оценить все их разнообразие, требующее проверки: ссылка.
О каком количестве этих кейсов подумает человек, не занимающийся тестированием?
Тогда за качество будут отвечать разработчики. Может у них получиться выпустить продукт хорошего качества? Конечно может!
Но я говорил скорее о том, что если все же тестирование необходимо, возможно ли его полностью передать автоматике? И склоняюсь к тому, что без определенной экспертизы — нет, нельзя.
Более того, Selenide навязывает Java для использования. Может быть человек хочет писать на Python, например? Зачем его ограничивать Selenide? А вот Selenium ему все равно понадобится. Такие дела.
А статью напишите, интересно было бы!
— Алло, это пожарная? У нас тут здание девятиэтажное горит!
— Ну не знаем, у нас напротив такое же девятиэтажное здание и оно не горит…