Вот я всегда любил строить из игрушек огромные миры, но никогда не играл в них. Ещё я любил их разбирать, меня всегда интересовало что там внутри. Потом я вырос и моей игрушкой стал комп, но поскольку играть я не люблю, то почти сразу я начал грезить программированием. Мне кажется я единственный человек на планете, который обожает делать игры , но не любит в них играть. Или делать сайты, но вообще не пользоватиься соц сетями.
А вы что любите делать, если решили стать тестировщиком?
И вам нужно понять истину - нет хороших сфер деятельности. Есть хорошие люди, которые объединяют таких же хороших людей создавая фантастические оазисы в токсичном мире.
Никто, примерно никто, не идёт в тестирование потому, что «мне всегда нравилось …».
Это басня для собеседований (что б повеселить собеседующих).
Идут потому, что «код писать сложно».
Идут потому, что внутри компании тестирование это маршрут ротации толковых ребят из саппорта.
Идут потому, что насмотрелись рекламы «стань тестировщиком и зарабатывай от 100к уже через 21 день».
Ну и потому, что тестирование - самый тупой путь вкатывания в айти, порог вхождения минимален.
А если говорить про автоматизированное тестирование, то для абсолютного большинства задач знания ЯП и разработки там нужны на уровне ниже джуниор кодера.
Порог входа в автоматизатора - потыкал селениум\сайпресс\плэйрайт, умеешь складывать жсоны в HTTP реквест и валидировать жсонсхему.
А, ну, ещё можешь прикрутить аллюр к жюнит\пайтесту.
Всё.
Тут надо некий баланс, чтобы старые тесты можно было менять и новые писать за адекватное время. А то можно все красиво сделать, а добавить новый тест займет 1 день)) у нас в банке автотесты хорошие, даже я будучи аналитиком мог сам менять и писать новые + ну и возможность запустить без тестировщика тоже важна (когда он в отпуске)
К сожалению всё так.
Есть при этом и обратная сторона - когда господа wannabe-developer среди автоматизаторов начинают строить космолеты «что б как у разработчиков», обмазывая все это миллионом слоёв абстракций, создавая внутри собственные сервисы (привет, необходимость писать тесты на тесты) и прочее.
Потому что писать сложный и «красивый» код как в продакшене хочется, а понимания KISS нет.
Проблема «я как разработчик вижу тут плохой код» в том, что код тестов решает принципиально другую задачу, нежели код приложения.
Он должен быть максимально тупым и простым, потому что все его задачи сводятся к arrange-act-assert, а не созданию стабильной и расширяемой бизнес логики.
Подходы и конечный результат тоже, ожидаемо, отличаются.
Не, я прекрасно понимаю о чем вы.
Плавали, знаем. :)
Я про то, что, к сожалению, довольно часто желание «писать правильный код» выливается в обратную крайность.
А людей, способных найти баланс - мало, и обычно они довольно стремительно покидают автоматизацию.
Нехватка куа такая, потому что из желающих вкатиться готовы хоть что-то учить процентов 10.
Остальные «я закончил курсы от скиллбокс, дайте мне 150к».
В итоге при наборе джунов ты играешь в сито-уито, в попытках с минимумом усилий найти кого-то, кто имеет хотя бы базовые признаки когнитивных способностей.
А при наборе миддлов и выше сталкиваешься с тем, что рынок растёт быстрее роста адекватных специалистов.
Если вы не слышали про нехватку, значит вы просто не занимались наймом.
Толковых (обладающих базовыми знаниями и умеющих думать головой) джунов приходится искать как иголку в стоге сена.
А начиная с года-полутора опыта (нормального опыта, а не сидел на жопе ровно) начинается тотальный рынок кандидата и даже неистово оверпрайснутые ребята из банковского сектора выбирают офферами, а не ищут работу.
Нехватка автотестеров и как следствие высокие зарплаты у них объясняются достаточно просто. Это уже все таки программирование, с улицы за 21 день не зайти. Но в большинстве своем, те кто осилил программирование видят себя "творцами" :) а не покладавателями соломы под других "творцов" :)
Тут правильно писали выше, это скорей те, кто из саппорта вышел.
Но я ещё пару вариантов вижу: разраб, который сидел слишком долго на старом стеке и на новый не хочет, не получается (например).
Лично видел человека, который отличный тестировщик - настолько вкрадчивого, критичного и мелочного (в хорошем смысле) спеца я ещё не видел))) вот такие для тестов отлично подходят
Дык хорошо.
Ну давайте честно, какая в тестах работа с базой?
У тебя нет конкурентности, нет сложных транзакций, нет необходимости следить за дедлоками, даже за производительностью особо следить не нужно.
Налил фикстур на старте пайплайна, сделал селекты по ходу тестов, грохнул, повторил на следующем прогоне.
Действительно серьёзные (что-то сложнее джоинов и деклэйра) ожидания к пониманию работы БД встречаются только у ребят, которые или сами БД/шины данных тестируют, или всякие даталейки.
С моками похожая история, 90% куак моки вообще не трогают, или е2е тесты, или тесты интеграции.
Те, кто трогают - поднимают примитивные заглушки с каким-нибудь mockito, работая с ним на уровне “прочитал quickstart”.
И что одно, что другое очень редко является блокером для входа в профессию.
Знаешь что такое пэйдж обжект и какие бывают ожидания?
Молодец, держи оффер.
1. Если вы в тестах не будете проверять работу с базой, то не сможете гарантировать правильную работу с ней. Я имею в виду банальные инсерты, апдейты и селекты, которые могут при обновлении структур данных перестать работать или начать работать неожиданным образом.
2. Одна из концепций тестирования в изоляции тестов, если вы будете поддерживать данные между прогонами, они могут воздействовать на результаты тестирования.
Все упирается в обьект тестирования. Разные объекты тестирования - разные уровни тестов.
Тестировать инсерты надо юнитами, которые обычно не тестировщики пишут.
Уровнем выше ты взаимодействуешь с интерфейсом - создал сущность, забрал сущность, сверил данные.
Ходить из функциональных тестов напрямую в базу - такое себе решение, хотя есть случаи, когда без этого никак.
По поводу изолированности и не-переиспользования данных вы правы.
Поэтому в описанной мной схеме и есть последовательность «налил фикстуры-> прогнал тесты -> грохнул».
Только вот всё равно, что б налить синтетических данных для тестов особых знаний скуля ненужно.
В основном с того, что я этим занимаюсь последние 9 лет. :)
И да, баги находят, баги пропускают, и это нормально, особенно учитывая что поиск багов - не основная задача тестировщиков. :)
Вот я всегда любил строить из игрушек огромные миры, но никогда не играл в них. Ещё я любил их разбирать, меня всегда интересовало что там внутри. Потом я вырос и моей игрушкой стал комп, но поскольку играть я не люблю, то почти сразу я начал грезить программированием. Мне кажется я единственный человек на планете, который обожает делать игры , но не любит в них играть. Или делать сайты, но вообще не пользоватиься соц сетями.
А вы что любите делать, если решили стать тестировщиком?
И вам нужно понять истину - нет хороших сфер деятельности. Есть хорошие люди, которые объединяют таких же хороших людей создавая фантастические оазисы в токсичном мире.
Никто, примерно никто, не идёт в тестирование потому, что «мне всегда нравилось …».
Это басня для собеседований (что б повеселить собеседующих).
Идут потому, что «код писать сложно».
Идут потому, что внутри компании тестирование это маршрут ротации толковых ребят из саппорта.
Идут потому, что насмотрелись рекламы «стань тестировщиком и зарабатывай от 100к уже через 21 день».
Ну и потому, что тестирование - самый тупой путь вкатывания в айти, порог вхождения минимален.
Смотря какое тестирование... Если ручное, то наверно.
А если говорить про автоматические, то там без знаний ЯП, очередей, сервисов делать нечего
А если говорить про автоматизированное тестирование, то для абсолютного большинства задач знания ЯП и разработки там нужны на уровне ниже джуниор кодера.
Порог входа в автоматизатора - потыкал селениум\сайпресс\плэйрайт, умеешь складывать жсоны в HTTP реквест и валидировать жсонсхему.
А, ну, ещё можешь прикрутить аллюр к жюнит\пайтесту.
Всё.
Комментарий недоступен
Тут надо некий баланс, чтобы старые тесты можно было менять и новые писать за адекватное время. А то можно все красиво сделать, а добавить новый тест займет 1 день)) у нас в банке автотесты хорошие, даже я будучи аналитиком мог сам менять и писать новые + ну и возможность запустить без тестировщика тоже важна (когда он в отпуске)
К сожалению всё так.
Есть при этом и обратная сторона - когда господа wannabe-developer среди автоматизаторов начинают строить космолеты «что б как у разработчиков», обмазывая все это миллионом слоёв абстракций, создавая внутри собственные сервисы (привет, необходимость писать тесты на тесты) и прочее.
Потому что писать сложный и «красивый» код как в продакшене хочется, а понимания KISS нет.
Проблема «я как разработчик вижу тут плохой код» в том, что код тестов решает принципиально другую задачу, нежели код приложения.
Он должен быть максимально тупым и простым, потому что все его задачи сводятся к arrange-act-assert, а не созданию стабильной и расширяемой бизнес логики.
Подходы и конечный результат тоже, ожидаемо, отличаются.
Комментарий недоступен
Не, я прекрасно понимаю о чем вы.
Плавали, знаем. :)
Я про то, что, к сожалению, довольно часто желание «писать правильный код» выливается в обратную крайность.
А людей, способных найти баланс - мало, и обычно они довольно стремительно покидают автоматизацию.
В желании «писать правильный код» ничего плохого нет, если эта правильность берёт начало из методички лида, а не каких-то мечтаний тестировщика )
В желании писать «правильный код» очень много всего плохого.
Потому что нет никакого «правильного кода» (если не считать того, который не написан).
Надо решать задачи, а не писать «правильный» код ради «правильного кода».
Не говоря уж о том, что тимлиды тоже могут оверинженирить, терять фокус или просто писать откровенную херню, как в иде, так и в методичках.
Если так просто, то почему то какая нехватка qa? При условии, что и зп им очень неплохо предлагают
Нехватка куа такая, потому что из желающих вкатиться готовы хоть что-то учить процентов 10.
Остальные «я закончил курсы от скиллбокс, дайте мне 150к».
В итоге при наборе джунов ты играешь в сито-уито, в попытках с минимумом усилий найти кого-то, кто имеет хотя бы базовые признаки когнитивных способностей.
А при наборе миддлов и выше сталкиваешься с тем, что рынок растёт быстрее роста адекватных специалистов.
Не слышал про нехватку. Мне кажется наоборот их как грязи. Так как порог входа низкий. Я про ручное тестирование.
Если вы не слышали про нехватку, значит вы просто не занимались наймом.
Толковых (обладающих базовыми знаниями и умеющих думать головой) джунов приходится искать как иголку в стоге сена.
А начиная с года-полутора опыта (нормального опыта, а не сидел на жопе ровно) начинается тотальный рынок кандидата и даже неистово оверпрайснутые ребята из банковского сектора выбирают офферами, а не ищут работу.
Нехватка квалифицированных автотестеров, а не васьков с улицы, которые могут заходить на форму, жать кнопку и сравнивать что пришло и что ожидалось
А ну так да это другой разговор ;)
Нехватка автотестеров и как следствие высокие зарплаты у них объясняются достаточно просто. Это уже все таки программирование, с улицы за 21 день не зайти. Но в большинстве своем, те кто осилил программирование видят себя "творцами" :) а не покладавателями соломы под других "творцов" :)
Тут правильно писали выше, это скорей те, кто из саппорта вышел.
Но я ещё пару вариантов вижу: разраб, который сидел слишком долго на старом стеке и на новый не хочет, не получается (например).
Лично видел человека, который отличный тестировщик - настолько вкрадчивого, критичного и мелочного (в хорошем смысле) спеца я ещё не видел))) вот такие для тестов отлично подходят
А работа с базой? А всякие моки?
Дык хорошо.
Ну давайте честно, какая в тестах работа с базой?
У тебя нет конкурентности, нет сложных транзакций, нет необходимости следить за дедлоками, даже за производительностью особо следить не нужно.
Налил фикстур на старте пайплайна, сделал селекты по ходу тестов, грохнул, повторил на следующем прогоне.
Действительно серьёзные (что-то сложнее джоинов и деклэйра) ожидания к пониманию работы БД встречаются только у ребят, которые или сами БД/шины данных тестируют, или всякие даталейки.
С моками похожая история, 90% куак моки вообще не трогают, или е2е тесты, или тесты интеграции.
Те, кто трогают - поднимают примитивные заглушки с каким-нибудь mockito, работая с ним на уровне “прочитал quickstart”.
И что одно, что другое очень редко является блокером для входа в профессию.
Знаешь что такое пэйдж обжект и какие бывают ожидания?
Молодец, держи оффер.
1. Если вы в тестах не будете проверять работу с базой, то не сможете гарантировать правильную работу с ней. Я имею в виду банальные инсерты, апдейты и селекты, которые могут при обновлении структур данных перестать работать или начать работать неожиданным образом.
2. Одна из концепций тестирования в изоляции тестов, если вы будете поддерживать данные между прогонами, они могут воздействовать на результаты тестирования.
Все упирается в обьект тестирования. Разные объекты тестирования - разные уровни тестов.
Тестировать инсерты надо юнитами, которые обычно не тестировщики пишут.
Уровнем выше ты взаимодействуешь с интерфейсом - создал сущность, забрал сущность, сверил данные.
Ходить из функциональных тестов напрямую в базу - такое себе решение, хотя есть случаи, когда без этого никак.
По поводу изолированности и не-переиспользования данных вы правы.
Поэтому в описанной мной схеме и есть последовательность «налил фикстуры-> прогнал тесты -> грохнул».
Только вот всё равно, что б налить синтетических данных для тестов особых знаний скуля ненужно.
Много в ваших словах презрения к тестированию и тестировщикам. С чего бы? Часто баги у вас находят? Или наоборот, пропускают?
В основном с того, что я этим занимаюсь последние 9 лет. :)
И да, баги находят, баги пропускают, и это нормально, особенно учитывая что поиск багов - не основная задача тестировщиков. :)