Каковы источники информации для создания отчета об ошибках

Баг-репорт — это отчет об ошибке. В нём указывают, что нужно исправить в программном обеспечении или на сайте. Перечисляют причины и факты, почему поведение считают ошибочным.

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

Почему важно сообщать об ошибках и кто это делает

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

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

Тестировщиком реально стать даже без опыта в IT. Для этого пройдите курс Skypro «Инженер по тестированию». Научитесь писать тестовую документацию и составлять отчеты, тестировать веб- и мобильные приложения и API, освоите нужные инструменты. Внутри — мастер-классы с реальными рабочими задачами, домашки и разборы от наставника. Создадите четыре проекта для портфолио и получите диплом гособразца.

Основные принципы

Правильные отчеты помогают программистам быстрее исправлять ошибки. Детали зависят от типа багов. Но есть несколько основных принципов — что и как включать в баг-репорт, чтобы заранее снять вопросы разработчиков.

Указывайте:

1️⃣ Только одну ошибку на отчет. Это золотое правило, потому что так гораздо проще исправлять баги. Легче отслеживать статус отдельных отчетов и выставлять приоритеты задач, распределять работу между несколькими разработчиками. Да и меньшее количество информации проще запомнить и проанализировать.

2️⃣ Место интерфейса программного обеспечения, в котором возникла ошибка. Опишите экран, на котором находитесь, состояние интерфейса. Включите URL-адрес страницы, если это веб-приложение.

3️⃣ Действия в программе. Пошагово опишите действия, которые выполняли перед тем, как столкнулись с ошибкой. Это важно: может оказаться, что некорректное поведение программы началось до того, как вы его заметили.

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

5️⃣ Скриншот или запись экрана с ошибкой. Есть риск ошибиться, когда пишешь отчет об ошибке. Это значительно усложнит работу команды разработки. Визуальные материалы — более точный способ указать на проблему, чем просто описать ее.

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

7️⃣ Все сообщения об ошибках и коды. Они помогут определить, что это за ошибка и как ее устранить. Показывайте и те сообщения, которые кажутся нерелевантными. Даже они могут помочь разобраться в проблеме.

8️⃣ Можете ли вы воспроизвести проблему. То есть происходит ли одно и то же каждый раз, когда вы пытаетесь выполнить задачу. Эта информация поможет разработчику найти причину ошибки.

9️⃣ Пробовали ли исправить проблему. Есть причина, по которой айтишник всегда спрашивает: «Вы пробовали выключить и снова включить?» или «Пытались ли обновить веб-страницу?». Перезагрузка может быть простым способом исправить проблему. Если она не исчезает — это дает много информации. Укажите, и это сэкономит время на последующее обсуждение проблемы.

🔟 Насколько проблема влияет на работу. Обычно серьезность варьируется от очень высокой (полностью останавливает работу) до очень низкой (визуальные недочеты). Эта информация поможет командам разработчиков расставить приоритеты, определить порядок, в котором устранять ошибки.

Основные элементы

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

Обычно программисты и тестировщики договариваются, что и как указывать. Еще на это влияет система, в которой готовят отчет. Но есть общие компоненты баг-репорта:

👉 Резюме — краткое обозначение проблемы, причина и тип ошибки.

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

👉 Вложения — любые визуальные или другие материалы.

👉 Срок выполнения — если важно, чтобы ошибку исправили к определенной дате.

👉 Критичность — комментарий, насколько баг мешает нормальной работе приложения.

Часто выделяют следующие уровни критичности ошибок:

☝ Блокирующий (Blocker) — полностью блокирует нормальную работу программы, нужно исправить как можно быстрее.

☝ Критический (Critical) — сильно искажает логику приложения и значительно осложняет работу с ним.

☝ Значительный (Major) — затрагивает только отдельные элементы программы, существенно мешает работать.

☝ Незначительный (Minor) — либо не сильно влияет на работу программы, либо проявляется редко.

☝ Тривиальный (Trivial) — относится к визуальным недочетам в интерфейсе: опечатки, неудобные цвета и прочее.

Жизненный цикл

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

💡 Новый — только создан, ждет проверки разработчиком.

💡 Принят — отчет проверили, проблему подтвердили.

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

💡 Назначен — ошибку передали исполнителю.

💡 В работе — разработчик исправляет ошибку.

💡 Проверяется — исполнитель закончил работу, результат проверяет старший специалист.

