Не буду повторяться про большую разницу "тестировщик" и QA. Да, нельзя путать эти понятия. В этой статье мы будем использовать народное слово "тестировщик", а думать про QA.
Недавно я очередной раз услышала, что "тестировщик – это слишком просто". Отнесем в этот скоуп все подобные фразы "тестировщики просто нажимают кнопочки", "легко войти в айти через тестирование", "разработка – это для умных, а в тестировании много ума не надо" и т.д.
Из-за этих заблуждений на рынке очень мало хороших QA
Люди, которые так считают, возможно, априори не смогут “легко войти в айти”. Да и стать крутыми специалистами. Сейчас объясню почему. В этих фразах четко прослеживается: обесценивание чужого труда, незнание особенностей профессии QA, кодоцентричность и отсутствие тактичности. Для QA важно критическое мышление, чего мы не наблюдаем в этих фразах.
Обесценивание чужого труда – это прямой путь к оправданию своей лени.
Лень разобраться, почитать десяток статей и одну книгу. Лень понимать компетентных людей, лень думать.Когда меня спрашивают “Чего ты не хотела бы видеть в команде/компании?”, первое, что я отвечаю, это “Чтобы никто не обесценивал чужой труд”. Такое может встречаться относительно любой профессии. Люди от незнания считают, что тестирование – это просто кликанье на кнопочки, что фронтенд – это изи, что дизайнер – это не серьезно и TypeScript – язык для лохов и т.д. Стоит лишь поработать полгода с тем, что кажется простым, и придет понимание, что у этого есть свое предназначение и без этой составляющей не построить успешный бизнес.
Так что же “сложного” в QA
Выучить список техник тест-дизайна – просто. Понять и научиться их применять – не просто. Это приходит с продолжительным трудом, работой и умением системно мыслить.
Увидеть, что кнопка не работает – просто. Продумать заранее неочевидные сценарии, в которых кнопка может не работать – сложно. Кликнуть на готовую кнопку – просто. Кликнуть на несуществующую кнопку – сложно. Сложно проверить несуществующее. И сложно предотвратить несуществующее. А еще сложнее, когда работа кнопки зависит от других компонентов системы, от нагрузки на сервер и от много чего другого одновременно.
Сказать, что эта кнопка не работает – просто. А понять в каких сценариях она ломается и почему – сложно. Предвидеть аналогичные ошибки в будущем, тоже непросто.
А какие главные и основополагающие качества QA?
- Внимательность
- Критическое мышление
- Честность. Если QA что-то не учел при тестировании, он должен уметь честно и без страха в этом признаться. Важно вовремя и честно говорить о проблемах. Это важно для продукта, для бизнеса, для пользователя. Нормально – что-то упускать, забывать, не нормально – скрывать, забивать.
- Умение давать честный фидбэк и принимать критику в свою сторону
- Умение грамотно и четко документировать
- QA – это адвокат пользователя
Мы говорили сейчас о ручных QA. Но не забываем про ветку QA Automation, где недостаточно всего вышеописанного. При автоматизации вы заставляете тачку воспроизводить код разработчика так, как вам нужно. И предварительно, используя все знания о тестировании и свой опыт, вам нужно определить – как вам нужно.
Каждая профессия несет свою ценность, как и любой труд.
"тестировщики просто нажимают кнопочки", "легко войти в айти через тестирование", "разработка – это для умных, а в тестировании много ума не надо"
Все сказанное верно, говорю как ворвавшийся тестировщик. Бизнес задачи решать много ума не надо, упущенные баги подфиксятся, главное не совсем дегродом быть и не пропускать критические. С умением признавать свои ошибки согласен, но это качество должно быть у любого адекватного человека.
Идёт речь не о тестировщиках. А о QA Engineer.
Часто возникает непонимание того, чем отличается QA, QC и тестировщик. А это абсолютно три разных уровня работы с тестированием ПО (программное обеспечение).
• 1 уровень. Tester (Тестирование) - мы все тестировщики. Мы те...
Часто возникает непонимание того, чем отличается QA, QC и тестировщик. А это абсолютно три разных уровня работы с тестированием ПО (программное обеспечение).
• 1 уровень. Tester (Тестирование) - мы все тестировщики. Мы тестировщики микроволновки, когда греем в ней еду. Мы тестировщики инстаграма, когда они выпускают новые фичи на небольшую часть пользователей (A/B – тесты). Мы тестировщики онлайн-тренировок. Мы ежедневно тестируем множество процессов и предметов.
Тестировщики проверяют, что ПО соответствует требованиям к нему.
Тестировщик поможет, когда есть готовое ПО. Ему дают задание – он проверяет – описывает найденные несоответствия.
Тестировние – это непросто и базовый минимум того, без чего нельзя релизить продукт.
🧑🏻💻Основная задача тестировщика – выявить и зафиксировать дефекты.
• 2 уровень. Quality Control Engineer (Контроль качества) включает в себя и проверку продукта на соответствие требованиям.
QC Engineer проверяет соответствие ПО заранее определенному уровню качества.
QC Engineer может определить, готов ли продукт к релизу или нет.
🧑🏻💻Основная задача QC Engineer – предоставить информацию о качестве продукта на всех этапах разработки.
• 3 уровень. Quality Assurance Engineer (Обеспечение качества) включает в себя мероприятия на всех этапах разработки и сопровождение после релиза.
Тестирование ПО занимает малый процент времени от работы QA.
QA занимается тестированием документации, ревью кода на соответствие стандартам, выстраивание процесса тестирования, внедрение методик для повышения качества тестирования и т.д.
👨🏻💻Основная задача обеспечения качества – повысить качество тестирования: выстроить систему, которая будет работать на качество продукта до начала разработки, во время разработки и после окончания разработки, чтобы при тестировании количество дефектов было минимальным.
По опыту могу сказать, что в хороших компаниях чаще всего ищут QA Engineer и составляют соответствующие вакансии. Вызывают отторжение вакансии “Тестировщик ПО” с требованиями, как к QA Engineer. Ведь если работодатель не отличает для себя уровни работы в тестировании, как он сможет по достоинству оценить вашу работу?
Стремитесь быть профессиональным QA, а не тестировщиком❤
Если вы испытываете сложность из-за зависимостей кнопки от других элементов программы, значит вы не видите границы видов тестирования. Не зря их разделяют на юнит, модульные и и.д.
Так же есть зависимость от уровня разработчиков. Если они низкого уровня, то будут создавать сложно тестируемый код, так как размывают и разницы контекстов предметной области.
Ещё есть стремность из-за попытки следовать тдд тогда, когда это вредит. Тдд круто когда у вас в компании есть крутой архитектор и бизнесаналитики. Писать тдд возможно только при наличии законченной архитектуры. Иначе, это сведёт сума.
И да, стать программистом после тостировщика очень сложно. Но и программист, который не писал тесты не может стать профессионалом. Только при углублении в тестировании понимаешь как реально правильно писать код.
Разбор пирамиды тестирования в этой статье приводить не стала, вместо этого выразилась так, как посчитала нужным.
Я на своем пути не встречала разработчика, который не пишет юнит тесты.
Это работает и в обратную сторону: тестер, который не понимает код и не знает, как он выглядит, будет оставаться в высокоуровневом тестировании.
Спасибо за статью!
Есть мнение, что по пути QA проще всего войти в IT, я считаю это очень большим заблуждением. По моему мнению, нет "простого" маршрута, есть время и усилия в любом направлении. Не согласен с комментаторами, которые стараются разделить по какой-то выдуманной статистике тех, кто работает в каком-либо направлении (в данном случае в QA), тем самым указывая кто конкретно должен работать в этом направлении.
IT направления идеальны тем, что этих рамок/разделений нет. Ты можешь натренировать скиллы, погрузиться в тему и работать, а не думать о том, куда идти, если ты не из тех. универа, девушка или у тебя рыжие волосы.
Основываясь на своём субъективном опыте, обычно есть 2 вида ручных тестировщиков - те, кто учился на мехматах, профильных вузах и специальностях, но программирование было для них слишком сложным, они не вывозили, а работать в айти хотелось. И вторые - люди со стороны, которые работали в других сферах, но услышали что в айти много платят и ломанулись сюда. Анастасия, вы к какому относитесь?
А ведь у вас даже нет варианта, что человек не хочет программировать.
Следуя вашей логике получается, что программисты - это не состоявшиеся Data Scientist.
И ещё кстати 95% ручных тестировщиков это женщины, по крайней мере в моём опыте. Буквально двух знаю мужчин.
Единственное с чем согласен - это качаства QA.. все остальное - вода мокрая..
От статьи сложилось впечатление что у автора комплекс неполноценности..
Спасибо, что прочитали статью и за ваш честный отзыв! Мы оперативно свяжемся с психологом и в ближайшем релизе это исправим!
Просто только на диване лежать и комменты строчить. С автором полностью согласен. Еще и зп у хорошего спеца могут быть выше чем у синьоров-разрабов и спрос огромный.
ну по мне так действительно если входить в айти из гуманитария, например - то только через тестировщика
программирование очень сложно освоить, а работать в сфере уже хочеца
Тестирование и разработка это разные вещи. Также как механик и водитель.
Работодатели зачастую заинтересованы в том, чтобы нанять человека, который будет выполнять свою работу профессионально, а не из-под палки и с навязчивой мыслю "быстрее бы свалить в разработку".
Входить в айти бездумно – это трата времени. Вы поступаете не в школу, где вас "должны" учить, вы устраиваетесь туда, где вам нужно будет работать и качественно выполнять свои задачи, как QA. Учиться вам придется самостоятельно в свое свободное время. Чтобы не перетруждать себя лучше сразу определить для себя желаемый вектор развития.
"тестировщик – это слишком просто" - да. Плохо - просто. Хорошо - сложно.
Искал в команду сотрудника, собеседовал человек 20 с опытом от полугода до нескольких лет, и у большинства нет знаний базовых техник тест-дизайна. И люди как-то работают, им зарплату платят, и некоторым даже весьма приличную на фоне других отраслей. Спрос есть, и предложение настолько больше, что работу может найти буквально любой специалист, отсюда и растут ноги у утверждения, что это просто.
Полностью согласна. Я это выразила в статье.
Люди идут "в айти по-простому" в первую попавшуюся галеру, где их готовы взять даже без понимания, зачем нужны QA, не говоря о базовой теории.
И эти люди сидят на одном месте, потому что за рутину они получают деньги – им комфортно. Поэтому они и ищут "простые пути", чтобы потом "просто сидеть". Они не становятся специалистами от того, что вошли в айти. Недостаточно просто зайти в айти.
Да, здесь есть высокие зарплаты, но также есть и низкие. Много платят профессионалам, а не людям, которые "я вошел в айти, платите мне много". Эта сфера развивается с высокой скоростью. И если не развиваться вместе с ней, так и останешься "по кнопочкам клац клац".
В IT-сфере есть много профессий и нужно просто выбрать свою.
Комментарий недоступен
Разработчики-ребята хорошие. Но люди, которые выбрали другие навыки, ничем не хуже.
В QA тоже можно программировать. В QA необходим хотя бы технический бэкграунд и вообще-то умение обращаться с компьютером не на пользовательском уровне. Увы, домохозяйка, которая не сможет разобраться в протоколах соединения или в тестовых окружениях - вылетит с испытательного срока)
При желании можно и 3 года обучаться программированию. Курс по питону средне занимает недели две, плюс различные курсы по компьютерным сетям, git и т.д по 2 дня. Если домохозяйке очень хочется программировать, то ей хватит 1-2 месяца.
Каждый выбирает то, что ему по душе.
Пилотом не каждый может стать. Нужно здоровье как минимум.
Переоценивать тоже не стоит
Тестировщики, родные, а вот скажите. Учусь сейчас на ПМа, и одно из учебных заданий было про тестирование. А там мы составляли тестовый сценарий. Вопрос один: реально он всегда создаётся? Вопрос второй: реально он всегда создаётся в текстовом редакторе, или уже давно есть специальные проги?
Почти никогда не создается, к сожалению. Много ресурсов занимает, особенно в аутсорсе, когда каждый час клиента стоит денег (они любят урезать косты, а тестирование сокращается охотнее всего).
Отвечая на второй, это помогает развивать воображение, когда сам рисуешь архитектуру с ветками в гугл таблицах. А так да, используют тулзы.
Если про мануальное тестирование.
Представьте, что у вас есть программа, которая обновляется раз в квартал, и каждый раз перед релизом нужно проверить, что все или основные функции работают.
Как это сделать, если не будут зафиксированы все сценарии, которые нужно пройти?
В ходе тестирования вы нашли баг. Теперь вам нужно объяснить разработчику в чем проблема, для этого описать свои действия.
Как же приятно просто скопировать сценарий и указать на шаге 8, кнопка не нажимается, хотя должна.
К вам пришел новый QA, как он будет находить и запоминать все сценарии если они не зафиксированы письменно
Комментарий недоступен
👍
Не тестер и QA тогда уж, а тестер и QA engineer. Так как инженер уже подразумевает знания какого-то языка. Тестер по факту это QA analyst. Но допускаю, что в России/снг могло что-то пойти по кривой (как часто бывает) и заложить в QA иной смысл.
Вы можете посоветовать какие-нибудь источники для обучения профессии manual qa?
Есть много курсов, от разных школ. Можете сами помскать какие-то онлайн, которые подойдут под ваши критерии
Есть большое количество источников по каждой теме, по инструментам и т.д. Можно пойти на курсы, но выбирать нужно тщательно. Можно изучать самостоятельно по темам, ориентируясь на программы наиболее известных курсов. А также можно работать с ментором, который подберет вам программу, соберет необходимые источники для обучения и поможет с изучением тем и инструментов.
Сейчас в Айти ситуация по аналогии с ВОВ - кадров жутко не хватает, а враг наступает.
Так что лычки раздают направо и налево. И войти через тестирование действительно легче
Комментарий недоступен
Комментарий недоступен
Статья не тупая, если читать статью, а не только заголовок :)