Как стать qa-инженером?

На микроволновках

Допустим, в компании решили создать бытовую микроволновку.

Продакт-менеджер:
Коллеги, нам нужно устройство, в котором люди смогут разогревать блюда, но без нагревательного элемента. Чтобы работала быстро. Размер такой-то. Нужна дверца. Обязательно таймер.

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

Продакт:
Ничего не понял, делайте.

Инженер по тестированию:
Постойте!

Все:
Что?

Инженер по тестированию:
От какого напряжения будет работать? Какая будет защита от перепадов? А если включить в розетку вдвое менее мощную? Что там можно будет греть, а что нельзя? Что если включить с открытой дверцей? Что будет, если греть воду? Что если греть камень? А сталь? А кота? А динамит? А если поджечь фитиль? А если туда ничего не положить и включить?

Все крепко думают.

Это и есть работа тестировщика: убедиться, что продукт работает нормально в штатных и внештатных ситуациях. По-умному будет так: «Насколько реальное поведение продукта совпадает с ожидаемым и как это отразится на опыте пользователя?»

Распределённая команда нагрузочного тестирования в Miro

«Центр» — команда НТ — центр компетенций и поддержки

Зоны ответственности:Разработка инструментария (особое внимание к качеству!). У функциональных команд заказчик — клиенты Miro, у нашей команды заказчик — функциональные команды

Внутренние инструменты не должны быть поделками, сделанными «на коленке». Это должны быть полноценные и качественные продукты с должным уровнем поддержки всех видов. Функциональные команды и так загружены и повышать их уровень стресса плохими инструментами — недопустимо. Поэтому у нас есть:Мастер-классы.
Miro доски-презентации.
Confluence документация.
Версии, changelog, детальная отладочная информация в ходе работы инструмента.
Общий репозиторий с примерами кода и всеми НТ сценариями, чтобы было единое место, где собрана вся практика НТ.
Отдельные чаты на каждый инструмент для поддержки, сообщений о релизах, багрепортов и фичереквестов.

Помощь в обучении и консультирование коллег из функциональных команд, не только QA инженеров.
Проведение больших тестов, когда нужна проверка суммы функционала от множества команд.
Поддержка тестовых окружений совместно с QA Automation Team и DevOps Team.

«Агенты» — QA инженеры и разработчики в функциональных командах — проводят более узконаправленные тесты.

Основные задачи тестирования

Еще несколько терминов, которые связаны с упомянутыми двумя задачами, которыми занимается тестировщик, это стимулы, реакции и оракул.

• Стимулы – это данные, которые подаются на вход программе.
• Реакции — это то, что получается на выходе.
• Оракул — это способ проверки наблюдаемого результата, совпадает он с некоторыми ожиданиями или не совпадает.

Программа представляет собой механизм по переработке информации. На вход поступает информация в каком-то одном виде, на выходе информация в некотором другом виде. При этом входов и выходов у программы может быть много, они могут быть разными, то есть у программы может быть несколько разных интерфейсов, и эти интерфейсы могут иметь разные виды:

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• графический,
• текстовый,
• консольный,
• и речевой.

Через пользовательский интерфейс компьютер взаимодействует с человеком, с пользователем.

Через программный интерфейс программы взаимодействуют друг с другом (человек тут не нужен).

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

Это файловая система, программы могут писать данные на диск и читать данные с диска.

Это состояние окружения, которое могут программы модифицировать и, соответственно, тоже читать.

Это события, в частности, таймер. То есть некоторые механизмы отслеживания времени.

Используя все эти интерфейсы, тестировщик каким-то образом создает искусственные ситуации, и проверяет в этих ситуациях как программа себя ведет. Вот это и есть тестирование.

Что нужно, чтобы стать хорошим QA-инженером

Для начала стоит понять, ваше ли это. Я бы выделил несколько основных особенностей работы и черт характера, чтобы заниматься тестированием.

Техническая эрудиция

«Technical savvy», как иногда пишут в вакансиях, и желание разбираться в технологиях. Вы должны интересоваться тем, как что работает, как что устроено внутри. Это понимание сослужит хорошую службу в будущем и обычно идёт в связке с необходимым хорошему тестировщику любопытством.

