Не тянешь на программиста — иди в QA?

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

В Фейсбуке встретил рекламу с завлекаловом:

Профессия QA идеально подходит для тех, кто хочет работать в IT, но не видит себя программистом

И случился у меня баттхерт. Здесь и далее я буду регулярно путать QA и QC, за что сразу ж посыпаю голову пеплом. Говорю о крупных-аутсорсерах, потому что в конторах помельче зачастую просто не выделяют отдельную позицию, ну, а где выделяют — требования всё ж помягче.

А еще — речь скорее о Manual QC. Написание интеграционных автотестов — там уже проще, но такой зверь всё еще редкий.
Так вот. О мифе. Мифе про «низкий порог входа».

1. От джуна QC ждут, что он достаточно хорошо знает английский. Если он не в состоянии зарепортить багу, чтоб её можно было воспроизвести — он просто тратит время команды впустую. От девелопера такого не ждут. Если толковый, но даже письмо написать не сможет — окей, возьмут под «честное слово» обучиться, и попервой за него будет говорить кто-то из команды.

2. От джуна QC ждут и других софт-скиллов. Например, коммуникативности(пояснить), настойчивости(девелопер убеждает, что это «не наше дело» и «давай, не будем больше никого трогать и просто закроем багу»). И это не полный список, да.

3. Джуну QC сложно продемонстрировать навыки. «Тестирование карандаша» — неизбежное зло, где-то на уровне «а теперь напишите на бумаге работу с красно-черным деревом» для разработчика. Если разработчик может сделать тестовое задание или предъявить репо на github, джун QC на собеседовании может только рассказать, какой он обучаемый.
Да, когда есть ICTQB-сертификат становится легче, но я говорю о старте и джунах.

4. Если накосячит джун-разработчик — его страхует тима: даже если формального код-ревью не происходит — код все равно читается остальными. И еще его тестируют автотесты и тот же отдел QC.
Если накосячит джун-QC(невнимательно пройдется по шагам баги и закроет все еще актуальное), может быть все что угодно(точнее, только одно — упущенные проблемы). А дублировать всё-всё, сделанное джуном QC — попросту не рационально.

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

tl; dr; От новичка QC ожидают большего, чем от новичка-разработчика. Причем требования плохо формализованы и сложнопроверяемы. Так что по окончанию курсов QC сложнее «войти в айти».

Посмотрите на статистику вакансий на ДОУ. QC-вакансий меньше, чем сугубо PHP-шных. Потому что взять 3 джунов девелоперов и одного синьора над ними — имеет смысл(хотя, как бизнес-план так себе). А 3 джунов QA и одного тестлида — уже тянет на диагноз.

PS Пожалуйста, не «идите в QC» только потому, что вам рассказали, какой там низкий порог входа. Реальность настигнет очень быстро. И больно.

[UPD] загляните в тему со смежной точкой зрения: Свитчерам в IT