"Тестировщик" – это просто

"Тестировщик" – это просто

Не буду повторяться про большую разницу "тестировщик" и QA. Да, нельзя путать эти понятия. В этой статье мы будем использовать народное слово "тестировщик", а думать про QA.

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

Из-за этих заблуждений на рынке очень мало хороших QA
Люди, которые так считают, возможно, априори не смогут “легко войти в айти”. Да и стать крутыми специалистами. Сейчас объясню почему. В этих фразах четко прослеживается: обесценивание чужого труда, незнание особенностей профессии QA, кодоцентричность и отсутствие тактичности. Для QA важно критическое мышление, чего мы не наблюдаем в этих фразах.

Обесценивание чужого труда – это прямой путь к оправданию своей лени.
Лень разобраться, почитать десяток статей и одну книгу. Лень понимать компетентных людей, лень думать.Когда меня спрашивают “Чего ты не хотела бы видеть в команде/компании?”, первое, что я отвечаю, это “Чтобы никто не обесценивал чужой труд”. Такое может встречаться относительно любой профессии. Люди от незнания считают, что тестирование – это просто кликанье на кнопочки, что фронтенд – это изи, что дизайнер – это не серьезно и TypeScript – язык для лохов и т.д. Стоит лишь поработать полгода с тем, что кажется простым, и придет понимание, что у этого есть свое предназначение и без этой составляющей не построить успешный бизнес.

Так что же “сложного” в QA

Выучить список техник тест-дизайна – просто. Понять и научиться их применять – не просто. Это приходит с продолжительным трудом, работой и умением системно мыслить.

Увидеть, что кнопка не работает – просто. Продумать заранее неочевидные сценарии, в которых кнопка может не работать – сложно. Кликнуть на готовую кнопку – просто. Кликнуть на несуществующую кнопку – сложно. Сложно проверить несуществующее. И сложно предотвратить несуществующее. А еще сложнее, когда работа кнопки зависит от других компонентов системы, от нагрузки на сервер и от много чего другого одновременно.

Сказать, что эта кнопка не работает – просто. А понять в каких сценариях она ломается и почему – сложно. Предвидеть аналогичные ошибки в будущем, тоже непросто.

А какие главные и основополагающие качества QA?

  • Внимательность
  • Критическое мышление
  • Честность. Если QA что-то не учел при тестировании, он должен уметь честно и без страха в этом признаться. Важно вовремя и честно говорить о проблемах. Это важно для продукта, для бизнеса, для пользователя. Нормально – что-то упускать, забывать, не нормально – скрывать, забивать.
  • Умение давать честный фидбэк и принимать критику в свою сторону
  • Умение грамотно и четко документировать
  • QA – это адвокат пользователя

Мы говорили сейчас о ручных QA. Но не забываем про ветку QA Automation, где недостаточно всего вышеописанного. При автоматизации вы заставляете тачку воспроизводить код разработчика так, как вам нужно. И предварительно, используя все знания о тестировании и свой опыт, вам нужно определить – как вам нужно.

Каждая профессия несет свою ценность, как и любой труд.

2323 показа
10K10K открытий
22 репоста
52 комментария

"тестировщики просто нажимают кнопочки", "легко войти в айти через тестирование", "разработка – это для умных, а в тестировании много ума не надо"

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

Ответить

Идёт речь не о тестировщиках. А о QA Engineer.

Ответить

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

Ответить

Разбор пирамиды тестирования в этой статье приводить не стала, вместо этого выразилась так, как посчитала нужным.
Я на своем пути не встречала разработчика, который не пишет юнит тесты.
Это работает и в обратную сторону: тестер, который не понимает код и не знает, как он выглядит, будет оставаться в высокоуровневом тестировании.

Ответить

Спасибо за статью!
Есть мнение, что по пути QA проще всего войти в IT, я считаю это очень большим заблуждением. По моему мнению, нет "простого" маршрута, есть время и усилия в любом направлении. Не согласен с комментаторами, которые стараются разделить по какой-то выдуманной статистике тех, кто работает в каком-либо направлении (в данном случае в QA), тем самым указывая кто конкретно должен работать в этом направлении.
IT направления идеальны тем, что этих рамок/разделений нет. Ты можешь натренировать скиллы, погрузиться в тему и работать, а не думать о том, куда идти, если ты не из тех. универа, девушка или у тебя рыжие волосы.

Ответить

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

Ответить

А ведь у вас даже нет варианта, что человек не хочет программировать.
Следуя вашей логике получается, что программисты - это не состоявшиеся Data Scientist.

Ответить