Что такое базис тестирования

Артефакты, необходимые для тестирования

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

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

Я выделяю несколько артефактов:

1. План тестирования (Test plan)
2. Тестовый сценарий (Test-case)
3. Наборы тестовых сценариев (Test script or Test suite)
* Набор тестовых сценариев для Smoke-test
* План приёмосдаточных испытаний (ПСИ)
4. Описание дефектов
5. Отчет о тестировании

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

Есть как минимум два общепринятых понимания этого документа:

1. Документ описывающий кто, что, когда и как будет тестироваться
2. Документ описывающий все необходимые для проверки приложения тесты.

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

* Взять книгу Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
* Взять RUP
* Погуглить
* Дождаться когда я изложу пример в одной из следующих статей

Тестовый сценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.
Хорошая практика — написание тестовых сценариев на основании вариантов использования (Use cases).

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

* Атомарный тест
* Тестовый вариант
* Вариант тестирования
* Тестовый случай

Наборы тестовых сценариев

Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test script)), так и независимыми (Test suite).
Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.

Набор тестовых сценариев для Smoke-test

Если честно, то я не знаю адекватного перевода на русский данного термина. Иногда используется перевод “Дымчатое тестирование”, но он вызывает у меня стойкое отвращение.

Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.

Хорошая практика — прием билда в тестирование на основании прохождения Smoke-test. Также зачастую в качестве такого теста используют ежедневную сборку с обязательным прохождением unit тестов.

Комментарий: Ежедневная сборка без unit тестов не может считаться как Smoke test. Это называется: “Ух ты компилицо”

План приёмо-сдаточных испытаний (ПСИ)

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

В общем случае подмножества тестов выглядят так как на рисунке.

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

Источник

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

Существует 4 уровня тестирования [1]:

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

Начнем с простого примера.

Давай вспомним, что такое конструктор LEGO.

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

Обычно, процесс сборки игрушки выглядит так:

Программное обеспечение очень похоже на такой конструктор.

Но оно намного круче, ведь мы сами можем создавать любые детали и использовать детали (и даже блоки), созданные другими людьми (привет Open Source) 😉

Если посмотреть на процесс сборки с точки зрения тестирования, его можно описать так:

Суть процесса проста: проверка любой системы (будь то конструктор LEGO или мобильное приложение) начинается с ее наименьших элементов и двигается в сторону их объединения / увеличения до максимального размера.

Благодаря этому подходу ты никогда не попадешь в ситуацию, когда «колеса не того размера», «двери не от той машины» или «мы хотели самолет, а получили вертолет, платить не будем» 🙂

Теперь ты осознаешь уровни тестирования, но для эффективной работы этого недостаточно. Давай разбираться глубже)

Что такое уровень тестирования?

Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.

К характеристикам относятся:

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

Пример реальной задачи по разработке

Предположим, перед вашей командой ставят задачу:

Создать страницу Contact Us на сайте Х. После отправки формы отдел поддержки должен получить Email, содержащий введенные данные и контактную информацию клиента.

Этап разработки требований и критериев приемки завершен, команда может приступать к реализации, задача переходит на этап дизайна (см. SDLC)

Первым делом разработчики прорабатывают дизайн системы.

Он может представлять собой следующую схему:

Дизайн системы Contact Us

Далее, разработчики детализируют схему добавляя описание шагов:

* логика проверки (валидации данных) опущена для упрощения схемы. Но, это не означает, что ее нет!
** логика отправки Email опущена для упрощения схемы

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

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

Модульное / Компонентное / Unit тестирование

Модульное / Компонентное / Unit тестирование фокусируется на компонентах / модулях, которые должны быть проверены в изоляции, как самостоятельные, независимые блоки.

Module / Component / Unit testing: A test level that focuses on individual hardware or software components [ISTQB Glossary]

Характеристики модульного тестирования

Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок

Объект: модуль / компонент / unit

Базис: дизайн системы, код, спецификация компонента

Типичные ошибки: ошибка в реализации требований, ошибка в коде

Ответственный: разработчик (редко тестировщик)

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

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

Продолжая рассмотрение примера со страницей сайта, мы можем выделить следующие модули:

Для примера, рассмотрим модуль «страница Contact Us».
Требования:

В свою очередь, требования к модулю «Contact Us Controller»:

Все описанные выше требования должны проверяться Unit тестами.

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

Интеграционное тестирование

Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / под-системами / системами.

Выделяют 2 подтипа:

Integration testing. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. [ISTQB Glossary]

