Тестировщик | IT

Наша главная задача как тестировщиков – это выявить реальный статус продукта. Помните – все остальные участники проекта сконцентрированы на Успехе, Предотвращении Проблем, Встраивании Качества, Добавлении Ценности, и всякое такое. Все это здорово, ничего плохого тут нет. Но есть нюанс. Оптимистический фокус, необходимый для создания продукта, может отвлечь внимание от проблем, угрожающих его качеству и ценности – проблемы, которые просочились мимо всех усилий их предотвратить. Как тестировщики, мы изучаем продукт, исследуем его и экспериментируем с ним, чтобы выявить его настоящее состояние, особо концентрируясь на поиске багов и риска. Это делает нас особенными: у всех остальных не стоит основной задачи искать неприятности – в том числе потенциальные.

Недавно моя знакомая разработчица из Канады искала работу в тестировании, в том числе в российских компаниях, и обратила внимание, что у нас собеседования сложнее: они более долгие, детальные и насыщенные техническими вопросами. У меня зарубежного опыта нет, но впечатления от интервью в наших компаниях позитивные — ищут скрупулёзно и надолго, готовы растить сотрудников и обращают внимание на софты. В этом тексте я расскажу, как прошёл около семи собеседований, три из которых были странными, и поделюсь своим опытом и рекомендациями: на каких площадках тестировщику лучше искать работу, чтобы поиск не затягивался, из каких этапов состоит интервью и что обычно спрашивают в технической части.

При выборе языка мне показался полезным такой совет: если вы сможете с ходу и в контексте QA перевести слова root cause, commercial off-the-shelf (COTS), ad hoc reviewing, inspection, boundary value analysis, equivalence partitioning, entry/exit criteria, approach, estimation, data-driven testing, keyword-driven testing, то, вероятно, английский вариант Syllabus вы осилите. Если же перевод этих терминов вызывает определенные сложности, то, скорее всего, стоит отложить английскую версию и готовиться по русскоязычной.

При тестировании требований и макетов возникает много вопросов? В этом видео мы рассмотрим на примерах основные рекомендации по формулированию вопросов к требованиям. После просмотра вы наладите понимание с аналитиками :)

Иногда, когда я говорю, что в мире есть дураки, стремящиеся уничтожить культуру и искусство тестирования, люди мне не верят. Вот хороший пример того, что я имею в виду: «Тесты – это плохо для разработчиков». Пост написан Стефаном Шмидтом. Он говорит, что у него за плечами более сорока лет разработки. У меня их столько же (1 января 2024 стукнул 41 год, годовщина моего первого рабочего дня в Dale Disharoon, Inc. Моим первым проектом было создание игры Hey Diddle Diddle для Apple II и С64). Возможно, разница между нами в том, что я всю свою карьеру занимался именно тестированием, а он говорит, что «пишет тесты» в ходе разработки. Между написанием тестов, предполагаю, он пишет код продукта, а это не тестирование. То есть он в лучшем случае поверхностно знаком с нашей отраслью. В своей статье он заявляет, что QA-специалисты не должны тестировать, и что заниматься этим должны только разработчики. Поясню: он считает, что мир станет лучше, если разработчики, которые тестируют в лучшем случае изредка и не учились этому специально, будут единственными тестирующими людьми. Он считает, что эта ответственность лежит на разработчиках. Я считаю это шокирующе глупой идеей.

«Уметь разрабатывать» — не то же самое, что «уметь тестировать». Учиться тестированию нужно отдельно, и чаще всего разработчик не умеет писать тестовые сценарии, проводить различные виды тестов и автоматизировать процесс. Так что QA-специалист — это другая профессия. Не менее сложная, чем профессия разработчика.

Знаменитая фраза Аристотеля звучит, как «Чем больше вы знаете, тем больше понимаете, что ничего не знаете». Я давно знаю, что так оно и есть, но не применял это знание на практике. Поэтому теперь я концентрирую свои размышления, записи, тренинги, доклады и работу в целом на темах, которые меня интересуют, с радостью оставляя все остальное другим. Я просто не могу успевать все и знать все, и не думаю, что кто-либо может.