💡 Закрыт — ошибку исправили, результат доступен пользователям.

Системы для отчетов об ошибках

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

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

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

К наиболее распространенным системам управления проектами относят:

• Jira.
• YouTrack.
• Redmine.

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

К основным системам управления исходным кодом относят:

• GitHub.
• GitLab.
• Bitbucket.

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

✔️ форма создания отчета об ошибке с полями для ввода основных элементов;

✔️ управление состоянием и параметрами;

✔️ форма обсуждения, в которой команда задает вопросы и оставляет комментарии, указывает дополнительные детали;

✔️ уведомление об изменениях через имейл или другую систему обмена сообщениями.

У части баг-трекеров есть публичное голосование. Пользователи голосуют за или против бага: так повышают или понижают его приоритет.

Главное

• Баг-репорт — специальный вид отчета о неисправности в программном обеспечении или веб-сайте. Баг-репорт готовят тестировщики или специалисты из команды по контролю качества.
• Оформление баг-репорта сильно влияет на скорость, с которой исправят ошибки, на итоговый результат. Указывайте причину и тип ошибки, подробности, срок выполнения, критичность. Прикладывайте скриншоты или запись экрана.
• Прописывайте, пробовали ли исправить проблему, насколько она влияет на работу. Указывайте операционную систему, браузер, тип устройства, параметры монитора.
• Есть системы, с которыми проще создавать баг-репорты и управлять ими. Основные: Jira, YouTrack, Redmine, GitHub, GitLab, Bitbucket.

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

Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.

Баг-репорт содержит ответы на следующие вопросы:

• что идёт не так;
• где проявляется дефект;
• когда ошибка воспроизводится.

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

Разберёмся, как добиться этого сочетания.

Как выявляют баги?

Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:

1. во время проведения тестирования ПО;
2. при обращении заказчика с описанием ошибки;
3. из сообщений пользователей, которые столкнулись с проблемами во время использования программного продукта.

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

Какой инструмент используют для документирования дефектов?

Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.

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

Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.

Каких правил придерживаться при написании баг-репорта?

Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.

Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.

Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.

Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.

Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.

Если всё в порядке, можно переходить к описанию.

Из каких элементов состоит баг-репорт?

Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:

Summary (заголовок)

Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.

Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:

«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».

При тестировании мобильных приложений важно внести и название платформы, iOS или Android.

Заголовок готов. Можем двигаться дальше.

Description (описание)

Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:

1. переход на сайт menyaemsya.com;
2. вход или регистрация;
3. нажатие кнопки «Добавить объявление»;
4. ввод символов в поле «Описание».

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

«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».

Actual/expected result (фактический/ожидаемый результат)

Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.

Пример заполнения данного раздела:

«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».

Attachments (вложения)

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

Priority (приоритет)

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

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

• P1 High (высокий приоритет);
• P2 Medium (средний приоритет);
• P3 Low (низкий приоритет);

Высокий приоритет имеют критические дефекты, которые необходимо исправить в кратчайшие сроки. Категория P3 включает те баги, которые не влияют на работу системы и могут быть устранены в последнюю очередь.

Severity (серьёзность)

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

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

Status (статус)

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

• New – новый баг;
• Feedback – требуется обратная связь;
• Acknowledged – с содержанием документа ознакомились;
• Accepted – ошибка воспроизвелась и была подтверждена;
• Assigned – исправление ошибки назначено;
• Resolved – изменения были внесены;
• Closed – дефект больше не воспроизводится.

Такими являются основные элементы баг-репорта, с которыми приходится встречаться чаще всего. Но в отчёте могут содержаться и дополнительные поля:

• Environment/platform – среда, платформа или операционная система;
• Fix version – этап разработки ПО на момент выявления бага;
• Assignee – пользователь, которому предстоит утвердить или исправить дефект;
• Lable – категория ошибки (текст, визуальные элементы и прочее).

Резюмируем

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

• убедиться в воспроизводимости ошибки;
• оценить поведение системы на разных платформах (при необходимости);
• проверить дефект на уникальность в баг-трекинговой системе.

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

Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!

Небольшое лирическое отступление

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

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

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

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

Как это работает

Для понимания принципа работы Sedge важны два понятия – Suite (набор приложений) и Application (приложение). Набор приложений может быть описан в одном или нескольких .sedge файлах и определяет для набора связанных программ общие свойства, такие как пользовательский интерфейс, общие файлы и метод отправки отчета.

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

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

Пример простого конфигурационного файла

