И снова здравствуйте! Сегодня у тестировщиков профессиональный праздник, с чем мы всех причастных и поздравляем! Ну и заодно предлагаем поговорить о тестировании программного обеспечения - о чем же еще? Для начала вспомним историю тестирования, её эволюцию и продвижение к современным концепциям. Если историю вы знаете, то первую часть можно пропустить. Во второй Никита Прокопенко, лидер команды автоматизации тестирования UI на устройствах SD, рассказывает о том, как проходят собеседования кандидатов на тестировщика ПО в Сбере. В любом случае, велкам под кат!

Как, когда и почему появилось направление тестирования ПО

История тестирования программного обеспечения насчитывает несколько десятков лет, и тут много интересного. Уже не будем вспоминать несчастного мотылька, благодаря которому появилось название «баг», но всё же воздадим должное этому безымянному представителю отряда чешуекрылых (если кому интересно, то на латыни название отряда — Lepidoptera). Но хватит лирики ― к делу!

Выделение направления тестирования ПО произошло где-то в 50-х годах прошлого века. Тогда всё, конечно, было по-другому. Например, в то уже далёкое для нас время главенствовала концепция исчерпывающего тестирования — ПО старались проверять от и до, стремясь анализировать все пути выполнения кода. С течением времени программное обеспечение усложнялось, и стало понятно, что исчерпывающее тестирование во многих случаях либо крайне сложно провести, либо вообще невозможно. В 1951 году Джозеф Джуран, которого сейчас считают отцом тестирования программного обеспечения, впервые отметил важность обеспечения качества программного обеспечения в своей книге «Руководство по контролю качества». Он также определил 3 части управления качеством: планирование качества, контроль и улучшение. Ну а в 1957 году Чарльз Л. Бейкер разграничил тестирование программ от отладки в своём обзоре книги Дэна Маккракена «Программирование цифровых компьютеров».

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

Примерно через 10 лет программы стали тестировать не в конце цикла написания, а в ходе всего процесса, что в идеальных условиях позволяло обнаружить проблему/ошибку сразу или почти сразу после её появления. В противном случае, если тестирование проводилось в конце цикла и обнаруживалась ошибка, то приходилось тратить большое количество усилий и времени на поиск первопричины проблемы.

Именно в 80-х годах XX века тестирование ПО проходило этап становления в узнаваемых и сейчас формах и концепциях. Тогда это направление вышло на новый уровень, появились новые методологии, стандарты, инструменты, позволяющие оптимизировать работу по проверке ПО. Кстати, важный момент: с 1983 по 1987 годы основное внимание специалистов уделялось оценке и измерению качества программного обеспечения. Тестирование улучшило индекс уверенности в том, как работает программное обеспечение. Тестировщики работали до тех пор, пока не достигали приемлемой точки, когда количество обнаруженных ошибок уменьшалось. Этот подход в основном был применим к объёмному программному обеспечению.

С течением времени тестирование ПО эволюционировало, расширялось и дополнялось. С 1988 по 2000 годы появился новый подход, когда тесты были сосредоточены на демонстрации того, что программное обеспечение соответствует его спецификации, обнаружении ошибок и предотвращении возникновения дефектов. В эту эпоху определение методов тестирования было ключевым. А в последнее десятилетие XX века также стало применяться исследовательское тестирование, когда тестировщик изучал и пытался как можно глубже понять исследуемое программное обеспечение, пытаясь найти больше ошибок.

В начале 2000-х появились гибкие методологии разработки и подходы. Стала весьма актуальной автоматизация тестирования ― её постепенно адаптировали в процессы работы многие компании и разработчики. Появились такие концепции, как  test-driven development (TDD) и behavioural-driven development (BDD), о которых много говорилось на Хабре, и, без сомнения, всё это ещё будет обсуждаться в будущем.

В 2004 году произошла крупная революция в тестировании с появлением открытых инструментов автоматизации тестирования Selenium. Точно так же тестирование API с использованием таких инструментов, как SOAP UI, стало ещё одним поворотным моментом в истории тестирования. Если интересно, об этом можно поговорить в одной или нескольких последующих статьях.

Что касается текущего этапа развития тестирования ПО, то об этом уже написаны десятки статей на самом Хабре, так что повторяться не будем. Единственное, стоит упомянуть, что сейчас активно используются гибкие методологии и тестирование, всё это глубоко интегрировано в процесс разработки. Повсеместно используется автоматизация, появилась масса инструментов, методов и технологий для работы тестировщиков.

Всё это очень упрощённо, но всё же даёт представление о том, как тестирование ПО пришло к своему нынешнему виду.

Ну хорошо, все это — история. А как стать тестировщиком в Сбере?

Как проходят собеседования на тестировщика в Сбере, рассказывает Никита Прокопенко, лидер команды автоматизации тестирования UI на устройствах SD. Он участвует во многих собеседованиях, так что поделиться есть чем. По его словам, большинство собеседований проходит штатно, но есть и те, что запоминаются. Кроме того, есть критерии успешного интервью, которые проявляются уже в первые минуты и ясно дают понять — собеседование пройдет как минимум интересно. Главное, конечно, это пресловутые «горящие глаза» и общая заинтересованность кандидата. Всё это заметно ещё на этапе знакомства. Большинство тех, кто проявляет неподдельный интерес к должности и самой работе, рассказывают про процессы в компании, при этом подмечая слабые места и предлагая идеи по их улучшению.