Вы когда-нибудь ставили и настраивали Linux — для себя, чисто из интереса? Пытались разобраться, как работает блокчейн? Делали друзьям сайт на WordPress? Если нет, попробуйте и проследите за своей реакцией. Интересно ли, подстегивают ли сложности найти решение, покопаться в Google и на форумах? Когда конечный результат не тот, появляется ли желание докопаться и сделать, чтобы всё начало работать как надо? Если вы ответили «да», скорее всего, тестирование вам подходит.

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

Ориентированность на пользователя и бизнес

Есть хорошая шутка про тестировщика, который заходит в бар, и лучшее продолжение для клиента.

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

В вакансиях часто пишут «ориентированность на детали, перфекционизм». Они нужны, но только если правильно сфокусированы.

Умение структурировано думать и писать

Проведите мысленный эксперимент: представьте, что вам нужно описать, как тестировать центральный замок автомобиля. Вы начнёте писать, например, «открыть, закрыть», но есть же разные состояния: «открыть уже открытое», «закрыть уже закрытое», — или разные точки воздействия: можно открывать брелком, ключом, кнопками изнутри

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

Умение работать с большими объёмами данных и быстро учиться

В работе вам скорее всего понадобится навык работать с большими и плохо структурированными объёмами информациями (также известными как «спецификация», «техническое задание», «корпоративная база знаний»), быстро понимать как работает сложная (и не всегда логично написанная) система и быстро получать базовые знания в абсолютно разных областях. Если ваш проект про управление финансовыми портфелями — придётся разобраться в финансах, если про управление складом — в логистике и т. д. Хороший способ проверить себя — взять и успешно пройти какой-нибудь курс на coursera.com по незнакомому и фундаментальному предмету, желательно на английском.

Умение говорить с людьми на неприятные темы

Очень много и очень хорошо говорить.

Middle Java Developer

L2U, Москва, Новосибирск, можно удалённо

tproger.ru

Вакансии на tproger.ru

Существует распространённый стереотип, что тестировщики и программисты недолюбливают друг друга как копы и федералы из американских фильмов. Это неправда.

Кто такой Software Engineer in Test

На моей текущей работе недавно сменился босс и он регламентировал, что QA — полностью обязанность каждого сотрудника, а я для них Software Engineer in Test. 

При ближайшем рассмотрении Software Engineer in Test у меня получилось, что это тоже QC Engineer с одной лишь разницей, что фокус его обязанностей в автоматизации тестирования и включает и разработку собственного фреймворка/инструмента, и написание автотестов:

• Создание/расширение фреймворка для тестирования.

• Разработка вспомогательных утилит для тестирования сервисов.

• Настройка и поддержка тестового окружения.

• Настройка автоматизированных тестов для надежного и эффективного выполнения в средах CI / CD.

• Обеспечение оптимального покрытия автотестами на всех уровнях.

• Автоматизация отчетности.

• и т.п.

Обязанности второго плана по сути копируют список QC Engineer.Подробнее про Software Engineer in Test можно почитать в How Google Tests Software (есть переведенная на русский)

Профессия QA Engineer: кто такие и что делают

QA-инженером (Quality Assurance Engineer) называют специалиста, который занимается функциональным тестированием программного обеспечения на всех этапах разработки. Чтобы более детально говорить о Quality Assurance, нужно разобраться с терминологией.

Многие ошибочно думают, что термины Quality Assurance, Quality Control и тестирование – это синонимы. Но это неверное суждение.

• Quality Assurance (QA). QA-специалисты подготавливают и устанавливают стандарты, анализируют качество, выбирают инструменты, предотвращают ошибки и совершенствуют программу. 
• Quality Control (QC). Контроль качества продукта отвечает за анализ результатов тестирования, поиск и устранение ошибок. QC-специалисты анализируют код, технические обзоры и проверяют программу.
• Тестирование программного обеспечения (Software Testing). Тестировщики проверяют готовый продукт на соответствия установленным требованиям. 

Что должен уметь QA Engineer: основные навыки и обязанности

Теоретические знания и практические умения:

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

Английский язык

Английский язык для QA-тестера очень важен. В большинстве случаев заказчики или часть команды находятся в других странах и коммуницировать с ними приходится на английском. 

• Баги, которые обнаружил тестировщик, он должен описывать в специальной системе.
• Умение детально описать ошибки и присваивать им приоритетность по устранению.
• Описывать свой путь в программе и указать другие детали, которые помогут разработчикам все подправить.
• Умение работать с тест-кейсами, тест-листами, чек-листами и баг-трекерами. 

