Тестирование ПО (Тестировщик, QA инженер)

dammitt:

DenisN89, а мне семенченко нравится, у него очень клевые доклады и манера их вести ну и мысли иногда не стандартные озвучивает

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

DenisN89:

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

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

p/s личное мнение, оно может меняться если будут аргументы) (не предвзят, т.к. сам не авто.)
p/s p/s упоминание unit тестов какбы вообще не относится к теме автоматизации в контексте сравнения с manual testing

aleeeeenka, пару советов
1) Дизайн это не только UI. Это еще и функциональная часть. Грубо говоря, сразу проясните, требуется ли тестирование исключительно интерфейса или еще и функциональное.
2) UI тестирование выполянется по различным методикам. Ключевой момент - требуется ли pixel perfect. Если да, то сразу проверяем дизайн документ, указаны ли все измерения для всех элементов, цвета. Responsive design или нет туда же.
3) Обязательно в любом случае прояснить скоуп тестирования по браузерам (десктопные, мобильные, различные версии ОС, различные девайсы, в особо запущенных случаях даже различные версии самих браузеров)
4) Тулзы в помощь, особенно для пиксель-перфект. Куча расширений для браузеров имхо наиболее удобны. Гугл поможет подобрать.

Ну для начала, думаю достаточно.

Спасибо за советы!!
На данном этапе pixel perfect не обязателен(но я все равно хочу и это уметь)

DeathInfector:

DenisN89:

А сотни (тысячи) тест кейсов автоматизировать это вообще бесперспективное занятие. Реальный выхлоп от такого небольшой..

Абсолютли согласен.
Обычно приводят пример, что
Если для фичи А на проверку у мануальщика уходит 5 минут, а на написание теста а автоматизатора уходит 4 часа, то надо 48 проверок, чтобы только компенсировать изначальные временные затраты (не включая затраты на сопровождение написанного теста).

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

aleeeeenka:

Спасибо за советы!!
На данном этапе pixel perfect не обязателен(но я все равно хочу и это уметь)

Уметь наложить 2 картинки друг на друга? Какой же п* твориться сейчас в тестировании.

DenisN89:

DeathInfector:

DenisN89:

А сотни (тысячи) тест кейсов автоматизировать это вообще бесперспективное занятие. Реальный выхлоп от такого небольшой..

Абсолютли согласен.
Обычно приводят пример, что
Если для фичи А на проверку у мануальщика уходит 5 минут, а на написание теста а автоматизатора уходит 4 часа, то надо 48 проверок, чтобы только компенсировать изначальные временные затраты (не включая затраты на сопровождение написанного теста).

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

+100000%. Заметила, что вопрос "а рассматриваете ли вы в будущем изучать автоматизацию?" чаще всего задают в аутсорс-конторах. И понятно, почему: автоматизатора продать проще и дороже, чем мануал. Конечно, я думаю, что заказчик может посчитать простейший ROI и задать вопрос о смысле использования автоматизации, но чаще всего такое не происходит + менеджеры навешают лапши, что с автоматизацией все будет збс точно.

На практике же проектов, на которых действительно требуется автоматизация (не потому что хайп, а потому что она оправдана) - это супердлительные проекты крупных контор типа Audi, BMW, Nike, какой-нибудь крупный трейдинговый кастомер с длительным проектом и суперстабильными требованиями. По факту же таких проектов не так много, а для не таких гигантских и длительных проектов мануал при хорошей оптимизации кейсов и нормальном их апдейте затыкает за пояс плюсы авто потому что тестить можно здесь и сейчас, сразу же, а не ждать, пока авто кейс напишет, а потом его и заавтоматизирует + мануал может проверить различные трики-кейсы + сложные эрии для автоматизации + при частом изменении требований (привет, АДжайл)) плюсы автоматизации вообще сомнительны)

И да, кстати. По поводу аквы. Не удивлена, что там вырос так сильно департамент автоматизаторов. Как я уже сказала, продавать их лучше, дороже, а менеджеры кастомерам всегда могут правильно обосновать нужность авто. Но блин) Я узнала, что в той же акве автоматизатор - это не человек, который пишет кейсы, а потом их автоматизирует. Автоматизатор в этой конторе просто автоматизирует кейсы, которые УЖЕ написаны ручником или кем-то там. То есть автоматизатор вообще не заменяет ручника, это еще один человек, на котором аутсорс рубит бабки.

zffman:

У меня на работе многие мануальщики имеют хотя бы минимальный опыт автоматизации уже. Кто на JS поддерживает готовые UI-тесты, кто на питоне, кто на опять же JS колбасит скрипты для Postman-а.

А смысл? Если проект состоит из одних вызовов api, то там тестировщик вообще не нужен. Разработчики сразу могут написать проверки и их использовать потом. Ui тесты вообще особо смысла автоматизировать не вижу, так как время на создание тестов никогда не отобьется

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

Slovopyt:

акве автоматизатор - это не человек, который пишет кейсы, а потом их автоматизирует. Автоматизатор в этой конторе просто автоматизирует кейсы, которые УЖЕ написаны ручником или кем-то там

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

Legart_1:

Подскажите знающие люди, берут ли Junior QA Automation без опыта мануального тестирования? На что обращают внимание при трудоустройстве? спасибо.

Из технического - ООП, работа со списками, дженерики, регулярки, апи запросы, xpath, selenium. А если еще и Дженкинс настроите, то оторвут с руками и ногами. Ну и английский, хотя по нему требования поменьше чем у мануальщиков.