Component integration testing. Testing performed to expose defects in the interfaces and interaction between integrated components. [ISTQB Glossary]

System integration testing. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet). [ISTQB Glossary]

Характеристики интеграционного тестирования

Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы

Объект: модули, состоящие из нескольких компонентов; под-системы, API, микросервисы

Базис: дизайн системы, архитектура системы, описание связей компонентов

Типичные ошибки: отсутствие / неправильные связи между элементами системы, неправильные передаваемые данные, отсутствие обработки ошибок, отказы и падения при обращениях к API

Ответственный: разработчик и тестировщик

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

Продолжим рассмотрение примера.

Теперь, обратим внимание на связи между компонентами / под-системами:

Интеграционное тестирование

Начнем с компонентного интеграционного тестирования.

Обрати внимание на стрелки 5 и 7.

Они описывают связь между компонентами Contact Us Controller и Email Sender внутри под-системы Backend.

Contact Us Controller обращается к Email Sender с запросом для отправки Email сообщения (5), Email Sender отправляет письмо (6) и отвечает Contact Us Controller что все прошло удачно (7). Если при отправке (6) произошла ошибка, в ответе (7) вернется информация об ошибке.

В нашем случае интеграционные тесты проверят, что описанный выше процесс работает и что модуль Contact Us Controller инициирует отправку Email сообщения, а не SMS.

Тестирование интерфейсов (частично) и тестирование API являются примерами интеграционного компонентного тестирования.

В случае с тестированием API мы «имитируем» запрос от клиента — (3) и анализируем ответ сервера — (9), таким образом проверяя интеграцию всех задействованных модулей для конкретного API Endpoint внутри Backend.

Interface Testing. An integration test type that is concerned with testing the interfaces between components or systems. [ISTQB Glossary]

API testing. Testing performed by submitting commands to the software under test using programming interfaces of the application directly. [ISTQB Glossary]

Далее посмотрим на системное интеграционное тестирование.

Обрати внимание на стрелки 3 и 9.

Они описывают связь между двумя под-системами: Frontend, который формирует и отправляет запрос со страницы Contact Us с данными формы, и Backend, который обрабатывает и реагирует на запрос.

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

В нашем случае для проверки правильности достаточно написать 1 тест: отправить форму Contact Us с ожидаемым результатом в виде показанного сообщения об успешной отправке — (10) и полученного Email сообщения с данными, оставленными с формы Contact Us.

Теперь, когда мы проверили интеграции компонентов внутри под-систем и интеграции под-систем, мы можем двигаться дальше.

Системное тестирование

Системное тестирование фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.

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

Системное тестирование может проверять выполнение стандартов или законодательных / нормативных требований.

Тестовая среда для системного тестирования должна быть максимально приближенной (в идеальном варианте — идентичной) к окружению для эксплуатации (production).

System testing The process of testing an integrated system to verify that it meets specified requirements. [ISTQB Glossary]

Характеристики системного тестирования

Цель: проверка работы системы в целом

Объект: система, конфигурации системы, рабочее окружение

Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции

Типичные ошибки: невозможность выполнять функциональные задачи, для которых создавалась система, неправильная передача данных внутри системы, неспособность системы работать правильно в среде эксплуатации, нефункциональные сбои (уязвимости, зависания, выключения)

Ответственный: тестировщик

Системное тестирование для нашего примера может включать в себя такие типы тестирования:

Системное тестирование системы Contact Us

* слово «тестирование» — убрано с изображения для упрощения 🙂

Помимо проверки отправки формы Contact Us, получения Email сообщения на почту суппорта и показа Success сообщения, в ходе системного тестирования мы должны ответить на вопросы:

На этом уровне тестирования создаются end-to-end тесты, имитирующие бизнес процессы, Use Cases и Use Stories от начала до конца.

Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п. — все здесь).

E2e тесты очень медленные (обычно 5-10 тестов в минуту) и коварные, с их автоматизацией нужно быть очень осторожным 😉

Системное тестирование — одна из самых творческих и объемных областей тестирования. Кроме end-to-end (e2e) тестирования, к этому уровню относятся все виды нефункционального тестирования.

Очень часто начинающие тестировщики видят только одно направление развития: автоматизация.

Но на самом деле направлений много.

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

End-to-End Testing A type of testing in which business processes are tested from start to finish under production-like circumstances. [ISTQB Glossary]

После завершения тестирования всей системы нас ждет последняя проверка перед сдачей работы.

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

Приемочное тестирование фокусируется на готовности всей системы в целом.

