Я просто не понимаю, как можно строить данные и называть статью "Сколько зарабатывает ручной тестировщик", если меньше 20% компаний указывают доход? При такой выборке очень сложно получить реальные данные.
Сейчас на HH 2000+ вакансий на QA и из них только в 370 указан доход. Причем доход - не точная цифра, а диапазон от или до какого-то числа. Получается что брали рандомно 200 позиций, брали числа, где могло быть и "от" или "до" и составили статистику? Ну такое себе. При этом не брали крупные IT компании для выборки, не проводили опросов, не собирали каких-нибудь данных с glassdor.
А, ну тогда по вашей диванной аналитике уже сейчас разработчикам стоит опасаться за будущее больше, учитывая, что Unit-тесты пишут в основном они) Код кстати ChatGPT пишет неплохой, я тут недавно писал игрушку на шарпах, он большой молодец, надо просто модель достаточно хорошо научить. Но у него есть проблема с большими блоками кода и с запоминанием. Он через 20-30 новых запросов может забыть все методы класса, который сам же и описал.
За 10 минут ему удалось в красках расписать всю автобиографию, начиная со знакомства его родителей.
Для этого хороший HR одергивает кандидата в начале повествования, объясняет, что именно подразумевает под вопросом "расскажите о себе" и не выслушивает все 10 минут.
Также часто спрашивают, какие виды тестирования существуют.
Не стоит употреблять малознакомые термины, размыто говорить сразу обо всём или наоборот, слишком вдаваться в подробности, потому что каждое такое уточнение может стать поводом для новых, обычно более сложных вопросов.
Для этого надо спрашивать, не какие виды тестирования существуют, а спросить, по каким основным классификациям можно выделить виды тестирования. Дополнительно, можно обозначить их и спросить кандидата отдельно по каждой классификации. А то так спросили виды тестирования, кандидат и начинает перечислять все, которые знает.
Отвечать «я не знаю» тоже не следует, потому что интервьюер может подумать, что эта тема вам вовсе не интересна и у вас нет мотивации узнавать новое.
Мне кажется, что отвечать "Я не знаю" абсолютно адекватный и честный ответ на вопрос. Это не значит, что тема не интересна и что у человека нет мотивации, это значит, что он просто не знает ответ на вопрос и честно признается в этом.
В любой непонятной ситуации задавайте уточняющие вопросы.
Так можно закопать себя еще больше. Например простой вопрос: "В чем отличия между HTTP и HTTPS протоколами"? Допустим, человек не знает ответа, какой уточняющий вопрос его спасет в этой ситуации, а не сделает еще хуже? "Что вы подразумеваете под HTTP протоколом?" Единственное, если кандидат действительно это знает или читал об этом, но забыл, можно сказать честно об этом, попросить дать ответ на вопрос, а потом самому дополнить ответ, чтобы показать, что действительно знаком с темой.
Также в этом блоке интервьюер может проверить знание SQL и дать логические задачки «на засыпку».
А дают еще на собеседованиях задачки на логику? А то я давно не встречал такие даже среди джунов. Чаще просто дают сценарии для тестирования и смотрят на то, как человек размышляет.
По опыту ISTQB нужен только для работы в Нидерландах и Бельгии, там буквально все вакансии требуют сертификат хотя б Foundation уровня. А так для себя, если есть желание и время, почему бы и не сдать, я не думаю, что он в минус пойдет.
Я не знаю почему вы решили, что я говорю, что разработчику ничего не надо писать
Это отсутствует в вашей статье изначально в принципе в этом сценарии. А я как раз указал, что по мне это важный пункт, ведь он решает большинство проблем. Напиши вы про это, и не было б моих комментариев) Если он подразумевается, то мои извинения, я лишь сделал акцент на этом. Другой пытливый ум может это не понять, посмотреть вашу статью и начать сразу же заводить три новых бага, не пытаясь разобраться.
Если заведение багов как-то подставляет разработчика и приводит к проблемам, то что-то не так с процессами, количество багов не может являться критерием оценки качества, с таким подходом вы будете в один баг сразу несколько засовывать, теряя атомарность.
Ну вы читайте внимательно: "не предупредить разработчика (вы тем самым и подставляете его...". Речь опять же про взаимодействие и коммуникацию с разработчиком. Стоит хотя бы предупредить о проблеме и какие новые баги она вызывает.
Опять же, я не против пунктов про заведение новых багов. Я просто повторюсь, что все это не обязательно и не первостепенно, и скорее всего вся проблема решится простым взаимодействием QA - Разработчик. Вы просто переоткрываете баг, пишите девелоперу, в чем новые проблемы, по моему опыту он в 90% просто решает эти проблемы. Итог: баг починен, не заведено три новых ненужных бага, разработчик в курсе, так же не возникли потенциально те проблемы, которые QA не увидел со своей колокольни. В остальных 10% мы действительно смотрим по описанному вами флоу.
Да что ж тут за любовь авторов к утрированию и усложнению. Да, вместе с личным сообщением разработчику, мы естественно переоткрываем баг, чтобы он был в статусе Reopened, я думал, что это очевидно (ну или разработчик сам сделает, не суть). И нет, мы не пишем комментарий к задаче.
Теперь по вашим комментариям.
К сожалению, это самая большая ошибка - навалить все баги вместе разработчику в лс и нигде больше про них не писать.
Мы с вами обсуждали как один баг вызывает новые, теперь вы пишите про "навалить все баги", пожалуйста не выдумывайте, речь про конкретную проблему.
Да, Максим может починить всё сразу, а может починить но не всё, а может он сейчас работает над другой задачей и обещает вернуться через пару дней.
Ну так для этого мы ему и пишем! Что ж вы с разработчиками не хотите взаимодействовать. Напишем, уточним приоритеты.
А что если он заболеет, задачу надо передать кому-то, а ты даже статус не поменял, или поменял, но не понятно что не так, а потом и ты в отпуск уходишь и другой тестировщик после фиксов не знает что смотреть.
Я редко помню, чтобы реопены чинили другие разработчики. Опять же, я говорю про 90% случаев, в которых реопен починит этот же разработчик, который уже разобрался с функционалом и ему будет проще решить проблему. И чаще всего после болезни сам и сделает, никто не полезет в фичу разработчика, с которой он месяц разбирался.
Я не говорю, что в лс не надо писать, но всё что было в лс надо вынести как минимум в описание задачи, чтобы никто не потерял контекст. Завести баг это дело 5 минут.
Если вы оутсорсер и вам платят за каждый заведенный баг - welcome. Цель тестирования - не заводить баги. Наша цель улучшать качество продукта и внутренние процессы тестирования и разработки. Если вы хотите качественно решить задачу - решаем через взаимодействие с разработкой, находим лучшее решение (там могут быть и новые баги, и комментарии к старым, и т.д.). Если один фикс бага вызывает три, то самое последнее дело - завести три новых бага, не предупредить разработчика (вы тем самым и подставляете его, а еще это может обернуться ворохом проблем, которые вы с позиции тестирования даже себе не можете предположить).
Фичу нужно сразу разрабатывать с изолированным подходом, если это будет на уровне процессов разработки подразумеваться, то случаи, когда невозможно сделать управление с бэка будут довольно редки.
Редки ситуации, когда вы можете полностью изолировать фичу от остального функционала. Ну только если у вас очень хорошая и отлаженная система микросервисов. Тогда да, спорить не буду, так можно. При использовании монолита, можно выстрелить себе в ногу, там очень много технических и других зависимостей, которые надо учитывать.
Ну нет, я за вас не буду всю работу делать. Если вам есть чем опровергнуть, то пожалуйста. Я же руководствуюсь тем, что есть сайты по всем мировым массовым сокращениям: https://layoffs.fyi/ , а так же исследованиям, где QA входит в топ 5 позиций, которую затронули все эти сокращения или которые наиболее at-risk. По поводу новых вакансий - я смотрю на тенденции по Европе сейчас и два года назад, количество открытых позиций в QA в тот же Microsoft, Apple и т.д. стало значительно меньше.
При текущих тенденциях разгона технологий и трендах разработки, скорее всего, произойдет выравнивание заработной платы fullstack QA до уровня dev.
Будущее QA обещает быть интересным и перспективным, и прокачать свою квалификацию до fullstack QA — это отличный способ оставаться в тренде и быть ценнейшим сотрудником в компании.
Я побуду унылым скептиком, и буду счастлив, если то, что вы пишите окажется правдой. Но пока если посмотреть современные тенденции за последние два года, то QA входит в топ позиций, попавших под сокращение в мировых компаниях. Если посмотреть на список открытых вакансий, то за последние два года позиции QA существенно сократились. Компаниям действительно проще (не значит что лучше, конечно) обучить разработчика самому тестировать свои задачи и сэкономить на целой позиции. Надеюсь, что эта тенденция изменится, но пока реальность не очень радужна.
P.S. Я бы еще добавил в статью про знание и умение работать с API запросами для Fullstack QA, а то про SQL написали, а про API нет.
Спасибо за статью, но не мог не отметить пару моментов в ваших сценариях.
Ситуация 1 – Новые баги
Тут сразу во всей ситуации напрашивается первый и как мне кажется единственно правильный шаг. Написать разработчику. Например: "Привет, Максим, я тут проверял такую-то задачку и заметил, что твой фикс вызывает новые баги. Далее кинуть Максиму баги, их воспроизведение и стектрейс. Я уверяю, что в 90% случаев Максим просто и быстро починит эти проблемы. Скорее всего он просто допустил ошибку и не заметил. В остальных 10% мы действительно переходим уже к вашим возможным решениям.
Ситуация 5 – Завтра релиз, а ничего не готово
что сделать, чтобы запуск состоялся успешно?
Ответ тут по сути один (ваш третий пункт): Мы закладываем достаточно времени на тестирование нового функционала после того, как готов бэкэнд. К сожалению, остальные решения - не панацея, а могут привести к недостоверным результатам тестирования и упущению потенциальных проблем, которые могут возникнуть в реальной среде. Те же моки не тестируют реального клиент-серверного взаимодействия, интеграцию с внешними сервисами, платежи и т.д. Отключение фичи работает только при ее достаточной изолированности, что на практике происходит редко. А внеплановый релиз может нарушить планы и порядок развертывания.
Ищите компромисс между качеством продукта и задачами бизнеса, ваша задача найти и указать на проблемы, нельзя взять и сказать “я не буду тестировать без бэкенда и точка”.
Да, так говорить нельзя, вы правы. Но так же надо понимать, что без готового бэкэнда вы не сможете дать вашу полную оценку готовности продукта к релизу. И ответственный за релиз должен это понимать. Важно уметь идти на компромисс, но не менее важно и уметь отстаивать свою позицию в данной ситуации, ведь большая степень ответственности за качество лежит именно на вас.
Касательно типизации: если бы вы чуть внимательнее прочитали, я использую формулировку: "ЭТО ЛИШЬ НЕСКОЛЬКО ТИПОВ".
Я очень не хотел писать подробнее, потому что я очень не люблю углубляться в теорию, но видимо придется, чтобы люди не путались. Потому что этот вопрос задают на собеседовании и на нем же его заваливают. Основные типы тестирования можно классифицировать по различным критериям, в зависимости от цели тестирования, объекта тестирования, стадии разработки и так далее.
Например, по методу проверки его разделяют на функциональное и нефункциональное тестирование. В нефункциональное входят нагрузочное тестирование, тестирование производительности, совместимости, безопасности, надежности и т.д.
По уровню абстракции оно уже распределяется на модульное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование.
По цели тестирования: позитивное тестирование, негативное тестирование, регрессионное тестирование, автоматизированное тестирование и ручное тестирование.
Есть еще классификации. И да, это очень важно, нельзя просто взять и начать рассказывать все типы тестирования, что вы знаете в любом порядке. Важно понимать эти классификации и распределение. Вы же просто указали часть типов тестирования в список без распределения по классификации (я выделил ваши пункты болдом). Так делать нельзя, это может еще больше запутать людей.
Никто не будет спорить с тем, что Agile — это методология разработки программного обеспечения. Просто если мы смотрим на вопрос с функциональной точки зрения, например, для менеджера Agile будет методологией управления проектом, для тестировщика — в том числе методологией тестирования (ведь именно этим он и занимается), для аналитика и разраба - другое, но все вместе они работают по Agile.
Нет, снова запутаете начинающих тестировщиков. У Agile есть вполне очевидный жизненный цикл: Plan -> Design -> Develop -> Test -> Deploy -> Review -> Launch. Это цикл разработки программного обеспечения. Тестирование - только часть этого процесса. Да, я не сбуду спорить, что тестировщик начинает свою работу гораздо раньше, еще на этапе построения дизайна (это тоже спрашивают на собеседовании), для понимания основных требований, это уже другой вопрос. Но это методология разработки, не надо называть её методологией тестирования. Начинающий тестировщик должен понимать общий процесс разработки и свою роль в нем.
и то, что все виноваты, это и так понятно.
Я такого не говорил) Я рассказал, что все отвечают на проекте за качество продукта, вы же делаете свои выводы) Я же говорил, что каждый в своей мере отвечает за свой компонент и за свою область и так же контролирует его качество.
"А я то что, все виноваты" особенно для начинающих тестировщиков это может быть краеугольным камнем для успешности проекта
Спасибо за статью, я всегда люблю, когда рассказывают про тестирование и про то, что сама позиция гораздо сложнее, чем кажется на первый взгляд. Но тем не менее хочется обратить внимание на несколько пунктов, чтобы не сбивать лишний раз людей.
Ответственность за качество: тестировщики несут ответственность за обнаружение всех возможных ошибок в программном обеспечении, что требует высокой степени внимательности и детализации.
Вот тут я вас поправлю. Во-первых, тестировщики не несут ответственность за обнаружение всех возможных ошибок. Цель тестирования - не искать ошибки, цель - обеспечивать высокий уровень качества продукта согласно определенным критериям. Искать баги - один из способов достижения этой цели. Во-вторых. Есть такой хороший вопрос на собеседовании, который мне задавали не раз. Он звучит так: "Кто отвечает за качество продукта?" Правильный ответ: "Все". Все, включая программистов, должны отвечать за качество продукта. Я тут тоже не буду расписывать долго, но плохи те процессы, если программист просто резолвит задачу без своих проверок. А еще программисты пишут юнит тесты.
Технологии и методы тестирования постоянно развиваются
Могу я попросить вас привести пример, как за последние пару лет развились технологии и методы тестирования? Я бы просто не отделял тестирование от общих тенденций, которые касаются всего IT. Технологии и методы программирования так же развиваются и похлеще тестирования.
Ведь, как говорится, страшно или тяжело - в обучении, а на реальной работе, в бою будет легко
Нет, не будет. Учить проще. Проблема в том, что люди начитаются теории, а потом не могут адаптироваться к процессам на работе и их увольняют. На реальной работе, особенно в первые месяцы онбординга намного сложнее.
Знание методологий тестирования: Понимание основных методологий тестирования, таких как Waterfall, Agile, Scrum, и их применение в работе.
Это не методологии тестирования, это методологии всей разработки продукта.
В остальном, я бы оставил в статье поменьше теории, она уже есть и на хабре и много где, да и структурирована более правильней, в особенности вон пункты про типы тестирования, у них к слову есть определенная правильная типизация, не надо их все мешать в одну кучу. Про инструменты еще. Тут в целом надо добавить не обязательно изучать все, надо читать только о том, что может пригодится для конкретной позиции и конкретного проекта. А еще у вас в современных инструментах тестирования Robot Framework, которому 16 лет уже) И я не уверен, что кто-то вообще использует половину из написанного в современных инструментах. А еще есть Android Studio, но нет XCode. И где Docker?) Ладно, тут можно много еще полезного придумать.
Честно говоря, если кому-то нужны месяцы для вкатывания в проект - это уже клиника и однозначная рекомендация "на выход с вещами".
Как же вы интересно интерпретируете написанное. Я пишу про "странно от сеньора для первых месяцев работы требовать полного понимания проекта", вы мне про "вкатиться в проект". Я говорю про более глубокое и полное понимание процессов все же. Я предполагаю, что для особого крупного и комплексного проекта на это уходит больше времени, чем пара месяцев. Хотя я не знаю, что у вас там за компания и проект, где вы через пару месяцев увольняете людей, потому что они не познали все аспекты, возможно мы изначально с вами говорим о разных вещах.
Учить да, научить - нет :) Но тривиальные вещи вроде, "где здесь туалет", и вот тут набирать воду для чайника действительно показать может любой
Ого, да вы совсем недооцениваете своих сотрудников, в особенности Мидлов. Мидл - не безмозглая обезьянка, тыкающая на кнопки. Они могут и смогут научить. Мидлом можно быть и с 10-ти летним опытом и экспертизой, с хорошими знаниями и пониманием проекта. Я как раз пытаюсь донести, что они хорошо выполняют поставленные задачи. Просто они не смотрят на многие вещи с позиции Сеньора и как Сеньор. Их подход больше похож на то, как поезд катается по рельсам по одному и тому же маршруту, который они знают отлично и могут объяснить отлично, но при этом не пытаются понять, как устроены другие маршруты.
А в чем проблема? Ну правда, если я писал эти тесты.
Я как раз описываю ситуацию, когда вы приходите на проект и видите сотни и тысячи тестов (написанных не вами) и пытаетесь разобраться, вы же мне сразу начинаете писать обратное. Пожалуйста, не интерпретируете написанное, как вам удобно.
На самом деле, на нормальном проекте у QA своя среда, где "чужие" не ходят, а то и несколько. Они сами себе все ставят и сами отвечают за конфиг. Если это нет так - прямой вопрос к лиду/сеньору на таком проекте. Ну серьезно, если QA чего-то тестируют, а паралельно кто-то чего-то на среде меняет - тут вопрос к базовым компетенциям тех, кто такое допускает.
Ну вот опять же, зависит от проекта. Вы говорите явно про небольшой проект, а не про комплексный, разделенные на многие компоненты, еще и с ежедневными релизами. Как там не разграничивай, там много зависимостей и один может потрогать свое, что затронет другие компоненты, и от этого никуда не денешься и не изолируешься. И разобраться в том, кто и как задел - та еще наука, еще и за ограниченное время.
Не совсем правильное представление. Как раз Мидл абсолютно нормальная рабочая единица, знает куда себя пристроить и ответственно выполняет поставленные ему цели. Просто несамостоятельная. Дашь ему задачку в джире? Сделает. Скажешь ему починить автотест и напишешь, когда и почему стал ломаться? Починит. Но в целом все. Сеньор посмотрит в историю падения автотеста, найдет, еще причину, почему он иногда падал до этого и вообще перепишет метод, чтобы он стал стабильнее. Или вообще вместо починки заведет новую таску на удаление теста, ведь он уточнил, что он больше не нужен, потому что этот функционал не актуален и нет смысла это проверять, а стейкхолдеры сказали, что больше и не планируют этот функционал включать. Но это как раз пример, как сеньор мыслит за рамками поставленной задачи. Если у вас и Мидл так мыслит, то я считаю, что это уже большой шаг на пути к Сеньору и отличный прогресс, а не стагнация на одном месте.
И имя не уничижительное, а наоборот простецкое что ли, чтобы показать насколько просто и прямо сотрудник подходит к своим обязанностям. Да и вообще тут не надо искать скрытый смысл.
Сеньор дополнительно обладает техническими навыками, которые позволяют:
учить молодняк, т.е. сеньор уже не просто знает, но уже и достаточно отрефлексировал, чтобы пояснить то, что он знает
возможность решить сложную задачу, сделать PoC новой технологии, т.е. банально широкий кругозор и больший технический опыт
Учить молодняк может любой. Наставничество никак не связано с позицией, оно целиком зависит от твоего опыта и понимания проекта. Я будучи мидлом менторил новых сотрудников как раз потому того, что пришел позже, лучше и свежее понимал какие инструменты и какие вещи требуются для более успешного и быстрого анбординга. (А возможно и потому что сеньору было просто лень)
Насчет сложной задачи опять же есть пример, как у нас приходил человек, который на собеседовании доказал, что он готов решать сложные задачи, обладает очень большим техническим опытом. Ему сходу дали сеньора. Через полгода он все еще делал задачи с большим количеством брака и очень долго. Тут надо понимать, что большой технический опыт не равно моментальному пониманию всех внутренних процессов на проекте и того, как устроен вверенный ему компонент. Да, это должно помогать, но не всегда является гарантией.
Дело не в том, что миддл будет просить помощи, или сидеть на опке ровно, пока рак на горе свистнет. Он просто не знает "как" или потратит много времени.
Все дело в том, что сеньор тоже не знает сходу "как" и так же потратит много времени, особенно в первые разы. Странно от сеньора для первых месяцев работы требовать полного понимания проекта и внутренних процессов и того, что он сходу начнет щелкать задачки.
Блин, тут мне кажется зарыт трешак. Ты либо автоматизатор, либо "никто". Если твой тест сломался а ты не знаешь почему - ты даже не миддл. Ты просто недо джун :) Ну серьезно. А-а-а-а, у меня ошибка, помогите ... тут либо в табло (можно вербально), либо с ноги под зад из команды.
У вас на проекте сотни или даже тысячи тестов, вы с ходу разберетесь в чем проблема, если условный разработчик что-то потрогал в коде? Даже если хорошо и подробно выведена ошибка и правильно ловятся все экспешены. Ну да, условный локатор в селениуме, я уверен, вы быстро заметите. Но почему вдруг резко перестал проходить платеж в условном Paypal, вы быстро разберетесь? Учитывая что могут быть проблемы со стороны аггрегатора? А есть проекты еще сложнее и комплекснее с еще более невнятными ошибками. У меня похожее было в прошлом опыте кибербезопасности, когда малварные аналитики из другой команды могли немного потрогать у себя определение новых угроз и их отрисовку на основе новой классификации, что влияло на неправильный ответ по запросу из автотеста. А ты пол дня мучаешься с тестом и не понимаешь, почему он перестал выдавать неправильный ответ, хотя никто из твоей команды ничего даже близко не трогал.
Со слов организаторов мероприятия (особенно учитывая документы о неразглашении, которые мы подписывали), пронеслась шутка, что если мы захотим рассказать об ивенте, то мы можем рассказать только о том, что… еда была вкусная и ничего больше.
Но в целом ивент был потрясающий, призы очень хорошие и задания интересные. Спасибо организаторам.
Я просто не понимаю, как можно строить данные и называть статью "Сколько зарабатывает ручной тестировщик", если меньше 20% компаний указывают доход? При такой выборке очень сложно получить реальные данные.
Сейчас на HH 2000+ вакансий на QA и из них только в 370 указан доход. Причем доход - не точная цифра, а диапазон от или до какого-то числа. Получается что брали рандомно 200 позиций, брали числа, где могло быть и "от" или "до" и составили статистику? Ну такое себе. При этом не брали крупные IT компании для выборки, не проводили опросов, не собирали каких-нибудь данных с glassdor.
А, ну тогда по вашей диванной аналитике уже сейчас разработчикам стоит опасаться за будущее больше, учитывая, что Unit-тесты пишут в основном они)
Код кстати ChatGPT пишет неплохой, я тут недавно писал игрушку на шарпах, он большой молодец, надо просто модель достаточно хорошо научить. Но у него есть проблема с большими блоками кода и с запоминанием. Он через 20-30 новых запросов может забыть все методы класса, который сам же и описал.
Для этого хороший HR одергивает кандидата в начале повествования, объясняет, что именно подразумевает под вопросом "расскажите о себе" и не выслушивает все 10 минут.
Для этого надо спрашивать, не какие виды тестирования существуют, а спросить, по каким основным классификациям можно выделить виды тестирования. Дополнительно, можно обозначить их и спросить кандидата отдельно по каждой классификации. А то так спросили виды тестирования, кандидат и начинает перечислять все, которые знает.
Мне кажется, что отвечать "Я не знаю" абсолютно адекватный и честный ответ на вопрос. Это не значит, что тема не интересна и что у человека нет мотивации, это значит, что он просто не знает ответ на вопрос и честно признается в этом.
Так можно закопать себя еще больше. Например простой вопрос: "В чем отличия между HTTP и HTTPS протоколами"? Допустим, человек не знает ответа, какой уточняющий вопрос его спасет в этой ситуации, а не сделает еще хуже? "Что вы подразумеваете под HTTP протоколом?"
Единственное, если кандидат действительно это знает или читал об этом, но забыл, можно сказать честно об этом, попросить дать ответ на вопрос, а потом самому дополнить ответ, чтобы показать, что действительно знаком с темой.
А дают еще на собеседованиях задачки на логику? А то я давно не встречал такие даже среди джунов. Чаще просто дают сценарии для тестирования и смотрят на то, как человек размышляет.
А каких тестов, расскажите подробнее? Unit-тесты или E2E тесты?
Тогда уж трех. Я вот редко встречаю чисто ручных QA и чисто AQA, везде есть распределение.
А можно подробнее, откуда вы взяли эти 200 вакансий и откуда получили точные данные по зарплате?
По опыту ISTQB нужен только для работы в Нидерландах и Бельгии, там буквально все вакансии требуют сертификат хотя б Foundation уровня. А так для себя, если есть желание и время, почему бы и не сдать, я не думаю, что он в минус пойдет.
Это отсутствует в вашей статье изначально в принципе в этом сценарии. А я как раз указал, что по мне это важный пункт, ведь он решает большинство проблем. Напиши вы про это, и не было б моих комментариев) Если он подразумевается, то мои извинения, я лишь сделал акцент на этом. Другой пытливый ум может это не понять, посмотреть вашу статью и начать сразу же заводить три новых бага, не пытаясь разобраться.
Ну вы читайте внимательно: "не предупредить разработчика (вы тем самым и подставляете его...". Речь опять же про взаимодействие и коммуникацию с разработчиком. Стоит хотя бы предупредить о проблеме и какие новые баги она вызывает.
Опять же, я не против пунктов про заведение новых багов. Я просто повторюсь, что все это не обязательно и не первостепенно, и скорее всего вся проблема решится простым взаимодействием QA - Разработчик. Вы просто переоткрываете баг, пишите девелоперу, в чем новые проблемы, по моему опыту он в 90% просто решает эти проблемы. Итог: баг починен, не заведено три новых ненужных бага, разработчик в курсе, так же не возникли потенциально те проблемы, которые QA не увидел со своей колокольни. В остальных 10% мы действительно смотрим по описанному вами флоу.
Да что ж тут за любовь авторов к утрированию и усложнению.
Да, вместе с личным сообщением разработчику, мы естественно переоткрываем баг, чтобы он был в статусе Reopened, я думал, что это очевидно (ну или разработчик сам сделает, не суть). И нет, мы не пишем комментарий к задаче.
Теперь по вашим комментариям.
Мы с вами обсуждали как один баг вызывает новые, теперь вы пишите про "навалить все баги", пожалуйста не выдумывайте, речь про конкретную проблему.
Ну так для этого мы ему и пишем! Что ж вы с разработчиками не хотите взаимодействовать. Напишем, уточним приоритеты.
Я редко помню, чтобы реопены чинили другие разработчики. Опять же, я говорю про 90% случаев, в которых реопен починит этот же разработчик, который уже разобрался с функционалом и ему будет проще решить проблему. И чаще всего после болезни сам и сделает, никто не полезет в фичу разработчика, с которой он месяц разбирался.
Если вы оутсорсер и вам платят за каждый заведенный баг - welcome. Цель тестирования - не заводить баги. Наша цель улучшать качество продукта и внутренние процессы тестирования и разработки. Если вы хотите качественно решить задачу - решаем через взаимодействие с разработкой, находим лучшее решение (там могут быть и новые баги, и комментарии к старым, и т.д.). Если один фикс бага вызывает три, то самое последнее дело - завести три новых бага, не предупредить разработчика (вы тем самым и подставляете его, а еще это может обернуться ворохом проблем, которые вы с позиции тестирования даже себе не можете предположить).
Редки ситуации, когда вы можете полностью изолировать фичу от остального функционала. Ну только если у вас очень хорошая и отлаженная система микросервисов. Тогда да, спорить не буду, так можно. При использовании монолита, можно выстрелить себе в ногу, там очень много технических и других зависимостей, которые надо учитывать.
Ну нет, я за вас не буду всю работу делать. Если вам есть чем опровергнуть, то пожалуйста. Я же руководствуюсь тем, что есть сайты по всем мировым массовым сокращениям: https://layoffs.fyi/ , а так же исследованиям, где QA входит в топ 5 позиций, которую затронули все эти сокращения или которые наиболее at-risk. По поводу новых вакансий - я смотрю на тенденции по Европе сейчас и два года назад, количество открытых позиций в QA в тот же Microsoft, Apple и т.д. стало значительно меньше.
Я побуду унылым скептиком, и буду счастлив, если то, что вы пишите окажется правдой. Но пока если посмотреть современные тенденции за последние два года, то QA входит в топ позиций, попавших под сокращение в мировых компаниях. Если посмотреть на список открытых вакансий, то за последние два года позиции QA существенно сократились. Компаниям действительно проще (не значит что лучше, конечно) обучить разработчика самому тестировать свои задачи и сэкономить на целой позиции. Надеюсь, что эта тенденция изменится, но пока реальность не очень радужна.
P.S. Я бы еще добавил в статью про знание и умение работать с API запросами для Fullstack QA, а то про SQL написали, а про API нет.
Спасибо за статью, но не мог не отметить пару моментов в ваших сценариях.
Тут сразу во всей ситуации напрашивается первый и как мне кажется единственно правильный шаг. Написать разработчику. Например: "Привет, Максим, я тут проверял такую-то задачку и заметил, что твой фикс вызывает новые баги. Далее кинуть Максиму баги, их воспроизведение и стектрейс. Я уверяю, что в 90% случаев Максим просто и быстро починит эти проблемы. Скорее всего он просто допустил ошибку и не заметил. В остальных 10% мы действительно переходим уже к вашим возможным решениям.
Ответ тут по сути один (ваш третий пункт): Мы закладываем достаточно времени на тестирование нового функционала после того, как готов бэкэнд. К сожалению, остальные решения - не панацея, а могут привести к недостоверным результатам тестирования и упущению потенциальных проблем, которые могут возникнуть в реальной среде. Те же моки не тестируют реального клиент-серверного взаимодействия, интеграцию с внешними сервисами, платежи и т.д. Отключение фичи работает только при ее достаточной изолированности, что на практике происходит редко. А внеплановый релиз может нарушить планы и порядок развертывания.
Да, так говорить нельзя, вы правы. Но так же надо понимать, что без готового бэкэнда вы не сможете дать вашу полную оценку готовности продукта к релизу. И ответственный за релиз должен это понимать. Важно уметь идти на компромисс, но не менее важно и уметь отстаивать свою позицию в данной ситуации, ведь большая степень ответственности за качество лежит именно на вас.
Я очень не хотел писать подробнее, потому что я очень не люблю углубляться в теорию, но видимо придется, чтобы люди не путались. Потому что этот вопрос задают на собеседовании и на нем же его заваливают. Основные типы тестирования можно классифицировать по различным критериям, в зависимости от цели тестирования, объекта тестирования, стадии разработки и так далее.
Например, по методу проверки его разделяют на функциональное и нефункциональное тестирование. В нефункциональное входят нагрузочное тестирование, тестирование производительности, совместимости, безопасности, надежности и т.д.
По уровню абстракции оно уже распределяется на модульное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование.
По цели тестирования: позитивное тестирование, негативное тестирование, регрессионное тестирование, автоматизированное тестирование и ручное тестирование.
Есть еще классификации. И да, это очень важно, нельзя просто взять и начать рассказывать все типы тестирования, что вы знаете в любом порядке. Важно понимать эти классификации и распределение. Вы же просто указали часть типов тестирования в список без распределения по классификации (я выделил ваши пункты болдом). Так делать нельзя, это может еще больше запутать людей.
Нет, снова запутаете начинающих тестировщиков. У Agile есть вполне очевидный жизненный цикл: Plan -> Design -> Develop -> Test -> Deploy -> Review -> Launch. Это цикл разработки программного обеспечения. Тестирование - только часть этого процесса. Да, я не сбуду спорить, что тестировщик начинает свою работу гораздо раньше, еще на этапе построения дизайна (это тоже спрашивают на собеседовании), для понимания основных требований, это уже другой вопрос. Но это методология разработки, не надо называть её методологией тестирования. Начинающий тестировщик должен понимать общий процесс разработки и свою роль в нем.
Я такого не говорил) Я рассказал, что все отвечают на проекте за качество продукта, вы же делаете свои выводы) Я же говорил, что каждый в своей мере отвечает за свой компонент и за свою область и так же контролирует его качество.
Это опять же неправильный вывод) Не выдумывайте)
А что это означает? Не совсем понимаю.
Спасибо за статью, я всегда люблю, когда рассказывают про тестирование и про то, что сама позиция гораздо сложнее, чем кажется на первый взгляд. Но тем не менее хочется обратить внимание на несколько пунктов, чтобы не сбивать лишний раз людей.
Вот тут я вас поправлю.
Во-первых, тестировщики не несут ответственность за обнаружение всех возможных ошибок. Цель тестирования - не искать ошибки, цель - обеспечивать высокий уровень качества продукта согласно определенным критериям. Искать баги - один из способов достижения этой цели.
Во-вторых. Есть такой хороший вопрос на собеседовании, который мне задавали не раз. Он звучит так: "Кто отвечает за качество продукта?" Правильный ответ: "Все". Все, включая программистов, должны отвечать за качество продукта. Я тут тоже не буду расписывать долго, но плохи те процессы, если программист просто резолвит задачу без своих проверок. А еще программисты пишут юнит тесты.
Могу я попросить вас привести пример, как за последние пару лет развились технологии и методы тестирования? Я бы просто не отделял тестирование от общих тенденций, которые касаются всего IT. Технологии и методы программирования так же развиваются и похлеще тестирования.
Нет, не будет. Учить проще. Проблема в том, что люди начитаются теории, а потом не могут адаптироваться к процессам на работе и их увольняют. На реальной работе, особенно в первые месяцы онбординга намного сложнее.
Это не методологии тестирования, это методологии всей разработки продукта.
В остальном, я бы оставил в статье поменьше теории, она уже есть и на хабре и много где, да и структурирована более правильней, в особенности вон пункты про типы тестирования, у них к слову есть определенная правильная типизация, не надо их все мешать в одну кучу. Про инструменты еще. Тут в целом надо добавить не обязательно изучать все, надо читать только о том, что может пригодится для конкретной позиции и конкретного проекта. А еще у вас в современных инструментах тестирования Robot Framework, которому 16 лет уже) И я не уверен, что кто-то вообще использует половину из написанного в современных инструментах. А еще есть Android Studio, но нет XCode. И где Docker?) Ладно, тут можно много еще полезного придумать.
Как же вы интересно интерпретируете написанное. Я пишу про "странно от сеньора для первых месяцев работы требовать полного понимания проекта", вы мне про "вкатиться в проект". Я говорю про более глубокое и полное понимание процессов все же. Я предполагаю, что для особого крупного и комплексного проекта на это уходит больше времени, чем пара месяцев. Хотя я не знаю, что у вас там за компания и проект, где вы через пару месяцев увольняете людей, потому что они не познали все аспекты, возможно мы изначально с вами говорим о разных вещах.
Ого, да вы совсем недооцениваете своих сотрудников, в особенности Мидлов. Мидл - не безмозглая обезьянка, тыкающая на кнопки. Они могут и смогут научить. Мидлом можно быть и с 10-ти летним опытом и экспертизой, с хорошими знаниями и пониманием проекта. Я как раз пытаюсь донести, что они хорошо выполняют поставленные задачи. Просто они не смотрят на многие вещи с позиции Сеньора и как Сеньор. Их подход больше похож на то, как поезд катается по рельсам по одному и тому же маршруту, который они знают отлично и могут объяснить отлично, но при этом не пытаются понять, как устроены другие маршруты.
Я как раз описываю ситуацию, когда вы приходите на проект и видите сотни и тысячи тестов (написанных не вами) и пытаетесь разобраться, вы же мне сразу начинаете писать обратное. Пожалуйста, не интерпретируете написанное, как вам удобно.
Ну вот опять же, зависит от проекта. Вы говорите явно про небольшой проект, а не про комплексный, разделенные на многие компоненты, еще и с ежедневными релизами. Как там не разграничивай, там много зависимостей и один может потрогать свое, что затронет другие компоненты, и от этого никуда не денешься и не изолируешься. И разобраться в том, кто и как задел - та еще наука, еще и за ограниченное время.
Не совсем правильное представление. Как раз Мидл абсолютно нормальная рабочая единица, знает куда себя пристроить и ответственно выполняет поставленные ему цели. Просто несамостоятельная. Дашь ему задачку в джире? Сделает. Скажешь ему починить автотест и напишешь, когда и почему стал ломаться? Починит. Но в целом все. Сеньор посмотрит в историю падения автотеста, найдет, еще причину, почему он иногда падал до этого и вообще перепишет метод, чтобы он стал стабильнее. Или вообще вместо починки заведет новую таску на удаление теста, ведь он уточнил, что он больше не нужен, потому что этот функционал не актуален и нет смысла это проверять, а стейкхолдеры сказали, что больше и не планируют этот функционал включать. Но это как раз пример, как сеньор мыслит за рамками поставленной задачи. Если у вас и Мидл так мыслит, то я считаю, что это уже большой шаг на пути к Сеньору и отличный прогресс, а не стагнация на одном месте.
И имя не уничижительное, а наоборот простецкое что ли, чтобы показать насколько просто и прямо сотрудник подходит к своим обязанностям. Да и вообще тут не надо искать скрытый смысл.
Учить молодняк может любой. Наставничество никак не связано с позицией, оно целиком зависит от твоего опыта и понимания проекта. Я будучи мидлом менторил новых сотрудников как раз потому того, что пришел позже, лучше и свежее понимал какие инструменты и какие вещи требуются для более успешного и быстрого анбординга. (А возможно и потому что сеньору было просто лень)
Насчет сложной задачи опять же есть пример, как у нас приходил человек, который на собеседовании доказал, что он готов решать сложные задачи, обладает очень большим техническим опытом. Ему сходу дали сеньора. Через полгода он все еще делал задачи с большим количеством брака и очень долго. Тут надо понимать, что большой технический опыт не равно моментальному пониманию всех внутренних процессов на проекте и того, как устроен вверенный ему компонент. Да, это должно помогать, но не всегда является гарантией.
Все дело в том, что сеньор тоже не знает сходу "как" и так же потратит много времени, особенно в первые разы. Странно от сеньора для первых месяцев работы требовать полного понимания проекта и внутренних процессов и того, что он сходу начнет щелкать задачки.
У вас на проекте сотни или даже тысячи тестов, вы с ходу разберетесь в чем проблема, если условный разработчик что-то потрогал в коде? Даже если хорошо и подробно выведена ошибка и правильно ловятся все экспешены. Ну да, условный локатор в селениуме, я уверен, вы быстро заметите. Но почему вдруг резко перестал проходить платеж в условном Paypal, вы быстро разберетесь? Учитывая что могут быть проблемы со стороны аггрегатора? А есть проекты еще сложнее и комплекснее с еще более невнятными ошибками. У меня похожее было в прошлом опыте кибербезопасности, когда малварные аналитики из другой команды могли немного потрогать у себя определение новых угроз и их отрисовку на основе новой классификации, что влияло на неправильный ответ по запросу из автотеста. А ты пол дня мучаешься с тестом и не понимаешь, почему он перестал выдавать неправильный ответ, хотя никто из твоей команды ничего даже близко не трогал.
Но в целом ивент был потрясающий, призы очень хорошие и задания интересные. Спасибо организаторам.