Тестировщик 1С, также известный как QA-Engineer, — одна из самых востребованных и перспективных профессий в сфере IT. Но как понять, что это именно для вас?  Предлагаем для начала выяснить, кто же на самом деле этот специалист и какие знания нужны для успешного поиска первой работы? В этой статье Артем Коротченко, QA Automation Engineer «Автомакона» в направлении «ВкусВилл», делится лайфхаками для начинающих тестировщиков.

О чем молчат в рекламе курсов QA

Давайте представим обычного работягу – Олега, который работает на заводе, и приходя домой, открывает соцсети, чтобы немного отвлечься и отдохнуть. И вот однажды его внимание привлекает реклама: «Стань тестировщиком 1С за неделю и зарабатывай от 100 000 рублей».

— Так-так, — думает Олег. — А что, если попробовать?

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

С чего же начать путь к профессии QA?

Знание платформы 1С:Предприятие

Несомненно, тестировщику необходимо знать хотя бы основы программирования. Для этого рекомендуем пройти курс helpme1c . В нем есть необходимая база для понимания языка 1С, а именно: 

• Что такое переменные, циклы, функции и процедуры;

• Основы работы с СКД (Система компоновки данных);

• Объекты метаданных — какие бывают и для чего нужны;

• Умение работать с отладчиком;

• Как выгружать и загружать базы данных.

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

Если вы еще не имели опыта работы с 1С:Предприятие, можно начать с небольшого бесплатного курса. Он поможет вам разобраться в основах и понять, что представляет собой эта система.

Теория тестирования

Первое с чего стоит начать – ознакомиться с техниками тест-дизайна. На самом деле, в 99% собеседований на должность тестировщика, HR-менеджер или тимлид обычно спрашивают, какие техники тест-дизайна знает кандидат и просят привести примеры, как и где их использовать.    

Тест-дизайн и его основные техники

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

1. Эквивалентное разделение (Equivalence Partitioning)

Эта техника предполагает разделение входных данных на эквивалентные классы, где все значения внутри одного класса обрабатываются одинаково. Это позволяет сократить количество тестов, поскольку достаточно протестировать только одно значение из каждого класса.

Пример: Если поле ввода принимает значения от 1 до 100, то можно выделить три класса: 

• Значения меньше 1 (недопустимые)

• Значения от 1 до 100 (допустимые)

• Значения больше 100 (недопустимые)

2. Граничные значения (Boundary Value Analysis)

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

Пример: Для диапазона от 1 до 100 следует протестировать значения 0, 1, 100 и 101.

3. Дерево решений (Decision Table Testing)

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

Пример: Если у вас есть три условия (A, B, C), каждое из которых может быть истинным или ложным, дерево решений поможет визуализировать все возможные комбинации и их результаты.

4. Состояния и переходы (State Transition Testing)

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

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

5. Тестирование на основе сценариев (Scenario Testing)

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

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

6. Модульное тестирование (Modular Testing)

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

7. Тестирование по требованиям (Requirements-based Testing)

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

8. Тестирование с использованием случайных данных (Random Testing)

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

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

Упрощенная схема для написания автотестов

Для написания автотестов Артем использует три вида тестов. 

1. Unit (юнит) — тесты. Самый простой вид тестов. Он отнимает меньше всего времени, сил, и выполняется быстрее других видов тестов. Цель такого теста, как правило, проверить небольшой «кусочек кода», либо проверить форму (формой называется открывающееся окно). 

Сценарий: Пользователь открывает окно «Возврат товара» на наличие ошибок 

Шаги теста:

1. Открываем окно «Возврат товара».

2. Проверяем что при открытии не появляется окно предупреждения. 

2. Integration (интеграционные) — тесты, которые проверяют взаимодействие нескольких процедур или функций. 

Сценарий: Пользователь создает сотрудника и проверяет его отображение в документе.

Шаги теста:

Создание сотрудника 

1. Открыть справочник.

2. Создать нового сотрудника.

Проверка отображения сотрудника в документе:

1. Открываем необходимый документ.

2. Проверяем наличие сотрудника  в поле сотрудников.

3. E2E тесты (сквозное тестирование) — самый энергоемкий процесс тестирования как при создании автотеста, так и при выполнении. Это метод тестирования, который проверяет всю систему целиком, от начала до конца, чтобы убедиться, что все компоненты работают вместе так, как задумано.

Вот пример простого E2E-теста для веб-приложения интернет-магазина.

Сценарий: Пользователь добавляет товар в корзину и завершает покупку в веб-версии, затем документ создается в Центральной базе. 

Шаги теста:

1. Открытие веб-сайта:

• Открыть браузер.

• Перейти на главную страницу интернет-магазина. 

2. Поиск товара:

• Ввести название товара в строку поиска.

• Нажать кнопку «Поиск».

3. Выбор товара:

• Кликнуть на первый товар из результатов поиска.

4. Добавление товара в корзину:

• Нажать кнопку «Добавить в корзину».

• Проверка корзины:

• Перейти в раздел «Корзина».

• Убедиться, что добавленный товар отображается в корзине.

5. Оформление заказа:

• Нажать кнопку «Оформить заказ».

• Ввести необходимые данные для доставки и оплаты.

• Подтвердить заказ.

6. Проверка подтверждения заказа:

• Убедиться, что отображается сообщение об успешном оформлении заказа.

7. Проверка создания документа заказа:

• Открываем центральную базу

• Открываем список документов «Заказ клиента»

• Проверяем наличие заказа, созданного через сайт.