<?xml version="1.0" encoding="UTF-8" ?>
<Sedge>
  <Suite name="LunarFrog.TaggedFrog" caption="TaggedFrog Error Reporting" partial="no">
    <Schedule>
      <Step name="Screenshot" />
      <Step name="ErrorDetails" />
      <Step name="Contacts" />
      <Step name="Collect" />
    </Schedule><Transport name="Email">
      <Option name="to" value="error_mail@company.com" />
      <Option name="subject" value="Error report" />
    </Transport><Report>
      <Group name="UserGroup" caption="User Information">
        <Page name="ImagePage" caption="Screenshot">
          <Temp name="screenshot" caption="Screen" />
        </Page>
        <Page name="InfoPage" caption="Information">
          <Temp name="ReportDetails" caption="Details"/>
          <Temp name="Contacts" caption="Contact Information" />
          <Temp name="UserFiles" />
        </Page>
      </Group>
      <Group name="EnvGroup" caption="Enviroment">
        <Page name="ProcessesPage" caption="Processes">
          <Data name="Processes" />
        </Page>
        <Page name="SystemPage" caption="System">
          <Data name="System" />
        </Page>
      </Group>
    </Report><Application name="TaggedFrog" caption="TaggedFrog">
      <Report>
        <Group name="ApplicationGroup" caption="Application">
        </Group>
      </Report>
    </Application></Suite>
</Sedge>

* This source code was highlighted with Source Code Highlighter.

Первый шаг визарда

Одна из страниц отчета, созданного согласно этой конфигурации

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

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

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

Информация о программе

Платформа: .NET Framework 2.0 / C# 3.0
Лицензия: MIT
Статус: Beta
Сайт: sedge.codeplex.com

Отчеты об ошибках (на англ. «Bug
Report»)– это основной
материальный продукт тестирования,
надежная техническая документация,
которая описывает вид ошибки в тестируемой
системе.

Для упрощения организации взаимодействия
групп и общего централизованного
хранения отчетов об ошибках следует
использовать системы отслеживания
ошибок (на англ. «bug tracking»).
Это позволяет иметь единое хранилище
ошибок, отслеживать их повторное
появление, контролировать скорость и
эффективность исправления ошибок,
видеть наиболее нестабильные компоненты
системы, а также поддерживать связь
между группой разработчиков и группой
тестирования (уведомления об изменениях
по почте и т.п.). Чем больше проект, тем
сильнее потребность в централизованном
хранилище дефектов.

Пример одной из свободных систем
отслеживания ошибок с веб-интерфейсом.
является Bugzilla (разработка
компании Mozilla). Данная
система очень проста и популярна в
использовании [10].

Подобная
система обеспечивает следующие функции:

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

• система
  уведомления о появлении новых ошибок,
  об изменении статуса известных в системе
  ошибок (как правило, это уведомления
  по электронной почте);

• отчеты
  об актуальных ошибках по компонентам
  системы, по интервалам времени, по
  группам разработчиков и разработчикам;

• информация
  об истории ошибки (в том числе отслеживание
  похожих ошибок, отслеживание повторного
  возникновения ошибки);

• правила
  доступа к ошибкам тех или иных категорий;

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

Существуют основные виды продвижения
ошибки (на англ. «bug») по
системе (на англ. «Defect
flow»)(см. рисунок 6).

Рисунок 6 — Defect
flow

При поступление ошибки в систему, из
любого источника (заказчик, разработчик,
тестировщик), баг принимает статус new
(пер. с англ. «новый»). Затем рассматривается
программистом его описание и: или ошибка
решается (на англ. «resolve»)
или ей ставится статус duplicated
(пер. с англ. «дубль»), что означает, что
данная ошибка уже была и на данном этапе
решается, или же ей ставится статус
invalid (пер. с англ.
«необоснованный»)- неверное описание,
такой ошибки не существует. После всего
этого командой тестировщиков данная
ошибка перепроверяется и закрывается
(на англ. «verify») в случае,
если она больше не повторяется, или
переоткрывается (на англ. «reopen»), если
изменения все равно приводят к ошибке.

В отчете об ошибки необходимо соблюдать
некоторые правила:

1. В отчете должна быть с самого начала
понятна суть ошибки.

2.Должны быть четко понятны шаги
воспроизведения.

3.Должен быть известен альтернативный
правильный вариант поведения.

4. Указана версия и приоритет данной
ошибки.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #