{"id":14279,"url":"\/distributions\/14279\/click?bit=1&hash=4408d97a995353c62a7353088166cda4ded361bf29df096e086ea0bbb9c1b2fc","title":"\u0427\u0442\u043e \u0432\u044b\u0431\u0435\u0440\u0435\u0442\u0435: \u0432\u044b\u0435\u0445\u0430\u0442\u044c \u043f\u043e\u0437\u0436\u0435 \u0438\u043b\u0438 \u0437\u0430\u0435\u0445\u0430\u0442\u044c \u0440\u0430\u043d\u044c\u0448\u0435?","buttonText":"","imageUuid":""}

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

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

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

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

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

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

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

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

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

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

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

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

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

0
52 комментария
Написать комментарий...
Михаил Грозовский

Тестировщики, родные, а вот скажите. Учусь сейчас на ПМа, и одно из учебных заданий было про тестирование. А там мы составляли тестовый сценарий. Вопрос один: реально он всегда создаётся? Вопрос второй: реально он всегда создаётся в текстовом редакторе, или уже давно есть специальные проги?

Ответить
Развернуть ветку
Ingvar K

Если про мануальное тестирование.

Представьте, что у вас есть программа, которая обновляется раз в квартал, и каждый раз перед релизом нужно проверить, что все или основные функции работают.
Как это сделать, если не будут зафиксированы все сценарии, которые нужно пройти?

В ходе тестирования вы нашли баг. Теперь вам нужно объяснить разработчику в чем проблема, для этого описать свои действия.
Как же приятно просто скопировать сценарий и указать на шаге 8, кнопка не нажимается, хотя должна.

К вам пришел новый QA, как он будет находить и запоминать все сценарии если они не зафиксированы письменно

Ответить
Развернуть ветку
Михаил Грозовский

Игорь, спасибо. Очень пространный ответ. Это на мой вопрос?

Ответить
Развернуть ветку
Ingvar K

Это ответ на:
"мы составляли тестовый сценарий. Вопрос один: реально он всегда создаётся?"

Без зафиксированных сценариев невозможно нормально регулярно вручную тестировать программу.

Ответить
Развернуть ветку
49 комментариев
Раскрывать всегда