Важно! Данные примеры только для ознакомления и общего представления о теории тестировании. 

В просторах интернета множество материалов для изучения данной сферы. Чтобы получить хорошую основу, рекомендуем изучить книгу «Основы тестирования программного обеспечения» В.Н.Пероцкой, Д.А.Градусова.

Для первого ознакомления с теорией тестирования можно прочитать эту статью. 

Фреймворк «Vanessa-automation»

Vanessa Automation — это инструмент для автоматизации тестирования, разработанный специально для работы с приложениями на платформе 1С:Предприятие. Он позволяет создавать и выполнять автоматизированные тесты, что значительно упрощает процесс тестирования программного обеспечения, особенно в контексте 1С.

Проект открытый, и всю информацию можно прочитать по ссылке. Также рекомендуем курс видеоуроков от Виталия Онянова «Быстрый старт в тестирование с помощью vanessa-automation».

Vanessa Automation запускается как внешняя обработка:

А выглядит она вот так: 

Из чего состоит тест: 

• #language: ru — настройка, указывающая язык, на котором будет написан тест.

• @functional_test – теги, которые используются для управления запусками тестов.

Функционал: наименование тестируемого функционала.

Переменные: раздел, где мы создаем структуру с переменными, по типу ключ – значение. В раздел переменных можно даже помещать таблицу (Строки 12-14) , к которой потом будут обращаться шаги теста.  

Контекст: раздел, куда помещаются шаги, которые выполняются перед каждым сценарием.  

Сценарий: это заголовок самого теста. В сценарии мы описываем что именно будет проверяться. Поэтому наименование сценария должно быть конкретным и емким. 

Далее идет «тело теста» — непосредственно код автотеста, в котором содержатся «Шаги». Каждая строка кода — это шаг или по-другому действие, которое мы запрограммировали выполнить программу.  

Allure – отчеты

Allure — это фреймворк для создания отчетов о тестировании программного обеспечения. Он позволяет тестировщикам генерировать наглядные и информативные отчеты по результатам автоматизированного тестирования.

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

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

1. Передача задания: аналитик формулирует требования и передает их разработчику.

2. Внесение изменений: разработчик вносит необходимые изменения в кодовую базу через EDT (инструмент разработки) и отправляет обновления в репозиторий GIT.

3. Обновление тестовой среды: тестировщик получает изменения с помощью EDT и обновляет тестовую базу данных.

4. Проверка требований: тестировщик анализирует исходную задачу от аналитика и проверяет, соответствуют ли все доработки установленным требованиям. Затем он разрабатывает автотесты для проверки нового функционала.

5. Запуск автотестов: тестировщик отправляет новые автотесты в репозиторий GIT и запускает все существующие тесты на удаленном сервере.

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

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

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

Для знакомства с данным инструментом советуем к просмотру видео по ссылке.

1C:Enterprise Development Tools

1C:Enterprise — это мощная платформа для разработки и автоматизации бизнес-процессов. Она предоставляет разработчикам инструменты для создания, настройки и поддержки приложений, которые могут быть адаптированы под специфические нужды бизнеса. Здесь мы рассмотрим основные аспекты использования 1C:Enterprise Development Tools (EDT), включая установку, создание проектов, разработку и отладку приложений.

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

1. Добавление базы данных из репозитория Git: как клонировать репозиторий и настроить базу данных для локального использования.

2. Ветки в Git: понятие веток, их назначение и инструкции по переключению между ними.

3. Коммиты в Git: определение коммита, его роль в системе контроля версий и пошаговая инструкция по созданию коммита.

4. Обновление приложения с изменениями из репозитория: как получать последние изменения из удалённого репозитория и интегрировать их в локальную версию приложения.

Для понимания основ рекомендуем просмотреть видео по ссылке.

Репозиторий Git

Репозиторий Git — это место, где хранится вся история изменений проекта, включая файлы, их версии и метаданные. Git — система контроля версий, разработанная для отслеживания изменений в коде и управления совместной работой над проектами. Репозиторий может быть локальным (на вашем компьютере) или удалённым (на сервере, например, на GitHub или GitLab).

Основные компоненты репозитория Git:

1. Файлы проекта: все исходные файлы, которые вы разрабатываете, хранятся в репозитории. Это могут быть файлы кода, документы, изображения и другие ресурсы.

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

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

4. Ветки: Git поддерживает концепцию веток, что позволяет разработчикам работать над различными функциями или исправлениями одновременно, не мешая друг другу. Ветки могут быть объединены (merged) после завершения работы.

5. Удалённые репозитории: это версии репозитория, расположенные на удалённых серверах. Они позволяют командам работать совместно, синхронизируя изменения между локальными и удалёнными копиями проекта.

Зачем нужен репозиторий Git?

• Отслеживание изменений: легко видеть, как проект развивался со временем.

• Совместная работа: несколько разработчиков могут работать над одним проектом одновременно.

• Безопасность: в случае ошибок или проблем можно быстро восстановить предыдущие версии файлов.

• Управление версиями: позволяет создавать разные версии проекта и экспериментировать с новыми функциями без риска повредить основную кодовую базу.

Для первого ознакомления с Git советуем к прочтению статью по ссылке.

---

Овладение профессией тестировщика 1С требует терпения и упорства. Освоив базовые инструменты — от платформы 1С до Vanessa Automation и Allure — вы сможете не только получить работу, но и стать востребованным специалистом.

Не бойтесь сложностей, и помните: путь к успеху начинается с первого шага!