QA-тестировщик

Тестирование программного обеспечения — это процесс исследования и проверки программного продукта с целью обнаружения дефектов, проверки соответствия требованиям и оценки его качества. Главная задача тестирования — убедиться, что программа работает так, как ожидается, и выявить ситуации, в которых фактический результат отличается от ожидаемого. Например, если интернет-магазин должен позволять пользователю добавить товар в корзину, тестировщик проверяет, добавляется ли товар, правильно ли отображается его название и цена, изменяется ли количество, можно ли удалить товар и что происходит при различных ошибочных действиях пользователя. В тестировании используются понятия Expected Result — ожидаемый результат, то есть то, что должно произойти, и Actual Result — фактический результат, то есть то, что произошло в программе. Если фактический результат отличается от ожидаемого и это противоречит требованиям, может быть обнаружен Bug, то есть дефект программного обеспечения.

QA-тестировщик — специалист, который занимается обеспечением и контролем качества программного продукта. QA расшифровывается как Quality Assurance, то есть «обеспечение качества». Работа QA не ограничивается только поиском ошибок. Тестировщик изучает требования, определяет, что необходимо проверить, создаёт тестовую документацию, выполняет различные виды тестирования, фиксирует найденные дефекты, проверяет исправления и контролирует качество продукта. QA может участвовать в проекте ещё до начала разработки: например, изучать требования и находить в них неоднозначности или противоречия. Это позволяет предотвратить часть проблем ещё до написания кода. Тестировщик также взаимодействует с разработчиками, аналитиками, менеджерами и другими участниками команды. В зависимости от специализации существует ручное и автоматизированное тестирование. Manual QA выполняет проверки вручную, а Automation QA создаёт автоматизированные тесты, которые выполняются с помощью программного кода.

Методология разработки ПО — это система принципов, правил и практик, которая определяет, каким образом команда создаёт и поддерживает программное обеспечение. Методология помогает организовать работу команды, распределить задачи, контролировать сроки, управлять требованиями и понимать, на каком этапе находится проект. Одной из традиционных методологий является Waterfall, или каскадная модель. В ней этапы выполняются последовательно: сначала собираются требования, затем проектируется система, выполняется разработка, тестирование, релиз и поддержка. Главный недостаток такого подхода заключается в том, что изменения на поздних этапах могут быть дорогими и сложными. Agile — это не одна конкретная методология, а набор принципов гибкой разработки. Agile делает акцент на взаимодействии команды, работающем продукте, сотрудничестве с заказчиком и готовности к изменениям. Работа обычно выполняется небольшими частями, чтобы команда могла регулярно получать обратную связь и улучшать продукт. Scrum — популярный фреймворк Agile. Работа в Scrum организована через спринты — ограниченные по времени периоды, в течение которых команда создаёт определённый объём функциональности. Основные роли Scrum — Product Owner, который отвечает за ценность продукта и управление Product Backlog, Scrum Master, который помогает команде правильно использовать Scrum и устранять препятствия, и Developers, которые создают продукт. Основные события Scrum включают Sprint, Sprint Planning, Daily Scrum, Sprint Review и Sprint Retrospective. Product Backlog содержит список необходимых изменений и функций продукта, а Sprint Backlog содержит задачи, выбранные для конкретного спринта. Kanban — подход к управлению потоком работы. Основным инструментом является Kanban-доска, на которой задачи перемещаются между этапами, например «To Do → In Progress → Testing → Done». В Kanban большое значение имеет ограничение WIP — Work In Progress, то есть количества задач, которые одновременно находятся в работе. Это помогает не перегружать команду и быстрее доводить начатые задачи до завершения.

Функциональное тестирование направлено на проверку того, что программа выполняет свои функции в соответствии с требованиями. Например, если интернет-магазин должен позволять пользователю добавлять товар в корзину, тестировщик проверяет возможность добавления товара, изменения его количества и удаления из корзины. Нефункциональное тестирование проверяет не конкретную бизнес-функцию, а характеристики системы. К нему относятся тестирование производительности, нагрузки, безопасности, удобства использования, совместимости, надёжности и других характеристик. Например, можно проверить, как сайт работает при одновременном подключении большого количества пользователей. Метод чёрного ящика означает, что тестировщик не использует информацию о внутреннем коде программы и оценивает систему по входным данным и результатам. Метод белого ящика предполагает знание внутреннего устройства программы, её кода, условий, циклов и логики. Такой подход часто используется разработчиками при модульном тестировании и специалистами по автоматизации. Серый ящик является промежуточным вариантом: тестировщик знает некоторую информацию о внутреннем устройстве системы, но не имеет полного доступа или не использует его полностью. Уровни тестирования показывают масштаб проверки. Unit Testing, или модульное тестирование, проверяет отдельные небольшие компоненты программы, например функцию или метод. Integration Testing проверяет взаимодействие нескольких компонентов между собой, например взаимодействие приложения с базой данных или API. System Testing проверяет полностью интегрированную систему с точки зрения требований к продукту. UAT, или User Acceptance Testing, — приёмочное тестирование, при котором проверяется, удовлетворяет ли система бизнес-потребностям и готова ли она к использованию заказчиком или конечными пользователями. В упрощённом виде уровни можно представить так: Unit → Integration → System → UAT.

Техники тест-дизайна нужны для того, чтобы эффективно выбирать тестовые данные и сценарии. Если пытаться проверить абсолютно все возможные значения и комбинации, количество тестов может стать огромным. Поэтому тестировщик использует специальные техники, позволяющие получить хорошее покрытие меньшим количеством проверок. Класс эквивалентности предполагает разделение возможных входных данных на группы, называемые классами эквивалентности. Например, поле «Возраст» принимает значения от 18 до 60 лет. Можно выделить три группы: значения меньше 18, значения от 18 до 60 и значения больше 60. Проверка нескольких представителей каждой группы может дать информацию о поведении системы для всего класса. Анализ граничных значений предполагает проверку значений на границах и рядом с ними. Для диапазона 18–60 полезно проверить 17, 18, 19, 59, 60 и 61. Парное тестирование используется, когда у системы есть несколько параметров с большим количеством значений и невозможно проверить все комбинации. Вместо полного перебора выбираются такие комбинации, чтобы каждое значение одного параметра сочеталось с каждым значением другого параметра хотя бы один раз. Предугадывание ошибок, или Error Guessing, основывается на опыте тестировщика. Тестировщик заранее предполагает места, где может возникнуть ошибка, например пустые поля, специальные символы, слишком длинный текст, повторное нажатие кнопки или неправильный формат данных. Исследовательское тестирование — это подход, при котором тестировщик одновременно изучает систему, формирует идеи для проверок и выполняет их. Оно особенно полезно, когда документации недостаточно, продукт быстро меняется или необходимо быстро найти неизвестные проблемы.

Тестовая документация помогает организовать процесс тестирования и сделать его понятным для всей команды. В зависимости от проекта набор документов может отличаться, но часто используются Test Plan, Test Strategy, Test Case, Checklist, Bug Report и Test Summary Report. Test Plan описывает конкретный план тестирования: что необходимо проверить, какие ресурсы и сроки нужны, какие виды тестирования будут выполняться и какие существуют риски. Test Strategy описывает общий подход к тестированию: какие принципы, методы, инструменты и виды тестирования будут использоваться. Test Case представляет собой подробную инструкцию для проверки конкретного сценария и обычно содержит идентификатор, название, предусловия, тестовые данные, шаги, ожидаемый результат и другие атрибуты. Checklist представляет собой более краткий список проверок, позволяющий быстро контролировать функциональность. Bug Report создаётся при обнаружении дефекта и содержит информацию, необходимую разработчику для понимания и воспроизведения проблемы. Test Summary Report создаётся после завершения тестирования и содержит итоговые результаты: что было протестировано, сколько тестов выполнено, сколько дефектов найдено, какие проблемы остались и можно ли считать тестирование завершённым. Документы создаются на основе требований проекта и должны регулярно обновляться при изменении продукта.

Test Plan — это документ, который описывает организацию тестирования конкретного проекта, продукта, версии или определённого объёма работ. В нём указывается цель тестирования и определяется Scope, то есть область, которая входит в тестирование и которая не входит в него. Также описываются виды и уровни тестирования, тестовое окружение, необходимые инструменты, роли участников команды, сроки, ресурсы, критерии начала и завершения тестирования, риски и способы их снижения. Например, в Test Plan может быть указано, что необходимо провести функциональное, регрессионное и интеграционное тестирование, а нагрузочное тестирование в текущий этап не входит. Test Strategy определяет общий подход к тестированию. Она обычно является более высокоуровневым документом и может использоваться для нескольких проектов или длительного периода. В стратегии могут быть описаны цели тестирования, уровни и виды тестирования, подход к автоматизации, инструменты, управление дефектами, требования к окружению, критерии качества, риски и принципы отчётности. Главное отличие состоит в масштабе: стратегия определяет общий подход, а план конкретизирует, как этот подход будет применяться в конкретном проекте или этапе.

Test Case — это документированная последовательность действий, которая используется для проверки определённого поведения программного продукта. Хороший тест-кейс должен быть понятным, однозначным и воспроизводимым. Обычно он содержит ID, название, предусловия, тестовые данные, последовательность шагов, ожидаемый результат, фактический результат и статус. Дополнительно могут указываться приоритет, важность, окружение, автор и другие данные. Чтобы создать тест-кейс, сначала необходимо изучить требования, определить проверяемую функцию, подготовить необходимые данные, описать условия и шаги, а затем указать ожидаемый результат. Например, для авторизации можно создать тест-кейс, в котором пользователь открывает страницу входа, вводит корректные данные и нажимает кнопку «Войти», после чего ожидается успешный вход в аккаунт. Checklist — это список проверок, который используется для быстрого контроля функциональности. Например: «Проверить вход с правильными данными», «Проверить вход с неправильным паролем», «Проверить восстановление пароля», «Проверить выход из аккаунта». В отличие от тест-кейса, чек-лист обычно не содержит подробного описания каждого шага. Test Case лучше использовать, когда важна детальная воспроизводимость и необходимо точно зафиксировать процесс проверки. Checklist удобен, когда тестировщик хорошо знает систему и требуется быстро выполнить большое количество проверок. Оба инструмента используются для систематизации тестирования и повышения покрытия.

Баг — это дефект в программном обеспечении, который приводит к тому, что фактическое поведение системы не соответствует ожидаемому поведению, требованиям или другим согласованным условиям. После обнаружения проблемы тестировщик должен убедиться, что она действительно воспроизводится, определить необходимые условия и создать Bug Report. Заголовок должен кратко и понятно описывать проблему. В описании указывается дополнительная информация о дефекте. Шаги воспроизведения должны позволять другому человеку повторить проблему. Expected Result показывает, что должно происходить, а Actual Result — что происходит фактически. Также указывается окружение, например операционная система, браузер, версия приложения или устройство. При необходимости добавляются скриншоты, видео, логи и другие доказательства. Severity показывает серьёзность влияния дефекта на систему, а Priority показывает, насколько срочно его необходимо исправить с точки зрения бизнеса. Например, блокирующая ошибка, из-за которой пользователи вообще не могут войти в приложение, имеет высокую серьёзность. В разных системах используются разные наборы статусов и классификаций. Распространённый жизненный цикл бага может выглядеть так: New → Open → In Progress → Fixed → Retest → Closed. Если после исправления проблема сохраняется, баг может перейти в Reopened. Основная цель Bug Report — передать разработчику точную информацию о проблеме и обеспечить её отслеживание до полного решения.

Мобильное тестирование — это процесс проверки мобильных приложений на смартфонах и планшетах. Тестировщик проверяет не только правильность функций, но и то, насколько приложение стабильно, удобно, быстро и корректно работает на разных устройствах. Для мобильного тестирования важны такие данные, как модель устройства, производитель, операционная система, версия ОС, размер и разрешение экрана, объём оперативной памяти, процессор, состояние батареи, тип и скорость интернет-соединения, ориентация устройства и доступные разрешения. Android — мобильная операционная система, используемая большим количеством производителей и устройств, поэтому существует большое разнообразие конфигураций. iOS — операционная система Apple для её мобильных устройств, где набор поддерживаемых устройств более ограничен, но также существуют разные версии системы и характеристики устройств. Нативное приложение разрабатывается специально под определённую платформу и использует её технологии и возможности. Веб-приложение работает через мобильный браузер и обычно не требует установки как отдельного приложения. Гибридное приложение сочетает веб-технологии с возможностями мобильной платформы и устанавливается на устройство как приложение. При мобильном тестировании необходимо учитывать особенности сенсорного управления, жестов, клавиатуры, поворота экрана, разрешений, уведомлений, звонков и других системных событий. Также необходимо проверять поведение приложения при потере интернет-соединения, переключении между Wi-Fi и мобильной сетью, низком заряде батареи, блокировке экрана и возвращении приложения из фона. Важную роль играет compatibility testing — проверка работы приложения на разных устройствах, разрешениях экранов и версиях операционных систем.

1. База данных — это система хранения и организации информации. В реляционных базах данные обычно хранятся в таблицах, состоящих из строк и столбцов. Например, таблица Users может содержать ID пользователя, имя, email и возраст. SQL — Structured Query Language, язык структурированных запросов, который используется для работы с реляционными базами данных. Команда SELECT используется для получения данных. Например, запрос SELECT * FROM Users возвращает все столбцы и строки таблицы Users. Можно выбирать только необходимые столбцы, например SELECT name, email FROM Users. Команда INSERT INTO используется для добавления новой записи. UPDATE используется для изменения существующих данных. Например, можно изменить email конкретного пользователя. DELETE используется для удаления записей. При изменении или удалении данных особенно важно использовать WHERE, иначе можно случайно изменить или удалить большое количество записей. WHERE используется для фильтрации данных по определённому условию. IN позволяет проверить, находится ли значение среди нескольких указанных значений. NOT используется для отрицания условия. BETWEEN используется для поиска значений в определённом диапазоне. Например, можно выбрать пользователей с возрастом от 18 до 30 лет. Агрегатные функции используются для получения общего результата по нескольким строкам. SUM вычисляет сумму, AVG вычисляет среднее значение, COUNT подсчитывает количество записей, MIN возвращает минимальное значение, а MAX — максимальное. UNION используется для объединения результатов двух или более SELECT-запросов в один набор результатов. JOIN используется для объединения данных из нескольких таблиц на основании связанного поля. Например, таблица Users может быть связана с таблицей Orders через идентификатор пользователя. С помощью JOIN можно получить информацию о пользователе вместе с его заказами. Основные команды, которые необходимо запомнить: SELECT — выбрать данные, INSERT INTO — добавить данные, UPDATE — изменить данные, DELETE — удалить данные, WHERE — задать условие, IN — проверить значение среди списка, NOT — отрицание, BETWEEN — диапазон, SUM — сумма, AVG — среднее, COUNT — количество, MIN — минимум, MAX — максимум, UNION — объединение результатов запросов, JOIN — объединение связанных таблиц.