Следующий этап после знакомства — теория тестирования. Здесь тоже выделяются кандидаты, которым явно по душе тестирование. На этот этап заложено всего 15 минут, но с такими соискателями беседа затягивается. В целом, из диалога уже становится понятно, что кандидат понимает, как устроен процесс тестирования в его команде и что можно улучшить. В такой беседе его не спрашивают общие вещи, если заметно, что соискатель «не плавает» в вопросе, а явно неплохо разбирается в своей профессии и всём, что с ней связано.  Поэтому обсуждение заходит уже об общих процессах как ручного, так и автотестирования, а также рассказывается о взаимодействии в команде. Если всё совсем хорошо, то в ход идут уже ситуационные задачи, когда обсуждается некая стресс-ситуация, для которой кандидату нужно составить план действий по ее решению. У «интересных» кандидатов, о которых мы и говорим выше, уже есть опыт и варианты решения самых разных проблем.

Затем следует секция технических вопросов, которые касаются целевых технологий, используемых кандидатом в работе. Мы стараемся идти с вопросами по нарастающей сложности, не накидывая нечто глубоко техническое уже «с порога». Наоборот, всё начинается с общих определений — это нужно, чтобы специалист понял общий вектор вопросов и начал переключаться с софтовой части. В интересных собеседованиях на «раскачку» уходит совсем немного времени, так что кандидаты быстро погружаются в тему и могут отвечать на специфические вопросы. Например, можно начать с наиболее распространённого паттерна в автоматизации Page Object, после чего кандидат отвечает на вопрос, а затем рассказывает, какие еще паттерны он знает и применяет в своем проекте.

После этого остаётся время на лайв-кодинг, чтобы убедиться в способности кандидата решать практические задачи, а не просто теоретизировать. На собеседовании не даются сверхсложные задачи — всё, так сказать, в рамках базовых навыков. Задания в этой секции очень похожи на те, что можно порешать на Codewars или HackerRank — конечно, в пределах разумного: всё, что можно решить минут за 10-15. Мы разрешаем решать задачи на любом удобном кандидату языке программирования, чтобы оценить ход мысли и выбранный подход. У хороших кандидатов есть несколько вариантов решения, так что они ещё могут и рассказать о наиболее оптимальном из предложенных подходов.

На этом собеседование, как правило, завершается. Команда Сбера старается как можно быстрее дать обратную связь — как правило, в течение 1-2 дней.

Когда что-то идет не так

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

• Отсутствие интереса у кандидата к собственной работе. Например, уже во время знакомства на вопросы о том, что происходит в команде и как человек влияет на качество продукта, могут быть даны ответы вроде: «У нас нет процессов, автоматизирую, что дают», «Мне лид выдает задачи, я не погружаюсь в бизнес» и даже «А вам зачем, я же к вам устраиваться пришел?». Подобная реакция означает, что кандидат не погружается в суть происходящего и не особо понимает, в чем его роль, кроме написания автотестов.

• Поверхностные технические знания. Мы не прекращаем собеседование на этапе знакомства, а переходим к теории тестирования, чтобы можно было понять, есть ли у соискателя технический бэкграунд, самостоятельность, или же кандидат может лишь писать выданные третьей стороной тесты в рамках своей команды, без интереса к происходящему вокруг. Приятные сюрпризы возникают нечасто - обычно в связке с первым фактором сразу же проявляется и второй. Речь как раз о поверхностных знаниях, поскольку кандидат сразу же “впрыгивает” в код, стремясь автоматизировать хоть что-то, без разбора и понимания целей. Самый яркий пример - когда кандидат заявил, что считает необязательным знание теории тестирования автоматизатору тестирования. После этого он просто отключился от звонка.

1. В ситуационных задачах такие соискатели чаще всего отвечают однообразно, без поиска вариантов решения проблем. Ответ обычно: “Все отдам своему тимлиду, пусть он с проблемами и разбирается”.

2. На вопросах по технологическому стеку и лайв-кодингу такие кандидаты совершают общие ошибки и не проходят дальше базовых вопросов. Скорее всего, проблема в отсутствии подготовки перед собеседованием, с попыткой пройти “а вдруг прокатит”. Если “не прокатило” - всегда можно пойти на другое собеседование. Кстати, мы не сдаемся и на этом этапе, если вдруг кто-то отказывается от лайв-кодинга, то предлагаем просто посмотреть на задачи и описать хотя бы подход к их решению, который приходит в голову. Были случаи, когда соискатели неплохо описывали решение, а после обсуждения предлагали и готовое решение задачи.

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

В целом, чтобы стать хорошим специалистом, кандидат обязательно должен иметь интерес к своей работе — ведь в противном случае нет ни стремления к обучению, ни желания самосовершенствоваться. Конечно, нужны и знания, технический бекграунд, а также самодисциплина. Если кандидат не подготовился даже к собеседованию - то как он будет относиться к своей работе? Это риторический вопрос.

Ну и напоследок — несколько вакансий на должность тестировщика в команде Сбера:

• QA automation engineer (Kotlin).

• Mobile QA Engineer (Цифровые поверхности Салют SberDevices).

• QA engineer (Jazz)

• QA automation engineer (JavaScript)

Приходите обязательно, нам нужны профессионалы!