Дополнительные технологии:

• Умение работать с HTML/CSS, JavaScript, jQuery и HTTP для тестирования web-приложений.
• Чтобы было легче тестировать мобильные приложения, нужно уметь работать с Genymotion, VirtualBox и iOS Simulator. 

Владение языками запроса SQL и умение работать с базами данных

Умение работать с языком запроса SQL встречается в каждой вакансии тестировщика. QA-инженерам, которые планируют тестить программы и приложения язык запросов SQL и работа с базами данных будут очень полезны. 

Важные качества, на которые нужно обратить внимание при собеседовании QA-инженера

1. Аналитический ум и внимательность для обнаружения даже маленьких ошибок.
2. Стратегическое и абстрактное мышление, умение моделировать и абстрагироваться от внешних факторов.
3. Умение работать с командой, аргументированно объяснять свои решения.
4. Перфекционизм, ответственность, усидчивость.
5. Умение расставлять приоритеты, находить компромиссы, настойчивость.

F.A.Q QA — обеспечение качеством

Что такое обеспечение качества программного обеспечения?

Обеспечение качества программного обеспечения определяется действиями, которые контролируют, измеряют, оценивают и проверяют процессы, используемые для создания программного обеспечения.

Каждой программе требуется тестер?

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

Что такое план тестирования?

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

Как мне может помочь юзабилити-тестирование?

Юзабилити-тестирование измеряет простоту использования программного приложения. Как таковая, она является неотъемлемой частью качества программного обеспечения. Даже самый интересный и продаваемый программный продукт пострадает в популярности, если он покажет громоздкое удобство использования.

Почему в программном обеспечении есть ошибки?

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

Как тестируются сайты?

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

Что такое качество программного обеспечения?

Качество программного обеспечения — это соответствие программного обеспечения его требованиям.

Что такое регрессионное тестирование?

Регрессионное тестирование — это цикл обеспечения качества, при котором ошибки, обнаруженные во время предыдущего обзора обеспечения качества, «регрессируются», чтобы гарантировать, что

• а) они были исправлены разработчиками,
• b) в результате исправлений не было создано никаких новых ошибок.

Кто такой бета-тестер?

Бета-тестер — это тот, кто тестирует бета-версию программного приложения. Они могут быть профессиональными тестировщиками или членами целевой аудитории программного обеспечения.

Каковы основные этапы QA процесса?

Работа с требованиями

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

Планирование тестирования

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

Разработка тестовых сценариев

Имея на руках план, пора разработать тестовые сценарии или тест кейсы, создать чек-листы, подготовить среду для выполнения тестов и создать сценарии для автоматического тестирования.

Тестирование программного обеспечения

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

Повторное тестирование

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

Завершение тестирования

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

Задачи и обязанности

Основная задача QA — обеспечение качества

QA-инженер фокусирует внимание на процессах разработки ПО, улучшает их, предотвращает появление дефектов и проблем (Makes sure you are doing the right things, the right way)

Процесс обеспечения качества состоит из таких этапов:— проверка требований к продукту;— оценка рисков;— планирование идей по улучшению качества продукта;— планирование тестирования;— анализ результатов тестирования;

Внутри процесса QA выделяют процесс Quality Control — контроль качества продукта. QC-специалисты анализируют результаты тестирования и отвечают за выявление и уничтожение дефектов в продукте (Makes sure the results of what you have done is what you expected).

Еще более узкая специальность в рамках QA/QC — тестировщик ПО, который проверяет готовый продукт на наличие ошибок (багов) и несоответствие требованиям, и затем документирует найденные дефекты и пути их воспроизведения. Тестирование — это один из этапов обеспечения и контроля качества.

Есть 4 основные роли:

• Test Analyst — занимается статическим тестированием требований: проверяет, насколько они полны, однозначны, непротиворечивы etc;
• Test Designer — создает набор тестов на базе требований, планирует конфигурации, необходимые для тестирования;
• Test Executor — выполняет заранее подготовленные тесты, документирует найденные ошибки и шаги их воспроизведения;
• Test Manager — скорее управленец, чем инженер. Планирует и контролирует работы, связанные с тестированием: оценки сроков, работу над планом-графиком, контроль покрытия требований тестами, постановку задач членам команды, коммуникацию со стейкхолдерами).

В Украине различия между должностями QA и тестировщика смазаны, и на практике это одно и то же. Хотя теоретически тестировщик тестирует продукт как результат, а QA работает над обеспечением процессов, которые могут повысить качество ПО в целом.

В круг обязанностей QA-инженера входит:— Анализ и уточнение требований с заказчиком или бизнес-аналитиками;— Планирование процесса тестирования;— Написание тест-кейсов (сценариев тестирования);— Тестирование функционала;— Идентификация проблемных мест, внесение их в трэкинговую систему;— Обсуждение фиксов с разработчиками;— Отслеживание жизненного цикла ошибок;— Ре-тест починенных дефектов;— Анализ тестирования;— Оптимизация процесса тестирования;— Анализ процессов работы в команде;— Улучшение процессов;— Ведение тестовой документации.

Типичный рабочий день QA-специалиста включает в себя:— Написание тест-кейсов, тестирование, документирование ошибок (в зависимости от фазы проекта);— Проверка баг-трекинговой системы на предмет появления исправленных ошибок;— Стенд-ап митинги;— Изучение требований, их уточнение у заказчика;— Активное общение с разработчиками;— Оформление тестовой документации.

Тестирование методом черного и белого ящика

Наконец, третья широко распространенная классификация — разделение тестирования на два больших класса: тестирование методом черного ящика и тестирование методом белого ящика. Эта классификация связана с таким понятием как «полнота тестирования». Поэтому сначала мы поговорим именно о ней.

Полнота тестирования

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

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

Когда мы собираем полное собрание сочинений, то у нас нет цели скупить все книги, полностью весь тираж, нам нужно чтобы в нашу коллекцию попало по одной книжке каждого вида.

И вот когда мы собираем с вами эту коллекцию бабочек, мы можем, конечно же, ориентироваться только на раскраску крыльев

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

Но одного рисунка нам недостаточно. Нам нужно еще принимать во внимание внутреннее устройство

И тогда мы должны были бы их тоже включить в коллекцию, мы же пытаемся собрать все виды бабочек. Но одного рисунка нам недостаточно

Нам нужно еще принимать во внимание внутреннее устройство

И вот это как раз и есть разница между тестированием методом черного ящика и тестированием методом белого ящика.

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

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

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

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

Мы принимаем во внимание и ее внешнее поведение, и ее внутреннее устройство. Коллекция тестов увеличивается

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

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

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

Что входит в основной пул обязанностей QA-автоматизатора?

АЛЕКСЕЙ БЕДУНКЕВИЧ: Как ни странно, автоматизация QA процессов:

• Составление плана и стратегии
• Автоматизация тесткейсов
• Настройка CI, репортинг, и нотификация

ЕКАТЕРИНА ЖУКОВСКАЯ: Обязанности разнятся от проекта к проекту. В основном это непосредственно:

• Разработка фреймворка для автоматизации продукта и написание автотестов
• Настройка окружения, создание дополнительных условий для корректного функционирования автотестов
• Интеграция автотестов с порталами баг репортинга для последующего анализа результатов
• Интеграция с системами автозапуска (CI/CD) и с системами отслеживания версий.
• Но самая главная обязанность – любить свою работу.

В чем проблема?

Одна из главных причин возникновения ситуации, описанной выше, — это отсутствие культуры разработки, в которой каждый разработчик несет ответственность за написанный им код. А даже минимальная ответственность понимает под собой необходимость удостовериться в работоспособности кода прежде чем радостно восклицать: “Моя работа готова!”.

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

Наиболее оптимальный способ — это написание автотестов на разрабатываемый код

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

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

Выводы

При выборе кандидата на должность специалиста по тестированию определяющими будут опыт и знания, а не наличие сертификата

Хотя при наличии схожих навыков предпочтение отдадут сертифицированному специалисту.
Сертификация помогает в развитии карьеры (для 90% менеджеров важно иметь в команде 50-100% сертифицированных тестировщиков), кроме того, в некоторых зарубежных компаниях получение сертификата является поводом для повышения зарплаты.
Сертификация помогает повысить вашу уверенность в собственных силах. Это также помогает вам развить способность думать о вещах под разными углами, вы растете как специалист.

В первой части нашей статьиВо второй части статьиАнна ПалейПавла Толоконина