Существуют несколько форм приемочного тестирования:

Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.

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

Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов.

Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.

Бета-тестирование проводится реальными пользователями системы.

Acceptance testing A test level that focuses on determining whether to accept the system. [ISTQB Glossary]

User acceptance testing (UAT) A type of acceptance testing performed to determine if intended users accept the system. [ISTQB Glossary]

Contractual acceptance testing A type of acceptance testing performed to verify whether a system satisfies its contractual requirements. [ISTQB Glossary]

Alpha testing A type of acceptance testing performed in the developer’s test environment by roles outside the development organization. [ISTQB Glossary]

Beta testing A type of acceptance testing performed at an external site to the developer’s test environment by roles outside the development organization. [ISTQB Glossary]

Характеристики приемочного тестирования

Цель: проверка готовности системы

Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика

Базис: системные требования, бизнес требования, сценарии использования, User Stories

Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта

Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик

Завершая рассмотрение примера можем написать приемочный тест, который выполнит заказчик:

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

В Agile разработке, конкретно в Scrum, для всех User Stories обязательно прописываются Acceptance Criteria. Именно они являются основой для приемочных тестов и показывают, что команда сделала именно то, что было нужно.

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

Резюме

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

Мы рассмотрели пример тестирования формы Contact Us.

Мы поняли, что тестирование нужно начинать с самых маленьких частей системы — компонентов / модулей.

Далее стоит проверить взаимосвязи между компонентами и всю систему в целом.

А завершает тестирование — заказчик, выполняя приемочное тестирование.

Для того, чтоб ты смог проверить себя — мы создали специальный тест! Он поможет тебе узнать, насколько хорошо ты разобрался в определениях уровней тестирования и подскажет, что нужно повторить)

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

Если тебе интересна тема тестирования и ты хотел бы получать актуальную информацию по этой теме — подписывайся на наш Телеграм канал! Там интересно: статьи, тесты, опросы, нет спама 😉

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

Если у тебя возникли вопросы или есть предложения по статье — обращайся к нам в Телеграм, будем рады 🙂

Источники

Что такое уровень тестирования?

Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.

Что такое компонентное тестирование (unit testing)?

Компонентное / модульное / unit testing — фокусируется на компонентах / модулях / классах, которые могут быть проверены изолированно / отдельно.

Что такое интеграционное тестирование (integration testing)?

Интеграционное тестирование / integration testing — фокусируется на взаимодействии между компонентами / модулями, системами.

Что такое системное тестирование (system testing)?

Системное тестирование / system testing — фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.

Что такое приемочное тестирование (acceptance testing)?

Приемочное тестирование / acceptance testing — фокусируется на поведении всей системы в целом. Оно дает возможность оценить готовность системы к развертыванию и использованию.

Источник

Тестирование. Ошибки при сертификации или ISTQB мне очень нужен

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

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

Мне бы хотелось написать о ISTQB, т.н. International Software Testing Qualifications Board. Это признанная во всём мире сертификация для тестировщика. Если ты такое получил, то по идее владеешь базовыми знаниями и теорией, то есть и плюсик тебе на собеседованиях добыть можешь, и в общем самоутверждаешься.

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

Исчерпывающее тестирование

Хотелось бы для начала, чтобы запомнили следующее, “исчерпывающее тестирование невозможно, независимо от того, сколько усилий затрачено на тестирование (т.н. Принцип # 2)”. Этот принцип запомнить придется. Много ссылок на материалы для подготовки кидать не буду, одну приведу в конце статьи. Пункт, в котором засомневалась я, был “При достаточных усилиях и инструментальной поддержке исчерпывающее тестирование возможно для любого программного обеспечения». Первые мысли были о том, что терпение и труд всё перетрут. Это верно только для тривиальных ситуаций, в любой реальной системе предусмотреть все ситуации не сможем, остается только свести к минимуму количество проблем.

Стадии и задачи

Информация для запоминания. Основной процесс тестирования можно поделить на этапы, направления деятельности:

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

Вопрос, с которым я столкнулась, по сути, был таким, какие задачи мы выполняем на этапе анализа и проектирования. Были разные варианты ответов.

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

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

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

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

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

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

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

Тестирование в период сопровождения

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

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

Системное и компонентное тестирование

Главное помнить, что компонентное тестирование обычно является ответственностью разработчиков, в то время как системное тестирование — типичная ответственность тестировщиков.

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

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

Формальное рецензирование и его шаги

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

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

Заключение

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

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

Источник