diff --git a/README.md b/README.md
index 49a5146..3d4c8bb 100644
--- a/README.md
+++ b/README.md
@@ -1,22 +1,18 @@
-
+# Введение
-[**>>> ЧИТАТЬ <<<**](https://vladislaveremeev.gitbook.io/qa_bible/)
+
-**Что это за проект?**
+**Что это за проект?**
“Библия QA” - это обновляемая база знаний объемом 560+ страниц:
-
-
* Ответы на самые популярные вопросы новичков о профессии и старте карьеры;
* Крупнейшая подборка ссылок и полезных ресурсов;
* Конспект всевозможной теории и ответов на вопросы с реальных собеседований.
**Дисклеймер**:
-
-
* Материал не проектировался как обучающий, за этим на хорошие курсы или в фундаментальные книги;
* Здесь можно найти очень многое, но это не значит, что всё это нужно знать. Это копилка, а не учебник. Перечень тем для джунов есть в f.a.q;
* Конспект теории авторский и составлен одним простым человеком, который не senior. Каждую из тем наверняка можно написать полнее и правильнее, ссылки подобрать получше, но на это уйдет еще не один год;
-* Проект находится в свободном доступе, не содержит рекламы и открыт для контрибьютинга.
+* Проект находится в свободном доступе, не содержит рекламы и открыт для контрибьютинга.
diff --git a/SUMMARY.md b/SUMMARY.md
index fb6dd4b..5dee6ab 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -1,3 +1,213 @@
# Table of contents
-* [Page 1](README.md)
+* [Введение](README.md)
+* [FAQ для новичков](faq-dlya-novichkov/README.md)
+ * [Ответы на самые популярные вопросы новичков в чатах](faq-dlya-novichkov/otvety-na-samye-populyarnye-voprosy-novichkov-v-chatakh.md)
+ * [Качества и навыки, которыми нужно обладать тестировщику?](faq-dlya-novichkov/kachestva-i-navyki-kotorymi-nuzhno-obladat-testirovshiku.md)
+ * [Что должен знать и уметь Junior? Что спросят на собеседовании?](faq-dlya-novichkov/chto-dolzhen-znat-i-umet-junior-chto-sprosyat-na-sobesedovanii.md)
+ * [С чего начать обучение и куда развиваться?](faq-dlya-novichkov/s-chego-nachat-obuchenie-i-kuda-razvivatsya.md)
+ * [Как составить резюме?](faq-dlya-novichkov/kak-sostavit-rezyume.md)
+ * [Где искать работу?](faq-dlya-novichkov/gde-iskat-rabotu.md)
+ * [Как происходит процесс найма?](faq-dlya-novichkov/kak-proiskhodit-process-naima.md)
+ * [Как проходить собеседование?](faq-dlya-novichkov/kak-prokhodit-sobesedovanie.md)
+ * [Начало работы Junior-тестировщика](faq-dlya-novichkov/nachalo-raboty-junior-testirovshika.md)
+ * [Ошибки в работе у начинающих тестировщиков](faq-dlya-novichkov/oshibki-v-rabote-u-nachinayushikh-testirovshikov.md)
+ * [Как взаимодействовать с коллегами?](faq-dlya-novichkov/kak-vzaimodeistvovat-s-kollegami.md)
+ * [Перспективы профессии](faq-dlya-novichkov/perspektivy-professii.md)
+* [Полезные ссылки](poleznye-ssylki/README.md)
+ * [Список полезных ресурсов на разных платформах](poleznye-ssylki/spisok-poleznykh-resursov-na-raznykh-platformakh.md)
+ * [Список ресурсов по инструментам тестировщика](poleznye-ssylki/spisok-resursov-po-instrumentam-testirovshika.md)
+* [Общее](obshee/README.md)
+ * [QA/QC/Testing](obshee/qa-qc-testing.md)
+ * [Почему требуется тестирование ПО?](obshee/pochemu-trebuetsya-testirovanie-po.md)
+ * [Качество ПО (Software Quality)](obshee/kachestvo-po-software-quality.md)
+ * [Принципы тестирования](obshee/principy-testirovaniya.md)
+ * [Верификация и валидация (Verification and Validation)](obshee/verifikaciya-i-validaciya-verification-and-validation.md)
+ * [Дефекты и ошибки](obshee/defekty-i-oshibki.md)
+ * [Серьезность и приоритет Дефекта (Severity & Priority)](obshee/sereznost-i-prioritet-defekta-severity-and-priority.md)
+ * [Альфа- и бета- тестирование (Alpha Testing and Beta Testing)](obshee/alfa-i-beta-testirovanie-alpha-testing-and-beta-testing.md)
+ * [Процесс тестирования (test process) (draft)](obshee/process-testirovaniya-test-process-draft.md)
+ * [Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)](obshee/tekhniki-ocenki-testov-ocenka-trudozatrat-na-testirovanie-test-estimation.md)
+ * [Экономика тестирования/стоимость качества (Cost of quality)](obshee/ekonomika-testirovaniya-stoimost-kachestva-cost-of-quality.md)
+ * [Подход к тестированию (Test Approach)](obshee/podkhod-k-testirovaniyu-test-approach.md)
+ * [Импакт анализ (анализ влияния, Impact Analysis)](obshee/impakt-analiz-analiz-vliyaniya-impact-analysis.md)
+ * [Анализ первопричин (RCA - Root Cause Analysis)](obshee/analiz-pervoprichin-rca-root-cause-analysis.md)
+ * [Тестирование со сдвигом влево (Shift left testing)](obshee/testirovanie-so-sdvigom-vlevo-shift-left-testing.md)
+ * [Модель зрелости возможностей (CMM - Capability Maturity Model)](obshee/model-zrelosti-vozmozhnostei-cmm-capability-maturity-model.md)
+ * [Тестовая среда и тестовый стенд (Test Environment/Test Bed)](obshee/testovaya-sreda-i-testovyi-stend-test-environment-test-bed.md)
+ * [Бизнес-логика (Business logic)](obshee/biznes-logika-business-logic.md)
+ * [Политика отсутствия багов (ZBP - Zero Bug Policy)](obshee/politika-otsutstviya-bagov-zbp-zero-bug-policy.md)
+ * [Независимое тестирование (Independent testing)](obshee/nezavisimoe-testirovanie-independent-testing.md)
+ * [Роли/должности в команде](obshee/roli-dolzhnosti-v-komande.md)
+ * [Эвристики и мнемоники](obshee/evristiki-i-mnemoniki.md)
+* [Виды-методы-уровни тестирования](vidy-metody-urovni-testirovaniya/README.md)
+ * [Методы тестирования (White/Black/Grey Box)](vidy-metody-urovni-testirovaniya/metody-testirovaniya-white-black-grey-box.md)
+ * [Тестирование методом черного ящика (Black Box Testing)](vidy-metody-urovni-testirovaniya/testirovanie-metodom-chernogo-yashika-black-box-testing.md)
+ * [Тестирование методом белого ящика (White Box Testing)](vidy-metody-urovni-testirovaniya/testirovanie-metodom-belogo-yashika-white-box-testing.md)
+ * [Тестирование методом серого ящика (Grey Box Testing)](vidy-metody-urovni-testirovaniya/testirovanie-metodom-serogo-yashika-grey-box-testing.md)
+ * [Статическое и динамическое тестирование (Static Testing, Dynamic Testing)](vidy-metody-urovni-testirovaniya/staticheskoe-i-dinamicheskoe-testirovanie-static-testing-dynamic-testing.md)
+ * [Пирамида / уровни тестирования (Test Pyramid / Testing Levels)](vidy-metody-urovni-testirovaniya/piramida-urovni-testirovaniya-test-pyramid-testing-levels.md)
+ * [Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)](vidy-metody-urovni-testirovaniya/modulnoe-yunit-komponentnoe-testirovanie-module-unit-component-testing.md)
+ * [Интеграционное тестирование (Integration testing)](vidy-metody-urovni-testirovaniya/integracionnoe-testirovanie-integration-testing.md)
+ * [Системное тестирование (System Testing)](vidy-metody-urovni-testirovaniya/sistemnoe-testirovanie-system-testing.md)
+ * [Приемочное тестирование (AT - Acceptance testing)](vidy-metody-urovni-testirovaniya/priemochnoe-testirovanie-at-acceptance-testing.md)
+ * [Основные виды тестирования ПО](vidy-metody-urovni-testirovaniya/osnovnye-vidy-testirovaniya-po.md)
+ * [Функциональное тестирование (Functional/Behavioral testing)](vidy-metody-urovni-testirovaniya/funkcionalnoe-testirovanie-functional-behavioral-testing.md)
+ * [Нефункциональное тестирование (Non-Functional testing)](vidy-metody-urovni-testirovaniya/nefunkcionalnoe-testirovanie-non-functional-testing.md)
+ * [Тестирование производительности (Performance testing)](vidy-metody-urovni-testirovaniya/testirovanie-proizvoditelnosti-performance-testing.md)
+ * [Тестирование емкости (Capacity testing)](vidy-metody-urovni-testirovaniya/testirovanie-emkosti-capacity-testing.md)
+ * [Нагрузочное тестирование (Load testing)](vidy-metody-urovni-testirovaniya/nagruzochnoe-testirovanie-load-testing.md)
+ * [Стрессовое тестирование (Stress testing)](vidy-metody-urovni-testirovaniya/stressovoe-testirovanie-stress-testing.md)
+ * [Тестирование масштабируемости (Scalability testing)](vidy-metody-urovni-testirovaniya/testirovanie-masshtabiruemosti-scalability-testing.md)
+ * [Объемное тестирование (Volume testing)](vidy-metody-urovni-testirovaniya/obemnoe-testirovanie-volume-testing.md)
+ * [Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)](vidy-metody-urovni-testirovaniya/testirovanie-vynoslivosti-stabilnosti-endurance-soak-stability-testing.md)
+ * [Тестирование устойчивости (Resilience testing)](vidy-metody-urovni-testirovaniya/testirovanie-ustoichivosti-resilience-testing.md)
+ * [Тестирование надежности (Reliability Testing)](vidy-metody-urovni-testirovaniya/testirovanie-nadezhnosti-reliability-testing.md)
+ * [Тестирование на отказ и восстановление (Failover and Recovery testing)](vidy-metody-urovni-testirovaniya/testirovanie-na-otkaz-i-vosstanovlenie-failover-and-recovery-testing.md)
+ * [Эталонное и базовое тестирование (Benchmark and Baseline Testing)](vidy-metody-urovni-testirovaniya/etalonnoe-i-bazovoe-testirovanie-benchmark-and-baseline-testing.md)
+ * [Тестирование хранилища (Storage testing)](vidy-metody-urovni-testirovaniya/testirovanie-khranilisha-storage-testing.md)
+ * [Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)](vidy-metody-urovni-testirovaniya/odnovremennoe-mnogopolzovatelskoe-testirovanie-concurrency-multi-user-testing.md)
+ * [Тестирование сервиса (Service Testing)](vidy-metody-urovni-testirovaniya/testirovanie-servisa-service-testing.md)
+ * [Тестирование безопасности (Security and Access Control testing)](vidy-metody-urovni-testirovaniya/testirovanie-bezopasnosti-security-and-access-control-testing.md)
+ * [Оценка уязвимости/защищенности (Vulnerability Assessment)](vidy-metody-urovni-testirovaniya/ocenka-uyazvimosti-zashishennosti-vulnerability-assessment.md)
+ * [Фаззинг-тестирование (Fuzz testing)](vidy-metody-urovni-testirovaniya/fazzing-testirovanie-fuzz-testing.md)
+ * [Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести](vidy-metody-urovni-testirovaniya/mozhno-li-otnesti-testirovanie-bezopasnosti-ili-nagruzochnoe-testirovanie-k-funkcionalnym-vidam-test.md)
+ * [Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)](vidy-metody-urovni-testirovaniya/testirovanie-sovmestimosti-vzaimodeistviya-compatibility-interoperability-testing.md)
+ * [Конфигурационное тестирование (Configuration testing)](vidy-metody-urovni-testirovaniya/konfiguracionnoe-testirovanie-configuration-testing.md)
+ * [Инсталляционное тестирование (Installation Testing)](vidy-metody-urovni-testirovaniya/installyacionnoe-testirovanie-installation-testing.md)
+ * [Тестирование на соответствие (Conformance/Compliance testing)](vidy-metody-urovni-testirovaniya/testirovanie-na-sootvetstvie-conformance-compliance-testing.md)
+ * [Тестирование удобства пользования (Usability testing)](vidy-metody-urovni-testirovaniya/testirovanie-udobstva-polzovaniya-usability-testing.md)
+ * [Тестирование доступности (Accessibility testing)](vidy-metody-urovni-testirovaniya/testirovanie-dostupnosti-accessibility-testing.md)
+ * [Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio](vidy-metody-urovni-testirovaniya/testirovanie-lokalizacii-globalizacii-i-internacionalizacii-localization-globalization-internatio.md)
+ * [Исследовательское тестирование (Exploratory testing)](vidy-metody-urovni-testirovaniya/issledovatelskoe-testirovanie-exploratory-testing.md)
+ * [Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)](vidy-metody-urovni-testirovaniya/svobodnoe-intuitivnoe-testirovanie-adhoc-ad-hoc-testing.md)
+ * [Тестирование поддержки (Maintenance testing)](vidy-metody-urovni-testirovaniya/testirovanie-podderzhki-maintenance-testing.md)
+ * [Регрессионные виды тестирования (Regression testing)](vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing.md)
+ * [Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)](vidy-metody-urovni-testirovaniya/testirovanie-klientskoi-chasti-i-servernoi-frontend-testing-vs.-backend-testing.md)
+ * [Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing](vidy-metody-urovni-testirovaniya/testirovanie-graficheskogo-interfeisa-vizualnoe-testirovanie-gui-graphical-user-interface-testing.md)
+ * [Тестирование API (API - Application Programming Interface)](vidy-metody-urovni-testirovaniya/testirovanie-api-api-application-programming-interface.md)
+ * [A/B тестирование (A/B Testing)](vidy-metody-urovni-testirovaniya/a-b-testirovanie-a-b-testing.md)
+ * [Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes](vidy-metody-urovni-testirovaniya/destruktivnoe-i-nedestruktivnoe-testirovanie-dt-destructive-testing-and-ndt-non-destructive-tes.md)
+ * [Выборочное/хаотическое тестирование (Random/monkey testing)](vidy-metody-urovni-testirovaniya/vyborochnoe-khaoticheskoe-testirovanie-random-monkey-testing.md)
+ * [Тестирование рабочего процесса/воркфлоу (Workflow testing)](vidy-metody-urovni-testirovaniya/testirovanie-rabochego-processa-vorkflou-workflow-testing.md)
+ * [Тестирование документации (Documentation testing)](vidy-metody-urovni-testirovaniya/testirovanie-dokumentacii-documentation-testing.md)
+ * [Как протестировать продукт без требований?](vidy-metody-urovni-testirovaniya/kak-protestirovat-produkt-bez-trebovanii.md)
+ * [Кроссбраузерное тестирование (Cross-browser testing)](vidy-metody-urovni-testirovaniya/krossbrauzernoe-testirovanie-cross-browser-testing.md)
+ * [Тестирование, основанное на рисках (Risk-Based Testing)](vidy-metody-urovni-testirovaniya/testirovanie-osnovannoe-na-riskakh-risk-based-testing.md)
+ * [Разница тестирования ПО и железа (Software Vs. Hardware testing)](vidy-metody-urovni-testirovaniya/raznica-testirovaniya-po-i-zheleza-software-vs.-hardware-testing.md)
+ * [Тестирование качества данных (Data Quality Testing)](vidy-metody-urovni-testirovaniya/testirovanie-kachestva-dannykh-data-quality-testing.md)
+* [Тест дизайн](test-dizain/README.md)
+ * [Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)](test-dizain/test-dizain-i-tekhniki-test-dizaina-test-design-and-software-testing-techniques.md)
+ * [Static - Reviews](test-dizain/static-reviews.md)
+ * [Static - Static Analysis](test-dizain/static-static-analysis.md)
+ * [Dynamic - White box](test-dizain/dynamic-white-box.md)
+ * [Dynamic - Black box](test-dizain/dynamic-black-box.md)
+ * [Dynamic - Experience based](test-dizain/dynamic-experience-based.md)
+* [Тестовая документация и артефакты (Test Deliverablestest artifacts)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/README.md)
+ * [Виды тестовой документации](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-testovoi-dokumentacii.md)
+ * [Политика качества и политика тестирования (Quality policy and Test policy)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/politika-kachestva-i-politika-testirovaniya-quality-policy-and-test-policy.md)
+ * [Стратегия тестирования (Test strategy)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/strategiya-testirovaniya-test-strategy.md)
+ * [План тестирования (Test plan)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/plan-testirovaniya-test-plan.md)
+ * [Тестовый сценарий (Test scenario)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-scenarii-test-scenario.md)
+ * [Тест-кейс (Test case)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/test-keis-test-case.md)
+ * [Чек-лист (Check List)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/chek-list-check-list.md)
+ * [Баг-репорт (Defect/bug report)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bag-report-defect-bug-report.md)
+ * [Требования (Requirements)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/trebovaniya-requirements.md)
+ * [Пользовательские истории (User stories)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/polzovatelskie-istorii-user-stories.md)
+ * [Критерии приемки (Acceptance Criteria)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/kriterii-priemki-acceptance-criteria.md)
+ * [Виды отчетов (Reports)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-otchetov-reports.md)
+ * [Базис тестирования (Test basis)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bazis-testirovaniya-test-basis.md)
+ * [Матрица трассируемости (RTM - Requirement Traceability Matrix)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/matrica-trassiruemosti-rtm-requirement-traceability-matrix.md)
+ * [Метрики тестирования (Software Test Metrics)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/metriki-testirovaniya-software-test-metrics.md)
+ * [Тестовый оракул (Test oracle)](testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-orakul-test-oracle.md)
+* [Мобильное тестирование](mobilnoe-testirovanie/README.md)
+ * [Особенности в тестировании мобильных приложений](mobilnoe-testirovanie/osobennosti-v-testirovanii-mobilnykh-prilozhenii.md)
+ * [Типы мобильных приложений](mobilnoe-testirovanie/tipy-mobilnykh-prilozhenii.md)
+ * [Симуляторы и эмуляторы](mobilnoe-testirovanie/simulyatory-i-emulyatory.md)
+ * [Архитектура Android OS](mobilnoe-testirovanie/arkhitektura-android-os.md)
+ * [Архитектура Android Application](mobilnoe-testirovanie/arkhitektura-android-application.md)
+ * [Архитектура iOS](mobilnoe-testirovanie/arkhitektura-ios.md)
+ * [Архитектура iOS Application](mobilnoe-testirovanie/arkhitektura-ios-application.md)
+ * [Android/iOS Developer Settings](mobilnoe-testirovanie/android-ios-developer-settings.md)
+ * [Основные различия Android/iOS](mobilnoe-testirovanie/osnovnye-razlichiya-android-ios.md)
+ * [Последнее обновление Android/iOS, что нового?](mobilnoe-testirovanie/poslednee-obnovlenie-android-ios-chto-novogo.md)
+ * [Основные проверки при тестировании мобильного приложения](mobilnoe-testirovanie/osnovnye-proverki-pri-testirovanii-mobilnogo-prilozheniya.md)
+ * [Каким образом тестировщик получает приложение на тест?](mobilnoe-testirovanie/kakim-obrazom-testirovshik-poluchaet-prilozhenie-na-test.md)
+ * [Как успешно зарелизить продукт в App Store и Google Play](mobilnoe-testirovanie/kak-uspeshno-zarelizit-produkt-v-app-store-i-google-play.md)
+ * [Тестирование требований к мобильным приложениям](mobilnoe-testirovanie/testirovanie-trebovanii-k-mobilnym-prilozheniyam.md)
+ * [Тестирование push-уведомлений](mobilnoe-testirovanie/testirovanie-push-uvedomlenii.md)
+ * [Тестирование дип линков (mobile deep links)](mobilnoe-testirovanie/testirovanie-dip-linkov-mobile-deep-links.md)
+ * [Тестирование сохраненных поисков](mobilnoe-testirovanie/testirovanie-sokhranennykh-poiskov.md)
+ * [Тестирование покупок в Android-приложениях](mobilnoe-testirovanie/testirovanie-pokupok-v-android-prilozheniyakh.md)
+ * [Тестирование покупок в iOS-приложениях](mobilnoe-testirovanie/testirovanie-pokupok-v-ios-prilozheniyakh.md)
+ * [Тестирование рекламы](mobilnoe-testirovanie/testirovanie-reklamy.md)
+ * [Тестирование просмотренных товаров](mobilnoe-testirovanie/testirovanie-prosmotrennykh-tovarov.md)
+ * [Покрытие девайсов](mobilnoe-testirovanie/pokrytie-devaisov.md)
+ * [Middleware](mobilnoe-testirovanie/middleware.md)
+ * [Android Debug Bridge (ADB)](mobilnoe-testirovanie/android-debug-bridge-adb.md)
+ * [Как проверить использование ресурсов на Android](mobilnoe-testirovanie/kak-proverit-ispolzovanie-resursov-na-android.md)
+ * [Как протестировать приложение для другой страны?](mobilnoe-testirovanie/kak-protestirovat-prilozhenie-dlya-drugoi-strany.md)
+* [Тестирование в разных сферах-областях (testing different domains)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/README.md)
+ * [Тестирование веб-сайта или веб-приложения (Web application)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-veb-saita-ili-veb-prilozheniya-web-application.md)
+ * [Тестирование интернет-магазина (eCommerce)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-internet-magazina-ecommerce.md)
+ * [Тестирование платежного шлюза (Payment Gateway)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platezhnogo-shlyuza-payment-gateway.md)
+ * [Тестирование игр (Game testing)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-igr-game-testing.md)
+ * [Тестирование VR программного обеспечения](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-vr-programmnogo-obespecheniya.md)
+ * [Тестирование мессенджера (Messenger)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-messendzhera-messenger.md)
+ * [Тестирование чат-бота (Chatbot)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-chat-bota-chatbot.md)
+ * [Тестирование электронных писем (E-mail)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-elektronnykh-pisem-e-mail.md)
+ * [Тестирование интернета вещей (IoT - Internet of Things)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-interneta-veshei-iot-internet-of-things.md)
+ * [Тестирование облачных решений (Cloud testing)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-oblachnykh-reshenii-cloud-testing.md)
+ * [Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-servis-orientirovannoi-arkhitektury-soa-service-oriented-architecture.md)
+ * [Тестирование микросервисной архитектуры (MSA/Microservices)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-mikroservisnoi-arkhitektury-msa-microservices.md)
+ * [Тестирование платформы электронного обучения (E-learning platform)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platformy-elektronnogo-obucheniya-e-learning-platform.md)
+ * [Тестирование систем розничной торговли (POS - Point Of Sale)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-sistem-roznichnoi-torgovli-pos-point-of-sale.md)
+ * [Тестирование банковского ПО (Banking domain applications/BFSI)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-bankovskogo-po-banking-domain-applications-bfsi.md)
+ * [Тестирование страхового ПО (Insurance)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-strakhovogo-po-insurance.md)
+ * [Тестирование в сфере телекоммуникаций (Telecom)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-v-sfere-telekommunikacii-telecom.md)
+ * [Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-planirovaniya-resursov-predpriyatiya-erp-enterprise-resource-planning.md)
+ * [Тестирование миграции данных (ETL)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-migracii-dannykh-etl.md)
+ * [Тестирование баз данных (Database)](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-baz-dannykh-database.md)
+ * [Другое](testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/drugoe.md)
+* [SDLC и STLC](sdlc-i-stlc/README.md)
+ * [Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)](sdlc-i-stlc/zhiznennyi-cikl-razrabotki-po-sdlc-software-development-lifecycle.md)
+ * [Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)](sdlc-i-stlc/zhiznennyi-cikl-testirovaniya-po-stlc-software-testing-lifecycle.md)
+ * [Модели разработки ПО](sdlc-i-stlc/modeli-razrabotki-po.md)
+ * [Agile](sdlc-i-stlc/agile.md)
+ * [Scrum](sdlc-i-stlc/scrum.md)
+ * [Подходы к разработке/тестированию (... - driven development/testing)](sdlc-i-stlc/podkhody-k-razrabotke-testirovaniyu-...-driven-development-testing.md)
+* [Сети и около них](seti-i-okolo-nikh/README.md)
+ * [База по сетям](seti-i-okolo-nikh/baza-po-setyam.md)
+ * [Клиент - серверная архитектура (Client-Server Architecture)](seti-i-okolo-nikh/klient-servernaya-arkhitektura-client-server-architecture.md)
+ * [Микросервисная архитектура (Microservice Architecture)](seti-i-okolo-nikh/mikroservisnaya-arkhitektura-microservice-architecture.md)
+ * [Эталонные модели OSI и TCP/IP](seti-i-okolo-nikh/etalonnye-modeli-osi-i-tcp-ip.md)
+ * [HTTP](seti-i-okolo-nikh/http.md)
+ * [Идентификация ресурсов в сети (Identifying resources on the Web)](seti-i-okolo-nikh/identifikaciya-resursov-v-seti-identifying-resources-on-the-web.md)
+ * [Веб-сервис (WS - Web service)](seti-i-okolo-nikh/veb-servis-ws-web-service.md)
+ * [REST/SOAP/gRPC](seti-i-okolo-nikh/rest-soap-grpc.md)
+ * [Сокет/веб-сокет (socket/websocket)](seti-i-okolo-nikh/soket-veb-soket-socket-websocket.md)
+ * [Хранилище на стороне клиента (Client-side storage)](seti-i-okolo-nikh/khranilishe-na-storone-klienta-client-side-storage.md)
+ * [Кэш (Cache)](seti-i-okolo-nikh/kesh-cache.md)
+ * [Аутентификация и авторизация (Authentication and authorization)](seti-i-okolo-nikh/autentifikaciya-i-avtorizaciya-authentication-and-authorization.md)
+ * [Рендеринг в интернете (Rendering on the Web)](seti-i-okolo-nikh/rendering-v-internete-rendering-on-the-web.md)
+* [Практическая часть](prakticheskaya-chast/README.md)
+ * [Логические задачи](prakticheskaya-chast/logicheskie-zadachi.md)
+ * [Тестирование полей и форм](prakticheskaya-chast/testirovanie-polei-i-form.md)
+ * [Примеры задач на собеседованиях и тестовых заданий](prakticheskaya-chast/primery-zadach-na-sobesedovaniyakh-i-testovykh-zadanii.md)
+ * [Платформы для тренировок и квизы](prakticheskaya-chast/platformy-dlya-trenirovok-i-kvizy.md)
+* [Автоматизация (beta)](avtomatizaciya-beta/README.md)
+ * [Общее](avtomatizaciya-beta/obshee.md)
+ * [Полезные ссылки](avtomatizaciya-beta/poleznye-ssylki.md)
+ * [Как стать автоматизатором и вопросы с собеседований](avtomatizaciya-beta/kak-stat-avtomatizatorom-i-voprosy-s-sobesedovanii.md)
+ * [Что нужно автоматизировать?](avtomatizaciya-beta/chto-nuzhno-avtomatizirovat.md)
+ * [Виды и инструменты автоматизации](avtomatizaciya-beta/vidy-i-instrumenty-avtomatizacii.md)
+ * [Инфраструктура и пайплайн (CI/CD)](avtomatizaciya-beta/infrastruktura-i-paiplain-ci-cd.md)
+ * [Процессы и автоматизация проекта с нуля](avtomatizaciya-beta/processy-i-avtomatizaciya-proekta-s-nulya.md)
+ * [Лучшие практики автоматизации](avtomatizaciya-beta/luchshie-praktiki-avtomatizacii.md)
+ * [Что такое flaky tests?](avtomatizaciya-beta/chto-takoe-flaky-tests.md)
+ * [Мутационное тестирование (Mutation testing)](avtomatizaciya-beta/mutacionnoe-testirovanie-mutation-testing.md)
+ * [Параллельное тестирование (Parallel testing)](avtomatizaciya-beta/parallelnoe-testirovanie-parallel-testing.md)
+ * [Подкожный тест (Subcutaneous test)](avtomatizaciya-beta/podkozhnyi-test-subcutaneous-test.md)
+ * [Разница между coupling и cohesion](avtomatizaciya-beta/raznica-mezhdu-coupling-i-cohesion.md)
+ * [Другое (ссылки)](avtomatizaciya-beta/drugoe-ssylki.md)
+* [Контакты](kontakty.md)
diff --git a/avtomatizaciya-beta/README.md b/avtomatizaciya-beta/README.md
new file mode 100644
index 0000000..793a874
--- /dev/null
+++ b/avtomatizaciya-beta/README.md
@@ -0,0 +1,3 @@
+# Автоматизация (beta)
+
+_Это черновик большого раздела автоматизации тестирования. Здесь не будет подробных гайдов по инструментам с практикой и кодом. Вместо этого, в рамках своих скромных компетенций, я бы хотел рассмотреть азы, дающие представление об общей картине: что это, зачем оно надо, какая бывает автоматизация, что следует автоматизировать, общие сведения о CI/CD, инфраструктуре, месте автотестов в общем пайплайне, механизме их запуска и отчетности, а также темы, полезные для поиска работы автоматизатором._
diff --git a/avtomatizaciya-beta/chto-nuzhno-avtomatizirovat.md b/avtomatizaciya-beta/chto-nuzhno-avtomatizirovat.md
new file mode 100644
index 0000000..39070b0
--- /dev/null
+++ b/avtomatizaciya-beta/chto-nuzhno-avtomatizirovat.md
@@ -0,0 +1,29 @@
+# Что нужно автоматизировать?
+
+
+
+**Какие модули и места следует подвергать автоматизации?**
+
+* Участки кода, исполнение которых трудно визуализировать и получить осязаемую информацию о протекающих процессах (back-end процессы, занесение в базу данных, занесение логов в файл);
+* Функциональность продукта, которая будет использоваться наиболее часто и возникновение ошибок которой связано с достаточно высоким риском. Автоматизированное тестирование узловых моментов функциональности потребует меньше времени для поиска ошибок. И соответственно, сократит время на их устранение;
+* Типовые часто выполняемые операции, которые обычно связаны с обработкой данных (CRUD). Например - формы, в которых количество заполняемых граф и полей довольно значительное. Цель - автоматизировать занесение требуемых данных в нужное поле и проверить правильность выполнения задачи после сохранения результата;
+* Сообщения об ошибках. Требуется автоматизация разнесения некорректных данных по соответствующим полям и тестирование корректности проверки правильности данных и сообщений об ошибках;
+* Комплексная проверка поведения всей системы, как целостного объекта (end-to-end testing);
+* Проверка числовых массивов, нужных для достоверных математических операций;
+* Тестирование корректности отображаемых результатов поиска в ответ на запрос по нужным данным;
+* Предложенный список только ориентировочный. Всё зависит от предъявляемых к проверяемой системе требований, возможностей, которые позволяет реализовать выбранный для автоматического тестирования инструмент.
+
+Источники:
+
+* [Какие места в проекте нужно автоматизировать в первую очередь?](https://software-testing.org/automation-testing/kakie-mesta-v-proekte-nuzhno-avtomatizirovat-v-pervuyu-ochered.html)
+
+Доп. материал:
+
+* [Автоматизировать или нет: спорные кейсы, плюсы и минусы автотестов](https://habr.com/ru/post/653721/)
+* [How To Select Correct Test Cases For Automation Testing (And Ultimately Achieve A Positive Automation ROI)](https://www.softwaretestinghelp.com/manual-to-automation-testing-process-challenges/)
+* [How To Implement Efficient Test Automation In The Agile World](https://www.softwaretestinghelp.com/automation-in-agile-world/)
+* [Right Tests for Automation](https://www.softwaretestinghelp.com/automation-testing-tutorial-1/#:\~:text=to%20strategize%20automation.-,Right%20Tests%20for%20Automation,-The%20best%20way)
+* [Решаем, что и когда автоматизировать, и нужно ли](https://testengineer.ru/reshaem-chto-i-kogda-avtomatizirovat/)
+* [Не автоматизируйте test cases](https://habr.com/ru/post/652499/)
+* [Автоматизация тестирования: что можно, а что не нужно](https://cleverics.ru/digital/2021/01/sw-testing-automation/)
+* [Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать](https://telegra.ph/Luchshie-praktiki-avtomatizacii-testirovaniya-reshenie-chto-i-kogda-avtomatizirovat-05-06)
diff --git a/avtomatizaciya-beta/chto-takoe-flaky-tests.md b/avtomatizaciya-beta/chto-takoe-flaky-tests.md
new file mode 100644
index 0000000..cf48c69
--- /dev/null
+++ b/avtomatizaciya-beta/chto-takoe-flaky-tests.md
@@ -0,0 +1,56 @@
+# Что такое flaky tests?
+
+Флейки-тесты, они же “флаки”, они же нестабильные, они же ненадежные, они же “моргающие”, они же “случайно успешные”
+
+Flaky-тест, буквально “хлопчатый”, “рассыпающийся на кусочки”, в индустрии ИТ-тестирования означает нестабильный, ненадежный тест, который иногда “pass”, иногда “fail”, и трудно понять, по какой закономерности. Убийца времени тестировщика, источник нервозности в команде.
+
+На такие тесты тратится много времени. Возникает задержка, пока команда не разберется, в чем дело. Конечно, страдает продуктивность.
+
+**Причины кратко**
+
+* Тестовый фреймворк изначально плохо собран. Его код не проверен на соответствие задачам. Совет: код фреймворка должен быть в достаточной мере чистым; должны соблюдаться принципы DRY, использоваться Object design pattern страницы, или Factory design pattern.
+* В тесте слишком много hardcoded-данных. Нестабильность результатов тестов возникает, когда эти тесты запускаются в другом окружении. Надо откорректировать hardcoded-данные (практика показывает, что это чаще всего неправильно прописанные пути к чему-то, неправильные IP-адреса и т.п.).
+* Кэширование предыдущего состояния теста и запуск нового теста с кэшированными данными. Лучше чистить кэш для каждого выполнения тестов. Проверяй данные перед каждым тестом, и очищай их состояние после каждого теста.
+* По внешней причине, не связанной с самими тестами. Плохое подключение к интернету или к конкретной базе данных; неподходящая версия браузера; утечки памяти.
+* “Потеря связи” со сторонним (3rd party) компонентом также приводит к ненадежности; здесь поможет тщательная проверка сторонних компонентов перед запуском.
+* Неэффективные селекторы элементов (например XPATH), или некорректные координаты элементов. Селекторы можно поменять достаточно легко, корректируя дизайн страницы. Рекомендуется работать с более надежными селекторами (например “id” или “name”).
+* Злоупотребление “sleep”-командами, останавливающими выполнение в ожидании чего-то. Здесь помогает замена “sleep”-ожидания на более надежное в этом плане “wait”-ожидание (пока элемент появится). Это экономит время и (почти) устраняет “моргание” тестов во многих случаях.
+
+**Что делать**
+
+Если есть время, надо документировать такие тесты, и отправлять в “карантин”. После выполнения тестов, проверь выведенные данные. Проверь логи, дампы памяти, текущее состояние системы. Возможно скриншоты, если это UI-тесты. В 90% случаев причина выяснится уже на этом этапе! Если нет, создай тикеты насчет этих тестов, и проверь их по одному в карантине, тщательно. Исключи тесты в карантине из пайплайна до конца проверки, пока не добьешься стабильности. В Google тоже бывают flaky-тесты, говорит Hala Samir из Google; как они решают эту проблему? Стандартно, например анализируют выведенные данные, проверяя корреляцию с функциями возможно вызвавшими нестабильность, по возможности без перезапуска тестов.
+
+**Еще раз о причинах**
+
+Если разделить причины по происхождению:
+
+* Тесты сами по себе имеют “склонность к нестабильности”
+* Проблемы с фреймворком
+* Проблемы в подключаемых библиотеках/сервисах
+* Проблемы в операционной системе / в устройстве
+
+**Подробнее.**
+
+Как уже говорилось выше, нестабильность результатов часто возникает из-за неправильной инициализации, или «очистки». Реже, но тоже случается - от неправильно подобранных тестовых данных. Головная боль тестировщиков - асинхронные действия, на это следует обращать особое внимание. Более простая причина - неправильный порядок запуска тестов.
+
+Проблемы с фреймворком: часто фреймворк не сконфигурирован на выделение достаточных системных ресурсов; или неправильно планирует очередность запуска тестов, из-за чего они “перекрываются” между собой.
+
+Если в проекте много сторонних библиотек или подключаемых сервисов, у них может быть свое “дерево зависимостей”, где и таятся причины нестабильности. Например переменные некорректно инициализируются; память “утекает”; какой-то ресурс не отвечает на запрос; и т.п. Чтобы исключить эти проблемы, в идеале надо стремиться к “герметичности” тестовой среды, то есть тестовая среда не должна иметь внешних зависимостей.
+
+Операционная система и тестовые устройства. Банально, но причиной иногда бывает нестабильное интернет-подключение. Также банальная причина - ошибки чтения/записи на физический носитель данных.
+
+**Статистика**
+
+Статистически (со слов тестировщиков), основные причины нестабильности это: на первом месте по «сложности разбора» асинхронные операции (async wait); затем многопоточные операции; затем неправильный порядок запуска тестов; затем аппаратные проблемы (с сетью и синхронизацией времени, или с памятью).
+
+Ну, а если найти причину нестабильных тестов и исправить их - не получается никак, то, как говорил вице-президент Unity3D Алан Берд, “нестабильные тесты это еще хуже, чем вообще без тестов”.
+
+Источники:
+
+* [Нестабильные тесты. Почему они существуют и что с ними делать](https://testengineer.ru/nestabilnye-testy-pochemu-oni-sushchestvuyut-i-chto-s-nimi-delat/)
+
+Доп. материал:
+
+* [Blog: Flaky Testing](https://www.developsense.com/blog/2021/02/flaky-testing/)
+* [Flaky-тесты: Откуда ноги растут. Опыт Uber](https://habr.com/ru/post/565806/)
+* [Flaky тесты (они же моргающие или "случайно успешные")](https://www.maxshulga.ru/2021/04/flaky-tests-or-random-success.html)
diff --git a/avtomatizaciya-beta/drugoe-ssylki.md b/avtomatizaciya-beta/drugoe-ssylki.md
new file mode 100644
index 0000000..0388f9f
--- /dev/null
+++ b/avtomatizaciya-beta/drugoe-ssylki.md
@@ -0,0 +1,64 @@
+# Другое (ссылки)
+
+_Всякое из сохраненного, что пока не определилось в другие темы_
+
+**Тренды автоматизации тестирования**
+
+* [AI/ML in Software Test Automation](https://medium.com/slalom-build/ai-ml-in-software-test-automation-979d18396ffa)
+* [Top 10 Automation Testing Trends for 2021](https://hackernoon.com/top-10-automation-testing-trends-for-2021-ra53354c)
+* [Топ тренды автоматизации тестирования, на которые следует обратить внимание в 2021 году](https://telegra.ph/Top-trendy-avtomatizacii-testirovaniya-na-kotorye-sleduet-obratit-vnimanie-v-2021-godu-03-04)
+* [Заменит ли автоматизация мануальщиков](https://www.developsense.com/blog/2021/08/alternatives-to-manual-testing-experiential-attended-exploratory/)
+* [Может ли автоматизированное тестирование заменить ручное?](https://habr.com/ru/post/565352/)
+
+**DevOps & TestOps**
+
+* [A Brief Guide to Testing in DevOps](https://dzone.com/articles/a-brief-guide-to-testing-in-devops)
+* [Артем Ерошенко - TestOps: DevOps для тестировщиков](https://www.youtube.com/watch?v=Iam2NlTukFQ\&list=PLsVTVVvrKX9td9Zm\_4nF6Ywlz6gC5\_e7K\&index=3)
+* [Почему TestOps - это DevOps для тестировщиков](https://www.youtube.com/watch?v=s-cXhMcYwQM\&list=PLd\_j4Ug00ng1y\_qvfszViFH53fhOTZoPn\&index=35)
+* [Обновленный обзор Allure TestOps](https://www.youtube.com/watch?v=F8cY8YN3DiE)
+* [Управление тестами в TestOps: храните информацию, а не выводы](https://habr.com/ru/post/558594/)
+* [Готовим QA-команду к внедрению DevOps: 5 советов](https://testengineer.ru/gotovim-qa-komandu-k-vnedreniyu-devops/)
+
+**Test case as a code**
+
+* [Артем Ерошенко - Тест-кейсы как код](https://www.youtube.com/watch?v=Prm2-c\_5mYs)
+* [Test as Text Approach in IntelliJ IDEA](https://blog.jetbrains.com/qa/2021/08/test-as-text-approach-in-intellij-idea/)
+* [Test case-as-code BDD, или управление ручными и автоматическими тестами](https://www.youtube.com/watch?v=6sK\_uaRyO5A)
+
+**Разное**
+
+* [Сколько стоит избавиться от ручного тестирования?](https://habr.com/ru/post/558074/)
+* [When To Opt For Automation Testing?](https://www.softwaretestinghelp.com/software-automation-testing-should-automate-project-testing/)
+* [По следам приложения - мониторинг](https://www.youtube.com/watch?v=2Xd9pAGGLk8)
+* [Внедряем Snapshot testing в UI-тесты iOS](https://habr.com/ru/company/vivid\_money/blog/569032/)
+* [Интеграционная шина и автоматизация бп](https://www.inpolus.ru/esb/)
+* [QA митап SuperJob](https://www.youtube.com/watch?v=LcEBjho7Ems)
+* [Manual Testing Vs. Automated Testing: Which One Is The Best Fit For You?](https://hackernoon.com/manual-testing-vs-automated-testing-which-one-is-the-best-fit-for-you-f226372o)
+* [AUTOMATED TESTING W/ TESTRIGOR CEO ARTEM GOLUBEV & PAUL GROSSMAN](https://theqalead.com/podcast/automated-testing-artem-golubev-paul-grossman/)
+* [THE GENERATION OF AUTONOMOUS AUTOMATION AND WHAT IT LOOKS LIKE (WITH BERTOLD KOLICS FROM MABL)](https://theqalead.com/podcast/the-generation-of-autonomous-automation-and-what-it-looks-like-with-bertold-kolics-from-mabl/)
+* [How To Make End-to-End Testing Your Friend](https://hackernoon.com/how-to-make-end-to-end-testing-your-friend)
+* [TEAMWORK, AI, AND CONTAINERIZATION (WITH NASA’S MICHAEL RITCHSON)](https://theqalead.com/podcast/teamwork-ai-and-containerization-with-nasas-michael-ritchson/)
+* [«Автотестеры, которые не ошибаются: как это сделать»](https://www.youtube.com/watch?v=fusFaT24F3o\&t=1225s)
+* [Автотесты на расширениях](https://habr.com/ru/company/sportmaster\_lab/blog/581696/)
+* [MVVM и МBT в контексте автоматизации UI](https://habr.com/ru/post/581206/)
+* [You shall not pass, или Как мы настроили мониторинг тестовых окружений](https://habr.com/ru/company/dins/blog/580712/)
+* [Тест дизайн методом Interface - Model - State](https://egor-romanov.medium.com/%D1%82%D0%B5%D1%81%D1%82-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD-%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BC-interface-model-state-7fa89c43934d)
+* [Автоматическое тестирование аналитики в браузере](https://habr.com/ru/company/ozontech/blog/592295/)
+* [Тестирование производительности приложений как часть ежедневного цикла разработки](https://habr.com/ru/company/veeam/blog/586666/)
+* [Паттерны и Методологии Автоматизации UI: Примеры из жизни](https://telegra.ph/Patterny-I-Metodologii-Avtomatizacii-UI-Primery-iz-zhizni-02-13)
+* [Три паттерна для улучшения работы с автотестами](https://habr.com/ru/company/badoo/blog/558496/)
+* [Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает](https://habr.com/ru/company/croc/blog/544028/)
+* [Так как же не страдать от функциональных тестов?](https://habr.com/ru/post/553820/)
+* [Как оценить покрытие автоматизации](https://software-testing.ru/library/testing/testing-automation/3589-how-to-document-coverage-of-automation)
+* [Координация автоматизированного и ручного тест-менеджмента](https://software-testing.ru/library/around-testing/management/3586-coordinating-manual-and-automatic-testing)
+* [THE PITFALLS OF TEST AUTOMATION](https://theqalead.com/topics/pitfalls-of-test-automation/)
+* [Три паттерна для улучшения работы с автотестами](https://software-testing.ru/library/testing/testing-automation/3616-how-3-process-patterns-will-change-the-way-you-do-test-automation)
+* [Software Tester or Lazy Developer?](https://thinkingtester.com/software-tester-or-lazy-developer/)
+* [Проверка эффективности автотестов](https://habr.com/ru/company/vivid\_money/blog/556988/)
+* [Test Markup in QA Automation](https://www.youtube.com/watch?v=Y4I6Vp4sk\_o)
+* [Алексей Баранцев: Десять правил построения хороших локаторов](https://www.youtube.com/watch?v=\_TNh2ydpoOw\&t=2s)
+* [Did You Test the Right Things? Test Gap Analysis Can Tell You](https://www.tricentis.com/blog/test-gap-analysis/)
+* [Using Gap Analysis In The Testing Process To Align Devs and Testers](https://www.functionize.com/blog/bridging-gap-devs-testers-test-gap-analysis-solution/)
+* [Семь самых распространенных ошибок при переходе на CI/CD](https://habr.com/ru/company/vk/blog/489430/)
+* [Как сократить издержки на автотестах](https://habr.com/ru/company/X5Group/blog/515752/)
+* [Меньше, чем пара. Еще один способ сокращения количества тестов](https://habr.com/ru/company/tinkoff/blog/516132/)
diff --git a/avtomatizaciya-beta/infrastruktura-i-paiplain-ci-cd.md b/avtomatizaciya-beta/infrastruktura-i-paiplain-ci-cd.md
new file mode 100644
index 0000000..b92dab1
--- /dev/null
+++ b/avtomatizaciya-beta/infrastruktura-i-paiplain-ci-cd.md
@@ -0,0 +1,158 @@
+# Инфраструктура и пайплайн (CI/CD)
+
+В этой теме у меня мало опыта, вероятность белиберды увеличена втрое.
+
+Сейчас компетентность в сфере TestOps является таким же базовым требованием к QA-инженерам, как и написание автоматизированных тестов. Причина - в активном развитии CI/CD в проектах и необходимости QA-инженерам работать с пайплайнами
+
+Многие начинающие автоматизаторы бросаются учить язык программирования, пишут первые учебные тесты и даже успешно делают тестовые задания по автоматизации тест-кейсов. Однако не все задумываются о том, что с этими тестами в реальной работе делать дальше. Кто их будет запускать? Когда? Каким образом? Здесь я бы хотел рассказать о пайплайне CI, месте автотестов в нем, а так же как и на чем тесты запускаются.
+
+Прежде всего, откуда этот пайплайн взялся и что за CI/CD.
+
+**Непрерывная интеграция** (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.
+
+CI/CD - это одна из DevOps-практик. Она также относится и к agile-практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес-требований, на качестве кода и безопасности.
+
+Непрерывная интеграция - это методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. И поскольку большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений. С технической точки зрения, цель CI - обеспечить последовательный и автоматизированный способ сборки, упаковки и тестирования приложений. При налаженном процессе непрерывной интеграции разработчики с большей вероятностью будут делать частые коммиты, что, в свою очередь, будет способствовать улучшению коммуникации и повышению качества программного обеспечения.
+
+**Непрерывная поставка** начинается там, где заканчивается непрерывная интеграция. Она автоматизирует развертывание приложений в различные **окружения**: большинство разработчиков работают как с продакшн-окружением, так и со средами разработки и тестирования.
+
+Инструменты CI/CD помогают настраивать специфические параметры окружения, которые конфигурируются при развертывании. А также CI/CD-автоматизация выполняет необходимые запросы к веб-серверам, базам данных и другим сервисам, которые могут нуждаться в перезапуске или выполнении каких-то дополнительных действий при развертывании приложения.
+
+Непрерывная интеграция и непрерывная поставка нуждаются в непрерывном тестировании, поскольку конечная цель - разработка качественных приложений. Непрерывное тестирование часто реализуется в виде набора различных автоматизированных тестов (регрессионных, производительности и других), которые выполняются в **CI/CD-конвейере** (pipeline, build chain и т.д.). Зрелая практика CI/CD позволяет реализовать непрерывное развертывание: при успешном прохождении кода через CI/CD-конвейер, сборки автоматически развертываются в продакшн-окружении. Команды, практикующие непрерывную поставку, могут позволить себе ежедневное или даже ежечасное развертывание.
+
+Типичный CD-**конвейер** состоит из этапов сборки, тестирования и развертывания. Более сложные конвейеры включают в себя следующие этапы:
+
+* Получение кода из системы контроля версий и выполнение сборки;
+* Настройка инфраструктуры, автоматизированной через подход “инфраструктура как код”;
+* Копирование кода в целевую среду;
+* Настройка [переменных](https://theqalead.com/topics/api-smoke-tests-cd-pipeline/#:\~:text=Step%20Five%3A%20Organize%20Your%20Variables) окружения для целевой среды;
+* Развертывание компонентов приложения (веб-серверы, API-сервисы, базы данных);
+* Выполнение дополнительных действий, таких как перезапуск сервисов или вызов сервисов, необходимых для работоспособности новых изменений;
+* Выполнение тестов и откат изменений окружения в случае провала тестов;
+* Логирование и отправка оповещений о состоянии поставки.
+
+Например, в Jenkins конвейер определяется в файле Jenkinsfile, в котором описываются различные этапы, такие как сборка (build), тестирование (test) и развертывание (deploy). Там же описываются переменные окружения, секретные ключи, сертификаты и другие параметры, которые можно использовать в этапах конвейера. В разделе post настраивается обработка ошибок и уведомления. В более сложном CD-конвейере могут быть дополнительные этапы, такие как синхронизация данных, архивирование информационных ресурсов, установка обновлений и патчей. CI/CD-инструменты обычно поддерживают плагины. Например, у Jenkins есть более 1500 плагинов для интеграции со сторонними платформами, для расширения пользовательского интерфейса, администрирования, управления исходным кодом и сборкой.
+
+Многие команды, использующие CI/CD-конвейеры в облаках используют **контейнеры**, такие как [Docker](https://www.software-testing.ru/library/testing/testing-for-beginners/3661-docker), и **системы оркестрации**, такие как Kubernetes. Контейнеры позволяют стандартизировать упаковку, поставку и упростить масштабирование и уничтожение окружений с непостоянной нагрузкой. Есть множество вариантов совместного использования контейнеров, инфраструктуры как код (**Iaas**) и CI/CD-конвейеров. Архитектура бессерверных вычислений представляет собой еще один способ развертывания и масштабирования приложений. В бессерверном окружении инфраструктурой полностью управляет поставщик облачных услуг, а приложение потребляет ресурсы по мере необходимости в соответствии с его настройками. Например, в AWS бессерверные приложения запускаются через функции AWS Lambda, развертывание которых может быть интегрировано в CI/CD-конвейер Jenkins с помощью плагина.
+
+_Больше о CI/CD можно почитать_ [_тут_](https://martinfowler.com/articles/continuousIntegration.html) _и_ [_тут_](https://martinfowler.com/delivery.html)_._
+
+**Этапы конвейера**
+
+В момент, когда триггерится сборка, например, когда разработчик сделал коммит в свою ветку, запускается процесс, который выполняется специально написанными скриптами и утилитами. Этот процесс состоит из нескольких обязательных шагов. Простой пример для PR:
+
+* При открытии каждого Pull Request, Git-сервер отправляет уведомление CI-серверу;
+* CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting), и сливает код с кодом master-ветке;
+* Тогда запускается билд-скрипт (сценарий сборки). Например ./gradlew build;
+* Если эта команда возвращает код ответа “0”, то билд успешно выполнен. (Другой ответ означает ошибку);
+* CI-сервер направляет уведомление об успешном билде на Git-сервере;
+* Если билд был успешен, то Pull Request разрешается слить с существующим кодом. (Если не успешен, то, соответственно, не разрешается).
+
+Ошибка в любом из шагов приводит к полному падению всей сборки. Ну и, само собой разумеется, шаги расположены в таком порядке, чтобы сужать воронку потенциальных проблем. Если Quality Gate предыдущего этапа не пройдет, то на проверку следующего уже можно не тратить ресурсы.
+
+Пример Quality Gates, которые встроены в pipeline [отсюда](https://habr.com/ru/company/otkritie/blog/568612/):
+
+* Сборка сервиса:
+ * Проверка наличия конфигурации корректного формата;
+ * Проверка стандартов оформления кода;
+ * Проверка на необходимое покрытие Unit-тестами;
+ * Генерации и публикации контрактов (контроль обратной совместимости).
+* Запуск Beta-тестов;
+* Обязательный code-review;
+* Сканирование на уязвимости.
+
+Пример сферического пайплайна в вакууме [отсюда](https://habr.com/ru/company/rabota/blog/560922/):
+
+* Code scanning: код проверяется на соответствие общему гайдлайну (linters), уязвимости (code security) и качество (code quality);
+* Unit tests;
+* Build: этап для сборки artifacts/packages/images и т.д. Здесь уже можно задуматься о том, каким будет стратегия версионирования всего приложения. Во времена контейнеризации, в первую очередь интересуют образы для контейнеров и способы их версионирования;
+* Scan package: пакет/образ собрали. Теперь нужно просканировать его на уязвимости. Современные registry уже содержат инструментарий для этого;
+* Deploy: стадия для развертывания приложения в различных окружениях;
+* Integration testing: приложение задеплоили. Оно где-то живет в отдельном контуре. Наступает этап интеграционного тестирования. Тестирование может быть как ручным, так и автоматизированным;
+* Performance testing (load/stress testing): данный вид тестирования имеет смысл проводить на stage/pre-production окружениях. С тем условием, что ресурсные мощности на нем такие же, как в production;
+* Code Review / Approved: одним из важнейших этапов являются Merge Request. Именно в них могут производиться отдельные действия в pipeline перед слиянием, а также назначаться группы лиц, требующих одобрения перед слиянием.
+
+_Больше про build-agent можно почитать тут:_ [_TeamCity: настраиваем CI/CD в вашей команде_](https://habr.com/ru/company/tinkoff/blog/532546/) _и тут_ [_Что такое сборщик продукта_](https://habr.com/ru/post/595375/)_, про окружения тут\*\* \*\*_[_Создаем инфраструктуру для интеграционных тестов_](https://habr.com/ru/company/2gis/blog/575688/)
+
+**Е2Е автотесты**
+
+Теперь пора поговорить непосредственно про то, что чаще всего касается рядового автоматизатора - **Е2Е автотесты**. Как мы выяснили выше, до прогона Е2Е сборка сначала проходит несколько шагов, а условиями запуска чаще являются ключевые моменты: commit, pull request и merge request. В моей прошлой компании был очень простой конвейер, где на коммит в фича-ветку запускались тесты разработчика, на вливание в develop стартовали критичные Е2Е тесты, а на вливание в main уже всё что есть, включая регрессионные тесты. Теперь, когда известны места автотестов в конвейере, нужно еще понять, на чем эти тесты будут прогоняться и как имея скрипт автотеста его запустить в конвейере.
+
+Все эти моменты конфигурируются в самом CI-агенте, в jenkins это были джобы (job). Пример: [How to Add your First Android Job to Jenkins](https://bugfender.com/blog/how-to-add-your-first-android-job-to-jenkins/). За запуск кода тестов, когда вы инициируете запуск из конвейера или локально, отвечает **Test Runner**. Это лишь одна из задач, в зону ответственности раннера [входят](https://habr.com/ru/company/avito/blog/516650/):
+
+* подготовка окружения;
+* формирование набора тестов для исполнения;
+* запуск тестов;
+* получение результатов выполнения тестов;
+* подготовка отчетов о прохождении тестов;
+* сбор статистики.
+
+Несмотря на то, что с фреймворком поставляется также и раннер, существует возможность использования более совершенных сторонних раннеров.
+
+Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:
+
+* Настоящий девайс.
+ * Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя - как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
+ * Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них - необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
+* Чистый эмулятор. Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
+ * Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
+ * Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус - это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
+* Docker-образ Android-эмулятора. Docker решает недостатки чистых эмуляторов.
+ * Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора - это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
+ * Минусы. Более высокий входной порог.
+
+В сети есть разные Docker-образы Android-эмуляторов:
+
+* [Docker image от Avito](https://avito-tech.github.io/avito-android/docs/ci/containers/);
+* [Docker image от Google](https://github.com/google/android-emulator-container-scripts);
+* [Docker image от Agoda](https://github.com/agoda-com/docker-emulator-android).
+
+Предстоит сделать сложный выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ. Вся эта инфраструктура уже связывается с раннером для запуска тестов, после чего уже решаются остальные моменты, такие как вывод отчета по прогону тестов (например, Allure) и внедрение/синхронизация с TMS.
+
+Источники:
+
+* [Что такое CI/CD? Разбираемся с непрерывной интеграцией и непрерывной поставкой](https://habr.com/ru/company/otus/blog/515078/)
+* [Разбираемся в CI/CD](https://testengineer.ru/razbiraemsya-v-ci-cd/)
+* [Автотесты на Android. Картина целиком](https://habr.com/ru/company/kaspersky/blog/510230/)
+
+Доп. материал:
+
+* [DevOps инструменты не только для DevOps. Процесс построения инфраструктуры автоматизации тестирования с нуля](https://habr.com/ru/post/497918/)
+* [Руководство для начинающих: создаем DevOps-пайплайн](https://habr.com/ru/company/skillfactory/blog/509964/)
+* [Зачем CI/CD тестировщикам?](https://habr.com/ru/company/JetBrains/blog/650757/)
+* [Jenkins Pipeline. Что это и как использовать в тестировании](https://habr.com/ru/company/yoomoney/blog/538664/)
+* [ГДЕ И КАК ПРОГОНЯТЬ UI ТЕСТЫ](https://www.youtube.com/watch?v=0AQlKbskhkM\&t=3963s)
+* [Инфраструктура + тестирование = любовь](https://habr.com/ru/post/655671/)
+* [Leadership in test: a guide to infrastructure and environments](https://theqalead.com/topics/infrastructure/)
+* [Leadership in test: testing tools](https://theqalead.com/topics/testing-tools/)
+* [Создаем инфраструктуру для интеграционных тестов](https://habr.com/ru/company/2gis/blog/575688/)
+* [HOW TO RUN API SMOKE TESTS IN YOUR CONTINUOUS DEPLOYMENT PIPELINE](https://theqalead.com/topics/api-smoke-tests-cd-pipeline/)
+* [Разбираемся в CI/CD](https://testengineer.ru/razbiraemsya-v-ci-cd/)
+* [Что такое CI (Continuous Integration)](https://habr.com/ru/post/508216/)
+* [Как мы настроили CI/CD, чтобы релизить часто и без страха](https://habr.com/ru/company/otkritie/blog/568612/)
+* [Как настроить Pipeline для Jenkins, Selenoid, Allure](https://habr.com/ru/company/simbirsoft/blog/597703/)
+* [CI-билд - это не елка](https://telegra.ph/CI-bild--ehto-ne-elka-02-15)
+* [Идеальный пайплайн в вакууме](https://habr.com/ru/company/rabota/blog/560922/)
+* [Основные подходы к CI/CD для целей тестирования ПО](https://www.youtube.com/watch?v=oiSUH4eHYoc\&t=5980s)
+* [How To Have Seamless Script Execution Planning And Reporting For Success Of An Automation Project](https://www.softwaretestinghelp.com/automation-testing-tutorial-6/)
+* [Что такое сборщик продукта](https://habr.com/ru/post/595375/)
+* [#8 QA инфраструктура компании на локальной машине. Docker, Jenkins, Jira, Selenoid, Allure.](https://www.youtube.com/watch?v=LeA2\_GJ1e70\&list=WL\&index=9\&t=3047s)
+* [Автотесты и Docker](https://testengineer.ru/avtotesty-i-docker/)
+* [Интеграция с Allure: структурировать, упростить, стабилизировать](https://habr.com/ru/company/wrike/blog/588873/)
+* [Автоматизация расчета покрытия требований и его визуализация в Allure Report](https://www.youtube.com/watch?v=oPpVRc7xvDc)
+* [Что такое Docker](https://www.software-testing.ru/library/testing/testing-for-beginners/3661-docker)
+* [Continuous Integration with Jenkins](https://learn.epam.com/detailsPage?id=62dc3947-e941-4c30-ba32-552eb363978e)
+* [Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)](https://habr.com/ru/company/flant/blog/471620/)
+* [Как e2e автотесты на Selenide помогают QA-команде при частых релизах](https://habr.com/ru/company/croc/blog/546430/)
+* [Как ускорить автотесты](https://habr.com/ru/company/vk/blog/645695/)
+* [Тестируем CI Pipeline](https://www.youtube.com/watch?v=OvhjxN9fY5c)
+* [Switchboard: набор инструментов для управления авто-тестами](https://www.youtube.com/watch?v=2RDT1gsSjcE)
+* [Централизованное логирование в Docker с применением ELK Stack](https://habr.com/ru/company/otus/blog/542144/)
+* [Строим домашний CI/CD при помощи GitHub Actions и Python](https://habr.com/ru/post/476368/)
+* [Нагрузочное тестирование как CI-сервис для разработчиков](https://habr.com/ru/company/pt/blog/504290/)
+* [Автоматическое тестирование микросервисов в Docker для непрерывной интеграции](https://habr.com/ru/company/auriga/blog/503334/)
+* [Тесты на pytest с генерацией отчетов в Allure с использованием Docker и Gitlab Pages и частично selenium](https://habr.com/ru/post/513432/)
+* [Автоматизация системных тестов на базе QEMU (Часть 1/2)](https://habr.com/ru/post/520310/)
+* [Как сократить время сборки образов Docker в GitLab CI](https://habr.com/ru/company/otus/blog/537780/)
+* [Crash-crash, baby. Автоматический мониторинг фатальных ошибок мобильных приложений](https://habr.com/ru/company/avito/blog/518222/)
+* [git-flow](https://danielkummer.github.io/git-flow-cheatsheet/index.ru\_RU.html), [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow), [GitLab Flow](https://docs.gitlab.com/ee/topics/gitlab\_flow.html)
diff --git a/avtomatizaciya-beta/kak-stat-avtomatizatorom-i-voprosy-s-sobesedovanii.md b/avtomatizaciya-beta/kak-stat-avtomatizatorom-i-voprosy-s-sobesedovanii.md
new file mode 100644
index 0000000..3b733ca
--- /dev/null
+++ b/avtomatizaciya-beta/kak-stat-avtomatizatorom-i-voprosy-s-sobesedovanii.md
@@ -0,0 +1,119 @@
+# Как стать автоматизатором и вопросы с собеседований
+
+**Можно ли стать автоматизатором без опыта ручного тестирования?**
+
+Можно, если у вас есть опыт в программировании. В каких-то компаниях это действительно так и работает. Ручные тестировщики пишут тест-кейсы (шаги + ожидаемый результат), автоматизатор их берет и переносит в код. В принципе, такой подход вполне валиден и работает, но я вижу в нем некоторые недостатки.
+
+Во-первых, когда сам пишешь автотесты на функционал, который хорошо знаешь, ты можешь по ходу добавлять какие-то проверки, которые мог пропустить во время написания тест-кейсов. Плюс знаешь другие автотесты, которые можно дополнить. Соответственно, тебе легче поддерживать актуальность автотестов.
+
+Во-вторых, автоматизация тестирования - это интересно и полезно. Ты начинаешь изучать код, расширяешь свои знания о продукте, понимаешь, как всё работает изнутри. Это полезно и для ручного тестирования в том числе. Начинаешь чуть лучше понимать разработчиков.
+
+**Можно ли писать автотесты автоматически? Не хочется учиться программированию.**
+
+Попробовать можно. Мы пробовали. Для таких дел существуют рекордеры. Но те тесты, которые ими создаются - это монструозные и неподдерживаемые куски кода.
+
+Возможно, это будет работать, если, допустим, в приложении есть какая-то кнопка, которая никогда не будет меняться. Не изменится ни путь до нее, ни ее функциональность и положение. Тогда код этого теста никогда не нужно будет менять, и пусть этот тест будет жить. Но увы, на практике так не работает. Тесты должны быть легко поддерживаемыми, понятными, читаемыми. Рекордером такого не добьешься.
+
+Можно использовать рекордеры в каких-нибудь сложных местах приложения, чтобы посмотреть, как можно повзаимодействовать с каким-нибудь труднонаходимым элементом. То есть использовать его как помощника, как вспомогательный инструмент, но не как основное средство автоматизации.
+
+**За сколько тестировщик превращается в автотестировщика**
+
+Опять же, по нашему опыту, мы нанимаем человека без опыта автоматизации и на испытательный срок (3 месяца) ему ставится задача - написать свой первый автотест на любую из платформ, которая ему понравится больше или покажется проще. И у нас еще никто не провалил испытательный срок.
+
+Естественно, большую роль играет то, что человек пишет автотесты не совсем с нуля. У нас уже есть и готовые автотесты, которые можно смотреть и писать по аналогии, и люди, которые готовы помогать и отвечать на вопросы.
+
+По итогу за 3 месяца мы получаем человека, который уже понимает, как писать автотесты минимум для одной из платформ. Следующим шагом будет написать такой же тест для второй платформы. Еще через 3-4 месяца мы получим самостоятельного автоматизатора мобильных приложений под обе платформы, которому еще какое-то время, возможно, нужна будет помощь с какими-то сложными вещами. Но вот свободно писать легкие автотесты под обе платформы он будет уже через полгода.
+
+**Карьерный путь автоматизатора**
+
+* [Что учить, чтоб стать автоматизатором тестирования](https://www.youtube.com/watch?v=d5yCDe0\_ddE)
+* [Карьерный путь автоматизатора](https://software-testing.ru/library/around-testing/job/3626-test-automation-career-path)
+
+Роадмапы в основном включают и мануал и авто, их можно посмотреть в теме “Что должен знать и уметь Junior? Что спросят на собеседовании?”.
+
+**Вопросы для подготовки к собеседованию** можно условно поделить на 3 большие группы:
+
+* джуна наверняка всё-равно будут спрашивать общую теория тестирования по мануалу, хотя бы по верхам;
+* всё то, что касается непосредственно автоматизации: какая бывает, инструменты в общем и конкретно под вакансию, представление об инфраструктуре CI/CD, лучшие практики автоматизации и т.п.;
+* core языка программирования, указанного в вакансии и всё, что вокруг этого.
+
+**Вопросы по автоматизации**:
+
+* Что такое автоматизация и зачем она нужна?
+* Когда нужно начинать автоматизацию на проекте?
+* Какая бывает автоматизация (виды, методы, платформы и т.п.)?
+* Популярные фреймворки и инструменты автоматизации, запуска тестов и генерации отчетности;
+* Инфраструктура CI/CD, пайплайн, место автотестов в нем;
+* Что следует автоматизировать в первую очередь?
+* Какая тестовая документация нужна для автоматизированного тестирования?
+
+**Вопросы по языкам программирования**:
+
+Java:
+
+* дизайн-паттерны;
+* дата-типы;
+* коллекции, Map...;
+* модификаторы доступа. Public, Private, Abstract классы и методы;
+* Что такое Интерфейс?
+* Что такое лямбда функция?
+* дженерики;
+* коллекции;
+* методы класса object;
+* больше [тут](https://github.com/enhorse/java-interview) или в гугле.
+
+**Вопросы общие** по типу:
+
+* Разница между библиотекой и фреймворком?
+* Что означает слово SNAPSHOT в версии библиотеки?
+* Что такое SDK?
+
+**Практические навыки**:
+
+* уметь писать код;
+* Git;
+* консоль;
+* типовые инструменты для платформы;
+* моки запросов (Swifter/Wiremock);
+* инструменты отчетности (Allure);
+* инструменты CI.
+
+[Пример](https://t.me/qa\_interviews/64422) вопросов от кандидата работодателю:
+
+* Сколько IOS разработчиков в приложении?
+* Сколько Unit Test’ов и сколько UI Test’ов на данный момент?
+* С какой периодичностью запускаются тесты?
+* Какой релизный цикл? Сколько сейчас времени на регресс?
+* Кто добавляет Accebility Identifier’ы в приложение?
+* Какая минимальная версия IOS поддерживается?
+* Сколько времени тратится на сборку приложения локально?
+* Какая система сборки используется на проекте?
+* Автоматизируете ли разрешение конфликтов в project.pbxproj ?
+
+Источники:
+
+* [ТОП-5 вопросов ручных тестировщиков про автоматизацию](https://habr.com/ru/company/hh/blog/575390/)
+* [ТОП-5 вопросов технического директора про автоматизацию](https://habr.com/ru/company/hh/blog/582968/)
+
+Доп. материал:
+
+* [Чек-лист для начинающего автотестера на Java](https://testit.software/blog/post/chek-list-dlya-nachinayushchego-avtotestera-na-java)
+* [**39 TOP Automation Testing Interview Questions And Answers**](https://www.softwaretestinghelp.com/test-automation-interview-questions/)
+* [**50 Most Popularly Asked Selenium Interview Questions And Answers**](https://www.softwaretestinghelp.com/selenium-interview-questions-answers/)
+* [**Automation Testing Interview Questions And Answers (Updated 2022**](https://www.softwaretestingmaterial.com/automation-testing-interview-questions/)**)**
+* [**Interview Prep Questions**](https://docs.google.com/document/d/1UQR1Zvwyrgyuo600qEVAWt4d25LWo5B5KLGe-c09aU4/edit#heading=h.tu27eqwwcawn)
+* [50 вопросов по Docker, которые задают на собеседованиях, и ответы на них](https://habr.com/ru/company/southbridge/blog/528206/)
+* [Как начать карьеру QA Automation Engineer: один простой совет](https://vc.ru/hr/350932-kak-nachat-kareru-qa-automation-engineer-odin-prostoy-sovet)
+* [Нужно ли знать программирование для qa автоматизатора?](https://www.youtube.com/watch?v=y2Xh25f5O9U)
+* [Как стать QA AUTOMATION engineer с нуля самостоятельно](https://www.youtube.com/watch?v=k0LFk9yH98c)
+* [Дмитрий Бормотов - Трансформация из Manual QA в Automation](https://www.youtube.com/watch?v=FkhWIgqtmZ8\&list=PLsVTVVvrKX9td9Zm\_4nF6Ywlz6gC5\_e7K\&index=12)
+* [Как стать автоматизатором тестирования?](https://habr.com/ru/post/253867/)
+* [Какие вопросы ожидать на позицию автоматизатора и причем тут сортировка?](https://habr.com/ru/post/550510/)
+* [Что спрашивают на собеседовании у джуна, или как я искала свою вторую работу в ИТ](https://habr.com/ru/post/442348/)
+* [10 Awesome Tips To Become A Better Automation Tester](https://www.softwaretestinghelp.com/how-to-become-better-automation-tester/)
+* [Какие ошибки совершает начинающий QA Automation Engineer? Как их избежать?](https://www.youtube.com/watch?v=8QQVe5LYgdw)
+* [Три типичных ошибки автоматизатора](https://testengineer.ru/tipichnye-oshibki-avtomatizatora/)
+* [QAGuild#54: Что должен знать тестировщик? Топ 3 навыка для QA Automation engineer](https://www.youtube.com/watch?v=XgMGjRAQZJg)
+* [Как стать Java разработчиком за 1,5 года](https://habr.com/ru/post/439432/)
+* [Как я изучал структуры данных и алгоритмы для собеседования в FAANG](https://habr.com/ru/company/skillfactory/blog/539058/)
+* [Как я готовился к собеседованию в Google](https://habr.com/ru/company/skillfactory/blog/538536/)
diff --git a/avtomatizaciya-beta/luchshie-praktiki-avtomatizacii.md b/avtomatizaciya-beta/luchshie-praktiki-avtomatizacii.md
new file mode 100644
index 0000000..1b12d68
--- /dev/null
+++ b/avtomatizaciya-beta/luchshie-praktiki-avtomatizacii.md
@@ -0,0 +1,114 @@
+# Лучшие практики автоматизации
+
+В каждой статье свой топ лучших практик, характеристик хороших тестов и подобного, так что я просто скопировал наиболее полезные на мой взгляд списки.
+
+**7 характеристик отлично написанных тестов**
+
+* **Тест полностью автоматизирован** (очевидно): Иногда попадаются такие тесты, которые автоматизированы не полностью. Самые распространенные причины: либо это очень сложно, либо просто невозможно;
+* **Тест повторяем**: тест не ломается, если приложение не поменялось: Это относится к основам генерации уникальных данных. Например, мы тестируем регистрацию. Очевидно, что если не генерировать уникальный емейл, то на продакшене такой тест, скорее всего, не будет работать;
+* **Тест заканчивается валидацией**: За исключением случаев, где нужно выполнить действия по зачистке данных и подобных действий, завершение валидацией является лучшей практикой. Это помогает убедиться, что последнее действие прошло успешно;
+* **Тест достаточно стабилен, чтобы его использовать в CI/CD**: Если тест регулярно ломается, то он недостаточно стабилен, чтобы использовать его в CI/CD. Так как практически любая компания пытается добиться CI или даже CD, то часто такой тест не просто бесполезен, но даже вреден, так как отнимает большое количество времени и все равно не может использоваться в CI автоматически;
+* **Тест очень легко читать**: Мы обычно не пишем тесты в одиночку. Часто это команда людей и нашим коллегам тоже приходится поддерживать наши тесты. Крайне важно, чтобы любой член команды мог разобраться в структуре теста, не тратя на это излишнее количество времени. Даже если мы пишем тесты в одиночку, иногда бывает очень тяжело понять, что тест делает и как, если он не написан специально для облегчения понимания;
+* **Тест требует минимальной поддержки**: Пункт очевидный, но не всегда соблюдаемый. Чем меньше мы тратим времени на поддержку, тем больше у нас времени на то, чтобы сделать что-то полезное, как, например, написать больше тестов;
+* **Тест работает параллельно с другими тестами и не ломается**: В какой-то момент, особенно для end-to-end тестов, мы сталкиваемся с тем, что прогон тестов занимает слишком много времени, это снижает скорость разработки и приводит к таким эффектам, как неоттестированный патч. На этом этапе мы обычно задумываемся о параллелизации, чтобы ускорить исполнение тестов. Если тесты были написаны так, что они могут быть запущены параллельно в любой последовательности и не пересекаться друг с другом, то это делает задачу параллельного исполнения просто задачей настройки инфраструктуры, а не задачей переписывания тестов.
+
+**Еще десять заповедей автоматизации**
+
+1. **Не автоматизируй только "по тест-кейсам"**
+
+Существует распространенное заблуждение, что тест-автоматизация обязана произрастать из тест-кейсов. Автоматизаторы берут существующие или свежесозданные тест-кейсы и превращают их в автоматизированные сценарии. Это называется "автокафе". В этом подходе может быть смысл, но другие подходы принесут не меньше, а то и больше выгоды. Расширяя определение автоматизации за рамки "тест-кейс - инструмент - тест-скрипт" до "продуманного применения технологии с целью помочь людям выполнять свою работу", мы можем использовать компьютерные мощности для задач, для которых они предназначены, а люди - тестировщики - пусть делают все остальное. К счастью, в большинстве задач, где хороши люди, компьютеры выступают плохо - и наоборот.
+
+**2. Обращайся с разработкой автоматизации, как с разработкой ПО**
+
+Разработка автоматизации - это и есть разработка ПО. Даже если мы используем интерфейс перетаскивания или записи и воспроизведения для создания автоматизации, то где-то под капотом или за занавесом над нашими действиями работает код. Мы должны начать обращаться с автоматизацией как с разработкой ПО, иначе мы окажемся с чем-то неподдерживаемым на руках, и проект умрет, едва родившись. Подход к автоматизации как к разработке ПО означает, что мы должны учитывать большинство (если не все) процессов и видов деятельности, требуемых при разработке ПО. Включая:
+
+* Дизайн - мы должны решить, что внедрять и как это делать, чтобы это было поддерживаемым и пригодным к эксплуатации.
+* Внедрение - надо написать код.
+* Хранение - код и его артефакты должны где-то храниться.
+* Тестирование - тестировать тесты? Естественно! Мы должны быть достаточно уверены, что автоматизация ведет себя так, как нам хочется. Если мы не доверяем автотестам, в них нет смысла.
+* Баги - в любом ПО есть баги; автоматизация, как ПО, не исключение. Тестирование поможет нам, но не отловит все баги на свете. Выделите время на исправление багов.
+* Логи - это артерия автоматизации. Без них мы не поймем, что автоматизация делает, и не сможем ее починить, когда она сломается. К тому же мы не сможем сказать, в автоматизации ли кроется проблема, или же в тестируемом ПО.
+
+**3. Следуй стандартам и идиомам программирования**
+
+Помимо обращения с автоматизацией как с разработкой ПО, мы должны встраивать в нее соответствующие идеи по внедрению. Каждый инструмент и язык имеют свои собственные идиомы и хитрости, но общепринятые подходы к проектированию и внедрению обычно годятся для всего. Эта статья про инкапсуляцию и абстракцию рассказывает об образцовых практиках, которое можно переносить в другие специфичные области.
+
+**4. Не забывай про поддержку и обслуживание**
+
+ПО не идеально и никогда не бывает полностью готово; с автоматизацией то же самое. В ней будут баги. С изменением тестируемого приложения нужно будет соответственно менять автоматизацию. Мы не можем это предотвратить, но можем разработать наше ПО так, чтобы снизить затраты на его поддержку и обслуживание; и на них тоже надо выделить время. Эта статья и этот пост в блоге рассказывают о факторах, которые надо учитывать, планируя будущую поддержку.
+
+**5. Не делай скрипты зависимыми друг от друга**
+
+Создание тест-скрипта, зависимого от результатов другого теста - как правило, мощный анти-паттерн. Если скрипты зависят друг от друга, их нельзя прогонять поодиночке, и это усложняет дебаг автоматизации и проблем приложения. К тому же зависимые скрипты нельзя запускать параллельно с теми, от которых они зависят. Тут есть граничный случай, когда абсолютно все скрипты зависят от одного-единственного. Этот единичный скрипт обычно настраивает тест-окружение и тестовые данные. В условиях современных фреймворков автоматизации и непрерывной развертки это все большая редкость, но этот сценарий может быть уместен в ситуациях, когда фреймворки недоступны или не подходят для специфической автоматизационной задачи.
+
+**6. Внедряй грамотное логирование и отчеты**
+
+Как описано здесь, грамотные логи, результаты и сообщения об ошибках критично важны для понимания, доверия к, и поддержки автоматизации. Эти логи - наш детализированный образ прогона автотестов: что запускалось, как именно, что упало, как оно упало, как оно преуспело, и т. д. Конечно, если мы тщательно внедрили грамотное логирование, которое дает нам эту информацию в читабельной форме.
+
+**7. Влияй на тестируемость и автоматизируемость**
+
+Тестируемость, та степень, до которой приложение или фича могут быть протестированы, и автоматизируемость, степень, до которой тест-деятельность может выполняться автоматически - это не то, что могут создавать тестировщики, QA и QE, но, конечно, есть вещи, на которые мы можем повлиять. Осуществление этого влияния - наша обязательная задача. Разработчики не всегда знают, что нам нужно для тестирования и для создания автотестов. Мы должны донести это до них. Статьи здесь и здесь рассказывают о некоторых аспектах тестируемости и автоматизируемости.
+
+**8. Не попадайся в ловушку невозвратных затрат**
+
+Иногда мы делаем ошибки. Иногда это крупные ошибки. Мы извлекаем максимум из информации, которой располагаем в моменте, но это не всегда срабатывает. Когда что-то в нашем плане идет не так, мы инстинктивно стараемся это исправить и продолжать исправлять. Однако иногда стоит начать заново, иначе мы рискуем выбросить хорошие деньги вслед за плохими. Это называется "ловушкой невозвратных затрат". Если кратко, она заключается в мнении, что мы уже потратили столько денег на этот проект, что обязаны потратить еще для его реабилитации, дабы извлечь выгоду из уже потраченных, невозвратных затрат на него. Возможно, мы эмоционально привязаны к нашему программному "ребенку"; мы потратили на него столько времени и денег, что не в силах выбросить его и начать заново. Возможно, мы боимся; руководство, скорее всего, не придет в восторг, захоти мы бросить все и снова сделать "то же самое". Мы должны рассматривать такие ситуации с точки зрения бизнеса, а не предаваться эмоциям.
+
+**9. Опасайся хитроумных приспособлений**
+
+Машины Руба Голдберга - это сложные машины, выполняющие сравнительно простые задачи, вроде "Автономного платочка". В мире автоматизации создание таких машин - очень веселое дело, и они могут делать крутые штуки вроде увязывания вместе разных инструментов для выполнения тест-задач. Минус в том, что это сложно понимать и поддерживать; надо опасаться создания того, что сложнее поддерживать, нежели выполнять эти задачи вручную. Эта статья расскажет больше об автоматизированных машинах Руба Голдберга; этот пост размышляет о состоянии "автоматизированности".
+
+**10. Не делай тестовые данные зависимыми от временных данных**
+
+Скрипт, с которым я столкнулся недавно, в один прекрасный день начал падать. Исследуя вопрос, мы выяснили, что падал он из-за смены месяца с июля на август. Скрипт был написан таким образом, что оракул проверял даты в июле, и в июле все было хорошо - приложение возвращало даты текущего месяца, июля. Когда дата сменилась на август, приложение начало возвращать даты августа, и тест падал. В этом случае надо не жестко кодировать даты июля, а динамически генерировать данные на основании текущего месяца.
+
+**Как можно и нельзя автоматизировать**
+
+**Нельзя**:
+
+* **Автоматизировать все ручные тесты**: ручные тесты прекрасны - они находят проблемы, о которых вы даже не помышляли. Но ручной подход к тестированию не всегда можно напрямую перенести на автоматизированные проверки. Возможно, стоит создать новые сценарии специально для автоматизации.
+* **Делать автотесты задачей одного-единственного человека**: когда вы только начинаете, найм консультанта по автоматизации - хорошая мысль, однако убедитесь, что соответствующие знания доступны всем участникам проекта. В один прекрасный день консультант или ключевой исполнитель покинет вас, и разбираться с тест-набором придется всем остальным.
+* **Автоматизировать все на свете**: сценарий автоматизируется не просто так - на это есть причины, его автоматизация каким-то образом ценна для проекта. Начните с рутинных задач, которые все равно выполняются ежедневно - и вы сразу увидите первую, мгновенную выгоду от усилий по автоматизации.
+* **Автоматизировать, просто чтобы автоматизировать**: подумайте, что вам нужно, и что нужно прямо сейчас. Если вы настроены на 80-100% автоматизацию во всех проектах просто потому, что "это круто и так хочет генеральный директор, или "это хорошо звучит на собраниях совета директоров", то вы попусту тратите время и деньги.
+* **Покупать лидирующий по рынку, наилучший инструмент автоматизации**: найдите инструмент, который подходит под ваши задачи, и убедитесь, что он действительно делает то, что обещает. Не поддавайтесь на уговоры продавцов купить дорогостоящую программу, которая очень крута прямо сейчас в этом конкретном проекте или на этой конкретной платформе. И не заставляйте другие проекты использовать инструмент, если он им не нужен.
+* **Думать в терминах "прошел" и "упал"**: у вас будут упавшие кейсы. Это не значит, что там есть ошибка. Не воспринимайте упавший тест как сигнал о баге - вам нужно разобраться, ПОЧЕМУ тест упал. Также подумайте, действительно ли категории "прошел/упал" подходят для отчетности об автотестах? Возможно, стоит подумать о другой классификации, которая лучше опишет происходящее?
+* **Запускать все подряд каждый божий раз**: подумайте о цели прогона ваших тестов. Если вам не нужно тестировать отдельную область - не делайте этого, тестируйте только ту функциональность, которая в этом нуждается. Прочее тестирование - это лишняя трата времени и сил, которая замусорит ваш отчет ненужными данными. Конечно, некоторые проверки могут гоняться постоянно, но убедитесь в том, что это оправданные меры.
+* **Забывать тестировать собственные тесты**: привыкайте к идее тестировать свои тесты. Автоматизированный тест-сценарий не должен выпускаться в мир, пока вы не увидели, как он несколько раз упал. Запускайте тест в обстоятельствах, когда он безусловно упадет, чтобы учесть это, когда он будет выпущен в релиз.
+* **Недооценивать усилия по поддержке автоматизированного набора тестов**: автоматизированный тест-сьют - не та штука, которую сделал и забыл, а она бегает себе там. Ваша система постоянно меняется, и тест-набор нужно обновлять и пополнять беспрестанно. Не сваливайте эту ответственность на единственного тех-тестировщика в вашей компании.
+
+**Нужно**:
+
+* **Дробить тесты на независимые сценарии**: куда легче определить, где гнездятся проблемы и ошибки, если ваш тест-набор состоит из кратких, конкретных тест-сценариев. Не пытайтесь впихнуть все в один сценарий. Очень, ОЧЕНЬ трудно разобраться, что же пошло не так, если вам надо докопаться до всего на свете, проверяющегося в вашем тесте. Пусть тесты будут краткими и простыми.
+* **Сделать автоматизацию задачей всей команды проекта**: почему бы не дать возможность всем, а не только тестировщикам, влиять на набор автотестов? Разработчики, менеджеры проекта, продакт-оунеры - всем им есть что сказать на предмет автоматизированного тестирования, и они могут принести ему пользу.
+* **Донести информацию о результатах автоматизированного тестирования до всех - и подумать, кто получает эти результаты**: предоставьте разную информацию разным людям в проекте. Разработчику нужна специфическая информация о прогоне автотестов, и она безразлична менеджеру проекта. Опросите всех заинтересованных лиц, выясните, какая информация им требуется.
+* **Начинать с простых вещей и пополнять тест-сьюты по ходу дела**: начните с того, что вам необходимо, и следуйте по воркфлоу проекта. Проекты постоянно меняются - не надо тратить время, силы и деньги на то, что не будет использовано или изменится в последний момент. Создавайте набор тестов по кусочкам, шаг за шагом.
+* **Заставить ваш фреймворк работать на износ**: вы приобрели дорогую программу, настроили ее и потратили время на создание и обновление наборов тестов. Пользуйтесь этим! Создайте набор, который может прогоняться часто И при этом ценен для проекта! Набор автотестов, который не запускается - это пустая трата денег.
+* **Учитывать проектные и организационные изменения**: найдите программу, которая способна расти вместе с вашими проектами и вашей организацией, и выясните, что вы можете - и не можете - с ней делать. Если она вам не подходит, отбросьте ее. Нет смысла тратить силы и время на неподходящие вам ресурсы.
+* **Разгрузить ручных тестировщиков**: думайте о наборе автотестов как о помощи мануальным тестировщикам. Освободите их от нудных повторяющихся задач, пусть они делают то, в чем они звезды - тестируют, а не тупо следуют сценариям.
+* **Сделать запуск тестом простым и быстрым**: настройка и старт набора автотестов должна быть простой задачей и давать мгновенную обратную связь. Если ваш тест-набор замедлен или очень сложен, люди просто не будут заморачиваться с запуском.
+* **Постоянно обновлять тест-набор**: если меняется ваш код - меняются автотесты, и это ваше золотое правило. Оно верно для ВСЕХ изменений базы кода. Правки багов, внедрение фич - все это ведет к изменениям тест-набора.
+
+_О паттернах проектирования/архитектуре есть ссылки в доп. материалах ниже. О создании фреймворка в теме про виды и инструменты._
+
+Источники:
+
+* [7 характеристик хороших тестов](https://habr.com/ru/post/599507/)
+* [Еще десять заповедей автоматизации](https://software-testing.ru/library/testing/testing-automation/3492-ten-more-commandments-of-automation)
+* [Как можно и нельзя автоматизировать](https://software-testing.ru/library/testing/testing-automation/2940-starting-up-test-automation)
+
+Доп. материал:
+
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/) 3.2.2. Особенности тест-кейсов в автоматизации
+* [Чистая архитектура в автотестах](https://www.youtube.com/watch?v=ZIg-yFJx2A8)
+* [Элементы хорошего автотеста](https://software-testing.ru/library/testing/testing-for-beginners/3714-what-makes-a-good-automated-test)
+* [Ловушки автоматизации (и 9 советов, как в них не попасть)](https://testengineer.ru/sovety-avtomatizacii/)
+* [7 характеристик хороших тестов](https://habr.com/ru/post/599507/)
+* [UI-автотесты: как делать не стоит](https://habr.com/ru/company/badoo/blog/419419/)
+* [7 способов повысить эффективность автоматизации тестирования в Agile разработке](https://habr.com/ru/company/otus/blog/520712/)
+* [UI-автотесты: как делать не стоит](https://habr.com/ru/company/badoo/blog/419419/)
+* [ТОП-5 вопросов начинающего автоматизатора про автотесты](https://habr.com/ru/company/hh/blog/584574/)
+* [Top 10 Test Automation Strategies And Best Practices](https://www.softwaretestinghelp.com/automation-testing-tutorial-7/)
+* [Пожалуй, лучшая архитектура для UI тестов](https://habr.com/ru/company/protei/blog/523802/)
+* [Распространенные паттерны и методологии UI-автоматизации: реальные примеры](https://telegra.ph/Rasprostranennye-patterny-i-metodologii-UI-avtomatizacii-realnye-primery-01-31)
+* [SOLID и другие принципы объектно-ориентированного проектирования в контексте автоматизации](https://www.youtube.com/watch?v=xG6NOxiOLhU)
+* [ООП, «святая троица» и SOLID: некоторый минимум знаний о них](https://habr.com/ru/post/446816/)
+* [Принцип открытости-закрытости](https://habr.com/ru/company/tinkoff/blog/472186/)
diff --git a/avtomatizaciya-beta/mutacionnoe-testirovanie-mutation-testing.md b/avtomatizaciya-beta/mutacionnoe-testirovanie-mutation-testing.md
new file mode 100644
index 0000000..735af49
--- /dev/null
+++ b/avtomatizaciya-beta/mutacionnoe-testirovanie-mutation-testing.md
@@ -0,0 +1,50 @@
+# Мутационное тестирование (Mutation testing)
+
+Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage). Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего. Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь? Ответ на этот вопрос даёт мутационное тестирование.
+
+Мутационное тестирование (MT, Mutation Testing, Mutation Analysis, Program mutation, Error-based testing, Fault-based testing strategy) - это вид тестирования ПО методом белого ящика, основанный на всевозможных изменениях (мутациях) частей исходного кода и проверке реакции на эти изменения набора автоматических юнит тестов. Изменения в мутантной программе сохраняются крайне небольшими, поэтому это не влияет на общее исполнение программы. Если тесты после изменения кода не падают (failed), значит либо этот код недостаточно покрыт тестами, либо написанные тесты бесполезны. Критерий, определяющий эффективность набора автоматических тестов, называется Mutation Score Indicator (MSI).
+
+Введем некоторые понятия из теории мутационного тестирования:
+
+Для применения этой технологии у нас, очевидно, должен быть исходный код (source code), некоторый набор тестов (для простоты будем говорить о модульных - unit tests). После этого можно начинать изменять отдельные части исходного кода и смотреть, как реагируют на это тесты. Одно изменение исходного кода будем называть Мутацией (Mutation). Например, изменение бинарного оператора "+" на бинарный "-" является мутацией кода. Результатом мутации является Мутант (Mutant) - то есть это новый мутированный код. Каждая мутация любого оператора в вашем коде (а их сотни) приводит к новому мутанту, для которого должны быть запущены тесты. Кроме изменения "+" на "-", существует множество других мутационных операторов (Mutation Operator, Mutator, faults or mutation rules), каждый из которых имеет свою цель и применение:
+
+* Мутация значений (Value mutation): изменение значения параметра или константы;
+* Мутация операторов (Statement mutation): реализуется путем редактирования, удаления или перестановки оператора;
+* Мутация решения (Decision Mutation): изменение логических, арифметических и реляционных операторов.
+
+В зависимости от результата теста мутанты делятся на:
+
+* Выжившие мутанты (Survived Mutants): мутанты, которые все еще живы, то есть не обнаруживаются при выполнении теста. Их также называют live mutants;
+* Убитые мутанты (Killed Mutants): мутанты, обнаруженные тестами;
+* Эквивалентные мутанты (Equivalent Mutants): мутанты, которые изменив части кода не привели к какому-либо фактическому изменению в выводе программы, т.е. они эквивалентны исходному коду;
+* Нет покрытия (No coverage): в этом случае мутант выжил, потому что для этого мутанта не проводились тесты. Этот мутант находится в части кода, не затронутой ни одним из ваших тестов. Это означает, что наш тестовый пример не смог его охватить;
+* Тайм-аут (Timeout): выполнение тестов с этим активным мутантом привело к тайм-ауту. Например, мутант привел к бесконечному циклу в вашем коде. Не обращайте внимание на этого мутанта. Он считается «обнаруженным». Логика здесь в том, что если этот мутант будет внедрен в ваш код, ваша CI-сборка обнаружит его, потому что тесты никогда не завершатся;
+* Ошибка выполнения (Runtime error): выполнение тестов привело к ошибке (а не к провалу теста). Это может произойти, когда средство запуска тестов не работает. Например, когда средство выполнения теста выдает ошибку OutOfMemoryError или для динамических языков, когда мутант привел к неразборчивому коду. Не тратьте слишком много внимания на этого мутанта. Он не отображается в вашей оценке мутации;
+* Ошибка компиляции (Compile error): это состояние возникает, когда это компилируемый язык. Мутант привел к ошибке компиляции. Он не отражается в оценке мутации, поэтому вам не нужно уделять слишком много внимания изучению этого мутанта;
+* Игнорируется (Ignored): мы можем видеть это состояние, когда пользователь устанавливает конфигурации для его игнорирования. Он будет отображаться в отчетах, но не повлияет на оценку мутации;
+* Тривиальные мутанты (Trivial Mutants): фактически ничего не делают. Любой тестовый пример может убить этих мутантов. Если в конце тестирования остались тестовые примеры, значит, это недопустимый мутант (invalid mutant).
+
+Метрики:
+
+* Обнаруженные (Detected): это количество мутантов, обнаруженных нашим тестом, то есть убитых мутантов. Detected = Killed mutants +Timeout;
+* Необнаруженные (Undetected): это количество мутантов, которые не были обнаружены нашим тестом, то есть выживших мутантов. Undetected = Survived mutants + No Coverage;
+* Покрытые (Covered): это количество мутантов покрытых тестами. Covered = Detected mutants + Survived mutants;
+* Действительные (Valid): это количество действительных мутантов, не вызвавших ошибки компиляции или рантайма. Valid = Detected mutants + Undetected mutants;
+* Недействительные (Invalid): это количество всех недействительных мутантов, т.е. они не могли быть протестированы, так как вызывали ошибку компиляции или выполнения. Invalid = Runtime errors + Compile errors;
+* Всего мутантов (Total mutants): содержит всех мутантов. Total = Valid + Invalid + Ignored;
+* Оценка мутации на основе покрытого кода (Mutation score based on covered code): оценивает общий процент убитых мутантов на основе покрытия кода. Mutation score based on covered code = Detected / Covered \* 100;
+* Неправильный синтаксис (Incorrect syntax): их называют мертворожденными мутантами, это представлено как синтаксическая ошибка. Обычно эти ошибки должен обнаруживать компилятор;
+* Оценка мутации (Mutation score): это оценка, основанная на количестве мутантов. В идеале равна 1 (100%). Mutation score = Detected / Valid \* 100 (%).
+
+Источники:
+
+* [Мутационное тестирование](https://habr.com/ru/post/334394/)
+* [Mutation Testing Guide: What You Should Know](https://www.softwaretestingmaterial.com/mutation-testing/)
+
+Доп. материал:
+
+* [Mutation testing](https://medium.com/@gayanper/mutation-testing-e16a5c89876e)
+* [Mutation Testing](https://testing.googleblog.com/2021/04/mutation-testing.html)
+* [What Is Mutation Testing: Tutorial With Examples](https://www.softwaretestinghelp.com/what-is-mutation-testing/)
+* [Мутанты, убийства - это о чем? О тестировании](https://testengineer.ru/mutacionnoe-testirovanie-i-kak-ego-provodit/)
+* [Изучаем mutmut - инструмент для мутационного тестирования на Python](https://habr.com/ru/company/vdsina/blog/512630/)
diff --git a/avtomatizaciya-beta/obshee.md b/avtomatizaciya-beta/obshee.md
new file mode 100644
index 0000000..d567c5f
--- /dev/null
+++ b/avtomatizaciya-beta/obshee.md
@@ -0,0 +1,201 @@
+# Общее
+
+* _Автоматизация тестирования (test automation): Использование программного обеспечения для осуществления или помощи в проведении определенных тестовых процессов, например, управление тестированием, проектирование тестов, выполнение тестов и проверка результатов. (ISTQB)_
+* _Автоматизация выполнения тестов (test execution automation): Использование программного обеспечения (например, средств захвата/воспроизведения) для контроля выполнения тестов, сравнения полученных результатов с эталонными, установки предусловий тестов и других функций контроля тестирования и организации отчетов. (ISTQB)_
+* _Автоматизированное тестирование (scripted testing): Выполнение тестов, реализуемое при помощи заранее записанной последовательности тестов. (ISTQB)_
+* _Автоматизированное тестовое обеспечение (automated testware): Тестовое обеспечение, используемое в автоматизированном тестировании, например, инструментальные сценарии. (ISTQB)_
+* _Автоматизированный сценарий тестирования (test script): Обычно используется как синоним спецификации процедуры тестирования, как правило, автоматизированной. (ISTQB)_
+
+**Автоматизированное тестирование** (automated testing, test automation) - набор техник, подходов и инструментальных средств, позволяющий исключить человека из выполнения некоторых задач в процессе тестирования.
+
+Многие задачи и действия, описанные в ИСО/МЭК/ИИЭР 29119-2 как процессы Менеджмента Тестирования и Динамического Тестирования, а также многие аспекты методов тестирования, представленные в ИСО/МЭК/ИИЭР 29119-4, могут быть автоматизированы. Автоматизация тестирования требует использования программного обеспечения, обычно называемого инструментами тестирования.
+
+**Области применения автоматизации**:
+
+* **Регрессионное тестирование**: необходимость выполнять вручную тесты, количество которых неуклонно растет с каждым билдом, но вся суть которых сводится к проверке того факта, что ранее работавшая функциональность продолжает работать корректно.
+* **Инсталляционное тестирование и настройка тестового окружения**: множество часто повторяющихся рутинных операций по проверке работы инсталлятора, размещения файлов в файловой системе, содержимого конфигурационных файлов, реестра и т.д. Подготовка приложения в заданной среде и с заданными настройками для проведения основного тестирования.
+* **Конфигурационное тестирование и тестирование совместимости**: выполнение одних и тех же тест-кейсов на большом множестве входных данных, под разными платформами и в разных условиях. Классический пример: есть файл настроек, в нём сто параметров, каждый может принимать сто значений: существует 100 100 вариантов конфигурационного файла - все их нужно проверить.
+* **Использование комбинаторных техник тестирования** (в т.ч. доменного тестирования): генерация комбинаций значений и многократное выполнение тест-кейсов с использованием этих сгенерированных комбинаций в качестве входных данных.
+* **Модульное тестирование**: проверка корректности работы атомарных участков кода и элементарных взаимодействий таких участков кода - практически невыполнимая для человека задача при условии, что нужно выполнить тысячи таких проверок и нигде не ошибиться.
+* **Интеграционное тестирование**: глубокая проверка взаимодействия компонентов в ситуации, когда человеку почти нечего наблюдать, т.к. все представляющие интерес и подвергаемые тестированию процессы проходят на уровнях более глубоких, чем пользовательский интерфейс.
+* **Тестирование безопасности**: необходимость проверки прав доступа, паролей по умолчанию, открытых портов, уязвимостей текущих версий ПО и т.д., т.е. быстрое выполнение очень большого количества проверок, в процессе которого нельзя что-то пропустить, забыть или «не так понять».
+* **Тестирование производительности**: создание нагрузки с интенсивностью и точностью, недоступной человеку. Сбор с высокой скоростью большого набора параметров работы приложения. Анализ большого объема данных из журналов работы системы автоматизации.
+* **Дымовой тест для крупных систем**: выполнение при получении каждого билда большого количества достаточно простых для автоматизации тест-кейсов.
+* **Приложения (или их части) без графического интерфейса**: проверка консольных приложений на больших наборах значений параметров командной строки (и их комбинаций). Проверка приложений и их компонентов, вообще не предназначенных для взаимодействия с человеком (веб-сервисы, серверы, библиотеки и т.д.).
+* **Длительные, рутинные, утомительные для человека и/или требующие повышенного внимания операции**: проверки, требующие сравнения больших объёмов данных, высокой точности вычислений, обработки большого количества размещенных по всему дереву каталогов файлов, ощутимо большого времени выполнения и т.д. Особенно, когда такие проверки повторяются очень часто.
+* **Проверка «внутренней функциональности» веб приложений** (ссылок, доступности страниц и т.д.): автоматизация предельно рутинных действий (например, проверить все 30’000+ ссылок на предмет того, что все они ведут на реально существующие страницы). Автоматизация здесь упрощается в силу стандартности задачи - существует много готовых решений.
+* **Стандартная, однотипная для многих проектов функциональность**: даже высокая сложность при первичной автоматизации в таком случае окупится за счёт простоты многократного использования полученных решений в разных проектах.
+* **“Технические задачи”**: проверки корректности протоколирования, работы с базами данных, корректности поиска, файловых операций, корректности форматов и содержимого генерируемых документов и т.д.
+
+**Преимущества автоматизации:**
+
+* Скорость выполнения тест-кейсов может в разы и на порядки превосходить возможности человека. Если представить, что человеку придётся вручную сверять несколько файлов размером в несколько десятков мегабайт каждый, оценка времени ручного выполнения становится пугающей: месяцы или даже годы. При этом 36 проверок, реализуемых в рамках дымового тестирования командными скриптами, выполняются менее чем за пять секунд и требуют от тестировщика только одного действия - запустить скрипт;
+* Отсутствует влияние человеческого фактора в процессе выполнения тест кейсов (усталости, невнимательности и т.д.). Продолжим пример из предыдущего пункта: какова вероятность, что человек ошибется, сравнивая (посимвольно!) даже два обычных текста размером в 100 страниц каждый? А если таких текстов 10? 20? И проверки нужно повторять раз за разом? Можно смело утверждать, что человек ошибется гарантированно. Автоматика не ошибется;
+* Средства автоматизации способны выполнить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скорости или иных факторов. И снова наш пример со сравнением больших текстов является актуальным: мы не можем позволить себе потратить годы, раз за разом выполняя крайне сложную рутинную операцию, в которой мы к тому же будем гарантированно допускать ошибки. Другим прекрасным примером непосильных для человека тест-кейсов является исследование производительности, в рамках которого необходимо с высокой скоростью выполнять определённые действия, а также фиксировать значения широкого набора параметров. Сможет ли человек, например, сто раз в секунду измерять и записывать объем оперативной памяти, занимаемой приложением? Нет. Автоматика сможет;
+* Средства автоматизации способны собирать, сохранять, анализировать, агрегировать и представлять в удобной для восприятия человеком форме колоссальные объемы данных. В нашем примере с дымовым тестированием «Конвертера файлов» объем данных, полученный в результате тестирования, невелик - его вполне можно обработать вручную. Но если обратиться к реальным проектным ситуациям, журналы работы систем автоматизированного тестирования могут занимать десятки гигабайт по каждой итерации. Логично, что человек не в состоянии вручную проанализировать такие объёмы данных, но правильно настроенная среда автоматизации сделает это сама, предоставив на выход аккуратные отчеты в 2-3 страницы, удобные графики и таблицы, а также возможность погружаться в детали, переходя от агрегированных данных к подробностям, если в этом возникнет необходимость;
+* Средства автоматизации способны выполнять низкоуровневые действия с приложением, операционной системой, каналами передачи данных и т.д. В одном из предыдущих пунктов мы упоминали такую задачу, как «сто раз в секунду измерить и записать объем оперативной памяти, занимаемой приложением». Подобная задача сбора информации об используемых приложением ресурсах является классическим примером. Однако средства автоматизации могут не только собирать подобную информацию, но и воздействовать на среду исполнения приложения или само приложение, эмулируя типичные события (например, нехватку оперативной памяти или процессорного времени) и фиксируя реакцию приложения. Даже если у тестировщика будет достаточно квалификации, чтобы самостоятельно выполнить подобные операции, ему всё равно понадобится то или иное инструментальное средство - так почему не решить эту задачу сразу на уровне автоматизации тестирования?
+
+**Недостатки автоматизации:**
+
+* Необходимость наличия высококвалифицированного персонала в силу того факта, что автоматизация - это «проект внутри проекта» (со своими требованиями, планами, кодом и т.д.). Даже если забыть на мгновение про «проект внутри проекта», техническая квалификация сотрудников, занимающихся автоматизацией, как правило, должна быть ощутимо выше, чем у их коллег, занимающихся ручным тестированием.
+* Разработка и сопровождение как самих автоматизированных тест-кейсов, так и всей необходимой инфраструктуры занимает очень много времени. Ситуация усугубляется тем, что в некоторых случаях (при серьёзных изменениях в проекте или в случае ошибок в стратегии) всю соответствующую работу приходится выполнять заново с нуля: в случае ощутимого изменения требований, смены технологического домена, переработки интерфейсов (как пользовательских, так и программных) многие тест-кейсы становятся безнадежно устаревшими и требуют создания заново.
+* Автоматизация требует более тщательного планирования и управления рисками, т.к. в противном случае проекту может быть нанесен серьезный ущерб (см. предыдущий пункт про переделку с нуля всех наработок).
+* Коммерческие средства автоматизации стоят ощутимо дорого, а имеющиеся бесплатные аналоги не всегда позволяют эффективно решать поставленные задачи. И здесь мы снова вынуждены вернуться к вопросу ошибок в планировании: если изначально набор технологий и средств автоматизации был выбран неверно, придётся не только переделывать всю работу, но и покупать новые средства автоматизации.
+* Средств автоматизации крайне много, что усложняет проблему выбора того или иного средства, затрудняет планирование и определение стратегии тестирования, может повлечь за собой дополнительные временные и финансовые затраты, а также необходимость обучения персонала или найма соответствующих специалистов.
+
+Исходя из вышеперечисленного, существуют\*\* случаи, в которых автоматизация, скорее всего, приведёт только к ухудшению ситуации\*\*. Вкратце - это все те области, где требуется человеческое мышление, а также некоторый перечень технологических областей:
+
+* Планирование, разработка тест-кейсов, написание отчетов о дефектах, анализ результатов тестирования и отчётность: компьютер пока не научился думать;
+* Функциональность, которую нужно (достаточно) проверить всего несколько раз, тест-кейсы, которые нужно выполнить всего несколько раз (если человек может их выполнить): затраты на автоматизацию не окупятся;
+* Низкий уровень абстракции в имеющихся инструментах автоматизации: придётся писать очень много кода, что не только сложно и долго, но и приводит к появлению множества ошибок в самих тест-кейсах.
+* Слабые возможности средства автоматизации по протоколированию процесса тестирования и сбору технических данных о приложении и окружении: есть риск получить данные в виде «что-то где-то сломалось», что не помогает в диагностике проблемы.
+* Низкая стабильность требований: придётся очень многое переделывать, что в случае автоматизации обходится дороже, чем в случае ручного тестирования.
+* Сложные комбинации большого количества технологий: высокая сложность автоматизации, низкая надёжность тест-кейсов, высокая сложность оценки трудозатрат и прогнозирования рисков.
+* Проблемы с планированием и ручным тестированием: автоматизация хаоса приводит к появлению автоматизированного хаоса, но при этом ещё и требует трудозатрат. Сначала стоит решить имеющиеся проблемы, а потом включаться в автоматизацию.
+* Нехватка времени и угроза срыва сроков: автоматизация не приносит мгновенных результатов. Поначалу она лишь потребляет ресурсы команды (в том числе время). Также есть универсальный афоризм: «лучше руками протестировать хоть что-то, чем автоматизированно протестировать ничего».
+* Области тестирования, требующие оценки ситуации человеком (тестирование удобства использования, тестирование доступности и т.д.): в принципе, можно разработать некие алгоритмы, оценивающие ситуацию так, как её мог бы оценить человек. Но на практике живой человек может сделать это быстрее, проще, надёжнее и дешевле.
+
+Далее копипаста различных вопросов-ответов из цикла статей на хабре.
+
+**Зачем нужна автоматизация, если наши ручные тестировщики и так справляются?**
+
+Действительно, прежде чем вводить автоматизацию на проекте, потому что это “стильно, модно, молодежно”, и у всех оно есть, стоит учесть следующие факторы:
+
+* Как долго будет жить проект, каков его масштаб, насколько сильно и часто он меняется;
+* Оценить, насколько трудозатратно будет писать автотесты в каждом конкретном случае. Возможно, что автоматизировать ваш функционал будет гораздо сложнее, дольше и дороже, чем тестировать его руками;
+* Также, если на проекте ожидается “выпиливаем всё старое и пишем новое с нуля”, время автотестов еще не пришло.
+
+Но если ваш проект:
+
+* стабильно развивается и растет;
+* увеличивается количество разработчиков;
+* приложение начинает обрастать новым функционалом.
+
+То прямо пропорционально начнет увеличиваться и время тестирования. Рано или поздно оно дойдет до критического момента, когда регресс будет занимать больше времени, чем велась разработка. Это значит, что пришло время задуматься об автоматизации тестирования.
+
+Автотесты станут гарантией, что ничего из старого не отвалилось, пока разработчики делали новые крутые штуки. Особенно, если эти новые штуки делались в совершенно других частях кода. Ручные регрессы, в данном случае, это, конечно, хорошо, но тут и человеческий фактор, и замыленный глаз, и непредсказуемость мест, в которых могут всплыть баги.При этом ручное тестирование полностью никуда не уходит, так как новый функционал все еще будет проверяться руками. Нет смысла автоматизировать то, что возможно не взлетит и уже через неделю будет выпилено или отправлено на доработки.
+
+Но вместо того, чтобы занимать ручного тестировщика написанием тест-кейсов на новый функционал, поддержку документации и постоянными регрессами, можно выделить ему хотя бы один день в неделю на автоматизацию, помочь на старте с настройками инфраструктуры, и уже через несколько месяцев у вас начнут гонять первые автотесты, ваши задачи станут в разы быстрее доходить до релизов а заодно станет больше уверенности в стабильности выпускаемого кода.
+
+Еще автоматизированный регресс позволяет тестировщикам больше времени уделять полезным задачам, например, исследовательскому тестированию. Кроме того, появится лучшее понимание, как работает приложение под капотом, что точно пригодится даже в ручном тестировании.
+
+**Можно ли начать писать автотесты за один день?**
+
+Писать автотесты можно начать прямо в этот самый момент, но лучше с этим не торопиться и подойти к вопросу осмысленно.
+
+Если на проекте еще не было автоматизации, то нужно обязательно начать с ресерча существующих инструментов, фреймворков, подходов. Почитать о том, с какими проблемами сталкиваются пользователи, и как быстро они решаются. Оценить все плюсы и минусы, выбрать самое подходящее, с чем будет легко и приятно работать. Цена ошибки на старте намного меньше, чем когда вы уже активно автоматизируете и вдруг понимаете, что выбранный вами фреймворк никому не удобен и совершенно вам не подходит.
+
+Если вы никогда раньше не занимались автотестами, первое время может быть сложно.. Непросто начать писать автотесты сразу, если еще нет никаких примеров и не на что опереться. Благо, сейчас в интернете очень много различных статей с массой хороших примеров кода, которые можно брать, подстраивать под себя и разбираться, как они работают.
+
+В конце концов, чтобы научиться автоматизировать, надо просто начать автоматизировать. Это действительно работает.
+
+Идеально, если со стороны разработчиков будут те, кто готов на первых порах вам помогать разбираться в коде, отвечать на все ваши вопросы. В hh именно так и было - первое время, когда мы только начинали писать свои первые автотесты, мы просто заваливали наших ребят всевозможными вопросами. Благодаря им мы и пришли к тому, что имеем сегодня
+
+Но вполне возможно, что у вашей команды не будет времени помогать вам с автотестами. К сожалению, такое возможно, и не стоит их за это винить. Если вы попали в такую ситуацию, не отчаивайтесь! В интернете очень мощное комьюнити тестировщиков. В том же самом телеграме есть чаты, где 24/7 вам ответят на все вопросы и помогут разобраться.
+
+**Можно ли заставить разработчиков писать автотесты?**
+
+В теории, конечно можно. Но скорее всего они будут не сильно этому рады, да и вряд ли кто-то будет рад в принципе.
+
+Во-первых, это замедлит саму разработку. Вместо того, чтобы писать код, разрабатывать продуктовый функционал, разработчики будут заниматься написанием автотестов.
+
+Во-вторых, это дорого.
+
+Ну и в-третьих, у каждого должна быть своя зона ответственности. Разработчики создают функционал, тестировщики - его проверяют. С автотестами все точно так же, как и в обычном тестировании. Вот юнит-тесты - да, зона ответственности разработчиков, но UI - это уже тестировщеское.
+
+По факту, этот вопрос равен “Зачем нам тестировщики, если можно попросить разработчиков самим проверять то, что они написали?”.
+
+**Не замедляют ли автотесты разработку?**
+
+Начнем с того, что в первую очередь автотесты мощно сокращают время на тестирование и регрессы, а значит помогают выпускать фичи в релизы быстрее.
+
+Но, действительно, иногда они увеличивают время разработки. Например, когда разработчик меняет покрытый автотестами функционал, в связи с чем приходится перед мержем своего кода править падающие автотесты.
+
+Чтобы это не становилось проблемой, при оценке и декомпозиции задачи нужно закладывать время на возможные фиксы автотестов. В идеале на таких встречах должен присутствовать тестировщик, который сможет сказать, какие автотесты могут быть затронуты новым функционалом. Тогда время задачи будет предсказуемым и не увеличится.
+
+Но чтобы это нормально работало, нужно, чтобы на проекте была стабильная инфраструктура, и автотесты падали по понятным причинам. Тогда разработчикам не придется тратить свое драгоценное время, чтобы в каждой задаче разбираться, из-за чего именно упал автотест - из-за его кода или из-за проблем на тестовом стенде.
+
+**Можно ли писать 1 автотест сразу на обе платформы?**
+
+Конечно, можно. Существуют кроссплатформенные фреймворки, и многие их используют. Но мы сразу выбрали для себя нативные, как более стабильные, надежные и легко поддерживаемые.
+
+В чем главные проблемы кроссплатформенных фреймворков?
+
+Это отдельно живущий от вашего приложения код. Если вам понадобится в нем что-то доработать или настроить под себя, то придется идти к другим разработчикам, делать запросы и ждать, пока они сделают и выпустят это на своей стороне, что не всегда удобно и продуктивно. Частые проблемы при выходе новых ОС и баги. Нужно ждать поддержку со стороны разработчиков фреймворка, и это ожидание весьма непредсказуемое. Вы не знаете, когда всё поправят и оптимизируют, и когда оно у вас наконец заработает. То есть вы зависимы от других людей. Возможно, выбранный вами кроссплатформенный фреймворк написан на языке программирования, который не знаком вашим разработчикам. Тогда помощь от них будет получить сложнее, если она вам вдруг понадобится. Также разработчики в этом случае не смогут писать и править автотесты самостоятельно.
+
+Может показаться, что написать один кроссплатформенный автотест быстрее и проще, чем два нативных. Но на самом деле это не так.
+
+Во-первых, всё “сэкономленное” время в последствии может уйти на поддержку такого автотеста для двух платформ. Это может стать проблемой из-за обновляемой специфики разных ОС. Кроме того, часто поведение одной и той же фичи или кнопки может различаться для iOS и Android.
+
+Во-вторых, если при выборе между кроссплатформенным фреймворком и нативными, главным аргументом является “выучить один язык программирования проще, чем два”, не спешите принимать решение. Синтаксис языков Kotlin и Swift очень похожи (по-крайней мере, в вопросах написания автотестов). Написав автотест на одном из языков, вы без труда напишете точно такой же для второй платформы.
+
+**Когда автотесты начнут приносить больше пользы, чем проблем?**
+
+Ровно тогда, когда:
+
+* на вашем проекте будет настроена стабильная инфраструктура,
+* автотесты будут встроены в ваш CI/CD, а не запускаться локально у кого-то, когда об их существовании вспомнили,
+* автотесты будут падать приемлемое для вас количество раз, то есть не будут флаковать.
+
+Даже если тестов совсем немного, но они уже гоняются хотя бы перед мержем ветки разработчика, то это уже польза: минус какое-то количество ручных проверок и гарантия того, что ваше приложение как минимум запускается.
+
+**За сколько месяцев можно прийти к 100% покрытию?**
+
+Вопрос 100% покрытия - очень скользкий. Не хочется вдаваться в бесполезные споры о том, существует ли оно вообще и нужно ли к нему стремиться. Но поскольку его задают очень часто, давайте разбираться.
+
+Во-первых, стоит рассматривать покрытие каждой фичи отдельно.
+
+Во-вторых, глобально ответ на вопрос “на сколько у тебя покрыта эта фича” будет основываться на опыте и знании продукта тестировщика.
+
+Оценивая покрытие фичи, я рассуждаю следующим образом:
+
+все позитивные проверки - это 60-70% от всего покрытия,
+
+далее добавляем негативные проверки (всевозможные прерывания, сворачивания-разворачивания экранов, зероскрины и т.п.) - получаем 90%.
+
+Оставшиеся 10% - это сложновоспроизводимые сценарии, зависимости от других фичей и т.д., которые покрывать либо вообще не стоит (подумайте, выдержит ли такую нагрузку ваш CI и стоит ли того время на поддержку таких автотестов), либо оставлять это на самую последнюю очередь. Также добавлю, что не все фичи в принципе нужно автоматизировать. Иногда трудозатраты на автоматизацию какой-то невероятно сложной проверки сильно преувеличивают возможность один раз перед релизом быстро проверить ее руками. Чтобы не оставлять вопрос менеджера без ответа - выявляем среди всей функциональности приложения наиболее критичный и в нём смотрим, какое количество позитивных и негативных проверок нам нужно автоматизировать в первую очередь, чтобы быть уверенными, что функционал работает. Далее смотрим какое количество тестировщиков сколько времени готовы уделять автоматизации и считаем, как долго мы будем это автоматизировать.
+
+**Сколько нужно тестировщиков, чтобы автоматизировать весь проект?**
+
+Расскажу историю об автоматизации мобильных приложений в hh.ru.
+
+В разные периоды времени у нас было от 2 до 4 тестировщиков на всё мобильное направление. Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк. В итоге, кстати, мы остановились на Kaspresso, с которым тесты стали сильно стабильнее и проще в написании. Каждый переезд был большим объемным рефакторингом, так как до этого мы уже успели написать какое-то значительное количество автотестов. Но тем не менее, за один год регрессы были автоматизированы.
+
+Иными словами, любым количеством тестировщиков можно автоматизировать проект, если выделить на это достаточно времени. Но возникает вопрос: как тестировщику успевать и руками тестировать, и автотесты писать? Иногда это действительно сложно. Особенно если идет большой поток нового функционала, который срочно нужно тестировать. Всем хочется успеть в релиз, и задачам ставят больший приоритет. Знакомая ситуация. Что делать? Садимся. Понимаем, что автотесты в недалеком будущем принесут нам максимум пользы и выделяем каждому тестировщику, например, один день в неделю под автоматизацию. Мы такое практикуем, когда у тестировщиков завал с ручным тестированием, и это работает. Для автоматизации можно выбрать день после релиза, когда уже ничего не горит, и тестировщик с чистой совестью может писать автотесты, не отвлекаясь на другие задачи.
+
+**Как вам живется с автоматизированными регрессами?**
+
+За два года, что мы живем с автоматизированным регрессом, у нас надежно устаканился недельный релиз-трейн. Релизы регулярно отправляются в прод без проведения ручных регрессов благодаря количеству, качеству и, главное, доверию к автотестам.
+
+Помимо того, что автотесты запускаются на релизных ветках, весь набор автотестов всегда прогоняется на фиче-ветках разработчиков перед мерджем. В девелоп/мастер не допускается код, который уронил тесты. Благодаря этому мы поддерживаем стабильность девелопа, мы уверены в нем и можем отрезать релизную ветку в любой момент.
+
+Для тестировщика автоматизированный регресс может означать больше свободного времени для более важных и полезных задач - это, например, написание новых автотестов, увеличение стабильности существующих, развитие своего направления и тому подобные крутые задачи.
+
+**Много ли времени уходит на поддержку автотестов?**
+
+Поддержка автотестов встроена в наши процессы разработки. Как это работает - каждую неделю назначается дежурный тестировщик, одной из задач которого является следить за стабильностью тестов. Если тест упал, дежурный должен разобраться в причине падения и назначить ответственного на фикс. Если тест упал из-за собственной нестабильности - задача на тестировщика, если тест нашел баг - на разработчика, код которого повлиял на этот автотест. По опыту, чаще всего это не занимает много времени - один тестировщик тратит несколько часов за неделю.
+
+Более сложные задачи - развитие, улучшение и оптимизация, фиксы инфраструктуры. Такие задачи идут наравне с разработкой продуктового функционала и имеют соответствующий флоу (проработка, декомпозиция, оценка, разработка и тд). Это случается не слишком часто, в среднем раз в квартал на каждую платформу. Тут важно отметить, что чаще всего это не самые высокоприоритетные задачи, и делаются они, когда у команды появляется на это ресурс.
+
+Если всё четко настроить, научиться работать с флакующими тестами и по-максимуму их не допускать, то поддержка автотестов занимает мало времени и приносит много пользы.
+
+**Насколько сложно найти мобильного автоматизатора?**
+
+Порой сложно найти просто хорошего мобильного тестировщика с релевантным опытом, а с опытом автоматизации в конкретном стеке технологий дела обстоят еще сложнее.
+
+В мобильные команды hh.ru мы обычно ищем просто крутых ручных тестировщиков, которые хотят развиваться в сторону автоматизации. Во время собеседований базовые знания в программировании, конечно, являются плюсом, но не решающим фактором. Автоматизации мы готовы обучать у себя. А вот что действительно важно - чтобы человек стремился развиваться, умел и хотел обучаться и был проактивным в этих моментах. Конечно, сложно точно определить такое во время собеседований, но и не совсем невозможно.
+
+Источники:
+
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). Раздел 3: Автоматизация тестирования
+* [ТОП-5 вопросов ручных тестировщиков про автоматизацию](https://habr.com/ru/company/hh/blog/575390/)
+* [ТОП-5 вопросов менеджера про автоматизацию](https://habr.com/ru/company/hh/blog/577664/)
+* [ТОП-5 вопросов технического директора про автоматизацию](https://habr.com/ru/company/hh/blog/582968/)
+
+Доп. материал:
+
+* [Введение в автоматизированное тестирование](https://www.youtube.com/watch?v=YLEhKE4vdHw)
+* [10 Tips You Should Read Before Automating Your Testing Work](https://www.softwaretestinghelp.com/10-tips-you-should-read-before-automating-your-testing-work/)
+* [Manual And Automation Testing Challenges](https://www.softwaretestinghelp.com/manual-and-automation-testing-challenges/)
+* [How To Translate Manual Test Cases Into Automation Scripts? - A Step By Step Guide With Example](https://www.softwaretestinghelp.com/how-to-translate-manual-test-cases-into-automation-scripts/)
+* [Test Automation - Is It A Specialized Career? Can Normal Testers Do Automation Also?](https://www.softwaretestinghelp.com/test-automation-specialized-career/)
diff --git a/avtomatizaciya-beta/parallelnoe-testirovanie-parallel-testing.md b/avtomatizaciya-beta/parallelnoe-testirovanie-parallel-testing.md
new file mode 100644
index 0000000..5451932
--- /dev/null
+++ b/avtomatizaciya-beta/parallelnoe-testirovanie-parallel-testing.md
@@ -0,0 +1,19 @@
+# Параллельное тестирование (Parallel testing)
+
+Обычно большинство команд тестирования выполняют свои тесты по одному. Этот процесс называется последовательным тестированием или серийным тестированием (sequential testing or serial testing). В процессе последовательного тестирования каждый тестовый пример запускается один за другим и следующий тест не начинается, пока не завершится предыдущий. Последовательный процесс тестирования требует много времени, усилий и ресурсов. Чтобы выпускать качественные продукты в кратчайшие сроки, более эффективным будет параллельное тестирование.
+
+Параллельное тестирование включает в себя в основном автоматизированное тестирование нескольких версий одного и того же приложения или разных компонентов приложения одновременно и с одинаковыми входными данными, чтобы сократить общее время выполнения теста путем интеграции фреймворка автоматизации с облачными решениями и виртуализацией.
+
+
+
+Пример: когда какая-либо организация переходит от старой системы к новой, legacy является важной частью. Передача этих данных является сложным процессом. При тестировании программного обеспечения проверка совместимости вновь разработанной системы со старой системой осуществляется посредством «параллельного тестирования».
+
+Источники:
+
+* [Parallel Testing Guide: How To Perform Parallel Testing](https://www.softwaretestingmaterial.com/parallel-testing/)
+* [What is Parallel Testing? Definition, Approach, Example](https://www.guru99.com/parallel-testing.html)
+
+Доп. материал:
+
+* [Parallel testing: get feedback earlier, release faster](https://medium.com/azimolabs/parallel-testing-get-feedback-earlier-release-faster-b66d4dd08930)
+* [What Is Parallel Testing And Why Is It Important?](https://www.lambdatest.com/blog/what-is-parallel-testing-and-why-to-adopt-it/)
diff --git a/avtomatizaciya-beta/podkozhnyi-test-subcutaneous-test.md b/avtomatizaciya-beta/podkozhnyi-test-subcutaneous-test.md
new file mode 100644
index 0000000..3da73c1
--- /dev/null
+++ b/avtomatizaciya-beta/podkozhnyi-test-subcutaneous-test.md
@@ -0,0 +1,34 @@
+# Подкожный тест (Subcutaneous test)
+
+Впервые упоминание встречается в 2010 году у Jimmy Bougard в [блоге](https://lostechies.com/jimmybogard/2010/08/25/an-effective-testing-strategy/): ”В то время как модульный тест фокусируется на мелкомасштабном дизайне, подкожный тест не касается дизайна, а вместо этого проверяет основные входы и выходы системы в целом”, затем в докладе Matt Davies and Rob Moore - “[Microtesting - How We Set Fire To The Testing Pyramid While Ensuring Confidence](https://www.youtube.com/watch?v=pls1Vk\_bw\_Y\&ab\_channel=NDCConferences)”, а позже и в презентации Daniel Lafeir and Michael Lawrie. Термин «подкожный» означает автоматизированный тест непосредственно под слоем пользовательского интерфейса. В приложении MVC это будут тесты для всего, что находится непосредственно под контроллером. Для веб-службы все, что находится ниже ендпоинта (endpoint).
+
+Идея состоит в том, что самый верхний уровень в приложении не выполняет никакой реальной бизнес-логики, а просто соединяет внешние интерфейсы с базовыми службами. Как подчеркивает Martin Fowler[ в своем сообщении о подкожном тестировании](https://martinfowler.com/bliki/SubcutaneousTest.html), такие тесты особенно полезны при попытке выполнить функциональные тесты, когда вы хотите реализовать сквозной сценарий, избегая при этом некоторых трудностей, связанных с тестированием через сам пользовательский интерфейс:
+
+* UI-тесты медленные. От этого никуда не деться. Их можно запускать параллельно, допиливать напильником и делать чуть-чуть быстрее, но они останутся медленными;
+* UI-тесты нестабильные. Отчасти потому, что они медленные. А еще потому, что Web-браузер и интерфейс пользователя не были созданы для того, чтобы ими управлял компьютер (в настоящее время данный тренд меняется, но не факт, что это хорошо);
+* UI-тесты - это наиболее сложные тесты в написании и поддержке. Они просто тестируют слишком много. (Это усиливается тем фактом, что, зачастую, люди берут «ручные» тест-кейсы и начинают их автоматизировать как есть, без учета разницы в ручном и автоматическом тестировании);
+* Нам говорят, что, якобы, UI-тесты эмулируют реального пользователя. Это не так. Пользователь не будет искать элемент на странице по ID или XPath локатору. Пользователь не заполняет форму со скоростью света, и не «упадет» если какой-то элемент страницы не будет доступен в какую-то конкретную миллисекунду. И даже теперь, когда браузеры разрабатываются с учетом того, что браузером можно программно управлять - это всего-лишь эмуляция, даже если очень хорошая;
+* Кто-то скажет, что некоторый функционал просто нельзя протестировать иначе. Я скажу, что если есть функционал, который можно протестировать только UI тестами (за исключением самой UI логики) - это может быть хорошим признаком архитектурных проблем в продукте.
+
+Таким образом определение можно сформулировать так: “Если модульный тест тестирует наименьший тестируемый компонент кода приложения, то подкожный тест представляет собой единый рабочий процесс (workflow), который можно идентифицировать и протестировать в коде приложения. Подкожное тестирование рассматривает рабочий процесс как тестируемую единицу”.
+
+Стоит помнить, что это не прямая замена автоматизации тестирования через UI, а просто более целенаправленное тестирование функциональности на нужном уровне приложения. Это позволяет команде создавать более совершенные сквозные тесты с использованием существующего кода, фреймворка и / или библиотек, доступных для внешнего приложения. Основная цель этого вида тестирования - уменьшить нестабильность теста и сосредоточиться на функциональности. Это позволяет группе различать функциональные сбои из-за проблем с кодом и сбои приложений из-за проблем совместимости или проблем с внешними зависимостями. Поскольку подкожные тесты можно запускать с той же тестовой средой, что и модульные тесты, они не имеют доступа к внутреннему коду или вызовам API во время работы. Изоляция этих тестов и использование имитирующих инструментов, которые могут имитировать вызовы API и заглушки для различных взаимодействий служб, могут дать целенаправленную, изолированную оценку функциональности во внешнем стеке. Такое тестирование функциональности позволяет сделать любую автоматизацию через браузер и пользовательский интерфейс более легкими. Это означает, что традиционные тесты пользовательского интерфейса могут быть очень минимальными и проверять только то, что связи работают между уровнями приложения. Вместо использования дорогостоящих тестов графического интерфейса и пользовательского интерфейса для получения информации о функциональности они могут быть поверхностными проверками работоспособности или дымовыми тестами. Избегая использования автоматизации пользовательского интерфейса, утверждающей ожидание чего-то функционально работающего, тесты могут утверждать, правильно ли приложение обменивается данными на своих уровнях интеграции.
+
+Поскольку при подкожном тестировании используются все компоненты на странице, создание интегрированных тестов, которые тестируют только несколько компонентов, или тестирование одного компонента на уровне модуля может не потребоваться. Модульные тесты могут быть нацелены на более сложную логику, а не пытаться протестировать всю логику вокруг одного компонента, тестирование базовой логики облегчает нагрузку на модульное тестирование. Подкожное тестирование использует ту же структуру тестирования (например, Jest), что и модульные тесты. Это сохраняет функциональные тесты внутренними и ближе к коду, что дает команде больше шансов на более быструю обратную связь и более быструю настройку теста, чем тестовая среда, поддерживаемая отдельно. Это означает, что командам не нужно выполнять дополнительную работу по сопровождению нескольких фреймворков, репозиториев, а иногда и языков для выполнения функционального тестирования пользовательского интерфейса. Теперь, когда подкожное тестирование позволяет проводить функциональное тестирование кода, а не через пользовательский интерфейс, любые тесты пользовательского интерфейса могут быть сокращены до небольшой части того, что было необходимо ранее. UI-тесты можно использовать как дымовые тесты. Таким образом они могут доказать, что приложение и все его уровни находятся в работоспособном состоянии связи.
+
+Поскольку подкожные тесты ориентированы на поведение высокого уровня (high-level behavior), а не на дизайн, они идеально подходят для стратегий тестирования на основе сценариев (scenario-based testing strategies), таких как BDD или паттерн [Testcase Class per Fixture](http://xunitpatterns.com/Testcase%20Class%20per%20Fixture.html).
+
+К сожалению, наряду со всеми плюсами subcutaneous подхода мы можем получить и снижение покрытия (coverage), в частности glue code ([Связующий код](https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D1%83%D1%8E%D1%89%D0%B8%D0%B9\_%D0%BA%D0%BE%D0%B4) - программный код, который служит исключительно для «склеивания» разных частей кода, и при этом не реализует сам по себе никакую иную прикладную функцию). Насколько важна\существенна потеря покрытия в данном случае? Зависит от ситуации. Мы потеряли немного glue code, который может быть (а может и не быть) важным (рекомендую в качестве упражнения определить, какой код потерялся). Оправдывает ли данная потеря покрытия введения тяжеловесного тестирования на уровне UI? Это тоже зависит от ситуации. Мы можем, например:
+
+* Добавить один UI-тест для проверки glue code, или
+* Если мы не ожидаем частых изменений glue code - оставить его без автотестов, или
+* Если у нас есть какой-то объем «ручного» тестирования - есть отличный шанс, что проблемы с glue code будут замечены тестировщиком, или
+* Придумать что-то еще (тот же канареечный релиз, Canary deployment)
+
+Один из способов избежать потери покрытия - “[Feature Tests Model](https://senpay.github.io/ta/ftm/feature\_tests)”
+
+Источники:
+
+* [Introduction To Subcutaneous Testing](https://www.ministryoftesting.com/dojo/lessons/introduction-to-subcutaneous-testing)
+* [Пишем автотесты эффективно - Subcutaneous tests](https://habr.com/ru/post/502154/) + [англ. версия](https://alexspush.medium.com/an-alternative-to-ubiquitous-ui-level-checking-subcutaneous-tests-8d29e8883fc2) + [видеоверсия](https://www.youtube.com/watch?v=96fL7pM3gYE\&ab\_channel=iTechArt)
+* [Subcutaneous Testing in ASP.NET Core](https://josephwoodward.co.uk/2019/03/subcutaneous-testing-asp-net-core)
diff --git a/avtomatizaciya-beta/poleznye-ssylki.md b/avtomatizaciya-beta/poleznye-ssylki.md
new file mode 100644
index 0000000..059bdb2
--- /dev/null
+++ b/avtomatizaciya-beta/poleznye-ssylki.md
@@ -0,0 +1,74 @@
+# Полезные ссылки
+
+**Telegram**
+
+* [Подборка сообществ в помощь QA automation инженеру](https://t.me/qa\_automation/72650)
+* Большая подборка чатов @[it\_chats](https://t.me/it\_chats)
+* [Чат для студентов БЕСПЛАТНОЙ ШКОЛЫ QA automation для всех](https://t.me/qadlyavsex) + [F.A.Q.](https://docs.google.com/spreadsheets/d/1-gvkhk4HcDlstBDewwjH5bXon4rxW3KCDLs6C9bxJg4/edit#gid=0)
+* Чат для начинающих автоматизаторов @[aqa\_chatka](https://t.me/aqa\_chatka)
+
+**Репозитории**
+
+* [Awesome Selenium](https://github.com/christian-bromann/awesome-selenium#readme)
+* [Awesome Appium](https://github.com/SrinivasanTarget/awesome-appium#readme)
+* [Awesome Visual Regression Testing](https://github.com/mojoaxel/awesome-regression-testing#readme)
+* [Awesome JMeter](https://github.com/aliesbelik/awesome-jmeter#readme)
+* [Awesome k6](https://github.com/grafana/awesome-k6#readme)
+* [Awesome Playwright](https://github.com/mxschmitt/awesome-playwright#readme)
+* [Awesome Gatling](https://github.com/aliesbelik/awesome-gatling#readme)
+* [Awesome JMeter](https://github.com/aliesbelik/awesome-jmeter#readme)
+* [10 интересных репозиториев на GitHub, полезных любому разработчику](https://habr.com/ru/company/plarium/blog/496472/)
+
+**Youtube**
+
+* [Eugene Suleimanov](https://www.youtube.com/c/EugeneSuleimanov/featured)
+* [alishev](https://www.youtube.com/c/alishevN)
+* [Тестировщик](https://www.youtube.com/c/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D1%89%D0%B8%D0%BA/featured)
+* [Антон Семенченко](https://www.youtube.com/results?search\_query=%D0%90%D0%BD%D1%82%D0%BE%D0%BD+%D0%A1%D0%B5%D0%BC%D0%B5%D0%BD%D1%87%D0%B5%D0%BD%D0%BA%D0%BE)
+* [dmdev](https://www.youtube.com/c/dmdev)
+* [Лёша Маршал](https://www.youtube.com/channel/UCTVciJQp8eYwKLLQIl-iSJw)
+* [SDET- QA Automation Techie](https://www.youtube.com/c/pavanoltraining)
+* [Автоматизация CI/CD - Полный Курс на Простом Языке](https://www.youtube.com/watch?v=cyb10iplv7U)
+* [Плейлист “Автоматизация с нуля”](https://www.youtube.com/playlist?list=PLWKsep\_LKQYq\_QRa4ROEjLse7jDbiSl-H)
+* [Плейлист “Python - Starter](https://www.youtube.com/playlist?list=PLvItDmb0sZw8RfG5odrtstiYkmiPg\_Yo\_)”
+* [Плейлист Курс программирования - "Python Essential"](https://www.youtube.com/playlist?list=PLvItDmb0sZw\_MVK2txwtBSHAzaYRrOdiJ)
+* [Плейлист “Вебинары Python”](https://www.youtube.com/playlist?list=PLvItDmb0sZw\_x1QivR1pTQ6tAK8Awb57L)
+* [Плейлист “Практики и инструменты DevOps”](https://www.youtube.com/playlist?list=PLvItDmb0sZw\_xTNDv8Bb1fsivN\_Z\_4oo9)
+* [Годные туториалы на YouTube](https://habr.com/ru/company/edison/blog/434034/)
+
+**Курсы**
+
+* [Лекции от Всеволода Брекелова](https://github.com/volekerb/testing-lectures/tree/master/lectures\_v\_2021)
+* [Питонтьютор - бесплатный курс по программированию с нуля на Python](http://pythontutor.ru)
+* [Программирование на Python](https://stepik.org/course/67/info)
+* [Python: основы и применение](https://stepik.org/course/512/info)
+* [Автоматизация тестирования с помощью Selenium и Python](https://stepik.org/course/575/info)
+* [Бесплатный курс “Введение в программирование”](https://ru.hexlet.io/courses/introduction\_to\_programming)
+* [Test Automation University](https://testautomationu.applitools.com)
+* [Continuous Integration with Jenkins](https://learn.epam.com/detailsPage?id=62dc3947-e941-4c30-ba32-552eb363978e)
+* [Автоматизированное тестирование с нуля / Полный курс за 3 часа / selenium + testng](https://www.youtube.com/watch?v=L2jMIJy0u90)
+* [Python за месяц](https://habr.com/ru/company/edison/blog/474212/)
+* [Как научиться разработке на Python: новый видеокурс Яндекса](https://habr.com/ru/company/yandex/blog/498856/)
+* [Python.org рекомендует: Программирование для НЕпрограммистов](https://habr.com/ru/company/skillfactory/blog/480898/)
+
+**Сборники материалов по автоматизации**
+
+* [What Is Automation Testing (Ultimate Guide To Start Test Automation)](https://www.softwaretestinghelp.com/automation-testing-tutorial-1/)
+
+**Книги**
+
+* Swaroop Chitlur - A Byte of Python (есть в переводе)
+* [Цикл статей с переводом Okken Brian - Python Testing with pytest](https://habr.com/ru/post/448782/)
+* [Топ-10 книг для разработчика](https://habr.com/ru/post/504276/)
+
+**Площадки для тренировки**
+
+* [Лучшие сайты для практики автоматизации тестирования](https://habr.com/ru/post/549450/)
+* [Сайты-песочницы, на которых можно практиковать написание автотестов](https://blog.noveogroup.ru/2020/01/testovye-ploschadki-dlya-trenirovok/)
+* [Skillotron QA Auto Tests](https://skillotron.com/qualifications/qa-automation)
+* [https://academybugs.com/find-bugs/](https://academybugs.com/find-bugs/)
+* [Selenium Certification Training](https://demoqa.com)
+* [Codewars](https://www.codewars.com), [HackerRank](https://www.hackerrank.com/dashboard), [Coderbyte](https://coderbyte.com), [CodinGame](https://www.codingame.com/start), [LeetCode](https://leetcode.com), [Topcoder](https://www.topcoder.com/challenges), [Project Euler](https://projecteuler.net), [CodeFights](https://codefights.com)
+* [Шесть бесплатных автоматизированных платформ для изучения программирования](https://habr.com/ru/company/hexlet/blog/432802/)
+* [Песочница и шпаргалка по изучению Python](https://habr.com/ru/post/421701/)
+* [Где порешать реальные задачи для кандидатов в Яндекc: тренировка на Codeforces и разбор](https://habr.com/ru/company/yandex/blog/493966/)
diff --git a/avtomatizaciya-beta/processy-i-avtomatizaciya-proekta-s-nulya.md b/avtomatizaciya-beta/processy-i-avtomatizaciya-proekta-s-nulya.md
new file mode 100644
index 0000000..4331121
--- /dev/null
+++ b/avtomatizaciya-beta/processy-i-avtomatizaciya-proekta-s-nulya.md
@@ -0,0 +1,135 @@
+# Процессы и автоматизация проекта с нуля
+
+Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать? Ниже будет рассмотрен пример компании Россельхозбанк.
+
+**Общая информация по проекту**
+
+* Большой проект с командами, разрабатывающими общий продукт;
+* В командах есть QA Manual (Ручной тестировщик);
+* Направления тестирования - Frontend, Backend.
+
+**Изучаем проект**
+
+**Понимаем цель разработки продукта и кто потребитель**: ответы на эти вопросы помогают понять, на что делать упор в автоматизации. Например, если работаем с юридическими лицами, то делаем упор на тестирование «исполнения законодательства» и переводы по платежам и тд. Если это физические лица, то на основные выполняемые операции: переводы с карты на карту, оплату услуг и тп. Так же важно, чтобы направление автоматизации «смотрело» в целом на продукт, а не на отдельные в нем команды.
+
+**Знакомимся с участниками разработки продукта**: в нашем случае нужно быть знакомым со всеми, так как необходимо будет взаимодействовать тем или иным образом. Выделю ключевых людей:
+
+* Владельцы продуктов (Product Owners), они заказчики автоматизации в команде;
+* QA каждой команды. Они - это клиенты инструмента автоматизации, их уровень счастья - это показатель успеха;
+* Лидер ручного тестирования. Помогает в организации процесса и во взаимодействии с ручным тестированием;
+* Лидер разработки Frontend. Он влияет на стабильность и качество автотестов;
+* Специалист по закупке. Решит вопросы выделения техники, в основном с серверным железом.
+
+**Изучаем каждую команду**: собираем информацию о том, какую часть проекта разрабатывает команда.
+
+* Разбираемся в направлении - Frontend, Backend или всё сразу;
+* Разбираемся с тем, как QA тестируют свою часть продукта;
+* Выясняем, на каком уровне QA manual знаком с автоматизацией;
+* Находим боли в тестировании и что приоритетно закрыть автоматизацией.
+
+**Формируем требования к автоматизации и заказываем ресурсы**
+
+**Что мы собрали?**
+
+* У нас есть 8 команд;
+* Есть 11 QA инженеров;
+* Есть направления тестирования Frontend, Backend + будем «ходить» в Базу данных;
+* 90% QA manual никогда не занимались автоматизацией.
+
+**Исходя из данных, формируем требования к автоматизации**
+
+У нас нет задачи делать какие-то инновационные решения, поэтому придерживаемся классики:
+
+* В качестве языка программирования выбираем Java - так будет проще найти специалистов;
+* Нужно тестировать Frontend. Берем Selenium;
+* Нужно тестировать Backend. Взаимодействуем с ним через REST. Берем REST-assured;
+* Нужно «ходить» в базу данных. Возьмем стандартные библиотеки из Java;
+* Нужно либо обучить QA manual разработке автотестов, либо нанять армию из N автоматизаторов. Мы думаем о расходах проекта на тестирование, поэтому убиваем 2-х зайцев сразу. Берем Cucumber;
+* Нам нужна отчетность с красивыми графиками. Берем Allure.
+
+Получился следующий стек технологий: Java, Selenium, REST-assured, Cucumber.
+
+**Оцениваем силы автоматизаторов**
+
+Поскольку их нет, берем 1 автоматизатора на 5 команд (больше 5-и не потянет).
+
+**Автотесты нужно где-то запускать**
+
+Что нам понадобится?
+
+* Машина для Jenkins. 1 штука. Через него реализуем удаленный запуск;
+* Машина под Slave Jenkins. Как agent для Jenkins;
+* Машина под Selenoid. Для параллельного запуска тестов.
+
+**Делаем демо нашего инструмента**
+
+Наше демо будут смотреть все: владельцы продуктов, QA инженеры, разработчики, аналитики и тд. Значит ориентируемся на понимание для всех.
+
+Берем команду в качестве первой «жертвы» автоматизации. Ребята разрабатывают Frontend. Нам нужна наглядность.
+
+* Делаем 5-10 автотестов. Записываем на видео;
+* Обязательно после прогона показываем Allure. Красивые графики любят все;
+* Рисуем «инфраструктуру автотестов». Главное, чтобы было просто и понятно;
+* Обозначаем главную цель автоматизации;
+* Демонстрируем эффект от автоматизации;
+* Делаем сравнительные тесты. Ручное прохождение и автоматизированное;
+* Показываем, как создаются сценарии;
+* Показываем планы автоматизации (когда появятся тот или иной функционал);
+* Показываем, как будет происходить внедрение автоматизации в команды.
+
+**Подготавливаем UI к автоматизации**
+
+Для обеспечения надежности, стабильности и качества автотестов, необходимо раскидать якоря на UI. Централизованно через лидера Frontend и дополнительно через владельцев продукта проставляем атрибут для UI-элементов “data-test-id“ или с любым другим названием. Смысл в том, чтобы со стороны UI проставить этот атрибут во всех элементах типа «Таблица, поле для ввода, кнопка» и тд. Если коротко, то на всех элементах, с которыми взаимодействуем, это даст +300% к надежности автотестов. Переезд элемента в другое место или изменение его содержимого никак не повлияют на проверку автотестом. Делаем этот момент обязательным для всех новых фич.
+
+**Разрабатываем автотесты**
+
+* Делим команды между автотестерами;
+* Разрабатываем каркас проекта для автоматизации. Все по шаблону;
+* Подготавливаем набор Cucumber шагов для работы с Frontend, основным направлением в тестировании. Выносим шаги в отдельный проект и делаем из него подключаемый артефакт;
+* Настраиваем Selenoid и Jenkins;
+* Начинаем подключать команды к автоматизации. При подключении команды все сводится к тому, чтобы создать репозиторий, загрузить каркас, создать Job в Jenkins по шаблону, обучить QA работе с Cucumber, работе с Git и средой разработки;
+* После обучения QA manual самостоятельно пишут автотесты. Один раз за спринт автоматизатор приходит в команду и принимает написанные автотесты, делает правки и вливает в основную ветку. На этом этапе ребята качают уровень написания правильных сценариев, а мы получаем качественные проверенные сценарии;
+* После встречи со всеми командами у автоматизатора в спринте остается еще 5-6 свободных дней. Это время тратим на разработку Cucumber шагов;
+* В конце спринта на продуктовом демо показываем результаты по командам и делаем анонсы новых фич в инструменте.
+
+**Результаты**
+
+6 спринтов (60 дней), 8 команд, 2 автотестера и 11 ручных тестировщиков - имеем 50% покрытия регресса проекта автотестами. Это с учетом подключения команд (подключались постепенно) и разработки шагов.
+
+**Вещи, о которых нужно помнить при разработке с таким подходом**
+
+**Ручной тестировщик - это клиент**. QA инженер - прямой потребитель инструмента автоматизации. Их уровень комфорта, счастья и количество автотестов - это показатель качества нашей работы. Если один из показателей падает, значит нужно что-то менять. Иначе все посыпется.
+
+**Ориентация на выгоду для проекта**. Нужно всегда помнить, что содержание разработчиков, тестировщиков, аналитиков и других специалистов стоит денег. В конечном итоге наша цель их сэкономить. Как мы их экономим?
+
+* Автотестами: находим дефекты запуская их каждый день.
+* На каждом этапе тестирования сокращаем время регресса.
+
+Все это приводит к более быстрому выпуску продукта в промышленную эксплуатацию.
+
+**Не работает? Меняй!** Не нужно бояться ошибок. Их будет очень много в разработке, в общении с командами, во взаимодействии с QA инженерами, в демо. Главное увидеть, что «что-то» не работает и менять подход до тех пор, пока все не будут в восторге. Всё делаем для людей. Не для себя.
+
+Источники:
+
+* [Автоматизация тестирования «с нуля» (нетехническая сторона вопроса)](https://habr.com/ru/company/rshb/blog/591449/)
+
+Доп. материал:
+
+* [Гайд внедрения автоматизации тестирования, если ты рядовой QA инженер](https://www.youtube.com/watch?v=LSlF\_0LqYAM)
+* [Путь к автоматизации тестирования в SuperJob: инструменты, проблемы и решения](https://habr.com/ru/company/superjob/blog/577042/)
+* [Как мы автоматизировали тестирование бэкенда](https://habr.com/ru/company/ru\_mts/blog/578600/)
+* [Готовим приложение для автоматизации тестирования](https://habr.com/ru/post/654959/)
+* [О чем спрашивать, унаследовав тест-автоматизацию](https://telegra.ph/O-chem-sprashivat-unasledovav-test-avtomatizaciyu-01-11)
+* [Андрей Солнцев - Воркшоп: Как начать свой проект автоматизации с нуля. Продолжение (часть 1)](https://www.youtube.com/watch?v=h254Tccxgq4\&list=PLsVTVVvrKX9td9Zm\_4nF6Ywlz6gC5\_e7K\&index=15)
+* [Андрей Солнцев - Воркшоп: Как начать свой проект автоматизации с нуля. Продолжение (часть 2)](https://www.youtube.com/watch?v=WETyt87o\_R4\&list=PLsVTVVvrKX9td9Zm\_4nF6Ywlz6gC5\_e7K\&index=16)
+* [AQA Checklist \ Score для интеграции Автоматизации тестирования в существующие Agile процессы](https://www.youtube.com/watch?v=Z6svY5iTdac)
+* [5 заклинаний для команды автоматизации](https://www.youtube.com/watch?v=kbDOZLcQsBo)
+* [Организация мониторинга бизнес-процессов (с нуля до автоматизации)](https://www.youtube.com/watch?v=CdH\_OB\_G5RA)
+* [Вместо 100 запусков приложения - один автотест, или как сэкономить QA-инженеру 20 лет жизни](https://habr.com/ru/company/pixonic/blog/503704/)
+* [Автоматизация тестирования в микросервисной архитектуре](https://habr.com/ru/company/avito/blog/509280/)
+* [Как (авто)тестировать Монстра](https://habr.com/ru/company/rshb/blog/518374/)
+* [Как автоматизировать тестирование на проекте, где по 100 релизов в месяц](https://dou.ua/lenta/columns/test-automation-in-parimatch/)
+* [Процесс автоматизированного тестирования за 10 шагов](https://habr.com/ru/company/otus/blog/546148/)
+* [How Does Test Planning Differ For Manual And Automation Projects?](https://www.softwaretestinghelp.com/automation-test-palnning/)
+* [Step By Step Guide To Implement Proof Of Concept (POC) In Automation Testing](https://www.softwaretestinghelp.com/implement-proof-of-concept-poc-in-automation-testing/)
+* [How To Perform Automation Testing Of JAVA/J2EE Applications (Part 2)](https://www.softwaretestinghelp.com/automated-testing-of-j2ee-applications-part-2/)
diff --git a/avtomatizaciya-beta/raznica-mezhdu-coupling-i-cohesion.md b/avtomatizaciya-beta/raznica-mezhdu-coupling-i-cohesion.md
new file mode 100644
index 0000000..43b78bb
--- /dev/null
+++ b/avtomatizaciya-beta/raznica-mezhdu-coupling-i-cohesion.md
@@ -0,0 +1,63 @@
+# Разница между coupling и cohesion
+
+Это термины из принципов разработки ПО.
+
+Целью этапа проектирования в жизненном цикле разработки программного обеспечения является создание решения проблемы, указанной в документе SRS (Спецификация требований к программному обеспечению). Результатом этапа проектирования является проектный документ программного обеспечения (SDD).
+
+По сути, проектирование представляет собой итеративный процесс, состоящий из двух частей. Первая часть - это концептуальный проект, который сообщает заказчику, что будет делать система. Во-вторых, это техническое проектирование, которое позволяет сборщикам систем понять, какое аппаратное и программное обеспечение необходимо для решения проблемы клиента.
+
+Концептуальный проект системы:
+
+* Написано простым языком, т.е. понятным для клиента языком.
+* Подробное объяснение характеристик системы.
+* Описывает функциональность системы.
+* Это не зависит от реализации.
+* Связан с документом требования.
+
+Технический проект системы:
+
+* Аппаратная составляющая и дизайн.
+* Функциональность и иерархия программных компонентов.
+* Архитектура программного обеспечения
+* Сетевая архитектура
+* Структура данных и поток данных.
+* Компонент ввода/вывода системы.
+* Показывает интерфейс.
+
+Модуляризация: модульность - это процесс разделения программной системы на несколько независимых модулей, где каждый модуль работает независимо. Есть много преимуществ модуляризации в разработке программного обеспечения. Некоторые из них приведены ниже:
+
+* Легко понять систему.
+* Обслуживание системы простое.
+* Модуль может использоваться много раз в соответствии с их требованиями. Нет необходимости писать это снова и снова.
+
+Связь (Coupling): Связь является мерой степени взаимозависимости между модулями. Хорошее программное обеспечение будет иметь низкую связность.
+
+Типы связности:
+
+* Связность данных (**Data Coupling**): если зависимость между модулями основана на том факте, что они обмениваются данными, передавая только данные, то говорят, что модули связаны данными. При соединении данных компоненты независимы друг от друга и взаимодействуют через данные. Коммуникации модулей не содержат бродячих данных (?tramp data). Пример - система расчетов с клиентами;
+* Связность штампов (**Stamp Coupling**): При соединении штампов полная структура данных передается от одного модуля к другому. Следовательно, он включает в себя tramp data. Это может быть необходимо из соображений эффективности - этот выбор сделал проницательный дизайнер, а не ленивый программист;
+* Связность управления (**Control Coupling**): если модули взаимодействуют, передавая управляющую информацию, то говорят, что они связаны управлением. Может быть плохо, если параметры указывают совершенно другое поведение, и хорошо, если параметры позволяют факторизовать и повторно использовать функциональность. Пример - функция сортировки, которая принимает функцию сравнения в качестве аргумента;
+* Внешняя связность (**External Coupling**): при внешней связности модули зависят от других модулей, внешних по отношению к разрабатываемому программному обеспечению или аппаратному обеспечению определенного типа. Ex - протокол, внешний файл, формат устройства и т. д.
+* Общая связность (**Common Coupling**): модули имеют общие данные, такие как глобальные структуры данных. Изменения в глобальных данных означают отслеживание всех модулей, которые обращаются к этим данным, для оценки эффекта изменения. Таким образом, у него есть недостатки, такие как сложность повторного использования модулей, ограниченная способность контролировать доступ к данным и меньшая ремонтопригодность.
+* Связность содержимого (**Content Coupling**): при связности содержимого один модуль может изменять данные другого модуля, или поток управления передается от одного модуля к другому модулю. Это наихудшая форма связности, и ее следует избегать.
+
+Сцепление/единство/сплоченность (Cohesion): это мера степени, в которой элементы модуля функционально связаны. Это степень, в которой все элементы, направленные на выполнение одной задачи, содержатся в компоненте. По сути, сцепление - это внутренний клей, который удерживает модуль вместе. Хороший дизайн программного обеспечения будет иметь высокое сцепление.
+
+Types of Cohesion:
+
+* **Functional Cohesion**: в компоненте содержится каждый важный элемент для отдельного вычисления. Функциональная сплоченность выполняет задачу и функции. Это идеальная ситуация.
+* **Sequential Cohesion**: элемент выводит некоторые данные, которые становятся входными данными для другого элемента, т. е. поток данных между частями. Это происходит естественным образом в функциональных языках программирования.
+* **Communicational Cohesion**: два элемента работают с одними и теми же входными данными или вносят свой вклад в одни и те же выходные данные. Пример - обновить запись в базе данных и отправить ее на принтер.
+* **Procedural Cohesion**: Элементы процедурного единства обеспечивают порядок исполнения. Действия по-прежнему слабо связаны и маловероятно, что их можно будет использовать повторно. Вычислить средний балл студента, распечатать студенческий отчет, рассчитать совокупный средний балл, распечатать совокупный средний балл.
+* **Temporal Cohesion**: элементы связаны по своему времени. В модуле, связанном с временной связностью, все задачи должны выполняться в один и тот же промежуток времени. Эта связность содержит код для инициализации всех частей системы. Происходит множество различных действий, и все они происходят в единицу времени.
+* **Logical Cohesion**: элементы связаны логически, а не функционально. Компонент Ex-A считывает входные данные с ленты, диска и сети. Весь код этих функций находится в одном компоненте. Операции родственные, но функции существенно различаются.
+* **Coincidental Cohesion**: элементы не связаны (несвязаны). Элементы не имеют никакой концептуальной связи, кроме местоположения в исходном коде. Это случайность и худшая форма сплоченности. Вывести следующую строку и поменять местами символы строки в одном компоненте.
+
+Источники:
+
+* [Coupling and Cohesion](https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/?ref=lbp)
+
+Доп. материал:
+
+* [Low Coupling и High Cohesion](https://medium.com/german-gorelkin/low-coupling-high-cohesion-d36369fb1be9)
+* [ООП для ООП: GRASP](https://habr.com/ru/post/38323/)
diff --git a/avtomatizaciya-beta/vidy-i-instrumenty-avtomatizacii.md b/avtomatizaciya-beta/vidy-i-instrumenty-avtomatizacii.md
new file mode 100644
index 0000000..a256c14
--- /dev/null
+++ b/avtomatizaciya-beta/vidy-i-instrumenty-avtomatizacii.md
@@ -0,0 +1,430 @@
+# Виды и инструменты автоматизации
+
+Одним из самых частых вопросов новичков в автоматизации является вопросы о том, какой язык программирования выбрать для изучения, а также какой инструмент лучше. Эти вопросы на самом деле стоит рассматривать в другой плоскости, а язык программирования является следствием, а не причиной (а где-то и вообще не нужен).
+
+При всем многообразии того, что можно считать автоматизацией, можно попытаться выделить категории:
+
+* Функциональное или нефункциональное тестирование;
+* Уровни: unit, integration, UI/E2E;
+* Метод: white box, black box;
+* Уровень в сетевой модели: frontend, backend, database;
+* Платформы: desktop, mobile, web, cross platform;
+* ОС: windows, macos, linux, cross platform;
+* Масштабируемость: однопоточные, многопоточные;
+* Программа, скрипт, фреймворк или библиотека;
+* Работа непосредственно с тестами, как вспомогательное средство (генераторы данных), инфраструктура (CI/CD, раннеры, отчетность);
+* Если это создание тестов, то каким образом: нативный язык программирования, универсальный ЯП, тестовая модель и ключевые слова, рекордеры (Capture & Playback);
+* и т.д. и т.п. до бесконечности.
+
+Каждый инструмент создан и подходит для определенных задач и сочетает в себе несколько таких критериев. Именно поэтому нет лучшего инструмента и единственно правильного языка программирования для старта.
+
+**Технологии автоматизации тестирования**
+
+Начнём с краткого обзора эволюции высокоуровневых технологий, при этом подчеркнув, что «старые» решения по-прежнему используются (или как компоненты «новых», или самостоятельно в отдельных случаях).
+
+| | **Подход** | **Суть** | **Преимущества** | **Недостатки** |
+| ----- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **1** | Частные решения |
Для решения каждой
отдельной задачи
пишется отдельная
программа
| Быстро, просто |
Нет системности,
много времени уходит на поддержку.
Почти невозможно
повторное использование
|
+| **2** |
Тестирование под
управлением данными (DDT)
|
Из тест-кейса вовне
выносятся входные
данные и ожидаемые результаты.
|
Один и тот же тест кейс можно повторять многократно с
разными данными
|
Логика тест-кейса по прежнему строго
определяется
внутри, а потому для
ее изменения тест кейс надо переписывать
|
+| **3** |
Тестирование под
управлением ключевыми словами (KDT)
|
Из тест-кейса вовне
выносится описание
его поведения
|
Концентрация на высокоуровневых действиях. Данные и
особенности поведения хранятся вовне и
могут быть изменены
без изменения кода
тест-кейса
|
Сложность выполнения низкоуровневых
операций
|
+| **4** |
Использование
фреймворков
| Конструктор, позволяющий использовать остальные подходы | Мощность и гибкость |
Относительная
сложность (особенно
- в создании
фреймворка)
|
+| **5** | Запись и воспроизведение (Record & Playback) |
Средство автоматизации записывает
действия тестировщика и может воспроизвести их,
управляя тестируемым приложением
|
Простота, высокая
скорость создания
тест-кейсов.
|
Крайне низкое качество, линейность, неподдерживаемость
тест-кейсов. Требуется серьёзная доработка полученного
кода
|
+| **6** |
Тестирование под
управлением поведением (BDT)
|
Развитие идей тестирования под управлением данными и
ключевыми словами.
Отличие - в концентрации на бизнес сценариях без выполнения мелких
количество функциональных и нефункциональных дефектов,
а потому должны
быть дополнены
классическими более низкоуровневыми тест-кейсами
|
+
+На текущем этапе развития тестирования представленные в таблице технологии иерархически можно изобразить следующей схемой:
+
+
+
+**Технологии: Частные решения**
+
+Иногда перед тестировщиком возникает уникальная (в том плане, что такой больше не будет) задача, для решения которой нет необходимости использовать мощные инструментальные средства, а достаточно написать небольшую программу на любом из высокоуровневых языков программирования (Java, C#, PHP и т.д.) или даже воспользоваться возможностями командных файлов операционной системы или подобными тривиальными решениями. Также сюда можно отнести задачи вида:
+
+* Подготовить базу данных, наполнив её тестовыми данными (например, добавить в систему миллион пользователей со случайными именами).
+* Подготовить файловую систему (например, создать структуру каталогов и набор файлов для выполнения тест-кейсов).
+* Перезапустить набор серверов и/или привести их в требуемое состояние.
+
+Удобство частных решений состоит в том, что их можно реализовать быстро, просто, «вот прямо сейчас». Но у них есть и огромный недостаток - это «кустарные решения», которыми может воспользоваться всего пара человек. И при появлении новой задачи, даже очень похожей на ранее решенную, скорее всего, придётся всё автоматизировать заново.
+
+Преимущества:
+
+* Быстрота и простота реализации;
+* Возможность использования любых доступных инструментов, которыми тестировщик умеет пользоваться;
+* Эффект от использования наступает незамедлительно;
+* Возможность нахождения очень эффективных решений в случае, когда основные инструменты, используемые на проекте для автоматизации тестирования, оказываются малопригодными для выполнения данной отдельной задачи;
+* Возможность быстрого создания и оценки прототипов перед применением более тяжеловесных решений
+
+Недостатки:
+
+* Отсутствие универсальности и, как следствие, невозможность или крайняя сложность повторного использования (адаптации для решения других задач).
+* Разрозненность и несогласованность решений между собой (разные подходы, технологии, инструменты, принципы решения).
+* Крайне высокая сложность развития, поддержки и сопровождения таких решений (чаще всего, кроме самого автора никто вообще не понимает, что и зачем было сделано, и как оно работает).
+* Является признаком «кустарного производства», не приветствуется в промышленной разработке программ.
+
+**Технологии:Тестирование под управлением данными (DDT)**
+
+Обратите внимание, как много раз в командных файлах повторяются строки, выполняющие одно и то же действие над набором файлов (и нам ещё повезло, что файлов немного). Ведь куда логичнее было бы каким-то образом подготовить список файлов и просто передать его на обработку. Это и будет тестированием под управлением данными. Теперь нам достаточно подготовить CSV-файл с любым количеством имён сравниваемых файлов, а код тест-кейса не увеличится.
+
+К другим типичным примерам использования тестирования под управлением данными относится:
+
+* Проверка авторизации и прав доступа на большом наборе имен пользователей и паролей;
+* Многократное заполнение полей форм разными данными и проверка реакции приложения;
+* Выполнение тест-кейса на основе данных, полученных с помощью комбинаторных техник.
+
+Данные для рассматриваемого подхода к организации тест-кейсов могут поступать из файлов, баз данных и иных внешних источников или даже генерироваться в процессе выполнения тест-кейса (см. описание источников данных для автоматизированного тестирования).
+
+Преимущества:
+
+* Устранение избыточности кода тест-кейсов;
+* Удобное хранение и понятный человеку формат данных;
+* Возможность поручения генерации данных сотруднику, не имеющему навыков программирования;
+* Возможность использования одного и того же набора данных для выполнения разных тест-кейсов;
+* Возможность повторного использования набора данных для решения новых задач;
+* Возможность использования одного и того же набора данных в одном и том же тест кейсе, но реализованном под разными платформами.
+
+Недостатки:
+
+* При изменении логики поведения тест-кейса его код всё равно придётся переписывать;
+* При неудачно выбранном формате представления данных резко снижается их понятность для неподготовленного специалиста;
+* Необходимость использования технологий генерации данных;
+* Высокая сложность кода тест-кейса в случае сложных неоднородных данных;
+* Риск неверной работы тест-кейсов в случае, когда несколько тест-кейсов работают с одним и тем же набором данных, и он был изменён таким образом, на который не были рассчитаны некоторые тест-кейсы;
+* Слабые возможности по сбору данных в случае обнаружения дефектов;
+* Качество тест-кейса зависит от профессионализма сотрудника, реализующего код тест кейса.
+
+**Технологии: Тестирование под управлением ключевыми словами**
+
+Логическим развитием идеи о вынесении вовне тест-кейса данных является вынесение вовне тест-кейса команд (описания действий). Идею можно развить, добавив в CSV-файл ключевые слова, являющиеся описанием выполняемой проверки. Ярчайшим примером инструментального средства автоматизации тестирования, идеально следующего идеологии тестирования под управлением ключевыми словами, является Selenium IDE, в котором каждая операция тест-кейса описывается в виде: Действие (ключевое слово) - Необязательный параметр 1 - Необязательный параметр 2.
+
+Тестирование под управлением ключевыми словами стало тем переломным моментом, начиная с которого стало возможным привлечение к автоматизации тестирования нетехнических специалистов. Согласитесь, что нет необходимости в знаниях программирования и тому подобных технологий, чтобы наполнять подобные только что показанному CSV-файлы или (что очень часто практикуется) XLSX файлы.
+
+Вторым естественным преимуществом тестирования под управлением ключевыми словами (хотя она вполне характерна и для тестирования под управлением данными) стала возможность использования различных инструментов одними и теми же наборами команд и данных. Так, например, ничто не мешает нам взять показанные CSV-файлы и написать новую логику их обработки не на PHP, а на C#, Java, Python или даже с использованием специализированных средств автоматизации тестирования.
+
+Преимущества:
+
+* Максимальное устранение избыточности кода тест-кейсов;
+* Возможность построения мини-фреймворков, решающих широкий спектр задач;
+* Повышение уровня абстракции тест-кейсов и возможность их адаптации для работы с разными техническими решениями;
+* Удобное хранение и понятный человеку формат данных и команд тест-кейса;
+* Возможность поручения описания логики тест-кейса сотруднику, не имеющему навыков программирования;
+* Возможность повторного использования для решения новых задач;
+* Расширяемость (возможность добавления нового поведения тест-кейса на основе уже реализованного поведения)
+
+Недостатки:
+
+* Высокая сложность (и, возможно, длительность) разработки;
+* Высокая вероятность наличия ошибок в коде тест-кейса;
+* Высокая сложность (или невозможность) выполнения низкоуровневых операций, если фреймворк не поддерживает соответствующие команды;
+* Эффект от использования данного подхода наступает далеко не сразу (сначала идет длительный период разработки и отладки самих тест-кейсов и вспомогательной функциональности);
+* Для реализации данного подхода требуется наличие высококвалифицированного персонала;
+* Необходимо обучить персонал языку ключевых слов, используемых в тест-кейсах
+
+**Технологии: Фреймворки**
+
+Фреймворк автоматизации тестирования - это интегрированная система, которая устанавливает правила автоматизации конкретного продукта. Эта система объединяет библиотеки функций, источники тестовых данных, сведения об объектах и различные повторно используемые модули. Эти компоненты действуют как небольшие строительные блоки, которые необходимо собрать для представления бизнес-процесса. Платформа обеспечивает основу для автоматизации тестирования и упрощает процесс автоматизации.
+
+Фреймворки автоматизации тестирования представляют собой не что иное, как успешно развившиеся и ставшие популярными решения, объединяющие в себе лучшие стороны тестирования под управлением данными, ключевыми словами и возможности реализации частных решений на высоком уровне абстракции.
+
+Фреймворков автоматизации тестирования очень много, они очень разные, но их объединяет несколько общих черт:
+
+* высокая абстракция кода (нет необходимости описывать каждое элементарное действие) с сохранением возможности выполнения низкоуровневых действий;
+* универсальность и переносимость используемых подходов;
+* достаточно высокое качество реализации (для популярных фреймворков).
+
+Как правило, каждый фреймворк специализируется на своём виде тестирования, уровне тестирования, наборе технологий. Существуют фреймворки для модульного тестирования (например, семейство xUnit), тестирования веб-приложений (например, семейство Selenium), тестирования мобильных приложений, тестирования производительности и т.д.
+
+Существуют бесплатные и платные фреймворки, оформленные в виде библиотек на некотором языке программирования или в виде привычных приложений с графическим интерфейсом, узко- и широко специализированные и т.д.
+
+Преимущества:
+
+* Широкое распространение;
+* Универсальность в рамках своего набора технологий;
+* Хорошая документация и большое сообщество специалистов, с которыми можно проконсультироваться;
+* Высокий уровень абстракции;
+* Наличие большого набора готовых решений и описаний соответствующих лучших практик применения того или иного фреймворка для решения тех или иных задач.
+
+Недостатки:
+
+* Требуется время на изучение фреймворка;
+* В случае написания собственного фреймворка де-факто получается новый проект по разработке ПО;
+* Высокая сложность перехода на другой фреймворк;
+* В случае прекращения поддержки фреймворка тест-кейсы рано или поздно придётся переписывать с использованием нового фреймворка;
+* Высокий риск выбора неподходящего фреймворка.
+
+**Технологии: Запись и воспроизведение (Record & Playback)**
+
+Технология записи и воспроизведения (Record & Playback) стала актуальной с появлением достаточно сложных средств автоматизации, обеспечивающих глубокое взаимодействие с тестируемым приложением и операционной системой. Использование этой технологии, как правило, сводится к следующим основным шагам:
+
+* Тестировщик вручную выполняет тест-кейс, а средство автоматизации записывает все его действия;
+* Результаты записи представляются в виде кода на высокоуровневом языке программирования (в некоторых средствах - специально разработанном);
+* Тестировщик редактирует полученный код;
+* Готовый код автоматизированного тест-кейса выполняется для проведения тестирования в автоматизированном режиме.
+
+Сама технология при достаточно высокой сложности внутренней реализации очень проста в использовании и по самой своей сути, потому часто применяется для обучения начинающих специалистов по автоматизации тестирования.
+
+Преимущества:
+
+* Предельная простота освоения (достаточно буквально нескольких минут, чтобы начать
+* использовать данную технологию);
+* Быстрое создание «скелета тест-кейса» за счет записи ключевых действий с тестируемым приложением;
+* Автоматический сбор технических данных о тестируемом приложении (идентификаторов и локаторов элементов, надписей, имен и т.д.);
+* Автоматизация рутинных действий (заполнения полей, нажатий на ссылки, кнопки и т.д.);
+* В отдельных случаях допускает использование тестировщиками без навыков программирования.
+
+Недостатки:
+
+* Линейность тест-кейсов: в записи не будет циклов, условий, вызовов функций и прочих характерных для программирования и автоматизации явлений;
+* Запись лишних действий (как просто ошибочных случайных действий тестировщика с тестируемым приложением, так и (во многих случаях) переключений на другие приложения и работы с ними);
+* Так называемый «хардкодинг», т.е. запись внутрь кода тест-кейса конкретных значений, что потребует ручной доработки для перевода тест-кейса на технологию тестирования под управлением данными;
+* Неудобные имена переменных, неудобное оформление кода тест-кейса, отсутствие комментариев и прочие недостатки, усложняющие поддержку и сопровождение тест кейса в будущем;
+* Низкая надёжность самих тест-кейсов в силу отсутствия обработки исключений, проверки условий и т.д
+
+**Технологии: Тестирование под управлением поведением**
+
+Рассмотренные выше технологии автоматизации максимально сфокусированы на технических аспектах поведения приложения и обладают общим недостатком: с их помощью сложно проверять высокоуровневые пользовательские сценарии (а именно в них и заинтересованы заказчики и конечные пользователи). Этот недостаток призвано исправить тестирование под управлением поведением, в котором акцент делается не на отдельных технических деталях, а на общей работоспособности приложения при решении типичных пользовательских задач.
+
+Такой подход не только упрощает выполнение целого класса проверок, но и облегчает взаимодействие между разработчиками, тестировщиками, бизнес-аналитиками и заказчиком, т.к. в основе подхода лежит очень простая формула «given-when-then»:
+
+* Given («имея, предполагая, при условии») описывает начальную ситуацию, в которой находится пользователь в контексте работы с приложением;
+* When («когда») описывает набор действий пользователя в данной ситуации;
+* Then («тогда») описывает ожидаемое поведение приложения.
+
+Такой принцип описания проверок позволяет даже участникам проекта, не имеющим глубокой технической подготовки, принимать участие в разработке и анализе тест-кейсов, а для специалистов по автоматизации упрощается создание кода автоматизированных тест-кейсов, т.к. такая форма является стандартной, единой и при этом предоставляет достаточно информации для написания высокоуровневых тест-кейсов. Существуют специальные технические решения (например, Behat, JBehave, NBehave, Cucumber), упрощающие реализацию тестирования под управлением поведением.
+
+Преимущества:
+
+* Фокусировка на потребностях конечных пользователей;
+* Упрощение сотрудничества между различными специалистами;
+* Простота и скорость создания и анализа тест-кейсов (что, в свою очередь, повышает полезный эффект автоматизации и снижает накладные расходы).
+
+Недостатки:
+
+* Высокоуровневые поведенческие тест-кейсы пропускают много деталей, а потому могут не обнаружить часть проблем в приложении или не предоставить необходимой для понимания обнаруженной проблемы информации;
+* В некоторых случаях информации, предоставленной в поведенческом тест-кейсе, недостаточно для его непосредственной автоматизации
+
+_К классическим технологиям автоматизации тестирования также можно отнести разработку под управлением тестированием (Test-driven Development, TDD) с её принципом «красный, зелёный, улучшенный» (Red-Green-Refactor), разработку под управлением поведением (Behavior-driven Development), модульное тестирование (Unit Testing) и т.д. Но эти технологии уже находятся на границе тестирования и разработки приложений, потому выходят за рамки данной темы._
+
+**Автоматизация вне прямых задач тестирования**
+
+На протяжении данного раздела мы рассматривали, как автоматизация может помочь в создании и выполнении тест-кейсов. Но все те же принципы можно перенести и на остальную работу тестировщика, в которой также бывают длительные и утомительные задачи, рутинные задачи или задачи, требующие предельного внимания, но не связанные с интеллектуальной работой. Всё перечисленное также можно автоматизировать. Да, это требует технических знаний и первоначальных затрат сил и времени на реализацию, но в перспективе такой подход может экономить до нескольких часов в день. К самым типичным решениям из данной области можно отнести:
+
+* Использование командных файлов для выполнения последовательностей операций - от копирования нескольких файлов из разных каталогов до развертывания тестового окружения. Даже в рамках многократно рассмотренных примеров по тестированию «Конвертера файлов» запуск приложения через командный файл, в котором указаны все необходимые параметры, избавляет от необходимости вводить их каждый раз вручную;
+* Генерация и оформление данных с использованием возможностей офисных приложений, баз данных, небольших программ на высокоуровневых языках программирования. Нет картины печальнее, чем тестировщик, руками нумерующий три сотни строк в таблице;
+* Подготовка и оформление технических разделов для отчётов. Можно тратить часы на скрупулезное вычитывание журналов работы некоего средства автоматизации, а можно один раз написать скрипт, который будет за мгновение готовить документ с аккуратными таблицами и графиками, и останется только запускать этот скрипт и прикреплять результаты его работы к отчёту;
+* Управление своим рабочим местом: создание и проверка резервных копий, установка обновлений, очистка дисков от устаревших данных и т.д. и т.п. Компьютер всё это может (и должен!) делать сам, без участия человека;
+* Сортировка и обработка почты. Даже раскладывание входящей корреспонденции по подпапкам гарантированно занимает у вас несколько минут в день. Если предположить, что настройка специальных правил в вашем почтовом клиенте сэкономит вам полчаса в неделю, за год экономия составит примерно сутки;
+* Виртуализация как способ избавления от необходимости каждый раз устанавливать и настраивать необходимый набор программ. Если у вас есть несколько заранее подготовленных виртуальных машин, их запуск займёт секунды. А в случае необходимости устранения сбоев разворачивание виртуальной машины из резервной копии заменяет весь процесс установки и настройки с нуля операционной системы и всего необходимого программного обеспечения
+
+[**Классификация инструментов**](https://habr.com/ru/company/badoo/blog/347986/#:\~:text=%D0%A0%D0%B0%D1%81%D1%81%D0%BC%D0%BE%D1%82%D1%80%D0%B8%D0%BC%20%D0%B8%D1%85%20%D0%BF%D0%BE%D0%B4%D1%80%D0%BE%D0%B1%D0%BD%D0%B5%D0%B5.-,%D0%9A%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F%20%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2,-%D0%94%D1%80%D0%B0%D0%B9%D0%B2%D0%B5%D1%80) **автотестирования мобильных приложений**
+
+**Драйвер**. Утилиты автотестирования, как и другие программы, могут взаимодействовать с приложением только через программный интерфейс - по-другому они не умеют. Для работы через другие интерфейсы существуют специальные программы - драйверы. Драйвер - программа, которая предоставляет API для одного из интерфейсов приложения. Для каждого интерфейса, кроме, собственно, API, необходим свой драйвер. Например, когда вы даёте драйверу для GUI команду “Нажать на кнопку Menu”, он воспринимает её через API и отсылает в тестируемое приложение, где эта команда превращается в клик по графической кнопке Menu. Для взаимодействия с API приложения драйверы не нужны или почти не нужны - взаимодействие программное. А вот при работе с остальными интерфейсами без них не обойтись. Наиболее сложными обычно являются драйверы для GUI, так как этот интерфейс сильно отличается от обычного для программы общения кодом. При этом в автоматизированном тестировании мобильных приложений GUI наиболее актуален, так как в интеграционном тестировании использовать чаще всего приходится именно его. Наиболее популярные драйвера для GUI в мобильном тестировании - UIAutomator и Espresso для Android, XCUITest - для iOS.
+
+**Надстройка**. Когда функционала драйвера не хватает или он неудобен и сложен, над ним появляется еще один уровень, который я буду называть надстройкой.Надстройка - программа, которая взаимодействует с приложением через один или несколько драйверов, повышая удобство их использования или расширяя их возможности.
+
+У надстройки могут быть следующие функции:
+
+* Модификация поведения (без изменения API). Например:
+ * дополнительное протоколирование,
+ * валидация данных,
+ * ожидание выполнения действия в течение определенного времени.
+* Повышение удобства и/ или уровня абстракции API через:
+ * использование синтаксического сахара - удобных названий функций, более коротких обращений к ним, унифицированного стиля написания тестов;
+ * неявное управление драйвером, когда, например, он инициализируется автоматически, без необходимости прописывать каждое такое действие вручную;
+ * упрощение сложных команд вроде выбора события из календаря или работы с прокручивающимися списками;
+ * реализацию альтернативных стилей программирования, таких как процедурный стиль или fluent.
+* Унификация API драйверов. Здесь надстройка предоставляет единый интерфейс для работы сразу с несколькими драйверами. Это позволяет, например, использовать один и тот же код для тестов на iOS и Android, как в популярной надстройке Appium.
+
+**Фреймворк**. С другой стороны тестов находится фреймворк запуска. В рамках данной статьи я буду коротко называть его “фреймворк”. Фреймворк - это программа для формирования, запуска и сбора результатов запуска набора тестов.
+
+В задачи фреймворка входят:
+
+* формирование, группировка и упорядочение набора тестов,
+* распараллеливание набора (опционально),
+* создание фикстур,
+* запуск тестов,
+* сбор результатов их выполнения,
+* формирование отчётов о выполнении (опционально).
+
+Можно заметить, что эти функции не связаны с тестированием только мобильных приложений - их можно успешно применять и в тестировании десктоп- и веб-приложений. Дело в том, что фреймворк не должен обеспечивать взаимодействие тестов и приложения - он работает только с тестами, и тип приложения не имеет значения. Если драйверы и надстройки находятся между тестами и приложением, то фреймворк находится над тестами, организуя их запуск. Поэтому важно не путать понятия “драйвер” и “фреймворк”. Конечно, в некоторых фреймворках есть собственные драйверы для работы с приложениями, но это вовсе не обязательное условие. Самые заметные фреймворки в мобильном тестировании - xUnit и Cucumber.
+
+**Комбайны**. Наконец, еще одна группа утилит, использующихся для автоматизации тестирования мобильных приложений, - это комбайны, объединяющие в себе и фреймворки, и драйверы (причём не только мобильные), и даже возможности разработки. Xamarin.UITest, Squish, Ranorex - все они поддерживают автоматизацию тестирования iOS-, Android-, веб-приложений, а два последних - ещё и десктоп-приложений.
+
+**Android: Инструменты для автоматизации тестирования**
+
+Тесты под андроид бывают локальные и инструментальные:
+
+* Instrumented tests выполняются на устройстве Android, физическом или эмулированном. Тест собирается в APK и устанавливается вместе с тестовым приложением. Instrumented tests обычно представляют собой тесты пользовательского интерфейса, запуск приложения и последующее взаимодействие с ним;
+* Local tests выполняются на вашей машине разработки или сервере, поэтому их также называют тестами на стороне хоста (host-side tests). Для запуска тестов используется виртуальная машина Java (JVM). Обычно они маленькие и быстрые, изолируя тестируемый объект от остальной части приложения.
+
+Не все модульные тесты являются локальными, и не все Е2Е тесты выполняются на устройстве. Например:
+
+* Большой локальный тест: вы можете использовать симулятор Android, который работает локально, например Robolectric;
+* Небольшой инструментальный тест: вы можете убедиться, что ваш код хорошо работает с функцией платформы, такой как база данных SQLite. Вы можете запустить этот тест на нескольких устройствах, чтобы проверить интеграцию с несколькими версиями SQLite.
+
+UI тесты обращаются к GUI-драйверам. GUI-драйверы являются наиболее сложным компонентом всего стека тестирования. Они решают базовые, низкоуровневые задачи. Когда вы даете GUI-драйверу ([Espresso](https://github.com/android/android-test/tree/master/espresso), [UiAutomator](https://developer.android.com/training/testing/other-components/ui-automator), [Robotium](https://github.com/RobotiumTech/robotium), [Selendroid](https://github.com/selendroid/selendroid)) команду «кликнуть на кнопку», он обрабатывает ее, взаимодействует с приложением, и эта команда превращается в клик по элементу.
+
+Все драйверы работают на Android Instrumentation Framework - базовом API Android для взаимодействия с системой. Самые популярные - Espresso и UiAutomator. Они оба разрабатываются и поддерживаются компанией Google. Их без труда можно использовать одновременно в пределах одного теста.
+
+**UiAutomator** поставляется вместе с Android SDK начиная с 16 версии API. Как GUI-драйвер он служит для поиска элементов интерфейса на экране девайса и эмуляции различных действий: кликов, тачей, свайпов, ввода текста, проверок на видимость. Рекордер для записи тестов он не предоставляет, зато предоставляет утилиту для просмотра древовидной структуры экрана - Ui Automator Viewer.
+
+UiAutomator позволяет писать тесты по модели черного ящика (black-box). Он живет в собственном процессе и работает без доступа к исходному коду приложения. Значит, тест с его использованием может взаимодействовать практически с любыми приложениями, в том числе системными. Это открывает доступ к множеству функций, например, становятся возможны:
+
+* набор номера и совершение звонка;
+* отправка и чтение смс;
+* взаимодействие с нотификациями;
+* управление настройками сети, геолокации;
+* снятие скриншотов.
+
+Наиболее подходящим сценарием для использования UiAutomator является не работа с тестируемым продуктовым приложением, а взаимодействие со сторонними или системными приложениями. Более подходящим инструментом для работы с продуктовым приложением является **Espresso**.
+
+Это также официальный фреймворк для UI-тестирования от Google, но тесты с его использованием работают уже по модели белого ящика (white-box). Espresso поддерживает Android API с 10 версии, хотя появился значительно позже. Предоставляет рекордер для записи тестов. Фактически Espresso является лидером и даже стандартом в индустрии. Такой успех может быть связан с тем, что он обеспечивает повышенную скорость и стабильность тестов в сравнении с конкурентами. Espresso решает низкоуровневую задачу - найти необходимый элемент на экране по заданным параметрам (ViewMatcher), произвести с ним действия (ViewAction) или выполнить проверки (ViewAssertion). Синтаксис Espresso реализован на основе фреймворка Hamcrest. Он построен на использовании иерархий вложенных матчеров - сущностей, описывающих требования к объекту, в случае Espresso - к элементам интерфейса. Они используются при задании параметров поиска элемента на экране, а также в проверках как описание свойств, которыми элемент должен обладать. Вложенность матчеров часто приводит к тому, что код тестов становится трудно читать и поддерживать. Стабильность и скорость тестов на Espresso обусловлены его внутренним устройством - все команды Espresso выполняются в том же процессе, в котором работает само тестируемое приложение. Действия и проверки преобразовываются и кладутся в очередь сообщений главного потока приложения. Выполняются они только когда приложение готово к этому, то есть его главный поток находится в состоянии ожидания пользовательского ввода (idle).
+
+Итак, с драйверами и устройством наиболее популярных из них мы разобрались. Мы поняли, что все они решают низкоуровневые задачи: поиск элемента на экране и выполнение с ним какого-либо действия. Из-за этого они предоставляют невыразительный API, которым неудобно пользоваться для решения более высокоуровневых проблем. Например, ни один из них не предоставляет собственный механизм для реализации повторов неудачных действий или логирования. Более того, часто существует необходимость работать в тестах сразу с несколькими драйверами, например, с Espresso и UiAutomator.
+
+На помощь приходят **обертки** (надстройки). Именно к API оберток мы будем обращаться в наших тестах, и именно обертки предоставляют конечный арсенал приемов для наших тестов.
+
+* ****[**Kakao**](https://github.com/agoda-com/Kakao) **** - простой и удобный Kotlin DSL для Espresso. Он позволяет упростить код тестов на Espresso и повысить его читаемость;
+* [**Barista**](https://github.com/AdevintaSpain/Barista) **** - это объемная библиотека, содержащая большое количество полезных решений и приемов при работе с Espresso;
+* ****[**Kaspresso**](https://github.com/KasperskyLab/Kaspresso) **** - это фреймворк-обертка для UI-тестирования, который претендует на то, чтобы избавить мир от зла и стать практически единственной зависимостью в вашем проекте для работы с тестами. Kaspresso расширяет лаконичный Kakao DSL - он предоставляет собственный Kotlin DSL для описания тестовых секций и шагов, внутри которых продолжает жить Kakao.
+
+_Подробнее в источнике по первой ссылке далее._
+
+* [На чем писать Android UI-тесты](https://habr.com/ru/company/avito/blog/516650/)
+* [Автотесты на Android. Картина целиком](https://habr.com/ru/company/kaspersky/blog/510230/)
+* [An open-source documentation about Android UI testing](https://github.com/android-ui-testing/Cookbook/)
+* [Android Developers - Test apps on Android](https://developer.android.com/training/testing)
+* [Kaspresso: фреймворк для автотестирования, который вы ждали](https://habr.com/ru/company/kaspersky/blog/467617/)
+* [Kaspresso tutorials. Часть 1. Запуск первого теста](https://habr.com/ru/company/kaspersky/blog/570658/)
+* [Adb-server в Kaspresso](https://habr.com/ru/post/594017/)
+* [Светлана Смельчакова - UI Automator deep diving](https://www.youtube.com/watch?v=bqNguUHK3SM)
+* [Selendroid Tutorial: Android Mobile Test Automation Framework (Part 1)](https://www.softwaretestinghelp.com/selendroid-tutorial-1/)
+
+**iOS: Инструменты для автоматизации тестирования**
+
+Под iOS существуют следующие инструменты:
+
+* [TestProject](https://testproject.io) - фреймворк для iOS тестирования на базе Appium и Selenium. Подходит для тестирования веба, Android-приложений и API. При этом не обязательно использовать XCode;
+* [EarlGrey](https://github.com/google/EarlGrey) - open-source инструмент, разработанный компанией Google для тестирования своих собственных iOS-приложений, таких как YouTube, Google Calendar и т.д.;
+* [XCTest](https://developer.apple.com/documentation/xctest) - инструмент, созданный Apple для iOS тестирования. Он полностью совместим с XCode. XCTest универсален - c помощью него можно проводить как unit-тесты, так и тестировать производительность и пользовательский интерфейс;
+* [Detox](https://github.com/wix/Detox) - это инструмент end-to-end тестирования, который используется для тестирования методом серого ящика;
+* [OCMock](https://ocmock.org) - проект с открытым исходным кодом, который упрощает iOS-тестирование с помощью mock-объектов. OCMock расшифровывается как Objective-C Mock. С его помощью тестировщик может создавать mock-объекты, используя язык Objective-C;
+* [KIF](https://github.com/kif-framework/KIF) - это фреймворк для интеграционного тестирования iOS-приложений. KIF расшифровывается как “keep it functional” и используется для тестирования пользовательского интерфейса, как и XCTest.
+
+_Подробнее в источнике по первой ссылке далее._
+
+* [Обзор фреймворков для iOS тестирования](https://testengineer.ru/obzor-frejmvorkov-dlya-ios-testirovaniya/)
+* [Погружение в автотестирование на iOS. Часть 1. Как работать с accessibilityidentifier объектов](https://habr.com/ru/company/vivid\_money/blog/533180/)
+* [Погружение в автотестирование на iOS. Часть 2. Как взаимодействовать с ui-элементами iOS приложения в тестах](https://habr.com/ru/company/vivid\_money/blog/538708/)
+
+**Кроссплатформенные обертки**
+
+* [Appium](https://appium.io) - это довольно популярный кросс-платформенный open source инструмент для автоматизации тестирования десктоп и мобильных приложений под Android и iOS. Архитектура Appium схожа с Selenium WebDriver, широко распространенным и ставшим стандартом в web-тестировании. Кроссплатформенность достигается за счет использования разных драйверов для разных платформ. Именно драйверы транслируют клиентский Appium-код в команды, непосредственно исполняемые на устройствах. Для написания тестов Appium предоставляет клиентские библиотеки с фиксированным API;
+* [Calabash](https://www.guru99.com/calabash-android-ios-testing.html) пользуется большой популярностью среди разработчиков благодаря стабильности и подходу к построению тестов. Calabash использует Cucumber, благодаря чему его могут использовать даже люди, незнакомые с программированием. Поддерживает много языков программирования, может работать как с iOS, так и с Android приложениями.
+
+Доп. материал:
+
+* [Appium Studio Tutorial For Mobile Automation (15+ Hands-On Tutorials)](https://www.softwaretestinghelp.com/appium-studio-tutorial/)
+* [Appium Tutorial For Testing Android And IOS Mobile Apps](https://www.softwaretestinghelp.com/appium-tutorial-for-beginners/)
+* [Автоматизация мобильных приложений на базе Appium](https://habr.com/ru/company/dataart/blog/308180/)
+
+WEB: Инструменты для автоматизации тестирования
+
+* [Selenium](https://www.selenium.dev): Старейший фреймворк, все еще самый популярный. Поддерживает Java, Python, C#, Ruby, JavaScript. Эмулирует почти все возможные действия пользователя;
+* [Cucumber](https://cucumber.io): Фреймворк ориентирован на behavior-driven development (BDD) - “разработка через поведение”; удобный как для разработчиков, так и QA. Главное преимущество: простота;
+* [Cypress](https://www.cypress.io): И наконец Cypress, делающий жизнь тестировщиков проще. В нем нет некоторых проблем, существующих в Selenium, потому что он имеет другую архитектуру - построен на основе JS-фреймворка Mocha. Преимущества: простота и удобство асинхронных тестов. Применяется BDD/TDD-библиотека (TDD = test-driven development);
+* [Playwright](https://playwright.dev) enables reliable end-to-end testing for modern web apps;
+* [Puppeteer](https://pptr.dev) is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol
+
+_Подробнее в источнике по первой ссылке далее._
+
+* [E2E-тестирование и Cypress](https://testengineer.ru/e2e-testirovanie-i-cypress/)
+* [Александр Самойлов, Сергей Львов - Визуальные проверки в End-to-End-тестах](https://www.youtube.com/watch?v=RSNZ2312XJI\&list=PLsVTVVvrKX9td9Zm\_4nF6Ywlz6gC5\_e7K\&index=22)
+* [QA Wolf handles your end-to-end testing](https://www.qawolf.com)
+* [Selenium vs Puppeteer vs Cypress vs Playwright](https://habr.com/ru/post/566348/)
+* [30+ Best Selenium Tutorials: Learn Selenium With Real Examples](https://www.softwaretestinghelp.com/selenium-tutorial-1/)
+* [Что такое Cypress: Введение и архитектура](https://testengineer.ru/chto-takoe-cypress-vvedenie-i-arhitektura/)
+
+**API: Инструменты для автоматизации тестирования**
+
+По постману и соап есть множество ссылок в инструментах для мануальщика.
+
+* [Что такое REST Assured? - REST Assured API Testing - 18+](https://www.youtube.com/watch?v=8nAgzJea1L8)
+* [Тестирование API с помощью REST Assured (Java)](https://medium.com/@svetlana.podv/%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-api-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-rest-assured-2654f9b1faab)
+* [Cucumber и Spock для автоматизации API-тестов. В чем польза этих фреймворков](https://dou.ua/forums/topic/35288/)
+* [Cypress API](https://www.youtube.com/watch?v=QarebAg0zNM)
+
+**Unit**
+
+* [List of unit testing frameworks](https://en.wikipedia.org/wiki/List\_of\_unit\_testing\_frameworks)
+* [Перевод книги Python Testing with pytest](https://habr.com/ru/post/426699/)
+
+_**Инструменты по performance/security и всему не вошедшему смотри в разделе полезных ссылок по мануальному тестированию.**_
+
+_**Инструменты, касающиеся инфраструктуры CI/CD вынесены в следующую тему.**_
+
+Доп. материал:
+
+* [Автоматизация UI-тестирования в приложении Недвижимости на Android. Доклад Яндекса](https://habr.com/ru/company/yandex/blog/568800/)
+* [Как мы автоматизировали тестирование бэкенда](https://habr.com/ru/company/ru\_mts/blog/578600/)
+* [Browser Automation Testing For Start-Ups And Small-Sized Teams](https://www.softwaretestinghelp.com/browser-automation-testing/)
+* [Доказательная разработка или как data-driven подход добавил смысла работе](https://habr.com/ru/company/funcorp/blog/548576/)
+* [Why Do We Need Framework For Test Automation?](https://www.softwaretestinghelp.com/why-do-we-need-test-automation-framework/)
+
+По инструментам:
+
+* [Путеводитель по инструментам автотестирования мобильных приложений](https://habr.com/ru/company/badoo/blog/347986/)
+* [Top 20 Best Automation Testing Tools In 2022 (Comprehensive List)](https://www.softwaretestinghelp.com/top-20-automation-testing-tools/)
+* [100+ лучших инструментов для тестирования программного обеспечения](https://blog.themarfa.name/100-luchshikh-instrumientov-dlia-tiestirovaniia-proghrammnogho-obiespiechieniia/)
+* [How To Choose The Best Automation Testing Tool (A Complete Guide)](https://www.softwaretestinghelp.com/automation-testing-tutorial-4/)
+* [How To Develop Test Scripts Using Top 5 Most Popular Test Automation Frameworks (Examples)](https://www.softwaretestinghelp.com/automation-testing-tutorial-5/)
+* [Record-and-Replay тестирование - сочетание достоинств юнит и интеграционных тестов](https://habr.com/ru/post/573948/)
+* [LEADERSHIP IN TEST: TEST EXECUTION TOOLS](https://theqalead.com/topics/test-execution-tools/)
+* [Фреймворки для тестирования: личный опыт и новые методы](https://habr.com/ru/post/579032/)
+* [10 LATEST SOFTWARE TESTING TOOLS QAS ARE USING IN 2022](https://theqalead.com/tools/software-testing-tools/)
+* [Применение автотестов в ежедневных релизах](https://habr.com/ru/company/utkonos/blog/591539/)
+* [Разработка и сценарное тестирование с Vanessa-ADD. Концепция, теория и сквозной пример создания сценария](https://infostart.ru/1c/articles/969637/)
+* [THE 10 BEST QA AUTOMATION TOOLS FOR SOFTWARE TESTING IN 2022](https://theqalead.com/tools/qa-automation-tools/)
+* [Выбираем правильные инструменты автоматизации (с таблицей)](https://testengineer.ru/vybiraem-pravilnye-instrumenty-avtomatizacii/)
+* [Борьба с задержкой тестов в Selenium: пример из практики](https://testengineer.ru/borba-s-zaderzhkoj-testov-v-selenium/)
+* [Все про Mobile QA Automation - Appium, XCUITest, Espresso](https://www.youtube.com/watch?v=Yn0tlt1n5Nw)
+* [Дмитрий Буздин - Как построить свой фреймворк для автотестов?](https://www.youtube.com/watch?v=vrjN8VTeuOk)
+* [Одновременное использование нескольких тест-фреймворков](https://telegra.ph/Odnovremennoe-ispolzovanie-neskolkih-test-frejmvorkov-04-23)
+* [Почему я больше не использую Cucumber при автоматизации тестирования](https://telegra.ph/Pochemu-ya-bolshe-ne-ispolzuyu-Cucumber-pri-avtomatizacii-e2e-testirovaniya-04-22)
+* [Selenoid UI](http://aerokube.com/selenoid-ui/latest/)
+* [50 приложений для эффективной организации удалённой работы](https://habr.com/ru/company/vdsina/blog/494762/)
+* [Selenium, Selenoid, Selenide, Selendroid… Что все это значит?](https://habr.com/ru/post/463525/)
+* [6 антипаттернов для UI тестирования на JavaScript, которых следует избегать](https://telegra.ph/6-antipatternov-dlya-UI-testirovaniya-na-JavaScript-kotoryh-sleduet-izbegat-03-06)
+* [Эмуляторы и симуляторы vs реальные устройства для автоматизации тестирования](https://habr.com/ru/company/otus/blog/596371/)
+* [FlaNium: как сделать тестирование Desktop-приложений под Windows проще](https://habr.com/ru/company/lanit/blog/553588/)
+* [Black box API testing with server logs](https://glebbahmutov.com/blog/api-testing-with-sever-logs/)
+* [Veslo - расширение Retrofit для тестирования (Java)](https://habr.com/ru/post/647499/)
+* [The Essential Guide to Automated Visual Regression Testing](https://hackernoon.com/the-essential-guide-to-automated-visual-regression-testing-2l2k3467)
+* [QTP Tutorials - 25+ Micro Focus Quick Test Professional (QTP) Training Tutorials](https://www.softwaretestinghelp.com/qtp-quicktest-professional-tutorial-1/)
+* [15+ SoapUI Tutorials: The Best Web Services API Testing Tool](https://www.softwaretestinghelp.com/web-services-api-testing-tool-soapui-tutorial-1/)
+* [LoadRunner Tutorial For Beginners (Free 8-Day In-Depth Course)](https://www.softwaretestinghelp.com/hp-loadrunner-load-testing-tool-training-tutorials/)
+* [Most Popular Test Automation Frameworks With Pros And Cons Of Each - Selenium Tutorial #20](https://www.softwaretestinghelp.com/test-automation-frameworks-selenium-tutorial-20/)
+* [Introduction To Sikuli GUI Automation Tool (Automate Anything You See On Screen) - Sikuli Tutorial #1](https://www.softwaretestinghelp.com/sikuli-tutorial-part-1/)
+* [PowerShell UIAutomation Tutorial: UI Automation Of Desktop Applications](https://www.softwaretestinghelp.com/desktop-application-ui-automation-with-powershell/)
+* [Katalon Automation Recorder (Selenium IDE Alternative): Hands-On Review Tutorial](https://www.softwaretestinghelp.com/katalon-automation-recorder-review-tutorial/)
+* [Geb Tutorial - Browser Automation Testing Using Geb Tool](https://www.softwaretestinghelp.com/geb-tutorial-browser-automation-testing-using-geb-tool/)
+* [AutoIt Tutorial - AutoIt Download, Install & Basic AutoIt Script](https://www.softwaretestinghelp.com/autoit-tutorial-to-download-write-autoit-script/)
+* [Automation Testing Using Cucumber Tool And Selenium - Selenium Tutorial #30](https://www.softwaretestinghelp.com/cucumber-bdd-tool-selenium-tutorial-30/)
+* [Protractor Testing Tool For End-To-End Testing Of AngularJS Applications](https://www.softwaretestinghelp.com/protractor-testing-tutorial/)
+* [Ranorex Tutorial: A Powerful Desktop, Web, And Mobile Automation Testing Tool](https://www.softwaretestinghelp.com/ranorex-tutorial-1/)
+* [Осваиваем Data-driven Testing в Selenium](https://testengineer.ru/osvaivaem-data-driven-testing-v-selenium/)
+* [Борьба с задержкой тестов в Selenium: пример из практики](https://testengineer.ru/borba-s-zaderzhkoj-testov-v-selenium/)
+* [Доклад: Как достичь Pixel Perfect с Jetpack Compose и Figma / Владимир Иванов (Tinkoff)](https://www.youtube.com/watch?v=GaY3IbgW9V0)
+* [Ускоряем свои тесты с помощью сypress-grep](https://testengineer.ru/uskoryaem-svoi-testy-s-pomoshchyu-cypress-grep/)
+* [QAGuild#53: Тестирование api на python и schemathesis](https://www.youtube.com/watch?v=y5zSVa9GlY0)
+* [Selenide vs Selenium - подробное сравнение](https://habr.com/ru/company/otus/blog/651967/)
+* [Grafana и автотесты: учимся измерять работу тестов](https://habr.com/ru/company/ozontech/blog/657933/)
+* [Playwright: веб-тестирование без драмы](https://habr.com/ru/company/jugru/blog/652919/)
+* Рецепты применения техник тест-дизайна с помощью многофункц-ного Citrus Testing Framework часть [1](https://www.youtube.com/watch?v=ACyMqJpS3IQ), [2](https://www.youtube.com/watch?v=pvhON3pL4o8)
+* [Создание фреймворка для автоматических тестов: пошаговая инструкция](https://www.youtube.com/watch?v=42iLidKlC4I)
+* [Как в Яндексе используют PyTest и другие фреймворки для функционального тестирования](https://habr.com/ru/company/yandex/blog/242795/)
+* [Единственно верный способ загружать и скачивать файлы в Selenium тестах](https://habr.com/ru/post/497922/)
+* [Пишем автотест с использованием Selenium Webdriver, Java 8 и паттерна Page Object](https://habr.com/ru/post/502292/)
+* [Простой и удобный шаблон тестового фреймворка на selenide для UI автотестов](https://habr.com/ru/post/504408/)
+* [Тесты в Python: все основные подходы, плюсы и минусы. Доклад Яндекса](https://habr.com/ru/company/yandex/blog/517266/)
+* [Home видео для Selenium aka WebDriver. Или чем записать экран, если у вас есть java, поломанные тесты и немного времени](https://habr.com/ru/post/517446/)
+* [Эффективное тестирование верстки](https://habr.com/ru/company/oleg-bunin/blog/499638/)
+* [Автоматизация тестирования мобильных приложений. Часть 2: предусловия, верификация элементов и независимость шагов](https://habr.com/ru/company/badoo/blog/547196/)
diff --git a/faq-dlya-novichkov/README.md b/faq-dlya-novichkov/README.md
new file mode 100644
index 0000000..d0f04d9
--- /dev/null
+++ b/faq-dlya-novichkov/README.md
@@ -0,0 +1,2 @@
+# FAQ для новичков
+
diff --git a/faq-dlya-novichkov/chto-dolzhen-znat-i-umet-junior-chto-sprosyat-na-sobesedovanii.md b/faq-dlya-novichkov/chto-dolzhen-znat-i-umet-junior-chto-sprosyat-na-sobesedovanii.md
new file mode 100644
index 0000000..9b02392
--- /dev/null
+++ b/faq-dlya-novichkov/chto-dolzhen-znat-i-umet-junior-chto-sprosyat-na-sobesedovanii.md
@@ -0,0 +1,151 @@
+# Что должен знать и уметь Junior? Что спросят на собеседовании?
+
+Конкретного ответа на этот вопрос нет, всё зависит от компании и вакансии. Ожидания в двух разных компаниях и даже проектах могут не пересекаться совершенно никак. Мидл+ из одной компании может оказаться джуном- в другой.\
+Если всё же пытаться вывести среднее, то вот пара ссылок на карты знаний для тестировщиков:
+
+* [QA RoadMap 2021](https://disk.yandex.ru/i/x\_hOsnoxVMoB-A)
+* [Большая дорожная карта развития тестировщика](https://testengineer.ru/razvitie-testirovshchika/)
+* [Awesome Quality Assurance Roadmap](https://github.com/fityanos/awesome-quality-assurance-roadmap)
+* [https://www.mindmeister.com/ru/1324282825/junior-qa?fullscreen=1](https://www.mindmeister.com/ru/1324282825/junior-qa?fullscreen=1)
+* [https://www.mindmeister.com/ru/1558647509?t=973hdS2AKb](https://www.mindmeister.com/ru/1558647509?t=973hdS2AKb)
+* [https://miro.com/app/board/o9J\_lXUgVuQ=/](https://miro.com/app/board/o9J\_lXUgVuQ=/)
+* [Quality Engineer Learning Roadmap](https://medium.com/slalom-build/quality-engineer-learning-roadmap-fddfcb77409e)
+* [Пост “что нужно знать junior QA engineer”](https://t.me/shooandendlessagony/2)
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). 4.1. Карьера тестировщика
+
+Некоторые компании подробно расписывают на своих порталах ожидания от каждой стадии развития сотрудника, по этой же теме много видео на Youtube ([раз](https://www.youtube.com/watch?v=l9ezImoh5ac\&feature=emb\_logo\&ab\_channel=LearnQA%3A%D0%9E%D0%BD%D0%BB%D0%B0%D0%B9%D0%BD%D0%BE%D0%B1%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D1%89%D0%B8%D0%BA%D0%BE%D0%B2), [два](https://www.youtube.com/watch?v=wDHZsoZIxcY\&ab\_channel=LearnQA%3A%D0%9E%D0%BD%D0%BB%D0%B0%D0%B9%D0%BD%D0%BE%D0%B1%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D1%89%D0%B8%D0%BA%D0%BE%D0%B2), [три](https://www.youtube.com/watch?v=tzOhRHVX6ko\&ab\_channel=QAQC), [четыре](https://www.youtube.com/watch?v=5DGuDT98EC0\&ab\_channel=AzatZakuanov), …). Более практичный ориентир - просто открыть и почитать интересующие вакансии, выписывая повторяющиеся пункты.
+
+Дальнейшие пункты являются усредненными.
+
+**Джун должен уметь**:
+
+* Ориентироваться, как протестировать что-то структурированно и в правильном порядке (приоритезация);
+* Составлять тест-кейсы по ТЗ/юзер стори;
+* Оформлять баг-репорты;
+* Пользоваться базовыми инструментами: Chrome DevTools, Postman, Charles/Fiddler, GIT;
+* Для мобильщиков: посмотреть логи через ADB консоль или в IDE, собрать приложение.
+
+**HR-вопросы на собеседовании**
+
+Часть из них зададут в любом случае. Список, разумеется, не полный:
+
+* Расскажи о себе (все что хочешь, что нам нужно знать о тебе)
+* Есть ли релевантный опыт?
+* Какие курсы проходил и вообще, что изучал?
+* Что не устраивало на прошлом месте работы (если было), особенно если решил сменить сферу?
+* Почему выбрал именно тестирование?
+* Чем заинтересовала именно наша компания?
+* Как часто бываешь на собеседованиях?
+* Уровень английского? (вопрос могут задать на английском, многие теряются в этот момент)
+* (Если требуется и уровень хороший) расскажите на английском: как доехали до собеседования/о себе (только не как в обществе анонимных алкоголиков) /почему считаешь, что можешь стать тестировщиком/ как прошел вчерашний день/о своих хобби/ и т.п.
+* Как в целом смотришь на мир, как решаешь возникающие проблемы?
+* 3 твоих сильных и 3 слабых стороны?
+* Как отдыхаешь? Как проводишь свободное время?
+* Какие хобби?
+* Что последнее прочитал техническое? Не техническое?
+* Если бы мог вернуться в начало осознанной жизни, выбрал бы иной карьерный путь?
+* 3 примера, что тебе положительного дал предыдущий опыт работы (если есть)
+* 3 плюса и 3 минуса в сфере тестирования лично для тебя
+* Как видишь развитие в этой сфере, кем видишь себя через год, три?
+* Какая-то одна вещь или ситуация, которой ты гордишься
+* Твой самый большой факап
+* Представим, что остальных кандидатов много и они опытнее (обычно так и есть), может у тебя есть какие-то преимущества перед ними? Почему ты думаешь, что лучше других кандидатов?
+* Зарплатные ожидания сейчас, после испытательного срока, через год?
+* Есть ли какие-то факторы, с которыми ты согласишься на меньшие деньги?
+* С чем точно не готов мириться в отношении компании или руководителя?
+* Ожидания от работы?
+* Отношение к переработкам?
+* Парням: наличие военного билета, девушкам: планы на ближайшие годы по поводу декрета
+* Представь, что ты работаешь уже полгода. Опиши свой рабочий день.
+* Что если при выполнении задачи понимаешь, что не укладываешься в сроки?
+* Что делать, если нет времени на регрессионное тестирование?
+* Что делать, если разработчик утверждает, что найденный дефект таковым не является?
+* Пришел баг из продакшена, что делаем?
+* Какое самое важное влияние оказывает тестировщик на команду разработки? (не продукт!)
+* Чем ты как начинающий тестировщик можешь быть полезен нашей компании?
+* Кто виноват в багах, найденных в процессе регресса?
+* Как решать конфликты в удаленной команде?
+* Как понять, что тестировщик хорошо сделал свою работу?
+
+**Теория на собеседовании**
+
+* Что такое тестирование и зачем оно нужно;
+* Разница QA/QC/Тестирование;
+* Качество ПО;
+* Принципы тестирования;
+* Верификация и валидация;
+* Виды, типы, уровни тестирования;
+* Тестовые артефакты;
+* Баг и его жизненный цикл;
+* Severity/priority;
+* Техники тест-дизайна;
+* SDLC, STLC; Методологии разработки ПО;
+* API;
+* Базовое знание сетей: Клиент-серверная архитектура, HTTP(s), его методы, коды ответов, TCP/IP, REST/SOAP, JSON/XML;
+* Базы данных: основы БД, что такое SQL, СУБД, основные команды (селекты, джойны);
+* Специфика конкретного домена/направления/платформы (опционально): если ожидается работа с мобильными, то будут спрашивать и по этой теме. Темы см. в разделе “Мобильное тестирование”. В случае gamedev могут спросить жанровые предпочтения, про последнее, во что играл, что понравилось/не понравилось и т.п.
+
+**Практика на собеседовании**
+
+* Тестирование некого продукта. В качестве тестового задания это обычно подразумевает нахождение багов и оформление баг-репортов или написание кейсов, тест-плана. На собеседовании это открытый вопрос и оцениваются рассуждения кандидата и часто умение пользоваться техниками тест-дизайна;
+* Тестирование поля или формы;
+* Определение серьезности и приоритета какого-либо бага;
+* Придумать хороший summary для репорта;
+* Задачки по SQL.
+
+Для геймдева могут быть вопросы, относящиеся к определенной игре: как бы тестировал карту, персонажа, игровую механику и т.п. Больше [тут](https://www.softwaretestingmaterial.com/game-testing-interview-questions/).
+
+**Разница для Junior/Middle/Senior**
+
+Просто для цельной картины, если говорить про уровень middle, то работодателей теория уже не так интересует, если только это не крупная галера с высоким конкурсом (вопросы в таком случае будут +- те же, что и для junior, просто копнут глубже). Мидл - самостоятельная в решении рядовых задач боевая единица. Такой специалист уже имеет опыт в задачах, инструментах, видел какие-то процессы и уже примерно может давать оценку времени на выполнение задач. Соответственно и спрашивать будут больше по таким кейсам и по предыдущему опыту работы. Senior это уже про серьезный опыт, а также: организация работы, [менторинг](https://software-testing.ru/library/around-testing/management/3656-mentoring-software-testers), автоматизация, CI/CD и место автоматизации в нём, менеджмент процессов и их построение, планирование, метрики, ROI, знание стандартов, опыт в тест планах и стратегиях, декомпозиция и распределение задач, оценка времени и т.п. [Тут](https://www.youtube.com/watch?v=KlE3BOltGdw) можно узнать больше. [Тут](https://telegra.ph/Sobesedovanie-s-QA-250-voprosov-dlya-Junior-Middle-Senior-01-12) вопросы разделены по грейдам.
+
+**Английский**
+
+Помимо вышеперечисленного нужно помнить об английском языке. Он нужен для чтения документации и актуальных статей, просмотра вебинаров, поиска ответов на вопросы, т.к. в русскоязычном сегменте информации в разы меньше и пока ее переведут она уже устаревает. В РБ и Украине гораздо чаще чем в РФ язык нужен для ведения проектной документации и общения с иностранными коллегами (не надейтесь особо на переводчики и авто субтитры, всё это еще далеко от совершенства). Конечно, компании работающие на внутренние рынки могут не требовать знание языка, но тут, опять же, остается открытым вопрос личного развития. Если же в вакансии указан необходимый уровень владения языком, то будьте готовы к тому, что как минимум попросят ответить на какой-нибудь простенький житейский или HR-вопрос на английском. В отдельных случаях, где явно указана необходимость разговорного уровня, все собеседование вполне может пройти на английском.
+
+Доп. материал:
+
+* [Собеседование QA - Старт карьеры тестировщика в 2022 году](https://www.youtube.com/watch?v=kYgmffIHb0w)
+* [Знания и навыки, необходимые для работы в тестировании в 2022 году](https://habr.com/ru/post/656027/)
+* [Собеседование тестировщика на Западе: список вопросов](https://testengineer.ru/sobesedovanie-na-testirovshchika-v-zapadnyh-stranah/)
+* [Обзор вакансий для тестировщиков (QA)](https://www.youtube.com/watch?v=ePtN5vlNAlE)
+* [Образ современного тестировщика. Что нужно знать и уметь](https://habr.com/ru/company/funcorp/blog/426759/)
+* [Святослав Куликов про QA, Курсы тестировщиков / Как развиваться тестировщику](https://www.youtube.com/watch?v=aIb8BPzVWG4\&t=53s)
+* [Что должен знать тестировщик бэкенда](https://habr.com/ru/company/funcorp/blog/491188/)
+* [Тестировщик ПО / что делает QA Engineer / интервью с Artsiom Rusau QA](https://www.youtube.com/watch?v=Yd0Z-35GbK4\&feature=youtu.be\&ab\_channel=%D0%9B%D1%91%D1%88%D0%B0%D0%9C%D0%B0%D1%80%D1%88%D0%B0%D0%BB)
+* [Чек-лист подготовки к собеседованию на позицию ручного web-тестировщика](https://habr.com/ru/company/renins/blog/564522/)
+* [Исследование рынка труда в QA](http://mymonday.by/qa-market-research-august-2019)
+* [Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько зарабатывает, что надо знать и где учиться](https://ru.hexlet.io/blog/posts/gid-po-professii-testirovschik-chem-zanimaetsya-skolko-zarabatyvaet-chto-nado-znat-i-gde-uchitsya)
+* [Качественное тестирование ПО](https://habr.com/ru/company/otus/blog/530290/)
+* [Пути развития тестировщика. Карьера QA Engineer](https://www.youtube.com/watch?v=m7tQyFGU4Ls)
+* [Challenge accepted: карьера тестировщика](https://habr.com/ru/article/561354/)
+* Грейды на примере разработки: [раз](https://vas3k.ru/inside/39/levels/), [два](https://maximgorbatyuk.gitbook.io/knowledge-base/management/2019-09-08-developer-skill-matrix)
+* [Как стать QA-лидом - теория и практические советы](https://testengineer.ru/kak-stat-qa-lidom/)
+* [Что должен знать тестировщик без опыта](https://www.youtube.com/watch?v=96f8fqqumhE)
+* [Leadership in test: managing your career](https://theqalead.com/topics/managing-your-testing-career/)
+* [Какая разница между Junior, Middle и Senior тестировщиками](https://www.youtube.com/watch?v=9uPCf0-e48I)
+* [11 признаков Senior QA, к которым я пришёл за годы работы в тестировании](https://habr.com/ru/company/funcorp/blog/593231/)
+* [Junior QA - Middle QA - Senior QA](https://www.youtube.com/watch?v=oRszp5QflTk)
+* [Собеседование тестировщика на Западе: список вопросов](https://testengineer.ru/sobesedovanie-na-testirovshchika-v-zapadnyh-stranah/)
+* [Круглый стол "Джуниоры в QA: плюсы и минусы для компании”](https://www.youtube.com/watch?v=iNu5f-SyiNA)
+* [Модель обучения «70:20:10»](https://telegra.ph/Kak-dostich-maksimalnyh-rezultatov-v-svoyom-razvitii-02-17)
+* [Пентестер: суть профессии, востребованность, зарплата и другие нюансы](https://habr.com/ru/post/651167/)
+* [Устану ли я играть, нужно ли уметь кодить и чем вообще занимаются QA в геймдеве](https://habr.com/ru/company/lightmap/blog/650245/)
+* [Реестр профессиональных стандартов - Специалист по тестированию в области информационных технологий](https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT\_ID=57024)
+
+Английский:
+
+* [Как тестировщику учить английский язык](https://software-testing.ru/library/around-testing/job/3591-english-for-qa-engineers)
+* [Таблица уровней английского языка](https://englex.ru/english-levels-table/)
+* Марафон “Как IT-специалисту заговорить по-английски за 6 недель”: [часть 1](https://dt9xom8irs6kr.cloudfront.net/u256113/456701-5237085293807285895.mp4) + [часть 2](https://dt9xom8irs6kr.cloudfront.net/u256113/463400-3382237430755091928.mp4) + [часть 3](https://dt9xom8irs6kr.cloudfront.net/u256113/491184-811669784489900464.mp4)
+* [EngVid.com](https://www.engvid.com)
+* [Плейлист “Essential English Grammar или Красный Мёрфи (уровень elementary A1-A2) - лучшая английская грамматика для начинающих”](https://www.youtube.com/playlist?list=PLYB0SmefqEsniU1UbGzrfhNCV3noALHj7)
+* [QA English Basics - тренинг по английскому языку](https://www.youtube.com/watch?v=YCXw-MB5OBY\&t=469s)
+* [Английский для тестировщика (QA Engineer) / Мой топ English ресурсов](https://www.youtube.com/watch?v=vMudS9qnyyc)
+* [English with Lucy](https://www.youtube.com/c/EnglishwithLucy/playlists)
+* [Большая подборка](https://vk.com/topic-127171939\_34549533#:\~:text=%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9%20\(%D0%B0%D0%BC%D0%B5%D1%80%D0%B8%D0%BA%D0%B0%D0%BD%D1%81%D0%BA%D0%B8%D0%B9\)%20%2B%20%D0%BF%D0%BE%D0%BB%D0%B5%D0%B7%D0%BD%D1%8B%D0%B5%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B8)
+* [Как я осилил английский](https://habr.com/ru/post/413633/)
+* [Учим английский дешево и эффективно](https://habr.com/ru/post/369695/)
+* [Очень много YouTube-каналов для прокачки английского языка для программистов](https://habr.com/ru/post/465731/)
+* [9 четких инструментов для изучения и прокачки английской лексики](https://habr.com/ru/company/englishdom/blog/490736/)
+* [Экзамены TOEFL/IELTS как ориентир для развития. Фундаментальные апгрейды языка и их польза для разработчика](https://habr.com/ru/post/512346/)
diff --git a/faq-dlya-novichkov/gde-iskat-rabotu.md b/faq-dlya-novichkov/gde-iskat-rabotu.md
new file mode 100644
index 0000000..eca2cef
--- /dev/null
+++ b/faq-dlya-novichkov/gde-iskat-rabotu.md
@@ -0,0 +1,22 @@
+# Где искать работу?
+
+Подробнее см. в источнике.
+
+* [https://www.linkedin.com/](https://www.linkedin.com) ([добавляйтесь в друзья](https://www.linkedin.com/in/vladislaveremeev/) :)
+* [https://hh.ru/](https://hh.ru)
+* [https://career.habr.com/](https://career.habr.com)
+* Группы Facebook
+* Telegram-каналы
+* Группы Вконтакте
+* Чаты специалистов или профессиональных мероприятий
+* Офлайн конференции/кэмпы/мастер-классы
+* Сайты или группы от крупных компаний
+* Зарубежные площадки для поиска работы
+
+Источники:
+
+* [Где искать работу в IT?](https://habr.com/ru/post/655577/)
+
+Доп. материал:
+
+* [Сайти для пошуку роботи в Україні, в тому числі віддалено](https://dou.ua/forums/topic/37190/)
diff --git a/faq-dlya-novichkov/kachestva-i-navyki-kotorymi-nuzhno-obladat-testirovshiku.md b/faq-dlya-novichkov/kachestva-i-navyki-kotorymi-nuzhno-obladat-testirovshiku.md
new file mode 100644
index 0000000..fb8e640
--- /dev/null
+++ b/faq-dlya-novichkov/kachestva-i-navyki-kotorymi-nuzhno-obladat-testirovshiku.md
@@ -0,0 +1,31 @@
+# Качества и навыки, которыми нужно обладать тестировщику?
+
+* Самые главные:
+ * Развитые софт-скиллы;
+ * Самостоятельность;
+ * Прокачанное умение гуглить.
+* Второстепенные, но всё еще важные:
+ * Пытливый ум и желание докопаться до первопричины проблемы;
+ * Крайне полезно иметь склонность к развитию T-shaped skills (когда специалист углубляется в свою профессиональную область, но также развивается поверхностно в смежных областях);
+ * QA Engineer это всё же engineer, желательно иметь склонности к [problem solving](https://www.youtube.com/watch?v=1hKRsKKwtVU);
+ * Общая грамотность;
+ * Устойчивость к рутине;
+ * Умение воспринимать текстовую информацию. Ютуб - это хорошо, но большинство доки пишется текстом.
+
+Доп. материал:
+
+* [Миф об образе мышления в тестировании](https://telegra.ph/Mif-ob-obraze-myshleniya-v-testirovanii-02-10)
+* [Важные навыки тестировщика](https://software-testing.ru/library/testing/general-testing/3599-bloggers-club-essential-skills-for)
+* [How to Think Like a Tester](https://medium.com/@blakenorrish/how-to-think-like-a-tester-7a174ff6aeaf)
+
+Про soft-skills:
+
+* [Podlodka Soft Skills Crew - Интервью "Как я научился софт-скиллам и захватил мир"](https://www.youtube.com/watch?v=YbiHrgDx8j0)
+* [3 Tips To Improve Your Verbal Communication Skills](https://betterprogramming.pub/3-tips-to-improve-your-verbal-communication-skills-d461ff36688a)
+* [Как разговаривать с му\*аками (краткое содержание) - Марк Гоулстон](https://www.youtube.com/watch?v=3HeB9-FfClA)
+* [Конспект по книге Марка Гаулстона “Я слышу вас насквозь”](https://habr.com/ru/post/468291/)
+* [Патрик Ленсиони - Пять пороков команды (краткое содержание)](https://briefly.ru/lensioni/piat\_porokov\_komandy/)
+* [Моя роль в конфликте. Елена Татти. COMAQA Piter 2017](https://www.youtube.com/watch?v=AyzlgEIQ70M)
+* [Checklist молодого QA менеджера глазами тестировщика. Антон Семенченко](https://www.youtube.com/watch?v=HBVLuxDlow4)
+* [Soft-skills успешного тестировщика](https://habr.com/ru/post/434794/)
+* [Как ИТ-специалисту развить навыки коммуникации. 20+ полезных материалов](https://habr.com/ru/company/ncloudtech/blog/653243/)
diff --git a/faq-dlya-novichkov/kak-proiskhodit-process-naima.md b/faq-dlya-novichkov/kak-proiskhodit-process-naima.md
new file mode 100644
index 0000000..90a039d
--- /dev/null
+++ b/faq-dlya-novichkov/kak-proiskhodit-process-naima.md
@@ -0,0 +1,16 @@
+# Как происходит процесс найма?
+
+Все зависит от компании и в меньшей степени от уровня позиции. В среднем это выглядит так:
+
+1. Отклик на вакансию;
+2. \*Опционально: выполнение [тестового задания](https://www.youtube.com/watch?v=LAh7CAqzJec), п.2 и п.3 могут меняться местами;
+3. Скрининг по телефону (небольшая беседа с HR);
+4. Полноценное собеседование с HR;
+5. Техническое собеседование, п.4 и п.5 иногда делают за раз;
+6. \*Опционально: знакомство с боссом/лидом/командой);
+
+В очень больших компаниях с потоковым наймом бывает и по 6-7 этапов интервью, в мелких местных же всё может обойтись одной встречей с беседой за кофе.
+
+Доп. материал:
+
+* [Тестирование тестировщиков](https://habr.com/ru/company/hh/blog/571364/)
diff --git a/faq-dlya-novichkov/kak-prokhodit-sobesedovanie.md b/faq-dlya-novichkov/kak-prokhodit-sobesedovanie.md
new file mode 100644
index 0000000..220c0cc
--- /dev/null
+++ b/faq-dlya-novichkov/kak-prokhodit-sobesedovanie.md
@@ -0,0 +1,116 @@
+# Как проходить собеседование?
+
+Прежде всего, конечно, на него не нужно опаздывать. В случае оффлайна стоит прийти немного заранее, оглядеться, привыкнуть к атмосфере и настроиться на нужный лад. Требований по дресс-коду обычно нет, стоит просто быть опрятным и ориентироваться на “среднюю температуру по больнице” (району), т.е. не идти в Москва-сити в пляжных шортах и сланцах, так же как и не идти в офис на берегу моря в костюме-тройке, всё остальное приемлемо.
+
+В случае онлайна так же необходимо быть на связи уже за 5-10 минут до назначенного времени, поздороваться в чате и сообщить что вы онлайн, устройства должны быть заряжены, интернет стабилен, микрофон и звук настроены и проверены. Приятное впечатление оставят хороший свет и отсутствие постороннего шума. Внешний вид особого значения не имеет, но сидеть с голым торсом и хлебать борщ не стоит (помните про опрятность и здравый смысл). На фон за вами большинству всё равно, хотя сейчас почти везде можно включить размытие.
+
+Главное, что нужно сказать о собеседованиях - их нужно проходить. Регулярно. Это отдельный навык, который утрачивается если не практиковать. Не стоит бояться и относиться к ним как к экзамену, вы и сами это поймете на практике. В знаниях это скорее это как калибровка, нахождение ориентира где вы сейчас находитесь и в какую сторону корректировать курс. Прошли, проанализировали, подкачались - повторяете, пока не будет достигнут приемлемый результат. Некоторые советуют и после устройства на работу периодически ходить на собеседования, чтобы держать этот навык в тонусе и ориентироваться в своей ценности на рынке.
+
+К слову, сейчас можно предварительно потренироваться и на мок-интервью. Основная их цель даже не проверить знания, а помочь преодолеть страх первого собеседования. Посмотреть примеры и узнать как попасть можно в доп. материалах.
+
+Если вы ищете первую работу, начать ходить на собеседования нужно как можно раньше еще и потому, что никто не задумывается, как долго в реальности может занять процесс поиска работы. Самый сложный поиск работы - именно поиск первого опыта. Сначала нужно будет выбить себе возможность пройти интервью. Цифры примерно такие: 10 откликов на подходящие вакансии или 100 рассылкой = 1 собес. 10 не заваленных собесов = 1 оффер. Принятие решения компанией может занимать пару недель. В некоторых компаниях этапов может быть штук 7. Средне-оптимистичный сценарий предполагает от 2-3 месяцев с нуля до начала работы, но это в случае наличия вокруг выбора и хорошей подготовки у кандидата (а на этот счет тоже многие заблуждаются). В не идеальном случае процесс займет от полугода (и даже год не редкость).
+
+Основное, что хочется сказать про само собеседование:
+
+* Узнай всё что можешь о компании, в которую идешь проходить собеседование.
+* Не переживай и не накручивай себя. Волнение - стандартная реакция и опытный рекрутер сначала поговорит за жизнь и презентует компанию пока кандидат приходит в себя.
+* Не скромничай и не занижай свои навыки. Ты, возможно, 50-й кандидат на этой неделе и еще 100 будет после тебя. Если будешь мяться - про тебя забудут, как только ты закроешь за собой дверь. Здоровая гипербола и немного красок еще никому не мешали. Но никогда не переходи в ложь.
+
+Потренируйтесь в самопрезентации, записывая себя на видео и пересматривая. Обычно первое, что вас спросят - «расскажите о себе». Основная задача HR - проверить адекватность кандидата, в некоторых случаях еще соответствие определенному заказу из целевой команды (от взглядов до хобби, все что угодно). Помните, что собеседуют в компанию в первую очередь человека (soft skills), а уже потом специалиста (hard skills). Кто-то сравнивает собеседование со свиданием, где за час вы должны понять, подходите ли вы друг другу. Вопросы на этом этапе в основном стандартные, ответы на них лучше расписать заранее, но не заучивать. Заученный ответ обычно выглядит нелепо, а вот сформулировать свои мысли заранее и понять себя бывает полезно.
+
+Хороший базовый рассказ о себе определит дальнейший ход собеседования, HR будет копать вглубь от заинтересовавших фактов. Кстати, не на все вопросы вы будете знать ответ и это нормально. Одна из задач рекрутера проверить, как вы себя ведете и как отвечаете, когда не знаете ответ или если вопрос максимально глупый. Или вас попробуют заставить сомневаться в заведомо правильном ответе (в этот момент вы вспомните передачу “кто хочет стать миллионером”). Умение адекватно и грамотно отвечать на вопросы и отстаивать свою точку зрения очень важно для тестировщика.
+
+Еще хороший совет - всё, что вы скажете, может и будет использовано против вас. В том смысле, что не говорите лишнего или того, в чем плаваете, иначе очень быстро закопаетесь в новых вопросах.
+
+**Вопросы работодателю**
+
+В конце (хотя бывает и в начале) спрашивает собеседуемый! Помните, что это обоюдный процесс? Они выбирают себе кандидата, но и вы выбираете себе компанию. Немного информации для борьбы со стеснением: для компании найм сотрудника очень затратная затея. В крупных компаниях даже есть бонусы сотрудникам за удачную рекомендацию знакомого в размере тысяч 100 и это в контексте затрат на обычный процесс найма просто копейки. Обе стороны заинтересованы закрыть торги прямо здесь и сейчас, так что не бойтесь задавать вопросы и будьте полноценной второй стороной в этих переговорах. Естественно, что задавать нужно полезные и интересующие вопросы, а не устраивать допрос для галочки.
+
+**Общие вопросы:**
+
+* Новая ли это вакансия? Какая проблема решается наймом нового сотрудника? Если не новая, почему ушел предыдущий сотрудник с этого места?
+* Схема карьерного роста, матрица компетенций, период и порядок пересмотра з.п., премии?
+* Что входит в социальный пакет и когда он предоставляется?
+* Условия по испытательному сроку (оплата, возможность сокращения срока, критерии сокращения, задачи);
+* Если работа удаленная или частично удаленная - какая техника предоставляется?
+* Если офис, то как организовано рабочее место, что в него входит? Опенспейс или кабинет? Кресло/стол, софт/железо, наличие работающей вентиляции, нормальное освещение, кухня со всем необходимым, места для отдыха (груши/диваны) и т.п.
+* Как происходит онбординг, прикрепляется ли ментор, с чем к нему можно обращаться?
+* Есть ли KPI, что в них входит?
+* Как часто бывают переработки и оплачиваются ли они?
+* Фиксированы ли начало и окончание рабочего дня? Перерывы, обед?
+* Как осуществляется контроль за сотрудниками: есть ли тайм-трекеры, камеры и т. д.?
+* Практикуется ли компенсация обучения, заинтересован ли работодатель в сертификации, участии сотрудника в митапах, конференциях и т.п.?
+* Наличие корпоративного спортзала?
+* Наличие библиотеки с актуальной литературой?
+
+**Технические моменты:**
+
+* Методология разработки;
+* Для agile периодичность спринтов, размер команды, распределение обязанностей, какие мероприятия проводятся;
+* Стек технологий;
+* В каком виде сейчас тестирование на проекте, пишут ли разработчики юниты и интеграцию, есть ли какая-то документация (на каком языке), процессы, известные проблемы в процессах, как проходит регрессия;
+* Есть ли автоматизация, в каком виде, какие планы в этом направлении;
+
+**Собеседование в иностранные компании**
+
+Процесс найма в иностранные компании комплекснее и сложнее, обычно состоит из нескольких собеседований. Возможные трудности:
+
+* Формальности: соответствие диплома, перевод документов, наличие релевантного опыта и т.п.;
+* Языковой барьер. Вашему собеседнику может быть так же трудно, как и вам;
+* Разница в теории. При подготовке не следует использовать русскоязычные материалы, разница в некоторых моментах довольно существенна;
+* Софт скилы. Уделяется большое внимание взаимодействию с коллегами;
+* Культурные особенности. Некоторые ценности и взгляды могут совершенно не очевидным образом быть разными и при этом иметь решающее значение. Здесь нужно целенаправленно читать статьи о найме или релокации в интересующую страну, там упоминаются эти нюансы и особенности.
+
+Доп. материал:
+
+* [Общие вопросы рекрутеру](https://docs.google.com/document/d/13iAoqjuMf\_OjSsLnPa7Z7YYuu9z1HRzcyzmZ42HcsAY/edit)
+* [Ошибки Junior QA на собеседовании](https://medium.com/@viktoria\_qa/%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B8-junior-qa-%D0%BD%D0%B0-%D1%81%D0%BE%D0%B1%D0%B5%D1%81%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8-24fbc7081123)
+* [Вопросы для собеседования - от кандидата к работодателю](https://habr.com/ru/post/477354/)
+* [Использование метода STAR для успешного прохождения собеседований](https://testengineer.ru/ispolzovanie-metoda-star-dlya-uspeshnogo-prohozhdeniya-sleduyushchego-sobesedovaniya/)
+* [Как собеседовать работодателя?](https://habr.com/ru/post/470227/)
+* [Level up 2021: как собрать лучшие офферы в ИТ](https://www.youtube.com/watch?v=nCHJ0itnNvU)
+* [О чем поговорить на собеседовании с выпускником онлайн-курсов по тестированию](https://habr.com/ru/post/513524/)
+* [Как QA найти «ту самую» компанию и стать тимлидом](https://habr.com/ru/company/headzio/blog/529384/)
+* [Собеседование для QA: резюме, вопросы на интервью, переговоры о зарплате + полезные ссылки](https://habr.com/ru/company/gms/blog/527916/)
+* [Сценарий идеального технического собеседования](https://habr.com/ru/company/mailru/blog/522326/)
+* [Собеседование для собеседующих](https://habr.com/ru/post/431514/)
+* [Обратное собеседование](https://github.com/kix/reverse-interview/blob/master/README.md)
+* [Чек-лист для подготовки к собеседованию на английском](https://www.linkedin.com/pulse/%D1%87%D0%B5%D0%BA-%D0%BB%D0%B8%D1%81%D1%82-%D0%B4%D0%BB%D1%8F-%D0%BF%D0%BE%D0%B4%D0%B3%D0%BE%D1%82%D0%BE%D0%B2%D0%BA%D0%B8-%D0%BA-%D1%81%D0%BE%D0%B1%D0%B5%D1%81%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8E-%D0%BD%D0%B0-%D0%B0%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%BE%D0%BC-mashtalyar/)
+* [Круглый стол «Все грани собеседования»](https://www.youtube.com/watch?v=sx1EluXTUxE)
+* [Идеальное собеседование на позицию QA-инженера: как провести / как пройти](https://mymonday.by/karpovich-qaasp-2019)
+* [Лайфхаки: как получить больше обратной связи после собеседования](https://habr.com/ru/post/546596/)
+* [Оцениваем работодателя на собеседовании. Как понять, что за компания перед тобой?](https://habr.com/ru/company/maxilect/blog/546338/)
+* [25 актуальных вопросов работодателю + комментарии разработчика](https://habr.com/ru/company/gms/blog/548016/)
+* [Почему вам не дают подробный фидбэк после собеседования](https://habr.com/ru/post/547868/)
+* [Страх перед собеседованием: как перестать бояться и начать ходить на интервью](https://javarush.ru/groups/posts/2991-strakh-pered-sobesedovaniem-kak-perestatjh-bojatjhsja-i-nachatjh-khoditjh-na-intervjhju)
+* [50 вопросов потенциальному IT-работодателю](https://klever.blog/50-voprosov-potencialnomu-it-rabotodatelyu/)
+* [Собеседование QA: лайфхаки и скрипты успеха](https://www.youtube.com/watch?v=vmOK5r4bjRU)
+* [Как оценить процессы в компании + комментарии разработчика](https://habr.com/ru/company/gms/blog/555484/)
+* [Вы не просите дать вам работу, вы продаете услугу](https://habr.com/ru/company/vdsina/blog/557606/)
+* [Как новичку в ИТ-сфере показать HR свои лучшие стороны (поиск работы в ИТ)](https://www.youtube.com/watch?v=gt4u7B2ceLI)
+* [Типичные ошибки начинающего QA на собеседовании](https://dou.ua/forums/topic/33943/)
+* [Как найти удаленную работу в зарубежной компании. 10 шагов](https://habr.com/ru/company/gms/blog/553290/)
+* [Плейлист по подготовке к собеседованиям](https://www.youtube.com/playlist?list=PLvItDmb0sZw9FWMw5YGxq\_j0VurFLy8\_Y)
+* [QA-интервью: как решить любую задачу](https://testengineer.ru/qa-sobesedovanie-sovety/)
+* [Как легко пройти собеседование. Тактика подготовки и лайфхаки](https://dou.ua/forums/topic/34957/)
+* [Как должно проходить собеседование на тестировщика и программиста](https://www.youtube.com/watch?v=epLTrUODLCs)
+* [Собеседование QA: вопросы и тестовые задания начинающему тестировщику](https://www.youtube.com/watch?v=vmOK5r4bjRU)
+* [Что можно и чего нельзя делать на собеседовании по тестированию](https://testengineer.ru/chto-mozhno-i-chego-nelzya-delat-na-sobesedovanii-po-testirovaniyu/)
+* [Говорите о том, что важно для вас](https://t.me/shooandendlessagony/88)
+* [Какие вопросы задать работодателю на собеседовании?](https://habr.com/ru/post/655631/)
+* [Антисобеседования](https://habr.com/ru/post/417431/)
+* [Вольный опус про найм, собеседования и трэш на рынке IT-кадров](https://habr.com/ru/post/414243/)
+
+Мок-интервью:
+
+* [Тренировочное собеседование на позицию младшего тестировщика](https://www.youtube.com/watch?v=fLJ1x16MHIc)
+* [Мок собеседование на позицию junior тестировщика](https://www.youtube.com/watch?v=oSAIm6frBJA)
+* [QAGuild: Мок интервью на позицию Senior QA Automation](https://www.youtube.com/watch?v=KqslEN0tiMM)
+* [Тренировочное собеседование junior тестировщика](https://www.youtube.com/watch?v=KZgVzjpHC9I)
+* [Podlodka QA Crew - Публичное собеседование QA лида. Алексей Петров, Ольга Артемьева](https://www.youtube.com/watch?v=PBjYqFNfLhw)
+* [Плейлист “Собеседования в Andersen”](https://www.youtube.com/playlist?list=PLxGuQSFUcmKGVtwIdJoP51vqGuuPwVkeP)
+* [Mock QA Interview for IT Companies with QA Managers](https://www.youtube.com/watch?v=L\_2jiucxOK4)
+* [QUALITY ASSURANCE Interview Questions And Answers! (QA Interview Questions)](https://www.youtube.com/watch?v=V3-hVT1oBB8)
+* [QAGuild: Мок интервью на позицию Middle QA](https://www.youtube.com/watch?v=893iOnzQXMs)
+* [Успешное мок интервью на Senior QA](https://www.youtube.com/watch?v=x\_ztPZc4LEU)
+* [Вадим Ксендзов](https://www.youtube.com/channel/UC6hNNlCXv1ZgdGpziNf83RA)
diff --git a/faq-dlya-novichkov/kak-sostavit-rezyume.md b/faq-dlya-novichkov/kak-sostavit-rezyume.md
new file mode 100644
index 0000000..d9f2acd
--- /dev/null
+++ b/faq-dlya-novichkov/kak-sostavit-rezyume.md
@@ -0,0 +1,47 @@
+# Как составить резюме?
+
+Кратко о базовых рекомендациях.
+
+**В каком виде**:
+
+* Вариант минимум: PDF + расшаренная копия на google-диске. Оформить покрасивее можно [тут](https://www.canva.com/ru\_ru/), [тут](https://novoresume.com/resume-templates) или еще где-то;
+* Вариант получше: резюме в LinkedIn (мастхэв!) + в веб-версии на github-pages + PDF.
+
+**Размер** резюме стажера или джуниора - ровно 1 страница (имеется в виду вариант в файле, а не на площадках).
+
+**Язык** резюме - русский, если нацелены на компании из РФ с клиентами из РФ (или рекрутерами без знания английского :). В остальных случаях - английский.
+
+**Шапку** можно оформить без наворотов: Нейтральное фото, по которому вас можно узнать (в т.ч. если распечатать в ч/б), ФИО, на какую позицию претендуете, актуальные контакты, опционально локация.
+
+**Опыт работы** (любые практические навыки) идет сразу после шапки. Это самая важная часть резюме. Без лишней воды кратко и емко описывается чем конкретно вы занимались. Общее правило - использовать глаголы совершенного вида (сделал то, там-то; а делал, участвовал - ничего о вас не говорит), а еще лучше в формате «зона ответственности + достижения». Если занимались учебными проектами или самодеятельностью, то обязательно нужна ссылка на github с артефактами. Написать можно всё что угодно, а вот пруфы прикладывают немногие.
+
+**Навыки и технологии**. С чем работали, что умеете. Никогда не используйте банальные ключевые навыки «ответственный, целеустремленный, …». Только конкретика. Помните, что HR часто ищут по ключевым словам, а вы не должны раздувать ваше резюме всяким мусором. Технологии, инструменты - хороший выбор. Но будьте готовы, что вас по ним детально будут спрашивать в первую очередь. Не забудьте упомянуть знание иностранных языков. Сориентироваться поможет: [раз](https://www.cambridgeenglish.org/test-your-english/), [два](https://play.google.com/store/apps/details?id=com.englishscore), [три](https://www.efset.org/ru/ef-set-50/), [четыре](https://training.by/#!/Training/3101?lang=ru). Владение технологиями также нужно доказать артефактами в гитхабе (коллекции из постмана, экспорт из TMS/BTS, код и т.п.).
+
+**Образование и самообразование**. Университет, курсы, книги и т.п. Кратко и по существу. От свежего к старому.
+
+**Раздел «О себе»** можно включить, если есть что важного и интересного написать, опять же, коротко и если есть чем выделиться.
+
+При отклике на вакансию встает вопрос о сопроводительном письме. Чаще всего их всё-таки читают, но не надо их писать просто для галочки, это сразу бросается в глаза и идет в минус. Тут лучше поступать аналогично с разделом “О себе” - пишите только если это действительно нужно, т.е. вы ознакомились с информацией о компании, вам есть чем выделиться среди других кандидатов и вы точно можете описать какие ваши навыки и как пригодятся бизнесу нанимателя. Для компании найм джуна это очень дорого и хорошо если кандидат начнет окупаться после полугода в штате, поэтому разговор с работодателем на понятном ему языке доход/расход может вас выделить из серой массы.
+
+Вообще на тему составления резюме в IT есть миллион статей ([пример](https://hurma.work/rf/blog/idealnoe-rezyume-kandidata-mif-ili-realnost-2/)) и видео на youtube, да и не стоит исключать фактор личных пристрастий нанимателя, так что следует просто следовать базовым рекомендациям и периодически корректировать в зависимости от результатов, а если всё плохо, то можно скинуть итоговый вариант на оценку в коммьюнити.
+
+Насчет самих откликов, тут на мой взгляд уместна аналогия с холодными звонками, т.е. не нужно на начальном этапе выбирать место работы так, будто у вас лишь один шанс и вы собираетесь в ней состариться. Вообще слать резюме стоит не только откликаясь на вакансии. Есть мнение, что когда компания выкинула вакансию на работные сайты, это уже тупик (т.к. не нашли кандидата по своим каналам). Шлите на почты IT-компаний, HR-ов, расширяйте сеть контактов в linkedin и т.п.. Слышал, что активные джуны рассылали по несколько сотен писем в неделю. Стоит ли говорить, что они быстро нашли свою первую работу?
+
+Дополнительно я бы посоветовал ознакомиться с разными типами компаний. Работа в инхаус и аутсорс заметно отличается и помимо просто понимания, куда бы вам больше хотелось, преимуществом будет знать, как подогнать резюме и отклик под конкретный тип.
+
+Доп. материал:
+
+* [Идеальное резюме кандидата: миф или реальность](https://hurma.work/rf/blog/idealnoe-rezyume-kandidata-mif-ili-realnost-2/)
+* [Что писать в резюме, если нет опыта работы](https://habr.com/ru/post/470684/)
+* [Инхаус, фриланс, аутсорс компания: куда приземлиться тестировщику, чтобы не разлюбить профессию и расти как на дрожжах](https://habr.com/ru/post/542952/)
+* [Аутсорсинг или продуктовая компания для тестировщика (QA)](https://www.youtube.com/watch?v=UPEytnAiqtk)
+* [Как составить резюме на английском для иностранной компании](https://habr.com/ru/company/yandex\_praktikum/blog/545418/)
+* [Резюме для тестировщика. Структура, оформление, рекомендации](https://www.youtube.com/watch?v=tOUFyzeslvE)
+* [Разбор резюме тестировщика (QA) / Ответы на вопросы](https://www.youtube.com/watch?v=xrLydVVkNDE)
+* [Как написать классное резюме и получить работу в тестировании? (обработанная версия)](https://www.youtube.com/watch?v=OCupdpk4nf8)
+* [Как составить резюме тестировщика ? Обзор, примеры, советы](https://www.youtube.com/watch?v=9zVK776K7MQ)
+* [Топ-5 ошибок в резюме junior тестировщика. Как улучшить свое резюме](https://www.youtube.com/watch?v=PznWqzCGmtY)
+* [Советы по составлению резюме для новичка](https://testengineer.ru/sovety-po-sostavleniyu-rezyume-dlya-novichka-v-it/)
+* [Разбор резюме тестировщика (QA) 2022](https://www.youtube.com/watch?v=Rw7stX87RHw)
+* [Как составить резюме тестировщику](https://medium.com/@a\_tumanenko/%D0%BA%D0%B0%D0%BA-%D1%81%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%B8%D1%82%D1%8C-%D1%80%D0%B5%D0%B7%D1%8E%D0%BC%D0%B5-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D1%89%D0%B8%D0%BA%D1%83-c47b3b571d00)
+* [10 глупых вопросов рекрутеру](https://telegra.ph/10-glupyh-voprosov-rekruteru-03-21)
diff --git a/faq-dlya-novichkov/kak-vzaimodeistvovat-s-kollegami.md b/faq-dlya-novichkov/kak-vzaimodeistvovat-s-kollegami.md
new file mode 100644
index 0000000..c3e453c
--- /dev/null
+++ b/faq-dlya-novichkov/kak-vzaimodeistvovat-s-kollegami.md
@@ -0,0 +1,71 @@
+# Как взаимодействовать с коллегами?
+
+**Как правильно задавать вопросы?**
+
+В чатах, коллегам, на форумах, где угодно:
+
+* в случае общественных чатов убедитесь, что ответа нет в описании канала или в закрепленном сообщении, а также что ваш вопрос уже не задавали раньше (99% задавали). Проверьте поиском по истории сообщений;
+* прочитайте внимательно [https://nometa.xyz/](https://nometa.xyz);
+* убедитесь, что вы потратили уже достаточно времени в гугле и у вас ничего не вышло;
+* сформулируйте вопрос со всем контекстом, чтобы любой человек мог не напрягаясь его понять;
+* опишите все ваши действия и результаты, в т.ч. не увенчавшиеся успехом;
+* сформулируйте предельно ясно и четко с чем вы просите помочь;
+
+**Как общаться с разработчиками?**
+
+Нельзя:
+
+* Не отвлекайте программиста по мелочам. Сначала задайте свой вопрос в мессенджере, либо договоритесь о встрече, если уж очень жаждете личного общения. Я понял это, как только начал программировать сам. Когда вы творите, и кто-то отвлекает вас, требуется много времени и сил, чтобы снова погрузиться в состояние сосредоточения. Такие перерывы нарушают продуктивность.
+* Не бойтесь просить о помощи. Вы не можете знать все. Спрашивать - это нормально! Просто убедитесь, что вы поняли ответ, - не задавайте один и тот же вопрос дважды. Главный принцип командной работы при реализации проекта “Мы в одной лодке и всем будет хорошо, если у каждого будет весло.”. Он позволяет двигаться дальше в одном направлении.
+* Главное правило QA - никогда не верить словам разработчиков! «Все должно быть хорошо!» или «Я изменил одну строку в коде, это ничего не сломает» - фразы, после которых стоит насторожиться и перепроверить проект.
+* Не вините разработчика в ошибке. Не зацикливайтесь на негативе, попытайтесь решить проблему. Позже всей командой обсудим, как избежать того или иного случая в будущем. Никто не идеален. Ошибки неизбежны. Основная цель - иметь возможность быстро отреагировать на проблему и качественно выполнить свою работу.
+* Не назначайте конкретного разработчика на дефект. В этом есть аналогия с тем как разработчик закрывает тикет без одобрения QA. Подобное поведение может разозлить
+* Не занимайтесь микро менеджментом над разработчиком. «Ты посмотрел багу?», «Как насчет сейчас?», «Когда ты исправишь багу?». Это раздражает, не уменьшая сроки решения проблемы. Поставьте себя на место работника, выполняющего задачи в строгой последовательности. Подобные “пинки” нецелесообразны.
+* Не принимайте все близко к сердцу, с “толстой кожей” живется проще. Чрезмерная эмоциональность (негативная) - кратчайший путь к выгоранию. Не позволяйте своим чувствам преобладать над здравым смыслом. В любой момент времени на вашем пути могут попасться высокомерные люди, которых придется терпеть, выполняя при этом поставленные цели и задачи. Правило применимо относительно любого специалиста. “Толстая кожа” столь же необходима, как и тактичность.
+
+Правильно:
+
+* Обмен знаниями с разработчиками. Сообщите им о своих подходах к тестированию, найдите «access\_key» для каждого разработчика, с которым вам приходится работать. Расскажите о том, как вы собираетесь тестировать продукт. Это поможет избежать некоторых ошибок в коде. Однако такое взаимодействие не всегда возможно по нескольким причинам:
+ * нехватка времени;
+ * организация процессов внутри компании, не позволяющая этого сделать;
+ * банальное нежелание разработчика сотрудничать с тестером.
+* Если вы все же сможете найти тот самый «access\_key», который упоминался мною выше, - будет гораздо легче поддерживать здоровые отношения и хорошее качество продукта в долгосрочной перспективе.
+* Будьте честны. В противном случае это разрушит вашу репутацию.
+* Будьте готовы защищать дефекты, о которых сообщаете. Иногда приходится отстаивать критичность дефектов, которые необходимо исправить. Со временем это становится проще, когда вы способны озвучить четкую аргументацию с обоснованием того, почему дефект должен быть исправлен. Корректное формирование фактов и умение видеть на несколько шагов вперед помогает сэкономить деньги компании.
+* Сохраняйте хладнокровие под давлением. Я знаю, это тяжело. Когда все торопят тебя или твою команду сложно противостоять авторитетам. Однако говорить «нет» - часть нашей работы, даже если это устраивает далеко не всех.
+* Обсудите тестовые кейсы с разработчиком. По моему опыту, это очень сложно сделать. Данный процесс требует много времени и силы воли. Со своей стороны QA в таких “переговорах” должен быть харизматичен и крайне убедителен. Я занимался подобным некоторое время, но так и не смог научиться правильно внедрять данный подход в собственную работу. Однако от таких переговоров с разработчиком есть очевидная польза. Они расширяют спектр мнений и позволяют учитывать кейсы, которые изначально даже не рассматривались, как потенциально перспективные.
+* Описывайте дефекты понятно. Говорите на языке разработчика, если можете. В ином случае, старайтесь писать как можно проще. Хорошо описанный баг со всей его информативностью и полнотой погружения в проблему со стороны разработчика будет максимально быстро исправлен. Соответственно, команда QA оперативно приступит к повторному тестированию проблемного участка.
+* Поощряйте заинтересованность членов команды в глубоком изучении продукта. Максимальная осведомленность специалиста позволяет минимизировать число глупых дефектов. По моему опыту, такие несущественные ошибки забирают у команды слишком много времени и сил. Лучше предугадать возможные нецелесообразные действия и сосредоточиться на более важных вещах, чем тратить время на описание несущественных дефектов, которых, возможно, вовсе и нет.
+* Терпение, только терпение. Научитесь справляться с трудными и самовлюбленными людьми. Это общее правило, применимое к любой сфере, как и в случае с хладнокровием.
+
+**Как решать конфликты?**
+
+По действию на функционирование команды, конфликты делятся на деструктивные и конструктивные. Конструктивные (функциональные) конфликты - это продуманные дискуссии, которые возникают из-за того, что члены команды имеют разные точки зрения. Конструктивные конфликты начинаются с открытого общения и ведут к дальнейшей коммуникации и соглашению. Деструктивные (дисфункциональные) конфликты препятствуют эффективному взаимодействию и принятию решений (конкурентные отношения, чувство обиды, плохое настроение и т.д).
+
+Отличие конфликта в удаленной команде в инструментах. Инструменты в удаленной работе отличаются от тех, которые мы используем обычно в офисе. У нас только удаленные средства связи. Личное и непосредственное взаимодействие сильно ограничено или полностью исключено. Тактика избегания конфликтов, в условиях удаленной работы, весьма соблазнительна. В офисе, когда неприятные разговоры касаются работы, мы можем использовать массу средств для смягчения остроты разговора: например, сходить вместе пообедать, попить кофе.
+
+Что может спровоцировать конфликт? Средства удаленной связи могут спровоцировать конфликт. А именно потеря невербальных сигналов. Например, одно и то же сообщение может иметь множество интерпретаций. При удаленной коммуникации у нас гораздо меньше возможностей для понимания смысла сказанного.
+
+Как разрешить конфликтную ситуацию и провести важную беседу?
+
+* Для начала запланируйте встречу с коллегой на определенное время.
+* Во время разговора сформулируйте свою позицию в такой последовательности:
+ * Озвучьте свое наблюдение: что коллега сделал, что вам не понравилось.
+ * Выразите словами свои чувства и свою реакцию.
+ * Выразите словами значимую для вас потребность, которая была проигнорирована.
+ * Предложите решение или сформулируйте ясный запрос.
+* После разговора следует зафиксировать ваши договоренности.
+
+Источники:
+
+* [Набор правил для общения между разработчиком и QA инженером](https://habr.com/ru/post/648601/)
+* [Как решать конфликты в удаленной команде](https://t.me/qa\_chillout/100)
+
+Доп. материал:
+
+* [Коллеги: и не друг, и не враг, а как?](https://habr.com/ru/company/regionsoft/blog/497396/)
+* [И жили они долго и счастливо: как QA выстроить плодотворное взаимодействие с dev](https://habr.com/ru/company/ispring/blog/645229/)
+* [О конфликтах QA vs Dev, QA vs Product: почему так получается и что с этим делать](https://habr.com/ru/company/skyeng/blog/577010/)
+* [Почему разработчики иногда отказываются исправлять баги](https://dou.ua/forums/topic/35024/)
+* [Управление конфликтами](https://t.me/general\_it\_talks/204)
+* [Как "продать" баг разработчику](https://www.youtube.com/watch?v=wGyAW3l\_SxA)
diff --git a/faq-dlya-novichkov/nachalo-raboty-junior-testirovshika.md b/faq-dlya-novichkov/nachalo-raboty-junior-testirovshika.md
new file mode 100644
index 0000000..0b86b25
--- /dev/null
+++ b/faq-dlya-novichkov/nachalo-raboty-junior-testirovshika.md
@@ -0,0 +1,37 @@
+# Начало работы Junior-тестировщика
+
+Тут снова всё индивидуально и зависит от компании и даже проекта, в частности от типа компании (инхаус, аутсорс, аутстаф), размера штата, процессов и текущих задач.
+
+**Онбординг**
+
+* **Один тестировщик**: если вас угораздило быть на первой работе единственным тестировщиком, то скорее всего вас познакомят с коллегами, кофемашиной и расскажут о продукте (а вы уже сами должны знать о нем всё что возможно узнать заранее), после чего сходу бросят на амбразуру искать баги, писать кейсы и попутно будут отвечать на вопросы;
+* **Отдел тестирования**: в крупных компаниях обычно есть налаженный процесс онбординга, который начинается с выдачи прав доступа, настройки рабочих учеток и рабочей станции, знакомства с внутренней структурой проекта и компании, ознакомления со стеком технологий и инструментами. К вам прикрепляют ментора и рассказывают к кому и с какими вопросами можно обращаться.
+
+В любом случае каких-то значимых результатов от новичков первое время никто ждать не будет, обычно есть минимум один “золотой” месяц, когда сотрудника сюсюкают как младенчика на второстепенных задачах, пока тот не вольется в работу, так что не накручивайте себя заранее.
+
+**Первые задачи**
+
+* **Один тестировщик**: В нормальной ситуации вы проведете исследовательское тестирование, составите несколько наборов кейсов или чеклистов, задокументируете все текущие баги и в дальнейшем будете заниматься тестированием новых сборок, проверкой исправления найденных дефектов и проведением регрессии;
+* **Отдел тестирования**: Вам назначат посильные, но, вероятно, рутинные задачи, вроде регрессии, актуализации артефактов и т.п.
+
+**Советы единственному джуну тестировщику**
+
+Вообще создавать отдел тестирования нанимают QA Lead, а если вы джун без опыта работы, то либо работодатель не понимает что делает, либо у него есть вполне конкретная “боль”, которую он с помощью тестировщика хочет решить, в таком случае проводить целое расследование не придется - наверняка все объяснят еще на собеседовании.
+
+Начинать знакомство с проектом лучше с интервью. Станьте журналистом. Что из себя представляет структура организации, а именно кто над кем стоит и кто за что отвечает? Где больше всего багов, каким видят тестирование сейчас и какие ожидания в будущем? Оцените зрелость процессов по CMM и TMM, зрелость проекта (новый/старый-зрелый/старые-зрелые где будут глобальные изменения) и команды, определите методологию разработки. Соберите метрики, подбейте статистику, подумайте как на эту статистику можно повлиять. Проведите вводную лекцию команде: что такое QA, как оно может помочь, с какими проблемами обращаться и зачем всё это надо.
+
+Далее в зависимости от всего этого выбирайте в разделе процессов или на просторах интернета вебинар/статью о процессах (можно поинтересоваться опытом коллег в коммьюнити или поискать по истории) и сверяясь с целями компании аккуратно приступайте к внедрению оных. Нужно будет их обдумать и внедрить хотя бы на ключевые моменты: этап составления требований, этап проверки нового функционала перед вливанием в основной, этап регрессии, этап предоставления отчетности.
+
+Доп. материал:
+
+* [Welcome on board или по ту сторону оффера](https://habr.com/ru/post/550864/)
+* [Введение тестировщика в проект и процесс тестирования](https://www.youtube.com/watch?v=DyeDxg6Olh8)
+* [Как выжить на новой работе или онбординг снизу](https://red-foks.medium.com/%D0%BA%D0%B0%D0%BA-%D0%B2%D1%8B%D0%B6%D0%B8%D1%82%D1%8C-%D0%BD%D0%B0-%D0%BD%D0%BE%D0%B2%D0%BE%D0%B9-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B5-%D0%B8%D0%BB%D0%B8-%D0%BE%D0%BD%D0%B1%D0%BE%D1%80%D0%B4%D0%B8%D0%BD%D0%B3-%D1%81%D0%BD%D0%B8%D0%B7%D1%83-8e95c7c4ac0c)
+* [Один день из жизни тестировщика (QA Engineer)](https://www.youtube.com/watch?v=KIrbcOdNDZI)
+* [Как вырастить джунов - советы бывалых из 2ГИС](https://habr.com/ru/company/2gis/blog/649175/)
+* [Как я попала в большую корпорацию: ожидания и реальность](https://habr.com/ru/company/dell\_technologies/blog/583064/)
+* [Один тестировщик на проекте - Советы по организации работы](https://www.youtube.com/watch?v=yL5TNJsgjkM\&feature=youtu.be)
+* [Один тестировщик на проекте - Личный опыт](https://www.youtube.com/watch?v=KkgDW2kRDNo)
+* [Тестирование с нуля, или Один в поле - тестировщик](https://habr.com/ru/company/citymobil/blog/589729/)
+* [Технический онбординг: тяжело в учении - легко в бою!](https://www.youtube.com/watch?v=tGu5IVlCL8o)
+* [11 кругов ада для тех, кому не хватает опыта на новой работе](https://habr.com/ru/post/414471/)
diff --git a/faq-dlya-novichkov/oshibki-v-rabote-u-nachinayushikh-testirovshikov.md b/faq-dlya-novichkov/oshibki-v-rabote-u-nachinayushikh-testirovshikov.md
new file mode 100644
index 0000000..4054870
--- /dev/null
+++ b/faq-dlya-novichkov/oshibki-v-rabote-u-nachinayushikh-testirovshikov.md
@@ -0,0 +1,32 @@
+# Ошибки в работе у начинающих тестировщиков
+
+* Во всем видят дефекты. Как избежать:
+ * Внимательно анализировать требования
+ * Владеть информацией о том, как должен работать продукт
+ * Если сомневаешься, что это дефект - спроси БА или ответственного
+ * Несколько раз перепроверь прежде чем регистрировать дефект
+* Пытаются сразу все сломать. Как избежать:
+ * Начинать тестирование только с положительных тестов
+ * Акцентировать внимание на том, что в приоритете для заказчика
+ * Не проверять редкие сценарии в первую очередь
+* Боятся задавать вопросы. Как избежать:
+ * Начать понимать, что коммуникация это важная и неотъемлемая часть работы
+* Не интересуются, кто и за что отвечает, как устроены процессы. Как избежать:
+ * Узнать у ПМ об областях ответственности каждого члена команды
+ * Узнать у ПМ о всех процессах на проекте
+* Паникуют при малейшей трудности. Как избежать:
+ * Без паники, п. 3 и 4 помогут разобраться
+* Пытаются применить сразу все, что изучили. Как избежать:
+ * Помнить, что у каждого вида тестирования своя цель
+ * Бюджет всегда ограничен, расставлять приоритеты
+* Задают один и тот же вопрос несколько раз.
+
+Доп. материал:
+
+* [Шесть тест-персон, с которыми не стоит иметь дела](https://telegra.ph/SHest-test-person-s-kotorymi-ne-stoit-imet-dela-01-02)
+* [Лучше не знать и спросить, чем притворяться, что знаешь, или Шесть подсказок новичку в тестировании](https://ru.hexlet.io/blog/posts/shest-podskazok-novichku-v-testirovanii)
+* [Мои 3 ошибки, которые я совершала как junior QA engineer](https://abilmazhinova.medium.com/%D0%BC%D0%BE%D0%B8-3-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B8-%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5-%D1%8F-%D1%81%D0%BE%D0%B2%D0%B5%D1%80%D1%88%D0%B0%D0%BB%D0%B0-%D0%BA%D0%B0%D0%BA-junior-qa-engineer-10290234e949)
+* [7 QA-шных грехов, которые помогут или помешают тестировщику (стать тем, кем ты хочешь)](https://habr.com/ru/company/skyeng/blog/558656/)
+* [Сегодня - трейни, а завтра - сеньор. Что может быть не так с самооценкой у новичков](https://habr.com/ru/company/nix/blog/557238/)
+* [ТОП-10 ошибок тестировщиков, что приводят к блокерам](https://zen.yandex.ru/media/id/5e5822dfab3f5c1a51912a0f/top10-oshibok-testirovscikov-chto-privodiat-k-blokeram-611e8b4a271b2c7f7793431d)
+* [Как решать сложные (технические) проблемы?](https://habr.com/ru/company/itelma/blog/554746/)
diff --git a/faq-dlya-novichkov/otvety-na-samye-populyarnye-voprosy-novichkov-v-chatakh.md b/faq-dlya-novichkov/otvety-na-samye-populyarnye-voprosy-novichkov-v-chatakh.md
new file mode 100644
index 0000000..69e12e3
--- /dev/null
+++ b/faq-dlya-novichkov/otvety-na-samye-populyarnye-voprosy-novichkov-v-chatakh.md
@@ -0,0 +1,118 @@
+# Ответы на самые популярные вопросы новичков в чатах
+
+**Хочу войти в айти (в разработку) через тестирование, хороший план?**
+
+Это работало несколько лет назад, потому что тогда к новичкам-тестировщикам могло вообще не быть никаких требований кроме здравомыслия, но общий технический уровень в индустрии сильно вырос, а после эпидемии и агрессивной рекламы работы в IT со стороны “обучающих” компаний появились тысячи выпускников курсов по тестированию, так что этого “легкого пути вкатиться в айтишечку” уже нет и не будет и не нужно вестись на рекламу этих инфоцыган. Конкурс на одно место на удаленку может доходить до нескольких сотен человек. Конечно, в разработке тоже конкуренции поприбавилось, но если вы нацелены стать программистом, то никакие вхождения через другие специальности не имеют ни малейшего смысла - тестирование и разработка - разные профессии и опыт работы джуниор тестировщиком вам практически ничем не пригодится, вы лишь потратите время на подготовку к собеседованиям (а требования теперь весьма высокие), а потом еще на переобучение непосредственно той специальности, куда хотели изначально, т.к. опыт по сути не релевантен и спрашивать будут с нуля. Кейс перехода из тестирования в разработку (впрочем как и наоборот) встречается только у опытных специалистов и по совсем другим причинам.
+
+Если же говорить просто о желании работать где-нибудь, лишь бы в сфере информационных технологий, то тяп-ляп быстренько прочитать пару книжек и сразу устроиться чтобы получать много денег тут не прокатит. Стоит изучить огромный перечень специальностей и понять для себя, что из этого ближе и развиваться сразу в нужном направлении, как бы невозможно это ни казалось.
+
+Доп. материал:
+
+* [Как войти в айти через тестирование](https://youtu.be/Cc2biin9304?t=11497)
+* [Мифы о тестировании #2 / О чем не говорят на курсах по тестированию / Правда о работе в IT](https://www.youtube.com/watch?v=qiCjqqtWP7I\&t=31s)
+* [Мифы и легенды о тестировании](https://habr.com/ru/post/647701/)
+* [Почему профессия QA сложная и интересная, а не только простой «вход в IT»](https://dou.ua/forums/topic/33947/)
+* [Why I Love Software Testing](https://jarbon.medium.com/why-i-love-software-testing-ec23d5037dab)
+* [Программирование - это сложно](https://habr.com/ru/company/vdsina/blog/551302/)
+* [Распространенные поисковые запросы, часть 6: "Легко ли тестировать?"](https://software-testing.ru/library/testing/general-testing/3636-6-is-software-testing-easy)
+* [10 причин почему тестировщики увольняются](https://www.youtube.com/watch?v=jgqKLw8YAd4)
+* [На пути в IT: легко ли стать тестировщиком?](https://habr.com/ru/company/e-legion/blog/574856/)
+* [4 страха, мешающие стать тестировщиком в международной компании](https://habr.com/ru/company/dell\_technologies/blog/599523/)
+* [Бесплатный курс профориентации в IT](https://practicum.yandex.ru/career-advisor/)
+* [Каково быть тестировщиком: 4 истории о боли и радости](https://habr.com/ru/company/skypro/blog/649349/)
+* [Как зарабатывать миллион в IT если ты раздолбай без образования. Фил Ранжин - Как мы попали в IT](https://www.youtube.com/watch?v=N-IFG8gD7Gg)
+
+**Хочу зарабатывать много денег, мне сюда?**
+
+Первые зарплаты будут небольшими (особенно учитывая конкурс на места), а подняться выше по карьерной лестнице без искреннего интереса не получится, тестирование - слишком обширная область знаний. Без внутренней мотивации к ежедневному самообучению не получится зарабатывать больше чем в любой другой профессии на старте. Так что сферу деятельности стоит менять только если вы всю жизнь чувствовали, что занимаетесь не тем, а тут ёкнуло и хочется взахлеб осваивать именно тестирование. Но даже в этих случаях нужно понимать, что тестирование - не рекордсмен по зарплатам. Далеко не всем компаниям требуются эксперты тестировщики, как это может быть в случае с разработчиками. Именно по этой причине существует отток уже проработавших какое-то время в тестировании специалистов, в другие направления: менеджмент, чистая автоматизация, разработка. Фактически они просто не смогли найти дальнейшие пути развития своих навыков или спрос на свои навыки в текущем рынке при желаемых условиях. Соответственно и зарплаты здесь в среднем ниже, чем на многих специальностях в IT.
+
+Доп. материал:
+
+* Статистика зарплат: [Россия](https://career.habr.com/salaries), [Украина](https://jobs.dou.ua/salaries/), [Беларусь](https://salaries.dev.by)
+* [Сколько зарабатывают тестировщики в Европе?](https://www.youtube.com/watch?v=Cbhp1rDRLE0)
+* [Зарплати українських тестувальників - зима 2022](https://dou.ua/lenta/articles/salary-report-qa-winter-2022/)
+* [Зарплаты айтишников во втором полугодии 2021 (РФ)](https://habr.com/ru/article/649423/)
+* [glassdoor](https://www.glassdoor.com/Salaries/index.htm)
+* [djinni](https://djinni.co/salaries/)
+* [levels.fyi](https://www.levels.fyi)
+* [Зарплаты тестировщиков](https://www.youtube.com/watch?v=qk44Mr8Qg\_Y)
+* [Начальная зарплата QA в США. Работа в Америке. Как стать тестировщиком?](https://www.youtube.com/watch?v=nA0k9QlC5RA)
+* [Тред про зарплаты в айти и их формирование](https://twitter.com/annmuor/status/1446846723591217155?s=)
+* [Почему все «прутся» в IT](https://habr.com/ru/company/headzio/blog/593987/)
+* [Why Experience Is More Important Than Money Early in Your Career](https://betterprogramming.pub/why-experience-is-more-important-than-money-early-in-your-career-6527219f3915)
+* [Сколько стоят тестировщики и от чего зависят их зарплаты? Строим портрет успешного QA-специалиста](https://habr.com/ru/post/446650/)
+* [Детальный разбор структуры зарплат IT-специалистов в Кремниевой Долине](https://habr.com/ru/post/512598/)
+
+**Мне 30/40/50, кому-то нужен такой старик в команде?**
+
+Хорошая новость в том, что на возраст в IT чаще не смотрят. Безусловно, есть и молодые команды, куда возрастной коллега не впишется. Но в это же время существуют множество других команд, где возраст нового коллеги не имеет значения. Другой вопрос в том, можете ли вы:
+
+* поспеть в обучении за вчерашними студентами;
+* подчиняться 25-летнему руководителю;
+* понять, что работодателю не нужен “дед”, который будет учить его и команду жизни.
+
+Можно поискать по истории сообщений в QA-сообществах телеграма, там этот вопрос неоднократно поднимался и там же есть истории смены сферы деятельности и успешного трудоустройства и в 40+ и в 50+.
+
+Доп. материал:
+
+* [Беда “войти в айти” или курсы тестировщика отзывы: Сэм Канер о входящих после 40 и не только](https://habr.com/ru/post/647611/)
+* [Джуном? в 40 лет? Ещё и на удаленку? Да ну, не выдумывайте…](https://habr.com/ru/post/548606/)
+* [Как стать ТЕСТИРОВЩИКОМ в 45 лет ? Плюсы и Минусы работы в QA](https://www.youtube.com/watch?v=vvGn0BDBpyc)
+* [В тестировщики после 40 лет - плюсы в смене профессии, обучении. Мотивация.](https://www.youtube.com/watch?v=jP9IQX-iKbo)
+
+**Хочу работать удаленно джуном, это возможно?**
+
+Плохая новость в том, что шансы устроиться на удаленку специалисту без опыта сами по себе довольно низкие - высокая конкуренция, к тому же компании охотнее берут начинающих в офис (так эффективнее обучать). Поэтому попробовать, конечно, стоит, но рассчитывать на это особо не нужно. Да и начинающему действительно продуктивнее находиться в офисе вместе со всей командой, в гуще событий.
+
+Если говорить о работе на иностранные компании, то тут без вариантов. По законодательству обычно нанять могут только серьезных специалистов.
+
+**Обязательно ли прохождение курсов для дальнейшего трудоустройства?**
+
+Совершенно нет. Безусловно, у _хороших_ курсов есть преимущества:
+
+* Педагогический дизайн, последовательность и структурированность;
+* Личный опыт преподавателей и примеры из практики;
+* Свой тестовый проект для практики, дающий похожий опыт с реальным (или хотя бы просто задания, которые проверяет опытный наставник);
+* Сообщество одногруппников;
+* Выход из зоны комфорта: вы участник процесса, вы потратили кучу денег на курс;
+* Меньше time-to-market.
+
+Однако, вся теория есть в свободном доступе в десятках различных вариантов изложения и форматах, а за громкими рекламными лозунгами курсов может стоять записанная на видео посредственная информация и обучение без участия опытных наставников. Даже некоторым джунам порой поступают предложения подрабатывать преподавателями в популярных инфоцыганских “школах”.
+
+Работодателя сертификат таких курсов может наоборот отпугнуть. Сертификат хороших курсов сам по себе вам также не сильно поможет, т.к. спрашивать на собеседовании всех будут одинаково. И уж тем более ни один курс вам не гарантирует автоматическое трудоустройство, даже если это якобы прописано в договоре. Также стоит понимать, что далеко не все в итоге заканчивают курс, судя по тому, что видел лично я, это лишь около 20% участников.
+
+Весомая часть людей в профессии - самоучки. Если уверены в своей способности самостоятельно обучаться и на это есть время, то дерзайте.
+
+Доп. материал:
+
+* Беда “войти в айти” или курсы тестировщика отзывы [часть 0](https://habr.com/ru/post/588360/), [1](https://habr.com/ru/post/588376/), [2](https://habr.com/ru/post/589973/), [3](https://habr.com/ru/post/590249/)
+* [Об онлайн-образовании](https://t.me/yetanotherqa/117)
+
+**У меня нет высшего образования или я гуманитарий, всё пропало?**
+
+Зависит от требований нанимателя, но в большинстве случаев само наличие диплома никому не интересно, т.к. это ещё ни о чем не говорит (разве что есть какие-то достижения за время учёбы). Обычно такое требование можно увидеть только в вакансиях крупных компаний, да и то на деле оно чаще оказывается не обязательным. Не-техническая же специализация может оказаться вполне полезной, потому как бухгалтеров-экономистов охотно возьмут тестировать финтех, медиков соответственно медицинское ПО и т.д., а диплом переводчика вообще открывает некоторые двери автоматически.
+
+Доп. материал:
+
+* [Чтоб стать тестером и программистом нужен диплом?](https://www.youtube.com/watch?v=fqE2vvezQxI)
+
+**Я всю жизнь работал %название должности%, это может как-то пригодиться в тестировании?**
+
+По аналогии со сказанным выше, потенциально почти любой опыт можно как-то использовать в тестировании. Если говорить о максимально близкой работе, с которой чаще всего и растут сюда, то это техническая поддержка, реже эникеи и начинающие “сисадмины”.
+
+Доп. материал:
+
+* [Как я перешла в тестирование](https://habr.com/ru/company/maxilect/blog/562160/)
+* [From Support to QA: A Journey in Testing](https://www.softwaretestingnews.co.uk/from-support-to-qa-a-journey-in-testing/)
+* [Из РЖД в тестирование QA с нуля. Как войти в айти? Реальная история Стаса](https://www.youtube.com/watch?v=qBX7My4LGZU)
+
+**У меня старый компьютер, придется купить макбук про для работы?**
+
+В офисе или на удаленке в приличной компании вас всем обеспечит работодатель. Если же вы сами по себе или просто хотите узнать приемлемую конфигурацию, то для мануального тестировщика ресурсы рабочей машины и операционная система глобального значения не имеют, для комфортной работы ориентируйтесь на последнюю версию ОС, CPU 4 ядра/4 потока с поддержкой виртуализации + SSD + 8Gb RAM - этого хватит для любых задач. Если смотреть на перспективу, то для контейнеров, эмуляторов и всего такого потребуется больше потоков и от 16Gb оперативки. При использовании эмулятора вам пригодится поддержка аппаратного ускорения видео у APU или дискретной видеокарты.
+
+Доп. материал:
+
+* Больше ответов на вопросы новичков можно найти, например, [тут](https://www.instagram.com/rusau.qalife/)
+* [Плейлист “Карьера в IT”](https://www.youtube.com/playlist?list=PLvItDmb0sZw\_uOoxIR5EIaOkYksdAq7ks)
+* [Из грузчика в QA без регистрации и смс](https://habr.com/ru/company/petrovich/blog/582824/)
+* [Приключения филологической девы в IT и советы начинающим тестировщикам](https://habr.com/ru/company/quadcode/blog/592615/)
diff --git a/faq-dlya-novichkov/perspektivy-professii.md b/faq-dlya-novichkov/perspektivy-professii.md
new file mode 100644
index 0000000..1abe6a7
--- /dev/null
+++ b/faq-dlya-novichkov/perspektivy-professii.md
@@ -0,0 +1,88 @@
+# Перспективы профессии
+
+Сколько лет еще продержится ручное тестирование? Заменит ли автоматизация мануальщиков?
+
+**Почему современная разработка нуждается в manual-тестировщиках**:
+
+1. Существует огромный массив специфических тестов, которые должны быть ручными
+
+То, что у нас принято называть “пользовательским опытом” (user experience, UI) - самая первая и главная причина, почему в 2021 году необходимо ручное тестирование, и почему оно будет необходимо всегда. Мы все бываем критичны к чужой работе, и разработчики критикуют тестировщиков, и зачастую по делу! Но когда дело касается не функциональности, а впечатлений человека, клиента, то нет и не будет замены человеческому глазу, его внимательности, его склонности замечать приятное. Хотя простые smoke-тесты можно автоматизировать, намного лучше они получаются у людей. Намного быстрее тестировщик прокликает приложение и увидит, готово ли оно к тщательному тестированию, чем это сделают скрипты, добавляя лишний этап. Использовать автотесты здесь не лучшая идея. Потом, только человек способен хорошо проверить, например, нюансы локализации в продукте нацеленном на международный рынок.
+
+2\. Автоматизированное тестирование - лишь дополнение к ручному
+
+Автоматизация это помощник человеку, когда он устал или уже не способен сосредоточиться. Автоматизированное тестирование экономит время на рутинные стандартные задачи, а ручное тестирование сосредотачивается на креативных нюансах. Самая правильная автоматизация - это не пытаться копировать поведение стандартного пользователя, а стараться улучшить покрытие продукта тестированием, при помощи автотестов.
+
+3\. Баги там, где их не ждешь
+
+Даже когда тестируешь по специальным, продуманным use cases, только люди-тестировщики могут найти баги в неожиданных местах. И это одно из главных преимуществ ручного тестирования. В некоторых проектах большинство багов обнаруживаются исключительно ручными тестировщиками, которые искали “вообще другое”. Автоматизированное тестирование не способно обнаружить ошибки, на которые оно изначально не нацеливалось.
+
+4\. Люди по умолчанию нацелены на креативность и анализ
+
+Хотя мы все любим пожаловаться на человеческие ограничения, у нас всегда есть человеческие качества: склонность к анализу и креативу. Скиллы и опыт, которыми обладают тестировщики, помогают им видеть ситуацию в общем. Не бывает замены для человеческой скорости мышления и наших мощнейших аналитических способностей.
+
+5\. В Agile тестовые скрипты надо постоянно переписывать
+
+Работа по agile-методологии ведет к постоянным изменениям в интерфейсе и функциональности продукта. И каждый раз нужно переписывать автоматизированные скрипты. Изменения затрагивают также скрипты регрессионного тестирования, так что даже и этот классический пример автоматизации требует обновлений, если это правильный эджайл. Эта трудоемкий процесс требует много времени.
+
+6\. Автоматизация небольших проектов обходится слишком дорого
+
+Надо платить за качественный софт для автоматизированного тестирования, а также растут затраты на обслуживание и менеджмент, на написание и переписывание скриптов. Когда это большой продукт и длительный проект, то высокие затраты окупаются. В случае маленьких проектов это огромная трата времени и денег. Когда пытаешься понять потенциальный ROI (возврат вложенных денег) на покупку софта для автоматизации, то необходимо не забывать учитывать и дополнительные “человеко-часы”, связанные с интеграцией софта в проект.
+
+7\. Автоматизация может “отставать от разработки”
+
+Существует разница между нашими надеждами, которые мы возлагаем на автоматизацию, и тем, что она реально может дать. С постоянным обновлением скриптов в Agile, очень тяжело удерживать автоматизированное тестирование в одном темпе с разработкой. Нет нужды в автоматическом тестировании багов, которые уже устарели. Хорошая автоматизация начинается сразу, и никогда не “отстает” больше, чем на один спринт. Если у команды нет лишнего ресурса на то чтобы держать автоматизацию в одном темпе с разработкой, то, может быть, лучше и не автоматизировать (если это не большой крупный проект, в котором есть шансы наладить процесс).
+
+8\. Ручные тестировщики смотрят на продукт как “клиенты”
+
+Человек учится все время, и делает это - все еще - намного быстрее, чем искусственный интеллект, при всей скорости ИИ в обработке данных. Поскольку люди-тестировщики ведут себя как пользователи, они способны помочь не только с проверкой продукта. Иногда тестировщики могут выступать в роли BA и направлять развитие продукта, исходя из своего опыта его тестирования. Автоматическое тестирование сосредоточено на систематизации сегодняшних знаний, а ручное, исследовательское тестирование определяет вещи, которые будут актуальны завтра.
+
+9\. Автоматизация не поможет найти ошибки, о которых не знали
+
+Как уже говорилось в третьем пункте, баги часто находят там, где это не ожидали. Бывают крайне специфические пользовательские сценарии, и бывают вещи, которые может увидеть и устранить только человек. Автоматизированное тестирование никогда не станет альтернативой исследовательского тестирования, которое проводит человек. Ошибки в неожиданных местах могут быть найдены только человеком.
+
+10\. Правильное тестирование должно быть изменяемым
+
+Успешное тестирование должно содержать в себе две вещи: повторение и изменение. Автоматизированное тестирование хорошо в процессе постоянного контроля качества, но его недостаточно. Нужно изменять тесты, включать в них кейсы с “рандомными” вещами. Сочетанием “повторения хорошего” и “вариации неизвестного”, обеспечивается полное покрытие продукта.
+
+11\. Мобильные девайсы: сложные use cases
+
+Мобильные девайсы, с их огромным парком, с проблемами в совместимости и взаимодействии, очень редко могут быть покрыты автоматизированными скриптами. Например, события выхода из Wi-Fi -покрытия и возвращения туда, одновременный запуск 5-10 приложений, комбинация установленных разрешений на девайсе, получение звонка и SMS - это “непредсказуемо, а значит не-автоматизируемо”. Или например изменение настроек свайпа, или количества одновременных касаний, также может повлиять на мобильные приложения. Понятно, что если нужно качественное мобильное приложение, то без manual-тестировщика не обойдешься.
+
+12\. Ручное тестирование это больше, чем список pass/fail в стандартном отчете
+
+Тестирование по списку pass/fail полезная вещь, в компаниях в большей части так тестируют сетевые функции. Но в некоторых сложных проектах не обойтись без более тщательного тестирования. Особенно веб-формы: автоматический скрипт без проблем заполнит форму на странице, но не сможет надежно проверить, сохранятся ли данные, если пользователь ушел со страницы и вернулся. То же и со скоростью передачи: человек явно заметит проблемы со скоростью загрузки или сохранения данных в какой-то части приложения. Скорость это не то, что можно хорошо протестировать автотестами.
+
+13\. Только ручные тестировщики быстро воспроизведут ошибку, замеченную клиентом
+
+Рассчитываешь выловить все баги до деплоя? Так никогда не бывает - пользователи будут сообщать о найденных багах. Только manual-тестировщик быстро примет информацию об ошибке, обработает, воспроизведет и сделает баг-репорт для разработчика. Когда тестирование ручное, то время от принятия бага от пользователя до его исправления - самое короткое.
+
+**Тренды тестирования и перспективные области**:
+
+* Big Data Testing;
+* Internet of Things;
+* Artificial Intelligence (AI) and Machine Learning (ML);
+* Blockchain Testing;
+* QAOps;
+* Quality engineering (QE);
+* Codeless Automated Testing.
+
+Источники:
+
+* [Автоматизированное тестирование НИКОГДА не заменит ручное: вот почему](https://testengineer.ru/ruchnoe-testirovanie-budet-zhit/)
+
+Доп. материал:
+
+* [Тестирование в эпоху ИИ](https://habr.com/ru/company/jugru/blog/541334/)
+* [Software Testing Trends to Watch 2021](https://hackernoon.com/software-testing-trends-to-watch-2021-733y33ue)
+* [Тренды тестирования 2020-2021: правда и мифы](https://habr.com/ru/post/562842/)
+* [6 Popular Software Testing Trends Everyone Should Follow](https://hackernoon.com/6-popular-software-testing-trends-everyone-should-follow)
+* [Three Steps to the Future](https://www.ben-evans.com/presentations)
+* [Code to the Future](https://hackernoon.com/code-to-the-future)
+* [Будущее ручного тестирование и главные тренды области: интервью с Артёмом Ерошенко](https://habr.com/ru/company/dins/blog/591317/)
+* [Умрет ли тестирование к 2030 году](https://www.youtube.com/watch?v=tZpoGVPkYiE)
+* [What the future holds: 5 core QA trends to rule 2022](https://hackernoon.com/what-the-future-holds-5-core-qa-trends-to-rule-2022)
+* [QAOps - What is it? Process, Implementation & Benefits](https://www.softwaretestingmaterial.com/qaops/)
+* [Top 19 Software Testing Conferences In 2022 (The Best QA Events)](https://www.softwaretestinghelp.com/software-testing-conferences/)
+* [AI/ML в автоматизации тестирования программного обеспечения](https://habr.com/ru/post/648621/)
+* [QA-тренды в 2022 году](https://telegra.ph/QA-trendy-v-2022-godu-02-03-2)
+* [Профессия тестировщик. Востребованность и актуальность](https://www.youtube.com/watch?v=d1t6VzZ6xqM)
diff --git a/faq-dlya-novichkov/s-chego-nachat-obuchenie-i-kuda-razvivatsya.md b/faq-dlya-novichkov/s-chego-nachat-obuchenie-i-kuda-razvivatsya.md
new file mode 100644
index 0000000..6f32ae8
--- /dev/null
+++ b/faq-dlya-novichkov/s-chego-nachat-obuchenie-i-kuda-razvivatsya.md
@@ -0,0 +1,46 @@
+# С чего начать обучение и куда развиваться?
+
+_Уровень 0: базовый курс по Computer Science._
+
+Начать нужно с простого ознакомления с тестированием и самый частый совет для этого - книга Романа Савина “Тестирование дот ком”. Воспринимайте ее просто как худ. лит. на 1-2 вечера, т.к. местами она спорная и устаревшая, но простыми словами даст хоть какое-то представление о тестировании. После ознакомления я бы посоветовал выбрать по отзывам в коммьюнити хороший базовый онлайн-курс и пройти его, либо по возможности пойти на офлайн-курсы местной компании с возможностью последующего трудоустройства - это вообще лучший вариант. Если нет возможности, то хорошим выбором будет бесплатная [книга Святослава Куликова “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book\_download/) + бесплатный [курс в дополнение к ней](https://svyatoslav.biz/urls/stc\_online/) и далее уже имея общее представление и понимая азы равномерно восполнять пробелы, подготавливаясь к собеседованиям по требованиям в вакансиях.
+
+Тестирование - очень широкая область и, хотя базовая теория и не сильно сложная, ее довольно много. В отрыве от практике она плохо усваивается и быстро забывается, вы начинаете путаться. Нужно пытаться как можно быстрее найти применение своим навыкам. Начать стоит с тестирования приложений и сайтов, которыми нравится пользоваться или любых других, а также классики типа тестирования форм, тренировочных сайтов с дефектами специально для тестировщиков и т.п. Отдельно советую действительно вдумываться во все практические примеры до полного понимания и способности решать аналогичные кейсы самостоятельно, просто за факт прочтения деньги платить не будут. Не стоит забывать и о софт скилах (учитесь адекватно общаться с людьми в профильных чатах) и базовой грамотности (смолоду тренируйтесь в составлении тестовых артефактов).
+
+По мере роста компетенций как можно раньше стоит начать проходить собеседования и пытаться устроиться на любую стажировку, вообще любой вариант, где вы сможете применять знания и указать этот опыт в резюме, т.к. без опыта сейчас найти работу очень трудно. Если нет никаких оффлайн вариантов, как было у меня, можете регистрироваться на краудтестинговых платформах (но зачастую это гиблое дело + многие работодатели игнорируют такой опыт), искать в тг-каналах возможности протестировать какие-то проекты за бесплатно (иногда там ищут волонтеров за опыт) либо придумать такой тестовый проект себе самому - снова взяться тестировать какое-либо приложение или сайт, но теперь делать это близко к тому, будто это ваша реальная работа. То есть чтобы было что потом рассказать и показать результаты (тест-кейсы, баг-репорты и т.п.). Багов хватает в любом популярном приложении/сайте, стоит только поискать, хотя баг-репорты и не главное. Главное показать понимание что и как тестировать.
+
+Когда вы устроитесь на свою первую работу, спустя некоторые время сможете начать готовиться к дальнейшему развитию и выбору направления, ведь никто не заставляет всю жизнь быть ручным тестировщиком. Вы можете сосредоточиться на mobile/web/desktop платформе, профессионально развиваться в менеджеры или автоматизацию, готовиться к узкой специализации - безопасности или performance и т. д., либо сфокусироваться на подготовке по перспективным направлениям:
+
+* Big Data Testing;
+* Internet of Things;
+* Artificial Intelligence (AI) and Machine Learning (ML);
+* Blockchain Testing;
+* QAOps;
+* Quality engineering (QE);
+* Codeless Automated Testing.
+
+Помимо прочего, специалисту, планирующему развиваться профессионально, желательно как можно раньше начать сначала посещать релевантные митапы и конференции, а когда-нибудь и начать выступать в роли докладчика. Также не лишними будут различные сертификации (хотя бы тот же ISTQB разных уровней) если работодатель оплачивает банкет, но вообще istqb если где и смотрят, то на западе и обычно не более чем как небольшой бонус.
+
+Доп. материал:
+
+* [Направления развития для Junior QA в рамках процессов тестирования](https://www.youtube.com/watch?v=VUiOtjFVVAU)
+* [Как стать тестировщиком с нуля](https://habr.com/ru/company/plarium/blog/561454/)
+* [Как учиться, чтобы научиться](https://dou.ua/lenta/columns/how-to-learn/)
+* [Где начинающему тестировщику взять опыт для первой QA работы?](https://www.youtube.com/watch?v=3O78nFUEOzc)
+* [Где начинающему тестировщику получить первый опыт: проект «Хомячки»](https://habr.com/ru/company/yandex\_praktikum/blog/567470/)
+* [Курс тестировщика пройден. А дальше что?](https://habr.com/ru/company/yandex\_praktikum/blog/547280/)
+* [Где начинающему тестировщику взять опыт для первой QA работы?](https://www.youtube.com/watch?v=3O78nFUEOzc)
+* [Как получить первый опыт работы тестировщиком / Практика для тестировщика](https://www.youtube.com/watch?v=fc9Ho4\_U7cE)
+* [Заработок для QA - Практика - Фриланс](https://www.youtube.com/watch?v=3o2AcvlqF6U)
+* [Устаревшие концепции тестирования: сертификация](https://telegra.ph/Ustarevshie-koncepcii-testirovaniya-sertifikaciya-06-24)
+* [end-to-end discussion of ISTQB Foundation syllabus tutorials](https://www.youtube.com/playlist?list=PLj5VKaW115t1o1hk5ZbNWFr4sW5mBpvmv)
+* [Geekhub Podcast: про образование в QA с Артемом Ерошенко и Всеволодом Брекеловым](https://www.youtube.com/watch?v=yY20oeJ42XQ%D0%BC)
+* [Разговор тестировщиков среднего возраста об индустрии тестирования 21 века](https://habr.com/ru/company/oleg-bunin/blog/578084/)
+* [От тестировщика - к QA инженеру. Советы новичкам](https://habr.com/ru/company/nix/blog/576208/)
+* [Как и в чем опытному QA развиваться в профессии - и всегда ли это надо делать?](https://habr.com/ru/company/otus/blog/583312/)
+* [Пути развития для тестировщика (QA)](https://www.youtube.com/watch?v=raPrEOBGhcI)
+* [Куда расти тестировщику](https://www.youtube.com/watch?v=KdmXv5fpKBA)
+* [Карьера QA - возможен ли рост выше уровня Senior, но не в менеджмент](https://www.youtube.com/watch?v=5lEKebxdmmw)
+* [Тестировщик на прокачку: как X5 Group обучает SDET-специалистов](https://habr.com/ru/company/X5Group/blog/575576/)
+* [SDET: как вырастить и не потерять](https://www.youtube.com/watch?v=PMJYLi\_ePiQ)
+* [«Правила роста: от джуниора до CTO», конспект вебинара Фёдора Борщёва](https://habr.com/ru/post/482958/)
+* [Учимся читать научные статьи у Эндрю Ына из Стэнфорда](https://habr.com/ru/company/ruvds/blog/510550/)
diff --git a/kontakty.md b/kontakty.md
new file mode 100644
index 0000000..70961e9
--- /dev/null
+++ b/kontakty.md
@@ -0,0 +1,24 @@
+# Контакты
+
+
+
+**Автор: Еремеев Владислав**
+
+[**LinkedIn**](https://www.linkedin.com/in/vladislaveremeev/) **-** [**Telegram**](https://t.me/Vladislav\_Eremeev)
+
+***
+
+_Поскольку проект open-source, каждый может внести посильный вклад в его (и всех читающих) развитие. Смело можете писать, особенно если:_
+
+* _нашли ошибку;_
+* _прочитали тему, ничего не поняли и нужно переписать понятнее;_
+* _не нашли то, чего искали;_
+* _в другом месте нашли что-то полезное, чего тут нет и хотите, чтобы это увидели и другие;_
+* _ссылка в доп. материалах не соответствует теме, не содержит чего-то дополнительного или более понятного в плане изложения темы;_
+* _есть аргументированная критика и предложения._
+
+_**Отправить анонимное сообщение можно в**_ [_**форме обратной связи**_](https://forms.yandex.ru/u/61e02b48c0332911705c01f8/)_**.**_
+
+_**Поблагодарить автора материально можно (видимо теперь только по РФ) переводом на Alfa Bank по номеру +79044121375**_
+
+_Удачи в карьере!_
diff --git a/mobilnoe-testirovanie/README.md b/mobilnoe-testirovanie/README.md
new file mode 100644
index 0000000..5166eab
--- /dev/null
+++ b/mobilnoe-testirovanie/README.md
@@ -0,0 +1,2 @@
+# Мобильное тестирование
+
diff --git a/mobilnoe-testirovanie/android-debug-bridge-adb.md b/mobilnoe-testirovanie/android-debug-bridge-adb.md
new file mode 100644
index 0000000..a3eb72a
--- /dev/null
+++ b/mobilnoe-testirovanie/android-debug-bridge-adb.md
@@ -0,0 +1,19 @@
+# Android Debug Bridge (ADB)
+
+Отладочный мост Android - это универсальный инструмент командной строки, включенный в пакет Android SDK Platform-Tools, который позволяет вам взаимодействовать с устройством. Команда adb упрощает выполнение различных действий с устройством, таких как установка и отладка приложений, а также предоставляет доступ к оболочке Unix, которую можно использовать для выполнения различных команд на устройстве.
+
+Это клиент-серверная программа, состоящая из трех компонентов:
+
+* Клиент, который отправляет команды. Клиент работает на вашей машине разработки. Вы можете вызвать клиент из терминала командной строки, введя команду adb;
+* Демон (adbd), который запускает команды на устройстве. Демон работает как фоновый процесс на каждом устройстве;
+* Сервер, который управляет связью между клиентом и демоном. Сервер работает как фоновый процесс на вашей машине разработки.
+
+Когда вы запускаете клиент adb, клиент сначала проверяет, не запущен ли уже процесс сервера adb. Если нет, он запускает серверный процесс. Когда сервер запускается, он привязывается к локальному TCP-порту 5037 и прослушивает команды, отправленные от клиентов adb - все клиенты adb используют порт 5037 для связи с сервером adb. Затем сервер устанавливает соединения со всеми работающими устройствами. Он находит эмуляторы, сканируя порты с нечетными номерами в диапазоне от 5555 до 5585 - диапазоне, используемом первыми 16 эмуляторами. Когда сервер находит демон adb (adbd), он устанавливает соединение с этим портом. Обратите внимание, что каждый эмулятор использует пару последовательных портов - порт с четным номером для консольных подключений и порт с нечетным номером для подключений adb.
+
+Источники:
+
+* [Android Debug Bridge (adb)](https://developer.android.com/studio/command-line/adb)
+
+Доп. материал:
+
+* [Android Debug Bridge (adb) - основные команды](https://telegra.ph/Android-Debug-Bridge-adb-10-10)
diff --git a/mobilnoe-testirovanie/android-ios-developer-settings.md b/mobilnoe-testirovanie/android-ios-developer-settings.md
new file mode 100644
index 0000000..45c23c3
--- /dev/null
+++ b/mobilnoe-testirovanie/android-ios-developer-settings.md
@@ -0,0 +1,57 @@
+# Android/iOS Developer Settings
+
+В настройках обеих платформ скрыто меню разработчика с полезными возможностями.
+
+Информации по меню в iOS почти никакой, нашел лишь упоминание таких пунктов:
+
+* Energy Diagnostic: измерение энергопотребления;
+* Network Link conditioner: изменение скорости сети;
+* iAd Developer App Testing: отображение и обновление iAds;
+* PassKit Testing: дополнительное логирование.
+
+**Android developer options**:
+
+* **Общие (General)**:
+ * Память (**Memory**): отображение статистики памяти, такой как среднее использование памяти, производительность памяти, общий объем доступной памяти, средний объем используемой памяти, объем свободной памяти и объем памяти, используемый приложениями;
+ * Сделать отчет об ошибке (**Take bug report**): получите копию текущих файлов журнала устройства, чтобы поделиться с кем-нибудь. Когда вы получите уведомление о том, что отчет об ошибке готов, коснитесь его, чтобы поделиться им;
+ * Демонстрационный режим UI (**System UI demo mode**): упрощает создание чистых скриншотов за счет отображения стандартной предустановленной панели уведомлений, на которой не отображаются уведомления или предупреждения о низком заряде батареи. “Включить демонстрационный режим” (Enable Demo Mode) позволяет вам изменить внешний вид строки состояния с помощью команд демо-режима adb. Или вы можете использовать “Показать демонстрационный режим” (Show Demo Mode), чтобы скрыть уведомления и отобразить предварительно заданную строку состояния;
+ * Пароль резервного копирования рабочего стола (**Desktop backup password**): устанавливает пароль резервного копирования, чтобы вы могли использовать команды adb для резервного копирования и восстановления приложений и данных устройства под защитой паролем;
+ * Бодрствовать (**Stay awake**): экран остается включенным каждый раз, когда устройство подключено;
+ * Включить журнал отслеживания интерфейса хост-контроллера Bluetooth (HCI) (**Enable Bluetooth Host Controller Interface (HCI) snoop log**): фиксирует все пакеты HCI Bluetooth в файле, хранящемся в /sdcard/btsnoop\_hci.log. Вы можете получить пакеты, а затем использовать такую программу, как Wireshark, для анализа и устранения неполадок с информацией.
+* **Отладка (Debugging)**: Параметры отладки предоставляют способы настройки отладки на устройстве и установления связи между устройством и вашим компьютером для разработки. Включите отладку по USB, чтобы ваше устройство Android могло связываться с вашей машиной разработки через Android Debug Bridge (adb). Параметр “Подождать отладчик” (Wait for Debugger) недоступен, пока вы не используете команду “Выбрать приложение для отладки” (Select debug app). Если вы включите “Ожидание отладчика” (Wait for Debugger), выбранное приложение будет ожидать подключения отладчика перед своим выполнением. Другие опции отладки включают следующее:
+ * Постоянно хранить данные журнала на устройстве (**Store logger data persistently on device**): выберите тип сообщений журнала, которые вы хотите постоянно хранить на устройстве. Параметры отключены, все, все, кроме радио, или только ядро;
+ * Выберите приложение фиктивного местоположения (**Select mock location app**): используйте этот параметр, чтобы подделать местоположение устройства по GPS. Чтобы использовать эту опцию, загрузите и установите приложение фиктивного местоположения GPS;
+ * Включить проверку атрибутов представления (**Enable view attribute inspection**): сохраняет информацию об атрибутах представления в переменной-члене mAttributes экземпляра View, чтобы ее можно было использовать для отладки. Вы можете получить доступ к информации об атрибутах через пользовательский интерфейс Layout Inspector (без его включения элемент «Атрибуты» недоступен);
+ * Включить уровни отладки графического процессора (**Enable GPU debug layers**): включите этот параметр, чтобы разрешить загрузку уровней проверки Vulkan из локального хранилища устройства;
+* **Сети (Networking)**: Параметры сети позволяют настраивать параметры Wi-Fi и DHCP. Нажмите “Выбрать конфигурацию USB” (Select USB Configuration), чтобы указать, как компьютер будет идентифицировать устройство. Вы можете настроить устройства только для зарядки, для передачи файлов (MTP), для передачи изображений (PTP), для использования вашего мобильного Интернета на ПК (RNDIS) или для передачи аудио или MIDI файлов. Нажмите “Версия Bluetooth AVRCP” (Bluetooth AVRCP version) и выберите версию профиля, которую вы хотите использовать для управления всем аудио / видео оборудованием Bluetooth, к которому у вашего устройства есть доступ. Чтобы точно настроить воспроизведение звука на устройстве есть следующие параметры: Bluetooth Audio Codec, Bluetooth Audio Sample Range, Bluetooth Audio Bits Per sample, Bluetooth Audio Channel Mode, Bluetooth Audio LDAC Codec. В следующем списке описаны другие способы настройки Wi-Fi и DHCP:
+ * Сертификация беспроводного дисплея (**Wireless display certification**): включает расширенные средства управления конфигурацией и настройки для сертификации беспроводного дисплея в соответствии со спецификациями, изложенными в Спецификации Wi-Fi дисплея Wi-Fi Alliance. Сертификация распространяется на Android 4.4 (уровень API 19) и выше;
+ * Включить подробное ведение журнала Wi-Fi (**Enable Wi-Fi verbose logging**): увеличивает уровень ведения журнала Wi-Fi для каждой беспроводной сети (SSID), к которой вы подключаетесь, в соответствии с относительной мощностью принимаемого сигнала (RSSI). Дополнительные сведения о журналах см. В разделе [Запись и просмотр журналов с помощью Logcat](https://developer.android.google.cn/studio/debug/am-logcat).
+ * Агрессивный переход от Wi-Fi к сотовой сети (**Aggressive Wi-Fi to cellular handover**): при низком уровне сигнала Wi-Fi более эффективно переключает соединение для передачи данных в сотовую сеть;
+* **Ввод (Input)**:
+ * Показывать касания (Show taps), нужно для отображения мест касаний экрана. Под вашим пальцем или стилусом появляется круг, который следует за вами при перемещении по экрану. Касание работает как указатель, когда вы записываете видео на свое устройство;
+ * Местоположение указателя (Pointer Location), нужно для отображения местоположения указателя (касания) на устройстве с помощью перекрестия. В верхней части экрана появится полоса для отслеживания координат перекрестия. Когда вы перемещаете указатель, координаты на полосе отслеживают положение перекрестия, а путь указателя отображается на экране;
+* **Рисование (Drawing)**: Параметры рисования предоставляют визуальные подсказки о пользовательском интерфейсе приложения и о том, как он работает. Включите параметр “Показать границы макета” (Show Layout Bounds), чтобы отображать границы, поля и другие конструкции пользовательского интерфейса вашего приложения на устройстве. Другие опции рисования включают следующее:
+ * Принудительное направление макета RTL (**Force RTL layout direction**): Принудительное направление макета экрана справа налево (RTL) или слева направо (по умолчанию);
+ * Масштаб анимации окна (**Window animation scale**): устанавливает скорость воспроизведения анимации окна, чтобы вы могли проверить ее производительность на разных скоростях. Чем меньше масштаб, тем выше скорость;
+ * Масштаб анимации перехода (**Transition animation scale**): устанавливает скорость воспроизведения анимации перехода, чтобы вы могли проверить ее производительность на разных скоростях. Чем меньше масштаб, тем выше скорость;
+ * Имитация вторичных дисплеев (**Simulate secondary displays**): создание вторичного дисплея в качестве наложения на устройстве. Это полезно при поддержке дополнительных дисплеев с помощью Presentation API. См. [Дополнительные дисплеи](https://developer.android.google.cn/about/versions/android-4.2#SecondaryDisplays);
+* **Аппаратное ускорение рендеринга (Hardware accelerated rendering)**: Параметры аппаратного ускорения рендеринга позволяют оптимизировать ваше приложение для целевых аппаратных платформ за счет использования аппаратных опций, таких как графический процессор, аппаратные уровни и сглаживание мультисэмплов (MSAA). Нажмите “Имитировать цветовое пространство” (Simulate color space), чтобы изменить цветовую схему всего пользовательского интерфейса устройства. Варианты относятся к типам дальтонизма. Возможны следующие варианты: Disabled (без моделируемой цветовой схемы), Monochromacy (черный, белый и серый), Deuteranomaly (красно-зеленый), Protanomaly (красно-зеленый) и Tritanomaly (сине-желтый). Протаномалия относится к красно-зеленой цветовой слепоте со слабостью в красных тонах, а дейтераномалия к красно-зеленой дальтонии со слабостью в зеленых тонах. Если вы делаете снимки экрана в смоделированном цветовом пространстве, они выглядят нормально, как если бы вы не меняли цветовую схему. Вот некоторые другие опции:
+ * Настроить рендеринг ГПУ (**Set GPU renderer**): измените графический движок Open GL по умолчанию на графический движок Open GL Skia;
+ * Принудительный рендеринг ГПУ (**Force GPU rendering**): заставляет приложения использовать графический процессор для 2D-рисования, если они были написаны без графического рендеринга по умолчанию;
+ * Показать обновления ГПУ view (**Show GPU view updates**): отображает любой экранный элемент, нарисованный графическим процессором;
+ * Отладка перерисовки ГПУ (**Debug GPU overdraw**): отображает цветовую кодировку на вашем устройстве, чтобы вы могли визуализировать, сколько раз один и тот же пиксель был отрисован в одном кадре. Визуализация показывает, где ваше приложение может выполнять больше рендеринга, чем необходимо. Дополнительные сведения см. В разделе [Визуализация перерисовки графического процессора](https://developer.android.google.cn/topic/performance/rendering/inspect-gpu-rendering#debug\_overdraw);
+ * Отладка непрямоугольных операций обрезки (**Debug non-rectangular clip operations**): отключает область обрезки на холсте для создания необычных (непрямоугольных) областей холста. Обычно область обрезки предотвращает рисование чего-либо за пределами круглой области обрезки;
+ * Принудительное сглаживание (F**orce 4x MSAA**): включает мультисэмпловое сглаживание (MSAA) в приложениях Open GL ES 2.0;
+ * Отключить HW-оверлеи (**Disable HW overlays**): использование аппаратного оверлея позволяет каждому приложению, отображающему что-либо на экране, использовать меньше вычислительной мощности. Без наложения приложение разделяет видеопамять и должно постоянно проверять наличие коллизий и отсечения, чтобы отобразить правильное изображение. Проверка использует большую вычислительную мощность;
+* **Медиа (Media)**: Включите параметр “Отключить маршрутизацию звука USB” (Disable USB audio routing), чтобы отключить автоматическую маршрутизацию на внешние аудиоустройства, подключенные к компьютеру через порт USB. Автоматическая маршрутизация может мешать работе приложений, поддерживающих USB. В Android 11 и более поздних версиях, когда приложение без разрешения RECORD\_AUDIO использует UsbManager для запроса прямого доступа к USB-аудиоустройству с возможностью захвата звука (например, USB-гарнитуре), появляется предупреждающее сообщение, предлагающее пользователю подтвердить разрешение на использование устройства. Система игнорирует любой параметр «всегда использовать», поэтому пользователь должен подтверждать предупреждение и предоставлять разрешение каждый раз, когда приложение запрашивает доступ. Чтобы избежать такого поведения, ваше приложение должно запросить разрешение RECORD\_AUDIO;
+* **Мониторинг (Monitoring)**: Параметры мониторинга предоставляют визуальную информацию о производительности приложения, например о длинном потоке (long thread) и операциях с графическим процессором. Нажмите “Профилировать рендеринг графического процессора” (Profile GPU Rendering), а затем “На экране в виде полос” (On screen as bars), чтобы отобразить визуализацию профилирования графического процессора в виде полос. Для получения дополнительной информации см. [Profile GPU rendering](https://developer.android.google.cn/topic/performance/rendering/inspect-gpu-rendering#profile\_rendering);
+* **Приложения (Apps)**: Параметры приложения помогают понять, как ваше приложение работает на целевом устройстве.
+ * Ограничение фоновых процессов (**Background process limit**), нужно чтобы установить количество процессов, которые могут работать в фоновом режиме одновременно.
+ * Сбросить ограничение в ShortcutManager (**Reset ShortcutManager rate-limiting**), нужно во время тестирования, чтобы фоновые приложения могли продолжать вызывать shortcut APIs, пока не будет достигнут предел;
+ * Не сохранять активити (**Don't keep activities**) нужно чтобы увеличить время автономной работы, уничтожая все активити, как только пользователь покидает главное окно активити, либо для тестирования некоторых кейсов.
+
+Также что-то полезное возможно найдется в инженерном меню, чаще это комбинация _#_#4636#_#_ в звонилке.
+
+Источники:
+
+* [Android Developers - Android Studio - User guide - Configure on-device developer options](https://developer.android.google.cn/studio/debug/dev-options.html?hl=en-AU#networking)
diff --git a/mobilnoe-testirovanie/arkhitektura-android-application.md b/mobilnoe-testirovanie/arkhitektura-android-application.md
new file mode 100644
index 0000000..a405ea8
--- /dev/null
+++ b/mobilnoe-testirovanie/arkhitektura-android-application.md
@@ -0,0 +1,213 @@
+# Архитектура Android Application
+
+Приложения для Android можно писать на языках Kotlin, Java и C ++. Инструменты Android SDK компилируют ваш код вместе с любыми файлами данных и ресурсов в **APK** или **Android App Bundle**.
+
+**Android package**, который представляет собой архивный файл с расширением **.apk**, содержит содержимое приложения Android, которое требуется во время выполнения, и это файл, который устройства под управлением Android используют для установки приложения.
+
+Пакет [**Android App Bundle**](https://telegra.ph/Android-App-Bundle-12-11), который представляет собой архивный файл с расширением **.aab**, содержит содержимое проекта приложения Android, включая некоторые дополнительные метаданные, которые не требуются во время выполнения. AAB - это формат для публикации в маркете, который нельзя установить на устройствах Android, он откладывает создание APK и подписание на более поздний этап. Например, при распространении вашего приложения через Google Play серверы Google Play генерируют оптимизированные APK-файлы, которые содержат только ресурсы и код, которые требуются конкретному устройству, запрашивающему установку приложения.
+
+Каждое приложение Android находится в собственной изолированной программной среде безопасности или песочнице (security **sandbox**), защищенной следующими функциями безопасности Android:
+
+* Операционная система Android - это многопользовательская система Linux, в которой каждое приложение является отдельным пользователем. По умолчанию система назначает каждому приложению уникальный идентификатор пользователя Linux (идентификатор используется только системой и неизвестен приложению);
+* Система устанавливает разрешения для всех файлов в приложении, так что только идентификатор пользователя, назначенный этому приложению, может получить к ним доступ;
+* У каждого процесса есть собственная виртуальная машина (VM), поэтому код приложения работает изолированно от других приложений;
+* По умолчанию каждое приложение работает в собственном процессе Linux. Система Android запускает процесс, когда необходимо выполнить любой из компонентов приложения, а затем завершает процесс, когда он больше не нужен или когда системе необходимо восстановить память для других приложений.
+
+В системе Android реализован принцип наименьших привилегий. То есть каждое приложение по умолчанию имеет доступ только к тем компонентам, которые необходимы ему для работы, и не более того. Это создает очень безопасную среду, в которой приложение не может получить доступ к частям системы, для которых у него нет разрешения. Однако есть способы для приложения обмениваться данными с другими приложениями и для приложения для доступа к системным службам:
+
+* Можно организовать два приложения для использования одного и того же идентификатора пользователя Linux, и в этом случае они смогут получить доступ к файлам друг друга. Для экономии системных ресурсов приложения с одним и тем же идентификатором пользователя также могут работать в одном процессе Linux и совместно использовать одну и ту же виртуальную машину;
+* Приложения также должны быть подписаны тем же сертификатом. Приложение может запрашивать разрешение на доступ к данным устройства, таким как местоположение устройства, камера и соединение Bluetooth. Пользователь должен явно предоставить эти разрешения. Дополнительные сведения см. В разделе «[Работа с разрешениями системы](https://developer.android.google.cn/guide/topics/permissions/overview)».
+
+**Компоненты приложения**
+
+Компоненты приложения являются основными строительными блоками Android приложения. Каждый компонент - это точка входа, через которую система или пользователь могут войти в ваше приложение. Некоторые компоненты зависят от других. Есть четыре разных типа компонентов приложения:
+
+* Activities;
+* Services;
+* Broadcast receivers;
+* Content providers.
+
+Каждый тип служит определенной цели и имеет отдельный жизненный цикл, который определяет, как компонент создается и уничтожается.
+
+Начнем разбираться с таких компонентов, как активити и фрагменты, и рассмотрим кейсы, когда система может прекратить их работу.
+
+**Активити и фрагменты (activities and fragments)**
+
+С точки зрения тестировщика, активити можно воспринимать как экран, на котором отображаются элементы. Приложение состоит, как минимум, из одной активити. По сути, активити - это контейнер для UI-компонентов. Если активити - это контейнер, то фрагменты - это UI-компоненты активити. Фрагмент тоже, в свою очередь, является контейнером для UI-компонентов. Есть классная аналогия с браузером (спасибо разработчикам!) для более наглядного представления о том, как между собой связаны активити и фрагменты. Представим, что у нас открыто несколько окон одного браузера. Это несколько **активити** внутри одного приложения.
+
+
+
+Внутри окна может быть открыто несколько вкладок. Это **фрагменты** внутри активити.
+
+
+
+Фрагменты работают чуть быстрее, чем активити. Но на современных устройствах разница практически неощутима. В зависимости от того, каким образом решается задача, разработчик может написать приложение только на активити или на активити с использованием фрагментов.
+
+Операционная система при управлении жизненным циклом приложения работает именно с активити приложения. Поэтому пока нас больше всего интересует жизненный цикл активити.
+
+Пользователи запускают большое количество приложений, а значит, создается много процессов с активити. Каждый запущенный процесс съедает оперативную память устройства, и ее становится все меньше. Но Андроид тщательно следит за процессами и в случае нехватки ресурсов для выполнения более приоритетной работы закрывает те, которые менее приоритетны. Давайте разберемся, в какой момент приложение «уязвимо» к таким решениям системы и как это может повлиять на его работоспособность.
+
+**Жизненный цикл активити**
+
+После запуска и до завершения активити всегда пребывает в одном из статусов. В тестировании нам это полезно для понимания потенциально проблемных кейсов и в контексте тестирования прерываний (Interrupt testing):
+
+* Перед завершением Activity, будут вызваны соответствующие методы жизненного цикла;
+* Метод onPause() должен остановить все "слушания" и обновления интерфейса. Метод onStop() должен сохранять данные приложения. И наконец, метод onDestroy() высвободит любые ресурсы, выделенные для Activity;
+* Когда пользователь переключается обратно на приложение, которое было прервано системным событием, вызывается метод onResume(). На основе сохраненных данных, могут перерегистрироваться «слушатели» и переключиться обновления интерфейса.
+
+
+
+Жизненный цикл активити представлен следующими состояниями:
+
+
+
+Теперь приведу примеры. Они покрывают основные кейсы, с которыми мы чаще всего сталкиваемся при тестировании.
+
+**Первый запуск приложения**
+
+
+
+При первом запуске приложения создается и загружается главная активити в приложении.
+
+При переходе в состояние «Resumed» активити доступна для взаимодействия с пользователем. Все замечательно, проблем нет.
+
+**Переход с первого экрана на второй**
+
+
+
+* Шаг 1: При переходе с первого экрана на второй активити первого экрана сначала встает на паузу. В этот момент могут выполняться такие действия, как сохранение введенных данных и остановка ресурсоемких операций (например, проигрывание анимаций). Это происходит довольно быстро и неощутимо для пользователя.
+* Шаг 2, 3, 4: Запускается активити второго экрана.
+* Шаг 5: Останавливается активити первого экрана. Также в случае, если Андроид в этот момент пытается освободить память, активити первого экрана дополнительно может перейти в состояние «Destroyed» (то есть уничтожиться).
+
+Чтобы лучше понять, что из себя представляет состояние «Paused» давайте представим такую ситуацию: экран, поверх которого появился алерт. Мы не можем с ним взаимодействовать, но в то же время мы его видим.
+
+**Возврат со второго экрана на первый**
+
+
+
+При возврате со второго экрана на первый происходит почти то же самое, только первая активити не создается заново. Она подгружается из памяти (если, конечно, не была уничтожена системой). Вторая активити уничтожается после того, как была остановлена, так как она убирается из стека переходов.
+
+**Сворачивание и выход из приложения**
+
+
+
+При сворачивании приложения (например, по кнопке Home) активити останавливается.
+
+Важно, чтобы при разворачивании приложения активити корректно восстановилась и данные сохранились.
+
+На всех экранах стараемся проверять сворачивание-разворачивание приложения. Этот кейс особенно актуален на формах ввода. Согласитесь, будет обидно, если текст письма, который вы так старательно набирали, сотрется при банальном сворачивании приложения. Или форма, состоящая из множества полей, снова станет пустой.
+
+При выходе из приложения (по аппаратной кнопке назад) помимо шага 1 и шага 2, выполняется шаг 3. Активити уничтожается и при следующем запуске приложения создается заново.
+
+**Поворот экрана**
+
+
+
+Один из значимых случаев, который плодит баги - это поворот экрана. Оказывается, при повороте экрана активити проходит полный жизненный цикл. А именно уничтожается и снова создается. И так при каждом повороте. Поэтому, опять же, проверяем поворот на каждом экране.
+
+Поддержка горизонтальной ориентации экрана, с одной стороны, позволяет проверить корректность работы всех этапов активити, с другой стороны, значительно увеличивает количество тест-кейсов.
+
+**Многооконный режим**
+
+Начиная с Андроида 7 (с Андроида 6 как экспериментальная фича) стал доступен многооконный режим. Пользователи получили возможность видеть сразу несколько приложений на экране одновременно. При этом только то приложение, с которым пользователь сейчас взаимодействует, находится в состоянии «Resumed». Остальные устанавливаются в состояние «Paused».
+
+**Don’t keep activities (Не сохранять действия)**
+
+Надо ли проверять полный жизненный цикл активити, если приложение не поддерживает поворот экрана? Конечно, надо.
+
+Если оперативная память давно не чистилась, ее не очень много, и в параллели с вашим приложением было запущено какое-нибудь ресурсоемкое приложение (например, Pokemon Go), то шанс, что Андроид решит «прибить» процесс с вашей активити при переключении на другое приложение, возрастает.
+
+Как проверить корректность работы приложения вручную, если оно не поддерживает поворот экрана? Довольно просто: установить галку «don’t keep activities» в настройках разработчика и перезапустить приложение.
+
+В этом случае эмулируется ситуация, когда памяти не хватает и Андроид уничтожает все активити, с которыми пользователь сейчас не взаимодействует, оставляя только ту, что сейчас активна.
+
+Это не значит, что галка должна всегда быть включенной при тестировании, но периодически смотреть приложение с опцией «don’t keep activities» полезно, чтобы пользователи со слабыми устройствами не сильно страдали и не ругали нас.
+
+**Broadcast receiver (широковещательный приемник)**
+
+Для обработки внешних событий используется компонент Broadcast receiver. Приложение может подписываться на события системы и других приложений. Андроид доставляет событие приложению-подписчику, даже если оно не запущено, и таким образом, может «мотивировать» его запуск.
+
+При тестировании нам важно понимать, какие ожидаются события и как они обрабатываются.
+
+Например, в коде заранее было прописано, что приложение ждет сообщение от конкретного номера и имеет доступ к смс. Когда пользователю придет секретный код, то Broadcast receiver получит уведомление и в поле подтверждения операции будет введен смс-код.
+
+**Сервисы (Services)**
+
+Еще одна очень важная вещь в Андроиде - это сервисы. Они нужны для выполнения фоновых задач. При этом приложение не обязательно должно быть открыто пользователем в этот момент.
+
+У сервисов есть несколько режимов работы. Пользователь может видеть, что сервис запущен, а может и совершенно не замечать его.
+
+Если вы услышали волшебное слово «сервис» от разработчика, не поленитесь, выясните, какую логику работы заложили в него:
+
+* Что делает сервис и в каком виде проявляет себя?
+* Как ведет себя сервис, когда приложение не активно?
+* Восстанавливается ли сервис после прерывания (входящего звонка, перезапуска телефона)?
+
+Тут основной совет при проектировании тестовых сценариев - это обдумать пользовательские кейсы, когда работа сервиса может прерваться или начать конфликтовать с работой другого сервиса. Самые коварные ситуации: когда работа сервиса начинается, а пользователь этого не ждал. В этом случае полезно выяснить, что может спровоцировать запуск сервиса.
+
+Самые простые и безобидные - это **сервисы без дополнительных параметров**. При ручном тестировании мы чаще всего не замечаем их работу. Например, если нужно отправить данные в систему аналитики, то для этой задачи нередко используют именно такие сервисы.
+
+Еще один тип сервисов это **sticky-сервисы**. Если работа такого сервиса внезапно завершится, то спустя какое-то время sticky-сервис «возродится». Примечательно, что с каждым разом период до «возрождения» увеличивается, чтобы он меньше мешал работе системы. В некоторых приложениях примером sticky-сервиса может быть скачивание файлов на устройство. Возможно, вы замечали, если в «шторке» сбросить закачку, то спустя какое-то время она может восстановиться и продолжить скачивать файлы.
+
+Самые важные сервисы - те, работу которых пользователь «ощущает» на себе и она для него важна. Они называются **foreground-сервисы**, и у них обязательно есть нотификация в «шторке», которую пользователь не может закрыть. Система их будет уничтожать в последнюю очередь, так как приоритет у таких сервисов самый высокий.
+
+Например, музыкальный плеер. Если свернуть приложение и даже закрыть его, то плеер продолжает играть, пока пользователь не поставит его на паузу или не закроет. Или пока другое приложение или система не приостановит его работу. В частности, для музыкального плеера вариантов может быть много: входящий звонок, другое музыкальное приложение, звуковая нотификация.
+
+Раз речь зашла о музыкальных плеерах, то стоит отметить такое понятие, как аудиофокус.
+
+**Аудиофокус**
+
+Представим, что при запуске нескольких аудиоплееров, они все будут играть одновременно. Вряд ли это кому-то понравится. Тут на помощь приходит аудиофокус, который запрашивается приложением у системы. В случае **обычного запроса аудиофокуса** система как бы оповещает все запущенные приложения: «Сейчас другое приложение будет говорить, помолчите, пожалуйста». Забавно, но это происходит именно в формате просьбы.
+
+Если ваше приложение не очень вежливое, то оно спокойно может проигнорировать запрос. Наша задача - проверять эти ситуации.
+
+Компромиссный режим запроса аудиофокуса называется «**временным перехватом аудиофокуса**». Это значит, что вашему приложению вернется аудиофокус, когда прервавшее его подаст системе сигнал, что аудиофокус освобожден.
+
+Еще один вид запроса аудиофокуса - это «**duck**». Он просит остальные приложения не молчать, а уменьшить громкость наполовину пока воспроизводится звук запросившего фокус приложения. Например, такой запрос используется при проигрывании звука нотификации о новом сообщении в мессенджере.
+
+Тестирование аудиофокуса очень важно, т.к. здесь все завязано на совести разработчиков и система не принимает особого участия в разрешении конфликтов. Ну а если баг все-таки вылезет к пользователям, то не сомневайтесь, они быстро вам об этом сообщат.
+
+На этом, пожалуй, пока можно закончить. Конечно, есть еще много деталей и нет необходимости учитывать абсолютно все при тестировании. По моему опыту, тестировщику необходимо понимать из чего состоит приложение и как оно работает. Это дает возможность анализировать непростые баги, которые возникают на пересечении бизнес-логики приложения и особенностей работы операционной системы. Особенно если дело касается Андроида.
+
+**Content providers**
+
+Поставщик контента управляет общим набором данных приложения, которые вы можете хранить в файловой системе, в базе данных SQLite, в Интернете или в любом другом постоянном хранилище, к которому ваше приложение может получить доступ. Через поставщика содержимого другие приложения могут запрашивать или изменять данные, если поставщик содержимого позволяет это. Например, система Android предоставляет поставщика контента, который управляет контактной информацией пользователя. Таким образом, любое приложение с соответствующими разрешениями может запрашивать поставщика содержимого, например ContactsContract.Data, для чтения и записи информации о конкретном человеке. Заманчиво думать о провайдере контента как о абстракции базы данных, потому что для этого распространенного случая в них встроено множество API и встроенная поддержка. Однако с точки зрения системного дизайна у них другое основное назначение. Для системы поставщик контента - это точка входа в приложение для публикации именованных элементов данных, идентифицированных схемой URI. Таким образом, приложение может решить, как оно хочет сопоставить данные, которые оно содержит, с пространством имен URI, передавая эти URI другим объектам, которые, в свою очередь, могут использовать их для доступа к данным.
+
+Уникальный аспект системы Android заключается в том, что любое приложение может запускать компонент другого приложения. Например, если вы хотите, чтобы пользователь сделал снимок с помощью камеры устройства, вероятно, есть другое приложение, которое делает это, и ваше приложение может использовать его вместо разработки действия для самостоятельной съемки фотографии. Вам не нужно включать или даже ссылаться на код из приложения камеры. Вместо этого вы можете просто запустить действие в приложении камеры, которое делает снимок. По завершении фотография даже возвращается в ваше приложение, чтобы вы могли ее использовать. Пользователю кажется, что камера на самом деле является частью вашего приложения.
+
+Когда система запускает компонент, она запускает процесс для этого приложения, если оно еще не запущено, и создает экземпляры классов, необходимых для компонента. Например, если ваше приложение запускает действие в приложении камеры, которое делает снимок, это действие выполняется в процессе, принадлежащем приложению камеры, а не в процессе вашего приложения. Следовательно, в отличие от приложений в большинстве других систем, приложения Android не имеют единой точки входа (нет функции main ()). Поскольку система запускает каждое приложение в отдельном процессе с правами доступа к файлам, которые ограничивают доступ к другим приложениям, ваше приложение не может напрямую активировать компонент из другого приложения. Однако система Android может. Чтобы активировать компонент в другом приложении, доставьте системе сообщение, в котором указывается ваше намерение (**intent**) запустить конкретный компонент. Затем система активирует компонент за вас.
+
+**Активация компонентов (Activating components)**
+
+Три из четырех типов компонентов - activities, services, and broadcast receivers - активируются асинхронным сообщением, называемым **intent**. Намерения связывают отдельные компоненты друг с другом во время выполнения. Вы можете думать о них как о мессенджерах, которые запрашивают действие у других компонентов, независимо от того, принадлежит ли компонент вашему приложению или другому. Намерение создается с помощью объекта Intent, который определяет сообщение для активации либо определенного компонента (explicit intent), либо определенного типа компонента (implicit intent).
+
+**Файл манифеста (The manifest file)**
+
+Прежде чем система Android сможет запустить компонент приложения, система должна знать, что компонент существует, прочитав файл манифеста приложения AndroidManifest.xml. Ваше приложение должно объявить все свои компоненты в этом файле, который должен находиться в корне каталога проекта приложения. Манифест выполняет ряд функций в дополнение к объявлению компонентов приложения, например:
+
+* Определяет любые разрешения (user permissions), которые требуются приложению, такие как доступ в Интернет или доступ для чтения к контактам пользователя;
+* Объявляет минимальный уровень API, необходимый для приложения, в зависимости от того, какие API использует приложение;
+* Объявляет аппаратные и программные функции, используемые или требуемые приложением, такие как камера, службы Bluetooth или сенсорный экран;
+* Объявляет библиотеки API, с которыми необходимо связать приложение (кроме API-интерфейсов Android framework), например библиотеку Google Maps.
+
+**Ресурсы приложения (App resources)**
+
+Приложение Android состоит из большего, чем просто кода - для него требуются ресурсы, отдельные от исходного кода, такие как изображения, аудиофайлы и все, что связано с визуальным представлением приложения. Например, вы можете определять анимацию, меню, стили, цвета и макет пользовательских интерфейсов действий с помощью файлов XML. Использование ресурсов приложения позволяет легко обновлять различные характеристики вашего приложения без изменения кода. Предоставление наборов альтернативных ресурсов позволяет оптимизировать приложение для различных конфигураций устройств, например для разных языков и размеров экрана.
+
+Для каждого ресурса, который вы включаете в свой проект Android, инструменты сборки SDK определяют уникальный целочисленный идентификатор, который вы можете использовать для ссылки на ресурс из кода вашего приложения или из других ресурсов, определенных в XML. Например, если ваше приложение содержит файл изображения с именем logo.png (сохраненный в каталоге res / drawable /), инструменты SDK генерируют идентификатор ресурса с именем R.drawable.logo. Этот идентификатор сопоставляется с целым числом для конкретного приложения, которое вы можете использовать для ссылки на изображение и вставки его в свой пользовательский интерфейс.
+
+Одним из наиболее важных аспектов предоставления ресурсов отдельно от исходного кода является возможность предоставления альтернативных ресурсов для различных конфигураций устройств. Например, определяя строки пользовательского интерфейса в XML, вы можете перевести строки на другие языки и сохранить эти строки в отдельных файлах. Затем Android применяет соответствующие языковые строки к вашему пользовательскому интерфейсу на основе квалификатора языка, который вы добавляете к имени каталога ресурсов (например, res / values-fr / для французских строковых значений) и языковых настроек пользователя.
+
+Android поддерживает множество различных квалификаторов для ваших альтернативных ресурсов. Квалификатор - это короткая строка, которую вы включаете в имя своих каталогов ресурсов, чтобы определить конфигурацию устройства, для которой следует использовать эти ресурсы. Например, вы должны создать разные макеты для своих занятий в зависимости от ориентации и размера экрана устройства. Когда экран устройства находится в портретной ориентации (высокий), вы можете захотеть, чтобы макет с кнопками был вертикальным, но когда экран находится в альбомной ориентации (широкий), кнопки можно выровнять по горизонтали. Чтобы изменить макет в зависимости от ориентации, вы можете определить два разных макета и применить соответствующий квалификатор к имени каталога каждого макета. Затем система автоматически применяет соответствующий макет в зависимости от текущей ориентации устройства.
+
+Дополнительные сведения о различных типах ресурсов, которые вы можете включить в свое приложение, и о том, как создавать альтернативные ресурсы для различных конфигураций устройств, см. В разделе «[Предоставление ресурсов](https://developer.android.google.cn/guide/topics/resources/providing-resources)». Чтобы узнать больше о передовых методах разработки и разработке надежных приложений производственного качества, см. [Руководство по архитектуре приложений](https://developer.android.google.cn/jetpack/guide).
+
+Источники:
+
+* [Android Developers - Docs - Guides - Application Fundamentals](https://developer.android.google.cn/guide/components/fundamentals?hl=en)
+* [Системный подход к тестированию Android-приложений, или О чем молчали разработчики](https://habr.com/ru/company/mobileup/blog/327416/)
+
+Доп. материал:
+
+* YaTalks 2021. Mobile: [Современная архитектура android приложений](https://www.youtube.com/watch?v=0AQlKbskhkM\&t=18671s) + [презентация](https://disk.yandex.ru/i/ecrzwwYKTlbkgA)
+* [Видео: Урок 23. Жизненный цикл активити (Activity Lifecycle)](https://www.youtube.com/watch?v=vv9w9\_l17z4)
diff --git a/mobilnoe-testirovanie/arkhitektura-android-os.md b/mobilnoe-testirovanie/arkhitektura-android-os.md
new file mode 100644
index 0000000..ea8c7fa
--- /dev/null
+++ b/mobilnoe-testirovanie/arkhitektura-android-os.md
@@ -0,0 +1,73 @@
+# Архитектура Android OS
+
+
+
+**Linux Kernel**
+
+Данный уровень является базовым в архитектуре Android, так как вся система Android построена на ядре Linux с некоторыми архитектурными изменениями.
+
+Основные задачи, выполняемые ядром: Ядро содержит в себе драйверы, необходимые для взаимодействия с оборудованием. Например, возьмем Bluetooth. В наше время сложно найти устройство, которое бы не включало в себя эту функцию. Поэтому ядро должно включать драйвер для работы с ним. На схеме выше как раз таки перечислены все драйверы, входящие в ядро Linux, поэтому не будем перечислять их все по отдельности.
+
+* Power Management - это своего рода система управления питанием. Она предоставляет различные средства, с помощью которых приложение может реагировать на режимы питания устройства, а также поддерживать необходимые компоненты устройства активными. Например, при чтении книги нам было бы удобно, если бы экран оставался постоянно активным. Или когда мы включаем музыку и она продолжает проигрываться в фоне при отключенном экране.
+* Управление памятью. При запуске различных приложений ядро гарантирует, что пространство памяти, которое они используют, не конфликтует и не перезаписывает друг друга. Также оно проверяет, что все приложения получают достаточный объем памяти для своей работы, и в то же время следит, чтобы ни одно приложение не занимало слишком много места.
+* Управление процессом. Каждое приложение в Android работает в отдельном процессе. Ядро же отвечает за управление этими процессами, а именно за создание, приостановку, остановку, или завершение процессов, за одновременное выполнение нескольких процессов, обмен данными между процессами, запуск процессов в фоновом режиме. Помимо этого ядро распределяет работу между процессорами устройства, что максимизирует производительность устройств с несколькими ядрами.
+
+**Hardware Abstraction Layer (HAL)**
+
+HAL обеспечивает связь между драйверами и библиотеками. Состоит он из нескольких библиотечных модулей, каждый из которых реализует интерфейс для определенного аппаратного компонента (Bluetooth, Камера итд.). И когда к оборудованию устройства обращаются через API-интерфейс, загружается необходимый для его работы модуль.
+
+Если объяснять на пальцах, то когда от приложения поступает какое-либо сообщение, HAL его обрабатывает таким образом, чтобы оно стало понятным для драйверов. И наоборот.
+
+**Android Runtime (ART)**
+
+Основным языком Android был выбран Java, поскольку это один из самых популярных языков программирования. Для Java существует много наработок и специалистов, а написанные на нем программы переносимы между операционными системами.
+
+Но для того, чтобы программа работала на Java необходима виртуальная машина - Java Virtual Machine. В Android используется виртуальная машина Android Runtime (ART). Эта машина специально оптимизирована для работы на мобильных устройствах: с нехваткой памяти, с постоянной выгрузкой и загрузкой приложений и т.д. В версиях Android ниже 5.0 Lollipop, использовалась виртуальная машина Dalvik - старая реализация виртуальной машины для Android.
+
+В ART, как и в Dalvik, используется свой формат байт-кода - DEX (Dalvik executable). При сборке приложения исходные файлы сначала компилируются в файлы типа class обычным компилятором, а затем конвертируются специальной утилитой в DEX.
+
+И Dalvik, и ART оптимизируют выполняемый код, используя механизм компиляции just-in-time (JIT) - компиляция происходит во время выполнения приложения, что позволяет оптимизировать код для выполнения на конкретном устройстве. При этом байт-код приложения можно переносить на другие устройства.
+
+ART может компилировать байт-код заранее, а не во время выполнения, используя ahead-of-time (AOT). Система сама решает, когда и какие приложения необходимо скомпилировать. Например, когда устройство не загружено и подключено к зарядке. При этом ART учитывает информацию о приложении, собранную во время предыдущих запусков, что дает дополнительную оптимизацию.
+
+**Native C/C++ Libraries**
+
+Набор библиотек, написанных на языках C или C++ и используемых различными компонентами ОС.
+
+Примеры библиотек:
+
+* WebKit - представляет из себя движок веб-браузера и другие связанные с ним функции.
+* Media Framework предоставляет медиа кодеки, позволяющие записывать и воспроизводить различные медиа-форматы.
+* OpenGL - используется для отображения 2D и 3D графики.
+* SQLite - движок базы данных, используемый в Android для хранения данных.
+
+**Java API Framework (Application Framework)**
+
+Набор API, написанный на языке Java и предоставляющий разработчикам доступ ко всем функциям ОС Android. Эти API-интерфейсы образуют строительные блоки, необходимые для создания приложений, упрощая повторное использование основных, модульных, системных компонентов и сервисов, таких как:
+
+* Activity Manager - управляет жизненным циклом приложения и обеспечивает общий навигационный стек обратных вызовов.
+* Window Manager - управляет окнами и является абстракцией библиотеки Surface Manager.
+* Content Providers - позволяет приложению получать доступ к данным из других приложений или обмениваться собственными данными, т.е. предоставляет механизм для обмена данными между приложениями.
+* View System - содержит строительные блоки для создания пользовательского интерфейса приложения (списки, тексты, кнопки итд.), а также управляет событиями элементов пользовательского интерфейса.
+* Package Manager - управляет различными видами информации, связанными с пакетами приложений, которые в настоящее время установлены на устройстве.
+* Telephony Manager - позволяет приложению использовать возможности телефонии.
+* Resource Manager - обеспечивает доступ к таким ресурсам, как локализованные строки, растровые изображения, графика и макеты.
+* Location Manager - возможность определения местоположения.
+* Notification Manager - отображение уведомлений в строке состояния.
+
+**System Apps**
+
+Верхний уровень в архитектуре Android, который включает в себя ряд системных (предустановленных) приложений и тонну других приложений, которые можно скачать с Google Play.
+
+Системные приложения на всех устройствах разные, но все они являются предустановленными производителями устройства (приложение для SMS-сообщений, календарь, карты, браузер, контакты итд.).
+
+Этот уровень использует все уровни ниже (если смотреть на схему) для правильного функционирования приложений.
+
+Источники:
+
+* [Как работает Android. Архитектура платформы](https://bimlibik.github.io/posts/how-does-android-work/) + [оригинал из офф доки](https://developer.android.com/guide/platform)
+
+Доп. материал:
+
+* Более подробный цикл статей “Как работает Android”: часть [1](https://habr.com/ru/company/solarsecurity/blog/334796/), [2](https://habr.com/ru/company/solarsecurity/blog/338292/), [3](https://habr.com/ru/company/solarsecurity/blog/338494/), [4](https://habr.com/ru/company/solarsecurity/blog/427431/)
+* [Android's HIDL: Treble in the HAL](https://www.slideshare.net/opersys/androids-hidl-treble-in-the-hal)
diff --git a/mobilnoe-testirovanie/arkhitektura-ios-application.md b/mobilnoe-testirovanie/arkhitektura-ios-application.md
new file mode 100644
index 0000000..47c5e8e
--- /dev/null
+++ b/mobilnoe-testirovanie/arkhitektura-ios-application.md
@@ -0,0 +1,51 @@
+# Архитектура iOS Application
+
+Приложения представляют очень сложное взаимодействие между вашим кодом и системными фреймворками. Системный фреймворки предоставляют базовую инфраструктуру, с которой все приложения должны работать, а вы пишете код для настройки этой инфраструктуры.
+
+Фреймворки iOS основаны на таких шаблонах проектирования, как MVC и делегирование.
+
+**Жизненный цикл iOS приложения**
+
+Точкой входа для каждого C-приложения является функция main. Во время запуска UIApplicationMain функция устанавливает несколько ключевых объектов и запускает приложение. Сердцем каждого iOS приложения является объект UIApplication, задача которого - облегчить взаимодействие между системой и другими объектами приложения. Рисунок ниже показывает объекты, обычно встречающиеся в iOS приложениях. А еще ниже представлено описание роли каждого объекта в приложении. Первое что стоит отметить - iOS приложения используют архитектуру Model-View-Controller. Эта архитектура имеет решающее значение для создания приложений, которые могут работать на различных устройствах с различными размерами экрана.
+
+
+
+* Объект UIApplication: UIApplication управляет циклом обработки событий и разными типами поведения приложений высокого уровня. Он также сообщает о ключевые переходах приложения и некоторых специальных событиях (например, входящих уведомлений Push) своему делегату, который представляет собой пользовательский объект. Используйте UIApplication «как есть», без подклассов.
+* Объект UIDelegate: App Delegate является сердцем вашего кода. Этот объект работает в связке с объектом UIApplication и служит для обработки инициализации приложения, перехода между состояниями, а также обеспечивает множество событий в приложениях высокого уровня.
+* Documents и Data Model Objects: Модель данных может быть специфической для вашего приложения. Пример: банковская база данных и приложения со списком фильмов будут иметь разную модель данных. Приложения могут также использовать объекты Documents (подклассы UIDocuments) для управления моделями данных. Объекты Documents необязательны, но предлагают удобный способ группировать данные в пакетах файлов.
+* Объект View Controller: Объект View Controller служит для управления отображением контента вашего приложения на экране. Класс UIViewController является базовым классом для всех объектов View Controller. Он предоставляет функциональные возможности по умолчанию для загрузки представления, показывая их, вращая их в ответ на поворот устройства, а также несколько других стандартных систем поведения.
+* Объект UIWindow: Выводит и координирует один или несколько View на экране. Большинство приложений имеют только один Window, в котором представлен весь контент приложения на главном экране. Но могут потребоваться дополнительный Window. Например, для отображения вспомогательных элементов на внешнем экране.
+* Объекты View, объекты Controls, объекты Layer: Объекты View обеспечивают визуальное представление содержимого вашего приложения. View является объектом, который рисует содержимое в назначенной прямоугольной области и реагирует на события в пределах этой области. Объекты Controls представляют из себя специальные типы View, отвечающие за реализацию привычных объектов интерфейса: кнопки, текстовые поля, переключатели и т. д. Объекты Layer - это объекты данных, которые представляют из себя визуальный контент.
+
+Приложение в главном цикле обрабатывает все пользовательские события. Главный цикл работает в главном потоке приложения. На изображении ниже показана схема работы главного цикла.
+
+
+
+В любой момент времени ваши приложение находятся в каком либо из перечисленных ниже состояний. Система меняет состояния вашего приложения в ответ на происходящие события. Например, когда пользователь нажимает кнопку Home, или поступает входящий вызов, или что либо еще - приложения в ответ на все это меняют свое состояние.
+
+* Not Running: Приложение не запущено, либо запущенно но прервано системой;
+* Inactive: Приложение работает, но в настоящий момент ничего не делает (это может быть связано с выполнением другого кода). Приложение, как правило, остается в этом состоянии очень мало времени и переходит в другое состояние;
+* Active: Нормальный обычный режим работы приложения на переднем плане;
+* Background: Приложение находится в фоне, но работает. Большинство приложений входят в это состояние на короткое время и позже приостанавливаются. Но если необходимо дополнительное время для работы в бекграунде, приложение может оставаться в этом состоянии;
+* Suspended: Приложение работает в фоне, но не выполняет никакой код. Система перемещает приложение в это состояние автоматически и не предупреждает об этом. При условии малого количества памяти, система может не предупреждая закрыть приложения в этом состоянии для освобождения памяти.
+
+
+
+Большинство переходов между состояниями обеспечивается соответствующими методами в AppDelegate.
+
+Приложение должно быть готово к завершению в любое время. Завершение - это нормальная часть жизненного цикла. Система обычно выключает приложения, для очищения памяти и подготовки к запуску других приложений, которые запущены пользователем, но система также может выключить приложения , которые некорректно или не отвечающим на события своевременно.
+
+Suspended приложения не получают уведомления о завершении. Система убивает процесс и восстанавливает соответствующую память. Если приложение запущено в фоне и не отвечает, система вызовет applicationWillTerminate: чтобы приложение подготовилось к выключению. Система не вызывает метод когда устройство перезагружается.
+
+Система создает приложение в основном потоке и вы можете создавать отдельные потоки, если вам это необходимо, для решения каких либо задач. Для приложений iOS, предпочтительным методом является использование Grand Central Dispatch (GCD), оперирующим с объектами, и другими интерфейсами асинхронного программирования не создавая и управляя потоками собственноручно. Такие технологии как GCD позволяют определить работу, которую вы хотите сделать и в каком порядке вы хотите ее сделать, но пусть система решает как лучше выполнить эту работу для CPU. Когда система управляет вашими потоками вам становиться легче писать код, обеспечивается большая корректность кода, а так же увеличивает общую производительность.
+
+
+
+Источники:
+
+* [Preworking 4: жизненный цикл iOS приложения](https://blog.justdev.org/preworking/preworking-4-ios-app-lifecicle/)
+
+Доп. материал:
+
+* [Официальная документация](https://developer.apple.com/documentation/uikit)
+* [Общее представление об архитектуре Clean Swift](https://habr.com/ru/post/453986/)
diff --git a/mobilnoe-testirovanie/arkhitektura-ios.md b/mobilnoe-testirovanie/arkhitektura-ios.md
new file mode 100644
index 0000000..52567eb
--- /dev/null
+++ b/mobilnoe-testirovanie/arkhitektura-ios.md
@@ -0,0 +1,113 @@
+# Архитектура iOS
+
+Все в курсе, что мобильные девайсы Apple работают под управлением iOS. Многие знают, что iOS представляет собой облегченную версию настольной Mac OS X. Некоторые догадываются, что в основе Mac OS X лежит POSIX-совместимая ОС Darwin, а те, кто всерьез интересуется IT, в курсе, что основа Darwin - это ядро XNU, появившееся на свет в результате слияния микроядра Mach и компонентов ядра FreeBSD. Однако все это голые факты, которые ничего не скажут нам о том, как же на самом деле работает iOS и в чем ее отличия от настольного собрата.
+
+**Mac OS X**
+
+Операционная система, установленная сегодня на все маки и (в измененном виде) на айдевайсы, ведет свою историю аж с 1988 года, который в мире IT известен также тем, что стал годом выпуска первой бета-версии операционной системы NeXTSTEP. Сама NeXTSTEP была детищем команды разработчиков Стива Джобса, который к тому времени уже покинул Apple и основал компанию NeXT, которая занялась разработкой компьютеров для образовательных нужд.
+
+В момент своего появления на свет NeXTSTEP была поистине передовой операционной системой, которая включала в себя множество технологических новаций. В основе ОС лежало модифицированное микроядро Mach, дополненное компонентами ядра FreeBSD, включая эталонную реализацию сетевого стека. Более высокоуровневые компоненты NeXTSTEP были написаны с использованием языка Objective-C и предоставляли разработчикам приложений богатый объектно-ориентированный API. Система была снабжена развитым и весьма удобным графическим интерфейсом (ключевые компоненты которого сохранились в OS X и даже iOS) и мощной средой разработки, включавшей в себя в том числе известный всем современным разработчикам визуальный дизайнер интерфейса.
+
+После провала NeXT и возвращения Стива Джобса в компанию Apple в 1997 году NeXTSTEP легла в основу проекта Rhapsody, в рамках которого началась разработка системы-наследника Mac OS 9. В 2000 году из Rhapsody был выделен открытый проект Darwin, исходники которого опубликованы под лицензией APSL, а уже в 2001 году появилась на свет OS X 10.0, построенная на его основе. Спустя несколько лет Darwin лег в основу операционной системы для готовящегося к выпуску смартфона, о котором до 2007-го, кроме слухов, не было известно почти ничего.
+
+**XNU и Darwin**
+
+Условно начинку OS X / iOS можно разделить на три логических уровня: ядро XNU, слой совместимости со стандартом POSIX (плюс различные системные демоны/сервисы) и слой NeXTSTEP, реализующий графический стек, фреймворк и API приложений. Darwin включает в себя первые два слоя и распространяется свободно, но только в версии для OS X. iOS-вариант, портированный на архитектуру ARM и включающий в себя некоторые доработки, полностью закрыт и распространяется только в составе прошивок для айдевайсов (судя по всему, это защита от портирования iOS на другие устройства).
+
+По своей сути Darwin - это «голая» UNIX-подобная ОС, которая включает в себя POSIX API, шелл, набор команд и сервисов, минимально необходимых для работы системы в консольном режиме и запуска UNIX-софта. В этом плане он похож на базовую систему FreeBSD или минимальную установку какого-нибудь Arch Linux, которые позволяют запустить консольный UNIX-софт, но не имеют ни графической оболочки, ни всего необходимого для запуска серьезных графических приложений из сред GNOME или KDE.
+
+Ключевой компонент Darwin - гибридное ядро XNU, основанное, как уже было сказано выше, на ядре Mach и компонентах ядра FreeBSD, таких как планировщик процессов, сетевой стек и виртуальная файловая система (слой VFS). В отличие от Mach и FreeBSD, ядро OS X использует собственный API драйверов, названный I/O Kit и позволяющий писать драйверы на C++, используя объектно-ориентированный подход, сильно упрощающий разработку.
+
+iOS использует несколько измененную версию XNU, однако в силу того, что ядро iOS закрыто, сказать, что именно изменила Apple, затруднительно. Известно только, что оно собрано с другими опциями компилятора и модифицированным менеджером памяти, который учитывает небольшие объемы оперативки в мобильных устройствах. Во всем остальном это все то же XNU, которое можно найти в виде зашифрованного кеша (ядро + все драйверы/модули) в каталоге /System/Library/Caches/com.apple.kernelcaches/kernelcache на самом устройстве.
+
+Уровнем выше ядра в Darwin располагается слой UNIX/BSD, включающий в себя набор стандартных библиотек языка си (libc, libmatch, libpthread и так далее), а также инструменты командной строки, набор шеллов (bash, tcsh и ksh) и демонов, таких как launchd и стандартный SSH-сервер. Последний, кстати, можно активировать путем правки файла /System/Library/LaunchDaemons/ssh.plist. Если, конечно, джейлбрейкнуть девайс.
+
+На этом открытая часть ОС под названием Darwin заканчивается, и начинается слой фреймворков, которые как раз и образуют то, что мы привыкли считать OS X / iOS.
+
+**Фреймворки**
+
+Darwin реализует лишь базовую часть Mac OS / iOS, которая отвечает только за низкоуровневые функции (драйверы, запуск/остановка системы, управление сетью, изоляция приложений и так далее). Та часть системы, которая видна пользователю и приложениям, в его состав не входит и реализована в так называемых фреймворках - наборах библиотек и сервисов, которые отвечают в том числе за формирование графического окружения и высокоуровневый API для сторонних и стоковых приложений
+
+Как и во многих других ОС, API Mac OS и iOS разделен на публичный и приватный. Сторонним приложениям доступен исключительно публичный и сильно урезанный API, однако jailbreak-приложения могут использовать и приватный.
+
+В стандартной поставке Mac OS и iOS можно найти десятки различных фреймворков, которые отвечают за доступ к самым разным функциям ОС - от реализации адресной книги (фреймворк AddressBook) до библиотеки OpenGL (GLKit). Набор базовых фреймворков для разработки графических приложений объединен в так называемый Cocoa API, своего рода метафреймворк, позволяющий получить доступ к основным возможностям ОС. В iOS он носит имя Cocoa Touch и отличается от настольной версии ориентацией на сенсорные дисплеи.
+
+Далеко не все фреймворки доступны в обеих ОС. Многие из них специфичны только для iOS. В качестве примеров можно привести AssetsLibrary, который отвечает за работу с фотографиями и видео, CoreBlueTooth, позволяющий получить доступ к синезубу, или iAd, предназначенный для вывода рекламных объявлений в приложениях. Другие фреймворки существуют только в настольной версии системы, однако время от времени Apple переносит те или иные части iOS в Mac OS или обратно, как, например, случилось с фреймворком CoreMedia, который изначально был доступен только в iOS.
+
+Все стандартные системные фреймворки можно найти в системном каталоге /System/Library/Frameworks/. Каждый из них находится в своем собственном каталоге, называемом бандлом (boundle), который включает в себя ресурсы (изображения и описание элементов интерфейса), хидеры языка си, описывающие API, а также динамически загружаемую библиотеку (в формате dylib) с реализацией фреймворка.
+
+Одна из интересных особенностей фреймворков - их версионность. Один фреймворк может иметь сразу несколько разных версий, поэтому приложение, разработанное для устаревших версий системы, будет продолжать работать, даже несмотря на изменения, внесенные в новые версии ОС. Именно так реализован механизм запуска старых iOS-приложений в iOS 7 и выше. Приложение, разработанное для iOS 6, будет выглядеть и работать именно так, как если бы оно было запущено в iOS 6.
+
+**SpringBoard**
+
+Уровнем выше находятся приложения, системные и устанавливаемые из магазина приложений. Центральное место среди них занимает, конечно же, SpringBoard (только в iOS), реализующее домашний экран (рабочий стол). Именно оно запускается первым после старта системных демонов, загрузки в память фреймворков и старта дисплейного сервера (он же менеджер композитинга, он же Quartz Compositor), отвечающего за вывод изображения на экран.
+
+SpringBoard - это связующее звено между операционной системой и ее пользователем, графический интерфейс, позволяющий запускать приложения, переключаться между ними, просматривать уведомления и управлять некоторыми настройками системы (начиная с iOS 7). Но также это и обработчик событий, таких как касание экрана или переворот устройства. В отличие от Mac OS X, которая использует различные приложения и демоны-агенты для реализации компонентов интерфейса (Finder, Dashboard, LaunchPad и другие), в iOS почти все базовые возможности интерфейса пользователя, в том числе экран блокировки и «шторка», заключены в одном SpringBoard.
+
+В отличие от других стоковых приложений iOS, которые располагаются в каталоге /Applications, SpringBoard наравне с дисплейным сервером считается частью фреймворков и располагается в каталоге /System/Library/CoreServices/. Для выполнения многих задач он использует плагины, которые лежат в /System/Library/SpringBoardPlugins/. Кроме всего прочего, там можно найти, например, NowPlayingArtLockScreen.lockboundle, отвечающий за отображение информации о проигрываемой композиции на экране блокировки, или IncomingCall.serviceboundle, ответственный за обработку входящего звонка.
+
+Начиная с iOS 6 SpringBoard разделен на две части: сам рабочий стол и сервис BackBoard, ответственный за коммуникации с низкоуровневой частью ОС, работающей с оборудованием (уровень HAL). BackBoard отвечает за обработку таких событий, как касания экрана, нажатия клавиш, получение показания акселерометра, датчика положения и датчика освещенности, а также управляет запуском, приостановкой и завершением приложений.
+
+SpringBoard и BackBoard имеют настолько большое значение для iOS, что, если каким-либо образом их остановить, вся система застынет на месте и даже запущенное в данный момент приложение не будет реагировать на касания экрана. Это отличает их от домашнего экрана Android, который является всего лишь стандартным приложением, которое можно остановить, заменить или вообще удалить из системы (в этом случае на экране останутся вполне рабочие кнопки навигации и строка состояния со «шторкой»).
+
+**Приложения**
+
+На самой вершине этой пирамиды находятся приложения. iOS различает встроенные (стоковые) высоко привилегированные приложения и сторонние, устанавливаемые из iTunes. И те и другие хранятся в системе в виде бандлов, во многом похожих на те, что используются для фреймворков. Разница заключается лишь в том, что бандл приложения включает в себя несколько иную метаинформацию, а место динамической библиотеки занимает исполняемый файл в формате Mach-O.
+
+Стандартный каталог хранения стоковых приложений - /Applications/. В iOS он абсолютно статичный и изменяется только во время обновлений системы; пользователь получить к нему доступ не может. Сторонние приложения, устанавливаемые из iTunes, напротив, хранятся в домашнем каталоге пользователя /var/mobile/Applications/ внутри подкаталогов, имеющих вид 4-2-2-2-4, где два и четыре - это шестнадцатеричные числа. Это так называемый GUID - уникальный идентификатор, который однозначно идентифицирует приложение в системе и нужен в том числе для создания изолированной песочницы (sandbox).
+
+**Sandbox**
+
+В iOS песочницы используются для изолирования сервисов и приложений от системы и друг от друга. Каждое стороннее приложение и большинство системных работают в песочнице. С технической точки зрения песочница представляет собой классический для мира UNIX chroot, усиленный системой принудительного контроля доступа TrustedBSD MAC (модуль ядра sandbox.kext), которая отрезает приложениям не только доступ к файлам за пределами домашнего каталога, но и прямой доступ к железу и многим системным функциям ОС.
+
+В целом заключенное в sandbox приложение ограничено в следующих возможностях:
+
+* Доступ к файловой системе за исключением своего собственного каталога и домашнего каталога пользователя.
+* Доступ к каталогам Media и Library внутри домашнего каталога за исключением Media/DCIM/, Media/Photos/, Library/AddressBook/, Library/Keyboard/ и Library/Preferences/.
+* Доступ к информации о других процессах (приложение «считает» себя единственным в системе).
+* Прямой доступ к железу (разрешено использовать только Cocoa API и другие фреймворки).
+* Ограничение на использование оперативной памяти (контролируется механизмом Jatsam).
+
+Все эти ограничения соответствуют sandbox-профилю (набору ограничивающих правил) container и применяются к любому стороннему приложению. Для стоковых приложений, в свою очередь, могут применяться другие ограничения, более мягкие или жесткие. В качестве примера можно привести почтовый клиент (профиль MobileMail), который в целом имеет такие же серьезные ограничения, как и сторонние приложения, но может получить доступ ко всему содержимому каталога Library/. Обратная ситуация - SpringBoard, вообще не имеющий ограничений.
+
+Внутри песочниц работают многие системные демоны, включая, например, AFC, предназначенный для работы с файловой системой устройства с ПК, но ограничивающий «область видимости» только домашним каталогом пользователя. Все доступные системные sandbox-профили располагаются в каталоге /System/Library/Sandbox/Profiles/\* и представляют собой наборы правил, написанных на языке Scheme. Кроме этого, приложения также могут включать в себя дополнительные наборы правил, называемых entitlement. По сути, это все те же профили, но вшитые прямо в бинарный файл приложения (своего рода самоограничение).
+
+Смысл существования всех этих ограничений двойной. Первая (и главная) задача, которую решает sandbox, - это защита от вредоносных приложений. Вкупе с тщательной проверкой опубликованных в iTunes приложений и запретом на запуск не подписанных цифровым ключом приложений (читай: любых, полученных не из iTunes) такой подход дает прекрасный результат и позволяет iOS находиться на вершине в списке самых защищенных от вирусов ОС.
+
+Вторая проблема - это защита системы от самой себя и пользователя. Баги могут существовать как в стоковом софте от Apple, так и в головах юзеров. Sandbox защищает от обоих. Даже если злоумышленник найдет дыру в Safari и попытается ее эксплуатировать, он все равно останется в песочнице и не сможет навредить системе. А юзер не сможет «сломать свой любимый телефончик» и не напишет гневных отзывов в адрес Apple. К счастью, знающие люди всегда могут сделать jailbreak и обойти защиту sandbox (собственно, в этом и есть смысл джейлбрейка).
+
+**Многозадачность**
+
+Одна из самых спорных особенностей iOS - это реализация многозадачности. Она вроде бы и есть, а с другой стороны, ее нет. В сравнении с традиционными настольными ОС и пресловутым Android iOS не является многозадачной операционной системой в привычном смысле этого слова и не позволяет приложениям свободно работать в фоне. Вместо этого ОС реализует API, который приложение может использовать для выполнения отдельных задач, пока оно находится в фоновом режиме.
+
+Впервые такой API появился в iOS 4 (до этого фоновые задачи могли выполнять только стоковые приложения) и наращивался по мере развития операционной системы. Сегодня (речь идет об iOS 7) так называемый Background API позволяет делать следующее:
+
+* проигрывать аудио;
+* совершать VoIP-звонки;
+* получать информацию о смене местоположения;
+* получать push-уведомления;
+* планировать отложенный вывод уведомлений;
+* запрашивать дополнительное время для завершения работы после перехода в фоновый режим;
+* обмениваться данными с подключенными к девайсу аксессуарами (в том числе Bluetooth);
+* получать и отправлять данные по сети (начиная с iOS 7).
+
+Такие ограничения на работу в фоне необходимы в первую очередь для того, чтобы сохранить заряд батареи и избежать лагов интерфейса, так знакомых пользователям Android, где приложения могут делать в фоне все что захотят. На самом деле Apple настолько сильно заботится о сохранении батареи, что даже реализовала специальный механизм для группировки фоновых действий приложений и их запуска в нужные моменты, например тогда, когда смартфон активно используется, подключен к Wi-Fi-сети или к зарядному устройству.
+
+**Шесть стадий загрузки iOS**
+
+
+
+* Boot ROM. После включения устройства первым запускается минималистичный загрузчик, прошитый в постоянную память устройства. Его задача - произвести начальную инициализацию железа и передать управление первичному загрузчику LLB. Boot ROM всегда имеет заводскую прошивку и не может быть обновлен.
+* Low Level Bootloader (LLB). Далее управление получает LLB. Это первичный загрузчик, задача которого - найти в памяти устройства iBoot, проверить его целостность и передать ему управление либо переключить девайс в режим восстановления, если это не удалось. Код LLB хранится в NAND-памяти устройства и обновляется вместе с установкой новой версии прошивки. Кроме всего прочего, он выводит на экран загрузочный логотип.
+* iBoot. Это вторичный и основной загрузчик айдевайсов. Он включает в себя драйвер файловой системы, с помощью которого получает доступ к содержимому NAND-памяти, находит ядро и передает ему управление. В iBoot также встроен драйвер UART, с помощью которого можно производить отладку ядра и ОС, подключив девайс к COM-порту или USB-порту компа (с помощью кабеля USB - UART).
+* Ядро. Здесь все как обычно. Ядро производит инициализацию оборудования, после чего передает управление демону launchd.
+* Launchd. Это первичный процесс iOS и Mac OS X, он подключает файловые системы, запускает демоны/службы (например, backupd, configd, locationd), дисплейный сервер, фреймворки, а на последнем этапе загрузки отдает управление SpringBoard. В iOS и Mac OS X launchd используется как замена стандартного /bin/init в UNIX, однако его функциональность гораздо шире.
+* SpringBoard. Вот и экран блокировки!
+
+Первые четыре этапа в этой цепи образуют chain of trust, реализованный с помощью сверки цифровой подписи загружаемого компонента. Цифровую подпись имеют LLB, iBoot и ядро, что позволяет исключить внедрение в цепочку хакнутого загрузчика или ядра, которые могут быть использованы для загрузки сторонней операционной системы или джейлбрейка. Единственный способ обойти этот механизм - найти дыру в одном из загрузчиков и воспользоваться ею для обхода проверки. В свое время было найдено несколько таких дыр в Boot ROM (наиболее известен эксплойт limera1n от geohot, актуальный для iPhone 1-4), а в начале 2014 года и в iBoot (хакер iH8sn0w, эксплойт так и не был опубликован).
+
+Удерживая кнопку «Домой» при включении iPhone, можно заставить iBoot загрузиться в так называемый режим восстановления (Recovery), который позволяет восстановить прошивку iOS или обновить ее, используя iTunes. Однако механизм автоматического OTA-обновления использует другой режим, именуемый DFU (Device Firmware Upgrade), который активируется на раннем этапе загрузки сразу после Boot ROM и реализован в двух компонентах: iBSS и iBEC. По сути, это аналоги LLB и iBoot, конечная цель которых - не загрузить ОС, а перевести смартфон в режим обновления.
+
+Источники:
+
+* [Как устроена iOS](https://xakep.ru/2014/10/08/kau-ustroena-ios/)
diff --git a/mobilnoe-testirovanie/kak-protestirovat-prilozhenie-dlya-drugoi-strany.md b/mobilnoe-testirovanie/kak-protestirovat-prilozhenie-dlya-drugoi-strany.md
new file mode 100644
index 0000000..c3b0be8
--- /dev/null
+++ b/mobilnoe-testirovanie/kak-protestirovat-prilozhenie-dlya-drugoi-strany.md
@@ -0,0 +1,7 @@
+# Как протестировать приложение для другой страны?
+
+* VPN;
+* Сброс до заводских настроек и выбор нужного региона;
+* Fake GPS;
+* Google/Apple аккаунт нужной страны.
+
diff --git a/mobilnoe-testirovanie/kak-proverit-ispolzovanie-resursov-na-android.md b/mobilnoe-testirovanie/kak-proverit-ispolzovanie-resursov-na-android.md
new file mode 100644
index 0000000..1996a12
--- /dev/null
+++ b/mobilnoe-testirovanie/kak-proverit-ispolzovanie-resursov-na-android.md
@@ -0,0 +1,5 @@
+# Как проверить использование ресурсов на Android
+
+* В Google Play доступны различные приложения, такие как CPU Monitor, Usemon, CPU Stats, CPU-Z и т. д. Это расширенный инструмент, который записывает информацию о процессах, запущенных на вашем устройстве. Не все показатели могут быть доступны без root, это зависит от конкретного устройства.
+* В инструментах разработчика доступны инструменты профилирования;
+* [Профилировщик в IDE (Android Studio)](https://developer.android.com/studio/profile/android-profiler).
diff --git a/mobilnoe-testirovanie/kak-uspeshno-zarelizit-produkt-v-app-store-i-google-play.md b/mobilnoe-testirovanie/kak-uspeshno-zarelizit-produkt-v-app-store-i-google-play.md
new file mode 100644
index 0000000..7e2076a
--- /dev/null
+++ b/mobilnoe-testirovanie/kak-uspeshno-zarelizit-produkt-v-app-store-i-google-play.md
@@ -0,0 +1,48 @@
+# Как успешно зарелизить продукт в App Store и Google Play
+
+**Специфика работы с платформой Apple**
+
+* Review Guidelines. Любые реджекты, баны и блокировки всегда исходят из нарушений этих гайдов, ну или потому что Apple посчитали, что вы их нарушаете. Гайдлайны регулярно обновляются, особенно много обновлений бывает перед и после конференции WWDC;
+* Следующий по важности документ - [гайдлайны интерфейсов](https://developer.apple.com/design/human-interface-guidelines/). Здесь представлены рекомендации и лучшие практики по построению красивых, удобных и понятных интерфейсов для всех устройств Apple. Его необходимо прочитать хотя бы раз любому дизайнеру интерфейсов, а также полезно будет QA-специалистам и разработчикам;
+* [App Store Connect](https://help.apple.com/app-store-connect/en.lproj/static.html) - навряд ли часто открывают. В то же время это исчерпывающая инструкция по использованию консоли для управления вашим приложением. Всякий раз, когда у вас возникает вопрос по работе с Connect’ом, пожалуйста, сверяйтесь с документацией;
+* Если у вас уже было опубликовано приложение с поддержкой iPad, то выпилить поддержку уже не получится.
+
+**Топ-8 причин для реджектов от Apple (в Google Play примерно также)**:
+
+* App Completeness - не работающие приложения с крашами и багами;
+* Inaccurate Metadata - подробно и точно описывайте функционал приложений, прикрепляйте правильные скриншоты;
+* Incomplete Info - важно рассказать о вашем продукте все, что стоит знать ревьюерам. Проверяйте актуальность тестовых учеток перед сабмитом. Если вы что-то экспериментируете в билде, расскажите об этом команде ревью;
+* Unusual Interface - Apple не зря сделали целый портал про свои интерфейсы. Они хотят чтобы все приложения работали так, как пользователи от них этого ждут. Хороший пример Албания, в которой привычное для нас качание головой вверх-вниз означает нет, а из стороны в сторону - да. Apple это весь мир, не будьте в этом мире Албанией;
+* Web Content Aggregators - сайты обернутые в iOS приложение обычно не принимаются;
+* Similar App Submission - Apple хотят видеть уникальные приложения и если вы вдруг решили запустить сразу пять одинаковых игр дабы увеличить шансы на взрывной рост, то рискуете остаться без взрывного роста и без приложений;
+* Misleading Offers - мы все прошли через рентген для камеры нокии. Не обещать того, чего нет;
+* Not Enough Value - Apple хотят видеть уникальные приложения. Это касается не только конкретного разработчика, но и всех вместе. Не нужно делать десятитысячный калькулятор и миллионный фонарик, их достаточно. Также не нужно делать приложение, которым будут пользоваться три человека. Ваше приложение должно нести в себе нужный широкому пользователю, уникальный функционал.
+
+**Специфика работы с платформой Google Play Developer**:
+
+* Необходимо следить за [предстоящими обновлениями гайдлайнов](https://developer.android.com/distribute/play-policies) перед и после конференции Google I/O;
+* Все политики вы найдете в [Google Play Developer Policy Center](https://play.google.com/intl/en/about/developer-content-policy/), они написаны на русском языке, что заметно удобнее. Во многом политики Google и Apple схожи, однако различия есть и иногда они весьма значительны - обратите на это свое внимание, прочитать и использовать политики только одной платформы - плохая идея;
+* Самый полезный ресурс для понимания работы консоли Google Play - это [Google Play Academy](https://playacademy.exceedlms.com/student/catalog), там есть ответы на 90% вопросов и все возможные сценарии ее использования как с точки зрения пользователя (разработчика) так и для маркетологов и ASO-специалистов;
+* Если у вас есть вопросы по дизайну своего продукта, вы сомневаетесь о проценте прозрачности или даже не знаете правильно ли используете жесты, вы найдете ответ на свой вопрос и/или сможете открыть для себя что-то новое и полезное для ваших приложений в гайдлайнах [Material Design](https://material.io/design/introduction).
+
+**Соблюдайте правила сторов**
+
+В Apple и Google сидят весьма смышленые ребята, основная задача которых не допустить того, чтобы приложения противоречили их политикам:
+
+* не прячьте части функционала приложения от ревьюверов;
+* не пытайтесь обойти комиссию платформ и прятать 3rd-party эквайринг;
+* не вводите пользователя в заблуждение;
+* не запрашивайте лишние доступы, объясняйте зачем нужны доступы, которые запрашиваете.
+
+Источники:
+
+* [Как успешно зарелизить продукт в App Store и Google Play](https://telegra.ph/Kak-uspeshno-zarelizit-produkt-v-App-Store-i-Google-Play-02-27)
+
+Доп. материал:
+
+* [Policies & publishing on Google Play](https://www.youtube.com/watch?v=ZDS4diFfBmQ)
+* [Соответствие правилам для страниц приложений в Google Play](https://playacademy.exceedlms.com/student/activity/15949)
+* [Запуск приложения или игры](https://playacademy.exceedlms.com/student/path/16605)
+* [Pre-launch testing for mobile games: tools and best practices on Google Play](https://medium.com/googleplaydev/test-pre-launch-96d0ef3c4d51)
+* [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)
+* [App Store Connect](https://developer.apple.com/support/app-store-connect/)
diff --git a/mobilnoe-testirovanie/kakim-obrazom-testirovshik-poluchaet-prilozhenie-na-test.md b/mobilnoe-testirovanie/kakim-obrazom-testirovshik-poluchaet-prilozhenie-na-test.md
new file mode 100644
index 0000000..82af641
--- /dev/null
+++ b/mobilnoe-testirovanie/kakim-obrazom-testirovshik-poluchaet-prilozhenie-na-test.md
@@ -0,0 +1,18 @@
+# Каким образом тестировщик получает приложение на тест?
+
+**Android**:
+
+* Разработчик скинет .apk :) или .aab, который нужно разархивировать;
+* Из CI-агента. Тот же Jenkins/TeamCity может присылать ссылку на билд в tg-канал или можно забрать его вручную;
+* Сбилдить в Android Studio самому из нужной ветки;
+* [Открытые и закрытые бета-тестирования приложений в Google Play](https://support.google.com/googleplay/android-developer/answer/9845334?hl=ru);
+
+**iOS**:
+
+* сбилдить в Xcode;
+* внутреннее и внешнее тестирование в [TestFlight](https://testflight.apple.com);
+* сервис [tiny.app.link](https://getappbox.com)
+
+Доп. материал:
+
+* [Visual Studio App Center](https://appcenter.ms)
diff --git a/mobilnoe-testirovanie/middleware.md b/mobilnoe-testirovanie/middleware.md
new file mode 100644
index 0000000..85f468c
--- /dev/null
+++ b/mobilnoe-testirovanie/middleware.md
@@ -0,0 +1,40 @@
+# Middleware
+
+
+
+Связу́ющее програ́ммное обеспе́чение (англ. middleware; также переводится как промежу́точное программное обеспечение, программное обеспечение среднего слоя, подпрогра́ммное обеспечение, межплатфо́рменное программное обеспечение) - широко используемый термин, означающий слой или комплекс технологического программного обеспечения для обеспечения взаимодействия между различными приложениями, системами, компонентами. (с) Вики. В данном разделе нас интересует применение в мобильной разработке.
+
+Особенностью заказной разработки мобильных приложений является то, что основной сервер с API обычно предоставляет заказчик. Ниже список, с чем в этом случае придется иметь дело мобильным разработчикам:
+
+* API не дописано - разработчики заказчика загружены текущей работой и не мотивированы сдать его в срок, при том, что у маркетинга планы и сроки запуска мобильного приложения горят;
+* API сильно не совпадает со структурой мобильного приложения (данные для экранов приходится дергать с 3-4 методов и обрабатывать локально);
+* Нет документации, либо она сильно разрознена и не актуальна;
+* Несколько точек входа (разросшаяся инфраструктура находится на нескольких серверах с разными адресами);
+* Уже существующее API меняется после апдейтов основного сайта;Отсутствие тестовых серверов;
+* Баги (много багов).
+
+И добавим сюда понимание, что со всем этим придется бороться сразу на двух платформах, которые хоть и являются мобильными, часто используют разные архитектурные подходы и, как следствие, разные сроки старта и готовности этапов. Все это приводит к увеличению сроков разработки и, соответственно, стоимости разработки.
+
+Для минимизации всех этих проблем предлагается использовать промежуточный сервер - шину данных.
+
+Middleware - чаще всего простой быстро настраиваемый сервер, не хранящий каких-либо данных, кроме логов. Он позволяет использовать для общения мобильных приложений с собой простой REST API, строго подогнанный под логику экранов, а сам уже обращается к целевому API необходимым образом.
+
+Бонусом мы имеем возможность разрабатывать приложения со своими наработками по авторизации, обработкам ошибок и прочим мелочам, протестированными и проверенными.
+
+Плюсы такого подхода:
+
+* Отсутствуют простои из-за неготовности API заказчика - в худшем случае на шине отдаются тестовые данные;
+* Упрощается реализация мобильного приложения практически до тонкого клиента;
+* Единственная точка входа позволяет упростить архитектуру работы с сетью в МП;
+* Возможность выкладывать обновления для сервера шины (меняющую взаимодействие с сервером заказчиком) без обновления МП, в кратчайшие сроки, без модерации со стороны третьих фирм;
+* Простота и отсутствие полноценной БД позволяет легко разворачивать любое количество тестовых серверов;
+* Удобное логирование всех сетевых ошибок и оповещение о них;
+* Изменения в работе API заказчика необходимо вносить только в одном месте - на сервере шины;
+* Документация ведется принятым и привычным в компании способом;
+* Использование наработок снижает сроки и стоимость разработки.
+
+Все это позволяет снизить сроки и стоимость, напрямую и косвенно, за счет снижения рисков простоя, сложности реализации серверной части и тестирования. Шикарный бонус разработчику - возможность предложить более низкую цену и выиграть конкурс, а заказчику - сэкономить и уменьшить сроки внедрения МП.
+
+Источники:
+
+* [Middleware, необходимость в мире разработки мобильных приложений](https://www.saratovit.ru/2019/12/27/middleware-mobile-apps/)
diff --git a/mobilnoe-testirovanie/osnovnye-proverki-pri-testirovanii-mobilnogo-prilozheniya.md b/mobilnoe-testirovanie/osnovnye-proverki-pri-testirovanii-mobilnogo-prilozheniya.md
new file mode 100644
index 0000000..e0c11f1
--- /dev/null
+++ b/mobilnoe-testirovanie/osnovnye-proverki-pri-testirovanii-mobilnogo-prilozheniya.md
@@ -0,0 +1,133 @@
+# Основные проверки при тестировании мобильного приложения
+
+
+
+
+
+В описанный ниже чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению. Чек-лист состоит из восьми разделов:
+
+* Функциональное тестирование;
+* Тестирование совместимости;
+* Тестирование безопасности;
+* Тестирование локализации и глобализации;
+* Тестирование удобства использования;
+* Стрессовое тестирование;
+* Кросс-платформенное тестирование;
+* Тестирование производительности.
+
+**Функциональное тестирование**: В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
+
+* Установка/удаление/накатка версий;
+* Запуск приложения (отображение Splash Screen);
+* Работоспособность основного функционала приложения;
+ * Авторизация (по номеру телефона/через соц. сети/e-mail);
+ * Регистрация (по номеру телефона/через соц. сети/e-mail);
+ * Онбординг новых пользователей;
+ * Валидация обязательных полей;
+ * Навигация между разделами приложения;
+ * Редактирование данных в профиле пользователя;
+ * Проверка оплаты;
+ * Тестирование фильтров;
+ * Бонусы;
+* Корректное отображение ошибок;
+* Работа с файлами (отправка/получение/просмотр);
+* Тестирование тайм-аутов;
+* Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д);
+* Тестирование pop-up, алертов;
+* Тестирование WebView;
+* Скролл/свайп элементов;
+* Тестирование PUSH уведомлений;
+* Сворачивание/разворачивание приложения;
+* Разные типы подключений (сотовая связь/Wi-Fi);
+* Ориентация экрана (альбомная/портретная);
+* Темная/светлая темы;
+* Реклама в приложении;
+* Шаринг контента в соц. сети;
+* Работа приложения в фоне;
+* Пагинация страниц;
+* Политики конфиденциальности и прочие ссылки на документы.
+
+**Тестирование совместимости**: Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
+
+* Корректное отображение гео;
+* Информации об операциях (чеки и т.д.);
+* Различные способы оплаты (Google Pay, Apple Pay);
+* Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.);
+* Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.);
+* Подключение внешних устройств (карта памяти/наушники и т.д.).
+
+**Тестирование безопасности**: Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
+
+* Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.);
+* Данные пользователя (пароли) не передаются в открытом виде;
+* В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками.
+
+**Тестирование локализации и глобализации**: Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
+
+* Все элементы в приложении переведены на соответствующий язык;
+* Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык;
+* Тексты зависят от языка в системных настройках;
+* Тексты приходят с сервера;
+* Корректное отображение форматов дат (ГОД - МЕСЯЦ - ДЕНЬ или ДЕНЬ - МЕСЯЦ - ГОД.);
+* Корректное отображение времени в зависимости от часового пояса.
+
+**Тестирование удобства использования**
+
+Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
+
+* Корректное отображение элементов на устройствах с различными разрешениями экранов;
+* Все шрифты соответствуют требованиям;
+* Все тексты правильно выровнены;
+* Все сообщения об ошибках верные, без орфографических и грамматических ошибок;
+* Корректные заголовки экранов;
+* В поисковых строках присутствуют плейсхолдеры;
+* Неактивные элементы отображаются серым;
+* Ссылки на документы ведут на соответствующий раздел на сайте;
+* Анимация между переходами;
+* Корректный возврат на предыдущий экран;
+* Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.);
+* Пиксель-перфект.
+
+**Стрессовое тестирование**: Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
+
+* Высокая загрузка центрального процессора;
+* Нехватка памяти;
+* Загрузка батареи;
+* Отказы;
+* Низкая пропускная способность сети;
+* Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети).
+
+**Кросс-платформенное тестирование**: Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
+
+* Работоспособность приложения на различных устройствах разных производителей
+
+**Тестирование производительности**: Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
+
+* Время загрузки приложения;
+* Обработка запросов;
+* Кэширование данных;
+* Потребление ресурсов приложением (например расход заряда батареи).
+
+Помимо прочего, можно использовать **эвристики и мнемоники**: I SLICED UP FUN, COP FLUNG GUN, SFDPOT, LONG FUN CUP.
+
+_Примечание: в свете последних анонсов раскладных смартфонов и Android 12L, следует также при необходимости учитывать такие кейсы._
+
+Источники:
+
+* [Чек-лист тестирования мобильных приложений](https://habr.com/ru/post/534190/)
+
+Доп. материал:
+
+* [Распространенные баги на iOS](https://telegra.ph/bagi-na-iOS-02-05)
+* [Распространенные баги на Android](https://telegra.ph/bagi-na-android-10-07)
+* [ISTQB Mobile Application Testing](https://www.istqb.org/certification-path-root/mobile-application-testing.html)
+* [Mobile App Testing Tutorials (A Complete Guide With 30+ Tutorials)](https://www.softwaretestinghelp.com/beginners-guide-to-mobile-application-testing/)
+* [Жизнь без AppStore и Google Play: работаем с Huawei Mobile Services и AppGallery](https://habr.com/ru/post/551262/)
+* [Особенности тестирования Android без Google-сервисов](https://habr.com/ru/company/surfstudio/blog/559106/)
+* YaTalks 2021. Mobile: [Моделирование угроз для мобильных приложений](https://www.youtube.com/watch?v=0AQlKbskhkM\&t=16024s) + [презентация](https://disk.yandex.ru/i/kLk2Nscwqnto2Q)
+* [Как тестировать мобильные игры](https://dou.ua/forums/topic/34948/)
+* [Free Mobile App Testing Tutorial](https://www.guru99.com/mobile-testing.html)
+* [Как тестировать мобильное приложение](https://www.youtube.com/watch?v=sCpY9E9oKW4)
+* [Простые мобильные баги: примеры](https://www.youtube.com/watch?v=cqF99cqtcTw)
+* [Чеклист по UX из 30 пунктов для мобильных приложений](https://habr.com/ru/company/edison/blog/474472/)
+* Больше чек-листов и идей можно найти в разделе полезных ресурсов
diff --git a/mobilnoe-testirovanie/osnovnye-razlichiya-android-ios.md b/mobilnoe-testirovanie/osnovnye-razlichiya-android-ios.md
new file mode 100644
index 0000000..3090d70
--- /dev/null
+++ b/mobilnoe-testirovanie/osnovnye-razlichiya-android-ios.md
@@ -0,0 +1,27 @@
+# Основные различия Android/iOS
+
+Последние годы обе системы заимствовали что-то друг у друга и пользовательский опыт теперь у них мало чем отличается, тем не менее, различий всё ещё хватает в другом:
+
+* iOS - закрытая система, а Android - open-source;
+* Языки разработки: Android - Kotlin/Java, iOS - objective-С или Swift;
+* Гайдлайны: [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/) (HIG) у iOS и [Material Design](https://material.io) у Android;
+* Простота получения root-прав на многих устройствах Android;
+* Различная целевая аудитория, в т.ч. разный ее размер (у Android сегодня ориентировочно 80% всех гаджетов в мире);
+* Различная монетизация, в т.ч. ее размер (согласно статистике, iOS пользуются более платежеспособные люди, которые делают покупки в 3 раза чаще);
+* Различный market share (например, в США в лидерах айфоны);
+* Отличия в модерации приложений для публикации в магазине приложений - у Android процедура значительно быстрее и проще;
+* Функция «Назад» (виртуальная кнопка или жест). Во всех Android-смартфонах клавишу, возвращающую на шаг назад, можно закрепить в нижней части экрана (вместе с виртуальными кнопками возврата на главный экран и вызова меню запущенных программ). С жестами ситуация не отличается: на каком экране (или в каком приложении) ни находился бы юзер, проведя пальцем вправо или влево от соответствующей стороны дисплея, он сможет вернуться на шаг назад. В iOS все работает немного иначе. Вернее, универсальности на уровне системы, а не отдельной программы не предусмотрено. В некоторых приложениях жест «Назад» присутствует (например, в популярном Instagram) и действует едва ли не с середины дисплея - удобно. Где-то такое работает только с левого края экрана (скажем, в приложении «Настройки»). Еще где-то его просто нет. «Передвигаться» по меню такие программы предлагают нажатием на виртуальную клавишу, предусмотренную разработчиками конкретной программы;
+* В сети в целом часто жалуются на файловую систему iOS. Вернее, претензии предъявляются к ее серьезной ограниченности. Если к Android-устройству можно подключить накопитель и переписать данные с него или на него, или оперировать файлами через тот же telegram, то с iPhone такое уже не пройдет (не считая условных фотографий, и то не без «костылей», если речь не про синхронизацию с Mac);
+* Отсутствие возможности набора текста свайпами на русской раскладке фирменной клавиатуры Apple (в сторонних можно);
+* Скачать какой-нибудь .ipa и установить в обход App Store не получится;
+* Возможность установки свежей версии «операционки» на смартфоны от Apple, вышедшие более пяти лет назад и уже не доступные в продаже.
+
+Источники:
+
+* [Как я перешел на iPhone после многих лет с Android-смартфонами. Плюсы и минусы экосистемы Apple](https://tech.onliner.by/2021/11/22/plyusy-i-minusy-ekosistemy-apple)
+
+Доп. материал:
+
+* [32 отличия дизайна мобильного приложения под iOS и Android](https://habr.com/ru/company/redmadrobot/blog/491674/)
+* [Гайдлайны Google Material и Apple Human Interface. Android, iOS и Material You](https://www.youtube.com/watch?v=28m34MR\_g2c)
+* [Difference Between iOS and Android Testing](https://w3softech.com/blog/difference-between-ios-and-android-testing/)
diff --git a/mobilnoe-testirovanie/osobennosti-v-testirovanii-mobilnykh-prilozhenii.md b/mobilnoe-testirovanie/osobennosti-v-testirovanii-mobilnykh-prilozhenii.md
new file mode 100644
index 0000000..9c27154
--- /dev/null
+++ b/mobilnoe-testirovanie/osobennosti-v-testirovanii-mobilnykh-prilozhenii.md
@@ -0,0 +1,23 @@
+# Особенности в тестировании мобильных приложений
+
+Многие особенности очевидны из самого названия “мобильные” - смартфон имеет маленький дисплей, им пользуются на ходу и в условиях совместного использования с большим количеством других приложений и подключенных устройств, а высокий темп современной жизни заставит пользователя уйти к конкурентам, если экран приложения загружается дольше пары секунд, если с приложением сложно взаимодействовать или оно доставляет еще какие-либо неудобства.
+
+**Отличия от веба и десктопа**:
+
+* Постоянные прерывания в работе приложения: сворачивание, блокировка, входящий звонок или сообщение, уведомления, обновления приложений, выключение или перезагрузка, выгрузка системой из ОЗУ, разряд АКБ, подключение зарядки или других устройств, переход в энергосберегающий режим и режим ожидания, включение и отключение функций необходимых устройству (gps, bluetooth, связь), использование/отзыв разрешений, подключение/отключение карты памяти/симки/АКБ, платежи NFC, принудительная остановка);
+* Работа в беспроводной сети с изменяющейся стабильностью и скоростью приема сигнала, переключение между сотовой связью и wi-fi;
+* Уведомления;
+* Взаимодействие с web view;
+* Использование вертикальной и горизонтальной ориентации, повороты;
+* Распространение приложений через маркеты;
+* Необходимо соответствие гайдлайнам систем;
+* Большое внимание уделяется UI и UX;
+* В случае Android большая фрагментация устройств и прошивок со своими особенностями;
+* Тач-интерфейс, мультитач, жесты;
+* Множество каналов ввода: стоковая клавиатура, сторонние клавиатуры, хардовые клавиатуры, голос, жесты и т. д.;
+* Биометрия;
+* Повышенные требования к энергопотреблению и использованию аппаратных ресурсов;
+* Ситуации установки и обновления при нехватке памяти, переноса приложения на карту памяти и обратно;
+* Важность инсталляционного тестирования, особенно обновлений, т.к. в условиях высококонкурентного мобильного рынка приложения обновляются часто, чтобы предоставить пользователям новые функции как можно скорее и при этом должны проходить бесшовно;
+* GPS и локализация;
+* Размер дисплея, челка и вырез под фронтальную камеру;
diff --git a/mobilnoe-testirovanie/pokrytie-devaisov.md b/mobilnoe-testirovanie/pokrytie-devaisov.md
new file mode 100644
index 0000000..36cbd0e
--- /dev/null
+++ b/mobilnoe-testirovanie/pokrytie-devaisov.md
@@ -0,0 +1,42 @@
+# Покрытие девайсов
+
+В крупной компании джун-тестировщик с этим вопросом столкнется разве что на собеседовании. Можно рассказать общие принципы:
+
+* составление таблицы на 5-10 критериев отбора;
+* выбор, учитывая особенности приложения, характеристики реальных устройств и бюджет;
+* упомянуть, что девайс на руках - не единственный вариант, частично можно протестировать эмуляторами и симуляторами и про фермы тоже не забыть.
+
+В компании поменьше, оказавшись в начале пути перед выбором реальным, а не теоретическим, будет заметно сложнее. Самый простой и быстрый вариант, взять готовый усредненный список предлагаемый [BrowserStack](https://www.browserstack.com/test-on-the-right-mobile-devices). Если не ищете легких путей - идем дальше.
+
+**Первым делом запросите статистику у команды**
+
+Если вдруг она есть, да еще и подробная - вы счастливчик и сюда заглянули скорее из любопытства. Если вам сказали что ее нет, не отступайте так сразу, может оказаться что таки есть, допустим, статистика сайта, но про это или не подумали, или решили что она не годится, или прошлая версия приложения, или был проект близкой тематики, но не взлетел. Любая статистика лучше ее полного отсутствия, даже если это не достоверные данные на конкретное приложение, а срез аудитории в вашей теме. Но рассматривайте эти варианты только как подсказку, а не как готовый список.
+
+**Изучите целевую аудиторию (ЦА)**
+
+Часто этим пунктом пренебрегают. Но он может быть важен. Приложение элитного Барбершопа нацелит вас на новые модели смартфонов, флагманы с большим экраном; в женском салоне предположительно увеличится процент айфонов и уменьшится любовь к формату Plus (модели iOS увеличенного размера с приставками Max, Plus). А если ваша ЦА средний класс в регионах - тут будет большой разброс по производителям/устройствам, заметный процент старых моделей и Android в приоритете.
+
+**Особенности самого приложения тоже могут влиять на выбор**
+
+Пообщайтесь с менеджером или разработчиками (как вариант редкий, но существующий - изучите документацию), чтобы потом не оказалось, что в приложении графическом вы не можете протестировать поведение Pencil 2, потому что купили девайсы только с первым. Или ваше мобильное приложение сильно зависит от железа, а вы этот момент не учли и у всех ваших девайсов схожие характеристики. Узнайте и выпишите отдельно требования. Погуглите могут ли быть нюансы на разных устройствах при использовании «ваших» технологий (NFC, Fingerprint etc.).
+
+**Готовим шаблон**
+
+При наличии своей статистики таблицу можно заполнить сразу в чистовую. Иначе накидать черновик с которым вы потом будете работать, уточняя и редактируя.
+
+* **Производители**. Посмотреть лидирующих (по трафику) вендоров можно на [Statcounter](https://gs.statcounter.com/vendor-market-share/mobile/russian-federation). Определиться с разработкой версии для Huawei без гугл-сервисов;
+* **Соотношение сторон экрана**. При выборе постарайтесь захватить оба значения ближе к краю (из используемых) и среднее;
+* **Размер**. Нужны ли планшеты, а также отдельно варианты для Android и для iOS, т.к. у них немного отличается и подход и обозначение;
+* **Особенности**. На iOS могут быть нюансы работы нативной «Назад» у моделей с монобровью/челкой, хотя физически она и расположена в зоне статус-бара. Любое приложение с ландшафтной ориентацией и полным использованием экрана (например плеер) также желательно посмотреть на моделях с бровью. Если у вас не веб, а приложение, рассчитанное не на премиум-сегмент, да еще и с записью данных на устройство - работа с SD-картой иногда вызывает вопросы, включаем в список.
+
+Источники:
+
+* Выбор мобильных устройств: пошаговая инструкция для начинающих QA. [Часть I](https://habr.com/ru/post/513018/)
+
+Доп. материал:
+
+* Выбор мобильных устройств: пошаговая инструкция для начинающих QA. [Часть II](https://habr.com/ru/post/516160/)
+* [Сервисы статистики для мобильных приложений](https://habr.com/ru/post/457304/)
+* [Облачные платформы для мобильного тестирования](https://habr.com/ru/post/464433/)
+* [Что общего у мобильного QA и осьминога](https://habr.com/ru/company/badoo/blog/317964/)
+* [Тестовая ферма из Android-устройств: как собрать, отладить и не взорвать офис](https://habr.com/ru/company/vk/blog/579210/)
diff --git a/mobilnoe-testirovanie/poslednee-obnovlenie-android-ios-chto-novogo.md b/mobilnoe-testirovanie/poslednee-obnovlenie-android-ios-chto-novogo.md
new file mode 100644
index 0000000..122bcfe
--- /dev/null
+++ b/mobilnoe-testirovanie/poslednee-obnovlenie-android-ios-chto-novogo.md
@@ -0,0 +1,3 @@
+# Последнее обновление Android/iOS, что нового?
+
+Актуализируется перед собеседованием, т.к. написанное здесь будет слишком быстро устаревать.
diff --git a/mobilnoe-testirovanie/simulyatory-i-emulyatory.md b/mobilnoe-testirovanie/simulyatory-i-emulyatory.md
new file mode 100644
index 0000000..f627a28
--- /dev/null
+++ b/mobilnoe-testirovanie/simulyatory-i-emulyatory.md
@@ -0,0 +1,16 @@
+# Симуляторы и эмуляторы
+
+_Эмулятор (emulator): Устройство, компьютерная программа или система, которая принимает те же самые входные данные и выдает те же самые выходные данные, что и данная система. (IEEE 610)_
+
+_Имитатор (simulator): Устройство, компьютерная программа или система, используемая в тестировании, работающая или ведущая себя аналогично заданной при тех же входных данных. (IEEE 610, DO178b)_
+
+**Реальное устройство**: позволяет запускать мобильные приложения и проверять его функциональность. Тестирование реального устройства гарантирует, что ваше приложение будет работать без проблем на клиентских телефонах. Когда устройств становится слишком много, их иногда собирают в так называемые фермы устройств. Реальными устройствами также не обязательно обладать, сейчас широко распространены облачные решения.
+
+**Эмулятор**: пытается дублировать устройство - это полноценная виртуалка (контейнер) со своей сетевой картой и диском, то есть представляет собой полную повторную реализацию конкретного устройства или платформы изолированно внутри нашей хост-системы. Одним из недостатков такого подхода является скорость работы. Примером служит эмулятор в Android Studio, хотя можно найти и неофициальные эмуляторы и образы Android-устройств.
+
+**Симулятор**: пытается дублировать только поведение устройства. Как правило, симулятор - это имитация лишь отдельных свойств, возможностей или функций симулируемой системы, причем не в полном объеме, а только в том, в каком это необходимо в рамках тех задач, которые были поставлены перед симулятором. Вы как будто бы работаете с настоящим устройством, но при этом под капотом оно является лишь ПО-имитацией, не работающей изолированно от нашей системы и использующей общий диск и сеть. Примером служит симулятор в XCode.
+
+Доп. материал:
+
+* [Как тестировать на эмуляторе (android studio)](https://www.youtube.com/watch?v=ic-sniUEYw4)
+* [Как тестировать на симуляторе. Основы тестирования на симуляторе Iphone. Simulator ios xcode](https://www.youtube.com/watch?v=LimscelXdFI)
diff --git a/mobilnoe-testirovanie/testirovanie-dip-linkov-mobile-deep-links.md b/mobilnoe-testirovanie/testirovanie-dip-linkov-mobile-deep-links.md
new file mode 100644
index 0000000..74fff9c
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-dip-linkov-mobile-deep-links.md
@@ -0,0 +1,31 @@
+# Тестирование дип линков (mobile deep links)
+
+Дип линкинг (deep linking) позволяет конечному пользователю с помощью ссылки открыть страницу с нужным контентом внутри мобильного приложения, минуя его домашнюю страницу и минимизируя трату времени на поиск необходимого контента.
+
+В случае, если приложение не установлено на девайсе, отложенный дип линкинг (deferred deep linking) позволяет пользователю открыть нужную страницу внутри мобильного приложения даже после его установки.
+
+Контекстный дип линкинг (contextual deep linking) дает дополнительную возможность сохранения информации (например, о промо кампании) во время всего сценария установки приложения.
+
+**Проблемы, с которыми сталкиваются разработчики и тестировщики**:
+
+* Поддержка различных технологий работы с дип линками и разработка линков, которые будут работать во всех мобильных браузерах;
+* Интеграция с соц.сетями и мессенджерами;
+* Встроенные браузеры (in-app browsers);
+* Отслеживание атрибуции (attribution);
+* Предотвращение мошенничества;
+* Некоторые end-to-end сценарии очень тяжело (или невозможно) автоматизировать;
+* Постоянная поддержка.
+
+**Полезные инструменты**
+
+* [UA Switcher плагин](https://chrome.google.com/webstore/detail/user-agent-switcher/lkmofgnohbedopheiphabfhfjgkhfcgf), который позволяет просматривать веб-страницы, используя user agent мобильных браузеров. Также можно импортировать свои кастомные конфигурации.
+* Сайты, позволяющие сгенерировать webhook ссылки: [раз](http://webhook.site) и [два](http://hookbin.com). Большинство провайдеров дип линков позволяют отслеживать ивенты “на лету”, достаточно лишь вставить полученную ссылку в панель управления провайдера.
+* [Сайт](https://halgatewood.com/deeplink/) для проверки, откроет ли дип линк ваше приложение.
+* [App Search Validation Tool](https://search.developer.apple.com/appsearch-validation-tool) от Apple. Можно протестировать правильность конфигурации Universal Links.
+* [Deep Link Tester](https://github.com/andmar1x/deep-link-tester) для Android, который можно собрать своими руками. Также можно скачать готовые аналоги с Google Play.
+* Подписка на обновления сторонних приложений. Мы используем [AppShopper](http://appshopper.com), этот сервис присылает письма на почту каждый раз, когда интересующее нас приложение обновилось в App Store. Это очень удобно - сразу видно, какие мессенджеры следует протестировать в первую очередь.
+* Электронные таблицы и таблицы решений (decision tables) для поддержания структуры основных сценариев.
+
+Источники:
+
+* [Разработка и тестирование мобильных дип линков (mobile deep links)](https://software-testing.ru/library/testing/mobile-testing/2837-mobile-deep-links)
diff --git a/mobilnoe-testirovanie/testirovanie-pokupok-v-android-prilozheniyakh.md b/mobilnoe-testirovanie/testirovanie-pokupok-v-android-prilozheniyakh.md
new file mode 100644
index 0000000..6edc13d
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-pokupok-v-android-prilozheniyakh.md
@@ -0,0 +1,166 @@
+# Тестирование покупок в Android-приложениях
+
+С помощью набора API-интерфейсов разработчики могут предлагать два типа продуктов:
+
+* Управляемые продукты в приложении (Managed in-app products): Как следует из названия, этими продуктами управляет разработчик, и они делятся на расходуемые и нерасходуемые (consumable and non-consumable). Расходуемый продукт обычно носит временный характер, и после его использования его можно снова купить, в то время как нерасходуемый продукт - это одноразовое преимущество, которое пользователь будет продолжать получать в вашем приложении$
+* Подписки (Subscriptions): Эти продукты имеют срок действия (дни, месяцы, недели, годы) и автоматически продлеваются в конце каждого платежного цикла. Если подписка не продлевается, продукт перестает быть активным для пользователя.
+
+Официальная документация очень полезна, когда дело доходит до первых шагов по добавлению встроенных продуктов в ваше приложение. В частности, тренинг «[Продажа продуктов в приложениях](https://developer.android.com/training/in-app-billing/index.html)» хорошо структурирован и проведет вас через каждый необходимый шаг:
+
+* Добавление библиотеки Play Billing в приложение (также ознакомьтесь с [этой статьей](https://medium.com/exploring-android/exploring-the-play-billing-library-for-android-55321f282929) Джо Берча);
+* Настройка продуктов в консоли Google Play;
+* Тестирование встроенных продуктов в вашем приложении.
+
+Согласно документации по тестированию, у нас есть два способа тестирования покупок:
+
+* Статические ответы от Google Play: Используя ограниченный набор ID продуктов, вы можете запускать статические ответы из Google Play, чтобы проверить, правильно ли ваше приложение обрабатывает все возможные состояния. Вы должны использовать это при интеграции Play Billing Library в наше приложение или для инструментального тестирования;
+* Тестовые покупки: Аккаунт Google, внесенный в белый список как license-test в Play Console, сможет совершать покупки без фактической оплаты. Вы можете использовать это, когда приложение отправляется в QA или для общего тестирования.
+
+Используя так называемую In-app Billing Sandbox, мы можем разрешить доступ к тестовым покупкам. Это самое близкое к реальным покупкам, за несколькими заметными исключениями:
+
+* С вас не взимается никакая сумма за продукт, который вы покупаете;
+* Если вы покупаете подписку, расчетный период повторяется ежедневно, независимо от продолжительности, настроенной в Play Console;
+* У вас есть ручное управление откликом для каждой покупки.
+
+Последний пункт особенно интересен, потому что у нас есть два способа настройки поведения тестовой покупки.
+
+Первый метод позволяет точно контролировать поведение лицензирования для всех тестировщиков: например, оставив RESPOND\_NORMALLY, мы получим поведение, похожее на реальное. Второй метод, с другой стороны, позволяет грубо контролировать реакцию поддельной кредитной карты: вы можете решить, будет ли карта всегда одобрять покупку или всегда отклонять ее. Интуитивно понятно, что этот второй метод может быть настроен каждым тестировщиком.
+
+
+
+
+
+Чтобы получить право на пробную покупку, необходимо пройти несколько шагов:
+
+* Ваш APK должен быть загружен в Play Console (черновики больше не поддерживаются);
+* Добавьте license testers в Play Console;
+* Пригласите тестировщиков присоединиться к группе альфа-/бета-тестирования (если есть);
+* Подождите 15 минут, затем начните тестирование.
+
+Звучит достаточно просто, верно? Документация также очень обнадеживает: “Легко настроить пробные покупки”.
+
+Тестирование, согласно реальной жизни. Вы неукоснительно следите за документацией, ждете 15 минут (на всякий случай 30), запускаете тестирование и… возникает ошибка. Что теперь? Оказывается, документация довольно оптимистично объясняет необходимые шаги для тестирования встроенных покупок. Согласно [этому ответу StackOverflow](https://stackoverflow.com/questions/13117081/the-item-you-requested-is-not-available-for-purchase/35132936#35132936), который, в свою очередь, представляет собой набор различных проб и ошибок других пользователей, а также мой личный опыт, на самом деле существует более 10 условий, которые вам необходимо выполнить или учесть, прежде чем вы сможете правильно использовать тестовые продукты:
+
+* Ваше приложение опубликовано (то есть не находится в черновике);
+* APK должен быть опубликован (рабочий, альфа- или бета-каналы);
+* APK, который вы загрузили, соответствует тому, который вы тестируете, когда речь идет о коде версии, имени версии и подписи хранилища ключей (этот пункт, по моему опыту, не нужен);
+* При тестировании на устройстве вы используете учетную запись, отличную от той, которая привязана к Play Console (т. е. не учетную запись разработчика);
+* Инструкции ждать 15 минут слишком оптимистичны, так как распространение изменений из Play Console может занять до 2 часов;
+* Дважды проверьте, соответствует ли артикул, который вы используете в приложении, артикулу продукта, который был настроен в Play Console;
+* Дважды проверьте, не пытаетесь ли вы приобрести уже имеющийся продукт или уже активную подписку;
+* Дважды проверьте, активировали ли вы свои продукты в Play Console: по умолчанию продукты в консоли деактивированы, и вам нужно активировать их вручную;
+* Если вы используете альфа-/бета-каналы, убедитесь, что учетная запись, которую вы тестируете, входит в группу тестирования (т. е. нажала «Стать тестировщиком» после перехода по URL-адресу подписки);
+* Если вы используете разновидности ABI, такие как arm-v7, arm-v8 и т. д., убедитесь, что APK, который вы используете для тестирования, содержит все библиотеки ABI;
+* Убедитесь, что при получении Intent с помощью getBuyIntent вы передаете правильный тип продукта, т. е. inapp, если вы покупаете управляемые продукты в приложении, или подписки, если вы покупаете подписки;
+* Если вы используете открытый ключ для повышения безопасности, убедитесь, что он совпадает с ключом в Play Console, поскольку со временем он может меняться (см. [здесь](https://stackoverflow.com/questions/14600664/android-in-app-purchase-signature-verification-failed/14647065#14647065));
+* Убедитесь, что сервисы Google Play обновлены на тестовом устройстве, перейдя на страницу [сервисов Google Play](https://play.google.com/store/apps/details?id=com.google.android.gms\&hl=en) в Play Store.
+
+Как видите, песочница далеко не проста, когда дело доходит до реального использования, но, по крайней мере, теперь у нас есть несколько дополнительных подсказок, чтобы начать поиск решения!
+
+Итак, вы должны тестировать свою интеграцию Google Play Billing Library на протяжении всей разработки. Для тестирования на этапе разработки мы рекомендуем использовать тестировщиков лицензий (license testers) для выполнения сценариев, описанных в этом разделе. Сведения о настройке license testers см. в разделе [Проверка выставления счетов в приложении с помощью лицензирования приложений](https://support.google.com/googleplay/android-developer/answer/6062777).
+
+Использование license testers дает следующие преимущества:
+
+* Обычно Платежная библиотека Google Play блокируется для приложений, которые не подписаны (signed) и не загружены в Google Play. Тестеры лицензий могут обойти эту проверку, что означает, что вы можете загружать приложения для тестирования, даже для приложений, использующих отладочные сборки с отладочными подписями, без необходимости загрузки в новую версию вашего приложения. Обратите внимание, что имя пакета должно совпадать с именем приложения, настроенного для Google Play, а учетная запись Google должна быть тестером лицензии для учетной записи Google Play Console;
+* Тестировщики лицензий имеют доступ к тестовым методам оплаты, которые позволяют избежать взимания с тестировщиков реальных денег за покупки. Вы также можете использовать тестовые способы оплаты для имитации определенных ситуаций, например отклонения платежа;
+* Тестировщики лицензий могут быстро протестировать функции подписки.
+
+Вот некоторые дополнительные сведения о процессе тестовой покупки:
+
+* Для тестовых покупок используется тот же процесс покупки приложений, что и для реальных покупок;
+* Налоги не рассчитываются для пробных покупок;
+* Google Play указывает на пробную покупку, отображая уведомление в центре диалогового окна покупки.
+
+Вы можете подтвердить учетную запись, которая совершает покупку, развернув диалоговое окно покупки. Обратите внимание на следующее:
+
+* Тестовые учетные записи должны быть на Android-устройстве тестировщика;
+* Если на устройстве имеется более одной учетной записи, покупка осуществляется с использованием учетной записи, с которой было загружено приложение;
+* Если ни одна из учетных записей не загрузила приложение, покупка осуществляется с помощью первой учетной записи.
+
+Прежде чем распространять свое приложение, вы можете использовать [тестовые версии](https://support.google.com/googleplay/android-developer/answer/9845334?visit\_id=637775040806604937-1685107894\&rd=1) (test track) Google Play для дополнительной проверки. Например, вы можете использовать тестовые версии, чтобы ваша группа контроля качества проверяла новый выпуск. С помощью тестовых версий пользователи могут установить ваше приложение из Google Play и протестировать версию вашего приложения, которая еще не является общедоступной. Пользователи могут совершать реальные покупки, используя любой из своих способов оплаты в Google Play.
+
+_Примечание. Покупки пользователей в тестовых версиях приводят к фактическому списанию средств с учетных записей пользователей, если только пользователь не является license tester._
+
+Чтобы протестировать интеграцию с биллинговой библиотекой Google Play с помощью тестовых версий, выполните следующие действия:
+
+* Опубликуйте свое приложение в test track. Обратите внимание, что после публикации приложения в версии для тестирования может пройти несколько часов, прежде чем оно станет доступным для тестировщиков.
+* Убедитесь, что каждый тестировщик подписался на тест вашего приложения. На URL-адресе вашего теста ваши тестировщики увидят объяснение того, что значит быть тестировщиком, а также ссылку для регистрации.
+
+Вы можете протестировать интеграцию на любом аппаратном устройстве с Android 1.6 или более поздней версии. На устройстве должна быть установлена самая актуальная версия приложения Google Play. Общие сведения о том, как настроить устройство для использования в разработке приложений для Android, см. в разделе [Использование аппаратных устройств](https://developer.android.com/studio/run/device).
+
+_Примечание. Несмотря на то, что тестеры лицензий рекомендуются для разработки и тестирования, убедитесь, что вы также тестируете свое приложение, используя учетные записи, не являющиеся тестировщиками лицензий, время от времени или при внесении крупных изменений. Нелицензионное тестирование помогает гарантировать, что ваше приложение не полагается на тестирование конкретной логики, такой как продолжительность продления (renewal durations)._
+
+_Примечание. Пользователи в testing tracks также могут быть license testers для вашего приложения._
+
+**Тестирование одноразовых продуктов**
+
+Тестирование расходных материалов (**consumable products**):
+
+* Успешная покупка, когда пользователь получает товар. С помощью license tester Test instrument вы можете настроить оплату как всегда успешную;
+* Покупка, при которой оплата не была списана, и пользователь не должен получить товар. С помощью license tester вы можете использовать Test instrument, всегда отклоняющий оплату;
+* Убедитесь, что товары можно покупать несколько раз.
+
+Вы также должны убедиться, что покупки подтверждены должным образом, как описано в разделе «[Обработка покупок](https://developer.android.com/google/play/billing/integrate#process)». Для покупок у license tester покупка будет возвращена через 3 минуты, если ваше приложение не подтвердит покупку, и вы получите электронное письмо об отмене. Вы также можете проверить вкладку «Заказы» в консоли Google Play, чтобы узнать, был ли возмещен заказ через 3 минуты.
+
+Тестирование **non-consumable products**: следует тестировать так же, как и consumable products, но вы должны убедиться, что элемент нельзя купить снова в вашем приложении. Обязательно проверьте подтверждение покупки как для consumable products, так и для non-consumable products (если применимо), поскольку логика обработки каждого из двух типов покупок различается.
+
+_Примечание. Чтобы совершить несколько тестовых покупок одного и того же non-consumable product, вы можете вернуть средства и отозвать покупки с помощью Google Play Console._
+
+**Тестирование функций подписки**
+
+Флоу покупки одноразовых продуктов и подписок аналогичны, но у подписок есть дополнительные сценарии, такие как успешное или отклоненное продление подписки. Чтобы протестировать продление, вы можете использовать Test instrument, always approves and Test instrument, always declines payment methods, доступные для license testers. Используйте эти инструменты оплаты для тестирования сценариев, выходящих за рамки успешного сценария подписки.
+
+Как и в случае с одноразовыми продуктами, вы также должны убедиться, что покупки подтверждены должным образом, как описано в разделе «Обработка покупок». Для покупок у тестировщиков лицензий покупка будет возвращена через 3 минуты, если ваше приложение не подтвердит покупку, и вы получите электронное письмо об отмене. Вы также можете проверить вкладку «Заказы» в Google Play Console, чтобы узнать, был ли возвращен заказ через 3 минуты.
+
+Периоды продления: Тестовые подписки продлеваются быстрее, чем фактические подписки, а тестовые подписки можно продлевать не более шести раз. В следующей таблице указано время продления тестирования для подписок различной продолжительности. Эти времена являются приблизительными. Вы можете увидеть небольшие отклонения в точном времени события. Чтобы компенсировать вариацию, вызывайте API для просмотра текущего состояния после каждой даты истечения срока действия подписки.
+
+| Срок реальной подписки (**Production subscription period**) | Продление тестовой подписки (**Test subscription renewal**) |
+| ----------------------------------------------------------- | ----------------------------------------------------------- |
+| 1 неделя | 5 минут |
+| 1 месяц | 5 минут |
+| 3 месяца | 10 минут |
+| 6 месяцев | 15 минут |
+| 1 год | 30 минут |
+
+Функции подписки на основе времени, такие как бесплатные пробные версии, также сокращены для тестирования. В следующей таблице указаны периоды тестирования, связанные с функциями подписки на основе времени:
+
+| **Feature** | **Test period** |
+| ---------------------------------------------------- | ------------------------------------- |
+| Подтверждение покупки | 5 минут |
+| Бесплатная пробная версия | 3 минуты |
+| Начальный ценовой период (Introductory price period) | То же, что и subscription test period |
+| Льготный (Grace) период (3- и 7-дневный) | 5 минут |
+| Account hold | 10 минут |
+| Пауза (1 месяц) | 5 минут |
+| Пауза (2 месяц) | 10 минут |
+| Пауза (3 месяц) | 15 минут |
+
+Разверните [следующий раздел](https://developer.android.com/google/play/billing/test#test\_cases), щелкнув Показать/Скрыть, чтобы отобразить сценарии тестирования, которые следует использовать для проверки интеграции подписки.
+
+**Тестирование промокодов (промоакций)**
+
+Вы можете использовать Google Play Console для [создания кодов для собственного тестирования](https://support.google.com/googleplay/android-developer/answer/6321495). Имейте в виду, что вы можете создавать только 500 промокодов в квартал для всех управляемых продуктов в приложении.
+
+Вам следует протестировать следующие сценарии погашения (Redemption) промокода:
+
+* При вводе промокода в диалоговом окне покупки, запущенном в вашем приложении;
+* При активации промокода в приложении Google Play Store;
+* При активации промокода на странице https://play.google.com/store с помощью кнопки «Активировать» на панели навигации слева.
+
+В этих сценариях вы должны тестировать коды всеми возможными способами. Мы рекомендуем выполнить как минимум следующие тесты:
+
+* Выкуп до установки приложения;
+* Выкуп, пока приложение работает на переднем плане. Обратите внимание, что для этого теста вам понадобится другое устройство для тестирования с помощью приложения Google Play Store. Обязательно протестируйте погашения с разных экранов в своем приложении;
+* Погашение с многооконным режимом, в котором ваше приложение и приложение Google Play Store отображаются одновременно.
+
+Для каждого теста убедитесь, что элемент правильно обнаружен и что пользователь уведомлен.
+
+Источники:
+
+* [Testing in-app purchases on Android](https://medium.com/bleeding-edge/testing-in-app-purchases-on-android-a6de74f78878)
+* [Test your Google Play Billing Library integration](https://developer.android.com/google/play/billing/test)
+
+Доп. материал:
+
+* [Более подробно о подписках](https://developer.android.com/google/play/billing/subscriptions)
+* [Дмитрий Макаренко - Тестирование платежей в Android-приложении](https://www.youtube.com/watch?v=U9r-uOI7g3Q\&ab\_channel=Heisenbug)
diff --git a/mobilnoe-testirovanie/testirovanie-pokupok-v-ios-prilozheniyakh.md b/mobilnoe-testirovanie/testirovanie-pokupok-v-ios-prilozheniyakh.md
new file mode 100644
index 0000000..5c14c31
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-pokupok-v-ios-prilozheniyakh.md
@@ -0,0 +1,20 @@
+# Тестирование покупок в iOS-приложениях
+
+На iOS есть два варианта тестирования: классический, посредством Sandbox покупок, и новый способ локального тестирования покупок через Xcode (StoreKit local testing).
+
+* [Sandbox тестирование](https://developer.apple.com/apple-pay/sandbox-testing/) - процесс несколько муторный и работает только на реальном девайсе. Чтобы тестировать в Sandbox, в самом начале надо завести аккаунт тестировщика на портале, связать его со своим устройством и после этого этого проверить все сценарии. Некоторые сценарии которых требуют очень большого количества манипуляций (refund, ask to buy, lifetime non-consumable покупки);
+* [Тестирование в Xсode](https://developer.apple.com/documentation/xcode/testing-your-apps-in-xcode) стало доступным, начиная с Xcode 12 (iOS 14), и значительно упростило процесс тестирования. Во-первых, тестировать покупки в Xcode можно на раннем этапе, когда приложение не подключено к AppStore Connect. Во-вторых, для Xcode не нужно заводить дополнительных аккаунтов в AppStore, что сильно ускоряет процесс конфигурации тестов, особенно для lifetime non-consumable. В-третьих, локальное тестирование можно автоматизировать, что потенциально снижает шанс появления ошибок в коде. Более того, можно даже писать UI-тесты на пейволы и другие интерфейсы, где фигурируют покупки.
+
+Однако некоторые вещи доступны только в Sandbox. Например, использовать таблицу цен с автоматической конвертацией на разные валюты можно только в AppStore. Также валидация покупок (receipt validation) в обычном виде уже не работает - локальные покупки валидируются через Xcode, и этот механизм ложится на плечи разработчика. В остальном Xcode покрывает большинство сценариев и задач тестирования.
+
+Источники:
+
+* [iOS in-app purchases, часть 4: локальное тестирование покупок в XCode](https://habr.com/ru/company/adapty/blog/571960/)
+
+Доп. материал:
+
+* [Testing In-App Purchases in Xcode](https://developer.apple.com/documentation/storekit/original\_api\_for\_in-app\_purchase/testing\_in-app\_purchases\_in\_xcode)
+* [Test in-app purchases in Sandbox](https://help.apple.com/app-store-connect/#/dev7e89e149d)
+* [In-app purchase types](https://help.apple.com/app-store-connect/#/dev3cd978dbd)
+* [In-app purchase statuses](https://help.apple.com/app-store-connect/#/dev840c56fb6)
+* [Auto-renewable subscription information](https://help.apple.com/app-store-connect/#/dev7f2d6b652)
diff --git a/mobilnoe-testirovanie/testirovanie-prosmotrennykh-tovarov.md b/mobilnoe-testirovanie/testirovanie-prosmotrennykh-tovarov.md
new file mode 100644
index 0000000..8111a1f
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-prosmotrennykh-tovarov.md
@@ -0,0 +1,20 @@
+# Тестирование просмотренных товаров
+
+Весьма популярная фича во многих маркетплейсах, которая выделяет просмотренные товары от непросмотренных в какой-либо ленте, чтобы пользователю было проще ориентироваться.
+
+**Немного ТЗ**
+
+* Карточка товара будет считаться просмотренной, если она была открыта и в ней хоть что-то показали пользователю без ошибок. Срок хранения «просмотренности» на клиенте составляет неделю. Затем товар помечается непросмотренным;
+* Для авторизованных пользователей: если пользователь разлогинивается, то все статусы «просмотрено» сбрасываются;
+* Для неавторизованных пользователей: если пользователь авторизуется, то все статусы «просмотрено» сохраняются;
+* Также имеются и другие товары с различными статусами, которым отдаются приоритеты.
+
+**Как тестировать и на что обращать внимание**
+
+* **Логика**: с одной стороны, логика довольно простая, необходимо просмотреть товар, вернуться в ленту и проверить, появился ли статус «просмотрено». Не совсем так. Обращаем внимание на условие того, а при каком условии именно проставляется статус. Верно! Необходимо, чтобы не просто товар отобразился, проверить, отобразились ли данные по товару. Например, если вернуться «назад» когда товар не отобразился, то товар не будет засчитан как «просмотренный». А если пользователь не авторизован? Необходимо проверить кейсы, связанные с авторизацией и разлогином. Просмотренный товар неавторизованным пользователем должен либо помечаться просмотренным после авторизации, либо возвращаться в «непросмотренные» при разлогине. Проверяем срок хранения статуса «просмотрено» в течение N времени. А если товар неделю статус хранится на клиенте - в таком случае ждать столь продолжительное время не стоит, можно изменить в коде переменную, отвечающую за срок хранения статуса.
+* **Верстка**: при добавлении различных новых бейджей стоит отдельное внимание уделять верстке карточек на разных устройствах с разным разрешением экрана и альбомной ориентации.
+* **Дополнительные проверки**: в зависимости от реализации могут быть добавлены тултипы, попапы, тоасты - все это, разумеется, требует дополнительных проверок. Также не стоит забывать и про базовые кейсы при тестировании.
+
+Источники:
+
+* [Просмотренные товары](https://telegra.ph/Prosmotrennye-tovary-10-17)
diff --git a/mobilnoe-testirovanie/testirovanie-push-uvedomlenii.md b/mobilnoe-testirovanie/testirovanie-push-uvedomlenii.md
new file mode 100644
index 0000000..12ff873
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-push-uvedomlenii.md
@@ -0,0 +1,65 @@
+# Тестирование push-уведомлений
+
+**Push-уведомления** - это сообщения, отправляемые приложением на мобильное устройство клиента. Они обычно используются для доставки обновлений продуктов, напоминаний, персонализированных предложений, последних новостей и любой информации, которая является неотъемлемой частью функциональности приложения и требует особого внимания или быстрых действий.
+
+**Принцип работы push-уведомлений**
+
+* пользователь устанавливает приложение на устройство;
+* выдается запрос прав на отправку уведомлений, и в случае успеха - ОС получает токен (идентификатор устройства) у службы push-уведомлений;
+* ОС передает токен на сервер для подключения к уведомлениям;
+* сервер шлет уведомления при наступлении определенного события.
+
+В случае iOS уведомления работают через облачную платформу APNS (Apple Push Notification Service).
+
+Если говорить о решении пуш-уведомлений от Android, то есть несколько вариантов. Самый простой способ действовать - использовать Firebase Cloud Messaging (для устройств Android с Google Apps). Если у ваших пользователей есть устройства Huawei (а именно, без Google Apps), вам следует прибегнуть к Huawei Push Kit.
+
+Конечно, вы также можете создать собственного провайдера push-уведомлений или использовать готовые проекты, поскольку платформа имеет открытый исходный код.
+
+**Разница между push-уведомлениями в iOS и Android**
+
+Функции push-уведомлений в iOS и Android довольно сильно различаются.
+
+iOS основана на модели push Opt-In, которая не позволяет брендам отправлять мобильные push-уведомления пользователям своих приложений до тех пор, пока эти пользователи не согласятся их получать. Android, с другой стороны, автоматически разрешает пользователям получать push-уведомления с возможностью отказаться от них вручную.
+
+Подход Android по сравнению с iOS по умолчанию дает более широкую аудиторию пользователей с поддержкой push. Однако, когда у пользователей нет возможности легко отказаться от их получения, нерелевантные или слишком частые уведомления могут подтолкнуть клиентов отключить сообщения или удалить приложение.
+
+**Тестирование push-уведомлений**
+
+**Не приходят push-уведомления**: Чтобы разобраться в причине, для начала проверьте, чтобы в меню устройства была активирована соответствующая функция (разрешены уведомления для конкретного приложения). Затем убедитесь, что не включен режим «Не беспокоить». Если всё настроено правильно, но уведомления не приходят, попробуйте перезагрузить устройство и заново авторизоваться в приложении. Бывает так, что необходимо заново отправить push-токен на серверную часть сервиса. Проверьте также, какой стиль уведомления используется (необходим «Баннер» либо «Предупреждение»). Если не помогло всё перечисленное, попробуйте перезайти в свою учетную запись магазина приложений, либо откройте саму программу, в том случае, если на другие приложения тоже не приходят push-уведомления (стоит также проверить наличие интернета на устройстве).
+
+**Переходы по push-уведомлению**: При тестировании необходимо проверить такие сценарии (с учётом того, что пользователь может быть авторизован или неавторизован):
+
+* переход по push-уведомлению с заблокированного экрана;
+* переход по push-уведомлению из «шторки»;
+* пользователь находится в приложении;
+* переход по push-уведомлению при свёрнутом приложении;
+* пользователь разлогинился после получения push;
+* переход по push-уведомлению с включенным «Don't keep Activities» (характерно для Android-приложений).
+
+Существуют push-уведомления, которые ведут на определенный экран с выбором определенных фильтров. В таком случае необходимо проверить, что переход осуществляется на правильный экран. Если это был поисковой запрос, то проверьте, что текст поискового запроса отображается в строке поиска и выдача товаров соответствует поиску. Также могут передаваться определенные фильтры, в таком случае необходимо проверить, что выбраны все «зашитые» фильтры.
+
+Если push-уведомление ведет на WebView, то проверьте, что WebView открывается корректно на обеих платформах. И что в push зашит корректный URL.
+
+**Устаревший push-токен**: У устройства изменился push-токен, когда восстановили приложение из резервной копии системы и не передался новый push-токен.
+
+**Очередь со стороны Apple**: В Apple большая очередь на отправку push-уведомлений, они приходят с задержкой (Apple не гарантирует доставку push).
+
+**Проверка максимального и минимального количества отображаемых символов**: В iOS и Android имеется лимит отображаемых символов. Он разный. Максимальное значение количества символов для платформы iOS - ограничение в 4 строки (178 символов), а для Android - не более 13 строк (663 символа). Не забудьте также проверить push-уведомление, содержащее минимальное количество символов, для обоих платформ можно задать 1 символ.
+
+**Кастомный звук для push-уведомления**: При тестировании push-уведомлений важно учитывать тот факт, что звук push-уведомления может быть задан кастомный. В таком случае необходимо проверять и звуковое сопровождение нотификации.
+
+**Изображения в push-уведомлениях**: Push-уведомление может содержать изображение, при отправке пуша - клиент получает ссылку на изображение и перед показом загружает его, далее происходит процесс обогащения пуша картинкой - она устанавливается. Уведомление отображается после загрузки картинки. Если push-уведомление содержит картинку, необходимо проверить, что она отображается.
+
+**Локальные push-уведомления**: Локальные уведомления планируются самим приложением и служат для своевременного и актуального информирования пользователей, пока приложение не работает на переднем плане. Чтобы уведомление отобразилось, его необходимо запланировать самому пользователю. В таких случаях проверяем кейсы, связанные с таймингом отправки сообщения.
+
+**Проблемы на серверной стороне**: В другие приложения приходят push-уведомления, но не приходит на наше, хотя push-токен отправлен на сервер. Стоит проверить корректность отправки push на другие аккаунты сервиса и другие устройства. При отсутствии push-уведомлений сообщите команде серверной разработки.
+
+Источники:
+
+* [Тестирование push-уведомлений в мобильных приложениях](https://habr.com/ru/company/youla/blog/553762/)
+* [Механизм пуш-уведомлений для iOS и Android](https://macdays.ru/soft/mehanizm-push-uvedomlenij-dlya-ios-i-android/)
+
+Доп. материал:
+
+* [Отправка push-уведомлений с помощью Firebase Cloud Messaging](https://medium.com/nuances-of-programming/%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%B0-push-%D1%83%D0%B2%D0%B5%D0%B4%D0%BE%D0%BC%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-firebase-cloud-messaging-66e329fdfdc2)
+* [Отправка push-уведомлений в приложение для iOS с помощью облачных сообщений Firebase](https://code.tutsplus.com/ru/tutorials/get-started-with-firebase-messaging-for-ios--cms-32126)
diff --git a/mobilnoe-testirovanie/testirovanie-reklamy.md b/mobilnoe-testirovanie/testirovanie-reklamy.md
new file mode 100644
index 0000000..ae2bba5
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-reklamy.md
@@ -0,0 +1,103 @@
+# Тестирование рекламы
+
+Для тестирования в основном используется тестовая реклама, которую партнёры готовят заранее. Это делается, потому что разные характеристики рекламы на продакшене не позволяют быть уверенным, что новый функционал или фикс бага не задели основные параметры и работу рекламного креатива.
+
+Но получение тестовой рекламы требует изменения определённых параметров в наших экспериментах, обращения к тестовой админке медиатора, добавления тест-мода (специальные параметры, чтобы партнер понимал, что запрашивается именно тестовый креатив), использования своей дебаг-панели, а также VPN по странам, а в отдельных кейсах - по городам. И тут нам понадобятся некоторые инструменты.
+
+**Инструменты**
+
+* Сниффер для анализа трафика;
+* Админка у медиатора, где можно настроить получение рекламы от конкретного партнера на свой тестовый юнит (специальный id, используя который, паблишер запрашивает рекламу у медиатора);
+* Своя админка с фича-тогглами, где можно включить/отключить, или изменить наши эксперименты;
+* Наша дебаг-панель;
+* VPN;
+* Внешние гайдлайны;
+* Внутренняя база знаний и Confluence для её хранения;
+* Чек-листы;
+* TMS.
+
+**Инструмент №1. Charles**. Активно используется не только тестировщиками, но и разработчиками. Практически все задачи требуют замены продакшн параметров на тестовые. Например, часто возникает необходимость добавить в конфиг эксперимент или обращаться к тестовым юнитам медиатора. К тому же для тестирования при запросе рекламы необходимо добавлять дополнительные параметры тест-мода. Также довольно часто требуется имитировать проблемы с загрузкой креативов и проверять их с нужными параметрами, например, во время регрессионного тестирования.
+
+**Инструмент №2. Тестовая админка медиатора**. Медиатор - это специальная платформа, которая позволяет подключать приложение сразу к нескольким рекламным сетям, а также управлять показом рекламы (например, Google AdMob, Fyber и другие). Ещё во время онбординга мы проводим обучающие курсы по рекламе, где сотрудники в тестовой админке медиатора создают свой тестовый юнит для настройки параметров рекламы под себя.
+
+**Инструмент №3. Админка с фича-тогглами**. Практически все рекламные (и не только) механики в приложении iFunny закрыты под фича-тогглы (механизм реализации, при котором часть кода прячется за флаг, контролирующий его включение или выключение). Это нужно, чтобы сделать более надёжным и безопасным выпуск той или иной функциональности. Чтобы получить нужный для тестирования конфиг, мы используем нашу админку с фича-тогглами или подменяем параметры, используя Charles. А эксперименты помогают понять, какая из запущенных гипотез является наиболее оптимальной. Всё это есть в нашей админке, которая хранит данные и управляет ими по всем фичам и экспериментам. Документацию обновляем и дополняем по мере необходимости: если после обновления SDK изменилась описанная логика работы, или если вышли нормативы/регламенты, требующие внесения обязательных правок.
+
+**Инструмент №4. Дебаг-панель**. Для удобства разработали свою рекламную дебаг-панель, которая представляет собой отдельный интерфейс и в большинстве случаев позволяет локально на клиенте настроить необходимые параметры, заменяя собой практически все инструменты, описанные выше.
+
+
+
+**Инструмент №5. VPN**. В основном используется для проверки задач, связанных с GDPR и CCPA. Для тестирования GDPR подходит VPN с возможностью получения IP европейской страны. Для тестирования CCPA необходим VPN с возможностью получения калифорнийского IP.
+
+**Инструмент №6**. Внешние гайдлайны. В работе с рекламными SDK часто используем их официальную документацию, где можно получить:
+
+* рекламные креативы и их идентификаторы, которые используются для настройки и получения тестовой рекламы;
+* форматы запросов и ответов рекламной SDK, а также параметры, из описания которых понимаем, за что они отвечают, и какие возможные значения для них допустимы;
+* changelog изменений рекламных SDK - чтобы понять, на какие изменения при обновлении SDK нужно обратить внимание во время тестирования.
+
+**Инструмент №7**. Внутренняя документация. Внешние гайды не всегда являются достаточно подробными. Кроме того, проверка одной и той же функциональности от разных SDK требует переключения между разными источниками для поиска необходимой информации. Поэтому оказалось удобным агрегировать информацию из разных гайдлайнов SDK и делать сборную внутреннюю документацию в нашем Confluence, дополняя ее своими комментариями.
+
+**Инструмент №8. Чек-листы**. Наравне с внешней и внутренней документацией для проверок различных задач используем чек-листы (пример можно посмотреть ниже в разделе про обновление SDK). Для такого типа задач, как проверка обновлений SDK, обновлений медиатора или адаптеров, мы используем уже составленный чек-лист, который изменяется по мере необходимости. Для остальных задач составляем чек-листы либо в процессе разработки задачи, либо непосредственно перед тестированием, в зависимости от сложности задач.
+
+**Инструмент №9. Тест-кейсы**. Тест-кейсы - неотъемлемая часть тестирования любого проекта/функциональности, в том числе рекламы. Тест-кейсы разделены по приоритетам, что позволяет использовать risk-based testing, о котором будет рассказано подробнее ниже. В тест-кейсах фигурируют такие проверки, как загрузка и показ рекламы, запросы на рекламу, работа разных механик (например: водопад, аукцион), а также запрос и отображение рекламы от партнерских рекламных сетей. Данные проверки в полной мере позволяют убедиться, что рекламный функционал работает без сбоев/корректно.
+
+**Задачи**
+
+Тестирование рекламных интеграций, чтобы все механики работали как часы - довольно трудоемкий процесс. Среди всех задач есть много рутинных, но они компенсируются интересными и технически сложными исследованиями по ходу проработки других задач.
+
+Разберем, с чем приходится сталкиваться на постоянной основе:
+
+* Обновление SDK;
+* Тестирование форматов;
+* Безопасность;
+* Регрессионное тестирование;
+* Смоук тестирование;
+* Другие задачи (юридические вопросы, локализации, эксперименты, аналитика, рефакторинг и так далее).
+
+**Задача №1. Обновление SDK**. Можно сказать, что обновление SDK - наиболее популярная задача в рамках тестирования рекламы. Из-за частого проведения тестирования обновлений SDK (а также медиатора или адаптеров) составили чек-лист проверок:
+
+* Вёрстка. Проверяем всё: центрирование, размер, отображение на устройствах с разными разрешениями экранов.
+* Пользовательские сценарии. Тап по контенту/кнопке и по privacy icon, возврат в приложение, воспроизведение и остановка видеорекламы.
+* Репорт (отправка жалоб, связанных с рекламой). Пользователь может пожаловаться на рекламный контент или сообщить о технических проблемах.
+* Соответствие стандартам [GDPR](https://habr.com/ru/company/digitalrightscenter/blog/344064/) и CCPA.
+* Отправка аналитики. Внутренняя и внешняя (партнёру и медиатору).
+* Технические проверки. Например, уход в фон во время загрузки рекламы.
+
+**Задача №2. Тестирование форматов**. Баннерная и нативная рекламы у нас закрепились и работают стабильно, но мы пробуем интегрировать и другие виды, в частности, fullscreen-рекламу. В целом, тестирование Rewarded Video и Interstitial во многом схоже с тестированием других видов: проверяется корректная загрузка и отображение рекламы, а также отправка аналитики.
+
+Ключевым в проверке fullscreen-рекламы является ее отображение на разных по диагонали экранах, например, на смартфоне и планшете. Важно, чтобы появившаяся на экране реклама не перекрывалась другими элементами, и по завершению таймера скрывалась автоматически или тапом по крестику, возвращая пользователя в исходную точку приложения:
+
+Отдельно нужно сказать про механику Rewarded Video - после окончания просмотра рекламы (или просмотра до определенной временной метки) пользователь должен получить вознаграждение. Поэтому очень важно хорошо протестировать этот функционал.
+
+Подробно про разные форматы мобильной рекламы мы уже писали в отдельной [статье](https://habr.com/ru/company/funcorp/blog/549730/).
+
+**Задача №3. Безопасность**. Чтобы следить за качеством трафика, интегрировали в iFunny внешнее антифрод-решение. В него для дополнительной проверки атрибуции показов и кликов на каждое событие генерируется новое. На стороне системы с помощью технологий машинного обучения и большого объема накопленных данных происходит дальнейший анализ. Со своей стороны мы проверяем отправку и разметку событий для разных сетей и разных типов рекламы.
+
+**Задача №4. Регрессионное тестирование**. Раз в две недели iFunny релизится на iOS и Android. Независимо от количества рекламных задач, попавших в релизную ветку, мы проводим регрессионное тестирование рекламного функционала/блока. В регрессионных паках собраны следующего рода проверки:
+
+* Основные проверки, что реклама запрашивается и отображается на нужных экранах приложения;
+* Работа нативной и баннерной рекламы, а также рекламных сетей, с которыми сотрудничаем - по сути, это упрощенный чек-лист, используемый для тестирования SDK (добавления, обновления);
+* Работа разных механик: водопад и биддинг (что это такое, можно ознакомиться [здесь](https://habr.com/ru/company/funcorp/blog/467979/));
+* Проверка на соответствие юридическим нормам;
+* Проверки каких-то наших внутренних разработок (например, эксперименты с дизайном).
+
+Если встречаем проблемы в процессе тестирования (не проходят какие-то кейсы регресса), то чиним в текущей релизной ветке - не катимся с рекламой, которая не работает.
+
+Проведение полного ручного прогона регресса занимает порядка 2-3 дней. Поэтому, чтобы сократить время прохождения регресса, используется практика проведения Risk-based testing (вид тестирования, основанный на вероятности риска). Суть такого тестирования - исключить некоторое количество тест-кейсов из прогона, проведение которых не может выявить потенциальных ошибок на текущем релизном билде. Иными словами, кейс не имеет смысла включать в регрессионное тестирование, если при разработке не был затронут функционал, проверяющийся в кейсе.
+
+**Задача №5. Смоук тестирование**. Перед тем, как выкладывать сборку в сторы, а также при тестировании хотфиксов, мы прогоняем смоук тесты. В рамках смоук тестирования реклама проверяется, но не так детально, как при регрессе. Мы тестируем основные моменты, связанные с рекламой, а именно ее загрузку и отображение.
+
+**Задача №6. Другое**. К тестированию других задач можно отнести:
+
+* юридические задачи, например, связанные с GDPR и CCPA;
+* задачи локализации (для пользователей iFunny из Бразилии);
+* эксперименты, связанные с дизайном рекламы;
+* задачи аналитики;
+* рефакторинг, оптимизации. Например, оцениваем доступный нам для анализа контент на предмет валидности.
+
+Источники:
+
+* [Гайд по тестированию рекламы для мобильных приложений](https://habr.com/ru/company/funcorp/blog/562804/)
+
+Доп. материал:
+
+* [Реклама в мобильных приложениях](https://telegra.ph/Reklama-v-mobilnyh-prilozheniyah-10-24)
diff --git a/mobilnoe-testirovanie/testirovanie-sokhranennykh-poiskov.md b/mobilnoe-testirovanie/testirovanie-sokhranennykh-poiskov.md
new file mode 100644
index 0000000..5d9dcd9
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-sokhranennykh-poiskov.md
@@ -0,0 +1,78 @@
+# Тестирование сохраненных поисков
+
+Сохраненные поиски - удобный инструмент, с помощью которого можно сохранить необходимый запрос и быть в курсе о новых поступлениях. Это удобно так как:
+
+* не нужно каждый раз выставлять параметры и фильтры поиска заново, вы сразу переходите к нужным результатам;
+* вы получаете уведомления о новых объявлениях сразу после их публикации.
+
+**Сохранение поискового запроса неавторизованным и авторизованным пользователями**
+
+Разумеется есть два вида пользователей: авторизованный и неавторизованный. Если мы сохраняем поисковой запрос будучи неавторизованным пользователем, в таком случае проверяем, что выполняется переход на экран авторизации и после авторизации или регистрации пользователя, поисковой запрос добавляется в раздел "избранное". Кейсы, на которые стоит обратить внимание, если пользователь новый, то ему должны отобразиться все необходимые попапы, тултипы, онбординги. Есть большая вероятность, что про них могли забыть.\*\* \*\*При сохранении поискового запроса авторизованным пользователем, все гораздо проще - поиск сохраняется, а сохраненный поиск пользователь может обнаружить на экране с сохраненными поисками (о нем мы поговорим несколько позже).
+
+**Текстовый поиск**
+
+Не всегда пользователь хочет задавать фильтры для поискового запроса, а желает ограничиться например только одним текстовым поиском. При сохранении текстового поиска необходимо проверить, что на бэк с клиента уходит корректный запрос, в котором передается параметр с нашим поисковым запросом. Также стоит учесть кейсы, когда значение параметра, содержащего поисковой запрос, оказалось пустым, а также кейсы, когда в параметре содержится эмодзи.
+
+**Поиск с выбранными фильтрами**
+
+Наиболее распространенный кейс, когда пользователь задает специфичный поисковой запрос и хочет его сохранить. Например пользователь ищет автомобиль со множеством фильтров.
+
+В данном кейсе необходимо проверить сохранение при различных комбинациях фильтров, а также что все фильтры корректно передаются с клиента на бэк. В дальнейшем, разумеется, при открытии сохраненного запроса со множеством комбинаций фильтров, стоит проверить, что все фильтры, пришедшие с бэка, корректно отображаются у пользователя и поисковая выдача соответствует запросу.
+
+**Настройка частоты уведомлений при сохранении**
+
+Пользователь может настроить частоту уведомлений о новых поступлениях. Мы выбираем определенный параметр, который в данном случае передается на бэк. А уже в дальнейшем, в соответствии с заданными параметрами, будет приходить push-уведомление клиенту. Как и в предыдущих кейсах, стоит проверить, что передается корректное значение параметра частоты уведомлений, а также это выбранное значение отображается на клиенте.
+
+**Отображение сохраненного поискового запроса**
+
+Пользователь сохранил поисковой запрос. А теперь рассмотрим кейсы, которые стоит учесть при тестировании экрана, где отображаются все сохраненные поисковые запросы.
+
+**Текстовый поисковой запрос (длинный текст)**
+
+Стоит учесть, что пользователь может сохранить поисковой запрос с абсолютном разным количеством символов, поэтому обращаем внимание на проверки, когда оставшиеся символы должны скрываться под многоточие.
+
+**Сохраненный поиск с выбранными фильтрами**
+
+Как мы уже говорили выше, когда мы ищем тот или иной товар, мы задаем определенные фильтры. Это может быть определенная стоимость, наличие доставки, удаленность от нас, наличие скидки и многое другое. Фильтров может быть много, поэтому не всегда они все могут поместиться в ячейке. В данном случае, фильтры, которые не поместились, должны скрываться также под многоточие.
+
+**Поисковой запрос с emoji**
+
+Пользователь может выразить свои эмоции и добавить в поисковой запрос, например эмодзи. Стоит проверить как корректное сохранение поискового запроса, так и отображение товаров по данному поиску.
+
+**Карусель товаров в сохраненном поиске**
+
+По определенному запросу может быть много товаров. Сгруппированные товары по категории располагаются в карусели. Естественно не все товары будут помещаться, поэтому пользователь должен иметь возможность просмотреть ленту со всеми товарами из карусели. Для начала, стоит проверить отображение разного количества товаров (минимальное и максимальное значение). Следом, стоит проверить скролл товаров в карусели. Также проверяем переходы из карусели на ленту с товарами. Для этого может быть реализована кнопка в конце карусели, например "Посмотреть все объявления", либо активное название карусели, например, при тапе на заголовок "телефоны", у нас откроется лента с товарами, выбранными в соответствии с заданными фильтрами.
+
+**Сохраненный поиск без подходящих товаров**
+
+Предположим, пользователь задал такой поисковой запрос, по которому в выдаче на данный момент нет подходящих товаров? В таком случае он может сохранить такой запрос, а на экране сохраненных поисков уже карусели с товарами не будет. Когда товары, соответствующие запросу появятся на сервисе, то они отобразятся пользователю в карусели товаров.
+
+Необходимо учесть, что может быть как один товар, так и n-количество товаров, соответственно скролл товаров в карусели должен работать корректно, а также все атрибуты превью карточки товара (стоимость, название, "сердечко" избранного) отображаются на карточке.
+
+**Настройка частоты уведомлений о новых поступлениях**
+
+Поиск может быть нам интересен по-разному. Например, мы очень хотим не пропустить появление нового товара, в таком случае выберем "Уведомления сразу", либо не хотим получать уведомления часто и предпочтем "Уведомления раз в день". В любом выбранном нами случае, мы должны получать уведомления ровно столько раз, сколько мы выбрали в настройке.
+
+**Настройка частоты уведомлений, если уведомления отключены**
+
+А если пользователь отключит в настройках уведомления? В таком случае подписаться на поиск и настроить уведомления не получится. Однако можно перейти в настройки и включить уведомления. Тут важно проверить переход между приложением и экраном настроек уведомлений.
+
+**Удаление поиска**
+
+Пользователю может быть не интересен поисковой запрос и он захочет его удалить. В данном случае, удалить поиск возможно из боттомшита "Подписка на поиск". После удаления проверяем то, чтобы поиск исчезал с экрана "Поиски", а также верстку ленты с сохраненными поисками. Она не должна ломаться. Также стоит учесть кейсы с отключенным соединением с интернетом.
+
+**Каунтеры поисков**
+
+Каунтеры - счетчики, которые служат для интерактивного отображения какого-то количества: новые товары, сообщения, избранное и многое другое. Разумеется, при появлении нового товара в сохраненном поиске, информация об этом товаре придет к нам с бэка. Каунтеры приходят также с бэка. Основные кейсы при тестировании счетчиков будут связаны с удалением товаров и проверки, что значение каунтера изменилось в меньшую сторону, а также, что при поступлении нового товара каунтер изменяется в большую сторону. Но это не все. Стоит проверить максимальное отображаемое значение (в кружке) для каунтера, например, если товаров будет более 100. В таком случае реализация может быть разной, например отображаться значение 99+. Также может отображаться полностью значение счетчика, например 115, тогда следует исходить из логики работы приложения и проверить как будет отображаться максимально допустимое значение (например, вряд ли в приложении для заказа пиццы, пользователь добавит в заказ 124 455 пицц).
+
+**Уведомления по новым товарам в сохраненном поиске**
+
+При тестировании push-уведомлений по новым товарам стоит выполнять проверки, характерные для тестирования пушей. В данной статье не будем затрагивать все кейсы при тестировании push-уведомлений, так как они описаны в одной нашей статье.
+
+**Дополнительные проверки**
+
+В зависимости от реализации могут быть добавлены тултипы, попапы, тоасты - все это, разумеется, требует дополнительных проверок. Также не стоит забывать и про базовые кейсы при тестировании.
+
+Источники:
+
+* [Тестирование сохраненных поисков](https://telegra.ph/Testirovanie-sohranennyh-poiskov-05-20)
diff --git a/mobilnoe-testirovanie/testirovanie-trebovanii-k-mobilnym-prilozheniyam.md b/mobilnoe-testirovanie/testirovanie-trebovanii-k-mobilnym-prilozheniyam.md
new file mode 100644
index 0000000..fca7b79
--- /dev/null
+++ b/mobilnoe-testirovanie/testirovanie-trebovanii-k-mobilnym-prilozheniyam.md
@@ -0,0 +1,177 @@
+# Тестирование требований к мобильным приложениям
+
+Шпаргалка-чеклист для ревью ТЗ к мобильному приложению:
+
+**Общие вопросы по приложению**
+
+* Для каких платформ будет разрабатываться приложение и какие версии ОС будут поддерживаться? Необходимо всегда помнить о минимальной поддерживаемой версии ОС. Иначе можно обнаружить, что функциональность не работает у пользователей, когда задача уже закрыта.
+* На каких устройствах необходимо проверить приложение? Например, приложение должно работать как на смартфонах, так и на планшетах. Или должна быть поддержка Apple Watch.
+* Какую ориентацию экранов поддерживает приложение? Портретная и/или ландскейп? Неприятный момент: если смена ориентации экрана хорошо работает на смартфонах, это не значит, что всё будет так же на планшетах.
+* На каких девайсах приоритетнее всего смотреть? На ваших девайсах приложение может идеально работать, а вот у заказчика на любимом (вставьте китайский android-смартфон) все разъехалось...
+* Должен быть идеальный пиксель-перфект или допускаются некоторые погрешности? Привет, тестирование на соответствие макетам! Ещё неплохо уточнить, должна ли растягиваться вёрстка или под каждый размер экрана должны быть свои макеты?
+* Существуют ли другие клиентские приложения? Например, есть админка, которая внезапно начнет удалять или добавлять элементы. Или веб-версия, которая существует уже в продакшене. Главное - узнать об этом как можно раньше.
+* Есть ли какие-то внешние устройства, которые могут повлиять на логику мобильного приложения? Например, beacon'ы, отправляющие сигналы приложению, или принтеры, печатающие информацию из приложения.
+* Какая целевая аудитория у приложения? Все пользователи в Play Market/AppStore или 50 человек в компании заказчика?
+
+**Разбор приложения по экранам**
+
+* Состав экрана и возможные действия на нем. Из каких элементов состоит экран? Какие действия можно совершить? Какие состояния экрана возможны? Какие есть переходы и на какие экраны они ведут? Что должно отображаться при возврате на этот экран? Ответы на эти вопросы необходимо найти, а лучше зафиксировать в документации.
+* Взаимодействие с сервером на экране. Какие запросы идут на экране? Понимание того, какие запросы на сервер отправляются на экране, поможет выявить такие требования, которые не сможет реализовать сервер по тем или иным причинам.
+* Активность по таймеру. Например, отправляется важная аналитика раз в две минуты или идет обновление данных.
+* Кэширование данных. Загрузка одних и тех же данных при каждом входе на экран может раздражать пользователей. При кэшировании необходимо продумать, когда должна обновляться информация на экране? Когда должен очищаться кэш?
+* Заглушки. Что отображается, если данных нет? Пустой экран - неинформативный для пользователя. А съехавшая заглушка может быть поводом для недовольства заказчика.
+* Поведение в случаях ошибки. Что должно отображаться, если произошла ошибка? Например, отсутствие интернета, серверная или незадокументированная ошибка.
+* Медленная загрузка данных. Что должно происходить при медленной загрузке данных? Лоадеры, блокировка действий, кастомные анимации - всё должно быть продумано.
+* Действия, которые влияют на поведение других экранов. Как действие на одном экране повлияет на поведение на других? Сквозные действия - опасная штука. Особенно, если разработка и тестирование идет по экранам или по отдельным фичам. Тут без регрессии обойтись сложно. Поэтому на некоторых проектах, прежде чем писать тест-кейсы, мы строим матрицу влияния для новых фич.
+* Обновление данных на экране. Когда происходит обновление? Есть следующие варианты и они могут сочетаться:
+ * Каждый раз при открытии экрана (данные живут только пока у пользователя открыт экран).
+ * Каждый раз при запуске приложения (данные живут только пока у пользователя запущено приложение).
+ * По pull-to-refresh'у/по специальной кнопке обновления/по таймеру (данные хранятся в локальном хранилище устройства и при перезапуске приложения восстанавливаются).
+
+Далее рассмотрим функциональность, которая часто используется в приложениях.
+
+**Навигация в приложении**
+
+* С помощью бокового меню. Какие разделы являются корневыми? Какие разделы открываются поверх корневых? Сбрасывается ли история переходов между корневыми разделами?
+* С помощью таббара. Остаётся ли таббар на экране при углублении по навигации внутри раздела? Возвращает ли на корневой экран при повторном тапе на разделе?
+* Различие в переходах между аппаратной и программной кнопкой «Back» в Android.
+
+**Локализация**
+
+Виды поддерживаемой локализации:
+
+* Тексты зашиты внутри приложения. Пользователь в настройках приложения может выставить необходимый язык.
+* Тексты зависят от языка в системных настройках. Язык определяется в зависимости от установленного языка в системных настройках.
+* Тексты приходят с сервера. Тексты приходят с сервера, и язык зависит либо от настроек устройства, либо от настроек приложения.
+
+**Разрешения**
+
+* Запрос на доступ к нотификациям, геолокации, галерее, камере, смс… Кастомный экран или просто системный алерт?
+* Пользователь отказался предоставить доступ. Как приложение поведет себя в этом случае? Предусмотрена ли логика перезапроса на доступ?
+* Пользователь отключил в системных настройках доступ (см. пункт выше).
+
+**Списки**
+
+Часто мобильные приложения включают в себя списки. Для них стоит обратить внимание на следующие моменты:
+
+* Первая загрузка списка. Сколько элементов загружаются за один раз? Что происходит при загрузке? Какое максимальное время может загружаться список?
+* Наличие пэйджинга. Есть ли подгрузка элементов при скролле или весь список загружается за раз? Если есть подгрузка, то обязательно надо проверить, что элементы на границах не пропадают и не дублируются.
+* Обновление списка (см. варианты выше).
+* Наличие разделов.
+* Наличие фильтров/сортировок. Фильтр может быть локальным или серверным. Для списков, которые загружаются целиком или зашиты внутри приложения, фильтры чаще всего локальные, и тестирование их не вызывает особых трудностей. Для списков с подгрузкой фильтры могут повлечь большое количество проверок. Аналогично для сортировок.
+* Состав каждого элемента в списке. Тут может быть как элементарный текст, так и целые экраны со своей внутренней логикой.
+* Взаимодействие с элементами. Добавление нового элемента, удаление, скрытие, перетаскивание.
+* Синхронизация списка между всеми устройствами. В качестве примера можно привести синхронизацию файлов после его изменения на всех устройствах.
+* Сохранение позиции скролла. При переходах между разделами или при возвращении на экран со списком может быть очень важной фичей. Например, если это лента постов.
+
+Поиск по списку
+
+* Онлайн/оффлайн поиск. С оффлайновым поиском всё просто. По сути, это локальный фильтр. Для онлайнового поиска, так же как и для онлайновых фильтров, кейсов будет гораздо больше.
+* Посимвольный поиск или поиск по нажатию на кнопку поиска. Обратите внимание, для посимвольного поиска должно быть ограничение на количество запросов, иначе сервер может начать игнорировать спам от приложения.
+* Очистка поисковой строки.
+* Наличие подсказок.
+* Наличие истории запросов.
+
+**Форма ввода**
+
+* Перечень полей с их описанием и особенностями.
+* Условия сохранения и сброса данных в полях. Когда и какие поля должны сохранять свои значения? Когда очищаться?
+* Ограничения на количество и вид символов.
+* Клавиатура для ввода данных по выбранному полю. Вид клавиатуры: цифровая или символьная. Должна ли клавиатура сдвигать контент при открытии? При каких условиях она должна закрываться?
+* Логика переходов между полями. По кнопке «Далее», по «Next» на клавиатуре.
+* Валидация некорректно введенных данных. Проверки на сервере или на клиенте.
+* Автозапросы на сервер при определенных условиях. Например, если пользователь ввел 6-значный код подтверждения.
+
+**Учетные записи**
+
+* Требования к регистрации и авторизации пользователей. Есть ли возможность регистрации не через мобильное приложение?
+* Восстановление учетной записи. Например, если пользователь забыл пароль от приложения.
+* Логаут. Очистка данных (в частности, сброс привязки пуш-нотификаций) для учетной записи.
+* Авторизация по смс-коду. Должны учитываться кейсы с телефонным номером, его форматом, кодом возможных стран. Переотправка смс в случае проблем с получением.
+* Авторизация через соцсети (см. подробности ниже в разделе «Регистрация/авторизация через соцсети»).
+* Авторизация на нескольких устройствах одновременно. Автологаут или обработка синхронизации данных.
+* Обработка ошибки неверного, устаревшего токена учетной записи.
+* Изменение данных учетной записи. Например, смена пароля.
+
+**Регистрация/авторизация через соцсети**
+
+* Создание учетной записи при первой авторизации через соцсеть.
+* Подгрузка данных из соцсети. Синхронизация при их изменении в соцсети. Например, имя-фамилия пользователя и аватарка.
+* Авторизация через мобильное приложение, соцсети или браузер/вебвью.
+* Запрет доступа приложению к данным из соцсети.
+
+**Ролевая модель**
+
+* Описание ролевой модели. Какие действия доступны для каждой роли?
+* Взаимодействие между представителями разных ролей. Взаимодействие между представителями одной роли.
+* Переход пользователей от одной роли к другой. Какие действия для этого должны выполниться?
+* Предполагаемое процентное соотношение представителей разных ролей. На какую роль обратить внимание в первую очередь?
+
+**Карта**
+
+* Первая загрузка карты. Какая область должна загрузиться? Где и в каком масштабе должна быть отцентрирована карта?
+* Загрузка и отрисовка элементов. Должны ли загруженные элементы кэшироваться? Когда элементы должны обновляться? Этот момент очень важно продумать, чтобы обеспечить быструю загрузку данных и плавные перемещения по карте.
+* Логика работы элементов на карте. Пины, попапы над пинами, карточки для пинов, построение маршрута.
+* Поддержка масштабирования, вращения, наклона карты.
+* Обновление геопозиции и отправка координат текущего местоположения при свернутом приложении.
+
+**Чаты**
+
+* Обработка кейсов, если отправка сообщений была при отсутствии интернет-соединения или при плохом интернете. Повторная отправка сообщений.
+* Групповые чаты. Логика добавления/удаления собеседников в чате. Максимальное количество собеседников.
+* Статусы отправки/получения сообщений. Тут лучше сразу обратить внимание на групповые чаты. Что считается прочитанным сообщением в групповых чатах?
+* Подгрузка истории чата (см. вопросы для списков).
+* Наличие дополнительных фич: удаление сообщений, отображение «Пользователь Х печатает», превью отправляемых файлов, пересылки сообщений.
+* Механизм работы чата. Например, необходимо понимать принцип работы чата на сокетах, чтобы во время тестирования локализовывать баги и определять, на чьей стороне проблема.
+
+**Отправка файлов на сервер и скачивание на устройство**
+
+* Формат файлов. Какие форматы файлов система должна обрабатывать и на какие выдавать ошибку?
+* Возобновление прерванной отправки/скачивания. Автоматическое или после подтверждения пользователя?
+* Максимальное количество отправляемых/закачиваемых файлов.
+* Нехватка памяти на устройстве для скачивания файла. На практике были случаи, когда памяти не хватает, чтобы не просто скачать файл, а даже сделать запись в базу данных. Такие проблемы приходилось обрабатывать.
+* Отмена отправки/скачивания файла.
+* Замена файла один на другой.
+* Скачивание на внешнюю память SD Card.
+* Скачивание в фоне при свернутом приложении.
+
+**Внешние устройства**
+
+* Подключение/отключение устройства. Канал связи, по которому оно взаимодействует с приложением (Wi-Fi/Bluetooth).
+* Влияние внешнего устройства на логику приложения.
+* Конфигурация внешнего устройства. Есть ли какие-то системы, которые администрируют внешнее устройство?
+* Максимальное расстояние, на котором происходит взаимодействие.
+* Сила/мощность сигнала. Выясните, от чего могут зависеть эти параметры? Например, если beacon спрятать в металлическую банку, то шансы на потерю его сигнала резко возрастает.
+* Подключение нескольких внешних устройств одновременно. Например, переключение с одного устройства на другое может привести к любопытным кейсам.
+* Подключение к внешнему устройству при свернутом приложении/при заблокированном экране.
+
+**Аудиоплеер/видеоплеер**
+
+* Поддерживаемые форматы файлов.
+* Кэширование проигрываемого контента. Обязательно нужно понять, какой объем данных необходимо кэшировать для удобства пользователя.
+* Проигрывание в фоне. Нужна ли подгрузка данных при свернутом приложении?
+* Нотификация плеера в системной шторке.
+* Интеграция с Bluetooth-гарнитурой, CarPlay и с другими внешними системами.
+
+**Оплата банковской картой**
+
+* Привязка к профилю и удаление банковской карты. Есть ли тестовое снятие минимальной суммы? Например, 1 рубль, который потом вернется на счет.
+* Оплата привязанной картой. Например, будет ли повторный запрос на смс-подтверждение при последующих оплатах?
+* Обработка ошибок при попытке привязать/оплатить по карте.
+* Синхронизация списка карт при наличии нескольких клиентов в системе. Например, есть веб-версия и есть iOS-версия.
+* Сканирование через камеру и распознавание номера карты.
+
+**Время, календарь, таймер**
+
+* Календарь/время. Влияет ли на логику приложения некорректно выставленная дата и время? Можно ли выбрать период? Какая область допустимых значений?
+* Таймер. Локальный/серверный? Как происходит синхронизация серверного таймера? Например, в Android приложение может ориентироваться не на время, установленное на устройстве, а на время запуска устройства. Как бы пользователь не переводил часы в системных настройках, таймер не собьется.
+
+**Нотификации**
+
+* Вид нотификаций. Есть ли нотификации на определенные события, которые зашиты в приложение? Или push-нотификации, которые присылает сервер?
+* Действия, которые доступны при нотификации. Что будет, если перейти по нотификации? Закрыть её? Что если нотификация устарела и она недоступна?
+* Привязка нотификаций к определенной учетке. Какие действия указывают серверу, что один пользователь вышел и зашел другой?
+
+Источники:
+
+* [Шпаргалка по тестированию требований к мобильным приложениям](https://habr.com/ru/company/mobileup/blog/336992/)
diff --git a/mobilnoe-testirovanie/tipy-mobilnykh-prilozhenii.md b/mobilnoe-testirovanie/tipy-mobilnykh-prilozhenii.md
new file mode 100644
index 0000000..586b733
--- /dev/null
+++ b/mobilnoe-testirovanie/tipy-mobilnykh-prilozhenii.md
@@ -0,0 +1,115 @@
+# Типы мобильных приложений
+
+**Нативные приложения**: написаны на родном для определенной платформы языке программирования. Для Android этим языком является Kotlin/Java, тогда как для iOS - objective-С или Swift. Нативные приложения находятся на самом устройстве, доступ к ним можно получить, нажав на иконку. Они устанавливаются через магазин приложений (Play Market на Android, App Store на iOS и др.). Они разработаны специально для конкретной платформы и могут использовать все возможности устройства - камеру, уведомления и т.п. (при наличии разрешений). В зависимости от предназначения нативного приложения, оно может всецело или частично обходиться без наличия интернет-соединения;
+
+**Веб-приложения**: на самом деле не являются приложениями как таковыми. В сущности, они представляют собой сайты, которые адаптированы и оптимизированы под любой смартфон и выглядят похоже на нативное приложение. И для того, чтобы воспользоваться им, достаточно иметь на устройстве браузер, знать адрес и располагать интернет-соединением. Запуская мобильные веб-приложения, пользователь выполняет все те действия, которые он выполняет при переходе на любой веб-сайт, а также получает возможность «установить» их на свой рабочий стол, создав закладку страницы веб-сайта. Веб-приложения отличаются кроссплатформенностью, то есть способны функционировать, независимо от платформы девайса. Очевидным недостатком такого вида приложений является утрата работоспособности при потере интернет-соединения. Причем из этого выплывает и другой минус - их производительность, которая находится на среднем уровне, в сравнении с другими видами приложений и зависит от возможностей интернет-соединения провайдера услуг. Помимо вышеперечисленного, веб-приложения не могут получить доступ к функциям системы и самого устройства;
+
+**Гибридные приложения**: это веб-приложение в обертке нативного приложения, что служит контейнером для отображения веб-приложения через встроенный упрощенный браузер (webview в Android(Chrome webview в последней версии) и WKWebView в iOS). Нативный “фундамент” даёт преимущества нативных приложений: доступ к функционалу смартфона (API системы, пуши и т.п.), размещение в маркетах, иконка на рабочем столе и т.п., а сторона веб-приложений дает плюсы в виде кроссплатформенности и простоты обновления контента. Компания, имеющая веб-приложение, может практически “на коленке” собрать гибридные приложения для основных платформ и обеспечить себе присутствие в маркете и на рабочем столе клиентов;
+
+**Кроссплатформенные приложения**: которые иногда путают с гибридными. Такие приложения разрабатываются с помощью кроссплатформенных фреймворков: [React Native](https://reactnative.dev) (JavaScript), [Flutter](https://flutter.dev) (Dart), [Ionic](https://ionicframework.com) (JavaScript), [Xamarin](https://dotnet.microsoft.com/en-us/apps/xamarin) (.NET and C#) и т.п. и имеют общий код для iOS и Android.
+
+**Аналоги инсталлируемых приложений**
+
+* Progressive Web Apps (PWA);
+* Google Play Instant (Android Instant Apps (AIA));
+* Accelerated Mobile Pages (AMP).
+
+**Progressive Web Apps (PWA)**: термин «прогрессивное веб-приложение» не является официальным названием. Это просто сокращение, которое изначально использовалось Google для обозначения концепции создания гибкого, адаптируемого приложения с использованием только веб-технологий. PWA - это веб-приложения, которые постепенно улучшаются, чтобы функционировать как установленные нативные приложения на поддерживаемых платформах, но при этом функционируют как обычные веб-сайты в других браузерах. Качества PWA сочетают в себе лучшее из Интернета и скомпилированных приложений. PWA запускаются в браузерах, как веб-сайты. Но PWA также имеют доступ к функциям приложений; Например:
+
+* PWA все еще может работать, когда устройство отключено;
+* PWA можно установить в операционной системе;
+* PWA поддерживают push-уведомления и периодические обновления;
+* PWA могут получить доступ к аппаратным функциям.
+
+Кроссплатформенность таких веб-приложений не ограничивается мобильными устройствами. Например, на платформе Windows такие приложения тоже выглядят и существуют в системе точно также, как и нативные приложения: можно установить из стора, добавить ярлык в пуск, доступны File systems, Video, Audio, High-performance code, Databases, USB, Bluetooth и т.п., при этом все фактическое содержимое является веб-сайтом.
+
+На самом деле, скорее всего, вы раньше часто посещали PWA, даже не осознавая этого. Если вы когда-нибудь просматривали Instagram, Pinterest, Spotify или Tinder на своем ноутбуке или смартфоне, вы столкнулись с PWA.
+
+Таким образом, PWA имеют гораздо более низкую стоимость кроссплатформенной разработки, чем скомпилированные приложения, которым требуется определенная кодовая база для каждой платформы.
+
+Для того, чтобы веб-приложение можно было называть PWA, оно должно соответствовать определенным критериям:
+
+* Обнаруживаемое (**Discoverable**): Приложение можно обнаружить в результатах веб-поиска и в поддерживаемых магазинах приложений;
+* Устанавливаемое (**Installable**): можно закрепить и запустить приложение с главного экрана;
+* Возможность повторного вовлечения (**Re-engageable**): приложение может получать push-уведомления, даже если неактивно;
+* Независимо от сети (**Network-independent**): приложение работает в автономном режиме и в условиях слабого подключения к сети;
+* Прогрессивное (**Progressive**): UX увеличивается или уменьшается в зависимости от возможностей устройства;
+* Безопасное (**Safe**): приложение обеспечивает безопасный HTTPS endpoint и другие меры безопасности для пользователей;
+* Отзывчивое (**Responsive**): приложение адаптируется к размеру и ориентации экрана, методу ввода;
+* Линкованное (**Linkable**): делитесь и запускайте приложение по стандартной ссылке.
+
+Итак, как можно ли узнать, является ли веб-сайт PWA? Ну, нет. По крайней мере, не совсем точно. Если вы не разработчик и не копаетесь в исходном коде сайта, у вас нет определенного способа точно сказать, построен ли сайт на технологии PWA. При этом есть несколько уловок, которые, хотя и не гарантируют точного результата, могут дать вам некоторые признаки того, что данный веб-сайт является PWA.
+
+* **Одностраничный сайт**. Это самый простой способ узнать, может ли веб-сайт быть PWA. Он основан на природе PWA: Progressive Web Apps технически представляют собой одностраничный веб-сайт. Это не означает, что веб-сайт, построенный на основе PWA, имеет только одну страницу. Это означает, что событие просмотра страницы происходит только один раз, когда пользователь изначально загружает сайт. После этого все загрузки страниц обрабатываются Javascript. Это отличается от обычных веб-сайтов, где каждое изменение страницы вызывает перезагрузку страницы вместе со всем исходным кодом HTML. Так как это работает? Что ж, очень просто: взгляните на активную вкладку в вашем браузере. Если сайт является PWA, при смене страниц сайт не перезагружается, что означает отсутствие анимации «загрузки» на вкладке браузера. Теперь давайте посмотрим на наш сайт [SimiCart](https://www.simicart.com/pwa.html/) в качестве примера. При смене страниц сайт не перезагружается! Технически вы просто все время остаетесь на одной «странице». Вот почему страницы PWA загружаются так быстро и плавно. Все страницы предварительно загружаются при первом посещении сайта и доставляются вам впоследствии. Они не зависят от скорости вашей сети и могут работать даже в автономном режиме!
+* **Service Workers**. Service Workers - это название технологии, лежащей в основе прогрессивного веб-приложения, которая обеспечивает его автономные возможности, push-уведомления и кэширование ресурсов. Согласно Google, сервис-воркеры лежат в основе методов PWA. Итак, если мы сможем выяснить, использует ли веб-сайт технологию Service Workers, мы сможем сказать, может ли этот сайт быть PWA. Если вы используете браузеры на базе Chrome, вы можете легко это проверить с помощью Inspector Tool. Щелкните правой кнопкой мыши веб-сайт, который вы хотите проверить, выберите «Проверить элемент». Затем перейдите на вкладку «Приложение» - «Рабочие службы». Вы можете легко увидеть, есть ли на этом сайте Service Workers. Опять же, этот трюк только дает намек на то, что определенный веб-сайт является PWA. Несмотря на то, что Service Workers является основной частью PWA, они не являются эксклюзивной частью PWA. Веб-сайты, не относящиеся к PWA, также могут использовать Service Workers для улучшения своей функциональности. Если вы хотите узнать больше о PWA Service Worker, у нас есть [эксклюзивная статья](https://www.simicart.com/blog/pwa-service-worker/) для вас, чтобы узнать все об этой удивительной технологии.
+* \*\*HTTPS \*\*secure origin. PWA работают только по HTTPS.
+* **Manifest.json** - Имеется файл настроек.
+
+**Accelerated Mobile Pages (AMP)**
+
+Accelerated Mobile Pages (AMP) - это технология с открытым исходным кодом, позволяющая создавать веб-страницы, которые быстро загружаются в мобильных браузерах. Формат AMP состоит из:
+
+* AMP HTML - язык HTML, в котором часть тегов заменена на эквивалентные AMP-теги, а часть запрещена для использования;
+* AMP JS - в работе используется собственная JS-библиотека, позволяющая элементам страницы загружаться асинхронно;
+* Google AMP Cache - в процессе индексации AMP-страницы, поисковая система кэширует её данные и воспроизводит со своих серверов.
+
+Многие воспринимают AMP как способ положить статический контент своего сайта (статьи, новости, заметки и т.д.) в кэш Google, чтобы при открытии из поиска этот контент загружался мгновенно (о высокой скорости загрузки AMP страниц свидетельствует иконка молнии в результатах поиска :)). Естественно, если вам нужно добиться именно такого результата, то с AMP это сделать будет очень легко. Но AMP - это гораздо больше чем просто технология для работы со статическим контентом или кэшем Google. AMP уже давно используется как библиотека общего назначения, основанная на web компонентах, для создания быстрых динамических страниц и даже сайтов целиком, на которые пользователи попадают как из поиска, так и из других источников, включая прямые заходы. С этой точки зрения AMP можно поставить в один ряд с Polymer, React или Angular. Естественно с оглядкой на то, что AMP предназначена для простых (чтобы это не значило) сайтов, где основной упор делается на контент, а динамическая составляющая ограничена.
+
+Отдельно хочется отметить, что несмотря на название - Accelerated Mobile Pages, AMP может использоваться для создания любых сайтов, как десктопных, так и мобильных. Сайт проекта - [ampproject.org](https://amp.dev) является замечательным примером того, что можно сделать с AMP для десктопа.
+
+**Google Play Instant (Android Instant Apps (AIA))**
+
+Google Play Instant (прошлое название Android Instant Apps) - это функция, которая позволяет вам использовать приложение без необходимости полностью загружать его на свой телефон: просто найдите его в Play Store и нажмите «Открыть приложение». Более того, это позволяет вам перейти к определенному действию в приложении, которое вы не установили, просто нажав URL-адрес. Недавно Google добавил в Play Store кнопку «Попробовать» для некоторых приложений с мгновенным запуском Android.
+
+Например, если вам прислали ссылку на видео в Buzzfeed, то можно сразу же открыть её в приложении этого сервиса, даже если оно у вас не установлено. Ранее выбор был лишь либо отдельно установить приложение, либо перейти по ссылке в браузере. Конечно, это несколько дольше, чем просто открыть веб-страницу, но всё же намного быстрее, чем устанавливать целое приложение ради одной ссылки. Обещают, что занимать весь процесс открытия чего-либо во «мгновенных приложениях» будет несколько секунд. Однако полноценную функциональность установленного приложения вы не получите, будет загружено лишь то, что необходимо для выполнения текущего действия, например, просмотра видео.
+
+На странице часто задаваемых вопросов о приложениях Google с мгновенным запуском говорится, что эти приложения могут использовать следующие разрешения:
+
+* ОПЛАТА
+* ACCESS\_COARSE\_LOCATION
+* ACCESS\_FINE\_LOCATION
+* ACCESS\_NETWORK\_STATE
+* КАМЕРЫ
+* INSTANT\_APP\_FOREGROUND\_SERVICE только в Android O.
+* INTERNET
+* READ\_PHONE\_NUMBERS только в Android O.
+* ЗАПИСЬ АУДИО
+* VIBRATE
+
+Все, что отсутствует в этом списке, не поддерживается Instant Apps. Обратите внимание, что такие вещи, как Bluetooth, установка будильника, использование отпечатков пальцев и установка обоев, отсутствуют.
+
+Другие ограничения включают отсутствие поддержки фоновых служб (приложений, которые могут запускаться без ведома пользователя), push-уведомлений, доступа к внешнему хранилищу или просмотра установленных приложений на устройстве. Приложения с мгновенным запуском также не смогут изменять настройки на устройстве пользователя, такие как обои.
+
+Ограничения на размер сборки:
+
+* Dynamic Feature Modules вообще не ограничены по размеру;
+* Instant-Enabled Dynamic Feature Modules могут занимать до 10 Мб.
+
+Если ваша фича:
+
+* больше 10 Мб, то извините;
+* от 4 до 10 Мб - доступна по кнопке «Попробовать» из Google Play и все;
+* меньше 4 МБ - доступны все средства привлечения пользователей в Instant-Enabled модуль (запуск из рекламы, по ссылке, из сообщений и т.д.).
+
+Примерами Instant Apps являются BuzzFeed, Skyscanner, Onefootball, Red Bull TV, приложение UNS ShareTheMeal, Sports.ru, Vimeo и многие другие.
+
+Источники:
+
+* [What Is PWA? All You Need to Know About Progressive Web Apps](https://www.simicart.com/blog/what-is-progressive-web-app/)
+* [Overview of Progressive Web Apps (PWAs)](https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps-chromium/)
+* [Используем AMP как библиотеку общего назначения для создания быстрых динамических сайтов](https://habr.com/ru/company/google/blog/419589/)
+* [Приложения с мгновенным запуском Android - что они значат для пользователей и разработчиков?](https://android.inform.click/prilozhenija-s-mgnovennym-zapuskom-android-chto-oni-znachat-dlja-polzovatelej-i-razrabotchikov/)
+* [Google Play Instant. Рефакторинг длиною в жизнь](https://habr.com/ru/company/oleg-bunin/blog/462511/)
+
+Доп. материал:
+
+* [Сайт, где можно узнать, что может PWA](https://whatpwacando.today)
+* [12 Best Examples of Progressive Web Apps (PWAs) in 2021](https://www.simicart.com/blog/progressive-web-apps-examples/)
+* [11 Best Progressive Web Apps (PWAs) Games in 2021](https://www.simicart.com/blog/pwa-games/)
+* [Тестирование аналогов инсталлируемых приложений. Диана Пинчук. Comaqa Spring 2019](https://www.youtube.com/watch?v=i9kmWZGnVEY)
+* [MDN Web Docs - Progressive web apps (PWAs)](https://developer.mozilla.org/en-US/docs/Web/Progressive\_web\_apps)
+* [An Introduction to Progressive Web Apps](https://www.cloudways.com/blog/progressive-web-apps/)
+* [All You Need to Know About Progressive Web App to Decide if Your Business Needs One](https://fulcrum.rocks/blog/progressive-web-app/)
+* [Натив или гибрид? Специалисты Яндекса отвечают на главный вопрос мобильной разработки](https://habr.com/ru/company/yandex/blog/326882/)
+* [Офф. дока Google Play Instant](https://developer.android.com/topic/google-play-instant)
+* [Особенности тестирования приложения на Flutter под iOS и Android и чем оно отличается от тестирования нативного приложения](https://habr.com/ru/company/atisu/blog/598389/)
diff --git a/obshee/README.md b/obshee/README.md
new file mode 100644
index 0000000..976f522
--- /dev/null
+++ b/obshee/README.md
@@ -0,0 +1,2 @@
+# Общее
+
diff --git a/obshee/alfa-i-beta-testirovanie-alpha-testing-and-beta-testing.md b/obshee/alfa-i-beta-testirovanie-alpha-testing-and-beta-testing.md
new file mode 100644
index 0000000..01fcdf0
--- /dev/null
+++ b/obshee/alfa-i-beta-testirovanie-alpha-testing-and-beta-testing.md
@@ -0,0 +1,38 @@
+# Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
+
+_Альфа-тестирование (alpha testing): Моделируемое или действительное эксплуатационное тестирование потенциальными пользователями/заказчиками или независимой командой тестирования на стороне разработчиков, но вне разрабатывающей организации. Альфа-тестирование часто применяется к коробочному программному обеспечению в качестве внутреннего приемочного тестирования. (ISTQB)_
+
+_Бета-тестирование (beta testing): Эксплуатационное тестирование потенциальными и/или существующими клиентами/заказчиками на внешней стороне никак не связанными с разработчиками, с целью определения действительно ли компонент или система удовлетворяет требованиям клиента/заказчика и вписывается в бизнес-процессы. Бета-тестирование часто проводится как форма внешнего приемочного тестирования готового программного обеспечения для того чтобы получить отзывы рынка. (ISTQB)_
+
+Альфа- и бета-тестирование - это Customer Validation methodologies (Acceptance Testing types) которые помогают укрепить веру в запуске продукта и, таким образом, привести к успеху продукта на рынке. Несмотря на то, что они оба полагаются на реальных пользователей и обратную связь разных команд, ими движут разные процессы, стратегии и цели. Эти два типа тестирования вместе увеличивают успех и продолжительность жизни продукта на рынке. Эти этапы можно адаптировать к продуктам Consumer, Business или Enterprise. Этапы альфа- и бета-тестирования в основном сосредоточены на обнаружении ошибок в уже протестированном продукте и дают четкое представление о том, как продукт на самом деле используется пользователями в реальном времени. Они также помогают получить опыт работы с продуктом перед его запуском, а ценные отзывы эффективно используются для повышения удобства использования продукта. Цели и методы альфа- и бета-тестирования переключаются между собой в зависимости от процесса, которому следуют в проекте, и могут быть изменены в соответствии с процессами.
+
+[Альфа-тестирование](https://www.softwaretestinghelp.com/alpha-testing/) - это форма внутреннего приемочного тестирования (internal acceptance testing), выполняемого, в основном, собственными командами по обеспечению качества и тестированию ПО. Альфа-тестирование - это последнее тестирование, проводимое группами тестирования на месте разработки после приемочного тестирования и перед выпуском программного обеспечения для бета-тестирования. Альфа-тестирование также может быть выполнено потенциальными пользователями или клиентами приложения. Но все же это форма внутреннего приемочного тестирования.
+
+[Бета-тестирование](https://www.softwaretestinghelp.com/beta-testing/) - это следующий этап после альфа-тестирования. Это заключительный этап тестирования, на котором компании выпускают ПО для нескольких внешних групп пользователей, не входящих в группы тестирования компании или сотрудников. Эта начальная версия программного обеспечения известна как бета-версия. Большинство компаний собирают отзывы пользователей в этом выпуске. Короче говоря, бета-тестирование можно определить как тестирование, проводимое реальными пользователями в боевой среде. Несмотря на то, что компании проводят строгую внутреннюю проверку качества с помощью специальных групп тестирования, практически невозможно протестировать приложение для каждой комбинации тестовой среды. Бета-версии упрощают тестирование приложения на тысячах тестовых машин и исправление проблем перед выпуском приложения для широкой публики. Выбор групп для бета-тестирования может производиться в зависимости от потребностей компании. Компания может либо пригласить нескольких пользователей для тестирования предварительной версии приложения, либо выпустить ее открыто, чтобы это мог сделать любой. Устранение проблем в бета-версии может значительно снизить затраты на разработку, поскольку большинство незначительных сбоев будут исправлены до окончательной версии. До сих пор многие крупные компании успешно использовали бета-версии своих самых ожидаемых приложений.
+
+| **Alpha Testing** | **Beta Testing** |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Testing environment | Real environment |
+| Functional, usability | Functional, Usability, Reliability, Security |
+| White box and / or Black box testing | Black box testing |
+| На найденные дефекты создаются баг-репорты с high priority, после чего они немедленно исправляются | Дефекты собираются из обратной связи от пользователей и записываются как улучшения для будущей версии |
+|
Цели:
Оценить качество продукта;
Убедиться в готовности к бета-тестированию;
Фокус на поиске ошибок;
Работает ли ПО?
|
Цели:
Оценить удовлетворенность клиентов;
Убедиться в готовности к релизу (в прод);
Фокус на сборе отзывов и предложений;
Нравится ли заказчикам (customers) продукт?
|
+|
Когда?
Обычно после System testing phase или когда продукт готов на 70-90%;
Фичи почти заморожены, и нет возможности для серьезных улучшений;
Сборка должна быть стабильной для технического пользователя;
|
Когда?
Обычно после альфа-тестирования и продукт готов на 90-95%;
Фичи заблокированы и улучшения уже не принимаются;
Сборка должна быть стабильной для реальных пользователей;
|
+|
Продолжительность теста:
Проведение множества циклов испытаний;
Каждый цикл тестирования длится 1-2 недели;
Продолжительность также зависит от количества обнаруженных проблем и количества добавленных новых функций;
|
Продолжительность теста:
Проведение всего 1 или 2 цикла испытаний;
Каждый цикл тестирования длится 4-6 недель;
Циклы тестирования могут увеличиваться в зависимости от отзывов / предложений реальных пользователей;
|
+|
Stakeholders:
Engineers (in-house developers), Quality Assurance Team, and Product Management Team
|
Stakeholders:
Product Management, Quality Management, and User Experience teams
|
+|
Участники:
Технические эксперты, специализированные тестировщики с хорошими знаниями предметной области (новые или уже участвовавшие в фазе тестирования системы), предметная экспертиза (Subject Matter Expertise);
В некоторых случаях клиенты и / или конечные пользователи могут участвовать в альфа-тестировании;
|
Участники:
Конечные пользователи, для которых предназначен продукт;
Customers также обычно участвуют в бета-тестировании;
|
+|
Ожидания:
Приемлемое количество ошибок, которые были пропущены при предыдущих тестовых мероприятиях;
Неполные функции и документация;
|
Ожидания:
Почти готовый продукт с гораздо меньшим количеством ошибок и сбоев;
Почти готовые функции и документация;
|
+|
Критерии начала (Entry Criteria):
Альфа-тесты, разработанные и проверенные с учетом требований бизнеса (Business requirements);
Требования покрыты тестами в Traceability matrix;
Команда тестирования со знанием предметной области (domain) и продукта;
Настройка среды и сборка для выполнения (Environment setup and build for execution);
Набор инструментов должен быть готов для регистрации ошибок и управления тестированием;
Системное тестирование, в идеале, должно быть закончено;
|
Критерии начала (Entry Criteria):
Бета-тесты, например, что тестировать, и процедуры, задокументированные для использования на проде;
Нет необходимости в матрице прослеживаемости;
Конечные пользователи и заказчик объединяются;
Настройка среды конечного пользователя;
Набор инструментов должен быть готов для сбора отзывов / предложений;
Alpha Testing должно быть закончено;
|
+|
Критерии окончания (Exit Criteria):
Все альфа-тесты должны быть выполнены, и все циклы должны быть завершены;
Critical / Major дефекты должны быть исправлены и повторно протестированы;
Должен быть завершен эффективный анализ отзывов, предоставленных участниками;
Alpha Test Summary report;
Alpha Testing должно быть закончено;
|
Критерии окончания (Exit Criteria):
Все циклы должны быть завершены;
Critical / Major дефекты должны быть исправлены и повторно протестированы;
Должен быть завершен эффективный анализ отзывов, предоставленных участниками;
Beta Test Summary report;
Beta Testing должно быть закончено;
|
+|
Плюсы (Pros):
Помогает обнаружить ошибки, которые не были обнаружены во время предыдущих тестовых мероприятий;
Лучшее представление об использовании и надежности продукта;
Анализ возможных рисков во время и после запуска продукта;
Помогает подготовиться к будущей поддержке клиентов;
Помогает укрепить доверие клиентов к продукту;
Снижение затрат на обслуживание за счет выявления и исправления ошибок перед запуском бета-версии / production версии;
Простое управление тестированием (Test Management);
|
Плюсы (Pros):
Тестирование продукта не поддается контролю, и пользователь может протестировать любую доступную функцию любым способом - в этом случае угловые области (corner areas) хорошо протестированы;
Помогает обнаружить ошибки, которые не были обнаружены во время предыдущих тестовых мероприятий (включая альфа-версию);
Лучшее представление об использовании продукта, надежности и безопасности;
Анализ точки зрения и мнение реального пользователя о продукте;
Отзывы / предложения реальных пользователей помогают в дальнейшем импровизировать продукт;
Помогает повысить удовлетворенность клиентов продуктом;
|
+|
Минусы (Cons):
Ожидается, что не вся функциональность продукта будет проверена;
Ограничено только бизнес-требованиями;
|
Минусы (Cons):
Определенный объем (Scope) может соблюдаться или не соблюдаться участниками;
Документация больше и требует больше времени - требуется для использования инструмента регистрации ошибок (при необходимости), использования инструмента для сбора отзывов / предложений, процедуры тестирования (установка / удаление, руководства пользователя);
Не все участники гарантируют, что проводят качественное тестирование;
Не все отзывы эффективны - на рассмотрение отзывов уходит много времени;
Управление тестированием слишком сложно;
|
+
+Помимо альфа- и бета-тестирования, существуют еще гамма-тестирования и пилотное.
+
+[Gamma Testing](https://www.softwaretestinghelp.com/gamma-testing-2/) - это заключительный этап тестирования, который выполняется, когда продукт готов к выпуску с особыми требованиями. Не все действия по внутреннему тестированию, которые решено пройти через этот этап тестирования, выполняются на продукте. Этот этап не позволяет вносить в продукт какие-либо изменения, кроме исправления критических ошибок, которые необходимо выполнить. Это тестирование проводится, чтобы убедиться, что продукт является более безопасным с точки зрения качества продукта, удобства использования, безопасности и производительности перед выпуском в прод.
+
+[Pilot testing](https://www.softwaretestinghelp.com/what-is-pilot-testing/) определяется как тип тестирования программного обеспечения, который проверяет компонент системы или всю систему в режиме реального времени. Целью пилотного теста является оценка осуществимости, времени, стоимости, риска и эффективности исследовательского проекта. Это тестирование проводится точно между UAT и Production. В пилотном тестировании выбранная группа конечных пользователей пробует тестируемую систему и предоставляет обратную связь до полного развертывания системы. Другими словами, это означает проведение генеральной репетиции для последующего теста на удобство использования. Пилотное тестирование помогает в раннем обнаружении ошибок в Системе. Пилотное тестирование связано с установкой системы на площадке заказчика (или в среде, моделируемой пользователем) для тестирования на предмет постоянного и регулярного использования. Выявленные недостатки затем отправляются команде разработчиков в виде отчетов об ошибках, и эти ошибки исправляются в следующей сборке системы. Во время этого процесса иногда приемочное тестирование также включается как часть тестирования на совместимость. Это происходит, когда система разрабатывается для замены старой.
+
+Источники:
+
+* [Alpha Testing And Beta Testing (A Complete Guide)](https://www.softwaretestinghelp.com/what-is-alpha-testing-beta-testing/)
diff --git a/obshee/analiz-pervoprichin-rca-root-cause-analysis.md b/obshee/analiz-pervoprichin-rca-root-cause-analysis.md
new file mode 100644
index 0000000..1898fb0
--- /dev/null
+++ b/obshee/analiz-pervoprichin-rca-root-cause-analysis.md
@@ -0,0 +1,80 @@
+# Анализ первопричин (RCA - Root Cause Analysis)
+
+_Анализ первопричины (root cause analysis): Анализ, направленный на идентификацию первопричин дефектов. При применении мер к устранению первопричины, можно надеяться на минимизацию частоты появления дефектов определенного типа. (ISTQB)_
+
+_Первопричина (root cause): Источник дефекта, при удалении которого частота подобных дефектов сокращается, или же подобные дефекты исчезают полностью. (CMMI)_
+
+Любой процесс, неважно, разработка это или тестирование, сопровождение, управление качеством и т.д., всегда должен быть цикличен. Существуют 4 основных подхода к работе с процессами, и самый популярный из них, это уже общепризнанный цикл Деминга. Именно на его основе строится работа процесса и все другие методологии, такие как DMAIC (6 сигм), IDEAL, EFQM, которые всегда говорят нам о том, что нужно не только требовать выполнение процесса, но и постоянно его анализировать и непрерывно совершенствовать. Эти модели позволяют нам понять, как мы должны работать с процессом, и самое главное, мы должны всегда видеть проблемы нашего процесса и стараться их решить.
+
+Говоря о тестировании, существуют 2 основополагающих подхода к совершенствованию процесса тестирования, это MBI и ABI.
+
+**MBI или Model Based Improvement** - подход к совершенствованию процесса тестирования, который основан на референтных моделях совершенствования процесса тестирования. Модели могут быть процессные, такие как TMMi, TPI и контекстные, такие как STEP или CTP. Эти модели позволяют нам на основе практик строить наш процесс тестирования по конкретным шагам, тем самым развивая процесс тестирования равномерно и последовательно.
+
+Но подходят ли нам такие модели для аудитов уже существующих процессов?
+
+Основная проблема в том, что каждый процесс тестирования различается в зависимости от организации, что ставит по сомнение применение тех практик, которые дает нам модельный подход. Ну и многие специалисты, которые проводили именно аудит процесса тестирования возможно слышали фразу, ставящую в тупик все результаты вашей работы: “Я могу сейчас взять ваши результаты, принести их в другую компанию и они тоже там будут применимы. Нет конкретики!” И все это потому, что многие руководители, тест-менеджеры, особенно в России, не понимают различия между аудитом и оценкой уровня зрелости процесса тестирования.
+
+Аудит - это анализ текущего состояния процесса с целью решения конкретных проблем, не позволяющих процессу выполнять поставленные задачи.
+
+Оценка зрелости - это анализ текущего состояния процесса с целью понимания его зрелости относительно общепринятых моделей процесса тестирования. Оценка уровня зрелости зачастую может не решать вообще никаких проблем, т.к. ее задача только оценить процесс.
+
+Поэтому, говоря о модельном подходе MBI разумно его применять только для выполнения задач по оценке уровня зрелости процесса тестирования и написанию стратегии развития процесса тестирования на длительных срок. Во всех остальных случаях, а особенно, когда вам нужно решить какую-то проблему, MBI не поможет вам. Для это существует подход ABI.
+
+**ABI или Analytical Based Improvement** - это подход к совершенствованию процесса тестирования, который основывается на аналитических подходах анализа процесса.
+
+Главное отличие модельного подхода от аналитического в том, что когда мы анализируем процесс по MBI, то мы анализируем процесс сверху вниз, то есть, сначала мы смотрим на процесс в целом, потому делим его на области, этапы и т.д., тем самым постепенно погружаясь в детали процесса. Аналитический подход работает наоборот, мы сначала погружаемся в самые детали нашего процесса и уже потом идя, как по цепочке, вверх, доходим до решения нашей главной проблемы.
+
+Существуют несколько аналитических подходов к совершенствованию процессов, но я ни разу не видел их применение к процессу тестирования, т.к. они содержат именно модель анализа и могут быть применимы, в том числе, и в производстве фабрики, расследовании аварий, построении мостов и многом многом другом.
+
+Задайте себе вопрос, как часто к вам приходил ваш руководитель со словами, у нас есть такая проблема в процессе и ее нужно решить? Что вы делаете? Вы ищете причину этой проблемы и пытаетесь ее устранить. Но очень часто бывает так, что вроде вы решаете причину, но процесс все равно не работает как надо. И все это потому, что вы выбрали для решения не то узкое место!
+
+Поэтому для проведения аудита процесса тестирования, с целью решения конкретных проблем стоит обратить свое внимание на Root Cause Analysis.
+
+**Анализ первопричин (RCA)** - это систематический процесс выявления скрытых первопричин проблем или событий и подхода к их устранению. В основе RCA лежит основная идея о том, что эффективное управление требует большего, чем просто «тушение пожаров» возникающих проблем, но и поиск способов их предотвращения. Таким образом RCA представляет собой древовидную иерархическую структуру зависимости причин, как с проблемой, так и между собой.
+
+Стандартно, к проблемам процесса тестирования, я отношу только те проблемы, которые связаны с классическим треугольником - цена/качество/сроки. Почему это так? Любой процесс ИТ, в том числе и тестирование, должен обеспечивать бизнес организации. ИТ - это помощник бизнеса, поэтому, когда вам бизнес говорит, что они не успевают внедрять все запланированные фичи, продукты, то это не проблема бизнеса (что они генерят много задач), а проблема тестирования. Все остальное, что не связано с этим “треугольником проблем” является причинами возникновения проблем, которые зачастую бывают непонятны и скрываются от нас.
+
+Процесс аудита по RCA состоит из 5 этапов:
+
+* Определить проблему и ее влияние на общие цели;
+* Собрать всю информацию и данные;
+* Определить любые инциденты (issues), которые способствовали возникновению проблемы;
+* Определить первопричины;
+* Определить рекомендации на случай повторения проблем в будущем;
+* Реализовать необходимые решения;
+
+Итак, что такое проблема? Проблема - это вопрос или задача, требующая разрешения. Проблемы в нашей работе мы находим постоянно, критичность проблемы мы определяем симптомами, т.е. признаками существования проблемы. Допустим, мы идентифицировали проблему, как постоянный сдвиг сроков внедрения релиза. Признаком существования в проблемы в данном случае может быть систематичность ее возникновения. Я думаю, вы понимаете разницу, один раз у вас произошел сдвиг за 6 релизов, или уже 6-й раз подряд. Во втором случае проблема уже начинает носить критический характер. Решать все проблемы невозможно, поэтому если у Вас есть большое количество проблем, то вы можете выбрать наиболее важные из них по степени влияния и частоте возникновения.
+
+Имея проблему, мы можем приступать к поиску вероятностных причин. Самый простой способ определения причин - метод брейншторма всех вовлеченных в процесс участников. Вы можете собрать со всех специалистов их мнение относительно того, какие они видят причины возникновения проблемы и после этого выбрать из них наиболее часто называемые сотрудниками.
+
+Следующий и очень важный шаг - это анализ вероятностных причин.
+
+Существуют несколько подходов к проведению анализа, таких как диаграммы зависимостей или рассеивания, аффинная диаграмма, но самым распространенным подходом к проведению анализа является диаграмма Парето.
+
+Путем брейншторма мы определили 5 основных причин возникновения проблемы, связанной со сдвигом сроков внедрения. После этого наша задача понять, какие из этих причин наиболее серьезно влияют на нашу проблему. Используя принцип Парето мы определяем количество человеко-дней, которые мы теряем из-за возникновения той или иной проблемы.
+
+В результате анализа мы видим, что только первые 2 причины на 60% влияют на сдвиг сроков внедрения, что существенно больше, чем остальные 3 причины суммарно.
+
+
+
+Следующим этапом является проведение причинно-следственного анализа (ПСА) с целью выявления коренных причин и их зависимостей друг с другом. Для этого используется диаграмма причинно-следственного анализа, основная задача которой заключается в том, что идя от проблемы по цепочке мы погружаемся на каждом уровне в причины возникновения причин, тем самым доходя до истинной или коренной причины возникновения проблем. В результате, решив коренную причину, мы автоматически решаем все остальные наши причины, что приводит к минимизации влияния или полного устранения нашей проблемы.
+
+Для выполнения ПСА мы наносим на наше дерево все наши причины, которые были определены ранее принципом Парето. После это мы их приоритезируем и определяем их взаимозависимость. Например, говоря о тестовых средах, а именно проблемах ,связанных с подбором тестовых данных, это приводит к возникновению дефектов “тестирования”, что увеличивает сроки выполнения работ по тестированию ПО. Соответственно, решив эту причину, мы автоматически сможем снизить влияние причины, связанной с дефектами. Поэтому, мы можем решать не 3 причины, а всего 2, тем самым сокращая затраты на оптимизацию процесса тестирования.
+
+
+
+Ну и заключительный этап - это выработка решений. Проведя анализ RCA решения будут уже вполне понятны, но очень важно, чтобы эти решения действительно были нацелены на конкретную причину и были выполнимы всей командой, на которую ложится их реализация.
+
+Наиболее понятной книгой, рассматривающей модель RCA, я считаю Андерсон Бьерн - «Анализ основной причины. Упрощенные инструменты и методы», в которой на обычных жизненных примерах рассматриваются различные возможности применения модели RCA.
+
+Поэтому, если Вам поставили задачу оптимизировать ваш процесс тестирования, но для этого вам нужно решить какие-то текущие проблемы, то вам нужен аудит с применением ABI, т.к. именно ABI позволяют точечно решать проблемы и любые ваши рекомендации будут носить не рекомендательный характер, а детальный, направленный на оптимизацию именно для вашего проекта или процесса.
+
+Источник:
+
+[Root Cause Analysis. Как минимизировать затраты на оптимизацию процесса тестирования](http://www.performance-lab.ru/blog/root-cause-analysis-kak-minimizirovat-zatraty-na-optimizatsiyu-protsessa-testirovaniya)
+
+Доп. материал:
+
+* [Guide To Root Cause Analysis - Steps, Techniques & Examples](https://www.softwaretestinghelp.com/root-cause-analysis/)
+* [A Brief History of Root Cause Analysis](https://www.brighthubpm.com/risk-management/123244-how-has-the-root-cause-analysis-evolved-since-inception/)
+* [How to Conduct a Root Cause Analysis](https://www.thecompassforsbc.org/how-to-guides/how-conduct-root-cause-analysis)
diff --git a/obshee/biznes-logika-business-logic.md b/obshee/biznes-logika-business-logic.md
new file mode 100644
index 0000000..beb82ed
--- /dev/null
+++ b/obshee/biznes-logika-business-logic.md
@@ -0,0 +1,15 @@
+# Бизнес-логика (Business logic)
+
+Бизнес-логика - это реализация работы бизнес-процессов внутри ПО, т.е. это реализация предметной области (domain) в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
+
+Еще одним примером бизнес-логики является процесс «встречи» клиента, посетившего сайт компании. Она включает запрос имени и пароля, вывод приветственной надписи, отображение персональных предложений (если есть), вывод поздравления, если посещение происходит в праздник или день рождения клиента, вывод предложения добавить товары в корзину и информации о методах оплаты. В то же время высказывание о необходимости «встречи» клиента является бизнес-правилом.
+
+Можно сказать, что все, что является процессом, процедурой - можно отнести к бизнес-логике. Напротив, все, что процессом и процедурой не является - является бизнес-правилами. Таким образом, бизнес-логика носит процедурный характер, а бизнес-правила - декларативный.
+
+В области разработки программного обеспечения бизнес-логикой также называются реализующие ее программные модули и уровни системы, на которых эти модули расположены.
+
+Источники:
+
+* [Что такое бизнес-логика](https://medium.com/%D0%B2%D1%8B-gui-ux-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD%D0%B5%D1%80/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0-f776355c6bfd)
+* [Бизнес-логика](https://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0)
+* [Бизнес-логика (Business logic)](https://wiki.loginom.ru/articles/busines-logic.html)
diff --git a/obshee/defekty-i-oshibki.md b/obshee/defekty-i-oshibki.md
new file mode 100644
index 0000000..4f001c4
--- /dev/null
+++ b/obshee/defekty-i-oshibki.md
@@ -0,0 +1,165 @@
+# Дефекты и ошибки
+
+Прежде всего, стоит разобраться с терминологией. В определениях Error/Mistake/Defect/Bug/Failure/Fault три из них переводятся на русский язык как ошибка. Определения из ISTQB:
+
+* _Просчет (mistake): См. ошибка;_
+* _Помеха (bug): См. дефект;_
+* _Недочет (fault): См. дефект;_
+* _Ошибка (error): Действие человека, которое приводит к неправильному результату;_
+* _Дефект (defect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы;_
+* _Отказ (failure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата._
+
+Неофициальные же источники показывают более широкую картину:
+
+* Ошибка (Error) возникает из-за просчета (Mistake) в написании кода разработчиком;
+* Дефект (Defect) это скрытый недостаток в ПО, возникший из-за ошибки в написании кода;
+* Когда дефект (Defect) обнаруживается тестировщиком, он называется багом (Bug);
+* Если тестировщики упустили дефект и его нашел пользователь, то это сбой (Failure);
+* Если программа в итоге не выполняет свою функцию, то это отказ (Fault).
+
+Так что же такое баг на практике? Когда мы имеем ситуацию “1 требование = 1 тест-кейс”, то вопрос отпадает сам собой - тест-кейс не прошёл, значит требование реализовано не правильно, значит баг. Но обычно вариантов куда больше:
+
+* работало, но вдруг перестало;
+* работает, но неправильно;
+* реализация не соответствует описанию и в задаче в явном виде не зафиксированы корректировки;
+* нужно изменить название кнопки/страницы/раздела, потому что в них есть опечатка или “Отменить отмену” (классика!);
+* опечатки в принципе (легко может иметь разный приоритет в зависимости от целей и задач проекта);
+* после сохранения информация не появляется на странице, даже если в консоли 200 ОК;
+* не все указанные при сохранении поля отображаются на странице, но поля неизменно показываются при редактировании;
+* при нажатии на кнопку “УДАЛИТЬ ВООБЩЕ ВСЕ ДАННЫЕ КЛИЕНТА” нет модального окна с подтверждением Да/Нет, да и сделать это может любой пользователь без авторизации, который нашел ссылку;
+* по переходу по прямой ссылке на услугу не проверяется какой пользователь сейчас авторизован и таким образом можно посмотреть чужие профили или детали услуг, если подобран валидный id;
+* можно cURL’ом заказать услугу другому клиенту или в Elements через DevTools изменить стоимость в корзине (не проворачивайте такие сценарии не на своих рабочих проектах);
+* информация торчит за границами своего блока или “наслаивается” на другой (ж-ж-ж-жуть, но на некоторых проектах этим можно легко пренебречь);
+* страница очень долго открывается, ну о-о-очень долго - секунд 30 на стабильном интернете (взбешенный клиент гарантирован);
+* система делает что-то, что она не должна делать согласно изначальной задумке. Например, закрытие аккаунта не только переводит его в статус “Закрыто”, но и возвращает клиенту все деньги, которые он принес проекту за всё время сотрудничества за уже оказанные услуги (о-о-ой!);
+* неудобно пользоваться. Например, чтобы посмотреть детали услуги клиента, нужно зайти на три вкладки вглубь аккаунта, а смотреть нужно 2-3 раза в день. Или неудобно копировать информацию со страницы, а по рабочим вопросам это нужно делать несколько раз в день - это баг интерфейса и он должен быть исправлен.
+
+При этом часто может возникнуть извечный вопрос “баг или фича?”, когда баг-репорт заводить не нужно. Это фича-реквест, если:
+
+* нужно изменить название кнопки/страницы/раздела, потому что есть ощущение, что оно не отражает действительности;
+* фичу сделали, но после использования видно, что есть простор для существенных улучшений. Например, по услуге не хватает мониторинга или статистических данных по использованию, а за перерасход может взиматься дополнительная плата - клиент точно будет несчастлив в неведении;
+* знаете как улучшить ту или иную часть системы, чтобы было удобней. Например, меню необоснованно занимает 30% ширины экрана, а полезная информация ютится на оставшихся 70%;
+* пользователь регулярно делает рутинные монотонные действия, которые можно автоматизировать. Например, копировать однотипную информацию с 12 страниц пагинации, когда простая выгрузка бы решила проблему;
+* изобретаете велосипед из действующих фич продукта, чтобы добиться желаемого результата;
+* на странице не хватает какой-то информации или возможности её добавить;
+* на странице не хватает фильтров и пагинации, когда информации много и трудно найти нужное или отображение 1000+ элементов существенно сказывается на скорости загрузки страницы;
+* пользователь ведет дополнительную отчетность в блокноте/экселе, когда проблему можно решить выводом ID на странице и несколькими фильтрами.
+
+Хорошо если в команде есть UX/UI дизайнер, а если нет? Тестировщику стоит различать что в дизайне баг, который может привести к печальным последствиям, а что запрос на улучшение, который сделает взаимодействие пользователей с системой более гладким и удобным, но может быть реализован позднее.
+
+**Классификация дефектов**
+
+Дефекты можно классифицировать по-разному. Для организации важно следовать единой схеме классификации и применять ее ко всем проектам. Некоторые дефекты можно отнести к нескольким классам или категориям. Из-за этой проблемы разработчики, тестировщики и сотрудники SQA должны стараться быть максимально последовательными при записи данных о дефектах.
+
+**Классы дефектов**:
+
+* **Дефекты требований и спецификаций** (Requirements and Specifications Defects): Начало жизненного цикла программного обеспечения важно для обеспечения высокого качества разрабатываемого программного обеспечения. Дефекты, введенные на ранних этапах, очень трудно устранить на более поздних этапах. Поскольку многие документы с требованиями написаны с использованием представления на естественном языке, они могут стать
+
+ * Двусмысленными;
+ * Противоречивыми;
+ * Непонятными;
+ * Избыточными;
+ * Неточными.
+
+ Некоторые специфические дефекты требований / спецификаций:
+
+ * Дефекты функционального описания: Общее описание того, что делает продукт и как он должен себя вести (входы / выходы), неверно, двусмысленно и / или неполно;
+ * Дефекты функций: описываются как отличительные характеристики программного компонента или системы. Дефекты функций связаны с отсутствием, неправильным, неполным или ненужным описанием функций;
+ * Дефекты взаимодействия функций: это происходит из-за неправильного описания того, как функции должны взаимодействовать друг с другом;
+ * Дефекты описания интерфейсов: это дефекты, которые возникают в описании взаимодействия целевого программного обеспечения с внешним программным обеспечением, оборудованием и пользователями.
+* **Дефекты дизайна**: Дефекты дизайна возникают когда неправильно спроектированы: Системные компоненты, Взаимодействие между компонентами системы, Взаимодействие между компонентами и внешним программным / аппаратным обеспечением или пользователями. Они включают дефекты в конструкции алгоритмов, управления, логики, элементов данных, описаний интерфейсов модулей и описаний внешнего программного обеспечения / оборудования / пользовательского интерфейса. К дефектам дизайна относятся:
+ * Алгоритмические дефекты и дефекты обработки: это происходит, когда этапы обработки в алгоритме, описанном псевдокодом, неверны;
+ * Дефекты управления, логики и последовательности: Дефекты управления возникают, когда логический поток в псевдокоде неверен;
+ * Дефекты данных: Они связаны с неправильным дизайном структур данных;
+ * Дефекты описания интерфейсов модулей: эти дефекты возникают из-за неправильного или непоследовательного использования типов параметров, неправильного количества параметров или неправильного порядка параметров;
+ * Дефекты функционального описания: к дефектам этой категории относятся неправильные, отсутствующие или неясные элементы дизайна;
+ * Дефекты описания внешних интерфейсов: они возникают из-за неправильных описаний дизайна интерфейсов с компонентами COTS, внешними программными системами, базами данных и аппаратными устройствами.
+* **Дефекты кода**: Дефекты кодирования возникают из-за ошибок при реализации кода. Классы дефектов кодирования аналогичны классам дефектов дизайна. Некоторые дефекты кодирования возникают из-за непонимания конструкций языка программирования и недопонимания с разработчиками.
+ * Алгоритмические дефекты и дефекты обработки:
+ * Непроверенные условия overflow and underflow;
+ * Сравнение несоответствующих типов данных;
+ * Преобразование одного типа данных в другой;
+ * Неправильный порядок арифметических операторов;
+ * Неправильное использование или пропуск круглых скобок;
+ * Потеря точности (Precision loss);
+ * Неправильное использование знаков.
+ * Дефекты управления, логики и последовательности: этот тип дефектов включает неправильное выражение операторов case, неправильное повторение циклов и пропущенные пути;
+ * Типографические дефекты: в основном это синтаксические ошибки, например неправильное написание имени переменной, которые обычно обнаруживаются компилятором, self-reviews, or peer reviews;
+ * Дефекты инициализации: этот тип дефектов возникает, когда операторы инициализации пропущены или неверны. Это может произойти из-за недопонимания или отсутствия связи между программистами или программиста и дизайнера, небрежности или непонимания среды программирования;
+ * Дефекты потока данных: дефекты потока данных возникают, когда код не следует необходимым условиям потока данных;
+ * Дефекты данных: на это указывает неправильная реализация структур данных;
+ * Дефекты интерфейса модуля: возникают из-за использования неправильных или несовместимых типов параметров, неправильного количества параметров или неправильного порядка параметров;
+ * Дефекты документации кода: когда документация по коду не описывает, что программа на самом деле делает, либо является неполной или двусмысленной;
+ * Внешнее оборудование, дефекты программных интерфейсов: эти дефекты возникают из-за проблем, связанных с Системными вызовами, Ссылками на базы данных, Последовательностью ввода / вывода, Использованием памяти, Использованием ресурсов, Обработкой прерываний и исключений, Обменом данными с оборудованием, Протоколами, Форматами, Интерфейсами с файлами сборки, Временными последовательностями.
+* **Дефекты тестирования**: Планы тестирования, тестовые наборы, средства тестирования и процедуры тестирования также могут содержать дефекты. Эти дефекты называются дефектами тестирования. Дефекты в планах тестирования лучше всего обнаруживать с помощью методов review.
+ * Дефекты тестовой обвязки: Для тестирования программного обеспечения на уровне модулей и интеграции необходимо разработать вспомогательный код. Это называется Test Harness или scaffolding code. Test Harness должен быть тщательно спроектирован, реализован и протестирован, поскольку это рабочий продукт, и этот код можно повторно использовать при разработке новых версий программного обеспечения;
+ * Дизайн тестового случая и дефекты процедуры тестирования: сюда входят неправильные, неполные, отсутствующие, несоответствующие тестовые примеры и процедуры тестирования.
+
+[В англоязычной Wikipedia описано плюс-минус то же самое](https://en.wikipedia.org/wiki/Software\_bug#:\~:text=or%20undocumented%20feature.-,Types,-%5Bedit%5D).
+
+**Жизненный цикл дефекта** (Defect/Bug Life Cycle)
+
+Жизненный цикл дефекта - это представление различных состояний дефекта, в которых он пребывает от начального до конечного этапа своего существования. Он может варьироваться от компании к компании и настраиваться под процессы конкретного проекта.
+
+
+
+**Статусы дефекта**:
+
+* **Новый** (New): когда новый дефект регистрируется и публикуется впервые;
+* **Назначен** (Assigned): после публикации бага тестировщиком руководитель тестировщика утверждает ошибку и передает ее команде разработчиков;
+* **Открыт** (Open): разработчик начинает анализ и работает над исправлением бага;
+* **Исправлен** (Fixed): разработчик внес необходимое изменение в код и проверил его;
+* **Ожидает повторного тестирования** (Pending retest): как только дефект будет исправлен, разработчик предоставляет тестировщику конкретный код для повторного тестирования кода. Поскольку тестирование программного обеспечения остается незавершенным со стороны тестировщиков, ему присваивается статус «ожидает повторного тестирования»;
+* **Повторное тестирование** (Retest): на этом этапе тестировщик выполняет повторное тестирование кода, чтобы проверить, исправлен ли дефект разработчиком;
+* **Проверен** (Verified): тестировщик повторно тестирует баг после его исправления разработчиком. Если баг исправлен, то присваивается статус «проверено»;
+* **Переоткрыт** (Reopen): если баг сохраняется даже после того, как разработчик исправил баг, тестировщик меняет статус на «повторно открыт». И снова баг проходит жизненный цикл.
+* **Закрыт** (Closed): если баг больше не существует, тестировщик присваивает статус «Закрыто».
+* **Дубль** (Duplicate): если дефект повторяется дважды или дефект соответствует той же концепции ошибки, статус изменяется на «дублировать».
+* **Отклонен** (Rejected): если разработчик считает, что дефект не является таковым, он меняет статус на «отклонен»;
+* **Отложен** (Deferred): если текущий баг не является приоритетным и ожидается, что он будет исправлен в следующем выпуске, таким багам присваивается статус «Отложено»;
+* **Не является багом** (Not a bug): если это не влияет на функциональность приложения, то багу присваивается статус «Не является багом».
+
+
+
+**Утечка дефектов и релиз бага (Bug Leakage & Bug Release)**
+
+Утечка бага (Bug Leakage): возникает когда пропускается баг в билде, который вышел в Production. Если баг был обнаружен конечным пользователем или заказчиком, мы называем это утечкой ошибок.
+
+Выпуск бага (Bug release): выпуск программного обеспечения в Production с некоторыми известными багами. Эти известные баги следует включить в примечания к выпуску (release notes). Другой вариант - передача программного обеспечения группе тестирования с некоторыми известными багами, серьезность и приоритет которых невысоки. Эти ошибки можно исправить перед выпуском в Production.
+
+**Основное отличие отладки от тестирования (**[**Debugging**](https://www.youtube.com/watch?v=URH45Vx08n4) **Vs. Testing)**
+
+После того, как разработчик получил баг-репорт, он приступает к исправлению бага. Но, прежде чем ошибку исправить, нужно ее воспроизвести, понять, как она происходит и где ее найти в коде. Дебаг, буквально “de”+”bug” - это и есть процесс поиска и устранения ошибок в коде. Специальная debug-версия билда приложения может иметь расширенный вывод для более информативных логов или любые другие модификации для упрощения понимания проблемы. Тактика отладки может включать интерактивную отладку, анализ потока управления, модульное тестирование, интеграционное тестирование, анализ логов, мониторинг на уровне приложения или системы, дампы памяти и профилирование. Многие языки программирования и инструменты разработки программного обеспечения также предлагают программы для помощи в отладке, известные как отладчики/дебаггеры.
+
+**Маскировка дефектов (Defect masking)**
+
+_Маскирование дефектов (defect masking): Случай, когда один дефект препятствует нахождению другого. (IEEE 610)_
+
+**Скрытый дефект (Latent defect)**
+
+Дефект, который является существующим дефектом в системе, но еще не вызывал сбоев, поскольку подходящий набор входных данных для его проявления не был введен или его проявлению мешает другой дефект (Defect masking).
+
+**Сортировка дефектов (Bug triage)**
+
+Это формальный процесс определения серьезности и приоритета дефектов в зависимости от их severity, риска, повторяемости и т. д. во время Defect Triage Meeting. Такая встреча полезна в условиях ограниченных ресурсов, когда нужно разобраться с множеством ошибок и тем, какие из них приоритетные.
+
+Понятие сортировки пришло из медицины, где это процесс быстрого обследования пациентов, доставленных в больницу, чтобы решить, какие из них наиболее серьезно больны и нуждаются в лечении в первую очередь. В тестировании мы используем ту же концепцию к ошибкам, обнаруженным на этапе тестирования.
+
+**Подсев недочетов (fault seeding)**
+
+_Процесс намеренного внесения дефектов в дополнение к тем, что уже существуют в компоненте или в системе, для целей отслеживания уровня обнаружения и устранения, а также оценивания количества оставшихся в системе дефектов. Подсев недочетов обычно является частью процесса тестирования разработки и может применяться на любом уровне тестирования (компонентном, интеграционном или системном). (IEEE 610)_
+
+Источники:
+
+* [Баг или фича? Вот в чём вопрос!](https://telegra.ph/Bag-ili-ficha-Vot-v-chyom-vopros-12-25)
+* [Defect Classes, the Defect Repository, and Test Design](https://worldofcse.wordpress.com/2014/07/20/defect-classes-the-defect-repository-and-test-design/)
+* [Defect/Bug Life Cycle in Software Testing](https://www.guru99.com/defect-life-cycle.html)
+* [Real Time Software QA Interview Questions And Answers](https://www.softwaretestingmaterial.com/software-qa-interview-questions-answers/)
+* [Top 150 Software Testing Interview Questions and Answers for Freshers and Experienced](https://www.guru99.com/software-testing-interview-questions.html)
+* [Defect Triage Process in Software Testing](https://www.softwaretestingmaterial.com/defect-triage-meeting/)
+
+Доп. материал:
+
+* [Showstopper Bug](https://www.techopedia.com/definition/22054/showstopper-bug)
+* [Жизненный цикл (Workflow) задач](http://okiseleva.blogspot.com/2018/08/workflow.html)
+* [Курс Тестирование ПО. Занятие 9. Классификация дефектов](https://www.youtube.com/watch?v=SJwXK-2rw4M)
diff --git a/obshee/ekonomika-testirovaniya-stoimost-kachestva-cost-of-quality.md b/obshee/ekonomika-testirovaniya-stoimost-kachestva-cost-of-quality.md
new file mode 100644
index 0000000..ae56e34
--- /dev/null
+++ b/obshee/ekonomika-testirovaniya-stoimost-kachestva-cost-of-quality.md
@@ -0,0 +1,231 @@
+# Экономика тестирования/стоимость качества (Cost of quality)
+
+_Стоимость качества (cost of quality): Общая стоимость затрат на задачи обеспечения и проблемы качества, часто разделяемая на стоимость предотвращения, стоимость оценки, стоимость внутренних отказов и стоимость внешних отказов. (ISTQB)_
+
+Стоимость качества разработки программного обеспечения - это метрика, которая может помочь превратить программное обеспечение в прибыльный инструмент для компаний. Компании смотрят на ROI, т. е. на прибыль организации от инвестиций в разработку программного обеспечения.
+
+Качество достигается за счет цены, и эта стоимость называется COQ или Cost of Quality.
+
+Чтобы понять, как обстоят дела с тестированием на проекте, нужно проанализировать его эффективность с точки зрения качества создаваемого продукта и процессов. Тут можно рассчитывать плотность дефектов, разрывы, утечки, эффективность тест-кейсов, RC, FDP, DDP, PTC, MTTD, TDE и десятки других метрик тестирования. Но, чтобы определить рентабельность такого тестирования, необходимо считать деньги. Деньги и их возрастающий поток - основная цель заказчика в большинстве случаев разработки ПО.
+
+Чтобы правильно принимать управленческие решения, тест-менеджеру необходимо в полной мере ориентироваться в себестоимости активностей по тестированию, видеть зоны развития и пути оптимизации процессов. Заказчику также важно понимать, за что он платит и почему, где он теряет, а где зарабатывает. Один в поле не воин, и задача так называемого архитектора постараться заставить пчел реально осознать, сколько денег они приносят заказчику, сколько помогли сэкономить. Сэкономленные деньги не обязательно, но могут формировать фонд для потенциального увеличения оплаты труда тех же пчел.
+
+**Цена и ценность**
+
+Любое качество имеет свою цену. Формально стоимость качества представляют так:
+
+
+
+* COQ = Cost of control + Cost of failure of control или
+* COQ = Cost of Good Software Quality + Cost of Poor Software Quality;
+* Стоимость хорошего качества (COGQ) = Затраты на предотвращение + Затраты на обнаружение;
+* Стоимость низкого качества (COPQ) = Внутренние затраты на отказ + Внешние затраты на отказ.
+
+Если же рассматривать стомость качества в глобальном смысле, то она складывается и из более практических аспектов:
+
+* Контекст проекта:
+ 1. Размер, объем и нагрузка. Тут к гадалке не ходи, чем масштабнее продукт, чем больше у него пользовательская аудитория и сложнее начинка, тем больше времени/ресурсов необходимо на его разработку, а значит и на тестирование и поддержку.
+ 2. Сфера/область. Разработка и тестирование простого веб-сайта и медицинского IT-продукта требуют разного количества времени и ресурсов. Последний продукт обладает более сложным функционалом, поэтому для него, как правило, нужно несколько видов тестирования, больше времени и хороший уровень специалистов.
+ 3. Качество разработки. Качество кода, его валидность, масштабируемость - все это влияет на стабильность функциональности, а значит и на то, сколько ресурсов понадобится на обеспечение качества и поддержку.
+ 4. Наличие тестовой документации. Тестовая документация - это такой плацдарм для тестирования. Если она уже есть, то это сократит сроки на погружение и работу. Если нет - это увеличит сроки и бюджет, потому что придется потратить на нее время.
+* Цифры и вводные проекта:
+ 1. Сколько людей пользуются сервисом;
+ 2. Сколько людей жалуются на сервис;
+ 3. Сколько проблем у нас появляется после релиза;
+ 4. Происходит ли рост/падение бизнеса/денег после релиза;
+ 5. Какие сроки и успеваем ли мы со сроками релиза;
+ 6. Насколько довольны ТОПы бизнеса в работе IT-отдела (правда, это не измерить цифрой, но показатель тоже важный).
+* Динамика:
+ 1. Насколько динамичен продукт - частота обновлений и релизов.
+
+Общая стоимость тестирования достаточно велика, но стоит лишь оценить стоимость плохого тестирования, как она уже кажется вполне приемлемой. Уоррен Баффет как-то сказал, что цена - это то, что вы платите, а ценность - то, что получаете. И не всегда они совпадают. Качество ещё не означает ценность. Попробуйте сегодня продать очень качественную печатную машинку либо убедить заказчика, что для него ценнее будет зарелизить фичу не послезавтра, а через год, ведь за это время вы ещё лучше всё протестите и качество будет выше. Не получится. Дорога ложка к обеду, и time to market никто не отменял.
+
+Задача в том, чтобы достичь оптимального соотношение цена/качество для заказчика. Почему оптимального? Потому что по мере увеличения затрат на поиск дефектов и их устранения стоимость поломки будет снижаться до тех пор, пока не будет достигнута оптимальная точка, после которой дальнейшее увеличение активностей по тестированию станет экономически нецелесообразным.
+
+
+
+**Как происходит оценка проекта**
+
+Работа считается в часах, которые рассчитываются по критериям, исходя из контекста и вводных проекта:
+
+* количество браузеров/устройств для проверки;
+* сложность фич/верстки;
+* документация;
+* сроки;
+* количество человек, которые будут участвовать в проекте и т.д.
+
+Назовем такой подход, в основе которого лежит анализ ценности и экономической целесообразности тестирования, value based, или value driven testing, и рассмотрим его на примере.
+
+QA team состоит из трех Manual QA. Это не Fixed Price проект, и ценообразование тут а-ля Time\&Materials. У нас 826 мануальных тестов, нехватка времени и целый вагон проблем с качеством. И стоит задача улучшить и оптимизировать тестовый процесс.
+
+Начнем с масштабной ревизии костов. Не прибегая ни к ПСБУ, ни к МСФО, расходы можно поделить на: капитальные, или CAPEX (покупка серверов, лицензий для софта, виртуалки и так далее), операционные (расходы на прогон нагрузочных и автотестов, работу серверов, репортинг и настройку окружения), прямые (зарплата, расходы на обучение) и косвенные (дебаггинг, повторное тестирование, обновление и исправление тест-кейсов). Для себя также фиксируем постоянные и переменные расходы. Вовсе не обязательно следовать боэмовской COCOMO, всё намного прозаичнее.
+
+Первое, с чего стоит начать, - определить, сколько времени уходит на ту или иную тестовую активность в часах, а затем проанализировать, как можно сократить это время. Тут и снижение трудоемкости, относительная экономия труда и борьба с неявным абсентеизмом QA-команды.
+
+**\_W = I\*T, где \_**
+
+\_W - трудозатраты, I - постоянная интенсивность труда или наш перформанс, а T - время работы QA. \_
+
+Краткий стиль оформления, чёткая приоритезация, уменьшение повторений в шагах и прочая оптимизация тест-кейсов помогла сократить их количество с 826 до 611, что, в свою очередь, снизило затраты времени на их прохождение в три раза. Эта активность и выработанные правила игры для всей команды экономили время на проектирование и выполнение тестов на будущее. Пример оптимизации теста:
+
+
+
+Аналогичные меры коснулись и активностей по написанию документации (наполнение Wiki-проекта), репортинга и внутренних коммуникаций. Но несмотря на то, что затраты труда (времени) снижались, они достигли своего предела (см. график). Скоуп регрессии увеличивался, и хотя освободившееся часы давали некий запас прочности, нужно было что-то ещё.
+
+
+
+**Экономия от масштаба**
+
+Left shit testing - основа теории тестирования. На мой взгляд, это чем-то похоже на концепцию стоимости денег во времени. Один доллар сегодня дороже, чем будет стоить завтра, так как его можно инвестировать уже сегодня. А найденный баг сегодня также ценнее, чем будет завтра, поскольку его можно раньше исправить.
+
+Преимущество достигается за счет скорости и снижения простоев - чем быстрее мы получаем деньги и находим дефекты, тем лучше. Увеличение количества проверок при одновременном снижении себестоимости одной проверки неминуемо приводит к экономии на масштабе. Да здравствует её величество автоматизация! Рассмотрим этот процесс через призму экономики:
+
+_**c = (TFC/Q) + AVC, где**_
+
+_с - себестоимость выполнения одного теста, TFC - общая величина постоянных издержек, Q - количество запускаемых тестов, AVC - средние переменные издержки._
+
+Следовательно, увеличение количества проверок за единицу времени и снижение средних переменных расходов на тестирование - это два ключа в ваших руках к снижению себестоимости нахождения одного дефекта.
+
+
+
+Добавление QA Auto в команду увеличило постоянные расходы QA Team, однако в перспективе обещало компенсировать это ростом производительности.
+
+Точка безубыточности автоматизации была достигнута не сразу, а лишь когда значительная часть тестов уже ранилась автоматически. Расчет критического объема тестов для автоматизации можно вычислить, вновь применив экономический анализ:
+
+_Критический объем = Постоянные затраты в целом на автоматизацию / (себестоимость выполнения одного мануального теста - переменные затраты на выполнение одного автотеста)._
+
+Эффект операционного левериджа начал снижаться, как и средние переменные затраты на тестирование, а у QA Manual стало больше времени на experience-based тестирование. Это позволило повысить оборачиваемость регрессионных ранов и значительно увеличить скоуп спринтов.
+
+Такой положительный тренд говорил о том, что целесообразно увеличить темпы прироста автоматизации, но добавление еще одной единицы QA Auto не вытягивало ROI из-за связанного с этим увеличения постоянных прямых расходов (оплаты труда). Решение было простым и быстрым - взять QA Auto Trainee с испытательным сроком три месяца. При отсутствии дополнительных прямых расходов (оплаты труда второго QA Auto) затраты на онбординг незначительно снизили производительность первого QA Auto, но не изменили общую тенденцию к росту.
+
+**Стадо бизонов**
+
+Стадо бизонов бежит со скоростью самого медленного бизона, и если ваши автоматизаторы работают быстро, но вынуждены ждать мануальных тестов от QA Manual, то вся их скорость теряет смысл. Это bottleneck проекта, и его нужно срочно исправлять.
+
+Если увеличить контроль за написанием мануальных тестов и привести формат их написания к единому стандарту, значительно уменьшиться время QA Auto на их разбор и конвертацию. Конечно, не нужно бросать все силы на срочную подготовку бессмысленных мануальных тестов для автоматизаторов для галочки. Тесты должны быть надежными сетями для ловли багов, а их поток должен лишь с небольшим запасом покрывать производительность Automation Team.
+
+В противном случае излишнее нагромождение тестов будет бессмысленным, а потери времени на их «простой» экономически необоснованными. Это касается всего процесса тестирования от планирования до составления summary-репорта. Никаких ботлнеков.
+
+Выстраивать конвейер непросто, но хорошо налаженная производственная линия гораздо ценнее сотни отдельных станков. Если хорошенько покопаться и проанализировать, можно убрать множество лишних активностей. И очень важно это сделать до автоматизации процессов. Иначе внедрение автоматизации лишь увеличит производительность такого сизифова труда.
+
+Недостаточно делать все, что от тебя зависит. Как говорил Деминг, сначала нужно знать, что делать, а тогда уже делать всё, что от тебя зависит, улучшая процессы. А из всех моделей по улучшению мне больше всего нравится TMMi, пятый уровень которой, как говориться, имеет много общего с идеальным мужчиной: все слышали, но мало кто видел.
+
+Но стремится к этому нужно, и если мы намерены нести ценность заказчику, то самое время определиться, где мы сейчас и куда идём. Ведь обычно, как пела группа «Кино», «Все говорят, что мы в-месте, все говорят, но немногие знают, в каком». Внедрение модели по улучшению тестирования - тоже желательная часть вашего value driven testing.
+
+**Риск или холодный расчет**
+
+Бывает, что, несмотря на найденные баги, принимается решение релизить версию. Такие новости часто демотивируют тестировщиков. Начинаются рассуждения по типу «ну, сами виноваты, что хотят, пусть и делают», «как можно с этим релизить», «смысл было проверять» и так далее. Есть и обратная ситуация, когда тестили-тестили, а багов не нашли особо. Все знают, что ПО, как и человек, не бывает абсолютно здоровым, а бывает недообследованным, поэтому и вопросы возникают «почему мало багов», «как именно проверяли». Но если посмотреть на эти ситуации с точки зрения ценности, то всё станет на места.
+
+Рассмотрим пример. Вы собираетесь релизить фичу, которая принесёт условно $75K. С вероятностью в 40% в этой версии может содержаться критический баг, и если этот дефект просочится к пользователям, то связанные с этим расходы составят $150K. Можно не рисковать - ничего не релизить, но и профита тогда не будет.
+
+Если релизим сразу, то с учетом вероятности появления критического бага ожидаемая чистая выгода составит: $75K - ($150K \* 40%) = $15K
+
+| **Решение** | **Нет бага** | **Есть баг** |
+| ----------- | ------------ | ------------ |
+| Релизим | 75 | -75 |
+| Не релизим | 0 | 0 |
+
+Можно потратить деньги на тестирование, пускай тоже $15K. Тестирование может найти баг, а может и не найти, пускай 50/50, или 40% делим на 2. В таком случае вероятность того, что баг попадёт в релиз, снизится с 40% до 20%. Теперь давайте считать деньги:
+
+| **Решение** | **Нет бага** | **Есть баг** | |
+| ------------------------------------------------- | --------------- | ------------ | ---- |
+| **Не найден нами** | **Найден нами** | | |
+| Релизим без тестирования | 75k | -75k | -75k |
+| Не релизим | 0 | 0 | 0 |
+| Тестируем и релизим, если только дефект исправлен | -15k | -15k | 60k |
+| Тестируем и релизим в любом случае | 60k | -90k | 60k |
+
+Перемножив вероятности наступления событий и стоимости их последствий, определим, какое решение будет более выгодным.
+
+* Не релизим вообще: $0K
+* Релизим сразу без тестирования: $15K (это мы уже определили выше)
+* Тестируем и релизим, если только дефект исправлен: −15K \* 60% + (-15K \* 20%) + 60K \* 20% = $0K
+* Тестируем и релизим в любом случае: 60K \* 60% + (-90K \* 20%) + 60K \* 20%= 30K
+
+Примечательно, что расходы на фикс не брались во внимание, иначе третья стратегия была бы еще менее привлекательной. Это ни в коем случае не означает, что не нужно фиксить баги, однако факт: наиболее выгодной стратегией оказалась четвертая - тестить продукт и релизить в любом случае. В это сложно поверить, но для конкретного примера это так. Даже если прошедшие тесты не нашли багов (при условии, что они способны были), то они действительно приносят реальную экономическую ценность, снижая вероятность утечки ошибок.
+
+Как следствие, намного важнее величина тестового покрытия (вероятности обнаружения дефектов), чем фактическое количество обнаруженных багов. Это как морской бой. Выигрывает тот, кто добьется большего покрытия поля соперника первым, это важнее, чем просто подбитые корабли.
+
+Тестовые активности будут иметь еще большую ценность, если применять любую из моделей Risk-Based Testing, будь это FMEA, PRA, PRISMA. Тестирование, основанное на рисках, грамотно приоритезирует ваши тесты, научит всю команду и заказчика правильно их искать и оценивать, а в качестве результата обезопасит будущие релизы. Подверженность риску можно найти, перемножив вероятность использования функционала на вероятность фейла и, собственно, цену его последствий. Имплементация такого подхода потребует затрат, однако качество продукта и спокойный сон того стоят.
+
+Теперь, когда риски известны, оценены и нашли выражение в соответствующих приоритетах тестов, наиболее рисковые фичи будут проверены детальнее и в первую очередь.
+
+**Леверидж рисков**
+
+Использовать результаты финансового анализа при принятии управленческих решений я рекомендую в разных ситуациях.
+
+Рассмотрим пример. На вашем проекте существует вероятность потери данных на тестовом сервере 20%. Если это произойдет, стоимость такой потери (сроки + стоимость восстановления данных) составит $20K.
+
+Оценим риск: 20% \* $20K = $4K
+
+Рисков можно избегать, их можно принимать, снижать и передавать. Но что из этого выбрать? Есть вариант внедрить механизм бэкапа и уменьшить риск до 5%. Влияние будет прежним, так как в случае сбоя на сервере мы также потеряем, а стоимость работ по бэкапу составит $2K. Итак:
+
+Вероятность - 5% (после предпринятых мер)
+
+Потери - $20K (такие же)
+
+Оценка риска после 5% \* $20K = $1K
+
+Расходы на уменьшение риска - $2K
+
+_**Risk Reduction Leverage = (Risk Estimation (до) - Risk Estimation (после))/Risk Reduction Cost**_
+
+Рассчитаем леверидж уменьшения риска: ($4K - $1K) / $2K = 1.5
+
+Полученная величина (>1) говорит о том, что такие меры целесообразны.
+
+Можно рассмотреть вариант передачи риска, использовав услуги аутсорса. Если выгода второго варианта окажется большей, но команда остановится всё-таки на самостоятельном внедрении механизма бэкапа, то она будет нести альтернативные издержки или издержки упущенных возможностей.
+
+Похожие сравнения необходимо проводить и с ROI, выбирая лучший вариант.
+
+_**ROI = ((Savings - Costs)/Costs) \* 100%**_
+
+При расчете ROI есть масса нюансов в зависимости от проекта и вида тестирования. Основная сложность - правильно рассчитать получаемую выгоду. Без анализа затрат и себестоимости тестовых активностей сделать это корректно будет проблематично. Снижение затрат по автоматизации происходит в основном за счет параллельного запуска тестов, переиспользования кода, снижения затрат на анализ результатов, автоматизации создания отчётов о тестировании и настройки тестового окружения.
+
+**Проблема выбора**
+
+Допустим, у вас два проекта или две отдельные команды тестировщиков A и Z.
+
+Кому направить средства на развитие и как не ошибиться в расчетах? Ставка дисконтирования проекта A 10%, а проекта Z 12% (из-за более продолжительного срока его реализации).
+
+| **Показатели** | **Проекты по тестированию** | |
+| ------------------------------------------- | --------------------------- | ---- |
+| **A** | **Z** | |
+| Объем планируемых вложений | 70K | 68K |
+| Количество периодов эксплуатации | 2 | 4 |
+| Сумма планируемого чистого денежного потока | 100k | 110k |
+| в том числе: | | |
+| 1-й период | 60k | 20k |
+| 2-й период | 40k | 30k |
+| 3-й период | - | 30k |
+| 4-й период | - | 30k |
+
+При прочих равных условиях вроде как выгоднее предоставить бюджет развития проекту Z, поскольку он требует меньших вложений и лучше окупается.
+
+Но доллар сегодня дороже, чем будет стоить завтра, поэтому следует определить чистый приведенный доход по каждому проекту:
+
+
+
+_Тут Fn - объём денежного потока за период n, а r - ставка дисконтирования._
+
+Рассчитав итоговую настоящую стоимость чистых денежных потоков за минусом запланированных вложений, получим:
+
+NPV (A) = 54545 + 33057 - 70000 = 17603
+
+NPV (Z) = 17860 + 23910 + 21360 + 19080 - 68000 = 14210
+
+Еще до расчета внутренней нормы доходности (IRR) очевидно, что более выгодно предоставить бюджет развития тестировщикам проекта A.
+
+Все эти примеры не столько о финансах, как о мировоззрении в тестировании, о понимании смысла своей работы. Какую бы тестовую активность команда не начинала, неплохо бы думать о том, какую ценность она имеет для заказчика и конечных пользователей. Такой подход одинаково полезен всем как директору по тестированию, так и вновь испеченному джуну. Порой стереотипы о том, что созидателем является только разработчик, мешают тестировщику также любить и заботится о продукте как о своём детище. Это как обида злой феи, которую не пригласили на крестины принцессы. Вместо заботы она злорадно ожидает, когда малышка уколется веретеном, а потом скажет: «Я же говорила, тут баг на баге». Но мы не разрушаем, а создаём. Быть лишь хорошим исполнителем, регулярно осваивать бюджет и делать ровно столько, сколько сказали, можно, но и ценность этого соответствующая. Соответствовать ожиданиям - ещё не предвосхищать их.
+
+Источники:
+
+* [Что нужно знать о Value Driven Testing. Анализируем ценность и экономическую целесообразность тестирования](https://dou.ua/lenta/columns/value-driven-testing/)
+* [А чо так дорого: сколько стоит качество IT-продукта](https://vc.ru/life/251392-a-cho-tak-dorogo-skolko-stoit-kachestvo-it-produkta)
+
+Доп. материал:
+
+* [Экономика тестирования](https://habr.com/ru/company/luxoft/blog/546228/)
+* [Value Driven Testing](https://www.researchgate.net/publication/232655008\_Value\_Driven\_Testing)
+* [Leadership in test: how much testing is enough?](https://theqalead.com/topics/how-much-testing-is-enough/)
+* [What Is Cost Of Quality (COQ): Cost Of Good And Poor Quality](https://www.softwaretestinghelp.com/coq-cost-of-quality-tutorial/)
diff --git a/obshee/evristiki-i-mnemoniki.md b/obshee/evristiki-i-mnemoniki.md
new file mode 100644
index 0000000..f7e7166
--- /dev/null
+++ b/obshee/evristiki-i-mnemoniki.md
@@ -0,0 +1,84 @@
+# Эвристики и мнемоники
+
+**Эвристики** - это быстрые, недорогие способы решения проблемы или принятия решения. В мире тестирования ПО мы можем использовать эвристики как выведенные опытным путём подсказки для принятия решений и решения проблем в ходе тестирования. Они могут быть особенно полезными для генерации предположений, если мы не уверены, как начать тестирование, или исчерпали идеи, что делать дальше.
+
+**Мнемоника** - это тип эвристики, набор правил и приемов, которые помогают эффективно запоминать необходимые сведения (информацию), обычно это слово-аббревиатура или фраза. Например, все помнят детскую мнемонику “каждый охотник желает знать где сидит фазан”, в которой по первым буквам каждого слова можно вспомнить порядок цветов радуги.
+
+Множество известных тест-эвристик использует мнемоники и широко распространено заблуждение, что у эвристик должна быть мнемоника, или что это одно и то же. Это не так. Эвристики не требуют мнемоник, они просто создаются таким образом, чтобы их было легче запомнить.
+
+Эвристики и мнемоники могут быть придуманы, модифицированы и скрещены как удобно автору для своих нужд. Вот наиболее известные:
+
+* **I SLICED UP FUN**: Для тестирования мобильных приложений;
+* **COP FLUNG GUN**: Еще одна;
+* **MOBILE APP TESTING**: И еще одна;
+* **SPIES**: Для тестирования локализации;
+* **PAOLO**: Тестирование мобильных приложений и смены ориентации экрана;
+* **GO DaRE=M**: Для составления тест-плана;
+* **PAPAS BE @ SFO**: Мнемоника для API-тестов функционала;
+* **DEED HELP GC**: Еще одна мнемоника по API-тестам;
+* **DVLA PC**: Для поддержки API-тестов;
+* **ICE OVER MAD!**: Мнемоника по тестированию API;
+* **INVEST**: Атрибуты хорошей юзер-стори;
+* **CIRCUS MATTA**: Для ревью пользовательских историй;
+* **CAN I USE THIS**: Для тестирования Usability;
+* **SAQSII meeting**: Для улучшения эффективности любого собрания;
+* **SFPDO & SFDIPOT**: Для знакомства с продуктом, новых тест-идей и т.п.;
+* **RCRCRC**: Для регрессионного тестирования;
+* **CRUSSPIC STMPL**: Эвристика качественных характеристик системы;
+* **FEW HICCUPS**: Тестовые оракулы;
+* **RIMGEA**: Для описания багов;
+* **MOCHA**: Описывает стиль собеседований для найма тестировщиков
+* **HEENA**: Для тестирования сложных продуктов;
+* **SCAMPER**: Для того, чтобы задать вопросы по продукту, которые принесут креативные идеи и кейсы;
+* **DUFFSSCRA**: Для техник тестирования;
+* **MCOASTER**: Для составления баг-репортов;
+* **FAILURE**: Для составления грамотных сообщений об ошибке;
+* **W5HE (WWWWWH/KE)**: Для анализа требований;
+* **PROOF**: Для написания тестового отчета после сессионного тестирования;
+* **GRATEDD SCRIPTS & B GRADED SCRIPTTS**: Для тестовой стратегии;
+* **CIDTESTD**: Для высокоуровневого планирования процесса тестирования;
+* **MAC RUSS**: Для приемочного тестирования;
+* **SACKED SCOWS**: Для обучения;
+* **MR.Q COMP GRABC R\&R**: Для проведения исследовательского тестирования;
+* **FCC CUTS VIDS**: Эвристика тестовых туров;
+* **SLIME**: Эвристика приоритетов для тестирования;
+* **CCD IS EARI**: Основные принципы нагрузочного тестирования;
+* **IVECTRAS**: Классификация нагрузочных тестов;
+* **FIBLOTS**: Модель нагрузки для нагрузочного тестирования;
+* **RSTLLL**: Эвристика тестирования сообщений, отправляемых приложением;
+* **MUTII**: Эвристика для тестирования;
+
+Расшифровка, больше вариантов и дополнительные ссылки в первом источнике.
+
+**Эвристики окончания тестирования** (когда пора прекратить тестировать продукт):
+
+1. **Эвристика «Время вышло!»**. Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время. Получили ли мы информацию, которую нам требуется знать о продукте? Не слишком ли высок риск прекращения тестирования? Не был ли срок искусственным, произвольным? Будет ли выполняться дополнительная разработка, которая потребует дополнительного тестирования?
+2. **Эвристика пиньяты (The Piñata Heuristic)**. Мы прекращаем ломать программу, когда начинают выпадать конфеты - мы останавливаем тестирование, когда видим первую достаточно серьезную проблему. Не застряло ли в ноге пиньяты еще несколько конфет? Является ли первая серьезная проблема самой важной? Единственной, о которой стоит беспокоиться? Не найдем ли мы другие интересные проблемы, если продолжим тестирование? Что если наше ощущение «серьезности» ошибочно и проблема не столь грандиозна?
+3. **Эвристика «мертвой лошади»** (The Dead Horse Heuristic). В программе слишком много ошибок, так что продолжение тестирования не имеет смысла. Мы знаем, что все изменится настолько, что сведет на нет результаты текущего тестирования. Здесь мы предполагаем, что уже найдено много интересного и важного. Если мы сейчас остановимся, не пропустим ли мы что-то еще более важное или более интересное?
+4. **Эвристика «Задание выполнено»** (The Mission Accomplished Heuristic). Мы останавливаем тестирование, когда найдены ответы на все поставленные вопросы. В процессе нашего тестирования могут возникнуть новые вопросы. Это приводит нас к эвристике Рамсфелда (Rumsfeld Heuristic): «Есть то, про что мы знаем, что мы это не знаем, и есть то, про что мы не знаем, что мы этого не знаем». Достаточно ли неизвестных переместило наше тестирование в область известного? Обнаружило ли наше тестирование новые неизвестные? И сложный для разбора, но важный вопрос: удовлетворены ли мы тем, что мы переместили достаточно неизвестных неизвестных в область известного или по крайней мере сделали их известными неизвестными.
+5. **Эвристика «Отмена задания»** (The Mission Revoked Heuristic). Наш клиент сказал нам: «пожалуйста, прекратите тестирование». Это может произойти по причине перерасхода бюджета, или вследствие отмены проекта, и по любой другой причине. Какова бы ни была причина, нам поручили остановить тестирование. (На самом деле эвристика «Время вышло!» может быть частным случаем более общей «Отмены задания», в том случае, если предпочтительнее, чтобы не мы сами, а заказчик принял решение о том, что время вышло.) В достаточной ли степени наш клиент осознает ценность продолжения тестирования или риски прекращения? Если мы не согласны с клиентом, то в достаточной ли мере мы осознаем бизнес-причины приостановки тестирования?
+6. **Эвристика «Я зашел в тупик!»** (The I Feel Stuck! Heuristic). По какой бы то ни было причине мы останавливаемся, поскольку обнаруживаем некое препятствие. У нас нет информации, которая нам требуется (например, многие люди заявляют, что не могут тестировать без достаточного количества спецификаций). Имеется блокирующая ошибка, и таким образом мы не можем перейти в ту область продукта, которую необходимо протестировать, у нас нет необходимого оборудования или инструментария, у команды нет квалификации, требуемой для выполнения некоторых специальных тестов. Существует масса способов выйти из тупика. Может быть, нам нужна помощь, а может быть нам просто надо сделать перерыв (смотрите ниже). Может быть, продолжение тестирования позволит нам получить требуемые знания. Может быть, вся цель тестирования и заключается в исследовании продукта и получении недостающей информации. Возможно, имеется путь, позволяющий обойти блокирующую ошибку; возможно инструменты и оборудование имеются, но мы просто не знаем о них или никогда не задавали правильных вопросов тем, кому надо; возможно имеются доступные для нас эксперты - в команде тестирования, среди программистов или на стороне бизнеса - и мы этого просто не знаем. Есть разница между ощущением тупика и нахождением в тупике.
+7. **Эвристика «освежающей паузы»** (The Pause That Refreshes Heuristic). Вместо прекращения тестирования мы приостанавливаем его на некоторое время. Мы можем остановить тестирование и сделать перерыв, когда мы устали, когда нам стало скучно или пропало вдохновение. Мы можем сделать паузу на то, чтобы выполнить некоторые исследования, разработать планы, поразмыслить над тем, что мы делали в прошлом и понять, что делать дальше. Идея заключается в том, что нам требуется определенный перерыв, после которого мы сможем вернуться к продукту со свежим взглядом или свежими мыслями. Также есть и другой вид паузы: мы можем остановить тестирование какой-либо функции, поскольку в настоящий момент другая имеет более высокий приоритет. Конечно, мы можем чувствовать себя уставшими, нам может быть скучно, но не нужно ли проявить упорство и продолжить двигаться вперед? Не получится ли изучить требуемое в процессе работы с программой, вместо того, чтобы делать это отдельно? Не найдется ли тот критичный бит информации, которого нам не хватает, благодаря лишь еще одному тесту? Является ли функция с «более высоким приоритетом» действительно более приоритетной? Готова ли она к тестированию? Не протестировали ли мы ее и так уже достаточно?
+8. **Эвристика «Отсутствие продвижения»** (The Flatline Heuristic). Что бы мы ни делали, мы получаем тот же самый результат. Это может происходить в случае, когда программа падает определенным способом или перестает отвечать, но также мы можем не продвигаться, когда программа в основном ведет себя стабильно: "выглядит хорошо!" Действительно ли приложение упало или, возможно, оно восстанавливается? Не является ли отсутствие отклика само по себе важным результатом тестирования? Включает ли в себя понятие «что бы мы ни делали» достаточное разнообразие вариантов или нагрузок, чтобы покрыть потенциальные риски?
+9. **Эвристика Привычного завершения** (The Customary Conclusion Heuristic). Мы останавливаем тестирование тогда, когда мы обычно останавливаем тестирование. Имеется протокол, задающий определенное количество идей для тестирования, или тест-кейсов, или циклов тестирования, или как вариант - имеется определенный объем работ по тестированию, который мы выполняем и после этого останавливаемся. Agile-команды, например, часто применяют такой подход: «когда выполнены все приемочные тесты, мы знаем, что продукт готов к поставке». Эвальд Руденриджс (Ewald Roodenrijs) приводит в своем блоге пример этой эвристики в статье «Когда прекращать тестирование». Он говорит, что он останавливается, «когда выполнено определенное количество тестовых циклов, включая регрессионное тестирование». Отличие от эвристики «Время вышло!» в том, что временные ограничения могут изменяться более гибко, чем некоторые другие. Поскольку в большинстве проектов главенствует именно график проекта, и у меня и у Джеймса заняло некоторое время осознание того, что эта эвристика также очень распространена. Иногда мы можем слышать фразы типа «один тест на требование» или «один положительный и один отрицательный тест на требование», в качестве соглашения для определения «достаточно хорошего» тестирования. (Конечно же, мы не согласны с этим, но мы слышим это). Достаточно ли мы задумываемся о том, почему мы всегда останавливаемся на этом? Не должны ли мы на самом деле провести дополнительное тестирование? Или наоборот наше тестирование избыточно? Нет ли у нас информации - например, от службы технической поддержки, от службы продаж, от внешних рецензентов - которая подсказала бы, как нам изменить наши шаблоны? Рассмотрели ли мы все прочие эвристики?
+10. **Больше нет интересных вопросов** (No more interesting questions). В этот момент мы решаем, что не осталось вопросов, ответы на которые были бы достаточно ценными, чтобы оправдать стоимость продолжения тестирования, и поэтому мы останавливаемся. Эта эвристика используется в основном как дополнение к другим эвристикам, помогая принять решение о том, есть ли какие-то вопросы или риски, которые отменяют действие этих эвристик (примеры таких вопросов я привожу после каждой эвристики). Кроме того, если одна эвристика советует нам прекратить тестирование, следует проверить, нет ли интересных вопросов или серьезных рисков в других областях, и если они есть, то мы скорее продолжим тестирование, чем остановимся. Что мы думаем о наших моделях рисков? Нет ли опасности недооценки или наоборот переоценки риска, не случилось ли так, что мы не заметили Чёрного лебедя (а может быть даже Белого лебедя)? Достигли ли мы достаточного покрытия? Достаточно ли тщательно мы проверили свои оракулы?
+11. **Эвристика уклонения/безразличия** (The Avoidance/Indifference Heuristic). Иногда людей не интересует дополнительная информация, либо они не хотят знать, что происходит в программе. Тестируемое приложение может быть первой версией, которую, как мы знаем, скоро заменят. Некоторые люди прекращают тестирование по причине лени, злого умысла или отсутствия мотивации. Иногда бизнес-критичность выпуска нового релиза настолько высока, что никакая мыслимая проблема не остановит выход программы, и поэтому никакие новые результаты тестирования не будут иметь значения. Если это безразлично нам сейчас, то почему мы вообще тестировали? У нас сменились приоритеты? Если кто-то закончил работу, то почему? Иногда компанию меньше беспокоит незнание о существовании проблемы, чем знание и отсутствие действий по ее устранению - не может ли это быть нашим случаем?
+
+Дополнение: Кем Канер (Cem Kaner) предложил еще одну эвристику: «Отказ от выполнения задания» (Mission Rejected), в которой тестировщик сам отказывается от продолжения тестирования.
+
+Источники:
+
+* [Мнемоники в тестировании](http://okiseleva.blogspot.com/2018/11/blog-post\_4.html)
+* [Эвристики тестирования: будьте внимательны!](https://www.software-testing.ru/library/testing/test-analysis/3308-software-testing-heuristics-mind-the-gap)
+* [Когда нужно прекращать тестирование?](https://www.software-testing.ru/library/testing/general-testing/947-when-do-we-stop-testing)
+
+Доп. материал:
+
+* [Test Heuristics Cheat Sheet - Data Type Attacks & Web Tests](https://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf)
+* [CRUSSPIC STMPL Reborn](http://www.testthisblog.com/2011/08/crusspic-stmpl-reborn.html)
+* [Heuristic Test Strategy Model](https://www.satisfice.com/download/heuristic-test-strategy-model)
+* [FEW HICCUPPS](https://www.developsense.com/blog/2012/07/few-hiccupps/)
+* [A heuristic for regression testing](http://karennicolejohnson.com/2009/11/a-heuristic-for-regression-testing/)
+* [Software Testing Heuristics & Mnemonics](http://karennicolejohnson.com/wp-content/uploads/2012/11/KNJohnson-2012-heuristics-mnemonics.pdf)
+* [Heuristics](https://www.huibschoots.nl/wordpress/?page\_id=441#:\~:text=for%20Test%20Ideas-,Heuristics,-%3A)
+* [Эвристики, мнемоники и другие греческие слова в исследовательском тестировании мобильных приложений](https://www.youtube.com/watch?v=FuF4WT0L4vE)
diff --git a/obshee/impakt-analiz-analiz-vliyaniya-impact-analysis.md b/obshee/impakt-analiz-analiz-vliyaniya-impact-analysis.md
new file mode 100644
index 0000000..6971d0b
--- /dev/null
+++ b/obshee/impakt-analiz-analiz-vliyaniya-impact-analysis.md
@@ -0,0 +1,40 @@
+# Импакт анализ (анализ влияния, Impact Analysis)
+
+_Анализ влияния (impact analysis): Оценка изменений в документации разработки и тестирования, а также компонентов с целью внесения данных изменений в определенные требования. (ISTQB)_
+
+Impact Analysis (импакт анализ) - это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты.
+
+Затронутые области требуют большего внимания во время проведения регрессионного тестирования.
+
+Импакт анализ может быть полезным в следующих случаях:
+
+* есть изменения в требованиях;
+* получен запрос на внесение изменений в продукт;
+* ожидается внедрение нового модуля или функциональности в существующий продукт;
+* каждый раз, когда есть изменения в существующих модулях или функциональностях продукта.
+
+Как мы знаем, в настоящее время продукты становятся все более большими и комплексными, а компоненты все чаще зависят друг от друга. Изменение строчки кода в таком проекте может "сломать" абсолютно все.
+
+Информация о взаимосвязи и взаимном влиянии изменений могут помочь QA:
+
+* сфокусироваться на тестировании функциональности, где изменения были представлены;
+* принять во внимание части проекта, которые были затронуты изменениями и, возможно, пострадали;
+* не тратить время на тестирование тех частей проекта, которые не были затронуты изменениями.
+
+Есть 3 типа импакт анализа:
+
+* Анализ влияния зависимостей (Dependency impact analysis) фокусируется на обнаружении зависимостей: потенциальных последствий изменений или частей продукта, которые необходимо переработать при реализации этих изменений
+* Эмпирический анализ влияния направлен на оценку рисков, связанных с изменениями продукта, с точки зрения всего процесса разработки, включая потребность в дополнительном времени и ресурсах для разработки
+* Анализ влияния прослеживаемости (Traceability impact analysis), согласно определению в глоссарии ISTQB, оценивает, что необходимо изменить на разных уровнях документации, чтобы внести конкретное изменение в продукт.
+
+...
+
+Источники:
+
+* [Dependency Impact Analysis in Software Testing and Development: What It Is and How to Do It](https://www.apriorit.com/qa-blog/252-impact-analysis)
+* [Impact Analysis: 6 шагов, которые облегчат тестирование изменений](https://habr.com/ru/post/539208/)
+* [Impact Mapping на практике](https://habr.com/ru/post/246401/), [https://www.impactmapping.org/](https://www.impactmapping.org)
+
+Доп. материал:
+
+[The Rise of Test Impact Analysis](https://martinfowler.com/articles/rise-test-impact-analysis.html)
diff --git a/obshee/kachestvo-po-software-quality.md b/obshee/kachestvo-po-software-quality.md
new file mode 100644
index 0000000..4318266
--- /dev/null
+++ b/obshee/kachestvo-po-software-quality.md
@@ -0,0 +1,65 @@
+# Качество ПО (Software Quality)
+
+_Качество программного обеспечения (software quality): Сумма функциональности и технических характеристик программного продукта, отвечающих за возможность выполнения сформулированных или подразумевающихся задач. (ISO 9126)_
+
+_Качество (quality): Степень, с которой компонент, система или процесс соответствует зафиксированным требованиям и/или ожиданиям и нуждам пользователя или заказчика. (IEEE 610)_
+
+Формально стандарт ISO 8402-1986 определяет качество как совокупность функций и характеристик продукта или сервиса, которые обладают способностью удовлетворять явные или неявные требования. Иными словами, качество заключается в соответствии требованиям (conformance to requirements) и пригодности к использованию (fitness for use), т.е. характеризуется набором свойств, определяющих, насколько продукт "хорош" с точки зрения заинтересованных сторон, например, заказчик продукта или пользователь.
+
+ИСО/МЭК 25010 "Модели качества систем и программных продуктов" определяет модель качества программного обеспечения. Эта модель включает в себя восемь показателей качества, которые определяют атрибуты качества элемента тестирования. Тестирование представляет собой действие, которое измеряет важные показатели качества конкретного элемента тестирования.
+
+**Показатели качества**:
+
+* **функциональная пригодность**: степень, с которой продукт или система обеспечивают выполнение функции в соответствии с заявленными и подразумеваемыми потребностями при использовании при указанных условиях;
+* **уровень производительности**: производительность относительно суммы использованных при определенных условиях ресурсов;
+* **совместимость**: способность продукта, системы или компонента обмениваться информацией с другими продуктами, системами или компонентами и/или выполнять требуемые функции при совместном использовании одних и тех же аппаратных средств или программной среды;
+* **удобство использования**: степень, с которой продукт или система могут быть использованы определенными пользователями для достижения конкретных целей с эффективностью, результативностью и удовлетворенностью в заданном контексте использования;
+* **надежность**: степень выполнения системой, продуктом или компонентом определенных функций при указанных условиях в течение установленного периода времени;
+* **защищенность**: степень защищенности информации и данных, обеспечиваемая продуктом или системой путем ограничения доступа людей, других продуктов или систем к данным в соответствии с типами и уровнями авторизации;
+* **сопровождаемость**: результативность и эффективность, с которыми продукт или система могут быть модифицированы предполагаемыми специалистами по обслуживанию;
+* **переносимость**: степень простоты эффективного и рационального переноса системы, продукта или компонента из одной среды (аппаратных средств, программного обеспечения, операционных условий или условий использования) в другую.
+
+Для проверки показателя качества может потребоваться реализация подпроцесса тестирования. Например, планирование и выполнение тестирования для измерения показателя качества защищенности могут потребовать реализации подпроцесса тестирования защищенности (тестирования защищенности).
+
+Каждый из вышеперечисленных показателей качества имеет ряд дочерних характеристик, которые для обеспечения полного представления показателя качества могут быть протестированы. Следует также помнить, что не все показатели качества применимы ко всем системам, например переносимость не может быть важна для одноразовой встроенной системы. Необходимо обратить внимание на то, что приведенный выше перечень показателей качества не всегда является исчерпывающим, в отдельных случаях может потребоваться определение соответствующих дополнительных показателей качества для конкретного элемента тестирования.
+
+Основная последовательность действий при выборе и оценке критериев качества программного продукта включает:
+
+* Определение всех лиц, так или иначе заинтересованных в исполнении и результатах данного проекта.
+* Определение критериев, формирующих представление о качестве для каждого из участников.
+* Приоритезацию критериев, с учетом важности конкретного участника для компании, выполняющей проект, и важности каждого из критериев для данного участника.
+* Определение набора критериев, которые будут отслежены и выполнены в рамках проекта, исходя из приоритетов и возможностей проектной команды. Постановка целей по каждому из критериев.
+* Определение способов и механизмов достижения каждого критерия.
+* Определение стратегии тестирования исходя из набора критериев, попадающих под ответственность группы тестирования, выбранных приоритетов и целей.
+
+_Метод оценки качества на основании цены (value-based quality): Вид оценки качества, где качество определяется ценой. Качественный продукт (или услуга) - тот (или та), которая обеспечивает желаемую производительность по приемлемой стоимости. Качество определяется с помощью процесса принятия решений заинтересованными сторонами путем компромисса между временем, усилиями и финансовыми аспектами. (Garvin)_
+
+_Метод оценки качества на основе продукта (product-based quality): Взгляд на качество, при котором качество основывается на четко определенном наборе атрибутов качества. Эти атрибуты должны быть объективно измеряемы и представимы в численном виде. Различия в качестве продуктов одного типа могут быть трассируемы к конкретным методам реализации атрибутов качества. (Garvin)_
+
+_Метод оценки качества на основе производства (manufacturing-based quality): Вид качества, в котором качество продукта или услуги измеряется степенью соответствия предполагаемому дизайну и требованиям. Качество возникает в результате использования процесса (ов). (Garvin)_
+
+_Метод оценки качества на трансцендентной основе (transcendent-based quality): Вид оценки качества, в котором качество не может быть точно определено, но мы знаем о его присутствии, когда мы видим его, либо знаем о его отсутствии, когда оно отсутствует. Качество зависит от восприятия и эмоциональных чувств лица или группы лиц по отношению к продукту. (Garvin)_
+
+_Метод оценки качества с точки зрения пользователя (user-based quality): Вид оценки качества, в котором качество определяется как способность удовлетворять потребности, желания и нужды пользователя (ей). Пользователи вряд ли будут использовать продукт или услугу, которая не выполняет их потребности. Это зависит от контекста, так называемый условный подход к качеству, потому что различные деловые характеристики требуют различный уровень качества продукта. (Garvin)_
+
+Источники:
+
+* [Лекция 9: Особенности индустриального тестирования](https://intuit.ru/studies/courses/48/48/lecture/1440)
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996)
+
+Доп. материал:
+
+* Роберт Мартин "Идеальный программист. Как стать профессионалом разработки ПО"
+* [ГОСТ Р ИСО/МЭК 25010-2015 “Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов”](https://docs.cntd.ru/document/1200121069)
+* [Качество программного обеспечения (Software Quality)](https://analytics.infozone.pro/software-quality/)
+* [Кто несет ответственность за качество тестирования приложения? 10 причин попадания ошибки в продакшен](https://habr.com/ru/company/otus/blog/471080/)
+* [На ком лежит ответственность за качество программного обеспечения?](https://habr.com/ru/company/otus/blog/537554/)
+* [Hey QA, Why Didn’t You Find That Bug?](https://betterprogramming.pub/hey-qa-why-didnt-you-find-that-bug-42ab3ef0a7e0)
+* [Лекция 9: Особенности индустриального тестирования](https://intuit.ru/studies/courses/48/48/lecture/1440?page=1)
+* [Как встроить качество в процессы производства ПО?](https://habr.com/ru/post/590639/)
+* [Качество вместо контроля качества](https://habr.com/ru/post/549130/)
+* [Как добиться качества системы / Алексей Петров (СберМаркет)](https://www.youtube.com/watch?v=oi8V6bk8oSw)
+* [Грязные секретики качества](https://telegra.ph/Gryaznye-sekretiki-kachestva-03-15)
+* [Качество как ответственность всей команды](https://www.youtube.com/watch?v=3URqwgBMn3g)
+* [Качество и его критерии](https://www.youtube.com/watch?v=ekR7Txrmpy0)
+* [Измерение качества релиза и создание его ценности](https://www.youtube.com/watch?v=QqbqudHeQck)
diff --git a/obshee/model-zrelosti-vozmozhnostei-cmm-capability-maturity-model.md b/obshee/model-zrelosti-vozmozhnostei-cmm-capability-maturity-model.md
new file mode 100644
index 0000000..d7cf27a
--- /dev/null
+++ b/obshee/model-zrelosti-vozmozhnostei-cmm-capability-maturity-model.md
@@ -0,0 +1,73 @@
+# Модель зрелости возможностей (CMM - Capability Maturity Model)
+
+_Интегрированная модель зрелости процессов программного обеспечения (CMMI) (Capability Maturity Model Integration (CMMI)): Система, описывающая ключевые элементы эффективного процесса разработки и поддержки продукта. CMMI включает в себя передовой опыт планирования, проектирования и управления разработкой и поддержкой продукта. (CMMI)_
+
+_Интегрированная модель зрелости тестирования (Test Maturity Model Integration): Пятиступенчатая структура совершенствования процесса тестирования, связанная с интегрированной моделью зрелости процессов программного обеспечения (CMMI) и описывающая ключевые элементы эффективного процесса тестирования. (ISTQB)_
+
+_Модель зрелости (maturity model): Структурированный набор элементов, которые описывают некоторые аспекты зрелости в организации, и помогают в определении и понимании процессов организации. Модель зрелости часто предоставляет общий язык, общее видение и основы для определения приоритетности действий по совершенствованию. (ISTQB)_
+
+Для любого процесса, будь то процесс контроля качества, процесс разработки или любой другой нетехнический процесс, существуют уровни зрелости. Под уровнями зрелости мы понимаем уровень формализации и совершенствования процессов, начиная от ad-hoc процессов до таких, которые состоят из формализованных и определенных шагов, у которых есть метрики результатов, и которые были оптимизированы.
+
+**CMM** (Capability Maturity Model, Модель зрелости возможностей)
+
+Это модель, основанная на процессах, которая используется для оценки зрелости организации в различных областях. Концепция СММ была введена Институтом Программной Инженерии (SEI) в США.
+
+Несмотря на то, что эта модель применяется к процессу разработки программного обеспечения, в конечном итоге она используется и для других процессов, таких как QA и тестирование.
+
+Существует пять различных уровней зрелости: от 1 до 5. По мере развития от первого до пятого уровня уменьшаются изменчивость и непоследовательность. Ниже приведено детальное описание пяти уровней. Здесь мы будем рассматривать 5 уровней СММ с позиции QA - процессов, а все результаты по выходу с каждого уровня будут применяться к процессу анализа качества и тестирования последовательно, чтобы достичь 5 уровня.
+
+**Уровень 1 (Начальный)** - Ad-Hoc: нераспланированный, бессистемный и непоследовательный
+
+Как предполагает термин «Ad-Hoc»: нераспланированный, неподготовленный, то есть на этом уровне не придается значение планированию, постановке целей на дальнейшие процессы, принципам руководства и стандартам. Не существует стандартизированного и последовательного способа выполнения любой задачи. Единственное, что важно на этом уровне, - это соблюдение сроков, независимо от качества конечного продукта и результатов. Поскольку нет заранее определенных стандартов и процессов, одна и та же задача может быть выполнена разными людьми по-разному. Это вносит еще больше хаоса, поскольку эта же задача будет выполнена в следующих раз совсем по-другому, ведь нет никакой документации о процессе, которая помогла бы его воспроизвести еще раз. Таким образом, на этом уровне процесс плохо контролируется, ведет себя реактивно и непредсказуемо.
+
+Пример:
+
+В QA примером может послужить такая ситуация, когда в организации несмотря на то, что анализ качества является одной из фаз жизненного цикла продукта, нет никаких стандартов и нет определенного процесса, нет шаблонов для результатов тестирования - планы тестирования, стратегии тестирования, сценарии и тестовые случаи не стандартизированы. Даже если все эти вещи определены и задокументированы, но у каждого члена команды свой способ выполнения того или иного процесса, то процессы все еще не являются последовательными. То есть в таком случае не приходится говорить о контроле QA, а сам уровень в целом характеризуется хаотичностью.
+
+**Уровень 2 (Повторяемый)** - Управление: Инициирование определения процессов на высоком уровне
+
+На этом этапе мы получаем решение проблемы в связи с тем, что характеристики QA - процессов отличаются от тех, которые мы видели на первом уровне. У нас уже есть четкие процессы, методология и стандарты. Стандарты и процессы не только оказываются завершенными, но по итогу они хорошо задокументированы, поэтому они могут быть воспроизведены в любой из аналогичных задач, которые были выполнены ранее. Вот почему этот уровень еще называется «повторяемый», по сути мы можем повторить шаги и выполнить ту же самую работу. Таким образом, основное внимание уделяется базовому управлению проектами на этом уровне.
+
+Пример:
+
+Для проведения анализа качества определите весь процесс и методологию проведения QA для различных типов тестирования, таких как функциональное, тестирование на производительность и т.д. Определите роли и обязанности специалистов по тестированию и их тимлида в жизненном цикле проекта и подготовьте шаблоны для представления результатов на каждом этапе. План тестирования, стратегия тестирования, сценарии и тестовые случаи должны быть организованными. Нужно не только написать и подготовить, но и поделиться документацией с командой.
+
+**Уровень 3 (Определенный)** - Основная Компетенция: Придумайте обобщенный процесс, покрывающий большую аудиторию и большее количество областей
+
+На третьем уровне люди мотивированно следуют стандартам и процессам, которые были определены на предыдущем уровне. Для этого, процессы в первую очередь должны быть посильны всем людям, вовлеченным в их выполнение. Необходимо определить, какие навыки необходимы для эффективного выполнения или использования процессов и стандартов, а также требуется ли для этого какая-то предварительная подготовка. Далее мотивируйте и поддерживайте человеческие ресурсы, чтобы они были в состоянии выполнять процессы и следовать стандартам. На этом уровне, люди, имеющие больше опыта, делятся своими знаниями с другими. Основное внимание уделяется документации, стандартизации процессов и интеграции. К этому времени у организации уже есть свой собственный стандартный процесс тестирования программного обеспечения.
+
+Пример:
+
+Проведение вебинаров или тренингов, позволяющих тестировщикам ознакомиться с определенным новым процессом и стандартами QA и мотивировать их пользоваться ими в своей повседневной проектной деятельности.
+
+**Уровень 4 (Управляемый)** - Предсказуемый: Измерение процессов
+
+На этом уровне количественно измеряются процессы, определенные на уровне 3. Это нужно для контроля ресурсов, необходимых для выполнения любой задачи. На основе этого количественного анализа, без ухудшения качества конечного продукта процессы можно скорректировать, если это необходимо. Анализ проводится путем разделения всего процесса на более мелкие подпроцессы, а затем к этим подпроцессам применяются количественные методы. В соответствии с результатом, подпроцессы корректируются по мере необходимости. Этот уровень называют предсказуемым, поскольку на основе предыдущего опыта можно количественно скорректировать курс выполнения процесса и предсказать эффективность работы последующих выполнений процессов. Ключевыми областями на 4 уровне СММ являются количественное управление проектами и эффективность организационных процессов. Вкратце на этом уровне измеряется и контролируется процесс.
+
+Пример:
+
+Хорошей идеей будет проведение регулярных QA-аудитов. Они могут включать проверку того, действительно ли команды следуют определенным процессам, используют стандартные шаблоны и придерживаются методологии. Если вы занимаетесь автоматизированным тестированием, то периодические review кода тестовых сценариев автоматизации, можно привести и это в качестве примера.
+
+**Уровень 5 (Оптимизация)** - Инновационный: Непрерывное совершенствование
+
+На этом уровне определяются инновационные способы дальнейшего совершенствования предварительно определенных процессов и стандартов. Для этого наши собственные процессы должны постоянно пересматриваться и изменяться путем добавления новых инструментов и технологий, непрерывными исследованиями и обучению новому, освоению самого современного опыта рынка. Этого можно достигнуть путем сопоставительного анализа вашей организации с другими, обучения у них, попытками перенять опыт и улучшить собственный процесс, добавив в него нечто инновационное. Таким образом, на этом уровне основное внимание уделяется непрерывному совершенствованию процессов. Ключевыми областями процесса являются управление эффективностью организации и количественное управление проектами.
+
+Пример:
+
+Продолжайте совершенствовать методологию, процессы анализа качества, определенные на основе имеющихся результатов аудита. На основании некоторых исследований был сделан вывод о том, что организация, находящаяся на первом уровне, может потратить до $1000 на ту задачу, которую организации пятого уровня сможет выполнить, затратив всего $10. Недавно в моей организации выяснилось, что мы проводим регрессионное тестирование вручную, то есть руками повторяем одну и ту же последовательность действий, что занимает много времени и усилий, которые можно сэкономить и вложить в другие более продуктивные действия. Затем мы разработали доказательство осуществимости концепции автоматизации процесса регрессионного тестирования с помощью инструментов автоматизации. POC прошло нормально и, наконец, нам удалось наладить процесс выполнения регрессионного тестирования с помощью тестовых сценариев автоматизации. Это сэкономило много сил и времени и способствовало улучшению процесса в целом.
+
+После рассмотрения всех пяти уровней, о которых мы говорили выше, кажется, что сложнее всего достичь третьего уровня. Как только вы его достигнете, до всех остальных уровней будет рукой подать.
+
+Источники:
+
+* [Как достичь Уровня 5 по модели CMM в области QA и тестирования](https://habr.com/ru/company/otus/blog/479368/)
+
+Доп. материал:
+
+* [TMMi Model](https://www.tmmi.org/tmmi-model/)
+* [The Quality Maturity Model](https://thinkingtester.com/the-quality-maturity-model/)
+* [Модель зрелости тестирования TPI Next: преимущества, недостатки и варианты внедрения](https://devsday.ru/blog/details/5427)
+* [Test Maturity Model: как тестировщику оценить проект и спланировать процессы](https://www.software-testing.ru/library/around-testing/processes/3092-test-maturity-model)
+* [Как достичь Уровня 5 по модели CMM в области QA и тестирования](https://habr.com/ru/company/otus/blog/479368/)
+* [7 подходов к тестированию](https://medium.com/@grifer163/7-%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%D0%BE%D0%B2-%D0%BA-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8E-a78fc69da167)
+* [Software testing process improvement models - TMMi, TPI Next, CTP, STEP](https://tryqa.com/software-testing-process-improvement-models-tmmi-tpi-next-ctp-step/)
diff --git a/obshee/nezavisimoe-testirovanie-independent-testing.md b/obshee/nezavisimoe-testirovanie-independent-testing.md
new file mode 100644
index 0000000..de4defd
--- /dev/null
+++ b/obshee/nezavisimoe-testirovanie-independent-testing.md
@@ -0,0 +1,14 @@
+# Независимое тестирование (Independent testing)
+
+Можете ли вы доверять вердикту судьи, который является частью внутреннего круга людей, которых он должен судить? Чтобы этот процесс был справедливым, лица, принимающие решения, должны быть беспристрастными. Теперь, когда вы активно участвуете в разработке какого-либо продукта или программного обеспечения, тестировать его с нейтральным мышлением это легче сказать, чем сделать. Вы бы хотели отгружать продукт в кратчайшие сроки и считать его безупречным и в конечном итоге упустите из виду некоторые ошибки. Чтобы избежать такой ситуации, иногда следует нанять независимую организацию по тестированию.
+
+Тестирование по уровням независимости:
+
+* Когда программист проверяет свой код: Вы бы никогда не попросили шеф-повара быть его собственным критиком. И даже если вы это сделаете, вам будет трудно поверить всему, что он говорит. Смысл - создатель никогда не может быть хорошим критиком своей собственной работы. Программист знает свой код от и до. Их цель - создать продукт и отправить его в кратчайшие сроки. Вместо того, чтобы искать ошибки со всех возможных точек зрения, они будут искушены найти способы обойти найденные ошибки. Писатель Гленфорд Майерс в своей книге «Искусство тестирования программного обеспечения» перечислил разницу в мышлении разработчика и тестировщика. Он сказал, что разработчик думает как строитель, сосредоточенный на строительстве, в то время как тестировщик ищет недостатки, которые приведут к разрушению здания, если не будут решены.
+* Тестирование проводится другим программистом в организации: Компромисс - это найти кого-то в организации. Это может быть какой-то другой программист, который участвует в некоторых других проектах. Это дает определенный уровень независимости. Но проблема возникает из-за того же reporting manager. Менеджер может попросить программиста пропустить некоторые тесты, когда есть ограничения по времени. Это приведет к неполному тестированию продукта. Кроме того, если попросить других разработчиков провести тестирование, это приведет к развертыванию различных ресурсов в одном проекте. Это будет вредно для всей работы организации.
+* Внутренняя команда тестирования: Наличие другой внутренней команды - это хорошее решение. Но поскольку они будут в организации, на них будут влиять ограничительные сроки. Кроме того, это будет дорого поддерживать внутреннюю команду. Это приведет к большим бюджетным и ресурсным ограничениям для команды. Команда может иметь доступ к ограниченным инструментам и программному обеспечению, таким образом, не отвечая требованиям всех проектов. Среда тестирования также будет варьироваться в зависимости от количества пользователей и числа выполненных интеграций. Затем тестирование будет проводиться в спешном порядке, что приведет к упущению некоторых ошибок, которые могут появиться после выпуска продукта. Решение, которое позаботится обо всех этих недостатках, - «Независимое тестирование».
+* Почему независимое тестирование? Независимые тестирующие организации изучат все аспекты вашей продукции. Они работают с мышлением поиска недостатков и ошибок. Они не будут использовать ярлыки в процессе тестирования. И поскольку они не были частью процесса разработки, они будут проводить тесты на нейтральной основе, чтобы прежние интересы не мешали процессу тестирования. Мысль о поиске максимальных «точек останова» пойдет на пользу вашему продукту. Почти все сторонние тестирующие организации предоставят вам подробные отчеты об ошибках и предложат корректирующие меры.
+
+Источник:
+
+[Independent Testing Guide - How It Delivers Quality Driven Product](https://www.softwaretestingmaterial.com/independent-testing/)
diff --git a/obshee/pochemu-trebuetsya-testirovanie-po.md b/obshee/pochemu-trebuetsya-testirovanie-po.md
new file mode 100644
index 0000000..193ebfc
--- /dev/null
+++ b/obshee/pochemu-trebuetsya-testirovanie-po.md
@@ -0,0 +1,34 @@
+# Почему требуется тестирование ПО?
+
+Необходимость тестирования программного обеспечения может быть продиктована следующими условиями:
+
+* лица, принимающие решения, запрашивают информацию о показателях качества элемента(ов) тестирования;
+* проверяемый(ые) элемент(ы) тестирования не всегда делает то, что от него (них) ожидается;
+* необходимо произвести верификацию проверяемого(ых) элемента(ов) тестирования;
+* необходимо произвести валидацию проверяемого(ых) элемента(ов) тестирования и/или
+* необходимо провести оценку элемента(ов) тестирования по всему жизненному циклу разработки программного обеспечения и систем.
+
+Общеизвестно, что создать совершенное программное обеспечение невозможно. Поэтому прежде чем программное обеспечение будет передано пользователям, его необходимо протестировать, чтобы в производстве программного обеспечения снизить риск ошибок, оказывающих негативное влияние на его функционирование. В равной степени необходимо обеспечить качественное выполнение тестирования программного обеспечения.
+
+Ошибки или допущенные дефекты обычно имеют место и неизбежны. Опечатка или ошибка, сделанная человеком, приводит к возникновению дефекта в продукте, над которым человек работает (например, спецификация требований или компонент программного обеспечения). Дефект не оказывает влияния на функционирование программного обеспечения до тех пор, пока он не будет обнаружен при эксплуатации программного обеспечения. Однако если дефект обнаружен в реальных условиях, когда продукт уже сдан в эксплуатацию, то это может привести к тому, что продукт не будет удовлетворять законным потребностям пользователя. Последствия программной ошибки для пользователя могут быть серьезны. Например, дефект может поставить под угрозу бизнес-репутацию, государственную безопасность, бизнес-экономическую жизнеспособность, бизнес или безопасность пользователей и/или окружающую среду.
+
+Динамическое тестирование является необходимым, но не достаточным условием, чтобы обеспечить приемлемую уверенность в том, что программное обеспечение будет функционировать, как задумано. В сочетании с эффективными действиями динамического тестирования необходимо произвести дополнительные действия статического тестирования, такие как экспертная оценка и статический анализ.
+
+Источник:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996)
+
+Доп. материал:
+
+* [Мир без QA](https://telegra.ph/Mir-bez-QA-03-13)
+* [Продукт без тестирования](https://habr.com/ru/post/564816/)
+* [«Ответственность должна быть на инженерах, которые пишут код». Почему в People.ai отказались от QA-команды и что это дало](https://dou.ua/lenta/interviews/working-without-qa-in-peopleai/)
+* [Чужие ошибки и успехи: Космические уроки для QA (часть 2)](https://www.youtube.com/watch?v=9mxhNfEcgvA)
+* [Why is software testing necessary?](https://tryqa.com/why-is-testing-necessary/)
+* [Что делать без тестировщика](https://medium.com/xsolla-tech/testing-without-qa-6f94df32e696)
+* [7 эпичнейших багов в истории человечества](https://testengineer.ru/dorogostoyashchie-bagi/)
+* [Эпические баги прошлого](https://habr.com/ru/post/645133/)
+* [Эй, QA! Почему вы не нашли этот баг?](https://habr.com/ru/post/647385/)
+* [Blog: “Why Didn’t We Catch This in QA?”](https://www.developsense.com/blog/2020/08/why-didnt-we-catch-this-in-qa/)
+* [Blog: Testers: Get Out of the Quality Assurance Business](https://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/)
+* [Быть или не быть: дискуссии о тестировании в мобильной разработке](https://habr.com/ru/company/yoomoney/blog/513722/)
diff --git a/obshee/podkhod-k-testirovaniyu-test-approach.md b/obshee/podkhod-k-testirovaniyu-test-approach.md
new file mode 100644
index 0000000..ceaa18d
--- /dev/null
+++ b/obshee/podkhod-k-testirovaniyu-test-approach.md
@@ -0,0 +1,32 @@
+# Подход к тестированию (Test Approach)
+
+_Подход к тестированию (test approach): Реализация стратегии тестирования для определенного проекта. Обычно включает в себя заключения, сделанные на основе цели (тестирования) проекта и анализе рисков, стартовые точки процесса тестирования, применяемые методики разработки тестов, критерии выхода, типы тестирования, которые должны быть произведены. (ISTQB)_
+
+_Оценка риска (risk assessment): Процесс идентификации и последующего анализа определенного риска проекта или продукта с целью определить его уровень. Обычно состоит из назначения рейтинга вероятности и влияния. (ISTQB)_
+
+_Цель тестирования (test target): Набор критериев выхода. (ISTQB)_
+
+Подход к тестированию - это реализация стратегии тестирования для конкретного проекта.
+
+Подход к тестированию определяется и уточняется в test plans and test designs. Подход к тестированию обычно включает решения, принимаемые на основе цели (тестового) проекта и оценки рисков (risk assessment). Подход к тестированию является отправной точкой для планирования процесса тестирования, для выбора применяемых методов проектирования тестов и типов тестов, а также для определения критериев начала и окончания тестирования. Выбранный подход зависит от контекста и может учитывать риски, опасности и безопасность, доступные ресурсы и навыки, технологии, характер системы (например, [custom built](https://en.wikipedia.org/wiki/Custom\_software) vs. [commercially available off-the-shelf (COTS)](https://en.wikipedia.org/wiki/Commercial\_off-the-shelf)), цели тестирования (test objectives) и правила.
+
+Подход к тестированию включает две техники:
+
+* Упреждающий (Proactive) - подход, при котором test design process запускается как можно раньше, чтобы найти и исправить дефекты до создания сборки (build);
+* Реактивный (Reactive) - подход, при котором тестирование не начинается до завершения проектирования и разработки.
+
+Различные подходы к тестированию:
+
+* **Аналитические подходы (Analytical approaches)**, такие как risk-based testing, когда тестирование направлено на области наибольшего риска;
+* **Подходы на основе моделей (Model-based approaches)**, такие как стохастическое тестирование с использованием статистической информации о частоте отказов (например, модели роста надежности) или использовании (например, рабочие профили);
+* **Методические подходы (Methodical approaches)**, такие как основанные на отказах (failure-based) (включая error guessing and fault attacks), основанные на опыте, на основе чек-листов и на основе характеристик качества (experience-based, checklist-based, and quality characteristic-based);
+* **Подходы, соответствующие процессам или стандартам (Process- or standard-compliant approaches)**, например, указанные в отраслевых стандартах или различных гибких методологиях;
+* **Динамические и эвристические подходы (Dynamic and heuristic approaches)**, такие как exploratory testing, при котором тестирование более реагирующее (reactive) на события, чем при запланированном заранее (pre-planned), и где выполнение и оценка (execution and evaluation) являются параллельными задачами;
+* **Консультативные подходы (Consultative approaches)** - подходы, при которых test coverage определяется в первую очередь советами и руководством экспертов в области технологий и / или бизнеса, не входящих в группу тестирования;
+* **Подходы против регрессии (Regression-averse approaches)** - подходы, которые включают повторное использование существующего тестового материала, обширную автоматизацию функциональных регрессионных тестов и стандартные наборы тестов.
+
+Можно комбинировать разные подходы, например, динамический подход, основанный на оценке риска.
+
+Источник:
+
+[ISTQB Foundation - 5.2.6 Test Strategy, Test Approach](https://istqbfoundation.wordpress.com/2017/09/18/test-strategy-test-approach/)
diff --git a/obshee/politika-otsutstviya-bagov-zbp-zero-bug-policy.md b/obshee/politika-otsutstviya-bagov-zbp-zero-bug-policy.md
new file mode 100644
index 0000000..b5d1df5
--- /dev/null
+++ b/obshee/politika-otsutstviya-bagov-zbp-zero-bug-policy.md
@@ -0,0 +1,20 @@
+# Политика отсутствия багов (ZBP - Zero Bug Policy)
+
+Она означает, что все баги имеют приоритет над разработкой новых фич или улучшениями. Важным следствием этого подхода является отсутствие таких вещей, как приоритет багов, critical bugs или minor bugs. Либо issue является багом, либо нет. И если это баг, вам нужно исправить его, прежде чем выполнять другую работу.
+
+Преимущества:
+
+* снижение затрат на разработку;
+* лучшие оценки (estimates);
+* повышение гибкости;
+* повышение удовлетворенности клиентов/заказчиков;
+
+Источники:
+
+* [The Zero Bug Policy](https://sookocheff.com/post/process/zero-bug-policy/)
+
+Доп. материал:
+
+* [QA Crew #4:Круглый стол:Zero Bug Policy: о политике, ее преимуществах/недостатках, нюансах внедрения](https://www.youtube.com/watch?v=Nv7lb7CdHaY)
+* [How We Got to Zero Bugs and Implemented a Zero Bug Policy](https://medium.com/swlh/how-we-got-to-zero-bugs-and-implemented-a-zero-bug-policy-c77ee3f2e50b)
+* [Шестой подвиг Геракла: как мы расчистили прод от багов](https://habr.com/ru/company/dins/blog/577996/)
diff --git a/obshee/principy-testirovaniya.md b/obshee/principy-testirovaniya.md
new file mode 100644
index 0000000..3990b66
--- /dev/null
+++ b/obshee/principy-testirovaniya.md
@@ -0,0 +1,57 @@
+# Принципы тестирования
+
+1. Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
+2. Исчерпывающее тестирование недостижимо (Exhaustive testing is not possible)
+3. Раннее тестирование (Early testing)
+4. Скопление/кластеризация дефектов (Defect clustering)
+5. Парадокс пестицида (Pesticide paradox)
+6. Тестирование зависит от контекста (Testing is context dependent)
+7. Заблуждение об отсутствии ошибок (Absence of errors fallacy)
+
+**Принцип 1. Тестирование показывает наличие дефектов**\
+Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов больше нет.\
+Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку.
+
+**Принцип 2**. [Исчерпывающее тестирование невозможно](https://www.softwaretestingclass.com/what-is-exhaustive-testing-in-software-testing/)\
+Для проведения исчерпывающего тестирования придется протестировать все возможные входные значения и все пути выполнения программы, в большинстве случаев число таких вариаций стремится к бесконечности или просто на порядки превосходит отведенное время и бюджет. Вместо попыток «протестировать все» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками - одна из наиболее важных активностей в любом проекте.
+
+**Принцип 3. Раннее тестирование**\
+Тестовые активности должны начинаться как можно раньше в SDLC, а именно когда сформированы требования.\
+Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить. Дефект, найденный в требованиях, обходится дешевле всего.\
+Еще одно важное преимущество раннего тестирования - экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.
+
+**Принцип 4. Скопление дефектов**
+
+Небольшое количество модулей содержит большинство дефектов, обнаруженных на этапе предрелизного тестирования, или же демонстрируют наибольшее количество отказов на этапе эксплуатации.\
+Многие тестировщики наблюдали такой эффект - дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов - тестировщики фокусируются на известных «проблемных зонах». Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
+
+**Принцип 5**. [Парадокс пестицида](https://okiseleva.blogspot.com/2020/11/blog-post\_26.html)
+
+Boris Beizer в своей книге Software Testing Techniques объяснил парадокс пестицида как феномен, согласно которому чем больше вы тестируете ПО, тем более невосприимчивым оно становится к имеющимся тестам, т.е.
+
+1. каждый метод и набор тестов, который используется для предотвращения или поиска ошибок, может оставлять часть не найденных ошибок, против которых эти методы и тесты неэффективны;
+2. имеющиеся тесты устаревают после исправления дефекта и не могут обнаружить новые;
+
+Из чего следует, что набор тестов, тестовых данных и подходов нужно постоянно пересматривать и улучшать для выявления не найденных ошибок, а также необходимо обновлять тесты и тестовые данные после исправления уже найденных дефектов.
+
+**Принцип 6. Тестирование зависит от контекста**\
+Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.\
+Этот принцип тесно связан с понятием риска. Что такое риск? Риск - это потенциальная проблема. У риска есть вероятность (likelihood) - она всегда выше 0 и ниже 100% - и есть влияние (impact) - те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние.\
+То же можно сказать и о мире ПО: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьируется. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.\
+Уровень риска влияет на выбор методологий, техник и типов тестирования.\
+**Принцип 7. Заблуждение об отсутствии ошибок**\
+Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.\
+Заказчики ПО - люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи - на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.\
+Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей.\
+Иначе говоря, верификация не равна валидации.
+
+Источники:
+
+* 7 принципов тестирования. [Часть 2](https://www.luxoft-training.ru/about/news/7\_printsipov\_testirovaniya\_CHast\_2/), [3](https://www.luxoft-training.ru/about/news/7\_printsipov\_testirovaniya\_CHast\_3/)
+
+Доп. материал:
+
+* [Семь принципов тестирования. Почему они так важны и как ими пользоваться](https://www.youtube.com/watch?v=TxPbhqxcKP4)
+* [Парадокс пестицида и поддержка эффективности тест-кейсов](https://training.qatestlab.com/blog/technical-articles/pesticide-paradox-support-effectiveness-test-cases/)
+* [Pesticide Paradox in Software Testing](https://testwithnishi.com/2015/01/03/pesticide-paradox-in-software-testing/)
+* [The Cold Hard Truth About Zero-Defect Software](https://theqalead.com/topics/zero-defect-software/)
diff --git a/obshee/process-testirovaniya-test-process-draft.md b/obshee/process-testirovaniya-test-process-draft.md
new file mode 100644
index 0000000..a20bd15
--- /dev/null
+++ b/obshee/process-testirovaniya-test-process-draft.md
@@ -0,0 +1,157 @@
+# Процесс тестирования (test process) (draft)
+
+Большая и сложная тема, пока останется черновиком. В будущем, возможно, перерастет в отдельный раздел. Накопилось некоторое количество ссылок по теме, так что углубиться можно уже сейчас в доп. материалах.
+
+_Процесс тестирования (test process): Фундаментальный процесс тестирования охватывает планирование тестирования, анализ и дизайн тестов, внедрение и выполнение тестов, оценку достижения критериев выхода и отчетность, а также работы по завершению тестирования. (ISTQB)_
+
+_Управление рисками (risk management): Систематическое использование процедур и практик с целью идентификации, анализа, определения приоритетов и контроля рисков. (ISTQB)_
+
+_Управление тестированием (test management): Планирование, оценка, мониторинг и контроль тестовых активностей, обычно выполняемые руководителем тестирования. (ISTQB)_
+
+_Менеджмент тестирования (test management): Планирование, составление графика, оценка, мониторинг, отчетность, управление и выполнение действий по тестированию (ГОСТ 56920)_
+
+Управление тестированием - это процесс управления тестовой деятельностью с целью обеспечения высококачественного и высококлассного тестирования программного приложения. Метод заключается в организации, контроле, обеспечении отслеживания и видимости процесса тестирования с целью создания высококачественного программного приложения. Это обеспечивает выполнение процесса тестирования программного обеспечения в соответствии с ожиданиями.
+
+Вы становитесь тест-менеджером самого важного проекта в вашей компании. Задача проекта - протестировать банковскую сеть уважаемого "Guru99 Bank".
+
+Кажется, что все отлично. Менеджер вам доверяет и на вас рассчитывает. У вас есть хороший шанс доказать, что вы справитесь со своей задачей. Но правда в том, что:
+
+Управление тестированием - это не просто один вид деятельности. Оно состоит из целого ряда мероприятий.
+
+**Фазы управления тестированием**
+
+В этом разделе кратко описывается процесс управления тестированием и дается обзор этапов управления тестированием. Более подробно о каждой фазе управления тестированием вы узнаете в следующих статьях.
+
+
+
+Процесс управления тестированием - это процедура управления деятельностью по тестированию программного обеспечения от начала и до конца. Процесс управления тестированием обеспечивает планирование, контроль, отслеживание и мониторинг на протяжении всего цикла проекта. Он включает в себя несколько видов деятельности, таких как планирование, проектирование и выполнение тестов; обеспечивает первоначальный план и порядок процесса тестирования программного обеспечения.
+
+Процесс управления тестированием состоит из двух основных частей:
+
+* **Планирование**:
+ * Анализ рисков;
+ * Оценка тестирования;
+ * Планирование тестирования;
+ * Организация тестирования.
+* **Выполнение**:
+ * Мониторинг и контроль тестирования;
+ * Решение проблем;
+ * Отчет о тестировании и оценка.
+
+**Анализ рисков и их решение**
+
+Риск - это потенциальная потеря (нежелательный результат, но не обязательно таковой), возникающая в результате какого-либо воздействия или деятельности.
+
+Анализ рисков - это первый шаг, который должен предпринять тест-менеджер перед началом любого проекта. Поскольку все проекты могут содержать риски, раннее выявление и определение путей их решения помогут тест-менеджеру избежать потенциальных потерь в будущем и сократить затраты на проект.
+
+Более подробно об анализе рисков и их решении вы узнаете здесь.
+
+**Оценка теста**
+
+Оценка - это прогноз или предсказание. Оценка теста - это приблизительное определение того, сколько времени потребуется для выполнения задания. Оценка трудоемкости теста является одной из основных и важных задач в управлении тестированием.
+
+Преимущества правильной оценки:
+
+* Точные оценки тестов помогают лучшему планированию, выполнению и мониторингу задач, находящихся в поле зрения менеджера по тестированию.
+* Позволяют составить более четкий график работ и способствуют более уверенной реализации результатов.
+
+**Планирование тестирования**
+
+План тестирования можно определить как документ, описывающий объем, подход, ресурсы и график предполагаемых мероприятий по тестированию. Без полного плана тестирования проект может потерпеть неудачу. Планирование тестирования особенно важно при разработке крупных программных систем. При тесте программного обеспечения план предоставляет подробную информацию о предстоящем тестировании, включая:
+
+* Стратегия тестирования;
+* Цель тестирования;
+* Критерии выхода/приостановки;
+* Планирование ресурсов;
+* Результаты тестирования.
+
+**Что такое организация тестов при тестировании программного обеспечения?**
+
+Организация тестов при тестировании программного обеспечения - это процедура определения ролей в процессе тестирования. Она определяет, кто и за какие действия отвечает в процессе тестирования. В рамках этого процесса также объясняются функции, средства и виды деятельности, связанные с тестированием. Компетентность и знания вовлеченных людей также определены, при этом каждый несет ответственность за качество процесса тестирования.
+
+Теперь у вас есть План, но как вы будете придерживаться и выполнять его? Чтобы ответить на этот вопрос, вам нужно пройти этап организации тестирования. По существу, вам нужно организовать эффективную команду тестирования. Необходимо собрать квалифицированную команду, для эффективного управления постоянно растущим процессом тестирования. Вам нужно больше узнать об организации тестирования? Почему самоорганизованные команды так важны? Кликните здесь для получения подробной информации.
+
+**Мониторинг и контроль тестирования**
+
+Что вы будете делать, когда у вашего проекта закончатся ресурсы или он не уложится в сроки? Необходимо провести мониторинг и контроль тестовых мероприятий, чтобы вновь вернуться в график. Мониторинг и контроль тестирования - это процесс наблюдения за всеми показателями, необходимый для того, чтобы гарантировать, что проект работает хорошо, по графику и не выходит за рамки бюджета.
+
+**Мониторинг**
+
+Мониторинг - это процесс сбора, регистрации и предоставления информации о деятельности проекта, которую необходимо знать менеджеру проекта и стейкхолдерам.
+
+Для мониторинга тест-менеджер выполняет следующие действия:
+
+* Определение цели проекта или стандарта производительности проекта;
+* Наблюдение за ходом выполнения проекта и сопоставление фактической и запланированной производительности;
+* Записывает и сообщает про любую обнаруженную проблему, которая происходит с проектом.
+
+**Контроллинг**
+
+Контроллинг проекта - это процесс использования данных, полученных в ходе мониторинга, для приведения фактических показателей к запланированным.
+
+На этом этапе тест-менеджер предпринимает действия для исправления отклонений от плана. В некоторых случаях план должен быть скорректирован в соответствии с ситуацией в проекте.
+
+**Решение проблем**
+
+Как упоминалось в начале, все проекты потенциально рискованны. Когда риск возник, он становится проблемой. В жизненном цикле любого проекта всегда будут появляться неожиданные проблемы и вопросы. Например:
+
+* Компания сокращает бюджет вашего проекта;
+* Вашей проектной команде не хватает навыков для завершения проекта;
+* График проекта слишком жесткий, чтобы ваша команда смогла завершить его в срок;
+* Компания сокращает бюджет вашего проекта;
+* Вашей проектной команде не хватает навыков для завершения проекта;
+* График проекта слишком жесткий, чтобы ваша команда смогла завершить его в срок.
+
+Риск, которого следует избегать при тестировании:
+
+* Нарушение дедлайна;
+* Превышение бюджета проекта;
+* Потеря доверия заказчика.
+
+Когда возникают эти проблемы, вы должны быть готовы к их решению - или они потенциально способны повлиять на исход проекта.
+
+**Отчет о тестировании и оценка**
+
+Проект уже завершен. Настало время проанализировать, что было сделано. Целью отчетов с оценкой результатов тестирования является следующее:
+
+"Отчет с оценкой тестирования" описывает результаты тестирования с точки зрения покрытия теста и критериев выхода. При оценке тестов используются сведения, основанные на данных о результатах тестирования и сводной информации о результате тестирования.
+
+Источники:
+
+* [Процесс управления тестированием: Полное руководство по тестированию проекта](https://habr.com/ru/company/otus/blog/599921/)
+
+Доп. материал:
+
+* [Certified Tester - Advanced Level Syllabus - Test Manager](https://bystqb.org/files/content/bystqb/downloads/ISTQB\_CTAL\_Syllabus\_TM\_English\_v2012.pdf)
+* [ГОСТ Р 56921-2016/ISO/IEC/IEEE 29119-2:2013 Часть 2: “Процессы тестирования”](https://docs.cntd.ru/document/1200134997)
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). 2.1.2. Жизненный цикл тестирования
+* [Процесс управления тестированием: Полное руководство по тестированию проекта](https://habr.com/ru/company/otus/blog/599921/)
+* [Как организовать работу QA. Один практически примененный способ](https://habr.com/ru/post/439128/)
+* [Как QA организовать автоматизацию тестирования на проекте. Один практически примененный способ](https://habr.com/ru/post/467109/)
+* [Как QA выстроить эффективное взаимодействие с разработчиками. Один возможный путь](https://habr.com/ru/post/471576/)
+* [Никогда такого не было и вот опять: Построение отдела тестирования - Андрей Мясников. QA Fest 2018](https://www.youtube.com/watch?v=RAC1bjWzIVk\&ab\_channel=FestGroup)
+* [Управляемое тестирование: с чего мы начинаем, чтобы не было мучительно больно](https://habr.com/ru/company/icl\_services/blog/564042/)
+* [Процесс: как наладить, а не нагадить - Андрей Мясников. QA Fest 2015](https://www.youtube.com/watch?v=54JtRR4GbPQ\&ab\_channel=FestGroup)
+* [Как проходит организация тестирования и составление тест планов (в зависимости от проекта)](https://www.youtube.com/watch?v=4KT\_ouolMQs\&ab\_channel=KatyaKravchenkoUSLife)
+* [Концепция построения процесса тестирования в Agile-проектах: 3+1](https://www.youtube.com/watch?v=UW8sTq8SuFQ\&feature=emb\_logo\&ab\_channel=LuxoftTrainingCenter)
+* [Построение процессов тестирования на новом проекте](https://www.youtube.com/watch?v=POYyrqpbr94\&feature=emb\_logo\&ab\_channel=VladislavOrlikov)
+* [Мифы о тестировании #2 / О чем не говорят на курсах по тестированию / Правда о работе в IT](https://www.youtube.com/watch?v=qiCjqqtWP7I\&t=790s)
+* [QAGuild #49: Самая частая проблема в сфере тестирования - Проблемы QA](https://www.youtube.com/watch?v=k\_SYBYbF2iI)
+* [QA-митап Redmadrobot 19/11, Современные паттерны тестирования, Марина Куликова](https://www.youtube.com/watch?v=u3EAoXpcx4Q)
+* [Оптимизируем процесс тестирования: на какие подходы стоит обратить внимание](https://dou.ua/lenta/columns/test-optimization-techniques/)
+* [Heisenbug Show / Методологии и процессы в тестировании // 29 сентября 2020](https://www.youtube.com/watch?v=KSRLfsVVs9s)
+* [Blog: Testers: Focus on Problems](https://www.developsense.com/blog/2021/06/testers-focus-on-problems/)
+* [Leadership in test: executing a test project](https://theqalead.com/topics/executing-a-testing-project/)
+* [ISTQB Foundation Level Syllabus, Chapter 5 of 6: Test Management](https://medium.com/@HugoSaxTavares/istqb-foundation-level-syllabus-chapter-5-of-6-test-management-a6b594135f09)
+* [Построение процессов в QA: проблемы и решения](https://habr.com/ru/company/socialquantum/blog/568946/)
+* [Чтобы сделать продукт качественнее, нужно каждое утро натощак… Кликбейта не будет: оптимизируем тестирование](https://habr.com/ru/company/agima/blog/569108/)
+* [Как построить процесс тестирования с нуля?](https://www.youtube.com/watch?v=GF5eZEQ9GiM)
+* [Здоровые тест-привычки](https://software-testing.ru/library/testing/testing-for-beginners/3726-healthy-testing-habits)
+* [Монолог QA-лида, возмужавшего в сражениях за качество кода](https://habr.com/ru/company/niisokb/blog/592053/)
+* ["Я не доверяю твоему тестированию" и как с этим бороться](https://software-testing.ru/library/around-testing/management/3658-i-dont-trust-your-testing-and-how-to)
+* [Как создать пирамиду из мороженки, если надежды нет](https://habr.com/ru/company/moex/blog/658183/)
+* [Обеспечение качества мобильной разработки в hh.ru](https://habr.com/ru/company/hh/blog/654121/)
+* [QA процессы с чистого листа](https://www.youtube.com/watch?v=0R0njynqUt4)
+* [QA Department с нуля. Построение эфф-ного взаимодействия с Client Support team в IT product company](https://www.youtube.com/watch?v=teEqTwwhXjQ)
+* [Исследовательское тестирование 21 века. Тестируем команду, процессы и тестовую модель](https://www.youtube.com/watch?v=h6kBCjE18Ow)
+* [Маленькие тайны тестирования большой LMS](https://habr.com/ru/company/arcadia/blog/516390/)
diff --git a/obshee/qa-qc-testing.md b/obshee/qa-qc-testing.md
new file mode 100644
index 0000000..190b1c4
--- /dev/null
+++ b/obshee/qa-qc-testing.md
@@ -0,0 +1,91 @@
+# QA/QC/Testing
+
+* _**Обеспечение Качества - это совокупность запланированных и систематических процессов и действий поддержки, необходимых для обеспечения надлежащего уровня уверенности в том, что процесс или рабочий продукт удовлетворяет установленным техническим требованиям или требованиям к качеству. Достигается это сочетанием методов, стандартов, инструментов и навыков, признанных как соответствующая практика. Процесс Обеспечения Качества использует результаты тестирования и другую информацию для анализа, оценки и информирования о любой проблеме (включая любой риск) в проектировании, планировании или выполнении процессов программной инженерии. (ГОСТ 56920)**_
+* _**Контроль качества (quality control): Рабочие методы и активности, нацеленные на выполнение требований к качеству, являющиеся частью управления качеством. (ISO 8402)**_
+* _**Тестирование (testing): Процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов. (ISTQB)**_
+* _**Тестирование (testing): Набор операций, проводимых для обеспечения выявления и/или оценки свойств одного или более элементов тестирования. Примечание - Действия тестирования могут включать в себя планирование, подготовку, выполнение, создание отчетов и менеджмент, поскольку все они направлены на тестирование. (ГОСТ 56920)**_
+
+**Обеспечение качества (QA - Quality Assurance)** - это часть Quality Management - совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и поддержки ПО, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта. QA обеспечивает создание правильных процессов для получения в результате качественного продукта.
+
+Это также означает создание процессов **контроля качества (QC - Quality Control)**, которые в свою очередь гарантируют, что процессы, установленные QA, соблюдаются. То есть QC - это часть QA - процесс установления стандартов и проверки, что ПО сделано правильно. Цель контроля качества - проверить, соблюдалась ли предписанная модель. Это может быть достигнуто путем проведения аудитов и определения того, следовала ли команда определенной модели для достижения качества.
+
+Активности QA проходят на всем протяжении SDLC: на этапе построения, анализа и улучшения процессов, формирования релизных политик, риск менеджмента и прочих how-to’s.
+
+QC подключаются на этапе составления критериев качества, [quality gate](https://istqb-glossary.page/quality-gate/)-ов, метрик и способов оценки.
+
+Тестировщик вступает уже после этапа разработки (с shift left на этапе получения тз и превращения его в спецификацию).
+
+Иными словами, QA занимается не проверкой постфактум уже готового ПО на соответствие требованиям и наличие дефектов, а пытается предотвратить само появление этих дефектов, являясь эдаким “инфлюенсером”, специалистом, влияющим на процессы разработки и улучшающий их качество для обеспечения качества итогового продукта. QA - не должность, а набор активностей по аналогии с DevOps. Где-то это может быть отдельный человек, где-то этим занимается вся команда.
+
+Тестирование программного обеспечения направлено на предоставление информации о программном продукте и нахождении максимально возможного числа дефектов на ранних этапах процесса разработки при заданных ограничениях стоимости и графика разработки.
+
+Основными целями **тестирования** как части QC являются:
+
+* предоставление информации о качестве элемента тестирования и любых остаточных рисках относительно того, до какой степени элемент тестирования был проверен;
+* обнаружение дефектов в элементе тестирования до его передачи в эксплуатацию;
+* смягчение рисков получения продукта низкого качества заинтересованными сторонами.
+
+Вышеупомянутая информация может использоваться в нескольких целях, включая:
+
+* улучшение элемента тестирования путем устранения дефектов;
+* улучшение управленческих решений, предоставляя как основание для решений информацию о качестве и рисках;
+* улучшение процессов в организации, особо выделяя процессы, которые позволяют дефектам возникать и/или оставаться скрытыми там, где они могут быть обнаружены.
+
+**Как понять, что тестировщик хорошо сделал свою работу?**
+
+Бытует мнение, что основная задача тестировщиков - сломать продукт, на самом деле тот уже приходит на тестирование с дефектами, одна из задач тестировщика как раз их выявить.
+
+Понять, что тестировщик выполнил свою работу хорошо можно по факту выполнения следующих задач:
+
+* продукт проверен на соответствие требованиям;
+* сведено к минимуму количество дефектов, которые обнаружит конечный пользователь;
+* предоставлена отчетность по актуальному качеству продукта и любых остаточных рисках заинтересованным лицам.
+
+**QA в СНГ и на западе**
+
+У нас понятия QA/QC/Testing часто не разделяются (особенно рекрутерами), поэтому и происходит путаница, поэтому же мы видим ворох вакансий с названием Junior QA, что само по себе - оксюморон. В QA можно развиваться только будучи уже опытным специалистом.
+
+**Quality Assistance и Quality Engineering**
+
+На западе, как обычно, терминологии и вариаций больше. Помимо привычных QA/QC/Testing можно встретить несколько другое вИдение картины. Акцент делается на том, что качество обеспечивает разработка (что разумно), а тестировщик своими навыками в этом помогает, то есть ассистирует (Assistance). В совокупности с менеджерскими задачами по улучшению процессов и прочего в сумме получается уже Quality Assurance. В других источниках Quality Assistance подразумевает развитие у разработчиков навыков тестирования.
+
+При этом в других источниках можно встретить другое название для того, что у нас подразумевается под QA - QE. [Quality Engineer](https://medium.com/slalom-build/quality-engineer-learning-roadmap-fddfcb77409e) - это больше, чем просто тестировщики или автоматизаторы, они расширяют возможности команд, привнося качественное мышление во все аспекты создания программного обеспечения. Они являются экспертами в области обеспечения качества, автоматизации тестирования, анализа рисков, гибких процессов, CI/CD и всего остального, что может повлиять на качество продукта. Они сотрудничают со всеми другими ролями, чтобы обеспечить качество с первого дня, с первой истории, до того, как будет написана первая строка кода. Некоторые компании называют эту роль SDET (инженер-разработчик программного обеспечения в тестировании), но каждая компания определяет роли по-своему, поэтому то, что делает SDET или QE в одной компании, может не совсем совпадать с другой.
+
+Источники:
+
+* [Real Time Software QA Interview Questions And Answers](https://www.softwaretestingmaterial.com/software-qa-interview-questions-answers/)
+* [Testing vs Quality Assurance vs. Quality Control What’s the Difference?](https://testsigma.com/blog/testing-vs-quality-assurance-vs-quality-control-whats-the-difference/)
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996)
+
+Доп. материал:
+
+**QA**
+
+* [QA - специалист по пожарной безопасности вашего проекта](https://habr.com/ru/company/badoo/blog/496452/)
+* [Being an Influencer of Quality](https://julie-griech.medium.com/being-an-influencer-of-quality-a2411e2bf2a6)
+* [What is quality engineering?](https://theqalead.com/topics/what-is-quality-engineering/)
+* [QA in Production](https://martinfowler.com/articles/qa-in-production.html)
+* [Кто такой QA Engineer, QC Engineer и Software Engineer in Test](https://habr.com/ru/post/563204/)
+* [В чем отличие QA-инженеров от тестеров](https://www.youtube.com/watch?v=XxdPPdt16yM)
+* [Обеспечение качества - чья это работа?](https://telegra.ph/Obespechenie-kachestva---chya-ehto-rabota-05-17)
+* [Quality Assurance vs Quality Control vs Testing](https://qatestlab.com/resources/knowledge-center/quality-assurance-control/)
+* [Кто такой QA Engineer?](https://www.youtube.com/watch?v=tMVC2nNmg9M)
+* [What Is Software Quality Assurance (SQA): A Guide For Beginners](https://www.softwaretestinghelp.com/software-quality-assurance/)
+* [Why Quality Assurance should never be an Afterthought](https://www.softwaretestingnews.co.uk/why-quality-assurance-should-never-be-an-afterthought/)
+* [Вакханалия в терминологии: Testing, Quality Control, Quality Assurance, Quality Assistance](https://qsusha.wordpress.com/2021/10/03/%D0%B2%D0%B0%D0%BA%D1%85%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%8F-%D0%B2-%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8-testing-quality-control-quality-assurance-quality-assis/)
+* [From QA to Engineering Productivity](https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html)
+
+**Testing**
+
+* [“Когда говорят, что тестировщики что-то там должны уметь «ломать» - я перестаю дальше слушать. Тестирование вообще не про это.”](https://habr.com/ru/post/462553/#comment\_20475675)
+* [Основные положения тестирования](https://testitquickly.com/2010/03/09/testing-basics-by-barancev/)
+* [Что же такое тестирование?](https://www.software-testing.ru/library/testing/general-testing/2576-so-what-is-software-testing)
+* [Уроки ретроспективного анализа: наука о тестировании](https://telegra.ph/Uroki-retrospektivnogo-analiza-nauka-o-testirovanii-02-23)
+* [Тестирование за пределами требований](https://software-testing.ru/library/around-testing/requirements/3632-testing-beyond-requirements)
+* [История тестирования](http://www.testingreferences.com/testingtimeline/testingtimeline.jpg)
+* [Testing Doesn’t Improve the Product](https://www.developsense.com/blog/2021/11/testing-doesnt-improve-the-product/)
+* [“Testers just Validate Acceptance Criteria”](https://medium.com/@blakenorrish/testers-just-validate-acceptance-criteria-4c25566b591e)
+* [Что такое тестирование](https://www.youtube.com/watch?v=rz9Ks4sFx8c)
+* [What Test Engineers do at Google](https://testing.googleblog.com/2016/09/what-test-engineers-do-at-google.html)
+* [Антипаттерны тестирования](https://www.youtube.com/watch?v=8wvkL5UY54g)
+* [8 стереотипов, с которыми сталкиваются тестировщики](https://habr.com/ru/company/usetech/blog/656595/)
diff --git a/obshee/roli-dolzhnosti-v-komande.md b/obshee/roli-dolzhnosti-v-komande.md
new file mode 100644
index 0000000..bb104cb
--- /dev/null
+++ b/obshee/roli-dolzhnosti-v-komande.md
@@ -0,0 +1,35 @@
+# Роли/должности в команде
+
+
+
+Роли в тестировании ПО:
+
+* Software Test Engineer: тестирует всю систему, используя соответствующие методы и инструменты тестирования;
+* Test Analyst: определяет test conditions and features для тестирования, разрабатывает тестовые сценарии и документацию;
+* Test Automation Engineer: разрабатывает сценарии для запуска автоматизированных тестов;
+* SDET (Software Development Engineer in Test) - это специалист, который может одинаково эффективно работать в сфере разработки и тестирования и принимает участие в полном процессе разработки ПО, в т.ч. в его обязанности может входить разработка внутренних инструментов для поддержки тестирования или других функций, написание тестового фреймворка, фикс найденных дефектов за разработчика, unit/integration testing и т.п.;
+* Test Architect: проектирует комплексную инфраструктуру тестирования, выбирает инструменты для реализации;
+* Test Manager: подготавливает стратегию тестирования, контролирует процесс тестирования и членов команды;
+
+Источники:
+
+* [Куда идти в IT. Подробная инструкция от Project Manager](https://habr.com/ru/company/englishdom/blog/505438/)
+* [QA Engineering Roles: Skills, Tools, and Responsibilities in a Testing Team](https://www.altexsoft.com/blog/engineering/qa-engineering-roles-skills-tools-and-responsibilities-within-a-testing-team/)
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “Приложение Е (справочное). Роли и обязанности в тестировании”
+* [Product Owner vs Product Manager или Product Owner/Product Manager](https://habr.com/ru/post/538128/)
+* [Business Analyst, Requirement Specialist, Product Owner и другие. Чем отличаются схожие на первый взгляд роли?](https://habr.com/ru/company/epam\_systems/blog/560500/)
+* [Роль QA Lead в продуктовой компании: особенности и зоны ответственности](https://habr.com/ru/company/miro/blog/561596/)
+* [Продакт-менеджмент как профессия: востребованность, зарплата и другие нюансы](https://habr.com/ru/company/habr\_career/blog/535032/)
+* [Кто такой продакт-менеджер? Или не все PM’ы - проджект-менеджеры](https://habr.com/ru/post/535418/)
+* [Project Management in QA and Testing](https://www.softwaretestingnews.co.uk/project-management-in-qa-and-testing/)
+* [Knowledge management: как перестать изобретать велосипеды](https://habr.com/ru/company/plarium/blog/541814/)
+* [Заметки knowledge manager'a. Как работает управление знаниями в Exness](https://habr.com/ru/company/exness/blog/505470/)
+* [Профессия СТО](https://habr.com/ru/company/ivi/blog/535448/)
+* [Кто такой DevOps-инженер, что он делает, сколько зарабатывает и как им стать](https://habr.com/ru/company/netologyru/blog/501690/)
+* [Гайд по DevOps для начинающих](https://habr.com/ru/company/skillfactory/blog/509344/)
+* [Распространенные поисковые запросы, часть 3: когда должно начинаться тестирование?](https://www.software-testing.ru/library/testing/general-testing/3517--3-)
+* [«Вам звонок». Как выстроить отношения между QA и техподдержкой](https://habr.com/ru/company/youla/blog/550320/)
+* [ПРОДАКТ В IT / Customer development и БОЛЬШИЕ ДЕНЬГИ / Product Management с Виталием Григорашем](https://www.youtube.com/watch?v=ddmAwvymOIs)
diff --git a/obshee/sereznost-i-prioritet-defekta-severity-and-priority.md b/obshee/sereznost-i-prioritet-defekta-severity-and-priority.md
new file mode 100644
index 0000000..0a231b4
--- /dev/null
+++ b/obshee/sereznost-i-prioritet-defekta-severity-and-priority.md
@@ -0,0 +1,57 @@
+# Серьезность и приоритет Дефекта (Severity & Priority)
+
+Bug management включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении - баги, запросы на улучшения и даже целые [релизы](https://en.wikipedia.org/wiki/Software\_bug#:\~:text=next%20software%20release.-,Software%20releases,-%5Bedit%5D) - обычно отслеживаются и управляются с помощью баг-трекинговых систем. Добавленные элементы могут называться дефектами, заявками, проблемами или, в соответствии с парадигмой гибкой разработки, эпиками и сторями (stories and epics). Категории могут быть объективными, субъективными или комбинированными, такими как номер версии, область программного обеспечения, серьезность и приоритет, а также тип проблемы, такой как фича-реквест или баг.
+
+_Критичность (severity): Важность воздействия конкретного дефекта на разработку или функционирование компонента или системы. (IEEE 610)_
+
+_Приоритет (priority): Степень важности, присваиваемая объекту. Например, дефекту. (ISTQB)_
+
+Иными словами, серьезность представляет техническое влияние ошибки в контексте работоспособности самого ПО, а приоритет указывает на очередность выполнения задачи или устранения дефекта, т.е. точку зрения бизнеса. Приоритет выставляется любыми business stakeholders, включая project managers, business analysts, product owner, а серьезность сам тестировщик (или в сложных случаях тот, кто лучше разбирается). Разработчик берет таски исходя из приоритета.
+
+**Градация Серьезности** (Severity):
+
+* Критическая (critical) - существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.;
+* Высокая (major) - существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы;
+* Средняя (medium) - существование дефекта слабо влияет на типичные сценарии работы пользователей, и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажатия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направления сортировок по некоему полю таблицы;
+* Низкая (minor) - существование дефекта редко обнаруживается незначительным процентом пользователей и (почти) не влияет на их работу, например: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов.
+
+**Градация Срочности/приоритета** (Priority):
+
+* Наивысшая (ASAP, as soon as possible) срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста «настолько быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц минут;
+* Высокая (high) срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем;
+* Обычная (normal) срочность означает, что дефект следует исправить в порядке общей очередности. Такое значение срочности получает большинство дефектов;
+* Низкая (low) срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
+
+**Сочетания Severity и Priority**
+
+* **High Priority and High Severity**: Любой Critical/major сбой бизнес-модели, критическая проблема, при которой полностью не работает большая часть функциональности или основной компонент системы:
+ * нажатие на определенную кнопку не запускает саму функцию, например, не работает кнопка отправки на странице входа, и клиенты не могут войти в приложение;
+ * выполнение определенной функции постоянно приводит к 500 ошибке сервера и потере данных;
+ * система дает сбой после того, как вы совершили платеж или когда вы не можете добавить товары в корзину;
+ * функция банкомата, при которой после ввода правильного имени пользователя и пароля автомат не выдает деньги, но списывает их с вашего счета;
+ * на веб-сайте банка появляется сообщение об ошибке, когда клиент нажимает кнопку перевода денег.
+* **High Priority and Low Severity**: Любые minor severity дефекты, которые влияют на взаимодействие с пользователями / репутацию:
+ * ожидается, что функция покажет пользователю конкретную ошибку по коду ответа. В этом случае функционально код выдает ошибку, но сообщение должно быть более релевантным коду;
+ * ошибка в логотипе или названии компании на главной странице, или опечатки, бросающиеся в глаза и способные повлиять на репутацию компании;
+ * опечатки в контактных данных;
+ * важные ошибки в соглашениях и юридических документах.
+* **Low Priority and High Severity**: Проблема, которая пока не повлияет на бизнес, но имеет большое влияние с точки зрения функциональности:
+ * присутствует серьезный баг, но есть workaround и исправление уже может быть запланировано в следующем релизе или функция будет удалена;
+ * функция генерации годового отчета, которая будет использована только через полгода;
+ * редкость проявления дефекта/сложность воспроизведения для юзеров.
+* **Low Priority and Low Severity**: Любые орфографические ошибки / начертание / несовпадение шрифта в абзаце 3-й или 4-й страницы заявки, а не на главной или титульной странице / заголовке. Эти дефекты возникают, когда это не влияет на функциональность, но все же в небольшой степени не соответствует стандартам. Обычно сюда классифицируются косметические ошибки или, скажем, размеры ячейки в таблице пользовательского интерфейса:
+ * в политике конфиденциальности веб-сайта есть орфографическая ошибка;
+ * страница часто задаваемых вопросов загружается очень долго;
+ * семейство шрифтов, размер шрифта, цвет или орфографическая ошибка в приложении или отчетах.
+
+Источники:
+
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). Раздел 2.5
+* [Defect Severity And Priority In Testing With Examples And Difference](https://www.softwaretestinghelp.com/how-to-set-defect-priority-and-severity-with-defect-triage-process/)
+* [Difference Between Defect Severity And Priority In Software Testing](https://www.softwaretestingmaterial.com/what-is-the-difference-between-severity-and-priority-in-software-testing/#What-is-Priority)
+
+Доп. материал:
+
+* [Серьезность и приоритет багов - в чем разница?](https://testengineer.ru/sereznost-i-prioritet-bagov-v-chem-raznica/)
+* [Про Severity - серьезно и несерьезно](https://www.software-testing.ru/library/testing/testing-for-beginners/2100-severity-)
+* [Про баги, алерты и басню «Волки, волки»](https://t.me/shooandendlessagony/90)
diff --git a/obshee/tekhniki-ocenki-testov-ocenka-trudozatrat-na-testirovanie-test-estimation.md b/obshee/tekhniki-ocenki-testov-ocenka-trudozatrat-na-testirovanie-test-estimation.md
new file mode 100644
index 0000000..d8b244f
--- /dev/null
+++ b/obshee/tekhniki-ocenki-testov-ocenka-trudozatrat-na-testirovanie-test-estimation.md
@@ -0,0 +1,212 @@
+# Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
+
+_Оценка затрат на тестирование (test estimation): Рассчитанная аппроксимация результатов, связанных с различными аспектами тестирования (например, затраченные усилия, дата завершения, связанные затраты, число тестовых сценариев, и т.д.), результаты которой могут использоваться даже когда входные данные неполные, неопределенные или неточные. (ISTQB)_
+
+Test Estimation - это управленческая деятельность, которая приблизительно показывает, сколько времени и денег потребуется для выполнения задачи. Оценка усилий для теста (Estimating effort) является одной из основных и важных задач в управлении тестированием (Test Management).
+
+Мы поговорим о планировании в прогнозирующих методологиях, потому что в них есть время попланировать до того, как проект начался. В гибких же методологиях все происходит «здесь и сейчас»: не только регулярный planning, но и initial planning, как правило, им занимается менеджмент. Это отдельная тема.
+
+Если мы говорим о прогнозирующих методологиях, то здесь могут быть целые этапы, которые вы можете наблюдать на слайде. Вот, к примерe, первый этап - Incention - он может занимать до полугода. И это период, когда не программируют и толком не занимаются требованиями. Кто может согласиться на то, когда нам платят, а мы толком ничего не делаем? Это может быть военная, медицинская промышленность. Это могут быть глобальные проекты, от которых зависит жизнь людей, и период разработки примерно составляет от 2-ух до 5-7 лет. Обычно же на планирование уходит около 2-ух недель, но зачастую это просто «завтра».
+
+Что такое планирование тестирования? Для тест-лида, это не только время, но и что, как и где тестировать.
+
+Планирование тестирования:
+
+* Определение требований к тестам;
+* Оценка рисков;
+* Разработка стратегии тестирования;
+* Определение ресурсов;
+* Разработка Тест Плана;
+* Создание графика работ.
+
+Каждый этот вопрос достоин рассмотрения. Но мы поговорим о маленьком пункте «Создание графика работ». Конечно, о тестирование можно просто сказать, но лучше показать и как-то формализовать свою аргументацию. Сейчас поговорим именно об этом. Конечно, планирование невозможно без оценки результатов - это и есть наша основная проблема.
+
+«Мы не умеем оценивать!» - команда может вам заявить такое, что джуниор, что опытный специалист. Причину видят в отсутствие определенных методов. Это очень большое заблуждение. Методы есть:
+
+Требующие детальной математической проработки:
+
+* [Метод оценки по 3 точкам (Three Point Estimation)](https://habr.com/ru/post/248325/);
+* [Широкополосный метод Дельфи (Wideband Delphi technique)](https://www.tutorialspoint.com/estimation\_techniques/estimation\_techniques\_wideband\_delphi.htm);
+* [Анализ функциональной точки/тестовой точки (Function Point/Testing Point Analysis)](https://www.sites.google.com/site/sqafordummies/information-technology/function-pointanalysis);
+* [Методика точки случая использования (Use Case Point Method)](https://www.mountaingoatsoftware.com/articles/estimating-with-use-case-points);
+* [Модель издержек разработки (COCOMO - COnstructive COst MOdel)](https://ru.wikipedia.org/wiki/COCOMO);
+* [Генетическая модель оценки](https://pandia.ru/text/78/371/675.php).
+
+Это математические методы, но я не видела ни одной компании, которая бы использовала их. Их основные минусы:
+
+* Они занимают много времени
+* Они трудоемкие
+* Они не дают результат.
+
+Почему?
+
+Потому что планирование должно быть гибким. Потому что сложно рассчитываемый план может нарушиться только из-за того, что кто-то не пришел или заболел. Пересчитывать? Вряд ли! Поэтому мы поговорим о методах, которыми вы уже пользуетесь, но не всегда осознаете!
+
+Наиболее простые в использовании:
+
+* ПВН (пальцем в небо), или метод проб и ошибок;
+* Аналогии и рекомендации экспертов;
+* [Иерархическая структура работ (WBS - Work Breakdown Structure)](https://www.workbreakdownstructure.com);
+* Процентное отношение к разработке;
+* [Процентное распределение (Percentage Distribution)](https://www.tutorialspoint.com/estimation\_techniques/estimation\_techniques\_testing.htm#:\~:text=Development%20Effort%20/100)-,Percentage%20Distribution,-In%20this%20technique);
+* [Методики, основанные на опыте (Ad-hoc method/Experience-based estimation)](https://existek.com/blog/how-calculate-man-hours-software-project-explanation-example/#:\~:text=Experience%2Dbased%20estimation).
+
+Наше любимое - метод проб и ошибок. Все мы им часто пользуемся. Нужно понимать, чем он отличается от метода экспертных оценок. Если вы уже работали с проектом, он вам знаком и что-то тестировали, то вы уже делаете как эксперт. Если вы не делали это для тестирования, не работали с проектом и никогда не сталкивались с этой областью или заказчиком, то вы оцениваете полностью пальцем в небо. В этом большая разница.
+
+Мой любимый метод - структура декомпозиции работ. Это наименее трудоемкий, но формализованный метод для оценки. Что подразумевается? Вам нужно просто дробить вашу работу до той минимальной, которую очень легко оценить и даже учиться этому не нужно.
+
+Например, протестировать авторизацию. Буква «о» не проходит - можно сходу сказать 5 мин для себя. Это минимальная единица. Такое может определить даже человек, который работает всего пару месяцев. Плюс в таком методе - вам сложнее что-то забыть.
+
+Берешь свои требования, и большую задачу, делишь их на 3 части, например: тестирование полей, тестирование кнопочек, тестирование локализации, тестирование перфоманса и тестирование по видам, методам, областям. Дробите дальше: по вводам чисел, букв, символов и т.д.
+
+
+
+Обратите внимание на диаграмму, здесь приведена статистика для сайтов от полугода - года. Программирование занимает от 20% до 40% разработки, это не тоже самое что 20-40% от проекта, это в среднем 15% от проекта. Тестирование никогда не занимает 15% от продукта. Если у вас не закладывают столько время для тестирования, то закладывайте хоть сколько-нибудь. Желательно выяснить статистически какой процент от проекта занимает тестирование и это применимо, если у вас стабильные версии релизов, постоянный объем продуктов один и тот же.
+
+Решение проблемы:
+
+* Обучаем новичков:
+ * Хронометраж;
+ * Анализ.
+* Создаем универсальный Estimation Check List для портфеля проектов;
+* НЕ ругаем за ошибки в оценках.
+
+Для этого не нужно ходить на тренинги, как-то же оцениваете, запишите свои оценки и посмотрите, сколько это заняло времени реально. Помогают разные трейлеры/приложения, которые помогают записывать время. Или примерно в днях запоминайте. Когда вы сами поймете, сможете научить свою команду. Очень важно, когда вы пытаетесь уговорить команду оценивать, очень важно не ругать ее за эти оценки. Чаще всего люди не хотят оценивать, потому что боятся, что вы можете к ним придраться. Пока не зафиксировано все, они вам ничего не должны.
+
+Объясните своим сотрудникам, что любая неправильная оценка лучше чем ее отсутствие. Иначе вы как тест-лид не знаете ничего, не можете соотносить ресурсы и так далее. Хвалите, если они даже ошиблись. Скажите: «Ты ошибся в 2 раза. а я ошибся в 3!». Но ошибки не пропускайте, сядьте и сравните, сколько запланировано было, сколько времени потребовалось в реальности, где был big fail, и на что потребовалось больше всего времени. Самое важное - этот анализ, когда человек сам осознает, что он не учел. Тут как раз и нужна декомпозиция работ, чтобы ничего не забыть.
+
+Тут нам может помочь - «незабудка для тестировщика».
+
+* Ознакомление/исследование;
+* Ревизия спецификации;
+* Написание тестовой документации (чек-лист, тест кейсы);
+* Подготовка данных;
+* Выполнение тестов + рекомендации от программистов;
+* Буфер/Риски.
+
+Первое, что мы сделали повесили это каждому на рабочее место. Она подходит для оценки баги и оценки задач. Она верхнеуровневая и подходит для глобальных задач.
+
+И вот это уже для тест-лидов и экспертов, которые оценивают очень большие задачи, особенно, когда до завтра нужно оценить проект из крупных 20 задач.
+
+Вы не пойдете ко всем тестировщикам, вы пойдете к первому опытному и спросите: «Давайте оценим - сколько это займет». Такой Estimation чек-лист (чек-лист по оценке), чтобы ничего не забыть. Для каждого проекта он свой. Накидайте список всех видов и типов тестирования, которыми вы пользуетесь, потому учтите, на что вы тратите время - время на анализ требований, общение с клиентами, программистами, на документирование, создание тест-кейсов, тест-планов. А потом проставляйте в чек листе, что вам нужно и не нужно.
+
+Следующая проблема - мы не хотим оценивать. Что делать с этими людьми, а вам очень нужно?
+
+Сделайте все оценки сами и используйте их для планирования. Повышайте свои скилы + это интересно знать, насколько хорошо, вы можете прогнозировать. Смотрите на задачу и оценивайте, чем лучше вы оцениваете, тем важнее вы для вашего тест-лида. Удивите свою команду и покажите, что вы можете предсказать то, что команда не знает!
+
+Давайте примем для себя, что планирование - это оптимальное распределение ресурсов, кроме оценки. Без оценки - планирование не имеет смысла.
+
+_Планирование - оптимальное распределение ресурсов для достижения поставленных целей, совокупность процессов, связанных с постановкой задач и действий в будущем. (с) Википедия._
+
+Важно кто выполняет оценки. На вас и вашего тест-лида, менеджера и продакт менеджера очень сильно влияет неопределенность, вот эти все факторы влияют на время завершения проекта.
+
+
+
+Вы скажете, как я как тест-лид, отвечаю за финансы? Все очень просто. Если вы включите 4 тестировщика в проект, то зарплату надо платить четверым, если троим, то соответственно, меньше. Это банальный уровень, но вот если ваша компания заключает договора о штрафах за просроченный проект, то там финансовые показатели очень большие. Поэтому каждый из этих показателей влияет на время окончания проекта.
+
+Поэтому каждый из этих показателей влияет на время окончания проекта. И в таких условиях хотелось бы иметь что-то, что помогало бы отвечать на такой сложный вопрос.
+
+Тут нам поможет сетевой график работ и Диаграмма Ганта.
+
+
+
+Вот на слайде сейчас график работ, который состоит из периода и задач. Это диаграмма для визуализации ваших работ, чтобы не нужно было всматриваться в табличку. Удобнее посмотреть на красивую диаграмму, с которой проще работать. Все это вместе поможет нам создать метод критического пути.
+
+Есть теория графов - это метод прохождения пути с наиболее тяжелыми весами. В данном случае «весы» - это оценки. Путь состоит из работ.
+
+Если аксимировать это на как управление проектами, то это будет набор задач от начала проекта до конца проекта, которые не имеет запаса по времени. Красненькое - это критический путь. Если вы нарушите сроки выполнения этих работ хоть на час, то релиз задержится на час, если на 2 дня, то значит на 2 дня задержится релиз. Зачем это нужно? Вам важно понимать какие задачи лежат на этом пути, потому что приходит к вам на середине пути тестировщик просит выходной, но оказывается он выполняет работу на критическом пути и от того, что его не было, релиз сдвинулся на 1 день. Метод Критического пути дает нам возможность предвидеть наступление таких критических работ, осознавать, что происходит в проекте.
+
+Давайте опишем основные шаги, которые мы делаем для составления плана.
+
+* Решить, что будем тестировать;
+* Сделать оценки;
+* Заполнить сетевой график работ, построить Диаграмму Ганта;
+* Проставить логические связи между работами;
+* Назначить ресурсы;
+* Определить Критический путь;
+* Проставить ресурсные связи;
+* Оптимизировать ресурсы (количество исполнителей).
+
+Это очень важно понять. Зачастую именно такой график позволяет понять взаимосвязь ресурсов и невозможность выполнения 400 часового плана сотней тестировщиков за 4 часа. Время тратится на подготовку данных, изучение проекта, анализ требований, общения с программистами.
+
+Все ли мы учли? Если нет, то что осталось и где это учитывать? Не забываем:
+
+* Отпуска, праздники;
+* Баги
+ * Время на заведение;
+ * Время на регрессию;
+ * Статистическое приближение;
+* Буфер
+ * На задачу или проект?
+ * %?
+* Риски;
+* Исполнители;
+ * Разделение;
+ * Опыт;
+* Если версия не первая;
+
+Менеджер это учитывает в своем буфере. Туда может войти и то, что нет тестового окружения, программист использовал другую технологию, время на заведение багов.
+
+Часто встречается проблема, когда проект для тестирования уже отдается без буфера, поэтому рассчитывайте буфер для программистов и тестировщиков отдельно, тогда будет ясно, кто его использовал.
+
+Те, кто уже планирует, обратите внимание, что нельзя применять Диаграмму Ганта для группы проектов, если у вас общие ресурсы.
+
+Если у вас общий архитектор, и он нужен на все проекты, то такое может не сработать.
+
+Его преимущества, когда у вас ресурсы не пересекаются сразу во всех проектах. Их много, так вы можете управлять своими ресурсами, понимать, где они находятся. Но вам важно, имеет ли это смысл для вашей компании.
+
+Преимущества:
+
+* Позволяет рассчитать стоимость и сроки проекта, основываясь на численных оценках;
+* Дает представление о занятости ресурсов;
+* Позволяет эффективнее распределять ресурсы между проектами;
+* Инструмент оптимизации сроков проекта;
+* Является наглядными документами для руководства и заказчика;
+* Если заказчик заинтересован в использовании наглядных графиков, то вы можете говорить о том, что так вам легче соблюдать обязательства перед ним, у вас будет четкий аргумент.
+
+Если заказчик заинтересован:
+
+* Соблюдаем обязательства;
+* Не приносим убытки;
+* Расширяем возможности;
+* Не экономим на качестве;
+* Это будет полноценное время для качественного тестинга, и вы отдадите такой продукт, за который не будет стыдно.
+
+Если заказчик НЕ заинтересован:
+
+* Сохраняем нервы Лида;
+* Развиваем свою команду;
+* Внедряем фишечки;
+* Разрабатываем свои инициативы;
+* Получаем удовольствие от качества;
+* Вы можете повышать качество, тратить время на совершенствование вашей команды, пригласить кого-то из тест-клуба, внутренний проект по обучению, наконец, заняться документацией.
+
+Нужно очень четко это контролировать. Сколько по времени занимает модификация этого плана? Это гибкий план, поэтому изменения должны производиться раз в неделю. Если это автоматизировано, то ваше время будет уходить только на оптимизацию. В компаниях, где этот процесс не автоматизирован, выясняют один вопрос: «Сколько времени осталось на задачу?». Им не интересно, что помешало, важно сколько времени осталось, и как поменять план. Следовательно, если у вас 20 тестировщиков, то придется менять 20 строк.
+
+Ну и выводы:
+
+* Планирование - совокупность процессов по:
+ * Созданию стратегии тестирования;
+ * Оценки трудозатрат;
+ * Прогнозированию сроков;
+ * Назначению и оптимизации ресурсов;
+ * Контролю выполнения задач;
+* Оценка трудозатрат и оценка сроков - не одно и тоже;
+* Большинство этапов можно автоматизировать.
+
+Планирование это здорово, так как все можно автоматизировать, помните, что планирование сроков и оценка трудозатрат не одно и то же.
+
+Источники:
+
+* [Планирование трудозатрат на тестирование - доклад с SQA Days 15](https://habr.com/ru/company/sqalab/blog/239011/)
+
+Доп. материал:
+
+* [Подборка статей от Huib Schoots](https://www.huibschoots.nl/wordpress/?page\_id=441#:\~:text=by%20Michael%20Bolton-,Test%20Estimation,-%3A)
+* Стив Макконнелл - “Сколько стоит программный проект”
+* [Александр Александров - Оценка трудозатрат на тестирование в проектах сопровождения](https://www.youtube.com/watch?v=KFmjP4f-t9s)
+* [Эстимация в тестировании / Оценка трудозатрат на тестирование](https://www.youtube.com/watch?v=CfHBhmtES1g)
+* [Размышления об оценке тестирования](https://www.software-testing.ru/library/testing/general-testing/2700-thoughts-around-test-estimation)
+* [Truthful Estimations by James Bach at ThinkTest 2015](https://www.youtube.com/watch?v=6\_eKPbigA1o\&ab\_channel=EventsTeam)
+* [Difference Between PERT and CPM](https://www.geeksforgeeks.org/difference-between-pert-and-cpm/?ref=leftbar-rightbar)
+* [Testing When You’re Short on Time](https://qa.world/testing-when-youre-short-on-time/)
diff --git a/obshee/testirovanie-so-sdvigom-vlevo-shift-left-testing.md b/obshee/testirovanie-so-sdvigom-vlevo-shift-left-testing.md
new file mode 100644
index 0000000..869a019
--- /dev/null
+++ b/obshee/testirovanie-so-sdvigom-vlevo-shift-left-testing.md
@@ -0,0 +1,17 @@
+# Тестирование со сдвигом влево (Shift left testing)
+
+Тестирование со сдвигом влево - это практика включения тестирования на более ранних этапах SDLC. Конечная цель состоит в том, чтобы тестировщики работали вместе с командой разработчиков на ранних этапах разработки, чтобы те могли работать над предотвращением проблем до их возникновения, а не выявлять их в конце проекта. Тестируя на раннем этапе, тестировщики могут сократить время, необходимое для проведения тестовых спринтов, могут помочь повысить качество программного обеспечения и помочь устранить фатальные проблемы, которые обычно обнаруживаются в конце.
+
+
+
+Доп. материал:
+
+* [Меньше «сложного» тестирования, больше - «умного» тестирования](https://m.habr.com/ru/company/otus/blog/554638/)
+* [Сочетание Shift-Left и «Традиционной» модели тестирования в будние дни QA](https://habr.com/ru/company/cian/blog/654067/)
+* [Экономим ресурсы и успеваем в срок: зачем подключать QA-инженера в начале работы над фичей](https://habr.com/ru/post/543318/)
+* [Эволюция идеи shift left - shift up and spread: a new testing concept](https://theqalead.com/topics/shift-up-and-spread-a-new-testing-concept-w-iman-benlekehal/)
+* [Shift Left Testing Benefits and Approach](https://www.xenonstack.com/insights/shift-left-testing)
+* [What is Shift Left Testing and Should Your Dev Team Adopt it?](https://hackernoon.com/what-is-shift-left-testing-and-should-your-dev-team-adopt-it)
+* [Shift Left Testing: A Secret Mantra For Software Success](https://www.softwaretestinghelp.com/shift-left-testing-approach/)
+* [Shift Left: Testing from the Onset of the Project](https://blog.gurock.com/shift-left/)
+* [How Shift-RIGHT Testing Can Build Product Resiliency](https://hackernoon.com/how-shift-right-testing-can-build-product-resiliency)
diff --git a/obshee/testovaya-sreda-i-testovyi-stend-test-environment-test-bed.md b/obshee/testovaya-sreda-i-testovyi-stend-test-environment-test-bed.md
new file mode 100644
index 0000000..e7fd501
--- /dev/null
+++ b/obshee/testovaya-sreda-i-testovyi-stend-test-environment-test-bed.md
@@ -0,0 +1,20 @@
+# Тестовая среда и тестовый стенд (Test Environment/Test Bed)
+
+_Тестовое окружение (test environment): Окружение, включающее в себя аппаратное обеспечение, измерительную аппаратуру, имитаторы, программный инструментарий и прочие инструменты, необходимые для проведения теста. (IEEE 610)_
+
+В общем случае среда тестирования - это конфигурация ПО/виртуального контейнера и/или сервера, т.е. эдакая песочница для тестирования. Позволяет не испытывать судьбу с production-версией, а также дает множество возможностей, которые недоступны на боевом окружении. Существует несколько сред:
+
+* Среда разработки (Development Env) - в ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.
+* Среда тестирования (Test Env) - в этой среде работают тестировщики. Тут тестируют новые билды: проверяют функционал, проводят регрессионные проверки, воспроизводят ошибки. Эта среда появляется во время начала динамического тестирования;
+* Интеграционная среда (Integration Env) - иногда реализована в рамках среды тестирования, а иногда в рамках превью среды. В этой среде собрана необходимая для end-to-end тестирования схема взаимодействующих друг с другом модулей, систем, продуктов. Собственно, необходима она для интеграционного тестирования. Поддержка среды - также, как и в случае со средой тестирования
+* Превью среда (Preview, Preprod Env) - в идеале, это среда идентичная или максимально приближенная к продуктивной: те же данные, то же аппаратно-программное окружение, та же производительность. Она используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к «боевым». Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и/или пользователи проводят UAT, а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.
+* Продакшн среда (Production Env) - среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3
+
+Испытательный стенд (Test Bed) - более глобальная сущность и включает в себя operating system, configuration management for the products, hardware, network topology и т. д. Настраиваются в соответствии с требованиями тестируемого приложения. В некоторых случаях испытательный стенд может представлять собой комбинацию тестовой среды и тестовых данных, которые он использует.
+
+Настройка правильной среды тестирования гарантирует успех тестирования ПО. Любые недостатки в этом процессе могут привести к дополнительным затратам и времени для клиента. Следующие люди участвуют в настройке тестовой среды: Системные администраторы, Разработчики, Тестировщики.
+
+Доп. материал:
+
+* [Тестовая среда](https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/testovaia-sreda-2#:\~:text=%D0%A1%D1%80%D0%B5%D0%B4%D0%B0%20%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%E2%80%94%20%D1%8D%D1%82%D0%BE%20%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE,%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D0%B4%D0%BB%D1%8F%20%D0%B2%D1%8B%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%20%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2%D1%8B%D1%85%20%D1%81%D0%BB%D1%83%D1%87%D0%B0%D0%B5%D0%B2.\&text=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0%20%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9%20%D1%81%D1%80%D0%B5%D0%B4%D1%8B%20%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D0%B3%D0%B0%D1%80%D0%B0%D0%BD%D1%82%D0%B8%D1%80%D1%83%D0%B5%D1%82%20%D1%83%D1%81%D0%BF%D0%B5%D1%85%20%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F.)
+* [STLC - настройка тестовой среды](https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/uznaite-stlc/stlc-nastroika-testovoi-sredy)
diff --git a/obshee/verifikaciya-i-validaciya-verification-and-validation.md b/obshee/verifikaciya-i-validaciya-verification-and-validation.md
new file mode 100644
index 0000000..1f1573c
--- /dev/null
+++ b/obshee/verifikaciya-i-validaciya-verification-and-validation.md
@@ -0,0 +1,33 @@
+# Верификация и валидация (Verification and Validation)
+
+_Верификация (verification): Доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены. (ISO 9000)_
+
+_Валидация (validation): Доказанное объективными результатами исследования подтверждение того, что требования для ожидаемого конкретного использования приложения были выполнены. (ISO 9000)_
+
+_Верификация - это подтверждение путем представления объективных доказательств выполнения данным рабочим элементом установленных требований. (ГОСТ 56920)_
+
+_Валидация демонстрирует, что рабочий элемент может использоваться пользователями для решения определенных ими задач. (ГОСТ 56920)_
+
+Верификация - это проверки, выполняемые в процессе разработки ПО для ответа на вопрос: “правильно ли мы разрабатываем продукт?”. Это в т.ч. включает проверку документации: requirements specification, design documents, database table design, ER diagrams, test cases, traceability matrix и т.д. Верификация гарантирует, что ПО разрабатывается в соответствии со стандартами и процессами организации, полагаясь на [reviews](https://www.softwaretestinghelp.com/test-documentation-reviews/) и статические методы тестирования (т.е. без запуска ПО, но, например, с unit/integration tests). Верификация является превентивным подходом (Preventative approach).
+
+| **Этап верификации** | **Действующие лица** | **Описание** | **На выходе** |
+| ----------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| Review бизнес / функциональных требований | Команда разработки / клиент для бизнес-требований | Это необходимый шаг не только для того, чтобы убедиться, что требования собраны и / или корректны, но и для того, чтобы убедиться, выполнимы ли они | Завершенные требования, которые готовы к использованию на следующем этапе - дизайне |
+| Review дизайна | Команда разработки | После создания дизайна команда разработчиков тщательно его просматривает, чтобы убедиться, что функциональные требования могут быть выполнены с помощью предложенного дизайна | Дизайн готов к имплементации |
+| Прохождение кода (Code Walkthrough) | Отдельный разработчик | Написанный код проверяется на наличие синтаксических ошибок. Это более обыденно и выполняется индивидуальным разработчиком на основе кода, разработанного им самим | Код готов к unit testing |
+| Проверка кода (Code Inspection) | Команда разработки | Это уже более формально. Специалисты в данной области и разработчики проверяют код, чтобы убедиться, что он соответствует бизнес-целям и функциональным целям | Код готов к тестированию |
+| Test Plan Review (внутренней командой QA) | QA команда | План тестирования проходит внутреннюю проверку командой QA, чтобы убедиться в его точности и полноте | Test plan готов к передаче внешним командам (Project Management, Business Analysis, development, Environment, client, etc.) |
+| Test Plan Review (внешнее) | Project Manager, Business Analyst, and Developer | Формальный анализ test plan, чтобы убедиться, что график и другие соображения команды QA соответствуют другим командам и всему проекту | Подписанный или утвержденный test plan, на котором будет основываться деятельность по тестированию |
+| Test documentation review (Peer review) | Члены команды QA | Экспертная проверка - это когда члены команды проверяют работу друг друга, чтобы убедиться, что в самой документации нет ошибок. | Документация по тестированию готова к передаче внешним командам |
+| Test documentation final review | Business Analyst and development team. | A test documentation review чтобы убедиться, что test cases охватывают все бизнес-условия и функциональные элементы системы | Тестовая документация готова к выполнению |
+
+Валидация - это процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям клиентов, т.е. отвечает на вопрос: “правильный ли мы разработали продукт?”. Валидация является динамическим тестированием, т.е. происходит с помощью выполнения кода и прогона тестов на нём (UAT/CAT, usability, всё что угодно). Валидация является реактивным подходом (Reactive approach).
+
+Если попробовать привести очень упрощенный пример, представим блюдо в ресторане. Верификация будет включать проверку технологической карты, оценку процесса приготовления (температуры, времени и т.п.). На протяжении этого процесса можно будет примерно быть уверенным, что блюдо получится именно тем, какое задумывалось и в итоге формально мы его приготовим. Валидация же - это, по сути, попробовать приготовленное блюдо, чтобы удостовериться, действительно ли получилось то, что ожидал бизнес и клиент.
+
+Источник: [Exact Difference Between Verification And Validation With Examples](https://www.softwaretestinghelp.com/what-is-verification-and-validation/)
+
+Доп. материал:
+
+* [В. В. Кулямин - Работа на тему “Методы верификации программного обеспечения”](https://www.ispras.ru/publications/methods\_of\_software\_verification.pdf)
+* [Форум тестировщиков: Verification & Validation - что это такое?](https://software-testing.ru/forum/index.php?/topic/979-verification-validation-chto-eto-takoe/)
diff --git a/poleznye-ssylki/README.md b/poleznye-ssylki/README.md
new file mode 100644
index 0000000..f3f28e1
--- /dev/null
+++ b/poleznye-ssylki/README.md
@@ -0,0 +1,2 @@
+# Полезные ссылки
+
diff --git a/poleznye-ssylki/spisok-poleznykh-resursov-na-raznykh-platformakh.md b/poleznye-ssylki/spisok-poleznykh-resursov-na-raznykh-platformakh.md
new file mode 100644
index 0000000..e3e1195
--- /dev/null
+++ b/poleznye-ssylki/spisok-poleznykh-resursov-na-raznykh-platformakh.md
@@ -0,0 +1,262 @@
+# Список полезных ресурсов на разных платформах
+
+**Telegram**:
+
+Must have (потому что [раз](https://t.me/general\_it\_talks/161), [два](https://www.youtube.com/watch?v=Rf9KJbSEmuI))! Каналы это: знакомство с коммьюнити, живое общение, уникальный опыт тысяч коллег; богатая история сообщений, где поиском по истории сообщений можно найти все что угодно; в шапке каждого канала закреплено сообщение со своим набором полезностей. Кроме того, некоторые каналы специализируются на мониторинге нового полезного материала с основных порталов, так что можно даже не погружаться с головой в хабр, доу, медиум и т.п., вам отберут все самое полезное. В конце концов, в этих каналах публикуются анонсы грядущих онлайн-мероприятий, чтобы ничего не упустить.
+
+* Большая подборка чатов @[it\_chats](https://t.me/it\_chats)
+* [Список интересных групп, каналов и ботов телеграма](https://github.com/goq/telegram-list)
+* Всем новичкам сюда! Тренировочные собеседования, интересные обсуждения @[qa\_interviews](https://t.me/qa\_interviews)
+* Огромный чат для новичков @[qajuniors](https://t.me/qajuniors)
+* Огромный чат для уже работающих @[qa\_ru](https://t.me/qa\_ru)
+* Чаты по геймдеву @[qa\_gamedev](https://t.me/qa\_gamedev), @[qa\_yashik](https://t.me/qa\_yashik)
+* Обсуждение курсов, отзывы о них @[qa\_courses](https://t.me/qa\_courses), @[qa\_course](https://t.me/qa\_course)
+* Тут можно размещать свое резюме @[qa\_resumes](https://t.me/qa\_resumes)
+* [15 отличных Телеграм-каналов для поиска работы на удаленке](https://habr.com/ru/post/654179/)
+* Вакансии для начинающих специалистов @[jobforjunior](https://t.me/jobforjunior)
+* Вакансии для Тестировщиков @[forallqa](https://t.me/forallqa)
+* Вакансии инженеров по тестированию производительности @[qaload\_job](https://t.me/qaload\_job)
+* О найме тестировщиков @[qa\_hiring](https://t.me/qa\_hiring)
+* Отзывы о компаниях @[qa\_bad\_company](https://t.me/qa\_bad\_company), @[qa\_good\_company](https://t.me/qa\_good\_company)
+* Чат для ревью резюме @[qaReview](https://t.me/qaReview)
+* Обсуждение финансов @[qa\_fin](https://t.me/qa\_fin)
+* Публикация книг @[booksqa](https://t.me/booksqa)
+* Авторский бложик @[shooandendlessagony](https://t.me/shooandendlessagony)
+* Еще один @[general\_it\_talks](https://t.me/general\_it\_talks)
+* Флудилки @[qachanellflood](https://t.me/qachanellflood) @[qaflood](https://t.me/qaFlood)
+* Чаты про производительность и инструменты @[qa\_load](https://t.me/qa\_load), @[loadland](https://t.me/loadland)
+* Jobs abroad - Работа за рубежом @[jobs\_abroad](https://t.me/jobs\_abroad)
+* Группа для QA интересующихся релокацией @[QA\_relocate](https://t.me/QA\_relocate)
+* [QA Sisters](https://www.sites.google.com/view/qasisters) - женское комьюнити
+* Канал подкаста Radio QA @[radioqa](https://t.me/radioqa)
+* Чат @[qalliance](https://t.me/qalliance)
+* Чат о тестировании ПО @[qa\_chatka](https://t.me/qa\_chatka)
+* Канал по тестированию ПО @[protestinginfo](https://t.me/protestinginfo)
+* Группа для поиска менторов и менти в области QA @[qa\_mentors](https://t.me/qa\_mentors)
+* Задания для подготовки к собеседованиям для тестировщиков @[qa\_sobes](https://t.me/qa\_sobes)
+* Склад полезных материалов и ссылок @[qa\_sklad](https://t.me/qa\_sklad)
+* Канал для тестировщиков, как для новичков, так и для бывалых @[qa\_and\_it](https://t.me/qa\_and\_it)
+* Чаты по penetration testing (pen test, pentest):
+ * @[qa\_security](https://t.me/qa\_security)
+ * @[true\_secator](https://t.me/true\_secator)
+ * @[pentesting\_channel](https://t.me/pentesting\_channel)
+ * @[pentesting\_chat](https://t.me/pentesting\_chat)
+ * @[AAAAAE\_Cu9rTSOgF7uolrg](https://t.me/joinchat/AAAAAE\_Cu9rTSOgF7uolrg)
+ * @[hackerlib](https://t.me/hackerlib)
+* Статьи, ссылки, фан:
+ * @[qa\_wiki](https://t.me/qa\_wiki)
+ * @[serious\_tester](https://t.me/serious\_tester)
+ * @[qa\_pro](https://t.me/qa\_pro)
+ * @[qa\_chillout](https://t.me/qa\_chillout)
+ * @[yetanotherqa](https://t.me/yetanotherqa)
+ * @[sedoitester](https://t.me/sedoitester)
+ * @[testerinlife](https://t.me/testerinlife)
+ * @[testerofqa](https://t.me/testerofqa)
+
+**Youtube-каналы**:
+
+* [Вадим Ксендзов (тренировочные собеседования!)](https://www.youtube.com/channel/UC6hNNlCXv1ZgdGpziNf83RA)
+* [Artsiom Rusau QA Life (бесплатный курс!)](https://www.youtube.com/c/ArtsiomRusauQALife)
+* [okiseleva (бесплатный курс!)](https://www.youtube.com/playlist?list=PLzy4cPXOwbY6bGOFj29LvzAjyFvbtUv3o)
+* [Podlodka Podcast](https://www.youtube.com/channel/UCOei1E1Vqq10S913OEqTWGw)
+* [Heisenbug](https://www.youtube.com/channel/UCX6fjZa167tSy\_4ryTLcOBw/videos)
+* [Vladislav Orlikov](https://www.youtube.com/user/vldcorp/videos)
+* [QA START UP](https://www.youtube.com/channel/UCAlCZby7zJHzyhOmS8issDQ)
+* [Компания DINS](https://www.youtube.com/channel/UCmJYB3hvbF3AlVh9HFeXX3A)
+* [Hillel IT School](https://www.youtube.com/c/HillelITSchool)
+* [QAGuild](https://www.youtube.com/channel/UCHtyBZ2XbtsRmNiAxh48RGg)
+* [QA Testing Life](https://www.youtube.com/channel/UCq-PbXBWej-lxniUkyEmUxw/featured)
+* [Mikhail Portnov](https://www.youtube.com/channel/UCDbzkNMBNZJBKP4C-9qGw4Q)
+* [Alexei Barantsev](https://www.youtube.com/c/AlexeiBarantsev/featured)
+* [LearnQA](https://www.youtube.com/c/learnqa/featured)
+* [Леша Маршал](https://www.youtube.com/channel/UCTVciJQp8eYwKLLQIl-iSJw)
+* [Тестирование](https://www.youtube.com/channel/UC9VeXtf7fcCJUfmZ\_cyweXA)
+* [Fest Group](https://www.youtube.com/channel/UClTnsvgTiW2YcfP1tcI2oKA)
+* [Andrey Sozykin](https://www.youtube.com/c/AndreySozykinCS/featured)
+* [All about QA](https://www.youtube.com/channel/UCHlMAfOwLZkSg3n1nr4nftw/videos)
+* [Look Live UI](https://www.youtube.com/channel/UCf485yG-ns2s379MPd9aCUA/videos)
+* [Test Club RU](https://www.youtube.com/c/TestClubRU/videos)
+* [Нагрузочное тестирование с нуля!](https://www.youtube.com/channel/UCuV0AwsyjhIzO16Rcxic-UQ/featured)
+* [edureka!](https://www.youtube.com/c/edurekaIN/videos)
+* [QA With Natalia](https://www.youtube.com/user/natasturza/featured)
+* [Bogdan Ovsiyuk](https://www.youtube.com/channel/UC6SHu94JlUfSk5B5TwJwY7A)
+* [Alex QA](https://www.youtube.com/channel/UC4FsI-c69O8ui\_5kwM3dalA/featured)
+* [Плейлист “Качество и Тестирование ПО” от VK](https://www.youtube.com/watch?v=3MBT9O6i0jk\&list=PLrCZzMib1e9pDKLsabJYuODdVJrHYc4Jd)
+* [Плейлист “Тестирование мобильных и веб-приложений”](https://www.youtube.com/playlist?list=PL0sm2CxWDkuuVRlcP31lWBLAafcQIikyb)
+
+**Web**:
+
+* [https://software-testing.ru/](https://software-testing.ru)
+* [https://protesting.ru/](https://protesting.ru)
+* [https://www.ministryoftesting.com/](https://www.ministryoftesting.com)
+* [https://artoftesting.com/](https://artoftesting.com)
+* [http://www.mobileappstesting.com/](http://www.mobileappstesting.com)
+* [https://www.softwaretestingmaterial.com/](https://www.softwaretestingmaterial.com)
+* [https://www.stickyminds.com/](https://www.stickyminds.com)
+* [https://mobilenativefoundation.org/](https://mobilenativefoundation.org)
+* [https://testing.googleblog.com/](https://testing.googleblog.com)
+* [Хроники тестировщика](https://w-bf.livejournal.com/tag/lessons%20learned%20in%20software%20testing)
+* [StackExchange q\&a - Software Quality Assurance & Testing](https://sqa.stackexchange.com)
+* [https://testengineer.ru/](https://testengineer.ru)
+* [http://wannatest.ru/](http://wannatest.ru)
+
+**Книги**:
+
+* Очень хвалят вот эту [подборку](http://okiseleva.blogspot.com/2014/02/blog-post\_6.html?m=1);
+* Если выделить самые советуемые книги в коммьюнити, то получится следующее:
+ * Самая спорная книга для новичков Р. Савин - “Тестирование дот ком”. Является скорее вариантом худ. лита “для чайников” на один вечер и может местами быть спорной и устаревшей;
+ * [Святослав Куликов - “Тестирование программного обеспечения. Базовый курс.”](http://svyatoslav.biz/software\_testing\_book/) Самая советуемая книга для начинающих, по сути курс EPAM в виде книги;
+ * Lee Copeland - “A Practitioner's Guide to Software Test Design” (есть в переводе)
+ * Rex Black - “Critical Testing Processes“ (есть в переводе)
+ * Гленфорд Майерс, Том Баджетт, Кори Сандлер «Искусство тестирования программ.»
+* [Лабун Билл - “Дружеское знакомство с тестированием программ](https://bhv.ru/product/druzheskoe-znakomstvo-s-testirovaniem-programm/)”
+* [Ольга Назина - «Что такое тестирование. Курс молодого бойца»](http://www.testbase.ru/book-beginner)
+* [23 Books for Quality Assurance Professionals](https://medium.com/slalom-build/23-books-for-quality-assurance-professionals-9a7db9945e8)
+* [Переводы lessons learned in software testing](https://w-bf.livejournal.com/tag/lessons%20learned%20in%20software%20testing)
+
+**Курсы**:
+
+Списка и конкретных рекомендаций здесь не будет, т.к. любые названия и рекомендации сочтут за рекламу. Я лишь посоветую обходить стороной разного рода инфоцыган, реклама которых вылезает из каждого утюга и что обещают якобы гарантированное трудоустройство по записанным лекциям за конский ценник или процент от з/п, думаю тут и без конкретики все поймут о каких компаниях речь.
+
+В телеграме есть чат @[qa\_courses](https://t.me/qa\_courses) с обсуждением разнообразных нормальных курсов и отзывами о них, ищите по истории сообщений по хештегам, читайте, выбирайте сами (только держите в уме, что админы и сами авторы некоторых курсов). Также есть таблица с [отзывами](https://docs.google.com/spreadsheets/d/1ORKfTDiBDsloeqXr9qkPTwruzs0PjC2nIx9Fu8U\_j0w/edit) от Артёма Русова.
+
+По поводу всяких sharewood и coursehunter. Использование слитых курсов - это личное дело каждого, ситуации в жизни бывают разные. Но имейте в виду, что в IT пиратство крайне не приветствуется, упоминать такие поступки не стоит, а обсуждение в чатах может легко закончиться баном. Кроме того, вся ценность курсов именно в практике и обратной связи от опытных преподавателей.
+
+Доп. материал:
+
+* Беда “войти в айти” или курсы тестировщика отзывы [часть 0](https://habr.com/ru/post/588360/), [1](https://habr.com/ru/post/588376/), [2](https://habr.com/ru/post/589973/), [3](https://habr.com/ru/post/590249/)
+
+**Мобильные приложения**:
+
+Подборка для Android, с iOS дела не имел. Возможно, указанные в списке приложения есть на обеих платформах.
+
+* [StrimQa - ваш карьерный навигатор!](https://play.google.com/store/apps/details?id=com.strimqa.android.app.strimqa\&hl=ru\&gl=US)
+* [Interview Questions and Answers 2021](https://play.google.com/store/apps/details?id=com.kgsinfoway.interviewapp)
+* [Software Engineering](https://play.google.com/store/apps/details?id=in.softecks.softwareengineering)
+* [QA Wizard подготовка к собеседованию для тестеров](https://play.google.com/store/apps/details?id=com.harrysapps.qainterviewhelper)
+* [Learn Software Testing-Interview questions & quiz](https://play.google.com/store/apps/details?id=wscubetech.softwaretesting)
+* [Software Testing Interview FAQ](https://play.google.com/store/apps/details?id=com.BabithaKG.SoftwareTesting)
+* [Software Testing - QA Learning](https://play.google.com/store/apps/details?id=nir.com.qalearning)
+* [Mobile Testing](https://play.google.com/store/apps/details?id=com.sagayraj.mobiletesting.instructions)
+* [Test Mentor for ISTQB](https://play.google.com/store/apps/details?id=com.istqbtestmentor\&hl=en)
+
+**Другие сборники материала и ответов на вопросы**:
+
+* **Англоязычные**:
+ * [Awesome Testing](https://github.com/TheJambo/awesome-testing#readme)
+ * [ISTQB » Downloads](https://www.istqb.org/downloads/category/)
+ * [Certifications Resources](https://www.softwaretestinggenius.com/certifications-resources/)
+ * [Complete Study Material - ISTQB Certified Tester Foundation Level Exam](https://www.softwaretestinggenius.com/complete-study-material-istqb-certified-tester-foundation-level-exam/)
+ * [Complete Study Material for Certified Tester Advanced Level - All 3 Certifications](https://www.softwaretestinggenius.com/complete-study-material-for-certified-tester-advanced-level-all-3-certifications/)
+ * [ISTQB Certified Tester Scheme / Syllabi](https://www.german-testing-board.info/en/syllabi/istqb-certified-tester-scheme/syllabi/)
+ * [ISO/IEC/IEEE 29119-1:2013(en)](https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:29119:-1:ed-1:v1:en)
+ * [BBST Foundations of Software Testing](http://www.testingeducation.org/BBST/foundations/)
+ * [Satisfice - resources](https://www.satisfice.com/resources)
+ * [Huib Schoots - Great Resources](https://www.huibschoots.nl/wordpress/?page\_id=441)
+ * [Martin Fowler - Software Testing Guide](https://martinfowler.com/testing/)
+ * [RSTE Appendices](https://www.satisfice.com/download/rst-appendices)
+ * [Cem Kaner & James Bach - Black Box Software Testing: Foundations](http://www.testingeducation.org/BBST/foundations/BBSTFoundationsNov2010.pdf)
+ * [RST for Yourself](https://rapid-software-testing.com/rst-for-yourself/)
+ * [Guru99 Software Testing Tutorial: Free QA Course](https://www.guru99.com/software-testing.html)
+ * [30 Things Every New Software Tester Should Learn](https://www.ministryoftesting.com/dojo/lessons/30-things-every-new-software-tester-should-learn)
+ * [What Is Software Testing? 100+ Free Manual Testing Tutorials](https://www.softwaretestinghelp.com/manual-testing-tutorial-1/)
+ * [IEEE Guide to the Software Engineering Body of Knowledge](https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf)
+ * [I am a Software Tester](https://www.xmind.net/m/s3Nt/#)
+ * [QA\_Links](https://github.com/skydive-dz/QA\_Links/blob/master/Links.md)
+* **Русскоязычные**:
+ * [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Часть 1: “Понятия и определения”](https://docs.cntd.ru/document/1200134996)
+ * [ГОСТ Р 56921-2016/ISO/IEC/IEEE 29119-2:2013 Часть 2: “Процессы тестирования”](https://docs.cntd.ru/document/1200134997)
+ * [ГОСТ Р 56922-2016/ISO/IEC/IEEE 29119-3:2013 Часть 3: “Документация тестирования”](https://docs.cntd.ru/document/1200134998)
+ * [RSTQB » Downloads](https://www.rstqb.org/ru/istqb-downloads.html)
+ * [Подборка от Артёма Русова](https://docs.google.com/spreadsheets/d/1qaCuDQMQFB7yGO8N4C\_aC2ncyRobXkriReRsp-UTOE4/edit#gid=49997284)
+ * [Подборка от сообщества QA juniors](https://docs.google.com/spreadsheets/u/0/d/18giT\_NbYLo9yc7yArAeTMnB8W9m3EqUvwftrfZMUyWQ/edit)
+ * [Подборка от сообщества QA sisters](https://docs.google.com/spreadsheets/d/1jfC3vrW1NFAZz91Xp7rL4RqFhVoSJTBbbSs0JHiu0eg/edit#gid=0)
+ * [Всё о QA: 80 бесплатных материалов по грамотному тестированию](https://tproger.ru/digest/free-software-testing-books/)
+ * [Что должен уметь начинающий тестировщик](http://testbase.ru)
+ * [Полезные ссылки для тестировщика](https://github.com/Kakha-Khinikadze/Links-QA/blob/master/Links.md)
+ * [Библиотека QA](https://github.com/ultragreatester/how-to-qa)
+ * [Обзор частых вопросов по тестированию ПО на собеседованиях и ответы на них](https://habr.com/ru/post/257529/)
+ * [Ресурсы для развития тестировщика 2021](https://gcoder.ru/resursy-dlya-razvitiya-testirovshchika-2021/)
+ * [14 самых вдохновляющих статей о тестировании ПО, которые я когда-либо читал](https://habr.com/ru/company/otus/blog/551266/)
+ * [Что почитать продолжающему тестировщику (часть 2)](https://tproger.ru/articles/chto-pochitat-prodolzhajushhemu-testirovshhiku-chast-2/)
+ * [Тестирование. Фундаментальная теория](https://dou.ua/forums/topic/13389/)
+ * [Фундаментальная теория тестирования](https://habr.com/ru/post/549054/)
+ * [Теория тестирования ПО просто и понятно](https://habr.com/ru/post/587620/)
+ * [Wikipedia - Тестирование программного обеспечения](https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5\_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE\_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F)
+ * [Mindmaps for QA](https://drive.google.com/drive/folders/1WvTRoPDROUkqXUY5mXQpKgM\_U3KFM11h?usp=sharing)
+ * [Практическое приложение базовой теории](https://www.youtube.com/watch?v=Pz7llk9Qff8)
+
+**Словари терминов (в т.ч. элементов интерфейса)**:
+
+* [Словарик айтишника или Что? Где? Куда? Часть 1](https://habr.com/ru/company/wrike/blog/475558/)
+* [IT-словарик для не-айтишников](https://habr.com/ru/company/jugru/blog/538698/)
+* [https://docs.google.com/spreadsheets/d/1LgytNrl7ep9wlr3A\_3u0NitQsrZzKhEQwC-OTQfbLAM/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1LgytNrl7ep9wlr3A\_3u0NitQsrZzKhEQwC-OTQfbLAM/edit?usp=sharing)
+* [https://docs.google.com/spreadsheets/d/1r5Ek83V4IHkOsW52DyVT8iJepR20oZu\_Jy5vAkq7SrI/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1r5Ek83V4IHkOsW52DyVT8iJepR20oZu\_Jy5vAkq7SrI/edit?usp=sharing)
+* [Элементы интерфейса сайта](https://borodaboroda.com/blog/elementy-interfejsa-sajta/)
+* [UI-элементы и жесты в мобильных приложениях](https://habr.com/ru/company/youla/blog/540768/)
+* [Словарь тестировщика](https://vk.com/@zapiskisedogotestera-slovar-testirovschika)
+* [User Interface Elements Every Designer Should Know](https://www.uxpin.com/studio/blog/user-interface-elements-every-designer-should-know/)
+* [Glossary WEB - project](https://docs.google.com/spreadsheets/d/1TAgu68E-0S1Lxk1mOTRKvetZszBGFwIByeioxbXI3PE/edit#gid=0)
+* [Software Testing Dictionary](https://www.tutorialspoint.com/software\_testing\_dictionary/)
+
+**Чек-листы и идеи для тестов**:
+
+* [Читлисты для тестировщика](https://www.youtube.com/watch?v=imQW1DFySm0)
+* [Где брать идеи для тестов (подборка полезных ссылок)](https://habr.com/ru/post/524784/)
+* [Развиваем интуицию в тестировании или где искать баги](https://habr.com/ru/post/572042/)
+* [Как тестировщику не стать обманутым](https://software-testing.ru/library/testing/general-testing/3631-how-to-avoid-being-fooled-in-software-testing)
+* [37 источников тест-идей](https://habr.com/ru/post/537510/)
+* [Checklists Base :)](https://checkvist.com/checklists/476089)
+* [Чек-лист тестирования мобильных приложений](https://www.software-testing.ru/library/testing/mobile-testing/3518-mobile-app-testing-checklist)
+* [Чеклист для тестирования мобильных приложений](https://software-testing.ru/images/stories/library/checklist-mobile-app-testen.pdf)
+* [Дополняем чек-лист тестирования при обновлении иконки и сплеша в мобильных приложениях](https://habr.com/ru/company/funcorp/blog/525538/)
+* [Mobile Testing Checklist](http://www.testingdiaries.com/mobile-testing-checklist/)
+* [Testing Criteria for Android Applications](https://www.appqualityalliance.org/files/AQuA\_testing\_criteria\_for\_Android\_v1.3\_oct\_2\_2012.pdf)
+* [A mnemonic for mobile app testing](https://i.imgur.com/DDWnzbS.png)
+* [Test Mobile Applications with I SLICED UP FUN!](http://www.kohl.ca/articles/ISLICEDUPFUN.pdf)
+* [Mobile App Test Coverage Model : LONG FUN CUP](https://testingideas.wordpress.com/2014/08/17/mobile-app-test-coverage-model-long-fun-cup/)
+* [Testing checklist for mobile applications](http://www.mobileappstesting.com/2012/07/05/testing-checklist-for-mobile-applications/)
+* [iOS App Testing Template](https://ontestpad.com/library/200/ios-app-testing-template)
+* [Getting started with mobile testing](https://www.flickr.com/photos/softwaretestingclub/7159412943/sizes/o/in/photostream/)
+* [Mobile testing in a nutshell](http://apps.testinsane.com/mindmaps/Mobile-Testing-In-a-Nutshell)
+* [Чек-лист для тестирования числового поля](https://okiseleva.blogspot.com/2020/10/blog-post\_28.html#more)
+* [Чек-лист для веб-форм](https://disk.yandex.ru/i/VdGkQ\_oPt7n9xQ)
+* [Чек-лист тестирования WEB приложений](https://habr.com/ru/post/542422/)
+* [Чек-лист - как тестировать поиск](https://habr.com/ru/post/577448/)
+* [Чеклист: 217 пунктов для отличного интернет-магазина](https://vc.ru/marketing/52090-cheklist-217-punktov-dlya-otlichnogo-internet-magazina)
+* [Тестирование оплаты картами](https://telegra.ph/Payment-gateway-ili-testirovanie-platezhnogo-shlyuza-10-01)
+* [Чек-лист API тестов](https://gist.github.com/zeburek/8c165c9e8676945d75d91fe2f2addf8d)
+* [Am I Really Done Testing?](https://www.koreyhinton.com/blog/ios/am-i-really-done-testing.html)
+* [Тестирование новой фичи](https://hsto.org/getpro/habr/upload\_files/079/663/f2f/079663f2fc528456afb1367b4096d266.png)
+* [Как тестировать pop-up сообщения](https://okiseleva.blogspot.com/2021/02/pop-up.html)
+* [Как тестировать письма от системы](https://okiseleva.blogspot.com/2021/02/blog-post\_69.html)
+* [Есть фича. Помогите протестировать!](https://www.youtube.com/watch?v=4S95hZXBhMg)
+* [Как накидать тестов на некий функционал](https://www.youtube.com/watch?v=drO2aI3nLvo)
+* [Как накидать тестов на что-нибудь](https://www.youtube.com/watch?v=cmlI5aJxdwE)
+
+[**Блоги**](https://www.maxshulga.ru/2016/06/useful-testers-resources.html?m=1#:\~:text=%D0%BE%D1%82%20%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D1%8F%20%D0%A1%D0%B0%D1%82%D0%B0%D1%80%D0%B8%D0%BD%D0%B0-,%D0%91%D0%BB%D0%BE%D0%B3%D0%B8,-%D0%BF%D1%80%D0%BE%20%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5):
+
+* [Никита Макаров](http://test-failed.blogspot.ru) - мастер автоматизации, но философские темы у него тоже хорошо удаются.
+* [Леша Виноградов](http://qa-blog.alexei-vinogradov.de) - мастер поднабросить на включенный вентилятор, диджей RadioQA
+* [Леша Лупан](https://testitquickly.com) - еще один философ, очень полезные статьи (Software Testing Glossary)
+* [Сергей Мартыненко](http://blog.shumoos.com) - я люблю его читать, потому что в его статьях всегда есть то, что заставляет меня с ним спорить. Там не только про тестирование. Статьи в стиле "Алисы в Зазеркалье" бесподобны.
+* [Александр Селяев](http://seljava.blogspot.com) - сейчас больше менеджерские статьи и задачки на сообразительность
+* [Алексей Булат](http://alexeybulat.blogspot.ru) - про автоматизацию и не только
+* [Сергей Высоцкий](http://goblingame.blogspot.com) - раньше хорошо писал, сейчас уехал на родину Карлсона и забросил это дело, но полистать можно
+* [Ольга Киселева](http://okiseleva.blogspot.ru) - пишет очень часто, большей частью по делу. Новичкам особенно будет полезно
+* [James Bach](http://www.satisfice.com/blog/) - самый лютый тестировщик, которого многие считают провокатором. Неокрепшим умам читать с осторожностью.
+* [Michael Bolton](http://www.developsense.com/blog/) - не менее лютый, и не менее провокатор, чем Бах. Насчет умов рекомендация та же, что и для Баха.
+* [Augusto Evangelisti](https://mysoftwarequality.wordpress.com) - понятные и полезные статьи, большей частью про работу тестировщика в команде разработчиков.
+* [Jeff Nyman](https://testerstories.com)
+* [Google Testing Blog](http://googletesting.blogspot.com) - я думаю из названия понятно
+* [QA Intelligence](http://qablog.practitest.com) - неплохие статьи
+* [About 98 Percent Done](http://about98percentdone.blogspot.ru) - хорошие статьи, но с адским белым шрифтом на черном фоне
+
+**Instagram/TikTok**:
+
+* [ladybug.qa.courses](https://www.instagram.com/ladybug.qa.courses/)
+* [annkolivan](https://www.instagram.com/annkolivan/)
+* [olia\_qacoach](https://www.instagram.com/olia\_qacoach/)
+* [protestinginfo](https://www.instagram.com/protestinginfo/)
+* [ТОП блогов по тестированию (QA)](https://www.youtube.com/watch?v=YQlSV9jaBv8\&t=1263s)
+* [vadim\_ksendzov](https://www.instagram.com/vadim\_ksendzov/)
diff --git a/poleznye-ssylki/spisok-resursov-po-instrumentam-testirovshika.md b/poleznye-ssylki/spisok-resursov-po-instrumentam-testirovshika.md
new file mode 100644
index 0000000..2d437f8
--- /dev/null
+++ b/poleznye-ssylki/spisok-resursov-po-instrumentam-testirovshika.md
@@ -0,0 +1,414 @@
+# Список ресурсов по инструментам тестировщика
+
+* Мультитул: DevTools;
+* Снифферы: Charles Proxy, Fiddler;
+* Тестирование API: Postman, SoapUI;
+* Тестирование производительности: JMeter;
+* Тестирование безопасности: Kali linux, Santoku Linux + drozer, OWASP ZAP, … ;
+* Тестирование UI/UX: Figma, Zeplin, любой mind map - like продукт;
+* Фермы устройств для тестирования мобильных приложений: BrowserStack, Xamarin, AWS;
+* Инструменты тестирования мобильных приложений;
+* Системы контроля версий: GIT;
+* Взаимодействие с базами данных: язык SQL, системы СУБД;
+* Системы CI/CD: Jenkins/TeamCity;
+* Прочее: мессенджеры, баг-трекинговые системы и TMS, генераторы тестовых данных и т.п.
+
+**DevTools**:
+
+* В каждый современный браузер встроены инструменты разработчика - они позволяют быстро отловить и исправить ошибки в разметке или в коде. С их помощью можно узнать, как построилось DOM-дерево, какие теги и атрибуты есть на странице, почему не подгрузились шрифты и многое другое:
+ * [Проверка ответа сервера](https://siteclinic.ru/blog/seo-instrumenty/seo-chrome-devtools/#2)
+ * [Проверка мобильной адаптивности](https://siteclinic.ru/blog/seo-instrumenty/seo-chrome-devtools/#3)
+ * [Проверка мобильной выдачи](https://siteclinic.ru/blog/seo-instrumenty/seo-chrome-devtools/#4)
+ * [Региональная поисковая выдача](https://siteclinic.ru/blog/seo-instrumenty/seo-chrome-devtools/#5)
+ * [Изменение дизайна](https://siteclinic.ru/blog/seo-instrumenty/seo-chrome-devtools/#6)
+ * [Анализ протокола безопасности](https://siteclinic.ru/blog/seo-instrumenty/seo-chrome-devtools/#7)
+ * [Анализ скорости загрузки страницы](https://siteclinic.ru/blog/seo-instrumenty/seo-chrome-devtools/#8)
+* [Средства консоли Chrome, которыми вы, возможно, никогда не пользовались](https://habr.com/ru/company/ruvds/blog/486692/)
+* [Урок 10: Введение в Тестирование ПО - QA с Нуля - DevTools, Web Console, Device Toolbar](https://www.youtube.com/watch?v=mP23B6o9uhQ)
+* [Курс Тестировщика с нуля. 25 урок. Как тестировщику работать в DevTools](https://www.youtube.com/watch?v=IO14lZynBvM)
+* [Основные Use case использования Dev Tools для QA](https://www.youtube.com/watch?v=pxM3f8vyIhA\&t=320s)
+* [Изучаем инструменты разработчика Google Chrome (ЧАСТЬ 1)](https://www.youtube.com/watch?v=FStLGMPHSEI\&list=PLvWwA9iDlhHA4kzfpRbu2cH-Z2ss6tB99)
+* [DevTools для «чайников»](https://habr.com/ru/post/548898/)
+* [Devtools для тестировщика - Devtools chrome - Что такое Devtools](https://www.youtube.com/watch?v=LYEEMWSrOgI)
+* [Chrome DevTools Official Documentation](https://developer.chrome.com/docs/devtools/)
+* [Safari DevTools Official Documentation](https://support.apple.com/ru-ru/guide/safari-developer/welcome/mac)
+* [Полезные функции DevTools для тестировщиков](https://habr.com/ru/post/558694/)
+* [Chrome DevTools. Обзор основных возможностей веб-инспектора](https://www.youtube.com/watch?v=C8Z-N0y6Sqo)
+* [Documentation - Chrome DevTools - Remote debugging](https://developer.chrome.com/docs/devtools/remote-debugging/)
+* [Chrome Developer Tools для тестировщика](https://testengineer.ru/chrome-developer-tools-dlya-testirovshchika/)
+* [Lighthouse](https://developers.google.com/web/tools/lighthouse?hl=ru)
+
+**Тестирование API**:
+
+Postman представляет собой мультитул для тестирования API. В нем можно создавать коллекции запросов, проектировать дизайн API и создавать для него моки (заглушки-имитации ответов реального сервера), настраивать мониторинг (периодическая отправка запросов с журналированием), для запросов возможно написание тестов на JS, есть собственный Runner и т.д. Постман хорошо подойдет в простых случаях автоматизации или как инструмент поддержки а анализа: проверка работоспособности endpoint, дебаг тестов, простая передача информации о дефектах (можно сохранить запрос в curl, ответ в json и т.п.). Postman также может работать без графического интерфейса (newman).
+
+* [Postman для тестировщика. Мини-курс](https://www.youtube.com/playlist?list=PLKbJd47KcbjvLgn-ukTvfpaGoXAqybza0)
+* [Курс Тестирование ПО. Занятие 30. POSTMAN. Ручное тестирование API - QA START UP](https://www.youtube.com/watch?v=55l6XIEK9l0\&ab\_channel=QASTARTUP-ITTrainingCenter)
+* [Сергей Махетов - Воркшоп: Исследуем возможности Postman (часть 1)](https://www.youtube.com/watch?v=OFGVn-isQyk\&ab\_channel=Heisenbug)
+* [Сергей Махетов - Воркшоп: Исследуем возможности Postman (часть 2)](https://www.youtube.com/watch?v=IQ9sjNm11Nc\&ab\_channel=Heisenbug)
+* [API testing using Postman](https://robertgorter.medium.com/api-testing-using-postman-87cf1c40b82c)
+* [Postman Beginner's Course - API Testing](https://www.youtube.com/watch?v=VywxIQ2ZXw4)
+* [Погружение qa junior в пучину API с использованием SoapUI(Open Source)](https://habr.com/ru/company/renins/blog/558436/)
+* [Шпаргалка по Postman](https://telegra.ph/SHpargalka-po-Postman-09-01-2)
+* [Большой гайд по тестированию с Postman для начинающих](https://testengineer.ru/gajd-po-testirovaniyu-v-postman/)
+* [Основы Postman для самых маленьких](https://habr.com/ru/company/maxilect/blog/596789/)
+* [Reqover](https://github.com/reqover/docs) is language agnostic tool that gives a picture about coverage of APIs based on Open API (Swagger) or GraphQL
+* [Swagger-coverage](https://github.com/viclovsky/swagger-coverage) gives a full picture about coverage of API tests (regression) based on OAS (Swagger)
+* [36 частых вопросов по Postman](https://testengineer.ru/postman-sobesedovanie/)
+* [Тестирование производительности в Postman](https://testengineer.ru/testirovanie-proizvoditelnosti-v-postman/)
+* [curl - учимся тестировать API](https://testengineer.ru/curl-uchimsya-testirovat-api/)
+* [Как мы тестируем Rest API в SM 2.0 с помощью Postman: сценарии, запросы, переменные окружения и немного автотестов](https://habr.com/ru/company/sportmaster\_lab/blog/646365/)
+* **Открытые и тренировочные API**:
+ * [Список открытых API](https://github.com/public-apis/public-apis)
+ * [Обзор сайтов с API документацией](https://github.com/docops-hq/learnapidoc-ru/blob/master/Publishing-doc/API-doc-sites-list.md#100-)
+ * [Бесплатные API - Ресурсы для практического тестирования веб-сервисов](https://www.youtube.com/watch?v=dvLZDdC9eR0)
+ * [Search the Largest API Directory on the Web](https://www.programmableweb.com/apis/directory)
+ * [100+ сайтов с API документацией](https://starkovden.github.io/API-doc-sites-list.html#100-%D1%81%D0%B0%D0%B9%D1%82%D0%BE%D0%B2-%D1%81-api-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D1%86%D0%B8%D0%B5%D0%B9)
+ * [Shop - это бесплатное приложения для тестирования](https://testbase.atlassian.net/wiki/spaces/SHOP/overview?homepageId=1411056054)
+ * [Mockend](https://mockend.com) is the #1 GitHub app dedicated to API mocking
+ * [MockAPI](https://mockapi.io/docs) is a simple tool that lets you easily mock up APIs, generate custom data, and preform operations on it using RESTful interface
+ * [Swagger Petstore](https://petstore.swagger.io)
+ * [ReqRes](https://reqres.in)
+ * [httpbin](http://httpbin.org)
+ * [users.bugred.ru](http://users.bugred.ru)
+ * [The Star Wars API](https://swapi.dev)
+ * [API with auth](https://restful-booker.herokuapp.com/apidoc/index.html#api-Auth-CreateToken)
+ * [another API with auth](https://www.weatherapi.com/docs/)
+ * [API hh.ru](https://habr.com/ru/company/hh/blog/303168/)
+ * [Фокус API](https://developer.kontur.ru/doc/focus?about=2)
+ * [API DaData](https://dadata.ru/api/)
+ * [API JSON Placeholder](https://jsonplaceholder.typicode.com)
+ * [openexchangerates.org](https://openexchangerates.org)
+ * [openweather](https://openweathermap.org/api)
+ * [Last.fm Music Discovery API](https://www.last.fm/api)
+ * [xml response](http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?WSDL)
+
+**Proxy (снифферы трафика)**:
+
+Charles - инструмент для мониторинга HTTP/HTTPS трафика. Программа работает как прокси-сервер между приложением и сервером этого приложения. Charles записывает и сохраняет все запросы, которые проходят через него и позволяет их редактировать.
+
+* [Charles: незаменимый тул в арсенале QA-инженера](https://habr.com/ru/company/redmadrobot/blog/269109/)
+* [Breakpoints charles proxy Подмена данных](https://www.youtube.com/watch?v=74v5lpOug8c\&feature=youtu.be\&ab\_channel=BogdanOvsiyuk)
+* [Как приручить Charles Proxy?](https://habr.com/ru/company/youla/blog/527648/)
+* [Using Web Debugging Proxies for Application Testing](https://www.apriorit.com/dev-blog/591-proxies-for-application-testing)
+* [Перехват SSL трафика с Android-приложения](https://telegra.ph/Perehvat-SSL-trafika-s-Android-prilozheniya-01-26)
+* [Hail Frida!! The Universal SSL pinning bypass for Android applications](https://infosecwriteups.com/hail-frida-the-universal-ssl-pinning-bypass-for-android-e9e1d733d29)
+* [Certificate and Public Key Pinning](https://trykov.ru/certificate-and-public-key-pinning/)
+* [Начинающему QA: полезные функции снифферов на примере Charles Proxy](https://habr.com/ru/company/maxilect/blog/554888/)
+* [Перехват SSL трафика с Android-приложения](https://telegra.ph/Perehvat-SSL-trafika-s-Android-prilozheniya-01-26)
+* [Откручивание SSL пиннинга в Android приложениях](https://habr.com/ru/post/559722/)
+* [HTTP Toolkit](https://httptoolkit.tech) is a beautiful & open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac
+* [mitmproxy is a free and open source interactive HTTPS proxy](https://mitmproxy.org)
+* [Charles Proxy meetup](https://www.youtube.com/watch?v=gWhvVaoHh70)
+* [Open Source Fiddler Alternatives for Mac](https://alternativeto.net/software/fiddler/?license=opensource\&platform=mac)
+* [Битва снифферов: Charles vs Proxyman](https://habr.com/ru/company/ozontech/blog/579392/)
+* [Почему Proxyman - сын маминой подруги в мире снифферов](https://habr.com/ru/company/indriver/blog/591525/)
+
+**Тестирование безопасности**:
+
+* [Сканирование на уязвимости: обзор продуктов, которые есть на рынке](https://habr.com/ru/company/cloud4y/blog/651831/)
+* [Чем искать уязвимости веб-приложений: сравниваем восемь популярных сканеров](https://habr.com/ru/company/tomhunter/blog/456892/)
+* [10 лучших инструментов сканирования уязвимостей для тестирования на проникновение - 2020](https://itsecforu.ru/2019/08/06/%F0%9F%92%A3-10-%D0%BB%D1%83%D1%87%D1%88%D0%B8%D1%85-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D1%81%D0%BA%D0%B0%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/)
+* [20 мощных инструментов тестирования на проникновение в 2019 году](https://itfb.com.ua/instrumenty-testirovaniya-bezopasnosti/)
+* [Пентест веб сайта с помощью Owasp Zap](https://habr.com/ru/company/alexhost/blog/530110/)
+* [Проверяем безопасность приложений с помощью Drozer](https://habr.com/ru/company/alexhost/blog/535396/)
+* [Santoku Linux](https://santoku-linux.com)
+* [Kali Linux](https://www.kali.org)
+* [https://github.com/FSecureLABS/drozer](https://github.com/FSecureLABS/drozer)
+* [Burp Suite is the choice of security professionals worldwide](https://portswigger.net/burp)
+* [Тестирование защищенности приложений при помощи SAST (Static Application Security Testing)](https://www.youtube.com/watch?v=Jk8LiaMF2aw)
+
+**GIT**:
+
+Git - это система контроля версий, которая упрощает работу нескольких человек над одним проектом, помогая разрешать конфликты слияния изменений, следить за историей, откатывать эти изменения и т.п.
+
+Ваш репозиторий может быть локальным и/или находиться в: [GitHub](https://github.com), [Bitbucket](https://bitbucket.org), [GitLab](https://gitlab.com)
+
+Даже ручному тестировщику пригодятся навыки работы с Git: хранить там портфолио для резюме с подтверждением навыков использования инструментов и написания документации, можно само резюме разместить на github pages, уже на работе иногда будет требоваться самостоятельно сбилдить себе сборку на тест или разобраться, в какой момент (в каком коммите) появился баг или наоборот был пофикшен и т.п. Про автоматизацию, очевидно, даже и говорить не стоит - гит там используется ежедневно.
+
+* Большая подборка [Все что нужно для работы с GIT](https://t.me/qa\_pro/480)
+* Серия свежих видеоуроков: [часть 1](https://www.youtube.com/watch?v=oKyzv8nzT28), [2](https://www.youtube.com/watch?v=x4DLZet8hQw), [3](https://www.youtube.com/watch?v=iCswbUkRILY), [4](https://www.youtube.com/watch?v=0DiNdpUx5\_Q), [5](https://www.youtube.com/watch?v=knz-JIaNrxk), [6](https://www.youtube.com/watch?v=JF69x66NVeM), [7](https://www.youtube.com/watch?v=e-GyWUgRS6c), [8](https://www.youtube.com/watch?v=RDFOIUGVZpw), [9](https://www.youtube.com/watch?v=WcS7Q6rUam8), [10](https://www.youtube.com/watch?v=\_MNw6G13zzs), [11](https://www.youtube.com/watch?v=\_5Qf21riOyQ)
+* [Very beautiful GIT documentation](https://www.linkedin.com/posts/fabbasi\_github-activity-6835855126062800896-hAiJ/)
+* [GIT PURR! Git Commands Explained with Cats!](https://girliemac.com/blog/2017/12/26/git-purr/)
+* [Git для тестировщиков](https://www.youtube.com/playlist?list=PLKbJd47KcbjuHU3AhyeOPJ9p\_GDB6yGL7)
+* [Git для новичков (часть 1)](https://habr.com/ru/post/541258/)
+* [Git изнутри и на практике](https://habr.com/ru/company/oleg-bunin/blog/468177/)
+* [Git, я хочу все отменить! Команды исправления допущенных ошибок](https://habr.com/ru/company/skillbox/blog/534972/)
+* [Getting solid at Git rebase vs. merge](https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c53aa)
+* [Git How To - это интерактивный тур, который познакомит вас с основами Git](https://githowto.com/ru)
+* [Плейлист “Основы использования GIT”](https://www.youtube.com/playlist?list=PLvItDmb0sZw8WmkxzGJUZl6S3KU\_-7-aP)
+* [GIT-практикум](https://www.youtube.com/watch?v=nRXacgNHNVw\&list=PLvItDmb0sZw-KsqUenM2jyBpNslNzDJLO\&index=1)
+* [Octotree](https://www.octotree.io) - GitHub on steroids
+* [Плейлист “GIT для тестировщиков с нуля за 1 час”](https://www.youtube.com/playlist?list=PL9mn2EBC\_SSynAcYKFAtMTIhsKD0OGqWX)
+* [Git простыми словами](https://www.youtube.com/watch?v=l26-jDN64o4)
+* [Как установить Git и выкачать репозиторий](https://www.youtube.com/watch?v=lZdGWJtrsNw)
+* [GitFlic](https://gitflic.ru) - первый российский сервис для хранения кода и работы с ним
+* _Практическое задание: форкнуть себе репозиторий QA bible :)_
+
+**SQL**:
+
+Это язык программирования, применяемый для создания, модификации и управления данными в базе данных.
+
+[Все что нужно для работы с SQL](https://t.me/qa\_pro/490):
+
+* Официальные сайты
+ * [SQLite](https://www.sqlite.org/index.html)
+ * [MySQL](https://www.mysql.com)
+ * [PostgreSQL](https://www.postgresql.org)
+* GUI клиенты
+ * [MySQL Workbench](https://www.mysql.com/products/workbench/)
+ * [dBeaver](https://dbeaver.com)
+ * [HeidiSQL](https://www.heidisql.com)
+ * [Navicat for MySQL](https://www.navicat.com/en/products/navicat-for-mysql)
+ * [dbForge Studio for MySQL](https://www.devart.com/dbforge/mysql/studio/)
+* Основы SQL
+ * [Алан Бьюли "Изучаем SQL"](https://www.amazon.com/Learning-SQL-Generate-Manipulate-Retrieve/dp/1492057614/ref=sr\_1\_1?dchild=1\&keywords=sQL\&qid=1613292997\&s=books\&sr=1-1)
+ * [Линн Бейли "Изучаем SQL"](https://www.amazon.com/Head-First-SQL-Brain-Learners/dp/0596526849/ref=sr\_1\_10?dchild=1\&keywords=sQL\&qid=1613292997\&s=books\&sr=1-10)
+ * [W3C Introduction to SQL](https://www.w3schools.com/sql/sql\_intro.asp)
+ * [Официальная дока](https://dev.mysql.com/doc/)
+ * [guru99 - SQL Tutorial for Beginners: Learn SQL in 7 Days](https://www.guru99.com/sql.html)
+ * [SQL запросы быстро. Часть 1](https://habr.com/ru/post/480838/)
+ * [Понимание джойнов сломано. Это точно не пересечение кругов, честно](https://habr.com/ru/post/448072/)
+ * [Плейлист ](https://www.youtube.com/playlist?list=PLvItDmb0sZw9-yTHNWpfXDyPPg8aXYb-B)по основам
+ * [Видеокурс “How to… SQL Essential”](https://www.youtube.com/playlist?list=PLvItDmb0sZw8BsPPGyZwGBDFjUgoxadKJ)
+* Продвинутый уровень
+ * [Энтони Молинаро "SQL. Сборник рецептов"](https://www.amazon.com/SQL-Cookbook-Query-Solutions-Techniques/dp/1492077445/ref=sr\_1\_2?dchild=1\&keywords=sQL\&qid=1613292997\&s=books\&sr=1-2)
+ * [Алекс Кригель "SQL. Библия пользователя"](https://www.amazon.com/SQL-Bible-Alex-Kriegel/dp/0470229063/ref=sr\_1\_1?dchild=1\&keywords=sQL+bible\&qid=1613293063\&s=books\&sr=1-1)
+ * [Джеймс Грофф, Пол Вайнберг, Эндрю Оппель "SQL Полное руководство. Третье издание."](https://www.amazon.com/SQL-Complete-Reference-James-Groff-dp-0071592555/dp/0071592555/ref=mt\_other?\_encoding=UTF8)
+* Практика
+ * [SQLAcademy - Онлайн тренажер с упражнениями по SQL](https://sql-academy.org/ru)
+ * [SQLBolt - Introduction to SQL](https://sqlbolt.com)
+ * [W3C - The Try-SQL Editor](https://www.w3schools.com/sql/trysql.asp?filename=trysql\_op\_in)
+ * [HackerRack SQL](https://www.hackerrank.com/domains/sql)
+ * [Упражнения по SQL](https://www.sql-ex.ru/?Lang=0)
+ * [Тест на знание SQL](https://www.learnqa.ru/sql\_test)
+ * [https://www.db-fiddle.com/](https://www.db-fiddle.com)
+ * [Видео курс “SQL Практикум”](https://www.youtube.com/playlist?list=PLvItDmb0sZw-WX3dpyJJcuIyy6i2dT7FA)
+* Shit happens
+ * [SQL Cheat Sheet](http://www.sqltutorial.org/wp-content/uploads/2016/04/SQL-cheat-sheet.pdf)
+ * [Основные команды SQL, которые должен знать каждый программист](https://tproger.ru/translations/sql-recap/)
+ * [27 распространенных вопросов по SQL с собеседований и ответы на них](https://tproger.ru/articles/sql-interview-questions/)
+* [Ресурсы и инструменты для обучения и практической работы с базами данных - SQL](https://www.youtube.com/watch?v=fiiNGLSIs80)
+* [The 10 best sql analytics services for qa teams in 2021](https://theqalead.com/tools/best-sql-analytics/)
+* [Что такое базы данных NoSQL?](https://aws.amazon.com/ru/nosql/)
+* [Курс Тестирование ПО. Занятие 34. NoSQL база данных. Сравнение SQL и NoSQL](https://www.youtube.com/watch?v=Skl0tWrnqz8)
+* [100+ Most Popular SQL Interview Questions And Answers](https://www.softwaretestingmaterial.com/sql-interview-questions/)
+* [Курс Тестирования ПО. Занятие 19. Зачем тестировщику нужен SQL. Практические примеры](https://www.youtube.com/watch?v=EdXq2AoRYI8)
+* [Лучшие вопросы средней сложности по SQL на собеседовании аналитика данных](https://habr.com/ru/company/dcmiran/blog/500360/)
+
+**Инструменты тестирования мобильных приложений**:
+
+* [Android Debug Bridge (adb)](https://developer.android.google.cn/studio/command-line/adb?hl=en), [Minimal ADB](https://rootmydevice.com/download-minimal-adb-and-fastboot/), [Инструменты тестирования Android приложений. Часть 2](https://szadorozhnyi.medium.com/%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-android-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9-%D1%87%D0%B0%D1%81%D1%82%D1%8C-2-4107dc748d0f), [Отладка по ADB](https://trofimovdigital.ru/blog/adb)
+* [Logcat](https://developer.android.com/studio/debug/am-logcat), [Инструменты тестирования Android приложений. Часть 3](https://szadorozhnyi.medium.com/%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-android-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9-%D1%87%D0%B0%D1%81%D1%82%D1%8C-3-e347a621a3bd)
+* [Logcat прямо на устройстве](https://play.google.com/store/apps/details?id=com.tananaev.logcat\&hl=ru\&gl=US)
+* [ANR-WatchDog](https://github.com/SalomonBrys/ANR-WatchDog), [Инструменты тестирования Android приложений. Часть 5](https://szadorozhnyi.medium.com/%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-android-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9-%D1%87%D0%B0%D1%81%D1%82%D1%8C-5-caddda14f175)
+* [Performance tracing](https://developer.android.com/topic/performance/tracing)
+* [Xcode profiler](https://www.avanderlee.com/debugging/xcode-instruments-time-profiler/)
+* [On-device developer options](https://developer.android.com/studio/debug/dev-options)
+* [apkanalyzer](https://developer.android.com/studio/command-line/apkanalyzer)
+* [Top 10 Mobile Performance Testing Tools in 2020](https://dzone.com/articles/top-10-mobile-performance-testing-tools-in-2020)
+* [UI/Application Monkey Tester](https://developer.android.com/studio/test/monkey), [Monkey Testing - Как тестировать мобильные приложения](https://www.youtube.com/watch?v=sXtXy5kWVw8)
+* [Mobile App Beta Testing Services (IOS And Android Beta Testing Tools)](https://www.softwaretestinghelp.com/mobile-app-beta-testing-services/)
+* Инструменты скорее разработчика, чем тестировщика, но наверняка когда-то придется столкнуться:
+ * Google Firebase: некоторые из самых популярных функций платформы включают в себя базы данных, аутентификацию, push-уведомления, аналитику (в т.ч. по крешам), хостинг и многое другое: [документация](https://firebase.google.com/docs/crashlytics), [youtube](https://www.youtube.com/c/firebase/videos?app=desktop), [обзор](https://blog.back4app.com/ru/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-firebase/), [мастеркласс](https://www.youtube.com/watch?v=1\_2R6yIg3SY)
+ * OneSignal: Лидер на рынке взаимодействия с клиентами, мобильных и веб пушей, электронной почты, SMS и in-app сообщений.
+
+**Эмуляторы, симуляторы, фермы устройств**:
+
+* [Android studio emulator](https://developer.android.google.cn/studio/run/emulator)
+* [Genymotion - Android Virtual Devices for all your development & testing needs](https://www.genymotion.com)
+* [BrowserStack - Test instantly on a wide range of real iOS and Android devices on the cloud](https://www.browserstack.com/app-live)
+* [10 лучших альтернатив BrowserStack (бесплатные и платные) 2021](https://rigorousthemes.com/blog/best-browserstack-alternatives-free-paid/)
+* [Xcode simulator](https://developer.apple.com/library/archive/documentation/ToolsLanguages/Conceptual/Xcode\_Overview/RunningintheSimulator.html)
+* [Центр приложений Visual Studio](https://visualstudio.microsoft.com/ru/app-center/)
+* [Samsung Remote Test Lab](https://developer.samsung.com/remotetestlab/rtlDeviceList.action)
+* [AWS Device Farm](https://aws.amazon.com/ru/device-farm/)
+* [Huawei cloud debugging](https://developer.huawei.com/consumer/en/doc/development/Tools-Guides/remote-debugging-0000001073142313)
+* [Device Farmer is a web application for debugging smartphones, smartwatches and other gadgets remotely](https://github.com/DeviceFarmer)
+* [Appetize.io - Run native mobile apps in your browser](https://appetize.io)
+* [Genymobile/scrcpy - обеспечивает отображение и управление устройствами Android через USB или TCP/IP](https://github.com/Genymobile/scrcpy)
+* [Как тестировщики написали свою мобильную ферму для IOS](https://habr.com/ru/post/572668/)
+* [Облачные платформы для мобильного тестирования](https://habr.com/ru/post/464433/)
+
+**Работа с логами**:
+
+* [Логи для тестировщика / Работа с логами в тестировании](https://www.youtube.com/watch?v=pAF1a\_2a\_6s)
+* [Tools for Log Analysis](https://medium.com/tensult/tools-for-log-analysis-461eb07c2d6b)
+* [https://developer.apple.com/documentation/os/logging](https://developer.apple.com/documentation/os/logging)
+* [Просмотр системных логов iOS](https://bulkin-me.turbopages.org/turbo/bulkin.me/s/notes/2884) и [еще](https://stackoverflow.com/questions/7277804/ios-iphone-ipad-ipodtouch-view-real-time-console-log-terminal)
+* [Инструменты для снятия логов с Android / iOS устройств. Чтение и разбор](https://www.youtube.com/watch?v=fusFaT24F3o\&t=1145s)
+* [Доклад: "Мониторинг приложения в проде" / Семён Мацепура (СберМаркет)](https://www.youtube.com/watch?v=lSS9eTlrNf8)
+
+**Тестирование производительности**:
+
+* [Apache JMeter](https://jmeter.apache.org) + JMeter Result Analysis: [The Ultimate Guide](https://octoperf.com/blog/2017/10/19/how-to-analyze-jmeter-results/#understanding-jmeter-metrics)
+* [Яндекс.Танк](https://yandex.ru/dev/tank/)
+* [LoadRunner](https://www.microfocus.com/ru-ru/portfolio/performance-engineering/overview)
+* [Google Lighthouse](https://developers.google.com/web/tools/lighthouse/)
+* [artillery.io](https://artillery.io)
+* [Top 10 лучших инструментов для нагрузочного тестирования](https://www.performance-lab.ru/blog/luchshie-instrumenty-dlya-nagruzochnogo-testirovaniya)
+* [10 инструментов тестирования производительности мобильных приложений](https://proglib.io/p/10-instrumentov-testirovaniya-proizvoditelnosti-mobilnyh-prilozheniy-2020-09-20#:\~:text=Akamai%20CloudTest%20%E2%80%93%20%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%20%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BE%D1%87%D0%BD%D0%BE%D0%B3%D0%BE,%D0%B8%20%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85%20%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2.%20%D0%9E%D1%81%D0%BE%D0%B1%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8%3A)
+* [Топ-15 бесплатных инструментов для нагрузочного тестирования](https://testengineer.ru/besplatnye-instrumenty-dlya-nagruzochnogo-testirovaniya/)
+
+**Mind maps**:
+
+* [12 программ и сервисов для создания майндкарт](https://presium.pro/blog/software\_for\_maindmapping)
+* [Как нарисовать карту приложения (mind map)](http://okiseleva.blogspot.com/2020/01/mind-map.html)
+* [Mind map вместо тест-кейса, или Как визуализация позволяет тестировать приложение быстрее](https://habr.com/ru/company/badoo/blog/418353/)
+* [Mind Map в помощь тестировщику](https://habr.com/ru/post/539756/)
+* [Mind Map в тестировании - или легкий способ тестировать сложные приложения](https://habr.com/ru/post/515990/)
+* [Mind Map для QA - Интеллектуальные карты](https://www.youtube.com/watch?v=N5B-3bi6\_88)
+
+**TMS**:
+
+* [Allure TestOps](https://qameta.io)
+* [Топ-12 лучших систем управления тестированием 2020](https://habr.com/ru/post/522474/)
+* [Инструмент на века - гугл таблицы](https://docs.google.com/spreadsheets/u/0/)
+* [Пришла пора отправить в отставку инструменты управления кейсами](https://software-testing.ru/library/testing/testing-tools/3588-its-time-to-retire-our-test-case-management-tools)
+* [Системы управления тест кейсами. Какую выбрать для немедленной работы?](https://habr.com/ru/post/582608/)
+* [Топ-10 лучших систем управления тестированием 2021](https://habr.com/ru/post/580526/)
+* [QA-митап Redmadrobot 19/11, Google Sheet - универсальное подспорье для QA, Саша Строкин](https://www.youtube.com/watch?v=9aXGHFuivck)
+* [10 Best free test management tools for 2022](https://theqalead.com/tools/free-test-management-tools/)
+* [10 Best test management tools for JIRA in 2022](https://theqalead.com/tools/test-management-tools-for-jira/)
+* [Successfully Managing Test Cases: Finding the Right Test Case Tool](https://blog.gurock.com/right-test-case-tool/)
+* [Allure. В поисках почти идеальной TMS](https://habr.com/ru/post/571476/)
+
+**Полезные расширения для браузера**:
+
+* [Vimbox Переводчик от Skyeng](https://chrome.google.com/webstore/detail/vimbox-%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4%D1%87%D0%B8%D0%BA-%D0%BE%D1%82-skye/heeikiohkfkolhmdodhcjdklofmhmmhn?hl=ru)
+* [Violentmonkey](https://chrome.google.com/webstore/detail/violentmonkey/jinjaccalgkegednnccohejagnlnfdag), [Tampermonkey](https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ru) + [script](https://4pda.to/pages/go/?u=https%3A%2F%2Fraw.githubusercontent.com%2Fsodapng%2Fvoice-over-translation%2Fmaster%2Fvot.user.js)
+* [Talend API Tester - Free Edition](https://chrome.google.com/webstore/detail/talend-api-tester-free-ed/aejoelaoggembcahagimdiliamlcdmfm)
+* [Dimensions](https://chrome.google.com/webstore/detail/dimensions/baocaagndhipibgklemoalmkljaimfdj) - A tool for designers to measure screen dimensions
+* [Page Ruler Redux](https://chrome.google.com/webstore/detail/page-ruler-redux/giejhjebcalaheckengmchjekofhhmal) - A Web Developer\Designer ruler to get pixel dimensions and positioning to measure elements on any web page
+* [Tape](https://chrome.google.com/webstore/detail/tape/jmfleijdbicilompnnombcbkcgidbefb) - Measurement tools, rulers and grids
+* [PerfectPixel](https://chrome.google.com/webstore/detail/perfectpixel-by-welldonec/dkaagdgjmgdmbnecmcefdhjekcoceebi?hl=ru)
+* [GoFullPage - Full Page Screen Capture](https://chrome.google.com/webstore/detail/gofullpage-full-page-scre/fdpohaocaechififmbbbbbknoalclacl)
+* [WhatFont](https://chrome.google.com/webstore/detail/whatfont/jabopobgcpjmedljpbcaablpmlmfcogm?hl=ru) - The easiest way to identify fonts on web pages
+* [Spectrum](https://chrome.google.com/webstore/detail/spectrum/ofclemegkcmilinpcimpjkfhjfgmhieb) for color blindness checks
+* [Check My Links](https://chrome.google.com/webstore/detail/check-my-links/ojkcdipcgfaekbeaelaapakgnjflfglf) for link checking
+* [Selenium IDE](https://www.selenium.dev/selenium-ide/) for test data setup and debugging
+* [Ranorex Selocity](https://www.ranorex.com/selocity/browser-extension/) for generating selectors
+* [Bug Magnet](https://bugmagnet.org) for test data
+* [Fake Filler](https://chrome.google.com/webstore/detail/fake-filler/bnjjngeaknajbdcgpfkgnonkmififhfo/related) for test data
+* [Mokku](https://github.com/mukuljainx/Mokku): Mock API calls seamlessly
+* [EditThisCookie](https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg) - менеджер cookie
+* [Гуру Очистки](https://chrome.google.com/webstore/detail/clean-all-history-cache-c/elidgjfpciimeeeoeneeiifkmhadhkeh?hl=ru&) - удаление кеша & истории браузера
+* [Responsive Viewer](https://chrome.google.com/webstore/detail/responsive-viewer/inmopeiepgfljkpkidclfgbgbmfcennb) - Show multiple screens once, Responsive design tester
+* [Window Resizer](https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh?hl=ru&) - Resize the browser window to emulate various screen resolutions
+* [Resolution Test](https://chrome.google.com/webstore/detail/resolution-test/idhfcdbheobinplaamokffboaccidbal) - An extension for developers to test web pages in different screen resolutions
+* [Exploratory Testing Chrome Extension](https://chrome.google.com/webstore/detail/exploratory-testing-chrom/khigmghadjljgjpamimgjjmpmlbgmekj)
+* [Web Developer Form Filler](https://chrome.google.com/webstore/detail/web-developer-form-filler/gbagmkohmhcjgbepncmehejaljoclpil/related?hl=en)
+* [Web Developer](https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm) - Adds a toolbar button with various web developer tools
+* [Web Developer Checklist](https://chrome.google.com/webstore/detail/web-developer-checklist/iahamcpedabephpcgkeikbclmaljebjp) - Analyses any web page for violations of best practices
+* [Docsumo Free OCR Software](https://chrome.google.com/webstore/detail/docsumo-free-ocr-software/ihmmlfacoffajllfpdfkdikgmoogbnph?ref=producthunt) - Screenshot any webpage or a portion of a webpage and immediately convert it into editable text
+* [ColorZilla](https://chrome.google.com/webstore/detail/colorzilla/bhlhnicpbhignbdhedgjhgdocnmhomnp) - Advanced Eyedropper, Color Picker, Gradient Generator and other colorful goodies
+* [d3coder](https://chrome.google.com/webstore/detail/d3coder/gncnbkghencmkfgeepfaonmegemakcol) - Encoding/Decoding Plugin for various types of encoding like base64, rot13 or unix timestamp conversion
+* [IE Tab](https://chrome.google.com/webstore/detail/ie-tab/hehijbfgiekmjfkfjpbkbammjbdenadd) - Display web pages using IE within Chrome. Use Java, Silverlight, ActiveX, Sharepoint, and more
+* [Screencastify](https://chrome.google.com/webstore/detail/screencastify-screen-vide/mmeijimgabbpbgpdklnllpncmdofkcpn?hl=ru&) - The #1 screen recorder for Chrome. Capture, edit and share videos in seconds
+* [Siteimprove](https://chrome.google.com/webstore/detail/siteimprove-accessibility/efcfolpjihicnikpmhnmphjhhpiclljc?hl=en-US) for accessibility
+* [axe DevTools](https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=ru&) - Web Accessibility Testing
+* [WAVE](https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh) is a web accessibility evaluation tool
+* [Proxy SwitchySharp](https://chrome.google.com/webstore/detail/proxy-switchysharp/dpplabbmogkhghncfbfdeeokoefdjegm?hl=ru&) - Manage and switch between multiple proxies quickly & easily
+* [Browsec VPN](https://chrome.google.com/webstore/detail/browsec-vpn-free-vpn-for/omghfjlpggmjjaagoclmmobgdodcjboh?hl=ru&) - Free VPN for Chrome
+* [Otsledit](https://chrome.google.com/webstore/detail/price-tracker-otsledit/ibamclpibpnhmkaphhemfbljmenlpbch?hl=ru&) - Отслеживайте изменения контента на веб-страницах, просматривайте историю мониторинга
+* [Ruto](https://chrome.google.com/webstore/detail/ruto-xpath-finder/ilcoelkkcokgeeijnopjnolmmighnppp?hl=ru&) - XPath Finder
+
+**Программы для снятия скриншотов и записи видео**:
+
+* Windows: скриншот всего экрана Prtsc+Fn, выделяемой части Win+Shift+S, запись видео Win+G
+* [Screenpic - больше чем программа для скриншотов](https://screenpic.net/ru/)
+* [ScreenRec](https://screenrec.com)
+* [Делайте снимки экрана в один клик со Скриншотером Mail.ru](https://screenshoter.mail.ru)
+* [ShareX - Screen capture, file sharing and productivity tool](https://getsharex.com)
+* [Greenshot is a light-weight screenshot software tool for Windows](https://getgreenshot.org)
+* [Flameshot - powerful yet simple to use screenshot software](https://flameshot.org)
+* [Bandicam - это лучшая программа для записи экрана, игр и видеоустройств](https://www.bandicam.com/ru/)
+* [Recordit - fast screencasts](https://recordit.co)
+* [ScreenToGif - screen, webcam and sketchboard recorder with an integrated editor](https://www.screentogif.com)
+* [OBS Studio - бесплатная программа с открытым исходным кодом для записи видео и потокового вещания](https://obsproject.com/ru)
+* [Snagit lets you quickly capture your screen](https://www.snagit.com)
+* [Joxi - бесплатная программа для снятия скриншотов](http://joxi.ru)
+* [Movavi Screen Recorder - захват экрана в один клик](https://www.movavi.ru/screen-capture/)
+* [PicPick - захват экрана, редактор изображений, выбор цвета, цветовая палитра, пиксельная линейка, угломер, перекрестие, грифельная доска и многое другое](https://picpick.app/ru/)
+* [Apowersoft Screen Capture Pro - multi-functional Screenshot Program](https://www.apowersoft.com/screen-capture-pro)
+* [Screencast-o-matic - Free Screen Recorder](https://screencast-o-matic.com/screen-recorder)
+* [Loom](https://www.loom.com) - Record quick videos of your screen and cam
+* [ImageOptim](https://imageoptim.com/mac) makes images load faster
+* [Monosnap](https://monosnap.com) - take screenshots in one click
+* [BugCatcher](https://bugcatcher.pro) - Создает скриншот или видео, Копирует контекст (OS, browser, hardware e.t.c ), Копирует errorlog, Отправляет в багтрекинг систему
+
+**Linux**
+
+* [Обсуждение зачем вообще уметь в Linux](https://software-testing.ru/forum/index.php?/topic/23210-linuxnix-znanija-dlja-testirovshika/)
+* [Введение в UNIX/LINUX для тестировщиков](https://www.youtube.com/watch?v=fpujpnsPiuA)
+* Command Line с нуля (Bash, Unix): [часть 1](https://www.youtube.com/watch?v=jRYggi1pNkM), [2](https://www.youtube.com/watch?v=ULhRW6mFzYI), [3](https://www.youtube.com/watch?v=38E3pE-jh38), [4](https://www.youtube.com/watch?v=ekM8q2SL5qM), [5](https://www.youtube.com/watch?v=\_nme7F-luJ0)
+* [Linux Command Line Cheat Sheet by DaveChild](https://cheatography.com/davechild/cheat-sheets/linux-command-line/)
+* [Базовые команды Linux для тестировщиков и не только](https://habr.com/ru/post/481398/) + [картинка](https://wizardzines.com/networking-tools-poster.pdf)
+* [Бесплатный курс “Основы командной строки”](https://ru.hexlet.io/courses/cli-basics)
+* [How To Run / Execute Command Using SSH](https://www.cyberciti.biz/faq/unix-linux-execute-command-using-ssh/)
+* [TOP 70+ Best UNIX Interview Questions With Answers](https://www.softwaretestinghelp.com/unix-interview-questions/)
+
+**RegExp**:
+
+* [Регулярные выражения (regexp) - основы](https://habr.com/ru/post/545150/)
+* [Мягкое введение в Regex](https://telegra.ph/Myagkoe-vvedenie-v-Regex-03-19)
+* [https://regex101.com/](https://regex101.com)
+* [http://myregexp.com/](http://myregexp.com)
+* [https://regexr.com/](https://regexr.com)
+
+**Разное**:
+
+* [HTML](https://developer.mozilla.org/en-US/docs/Learn/HTML)/[CSS](https://developer.mozilla.org/en-US/docs/Learn/CSS)/[JavaScript](https://developer.mozilla.org/en-US/docs/Learn/JavaScript)
+* [Подборка шпаргалок](https://overapi.com)
+* [Курс Тестирование ПО. Занятие 20. Инструменты для сбора тестовых доказательств (Test Evidences)](https://www.youtube.com/watch?v=4CBBWV6ldcs)
+* [AnyDesk](https://anydesk.com/ru) - подключение к удаленному рабочему столу любой платформы
+* [LetsView](https://letsview.com) - Free Wireless Screen Mirroring
+* [clumsy](https://github.com/jagt/clumsy) makes your network condition on Windows significantly worse, but in a managed and interactive manner
+* [netem](https://wiki.linuxfoundation.org/networking/netem) provides Network Emulation functionality for testing protocols by emulating the properties of wide area networks
+* [Полезные ресурсы для тестировщика. Генераторы данных, изображений, текста. Сравнение текста, файлов.](https://www.youtube.com/watch?v=-oWstXJFI2Y)
+* [Десять классных генераторов тестовых данных](https://testengineer.ru/klassnye-generatory-testovyh-dannyh/)
+* [Dynamic Dummy Image Generator](https://dummyimage.com)
+* [Just add your desired image size (width & height) after our URL, and you'll get a random image](https://picsum.photos)
+* [SortSite](https://www.powermapper.com/products/sortsite/) checks any website for broken links, spelling errors, browser compatibility, accessibility, web standards validation and search engine issues.
+* [PowerMapper](https://www.powermapper.com/products/mapper/) - One click site mapping
+* [File generator](https://file.generator.teremokgames.com)
+* [Screen Dimensions for Devices + my device](https://yesviz.com)
+* [Супер простой сервис для генерации разных HTTP-кодов](https://httpstat.us)
+* [Бесплатные одноразовые e-mail](https://www.mailinator.com)
+* [Tools for Software Testing](http://qala.io/blog/test-tools.html)
+* [Get Credit Card Numbers](https://www.getcreditcardnumbers.com)
+* [Тестовые банковские карты](https://securepayments.sberbank.ru/wiki/doku.php/test\_cards)
+* [Stripe test card numbers](https://stripe.com/docs/testing#cards)
+* ["Can I use"](https://caniuse.com) provides up-to-date browser support tables for support of front-end web technologies on desktop and mobile web browsers.
+* [Chrome Remote Desktop - теперь подключаемся к ПК и со смартфона на Android](https://habr.com/ru/post/219783/)
+* [Пингуем из Excel](https://pikabu.ru/story/pinguem\_iz\_excel\_8165074)
+* [Тулзы ручного тестировщика приложений на базе Windows](https://habr.com/ru/post/554300/)
+* [One click website testing tool](https://www.powermapper.com)
+* [Инструменты для тестирования - Что должен знать тестировщик без опыта.](https://www.youtube.com/watch?v=RPllElm0QQI)
+* [Генератор номеров банковских счетов](https://infostart.ru/public/1075832/)
+* [Программа для генерации банковских счетов и генерации ключа проверки](https://github.com/fleytman/generator\_bank\_accounts)
+* [mChat is a real-time messaging app written in Swift for iOS devices](https://github.com/vitaliy-paliy/Messenger)
+* [Telegram iOS Source Code Compilation Guide](https://github.com/TelegramMessenger/Telegram-iOS)
+* [Как установить, настроить и использовать подсистему Linux в Windows 10. Обновленный Windows Terminal](https://www.youtube.com/watch?v=UJ-Sncozy58)
+* [Багред - ставите задачу в баг-трекер? Проверьте название на стоп-слова!](http://bugred.ru)
+* [Top Cross-Browser Testing Tools to Test from Different Geo-Locations](https://hackernoon.com/top-cross-browser-testing-tools-to-test-from-different-geo-locations-nx2837uk)
+* [10 best data engineering tools and technologies in 2021](https://theqalead.com/tools/best-data-engineering-tools/)
+* [Кракозябры](https://disk.yandex.ru/d/ShyvfnM15MXacA)
+* [Прорисовка и визуализация сервисов, систем, архитектуры и всего остального](https://t.me/pmdaily/824)
+* RF SCreater - Генератор паспортов РФ
+* [Генератор личностей EN](https://vk.com/away.php?to=http%3A%2F%2Frandomprofile.com%2Fusa-random-names\&cc\_key=)
+* [Генератор личностей RUS](https://vk.com/away.php?to=http%3A%2F%2Frandus.ru%2F\&cc\_key=)
+* [Почтовый сервис для создания временного ящика](https://temp-mail.org)
+* [Одноразовые и Бесплатные адреса электронной почты](https://yopmail.com/ru/)
+* [Большой тред о полезных сервисах для разработчиков](https://twitter.com/bespoyasov/status/1430537219241123845?s=21)
+* [Install any command on any operating system](https://command-not-found.com)
+* [ngrok](https://ngrok.com) - One command for an instant, secure URL to your localhost server through any NAT or firewall
+* [projector-docker](https://github.com/JetBrains/projector-docker) - is a technology to run and access Swing GUI applications remotely
+* [Code With Me](https://www.jetbrains.com/ru-ru/code-with-me/) - Сервис JetBrains для совместной работы над кодом
+* [Calendly](https://calendly.com) is your hub for scheduling meetings
+* [Воркшоп: Инструменты для дебага сети / Евгений Рядовой (СберМаркет)](https://www.youtube.com/watch?v=Bf9WDqwHWAc)
+* [Как установить два независимых Chrome браузера на один ПК](https://www.youtube.com/watch?v=tyg15uz2F1M)
+* [Инструменты коммуникации для QA, и не только](https://www.youtube.com/watch?v=W2N9ALAqHSE)
+* [Application monitoring and error tracking software](https://sentry.io/welcome/#)
+* [Katacoda - Learn new technologies using real environments right in your browser](https://www.katacoda.com)
+
diff --git a/prakticheskaya-chast/README.md b/prakticheskaya-chast/README.md
new file mode 100644
index 0000000..c5d5a45
--- /dev/null
+++ b/prakticheskaya-chast/README.md
@@ -0,0 +1,2 @@
+# Практическая часть
+
diff --git a/prakticheskaya-chast/logicheskie-zadachi.md b/prakticheskaya-chast/logicheskie-zadachi.md
new file mode 100644
index 0000000..280d791
--- /dev/null
+++ b/prakticheskaya-chast/logicheskie-zadachi.md
@@ -0,0 +1,31 @@
+# Логические задачи
+
+1. Могут быть буквально на логику (тесты Войнаровского):
+
+«Саша смотрит на Ольгу, а Ольга смотрит на Андрея. У Саши есть дети, у Андрея нет. Смотрит ли человек, у которого есть дети, на человека, у которого детей нет? Варианты ответа: «Да», «Нет», «Нельзя определить». Объясните свою точку зрения.»
+
+2\. На рассуждение и перебор вариантов, цель - увидеть, как думает кандидат и насколько он эрудирован:
+
+* Мессенджер. Один пользователь отправляет другому сообщение - не доходит. В чем может быть причина?
+* Два абсолютно идентичных компьютера (аппаратная и программная конфигурация), файлы скачиваются с разной скоростью. Почему?
+* Два абсолютно идентичных компьютера (аппаратная и программная конфигурация), на одном баг воспроизводится, на другом нет. Почему?
+* Два разных мобильных устройства с одинаковой версией приложения. Бэк и связь стабильны. На одну приходят нотификации, на другую нет. В чем может быть причина?
+* Есть форма с 5 полями, после отправки в БД записываются только 4. В чем может быть причина?
+* Приложение при старте запрашивает по API профиль пользователя и на основе полученных данных расставляет в правильном порядке свои блоки интерфейса на главном экране. То есть ему нужны только цифры, остальное рендерится из готовых элементов приложения. На основе только этих данных, можно ли сказать что приложение является нативным или гибридным?
+
+3\. Или на «логику»:
+
+«Есть две изолированные друг от друга комнаты. В одной находятся 3 лампочки, в другой - три выключателя. Вы стоите в комнате с выключателями и можете перейти в комнату с лампочками лишь один раз. Необходимо определить, какая лампочка включается каким выключателем.»
+
+К первому типу можно подготовиться, изучив самые азы мат. логики и порешав несколько примеров. Многие относятся к этому несерьезно и проваливают этот тип заданий, между тем такие задачки щелкают на олимпиадах 5-клашки.
+
+Второй тип задач показывает эрудированность в области computer science, здесь помогут только базовые общие курсы.
+
+Про подготовку к третьему типу задач, если опустить дискуссии об их бесполезности, можно сказать только то, что проще их просто прочитать и запомнить решение.
+
+Доп. материал:
+
+* Уильям Паундстоун - “Как сдвинуть гору Фудзи”
+* [Мы нашли все самые крутые логические задачи](https://habr.com/ru/post/549844/)
+* [Логическая задача про лифт](https://thecode.media/lift/)
+* [У вас есть два ведра емкостью 3 литра и 5 литров и неограниченный запас воды. Как можно отмерить точно 4 литра воды?](https://mydocx.ru/7-30967.html)
diff --git a/prakticheskaya-chast/platformy-dlya-trenirovok-i-kvizy.md b/prakticheskaya-chast/platformy-dlya-trenirovok-i-kvizy.md
new file mode 100644
index 0000000..e603a77
--- /dev/null
+++ b/prakticheskaya-chast/platformy-dlya-trenirovok-i-kvizy.md
@@ -0,0 +1,20 @@
+# Платформы для тренировок и квизы
+
+* [Треугольники](https://playground.learnqa.ru/puzzle/triangle)
+* [Testing Challenges](http://testingchallenges.thetestingmap.org/index.php)
+* [TestQuiz](https://www.softwaretestingmaterial.com/quiz/testquiz/)
+* [Can't Unsee](https://cantunsee.space)
+* [User Inyerface](https://userinyerface.com/game.html)
+* [Text and code quizzes](https://skillotron.com/skills/qa-general)
+* [Тестовый магазин](https://qatester.ru/bugs)
+* [Examples of Bugs](https://academybugs.com)
+* [The greatest factorial calculator!](http://qainterview.pythonanywhere.com)
+* [Сайт](http://volchansk.pp.net.ua)
+* [Тестовый магазин](http://shop.bugred.ru/shop/1)
+* [Калькулятор](http://bugred.ru/calc/)
+* [Skillotron QA Manual Tests](https://skillotron.com/qualifications/qa-manual)
+* [Guru99 Quizzes](https://www.guru99.com/tests.html)
+* [Пробные экзамены](https://www.gasq.org/ru/%D1%81%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F/%D0%BF%D1%80%D0%BE%D0%B1%D0%BD%D1%8B%D0%B5-%D1%8D%D0%BA%D0%B7%D0%B0%D0%BC%D0%B5%D0%BD%D1%8B.html)
+* [ISTQB Trainer](https://istqb-training.ru)
+* [This playlist consists of an end-to-end discussion of ISTQB Foundation syllabus tutorials](https://www.youtube.com/playlist?list=PLj5VKaW115t1o1hk5ZbNWFr4sW5mBpvmv)
+* [«Нужно больше топлива!»: тест для разработчиков и тестировщиков](https://habr.com/ru/article/577128/)
diff --git a/prakticheskaya-chast/primery-zadach-na-sobesedovaniyakh-i-testovykh-zadanii.md b/prakticheskaya-chast/primery-zadach-na-sobesedovaniyakh-i-testovykh-zadanii.md
new file mode 100644
index 0000000..590f743
--- /dev/null
+++ b/prakticheskaya-chast/primery-zadach-na-sobesedovaniyakh-i-testovykh-zadanii.md
@@ -0,0 +1,89 @@
+# Примеры задач на собеседованиях и тестовых заданий
+
+1. Дан веб-сайт, на котором есть каталог и реализована регистрация. На каких уровнях и что будете тестировать, конкретно по пунктам?
+2. Дана багтрекинговая система. Протестируйте воркфлоу (жизненный цикл бага);
+3. Аутлук - протестировать форму отправки письма (только этот функционал);
+4. Дано мобильное приложение: случайное подбрасывание игрального кубика. Как будете тестировать (кейсы)?
+5. Есть некий обучающий портал с видео. Видео можно смотреть бесплатно до некоторой величины. При просмотре видео на 80% считается, что просмотрщик согласен заплатить (необходимо пометить видео как просмотренное, добавить в некий список, не суть). Необходимо накидать тестов, как проверить просмотр 80% контента;
+6. Есть ограничение родительский контроль. Какое минимальное количество тест-кейсов потребуется для проверки с ограничениями G,PG,R,NC-17,18+ если в наличии 40 каналов, 15 с ограничением G, 10- PG, 10- R, 3- NC-17 , 2 - 18+?
+7. В стране «Функциляндия» живут функи. И они очень вредные. Они ходят на работу и школы (взрослые и дети). Сразу можно увидеть кто из них, кто. Те, что розового цвета - те идут в школу, те, что серые - на работу. Иногда происходят метаморфозы. Если розового функа вызвать к доске на уроке в школе, он станет серым и почти не отличим от ходящего на работу, но и в этом случае его можно отличить, его щеки будут слегка розовые. Иногда серые функи становятся розовыми это случается по пятницам после 19.00, в таком случае, когда пойдут на работу снова будут серыми. Мы изобрели очки, смотря в которые можно увидеть надпись над функом, показывающею его принадлежность. Если смотрим на взрослого, то появится надпись «Биг босс» если на детей «Бэби босс». Вопрос: Какой информации Вам не хватает для проверки? Какие вопросы Вы бы задали аналитику для проверки этих очков?
+8. Условие. К нам обратился заказчик: у него есть сайт на устаревшем движке, он хочет чтобы разработали новый сайт на современном движке и заодно сделали редизайн. Мы завершили работы и теперь остался последний этап: перенести все новости со старого сайта на новый. Программисты разработали скрипт, переносящий новости со старого сайта на новый. Теперь тестировщику необходимо проверить правильно ли перенеслись новости. Каждая новость содержит: заголовок, подзаголовок, текст, обязательную картинку-миниатюру, опциональное видео, опциональную галерею картинок. Каждая новость относится к одному из 5 разделов. Задача. Напишите сценарий тестирования (тест-кейсы) для скрипта переноса новостей;
+9. У пользователя 4 из 5 попыток залогиниться (одинаковые комбинации логина\пароля) - неудачные, и одна из пяти - удачная. Логов сервера нет. Как бы вы расследовали баг, и на что обратили бы внимание? (Сам вопрос [тут](https://t.me/qa\_ru/177013), дальше есть обсуждение вариантов);
+10. Представьте ситуацию, что у разрабатываемого приложения еще нет интерфейса, но реализован REST API. Разработчик просит вас создать какую-то сущность в базе и проверить, что она создалась с нужными параметрами. Опишите ход ваших действий в данной ситуации: что и как вы бы проверили, опираясь на имеющееся описание API, с указанием конкретики (название типов запросов и т.д.);
+11. В англоязычных ресурсах встречаются задачи на определение decision/statement/branch coverage;
+12. Спроектировать спецификацию API для калькулятора;
+13. Написать тест-кейсы/тест-план для тестирования будильника/лифта/весов/светофора/кофейного автомата/…;
+14. Как изменятся кейсы для кофейного автомата, если оплата происходит только со смартфона через оператора сотовой связи (SMS)?
+15. Разделить колоду карт на классы эквивалентности (Equivalence Class Partitioning);
+16. Протестировать поиск адресов;
+17. Протестировать установку приложения при недостаточном количестве места не телефоне;
+18. Протестировать требование: приложение не должно быть доступно для скачивания пользователям некоторых стран;
+19. Есть проект к которому вас подключают. Срок его сдачи - через 2 недели. Есть команда которая его разрабатывала и РМ проекта. Есть коммуникация с клиентом. Как вы построите процесс работы по этому проекту чтобы сдать проект в срок и на чём вы будете основывать идею что проект “Готов”?
+20. Ты на новом рабочем месте. Перечисли действия и команды GIT как ты склонируешь себе репозиторий и создашь свою ветку;
+21. Вы инженер по контролю качества в Uber и только что узнали, что пассажиры больше не получают текстовые сообщения. Каковы ваши дальнейшие действия по локализации ошибки?
+22. Вот тебе комп и работающий сайт. Сделай мне 401-ю ошибку (снифферы с подменой);
+23. Оценить время на тестирование продукта;
+24. Написать чеклист для функционала корзины в интернет-магазине.
+25. Написать тестовые наборы данных для поля ввода даты, которое отсеивает пользователей в возрасте до 18 лет.
+26. Написать чеклист тестирования формы ввода данных платежной карты.
+27. Протестировать «предмет» для различных видов тестирования. (Предмет - лифт, карандаш, калькулятор и т.д.)
+28. Имеется Input поле, принимающее целые значения от 18 до 99 включительно. Следует протестировать с помощью техники тест-дизайна Boundary Values Analysis и Equivalence Partitioning.
+29. Есть веб-страница с полями: e-mail, password и кнопкой submit. Необходимо привести примеры отрицательных тест-кейсов, по которым можно проверить эту страницу.
+30. Привести примеры тест-кейсов для функционала, находящегося на нескольких страницах проекта (например, поле поиска).
+31. Как протестировать процесс оплаты в интернет-магазине?
+32. Объясните 7-летнему ребенку, что такое база данных.
+33. Определите количество функциональных тест-кейсов, чтобы проверить Login форму.
+34. Есть форма регистрации в веб-приложении с полями (first name, last name, username, password, repeat password) и кнопкой Register. Какие проверки нужно провести?
+35. Поле username должно быть обязательным, но оно не обязательно. Приведите пример баг-репорта, созданного для этой ошибки.
+36. Как вы провели smoke-testing для приложения типа Telegram?
+37. Как будет выглядеть баг-репорт, если, к примеру, не работает электрический чайник?
+38. Есть таблица books с полями: name, price, page\_count. Нужно выбрать все имена книг, в которых price более 10 единиц и количество страниц от 20 до 100.
+39. У вас есть функционал калькулятора, доступный через веб браузер по ссылке . Он имеет только функцию делить, так сказать, MVP-версию. Диапазоны для вписывания в числитель и делитель от 0,1 до 99,9. Вывод значения происходит автоматически, потому что front-end реализован на React JS. Как вы будете тестировать этот функционал? Какие виды тестирования примените? Какие техники тест-дизайна используете?
+40. [Несколько примеров задач с решениями](https://drive.google.com/file/d/1bUoYe6KeNO8bR3hhv-9ChuNPo0CwG1PX/view)
+41. [Тестовое задание на позицию специалист по тестированию (QA специалист) в СПб ИАЦ](https://docs.google.com/document/u/0/d/1xJuebAdcFSBQtVpmvWjjkPDXLalvx2gAjd8Fhe\_UTg4/mobilebasic)
+42. [Тестовое задание для специалиста по тестированию](https://docs.google.com/document/d/19wWZLQNDe8DSHZ8BAuX-DFa62SRYBy3qOKJAgqCqqQs/edit#) + [Инструкция](https://docs.google.com/document/d/18289fUEOSX1pmaLVBFmOMf32s1vAd5uVOLiTNoaLB40/edit#)
+43. [Тестирование программы, которая определяет тип треугольника по трем его сторонам](https://playground.learnqa.ru/puzzle/triangle)
+44. Тестовое задание: написать кейсы для [нового метода API](https://disk.yandex.ru/i/esax6PM2rZxLTw)
+45. [Тестовое задание на позицию специалист по тестированию (QA специалист) в СПб ИАЦ](https://docs.google.com/document/u/0/d/1kQ\_WOYty6\_2jO4b8avLsIbRKl\_wEYAxaLINPglZXYg4/mobilebasic)
+46. [ТЗ Тестировщик SL](https://docs.google.com/document/d/1SJkIiqpkRsRLuAO3bp3aSK82Idy6jnlhBYXK1fnfLcY/edit)
+47. [Тестовое задание](https://docs.google.com/document/d/1mk89HloPcct0DxeHX9DtyVbZ9GpuGaCczoTq9Pemuk0/edit)
+48. [задачка для тестирования](https://software-testing.ru/forum/index.php?/topic/16123-zadachka-dlia-testirovaniia/)
+49. [Тестовое задание](https://docs.google.com/document/d/1ZL5EtUXHr-eDFop86JbsDNOpM-t7GVXlDchKtVJ1U\_c/edit)
+50. [Проф. задание для Тестировщика QA](https://telegra.ph/Prof-zadanie-dlya-Testirovshchika-QA-09-09)
+51. [тз](https://docs.google.com/document/d/1H2DyCiIerU7cBvXeEQCDbUOL743jyhe5DbMpX\_RqSSM/mobilebasic)
+52. [Задание](https://docs.google.com/document/d/1faHFLLjdmoC52pBbyCBu273WBPJR-PSw\_xHZwvP2NIw/edit)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Доп. материал:
+
+* [Проект Хомячки](https://software-testing.ru/forum/index.php?/forum/736-proekt-khomiachki/)
+* [ТЕСТОВОЕ ЗАДАНИЕ ТЕСТИРОВЩИКА / Какие бывают тестовые задания для QA, как делать тестовое](https://www.youtube.com/watch?v=q75avN98ibg\&feature=youtu.be\&ab\_channel=AlphaITSchool)
+* [Записи прямых эфиров с разбором тестовых задания для тестировщика](https://www.youtube.com/playlist?list=PLKbJd47Kcbjtjxj9HrDWcT\_tR5ZJ-yjzn)
+* [Как тестировать веб сайт? Практика в примерах](https://www.youtube.com/watch?v=7jsO95MEkC0)
+* [Как испортить приложение и оттолкнуть пользователей. Разбираем и исправляем ошибки в приложении Роскомнадзора](https://vc.ru/design/224426-kak-isportit-prilozhenie-i-ottolknut-polzovateley-razbiraem-i-ispravlyaem-oshibki-v-prilozhenii-roskomnadzora)
+* [Hacking challenge site](https://hack.ainfosec.com)
+* [Как найти хотя бы 1 баг + пример](https://www.youtube.com/watch?v=eS\_dn64GuaQ)
+* [Практическое тестовое задание на позицию тестировщика (junior QA)](https://www.youtube.com/watch?v=3Ufo23ylSPU)
+* [Тестируем электрический чайник](https://www.learnqa.ru/tpost/6xpsluumu1-testiruem-elektricheskii-chainik)
+* [Тестирование чашки для кофе](https://vk.com/topic-28941412\_29428317)
+* [Как тестировать карандаш?](https://www.youtube.com/watch?v=Erctsy6i0zo)
+* [Как тестировать карандаш](https://www.youtube.com/watch?v=HWmDx8AD4eU)
+* [Как бы вы протестировали дверь?](https://tproger.ru/quiz/kak-by-vy-protestirovali-dver/)
+* [Баги ListBoxer](https://software-testing.ru/forum/index.php?/topic/37944-bagi-listboxer/)
+* [Решение задачи: Палиндром](http://ap-test-team.blogspot.com/2011/08/blog-post.html)
+* Множество практических задач с разбором было на [стримах Вадима Ксендзова](https://www.youtube.com/channel/UC6hNNlCXv1ZgdGpziNf83RA/videos)
diff --git a/prakticheskaya-chast/testirovanie-polei-i-form.md b/prakticheskaya-chast/testirovanie-polei-i-form.md
new file mode 100644
index 0000000..5314be1
--- /dev/null
+++ b/prakticheskaya-chast/testirovanie-polei-i-form.md
@@ -0,0 +1,50 @@
+# Тестирование полей и форм
+
+“Дана форма для регистрации. Протестируйте” - вопрос номер один практически на всех собеседованиях на младшую позицию. Он хорош еще и тем, что в зависимости от уровня кандидата будет раскрыт в разной степени. Всегда в первую очередь уточняйте хотя бы какие-то минимальные требования, даже если вначале озвучивают, что требования не формализованы.
+
+* Начальный уровень представляет из себя простые позитивные и негативные кейсы (в основном на валидацию):
+ * Обязательные поля отмечены \*
+ * Обязательные поля заполнены/нет
+ * Галочки на соглашениях проставлены/нет
+ * Поле password и подтверждение имеет соответствующий тип (в полях формы прописан корректный атрибут TYPE, сообщающий браузеру тип элементов формы.)
+ * Проверяется, что пароли одинаковы
+ * Имя пользователя валидируется как минимум на длину и спец. символы, остальное по ТЗ
+ * Адрес почты валидируется в соответствии со стандартом (наличие символа @, несколько символов @, длины частей до и после @, допустимые символы до и после, наличие пробелов перед адресом и после, корректная доменная часть и т.п.)
+ * Поля с ожидаемым числовым вводом и текстовым соответственно проверить позитивными и негативными кейсами по типам данных
+* Следующий уровень:
+ * Все из предыдущего
+ * Кроссбраузерность
+ * Понятность формы. Присутствует описание полей или плейсхолдеры
+ * Сенситив данные не должны передаваться в URL
+ * Проверяем, как форма отображается до сабмита и после
+ * Поведение, если нажать сабмит несколько раз подряд
+ * Если формы очищаются после сабмита, проверить регистрацию существующего пользователя
+ * Проверка глобализации - номер телефона, дата, почтовый индекс, валюта, вертикальное или RTL письмо и т.п. (опционально)
+ * Проверка простых инъекций
+ * Правильная работа многошаговых форм (Навигация рядом с формой показывает текущий этап и количество оставшихся шагов.)
+ * Для полей, предполагающих загрузку файлов, прописан атрибут accept, определяющий тип загружаемых документов
+ * Текстовое многострочное поле при вводе объемного сообщения изменяет высоту либо в правой части появляется скроллбар для просмотра всего содержимого
+ * Для авторизованного пользователя в поля формы автоматически подставляются все известные о посетителе данные.
+ * Форма сохраняется в веб-формах (админ-панели) или SQL-таблицах.
+ * Прописан реальный e-mail лица, отвечающего за обработку заявок (если предполагается ОС)
+ * Опционально. Пользователь получает уведомление на свой e-mail об успешно полученной заявке и последующих действиях, которые от него требуются.
+ * Прописан атрибут autocomplete для полей, поддерживающих это значение
+* Extra:
+ * Проверяем, отправились ли данные после сабмита
+ * Проверяем, добавились ли соответствующие записи в бд
+ * Проверка загрузки формы и сабмита при медленном/нестабильном интернет-соединении
+ * Корректность cookies/токена и т.п. после сабмита
+
+Доп. материал:
+
+* [Пароли, их тестирование и использование](https://training.qatestlab.com/blog/technical-articles/testing-and-using-passwords/)
+* [Принципы и тестовые сценарии для тестирования паролей](https://testmatick.com/ru/osobennosti-testirovaniya-parolej/)
+* [Как Тестировать? Форма Входа](http://marshrut-testirovshika.ru/forma\_vhoda/)
+* [Acceptable email address syntax according to RFC](https://www.mailboxvalidator.com/resources/articles/acceptable-email-address-syntax-rfc/)
+* [Как тестировать формы? Мини-руководство](https://testengineer.ru/mini-gajd-po-testirovaniyu-form/)
+* [Как вы протестируете текстовое поле?](https://software-testing.ru/library/testing/test-analysis/3713-how-would-you-test-text-field)
+* [Чек-лист для тестирования числового поля](https://okiseleva.blogspot.com/2020/10/blog-post\_28.html#more)
+* [Чек-лист для веб-форм](https://disk.yandex.ru/i/VdGkQ\_oPt7n9xQ)
+* [Как протестировать какое-то поле](https://www.youtube.com/watch?v=Q0kSqdOzFvw)
+* [Пример тестирования поля «Имя»](https://www.youtube.com/watch?v=3-5RbtRaYnk)
+* [Как найти границы на клиенте и сервере](https://habr.com/ru/post/510458/)
diff --git a/sdlc-i-stlc/README.md b/sdlc-i-stlc/README.md
new file mode 100644
index 0000000..bcdbd1a
--- /dev/null
+++ b/sdlc-i-stlc/README.md
@@ -0,0 +1,2 @@
+# SDLC и STLC
+
diff --git a/sdlc-i-stlc/agile.md b/sdlc-i-stlc/agile.md
new file mode 100644
index 0000000..3aa52a0
--- /dev/null
+++ b/sdlc-i-stlc/agile.md
@@ -0,0 +1,115 @@
+# Agile
+
+Agile - это способность создавать и реагировать на изменения. Это способ справиться с неопределенной и неспокойной средой и в конечном итоге преуспеть в ней. Авторы Agile Manifesto выбрали «Agile» в качестве названия всей этой идеи, потому что это слово олицетворяет адаптивность и реакцию на изменения, которые так важны для их подхода. На самом деле речь идет об осмыслении того, как вы можете понять, что происходит в среде, в которой вы находитесь сегодня, определить, с какой неопределенностью вы сталкиваетесь, и выяснить, как вы можете адаптироваться к этому по мере продвижения.
+
+Гибкая разработка программного обеспечения - это больше, чем такие фреймворки, как Scrum, Extreme Programming или Feature-Driven Development (FDD). Гибкая разработка программного обеспечения - это больше, чем такие практики, как парное программирование, разработка на основе тестирования, стендапы, сессии планирования и спринты.
+
+Гибкая разработка программного обеспечения - это общий термин для набора структур и практик, основанных на ценностях и принципах, изложенных в Манифесте гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе. Когда вы подходите к разработке программного обеспечения особым образом, обычно хорошо жить в соответствии с этими ценностями и принципами и использовать их, чтобы помочь понять, что делать в вашем конкретном контексте.
+
+Одна вещь, которая отличает Agile от других подходов к разработке программного обеспечения, - это сосредоточение внимания на людях, выполняющих работу, и на том, как они работают вместе. Решения развиваются в результате сотрудничества между самоорганизующимися кросс-функциональными командами, использующими соответствующие методы для своего контекста. Сообщество Agile-разработчиков программного обеспечения уделяет большое внимание совместной работе и самоорганизующейся команде. Это не значит, что менеджеров нет. Это означает, что команды могут самостоятельно определять, как они собираются подходить к делу. Это означает, что эти команды кросс-функциональны. Этим командам не обязательно должны быть задействованы определенные роли, просто когда вы собираете команду вместе, вы убедитесь, что у вас есть все необходимые навыки в команде. Еще есть место для менеджеров. Менеджеры следят за тем, чтобы члены команды имели или приобрели правильный набор навыков. Менеджеры создают среду, которая позволяет команде быть успешной. Менеджеры в основном отступают и позволяют своей команде выяснить, как они собираются выпускать продукты, но они вмешиваются, когда команды пытаются, но не могут решить проблемы. Когда большинство команд и организаций начинают заниматься гибкой разработкой, они сосредотачиваются на практиках, которые помогают в совместной работе и организации работы, и это здорово. Однако другой ключевой набор практик, которым не так часто следуют, но которые должны соблюдаться, - это конкретные технические практики, которые напрямую связаны с разработкой программного обеспечения таким образом, чтобы помочь вашей команде справиться с неопределенностью. Эти технические приемы очень важны, и их нельзя упускать из виду.
+
+В конечном итоге Agile - это образ мышления, основанный на ценностях и принципах Agile Manifesto. Эти ценности и принципы содержат указания о том, как создавать изменения и реагировать на них, а также как справляться с неопределенностью. Можно сказать, что первое предложение Agile Manifesto заключает в себе всю идею: «Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это». Когда вы сталкиваетесь с неуверенностью, попробуйте что-то, что, по вашему мнению, может сработать, получите обратную связь и внесите соответствующие коррективы. При этом помните о ценностях и принципах. Позвольте вашему контексту определять, какие рамки, практики и методы вы используете для сотрудничества со своей командой и предоставления ценности вашим клиентам.
+
+Если Agile - это образ мышления, то что это говорит об идее Agile-методологий? Чтобы ответить на этот вопрос, вам может быть полезно иметь четкое определение методологии. Алистер Кокберн предположил, что методология - это набор условностей, которым команда соглашается следовать. Это означает, что у каждой команды будет своя собственная методология, которая будет в малой или большой степени отличаться от методологии любой другой команды. Таким образом, Agile-методологии - это условности, которым команда решает следовать в соответствии с ценностями и принципами Agile. Вы, наверное, скажете: «Подождите, - я думал, что Scrum и XP - это Agile-методологии». Алистер применил термин “framework” к этим концепциям. Они, безусловно, родились на основе методологии одной команды, но они стали фреймворками, когда были обобщены для использования другими командами. Эти фреймворки помогают понять, где команда начинает свою методологию, но они не должны быть ее методологией. Команде всегда необходимо адаптировать использование фреймворка, чтобы оно соответствовало его контексту.
+
+**Ключевые концепции Agile**
+
+* Пользовательские истории (**User Stories**): после консультации с заказчиком или владельцем продукта команда делит работу, которую необходимо выполнить, на функциональные этапы, называемые «пользовательскими историями». Ожидается, что каждая пользовательская история внесет свой вклад в ценность всего продукта;
+* Ежедневные собрания (**Daily Meeting**): каждый день в одно и то же время группа собирается, чтобы ознакомить всех с информацией, которая имеет жизненно важное значение для координации: каждый член команды кратко описывает все «завершенные» вклады и любые препятствия, стоящие на их пути;
+* Персонажи (**Personas**): когда этого требует проект - например, когда пользовательский опыт является основным фактором результатов проекта - команда создает подробные синтетические биографии фиктивных пользователей будущего продукта: они называются personas;
+* Команда (**Team**): «Команда» в Agile понимании - это небольшая группа людей, назначенных на один и тот же проект или effort, почти все из них на постоянной основе. Незначительное меньшинство членов команды может работать неполный рабочий день или иметь конкурирующие обязанности;
+* Инкрементальная разработка (**Incremental Development**): почти все Agile-команды отдают предпочтение стратегии инкрементального развития; в контексте Agile это означает, что можно использовать каждую последующую версию продукта, и каждая основывается на предыдущей версии, добавляя видимые для пользователя функциональные возможности;
+* Итеративная разработка (**Iterative Development**): Agile-проекты являются итеративными, поскольку они намеренно позволяют «повторять» действия по разработке программного обеспечения и потенциально «пересматривать» одни и те же рабочие продукты;
+* Ретроспектива (**Milestone Retrospective**): после того, как проект был запущен в течение некоторого времени или в конце проекта, все постоянные члены команды (не только разработчики) вкладывают от одного до трех дней в подробный анализ значимых событий проекта.
+
+**The Agile Manifesto**:
+
+* люди и взаимодействие важнее процессов и инструментов;
+* работающий продукт важнее исчерпывающей документации;
+* сотрудничество с заказчиком важнее согласования условий контракта;
+* готовность к изменениям важнее следования первоначальному плану.
+
+Основополагающие принципы Agile Manifesto:
+
+* наивысшим приоритетом признается удовлетворение заказчика за счет ранней и бесперебойной поставки ценного программного обеспечения;
+* изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
+* частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего периода);
+* общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта;
+* проекты следует строить вокруг заинтересованных людей, которых следует обеспечить нужными условиями работы, поддержкой и доверием;
+* самый эффективный метод обмена информацией в команде - личная встреча;
+* работающее программное обеспечение - лучший измеритель прогресса;
+* спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
+* постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость;
+* простота как искусство не делать лишней работы очень важна;
+* лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд;
+* команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс.
+
+**Существуют методологии**, которые придерживаются ценностей и принципов заявленных в Agile Manifesto, некоторые из них:
+
+* Agile Modeling - набор понятий, принципов и приемов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения. Не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель: эффективное моделирование и документирование; но не охватывает программирование и тестирование, не включает вопросы управления проектом, развертывания и сопровождения системы. Однако включает в себя проверку модели кодом.
+* Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений.
+* Agile Data Method- группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд.
+* DSDM основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.
+* Essential Unified Process (EssUP).
+* Экстремальное программирование (Extreme programming, XP).
+* Feature driven development (FDD) - функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (англ. feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие - это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.
+* Getting Real - итеративный подход без функциональных спецификаций, использующийся для веб-приложений. В данном методе сперва разрабатывается интерфейс программы, а потом её функциональная часть.
+* OpenUP - это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как легкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.
+* Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта.
+* Бережливая разработка программного обеспечения (lean software development) использует подходы из концепции бережливого производства.
+
+**Манифест тестирования в Agile**:
+
+* постоянное тестирование, а не только в конце разработки;
+* предотвращение багов более значимо, чем их поиск;
+* понимание тестируемого продукта выше проверки функционала;
+* построение лучшей системы в связке с командой выше поиска методов ее сломать;
+* вся команда отвечает за качество, а не только тестировщик.
+
+**Особенности тестирования в Agile**
+
+В Agile, тестирование - это ответственность каждого. Критерий качества должен соблюдаться на протяжении всего цикла. В то время как бизнес-аналитики сосредотачиваются на создании подробных пользовательских историй, разработчики сосредотачиваются на разработке качественного кода, QA несет ответственность за уточнение критериев приемлемости для каждой пользовательской истории, тестирование завершенной функциональности в каждом спринте с точки зрения клиента и проверка всей ранее выполненной функциональности. Роли и ответственность QA не ограничиваются только тестированием в Agile, но также включают в себя следующее:
+
+* QA работают в тесном сотрудничестве с владельцами продуктов, бизнес-аналитиками и командой разработчиков, чтобы понять разрабатываемый продукт, для кого он предназначен и каковы будут критерии успеха продукта.
+* Они углубляются в критерии приемки, созданные бизнес-аналитиками, для написания тестовых примеров, визуализации рабочего процесса, тестирования стандартных элементов и проведения негативного тестирования.
+* Опытный QA также хорошо осведомлен об объеме выпуска и соответственно устанавливает границы своего тестирования.
+* Тестировщики должны общаться с командой и задавать вопросы во время тестирования, что позволяет им выявлять пробелы в требованиях или получать ответы на нерешенные вопросы. Коммуникация и сотрудничество с командой имеют решающее значение, поскольку они помогают сделать тестирование более точным и надежным. Это также помогает достичь необходимого темпа, чтобы двигаться быстрее, с ранними отзывами о тестировании и повышенным качеством.
+* Как член Agile команды, тестировщик всегда должен быть синхронизирован с командой проекта, посещая сессии планирования спринтов для выявления возможных проблемных областей и ежедневных митингов для содействия сотрудничеству. Посещение ретроспективы спринта дает возможность выявить слабые места и определить решения внутри команды. Посещение митингов по обзору спринта или демонстрации продукта позволяет тестировщику увидеть, как работает новая функция, и дает им возможность задать важные вопросы разработчикам.
+* Документирование сценариев тестирования и выполнения тестов с доказательствами важно для тестировщиков, но оно должно быть минимальным и кратким.
+
+Какие стратегии использует QA для проведения Agile-тестирования?
+
+В каждой организации есть разные подходы и стратегии, которые они используют для тестирования приложений. Методология Agile предполагает подготовку документации, достаточной только для удовлетворения насущных потребностей команды. Таким образом, QA подготовят достаточно высокоуровневой документации для стратегий тестирования и планов для руководства командой. Ниже приведены несколько стратегий, которым я следую при подготовке к тестированию в Agile:
+
+* Чрезвычайно важно иметь четкий план до начала тестирования. Перед началом тестирования спланируйте свое время и тест-кейсы, и это позволит вам сразу же погрузиться в тестирование после развертывания приложения.
+* Я использую сочетание ручного и автоматизированного тестирования. Автоматизированное тестирование помогает мне ускорить мои регрессионные тесты с помощью наборов тестов перед сборкой, а ручное тестирование помогает мне, когда мне нужно проводить более сфокусированное тестирование.
+* Как тестировщик, я всегда верю в проведение смоук-тестов основных или базовых функций сразу после развертывания приложения, что помогает мне выявлять любые ошибки критические раньше.
+* Выполнение приемочных испытаний, основанных на критериях приемки, чтобы обеспечить лучшее покрытие тестами. Каждый критерий приемки может иметь одно или несколько приемочных испытаний и ориентирован на заданные условия.
+* Тестирование эффективности потока помогает определить, могут ли пользователи беспрепятственно перемещаться по продукту. Это помогает определить, сбивает ли вас с толку какая-либо часть потока, и помогает определить, нужно ли вам добавлять или удалять какие-либо шаги.
+* Проверка бизнес-правил и определений данных - важная часть тестирования.
+* Проведение исследовательского тестирования позволяет тестировщикам идти по неопределенному пути и находить скрытые риски и дефекты в приложении.
+* Проведение регрессионного тестирования - важная часть гибкого тестирования. Регрессионное тестирование гарантирует, что проверенные функции работают должным образом после введения новых функций.
+* Использование кроссбраузерного тестирования чрезвычайно важно для гибкого тестирования, так как тестировщик может быстро протестировать несколько устройств и браузеров за ограниченное время.
+* Наличие приложений для обмена сообщениями в реальном времени, таких как Slack и Zoom, позволяет всем в команде быть на связи и быстро отвечать на важные вопросы.
+
+Источники:
+
+* [Agile 101](https://www.agilealliance.org/agile101/)
+* [Гибкая методология разработки](https://ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B1%D0%BA%D0%B0%D1%8F\_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F\_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8)
+* [Руководство тестировщика по Agile тестированию](https://telegra.ph/Rukovodstvo-testirovshchika-po-Agile-testirovaniyu-03-01)
+
+Доп. материал:
+
+* [ISTQB Agile Tester Extension Exam Theory Study Material Part 1](https://www.softwaretestinggenius.com/istqb-agile-tester-extension-exam-theory-study-material-part-1/)
+* [ISTQB Agile Tester Extension Exam Crash Course Part 1](https://www.softwaretestinggenius.com/istqb-agile-tester-extension-exam-crash-course-part-1/)
+* [Agile Glossary](https://www.agilealliance.org/agile101/agile-glossary/)
+* [Agile Software Development, lessons learned by Jerome Kehrli](https://www.niceideas.ch/roller2/badtrash/entry/agile-software-development-lessons-learned)
+* [Организация процесса тестирования в Agile команде с помощью квадрантов тестирования. - презентация](https://mypresentation.ru/presentation/organizaciya\_processa\_testirovaniya\_v\_Agile\_komande\_s\_pomoshhyu\_kvadrantov\_testirovaniya\_\_prezentaciya)
+* [10 примеров эффективного общения для тестировщиков](https://habr.com/ru/company/otus/blog/533400/)
+* [Как выживать тестировщику в Agile среде](https://www.youtube.com/watch?v=dHGq4ago09k\&ab\_channel=ITVDN)
+* [Стратегия тестирования краткосрочного проекта](https://habr.com/ru/company/arcadia/blog/542974/)
+* [Eight Signs Your Agile Testing Isn’t That Agile](https://medium.com/slalom-build/eight-signs-your-agile-testing-isnt-that-agile-d3989bc1b9bb)
+* [4 Agile Testing Trends That Will Continue in 2022](https://blog.gurock.com/agile-testing-trends/)
+* [Рассказ о ненастоящем эджайле](https://testengineer.ru/nenastoyashchij-agile/)
+* [Complete Study Material - ISTQB Agile Tester Extension Level Exam](https://www.softwaretestinggenius.com/complete-study-material-istqb-agile-tester-extension-level-exam/)
+* [8 признаков того, что ваше Agile-тестирование не такое уж и гибкое](https://habr.com/ru/post/651305/)
diff --git a/sdlc-i-stlc/modeli-razrabotki-po.md b/sdlc-i-stlc/modeli-razrabotki-po.md
new file mode 100644
index 0000000..f9c1e2e
--- /dev/null
+++ b/sdlc-i-stlc/modeli-razrabotki-po.md
@@ -0,0 +1,94 @@
+# Модели разработки ПО
+
+Чтобы лучше разобраться в том, как тестирование соотносится с программированием и иными видами проектной деятельности, для начала рассмотрим самые основы - модели разработки (lifecycle model) ПО (как часть жизненного цикла (software lifecycle) ПО). При этом сразу подчеркнем, что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим именно о разработке.
+
+**Модель разработки ПО** (Software Development Model, SDM) - структура, систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов. Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя выбор стратегии, расписание, необходимые ресурсы и т.д.
+
+Знать и понимать модели разработки ПО нужно затем, чтобы уже с первых дней работы осознавать, что происходит вокруг, что, зачем и почему вы делаете. Многие начинающие тестировщики отмечают, что ощущение бессмысленности происходящего посещает их, даже если текущие задания интересны. Чем полнее вы будете представлять картину происходящего на проекте, тем яснее вам будет виден ваш собственный вклад в общее дело и смысл того, чем вы занимаетесь. Еще одна важная вещь, которую следует понимать, состоит в том, что никакая модель не является догмой или универсальным решением. Нет идеальной модели. Есть та, которая хуже или лучше подходит для конкретного проекта, конкретной команды, конкретных условий.
+
+**Водопадная модель** (waterfall model) сейчас представляет скорее исторический интерес, т.к. в современных проектах практически неприменима, исключая авиастроение, военную или космическую отрасли, медицину и финансовый сектор. Она предполагает однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом. Очень упрощенно можно сказать, что в рамках этой модели в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить.
+
+
+
+К недостаткам водопадной модели принято относить тот факт, что участие пользователей ПО в ней либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократного сбора требований. С точки зрения же тестирования эта модель плоха тем, что тестирование в явном виде появляется здесь лишь с середины развития проекта, достигая своего максимума в самом конце.
+
+**V-образная модель** (V-model)
+
+_V-модель (V-model): Модель, описывающая процессы жизненного цикла разработки программного обеспечения с момента составление спецификации требований до этапа сопровождения. V модель показывает интеграцию процессов тестирования в каждую фазу цикла разработки программного обеспечения. (ISTQB)_
+
+V-образная модель (V-model) является логическим развитием водопадной. Можно заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v-образная модели жизненного цикла ПО могут содержать один и тот же набор стадий, но принципиальное отличие заключается в том, как эта информация используется в процессе реализации проекта. Очень упрощенно можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными.
+
+
+
+**Итерационная инкрементальная модель** (iterative model, incremental model)
+
+_Инкрементная модель разработки (incremental development model): Модель жизненного цикла разработки, в которой проект разделен на серию приращений, каждое из которых добавляет часть функциональности в общих требованиях проекта. Требования приоритезированы и внедряются в порядке приоритетов. В некоторых (но не во всех) версиях этой модели жизненного цикла каждый подпроект следует «мини V-модели» со своими собственными фазами проектирования, кодирования и тестирования. (ISTQB)_
+
+_Итеративная модель разработки (iterative development model): Модель жизненного цикла разработки, в которой проект разделен обычно на большое количество итераций. Итерация это полный цикл разработки, завершающийся выпуском (внутренним или внешним) рабочего продукта, являющегося частью конечного разрабатываемого продукта, который разрастается от итерации к итерации. (ISTQB)_
+
+Итерационная инкрементальная модель является фундаментальной основой современного подхода к разработке ПО. Ключевой особенностью данной модели является разбиение проекта на относительно небольшие промежутки (итерации), каждый из которых в общем случае может включать в себя все классические стадии, присущие водопадной и v-образной моделям. Итогом итерации является приращение (инкремент) функциональности продукта, выраженное в промежуточном билде (build).
+
+
+
+Длина итераций может меняться в зависимости от множества факторов, однако сам принцип многократного повторения позволяет гарантировать, что и тестирование, и демонстрация продукта конечному заказчику (с получением обратной связи) будет активно применяться с самого начала и на протяжении всего времени разработки проекта. Во многих случаях допускается распараллеливание отдельных стадий внутри итерации и активная доработка с целью устранения недостатков, обнаруженных на любой из (предыдущих) стадий. Итерационная инкрементальная модель очень хорошо зарекомендовала себя на объемных и сложных проектах, выполняемых большими командами на протяжении длительных сроков. Однако к основным недостаткам этой модели часто относят высокие накладные расходы, вызванные высокой «бюрократизированностью» и общей громоздкостью модели.
+
+**Спиральная модель** (spiral model)
+
+Спиральная модель представляет собой частный случай итерационной инкрементальной модели, в котором особое внимание уделяется управлению рисками, в особенности влияющими на организацию процесса разработки проекта и контрольные точки.
+
+
+
+Обратите внимание на то, что здесь явно выделены четыре ключевые фазы:
+
+* проработка целей, альтернатив и ограничений;
+* анализ рисков и прототипирование;
+* разработка (промежуточной версии) продукта;
+* планирование следующего цикла.
+
+С точки зрения тестирования и управления качеством повышенное внимание рискам является ощутимым преимуществом при использовании спиральной модели для разработки концептуальных проектов, в которых требования естественным образом являются сложными и нестабильными (могут многократно меняться по ходу выполнения проекта).
+
+Гибкая модель (agile model)
+
+_Гибкая методология разработки программного обеспечения (agile software development): Группа методологий разработки программного обеспечения, основанных на итеративной поэтапной разработке, где требования и решения развиваются посредством сотрудничества между самоорганизующимися межфункциональными командами. (ISTQB)_
+
+Гибкая модель представляет собой совокупность различных подходов к разработке ПО и базируется на т.н. «agile-манифесте». Положенные в основу гибкой модели подходы являются логическим развитием и продолжением всего того, что было за десятилетия создано и опробовано в водопадной, v-образной, итерационной инкрементальной, спиральной и иных моделях. Причём здесь впервые был достигнут ощутимый результат в снижении бюрократической составляющей и максимальной адаптации процесса разработки ПО к мгновенным изменениям рынка и требований заказчика.
+
+
+
+
+
+Очень упрощенно (почти на грани допустимого) можно сказать, что гибкая модель представляет собой облегченную с точки зрения документации смесь итерационной инкрементальной и спиральной моделей; при этом следует помнить об «agile-манифесте» и всех вытекающих из него преимуществах и недостатках.
+
+Главным недостатком гибкой модели считается сложность ее применения к крупным проектам, а также частое ошибочное внедрение ее подходов, вызванное недопониманием фундаментальных принципов модели. Тем не менее можно утверждать, что всё больше и больше проектов начинают использовать гибкую модель разработки.
+
+**В некоторых источниках можно найти еще пару моделей**:
+
+**Prototype Model**
+
+Prototype Model - это модель, в которой прототип разрабатывается раньше, чем фактическое программное обеспечение. Модели-прототипы обладают ограниченными функциональными возможностями и неэффективной производительностью по сравнению с реальным программным обеспечением. Фиктивные функции используются для создания прототипов. Это ценный механизм для понимания потребностей клиентов. Внедряются отзывы, и прототип снова проверяется заказчиком на предмет любых изменений. Этот процесс продолжается до тех пор, пока модель не будет принята заказчиком. После сбора требований создается быстрый дизайн и создается прототип, который представляется заказчику для оценки. Отзывы клиентов и уточненные требования используются для модификации прототипа и снова представляются заказчику для оценки. После того, как заказчик утверждает прототип, он используется в качестве требования для создания реального программного обеспечения. Фактическое программное обеспечение построено с использованием подхода модели водопада.
+
+
+
+Преимущества прототипа модели: Модель прототипа снижает стоимость и время разработки, так как дефекты обнаруживаются намного раньше. Отсутствующие функции или функциональные возможности или изменение требований могут быть выявлены на этапе оценки и могут быть реализованы в доработанном прототипе. Вовлечение клиента на начальном этапе уменьшает путаницу в требованиях или понимании какой-либо функциональности.
+
+Недостатки прототипа модели: Поскольку заказчик участвует на каждом этапе, заказчик может изменить требования к конечному продукту, что увеличивает сложность объема работ и может увеличить время доставки продукта.
+
+Модель Большого Взрыва (**Big Bang Model**)
+
+Big Bang Model не имеет определенного процесса. Деньги и усилия объединяются, поскольку вход и выход представляют собой разработанный продукт, который может совпадать, а может и не совпадать с тем, что нужно заказчику. Модель Большого Взрыва не требует особого планирования и составления графиков. Разработчик выполняет анализ требований и кодирование, а также разрабатывает продукт в соответствии с его пониманием. Эта модель используется только для небольших проектов. Нет команды тестирования и формального тестирования не проводится, и это может быть причиной провала проекта.
+
+Преимущества модели большого взрыва: Это очень простая модель. Требуется меньше планирования и составления графиков. Разработчик может создавать собственное программное обеспечение.
+
+Недостатки модели большого взрыва: Модели Большого взрыва нельзя использовать для крупных, текущих и сложных проектов. Высокий риск и неопределенность.
+
+Источники:
+
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). Глава 2.
+* [SDLC (Software Development Life Cycle) Phases, Process, Models](https://www.softwaretestinghelp.com/software-development-life-cycle-sdlc/#Software\_Development\_Life\_Cycle\_Models)
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “Приложение С (справочное). Тестирование в различных моделях жизненного цикла”
+* [Podlodka #250 - Lean](https://www.youtube.com/watch?v=lICpNfSxDQw)
+* [Методологии разработки ПО](https://dou.ua/forums/topic/14015/)
+* [Kanban Cheat-sheet](https://pin.it/jDKPYij)
diff --git a/sdlc-i-stlc/podkhody-k-razrabotke-testirovaniyu-...-driven-development-testing.md b/sdlc-i-stlc/podkhody-k-razrabotke-testirovaniyu-...-driven-development-testing.md
new file mode 100644
index 0000000..3c651ae
--- /dev/null
+++ b/sdlc-i-stlc/podkhody-k-razrabotke-testirovaniyu-...-driven-development-testing.md
@@ -0,0 +1,35 @@
+# Подходы к разработке/тестированию (... - driven development/testing)
+
+Тут и там можно встретить упоминания различных подходов к разработке и тестированию на основе чего-то, здесь краткое описание самых часто встречающихся вариантов:
+
+* **TDD - Test Driven Development**: разработка на основе тестов основывается на повторении коротких циклов разработки: изначально пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволит пройти написанный тест. Затем проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов. Есть два уровня TDD:
+ * Acceptance TDD (ATDD): вы пишете один приемочный тест. Этот тест удовлетворяет требованиям спецификации или удовлетворяет поведению системы. После этого пишете достаточно производственного / функционального кода, чтобы выполнить этот приемочный тест. Приемочный тест фокусируется на общем поведении системы. ATDD также известен как BDD - Behavior Driven Development;
+ * Developer TDD: вы пишете один тест разработчика, то есть модульный тест, а затем просто достаточно производственного кода для выполнения этого теста. Модульное тестирование фокусируется на каждой небольшой функциональности системы. Это называется просто TDD. Основная цель ATDD и TDD - определить подробные, выполнимые требования для вашего решения точно в срок (JIT). JIT означает принятие во внимание только тех требований, которые необходимы в системе, что повышает эффективность.
+* **BDD - Behaviour Driven Development:** это разработка, основанная на описании поведения. Определенный человек(или люди) пишет описания вида "я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке" (там есть специально выделенные ключевые слова). Программисты давно написали специальные тулы, которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста). А дальше классическая разработка с тестами (TDD);
+* **TDD - Type Driven Development:** при разработке на основе типов ваши типы данных и сигнатуры типов являются спецификацией программы. Типы также служат формой документации, которая гарантированно обновляется. Типы представляют из себя небольшие контрольные точки, благодаря которым, мы получаем множество мини-тестов по всему нашему приложению;
+* **DDD** - Domain Driven Design: Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD - это набор правил, которые позволяют принимать правильные проектные решения. Это набор принципов и схем, направленных на создание оптимальных систем объектов. Процесс разработки сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом;
+* **FDD** - Features Driven Development: представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в установленные сроки;
+* **MDD** - Model Driven Development: разработка, управляемая моделями - это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты;
+* **PDD** - Panic Driven Development: это своеобразный антипаттерн разработки, который, к сожалению, мы все время от времени практикуем. По сути это то, что получается, когда процессы плохо налажены и команда импровизирует в условиях горящих сроков (новые задачи приоритетнее старых, код решает конкретные срочные задачи, но копится технический долг, тестирование в конце и т.д.);
+* **ADD** - API Driven Development: разработка на основе API - это практика сначала проектирования и создания API, а затем создания на их основе остальной части приложения;
+* **BDT - Behavior Driven Testing**: в\*\* \*\*тестировании на основе поведения ваши тесты основаны на user stories, которые описывают некоторые конкретные ожидаемые действия приложения. Вместо проверки деталей реализации вы фактически проверяете то, что важно больше всего: правильно ли приложение выполняет user stories. Еще одним преимуществом является понятность тестов для менеджеров, аналитиков и т.п.;
+* **MDT - Model Driven Testing**: Тестирование на основе моделей - это метод тестирования черного ящика, при котором поведение тестируемого программного обеспечения во время выполнения проверяется на основе прогнозов, сделанных моделями. Модель - это описание поведения системы. Поведение может быть описано в виде наглядной схемы, Data Flow, Control Flow, Dependency Graphs, Decision Tables, State transition machines или mind map. Простой аналогией модели в тестировании является электрическая схема при разработке электроприбора. Этот подход к тестированию требуется, когда высока цена ошибки в большом продукте и нужно как можно раньше попытаться ее предотвратить;
+* **DDT - Data Driven Testing** (table-driven testing or parameterized testing): в тестировании на основе данных тестовые данные хранятся в виде таблицы. Оно позволяет одним скриптом выполнять тесты для всех тестовых данных из таблицы и ожидать результатов теста в той же таблице;
+* **VDT** - Value Driven Testing: тестирование на основе ценности - это подход, в основе которого лежит анализ ценности и экономической целесообразности тестирования.
+
+Источники:
+
+* [TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development](https://habr.com/ru/post/459620/)
+* [The Basics of API-Driven Development](https://dzone.com/articles/abcs-of-api-driven-development)
+* [Behavior-Driven Testing для iOS используя Quick и Nimble](https://habr.com/ru/post/352694/)
+* [Тестирование на основе моделей](https://habr.com/ru/company/jugru/blog/506048/)
+* [What is Data Driven Testing? Learn to create Framework](https://www.guru99.com/data-driven-testing.html)
+* [Что нужно знать о Value Driven Testing. Анализируем ценность и экономическую целесообразность тестирования](https://dou.ua/lenta/columns/value-driven-testing/)
+* [Mockup-Driven Development. Находка или ловушка?](https://www.youtube.com/watch?v=olAOOVe4f0A)
+
+Доп. материал:
+
+* [Leadership in test: modelling and coverage](https://theqalead.com/topics/test-modelling-and-coverage/)
+* [Test Driven Development: By Example](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530)
+* [НЕ ООП ЕДИНЫ! Domain Driven Design на примере ХОЛОДИЛЬНИКА / Tech Lead Борис Беньковский](https://www.youtube.com/watch?v=rkQ3-T82pkU)
+
diff --git a/sdlc-i-stlc/scrum.md b/sdlc-i-stlc/scrum.md
new file mode 100644
index 0000000..3839c03
--- /dev/null
+++ b/sdlc-i-stlc/scrum.md
@@ -0,0 +1,82 @@
+# Scrum
+
+**Scrum** - наиболее популярный Agile-фреймворк, для многих людей эти термины являются синонимами. Scrum - это фреймворк процесса, используемый для управления разработкой продукта и другой работой, связанной с знаниями. Скрам является эмпирическим в том смысле, что дает командам возможность установить гипотезу о том, как они думают, что что-то работает, опробовать это, проанализировать полученный опыт и внести соответствующие коррективы. То есть при правильном использовании фреймворка. Скрам структурирован таким образом, чтобы команды могли использовать практики из других фреймворков, которые имеют смысл для контекста команды.
+
+Scrum лучше всего подходит в случае, когда кросс-функциональная команда работает в среде разработки продукта, где есть нетривиальный объем работы, которую можно разделить на более чем одну 2-4-недельную итерацию.
+
+**Ценности**:
+
+* Преданность (Commitment): Члены команды лично привержены достижению целей команды;
+* Смелость (Courage): Члены команды поступают правильно и работают над сложными проблемами;
+* Сфокусированность (Focus): Сконцентрируйтесь на работе, намеченной для спринта, и целях команды;
+* Открытость (Openness): Члены команды и заинтересованные стороны открыто рассказывают обо всей работе и проблемах, с которыми сталкивается команда;
+* Уважение (Respect): Члены команды уважают друг друга за способности и независимость.
+
+**Принципы**:
+
+* Прозрачность (Transparency): Команда должна работать в среде, где каждый знает, с какими проблемами сталкиваются другие члены команды. Команды выявляют проблемы внутри организации, часто возникающие в течение длительного времени, которые мешают успеху команды;
+* Инспекция (Inspection): Частые контрольные точки встроены в структуру, чтобы дать команде возможность поразмышлять о том, как работает процесс. Эти контрольные точки включают в себя Daily Scrum meeting и the Sprint Review Meeting;
+* Адаптация (Adaptation): Команда постоянно изучает, как идут дела, и проверяет те пункты, которые кажутся бессмысленными.
+
+**События**:
+
+* **Спринт** (Sprint): это временной интервал в 2-4 недели, в течение которого команда создает потенциально готовый к поставке инкремент продукта;
+* **Планирование спринта** (Sprint Planning): Команда начинает спринт с обсуждения, чтобы определить, над какими элементами из бэклога продукта (product backlog) они будут работать во время спринта. Конечным результатом планирования спринта является бэклог спринта (Sprint Backlog). Планирование спринта обычно состоит из двух частей. В первой части владелец продукта и остальная часть команды согласовывают, какие элементы бэклога продукта будут включены в спринт. Во второй части планирования спринта команда определяет, как они будут успешно доставлять идентифицированные элементы Product Backlog как часть потенциально возможного инкремента продукта. Команда может определить конкретные задачи, необходимые для этого, если это одна из их практик. Элементы Product Backlog, определенные для доставки, и задачи, если применимо, составляют бэклог спринта. После того, как команда и владелец продукта установят объем спринта, как описано в элементах Product Backlog, никакие дополнительные элементы не могут быть добавлены в журнал Sprint Backlog. Это защищает команду от изменений в рамках этого спринта;
+* **Ежедневная встреча** (Daily Scrum/Meeting): это короткое (обычно не более 15 минут) обсуждение, во время которого команда координирует свои действия на следующий день. Дейли не предназначен для обсуждения статуса или обсуждения проблем;
+* **Обзор спринта** (Sprint Review): в конце спринта вся команда (включая владельца продукта) рассматривает результаты спринта с заинтересованными сторонами продукта. Цель этого обсуждения - обсудить, продемонстрировать и потенциально дать заинтересованным сторонам возможность использовать инкремент для получения обратной связи. Обзор спринта не предназначен для предоставления отчета о состоянии (status report). Отзывы об обзоре спринта помещаются в Product Backlog для дальнейшего рассмотрения;
+* **Ретроспектива спринта** (Sprint Retrospective): в конце спринта после обзора спринта (sprint review) команда (включая владельца продукта) должна подумать о том, как дела шли во время предыдущего спринта, и определить корректировки, которые они могут внести в будущем. Результатом этой ретроспективы является как минимум одно действие, включенное в бэклог следующего спринта;
+* **Упорядочение бэклога** ([Grooming](https://medium.com/pepegramming/pepegramming-%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9-%D0%B3%D1%80%D1%83%D0%BC%D0%B8%D0%BD%D0%B3-9385b0786a3d));
+
+**Артефакты**:
+
+* **Бэклог продукта** (Product Backlog): это упорядоченный список всех возможных изменений, которые могут быть внесены в продукт. Пункты в бэклоге продукта являются вариантами, а не обязательствами, и то, что они существуют в бэклоге продукта, не гарантирует, что они будут доставлены. Владелец продукта постоянно ведет бэклог продукта, включая его содержание, доступность и порядок;
+* **Бэклог спринта** (Sprint Backlog): это набор элементов из бэклога продукта, выбранных для доставки в спринте. После того, как команда определяет задачи, эти задачи необходимо выполнить для достижения цели спринта (Sprint Goal);
+* **Инкремент** (Increment): это набор элементов из бэклога продукта, которые соответствуют Definition of Done к концу спринта. Владелец продукта может решить выпустить дополнение или развить его в будущих Спринтах;
+* **Критерии Готовности** ([Definition of Done](https://tryqa.com/what-is-definition-of-done-test-levels-in-agile-software/)): это общее соглашение команды о критериях, которым должен соответствовать элемент бэклога продукта, прежде чем он будет считаться выполненным$
+* **Пользовательские истории** ([User Story](https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D0%B5\_%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8));
+* **Цель спринта** ([Sprint Goal](https://scrumtrek.ru/blog/agile-scrum/scrum-glossary/3724/sprint-goal/));
+* **Диаграмма сгорания задач** ([Burndown chart](https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0\_%D1%81%D0%B3%D0%BE%D1%80%D0%B0%D0%BD%D0%B8%D1%8F\_%D0%B7%D0%B0%D0%B4%D0%B0%D1%87)).
+
+**Роли**:
+
+* **Владелец продукта** (Product Owner): роль, ответственная перед командой за управлением бэклогом продукта для достижения результатов, к которым стремится команда. Роль product owner-а существует в Scrum для решения проблем, когда команда разработки имеет множественные противоречивые направления движения или отсутствие направления вообще в отношении того, что создавать;
+* **Скрам Мастер** (Scrum Master): роль, ответственная перед командой за то, чтобы команда придерживалась гибких ценностей и принципов и следовала процессам и практикам, которые команда согласилась использовать. Изначально это имя предназначалось для обозначения кого-то, кто является экспертом в Scrum и, следовательно, может обучать других. Роль обычно не имеет никаких фактических полномочий. Люди, выполняющие эту роль, должны руководить с позиции влияния, часто занимая позицию лидера-слуги ([servant-leadership](https://en.wikipedia.org/wiki/Servant\_leadership));
+* **Команда разработки** (Development Team): состоит из людей, которые создают инкремент продукта внутри спринта. Основная ответственность команды разработки - обеспечить инкремент, который приносит пользу каждому спринту. Как распределить работу, это остается на усмотрение команды в зависимости от условий на тот момент.
+
+**Жизненный цикл Scrum**:
+
+* Создайте бэклог продукта;
+* Владелец продукта и команда разработчиков проводят планирование спринта. Определите объем спринта в первой части планирования спринта и план реализации этого объема во второй половине планирования спринта;
+* По мере продвижения спринта команда разработчиков выполняет работу, необходимую для доставки выбранных элементов бэклога продукта;
+* Команда разработчиков ежедневно координирует свою работу в рамках Daily Scrum;
+* В конце спринта группа разработчиков предоставляет элементы бэклога продукта, выбранные во время планирования спринта. Команда разработчиков проводит обзор спринта, чтобы показать клиенту инкремент и получить обратную связь. Команда разработчиков и владелец продукта также размышляют о том, как прошел Sprint до сих пор, и соответствующим образом адаптируют свои процессы во время ретроспективы;
+* Команда повторяет шаги 2-5 до тех пор, пока не будет достигнут желаемый результат.
+
+**Стори поинты** (Story points)
+
+Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты ([1](https://scrumtrek.ru/blog/agile-scrum/scrum-glossary/3788/story-points/), [2](https://insurfing.ru/2020/04/25/story-points/)). Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.
+
+Источники:
+
+* [What is Scrum?](https://www.agilealliance.org/glossary/scrum/#q=\~\(infinite\~false\~filters\~\(postType\~\(\~'page\~'post\~'aa\_book\~'aa\_event\_session\~'aa\_experience\_report\~'aa\_glossary\~'aa\_research\_paper\~'aa\_video\)\~tags\~\(\~'scrum\)\)\~searchTerm\~'\~sort\~false\~sortDirection\~'asc\~page\~1\))
+
+Доп. материал:
+
+* [Scrum Guide](https://scrumguides.org/scrum-guide.html)
+* [Scrum Glossary](https://www.scrum.org/resources/scrum-glossary)
+* [Мини-справочник и руководство по Scrum](https://habr.com/ru/post/464861/)
+* [Scrum-мем на злобу дня](https://habr.com/ru/post/526822/)
+* [Когда Scrum не работает. Пять основных проблем его применения](https://dou.ua/lenta/columns/main-scrum-problems/)
+* [Лекция 7: Этапы и мероприятия Scrum](https://intuit.ru/studies/courses/3590/832/lecture/31182?page=1)
+* [Как провести ретроспективу](https://webmisha.medium.com/%D0%BA%D0%B0%D0%BA-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%81%D1%82%D0%B8-%D1%80%D0%B5%D1%82%D1%80%D0%BE%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D1%83-93124778247)
+* [Покер планирования - как сделать процесс постановки задач максимально прозрачным и четким](https://habr.com/ru/company/retailrocket/blog/334256/)
+* [Cheat-sheet](https://pin.it/7BBtXxG), [еще одна](https://www.pinterest.ru/pin/641059328205796599/)
+
+**Особенности тестирования в Scrum**:
+
+* [Тестирование в рамках SCRUM. Тернии, грабли и успехи](https://habr.com/ru/company/livetyping/blog/307860/)
+* [Регрессионное тестирование на Scrum-проектах: руководство по проведению](https://habr.com/ru/post/563918/)
+* [QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде](https://habr.com/ru/company/miro/blog/505282/)
+* [Тесты должна писать разработка (?)](https://habr.com/ru/company/yandex\_praktikum/blog/543262/)
+* [The Role of QA in Sprint Planning](https://www.mindfulqa.com/qa-sprint-planning/)
+* [Код-ревью для тестировщиков](https://www.software-testing.ru/library/testing/general-testing/2796-code-reviews-for-testers)
diff --git a/sdlc-i-stlc/zhiznennyi-cikl-razrabotki-po-sdlc-software-development-lifecycle.md b/sdlc-i-stlc/zhiznennyi-cikl-razrabotki-po-sdlc-software-development-lifecycle.md
new file mode 100644
index 0000000..7f6e356
--- /dev/null
+++ b/sdlc-i-stlc/zhiznennyi-cikl-razrabotki-po-sdlc-software-development-lifecycle.md
@@ -0,0 +1,49 @@
+# Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
+
+_Жизненный цикл программного обеспечения (software lifecycle): Период времени, начинающийся с момента появления концепции программного обеспечения и заканчивающийся тогда, когда дальнейшее использование программного обеспечения невозможно. Жизненный цикл программного обеспечения обычно включает в себя следующие этапы: концепт, описание требований, дизайн, реализация, тестирование, инсталляция и наладка, эксплуатация и поддержка и, иногда, этап вывода из эксплуатации. Данные фазы могут накладываться друг на друга или проводиться итерационно. (ISTQB)_
+
+_Период времени от концепции до первоначальной версии известен как жизненный цикл разработки, который является частью жизненного цикла программного обеспечения. С момента первого запуска система переходит в эксплуатацию (функционирование). Система остается в эксплуатации до момента прекращения использования. (ГОСТ 56920)_
+
+**SDLC** - это систематизированный процесс, этапы которого охватывают полный жизненный цикл программного обеспечения (Software Lifecycle) и который определяет различные этапы разработки программного обеспечения для создания высококачественного программного обеспечения, отвечающего ожиданиям клиентов и для улучшения эффективности разработки. Разработка системы должна быть завершена в заранее определенные сроки и стоимость. Каждая фаза жизненного цикла SDLC имеет свой собственный процесс и результаты, которые используются в следующей фазе.
+
+Обычно он делится на шесть-восемь шагов, но менеджеры проектов могут объединять, декомпозировать или пропускать шаги, в зависимости от скоупа проекта.
+
+В разных источниках фазы немного отличаются, но глобально суть везде одинакова.
+
+
+
+**Фазы SDLC**:
+
+* **Сбор и анализ требований** (Requirement Gathering and Analysis): На этом этапе от клиента собирается вся необходимая информация для разработки продукта в соответствии с их ожиданиями. Любые неясности должны быть разрешены сразу на этом этапе. Бизнес-аналитик и менеджер проекта назначили встречу с заказчиком, чтобы собрать всю информацию, например, что заказчик хочет построить, кто будет конечным пользователем, какова цель продукта. Перед созданием продукта очень важно понимание или знание продукта. Например, клиент хочет иметь приложение, которое включает денежные транзакции. В этом случае требование должно быть четким, например, какие транзакции будут выполняться, как они будут проводиться, в какой валюте они будут проводиться и т. д. После того, как сбор требований завершен, проводится анализ для проверки возможности разработки продукта. После четкого понимания требования создается документ SRS (Спецификация требований к программному обеспечению). Этот документ должен быть полностью понят разработчикам, а также должен быть рассмотрен заказчиком для использования в будущем;
+* **Дизайн** (Design): На этом этапе требования, собранные в документе SRS, используются в качестве входных данных, и создается архитектура программного обеспечения, которая используется для реализации разработки системы. Создаются два вида дизайн-документов:
+ * Высокоуровневый дизайн (HLD - High-Level Design):
+ * Краткое описание и название каждого модуля;
+ * Краткое описание функциональности каждого модуля;
+ * Отношения интерфейсов и зависимости между модулями;
+ * Таблицы базы данных, идентифицированные вместе с их ключевыми элементами;
+ * Полные архитектурные схемы с подробными сведениями о технологиях.
+ * Низкоуровневый дизайн (LLD - Low-Level Design):
+ * Функциональная логика модулей;
+ * Таблицы базы данных, которые включают тип и размер;
+ * Полная детализация интерфейсов;
+ * Решение всех типов проблем с зависимостями;
+ * Список сообщений об ошибках;
+ * Полные входные и выходные значения для каждого модуля.
+* **Разработка** (Implementation or Coding): Реализация / кодирование начинается, как только разработчик получает Design document. Дизайн программного обеспечения переведен в исходный код. На этом этапе реализуются все компоненты программного обеспечения;
+* **Тестирование** (Testing): Тестирование начинается после завершения кодирования и выпуска модулей для тестирования. На этом этапе разработанное программное обеспечение тщательно тестируется, и все обнаруженные дефекты передаются разработчикам для их исправления. Повторное тестирование, регрессионное тестирование проводится до тех пор, пока программное обеспечение не будет соответствовать ожиданиям клиента. Тестировщики обращаются к документу SRS, чтобы убедиться, что программное обеспечение соответствует стандарту заказчика;
+* **Развертывание** (Deployment): После тестирования продукта он развертывается в производственной среде или выполняется первое UAT (пользовательское приемочное тестирование), в зависимости от ожиданий клиента. В случае UAT создается копия производственной среды, и заказчик вместе с разработчиками выполняет тестирование. Если клиент остается доволен, то предоставляет согласие на [релиз](https://hackernoon.com/feel-the-release);
+* **Поддержка** (Maintenance): Основное внимание на этом этапе SDLC уделяется обеспечению того, чтобы потребности продолжали удовлетворяться и чтобы система продолжала работать в соответствии со спецификацией, упомянутой в первом этапе. После того, как система развернута и клиенты начинают использовать разработанную систему следует 3 вида активностей:
+ * Исправление ошибок;
+ * Обновление;
+ * Улучшение.
+
+Источники:
+
+* [SDLC: Phases & Models of Software Development Life Cycle](https://www.guru99.com/software-development-life-cycle-tutorial.html)
+* [SDLC (Software Development Life Cycle) Phases, Process, Models](https://www.softwaretestinghelp.com/software-development-life-cycle-sdlc/)
+
+Доп. материал:
+
+* [IEEE Guide to the Software Engineering Body of Knowledge](https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf). Chapters 7-8.
+* [ГОСТ Р ИСО/МЭК 12207-2010 “Процессы жизненного цикла программных средств”](https://docs.cntd.ru/document/1200082859)
+* [Workflow проекта. Agile, Scrum, Kanban. Рабочий процесс в JIRA (реальный проект)](https://www.youtube.com/watch?v=mfMr52CE5wE)
diff --git a/sdlc-i-stlc/zhiznennyi-cikl-testirovaniya-po-stlc-software-testing-lifecycle.md b/sdlc-i-stlc/zhiznennyi-cikl-testirovaniya-po-stlc-software-testing-lifecycle.md
new file mode 100644
index 0000000..f7ae3b7
--- /dev/null
+++ b/sdlc-i-stlc/zhiznennyi-cikl-testirovaniya-po-stlc-software-testing-lifecycle.md
@@ -0,0 +1,70 @@
+# Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
+
+**STLC** - это процесс тестирования, который включает в себя определенную последовательность шагов, чтобы гарантировать достижение целей в области качества. В процессе STLC каждое действие выполняется планомерно и систематически. Каждый этап имеет разные цели и результаты. У разных организаций разные этапы STLC, однако основа остается прежней.
+
+**Каждая фаза STLC имеет критерии начала и окончания**:
+
+* _**Критерии входа (entry criteria): Набор общих и специфичных условий для продолжения процесса с определенной задачей, например, фаза тестирования. Цель критериев входа - предотвращение начала задачи, которое может потребовать больше (бесполезных) усилий, чем на устранение не пройденных критериев входа. (Gilb and Graham)**_
+* _**Критерии выхода (exit criteria): Набор общих и специфичных условий, согласованных заранее с заинтересованными сторонами, для того, чтобы процесс мог официально считаться завершенным. Цель критериев выхода - предотвращение возможности, когда задание считается завершенным, однако еще существуют отдельные незавершенные части задания. Критерии выхода используются для отчетности, а также планирования того, когда остановить тестирование. (Gilb and Graham)**_
+
+**Фазы STLC**
+
+
+
+STLC имеет несколько взаимосвязанных фаз и в целом очень похож на SDLC. Эти фазы являются последовательными и называются:
+
+* **Анализ требований** (Requirement Analysis): один из важнейших этапов, потому что именно на нем можно почти бесплатно исправить недостатки проекта. Этап анализа требований также определяет потенциальную потребность в автоматизированном тестировании и позволяет производить экономические расчеты затрат на рабочую силу на основе оценки проекта. На этом же этапе обсуждаются и документируются критерии начала и окончания тестирования.
+ * Entry Criteria: BRS (Business Requirement Specification)
+ * Deliverables: список всех проверяемых требований, технико-экономическое обоснование автоматизации (если применимо);
+* **Планирование тестирования** (Test Planning): на этом этапе формируется план тестирования, т.е. мы определяем действия и ресурсы, которые помогут достичь целей тестирования (участники и их роли, инструменты, окружение). Во время планирования мы также пытаемся определить метрики, метод сбора и отслеживания этих метрик. План составляют исходя из требований, тестовой стратегии и анализа рисков.
+ * Entry Criteria: Requirements Documents;
+ * Deliverables: Test Strategy, Test Plan, and Test Effort estimation document.
+* **Разработка тест-кейсов** (Test Case Development): подразумевает использование ручного и автоматизированного тестирования для достижения полного охвата функциональности программного обеспечения, при этом процесс основан на заранее установленных требованиях. Чаще всего тест-кейсы для автоматического тестирования пишутся отдельно, так как кейсы для ручного тестирования описаны в виде шпаргалок (cheat sheets).
+ * Entry Criteria: Requirements Documents (Updated version);
+ * Deliverables: Test cases, Test Scripts (if automation), Test data.
+* **Настройка тестовой среды** (Test Environment Setup): в плане тестирования четко указано, какую тестовую среду следует использовать. На этом этапе STLC настраиваются операционные системы и виртуальные машины, развертываются инструменты тестирования, такие как Selenium, Katalon Studio, а также тестовая среда и базы данных проекта. Мы также обращаемся с запросами к DevOps и администраторам, если требуется поддержка.
+ * Entry Criteria: Test Plan, Smoke Test cases, Test Data;
+ * Deliverables: Test Environment. Smoke Test Results.
+* **Выполнение тестов** (Test Execution): тесты выполняются на основе готовой тестовой документации и правильно настроенной тестовой среды. Все результаты тестирования регистрируются в Системе управления тестированием. Отрицательно пройденные тесты, в которых фактический результат отличается от ожидаемого, регистрируются как ошибки и передаются команде разработчиков на доработку с последующей перепроверкой после исправления.
+ * Entry Criteria: Test Plan document, Test cases, Test data, Test Environment;
+ * Deliverables: Test case execution report, Defect report, RTM.
+* **Завершение цикла испытаний** (Test Cycle Closure): окончательная генерация отчетов о тестировании для клиента. Они должны включать затраченное время, процент обнаруженных ошибок и положительных результатов тестирования, общее количество обнаруженных и исправленных ошибок. Что касается отдела тестирования, то это момент для анализа его работы, подведения итогов, анализа его продуктивности и возможности внести предложения по улучшению качества тестирования.
+ * Entry Criteria: Test Case Execution report (убедитесь, что нет открытых high severity defects), Defect report;
+ * Deliverables: Test Closure report, Test metrics.
+
+**Разница STLC и SDLC**
+
+STLC и SDLC тесно связаны друг с другом, но они одновременно преследуют разные задачи с одной и той же целью, а именно:
+
+* сбор требований в желаемой форме и разработка заявленной функциональности (SDLC);
+* анализ требований, помощь клиенту и команде разработчиков и подтверждение качества реализованной функциональности (STLC).
+
+Общая цель - удовлетворение клиента и получение максимально возможного балла на этапах верификации и валидации.
+
+**Почему тестирование разбито на отдельные этапы?**
+
+Ответ из ISTQB Foundation Level Exam: У каждого этапа своя цель.
+
+В большинстве случаев тестирование разбивается на несколько этапов в зависимости от развития самого кода и стремления к эффективному использованию ресурсов. Давайте рассмотрим пример приложения, которое включает в себя как службы REST, так и веб-интерфейс, в agile команде, которая предоставляет набор user stories, которые в конечном итоге будут развернуты как производственный выпуск.
+
+Если команда следует Acceptance Test Driven Development (ATDD), то члены команды будут совместно работать над дизайном тестов историй. Это происходит до начала разработки (одна из характеристик ATDD). Допустим, Мэри - разработчик, который напишет код для служб REST, и допустим, что она практикует разработку через тестирование (TDD). Она строит модульные тесты, по одному, сначала позволяя тесту не пройти, а затем пишет достаточно кода для прохождения теста. Когда имеется достаточное количество тестов для удовлетворения всех требований к истории и эти тесты проходят, тогда разработка и модульное тестирование завершаются. Затем Мэри может написать автоматизированные тесты, которые включают базу данных и, возможно, другие зависимости вне ее кода. Это интеграционные тесты. Поскольку команда использует ATDD, у нее уже есть набор приемочных тестов, поэтому она основывает свои автоматизированные тесты на них. Когда код Мэри проверяется и объединяется в общую ветвь разработки, в процессе сборки выполняются автоматические регрессионные тесты, чтобы убедиться, что существующие функциональные возможности не были нарушены работой Мэри. Эти тесты часто представляют собой просто набор автоматических приемочных испытаний, проводимых в течение месяцев или лет.
+
+Если Сэм является разработчиком пользовательского интерфейса, возможно, он также пишет модульные тесты для некоторых частей своего кода. Когда его работа будет завершена, он может также написать автоматизированные интеграционные тесты, хотя в его тестах могут отсутствовать некоторые сценарии данных, поскольку они охватываются тестами Мэри, и он больше сосредоточится на использовании самого пользовательского интерфейса. Это все еще автоматизированные приемочные тесты, но цель состоит в том, чтобы избежать излишней избыточности существующих тестовых примеров. Как и в случае с кодом Мэри, когда код Сэма проверяется и объединяется в общую ветвь, автоматически выполняется набор регрессии пользовательского интерфейса.
+
+После того, как Сэм и Мэри закончат, Джо, QA-инженер, может провести некоторое ручное приемочное тестирование всей истории, а также некоторое исследовательское тестирование, чтобы убедиться, что сумасшедшее поведение пользователя не приводит к сумасшедшему поведению приложения. Эта комбинация автоматических и ручных тестов составляет приемочное тестирование истории. По завершении ряда историй набор изменений внедряется в интегрированную тестовую среду для окончательного тестирования. Это может представлять собой приемочное тестирование более высокого уровня, а также дополнительное регрессионное тестирование. Дополнительное приемочное тестирование может выполняться инженерами по обеспечению качества, которые следят за тем, чтобы набор историй обеспечивал согласованный рабочий процесс для пользователей и, в конечном итоге, ценность некоторых требований более высокого уровня, которые ранее были разбиты на истории.
+
+Заключительное регрессионное тестирование проводится поверх ранее запущенного пакета автоматизированной регрессии. Возможно, это приложение имеет некоторые функции, которые просто требуют человеческого вмешательства, или, возможно, это окончательная оценка другой группы тестировщиков, которые следят за соблюдением стиля и стандартов поведения.
+
+Как видно из этого рабочего процесса, многие из этих шагов было бы неэффективно выполнить раньше, чем когда они описаны выше. Автоматические тесты являются исключением, так как они могут и часто выполняются многократно на протяжении всего процесса. Однако большинство других «этапов» тестирования - это просто естественное развитие, основанное на развитии выпуска.
+
+Источники:
+
+* [What is Software Testing Life Cycle (STLC)](https://bambooagile.eu/insights/what-is-stlc/)
+* [What Is Software Testing Life Cycle (STLC)?](https://www.softwaretestinghelp.com/what-is-software-testing-life-cycle-stlc/)
+* [What is Software Testing Life Cycle (STLC) & STLC Phases](https://www.softwaretestingmaterial.com/stlc-software-testing-life-cycle/)
+* [Why is testing split into distinct stages?](https://www.quora.com/Why-is-testing-split-into-distinct-stages)
+
+Доп. материал:
+
+* [A Quick Guide to Software Testing Life Cycle](https://hackernoon.com/a-quick-guide-to-software-testing-life-cycle)
+* [Как встроить качество в процессы производства ПО? (Часть 2)](https://habr.com/ru/post/591993/)
diff --git a/seti-i-okolo-nikh/README.md b/seti-i-okolo-nikh/README.md
new file mode 100644
index 0000000..bf5f0ab
--- /dev/null
+++ b/seti-i-okolo-nikh/README.md
@@ -0,0 +1,2 @@
+# Сети и около них
+
diff --git a/seti-i-okolo-nikh/autentifikaciya-i-avtorizaciya-authentication-and-authorization.md b/seti-i-okolo-nikh/autentifikaciya-i-avtorizaciya-authentication-and-authorization.md
new file mode 100644
index 0000000..aab5303
--- /dev/null
+++ b/seti-i-okolo-nikh/autentifikaciya-i-avtorizaciya-authentication-and-authorization.md
@@ -0,0 +1,167 @@
+# Аутентификация и авторизация (Authentication and authorization)
+
+**Идентификация** - процедура, в результате выполнения которой для субъекта идентификации выявляется его идентификатор, однозначно определяющий этого субъекта в информационной системе.
+
+**Аутентификация** - процедура проверки подлинности, например проверка подлинности пользователя путем сравнения введенного им пароля с паролем, сохраненным в базе данных.
+
+**Авторизация** - предоставление определенному лицу или группе лиц прав на выполнение определенных действий.
+
+_В англоязычных источниках идентификация не выделяется в отдельный пункт: “Authentication is the process of **identifying** users and **validating** who they claim to be”._
+
+Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
+
+* Для начала система запрашивает логин, пользователь его указывает, система распознает его как существующий - это идентификация.
+* После этого Google просит ввести пароль, пользователь его вводит, и система соглашается, что пользователь, похоже, действительно настоящий, раз пароль совпал, - это аутентификация.
+* Скорее всего, Google дополнительно спросит еще и одноразовый код из SMS или приложения. Если пользователь и его правильно введет, то система окончательно согласится с тем, что он настоящий владелец аккаунта, - это двухфакторная аутентификация.
+* После этого система предоставит пользователю право читать письма в его почтовом ящике и все в таком духе - это авторизация.
+
+Аутентификация без предварительной идентификации лишена смысла - пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
+
+Идентификация без аутентификации - это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.
+
+А вот авторизация без идентификации и тем более аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны вообще кому угодно. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный енот. Несмотря на то, что енот совершенно неопознанный, система его все же авторизовала - то есть выдала право прочитать этот документ.
+
+А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа - авторизоваться.
+
+**Фреймворк HTTP-аутентификации** (HTTP authentication framework)
+
+[RFC 7235](https://datatracker.ietf.org/doc/html/rfc7235) определяет HTTP authentication framework, который может использоваться сервером для вызова клиентского запроса (to [challenge](https://developer.mozilla.org/en-US/docs/Glossary/challenge) a client request) и клиентом для предоставления информации для проверки подлинности. Порядок вызовов и ответов:
+
+* Сервер отвечает клиенту со статусом ответа 401 (Unauthorized) и предоставляет информацию о том, как авторизоваться, с WWW-Authenticate response header, содержащим как минимум один вызов.
+* Клиент, который хочет аутентифицировать себя на сервере, может сделать это, включив Authorization request header с учетными данными (credentials).
+* Обычно клиент представляет пользователю запрос пароля, а затем отправляет запрос, включая правильный Authorization header.
+
+
+
+**Популярные методы аутентификации**
+
+* Проверка подлинности на основе пароля (**Password-based authentication**) - это простой метод проверки подлинности, требующий ввода пароля для подтверждения личности пользователя.
+* Беспарольная аутентификация (**Passwordless authentication**) - это когда пользователь проверяется с помощью одноразового ПИН-а (OTP - One-time pins) или magic link, доставленной на зарегистрированный адрес электронной почты или номер телефона;
+* Для двухфакторной аутентификации/многофакторной аутентификации (**2FA/MFA**) требуется более одного уровня безопасности, например дополнительный PIN-код или контрольный вопрос, для идентификации пользователя и предоставления доступа к системе;
+* Единый вход (**SSO**) позволяет пользователям получать доступ к нескольким приложениям с одним набором учетных данных;
+* Социальная аутентификация (**Social authentication**) проверяет и аутентифицирует пользователей с существующими учетными данными на платформах социальных сетей.
+* Биометрия ([**Biometrics**](https://hackernoon.com/biometric-authentication-working-methods-and-use-cases-3z2a377p)) - пользователь предъявляет отпечаток пальца или скан глаза, чтобы получить доступ к системе.
+
+**Популярные методы авторизации**
+
+* Управление доступом на основе ролей (**RBAC - Role-based access controls**) может быть реализовано для управления привилегиями от системы к системе и от пользователя к системе.
+* Веб-токен JSON ([**JWT - JSON web token**](https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc)) - это открытый стандарт для безопасной передачи данных между сторонами, а пользователи авторизуются с помощью пары открытый/закрытый ключ.
+* **SAML** - это стандартный формат единого входа (SSO), в котором аутентификационная информация передается через XML-документы с цифровой подписью.
+* Авторизация [**OpenID**](https://habr.com/ru/company/nixys/blog/566910/) проверяет личность пользователя на основе аутентификации сервера авторизации;
+* [**OAuth**](https://betterprogramming.pub/the-complete-guide-to-oauth-2-0-and-openid-connect-protocols-35ebc1cbc11a) позволяет API аутентифицировать и получать доступ к запрошенной системе или ресурсу.
+
+**Аутентификация на основе сессий**
+
+Протокол HTTP не отслеживает состояния, и, если мы аутентифицируем пользователя с помощью имени и пароля, наше приложение не будет знать, тот ли это человек, что и в предыдущем запросе. Нам придётся аутентифицировать снова. При каждом запросе HTTP не знает ничего о том, что происходило до этого, он лишь передаёт запрос. Так что, если вам нужны личные данные, придётся снова логиниться, чтобы приложение знало, что это точно вы. Может сильно раздражать.
+
+Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространенный и широко известный метод, используемый уже давно.
+
+Процедура аутентификации на основе сессий:
+
+* Пользователь вводит в браузере своё имя и пароль, после чего клиентское приложение отправляет на сервер запрос.
+* Сервер проверяет пользователя, аутентифицирует его, шлёт приложению уникальный пользовательский токен (сохранив его в памяти или базе данных).
+* Клиентское приложение сохраняет токены в куках и отправляет их при каждом последующем запросе.
+* Сервер получает каждый запрос, требующий аутентификации, с помощью токена аутентифицирует пользователя и возвращает запрошенные данные клиентскому приложению.
+* Когда пользователь выходит, клиентское приложение удаляет его токен, поэтому все последующие запросы от этого клиента становятся неаутентифицированными.
+
+
+
+У этого метода несколько недостатков:
+
+* При каждой аутентификации пользователя сервер должен создавать у себя запись. Обычно она хранится в памяти, и при большом количестве пользователей есть вероятность слишком высокой нагрузки на сервер.
+* Поскольку сессии хранятся в памяти, масштабировать не так просто. Если вы многократно реплицируете сервер, то на все новые серверы придётся реплицировать и все пользовательские сессии. Это усложняет масштабирование. (Я считал, этого можно избежать, если иметь выделенный сервер для управления сессиями, но это сложно реализовать, да и не всегда возможно.)
+
+**Аутентификация на основе токенов**
+
+Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.
+
+При аутентификации на основе токенов состояния не отслеживаются. Мы не будем хранить информацию о пользователе на сервере или в сессии и даже не будем хранить JWT, использованные для клиентов.
+
+Процедура аутентификации на основе токенов:
+
+* Пользователь вводит имя и пароль.
+* Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user\_id, разрешений и т. д.
+* Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
+* Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer {JWT}. Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
+* Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
+* Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.
+
+
+
+У метода есть ряд преимуществ:
+
+* Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
+* В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
+* При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
+* Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение - для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение - для получения данных.
+* А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
+* У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.
+
+Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.
+
+**Беспарольная аутентификация**
+
+Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?». В наши головы внедрено убеждение, что пароли - абсолютный источник защиты наших аккаунтов. Но если изучить вопрос глубже, то выяснится, что беспарольная аутентификация может быть не просто безопасной, но и безопаснее традиционного входа по имени и паролю. Возможно, вы даже слышали мнение, что пароли устарели.
+
+Беспарольная аутентификация - это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая: вместо ввода почты/имени и пароля пользователи вводят только свою почту. Ваше приложение отправляет на этот адрес одноразовую ссылку, пользователь по ней кликает и автоматически входит на ваш сайт / в приложение. При беспарольной аутентификации приложение считает, что в ваш ящик пришло письмо со ссылкой, если вы написали свой, а не чужой адрес.
+
+Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Код или одноразовый пароль тоже можно отправлять по почте.
+
+И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев.
+
+Что может пойти не так: если кто-то получит доступ к пользовательским почтам, он получит и доступ к приложениям и сайтам. Но это не ваша головная боль - беспокоиться о безопасности почтовых аккаунтов пользователей. Кроме того, если кто-то получит доступ к чужой почте, то сможет перехватить аккаунты в приложениях с беспарольной аутентификацией, воспользовавшись функцией восстановления пароля. Но мы ничего не можем поделать с почтой наших пользователей. Пойдём дальше.
+
+В чём преимущества: как часто вы пользуетесь ссылкой «забыли пароль» для сброса чертового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.
+
+**Единая точка входа (Single Sign On, SSO)**
+
+Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автоматически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube - это сервисы Google, но всё же раздельные продукты. Как они аутентифицируют пользователя во всех продуктах после единственного входа? Этот метод называется единой точкой входа (Single Sign On, SSO).
+
+Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создает куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:
+
+* Пользователь входит в один из сервисов Google.
+* Пользователь получает сгенерированную в Google Accounts куку.
+* Пользователь идёт в другой продукт Google.
+* Пользователь снова перенаправляется в Google Accounts.
+* Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.
+
+Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю. Выглядит очень просто, но конкретные реализации бывают очень сложными. [Подробнее об этом методе аутентификации](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/).
+
+**Аутентификация в соцсетях (Social sign-in)** или социальный логин (Social Login)
+
+Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.
+
+Формально социальный логин - это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.
+
+Лучшее из двух миров: пользователи могут войти в ваше приложение одним кликом, если у них есть аккаунт в одной из соцсетей. Им не нужно помнить логины и пароли. Это сильно улучшает опыт использования вашего приложения. Вам не нужно волноваться о безопасности пользовательских данных и думать о проверке адресов почты - они уже проверены соцсетями. Кроме того, в соцсетях уже есть механизмы восстановления пароля.
+
+Как использовать: большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth2 (некоторые используют OAuth1, например Twitter). Разберёмся, что такое OAuth. Соцсеть - это сервер ресурсов, ваше приложение - клиент, а пытающийся войти в ваше приложение пользователь - владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).
+
+Для реализации такого механизма вам может понадобиться зарегистрировать свое приложение в разных соцсетях. Вам дадут app\_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.
+
+**Двухфакторная аутентификация (2FA)**
+
+Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счет использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность [многофакторной аутентификации](https://ru.wikipedia.org/wiki/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%BD%D0%B0%D1%8F\_%D0%B0%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F). Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдет вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! - Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.
+
+Другой знакомый пример - двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищенным, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.
+
+Вместо одноразового пароля в качестве второго фактора могут использоваться отпечатки пальцев или снимок сетчатки.
+
+При двухфакторной аутентификации пользователь должен предоставить **два из трёх**:
+
+* **То, что вы знаете**: пароль или PIN.
+* **То, что у вас есть**: физическое устройство (смартфон) или приложение, генерирующее одноразовые пароли.
+* **Часть вас**: биологически уникальное свойство вроде ваших отпечатков пальцев, голоса или снимка сетчатки.
+
+Большинство хакеров охотятся за паролями и PIN-кодами. Гораздо труднее получить доступ к генератору токенов или биологическим свойствам, поэтому сегодня двухфакторка обеспечивает высокую безопасность аккаунтов.
+
+То есть это универсальное решение? [Возможно](https://medium.com/@the\_economist/where-are-the-flaws-in-two-factor-authentication-5f7a468f41a9), [нет](https://www.theverge.com/2017/7/10/15946642/two-factor-authentication-online-security-mess).
+
+И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.
+
+Источники:
+
+* [Идентификация, аутентификация и авторизация - в чем разница?](https://www.kaspersky.ru/blog/identification-authentication-authorization-difference/29123/)
+* [HTTP authentication](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication)
+* [Authentication and Authorization Defined: What's the Difference?](https://www.loginradius.com/blog/start-with-identity/authentication-vs-authorization-infographic/)
+* [Как ты реализуешь аутентификацию, приятель?](https://habr.com/ru/company/vk/blog/343288/)
diff --git a/seti-i-okolo-nikh/baza-po-setyam.md b/seti-i-okolo-nikh/baza-po-setyam.md
new file mode 100644
index 0000000..b0a62e3
--- /dev/null
+++ b/seti-i-okolo-nikh/baza-po-setyam.md
@@ -0,0 +1,181 @@
+# База по сетям
+
+**Глобальные и Локальные сети**
+
+Вся интернет сеть подразделяется на глобальную (WAN) и локальную (LAN).
+
+Все пользовательские устройства в рамках одной квартиры или офиса или даже здания (компьютеры, смартфоны, принтеры/МФУ, телевизоры и т.д.) подключаются к роутеру, который объединяет их в локальную сеть.
+
+Участники одной локальной сети могут обмениваться данными между своими устройствами без подключения к интернет провайдеру. А вот чтобы выйти в сеть (например, выйти в поисковик Яндекс или Google, зайти в VK, Instagram, YouTube или AmoCRM) необходим доступ к глобальной сети.
+
+Выход в глобальную сеть обеспечивает интернет провайдер, за что мы и платим ему абонентскую плату. Провайдер устанавливает на своих роутерах уровень скорости для каждого подключения в соответствии с тарифом. Провайдер прокидывает нам витую пару или оптику до нашего роутера (нашей локальной сети) и после этого любое устройства нашей локальной сети может выходить в глобальную сеть.
+
+Для аналогии, сети, можно сравнить с дорогами. Например, дороги вашего города N это локальная сеть. Эти дороги соединяют вас с магазинами, учреждениями, парками и другими местами вашего города. Чтобы попасть в другой город N вам необходимо выехать на федеральную трассу и проехать некоторое количество километров. То есть выйти в глобальную сеть.
+
+Для более наглядного представления, что такое глобальная и локальная сеть я нарисовал схематичный рисунок:
+
+
+
+**Белые и серые IP-адреса**
+
+Каждое устройство в сети имеет свой уникальный IP-адрес. Он нужен для того, чтобы устройства сети понимали куда необходимо направить запрос и ответ.
+
+Это также как и наши дома и квартиры имеют свой точный адрес (индекс, город, улица, № дома, № квартиры). В рамках вашей локальной сети (квартиры, офиса или здания) есть свой диапазон уникальных адресов. Я думаю многие замечали, что ip-адрес компьютера, например, начинается с цифр 192.168.X.X. Так вот это локальный адрес вашего устройства.
+
+Существуют разрешенные диапазоны локальных сетей:
+
+| **от ip-адреса** | **до ip-адреса** | **кол-во возможных подключенных устройств** |
+| ------------------------------------ | ---------------------------------------- | ------------------------------------------- |
+| 10.0.0.0 | 10.255.255.255 | 16777216 |
+| 172.16.0.0 | 172.31.255.255 | 65536 |
+|
192.168.0.0
192.168.1.0
|
192.168.0.255
192.168.1.255
|
256
256
|
+
+Думаю из представленной таблицы сразу становится понятно почему самый распространенный диапазон это 192.168.X.X
+
+Чтобы узнать, например, ip-адрес своего компьютера (на базе ос windows), наберите в терминале команду ipconfig.
+
+Для выхода в глобальные сети, ваш локальный ip-адрес подменяется роутером на глобальный, который вам выдал провайдер. Глобальные ip-адреса не попадают под диапазоны из таблички выше. Так вот локальные ip-адреса - это серые ip-адреса, а глобальные - это белые.
+
+Для большего понимания рассмотрите схему ниже. На ней я подписал каждое устройство своим ip-адресом.
+
+
+
+На схеме видно, что провайдер выпускает нас в глобальные сети (в интернет) с белого ip-адреса 91.132.25.108
+
+Для нашего роутера провайдер выдал серый ip-адрес 172.17.135.11
+
+И в нашей локальной сети все устройства соответственно тоже имеют серые ip-адреса 192.168.Х.Х
+
+Узнать под каким ip-адресом вы выходите в глобальную сеть можно на сайте 2ip.ru
+
+Но из всего этого стоит помнить один очень важный фактор!
+
+В настоящее время обострилась проблема нехватки белых ip-адресов, так как число сетевых устройств давно превысило количество доступных ip. И по этой причине интернет провайдеры выдают пользователям серые ip-адреса (в рамках локальной сети провайдера, например в пределах нескольких многоквартирных домов) и выпускают в глобальную сеть под одним общим белым ip-адресом.
+
+Чтобы узнать серый ip-адрес выдает вам провайдер или белый, можно зайти к себе на роутер и посмотреть там, какой ip-адрес получает ваш роутер от провайдера.
+
+Например я на своем домашнем роутере вижу серый ip-адрес 172.17.132.2 (см. диапазаон локальных адресов). Для подключения белого ip-адреса провайдеры обычно предоставляют доп. услугу с абон. платой.
+
+На самом деле, для домашнего интернета это совсем не критично. А вот для офисов компаний рекомендуется покупать у провайдера именно белый ip-адрес, так как использование серого ip-адреса влечет за собой проблемы с работой ip-телефонии, а также не будет возможности настроить удаленное подключение по VPN. То есть серый ip-адрес не позволит вам вывести в интернет ваш настроенный сервер и не позволит настроить удаленное подключение на сервер из другой сети.
+
+**NAT**
+
+В предыдущем разделе я отметил, что “в настоящее время обострилась проблема нехватки белых ip-адресов” и поэтому распространенная схема подключения у интернет провайдеров сейчас, это подключать множество клиентов серыми ip-адресами, а в глобальный интернет выпускать их под одним общим белым ip.
+
+Но так было не всегда, изначально всем выдавались белые ip-адреса, и вскоре, чтобы избежать проблему дефицита белых ip-адресов, как раз и был придуман NAT (Network Address Translation) - механизм преобразования ip-адресов.
+
+NAT работает на всех роутерах и позволяет нам из локальной сети выходить в глобальную.
+
+Для лучшего понимания разберем два примера:
+
+1. Первый случай: у вас куплен белый ip-адрес 91.105.8.10 и в локальной сети подключено несколько устройств.
+
+
+
+Каждое локальное устройство имеет свой серый ip-адрес. Но выход в интернет возможен только с белого ip-адреса.
+
+Следовательно когда, например, ПК1 с ip-адресом 192.168.1.3 решил зайти в поисковик Яндекса, то роутер, выпуская запрос ПК1 в глобальную сеть, подключает механизм NAT, который преобразует ip-адрес ПК1 в белый глобальный ip-адрес 91.105.8.10
+
+Также и в обратную сторону, когда роутер получит от сервера Яндекса ответ, он с помощью механизма NAT направит этот ответ на ip-адрес 192.168.1.3, по которому подключен ПК1.
+
+2\. Второй случай: у вас также в локальной сети подключено несколько устройств, но вы не покупали белый ip-адрес у интернет провайдера.
+
+
+
+В этом случае локальный адрес ПК1(192.168.1.3) сначала преобразуется NAT'ом вашего роутера и превращается в серый ip-адрес 172.17.115.3, который вам выдал интернет-провайдер, а далее ваш серый ip-адрес преобразуется NAT’ом роутера провайдера в белый ip-адрес 91.105.108.10, и только после этого осуществляется выход в интернет (глобальную сеть).
+
+То есть, в этом случае получается, что ваши устройства находятся за двойным NAT’ом.
+
+Такая схема имеет более высокую степень безопасности ваших устройств, но также и имеет ряд больших минусов. Например, нестабильная sip-регистрация VoIP оборудования или односторонняя слышимость при звонках по ip-телефонии.
+
+Более подробно о работе механизма NAT, о его плюсах и минусах, о выделении портов, о сокетах и о видах NAT я напишу отдельную статью.
+
+**DHCP - сервер и подсети**
+
+Чтобы подключить устройство, например, компьютер к интернету вы обычно просто подключаете провод (витую пару) в компьютер и далее в свободный порт на роутере, после чего компьютер автоматически получает ip-адрес и появляется выход в интернет.
+
+Также и с Wi-Fi, например со смартфона или ноутбука, вы подключаетесь к нужной вам сети, вводите пароль, устройство получает ip-адрес и у вас появляется интернет.
+
+А что позволяет устройству получить локальный ip-адрес автоматически? Эту функцию выполняет DHCP-сервер.
+
+Каждый роутер оснащен DHCP-сервером. IP-адреса, полученные автоматически являются динамическими ip-адресами. Почему динамические? Потому что, при каждом новом подключении или перезагрузки роутера, DHCP-сервер тоже перезагружается и может выдать устройствам разные ip-адреса.
+
+То есть, например, сейчас у вашего компьютера ip-адрес 192.168.1.10, после перезагрузки роутера ip-адрес компьютера может стать 192.168.1.35
+
+Чтобы ip-адрес не менялся, его можно задать статически. Это можно сделать, как на компьютере в настройках сети, так и на самом роутере. А также, DHCP-сервер на роутере вообще можно отключить и задавать ip-адреса вручную. Можно настроить несколько DHCP-серверов на одном роутере. Тогда локальная сеть разделится на подсети.
+
+Например, компьютеры подключим к нулевой подсети в диапазон 192.168.0.2-192.168.0.255, принтеры к первой подсети в диапазон 192.168.1.2-192.168.1.255, а Wi-Fi будем раздавать на пятую подсеть с диапазоном 192.168.5.2-192.168.5.255 (см. схему ниже)
+
+
+
+Обычно, разграничение по подсетям производить нет необходимости. Это делают, когда в компании большое количество устройств, подключаемых к сети и при настройке сетевой безопасности. Но такая схема в компаниях встречается довольно часто. Поэтому обязательно нужно знать очень важный момент.
+
+Внимание! Если вам необходимо с ПК зайти на web-интерфейс, например, принтера или ip-телефона и при этом ваш ПК находится в другой подсети, то подключиться не получится.
+
+Для понимания разберем пример:
+
+
+
+Допустим вы работаете за ПК1 с локальным ip-адресом 10.10.5.2 и хотите зайти на web-интерфейс ip-телефона с локальным ip-адресом 192.168.1.3, то подключиться не получится. Так как устройства находятся в разных подсетях. К ip-телефона, находящиеся в подсети 192.168.1.X, можно подключиться только с ПК3 (192.168.1.5).
+
+Также и к МФУ (172.17.17.10) вы сможете подключиться только с ПК4 (172.17.17.12).
+
+Поэтому, когда подключаетесь удаленно к пользователю на ПК, чтобы зайти на web-интерфейс ip-телефона, то обязательно сначала сверяйте их локальные ip-адреса, чтобы убедиться, что оба устройства подключены к одной подсети.
+
+**Устройства маршрутизации сети (маршрутизатор, коммутатор, свитч, хаб)**
+
+Как ни странно, но есть такой факт, что новички в IT (иногда и уже действующие сис.админы) не знают или путают такие понятия как маршрутизатор, коммутатор, свитч, сетевой шлюз и хаб.
+
+Я думаю, причина такой путаницы возникла из-за того, что наплодили синонимов и жаргонизмов в названиях сетевого оборудования и это теперь вводит в заблуждение многих начинающих инженеров.
+
+Давайте разбираться.
+
+* Роутер, маршрутизатор и сетевой шлюз: Все знают что такое роутер. Что это именно то устройство, которое раздает в помещении интернет, подключенный от интернет провайдера. Так вот маршрутизатор и сетевой шлюз это и есть роутер. Данное оборудование является основным устройством в организации сети. В инженерной среде наиболее используемое название это “маршрутизатор”. Кстати маршрутизатором может быть не только приставка, но и системный блок компьютера, если установить туда еще одну сетевую карту и накатить, например, RouterOS Mikrotik. Далее разрулить сеть на множество устройств с помощью свитча.
+* Что такое Свитч и чем он отличается от Коммутатора и Хаба: Свитч и Коммутатор это тоже синонимы. А вот хаб немного другое устройство. О нем в следующем пункте. Коммутатор (свитч) служит для разветвления локальной сети. Как тройник или сетевой фильтр, куда мы подключаем свои устройства, чтобы запитать их электричеством от одной розетки. Коммутатор не умеет маршрутизировать сеть как роутер. Он не выдаст вашему устройству ip-адрес и без помощи роутера не сможет выпустить вас в интернет. У стандартного маршрутизатора обычно 4-5 портов для подключения устройств. Соответственно, если ваши устройства подключаются проводами и их больше чем портов на роутере, то вам необходим свитч. Можно к одному порту роутера подключить свитч на 24 порта и спокойно организовать локальную сеть на 24 устройства. А если у вас завалялся еще один роутер, то можно в его web-интерфейсе включить режим коммутатора и тоже использовать как свитч.
+* Хаб: Хаб выполняет те же функции, что и коммутатор. Но его технология распределения сильно деревянная и уже устарела. Хаб раздает приходящие от роутера пакеты всем подключенным устройствам без разбора, а устройства уже сами должны разбираться их это пакет или нет. А коммутатор имеет MAC таблицу и поэтому распределяет приходящие пакеты на одно конкретное устройство, которое и запрашивало этот пакет. Следовательно передача данных коммутатором быстрее и эффективнее. В настоящее время уже редко где встретишь использование хаба, но всё таки они попадаются, нужно быть к этому готовым и обязательно рекомендовать пользователю замену хаба на свитч.
+
+**Основные команды для анализа сети**
+
+* Команда Ping: Чтобы понять активен ли ip-адрес или само устройство, можно его “пропинговать”. Для этого в командной строке пишем команду ping “ip-адрес”. Ping намного полезней использовать с ключами:
+
+ * \-t -”пинговать” непрерывно (для остановки нажимаем комбинацию Ctrl+С);
+ * \-а -отображать имя “пингуемого” узла (сайта/устройства/сервера).
+
+ При непрерывном пинге можно увидеть адекватно ли ведет себя пингуемый узел и примерное качество работы интернет канала. Внимание! Иногда на роутерах отключена отправка ICMP пакетов (кто-то отключает специально, а где-то не включена по умолчанию), в таком случае на "пинги" такой узел отвечать не будет, хотя сам будет активен и нормально функционировать в сети. Еще одна возможность “пинга” это узнать какой ip-адрес скрывается за доменом сайта. А именно, на каком сервере установлен хост сайта;
+* Трассировка: Иногда очень важно увидеть каким путем идет пакет до определенного устройства. Возможно где-то есть пробоина и пакет не доходит до адресата. Так вот утилита трассировки помогает определить на каком этапе этот пакет застревает. На ОС Windows эта утилита вызывается командой “tracert” ip-адрес или домен. На ОС Linux эта утилита вызывается командой traceroute. Утилитой трассировки также и обладают некоторые устройства, маршрутизаторы или голосовые VoIP шлюзы.
+* Утилита whois: Данная утилита позволяет узнать всю информацию об ip-адресе или о регистраторе домена.
+
+**Транспортные протоколы TCP и UDP**
+
+Все передачи запросов и прием ответов между устройствами в сети осуществляются с помощью транспортных протоколов TCP и UDP.
+
+TCP протокол гарантированно осуществляет доставку запроса и целостность его передачи. Он заранее проверяет доступность узла перед отправкой пакета. А если по пути целостность пакета будет нарушена, то TCP дополнит недостающие составляющие. В общем, это протокол, который сделает все, чтобы ваш запрос корректно дошел до адресата. Поэтому TCP самый распространенный транспортный протокол. Он используется когда пользователь серфит интернет, лазает по сайтам, сервисам, соц. сетям и т.д.
+
+UDP протокол не имеет такой гарантированной передачи данных, как TCP. Он не проверяет доступность конечного узла перед отправкой и не восполняет пакет в случае его деградации. Если какой-то пакет или несколько пакетов по пути утеряны, то сообщение дойдет до адресата в таком неполном виде.
+
+Зачем тогда нужен UDP? Дело в том, что данный транспортный протокол имеет огромное преимущество перед TCP в скорости передачи данных. Поэтому UDP широко используется для пересылки голосовых и видео пакетов в реальном времени. А именно, в ip-телефонии и видео звонках.
+
+К примеру, любой звонок через WhatsApp или Viber использует транспортный протокол UDP. Также и при видео звонках, например, через Skype или те же мессенджеры WhatsApp и Viber.
+
+Именно потому что UDP не гарантирует абсолютную передачу данных и целостность передаваемого пакета, зачастую возникают проблемы при звонках через интернет. Это прерывание голоса, запаздывание, эхо или робоголос. Данная проблема возникает из-за нагруженного интернет канала, двойного NATа или радиоканала. Хорошо бы конечно в таких случаях использовать TCP, но увы, для передачи голоса необходима мгновенная передача целостных пакетов, а для этой задачи идеально подходит UDP.
+
+Чтобы не возникало проблем с использованием UDP протокола, нужно просто организовать качественный интернет канал. А также настроить на роутере выделенную полосу для UDP, чтобы нагрузка с других устройств, которые используют TCP не мешала работе транспортного протокола UDP.
+
+Источники:
+
+* [Сети для начинающего IT-специалиста. Обязательная база](https://habr.com/ru/post/491540/)
+
+Доп. материал:
+
+* [Podlodka #239 - Сети, часть 1: Интернет](https://www.youtube.com/watch?v=k\_GE-YfcnLg), [Podlodka #249 - Сети, часть 2](https://www.youtube.com/watch?v=G23ZpWRdjOI)
+* [Лекции по курсу "Компьютерные сети"](https://www.youtube.com/playlist?list=PLtPJ9lKvJ4oiNMvYbOzCmWy6cRzYAh9B1)
+* Таненбаум Э., Уэзеролл Д. - “Компьютерные сети”
+* В. Г. Олифер, Н. А. Олифер. “Компьютерные сети. Принципы, технологии, протоколы.”
+* [Цикл из 15 статей “Сети для самых маленьких”](https://habr.com/ru/post/134892/)
+* [Трансляция Saint HighLoad++ 2021, 20.09, Гриффиндор](https://www.youtube.com/watch?v=wG4u5XEl-vo)
+* [Список сетевых протоколов](https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA\_%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D1%8B%D1%85\_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%BE%D0%B2)
+* [Маска подсети](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D0%BA%D0%B0\_%D0%BF%D0%BE%D0%B4%D1%81%D0%B5%D1%82%D0%B8)
+* [Сетевая топология](https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F\_%D1%82%D0%BE%D0%BF%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F)
+* [Что такое VPN, Proxy, Tor? Разбор](https://habr.com/ru/company/droider/blog/549212/)
+* [Как устроен и работает протокол DHCP](https://interface31.ru/tech\_it/2019/07/kak-ustroen-i-rabotaet-protokol-dhcp.html)
+* [Ликбез №1. Как организована связь у операторов и что на нее влияет](https://mobile-review.com/articles/2016/likbez-1.shtml)
diff --git a/seti-i-okolo-nikh/etalonnye-modeli-osi-i-tcp-ip.md b/seti-i-okolo-nikh/etalonnye-modeli-osi-i-tcp-ip.md
new file mode 100644
index 0000000..1808ae8
--- /dev/null
+++ b/seti-i-okolo-nikh/etalonnye-modeli-osi-i-tcp-ip.md
@@ -0,0 +1,65 @@
+# Эталонные модели OSI и TCP/IP
+
+Мы опишем два важных архитектурных типа - эталонные модели OSI и TCP/IP. Несмотря на то что протоколы, связанные с эталонной моделью OSI, сейчас не используются, сама модель до сих пор весьма актуальна, а свойства ее уровней, которые будут обсуждаться в этом разделе, очень важны. В эталонной модели TCP/IP все наоборот: сама модель сейчас почти не используется, а ее протоколы являются едва ли не самыми распространенными. Исходя из этого, мы обсудим подробности, касающиеся обеих моделей. К тому же иногда приходится больше узнавать из поражений, чем из побед.
+
+**Эталонная модель OSI**
+
+
+
+Эта модель основана на разработке Международной организации по стандартизации (International Organization for Standardization, ISO) и является первым шагом к международной стандартизации протоколов, используемых на различных уровнях (Day и Zimmerman, 1983). Затем она была пересмотрена в 1995 году (Day, 1995). Называется эта структура эталонной моделью взаимодействия открытых систем ISO (ISO OSI (Open System Interconnection) Reference Model), поскольку она связывает открытые системы, то есть системы, открытые для связи с другими системами. Для краткости мы будем называть эту модель просто «модель OSI».
+
+Модель OSI имеет семь уровней. Появление именно такой структуры было обусловлено следующими соображениями:
+
+* Уровень должен создаваться по мере необходимости отдельного уровня абстракции;
+* Каждый уровень должен выполнять строго определенную функцию;
+* Выбор функций для каждого уровня должен осуществляться с учетом создания стандартизированных международных протоколов;
+* Границы между уровнями должны выбираться так, чтобы поток данных между интерфейсами был минимальным;
+* Количество уровней должно быть достаточно большим, чтобы различные функции не объединялись в одном уровне без необходимости, но не слишком высоким, чтобы архитектура не становилась громоздкой.
+
+Ниже мы обсудим каждый уровень модели, начиная с самого нижнего. Обратите внимание: модель OSI не является сетевой архитектурой, поскольку она не описывает службы и протоколы, используемые на каждом уровне. Она просто определяет, что должен делать каждый уровень. Тем не менее ISO также разработала стандарты для каждого уровня, хотя эти стандарты не входят в саму эталонную модель. Каждый из них был опубликован как отдельный международный стандарт. Эта модель (частично) широко используется, хотя связанные с ней протоколы долго были забыты.
+
+**Физический уровень** занимается реальной передачей необработанных битов по каналу связи. При разработке сети необходимо убедиться, что когда одна сторона передает единицу, то принимающая сторона получает также единицу, а не ноль. Принципиальными вопросами здесь являются следующие: какое напряжение должно использоваться для отображения единицы, а какое для нуля; сколько микросекунд длится бит; может ли передача производиться одновременно в двух направлениях; как устанавливается начальная связь и как она прекращается, когда обе стороны закончили свои задачи; из какого количества проводов должен состоять кабель и какова функция каждого провода. Вопросы разработки в основном связаны с механическими, электрическими и процедурными интерфейсами, а также с физическим носителем, лежащим ниже физического уровня.
+
+Основная задача\*\* уровня передачи данных\*\* - быть способным передавать «сырые» данные физического уровня по надежной линии связи, свободной от необнаруженных ошибок, и маскировать реальные ошибки, так что сетевой уровень их не видит. Эта задача выполняется при помощи разбиения входных данных на кадры, обычный размер которых колеблется от нескольких сот до нескольких тысяч байт. Кадры данных передаются последовательно с обработкой кадров подтверждения, отсылаемых обратно получателем. Еще одна проблема, возникающая на уровне передачи данных (а также и на большей части более высоких уровней), - как не допустить ситуации, когда быстрый передатчик заваливает приемник данными. Может быть предусмотрен некий механизм регуляции, который информировал бы передатчик о наличии свободного места в буфере приемника на текущий момент. В широковещательных сетях существует еще одна проблема уровня передачи данных: как управлять доступом к совместно используемому каналу. Эта проблема разрешается введением специального дополнительного подуровня уровня передачи данных - подуровня доступа к носителю.
+
+**Сетевой уровень** занимается управлением операциями подсети. Важнейшим моментом здесь является определение маршрутов пересылки пакетов от источника к пункту назначения. Маршруты могут быть жестко заданы в виде таблиц и редко меняться либо, что бывает чаще, автоматически изменяться, чтобы избегать отказавших компонентов. Кроме того, они могут задаваться в начале каждого соединения, например, терминальной сессии, такого как подключения к удаленной машине. Наконец, они могут быть в высокой степени динамическими, то есть вычисляемыми заново для каждого пакета с учетом текущей загруженности сети. Если в подсети одновременно присутствует слишком большое количество пакетов, то они могут закрыть дорогу друг другу, образуя заторы в узких местах. Недопущение подобной закупорки также является задачей сетевого уровня в соединении с более высокими уровнями, которые адаптируют загрузку. В более общем смысле, сетевой уровень занимается предоставлением определенного уровня сервиса (это касается задержек, времени передачи, вопросов синхронизации). При путешествии пакета из одной сети в другую также может возникнуть ряд проблем. Так, способ адресации, применяемый в одной сети, может отличаться от принятого в другой. Сеть может вообще отказаться принимать пакеты из-за того, что они слишком большого размера. Также могут различаться протоколы и т. д. Именно сетевой уровень должен разрешать все эти проблемы, позволяя объединять разнородные сети. В широковещательных сетях проблема маршрутизации очень проста, поэтому в них сетевой уровень очень примитивный или вообще отсутствует.
+
+Основная функция **транспортного уровня** - принять данные от сеансового уровня, разбить их при необходимости на небольшие части, передать их сетевому уровню и гарантировать, что эти части в правильном виде прибудут по назначению. Кроме того, все это должно быть сделано эффективно и таким образом, чтобы изолировать более высокие уровни от каких-либо изменений в аппаратной технологии с течением времени. Транспортный уровень также определяет тип сервиса, предоставляемого сеансовому уровню и, в конечном счете, пользователям сети. Наиболее популярной разновидностью транспортного соединения является защищенный от ошибок канал между двумя узлами, поставляющий сообщения или байты в том порядке, в каком они были отправлены. Однако транспортный уровень может предоставлять и другие типы сервисов, например пересылку отдельных сообщений без гарантии соблюдения порядка их доставки или одновременную отправку сообщения различным адресатам по принципу широковещания. Тип сервиса определяется при установке соединения. (Строго говоря, полностью защищенный от ошибок канал создать совершенно невозможно. Говорят лишь о таком канале, уровень ошибок в котором достаточно мал, чтобы им можно было пренебречь на практике.) Транспортный уровень является настоящим сквозным уровнем, то есть доставляющим сообщения от источника адресату. Другими словами, программа на машине-источнике поддерживает связь с подобной программой на другой машине при помощи заголовков сообщений и управляющих сообщений. На более низких уровнях для поддержки этого соединения устанавливаются соединения между всеми соседними машинами, через которые проходит маршрут сообщений. Различие между уровнями с 1-го по 3-й, действующих по принципу звеньев цепи, и уровнями с 4-го по 7-й, являющимися сквозными, проиллюстрировано на рис. 1.17.
+
+**Сеансовый уровень** позволяет пользователям различных компьютеров устанавливать сеансы связи друг с другом. При этом предоставляются различные типы сервисов, среди которых управление диалогом (отслеживание очередности передачи данных), управление маркерами (предотвращение одновременного выполнения критичной операции несколькими системами) и синхронизация (установка служебных меток внутри длинных сообщений, позволяющих продолжить передачу с того места, на котором она оборвалась, даже после сбоя и восстановления).
+
+В отличие от более низких уровней, задача которых - достоверная передача битов и байтов, **уровень представления** занимается по большей части синтаксисом и семантикой передаваемой информации. Чтобы было возможно общение компьютеров с различными внутренними представлениями данных, необходимо преобразовывать форматы данных друг в друга, передавая их по сети в неком стандартизированном виде. Уровень представления занимается этими преобразованиями, предоставляя возможность определения и изменения структур данных более высокого уровня (например, записей баз данных).
+
+**Прикладной уровень** содержит набор популярных протоколов, необходимых пользователям. Одним из наиболее распространенных является протокол передачи гипертекста HTTP (HyperText Transfer Protocol), который составляет основу технологии Всемирной паутины. Когда браузер запрашивает веб-страницу, он передает ее имя (адрес) и рассчитывает на то, что сервер, на котором расположена страница, будет использовать HTTP. Сервер в ответ отсылает страницу. Другие прикладные протоколы используются для передачи файлов, электронной почты, сетевых рассылок.
+
+**Эталонная модель TCP/IP**
+
+Рассмотрим теперь эталонную модель, использовавшуюся в компьютерной сети ARPANET, которая является бабушкой нынешних сетей, а также в ее наследнице, всемирной сети Интернет. ARPANET была исследовательской сетью, финансируемой Министерством обороны США. В конце концов, она объединила сотни университетов и правительственных зданий при помощи выделенных телефонных линий. Когда впоследствии появились спутниковые сети и радиосети, возникли большие проблемы при объединении с ними других сетей с помощью имеющихся протоколов. Понадобилась новая эталонная архитектура. Таким образом, возможность объединять различные сети в единое целое являлась одной из главных целей с самого начала. Позднее эта архитектура получила название эталонной модели TCP/IP, в соответствии со своими двумя основными протоколами. Первое ее описание встречается в книге Cerf и Kahn (1974), позднее превращается в стандарт (Braden, 1989). Конструктивные особенности модели обсуждаются в издании Clark, 1988. Поскольку Министерство обороны США беспокоилось, что ценные хосты, маршрутизаторы и межсетевые шлюзы могут быть мгновенно уничтожены, другая важная задача состояла в том, чтобы добиться способности сети сохранять работоспособность при возможных потерях подсетевого оборудования, так чтобы при этом связь не прерывалась. Другими словами, Министерство обороны США требовало, чтобы соединение не прерывалось, пока функционируют приемная и передающая машины, даже если некоторые промежуточные машины или линии связи внезапно вышли из строя. Кроме того, от архитектуры нужна была определенная гибкость, поскольку предполагалось использовать приложения с различными требованиями, от переноса файлов до передачи речи в реальном времени.
+
+**Канальный уровень**
+
+Все эти требования привели к выбору сети с пакетной коммутацией, основанной на уровне без установления соединения, который работает в различных сетях. Самый низкий уровень в модели, уровень канала, описывает то, как и что каналы, такие как последовательные линии и классический Ethernet, должны сделать, чтобы удовлетворить потребности этого межсетевого уровня без установления соединения. Это на самом деле не уровень вообще, в нормальном смысле слова, а скорее интерфейс между каналами передачи и узлами. В ранних материалах о модели TCP/IP мало что об этом говорится.
+
+**Межсетевой уровень**
+
+Все эти требования обусловили выбор модели сети с коммутацией пакетов, в основе которой лежал не имеющий соединений межсетевой уровень. Он соответствует сетевому уровню в OSI. Этот уровень, называемый интернет-уровнем или межсетевым уровнем, является основой всей архитектуры. Его задача заключается в обеспечении возможности каждого хоста посылать пакеты в любую сеть и независимо двигаться к пункту назначения (например, в другой сети). Они могут прибывать совершенно в другом порядке, чем были отправлены. Если требуется соблюдение порядка отправления, эту задачу выполняют более верхние уровни. Обратите внимание, что слово «интернет» здесь используется в своем первоначальном смысле, несмотря на то что этот уровень присутствует в сети Интернет. Здесь можно увидеть аналогию с почтовой системой. Человек может бросить несколько международных писем в почтовый ящик в одной стране, и, если повезет, большая часть из них будет доставлена по правильным адресам в других странах. Вероятно, письма по дороге пройдут через несколько международных почтовых шлюзов, однако это останется тайной для корреспондентов. В каждой стране (то есть в каждой сети) могут быть свои марки, свои предпочитаемые размеры конвертов и правила доставки, незаметные для пользователей почтовой службы. Межсетевой уровень определяет официальный формат пакета и протокол IP, с дополнительным протоколом ICMP (Internet Control Message Protocol, межсетевой протокол управления сообщениями). Задачей межсетевого протокола является доставка IP-пакетов к пунктам назначения. Основными аспектами здесь являются выбор маршрута пакета и недопущение закупорки транспортных артерий (хотя IP не оказался эффективным для избегания скоплений).
+
+**Транспортный уровень**
+
+Уровень, расположенный над межсетевым уровнем модели TCP/IP, как правило, называют транспортным. Он создан для того, чтобы объекты одного ранга на приемных и передающих хостах могли поддерживать связь, подобно транспортному уровню модели OSI. На этом уровне должны быть описаны два сквозных протокола. Первый, TCP (Transmission Control Protocol - протокол управления передачей), является надежным протоколом с установлением соединений, позволяющим без ошибок доставлять байтовый поток с одной машины на любую другую машину объединенной сети. Он разбивает входной поток байтов на отдельные сообщения и передает их межсетевому уровню. На пункте назначения получающий TCP-процесс собирает из полученных сообщений выходной поток. Кроме того, TCP осуществляет управление потоком, чтобы быстрый отправитель не завалил информацией медленного получателя. Второй протокол этого уровня, UDP (User Datagram Protocol - протокол пользовательских дейтаграмм), является ненадежным протоколом без установления соединения, не использующим последовательное управление потоком протокола TCP, а предоставляющим свое собственное. Он также широко используется в одноразовых клиент-серверных запросах и приложениях, в которых оперативность важнее аккуратности, например при передаче речи и видео. Со времени создания протокола IP этот протокол был реализован во многих других сетях.
+
+**Прикладной уровень**
+
+В модели TCP/IP нет сеансового уровня и уровня представления. В этих уровнях просто не было необходимости, поэтому они не были включены в модель. Вместо этого приложения просто включают все функции сеансов и представления, которые им нужны. Опыт работы с моделью OSI доказал правоту этой точки зрения: большинство приложений мало нуждаются в этих уровнях. Над транспортным уровнем располагается прикладной уровень. Он содержит все протоколы высокого уровня. К старым протоколам относятся протокол виртуального терминала (TELNET), протокол переноса файлов (FTP) и протокол электронной почты (SMTP). С годами было добавлено много других протоколов. Это DNS (Domain Name Service - служба имен доменов), позволяющая преобразовывать имена хостов в сетевые, HTTP, протокол, используемый для создания страниц на World Wide Web, а также RTP, протокол для представления мультимедиа в реальном времени, таких как звук или фильмы.
+
+Источники:
+
+* Таненбаум Э., Уэзеролл Д. - Компьютерные сети, 1.4 - 1.4.2
+
+Доп. материал:
+
+* Таненбаум Э., Уэзеролл Д. - Компьютерные сети, 1.4.4. “Сравнение эталонных моделей OSI и TCP”, 1.4.5. “Критика модели и протоколов OSI”, 1.4.6. “Критика эталонной модели TCP/IP”
+* [TCP/IP: что это и зачем это тестировщику](https://www.youtube.com/watch?v=rLUzYeLdM0k\&t=1s\&ab\_channel=HillelITSchool)
+* [Модель OSI - 7 уровней за 7 минут](https://www.youtube.com/watch?v=je0QFU7p5Oo)
+* [Модель и стек протоколов TCP/IP - Курс "Компьютерные сети"](https://www.youtube.com/watch?v=UZo4ffQ-aAc)
+* [New IP - следующий этап развития Интернета или ужесточение контроля над пользователями](https://habr.com/ru/company/vdsina/blog/553566/)
diff --git a/seti-i-okolo-nikh/http.md b/seti-i-okolo-nikh/http.md
new file mode 100644
index 0000000..3594f9d
--- /dev/null
+++ b/seti-i-okolo-nikh/http.md
@@ -0,0 +1,216 @@
+# HTTP
+
+HTTP (англ. HyperText Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных, изначально - в виде гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам) в формате HTML, в настоящее время используется для передачи произвольных данных.
+
+Основой HTTP является технология «клиент-сервер», то есть предполагается существование:
+
+* Потребителей (клиентов), которые инициируют соединение и посылают запрос;
+* Поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
+
+HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.
+
+Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (в частности, для этого используется HTTP-заголовок). Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
+
+HTTP - протокол прикладного уровня; аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния (stateless). Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
+
+Большинство протоколов предусматривает установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включенные в нее объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies; причем такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.
+
+При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нем данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющий клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов - в простейшем случае картинки в разных форматах).
+
+Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.
+
+**Структура HTTP-сообщения**
+
+Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:
+
+1. **Стартовая строка** (англ. Starting line) - определяет тип сообщения, различается для запроса и ответа;
+2. **Заголовки** (англ. Headers) - характеризуют тело сообщения, параметры передачи и прочие сведения;
+3. **Тело сообщения** (англ. Message Body) - непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.
+
+Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.
+
+**1. Стартовая строка**:
+
+* Стартовая строка запроса выглядит так: _Метод URI HTTP/Версия_, где:
+
+ * Метод (англ. Method) - тип запроса, одно слово заглавными буквами;
+ * URI определяет путь к запрашиваемому документу;
+ * Версия (англ. Version) - пара разделенных точкой цифр. Например: 1.1.
+
+ Чтобы запросить страницу данной статьи, клиент должен передать строку (задан всего один заголовок):
+
+ GET /wiki/HTTP HTTP/1.1
+
+ Host: ru.wikipedia.org
+* Стартовая строка ответа сервера имеет следующий формат: _HTTP/Версия КодСостояния Пояснение_, где:
+
+ * Версия - пара разделенных точкой цифр, как в запросе;
+ * Код состояния (англ. Status Code) - три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента;
+ * Пояснение (англ. Reason Phrase) - текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.
+
+ Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:
+
+ HTTP/1.0 200 OK
+
+**2. Заголовки:** Заголовки HTTP (англ. HTTP Headers) - это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой. Примеры заголовков:
+
+* Server: Apache/2.2.11 (Win32) PHP/5.3.0
+* Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
+* Content-Type: text/plain; charset=windows-1251
+* Content-Language: ru
+
+В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до двоеточия, называется именем (англ. name), а что после него - значением (англ. value).
+
+Все заголовки разделяются на четыре основных группы:
+
+* General Headers («Основные заголовки») - могут включаться в любое сообщение клиента и сервера;
+* Request Headers («Заголовки запроса») - используются только в запросах клиента;
+* Response Headers («Заголовки ответа») - только для ответов от сервера;
+* Entity Headers («Заголовки сущности») - сопровождают каждую сущность сообщения.
+
+Именно в таком порядке рекомендуется посылать заголовки получателю.
+
+Все необходимые для функционирования HTTP заголовки описаны в основных RFC. Если не хватает существующих, то можно вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией Microsoft для расширения WebDAV. Больше можно узнать [тут](https://developer.mozilla.org/ru/docs/Web/HTTP/Headers).
+
+_Какие заголовки важны тестировщику: очевидно, смотря что мы тестируем. В основном это заголовки, касающиеся авторизации, кук, кэша и юзер-агент, хотя для того же security тестера они будут иные. Больше_ [_тут_](https://habr.com/ru/post/413205/) _и_ [_тут_](https://xakep.ru/2011/05/24/55557/)_._
+
+\_Как сервер узнает, с какого типа устройства/браузера/ОС/языка вы открываете веб-сайт (Например, для Adaptive design): когда вы отправляете HTTP-запрос, он содержит в себе заголовки (headers) с различной информацией. Одним из них является User-Agent. Он сообщает: браузер, его версию и язык, движок браузера, версию движка, операционную систему. \_
+
+**3. Тело сообщения**: Тело HTTP-сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding.
+
+Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding - это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.
+
+Правила, устанавливающие допустимость тела сообщения в сообщении, отличны для запросов и ответов.
+
+Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения может быть добавлено в запрос, только когда метод запроса допускает тело объекта.
+
+Включается или не включается тело сообщения в сообщение ответа - зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения, даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения. Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.
+
+**Методы HTTP**
+
+Метод HTTP (англ. HTTP Method) - последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.
+
+Сервер может использовать любые методы, не существует обязательных методов для сервера или клиента, кроме того, программист может связать метод и выполняемую функцию как угодно его фантазии. Во избежание хаоса существуют соглашения (тот же REST) и стандарты. Формально если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.
+
+Основными и чаще всего используемыми методами являются GET, POST, PUT, DELETE которые эквивалентны базовым функциям при работе с БД или любыми хранимыми вычислительными сущностями - [CRUD](https://ru.wikipedia.org/wiki/CRUD) (create, read, update, delete).
+
+* **OPTIONS**: Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях. Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определен; сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера. Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку - «\*». Запросы «OPTIONS \* HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1. Результат выполнения этого метода не кэшируется;
+* **GET**: Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса. Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»: GET /path/resource?param1=value1\¶m2=value2 HTTP/1.1. Согласно стандарту HTTP, запросы типа GET считаются идемпотентными. Кроме обычного метода GET, различают ещё
+
+ * Условный GET - содержит заголовки If-Modified-Since, If-Match, If-Range и подобные;
+ * Частичный GET - содержит в запросе Range.
+
+ Порядок выполнения подобных запросов определен стандартами отдельно;
+* **HEAD**: Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения. Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше - копия ресурса помечается как устаревшая;
+* **POST**: Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами - текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер. В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться очередная копия этого комментария). При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location. Сообщение ответа сервера на выполнение метода POST не кэшируется. Стоит отметить, что [не всегда данные могут быть лишь в теле](https://stackoverflow.com/questions/611906/http-post-with-url-query-parameters-good-idea-or-not);
+* **PUT**: Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же ресурс был изменен, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-\*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или недопустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented). Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу. Сообщения ответов сервера на метод PUT не кэшируются;
+* **PATCH**: Аналогично PUT, но применяется только к фрагменту ресурса;
+* **DELETE**: Удаляет указанный ресурс;
+* **TRACE**: Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе;
+* **CONNECT**: Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищенного SSL-соединения через нешифрованный прокси.
+
+**Различия методов GET и POST**
+
+Основное состоит в способе передачи данных веб-формы обрабатывающему скрипту, а именно:
+
+* Метод GET отправляет скрипту всю собранную информацию формы как часть URL: http://www.komtet.ru/script.php?login=admin\&name=komtet
+* Метод POST передает данные таким образом, что пользователь сайта уже не видит передаваемые скрипту данные: http://www.komtet.ru/script.php
+
+Кроме того:
+
+* Количество информации, передаваемой методом GET через URL строку ограничено 2048 символами (минус служебная информация браузера);
+* Страницу, сгенерированную методом GET, можно добавить в закладки и поделиться ссылкой;
+* Sensitive data в таком открытом виде очевидно плохо влияют на безопасность;
+* Метод POST в отличие от метода GET позволяет передавать запросу файлы;
+* При использовании метода GET существует риск того, что поисковый робот может выполнить тот или иной открытый запрос.
+
+**Коды состояния**
+
+Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трёх цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделенная пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:
+
+* 201 Webpage Created;
+* 403 Access allowed only for registered users;
+* 507 Insufficient Storage.
+
+Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
+
+В настоящее время выделено пять классов кодов состояния.
+
+| **Код** | **Класс** | **Назначение** |
+| ----------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 100-е (1ХХ) |
Информационный
(англ. informational)
|
Информирование о процессе передачи.
В HTTP/1.0 - сообщения с такими кодами должны игнорироваться.
В HTTP/1.1 - клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно.
Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
|
+| 200-е (2ХХ) |
Успех
(англ. Success)
| Информирование о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса, сервер может ещё передать заголовки и тело сообщения. |
+| 300-е (3ХХ) |
Перенаправление
(англ. Redirection)
| Сообщает клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI. |
+| 400-е (4ХХ) |
Ошибка клиента
(англ. Client Error)
| Указание ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. |
+| 500-е (5ХХ) |
Ошибка сервера
(англ. Server Error)
| Информирование о случаях неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю. |
+
+Полный перечень можно найти [тут](https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA\_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2\_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F\_HTTP). Данные диапазоны определены в стандартах, однако ничего не мешает в повседневной жизни увидеть и [неофициальные](https://en.wikipedia.org/wiki/List\_of\_HTTP\_status\_codes#:\~:text=Fi%20hotspot).%5B57%5D-,Unofficial%20codes,-The%20following%20codes), [еще](https://developer.fastly.com/reference/http/http-statuses/) и [еще](https://support.cloudflare.com/hc/en-us/articles/360029779472-Troubleshooting-Cloudflare-1XXX-errors).
+
+**Почему ошибка 404 относится к 4** - клиентской, если по идее должна быть 5\*\*?\*\* Объясняется это тем, что сервер работает и готов вернуть страницу в ответ на запрос, однако страницы по запрашиваемому адресу у него попросту нет. Таким образом, вины сервера в этом нет и предполагается опечатка в URL, которая является виной клиента. В этом вопросе сбивает с толку то, что ошибка 404 часто возвращается, когда страница была перемещена или удалена, или не совпадает имя файла в коде и на сервере. Тогда корректнее показывать ошибки 301 Moved Permanently (перемещено), что можно настроить в конфигурации большинства серверов, либо производить перенаправление на другой URL, и возвращать код 410 Gone (удалено). Однако, так как эти два варианта требуют специальной настройки сервера, большинство веб-сайтов не используют их.
+
+**На какой метод не может вернуться ошибка 501?** The HTTP 501 Not Implemented серверный код ответа на ошибку указывает, что метод запроса не поддерживается сервером и не может быть обработан. Единственными методами, которые необходимы серверам для поддержки (и, следовательно, не должны возвращать этот код), являются GET и HEAD.
+
+**Отличия HTTP/1.1 от HTTP/2.0**
+
+11 февраля 2015 года опубликованы финальные версии черновика следующей версии протокола. В отличие от предыдущих версий, протокол HTTP/2 является бинарным. Среди ключевых особенностей: мультиплексирование запросов, расстановка приоритетов для запросов, сжатие заголовков, загрузка нескольких элементов параллельно посредством одного TCP-соединения, поддержка проактивных push-уведомлений со стороны сервера. Подробнее [тут](https://www.8host.com/blog/v-chem-raznica-mezhdu-http1-1-i-http2/).
+
+**HTTP3**
+
+Десятилетиями весь интернет держался на TCP, но он начал устаревать еще в конце 2000-х. Его предполагаемая замена, новый транспортный протокол под названием QUIC, настолько отличается от TCP по ключевым пунктам, что просто использовать поверх него HTTP/2 было бы очень сложно. Поэтому сам по себе HTTP/3 - это относительно незначительное изменение HTTP/2 для адаптации к новому протоколу QUIC. Вот он-то как раз и содержит те фичи, которые всех приводят в восторг.
+
+
+
+TCP, который мы использовали с первых дней интернета, изначально был создан не на максимуме эффективности, поэтому нам и стал нужен QUIC. Например, TCP требует рукопожатие для установки нового соединения, чтобы проверить, что клиент и сервер существуют и готовы обмениваться данными. Нужно сделать полный круговой путь по сети, прежде чем можно будет делать что-то ещё. Если клиент и сервер находятся далеко, время кругового пути (round-trip time, RTT) может составить более 100 мс, что приводит к ощутимым задержкам.
+
+Второй пример: TCP видит все данные, которые передает, как один «файл», или поток байтов, даже если мы передаем несколько файлов одновременно (например, загружаем страницу с несколькими ресурсами). На практике это означает, что, если пакеты TCP с данными одного файла теряются, все остальные файлы будут ждать восстановления этих пакетов. Это так называемая блокировка начала очереди - head-of-line (HoL) blocking. На практике с этими недостатками можно бороться (иначе зачем бы мы мучились с TCP целых 30 с лишним лет), но они серьезно влияют на протоколы верхнего уровня, например, HTTP.
+
+На самом деле нам нужен был не HTTP/3, а TCP/2. Просто в процессе у нас сам собой получился HTTP/3. Всё то, чего мы с таким нетерпением ждем от HTTP/3 (быстрая установка соединения, меньше блокировок HoL, миграция соединения и т. д.), - на самом деле уже реализовано в QUIC.
+
+**QUIC**
+
+QUIC - это универсальный транспортный протокол. Как и TCP, он может и будет использоваться в разных сценариях, не только для HTTP и загрузки сайтов. Например, поверх QUIC можно пристроить DNS, SSH, SMB, RTP и так далее. Давайте узнаем о QUIC чуть больше, ведь именно с ним связаны многие заблуждения по поводу HTTP/3.
+
+Вы, наверное, слышали, что QUIC работает поверх еще одного протокола - UDP. Это правда, но производительность тут ни при чём. В идеале QUIC мог бы быть полностью независимым транспортным протоколом сразу над IP в стеке, как на картинке выше.
+
+Но тогда возникли бы те же сложности, что и при попытке развивать TCP: пришлось бы сначала обновить все устройства в интернете, чтобы они распознавали и разрешали QUIC. К счастью, мы можем разместить QUIC поверх еще одного распространенного протокола транспортного уровня: UDP.
+
+Многие говорят, что HTTP/3 создан поверх UDP в целях производительности. Якобы HTTP/3 работает быстрее, потому что, как и UDP, не устанавливает соединение и не ждет повторной передачи пакетов. Не верьте. Мы уже сказали, что UDP используется протоколом QUIC, а значит и HTTP/3, в надежде, что так их будет проще развернуть, ведь UDP уже знают и используют почти все устройства в интернете.
+
+Расположенный поверх UDP, QUIC, по сути, реализует почти все функции, которые делают TCP таким эффективным и популярным (пусть и чуть более медленным) протоколом. QUIC абсолютно надежен - он использует подтверждение полученных пакетов и повторные передачи, чтобы добрать то, что потерялось. QUIC по-прежнему устанавливает соединение и использует сложную систему рукопожатий.
+
+Наконец, QUIC использует механизмы flow-control и congestion-control, которые не дают отправителю перегрузить сеть или получателя, но замедляют TCP по сравнению «чистым» UDP. Правда QUIC реализует эти функции умнее и эффективнее. В нём собраны десятилетия опыта и лучших практик TCP и новые функции.
+
+**HTTPS**
+
+У HTTP есть один недостаток: данные передаются в открытом виде и никак не защищены. На пути из точки А в точку Б информация в интернете проходит через десятки промежуточных узлов, и, если хоть один из них находится под контролем злоумышленника, данные могут перехватить. То же самое может произойти, когда вы пользуетесь незащищенной сетью Wi-Fi, например, в кафе. Для установки безопасного соединения используется протокол HTTPS с поддержкой шифрования.
+
+HTTPS (аббр. от англ. HyperText Transfer Protocol Secure) - расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL.
+
+HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения - от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства и сертификат сервера проверен и ему доверяют.
+
+По умолчанию HTTPS URL использует 443 TCP-порт (для незащищенного HTTP - 80). Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат открытого и закрытого ключа для этого веб-сервера. В TLS используется как асимметричная схема шифрования (для выработки общего секретного ключа), так и симметричная (для обмена данными, зашифрованными общим ключом). Сертификат открытого ключа подтверждает принадлежность данного открытого ключа владельцу сайта. Сертификат открытого ключа и сам открытый ключ посылаются клиенту при установлении соединения; закрытый ключ используется для расшифровки сообщений от клиента.
+
+Существует возможность создать такой сертификат, не обращаясь в центр сертификации. Подписываются такие сертификаты этим же сертификатом и называются самоподписанными (self-signed). Без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) такое использование HTTPS подвержено атаке посредника.
+
+Эта система также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только авторизованным пользователям. Для этого администратор обычно создает сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля.
+
+В HTTPS для шифрования используется длина ключа 40, 56, 128 или 256 бит. Некоторые старые версии браузеров используют длину ключа 40 бит (пример тому - IE версий до 4.0), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является надежной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит, с целью обеспечить достаточный уровень безопасности. Шифрование с длиной ключа 128 бит значительно затрудняет подбор паролей и доступ к личной информации.
+
+Традиционно на одном IP-адресе может работать только один HTTPS-сайт. Для работы нескольких HTTPS-сайтов с различными сертификатами применяется расширение TLS под названием Server Name Indication (SNI).
+
+Идентификация в HTTPS:
+
+* Идентификация сервера: HTTP/TLS запросы генерируются путём разыменования URI, вследствие чего имя хоста становится известно клиенту. В начале общения, сервер посылает клиенту свой сертификат, чтобы клиент идентифицировал его. Это позволяет предотвратить атаку посредника. В сертификате указывается URI сервера. Согласование имени хоста и данных, указанных в сертификате, происходит в соответствии с протоколом RFC2459. Если имя сервера не совпадает с указанным в сертификате, то пользовательские программы, например браузеры, сообщают об этом пользователю. В основном, браузеры предоставляют пользователю выбор: продолжить незащищённое соединение или прервать его.
+* Идентификация клиента: Обычно сервер не располагает информацией о клиенте, достаточной для его идентификации. Однако для обеспечения повышенной защищенности соединения используется так называемая two-way authentication. При этом сервер после подтверждения его сертификата клиентом также запрашивает сертификат. Таким образом, схема подтверждения клиента аналогична идентификации сервера.
+
+Источники:
+
+* [HTTP](https://ru.wikipedia.org/wiki/HTTP)
+* [HTTP/3 от А до Я: основные концепции. Часть 1](https://habr.com/ru/company/southbridge/blog/575464/)
+* [HTTPS](https://ru.wikipedia.org/wiki/HTTPS)
+
+Доп. материал:
+
+* [HTTP для тестировщиков](https://www.youtube.com/watch?v=iS-D5jZ\_c24\&t=1s\&ab\_channel=HillelITSchool)
+* [Идемпотентный метод](https://developer.mozilla.org/ru/docs/Glossary/Idempotent)
+* [Жизненный цикл HTTP-запроса](https://www.youtube.com/watch?v=8ZKlOD4fRT0)
diff --git a/seti-i-okolo-nikh/identifikaciya-resursov-v-seti-identifying-resources-on-the-web.md b/seti-i-okolo-nikh/identifikaciya-resursov-v-seti-identifying-resources-on-the-web.md
new file mode 100644
index 0000000..bf533ec
--- /dev/null
+++ b/seti-i-okolo-nikh/identifikaciya-resursov-v-seti-identifying-resources-on-the-web.md
@@ -0,0 +1,91 @@
+# Идентификация ресурсов в сети (Identifying resources on the Web)
+
+"Объект" (или "цель") HTTP-запроса называется "ресурс", чья природа может быть разной: фото, документ, или что-либо ещё. Каждый ресурс идентифицируется с помощью унифицированного идентификатора ресурса URI используемого повсюду в HTTP для идентификации ресурсов.
+
+* **URI** - Uniform Resource Identifier (унифицированный идентификатор ресурса);
+* **Uniform Resource Locator** (унифицированный определитель местонахождения ресурса);
+* **URN** - Uniform Resource Name (унифицированное имя ресурса).
+
+Твое имя, скажем, “Джон Доу” - это URN. Место, в котором вы живете, например, “Улица Вязов, 13” - это уже URL. Вы можете быть идентифицированы как уникальное лицо с вашим именем или вашим адресом. Эта уникальная личность - это уже URI. И хотя ваше имя может быть вашим уникальным идентификатором (URI), оно не может быть URL-адресом, поскольку ваше имя не помогает найти ваше местоположение. Другими словами, URI (которые являются URN) не являются URL-адресами.
+
+Упрощая: URL - отвечает на вопрос: «Где и как найти что-то?», URN - отвечает на вопрос: «Как это что-то идентифицировать».
+
+Вернемся в интернет:
+
+* URI - имя и адрес ресурса в сети, включает в себя URL и URN;
+* URL - адрес ресурса в сети, определяет местонахождение и способ обращения к нему;
+* URN - имя ресурса в сети, определяет только название ресурса, но не говорит как к нему подключиться.
+
+Пример:
+
+* URI - [https://wiki.merionet.ru/images/vse-chto-vam-nuzhno-znat-pro-devops/1.png](https://wiki.merionet.ru/images/vse-chto-vam-nuzhno-znat-pro-devops/1.png)
+* URL - [https://wiki.merionet.ru](https://wiki.merionet.ru)
+* URN - images/vse-chto-vam-nuzhno-znat-pro-devops/1.png
+
+**URI**
+
+URI - последовательность символов, идентифицирующая физический или абстрактный ресурс, который не обязательно должен быть доступен через сеть Интернет, причем, тип ресурса, к которому будет получен доступ, определяется контекстом и/или механизмом. **URI = URL + URN**.
+
+**Синтаксис URI**
+
+**1. Схема или протокол**
+
+
+
+http:// это пример протокола (схемы). Тут описывается какой протокол браузер должен использовать. Обычно это HTTP протокол или его безопасная версия - HTTPS. Интернет требует один из этих двух, но браузеры также знают как работать с некоторыми другими, например mailto: (чтобы открыть почтовый клиент) или ftp: для работы с передачей файлов. Популярные схемы:
+
+| **Схема** | **Описание** |
+| ----------- | ---------------------------------------------------------------------------------------------------------- |
+| data | [Data URIs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics\_of\_HTTP/Data\_URIs) |
+| file | Доступ к файлам на локальном компьютере |
+| ftp | [File Transfer Protocol](https://developer.mozilla.org/en-US/docs/Glossary/FTP) (протокол передачи файлов) |
+| http/https | Hyper text transfer protocol (Secure) |
+| mailto | Адрес электронной почты |
+| ssh | Протокол Secure shell для работы с серверами |
+| tel | Телефон |
+| urn | Uniform Resource Names |
+| view-source | Исходный код ресурса |
+| ws/wss | (Зашифрованные) соединения WebSocket |
+
+.
+
+**2. Владелец (имя хоста)**
+
+
+
+www.example.com - это доменное имя, идентификатор ответственного за это пространство имён. Идентифицирует, какой именно Веб-сервер получает запрос. Альтернативно, можно просто использовать IP address, но поскольку это не так удобно, то этот способ используется не часто.
+
+**3. Порт**
+
+
+
+:80 - это порт сервера. Он идентифицирует технические "ворота", которые нужны для доступа к ресурсу на сервере. Обычно порт не указывается, т.к. существуют общепринятые нормы о стандартных портах для HTTP (80 для HTTP и 443 для HTTPS). В других случаях обязательно нужно указывать.
+
+**4. Путь**
+
+
+
+/path/to/myfile.html - это путь к ресурсу на Веб-сервере. Изначально путь типа этого указывал на физическое место файла на сервере, но сейчас всё чаще это псевдоним или описание некоторого абстрактного ресурса.
+
+**5. Строка запроса (query string)**
+
+
+
+key1=value1\&key2=value2 - это дополнительные параметры (query parameters), предоставляемые Веб-серверу. Это список пар "ключ=значение", разделенных символом & . Веб-сервер может использовать эти параметры как дополнительные инструкции, что именно сделать с ресурсом перед отправкой его пользователю. Каждый Веб-сервер имеет свои правила насчет параметров, и единственный надежный способ узнать как конкретный Веб-сервер обрабатывает эти параметры - это спросить того, кто контролирует Веб-сервер.
+
+**6. Фрагмент**
+
+
+
+"символ решетки"SomewhereInTheDocument - это "якорь" на другую часть ресурса. Якорь представляет собой что-то вроде "закладки" внутри ресурса, давая браузеру указание показать содержимое с определённого места. В HTML-документе, к примеру, браузер будет скроллить к точке где якорь определён, а на аудио/видео-документе браузер попытается перейти на время, указанное в якоре. Важно что часть, начинающаяся с # - никогда не пересылается серверу в запросе.
+
+Источники:
+
+* [Идентификация ресурсов в Вебе](https://developer.mozilla.org/ru/docs/Web/HTTP/Basics\_of\_HTTP/Identifying\_resources\_on\_the\_Web)
+* [URL И URI - в чем различие?](https://wiki.merionet.ru/servernye-resheniya/36/url-i-uri-v-chem-razlichie/#)
+
+Доп. материал:
+
+* [URI - сложно о простом (Часть 1)](https://habr.com/ru/post/232385/)
+* [RFC 7230, секция 2.7: Uniform Resource Identifiers](https://datatracker.ietf.org/doc/html/rfc7230#section-2.7)
+* [Список схем URI](https://translated.turbopages.org/proxy\_u/en-ru.ru.4ae8fbd1-61dffb3d-16db65b2-74722d776562/https/en.wikipedia.org/wiki/List\_of\_URI\_schemes)
diff --git a/seti-i-okolo-nikh/kesh-cache.md b/seti-i-okolo-nikh/kesh-cache.md
new file mode 100644
index 0000000..331f70e
--- /dev/null
+++ b/seti-i-okolo-nikh/kesh-cache.md
@@ -0,0 +1,146 @@
+# Кэш (Cache)
+
+Производительность веб-сайтов и приложений можно значительно повысить за счет повторного использования ранее полученных ресурсов.
+
+**Кэширование (или кэш)** - это некий промежуточный буфер, в котором хранятся данные. Благодаря кэшированию страница сайта не воссоздается заново для каждого пользователя. Кэширование позволяет осуществлять работу с большим количеством данных в максимально сжатые сроки и при ограниченных ресурсах (серверных и пользовательских).
+
+Необходимо понимать, что работу с данными можно производить как на стороне клиента, так и на сервере. Притом, серверная обработка данных централизована и имеет ряд несомненных преимуществ (особенно для службы поддержки).
+
+**Категории кэшей**:
+
+* **Приватный** (private) кэш браузера: предназначен для отдельного пользователя. Вы, возможно, уже видели параметры кэширования в настройках своего браузера. Кеш браузера содержит все документы, загруженные пользователем по HTTP. Он используется для доступа к ранее загруженным страницам при навигации назад/вперед, позволяет сохранять страницы, или просматривать их код, не обращаясь лишний раз к серверу. Кроме того, кэш полезен при отключении от сети.
+* **Общий** (shared) прокси-кэш: это кэш, который сохраняет ответы, чтобы их потом могли использовать разные пользователи. Например, в локальной сети вашего провайдера или компании, может быть установлен прокси, обслуживающий множество пользователей, чтобы можно было повторно использовать популярные ресурсы, сокращая тем самым сетевой трафик и время ожидания.
+
+**Виды кэширования**:
+
+**1. Браузерное кэширование или клиентское кэширование**
+
+Представляет собой составление для браузера команды использовать имеющуюся кэшированную копию. Работа такого кэширования основана на том, что при повторном посещении, браузеру отдаётся заголовок 304 Not Modified, а сама страница или картинка загружаются из локального пользовательского кэша. Получается, что вы экономите на трафике между браузером посетителя и хостингом сайта. Соответственно, страница вашего сайта начинает загружаться быстрее.
+
+**1.1 Кэширование файлов и картинок**
+
+Браузерное кэширование как нельзя лучше подходит для сайтов, содержащих большое количество изображений: картинка не скачивается каждый раз при открытии сайта, а просто загружается через кэш браузера. Это первый уровень кэширования, который состоит в отдаче заголовка «expired» и заголовка «304 Not Modified». Наиболее эффективным считается кэширование на 2 недели. Однако в данном случае есть важный нюанс: если изображение на сайте меняется, то браузер узнает об этом не сразу, а только если выждать expiry или сбросить кэш в самом браузере. Это не очень эффективно, если файл постоянно изменяется и необходимо постоянно отдавать его актуальную версию.
+
+**1.2 Кэширование https**
+
+Специальные заголовки вида strict-security. Позволяет браузеру всегда обращаться по https к выбранному домену. Сохраняет это состояние довольно жёстко и, в случае отмены этого вида кэша, браузер ещё довольно долго будет пытаться загрузить страницу по https, при этом игнорируя текущие заголовки.
+
+**1.3 Кэширование центра сертификации**
+
+Так называемый, stamp центра сертификации.
+
+Данный вид кэширования считается обязательным для применения, если вы не хотите, чтобы пользователи вашего сайта ждали, когда центр сертификации (а это некий сервер, который отвечает за достоверность вашего сертификата) обработает запрос от браузера пользователя и подтвердит, что ваш сайт действительно подтверждён им.
+
+**1.4 Кэширование страниц**
+
+Когда страница уже сгенерирована, нужно постоянно отслеживать ее актуальность. Для этого вы должны использовать серверный кэш с отслеживанием времени изменения отдельных частей страницы (если страница строится из множества динамически генерируемых блоков). При таком подходе в каждом ответе от сервера установлены специальные заголовки, обозначающие время изменения страницы, которые затем отправляются браузером пользователя при повторном обращении к странице сайта. Сервер при получении таких заголовков можем проанализировать текущее состояние страницы (возможно, даже отрисовать её), но вместо содержимого страницы отдать заголовок «304 Not Modified», что для пользовательского браузера будет означать, что можно показать страницу из своего (браузера пользователя) кэша.
+
+Конечно, можно отправлять соответствующие заголовки без использования серверного отслеживания кэша, но в таком случае большинство пользователей получат обновление контента страницы довольно поздно. При таком подходе браузер иногда опрашивает сервер для получения обновлений, но периодичность и правила для каждого браузера настраиваются его разработчиком, поэтому надеяться на то, что ваши пользователи получат обновления вовремя, не приходится.
+
+Как правило, кэш подразделяется по типу пользователей:
+
+* для авторизованных;
+* для неавторизованных.
+
+Данное разделение обусловлено уникальностью контента, для каждого авторизованного пользователя и общностью контента для гостевых пользователей. В большинстве сайтов неавторизованный пользователь не может изменять содержимое сайта, а значит и влиять на его содержимое.
+
+Браузерный кэш позволяет экономить трафик и время, затрачиваемое на загрузку страниц. Но для достижения эффекта экономии, пользователь должен хотя бы один раз посетить нашу страницу, а это означает, что нагрузка на серверные ресурсы уменьшится, но не значительно.
+
+**2. Серверное кэширование**
+
+Под серверным кэшированием понимаются все виды кэширования, при котором данные хранятся на серверной стороне. Эти данные не доступны клиентским браузерам. Кэш создается и хранится по принципу «один ко многим» (многие, в данном случае, - это клиентские устройства).
+
+**2.1 Кэширование страницы целиком**
+
+Наиболее эффективный кэш. Чем он интересен? Самое большое его достоинство в том, что отдача страницы происходит практически в момент обращения, как следствие - это возможность обработки миллионов запросов даже на самом слабом сервере со скоростью работы памяти и с незначительным задействованием процессора.
+
+Пожалуй, любой когда-либо мечтал о сайте, работающем со скоростью «ping» или быстрее.
+
+Но и у этого типа кэша есть свои минусы: например, невозможность кэшировать страницы для авторизованного пользователя, либо пользователя, содержимое страницы которого зависит от текущих переменных пользователя.
+
+Используйте этот кэш, если серверу известны все статичные состояния внешних данных, такие как: uri, get (без дополнительных параметров), пользователь не авторизован - то есть, фактически, это идеальное состояние страницы для гостевых пользователей. Учитывайте тот факт, что при таком кэшировании архитектура сайта или приложения всегда должна однотипно обрабатывать входящие запросы и отдавать однотипные ответы. Такое состояние есть в любом приложении или сайте, его нужно лишь отследить и применить к нему кэш.
+
+Кэширование страниц целиком, чаще всего, применяют в каких-то экстренных случаях, при этом кэш страниц сохраняется на заранее указанное время (от 2 минут), в течение которого ответы от сервера однотипны (не позволяйте браузеру кэшировать это).
+
+**2.2 Кэширование результатов компиляции php-файлов**
+
+Различают как чистую компиляцию кода, так и его оптимизацию во время компилирования (подмена скриптов).
+
+**2.3 Кэширование отдельных блоков страницы**
+
+Это, пожалуй, самый интересный, но и сложный вид кэширования. Тем не менее, он тоже может быть эффективным, и на его примере легче всего объяснить принципы кэширования в целом.
+
+Необходимо отслеживать: состояние таблиц, состояние сессии пользователя, выключать ли кэширование при POST или GET запросах (http query), зависимость от текущего адреса, постоянство кэширования (при изменении предыдущих условий) или его динамическую подстройку.
+
+Кэширование отдельных блоков страниц лучше других типов кэширования подойдет, если вам нужно, например, уменьшить количество запросов к базе данных от реальных (авторизованных) пользователей. Кстати, при правильно заданных зависимостях, он будет работать даже эффективнее, чем все последующие виды кэширования.
+
+Почему этот вид кэширования настолько важен? Всё дело в том, что расширение пула серверов баз данных намного более сложная задача, чем расширение пула серверов php-части сайта. Более того, php конфликты состояния кэширования решаются гораздо легче, чем конфликты при работе с множеством баз данных.
+
+**2.4 Кэширование php на основе неразделяемых ресурсов**
+
+Лучше всего подходит при стандартизации запросов, получении данных из общих ресурсов, наличии внутренних переменных, к которым php-ресурсы обращаются несколько раз при генерации страницы.
+
+**2.5 Кэширование php на основе общих ресурсов**
+
+Такое кэширование применяйте для хранения сериализированных данных. Например: конфигурационного файла, состояния таблиц, списков файловой системы.
+
+**2.6 Кэширование mysql на основе query cache**
+
+Это довольно известная и наиболее освещенная тема. Тем не менее, хотелось бы рассмотреть специфику работы с timestamp и то, как можно избежать постоянного сброса query cache.
+
+Наверняка, вы регулярно сталкивались с ситуацией, когда необходимо отдать новые материалы, дата публикации которых уже разрешена текущим timestamp? Проще говоря, WHERE show\_ts<=UNIX\_TIMESTAMP()
+
+Если использовать постоянно меняющийся timestamp в таких запросах, то sql кэш будет не только бесполезен, но даже вреден, так как будет копиться количество кэшированных запросов, данные которых устарели в момент создания кэша. Мы предлагаем следующий выход из ситуации:
+
+Как правило, любой материал публикуется в определенные моменты времени. К примеру, 00:00. Всё что нужно сделать - создать запрос, который будет оценивать таблицу по максимальной дате, при этом, меньшей текущей.
+
+Что-то вроде: SELECT SQL\_NO\_CACHE MAX(show\_ts) … WHERE show\_ts<=UNIX\_TIMESTAMP();
+
+Да, этот запрос кэшироваться не будет, но будут кэшироваться все запросы к этой таблице, если их количество больше одного. Эта простая операция существенно улучшит жизнь sql-кэширования.
+
+Кэшировать эти запросы имеет смысл, если чтений из таблицы немного больше чем записи.
+
+**2.7 Кэширование mysql результатов работы, агрегирующие таблицы**
+
+Существует правило: обновлений данных должно быть значительно меньше, чем чтения для их отдачи. То есть не имеет смысл агрегировать то, что изменится в тот же момент, при этом важна актуальность агрегированных данных. Что выбирать для агрегирования? Обычно это какая-то статистическая информация о числе записей, дате последнего обновления, авторе последнего обновления и тому подобное.
+
+Существуют также кеши шлюзов, [CDN](https://www.cloudflare.com/learning/cdn/what-is-caching/#:\~:text=What%20is%20CDN%20caching%3F), реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надежности, производительности и масштабируемости веб-сайтов и веб-приложений.
+
+**3. Кэширование и прокси-серверы**
+
+В компьютерных сетях прокси-серверы могут быть представлены специальным аппаратным обеспечением или соответствующими приложениями. Они играют роль посредников между клиентами и серверами, хранящими данные, которые этим клиентам требуются. Кэширование - это одна из задач, которую они решают. Рассмотрим различные виды прокси-серверов.
+
+**3.1 Шлюзы**
+
+Шлюз (gateway) - это прокси-сервер, который перенаправляет входящие запросы или исходящие ответы, не модифицируя их. Такие прокси-серверы ещё называют туннелирующими прокси (tunneling proxy), веб-прокси (web proxy), прокси (proxy), или прокси уровня приложения (application level proxy). Эти прокси-серверы обычно совместно используются, например, всеми клиентами, находящимися за одним и тем же файрволом, что делает их хорошо подходящими для кэширования запросов.
+
+**3.2 Прямые прокси-серверы**
+
+Прямой прокси-сервер (forward proxy, часто такие серверы называют просто proxy server) обычно устанавливается на стороне клиента. Веб-браузер, который настроен на использование прямого прокси-сервера, будет отправлять исходящие запросы этому серверу. Затем эти запросы будут перенаправлены на целевой сервер, расположенный в интернете. Одно из преимуществ прямых прокси заключаются в том, что они защищают данные клиента (однако, если говорить об обеспечении анонимности в интернете, безопаснее будет пользоваться VPN).
+
+**3.3 Веб-ускорители**
+
+Веб-ускоритель (web accelerator) - это прокси-сервер, который уменьшает время доступа к сайту. Он делает это, заранее запрашивая у сервера документы, которые, вероятнее всего, понадобятся клиентам в ближайшем будущем. Подобные серверы, кроме того, могут сжимать документы, ускорять выполнение операций шифрования, уменьшать качество и размер изображений, и так далее.
+
+**3.4 Обратные прокси-серверы**
+
+Обратный прокси-сервер (reverse proxy) - это обычно сервер, расположенный там же, где и веб-сервер, с которым он взаимодействует. Обратные прокси-серверы предназначены для предотвращения прямого доступа к серверам, расположенным в частных сетях. Обратные прокси используются для балансировки нагрузки между несколькими внутренними серверами, предоставляют возможности SSL-аутентификации или кэширования запросов. Такие прокси выполняют кэширование на стороне сервера, они помогают основным серверам в обработке большого количества запросов.
+
+**3.5 Пограничное кэширование**
+
+Обратные прокси-серверы расположены близко к серверам. Существует и технология, при использовании которой кэширующие серверы располагаются как можно ближе к потребителям данных. Это - так называемое пограничное кэширование (edge caching), представленное сетями доставки контента (CDN, Content Delivery Network). Например, если вы посещаете популярный веб-сайт и загружаете какие-нибудь статические данные, они попадают в кэш. Каждый следующий пользователь, запросивший те же данные, получит их, до истечения срока их кэширования, с кэширующего сервера. Эти серверы, определяя актуальность информации, ориентируются на серверы, хранящие исходные данные.
+
+
+
+_Примечание. В тестировании практически во всех случаях правило - очищать кэш после каждого прохода теста (если только это не целенаправленной тестирование самого кэша или требуется наличие кэша по каким-либо причинам). Дело в том, что кэш очевидно искажает показатели performance testing, а также может быть причиной ошибочного дефект-репорта из-за устаревания и/или несогласованности актуальных и сохраненных данных. В некоторых ситуациях без очистки кеша не обойтись даже просто из-за огромного количества кэшируемых данных._
+
+Источники:
+
+* [11 видов кэширования для современного сайта](https://habr.com/ru/company/zerotech/blog/316316/)
+* [Кэширование и производительность веб-приложений](https://habr.com/ru/company/ruvds/blog/350310/)
+
+Доп. материал:
+
+* [Обзор кэширования](https://aws.amazon.com/ru/caching/)
+* [RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](https://datatracker.ietf.org/doc/html/rfc7234)
+* [HTTP-кеширование](https://developer.mozilla.org/ru/docs/Web/HTTP/Caching)
diff --git a/seti-i-okolo-nikh/khranilishe-na-storone-klienta-client-side-storage.md b/seti-i-okolo-nikh/khranilishe-na-storone-klienta-client-side-storage.md
new file mode 100644
index 0000000..5a7f3e2
--- /dev/null
+++ b/seti-i-okolo-nikh/khranilishe-na-storone-klienta-client-side-storage.md
@@ -0,0 +1,150 @@
+# Хранилище на стороне клиента (Client-side storage)
+
+Современные веб-браузеры поддерживают несколько способов хранения данных из веб-сайтов на компьютере пользователя - с разрешения пользователя - чтобы потом получать их, когда это необходимо. Это позволяет долгосрочно хранить данные, сохранять сайты или документы для использования без подключения к сети, сохранять пользовательские настройки для вашего сайта и многое другое.
+
+Ранее, мы говорили о разнице между статическими и динамическими сайтами. Большинство современных веб-сайтов являются динамическими - они хранят данные на сервере, используя какую-то базу данных (серверное хранилище), а затем запускают код на стороне сервера чтобы извлечь необходимые данные, вставить их в шаблоны статических страниц и передать полученный HTML-код клиенту для отображения в браузере пользователя.
+
+Хранилище на стороне клиента работает по схожим принципам, но используется по-другому. Оно состоит из API-интерфейсов JavaScript, которые позволяют вам хранить данные на клиенте (то есть на компьютере пользователя), а затем извлекать их при необходимости. Это имеет много разных применений, таких как:
+
+* Персонализация настроек сайта (например, отображение выбранных пользователем виджетов, цветовой схемы или размера шрифта).
+* Сохранение предыдущей активности на сайте (например, сохранение содержимого корзины покупок из предыдущего сеанса, запоминание, был ли пользователь ранее авторизован в системе).
+* Сохранение данных и ресурсов локально, так что сайт будет быстрее (и, возможно, экономичнее) загружаться или использоваться без подключения к сети.
+* Сохранение созданных веб-приложением документов локально для использования в автономном режиме.
+
+Часто, хранилища на сторонах клиента и сервера используются совместно. К примеру, вы должны загрузить из базы данных пакет музыкальных файлов для веб-игры, или музыкальный плеер хранит их в базе данных на стороне клиента, и воспроизводит по мере необходимости.
+
+Пользователь должен будет загрузить музыкальные файлы только один раз - при последующих посещениях они будут извлечены из локальной базы данных.
+
+**Старый подход: Cookie** (HTTP cookie, web cookie, internet cookie, browser cookie)
+
+**Куки** (англ. cookie, букв. - «печенье») - небольшой фрагмент данных, отправленный веб-сервером и хранимый на компьютере пользователя. Веб-клиент (обычно веб-браузер) всякий раз при попытке открыть страницу соответствующего сайта пересылает этот фрагмент данных веб-серверу в составе HTTP-запроса. Применяется для сохранения данных на стороне пользователя, на практике обычно используется для:
+
+* аутентификации пользователя;
+* хранения персональных предпочтений и настроек пользователя;
+* отслеживания состояния сеанса доступа пользователя;
+* сбора статистики о пользователях.
+
+Поддержки браузерами cookie (прием, сохранение и последующая пересылка серверу сохранённых cookie) требуют многие сайты с ограничениями доступа, большинство интернет-магазинов. Настройка оформления и поведения многих веб-сайтов по индивидуальным предпочтениям пользователя тоже основана на cookie.
+
+Cookie легко перехватить и подменить (например, для получения доступа к учетной записи), если пользователь использует нешифрованное соединение с сервером. В группе риска пользователи, выходящие в интернет при помощи публичных точек доступа Wi-Fi и не использующие при этом таких механизмов, как SSL и TLS. Шифрование позволяет также решить и другие проблемы, связанные с безопасностью передаваемых данных.
+
+Большинство современных браузеров позволяет пользователям выбрать - принимать cookie или нет, но их отключение делает невозможной работу с некоторыми сайтами. Кроме того, по законам некоторых стран (например, согласно постановлению Евросоюза от 2016 года, см. общий регламент по защите данных) сайты должны в обязательном порядке запрашивать согласие пользователя перед установкой cookie.
+
+**Назначение**
+
+Cookie используются веб-серверами для идентификации пользователей и хранения данных о них.
+
+К примеру, если вход на сайт осуществляется при помощи cookie, то, после ввода пользователем своих данных на странице входа, cookie позволяют серверу запомнить, что пользователь уже идентифицирован и ему разрешен доступ к соответствующим услугам и операциям.
+
+Многие сайты также используют cookie для сохранения настроек пользователя. Эти настройки могут использоваться для персонализации, которая включает в себя выбор оформления и функциональности. Например, Википедия позволяет авторизованным пользователям выбрать дизайн сайта. Поисковая система Google позволяет пользователям (в том числе и не зарегистрированным в ней) выбрать количество результатов поиска, отображаемых на одной странице.
+
+Cookie также используются для отслеживания действий пользователей на сайте. Как правило, это делается с целью сбора статистики, а рекламные компании на основе такой статистики формируют анонимные профили пользователей для более точного нацеливания рекламы
+
+**Типы cookie**
+
+* **Сессионные cookie**: Сессионные cookie, также известные как временные cookie, существуют только во временной памяти, пока пользователь находится на странице веб-сайта. Браузеры обычно удаляют сессионные cookie после того, как пользователь закрывает окно браузера. В отличие от других типов cookie, сессионные cookie не имеют истечения срока действия, и поэтому браузеры понимают их как сессионные.
+* **Постоянные cookie**: Вместо того, чтобы удаляться после закрытия браузера, как это делают сессионные cookie, постоянные cookie-файлы удаляются в определенную дату или через определённый промежуток времени. Это означает, что информация о cookie будет передаваться на сервер каждый раз, когда пользователь посещает веб-сайт, которому эти cookie принадлежат. По этой причине постоянные cookie иногда называются следящие cookie, поскольку они могут использоваться рекламодателями для записи о предпочтениях пользователя в течение длительного периода времени. Однако, они также могут использоваться и в «мирных» целях, например, чтобы избежать повторного ввода данных при каждом посещении сайта.
+* **Сторонние cookie**: Обычно атрибут домена cookie совпадает с доменом, который отображается в адресной строке веб-браузера. Это называется первый файл cookie. Однако сторонний файл cookie принадлежит домену, отличному от того, который указан в адресной строке. Этот тип файлов cookie обычно появляется, когда веб-страницы содержат контент с внешних веб-сайтов, например, рекламные баннеры. Это открывает возможности для отслеживания истории посещений пользователя и часто используется рекламодателями для предоставления релевантной рекламы каждому пользователю. В качестве примера предположим, что пользователь посещает www.example.org. Этот веб-сайт содержит рекламу от ad.foxytracking.com, которая при загрузке устанавливает файл cookie, принадлежащий домену рекламы (ad.foxytracking.com). Затем пользователь посещает другой веб-сайт www.foo.com, который также содержит рекламу от ad.foxytracking.com и устанавливает файл cookie, принадлежащий этому домену (ad.foxytracking.com). В конце концов, оба этих cookie будут отправлены рекламодателю при загрузке их рекламы или посещении их веб-сайта. Затем рекламодатель может использовать эти cookie для создания истории просмотров пользователя на всех веб-сайтах, на которых размещена реклама этого рекламодателя. По состоянию на 2014 год некоторые веб-сайты устанавливали cookie для чтения более чем на 100 сторонних доменах. В среднем на одном веб-сайте было установлено 10 файлов cookie, при этом максимальное количество файлов cookie (как для сторонних, так и для третьих сторон) может превышать 800. Большинство современных веб-браузеров содержит настройки конфиденциальности, которые могут блокировать сторонние cookie.
+* **Супер-cookie**: Супер-cookie - это cookie-файл с источником домена верхнего уровня (например, .ru) или общедоступным суффиксом (например, .co.uk). Обычные cookie, напротив, имеют происхождение от конкретного доменного имени, например example.com. Супер-cookie могут быть потенциальной проблемой безопасности и поэтому часто блокируются веб-браузерами. Если браузер разблокирует вредоносный веб-сайт, злоумышленник может установить супер-cookie и потенциально нарушить или выдать себя за законные запросы пользователей на другой веб-сайт, который использует тот же домен верхнего уровня или общедоступный суффикс, что и вредоносный веб-сайт. Например, супер-cookie с происхождением .com может злонамеренно повлиять на запрос к example.com, даже если файл cookie не был создан с сайта example.com. Это может быть использовано для подделки логинов или изменения информации пользователя. Публичный список суффиксов помогает снизить риск, который представляют супер-cookie. Публичный список суффиксов - это инициатива кросс-вендоров, целью которого является предоставление точного и актуального списка суффиксов доменных имен. В старых версиях браузеров может отсутствовать актуальный список, и поэтому они будут уязвимы для супер-cookie из определённых доменов. Термин «supercookie» (супер-cookie) иногда используется для отслеживания технологий, которые не используют файлы cookie HTTP. В августе 2011 года на веб-сайтах Microsoft были обнаружены два таких механизма «супер-cookie»: синхронизация файлов cookie, которая порождает cookie MUID (уникальный идентификатор машины), и cookie ETag. Из-за внимания средств массовой информации Microsoft позже отключила этот код.
+* **Зомби-cookie**: Поскольку cookie можно очень легко удалить из браузера, программисты ищут способы идентифицировать пользователей даже после полной очистки истории браузера. Одним из таких решений являются зомби-cookie (или evercookie, или persistent cookie) - неудаляемые или трудно удаляемые cookie, которые можно восстановить в браузере с помощью JavaScript. Это возможно потому, что для хранения куки сайт одновременно использует все доступные хранилища браузера (HTTP ETag, Session Storage, Local Storage, Indexed DB), в том числе и хранилища приложений, таких как Flash Player (Local Shared Objects), Microsoft Silverlight (Isolated Storage) и Java (Java persistence API). Когда программа обнаруживает отсутствие в браузере cookie-файла, информация о котором присутствует в других хранилищах, она тут же восстанавливает его на место и тем самым идентифицирует пользователя для сайта.
+
+**Работа cookie**
+
+Как и любой другой HTTP-заголовок, cookie должны передаваться в браузер до того, как будут переданы какие-либо другие данные, включая пустые строки и пробельные символы (это ограничение HTTP-протокола).
+
+Установка cookie: Запрашивая страницу, браузер отправляет веб-серверу короткий текст с HTTP-запросом. Например, для доступа к странице http://www.example.org/index.html браузер отправляет на сервер www.example.org следующий запрос:
+
+* GET /index.html HTTP/1.1
+* Host: www.example.org
+
+Сервер отвечает, отправляя запрашиваемую страницу вместе с текстом, содержащим HTTP-ответ. Там может содержаться указание браузеру сохранить cookie:
+
+* HTTP/1.1 200 OK
+* Content-type: text/html
+* Set-Cookie: name=value
+
+Строка Set-cookie отправляется лишь тогда, когда сервер желает, чтобы браузер сохранил cookie. В этом случае, если cookie поддерживаются браузером и их приём включен, браузер запоминает строку name=value (имя = значение) и отправляет её обратно серверу с каждым последующим запросом. Например, при запросе следующей страницы http://www.example.org/spec.html браузер пошлёт серверу www.examle.org следующий запрос:
+
+* GET /spec.html HTTP/1.1
+* Host: www.example.org
+* Cookie: name=value
+* Accept: _/_
+
+Этот запрос отличается от первого запроса тем, что содержит строку, которую сервер отправил браузеру ранее. Таким образом, сервер узна́ет, что этот запрос связан с предыдущим. Сервер отвечает, отправляя запрашиваемую страницу и, возможно, добавив новые cookie.
+
+Значение cookie может быть изменено сервером путем отправления новых строк Set-Cookie: name=new\_value. После этого браузер заменяет старое cookie с тем же name на новую строку.
+
+Cookie также могут устанавливаться программами на языках типа JavaScript, встроенными в текст страниц, или аналогичными скриптами, работающими в браузере. В JavaScript для этого используется свойство cookie объекта document - document.cookie. Например, document.cookie="temperature=20" создаст cookie под именем «temperature» и значением 20.
+
+**Аутентификация**
+
+Cookie могут использоваться сервером для опознания ранее аутентифицированных пользователей. Это происходит следующим образом:
+
+* Пользователь вводит имя пользователя и пароль в текстовых полях страницы входа и отправляет их на сервер.
+* Сервер получает имя пользователя и пароль, проверяет их и, при их правильности, отправляет страницу успешного входа, прикрепив cookie с неким идентификатором сессии. Эта cookie может быть действительна не только для текущей сессии браузера, но может быть настроена и на длительное хранение.
+* Каждый раз, когда пользователь запрашивает страницу с сервера, браузер автоматически отправляет cookie с идентификатором сессии серверу. Сервер проверяет идентификатор по своей базе идентификаторов и, при наличии в базе такого идентификатора, «узнаёт» пользователя.
+
+Этот метод широко используется на многих сайтах, например на Yahoo!, в Википедии и в Facebook'е.
+
+Многие браузеры (в частности Opera, FireFox) путём редактирования свойств cookie могут управлять поведением веб-сайтов. Изменив срок истечения непостоянных (сессионных) cookie, можно, например, получить формально-неограниченную сессию после авторизации на каком-либо сайте. Возможность редактирования cookie стандартными средствами отсутствует в Internet Explorer. Но, воспользовавшись иными механизмами, например, JavaScript, пользователь может изменить cookie-файл. Более того, существует возможность заменить сессионные cookie постоянными (с указанием срока годности).
+
+Однако серверное программное обеспечение может отслеживать такие попытки. Для этого сервер выдаёт cookie на определенный срок и записывает дату окончания cookie у себя или, в зашифрованном виде, в самих cookie, каждый раз, когда пользователь обращается к серверу. Если cookie, присланный браузером, имеет дату годности, отличную от той, что хранится на сервере или содержатся в cookie, значит, имеет место попытка подмены даты годности cookie. Сервер может отреагировать, например, запросив у пользователя повторную авторизацию.
+
+**Тестирование файлов cookie**
+
+Тестирование файлов cookie - это процесс проверки того, работают ли файлы cookie должным образом. При тестировании файлов cookie тестировщикам необходимо проверить статус файла cookie, срок действия файла cookie, доступность файла cookie, ограничения безопасности и т. д.
+
+**Пример чек-листа** для Cookie testing:
+
+* Файлы cookie корректно создаются на диске;
+* Поведение при отказе включить куки:
+ * Отображается ли соответствующее сообщение для Пользователей, чтобы включить файлы cookie для доступа к сайту?
+ * Есть ли обходной путь для доступа к сайту для браузеров с отключенными файлами cookie.
+* Работоспособность после удаления файлов cookie;
+* Работоспособность после повреждения (путем редактирования) файлов cookie и невозможность входа в систему после редактирования данных для входа;
+* Личные или конфиденциальные данные, хранящиеся в файле cookie, находятся в зашифрованном формате;
+* Кросс-браузерное тестирование файлов cookie;
+* Не должно быть чрезмерного использования файлов cookie.
+
+**Недостатки куки**
+
+Концепция хранения на стороне клиента существует уже давно. С первых дней Интернета, использовали cookies для хранения информации, чтобы персонализировать пользовательский опыт на веб-сайтах. Это самая ранняя форма хранилища на стороне клиента, обычно используемая в Интернете.
+
+Из-за этого возраста существует ряд проблем - как технических, так и с точки зрения пользовательского опыта - связанных с файлами cookie. Эти проблемы настолько значительны, что при первом посещении сайта людям, живущим в Европе, показываются сообщения, информирующие их о том, будут ли они использовать файлы cookie для хранения данных о них. Это связано с частью законодательства Европейского Союза, известного как EU Cookie directive.
+
+Они устарели, у них множество проблем с безопасностью, и они не способны хранить сложные данные. При этом существуют лучшие, более современные, способы хранения более широкого спектра данных на компьютере пользователя.
+
+Единственным преимуществом файлов cookie является то, что они поддерживаются очень старыми браузерами, поэтому, если ваш проект требует, чтобы вы поддерживали устаревшие браузеры (например, Internet Explorer 8 или более ранние версии), файлы cookie могут по-прежнему быть полезными, но для большинства проектов вы не нужно больше прибегать к ним.
+
+Почему по-прежнему создаются новые сайты с использованием файлов cookie? Это происходит главным образом из-за привычек разработчиков, использования старых библиотек, которые всё ещё используют куки-файлы, и наличия множества веб-сайтов, предоставляющих устаревшие справочные и учебные материалы для обучения хранению данных.
+
+**Новый подход: Web Storage и IndexedDB**
+
+Современные браузеры имеют гораздо более простые и эффективные API для хранения данных на стороне клиента, чем при использовании файлов cookie.
+
+* [**The Web Storage API**](https://developer.mozilla.org/ru/docs/Web/API/Web\_Storage\_API) обеспечивает очень простой синтаксис для хранения и извлечения данных, состоящих из пар 'ключ' : 'значение'. Это полезно, когда вам просто нужно сохранить некоторые простые данные, такие как имя пользователя, вошли ли они в систему, какой цвет использовать для фона экрана и т. д.
+* [**The IndexedDB API**](https://developer.mozilla.org/ru/docs/Web/API/IndexedDB\_API) обеспечивает браузер полной базой данных для хранения сложных данных. Это может быть использовано для хранения полных наборов записей клиентов и даже до сложных типов данных, таких как аудио или видео файлы.
+
+Интернет-хранилище упрощенно можно рассматривать как усовершенствование куки. Тем не менее, оно отличается от куки в некоторых ключевых направлениях:
+
+* Размер хранилища: интернет-хранилище поддерживает гораздо больше места на диске в сравнении с куки, которому доступно всего 4 Кбайта, что примерно в 1000 раз меньше чем у веб-хранилища (5 Мбайт на домен в Mozilla Firefox, Google Chrome, и Opera, и 10 Мбайт в Internet Explorer);
+* Интерфейс на стороне клиента: в отличие от куки, которые могут быть доступны как на сервере, так и на стороне клиента, веб-хранилище попадает исключительно под компетенцию сценариев (скриптов) на стороне клиента. Данные интернет-хранилища не передаются на сервер при каждом запросе HTTP, и веб-сервер не может напрямую записать в интернет-хранилище;
+* Локальное хранилище и Сессионное хранилище: интернет-хранилище предлагает две различных области: локальное хранилище и сессионное хранилище, которые различаются по своим объемам и времени жизни. Данные размещаются в отдельное для каждого домена локальное хранилище (оно доступно для всех скриптов из домена, который первоначально добавил данные) и сохраняются после закрытия браузера. Сессия сохраняется по принципу одна страница - одно окно и ограничивается жизнью данного окна, то есть для каждого открытого окна создается новая сессия, которая прекращает свое существование при закрытии окна и не зависит от домена, открывшего её. Сохранение сессии предназначено для предоставления отдельных экземпляров одного и того же веб-приложения для работы в разных окнах, не мешая друг другу. В случае с куки подобное становится крайне затруднительно или даже невозможно;
+* Интерфейс и модель данных: интернет-хранилище в настоящее время предоставляет программный интерфейс лучше, чем куки. Интерфейс представляет собой ассоциативный массив модели данных, где ключи и значения являются строками. Дополнительный API для доступа к структурированным данным на основе SQL находится на рассмотрении рабочей группы W3C.
+
+**Что нас ждёт в будущем: Cache API**
+
+Некоторые современные браузеры поддерживают новое [Cache API](https://developer.mozilla.org/ru/docs/Web/API/Cache). Этот API предназначен для хранения HTTP-ответов на конкретные запросы и очень полезен для таких вещей, как хранение ресурсов сайта в автономном режиме, чтобы впоследствии сайт можно было использовать без сетевого подключения. Cache обычно используется в сочетании с [Service Worker API](https://developer.mozilla.org/ru/docs/Web/API/Service\_Worker\_API), однако это не обязательно.
+
+Источники:
+
+* [Cookie](https://ru.wikipedia.org/wiki/Cookie)
+* [Learn Website Cookie Testing - Complete Guide](https://www.softwaretestingmaterial.com/website-cookie-testing/)
+* [Client-side storage](https://developer.mozilla.org/ru/docs/Learn/JavaScript/Client-side\_web\_APIs/Client-side\_storage)
+* [Web Storage](https://ru.wikipedia.org/wiki/Web\_Storage)
+
+Доп. материал:
+
+* [Плагины для тестирования файлов cookie](https://www.softwaretestingmaterial.com/website-cookie-testing/#:\~:text=the%20comments%20below.-,Plugins%20To%20Test%20Cookies,-%3A)
+* [«Осторожно, печеньки!»: советы начинающим тестировщикам в сфере безопасности](https://habr.com/ru/company/redmadrobot/blog/544198/)
+* [Cookies уходят. Да здравствует FLoC?](https://www.it-world.ru/it-news/tech/170330.html)
diff --git a/seti-i-okolo-nikh/klient-servernaya-arkhitektura-client-server-architecture.md b/seti-i-okolo-nikh/klient-servernaya-arkhitektura-client-server-architecture.md
new file mode 100644
index 0000000..ffd432a
--- /dev/null
+++ b/seti-i-okolo-nikh/klient-servernaya-arkhitektura-client-server-architecture.md
@@ -0,0 +1,132 @@
+# Клиент - серверная архитектура (Client-Server Architecture)
+
+**Клиент - сервер** - вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Фактически клиент и сервер - это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на одной машине. Программы-серверы ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде:
+
+* данных (например, загрузка файлов посредством HTTP, FTP, BitTorrent, потоковое мультимедиа или работа с базами данных);
+* сервисных функций (например, работа с электронной почтой, общение посредством систем мгновенного обмена сообщениями или просмотр web-страниц во всемирной паутине).
+
+Поскольку одна программа-сервер может выполнять запросы от множества программ-клиентов, ее размещают на специально выделенной вычислительной машине, настроенной особым образом, как правило, совместно с другими программами-серверами, поэтому производительность этой машины должна быть высокой. Из-за особой роли такой машины в сети, специфики ее оборудования и программного обеспечения, её также называют сервером, а машины, выполняющие клиентские программы, соответственно, клиентами.
+
+Архитектуру «клиент-сервер» принято разделять на три класса: одно-, двух- и трехуровневую. Однако, нельзя сказать, что в вопросе о таком разделении в сообществе ИТ-специалистов существует полный консенсус. Многие называют одноуровневую архитектуру двухуровневой и наоборот, то же можно сказать о соотношении двух- и трёхуровневой архитектур.
+
+**Одноуровневая архитектура (1-Tier)**
+
+Одноуровневая архитектура «клиент-сервер» (1-Tier) - такая, где все прикладные программы рассредоточены по рабочим станциям, которые обращаются к общему серверу баз данных или к общему файловому серверу. Никаких прикладных программ сервер при этом не исполняет, только предоставляет данные.
+
+В целом, такая архитектура очень надежна, однако, ей сложно управлять, поскольку в каждой рабочей станции данные будут присутствовать в разных вариантах. Поэтому возникает проблема их синхронизации на отдельных машинах. В общем, как можно видеть из рисунка, в этой архитектуре просматривается еще один уровень - базы данных, что дает повод во многих случаях называть её двухуровневой.
+
+**Двухуровневая архитектура (2-Tier)**
+
+К двухуровневой архитектуре «клиент-сервер» следует относить такую, в которой прикладные программы сосредоточены на сервере приложений (Application Server), например, сервере 1С или сервере CRM, а в рабочих станциях находятся программы-клиенты, которые предоставляют для пользователей интерфейс для работы с приложениями на общем сервере.
+
+Такая архитектура представляется наиболее логичной для архитектуры «клиент-сервер». В ней, однако, можно выделить два варианта. Когда общие данные хранятся на сервере, а логика их обработки и бизнес-данные хранятся на клиентской машине, то такая архитектура носит название “fat client thin server” (толстый клиент, тонкий сервер). Когда не только данные, но и логика их обработки и бизнес-данные хранятся на сервере, то это называется “thin client fat server” (тонкий клиент, толстый сервер). Такая архитектура послужила прообразом облачных вычислений (Cloud Computing).
+
+**Трехуровневая архитектура (3-Tier)**
+
+В трехуровневой архитектуре сервер баз данных, файловый сервер и другие представляют собой отдельный уровень, результаты работы которого использует сервер приложений. Логика данных и бизнес-логика находятся в сервере приложений. Все обращения клиентов к базе данных происходят через промежуточное программное обеспечение (middleware), которое находится на сервере приложений. Вследствие этого, повышается гибкость работы и производительность.
+
+
+
+**Многоуровневая архитектура (N-Tier)**
+
+В отдельный класс архитектуры «клиент-сервер» можно вынести многоуровневую архитектуру, в которой несколько серверов приложений используют результаты работы друг друга, а также данные от различных серверов баз данных, файловых серверов и других видов серверов.
+
+По сути, предыдущий вариант, трехуровневая архитектура - не более, чем частный случай многоуровневой архитектуры.
+
+Преимуществом многоуровневой архитектуры является гибкость предоставления услуг, которые могут являться комбинацией работы различных приложений серверов разных уровней и элементов этих приложений.
+
+Очевидным недостатком является сложность, многокомпонентность такой архитектуры.
+
+**Характеристики архитектуры «клиент-сервер»**
+
+* Асимметричность протоколов. Между клиентами и сервером существуют отношения «один ко многим». Инициатором диалога с сервером обычно является клиент.
+* Инкапсуляция услуг. После получения запроса на услугу от клиента, сервер решает, как должна быть выполнена данная услуга. Модификация («апгрейд») сервера может производиться без влияния на работу клиентов, поскольку это не влияет на опубликованный интерфейс взаимодействия между ними. Иными словами, максимум, что может при этом почувствовать пользователь - незначительная задержка отклика сервера в течение небольшого времени апгрейда.
+* Целостность. Программы и общие данные для сервера управляются централизованно, что снижает стоимость обслуживания и защищает целостность данных. В то же время, данные клиентов остаются персонифицированными и независимыми.
+* Местная прозрачность. Сервер - это программный процесс, который может исполняться на той же машине, что и клиент, либо на другой машине, подключенной по сети. Программное обеспечение «клиент-сервер» обычно скрывает местоположение сервера от клиентов, перенаправляя запрос на услуги через сеть.
+* Обмен на основе сообщений. Клиенты и сервер являются нежёстко связанными («loosely-coupled») процессами, которые обмениваются сообщениями: запросами на услуги и ответами на них.
+* Модульный дизайн, способный к расширению. Модульный дизайн программной платформы «клиент-сервер» придаёт ей устойчивость к отказам, то есть, отказ в каком-то модуле не вызывает отказа всего приложения. В такой системе, один или больше серверов могут отказать без остановки всей системы в целом, до тех пор, пока услуги отказавшего сервера могут быть предоставлены с резервного сервера. Другое преимущество модульности в том, что приложение «клиент-сервер» может автоматически реагировать на повышение или понижение нагрузки на систему, путем добавления или отключения услуг или серверов.
+* Независимость от платформы. Идеальное приложение «клиент-сервер» не зависит от платформ оборудования или операционной системы. Клиенты и серверы могут развертываться на различных аппаратных платформах и разных операционных системах.
+* Масштабируемость. Системы «клиент-сервер» могут масштабироваться как горизонтально (по числу серверов и клиентов), так и вертикально (по производительности и спектру услуг).
+* Разделение функционала. Система «клиент-сервер» - это соотношение между процессами, работающими на одной или на разных машинах. Сервер - это процесс предоставления услуг. Клиент - это потребитель услуг.
+* Общее использование ресурсов. Один сервер может предоставлять услуги множеству клиентов одновременно, и регулировать их доступ к совместно используемым ресурсам.
+
+**Практические применения архитектуры «клиент-сервер»**
+
+Архитектура «клиент-сервер» - один из основных принципов работы сети Интернет. Любой веб-сайт, или приложение в Интернет работает на сервере, а его пользователи являются клиентами. Социальные сети (Фейсбук, ВК и пр.), сайты электронной коммерции (Amazon, Озон и др.) , мобильные приложения (Instagram и т.д.), устройства Интернета вещей (умные колонки или смарт-часы) работают на основе клиент-серверной архитектуры.
+
+Хорошим примером работы системы «клиент-сервер» является автомобильный навигатор. Приложение навигации на сервере собирает данные с многих смартфонов пользователей, на которых установлены клиенты приложения. Кроме того, приложение навигации использует ещё и данные с сервера базы данных - геоинформационной системы, который предоставляет данные, например, о текущих ремонтах дорог, о появлении новых дорог и пр. Данные со многих клиентов (местоположение, скорость) обрабатывается сервером навигации и выдаётся на смартфоны пользователей в виде информации о средней скорости движения по тому или иному участку маршрута.
+
+Практически любая корпоративная сеть или ИТ-система предприятия, как правило, строится по архитектуре «клиент-сервер». В небольших сетях (3-5 компьютеров в компании) функции сервера может выполнять один из рабочих компьютеров. Если число машин в организации более 10, то лучше сделать выделенный сервер (почтовый сервер, приложений, баз данных и пр.), который будет заниматься обслуживанием клиентов - компьютеров и телефонов сотрудников организации.
+
+В домашних сетях архитектура «клиент-сервер» тоже используется довольно часто. Например, в домашнюю сеть могут быть объединены компьютеры членов семьи, один из которых выполняет функции сервера. В домашнюю сеть также могут быть включены такие устройства, как умные колонки, умные домашние устройства (пылесосы-роботы, фотоаппараты, DVD-плееры и пр.), а также «умные» счётчики (вода, электричество) и т.д. Тогда в системе управления сервера, будут видны все параметры, данные и медиа файлы (музыка, видео, фото), а также «умные устройства».
+
+В настоящее время можно встретить термин Serverless Architecture, т.н. «бессерверная архитектура». Однако, по сути, она представляет собой процесс получения функций сервера в виде облачной услуги. То есть, серверы в облаке тоже есть, но для конечного пользователя они не видны, и он получает их сервисы в виде абстрактной «функции как услуги» FaaS (Function as a Service).
+
+Архитектура «клиент-сервер» является основой большинства корпоративных сетей и берет свое начало от самых первых вычислительных машин, т.н. «мэйнфреймов».
+
+_Примечание. Можно встретить такие понятия:_
+
+* _“Толстый” клиент: на сервере реализованы главным образом функции доступа к базам данных, а основные прикладные вычисления выполняются на стороне клиента;_
+* _“Тонкий клиент”: на сервере выполняется основная часть прикладной обработки данных, а на клиентские рабочие станции передаются уже результаты обработки данных для просмотра и анализа пользователем с возможностью их последующей обработки (в минимальном объеме)._
+* _“Горячий/теплый” клиент: с кэшем и куками;_
+* _“Холодный” клиент: чистый, без или очищеный от кук и кэша._
+
+**Статические и динамические сайты**
+
+**Статический сайт** - это тот, который возвращает тот же жёсткий кодированный контент с сервера всякий раз, когда запрашивается конкретный ресурс. Например, если у вас есть страница о товаре в /static/myproduct1.html, эта же страница будет возвращена каждому пользователю. Если вы добавите еще один подобный товар на свой сайт, вам нужно будет добавить ещё одну страницу (например, myproduct2.html) и так далее. Это может стать действительно неэффективным - что происходит, когда вы попадаете на тысячи страниц товаров? Вы повторяли бы много кода на каждой странице (основной шаблон страницы, структуру и т. д.), И если бы вы захотели изменить что-либо в структуре страницы - например, добавить новый раздел «связанные товары» - тогда вам придётся менять каждую страницу отдельно.
+
+На заметку: Статические сайты превосходны, когда у вас небольшое количество страниц и вы хотите отправить один и тот же контент каждому пользователю. Однако их обслуживание может потребовать значительных затрат по мере увеличения количества страниц.
+
+
+
+Когда пользователь хочет перейти на страницу, браузер отправляет HTTP-запрос GET с указанием URL-адреса его HTML-страницы. Сервер извлекает запрошенный документ из своей файловой системы и возвращает HTTP-ответ, содержащий документ и код состояния HTTP Response status code 200 OK (успех). Сервер может вернуть другой код состояния, например, «404 Not Found», если файл отсутствует на сервере или «301 Moved Permanently», если файл существует, но был перемещён в другое место.
+
+Серверу для статического сайта нужно будет только обрабатывать GET-запросы, потому что сервер не сохраняет никаких модифицируемых данных. Он также не изменяет свои ответы на основе данных HTTP-запроса (например, URL-параметров или файлов cookie).
+
+Понимание того, как работают статические сайты, тем не менее полезно при изучении программирования на стороне сервера, поскольку динамические сайты точно так же обрабатывают запросы для статических файлов (CSS, JavaScript, статические изображения и т. д.).
+
+**Динамический сайт** - это тот, который может генерировать и возвращать контент на основе конкретного URL-адреса запроса и данных (а не всегда возвращать один и тот же жёсткий код для определенного URL-адреса). Используя пример сайта товара, сервер будет хранить «данные» товара в базе данных, а не отдельные HTML-файлы. При получении GET-запроса для товара сервер определяет идентификатор товара, извлекает данные из базы данных и затем создает HTML-страницу для ответа, вставляя данные в HTML-шаблон. Это имеет большие преимущества перед статическим сайтом:
+
+* Использование базы данных позволяет эффективно хранить информацию о товаре с помощью легко расширяемого, изменяемого и доступного для поиска способа.
+* Использование HTML-шаблонов позволяет очень легко изменить структуру HTML, потому что это нужно делать только в одном месте, в одном шаблоне, а не через потенциально тысячи статических страниц.
+
+**Анатомия динамического запроса**: чтобы не отдаляться от практики, мы будем использовать контекст веб-сайта менеджера спортивной команды, где тренер может выбрать имя своей команды и размер команды в HTML-форме и вернуться к предлагаемому «лучшему составу» для своей следующей игры.
+
+На приведённой ниже диаграмме показаны основные элементы веб-сайта «team coach», а также пронумерованные ярлыки для последовательности операций, когда тренер обращается к списку «лучших команд». Частями сайта, которые делают его динамичным, являются веб-приложение (так мы будем ссылаться на серверный код, обрабатывающий HTTP-запросы и возвращающие HTTP-ответы), база данных, которая содержит информацию об игроках, командах, тренерах и их отношениях, и HTML-шаблоны.
+
+
+
+После того, как тренер отправит форму с именем команды и количеством игроков, последовательность операций будет следующей:
+
+1. Веб-браузер отправит HTTP-запрос GET на сервер с использованием базового URL-адреса ресурса (/best) и кодирования номера команды и игрока в форме URL-параметров (например, /best?team=my\_team\_name\&show=11) или как часть URL-адреса (например, /best/my\_team\_name/11/). Запрос GET используется, потому что речь идёт только о запросе выборки данных (а не об их изменении).
+2. Веб-сервер определяет, что запрос является «динамическим» и пересылает его в веб-приложение для обработки (веб-сервер определяет, как обрабатывать разные URL-адреса на основе правил сопоставления шаблонов, определённых в его конфигурации).
+3. Веб-приложение определяет, что цель запроса состоит в том, чтобы получить «лучший список команд» на основе URL (/best/) и узнать имя команды и количество игроков из URL-адреса. Затем веб-приложение получает требуемую информацию из базы данных (используя дополнительные «внутренние» параметры, чтобы определить, какие игроки являются «лучшими», и, возможно, определяя личность зарегистрированного тренера из файла cookie на стороне клиента).
+4. Веб-приложение динамически создаёт HTML-страницу, помещая данные (из базы данных) в заполнители внутри HTML-шаблона.
+5. Веб-приложение возвращает сгенерированный HTML в веб-браузер (через веб-сервер) вместе с кодом состояния HTTP 200 («успех»). Если что-либо препятствует возврату HTML, веб-приложение вернёт другой код, например, «404», чтобы указать, что команда не существует.
+6. Затем веб-браузер начнёт обрабатывать возвращённый HTML, отправив отдельные запросы, чтобы получить любые другие файлы CSS или JavaScript, на которые он ссылается (см. шаг 7).
+7. Веб-сервер загружает статические файлы из файловой системы и возвращает их непосредственно в браузер (опять же, правильная обработка файлов основана на правилах конфигурации и сопоставлении шаблонов URL).
+
+Операция по обновлению записи в базе данных будет обрабатываться аналогичным образом, за исключением того, что, как и любое обновление базы данных, HTTP-запрос из браузера должен быть закодирован как запрос POST.
+
+**Выполнение другой работы**: задача веб-приложения - получать HTTP-запросы и возвращать HTTP-ответы. Хотя взаимодействие с базой данных для получения или обновления информации является очень распространённой задачей, код может делать другие вещи одновременно или вообще не взаимодействовать с базой данных.
+
+Хорошим примером дополнительной задачи, которую может выполнять веб-приложение, является отправка электронной почты пользователям для подтверждения их регистрации на сайте. Сайт также может выполнять протоколирование или другие операции.
+
+**Возвращение чего-то другого, кроме HTML**: серверный код сайта может возвращать не только HTML-фрагменты и файлы в ответе. Он может динамически создавать и возвращать другие типы файлов (текст, PDF, CSV и т. д.) или даже данные (JSON, XML и т. д.).
+
+Идея вернуть данные в веб-браузер, чтобы он мог динамически обновлять свой собственный контент (AJAX) существует довольно давно. Совсем недавно «Одностраничные приложения» стали популярными, где весь сайт написан с одним HTML-файлом, который динамически обновляется по мере необходимости. Веб-сайты, созданные с использованием приложений такого рода, переносят большие вычислительные затраты с сервера на веб-браузер и приводят к тому, что веб-сайты, ведут себя больше как нативные приложения (очень отзывчивые и т. д.).
+
+Источники:
+
+* [Клиент - сервер](https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B8%D0%B5%D0%BD%D1%82\_%E2%80%94\_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80)
+* [Архитектура «Клиент-Сервер»](https://itelon.ru/blog/arkhitektura-klient-server/)
+* [Клиент-сервер](https://developer.mozilla.org/ru/docs/Learn/Server-side/First\_steps/Client-Server\_overview)
+
+Доп. материал:
+
+* [Computer Networking Tutorial: The Ultimate Guide](https://www.softwaretestinghelp.com/computer-networking-basics/)
+* [Web Server vs. Application Server](https://www.ibm.com/cloud/learn/web-server-vs-application-server)
+* [Что такое сервер приложения](https://www.software-testing.ru/library/testing/testing-for-beginners/3771-what-is-an-application-server)
+* [Клиент-серверная архитектура в картинках](https://www.youtube.com/watch?v=wLHuviTWnuY\&t=873s)
+* [Тестировщик с нуля / Урок 11. Клиент-серверная архитектура. Веб-сайт, веб-приложение и веб-сервис](https://www.youtube.com/watch?v=00z-6hyIvG0\&t=743s)
+* [Клиент-серверная архитектура](https://www.youtube.com/watch?v=RBml4tRP500\&t=1370s)
diff --git a/seti-i-okolo-nikh/mikroservisnaya-arkhitektura-microservice-architecture.md b/seti-i-okolo-nikh/mikroservisnaya-arkhitektura-microservice-architecture.md
new file mode 100644
index 0000000..7d071b9
--- /dev/null
+++ b/seti-i-okolo-nikh/mikroservisnaya-arkhitektura-microservice-architecture.md
@@ -0,0 +1,37 @@
+# Микросервисная архитектура (Microservice Architecture)
+
+Микросервисная архитектура или просто микросервисы - это особый метод разработки программных систем, который пытается сосредоточиться на создании однофункциональных модулей с четко определенными интерфейсами и операциями. Эта тенденция стала популярной в последние годы, поскольку предприятия стремятся стать более гибкими и перейти к DevOps и непрерывному тестированию.
+
+
+
+
+
+Микросервисы имеют множество преимуществ для Agile- и DevOps-команд - как отмечает Мартин Фаулер, Netflix, eBay, Amazon, Twitter, PayPal и другие звезды технологий перешли от монолитной к микросервисной архитектуре. В отличие от микросервисов монолитное приложение строится как единая автономная единица. Это замедляет внесение изменений в приложение, поскольку влияет на всю систему. Модификация, внесенная в небольшой участок кода, может потребовать создания и развертывания совершенно новой версии программного обеспечения. Масштабирование определенных функций приложения также означает, что вам необходимо масштабировать все приложение. Микросервисы решают эти проблемы монолитных систем, будучи максимально модульными. В простейшей форме они помогают создать приложение в виде набора небольших служб, каждая из которых работает в своем собственном процессе и развертывается независимо. Эти сервисы могут быть написаны на разных языках программирования и могут использовать разные методы хранения данных. Хотя это приводит к разработке систем, которые являются масштабируемыми и гибкими, они нуждаются в динамическом преобразовании. Микросервисы часто подключаются через API и могут использовать многие из тех же инструментов и решений, которые выросли в экосистеме RESTful и веб-сервисов. Тестирование этих API может помочь проверить поток данных и информации во время развертывания микросервиса.
+
+Точно так же, как не существует формального определения термина «микросервисы», нет и стандартной модели, которую вы увидите представленной в каждой системе, основанной на этом архитектурном стиле. Но вы можете ожидать, что большинство микросервисных систем будут иметь несколько примечательных характеристик:
+
+1. **Мультикомпонентные**: Программное обеспечение, созданное как микрослужбы, по определению может быть разбито на несколько составных служб. Почему? Таким образом каждую из этих служб можно развертывать, настраивать, а затем повторно развертывать независимо друг от друга без ущерба для целостности приложения. В результате вам может потребоваться изменить только одну или несколько отдельных служб вместо повторного развертывания целых приложений. Но у этого подхода есть свои недостатки, в том числе дорогостоящие удаленные вызовы (вместо вызовов внутри процесса), более грубые удаленные API и повышенная сложность при перераспределении обязанностей между компонентами;
+2. **Созданы для бизнеса**: Стиль микросервисов обычно организован вокруг бизнес-возможностей и приоритетов. В отличие от традиционного монолитного подхода к разработке, когда разные команды уделяют особое внимание, скажем, пользовательскому интерфейсу, базам данных, технологическим уровням или логике на стороне сервера, в микросервисной архитектуре используются кроссфункциональные команды. В обязанности каждой команды входит создание конкретных продуктов на основе одного или нескольких отдельных сервисов, взаимодействующих через шину сообщений. В микросервисах команда владеет продуктом всю жизнь, как в часто цитируемой максиме Amazon: “[Вы создаете это, вы это запускаете](https://www.strehle.de/tim/weblog/archives/2010/11/09/1320)”;
+3. **Простая маршрутизация**: Микросервисы действуют примерно так же, как классическая система UNIX: они получают запросы, обрабатывают их и генерируют соответствующий ответ. Это противоположно тому, как работают многие другие продукты, такие как ESB (Enterprise Service Buses), где используются высокотехнологичные системы для маршрутизации сообщений, хореографии и применения бизнес-правил. Можно сказать, что у микросервисов есть интеллектуальные конечные точки (endpoints), которые обрабатывают информацию и применяют логику, и тупые каналы (?dumb pipes), по которым информация течет;
+4. **Децентрализованные**: Поскольку микросервисы включают множество технологий и платформ, старые методы централизованного управления не являются оптимальными. Сообщество микросервисов предпочитает децентрализованное управление, потому что его разработчики стремятся создавать полезные инструменты, которые затем могут использоваться другими для решения тех же проблем. Как и децентрализованное управление, микросервисная архитектура также способствует децентрализованному управлению данными. Монолитные системы используют одну логическую базу данных для разных приложений. В микросервисном приложении каждая служба обычно управляет своей уникальной базой данных;
+5. **Отказоустойчивость**: Как всесторонне развитый ребенок, микросервисы созданы, чтобы справляться с ошибками. Поскольку несколько уникальных и разнообразных сервисов взаимодействуют друг с другом, вполне возможно, что сервис может выйти из строя по той или иной причине (например, когда поставщик недоступен). В этих случаях клиент должен позволить своим соседним службам работать, пока он отключается. Однако мониторинг микросервисов может помочь предотвратить риск сбоя. По понятным причинам это требование делает микросервисы более сложными по сравнению с архитектурой монолитных систем;
+6. **Эволюционные**: Архитектура микросервисов представляет собой эволюционный дизайн и, опять же, идеально подходит для эволюционирующих систем, в которых вы не можете полностью предвидеть типы устройств, которые однажды могут получить доступ к вашему приложению. , можно постепенно преобразовать в микросервисы, взаимодействующие с более старой монолитной архитектурой через API.
+
+**Примеры**
+
+Netflix имеет широко распространенную архитектуру, которая превратилась из монолитной в SOA. Каждый день он получает более одного миллиарда вызовов с более чем 800 различных типов устройств на свой API потокового видео. Затем каждый вызов API запрашивает около пяти дополнительных вызовов серверной службы. Amazon также перешел на микросервисы. Они получают бесчисленное количество вызовов из различных приложений, включая приложения, которые управляют API веб-службы, а также самим веб-сайтом, которые были бы просто невозможны для их старой двухуровневой архитектуры. Аукционный сайт eBay - еще один пример, прошедший тот же переход. Их основное приложение состоит из нескольких автономных приложений, каждое из которых выполняет бизнес-логику для различных функциональных областей.
+
+**SOA vs. Microservices**
+
+«Погодите-ка, - могут бормотать некоторые из вас за утренним кофе, - разве это не просто другое название SOA?» Сервис-ориентированная архитектура (SOA), возникшая в первые несколько лет этого века, и микросервисная архитектура (сокращенно MSA) имеют ряд общих черт. Однако традиционная SOA представляет собой более широкую структуру и может означать самые разные вещи. Некоторые сторонники микросервисов вообще отвергают тег SOA, в то время как другие считают микросервисы просто идеальной, усовершенствованной формой SOA. В любом случае, мы считаем, что существует достаточно четких различий, чтобы оправдать отдельную концепцию «микросервиса» (по крайней мере, как особую форму SOA, как мы проиллюстрируем позже). Типичная модель SOA, например, обычно имеет более зависимые ESB, а микросервисы используют более быстрые механизмы обмена сообщениями. SOA также ориентирована на императивное программирование, тогда как архитектура микросервисов ориентирована на стиль программирования с гибким субъектом. Кроме того, модели SOA, как правило, имеют реляционную базу данных слишком большого размера, в то время как микросервисы часто используют базы данных NoSQL или micro-SQL (которые могут быть подключены к обычным базам данных). Но реальная разница в первую очередь связана с методами архитектуры, используемыми для получения интегрированного набора сервисов. Поскольку в цифровом мире все меняется, гибкие методы разработки, которые могут идти в ногу с требованиями эволюции программного обеспечения, бесценны. Большинство методов, используемых в архитектуре микросервисов, исходят от разработчиков, которые создавали программные приложения для крупных корпоративных организаций и знают, что сегодняшние конечные пользователи ожидают динамичного, но согласованного взаимодействия на самых разных устройствах. Масштабируемые, адаптируемые, модульные и быстродоступные облачные приложения пользуются большим спросом. И это заставило многих разработчиков изменить свой подход.
+
+Источники:
+
+* [What is Microservices?](https://smartbear.com/solutions/microservices/)
+
+Доп. материал:
+
+* [Современная Микросервисная архитектура в банковской сфере](https://www.youtube.com/watch?v=xEsLHjAPtok)
+* [Microservices](https://martinfowler.com/articles/microservices.html)
+* [Pattern: Microservice Architecture](https://microservices.io/patterns/microservices.html)
+* [Microservices vs Monolith](https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/)
diff --git a/seti-i-okolo-nikh/rendering-v-internete-rendering-on-the-web.md b/seti-i-okolo-nikh/rendering-v-internete-rendering-on-the-web.md
new file mode 100644
index 0000000..a5e33b9
--- /dev/null
+++ b/seti-i-okolo-nikh/rendering-v-internete-rendering-on-the-web.md
@@ -0,0 +1,165 @@
+# Рендеринг в интернете (Rendering on the Web)
+
+Одно из основных решений, которые должны принять веб-разработчики, - это где реализовать логику и рендеринг в своих приложениях. Это может быть сложно, так как существует несколько разных способов создания сайта.
+
+**Терминология**
+
+* **SSR**: рендеринг на стороне сервера - рендеринг клиентского или универсального приложения в HTML на сервере;
+* **CSR**: рендеринг на стороне клиента - рендеринг приложения в браузере, обычно с использованием DOM;
+* Регидратация (**Rehydration**): «загрузка» представлений JavaScript на клиенте так, чтобы они повторно использовали дерево DOM и данные HTML, представленные сервером;
+* Предварительный рендеринг (**Prerendering**): запуск приложения на стороне клиента во время сборки для захвата его исходного состояния в виде статического HTML;
+* **TTFB**: время до первого байта - рассматривается как время между нажатием на ссылку и первым поступающим контентом;
+* **FP**: First Paint - первый раз, когда любой пиксель становится видимым для пользователя;
+* **FCP**: First Contentful Paint - время, когда запрашиваемый контент (тело статьи и т. д.) Становится видимым;
+* **TTI**: Time To Interactive - время, когда страница становится интерактивной (события подключены и т. д.).
+
+**Серверный рендеринг**
+
+Серверный рендеринг генерирует полный HTML для страницы на сервере в ответ на навигацию. Это позволяет избежать дополнительных циклов обработки данных и шаблонов на клиенте, поскольку они обрабатываются до того, как браузер получает ответ.
+
+Серверный рендеринг обычно производит быструю First Paint и First Contentful Paint. Выполнение логики страницы и рендеринга на сервере позволяет избежать отправки большого количества JavaScript клиенту, что помогает быстро достичь Time to Interactive. Это имеет смысл, поскольку при серверном рендеринге вы просто отправляете текст и ссылки в браузер пользователя. Этот подход может хорошо работать для широкого спектра устройств и условий сети, и открывает интересные оптимизации браузера, такие как потоковый анализ документов.
+
+
+
+При использовании серверного рендеринга пользователи вряд ли будут ждать, пока обработается привязанный к процессору JavaScript, прежде чем они смогут использовать ваш сайт. Даже когда нельзя избежать стороннего JS, использование серверного рендеринга для сокращения собственных затрат на JS может дать вам больше « бюджета » на все остальное. Однако у этого подхода есть один главный недостаток: генерация страниц на сервере требует времени, что часто может привести к более долгому времени до первого байта.
+
+Достаточно ли серверного рендеринга для вашего приложения, во многом зависит от него самого. Существует давняя дискуссия о правильном применении серверного рендеринга по сравнению с рендерингом на стороне клиента, но важно помнить, что вы можете использовать серверный рендеринг для одних страниц, а не для других нет. Некоторые сайты успешно применяют гибридные методы рендеринга. Сервер Netflix отображает свои относительно статичные целевые страницы, предварительно выбирая JS для страниц с интенсивным взаимодействием, предоставляя этим более тяжелым страницам, отображаемым клиентом, более высокую вероятность быстрой загрузки.
+
+Многие современные фреймворки, библиотеки и архитектуры позволяют отображать одно и то же приложение как на клиенте, так и на сервере. Эти методы могут использоваться для серверного рендеринга, однако важно отметить, что архитектуры, в которых рендеринг происходит как на сервере, так и на клиенте, представляют собой собственный класс решений с очень разными характеристиками производительности и компромиссами. Пользователи React могут использовать renderToString() или решения, построенные на его основе, такие как Next.js, для серверного рендеринга. Пользователи Vue могут взглянуть на руководство по серверному рендерингу Vue или Nuxt. Angular имеет Universal. В большинстве популярных решений используется некоторая форма гидратации, поэтому перед выбором инструмента ознакомьтесь с подходом, который используется.
+
+**Статический рендеринг**
+
+Статический рендеринг происходит во время сборки и предлагает быстрые First Paint, First Contentful Paint и Time To Interactive - при условии, что количество JS на стороне клиента ограничено. В отличие от серверного рендеринга, ему также удается достичь стабильно быстрого времени до первого байта, поскольку HTML-код для страницы не нужно генерировать на лету. Как правило, статический рендеринг означает создание отдельного HTML-файла для каждого URL-адреса заранее. Поскольку HTML-ответы генерируются заранее, статические рендеры могут быть развернуты на нескольких CDN, чтобы воспользоваться преимуществом пограничного кэширования (edge-caching).
+
+
+
+Решения для статического рендеринга бывают всех форм и размеров. Такие инструменты как Gatsby спроектированы так, чтобы разработчики почувствовали что их приложения рендерятся динамически быстрее чем генерируются на этапе сборки. Другие, как Jekyll и Metalsmith принимают их статическую природу, обеспечивая более шаблонный подход.
+
+Одним из недостатков статического рендеринга является то, что отдельные HTML-файлы должны создаваться для каждого возможного URL. Это может быть сложно или даже невозможно, если вы не можете предсказать, какие будут эти URL-адреса раньше времени, или для сайтов с большим количеством уникальных страниц.
+
+Пользователи React могут быть знакомы с Gatsby , статическим экспортом Next.js или Navi - все это делает его удобным для автора с использованием компонентов. Тем не менее, важно понимать разницу между статическим рендерингом и предварительным рендерингом: статические рендеринг страниц являются интерактивными без необходимости выполнения большого количества JS на стороне клиента, тогда как предварительный рендеринг улучшает First Paint или First Contentful Paint одностраничного приложения (SPA), которое необходимо загрузить клиент для того, чтобы страницы были по-настоящему интерактивными.
+
+Если вы не уверены, является ли данное решение статическим или предварительным рендерингом, попробуйте этот тест: отключите JavaScript и загрузите созданные веб-страницы. Для статически визуализированных страниц большая часть функциональности будет по-прежнему существовать без включенного JavaScript. Для предварительно обработанных страниц могут существовать некоторые базовые функции, такие как ссылки, но большая часть страницы будет инертной.
+
+Еще один полезный тест - замедление работы сети с помощью Chrome DevTools и наблюдение за загрузкой JavaScript до того, как страница станет интерактивной. Для предварительного рендеринга обычно требуется больше JavaScript, чтобы стать интерактивным, и этот JavaScript имеет тенденцию быть более сложным, чем подход прогрессивного улучшения, используемый при статическом рендеринге.
+
+**Серверный Рендеринг против Статического Рендеринга**
+
+Серверный Рендеринг не является серебряной пулей - его динамическая природа может сопровождаться значительными вычислительными накладными расходами. Многие решения для рендеринга серверов не сбрасываются рано, могут задержать TTFB или удвоить отправку данных (например, встроенное состояние, используемое JS на клиенте). В React, функция renderToString() может быть медленной, поскольку она является синхронной и однопоточной. Получение серверным рендерингом «права» может включать в себя нахождение или создание решения для компонентов кэширования , управление потреблением памяти, применение техник мемоизации, и многие другие проблемы. Обычно вы обрабатываете / перестраиваете одно и то же приложение несколько раз - один раз на клиенте и один раз на сервере. Тот факт, что при рендеринге с сервера может появиться что-то раньше, не означает, что у вас меньше работы.
+
+Серверный рендеринг генерирует HTML по требованию для каждого URL, но может быть медленнее, чем просто обслуживание статического рендеринга контента. Если вы можете добавить дополнительную работу, серверный рендеринг + кэширование HTML может значительно сократить время серверного рендеринга. Преимуществом рендеринга на сервере является возможность извлекать больше «живых» данных и отвечать на более полный набор запросов, чем это возможно при статическом рендеринге. Страницы, требующие персонализации, являются конкретным примером типа запроса, который не будет хорошо работать при статическом рендеринге.
+
+Серверный рендеринг также может представлять интересные решения при построении [PWA](https://web.dev/progressive-web-apps/). Лучше использовать полностраничное сервис-воркер ([service-worker](https://developers.google.com/web/fundamentals/primers/service-workers/?hl=ru)) кэширование или просто рендерить отдельные части контента на сервере?
+
+**Рендеринг на стороне клиента (CSR)**
+
+Рендеринг на стороне клиента (CSR) означает рендеринг страниц непосредственно в браузере с использованием JavaScript. Вся логика, выборка данных, шаблоны и маршрутизация обрабатываются на клиенте, а не на сервере.
+
+Рендеринг на стороне клиента может быть трудно получить и быстро сохранить для мобильных устройств. Он может приблизиться к производительности чисто серверного рендеринга, если выполняет минимальную работу, сохраняя жесткий бюджет JavaScript и предоставляя ценность в минимально возможном количестве RTTs. Критические сценарии и данные могут быть доставлены быстрее, используя HTTP/2 Server Push или \, что заставляет парсер работать на вас быстрее. Шаблоны, такие как PRPL, стоит оценить, чтобы обеспечить мгновенную начальную и последующую навигацию.
+
+
+
+Основным недостатком рендеринга на стороне клиента является то, что количество требуемого JavaScript имеет тенденцию к росту по мере роста приложения. Это становится особенно трудным с добавлением новых библиотек JavaScript, полифилов и стороннего кода, которые конкурируют за вычислительную мощность и часто должны обрабатываться до того, как содержимое страницы может быть отображено. Опыт работы с CSR, основанный на больших пакетах JavaScript, должен учитывать агрессивное разделение кода и обязательно загружать JavaScript - «обслуживайте только то, что вам нужно, когда вам это нужно». Для случаев, когда интерактивность незначительна или отсутствует, рендеринг сервера может представлять собой более масштабируемое решение этих проблем.
+
+Для людей, создающих одностраничное приложение, идентификация основных частей пользовательского интерфейса, используемых большинством страниц, означает, что вы можете применить технику кэширования Application Shell . В сочетании с сервис-воркерами это может значительно улучшить воспринимаемую производительность при повторных посещениях.
+
+**Объединение серверного рендеринга и CSR через регидратацию**
+
+Этот подход, часто называемый универсальным рендерингом или просто «SSR». Этот подход пытается сгладить углы между рендерингом на стороне клиента и рендерингом сервера, выполняя оба действия. Запросы навигации, такие как полная загрузка или перезагрузка страницы, обрабатываются сервером, который отображает приложение в HTML, затем JavaScript и данные, используемые для визуализации, встраиваются в итоговый документ. При аккуратной реализации это обеспечивает быструю First Contentful Paint точно так же, как серверный рендеринг, а затем «подхватывает», снова выполняя рендеринг на клиенте, используя технику, называемую (ре)гидратация. Это новое решение, но оно может иметь некоторые существенные недостатки производительности.
+
+Основным недостатком SSR с регидратацией является то, что он может оказать существенное негативное влияние на Time To Interactive, даже если он улучшит First Paint. Страницы SSR часто выглядят обманчиво загруженными и интерактивными, но на самом деле не могут реагировать на ввод, пока JS на стороне клиента не будет выполнен и обработчики событий не присоединены. Это может занять несколько секунд или даже минут на мобильном телефоне.
+
+Возможно, вы испытали это сами - в течение некоторого времени после того, как страница, которая выглядит полностью загруженной не реагирует на клики или нажатия. Это быстро расстраивает ... «Почему ничего не происходит? Почему я не могу прокрутить?
+
+**Проблема регидратации: одно приложение по цене двух**
+
+Проблемы регидратации часто могут быть хуже, чем замедленная интерактивность из-за JS. Чтобы клиентский JavaScript мог точно «подхватить», где сервер остановился, без необходимости повторного запроса всех данных, которые сервер использовал для визуализации своего HTML, текущие SSR решения обычно сериализуют ответ от пользовательского интерфейса. зависимости данных в документе в виде тегов скрипта. Полученный HTML-документ содержит высокий уровень дублирования:
+
+
+
+Как вы можете видеть, сервер возвращает описание пользовательского интерфейса приложения в ответ на запрос навигации, но он также возвращает исходные данные, использованные для создания этого пользовательского интерфейса, и полную копию реализации пользовательского интерфейса, которая затем загружается на клиенте. Только после завершения загрузки и выполнения bundle.js этот интерфейс становится интерактивным.
+
+Метрики производительности, собранные с реальных веб-сайтов с использованием регидратации SSR, указывают на то, что его использование не рекомендуется. В конечном счете, причина кроется в пользовательском опыте: в конечном итоге крайне просто оставить пользователей в «странной долине».
+
+
+
+Хотя есть надежда на SSR с регидратацией. В краткосрочной перспективе только использование SSR для контента с высокой степенью кэширования может уменьшить задержку TTFB, что дает результаты, аналогичные предварительному рендерингу. Регидратация постепенно, постепенно или частично может стать ключом к повышению эффективности этого метода в будущем.
+
+\*\*Рендеринг потокового сервера и прогрессивная регидратация \*\*(Streaming server rendering and Progressive Rehydration)
+
+За последние несколько лет серверный рендеринг получил ряд разработок.
+
+Рендеринг потокового сервера позволяет отправлять HTML порциями, которые браузер может визуализировать по мере получения. Это может обеспечить быструю First Paint и First Contentful Paint, поскольку разметка поступает к пользователям быстрее. В React потоки, являющиеся асинхронными в renderToNodeStream() - по сравнению с синхронным renderToString - означают, что обратное давление хорошо обрабатывается.
+
+Прогрессивная регидратация также стоит того, чтобы за ней следить, и кое-что, что изучал React. При таком подходе отдельные части приложения, отображаемого на сервере, «загружаются» с течением времени, а не по общему текущему подходу - инициализации всего приложения сразу. Это может помочь уменьшить объем JavaScript, необходимый для того, чтобы сделать страницы интерактивными, поскольку обновление на стороне клиента низкоприоритетных частей страницы может быть отложено для предотвращения блокировки основного потока. Это также может помочь избежать одной из самых распространенных ошибок регидратации в SSR, когда дерево DOM, отображаемое сервером, разрушается, а затем немедленно перестраивается - чаще всего потому, что при первоначальной синхронной визуализации на стороне клиента требуются не совсем готовые данные, возможно, ожидающие разрешения Promise.
+
+**Частичная регидратация**
+
+Частичная регидратация оказалась трудно осуществимой. Этот подход является продолжением идеи прогрессивной регидратации, где анализируются отдельные части (компоненты/виды/деревья), которые должны быть постепенно регидратированы, и идентифицируются те, у которых мало интерактивности или нет реактивности. Для каждой из этих в основном статических частей соответствующий код JavaScript затем преобразуется в инертные ссылки и декоративную функциональность, сокращая их площадь на стороне клиента почти до нуля. Подход частичной гидратации имеет свои проблемы и недостатки. Это создает некоторые интересные проблемы для кэширования, и навигация на стороне клиента означает, что мы не можем предполагать, что серверный HTML-код для инертных частей приложения будет доступен без полной загрузки страницы.
+
+**Трисоморфный рендеринг** (Trisomorphic Rendering)
+
+Если сервис-воркеры являются подходящим вариантом для вас, «трисоморфный» рендеринг также может представлять интерес. Это метод, при котором вы можете использовать потоковый рендеринг сервера для начальной/не-JS-навигации, а затем попросить сервис-воркер на себя рендеринг HTML для навигации после его установки. Это может поддерживать кэшированные компоненты и шаблоны в актуальном состоянии и обеспечивает навигацию в стиле SPA для отображения новых представлений в одном сеансе. Этот подход работает лучше всего, когда вы можете совместно использовать один и тот же код шаблонов и маршрутизации между сервером, клиентской страницей и сервис-воркером.
+
+
+
+**SEO соображения**
+
+Команды часто учитывают влияние SEO при выборе стратегии рендеринга в сети. Рендеринг сервера часто выбирается для обеспечения «полного вида», который сканеры могут легко интерпретировать. Сканеры могут понимать JavaScript, но часто есть ограничения, о которых стоит знать, как они рендерится. Рендеринг на стороне клиента может работать, но часто не без дополнительного тестирования и работы. В последнее время динамический рендеринг также стал вариантом, заслуживающим внимания, если ваша архитектура сильно зависит от клиентского JavaScript.
+
+В случае сомнений инструмент Mobile Friendly Test неоценим для проверки того, что выбранный вами подход делает то, на что вы надеетесь. Он показывает визуальный предварительный просмотр того, как какая-либо страница отображается сканеру Google, найденный сериализованный контент HTML (после выполнения JavaScript) и любые ошибки, обнаруженные во время рендеринга.
+
+
+
+[Вот удобная инфографика](https://developers.google.com/web/updates/images/2019/02/rendering-on-the-web/infographic.png?hl=ru), показывающая спектр сервер-клиент:
+
+
+
+**Как работает рендеринг в браузере**
+
+* Из полученного от сервера HTML-документа формируется DOM (Document Object Model).
+* Загружаются и распознаются стили, формируется CSSOM (CSS Object Model).
+* На основе DOM и CSSOM формируется дерево рендеринга, или render tree - набор объектов рендеринга (Webkit использует термин «renderer», или «render object», а Gecko - «frame»). Render tree дублирует структуру DOM, но сюда не попадают невидимые элементы (например - \, или элементы со стилем display:none;). Также, каждая строка текста представлена в дереве рендеринга как отдельный renderer. Каждый объект рендеринга содержит соответствующий ему объект DOM (или блок текста), и рассчитанный для этого объекта стиль. Проще говоря, render tree описывает визуальное представление DOM.
+* Для каждого элемента render tree рассчитывается положение на странице - происходит layout. Браузеры используют поточный метод (flow), при котором в большинстве случаев достаточно одного прохода для размещения всех элементов (для таблиц проходов требуется больше).
+* Наконец, происходит отрисовка всего этого добра в браузере - painting.
+
+В процессе взаимодействия пользователя со страницей, а также выполнения скриптов, она меняется, что требует повторного выполнения некоторых из вышеперечисленных операций.
+
+**Адаптивный и отзывчивый веб-дизайн (Adaptive vs. Responsive)**
+
+Чтобы онлайн ресурс корректно отображался на компьютере и мобильных устройствах, при создании сайта или интернет-магазина рекомендуется использовать адаптивный дизайн. Такой тип верстки позволяет варьировать размеры и отображение интерфейса ресурса в зависимости от типа устройства, с помощью которого пользователь зашел в Интернет.
+
+
+
+**Responsive Design (RWD)** - отзывчивый дизайн - проектирование сайта с определенными значениями свойств, например, гибкая сетка макета, которые позволяют одному макету работать на разных устройствах;
+
+Помимо своей изменяющейся структуры, у респонсив дизайна есть несколько других преимуществ:
+
+* Одинаковый внешний вид ресурса в разных браузерах и на различных платформах\
+ Наличие у сайта одинакового URL, что способствует SEO-оптимизации\
+ Разработчикам необходимо обслуживать лишь один сайт, что позволяет сократить время, затрачиваемое на дизайн и контент
+
+И хотя положительные стороны респонсивного дизайна очевидны, у этого метода существует ряд недостатков. Самым большим из них является скорость загрузки, которая значительно снижается из-за высокого разрешения изображений и других визуальных элементов, необходимых для оформления внешнего вида ресурса.
+
+**Adaptive Design (AWD)** - адаптивный дизайн, или динамический показ - проектирование сайта с условиями, которые изменяются в зависимости от устройства, базируясь на нескольких макетах фиксированной ширины.
+
+Для создания отзывчивых макетов используются медиазапросы и относительные размеры элементов сетки, заданные с помощью %. В адаптивном дизайне серверные скрипты сначала определяют тип устройства, с помощью которого пользователь пытается получить доступ к сайту (настольный ПК, телефон или планшет), затем загружает именно ту версию страницы, которая наиболее оптимизирована для него. Для элементов сетки задаются фиксированные в пикселях (px) размеры.
+
+Источники:
+
+* [Рендеринг в Интернете](https://developers.google.com/web/updates/2019/02/rendering-on-the-web?hl=ru) + [оригинал](https://developers.google.com/web/updates/2019/02/rendering-on-the-web?hl=en)
+* [Как браузер рендерит веб-страницу](https://webdevblog.ru/kak-brauzer-renderit-veb-stranicu/)
+* [Отзывчивый и адаптивный дизайн сайта](https://html5book.ru/otzyvchivyj-dizayn-saita/)
+
+Доп. материал:
+
+* [Что происходит, когда вводишь url, или как работает интернет](https://habr.com/ru/company/karuna/blog/568702/)
+* [Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com](https://m.habr.com/en/company/htmlacademy/blog/254825/)
+* [Что происходит, когда пользователь набирает в браузере адрес сайта](https://vc.ru/selectel/76371-chto-proishodit-kogda-polzovatel-nabiraet-v-brauzere-adres-sayta)
+* [What happens when you type a URL in the browser and press enter?](https://medium.com/@maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a)
+* [В виде картинки](https://www.programando.org/blog/2020/09/05/el-camino-del-backend-developer-dns/que-pasa-al-tipear-una-url-big.jpeg)
+* [Critical rendering path](https://developer.mozilla.org/en-US/docs/Web/Performance/Critical\_rendering\_path)
+* [Что такое адаптивный дизайн сайта](https://webgain.ru/osobennosti-i-plyusy-razrabotki-adaptivnogo-dizajna-sajta/)
+* [Новый адаптивный дизайн](https://www.youtube.com/watch?v=dhrX\_biPH8c)
+* [Responsive design](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS\_layout/Responsive\_Design)
+
diff --git a/seti-i-okolo-nikh/rest-soap-grpc.md b/seti-i-okolo-nikh/rest-soap-grpc.md
new file mode 100644
index 0000000..886c140
--- /dev/null
+++ b/seti-i-okolo-nikh/rest-soap-grpc.md
@@ -0,0 +1,85 @@
+# REST/SOAP/gRPC
+
+**REST** (от англ. Representational State Transfer - “передача репрезентативного состояния” или “передача “самоописываемого”состояния”) - архитектурный стиль взаимодействия компонентов распределенного приложения в сети. Другими словами, REST - это набор правил того, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределенной гипермедиа-системы. В определенных случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC.
+
+В сети Интернет вызов удаленной процедуры может представлять собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса. Для веб-служб, построенных с учетом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».
+
+В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, [JSON](https://habr.com/ru/post/554274/) и, реже, XML.
+
+**Требования к архитектуре REST**
+
+Существует шесть обязательных ограничений для построения распределенных REST-приложений по Филдингу.
+
+Выполнение этих ограничений обязательно для REST-систем. Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надёжность. Если сервис-приложение нарушает любое из этих ограничительных условий, данную систему нельзя считать REST-системой.
+
+Обязательными условиями-ограничениями являются:
+
+* **Модель клиент-сервер**: Первым ограничением, применимым к гибридной модели, является приведение архитектуры к модели клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Наибольшее же влияние на всемирную паутину, пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.
+* **Отсутствие состояния**: Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится (Stateless protocol или «протокол без сохранения состояния»). Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния, например, на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние. Во время обработки клиентских запросов считается, что клиент находится в переходном состоянии. Каждое отдельное состояние приложения представлено связями, которые могут быть задействованы при следующем обращении клиента.
+* **Кэширование**: Информация должна быть проверяема, иначе она может быть удалена. Вы можете отредактировать статью, добавив ссылки на авторитетные источники. Эта отметка установлена 16 марта 2017 года. Как и во Всемирной паутине, клиенты, а также промежуточные узлы, могут выполнять кэширование ответов сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно частично или полностью устранить некоторые клиент-серверные взаимодействия, еще больше повышая производительность и масштабируемость системы.
+* **Единообразие интерфейса**: Наличие унифицированного интерфейса является фундаментальным требованием дизайна REST-сервисов. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо. К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия:
+ * Идентификация ресурсов: Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.
+ * Манипуляция ресурсами через представление: Если клиент хранит представление ресурса, включая метаданные - он обладает достаточной информацией для модификации или удаления ресурса.
+ * «Самоописываемые» сообщения: Каждое сообщение содержит достаточно информации, чтобы понять, каким образом его обрабатывать. К примеру, обработчик сообщения (parser), необходимый для извлечения данных, может быть указан в списке MIME-типов.
+ * Гипермедиа как средство изменения состояния приложения (HATEOAS): Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить, что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, Web Linking (RFC 5988 -> RFC 8288) и JSON Hypermedia API Language являются двумя популярными форматами предоставления ссылок в REST HYPERMEDIA сервисах.
+* **Слои**: Клиент обычно не способен точно определить, взаимодействует он напрямую с сервером или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует слои). Применение промежуточных серверов способно повысить масштабируемость за счет балансировки нагрузки и распределенного кэширования. Промежуточные узлы также могут подчиняться политике безопасности с целью обеспечения конфиденциальности информации.
+* **Код по требованию** (необязательное ограничение): Информация должна быть проверяема, иначе она может быть удалена. Вы можете отредактировать статью, добавив ссылки на авторитетные источники. Эта отметка установлена 16 марта 2017 года. REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера в виде апплетов или скриптов. Филдинг утверждает, что дополнительное ограничение позволяет проектировать архитектуру, поддерживающую желаемую функциональность в общем случае, но, возможно, за исключением некоторых контекстов.
+
+Просто посмотреть как выглядят запросы-ответы можно во вкладке Network в DevTools. Попробовать отправить запрос и посмотреть ответ можно с помощью [этой статьи](https://www.software-testing.ru/library/testing/testing-automation/2958-testing-get-requests).
+
+**SOAP**
+
+SOAP (от англ. Simple Object Access Protocol - простой протокол доступа к объектам) - протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате [**XML**](https://habr.com/ru/post/524288/), а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP.
+
+SOAP является расширением протокола XML-RPC. SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP. SOAP является одним из стандартов, на которых базируются технологии веб-служб.
+
+[Структура](https://www.w3schools.com/xml/xml\_soap.asp) протокола:
+
+* Envelope - корневой элемент, который определяет сообщение и пространство имен, использованное в документе;
+* Header - содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации;
+* Body - содержит сообщение, которым обмениваются приложения;
+* Fault - необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.
+
+[Пример SOAP-запроса на сервер интернет-магазина](https://ru.wikipedia.org/wiki/SOAP#:\~:text=%D0%BF%D1%80%D0%B8%20%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B5%20%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B9.-,%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80,-%5B%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D1%8C%20%7C%20%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D1%8C%20%D0%BA%D0%BE%D0%B4)
+
+[**WSDL**](https://www.w3.org/TR/wsdl.html) - это описательный язык, основанный на языке разметки XML, и именно в wsdl описан веб-сервис, который вам придется тестировать. WSDL включает в себя информацию о местоположении сервиса, часто включает в себя XSD. Именно из WSDL SOAPUI генерирует проверяемые классы.
+
+[**XSD**](https://en.wikipedia.org/wiki/XML\_Schema\_\(W3C\)) - это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных.
+
+Если Вы направите в веб-сервис нестандартный запрос, он ответит на это ошибкой. WSDL - это свод правил общения с вашим сервисом, соблюдая которые вы сможете с этим сервисом коммуницировать. Собственно WSDL и XSD подробно описывают что и в каком виде слать на сервер, чтобы получить хороший ответ.
+
+Что тестируется в SOAP? Бизнес-логика и то, что схема валидируется сервером (а также, что она принимает на вход параметры правильного формата). Собственно все, что касается схемы, проверяется на этапе разработки, а после, только бизнес-логика (до того момента, пока опять не начнутся изменения в схеме).
+
+**Отличия REST и SOAP**
+
+SOAP и REST нельзя сравнивать напрямую, поскольку первый - это протокол (или, по крайней мере, пытается им быть), а второй - архитектурный стиль.
+
+Основное различие между SOAP и REST заключается в степени связи между реализациями клиента и сервера. Клиент SOAP работает как пользовательское настольное приложение, тесно связанное с сервером. Между клиентом и сервером существует жесткое соглашение, и ожидается, что все сломается, если какая-либо из сторон что-то изменит. Вам нужно постоянное обновление после любого изменения, но легче определить, выполняется ли контракт.
+
+SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило - в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы - PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
+
+**gRPC**
+
+Для тех, кто еще не слышал о gRPC, gRPC - это не зависящий от языка фреймворк для удаленного вызова процедур (RPC, remote procedure calls), разработанный Google, которая серьезно вкладывается в производительность и масштабирование. Он появился довольно давно, но многие (а, может быть, только я) отложили его на второй план из-за затрат на написание IDL и дополнительного кода стабов (stub), который тоже необходимо поддерживать. В то же время REST очень легко реализуется с помощью ASP.NET Core WebAPI.
+
+Аналогично использованию JSON для REST, для gRPC используется [Protocol Buffers](https://developers.google.com/protocol-buffers) - не зависящий от языка формат для сериализации структурированных данных. Этим gRPC отличается от REST. Поддержка Protocol Buffers есть для всех основных языков благодаря компилятору protoc, который генерирует необходимый исходный код классов из определений в proto-файле. Еще важный момент состоит в том, что для связи gRPC использует HTTP/2, а это приносит дополнительные преимущества, такие как сжатие HTTP-заголовков и мультиплексирование запросов.
+
+Источники:
+
+* [REST](https://ru.wikipedia.org/wiki/REST)
+* [SOAP](https://ru.wikipedia.org/wiki/SOAP)
+* [Веб-сервисы в теории и на практике для начинающих](https://habr.com/ru/post/46374/)
+* [Что такое SOAP API](https://qahacking.ru/lessons/chto-takoe-soap-api)
+* [Сравниваем производительность REST и gRPC](https://habr.com/ru/company/otus/blog/545688/)
+
+Доп. материал:
+
+* [w3.org SOAP Версия 1.2 Часть 0: Учебник для начинающих](https://www.w3.org/2002/07/soap-translation/russian/part0.html)
+* [REST vs. SOAP (Making the Right Architectural Decision) - 1st International SOA Symposium, Amsterdam, October 2008](https://www.slideshare.net/cesare.pautasso/rest-vs-soap-making-the-right-architectural-decision-1st-international-soa-symposium-amsterdam-october-2008-presentation)
+* [Тестировщик с нуля / Урок 17. Тестирование веб-сервисов. SOAP и XML, REST и JSON для тестировщика](https://www.youtube.com/watch?v=\_cfmDnIIQTU\&t=1009s)
+* [Модель зрелости REST-сервисов](https://habr.com/ru/post/590679/#:\~:text=%D1%8D%D1%82%D0%BE%20%D0%BD%D0%B5%20SOAP.-,%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C%20%D0%B7%D1%80%D0%B5%D0%BB%D0%BE%D1%81%D1%82%D0%B8%20REST%2D%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BE%D0%B2,-%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C%20%D0%B7%D1%80%D0%B5%D0%BB%D0%BE%D1%81%D1%82%D0%B8%20REST)
+* [JSON Validator](https://jsonlint.com)
+* [XML Validator](https://xmllint.com)
+* [Семантика REST: Это смешное слово «идемпотентный»](https://qsusha.wordpress.com/2017/10/29/%D1%8D%D1%82%D0%BE-%D1%81%D0%BC%D0%B5%D1%88%D0%BD%D0%BE%D0%B5-%D1%81%D0%BB%D0%BE%D0%B2%D0%BE-%D0%B8%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D1%8B%D0%B9/)
+* [Soap VS Rest запросы на примерах](https://www.youtube.com/watch?v=C2TMZeRdLKw)
+* [Введение в SOAP и REST: что это и с чем едят](https://www.youtube.com/watch?v=2YWfJHDNQy0)
diff --git a/seti-i-okolo-nikh/soket-veb-soket-socket-websocket.md b/seti-i-okolo-nikh/soket-veb-soket-socket-websocket.md
new file mode 100644
index 0000000..13f4156
--- /dev/null
+++ b/seti-i-okolo-nikh/soket-veb-soket-socket-websocket.md
@@ -0,0 +1,83 @@
+# Сокет/веб-сокет (socket/websocket)
+
+**Со́кет** (англ. socket - разъем) - название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на различных ЭВМ, связанных между собой сетью. Сокет - абстрактный объект, представляющий конечную точку соединения.
+
+Следует различать клиентские и серверные сокеты. Клиентские сокеты грубо можно сравнить с конечными аппаратами телефонной сети, а серверные - с коммутаторами. Клиентское приложение (например, браузер) использует только клиентские сокеты, а серверное (например, веб-сервер, которому браузер посылает запросы) - как клиентские, так и серверные сокеты.
+
+**Принципы сокетов**
+
+Для взаимодействия между машинами с помощью стека протоколов TCP/IP используются адреса и порты. Адрес представляет собой 32-битную структуру для протокола IPv4, 128-битную для IPv6. Номер порта - целое число в диапазоне от 0 до 65535 (для протокола TCP).
+
+Эта пара определяет сокет («гнездо», соответствующее адресу и порту).
+
+В процессе обмена, как правило, используется два сокета - сокет отправителя и сокет получателя. Например, при обращении к серверу на HTTP-порт сокет будет выглядеть так: 194.106.118.30:80, а ответ будет поступать на mmm.nnn.ppp.qqq:xxxxx.
+
+Каждый процесс может создать «слушающий» сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы (в UNIX непривилегированные процессы не могут использовать порты меньше 1024).
+
+Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность проверить наличие соединений на данный момент, установить тайм-аут для операции и т. д.
+
+Каждый сокет имеет свой адрес. ОС семейства UNIX могут поддерживать много типов адресов, но обязательными являются INET-адрес и UNIX-адрес. Если привязать сокет к UNIX-адресу, то будет создан специальный файл (файл сокета) по заданному пути, через который смогут сообщаться любые локальные процессы путём чтения/записи из него (см. сокет домена Unix). Сокеты типа INET доступны из сети и требуют выделения номера порта.
+
+Обычно клиент явно «подсоединяется» к слушателю, после чего любое чтение или запись через его файловый дескриптор будут передавать данные между ним и сервером.
+
+**WebSocket**
+
+WebSocket - протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.
+
+В настоящее время в W3C осуществляется стандартизация API Web Sockets. Черновой вариант стандарта этого протокола утверждён IETF.
+
+WebSocket разработан для воплощения в веб-браузерах и веб-серверах, но он может быть использован для любого клиентского или серверного приложения. Протокол WebSocket - это независимый протокол, основанный на протоколе TCP. Он делает возможным более тесное взаимодействие между браузером и веб-сайтом, способствуя распространению интерактивного содержимого и созданию приложений реального времени.
+
+**Разница Socket и WebSocket**
+
+Socket и WebSocket - это разные понятия в принципе. При работе по протоколу WebSocket вы будете использовать обычные сокеты для соединения. Так же как и при работе с другими протоколами будут использованы сокеты (и для работы с http, с ftp и др.).
+
+Например, рассмотрим строку вида - ws://127.0.0.1:15000. В ней ws - это именно указание на то, что при обмене данными будет использован протокол WebSocket. 127.0.0.1 - ip адрес компьютера, 15000 - порт, на который производится подключение. Так вот 127.0.0.1:15000 - эта пара, если можно так выразится, и является сокетом.
+
+Протокол WebSocket создавался для того, чтобы можно было поддерживать длительные неразрывные соединения между браузером (который является клиентом) и веб-сайтом (который является сервером).
+
+Протокол WebSocket не похож на HTTP. Единственное, чем он напоминает HTTP - только одним самым первым запросом на подключение (так называемым рукопожатием/handshake). Это было сделано, потому что изначально протокол рассчитан на работу в браузере и необходимо было определение возможности поддержки его. После того, как соединение установлено, ничего похожего на протокол HTTP в протоколе WebSocket даже близко нет. Именно отсутствие каких-либо наворотов в протоколе WebSocket и дает ему возможность быстрой работы.
+
+**Разница WebSocket и Socket.IO**
+
+Говоря о веб-сокетах, мы имеем ввиду протокол веб-коммуникации, представляющий полнодуплексный канал коммуникации поверх простого TCP-соединения. Проще говоря, эта технология позволяет установить связь между клиентом и сервером с минимальными затратами, позволяя создавать приложения, использующие все преимущества живого общения. Например, представьте, что вы создаете чат: вам необходимо получать и отправлять данные как можно быстрее, верно? С этим прекрасно справляются веб-сокеты! Вы можете открыть TCP-соединение и держать его открытым сколько потребуется. Веб-сокеты используются в следующих случаях:
+
+* Чаты;
+* Многопользовательские игры;
+* Совместное редактирование;
+* Социальные (новостные) ленты;
+* Приложения, работающие на основе местоположения.
+
+Socket.IO - библиотека JavaScript, основанная (написанная поверх) на веб-сокетах… и других технологиях. Она использует веб-сокеты, когда они доступны, или такие технологии, как Flash Socket, AJAX Long Polling, AJAX Multipart Stream, когда веб-сокеты недоступны.
+
+**AJAX**
+
+Ajax ( Asynchronous Javascript and XML - «асинхронный JavaScript и XML») - подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате при обновлении данных веб-страница не перезагружается полностью, и веб-приложения становятся быстрее и удобнее. По-русски иногда произносится транслитом как «аякс». У аббревиатуры AJAX нет устоявшегося аналога на кириллице.
+
+В классической модели веб-приложения:
+
+* Пользователь заходит на веб-страницу и нажимает на какой-нибудь ее элемент;
+* Браузер формирует и отправляет запрос серверу;
+* В ответ сервер генерирует совершенно новую веб-страницу и отправляет ее браузеру и т. д. , после чего браузер полностью перезагружает всю страницу.
+
+При использовании AJAX:
+
+* Пользователь заходит на веб-страницу и нажимает на какой-нибудь ее элемент;
+* JavaScript определяет, какая информация необходима для обновления страницы;
+* Браузер отправляет соответствующий запрос на сервер;
+* Сервер возвращает только ту часть документа, на которую пришел запрос;
+* Скрипт вносит изменения с учетом полученной информации (без полной перезагрузки страницы).
+
+Источники:
+
+* [Сокет (программный интерфейс)](https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BA%D0%B5%D1%82\_\(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D1%8B%D0%B9\_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81\))
+* [WebSocket](https://ru.wikipedia.org/wiki/WebSocket)
+* [В чем разница между socket'ом и websocket'ом?](https://ru.stackoverflow.com/questions/507746/%D0%92-%D1%87%D0%B5%D0%BC-%D1%80%D0%B0%D0%B7%D0%BD%D0%B8%D1%86%D0%B0-%D0%BC%D0%B5%D0%B6%D0%B4%D1%83-socket%D0%BE%D0%BC-%D0%B8-websocket%D0%BE%D0%BC)
+* [Разница WebSocket и Socket.IO](https://habr.com/ru/post/498996/)
+* [AJAX](https://ru.wikipedia.org/wiki/AJAX)
+
+Доп. материал:
+
+* [WebSockets vs HTTP](https://webformyself.com/websockets-vs-http/)
+* [RFC 6455 - The WebSocket Protocol](https://datatracker.ietf.org/doc/html/rfc6455)
+* [The WebSocket API (WebSockets)](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets\_API)
diff --git a/seti-i-okolo-nikh/veb-servis-ws-web-service.md b/seti-i-okolo-nikh/veb-servis-ws-web-service.md
new file mode 100644
index 0000000..f8a276f
--- /dev/null
+++ b/seti-i-okolo-nikh/veb-servis-ws-web-service.md
@@ -0,0 +1,50 @@
+# Веб-сервис (WS - Web service)
+
+Веб-служба, веб-сервис (англ. web service) - идентифицируемая уникальным веб-адресом (URL-адресом) программная система со стандартизированными интерфейсами. Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах (SOAP, XML-RPC и т. д.) и соглашениях (REST). Веб-служба является единицей модульности при использовании сервис-ориентированной архитектуры приложения (SOA).
+
+В обиходе веб-сервисами называют услуги, оказываемые в Интернете. В этом употреблении термин требует уточнения, идет ли речь о поиске, веб-почте, хранении документов, файлов, закладок и т. п. Такими веб-сервисами можно пользоваться независимо от компьютера, браузера или места доступа в Интернет/
+
+Если посмотреть на веб-сервисы в разрезе стека сетевых протоколов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP. С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений - вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых. Но и сам Интернет - разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки. Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
+
+По сути, веб-сервисы - это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
+
+**Архитектура**
+
+
+
+Как показано на рисунке, можно выделить три инстанции, взаимодействующие в рамках веб-службы. Переведем их названия как:
+
+* заказчик (service requester);
+* исполнитель (service provider);
+* каталог (service broker).
+
+Когда служба разработана, исполнитель регистрирует ее в каталоге, где её могут найти потенциальные заказчики. Заказчик, найдя в каталоге подходящую службу, импортирует оттуда её WSDL-спецификацию и разрабатывает в соответствии с ней своё программное обеспечение. WSDL описывает формат запросов и ответов, которыми обмениваются заказчик и исполнитель в процессе работы.
+
+Для обеспечения взаимодействия используются следующие стандарты/протоколы:
+
+* SOAP (Simple Object Access Protocol) - по сути это тройка стандартов SOAP/WSDL/UDDI;
+* REST (Representational State Transfer) - архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP;
+* UDDI - устарел;
+* XML-RPC (XML Remote Procedure Call) - устарел;
+* JSON-RPC (JSON Remote Procedure Call) - более современный аналог XML-RPC. Основное отличие - данные передаются в формате JSON;
+* Специализированные протоколы для конкретного вида задач, такие как GraphQL;
+* Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.
+
+На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST - это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
+
+**Отличие сервиса от сервера**
+
+Сервис (микросервис) - это программа, размещаемая на сервере, которая предоставляет определенную функцию, находясь по определенному адресу и используя четко определенные интерфейсы и логику. Сегодня это чаще всего интерфейсы API.
+
+Сервер может хостить в себе тысячи сервисов. Впрочем, и один сервис может быть размещен на нескольких серверах. В более широком плане - сервер - это виртуальная машина, которая хостит в себе Apache, IIS и много-много web-сервисов. Еще в более широком плане - это железяка, которая хостит в себе множество виртуалок.
+
+Источники:
+
+* [Веб-служба](https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%B1-%D1%81%D0%BB%D1%83%D0%B6%D0%B1%D0%B0)
+
+Доп. материал:
+
+* [Веб-сервисы](https://gist.github.com/vchernogorov/81da656048875132d6963304d449f770)
+* [W3C Web Services](http://www.w3.org/2002/ws/)
+* [Тестировщик с нуля / Урок 17. Тестирование веб-сервисов. SOAP и XML, REST и JSON для тестировщика](https://www.youtube.com/watch?v=\_cfmDnIIQTU)
+* [Message broker](https://en.wikipedia.org/wiki/Message\_broker)
diff --git a/test-dizain/README.md b/test-dizain/README.md
new file mode 100644
index 0000000..92eca8c
--- /dev/null
+++ b/test-dizain/README.md
@@ -0,0 +1,2 @@
+# Тест дизайн
+
diff --git a/test-dizain/dynamic-black-box.md b/test-dizain/dynamic-black-box.md
new file mode 100644
index 0000000..8c8c471
--- /dev/null
+++ b/test-dizain/dynamic-black-box.md
@@ -0,0 +1,378 @@
+# Dynamic - Black box
+
+_Разработка тестов методом черного ящика (black box test design technique): Процедура создания и/или выбора тестовых сценариев, основанная на анализе функциональной или нефункциональной спецификации компонента или системы без знания внутренней структуры. (ISTQB)_
+
+_Основанные на спецификации методы проектирования тестирования используются для получения контрольных примеров из базиса тестирования, определяющего ожидаемое поведение элемента тестирования. При использовании этих методов входные данные для тестирования контрольного примера и ожидаемый результат получаются из базиса тестирования. Выбор, какие из основанных на спецификации методов проектирования тестирования использовать в каждой конкретной ситуации, зависит от природы базиса тестирования и/или элемента тестирования, и от присущих рисков. (ГОСТ 56920)_
+
+Все specification-based или Black Box testing techniques могут быть удобно описаны и систематизированы с помощью следующей таблицы:
+
+| **Группа** | **Техника** | **Когда используется** |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|
Элементарные техники:
сосредоточены на анализе входных / выходных параметров;
можно комбинировать для лучшего покрытия;
обычно не используют и не зависят от других методик;
| Equivalence Partitioning | Входные и выходные параметры имеют большое количество возможных значений |
+| Boundary Value Analysis | Значения параметров имеют явные (например, четко определенные в документации) границы и диапазоны или неявные (например, известные технические ограничения) границы | |
+|
Комбинаторные стратегии:
объединяют возможные значения нескольких параметров ввода / вывода;
могут использовать элементарные приемы для уменьшения количества возможных значений;
| All Combinations | Количество возможных комбинаций входных значений достаточно мало, или каждая отдельная комбинация входных значений приводит к определенному выходному значению |
+| Pairwise Testing | Количество входных комбинаций чрезвычайно велико и должно быть сокращено до приемлемого набора кейсов | |
+| Each Choice Testing | У вас есть функции, при которых скорее конкретное значение параметра вызывает ошибку, нежели комбинация значений | |
+| Base Choice Testing | Вы можете выделить набор значений параметров, который имеет наибольшую вероятность использования | |
+|
Продвинутые техники:
помогают проанализировать Систему с точки зрения бизнес-логики, иерархических отношений, сценариев и т. д.;
анализ основан на данных, организованных в таблицы, диаграммы и шаблоны;
может полагаться на элементарные и комбинаторные методы для разработки тестовых примеров;
| Decision Table Testing | Существует набор комбинаций параметров и их выходных данных, описываемых бизнес-логикой или другими правилами |
+| Classification Tree Method | У вас есть иерархически структурированные данные, или данные могут быть представлены в виде иерархического дерева | |
+| State Transition Testing | В функциональности есть очевидные состояния, переходы которых регулируются правилами (например, потоки) | |
+| Cause-Effect Graphing | Причины (входы) и следствия (выходы) связаны большим количеством сложных логических зависимостей | |
+| Scenario Testing | В функционале есть четкие сценарии | |
+| Другие техники | Random Testing | Вам необходимо имитировать непредсказуемость реальных вводных данных, или функциональность имеет несистематические дефекты |
+| Syntax Testing | Функциональность имеет сложный синтаксический формат для входных данных (например, коды, сложные имена электронной почты и т. д.) | |
+
+**Эквивалентное разделение (Equivalence Partitioning (ISTQB/Myers 1979) / Equivalence Class Testing (Lee Copeland))**
+
+Класс эквивалентности представляет собой набор данных, которые либо одинаково обрабатываются модулем, либо их обработка выдает одинаковые результаты. При тестировании любое значение данных, входящее в класс эквивалентности, аналогично любому иному значению класса.
+
+Эквивалентное разделение - это разделение всего набора данных ввода / вывода на такие разделы. Таким образом, вам не нужно выполнять тесты для каждого элемента подмножества, и достаточно одной проверки, чтобы охватить все подмножество. Хитрость заключается в том, чтобы увидеть и идентифицировать разделы, т.к. далеко не всегда они представляют собой числа.
+
+Пример: Мы пишем модуль для системы отдела кадров, который определяет, в каком порядке нужно рассматривать заявления о приеме на работу в зависимости от возраста кандидата.
+
+Правила нашей организации таковы:
+
+* от 0 до 16 - не принимаются;
+* от 16 до 18 - могут быть приняты только на неполный рабочий день;
+* от 18 до 55 - могут быть приняты как сотрудники на полный рабочий день;
+* от 55 до 99 - не принимаются;
+
+Что в коде выглядит как:
+
+* If (applicantAge >= 0 && applicantAge <=16)
+ * hireStatus="NO";
+* If (applicantAge >= 16 && applicantAge <=18)
+ * hireStatus="PART";
+* If (applicantAge >= 18 && applicantAge <=55)
+ * hireStatus="FULL";
+* If (applicantAge >= 55 && applicantAge <=90)
+ * hireStatus="NO";
+
+Из чего очевидно, что вместо 100 кейсов нам понадобится 4 по числу эквивалентных классов, все остальные кейсы внутри своих классов будут давать одинаковый результат тестов и являются избыточными.
+
+Теперь мы готовы начать тестирование? Вероятно, нет. Что насчет таких входных данных как 969, -42, FRED или &$#! ? Должны ли мы создавать тестовые сценарии для некорректных входных данных? Для того, чтобы понять ответ, мы должны проверить подход, который пришел из объектно-ориентированного мира, названный "проектирование-по-контракту".
+
+В подходе "проектирование-по-контракту" модули (в парадигме объектно-ориентированного программирования они называются "методами", но "модуль" является более общим термином) определены в терминах предусловий и постусловий. Постусловия определяют, что модуль обещает сделать (вычислить значение, открыть файл, напечатать отчет, обновить запись в базе данных, изменить состояние системы и т.д.). Предусловия описывают требования к модулю, при которых он переходит в состояние, описываемое постусловиями.
+
+Например, если у нас есть модуль "openFile", что он обещает сделать? Открыть файл. Какие будут разумные предусловия для этого модуля?
+
+* файл должен существовать,
+* мы должны предоставить имя (или другую идентифицирующую информацию),
+* файл должен быть "открываемым", т.е. он не может быть открытым в другом процессе,
+* у нас должны быть права доступа к файлу и т.д.
+
+Предусловия и постусловия основывают контракт между модулем и всеми, кто его вызывает. Тестирование-по-контракту основывается на философии проектирования-по-контракту. При использовании данного подхода мы создаем только те тест-кейсы, которые удовлетворяют нашим предусловиям. Например, мы не будем тестировать модуль "openFile", если файл не существует. Причина проста. Если файл не существует, то openFile не обещает работать. Если не существует требования работоспособности в определенных условиях, то нет необходимости проводить тестирование в этих условиях.
+
+В этот момент тестировщики обычно возражают. Да, они согласны, что модуль не претендует на работу в этом случае, но что делать, если предусловия нарушаются в процессе разработки? Что делать системе? Должны ли мы получить сообщение об ошибке на экране или дымящуюся воронку на месте нашей компании? Другим подходом к проектированию является оборонительное проектирование. В этом случае модуль предназначен для приема любого входного значения. Если выполнены обычные предусловия, то модуль достигнет своих обычных постусловий. Если обычные предварительные условия не выполняются, то модуль сообщит вызывающему, возвратив код ошибки или бросив исключение (в зависимости от используемого языка программирования). На самом деле, это уведомление является еще одним из постусловий модуля.
+
+На основе этого подхода мы могли бы определить оборонительное тестирование: подход, который анализирует как обычные, так и необычные предварительные условия.
+
+Нужно ли нам делать проверку с такими входными значениями, как -42, FRED и &$#! @? Если мы используем проектирование-по-контракту и тестирование-по-контракту, то ответ "Нет". Если мы используем оборонительное проектирование и, поэтому, оборонительное тестирование, то ответ "Да". Спросите ваших проектировщиков, какой подход они используют. Если их ответом будет «контрактный» либо «оборонительный», то вы знаете, какой стиль тестирования использовать. Если они ответят "Хм?", то это значит, что они не думают о том, как взаимодействуют модули. Они не думают о предусловиях и постусловиях контрактов. Вам стоит ожидать, что интеграционное тестирование будет главным источником дефектов, будет более сложным и потребует больше времени, чем ожидалось.
+
+Несмотря на то, что тестирование классов эквивалентности полезно, его величайшим вкладом является то, что оно приводит нас к тестированию граничных значений.
+
+**Анализ граничных значений (BVA - Boundary Value Analysis (Myers 1979)/range checking)**
+
+Тестирование классов эквивалентности - это самая основная методика тест-дизайна. Она помогает тестировщикам выбрать небольшое подмножество из всех возможных тестовых сценариев и при этом обеспечить приемлемое покрытие. У этой техники есть еще один плюс. Она приводит к идее о тестировании граничных значений - второй ключевой технике тест-дизайна.
+
+Пример. Выше описывались правила, которые указывали, каким образом будет происходить обработка заявок на вакансии в зависимости от возраста соискателя.
+
+Обратите внимание на проблемы на границах - это "края" каждого класса. Возраст "16" входит в два различных класса эквивалентности (как и "18", и "55"). Первое правило гласит не нанимать шестнадцатилетних. Второе правило гласит, что шестнадцатилетние могут быть наняты на неполный рабочий день Тестирование граничных значений фокусируется на границах именно потому, что там спрятано очень много дефектов. Опытные тестировщики сталкивались с этой ситуацией много раз. У неопытных тестировщиков может появиться интуитивное ощущение, что ошибки будут возникать чаще всего на границах. Эти дефекты могут быть в требованиях, или в коде, если программист ошибется с указанием границ в коде (включительно/не включительно, индекс +-1).
+
+Попробуем исправить приведенный выше пример:
+
+* от 0 до 15 - не принимаются;
+* от 16 до 17 - могут быть приняты только на неполный рабочий день;
+* от 18 до 54 - могут быть приняты как сотрудники на полный рабочий день;
+* от 55 до 99 - не принимаются;
+
+А что насчет возраста -3 и 101? Обратите внимание, что требования не указывают, как должны быть рассмотрены эти значения. Мы можем догадаться, но "угадывание требований" не является приемлемой практикой. Следующий код реализует исправленные правила:
+
+* if (applicantAge >= 0 && applicantAge <= 15)
+ * hireStatus = "NO";
+* if (applicantAge >= 16 && applicantAge <= 17)
+ * hireStatus = "PART";
+* if (applicantAge >= 18 && applicantAge <= 54)
+ * hireStatus = "FULL";
+* if (applicantAge >= 55 && applicantAge <= 99)
+ * hireStatus = "NO";
+
+В этом примере интересными значениями на границах или вблизи них являются {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56} и {98, 99, 100}. Другие значения, например {-42, 1001, FRED, %$#@} могут быть включены в зависимости от предусловий документации модуля.
+
+Для создания тест-кейсов для каждого граничного значения определите классы эквивалентности, выберите одну точку на границе, одну точку чуть ниже границы и одну точку чуть выше границы. Стоит отметить, что точка чуть выше границы может входить в другой класс эквивалентности. В таком случае не нужно дублировать тест. То же самое может быть верно по отношению точки чуть ниже границы.
+
+Тестирование граничных значений является наиболее подходящим там, где входные данные являются непрерывным диапазоном значений.
+
+**Тестирование таблиц решений (Decision Table testing)**
+
+Этот простой, но эффективный метод заключается в документировании бизнес-логики в таблице как наборы правил, условий выполнения действий и самих действий. Тестирование таблиц принятия решений может быть использовано, когда система должна реализовывать сложные бизнес-правила, когда эти правила могут быть представлены в виде комбинации условий и когда эти условия имеют дискретные действия, связанные с ними.
+
+Пример. Компания по автострахованию дает скидку водителям, которые состоят в браке и/или хорошо учатся.
+
+| - | **Правило 1** | **Правило 2** | **Правило 3** | **Правило 4** |
+| ---------------- | ------------- | ------------- | ------------- | ------------- |
+| **Условия** | - | - | - | - |
+| Состоит в браке? | Да | Да | Нет | Нет |
+| Хороший студент? | Да | Нет | Да | Нет |
+| - | - | - | - | - |
+| **Действия** | - | - | - | - |
+| Скидка ($) | 60 | 25 | 50 | 0 |
+
+эта таблица содержит все комбинации условий. Задав два бинарных условия ("да" или "нет"), возможные комбинации будут: ("да", "да"), ("да", "нет"), ("нет", "да") и ("нет", "нет"). Каждое правило представляет собой одну из этих комбинаций. Нам, тестировщикам, нужно будет проверить, что определяются все комбинации условий. Пропущенное сочетание может привести к разработке такой системы, которая не сможет правильно обработать определенный набор исходных данных. Каждое правило является причиной "запуска" действия. Каждое правило может задать действие, уникальное для этого правила, или правила могут иметь общие действия. Для каждого правила с помощью таблицы решений можно указать более одного действия. Опять же, эти правила могут быть уникальными или быть общими. В такой ситуации выбрать тесты просто - каждое правило (вертикальная колонка) становится тест-кейсом. Условия указывают на входные значения, а действия - на ожидаемые результаты.
+
+Если тестируемая система имеет сложные бизнес-правила, а у ваших бизнес-аналитиков или проектировщиков нет документации этих правил, то тестировщикам следует собрать эту информацию и представить ее в виде таблицы решений. Причина проста: представляя поведение системы в такой полной и компактной форме, тест-кейсы могут быть созданы непосредственно из таблицы решений. При тестировании для каждого правила создается как минимум один тест-кейс. Если состояния этого правила бинарные, то должно быть достаточно одного теста для каждого сочетания. С другой стороны, если состояние является диапазоном значений, то тестирование должно учитывать и нижнюю, и высшую границы диапазона. Таким образом мы объединяем идею тестирования граничных значений с тестированием таблиц решений.
+
+Чтобы создать тестовую таблицу, просто измените заголовки строк и столбцов: правила станут тест-кейсами, условия входными значениями, а действия ожидаемыми результатами.
+
+**Комбинаторные техники тест-дизайна (Combination Strategies)**
+
+_Комбинаторное тестирование (combinatorial testing): Метод, позволяющий выделить подходящую подгруппу тестовых комбинаций с целью добиться предопределенного уровня покрытия при тестировании объекта с множественными параметрами в случаях, когда эти параметры сами по себе состоят из нескольких значений, что приводит к появлению большего числа комбинаций, чем можно успеть протестировать за отведенное время. См. также метод дерева классификации, попарное тестирование, n-мерное (переборное) тестирование, тестирование с использованием ортогонального массива. (ISTQB)_
+
+Тестовые примеры выбираются на основе некоторого понятия покрытия, и цель стратегии комбинирования состоит в том, чтобы выбрать тестовые примеры из набора тестов таким образом, чтобы было достигнуто 100% покрытие.
+
+* 1-wise coverage (each-used) - это самый простой критерий покрытия. Для 100% each-used покрытия требуется, чтобы каждое значение каждого параметра было включено хотя бы в один тестовый пример в наборе тестов.
+* 2-wise (pair-wise) coverage требует, чтобы каждая возможная пара значений любых двух параметров была включена в некоторый тестовый пример. Обратите внимание, что один и тот же тестовый пример часто охватывает более одной уникальной пары значений.
+* Естественным продолжением 2-wise coverage является t-wise coverage, которое требует включения всех возможных комбинаций интересных значений параметров t в какой-либо тестовый пример в наборе тестов.
+* Самый тщательный критерий покрытия, N-wise coverage, требует набора тестов, который содержит все возможные комбинации значений параметров в input parameter model (IPM).
+
+**Все комбинации** (All combinations): как видно из названия, этот алгоритм подразумевает генерацию всех возможных комбинаций. Это означает исчерпывающее тестирование и имеет смысл только при разумном количестве комбинаций. Например, 3 переменные с 3 значениями для каждой дают нам матрицу параметров 3х3 с 27 возможными комбинациями.
+
+**Тестирование каждого выбора** (EC - Each choice testing): эта стратегия требует, чтобы каждое значение каждого параметра было включено по крайней мере в один тестовый пример (Ammann & Offutt, 1994). Это также определение 1-wise coverage.
+
+**Тестирование базового выбора** (BC - Base choice testing): алгоритм стратегии комбинирования базового выбора начинается с определения одного базового тестового примера. Базовый тестовый пример может быть определен по любому критерию, включая простейший, наименьший или первый. Критерий, предложенный Амманном и Оффуттом (Ammann & Offutt, 1994), - это «наиболее вероятное значение» с точки зрения конечного пользователя. Это значение может быть определено тестировщиком или основано на рабочем профиле, если таковой существует. Из базового тестового примера создаются новые тестовые примеры, изменяя интересующие значения одного параметра за раз, сохраняя значения других параметров фиксированными в базовом тестовом примере. Базовый выбор включает каждое значение каждого параметра по крайней мере в одном тестовом примере, поэтому он удовлетворяет 1-wise coverage.
+
+**Попарное тестирование** (Pairwise testing)
+
+Pairwise testing - техника тест-дизайна, а именно метод обнаружения дефектов с использованием комбинационного метода из двух тестовых случаев. Он основан на наблюдениях о том, что большинство дефектов вызвано взаимодействием не более двух факторов (дефекты, которые возникают при взаимодействии трех и более факторов, как правило менее критичны). Следовательно, выбирается пара двух тестовых параметров, и все возможные пары этих двух параметров отправляются в качестве входных параметров для тестирования. Pairwise testing сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Захватывающей надеждой попарного тестирования является то, что путем создания и запуска 1-20% тестов вы найдете 70-85% от общего объема дефектов.
+
+Пример: По ТЗ сайт должен работать в 8 браузерах, используя различные плагины, запускаться на различных клиентских операционных системах, получать страницы от разных веб-серверов, работать с различными серверными, операционными системами. Итого:
+
+* 8 браузеров;
+* 3 плагина;
+* 6 клиентских операционных систем;
+* 3 сервера;
+* 3 серверных операционных системы;
+
+\= 1296 комбинаций. Количество комбинаций настолько велико, что, скорее всего, у нас не хватит ресурсов, чтобы спроектировать и пройти тест-кейсы. Не следует пытаться проверить все комбинации значений для всех переменных, а нужно проверять комбинации пар значений переменных.
+
+Использование всех пар для создания тест-кейсов основывается на двух техниках:
+
+* ортогональные массивы (OA - Orthogonal Array): это двумерный массив символов. На примере выше мы составляем таблицу, где столбцы представляют собой переменные (браузер, плагин, клиентская операционная система, веб-сервер и серверная операционная система, а строки - значения каждой переменной (Chrome/Opera, Windows 8/10/11 и т.п.). После чего нужно определить ортогональный массив, у которого будет столбец для каждой переменной (каждый столбец ортогонального массива имеет столько же вариантов значений, сколько имеет ваша переменная). Используя ортогональный массив для примера выше, все пары всех значений всех переменных могут быть покрыты всего лишь 64-мя тестами.
+* алгоритм Allpairs: генерирует пары непосредственно, не прибегая к таким к ортогональным массивам. "Несбалансированный" характер алгоритма выбора всех пар требует только 48 тестов для примера. Следует отметить, что комбинации, выбранные методом ортогонального массива, могут быть не такими же, как те, которые выбраны Allpairs. Но это не важно. Важно лишь то, чтобы были выбраны все парные комбинации параметров. Это будут комбинации, которые мы хотим проверить.
+
+Подробнее с разбором примера см. у Копленда в главе 6.
+
+На практике же вручную эти массивы никто не формирует, всю механику реализуют автоматизированные инструменты, самый популярный из них PICT. Тестировщику остается лишь подготовить и скормить данные.
+
+**Classification tree method**
+
+_Метод дерева классификации (classification tree method): Разработка тестов методом черного ящика, в которой тестовые сценарии, описанные средствами дерева классификации, разрабатываются для проверки комбинаций выборок входных и/или выходных подмножеств. (Grochtmann) См. также комбинаторное тестирование._
+
+Дерево классификации (Classification tree): структура, показывающее иерархически упорядоченные классы эквивалентности, которое используется для разработки тестовых примеров в методе дерева классификации (Classification tree method). Не путать с [Decision tree](https://en.wikipedia.org/wiki/Decision\_tree).
+
+Метод дерева классификации: вид комбинаторной техники, в которой тестовые примеры, описанные с помощью дерева классификации, предназначены для выполнения комбинаций представителей входных и / или выходных доменов.
+
+
+
+Чтобы рассчитать количество тестовых примеров, нам необходимо проанализировать требования, определить соответствующие тестовые функции (классификации) и их соответствующие значения (классы).
+
+Обычно для создания Classification tree используется инструмент Classification Tree Editor. Если же взять лист бумаги и ручку, то у нас есть тестовый объект (целое приложение, определенная функция, абстрактная идея и т. д.) вверху как корень. Мы рисуем ответвления от корня как классификации (проверяем соответствующие аспекты, которые мы определили). Затем, используя классы эквивалентности и анализ граничных значений, мы определяем наши листья как классы из диапазона всех возможных значений для конкретной классификации. И если некоторые из классов могут быть классифицированы далее, мы рисуем под-ветку / классификацию с собственными листьями / классами. Когда наше дерево завершено, мы делаем проекции листьев на горизонтальной линии (Test case), используя одну из комбинаторных стратегий (all combinations, each choice и т. д.), и создаем все необходимые комбинации.
+
+Максимальное количество тестовых примеров - это декартово произведение всех классов всех классификаций в дереве, быстро приводящее к большим числам для реалистичных тестовых задач. Минимальное количество тестовых примеров - это количество классов в классификации с наиболее содержащимися классами. На втором этапе тестовые примеры составляются путем выбора ровно одного класса из каждой классификации дерева классификации.
+
+**Тестирование переходов между состояниями (State Transition testing)**
+
+_Таблица состояний (state table): Таблица, показывающая конечные переходы для каждого состояния вследствие каждого возможного события, как для корректных, так и для некорректных переходов. (ISTQB)_
+
+Тестирование переходов между состояниями определяется как метод тестирования ПО, при котором изменения входных условий вызывают изменения состояния в тестируемом приложении (AUT). В этом методе тестировщик предоставляет как положительные, так и негативные входные значения теста и записывает поведение системы. Это модель, на которой основаны система и тесты. Любая система, в которой вы получаете разные выходные данные для одного и того же ввода, в зависимости от того, что произошло раньше, является системой конечных состояний. Техника тестирования переходов между состояниями полезна, когда вам нужно протестировать различные системные переходы. Этот подход лучше всего подходит там, где есть возможность рассматривать всю систему как конечный автомат. Для наглядности возьмем классический пример покупки авиабилетов:
+
+
+
+* Состояние (state, представленное в виде круга на диаграмме) - это состояние приложения, в котором оно ожидает одно или более событий. Состояние помнит входные данные, полученные до этого, и показывает, как приложение будет реагировать на полученные события. События могут вызывать смену состояния и/или инициировать действия;
+* Переход (transition, представлено в виде стрелки на диаграмме) - это преобразование одного состояния в другое, происходящее по событию;
+* Событие (event, представленное ярлыком над стрелкой) - это что-то, что заставляет приложение поменять свое состояние. События могут поступать извне приложения, через интерфейс самого приложения. Само приложение также может генерировать события (например, событие «истек таймер»). Когда происходит событие, приложение может поменять (или не поменять) состояние и выполнить (или не выполнить) действие. События могут иметь параметры (например, событие «Оплата» может иметь параметры «Наличные деньги», «Чек», «Приходная карта» или «Кредитная карта»);
+* Действие (action, представлено после «/» в ярлыке над переходом) инициируется сменой состояния («напечатать билет», «показать на экране» и др.). Обычно действия создают что-то, что является выходными/возвращаемыми данными системы. Действия возникают при переходах, сами по себе состояния пассивны;
+* Точка входа обозначается черным кружком;
+* Точка выхода показывается на диаграмме в виде мишени;
+
+Все начинается с точки входа. Мы (клиенты) предоставляем авиакомпании информацию для бронирования. Служащий авиакомпании является интерфейсом между нами и системой бронирования авиабилетов. Он использует предоставленную нами информацию для создания бронирования. После этого наше бронирование находится в состоянии «Создано». После создания бронирования система также запускает таймер. Если время таймера истекает, а забронированный билет еще не оплачен, то система автоматически снимает бронь.
+
+Каждое действие, выполненное над билетом, и соответствующее состояние (отмена бронирования пользователем, оплата билета, получение билета на руки, и т. д.) отображаются в блок-схеме.
+
+На основании полученной схемы составляется набор тестов.
+
+Определим четыре разных уровня покрытия:
+
+1. Набор тестов, в котором все состояния будут посещены как минимум один раз. Этому требованию удовлетворяет набор из трех тестов, показанный ниже. Обычно это низкий уровень тестового покрытия.
+2. Набор тестов, в котором все события выполнятся как минимум один раз. Следует отметить, что тест-кейсы, которые покрывают каждое событие, могут быть точно теми же, которые покрывают каждое состояние. Опять же, это низкий уровень покрытия.
+3. Набор тестов, в котором все пути будут пройдены как минимум один раз. Несмотря на то, что этот уровень является наиболее предпочтительным из-за его уровня покрытия, это может быть неосуществимо. Если диаграмма состояний и переходов содержит петли, то количество возможных путей может быть бесконечным.
+4. Набор тестов, в котором все переходы будут осуществлены как минимум один раз. Этот уровень тестирования обеспечивает хороший уровень покрытия без порождения большого количества тестов. Этот уровень, как правило, один из рекомендованных.
+
+Диаграмма состояний и переходов - не единственный способ документирования поведения системы. Диаграммы, возможно, легче в понимании, но таблицы состояний и переходов могут быть проще в использовании на постоянной и временной основе. Таблицы состояний и переходов состоят из четырех столбцов - "Текущее состояние", "Событие", "Действие" и "Следующее состояние". Преимущество таблицы состояний и переходов в том, что в ней перечисляются все возможные комбинации состояний и переходов, а не только допустимые. При крайне необходимом тестировании систем с высокой степенью риска, например авиационной радиоэлектротехники или медицинских устройств, может потребоваться тестирование каждой пары состояние-переход, включая те, которые не являются допустимыми. Кроме того, создание таблицы состояний и переходов часто извлекает комбинации, которые не были определены, задокументированы или рассмотрены в требованиях. Очень полезно обнаружить эти дефекты до начала кодирования.
+
+Использование таблицы состояний и переходов может помочь обнаружить дефекты в реализации, которые позволяют недопустимые пути из одного состояния в другое. Недостатком таких таблиц является то, что, когда количество состояний и событий возрастает, они очень быстро становятся огромными. Кроме того, в таблицах, как правило, большинство клеток пустые.
+
+Подробнее с разбором примера см. у Копленда в главе 7.
+
+**Domain testing**
+
+_Анализ доменов (domain analysis): Методика разработки тестов, относящаяся к методу черного ящика, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно. Методика базируется и обобщает методы эквивалентного разбиения и анализа граничных значений/ (ISTQB)_
+
+В главах по тестированию классов эквивалентности и граничных значений мы рассмотрели тестирование одиночных переменных, которые требовали оценки в указанных диапазонах. В этой главе мы рассмотрим тестирование нескольких переменных одновременно. Существуют две причины, по которым стоит обратить на это внимание:
+
+* у нас редко будет достаточно времени на создание тест-кейсов для каждой переменной в нашей системе. Их просто слишком много;
+* часто переменные взаимодействуют. Значение одной переменной ограничивает допустимые значения другой. В этом случае, если проверять переменные поодиночке, можно не обнаружить некоторые дефекты;
+
+Domain-тестирование - это техника, которая может применяться для определения эффективных и действенных тест-кейсов, когда несколько переменных (например, поля ввода) должны проверяться вместе - либо для эффективности, либо по причине их логического взаимодействия. Она использует и обобщает тестирование классов эквивалентности и граничных значений в n одномерных измерениях. Подобно этим техникам, мы ищем случаи, где граница была неверно определена или реализована. Несмотря на то, что эта техника лучше всего подходит для числовых значений, она может быть обобщена и на другие типы - boolean, string, enumeration и т.д.
+
+В двухмерном измерении (с двумя взаимодействующими параметрами) могут возникнуть следующие дефекты:
+
+* сдвиг границы - граница, перемещённая вертикально или горизонтально;
+* направление границы - граница, повёрнутая под неправильным углом;
+* пропущенная граница;
+* лишняя граница
+
+
+
+Подробнее с разбором примера см. у Копленда в главе 8.
+
+**Use case-based Testing**
+
+_Сценарий использования системы (use case): Последовательность операций во взаимодействии актера и компонента или системы со значимым результатом, при которой актером может быть как пользователь, так и все, что может обмениваться информацией с системой. (ISTQB)_
+
+До сих пор мы исследовали техники разработки тестовых сценариев для частей системы - входные переменные с их диапазонами и границами, бизнес-правила, представленные в виде таблиц решений, а также поведения системы, представленные с помощью диаграмм состояний и переходов. Теперь пришло время рассмотреть тестовые сценарии, которые используют системные функции с начала и до конца путем тестирования каждой из их индивидуальных операций.
+
+Сегодня самым популярным подходом определения выполняемых системой операций является [диаграмма вариантов использования](https://habr.com/ru/post/566218/) (диаграмма прецедентов, Use case diagram). Как и таблицы решений и диаграммы состояний и переходов, диаграммы вариантов использования обычно создаются разработчиками для разработчиков. Но, как и другие техники, диаграммы вариантов использования содержат много полезной информации и для тестировщиков. Варианты использования были созданы Иваром Якобсоном и объяснены в его книге "Объектно-ориентированная разработка программ: подход, основанный на вариантах использования". Якобсон определил
+
+Вариант использования (Use Case) - это сценарий, который описывает использование системы действующим лицом для достижения определенной цели (Ивар Якобсон - "Объектно-ориентированная разработка программ: подход, основанный на вариантах использования").
+
+* Действующее лицо (или актер) - это пользователь, играющий роль с уважением к системе, старающегося использовать систему для достижения чего-то важного внутри конкретного контекста. Действующими лицами в основном являются люди, хотя действующими лицами также могут выступать другие системы;
+* "Сценарий" - это последовательность шагов, которые описывают взаимодействия между актером и системой. Заметьте, что варианты использования определены с точки зрения пользователя, а не системы. Заметьте также, что операции, выполняемые внутри системы, хоть и важны, но не являются частью определения вариантов использования. Набор вариантов использования составляет функциональные требования системы.
+
+Прежде чем использовать сценарии для создания Test case, их необходимо подробно описать с помощью шаблона. Шаблоны могут варьироваться от проекта к проекту. Но среди таких обычных полей, как имя, цель, предварительные условия, актер (ы) и т. д., всегда есть основной успешный сценарий и так называемые расширения (плюс иногда подвариации). Расширения - это условия, которые влияют на основной сценарий успеха. А подвариации - это условия, которые не влияют на основной flow, но все же должны быть рассмотрены. После того, как шаблон заполнен данными, мы создаем конкретные Test case, используя методы эквивалентного разделения и граничных значений. Для минимального охвата нам нужен как минимум один тестовый сценарий для основного сценария успеха и как минимум один Test case для каждого расширения. Опять же, этот метод соответствует общей формуле «получите условия, которые меняют наш результат, и проверьте комбинации». Но способ получить это - проанализировать поведение Системы с помощью сценариев.
+
+Польза вариантов использования в том, что они:
+
+* позволяют выявить функциональные требования системы с точки зрения пользователя несмотря на техническую перспективу и независимо от того, какая парадигма разработки использовалась;
+* могут быть использованы для активного вовлечения пользователей в процесс сбора требований и определений;
+* предоставляют базис для идентификации ключевых компонентов системы, структур, баз данных и связей;
+* служат основанием для разработки тест-кейсов системы на приемочном уровне.
+
+Подробнее с разбором примера см. у Копленда в главе 8.
+
+Как создать хорошие сценарии (Сэм Канер):
+
+1. Напишите истории жизни для объектов в системе.
+2. Перечислите возможных пользователей, проанализируйте их интересы и цели.
+3. Подумайте об отрицательных пользователях: как они хотят злоупотреблять вашей системой?
+4. Перечислите «системные события». Как система справляется с ними?
+5. Перечислите «особые события». Какие приспособления система делает для них?
+6. Перечислите преимущества и создайте сквозные задачи, чтобы проверить их.
+7. Интервью пользователей об известных проблемах и сбоях старой системы.
+8. Работайте вместе с пользователями, чтобы увидеть, как они работают и что они делают.
+9. Читайте о том, что должны делать подобные системы.
+10. Изучите жалобы на предшественника этой системы или ее конкурентов.
+11. Создать фиктивный бизнес. Относитесь к нему как к реальному и обрабатывайте его данные.
+12. Попробуйте преобразовать реальные данные из конкурирующего или предшествующего приложения.
+
+**Cause/Effect, Cause-Effect (CE)**
+
+_Таблица причинно-следственных решений (cause-effect decision table): См. таблица решений._
+
+_Таблица решений (decision table): Таблица, отражающая комбинации входных данных и/или причин с соответствующими выходными данными и/или действиям (следствиям), которая может быть использована для проектирования тестовых сценариев. (ISTQB)_
+
+Тестовые примеры должны быть разработаны так, чтобы проявлять принципы, которые характеризуют взаимосвязь между входными и выходными данными компонента, где каждый принцип соответствует единственной возможной комбинации входных данных компонента, которые были выражены как логические значения. Для каждого тестового примера следует уточнить:
+
+* Логическое состояние для каждого эффекта;
+* Логическое состояние (истина или ложь) по любой причине;
+
+Граф причинно-следственных связей (Cause-Effect Graph) использует такую модель логических взаимосвязей между причинами и следствиями для компонента. Каждая причина выражается как условие, которое может быть истинным, ложным на входе или комбинацией входных данных компонента. Каждый эффект выражается в виде логического выражения, представляющего результаты или комбинацию результатов для произошедшего компонента (?Every effect is expressed as a Boolean expression representing results, or a combination of results, for the component having occurred). Модель обычно представлена как логический граф, связывающий производные логические выражения ввода и вывода с использованием логических операторов:
+
+* И (AND);
+* ИЛИ (OR);
+* Истина, если не все входные данные верны («не оба») ([NAND](https://en.wikipedia.org/wiki/NAND\_gate));
+* Истина, когда ни один из входов не является истиной ("ни один") ([NOR](https://en.wikipedia.org/wiki/NOR\_gate));
+* НЕ (NOT).
+
+Cause-Effect Graph также известен как диаграмма Исикавы, поскольку он был изобретен Каору Исикава, или как диаграмма рыбьей кости из-за того, как он выглядит.
+
+
+
+Граф причинно-следственных связей похож на Decision Table и также использует идею объединения условий. И иногда они описываются как один метод. Но если между условиями существует много логических зависимостей, может быть проще их визуализировать на cause-effect graph.
+
+**Syntax testing**
+
+_Синтаксическое тестирование (syntax testing): Разработка тестов методом черного ящика, в которой тестовые сценарии строятся на основе области определения входящих и/или выходных значений. (ISTQB)_
+
+Синтаксическое тестирование используется для проверки формата и правильности входных данных в случаях символьных текстовых полей, проверки соответствия формату файла, схеме базы данных, протоколу и т.д., при этом данные могут быть формально описаны в технических или установленных и определенных обозначениях, таких как BNF ([Форма Бэкуса - Наура](https://ru.wikipedia.org/wiki/%D0%A4%D0%BE%D1%80%D0%BC%D0%B0\_%D0%91%D1%8D%D0%BA%D1%83%D1%81%D0%B0\_%E2%80%94\_%D0%9D%D0%B0%D1%83%D1%80%D0%B0)).
+
+
+
+Как правило, синтаксические тесты автоматизированы, так как они предполагают создание большого количества кейсов. Синтаксис тестируется с использованием двух условий:
+
+* Валидные: Проверка нормального состояния с использованием покрывающего набора путей синтаксического графа для минимально необходимых требований (?Testing the normal condition using the covering set of paths of the syntax graph, for the minimum necessary requirements). Иными словами находим возможные варианты значений, допускаемые отдельными элементами определения BNF, а затем разрабатываем кейсы, чтобы просто охватить эти варианты;
+* Невалидные: Проверка мусорных условий (garbage condition)\* с использованием недопустимого набора входных данных.
+
+Примечание \*: Мусорные условия - это метод проверки устойчивости системы к неверным или грязным данным. Условие выполняется путем предоставления в систему грязных данных (недопустимых данных), которые не поддерживаются указанным форматом и грамматикой синтаксиса. Для создания таких данных мы определяем и применяем возможные мутации (например, отсутствующий элемент, нежелательный дополнительный элемент, недопустимое значение для элемента и т. д.) к отдельным элементам определения BNF. Затем мы разрабатываем наши кейсы, применяя мутации, которые могут давать отличительные результаты (случаи, которые приводят к действительным комбинациям, исключаются).
+
+**Check List Based Testing**
+
+Тестирование на основе контрольного списка (чеклиста) выполняется с использованием предварительно подготовленного опытными тестировщиками чеклиста, который продолжает обновляться с учетом любых новых дефектов, обнаруженных при выполнении контрольных примеров контрольного списка. При любых изменениях в продукте прогоняется быстрый чеклист, чтобы убедиться, что из-за изменений не возникло новых дефектов. Этот контрольный список не имеет отношения к пользовательским историям.
+
+**User Journey Test**
+
+User Journey test, как следует из названия, охватывает полное путешествие пользователя по системе. Он охватывает сквозные тесты, из-за которых процент покрытия тестами больше по сравнению с другими методами. Этот метод помогает уменьшить количество тестовых примеров, поскольку тестовые примеры являются исчерпывающими и охватывают большую часть функциональности в одном сценарии. Сценарии написаны для самого сложного путешествия. Тесты взаимодействия с пользователем не связаны с пользовательскими историями (user stories).
+
+**User Story Testing (Agile)**
+
+Пользовательская история - это краткое и простое описание требований клиентов или конечного пользователя. Пользовательские истории написаны владельцем продукта (Product owner), поскольку именно он получает от клиента информацию о продукте, который будет создан. Если пользовательская история большая, она разбивается на несколько более мелких историй. Истории пользователей записываются на учетных карточках и вывешиваются на стене для обсуждения. Обсуждая важные аспекты функции, выберите те, которые в дальнейшем используются в пользовательской истории. Приемочные испытания - это заключительный этап, на котором продукт принимает заказчик после того, как он соответствует всем критериям выхода. Критерии приемлемости определяются владельцем продукта, заказчик на поставку также может привлекать разработчиков, определяя то же самое.
+
+**Exhaustive testing**
+
+_Исчерпывающее тестирование (exhaustive testing): Методика тестирования, в которой набор тестов включает в себя все комбинации входных данных и предусловий. (ISTQB)_
+
+Исчерпывающее тестирование (Exhaustive testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода почти всегда не представляется возможным, из-за огромного количества входных значений.
+
+Источники:
+
+* Ли Копланд - “A Practitioner's Guide to Software Test Design”, Главы 3-9
+* [Test Design Techniques overview](https://sysgears.com/articles/test-design-techniques-overview/)
+* [An Evaluation and comparison of practical results of Combination Strategies for Test Case Selection](https://cs.gmu.edu/\~offutt/rsrch/papers/evalcombstrat.pdf)
+* [Handling constraints in the input space when using combination strategies for software testing](https://www.researchgate.net/publication/228674683\_Handling\_constraints\_in\_the\_input\_space\_when\_using\_combination\_strategies\_for\_software\_testing)
+* [State Transition testing](https://quality-lab.ru/blog/roles-and-responsibilities-of-test-designer/)
+* [Classification Tree Method](https://en.wikipedia.org/wiki/Classification\_Tree\_Method)
+* [Black Box Test Techniques. Cause-Effect Graphing](https://blog.qatestlab.com/2011/09/13/black-box-test-techniques-cause-effect-graphing/)
+* [Syntax Testing](https://www.professionalqa.com/syntax-testing)
+* [Popular Software Testing Techniques With Examples](https://www.softwaretestinghelp.com/software-testing-techniques-2)
+
+Доп. материал:
+
+* [Тестирование областей определения или классы эквивалентности + анализ граничных значений + pairwise](https://habr.com/ru/amp/post/270909/)
+* [Классы эквивалентности](https://www.youtube.com/watch?v=MacODm0nh9o)
+* [Классы эквивалентности для населенных пунктов в адресах](https://okiseleva.blogspot.com/2019/10/blog-post\_30.html)
+* [Классы эквивалентности для имен](https://okiseleva.blogspot.com/2019/10/blog-post\_20.html)
+* [Классы эквивалентности для строки, которая обозначает число](https://www.software-testing.ru/library/testing/functional-testing/1238-number-string-subdomains)
+* [Классы эквивалентности для строки, которая обозначает дату](http://okiseleva.blogspot.com/2018/04/blog-post\_14.html)
+* [Класс эквивалентности «Ноль-не ноль»](http://okiseleva.blogspot.com/2016/12/blog-post\_15.html)
+* [James Bach, Patrick J. Schroeder - “Pairwise Testing: A Best Practice That Isn’t”](http://www.testingeducation.org/wtst5/PairwisePNSQC2004.pdf)
+* [Paul Ammann & Jeff Offutt - “Input Space Partition Testing”](http://cc.ee.ntu.edu.tw/\~farn/courses/ST/slides/Ch4-ISP.pdf)
+* [Jeff Offutt & Sten F. Andler - “Combination Testing Strategies”](https://cs.gmu.edu/\~offutt/rsrch/papers/combstrat-survey.pdf)
+* [Тестировщик с нуля / Урок 9. Техники тест-дизайна. Классы эквивалентности и граничные значения](https://www.youtube.com/watch?v=HJPF5qJx7jg)
+* [Попарное тестирование / Pairwise testing / PICT для тестировщика](https://www.youtube.com/watch?v=-Lu27061BiY)
+* [Комбинаторное тестирование: примеры с PICT](https://habr.com/ru/company/infopulse/blog/261381/)
+* [Pairwise Testing - Обзор веб инструментов для попарного тестирования](https://www.youtube.com/watch?v=Lzr9gb8TyqE)
+* [Reducing Environment Combinations with Microsoft PICT](https://pragmatic-qa.com/pairwise-testing-with-pict/)
+* [Pairwise Testing](https://www.microsoft.com/en-us/research/wp-content/uploads/2017/01/160.pdf)
+* [Test Run - Pairwise Testing with QICT](https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/december/test-run-pairwise-testing-with-qict)
+* [Попарное тестирование: суть техники, инструменты и примеры](https://habr.com/ru/company/otus/blog/592575/)
+* [Cem Kaner - ”Introduction to Domain Testing”](https://bbst.courses/wp-content/uploads/2018/01/Kaner-Intro-to-Domain-Testing-2018.pdf)
+* [Шаблон Requirement Traceability Matrix](https://biconsult.ru/node/561)
+* [Cause-Effect Graph example](https://www.softwaretestingclass.com/what-is-cause-and-effect-graph-testing-technique/)
+* [https://app.diagrams.net/](https://app.diagrams.net)
+* [Decision Table - что это и как применять](https://habr.com/ru/post/546432/)
+* [State & Transition Diagram - что это и как применять](https://habr.com/ru/post/548192/)
+* [Тестирование состояний и переходов / Таблица принятия решений](https://www.youtube.com/watch?v=e84cyz2HC24)
+* [State Transition на примере тортика!](https://okiseleva.blogspot.com/2018/10/state-transition.html)
+* [Примеры диаграммы State Transition Testing](https://okiseleva.blogspot.com/2018/07/state-transition-testing.html)
+* [Как составлять вариант использования](https://okiseleva.blogspot.com/2015/11/blog-post\_86.html)
+* [Что такое use case? Теория и примеры](https://testengineer.ru/chto-takoe-use-case/)
diff --git a/test-dizain/dynamic-experience-based.md b/test-dizain/dynamic-experience-based.md
new file mode 100644
index 0000000..f9fe7ed
--- /dev/null
+++ b/test-dizain/dynamic-experience-based.md
@@ -0,0 +1,40 @@
+# Dynamic - Experience based
+
+**Error Guessing**;
+
+_Предположение об ошибках (EG - error guessing): Метод проектирования тестов, когда опыт тестировщика используется для предугадывания того, какие дефекты могут быть в тестируемом компоненте или системе в результате сделанных ошибок, а также для разработки тестов специально для их выявления. (ISTQB)_
+
+Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
+
+Некоторые факторы использующиеся при Error Guessing:
+
+* Уроки, извлеченные из прошлых релизов;
+* Исторические знания;
+* Интуиция;
+* Тикеты с прода;
+* Review checklist;
+* Пользовательский интерфейс приложения;
+* Отчеты о рисках программного обеспечения;
+* Тип данных, используемых для тестирования;
+* Общие правила тестирования;
+* Результаты предыдущих тестов;
+* Знание об AUT (тестируемое приложение);
+
+**Исследовательское тестирование** (Exploratory testing);
+
+См. в видах тестирования
+
+**Ad-hoc testing**;
+
+См. в видах тестирования
+
+**Attack Testing**;
+
+_Атака (attack): Направленная и нацеленная попытка оценить качество, главным образом надежность, объекта тестирования за счет попыток вызвать определенные отказы. См. также негативное тестирование. (ISTQB)_
+
+\_Тестирование на основе атак (attack-based testing): Методика тестирования на основе опыта, использующая программные атаки с целью провоцирования отказов, в частности - отказов, связанных с защищенностью. (ISTQB) \_
+
+Источник:
+
+[How Error Guessing Testing Benefit in Software Testing](https://medium.com/@appsierra/how-error-guessing-testing-benefit-in-software-testing-bdbd076fea33)
+
diff --git a/test-dizain/dynamic-white-box.md b/test-dizain/dynamic-white-box.md
new file mode 100644
index 0000000..2f6e98a
--- /dev/null
+++ b/test-dizain/dynamic-white-box.md
@@ -0,0 +1,127 @@
+# Dynamic - White box
+
+_Разработка тестов методом белого ящика (white-box test design technique): Процедура разработки или выбора тестовых сценариев на основании анализа внутренней структуры компонента или системы. (ISTQB)_
+
+_Основанные на структуре методы проектирования тестирования используются для получения контрольных примеров из структурной характеристики, например структуры исходного кода или структуры меню. Если эти методы применяются к исходному коду приложения, то ожидаемые результаты для контрольных примеров получаются из базиса тестирования. Выбор, какие из основанных на структуре методов проектирования тестирования использовать в каждом конкретном случае, зависит от природы базиса тестирования и от присущих рисков. (ГОСТ 56920)_
+
+_Поток данных (data flow): Абстрактное представление последовательности и возможных изменений состояния объектов данных, при котором состояние объекта это: создание, использование либо уничтожение. (Beizer)_
+
+_Поток управления (control flow): Последовательность событий (путей) в процессе выполнения компонента или системы. (ISTQB)_
+
+**Динамическое тестирование методом белого ящика** - это стратегия, основанная на внутренних путях, структуре и реализации тестируемого программного обеспечения. Тесты здесь выполняются динамически, т.е. с запуском объекта тестирования и основаны на различных видах покрытии кода (путей исполнения программы).
+
+Глобально основных техник динамического тестирования методом белого ящика всего две:
+
+1. **Тестирование потока управления** (Control Flow Testing);
+2. **Тестирование потока данных** (Data Flow Testing).
+
+Фактически, это динамическая часть одного цельного тестирования, статическая часть которого - анализ и построение графа, описывается в предыдущей теме про статический анализ, а на этом определяется целевое покрытие (Coverage Target), создаются соответствующие тест-кейсы, тесты исполняются и результаты выполнения тестов анализируются.
+
+1. **Уровни тестового покрытия в тестировании потока управления**
+
+Под “покрытием" имеется в виду отношение объема кода, который уже был проверен, к объему, который осталось проверить. В тестировании потока управления покрытие определяется в виде нескольких различных уровней. Заметим, что эти уровни покрытия представлены не по порядку. Это потому, что в некоторых случаях проще определить более высокий уровень покрытия, а затем определить более низкий уровень покрытия в условиях высокого.
+
+**100% покрытие операторов** (Statement/node coverage). Оператор (statement) - это сущность языка программирования, обычно являющаяся минимальным неделимым исполняемым блоком (ISTQB). Покрытие операторов - это метод проектирования тестов методом белого ящика, который включает в себя выполнение всех исполняемых операторов (if, for и switch) в исходном коде как минимум один раз. Процентное отношение операторов, исполняемых набором тестов, к их общему количеству является метрикой покрытия операторов. Борис Бейзер написал: "тестирование, меньшее чем это (100% покрытие операторов), для нового программного обеспечения является недобросовестным и должно быть признано преступлением. …”. Несмотря на то, что это может показаться разумной идеей, на таком уровне покрытия может быть пропущено много дефектов и затруднен анализ покрытия некоторых управляющих структур. Покрытие операторов позволяет найти:
+
+* Неиспользованные выражения (Unused Statements);
+* Мертвый код (Dead Code);
+* Неиспользуемые ветви (Unused Branches);
+* Недостающие операторы (Missing Statements);
+
+**100% покрытие альтернатив/ветвей** (Decision/branch/all-edges/basis path/DC/C2/ decision-decision-path/edge coverage). «Решение» - это программная точка, в которой control flow имеет два или более альтернативных маршрута (ветви). На этом уровне достаточно такого набора тестов, в котором каждый узел с ветвлением (альтернатива), имеющий TRUE или FALSE на выходе, выполняется как минимум один раз, таким образом, для покрытия по веткам требуется как минимум два тестовых примера. На данном уровне не учитываются логические выражения, значения компонент которых получаются вызовом функций. В отличие от предыдущего уровня покрытия данный метод учитывает покрытие условных операторов с пустыми ветками. Покрытие альтернатив не гарантирует покрытие всех путей, но при этом гарантирует покрытие всех операторов;
+
+Для более полного анализа компонент условий в логических операторах существуют следующие три метода, учитывающих структуру компонент условий и значения, которые они принимают при выполнении тестовых примеров.
+
+**100% покрытие условий** (Condition/Toggle Coverage). Рассматриваются только выражения с логическими операндами, например, AND, OR, XOR. На этом уровне достаточно такого набора тест-кейсов, в котором каждое условие, имеющее TRUE и FALSE на выходе, выполнено как минимум один раз. Покрытие условий обеспечивает лучшую чувствительность к control flow, чем decision coverage. Для обеспечения полного покрытия по данному методу каждая компонента логического условия в результате выполнения тестовых примеров должна принимать все возможные значения, но при этом не требуется, чтобы само логическое условие принимало все возможные значения, т.е. Condition Coverage не дает гарантии полного decision coverage;
+
+\*\*100% покрытие условий + альтернатив \*\*(Decision + Condition coverage). На этом уровне тест-кейсы создаются для каждого условия и для каждой альтернативы, т.е. данный метод сочетает требования предыдущих двух методов - для обеспечения полного покрытия необходимо, чтобы как логическое условие, так и каждая его компонента приняла все возможные значения;
+
+**100% покрытия множественный условий** (Multiple condition coverage). Для выявления неверно заданных логических функций был предложен метод покрытия по всем условиям. При данном методе покрытия должны быть проверены все возможные наборы значений компонент логических условий: условий, альтернатив и условий/альтернатив. Т.е. в случае n компонент потребуется 2^n тестовых примеров, каждый из которых проверяет один набор значений. Тесты, необходимые для полного покрытия по данному методу, дают полную таблицу истинности для логического выражения. Несмотря на очевидную полноту системы тестов, обеспечивающей этот уровень покрытия, данный метод редко применяется на практике в связи с его сложностью и избыточностью. Еще одним недостатком метода является зависимость количества тестовых примеров от структуры логического выражения. Кроме того, покрытие множественных условий не гарантирует покрытие всех путей;
+
+**Покрытие бесконечного числа путей**. Если, в случае зацикливания, количество путей становится бесконечным, то имеет смысл существенно их сократить, ограничив количество циклов выполнения, что позволит уменьшить количество тестовых случаев. Первый вариант - не выполнять цикл совсем; второй - выполнить цикл один раз; третий - выполнить цикл n раз, где n - это небольшое значение, представляющее символическое количество повторений цикла; четвертый - выполнить цикл m раз, где m - максимальное количество повторений цикла. Кроме того, можно выполнить цикл m-1 и m+1 раз. Перед тем, как начинать тестирование потока управления, должен быть выбран соответствующий уровень покрытия;
+
+\*\*100% покрытие путей \*\*(Path coverage). Проверяет каждый линейно независимый путь в программе, что означает, что число тестовых примеров будет эквивалентно цикломатической сложности программы. Для кода модулей без циклов количество путей, как правило, достаточно мало, поэтому на самом деле можно построить тест-кейсы для каждого пути. Для модулей с циклами количество путей может быть огромным, что представляет неразрешимую проблему тестирования.
+
+Путь на самом деле является направлением, потоком выполнения, который следует за последовательностью инструкций. Он охватывает функцию от входа до точки выхода. Он охватывает statement, branch/decision coverage. Покрытие пути можно понять в следующих терминах:
+
+* **Loop coverage**: используется для проверки того, что все циклы были выполнены и сколько раз они были выполнены. Цель этого метода покрытия - убедиться, что циклы соответствуют предписанным условиям и не повторяются бесконечно и не завершаются ненормально. Цикл тестирования направлен на мониторинг от начала до конца цикла. Ценным аспектом этой метрики является определение того, выполняются ли циклы while и for более одного раза, т.к. эта информация не сообщается другими метриками;
+* **Function coverage**: показывает, вызывали ли вы каждую функцию или процедуру;
+* **Call coverage**: показывает, выполняли ли вы каждый вызов функции. Гипотеза состоит в том, что ошибки обычно возникают в интерфейсах между модулями (вызывающая функция и вызываемая функция). Также известен как покрытие пары вызовов (call pair coverage);
+
+7 вышеперечисленных уровней описываются в книге Копленда “A Practitioner's Guide to Software Test Design”, но можно найти и другие
+
+**FSM coverage (Finite State Machine Coverage)**
+
+Конечные автоматы (FSM) имеют конечное число состояний, условий, которые приводят к внутренним переходам между состояниями, и соответствующее поведение ПО в каждом состоянии автомата. Автомат обычно моделирует поведение управляющей логики.
+
+Покрытие FSM - покрытие конечного автомата, безусловно, является наиболее сложным методом покрытия кода. В этом методе покрытия вам нужно посмотреть, как много было переходов/посещений определенных по времени состояний (time-specific states). Оно также проверяет, сколько последовательностей включено в конечный автомат. Конечные автоматы могут иметь множество ветвей и несколько функциональных путей, а также любой скрытый путь (функциональный путь, пропущенный при проверке, или путь, непреднамеренно введенный на этапе реализации) в дизайне может вызвать серьезное нарушение функциональности, а также может создать тупик (система не может самостоятельно выйти из определенного состояния, даже если намеченный стимул присутствует).
+
+**Basis Path testing**
+
+Цель тестирования базового пути - в отличии от D-D Path (Decision-to-decision path) получить полное покрытие тех путей, которые находятся между точками принятия решений (decisions points) с высоким бизнес-риском и высокой бизнес-ценностью, т.к. проверять все возможные пути обходится слишком дорого. Это гибрид branch testing и path testing
+
+**LCSAJ coverage**
+
+_LCSAJ (LCSAJ): Последовательность линейного кода с переходами, состоящая из трех элементов (условно определяемая номерами строк исходного кода):_
+
+* _начало линейной последовательности выполняемых операторов_
+* _конец линейной последовательности_
+* _целевая строка кода, получающая управление после конца линейной последовательности_
+
+_(ISTQB)_
+
+LCSAJ (linear code sequence and jump) «линейная последовательность кода и переход». Каждый LCSAJ представляет собой сегмент кода, который выполняется последовательно от начальной точки до конечной точки, а затем прерывает последовательный поток для передачи потока управления. Каждая строка кода имеет плотность (density), то есть количество раз, когда номер строки появляется в LCSAJ.
+
+Один LCSAJ состоит из трех компонентов:
+
+* Начало сегмента, который может быть ветвью или началом программы;
+* Конец сегмента, который может быть концом ветви или концом программы;
+* Конкретная целевая линия;
+
+Его основное применение при динамическом анализе программного обеспечения, чтобы помочь ответить на вопрос «Сколько тестирования достаточно?». Динамический анализ программного обеспечения используются для измерения качества и эффективности тестовых данных программного обеспечения, где количественное определение выполняются в терминах структурных единиц кода при тестировании. В более узком смысле, LCSAJ является хорошо определенным линейным участком кода программы. При использовании в этом смысле, LCSAJ также называют JJ-путь (jump-to-jump path). 100% LCSAJ означает 100% Statement Coverage, 100% Branch Coverage, 100% procedure или Function call Coverage, 100% Multiple condition Coverage (в ISTQB говорится только о 100% Decision coverage).
+
+Определенные метрики используются для проверки покрытия кода. Эти показатели могут помочь нам определить, достаточно ли тестирования или нет. Эти показатели называются коэффициентом эффективности тестирования (TER - Test Effectiveness Ratio):
+
+* TER-1: количество операторов, выполненных с помощью тестовых данных, деленное на общее количество операторов;
+* TER-2: количество ветвей потока управления, выполненных тестовыми данными, деленное на общее количество ветвей потока управления;
+* TER-3: количество LCSAJ, выполненных тестовыми данными, деленное на общее количество LCSAJ;
+
+Исследователи ссылаются на коэффициент покрытия путей длиной n LCSAJ как на коэффициент эффективности теста (TER) n + 2.
+
+**2. Data Flow Testing**
+
+Тестирование потока данных - это еще один набор методов / стратегий белого ящика, который связан с анализом потока управления, но с точки зрения жизненного цикла переменной. Переменные определяются, используются и уничтожаются, когда в них больше нет необходимости. Аномалии в этом процессе, такие как использование переменной без ее определения или после ее уничтожения, могут привести к ошибке. Рапс и Вьюкер, популяризаторы данного метода, писали: "Мы уверены, что, как нельзя чувствовать себя уверенным в программе без выполнения каждого ее оператора в рамках какого-то тестирования, так же не следует быть уверенным в программе без видения результатов использования значений, полученных от любого и каждого из вычислений".
+
+Когда «поток данных» через информационную систему представлен графически, он известен как диаграмма потока данных (Data Flow Diagram). Она также используется для визуализации обработки данных. Но не нужно путать это с графом потока данных (Data Flow Graph), который используется в Data Flow Testing. Граф потока данных похож на граф потока управления тем, что показывает поток обработки через модуль. Дополнительно к этому, он детализирует определение, использование и уничтожение каждой из переменных модуля. Мы построим эти диаграммы и убедимся, что шаблоны определение-использование-уничтожение являются подходящими. Сначала мы проведем статический анализ. Под "статическим" мы имеем в виду, что мы исследуем диаграмму (формально через проверки или неформально беглыми просмотрами). Потом мы проведем динамические тесты модуля. Под "динамическими" мы понимаем, что мы создаем и исполняем тестовые сценарии.
+
+Так как тестирование потока данных основано на потоке управления модуля, то, предположительно, поток управления в основном верный. Процесс тестирования потока данных сводится к выбору достаточного количества тестов, таких как:
+
+* каждое "определение" прослеживается для каждого его "использования";
+* каждое "использование" прослеживается из соответствующего ему "определения";
+
+Чтобы сделать это, перечислим маршруты в модуле. Порядок выполнения такой же, как и в случае с тестированием потока управления: начинаем с точки входа в модуль, строим самый левый маршрут через весь модуль и заканчиваем на выходе из него. Возвращаемся в начало и идём по другому направлению в первом разветвлении. Прокладываем этот путь до конца. Возвращаемся в начало и идём по другому направлению во втором разветвлении, потом в третьем и т.д., пока не пройдем все возможные пути. Затем создадим хотя бы один тест для каждой переменной, чтобы покрыть каждую пару определение-использование.
+
+Существуют условные обозначения, которые могут помочь в описании последовательных во времени пар в жизненном цикле переменной:
+
+* \~ - переменная еще не существует или предыдущий этап был последним
+* d - определено, создано, инициализировано
+* k - не определено, убито
+* u - используется (c - использование вычислений; p - использование предикатов)
+
+Таким образом, \~ d, du, kd, ud, uk, uu, k \~, u \~ являются вполне допустимыми комбинациями, когда \~ u, \~ k, dd, dk, kk, ku, d \~ являются аномалиями, потенциальными или явными ошибками. В настоящее время практически все они эффективно обнаруживаются компиляторами или, по крайней мере, IDE, и нам редко требуется выполнять статический анализ для обнаружения этих аномалий. То же самое относится и к динамическому анализу, который сфокусирован на исследовании / выполнении du пар - современные языки программирования снижают вероятность возникновения проблем, связанных с du. Так что в настоящее время такая проверка в основном не стоит усилий.
+
+Источники:
+
+* [Software Testing Techniques](https://www.geeksforgeeks.org/software-testing-techniques/)
+* Ли Копланд - “A Practitioner's Guide to Software Test Design”, Главы 10 и 11
+* [НОУ Интуит - Лекция 4: Тестирование программного кода (покрытия)](https://intuit.ru/studies/courses/1040/209/lecture/5390?page=3)
+* [Code Coverage Tutorial: Branch, Statement, Decision, FSM](https://www.guru99.com/code-coverage.html)
+* [Statement, Branch, and Path Coverage Testing](https://www.professionalqa.com/statement-branch-path)
+* [What is the difference between dd-path testing and basis path testing (both aims branch coverage)?](https://www.quora.com/What-is-the-difference-between-dd-path-testing-and-basis-path-testing-both-aims-branch-coverage)
+* [Linear code sequence and jump](https://en.wikipedia.org/wiki/Linear\_code\_sequence\_and\_jump)
+* [What is LCSAJ Testing?](https://www.educative.io/edpresso/what-is-lcsaj-testing)
+
+Доп. материал:
+
+* [dynamic analysis tools](https://github.com/analysis-tools-dev/dynamic-analysis)
+* [НОУ Интуит - Лекция 4: Метод MC/DC для уменьшения количества тестовых примеров при 3-м уровне покрытия кода + Анализ покрытия](https://intuit.ru/studies/courses/1040/209/lecture/5390?page=4)
diff --git a/test-dizain/static-reviews.md b/test-dizain/static-reviews.md
new file mode 100644
index 0000000..3bb8986
--- /dev/null
+++ b/test-dizain/static-reviews.md
@@ -0,0 +1,53 @@
+# Static - Reviews
+
+_Рецензирование (review): Оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. Примерами рецензирования могут служить: управленческое рецензирование, неформальное рецензирование, технический анализ, инспекция и разбор. (ISTQB)_
+
+_Неформальное рецензирование (informal review): Рецензирование, которое не основано на формальной (документированной) процедуре. (ISTQB)_
+
+_Разбор (walkthrough): Пошаговый разбор, проводимый автором документа для сбора информации и обеспечения одинакового понимания содержания документа. (IEEE 1028)_
+
+_Равноправный анализ (peer review): Рецензирование разрабатываемого программного продукта, проводящееся сотрудниками компании-разработчика с целью нахождения дефектов и внесение улучшений. Примерами рецензирования являются: инспекция, технический анализ и разбор. (ISTQB)_
+
+_Инспекция (inspection): Тип равноправного анализа, основанный на визуальной проверке документов для поиска ошибок. Например, нарушение стандартов разработки и несоответствие документации более высокого уровня. Наиболее формальная методика рецензирования и поэтому всегда основывается на документированной процедуре. (IEEE 610, IEEE 1028). См. также равноправный анализ._
+
+Методы статического тестирования делятся на две основные категории, одной из которых являются ревью. Ранжирование по уровню формальности:
+
+
+
+**Экспертные обзоры** (Peer Reviews): Рецензирование - это стандартизированный метод проверки правильности исходного кода при разработке программного обеспечения, который проводится для выявления дефектов на ранних этапах жизненного цикла и которые не могут быть обнаружены с помощью методов тестирования черного ящика.
+
+**Прохождение/просмотр/пошаговый разбор** (walkthrough ): это метод проведения неформального группового / индивидуального просмотра. В walkthrough автор описывает и объясняет рабочий продукт на неформальной встрече своим коллегам или руководителю, чтобы получить обратную связь. Здесь проверяется применимость предложенного решения для рабочего продукта. Либо рабочий продукт проверяется на наличие дефектов несколькими лицами, кроме человека, который его фактически произвел;
+
+**Технический обзор** (Technical Review): Это метод более высокого уровня по сравнению с inspection или walkthrough, поскольку он также включает в себя управление. Этот метод используется для оценки (assess and evaluate) продукта путем проверки его соответствия стандартам разработки, руководствам и спецификациям. У него нет определенного процесса, и большая часть работы выполняется модератором, как описано ниже:
+
+* Модератор собирает и раздает материал и документацию всем членам команды;
+* Модератор также готовит набор показателей для оценки продукта в соответствии со спецификациями и уже установленными стандартами и гайдлайнами:
+ * последовательность;
+ * документация;
+ * соблюдение стандартов;
+ * полнота;
+ * определение проблемы и требования (? problem definition and requirements);
+* Результаты фиксируются в документе, который включает как дефекты, так и предложения;
+* Наконец, устраняются дефекты и учитываются предложения по улучшению продукта;
+
+**Инспекция**: Инспекция определяется как наиболее формальная, тщательная, глубокая групповая проверка, направленная на выявление проблем как можно ближе к их исходной точке. Процесс проверки выполняется на ранних этапах SDLC и применяется к определенной части продукта, такой как SRS, код, дизайн продукта. и т. д. Это включает в себя ручное изучение различных компонентов продукта на более ранних этапах. Инспекционная деятельность следует определенному процессу, и участники играют четко определенные роли. Инспекционная группа состоит из трех-восьми человек, которые играют роли модератора, автора, читателя, записывающего и инспектора. Например, разработчик может выступать в качестве инспектора во время проверки кода, в то время как представитель по обеспечению качества может действовать как исполнитель стандартов.
+
+Software inspection process:
+
+* Планирование встречи: на этом этапе основное внимание уделяется определению продукта, подлежащего инспекции, и цели этой инспекции. На этом этапе назначается модератор, который управляет всем процессом. Назначенный модератор проверяет, готов продукт к инспекции или нет. Модератор также выбирает инспекционную группу и назначает им их роли. Модератор также планирует инспекционную встречу и раздает необходимые материалы инспекционной группе;
+* Обзор: на этом этапе инспекционной группе предоставляется вся справочная информация для инспекционного совещания. Автор, который является программистом или дизайнером, ответственным за разработку продукта, представляет свою логику и рассуждения о продукте, включая функции продукта, его предполагаемое назначение и подход или концепцию, использованные при его разработке. Удостоверяется, что каждый член инспекционной группы понял и знаком с задачами и целью инспекционного совещания, которое должно быть проведено;
+* Индивидуальная подготовка участников: на этом этапе члены инспекционной группы индивидуально готовятся к инспекционной встрече, изучая материалы, предоставленные на более ранних этапах. Члены команды выявляют потенциальные ошибки или недочеты в продукте и записывают их в журнал. Журнал передается модератору. Затем модератор собирает все журналы, полученные от участников, и отправляет их автору. Инспектор - лицо, ответственное за проверку и выявление ошибок и несоответствий в документах или программах, проверяет продукт и записывает все обнаруженные в нем проблемы (как общие, так и специфические). Инспектор записывает проблемы или issues в журнал вместе со временем, затраченным на подготовку. Модератор просматривает логи, чтобы проверить, готова ли команда к инспекционной встрече или нет. Наконец, модератор отправляет автору все скомпилированные логи;
+* Инспекционная встреча (Inspection Meeting): на этом этапе автор обсуждает вопросы, поднятые членами команды в скомпилированном журнале. Участники приходят к решению, является ли поднятый вопрос ошибкой или нет. Модератор завершает встречу и подводит итоги встречи - это список ошибок, обнаруженных в продукте, которые должен устранить автор.
+* Переделка: доработка проводится автором согласно сводному списку, представленному модератором на предыдущем этапе. Автор исправляет все ошибки и сообщает модератору;
+* Follow - up: модератор проверяет, все ли ошибки устранены или нет. Затем модератор готовит отчет. Если все ошибки исправлены и устранены, модератор выпускает документ. В противном случае в отчет добавляются нерешенные вопросы и назначается еще одно инспекционное собрание;
+
+
+
+Источники:
+
+* [Podlodka #251 - Peer Review](https://www.youtube.com/watch?v=1bnIA1c3\_30)
+* [Best practices to make your QA meetings more effective](https://blog.qatestlab.com/2021/10/20/make-meetings-effective/)
+* [Software Testing Techniques](https://www.geeksforgeeks.org/software-testing-techniques/)
+* [Types of Static Testing](https://www.geeksforgeeks.org/types-of-static-testing/)
+* [Explain peer review](https://softwaretestingguide.blogspot.com/2007/09/explain-peer-review-in-software-testing.html)
+* [Static Testing Techniques](https://www.educba.com/static-testing-techniques/)
diff --git a/test-dizain/static-static-analysis.md b/test-dizain/static-static-analysis.md
new file mode 100644
index 0000000..09940ad
--- /dev/null
+++ b/test-dizain/static-static-analysis.md
@@ -0,0 +1,109 @@
+# Static - Static Analysis
+
+_Статический анализ (static analysis): Анализ артефактов разработки программного обеспечения, таких как требования или программный код, проводимый без исполнения этих программных артефактов. Статический анализ обычно выполняется при помощи вспомогательных инструментов. (ISTQB)_
+
+Статический анализ - это анализ программных артефактов, таких как программный код (или требования, дизайн), выполняемый статически, т.е. без запуска и, очевидно, методом белого ящика. Основная цель этого анализа - как можно раньше найти ошибки, независимо от того, могут ли они вызывать отказы (failures). Как и в случае с обзорами (reviews), статический анализ обнаруживает ошибки (bugs), а не отказы. Обычно статический анализ проводят до формальной проверки, даже до unit testing, путём добавления этих проверок специалистами DevOps в пайплайн проекта. Статический анализ не связан с динамическими свойствами требований, дизайна и кода, такими как покрытие тестами (test coverage). Существует множество инструментов для статического анализа, которые в основном используются разработчиками до или во время тестирования компонентов или интеграции (чаще новые и измененные классы и функции), а также дизайнерами во время моделирования программного обеспечения. Инструменты могут отображать не только структурные атрибуты, такие как глубина вложенности или число цикломатической сложности и проверка на соответствие стандартам кодирования, но также графические изображения потока управления, взаимосвязи данных и количество отдельных путей от одной строки кода к другой. Информация может использоваться вплоть до формальных методов, которые математически подтверждают свойства данной программы.
+
+Инструменты помогают в выявлении следующих дефектов:
+
+* Неиспользуемые переменные;
+* Части кода, которые никогда не выполнятся;
+* Бесконечные циклы;
+* Переменная с неопределенным значением;
+* Неправильный синтаксис;
+* Несогласованные интерфейсы между модулями и компонентами, такие как неправильное использование объекта, метода или функции, включая неправильные параметры;
+* Уязвимости безопасности, такие как проблемы безопасности, связанные с переполнением буфера, возникающим из-за невозможности проверить длину буфера перед копированием в буфер;
+* Различные типы нарушения стандартов программирования, как нарушения, создающие риск фактического сбоя, так и нарушения, которые усложняют тестирование, анализ и поддерживаемость кода;
+
+**Методы статического анализа**:
+
+* **Анализ управления** (Control Analysis): фокусируется на изучении элементов управления, используемых в структуре вызовов, анализе потока управления и анализе переходов состояний (calling structure, control flow analysis and state transition analysis). Структура вызова связана с моделью путем идентификации вызовов и их структуры. Вызывающая структура может быть процессом, подпрограммой, функцией или методом. Анализ потока управления проверяет последовательность передачи управления и может выявить неэффективные конструкции в модели. Создается граф модели (CFG - Control Flow Graph), в котором условные ветви и стыки модели представлены узлами. По итогам также можно рассчитать цикломатическую сложность программы. Для анализа потока управления [могут быть](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7\_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B0\_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F#:\~:text=%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%20%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B0%20%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-,%D0%BC%D0%BE%D0%B3%D1%83%D1%82%20%D0%B1%D1%8B%D1%82%D1%8C,-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D1%8B%3A%20%D0%90%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D0%B0%D1%8F%20%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D0%B5%D1%80%D1%82%D0%B0%D1%86%D0%B8%D1%8F) использованы: Абстрактная интерпретация, Удовлетворение ограничений, Типизация данных;
+* **Анализ данных** (Data Analysis): обеспечивает правильную работу с объектами данных, такими как структуры данных и связанные списки. Кроме того, этот метод также обеспечивает правильное использование определенных данных. Анализ данных включает два метода, а именно: зависимость данных и анализ потока данных (data dependency and data flow analysis). Зависимость данных необходима для оценки точности синхронизации между несколькими процессорами. Анализ потока данных проверяет определение и контекст переменных. Виды анализа потока данных:
+ * Reaching Definitions;
+ * Available Expressions;
+ * Constant Propagation;
+ * Very Busy Expressions;
+ * Live Variables;
+ * Use-Definition & Definition-Use;
+* Анализ неисправностей / отказов (Fault/Failure Analysis): анализирует неисправности (некорректный компонент) и отказ (некорректное поведение компонента модели) в модели. Этот метод использует описание преобразования ввода-вывода для определения условий, являющихся причиной сбоя. Для определения отказов в определенных условиях проверяется проектная спецификация модели (model design specification);
+* Анализ интерфейса (Interface Analysis): проверяет взаимодействующие и распределенные модели для проверки кода (This software verifies and verifies interactive and distribution simulations to check the code). Существует два основных метода анализа интерфейса, и анализ пользовательского интерфейса исследует интерфейсы подмоделей и определяет точность структуры интерфейса. Анализ пользовательского интерфейса исследует модель пользовательского интерфейса и меры предосторожности, предпринимаемые для предотвращения ошибок во время взаимодействия пользователя с моделью. Этот метод также фокусируется на том, насколько точно интерфейс интегрирован в общую модель и симуляцию.
+
+Анализ потока управления (Control Flow Analysis) и анализ потока данных (Data Flow Analysis) взаимозависимы: чтобы получить точные результаты для анализа потока данных, необходимо учитывать поток управления (поскольку порядок операций влияет на возможные значения данных в конкретном месте программы). Чтобы получить точные результаты для анализа потока управления, необходимо учитывать поток данных, поскольку поток динамического управления (решение, принимаемое во время выполнения) зависит от значений данных в конкретных местах программы. Однако эти два анализа преследуют разные цели.
+
+**Граф потока управления (Control Flow Graph)**
+
+Граф потока управления (CFG) - это графическое представление потока управления или вычислений во время выполнения программ или приложений. Графы потока управления в основном используются в статическом анализе, а также в приложениях-компиляторах, поскольку они могут точно представлять поток внутри программного модуля. Характеристики графа потока управления:
+
+* Граф потока управления процессно-ориентированный (process oriented);
+* Граф потока управления показывает все пути, которые можно пройти во время выполнения программы;
+* Граф потока управления - это [ориентированный](https://ru.wikipedia.org/wiki/%D0%9E%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9\_%D0%B3%D1%80%D0%B0%D1%84) граф;
+* Рёбра в CFG изображают пути потока управления, а узлы в CFG изображают базовые блоки.
+
+[Полное описание возможных элементов графа](https://ru.wikipedia.org/wiki/%D0%93%D1%80%D0%B0%D1%84\_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B0\_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F).
+
+**Цикломатическая сложность (Cyclomatic Complexity)**
+
+Цикломатическая сложность - это метрика для измерения сложности кода, основанная на графе потока управления. Независимый путь определяется как путь, имеющий хотя бы одно ребро, которое ранее не проходило ни в одном другом пути.
+
+Определение из книги Ли Копланда - “A Practitioner's Guide to Software Test Design”, Главы 10:
+
+Цикломатическая сложность - это конечное минимальное количество независимых, нецикличных маршрутов (называемых основными маршрутами), которые могут образовывать все возможные линейные пути в программном модуле.
+
+Цикломатическая сложность может быть рассчитана относительно функций, модулей, методов или классов в программе как вручную, так и с помощью автоматизированных инструментов.
+
+Математически цикломатическая сложность структурированной программы определяется с помощью ориентированного графа, узлами которого являются блоки программы, соединенные ребрами, если управление может переходить с одного блока на другой. Тогда сложность определяется как
+
+_M = E − N + 2P_,
+
+где:
+
+* M = цикломатическая сложность,
+* E = количество ребер в графе,
+* N = количество узлов в графе,
+* P = количество компонент связности.
+
+В другой формулировке используется граф, в котором каждая точка выхода соединена с точкой входа. В этом случае граф является сильносвязным, и цикломатическая сложность программы равна цикломатическому числу этого графа (также известному как первое число Бетти), которое определяется как
+
+_M = E − N + P_.
+
+Это определение может рассматриваться как вычисление числа линейно независимых циклов, которые существуют в графе, то есть тех циклов, которые не содержат в себе других циклов. Так как каждая точка выхода соединена с точкой входа, то существует по крайней мере один цикл для каждой точки выхода.
+
+Для простой программы, или подпрограммы, или метода P всегда равно 1. Однако цикломатическая сложность может применяться к нескольким таким программам или подпрограммам (например, ко всем методам в классе), в таком случае P равно числу подпрограмм, о которых идет речь, так как каждая подпрограмма может быть представлена как независимая часть графа.
+
+Может быть показано, что цикломатическая сложность любой структурированной программы с только одной точкой входа и одной точкой выхода эквивалентна числу точек ветвления (то есть, операторов if или условных циклов), содержащихся в этой программе, плюс один.
+
+Цикломатическая сложность может быть распространена на программу с многочисленными точками выхода; в этом случае она равна
+
+_π − s + 2_,
+
+где:
+
+* π - число точек ветвления в программе,
+* s - число точек выхода.
+
+Применение:
+
+* Ограничение сложности при разработке: одно из первоначально предложенных Маккейбом применений состоит в том, что необходимо ограничивать сложность программ во время их разработки. Он рекомендует, чтобы программистов обязывали вычислять сложность разрабатываемых ими модулей и разделять модули на более мелкие всякий раз, когда цикломатическая сложность этих модулей превысит 10. Эта практика была включена НИСТ-ом в методику структурного тестирования с замечанием, что со времени исходной публикации Маккейба выбор значения 10 получил весомые подтверждения, однако в некоторых случаях может быть целесообразно ослабить ограничение и разрешить модули со сложностью до 15. В данной методике признается, что иногда могут существовать причины для выхода за рамки согласованного лимита. Это сформулировано как рекомендация: «Для каждого модуля следует либо ограничивать цикломатическую сложность до согласованных пределов, либо предоставить письменное объяснение того, почему лимит был превышен»;
+* Применение при тестировании программного обеспечения: определение количества тестов, необходимых для полного покрытия кода. Цикломатическая сложность M имеет два свойства, для конкретного модуля:
+ * M - оценка сверху для количества тестов, обеспечивающих покрытие условий (точек ветвления);
+ * M - оценка снизу для количества маршрутов через граф потока управления и, таким образом, количества тестов для полного покрытия путей.
+* В составе других метрик: используется в качестве одного из параметров в индексе удобства сопровождения (англ. maintainability index).
+
+Источники:
+
+* [Types of Static Analysis Methods](https://www.geeksforgeeks.org/types-of-static-analysis-methods/)
+* [Software Testing - Static Testing](https://www.geeksforgeeks.org/software-testing-static-testing/)
+* [Static program analysis](https://en.wikipedia.org/wiki/Static\_program\_analysis)
+* [What is Static Analysis](https://www.educba.com/what-is-static-analysis/)
+* [Software Engineering - Control Flow Graph (CFG)](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/?ref=lbp)
+* [Цикломатическая сложность](https://ru.wikipedia.org/wiki/%D0%A6%D0%B8%D0%BA%D0%BB%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F\_%D1%81%D0%BB%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C)
+
+Доп. материал:
+
+* [Михаил Моисеев - “Формальные методы обеспечения качества ПО: Введение в статический анализ”](http://kspt.icc.spbstu.ru/media/files/2010/course/softwarequality/lec3.pdf)
+* [Y.N. Srikant - “Control Flow Analysis”](https://www.iith.ac.in/\~ramakrishna/fc5264/control-flow-analysis.pdf)
+* [Levels in Data Flow Diagrams (DFD)](https://www.geeksforgeeks.org/levels-in-data-flow-diagrams-dfd/)
+* [Control Flow Graph (CFG)](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/)
+* [Static analysis tools](https://github.com/analysis-tools-dev/static-analysis/blob/master/README.md)
+* [Podlodka #227 - Статический анализ кода](https://www.youtube.com/watch?v=S-ZRIKdZezQ)
+* [Архитектурное тестирование](https://habr.com/ru/post/590555/)
diff --git a/test-dizain/test-dizain-i-tekhniki-test-dizaina-test-design-and-software-testing-techniques.md b/test-dizain/test-dizain-i-tekhniki-test-dizaina-test-design-and-software-testing-techniques.md
new file mode 100644
index 0000000..cf3de39
--- /dev/null
+++ b/test-dizain/test-dizain-i-tekhniki-test-dizaina-test-design-and-software-testing-techniques.md
@@ -0,0 +1,124 @@
+# Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
+
+_Проектирование теста (test design): Процесс перевода общих причин тестирования в конкретные тестовые условия и тестовые сценарии. (ISTQB)_
+
+_Причина тестирования (test objective): Причина или цель разработки и выполнения теста. (ISTQB)_
+
+_Тестовое условие (test condition): Объект или событие в компоненте или системе, которое должно быть проверено одним или несколькими тестовыми наборами. Например: функция, транзакция, свойство, атрибут качества или структурный элемент. (ISTQB)_
+
+**Тест-дизайн** - важный этап STLС, а именно деятельность по получению и определению тестовых примеров из test objectives и test conditions. Проще говоря, цель тест-дизайна - создать максимально эффективный набор кейсов, покрывающий наиболее важные аспекты тестируемого ПО, т.е. минимизировать количество тестов, необходимых для нахождения большинства серьезных ошибок.
+
+Одним из наиболее важных аспектов теста является то, что он проверяет, выполняет ли система то, что она должна делать. Copeland говорит: “По сути, тестирование - это процесс сравнения того, что есть с тем, что должно быть”. Если мы просто введем какие-то данные и подумаем, что это было весело, я предполагаю, что с системой, вероятно, все в порядке, потому что она не крашнулась, но действительно ли мы ее тестируем? Beizer называет это «детским тестированием» (kiddie testing). Мы можем не знать каждый раз, какой правильный ответ в деталях, и иногда мы все равно можем получить некоторую выгоду от этого подхода, но на самом деле это не проверка. Чтобы знать, что система должна делать, нам нужен источник информации о правильном поведении системы - это называется «оракул» или тестовый оракул (test oracle). После того, как заданное входное значение было выбрано, тестировщику необходимо определить, каким будет ожидаемый результат ввода этого входа, и задокументировать его как часть тестового примера.
+
+Давайте проясним. Требования или пользовательские истории с критериями приемлемости (формы test basis) определяют, что вы должны тестировать (test objects and test conditions), и исходя из этого, вы должны выяснить способ тестирования, то есть спроектировать тестовые примеры. Один из наиболее важных вопросов заключается в следующем: какие факторы влияют на успешный дизайн теста? Если вы читаете разные блоги, статьи или книги, вы найдете примерно следующее:
+
+* Время и бюджет, доступные для тестирования;
+* Соответствующие знания и опыт вовлеченных людей;
+* Определен целевой уровень покрытия (измерение уровня достоверности (measuring the confidence level));
+* Способ организации процесса разработки программного обеспечения (например, водопад или гибкая разработка);
+* Устанавливается соотношение методов создания тестов (например, ручных и автоматических);
+
+Это неправда! Без достаточного времени и бюджета вы, вероятно, вообще не начнете ни одного проекта. Если у вас нет квалифицированных специалистов по тестированию программного обеспечения, включая дизайн тестов, то, вероятно, вы тоже не начнете проект. Однако, хороший дизайн теста включает три предварительных условия:
+
+* Полная спецификация (Complete specification)(test bases);
+* Анализ рисков и сложности (Risk and complexity analysis);
+* Исторические данные ваших предыдущих разработок;
+
+Требуются некоторые пояснения. Полная спецификация не означает безошибочную спецификацию, так как во время разработки теста можно найти и исправить множество проблем (предотвращение дефектов). Это только означает, что у нас есть все необходимые требования или в Agile разработке у нас есть все эпики, темы и пользовательские истории с критериями приемлемости (acceptance criteria). Существует минимальная ценность в одновременном рассмотрении затрат на тестирование и затрат на исправление дефектов, и цель хорошего тест-дизайна - выбрать подходящие методы тестирования, приближающиеся к этому минимуму. Это можно сделать, проанализировав сложность, риски и используя исторические данные. Таким образом, анализ рисков неизбежен для определения тщательности тестирования. Чем выше риск использования функции / объекта, тем более тщательное тестирование необходимо. То же самое можно сказать и о сложности кода. Для более рискованного или сложного кода мы должны сначала применить больше НЕкомбинаторных методов проектирования тестов вместо одного чисто комбинаторного.
+
+Наше другое и правильное представление о дизайне тестирования состоит в том, что если у вас есть соответствующая спецификация (тестовая база) и надежный анализ рисков и сложности, то, зная ваши исторические данные, вы можете выполнить дизайн теста оптимальным образом. Вначале у вас нет исторических данных, и вы, вероятно, не достигнете оптимума. Нет проблем, давайте сделаем предварительную оценку. Например, если риск и сложность низкие, используйте только исследовательское тестирование. Если они немного выше, используйте исследовательское тестирование и простые методы, основанные на спецификациях, такие как классы эквивалентности с анализом граничных значений. Если риск высок, вы можете использовать исследовательское тестирование, комбинационное тестирование, предотвращение дефектов, статический анализ и обзоры (reviews).
+
+Еще одно важное замечание. Критерии выбора тестов и адекватности тестовых данных различны. Первый - неотъемлемая часть любой техники тест-дизайна. Второй проверяет набор тестов. В результате процесса разработки тестов создаются независимые от реализации тестовые примеры, которые проверяют требования или пользовательские истории. Напротив, тесты, которые создаются на основе отсутствия покрытия по выбранным критериям адекватности тестовых данных, подтверждают проблемы, зависящие от реализации; однако это НЕ дизайн теста, это создание теста. Очень важно использовать метод «сначала тестирование» (test-first method), т. е. дизайн теста должен быть отправной точкой разработки. Дизайн тестов также очень эффективен для предотвращения дефектов, если он применяется до внедрения.
+
+Итак, хороший **процесс тест-дизайна** выглядит так:
+
+* Сбор информации, чтобы понять требования пользователей;
+* Получение всех важных бизнес-сценариев;
+* Создание тестовых сценариев для каждого производного критически важного бизнес-сценария;
+* Назначение всех запланированных тестовых сценариев различным тестовым случаям;
+
+Затем вам нужно будет выбрать технику тест-дизайна для каждого требования. На этом этапе, если все реализовано правильно, вы можете внести значительные изменения, которые чрезвычайно повлияют на ваш [ROI](https://ru.wikipedia.org/wiki/%D0%9E%D0%BA%D1%83%D0%BF%D0%B0%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C\_%D0%B8%D0%BD%D0%B2%D0%B5%D1%81%D1%82%D0%B8%D1%86%D0%B8%D0%B9).
+
+**Роли**, ответственные за тест дизайн:
+
+* **Тест аналитик** (test analyst) - определяет "ЧТО тестировать?":
+ * Исследует продукт:
+ * Понимание цели создания продукта;
+ * Какими способами цель должна достигаться;
+ * Какие и основные и вспомогательные возможности предоставляет продукт пользователям;
+ * Оценка, правильно ли понял разработчик заказчика.
+ * Составляет логическую карту продукта: Интеллект - карта - это техника представления любого процесса, события, мысли или идеи в систематизированной визуальной форме;
+ * Разбивает программный продукт на основные части:
+ * Система расчленяется только по одному, постоянному для всех уровней признаку (Они должны отвечать на один и тот же вопрос, по отношению к своему родителю);
+ * Вычленяемые подсистемы должны взаимно исключать друг друга, а в сумме - характеризовать систему;
+ * На каждом уровне рекомендуется использовать не более 7 подсистем;
+ * Расставляет приоритеты для тестирования:
+ * Требования клиента;
+ * Степень риска;
+ * Сложность системы;
+ * Временные ограничения;
+* **Тест дизайнер** - определяет "КАК тестировать?";
+
+Попросту говоря, задача тест аналитиков и дизайнеров сводится к тому, чтобы используя различные стратегии и техники тест дизайна, создать набор Test case, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. Однако, на большинстве проектов эти роли не выделяется, а доверяется обычным тестировщикам, что не всегда положительно сказывается на качестве тестов, тестировании и, как из этого следует, на качестве ПО (конечного продукта).
+
+**Техники тест-дизайна (Software testing techniques)**
+
+* Cтатические (Static):
+ * Reviews:
+ * Неформальное ревью (Informal review)
+ * Прохождение (Walkthrough)
+ * Техническое ревью (Technical Review)
+ * Инспекция (Inspection)
+ * Статический анализ (Static Analysis):
+ * Поток данных (Data Flow)
+ * Поток управления (Control Flow)
+ * Путь (Path)
+ * Стандарты (Standards)
+* Динамические (Dynamic):
+ * Белый ящик (White-box, Structure-Based)
+ * Выражение (Statement)
+ * Решение (Decision)
+ * Ветвь (Branch)
+ * Условие (Condition)
+ * Конечный автомат (FSM)
+ * Основанные на опыте (Experience-based):
+ * Предугадывание ошибки (Error Guessing - EG);
+ * Исследовательское тестирование (Exploratory testing);
+ * Ad-hoc testing;
+ * [Attack ](https://www.softwaretestinggenius.com/anatomy-of-various-types-of-experience-based-testing-techniques/)Testing;
+ * Черный ящик (Black-box, Specification-based):
+ * Эквивалентное Разделение (Equivalence Partitioning - EP)
+ * Анализ Граничных Значений (Boundary Value Analysis - BVA)
+ * Комбинаторные техники ([Combinatorial Test Techniques](https://sysgears.com/articles/test-design-techniques-overview/#combinatorial))
+ * Переходы между состояниями (State transition)
+ * Случаи использования (Use case testing)
+ * Domain testing
+ * Decision Table Testing
+ * Classification Tree Method
+ * State Transition Testing
+ * Cause-Effect Graphing
+ * Scenario Testing
+ * Random Testing
+ * Syntax Testing
+ * Check List Based Testing
+ * Risk-Based Testing
+ * User Journey Test
+
+Источники:
+
+* [What is Test design? or How to specify test cases?](https://tryqa.com/what-is-test-design-or-how-to-specify-test-cases/)
+* [What Is Test Design Actually?](https://dzone.com/articles/what-is-test-design-actually)
+* [Максим Дорофеев - Lecture 12. Test Design](https://en.ppt-online.org/220451)
+
+Доп. материал:
+
+* [Copeland Lee - “A Practitioner's Guide to Software Test Design”](https://www.amazon.com/Practitioners-Guide-Software-Test-Design/dp/158053791X) + [перевод](https://drive.google.com/file/d/1Wz5l6En9af4\_yz\_jQdI4DSM\_Y57SHSbF/view)
+* [Rikard Edgren - The little black book on test design](http://www.thetesteye.com/papers/TheLittleBlackBookOnTestDesign.pdf) + [перевод](https://www.software-testing.ru/images/stories/library/littleblackbookontestdesign.pdf)
+* [Test Design: A Survey of Black Box Software Testing Techniques](http://www.testingeducation.org/BBST/testdesign/) (видеолекции + доп.материалы)
+* Борис Бейзер - “Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем”
+* [Hillel - Техники тест-дизайна](https://www.youtube.com/watch?v=hJoChcIQFaE) (доклад с примерами)
+* [Лекция 3: Критерии выбора тестов](https://intuit.ru/studies/courses/48/48/lecture/1428)
+* [NIXMultiConf: Игорь Ямшанов - Приоритезация: начни с самого важного](https://www.youtube.com/watch?v=qkUCzvP-5mg\&t=20547s\&ab\_channel=NIX)
+* [Armando1514/Software-testing-techniques](https://github.com/Armando1514/Software-testing-techniques)
+* [The ABCs of Acceptance Test Design](https://dzone.com/articles/the-abcs-of-acceptance-test-design)
+* [Software testing methodologies](https://mrcet.com/downloads/digital\_notes/CSE/III%20Year/Software%20Testing%20Methodologies.pdf)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/README.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/README.md
new file mode 100644
index 0000000..14ff183
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/README.md
@@ -0,0 +1,2 @@
+# Тестирование в разных сферах-областях (testing different domains)
+
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/drugoe.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/drugoe.md
new file mode 100644
index 0000000..9d27629
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/drugoe.md
@@ -0,0 +1,13 @@
+# Другое
+
+* [О чем нужно помнить, тестируя носимые устройства](https://dou.ua/forums/topic/35700/)
+* [WebRTC лицом к лицу. Нагрузочный тест видео чата](https://habr.com/ru/company/flashphoner/blog/570308/)
+* [Awesome Blockchain Testing](https://github.com/alexromanov/awesome-blockchain-testing)
+* [How To Write Test Cases for ATM (Test Scenarios ATM Machine)](https://www.softwaretestingmaterial.com/how-to-write-test-cases-for-atm/)
+* How To Test Health Care Application - [Part 1](https://www.softwaretestinghelp.com/how-to-test-health-care-application-part-1/), [Part 2](https://www.softwaretestinghelp.com/testing-healthcare-applications-tips-and-important-test-scenarios-part-2/)
+* [Business Intelligence (BI) Testing: Sample Test Cases](https://www.guru99.com/business-intelligence-testing-sample-test-cases.html)
+* [Salesforce Testing - A Comprehensive Guide](https://www.softwaretestingmaterial.com/salesforce-testing/)
+* [Mainframe Testing - Complete Tutorial](https://www.guru99.com/mainframe-testing.html)
+* [Audio Testing - Automatic Gain Control](https://testing.googleblog.com/2015/10/audio-testing-automatic-gain-control.html)
+* [Testing Kafka based applications](https://medium.com/test-kafka-based-applications/https-medium-com-testing-kafka-based-applications-85d8951cec43)
+
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-bankovskogo-po-banking-domain-applications-bfsi.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-bankovskogo-po-banking-domain-applications-bfsi.md
new file mode 100644
index 0000000..6abe995
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-bankovskogo-po-banking-domain-applications-bfsi.md
@@ -0,0 +1,199 @@
+# Тестирование банковского ПО (Banking domain applications/BFSI)
+
+Банковские приложения (Сектор BFSI или Banking, Financial Services, and Insurance - банковские, финансовые услуги и страхование) являются одними из самых сложных приложений в современной индустрии разработки и тестирования программного обеспечения. Что делает банковские приложения такими сложными? Какой подход следует использовать для тестирования сложных рабочих процессов, связанных с банковскими приложениями? Банковские приложения напрямую связаны с конфиденциальными финансовыми данными. Все операции, выполняемые банковским программным обеспечением, должны выполняться без сбоев и ошибок. Банковское ПО выполняет различные функции, такие как перевод и внесение средств, запрос баланса, история транзакций, вывод средств и так далее. Тестирование банковского приложения гарантирует, что эти действия не только хорошо выполняются, но и остаются защищенными от хакеров.
+
+
+
+Давайте сначала разберемся с характеристиками банковского приложения:
+
+* Многоуровневая функциональность для поддержки тысяч одновременных пользовательских сеансов;
+* Крупномасштабная интеграция. Как правило, банковское приложение интегрируется с множеством других приложений;
+* Сложные бизнес-процессы;
+* Обработка в режиме реального времени и пакетная обработка (Real-Time and Batch processing);
+* Высокая скорость транзакций в секунду;
+* Безопасные транзакции;
+* Надежный раздел отчетности для отслеживания повседневных транзакций;
+* Строгий аудит для устранения проблем клиентов;
+* Массивная система хранения;
+* Управление аварийными ситуациями/восстановлениями.
+
+Что делает банковские приложения такими сложными?
+
+* Банковское программное обеспечение в основном имеет дело с конфиденциальными финансовыми данными, поэтому работа программного обеспечения должна быть безошибочной и безопасной;
+* Разработчики предпочитают сложный дизайн для разработки этих приложений, чтобы гарантировать, что приложение работает безопасным образом;
+* Банковское дело - это постоянно меняющийся мир. Банковское дело сегодня доступно для клиентов с использованием различных каналов, таких как обычные отделения, банкоматы, онлайн-банкинг и обслуживание клиентов;
+* С появлением технологий многие кошельки наводнили рынки, которые подключаются к банковским системам для финансовых транзакций;
+* Ожидается, что банковские услуги будут работать 24\*7 с высокой производительностью. Обновления программного обеспечения, мгновенные исправления и т. д. не должны повлиять на эту доступность;
+* На банковский мир также сильно влияют постоянные изменения, вносимые правительством в виде банковских правил. Любые изменения в структуре налогообложения повлияют и на банковскую систему;
+* Банковская система также должна быть современной в том, что касается новых технологий. Аналитика данных, такая как обработка больших данных, и получение информации из больших данных с помощью науки о данных (Data Science), становятся все более популярными в банковском мире.
+
+Когда мы говорим о тестировании банковских приложений, требуется методология сквозного тестирования (End to End Testing methodology), включающая несколько методов тестирования программного обеспечения, чтобы гарантировать:
+
+* Полный охват всех банковских рабочих процессов (banking workflows) и бизнес-требований (Business Requirements);
+* Функциональный аспект приложения;
+* Аспект безопасности приложения;
+* Целостность данных (Data Integrity);
+* Параллелизм (Concurrency);
+* Пользовательский опыт.
+
+**Banking App Testing Workflow**
+
+Типичные этапы тестирования банковских приложений показаны в приведенном ниже рабочем процессе. Мы обсудим каждый этап индивидуально. Это модель Waterfall для тестирования приложения.
+
+
+
+**1. Сбор требований**: этап сбора требований включает в себя документирование требований либо в виде функциональных спецификаций (Functional Specifications), либо в виде вариантов использования (Use Cases). Требования собираются в соответствии с потребностями клиентов и документируются банковскими экспертами или бизнес-аналитиками. Эксперты участвуют в написании требований по более чем одной теме, поскольку банковское дело само по себе имеет несколько поддоменов, и одно полноценное банковское приложение будет интегрировать все эти домены. Например, банковское приложение может иметь отдельные модули для переводов, кредитных карт, отчетов, ссудных счетов, оплаты счетов, торговли и т. д.;
+
+**2. Обзор требований**: результаты сбора требований проверяются всеми заинтересованными сторонами, такими как QA, руководители разработки и бизнес-аналитики. Они перепроверяют, чтобы ни существующие бизнес-процессы, ни новые рабочие процессы не нарушались. Все требования проверены и утверждены. Последующие действия и пересмотры документов требований выполняются на основе того же;
+
+**3. Подготовка бизнес-сценария**: на этом этапе QA составляют бизнес-сценарии (Business Scenarios) из документов с требованиями (requirement documents - Functions Specs or Use Cases); Бизнес-сценарии разработаны таким образом, что охватывают все бизнес-требования. Бизнес-сценарии - это сценарии высокого уровня без каких-либо подробных шагов. Кроме того, эти бизнес-сценарии проверяются бизнес-аналитиками, чтобы убедиться, что все бизнес-требования выполнены. BA легче просматривать сценарии высокого уровня, чем просматривать подробные тестовые случаи низкого уровня. Например, клиент, открывающий срочный депозит в интерфейсе цифрового банкинга, может быть бизнес-сценарием. Точно так же у нас есть различные бизнес-сценарии, связанные с созданием банковского счета, онлайн-депозитами, онлайн-переводами и т. д.;
+
+**4. Функциональное тестирование**: на этом этапе выполняется функциональное тестирование и выполняются обычные действия по тестированию программного обеспечения, такие как:
+
+* **Подготовка тестовых случаев** (Test Case Preparation): на этом этапе тестовые случаи создаются на основе бизнес-сценариев, один бизнес-сценарий приводит к нескольким положительным и отрицательным тестовым случаям;
+* **Обзор тестовых случаев** (Test Case Review): обзоры, сделанные коллегами-инженерами по обеспечению качества;
+* **Выполнение тестовых случаев** (Test Case Execution): выполнение тестового набора.
+
+Функциональное тестирование банковского приложения сильно отличается от обычного тестирования программного обеспечения. Поскольку эти приложения работают с деньгами клиентов и конфиденциальными финансовыми данными, их необходимо тщательно протестировать. Ни один важный бизнес-сценарий не должен оставаться незамеченным. Кроме того, ресурс QA, который тестирует приложение, должен иметь базовые знания в банковской области.
+
+**5. Тестирование баз данных**: банковское приложение включает в себя сложные транзакции, которые выполняются как на уровне пользовательского интерфейса, так и на уровне базы данных, поэтому тестирование базы данных так же важно, как и функциональное тестирование. База данных сложна и представляет собой совершенно отдельный слой в приложении, поэтому ее тестирование проводится специалистами по базам данных. Оно использует такие методы, как:
+
+* Загрузка данных;
+* Миграция базы данных;
+* Тестирование схемы БД и типов данных;
+* Тестирование правил;
+* Тестирование хранимых процедур и функций;
+* Тестирование триггеров;
+* Целостность данных.
+
+Основная цель тестирования базы данных состоит в том, чтобы убедиться, что:
+
+* Приложение может хранить и извлекать данные из базы данных без потери данных;
+* Завершенные транзакции должны быть зафиксированы, а прерванные транзакции должны быть возвращены обратно, чтобы избежать любых несоответствий в сохраненных данных;
+* Доступ к базе данных и базовым таблицам разрешен только авторизованным приложениям и пользователям.
+
+В основном существует три способа тестирования базы данных:
+
+* Структурное тестирование: включает в себя тестирование объектов базы данных, таких как базы данных, схемы, таблицы, представления, триггеры, элементы управления доступом и т. д. Обеспечение синхронизации типов данных в таблицах с соответствующими переменными в приложении. Проверка данных и ссылочной целостности в таблицах. Например, поле суммы в приложении должно иметь в таблице тип данных decimal/float. Чтобы соответствовать этим стандартам, пользователям следует предоставить средства управления доступом через представления;
+* Функциональное тестирование: включает в себя тестирование баз данных, которые удовлетворяют требованиям пользователя. Есть два способа добиться этого: тестирование черного ящика и тестирование белого ящика. Например, когда мы делаем онлайн-перевод денег, счет отправителя должен быть списан, а счет получателя должен быть зачислен на ту же сумму. Если транзакция завершается неудачей, вся транзакция должна быть отменена, а счет отправителя не должен дебетоваться или кредитоваться обратно;
+* Нефункциональное тестирование: включает в себя нагрузочное и стресс-тестирование и оптимизацию производительности. Нагрузочное тестирование помогает определить максимальное количество транзакций, которые могут выполняться одновременно, не влияя на производительность базы данных. Например, на основе результатов нагрузочного и стресс-тестирования банковские приложения могут решить добавить больше ресурсов в свое приложение в часы пик и сократить ресурсы в нерабочее время. Это помогает банку оптимально использовать ресурсы и экономить деньги.
+
+**6. Тестирование безопасности**: тестирование безопасности обычно является последним этапом цикла тестирования. Обязательным условием для начала тестирования безопасности является завершение функционального и нефункционального тестирования. Тестирование безопасности является одним из основных этапов всего цикла тестирования приложений, поскольку на этом этапе обеспечивается соответствие приложения федеральным и отраслевым стандартам. Из-за характера данных, которые они несут, банковские приложения очень чувствительны и являются главной целью для хакеров и мошеннических действий. Тестирование безопасности гарантирует, что приложение не имеет таких веб-уязвимостей, которые могут раскрыть конфиденциальные данные злоумышленнику. Это также гарантирует, что приложение соответствует таким стандартам, как OWASP. На этом этапе основной задачей является сканирование всего приложения, которое выполняется с помощью [различных инструментов](https://www.softwaretestinghelp.com/webinspect-alternatives/). После завершения сканирования публикуется отчет о сканировании. В этом отчете ложные срабатывания отфильтровываются, а остальные уязвимости сообщаются команде разработчиков, чтобы они могли приступить к устранению проблем в зависимости от серьезности каждой проблемы. На этом этапе также проводится тестирование на проникновение, чтобы выявить распространение ошибок. Необходимо проводить тщательное тестирование безопасности на разных платформах, в сетях и ОС. Несколько других используемых ручных инструментов для тестирования безопасности: Paros Proxy, Http Watch, Burp Suite и Fortify. Основная цель тестирования безопасности - выявить любые уязвимости, которые могут быть в программном приложении.
+
+Тестирование безопасности проверяет приложение на:
+
+* Любую внешнюю атаку или попытку взлома приложения со злым умыслом;
+* Любую лазейку в программном приложении может быть использована, что приведет к потере данных или денежных средств;
+* Любую уязвимость в сети, серверах или рабочих станциях, на которых размещено приложение.
+
+Ниже приведены различные типы тестирования безопасности:
+
+* **Тестирование уязвимостей** (Vulnerability Testing): разрабатывается и выполняется автоматизированная программа для проверки на наличие различных уязвимостей;
+* **Сканирование безопасности** (Security Scanning): этот вариант вращается вокруг исследования уязвимостей сети и системы, тем самым предоставляя решения для снижения связанного с этим риска;
+* **Тестирование на проникновение** (Penetration Testing): этот вариант тестирования безопасности имитирует попытку взлома для захвата уязвимостей и лазеек, которые могли бы дать хакеру доступ к базе данных или данным приложения;
+* **Аудит безопасности** (Security Audit): это включает в себя аудит приложения и связанных сетей на предмет любых нарушений безопасности;
+* **Оценка риска** (Risk Assessment): выполняется анализ для оценки уровня риска в случае, если уязвимость или лазейка используются со злым умыслом. Такой риск можно разделить на низкий, средний и высокий. В зависимости от уровня риска группа тестирования рекомендует надлежащие меры для снижения или предотвращения риска;
+* **Этический взлом** (Ethical Hacking): выполняется организацией в своих системах для выявления лазеек, которые могут быть использованы в ее приложении или сети. Цель этого вида взлома не состоит в том, чтобы украсть или нанести ущерб приложению или сети;
+* **Оценка состояния** (Posture Assessment): это комплексная оценка, включающая сканирование безопасности, оценку рисков и взлом с соблюдением этических норм;
+* **SQL-инъекция**: SQL-инъекция может использоваться для получения доступа к базе данных сервера. Тестирование выполняется, чтобы убедиться, что код работает правильно, выполняя запросы в базе данных на основе следующих входных данных от пользователя: Скобки, Апострофы, Запятые, Кавычки.
+
+**Другие этапы тестирования BFSI приложений**
+
+Помимо вышеуказанных основных этапов, могут быть задействованы различные этапы, такие как интеграционное тестирование, тестирование удобства использования, пользовательское приемочное тестирование и тестирование производительности.
+
+**Примеры тестов для банковского приложения**
+
+* Для нового филиала (?New Branch):
+ * Создайте новый филиал с допустимыми и недействительными тестовыми данными;
+ * Создайте новый филиал без данных;
+ * Создайте новый филиал с существующими данными;
+ * Проверьте параметры сброса и отмены;
+ * Обновите сведения о филиале с допустимыми и недействительными тестовыми данными;
+ * Обновите сведения о филиале с помощью существующих тестовых данных;
+ * Проверьте, можно ли сохранить новый филиал;
+ * Убедитесь, что опция отмены работает;
+ * Проверьте удаление филиала с зависимостями и без них;
+ * Проверьте, работает ли опция поиска филиалов.
+* Для новой роли:
+ * Создайте новую роль с допустимыми и недействительными тестовыми данными;
+ * Создайте новую роль без данных;
+ * Проверьте, можно ли создать новую роль с существующими тестовыми данными;
+ * Проверьте описание роли и тип роли;
+ * Убедитесь, что опция отмены и сброса работает;
+ * Проверьте процесс удаления роли с зависимостью и без нее;
+ * Проверьте ссылки на странице сведений о роли.;
+ * Проверьте вход администратора без тестовых данных;
+ * Проверьте все домашние ссылки для роли администратора;
+ * Убедитесь, что администратор может изменить пароль с допустимыми и недействительными тестовыми данными;
+ * Убедитесь, что администратор успешно вышел из системы.
+* Для Клиента и Банкира:
+ * Убедитесь, что все ссылки посетителей и клиентов работают правильно;
+ * Проверьте вход клиента с действительными и недействительными тестовыми данными;
+ * Проверьте логин клиента без каких-либо данных;
+ * Проверьте логин банкира без каких-либо данных;
+ * Проверьте логин банкира с действительными или недействительными тестовыми данными%
+ * Проверьте, смог ли клиент и банкир успешно выйти из системы.
+* Для новых пользователей:
+ * Проверьте, можно ли создать нового пользователя с допустимыми и недействительными тестовыми данными;
+ * Создайте нового пользователя с существующими тестовыми данными филиала;
+ * Убедитесь, что опция отмены и сброса работает правильно;
+ * Обновите сведения о пользователе, указав действительные и недействительные тестовые данные;
+ * Проверьте удаление нового пользователя;
+ * Проверьте, можно ли верифицировать нового пользователя;
+ * Проверьте обязательные входные параметры;
+ * Проверьте дополнительные входные параметры;
+ * Проверьте, можно ли создать пользователя без необязательных параметров.
+* Для создания новой учетной записи:
+ * Создайте новую учетную запись с действительными и недействительными данными пользователя;
+ * Убедитесь, что сведения о пользователе могут быть обновлены;
+ * Проверьте, можно ли сохранить нового пользователя;
+ * Создайте новую учетную запись с существующими данными пользователя;
+ * Убедитесь, что пользователь может внести сумму во вновь созданную учетную запись (и обновить баланс);
+ * Проверьте, может ли пользователь снять сумму с новой учетной записи (после внесения депозита и обновления баланса);
+ * В случае заработной платы учетная запись проверяет название компании и другие данные, предоставленные пользователем;
+ * Проверьте, указан ли номер основной учетной записи в случае дополнительной учетной записи;
+ * Проверьте данные пользователя, указанные в случае текущей учетной записи;
+ * Проверьте предоставленное доказательство для совместного счета в случае совместного счета;
+ * Проверьте, можете ли вы поддерживать нулевой баланс на вашем счете заработной платы;
+ * Проверьте, можете ли вы поддерживать нулевой баланс или минимальный баланс для счета, не связанного с зарплатой;
+ * Убедитесь, что новый пользователь смог успешно выйти из системы.
+* Для сетевого банковского приложения (Net Banking Application):
+ * пользователь может открыть сайт банка;
+ * все ссылки на сайте работают;
+ * пользователь может создать новую учетную запись;
+ * Проверьте, может ли пользователь войти в систему с допустимым и недействительным именем пользователя и паролем.
+ * Проверьте, что если имя пользователя или пароль пусты при входе в систему, пользователю не должно быть разрешено войти в систему, и должно отображаться предупреждающее сообщение;
+ * Проверьте, разрешено ли пользователю изменять пароль;
+ * Если введено неверное имя пользователя или пароль, будет показано соответствующее сообщение об ошибке;
+ * Пользователям с неверным паролем не разрешается входить в систему;
+ * Убедитесь, что после неоднократных попыток входа с неправильным паролем пользователю должно быть показано сообщение об ошибке и он заблокирован;
+ * Проверьте, может ли пользователь выполнять некоторые основные транзакции;
+ * Убедитесь, что пользователь может добавить получателя с допустимыми и недействительными данными;
+ * Проверьте, может ли пользователь удалить получателя;
+ * Убедитесь, что пользователь может совершать транзакции для вновь добавленного получателя;
+ * После транзакции проверьте, были ли обновлены учетные записи пользователя и получателя;
+ * Проверьте, может ли пользователь ввести сумму в десятичном виде (4.50);
+ * Убедитесь, что пользователь не может вводить отрицательные числа в поле суммы;
+ * Проверьте, разрешено ли пользователю совершать транзакции с минимальным балансом или без него;
+ * Проверьте, может ли пользователь создать новый RD;
+ * Убедитесь, что отображается правильное сообщение в случае транзакции, выполненной с недостаточным балансом;
+ * Проверьте, запрашивается ли у пользователя подтверждение перед выполнением какой-либо транзакции;
+ * Убедитесь, что квитанции о подтверждении предоставлены для каждой успешной транзакции;
+ * Проверьте, может ли пользователь переводить деньги на несколько счетов;
+ * Проверьте, может ли пользователь отменить транзакцию;
+ * Убедитесь, что данные учетной записи также отражают выполненные финансовые операции;
+ * Убедитесь, что функция тайм-аута реализована;
+ * Убедитесь, что в случае истечения времени сеанса пользователь должен снова войти в систему;
+ * Убедитесь, что установлен правильный тайм-аут сеанса в случае бездействия;
+ * Убедитесь, что при выполнении транзакции пользователь переведен в безопасный режим;
+ * Убедитесь, что пользователь смог успешно выйти из системы;
+ * Проверьте параметры поиска и сброса.
+
+Источники:
+
+* [How To Test Banking Domain Applications: A Complete BFSI Testing Guide](https://www.softwaretestinghelp.com/testing-banking-applications/)
+
+Доп. материал:
+
+* [How To Test Investment Banking Application (With 34+ Important Test Scenarios)](https://www.softwaretestinghelp.com/how-to-test-investment-banking-application/)
+* [How To Test Retail Banking System](https://www.softwaretestinghelp.com/how-to-test-retail-banking-system/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-baz-dannykh-database.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-baz-dannykh-database.md
new file mode 100644
index 0000000..88d5531
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-baz-dannykh-database.md
@@ -0,0 +1,109 @@
+# Тестирование баз данных (Database)
+
+**База данных** - представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).
+
+База данных является одной из неизбежных частей программного приложения. Неважно, будет ли это веб, настольный или мобильный, клиент-серверный, одноранговый, корпоративный или индивидуальный бизнес; База данных требуется везде на бэкенде. Точно так же, будь то здравоохранение, финансы, лизинг, розничная торговля, почтовое приложение или управление космическим кораблем; База данных всегда находится в действии за кулисами.
+
+**Зачем тестировать БД?**
+
+**1. Отображение данных (Data Mapping)**
+
+В программных системах данные часто перемещаются туда и обратно из UI (пользовательского интерфейса) в серверную БД и наоборот. Итак, вот некоторые аспекты, на которые стоит обратить внимание:
+
+* Проверьте, сопоставляются ли поля в формах пользовательского интерфейса/внешнего интерфейса с соответствующими полями в таблице БД. Обычно эта информация о сопоставлении определяется в документах с требованиями;
+* Всякий раз, когда определенное действие выполняется во внешнем интерфейсе приложения, соответствующее действие CRUD (создание, извлечение, обновление и удаление) вызывается в бэкенде. Тестировщик должен будет проверить, вызывается ли правильное действие и является ли вызванное действие само по себе успешным или нет.
+
+**2. Проверка требований ACID (ACID Properties Validation)**
+
+Каждая транзакция, которую выполняет БД, должна соответствовать этим четырем свойствам:
+
+* Атомарность (**Atomicity**): гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния;
+* Согласованность (**Consistency**): транзакция, достигающая своего нормального завершения (EOT - end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты;
+* Изолированность (**Isolation**): во время выполнения транзакции параллельные транзакции не должны оказывать влияния на ее результат;
+* Постоянство/надежность (**Durability**): если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
+
+**3. Целостность данных (Data Integrity)**
+
+Для любой операции CRUD обновленные и самые последние значения/статус общих данных должны отображаться во всех формах и экранах. Значение не должно обновляться на одном экране и отображать более старое значение на другом.
+
+Когда приложение находится в процессе выполнения, конечный пользователь в основном использует операции «CRUD».
+
+CRUD - акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (англ. create), чтение (read), модификация (update), удаление (delete). В SQL этим функциям, операциям соответствуют операторы Insert (создание записей), Select (чтение записей), Update (редактирование записей), Delete (удаление записей). В системах, реализующих доступ к базе данных через API в стиле REST, эти функции реализуются зачастую (но не обязательно) через HTTP-методы PUT, POST, GET, PATCH, DELETE.
+
+Любая операция с базой данных, выполняемая конечным пользователем, всегда является одной из четырех вышеперечисленных.
+
+Поэтому разработайте свои тестовые примеры БД таким образом, чтобы включить проверку данных во всех местах, где они появляются, чтобы увидеть, постоянно ли они одинаковы.
+
+**4. Соответствие бизнес-правилам (Business Rule Conformity)**
+
+Более сложная база данных означает более сложные компоненты, такие как реляционные ограничения, триггеры, хранимые процедуры и т. д. Поэтому тестировщикам придется придумывать соответствующие SQL-запросы для проверки этих сложных объектов.
+
+**Что тестировать?**
+
+**1. Транзакции**
+
+**2. Схемы базы данных**
+
+Схема базы данных - это не что иное, как формальное определение того, как данные будут организованы внутри БД. Чтобы проверить это:
+
+* Определите требования, на основе которых работает база данных. Образец требований:
+ * Первичные ключи должны быть созданы до создания любых других полей;
+ * Внешние ключи должны быть полностью проиндексированы для легкого извлечения и поиска;
+ * Имена полей, начинающиеся или заканчивающиеся определенными символами;
+ * Поля с ограничением, что определенные значения могут или не могут быть вставлены.
+* Используйте один из следующих методов в зависимости от релевантности:
+ * SQL-запрос для проверки схемы.
+ * Регулярные выражения для проверки имен отдельных полей и их значений;
+ * Такие инструменты, как SchemaCrawler.
+
+**3. Триггеры**
+
+Когда определенное событие происходит в определенной таблице, часть кода (триггер) может быть автоматически проинструктирована для выполнения.
+
+Например, новый ученик присоединился к школе. Ученик посещает 2 класса: математику и естествознание. Ученик добавлен в таблицу учеников. Триггер может добавить учащегося в соответствующие предметные таблицы, как только он будет добавлен в студенческую таблицу.
+
+Обычный метод тестирования состоит в том, чтобы сначала независимо выполнить SQL-запрос, встроенный в триггер, и сравнить фактический результат с ожидаемым.
+
+* Тестирование белого ящика : заглушки и драйверы используются для вставки, обновления или удаления данных, которые могут привести к срабатыванию триггера. Основная идея состоит в том, чтобы просто протестировать БД в одиночку еще до того, как будет выполнена интеграция с внешним интерфейсом (UI).
+* Тестирование черного ящика :
+ * а) Начиная с UI и БД теперь доступна интеграция; мы можем вставлять/удалять/обновлять данные из внешнего интерфейса таким образом, чтобы вызывался триггер. После этого операторы Select можно использовать для получения данных БД, чтобы увидеть, успешно ли триггер выполнил намеченную операцию.
+ * б) Второй способ проверить это - напрямую загрузить данные, которые вызовут триггер, и посмотреть, работает ли он так, как задумано.
+
+**4. Хранимые процедуры**
+
+Хранимые процедуры более или менее похожи на пользовательские функции. Они могут быть вызваны операторами вызова процедуры/выполнения процедуры, а выходные данные обычно представлены в виде наборов результатов.
+
+Они хранятся в СУБД и доступны для приложений.
+
+* Тестирование белого ящика: заглушки используются для вызова хранимых процедур, а затем результаты проверяются на соответствие ожидаемым значениям.
+* Тестирование «черного ящика»: выполните операцию из внешнего интерфейса (UI) приложения и проверьте выполнение хранимой процедуры и ее результаты.
+
+**5. Ограничения полей**
+
+Значение по умолчанию, уникальное значение и внешний ключ (Default value, Unique value, and Foreign key):
+
+* Выполните интерфейсную операцию, которая проверяет условие объекта базы данных.
+* Подтвердите результаты с помощью SQL-запроса.
+
+Проверить значение по умолчанию для определенного поля довольно просто. Это часть проверки бизнес-правил. Вы можете сделать это вручную или использовать такие инструменты, как QTP. Вручную вы можете выполнить действие, которое добавит значение, отличное от значения поля по умолчанию, из внешнего интерфейса и посмотреть, не приведет ли это к ошибке.
+
+Проверка уникального значения может быть выполнена точно так же, как мы делали это для значений по умолчанию. Попробуйте ввести значения из пользовательского интерфейса, которые будут нарушать это правило, и посмотрите, не появится ли ошибка.
+
+Для проверки ограничения внешнего ключа используйте загрузки данных, которые напрямую вводят данные, нарушающие ограничение, и посмотрите, ограничивает ли их приложение или нет. Наряду с загрузкой данных из серверной части выполняйте также операции пользовательского интерфейса фронтенда таким образом, чтобы нарушить ограничения, и посмотрите, отображается ли соответствующая ошибка.
+
+**Автоматизация**
+
+Автотесты в БД обычно пишутся на хранимые процедуры и джобы и похожи на автотесты API, только транспортный уровень - драйвер БД, и добавляются транзакции и роллбэки в тирдаун секции.
+
+Источники:
+
+* [Database Testing Complete Guide (Why, What, And How To Test Data)](https://www.softwaretestinghelp.com/database-testing-process/)
+
+Доп. материал:
+
+* [Базы данных: большой обзор типов и подходов. Доклад Яндекса](https://habr.com/ru/company/yandex/blog/522164/)
+* [Требования ACID на простом языке](https://habr.com/ru/post/555920/)
+* [Плейлист “Тестирование баз данных”](https://www.youtube.com/playlist?list=PLKbJd47KcbjtlWHMG4sy-qETG4aSSezom)
+* [Тестирование СУБД: 10 лет опыта](https://habr.com/ru/company/vk/blog/584864/)
+* [30+ Database Testing Interview Questions And Answers (Updated 2022)](https://www.softwaretestingmaterial.com/database-testing-interview-questions/)
+* [Testing code that talks to the database](https://engineering.helpscout.com/testing-code-that-talks-to-the-database-7d15a5391fb9)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-chat-bota-chatbot.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-chat-bota-chatbot.md
new file mode 100644
index 0000000..01e3787
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-chat-bota-chatbot.md
@@ -0,0 +1,164 @@
+# Тестирование чат-бота (Chatbot)
+
+Чат-бот - это программа, предназначенная для имитации общения с человеком. Разработчики обычно проектируют чат-ботов так, чтобы пользователям было сложно определить, общаются ли они с живым человеком или с роботом.
+
+Чат-боты - это не что иное, как приложения, которые имеют прикладной уровень, базу данных и API. Чтобы упростить работу чат-бота, мы можем сказать, что он работает на сопоставлении с образцом для классификации текста и выдачи подходящего ответа на вопросы/запросы, заданные пользователем. Чат-бот отвечает пользователю согласно заложенной в него программе. Чат-боты бывают разных типов, в зависимости от того, как они используются. Существует три основных типа чат-ботов:
+
+* Чат-бот на основе правил (Rule-Based Chatbot): это базовый чат-бот, пользователь взаимодействует с этим типом бота, используя предопределенные параметры. Чтобы получить ответы от этих ботов, пользователям необходимо выбрать определенные параметры. Такие боты собирают запрос пользователя, анализируют его, а затем предлагают результаты в виде кнопок. Эти боты обычно используются для замены часто задаваемых вопросов;
+* Независимые (Keyword) чат-боты: это боты с машинным обучением, в отличие от чат-ботов на основе правил, они анализируют то, что хочет пользователь, и реагируют соответствующим образом. Эти чат-боты используют настраиваемые ключевые слова и машинное обучение, чтобы определить, как эффективно и результативно реагировать на запросы пользователей;
+* НЛП (Contextual) чат-боты: на данный момент это самые продвинутые чат-боты. Они представляют собой комбинацию лучших чат-ботов на основе правил и ключевых слов. Эти чат-боты используют [NLP](https://en.wikipedia.org/wiki/Natural\_language\_processing), чтобы понять контекст и намерения запросов пользователей и действовать соответственно. Эти чат-боты могут легко обрабатывать несколько запросов от одного и того же пользователя.
+
+**Частые проблемы чат-ботов**:
+
+* Сломанные скрипты, которые приводят к сбоям в работе;
+* Долгие паузы перед ответами;
+* Нет связи с другими бизнес-каналами;
+* Слишком много намерений или бизнес-задач для одного бота;
+* Недостаток речи и/или точности (Lack of utterance and/or accuracy);
+* Нет права на ошибку;
+* Плохая навигация;
+* Плохой дизайн разговора.
+
+**Виды тестирования чат-ботов**
+
+**1. Functional Testing**
+
+Чат-бот может быть эффективным только в том случае, если он понимает контекст, в котором работает. Чтобы это произошло, разработчикам необходимо «научить» приложение различным категориям слов и конкретным терминам. Допустим, у нас есть чат-бот для кофейни, который позволяет пользователям размещать заказы. Вы можете перечислить варианты и сделать их кликабельными или научить бота распознавать заказы. В первом случае разработчикам может быть проще программировать функционал, но это может быть менее удобно для пользователей. Взгляните на пример такого потока:
+
+
+
+Этот поток может варьироваться, и вам может потребоваться добавить другие этапы - горячий, холодный и ледяной; с чаем, алкоголем или ароматизатором; и так далее. Логика будет усложняться, когда вы добавите возможность заказать кофе в зернах, десерты или другие продукты, которые покупатель обычно может найти в кофейне.
+
+Другой сценарий более сложен. Он обрабатывает прямые запросы пользователей и извлекает необходимую информацию. Например, пользователь видит «Привет! Что бы вы хотели заказать?" сообщение и набирает ответ. Пусть это будет «Капучино с одним сахаром и холодный напиток без сахара для Бена». Здесь есть несколько сущностей, которые чат-бот должен понимать:
+
+* Тип кофе - капучино, колд брю;
+* Варианты сахара - да, нет;
+* Количество сахаров - один, ноль;
+* Имя заказчика - Бен.
+
+Разработчики вставляют эти данные на ранних этапах и строят на их основе логику чат-бота. Чтение и извлечение информации функционирующим ботом также называется заполнением слотов (slot filling).
+
+ТЕСТИРОВАНИЕ: Чтобы узнать, знаком ли бот с основными сущностями, инженеру по контролю качества необходимо будет выполнить тесты, специфичные для предметной области. Важно убедиться, что чат-бот понимает все термины, связанные с кофе, которые могут использовать клиенты.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Убедитесь, что вы добавили достаточное количество объектов и значений для каждого, чтобы чат-бот мог правильно понять запрос. В идеальном случае вам нужно будет охватить оба сценария - один для тех, кто уже знает, и один для тех, кто выбирает, что заказать.
+
+**2. Валидация входных данных (Validating Inputs - Some More Functional Testing)**
+
+Если чат-бот принимает такие входные данные, как адреса электронной почты, номера телефонов и почтовые индексы, для системы очень важно распознать правильный формат данных.
+
+ТЕСТИРОВАНИЕ: Скармливайте чат-боту адреса электронной почты, номера телефонов и почтовые индексы в разных неправильных форматах, например:
+
+* адрес электронной почты без символа @;
+* адрес электронной почты с пробелами;
+* неправильное количество цифр в почтовом индексе;
+* буквы в номере мобильного телефона.
+
+Таким образом, вы узнаете, как система принимает неверные данные, и предложите улучшения, если ответ не удобен для пользователя.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Проверка данных должна быть немедленной и сопровождаться соответствующим сообщением. Сообщение может показывать пример правильного адреса электронной почты, номера мобильного телефона и т. д. или просто уведомлять об ошибке. Если ввод действителен, пользователь должен увидеть «сообщение об успехе» - доказательство того, что система получила ваши данные и распознала их как действительные.
+
+**3. Негативные входные данные (Unknown Inputs - Error Handling & Limit Value Testing)**
+
+Команда не может предусмотреть все возможные пользовательские вводы, особенно если есть вариант ввода, позволяющий ввести запрос. Поэтому необходимо исследовать границы запрограммированной логики. Другая задача - убедиться, что бот адекватно реагирует на входные данные, которые он не понимает.
+
+ТЕСТИРОВАНИЕ: Запустите исследовательские тесты, чтобы узнать, как чат-бот обрабатывает нестандартные входные данные. Они могут включать:
+
+* Случайные разговоры, не связанные с целью чат-бота;
+* Бессмысленные предложения или выражения, которые обычно не используются;
+* Грамматические ошибки, опечатки, сленг, разные варианты английского языка;
+* Сбивающие с толку и оскорбительные сообщения.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Креативность клиентов не имеет границ, особенно когда они хотят поиграть с чат-ботом. Вы не можете охватить все возможные сценарии и сообщения. Есть несколько вещей, которые нужно сделать:
+
+* Добавьте варианты общих ключевых слов с опечатками в жаргон чат-бота. Если бот не может понять небольшие изменения запроса, разработчикам нужно научить его это делать;
+* Работайте над светской беседой, чтобы поддержать основную непринужденную беседу. Это придаст человечности, сделает разговор непринужденным и веселым. Эти запросы привлекают внимание пользователей и оказывают положительное влияние на пользовательский опыт;
+* Придумывайте ответы на оскорбительные сценарии. Вам нужно будет создать несколько дополнительных слотов для ненормативной лексики, чтобы чат-бот мог дать остроумный ответ. Напишите экстренный ответ на несоответствующие запросы. Хотя приведенные выше пункты являются скорее рекомендациями, этот является обязательным. Вы можете использовать ответ «Извините, я не понял» для любого запроса, который не полностью соответствует логике;
+* Избегайте бесконечных циклов. Когда чат-бот не получает соответствующий запрос или ответ на вопрос, он должен попросить уточнить запрос или предложить дополнительные варианты. Убедитесь, что разговор завершен, и программа не показывает один и тот же ответ вечно. Вместо этого запрограммируйте чат-бота на завершение разговора или подключите человека-эксперта после трех или пяти запросов «Я не понял» подряд.
+
+Чат-бот - это бизнес-инструмент, а не игрушка, которую пользователи могут тестировать на наличие умных ответов. И тем не менее особенности гуманизации положительно сказываются на имидже бренда и пользовательском опыте. Однако когда дело доходит до ругательств, было бы разумно не отставать от тона голоса бренда. Пошутите и ответьте на оскорбительные вопросы, если можете. В противном случае просто выходите стратегически. Единственное, что является общим вне зависимости от стратегии общения, - это никогда не ругаться матом. Это не очень вежливо.
+
+**4. UI Testing**
+
+Чат-боты часто показывают кнопки с вариантами ответа, предоставляют ссылки на веб-сайт бренда или другие ресурсы, имеют карточки со встроенной информацией или другими изображениями. Все эти элементы должны быть функциональными - ссылки ведут на правильные источники, изображения оптимизированы и правильно отображаются, все цепочки ответов связаны так, чтобы разговор не прерывался резко.
+
+ТЕСТИРОВАНИЕ: Необходимо проверять весь поток на наличие битых ссылок, графических элементов и пробелов в логике.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Предоставьте пользователям возможность оставлять отзывы. Таким образом, они сообщат, если обнаружат какие-то дефекты, которые вы могли пропустить. 100% покрытие тестами - это миф, и оставить пару мелочей незамеченными - это нормально.
+
+**5. Compatibility Testing**
+
+Еще одна важная вещь - убедиться, что чат-бот корректно выглядит на разных устройствах. Интеграция бота в мессенджер - обычная практика, но это не единственный вариант. Хотя дизайн мессенджера уже настроен для различных устройств, подключение чат-бота к веб-сайту может быть не таким простым.
+
+ТЕСТИРОВАНИЕ: Проверьте, как выглядит окно чат-бота на разных устройствах, в разных браузерах и версиях ОС. Измените размер окна браузера на экране компьютера, чтобы графика не искажалась, а макет не нарушался. Тексты должны оставаться читабельными и не выходить за границы.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Проверьте чат-бот на широко используемых устройствах, браузерах и версиях ОС перед выпуском. При необходимости настройте стиль и параметры окна чат-бота.
+
+**6. UX Testing**
+
+Это один из наиболее очевидных аспектов чат-бота для проверки. UX-тестирование будет основываться как на бизнес-требованиях, так и на личном опыте пользователей. Важно убедиться, что чат-бот выполняет свою основную задачу, генерируя правильные и точные ответы.
+
+ТЕСТИРОВАНИЕ: На основе бизнес-требований создайте сценарии для пользовательских запросов. Основная идея - проверить эти запросы с точки зрения пользователя, который впервые видит вашего чат-бота. Итак, начните с ответов на следующие вопросы:
+
+* Понимает ли чат-бот вопросы?
+* Предоставляет ли он мгновенные ответы на эти запросы?
+* Является ли информация актуальной, точной и полезной для пользователя?
+* Требуется ли для завершения пути пользователя больше или меньше шагов?
+* Привлекательно ли это для пользователей?
+* Склонны ли они отказываться от чат-бота?
+* Как сделать беседу более увлекательной?
+
+СОВЕТЫ ПО КАЧЕСТВУ: Главное правило - вести разговор как можно более нормально. Итак, вот несколько основных правил, которые помогут вам достичь этой цели:
+
+* Разговор с чат-ботом должен иметь логический ход, очень похожий на реальный разговор с человеком. Например, начните с приветствия, а затем задайте вопрос, чтобы начать разговор:
+ * Могу я чем-нибудь помочь?
+ * Что вы ищете?
+ * Заинтересован ли ты в…?
+* Обратите внимание на варианты ввода. Если у вас есть текстовое поле, в котором пользователи могут вводить свои запросы, убедитесь, что чат-бот понимает разные запросы. Допустим, вы хотите заказать товар в канцелярском магазине. Существует несколько вариантов начала разговора:
+
+ * Я хочу заказать блокнот.
+ * Мне нужен блокнот.
+ * Какие тетради у вас есть?
+ * Можно мне лиловый блокнот с точками размером 5×3,5 дюйма?
+
+ Может быть разумно предоставить стандартный набор ответов, это зависит от цели вашего чат-бота и разнообразия доступных товаров/услуг.
+* Каждый ответ должен быть логически связан с предыдущим запросом или вопросом. Крайне важно, чтобы чат-бот предоставлял только актуальную и необходимую информацию. Мгновенно уведомляйте клиентов об ошибках в их запросах. Подтвердите сообщение об успешном завершении, если чат-бот запрашивает ввод контактных данных;
+* Всегда должно быть последнее сообщение, сигнализирующее об окончании разговора. Оно может содержать ссылки на некоторые полезные ресурсы, рекомендации по дальнейшему общению или прощальную фразу;
+* Рассмотрите возможность подключения пользователя к помощнику-человеку. Хотите вы того или нет, но есть вопросы, с которыми боты не справятся. И просто так предоставьте возможность вернуться к началу или вернуться к предыдущему шагу. Чат-бот требует четкой навигации, как и любой другой онлайн-сервис.
+
+**7. Performance Testing**
+
+Люди, использующие чат-боты, рассчитывают получить точные ответы на свои запросы и получить их мгновенно. Это означает, что тестирование производительности чат-бота необходимо. Следовательно, задержка - время, необходимое чат-боту для получения ответа и его отображения, - должна быть минимальной.
+
+ТЕСТИРОВАНИЕ: QA-инженер должен проверять разные запросы, которые охватывают маленькие и большие диалоги и содержат разные типы контента. Чтобы каждый ответ появился на экране, должно пройти одинаковое время, независимо от его места в пути пользователя и избранного контента.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Задержка, которая длится более пары секунд, вызывает разочарование, и пользователь, скорее всего, откажется от чат-бота. Задержка может зависеть от содержания ответа, но рекомендуемое время ответа составляет до двух секунд.
+
+**8. Integration/API Testing**
+
+Как правило, чат-бот не работает сам по себе - он становится неотъемлемой частью цифровой экосистемы компании. То есть вам в конечном итоге нужно будет подключить его к официальному сайту, учетной записи в социальной сети, мессенджеру или другому приложению.
+
+ТЕСТИРОВАНИЕ: Если вы используете программное обеспечение для создания ботов, вы, вероятно, найдете API, который позволяет подключать чат-бот к вашей системе и запускать тесты API. Если вы используете собственное решение, необходимо запустить интеграционные тесты, чтобы проверить, как бот и другие системные функции ведут себя при подключении.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Обратите внимание как на технические, так и на дизайнерские аспекты вашего чат-бота. Это часть вашей цифровой системы, и она должна легко интегрироваться. Все упомянутые выше аспекты функциональности и производительности должны соответствовать стандартам качества после подключения чат-бота к веб-сайту или другой платформе. Дизайн должен соответствовать другим медиа и имиджу бренда в целом. Последний аспект подпадает под UX-тестирование, но на этом этапе может стать очевидным несоответствие.
+
+**9. Localization Testing**
+
+И последнее, но не менее важное: избегайте ошибок в ответах - орфографических, грамматических, лексических, любых ошибок! В большинстве случаев они не будут иметь катастрофического эффекта, но внимательные пользователи могут скептически относиться к уровню предоставляемых вами услуг. Короче говоря, важны мелочи, поэтому тексты должны быть безошибочными. Если веб-сайт многоязычный, имеет смысл создать многоязычного чат-бота. Имейте в виду, что локализация охватывает и другие аспекты - часовые пояса, валюты, метрические системы и многое другое.
+
+ТЕСТИРОВАНИЕ: Доверьте тестирование локализации тому, кто умеет редактировать тексты. Если QA-специалист не уверен в своих навыках корректора, поручите эту задачу другому члену команды. Кроме того, свежий взгляд всегда полезен. Итак, проверьте ответы на орфографические, лексические и грамматические ошибки, пунктуацию и связность. Также убедитесь, что форматирование правильное. Всякий раз, когда у вас есть список вещей, используйте маркеры или цифры. Делайте предложения короткими и делите информацию на абзацы, если сообщение длинное.
+
+СОВЕТЫ ПО КАЧЕСТВУ: Было бы здорово, если бы чат-бот распознавал часовой пояс пользователя и соответственно приветствовал его. Что касается языка, то система должна иметь доступ к соответствующим настройкам устройства или начать разговор, указав эти данные. Если важна валюта и другие детали локализации, чат-бот также должен указывать их с помощью вопросов.
+
+Источники:
+
+* [Building a Chatbot using Chatterbot in Python](https://www.datacamp.com/community/tutorials/building-a-chatbot-using-chatterbot)
+* [Chatbot Testing: Features to Check & Quality Tips to Keep In Mind](https://www.qamadness.com/chatbot-testing/)
+
+Доп. материал:
+
+* [Как тестировать чат-бот / Chatbot testing](https://www.youtube.com/watch?v=9wpy2CwR-fU)
+* [BDD-тестирование чат-бота](https://habr.com/ru/company/oleg-bunin/blog/551430/)
+* [Chatbot Best Practices](https://www.chatbot.com/chatbot-best-practices/)
+* [Как улучшить сценарий чат-бота: коридорные тесты](https://robochat.io/blog/%D1%87%D0%B0%D1%82-%D0%B1%D0%BE%D1%82-%D1%82%D0%B5%D1%81%D1%82/)
+* [Using A/B Testing to Create Effective Chatbot Strategy](https://landbot.io/blog/chatbot-ab-testing)
+* [Основные различия между Viber и Telegram и как тестировать боты для них](https://blog.ithillel.ua/articles/osnovnye-razlichija-mezhdu-viber-i-telegram-i-kak-testirovat-boty-dlja-nih)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-elektronnykh-pisem-e-mail.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-elektronnykh-pisem-e-mail.md
new file mode 100644
index 0000000..9200008
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-elektronnykh-pisem-e-mail.md
@@ -0,0 +1,140 @@
+# Тестирование электронных писем (E-mail)
+
+Тестирование электронной почты относится к нескольким методам проверки электронной почты перед ее отправкой. Для маркетологов по электронной почте это больше касается анализа контента и кампаний A/B-тестирования. Для разработчиков и QA, которые работают с приложениями, отправляющими транзакционные электронные письма, тестирование электронной почты относится к более широкому циклу действий - от анализа HTML до обеспечения доставки электронной почты.
+
+**Ошибки рендеринга = плохой пользовательский опыт**
+
+К сожалению, не все почтовые клиенты в одинаковой степени поддерживают HTML и CSS. Например, Outlook или приложение Gmail для учетных записей, отличных от Google, не отображают фоновые изображения. Точно так же почтовые клиенты часто имеют определенные рекомендации по разработке электронных писем: Yahoo Mail обеспечивает соблюдение полей, в то время как Gmail обрезает письма, которые длиннее 102 КБ. Поскольку дизайнеры не обязательно заботятся о стандартах рендеринга в широком спектре почтовых клиентов, задача тестировщика - удовлетворить все требования.
+
+Вот почему вам следует сосредоточиться на тестировании кампаний, прежде чем делиться ими с пользователями. В противном случае человек может увидеть ваше письмо обрезанным, со смещенным макетом, не отвечающим на запросы или неподдерживаемым содержанием. В результате плохой UX гарантирован, и есть большая вероятность, что клиенты не вернутся. Если учесть, что вся кампания содержит битые электронные письма, это расстраивает.
+
+**Доставляемость берет свое**
+
+Обеспечение надежного пути между электронной почтой в приложении и конечными пользователями имеет решающее значение для поддержки больших баз пользователей. Поскольку многие команды используют уведомления по электронной почте для обмена паролями и уведомления сообщества об обновлениях продукта, невозможность связаться с подписчиками - серьезная проблема.
+
+Возьмем для примера типичный кейс регистрации на сайте. Какую роль может играть подтверждение e-mail при регистрации?
+
+* Провести double opt-in, т.е. убедиться, что был введён валидный адрес пользователя и этот пользователь действительно дает свое согласие на регистрацию на данном ресурсе и получение дополнительных рассылок/писем. Это позволяет отсеивать "мусорные" регистрации, когда подписывают на что-нибудь посторонних людей (намеренно или нет), уменьшать количество спама (за что очень больно бьют по рукам) и т. д.;
+* Для защиты страницы. Если кто-нибудь попытается получить доступ к аккаунту пользователя, то на почту пользователя придет соответствующее уведомление;
+* Для быстрого и самостоятельного восстановления доступа (логина и пароля). Многие пользователи испытывают затруднения при восстановлении доступа, если не указали email при регистрации;
+* Для отправки необходимой информации и электронного чека после оплаты услуг сервиса;
+* Для защиты от ботов;
+* Если не подтверждать емайл, то в этом поле можно будет написать все что угодно (в рамках проверки). Соответственно один и тот же пользователь будет регистрироваться множество раз, забывая и свой предыдущий пароль, и логин.
+
+В электронном маркетинге доставляемость электронной почты - это X-фактор, который определяет, может ли пользователь получить доступ к вашему важному сообщению. Критериев, определяющих доставляемость кампании, множество: количество писем, попавших в спам, взаимодействие пользователей с письмами, показатель отказов и другие.
+
+Обеспечение бесперебойной доставляемости - тяжелая работа, и обычно за нее отвечает команда инженеров. QA должен помнить, когда и сколько транзакционных электронных писем отправляет веб-сайт или приложение. Наоборот, спустить все усилия на ветер на удивление легко - нескольких неработающих ссылок или неудачной проверки на спам достаточно, чтобы свести на нет месяцы усилий.
+
+Тестирование доставляемости (Deliverability testing) - это способ предотвратить такие разочаровывающие неудачи, поскольку оно позволяет команде контроля качества:
+
+* избегать спам-ловушек (поддельные электронные письма, рассылаемые интернет-провайдерами по всему Интернету, которые часто сканируются ботами и включаются в базу подписчиков);
+* выяснить, какие элементы инфраструктуры электронной почты настроены неправильно (IP-адрес, записи DNS, записи аутентификации электронной почты и т. д.);
+* убедиться, что в контенте нет спам-триггеров.
+
+Если QA или разработчик игнорируют проверки на спам и тестирование доставляемости, кампании или важные электронные письма не доходят до конечного пользователя. Как пользователю сбросить пароль или получить ссылку для регистрации, если непроверенное письмо летит куда-то по сети? Из-за недоставленных электронных писем компания может пострадать от потери клиентов и других сбоев в бизнесе.
+
+**Репутация затронута**
+
+Теперь высоко персонализированные электронные письма являются прочной тенденцией. Однако при отправке сообщений, полных динамических тегов, ситуация часто выходит из-под контроля.
+
+Не новость, что получатели получают письма с неправильными тегами имен или темами вроде «Здравствуйте, имя пользователя». Для брендов небольшие оплошности убивают конверсию всей кампании и ухудшают отношения брендов со СМИ. Причина проста: у вас не будет второго шанса произвести первое впечатление. Если вы облажаетесь один раз, подписчики, скорее всего, пометят письмо как спам или оставят отрицательный отзыв. И бренд будет ассоциироваться с отправителями неработающих писем только потому, что кто-то пропустил тестирование HTML/CSS.
+
+**Четыре болевые точки тестирования электронной почты (+ способы их обойти)**
+
+**1. Тестовые электронные письма отправляются реальным пользователям**
+
+Эта досадная проблема возникает из-за того, что группы контроля качества используют рабочие домены для запуска тестовых сессий . В результате легко перейти черту и случайно отправить тестовое сообщение списку подписчиков. Вдобавок ко всему, использование производственного сервера для запуска тестов раздувает объемы отправки для домена и наносит ущерб авторитету домена. Легко убедиться, что вы не отправляете электронные письма реальным пользователям по ошибке, если вы используете отдельную среду для тестирования. Есть два способа безопасно протестировать электронную почту:
+
+* Тестирование среды разработки с использованием API-интеграции;
+* Использование инструментов, имитирующих работу реальных SMTP-серверов с возможностью проверки общих SMTP-портов и других элементов инфраструктуры.
+
+**2. Низкая доставляемость (или попадание в спам-папки)**
+
+Если ваши электронные письма с предварительным просмотром попадают в «Спам», это не обязательно красный флаг. Прежде чем предупредить команду маркетинга и перепроверить инфраструктуру, вычеркните следующие возможности:
+
+* В вашем электронном письме для предварительного просмотра все еще есть текст-заполнитель. При отправке тестовых писем убедитесь, что тело сообщения точно такое, какое увидит пользователь. Такие артефакты, как «[Lorem Ipsum dolor](https://ru.wikipedia.org/wiki/Lorem\_ipsum)», запускают спам-фильтры и снижают вероятность доставки тестового письма;
+* Вы не открываете собственные тестовые электронные письма. Если вы используете свой собственный адрес для проверки электронных писем, если вы не взаимодействуете с ними, интернет-провайдеры пометят письма как неактуальные и начнут отправлять их в спам;
+* Адрес отправителя и получателя совпадают. Для успешной доставки электронных писем почтовые клиенты требуют, чтобы адреса отправителя и получателя не совпадали с одним и тем же почтовым ящиком. Итак, когда вы делитесь тестовым сообщением с самим собой, выберите адрес электронной почты, отличный от того, который вы используете для отправки теста.
+* Нет ссылки «Отписаться». Пакеты, в которых нет нижнего колонтитула «Отписаться», с вероятностью 99,9 % будут отклонены или будут помечены как спам;
+* Добавление скриншота отписки.
+
+**3. Плохой рендеринг и кросс-девайсный отклик**
+
+Еще одним препятствием для проверки качества является обнаружение того, что сообщения отображаются по-разному в почтовых клиентах или типах устройств. Если это относится к вашему тестовому пакету, вот несколько соображений по рендерингу для конкретного клиента, которые вы должны проверить в теле письма:
+
+Gmail :
+
+* Изображения поддерживаются по умолчанию;
+* Электронные письма размером более 102 КБ автоматически обрезаются;
+* Тег style размещается в заголовке письма;
+* Автоматическое масштабирование электронных писем на iPhone (изображения будут казаться смещенными от центра, поэтому лучше указать «padding:0» в body;
+* Минимальный размер текста - 10,5 пт для текста и 16,5 пт для заголовков, чтобы обеспечить удобочитаемость на смартфонах.
+
+Outlook:
+
+* Нет поддержки фоновых изображений;
+* Нет поддержки интерактивных элементов, таких как формы или флажки;
+* Нет поддержки видео HTML5 или GIF;
+* Ограниченная поддержка заполнения.
+
+**4. Низкая эффективность тестирования**
+
+Еще в 2000-х тестирование электронной почты было ручным, статичным и утомительным. Команде тестирования нужно было с нуля создавать электронные письма и отправлять их на тестовые адреса. Хорошая новость заключается в том, что в настоящее время большинство этих шагов можно легко автоматизировать.
+
+Вот несколько инструментов, которые помогают QA-командам тратить меньше времени на тестирование отдельных элементов электронной почты:
+
+* Email preview: Litmus;
+* Email servers: GMass;
+* Email API: Mailosaur;
+* Spam check: SpamAssassin;
+* Email deliverability: Mail-Tester;
+* HTML check: HTML Email Check;
+* Browser automation system: Selenium.
+
+Если вам нужно комплексное решение для тестирования, которое позволит протестировать все технические аспекты электронной почты, включая SMTP, API, HTML/CSS, отдайте предпочтение удобным для совместной работы инструментам, таким как Mailtrap .
+
+**Основные элементы электронной почты, которые вы должны протестировать**
+
+Теперь, когда вы знаете, почему нельзя отказаться от тестирования электронной почты, и понимаете, как справляться с основными препятствиями, с которыми сталкиваются группы контроля качества при проведении сеансов, пришло время создать пошаговую стратегию тестирования, которая обеспечит высокую доставляемость и безупречный рендеринг ваших писем.
+
+**1. SMTP-мониторинг**
+
+Ошибки SMTP являются распространенной причиной проблем с доставкой электронной почты или сбоев всей инфраструктуры электронной почты. Вот проблемы, на которые QA должны обратить внимание:
+
+* Брандмауэр блокирует связь;
+* Ответ сервера занимает слишком много времени;
+* SMTP-сервер подключается с неправильным именем хоста;
+* SMTP не поддерживает данные команды.
+
+Чтобы упростить оценку SMTP, группы контроля качества используют специальные инструменты: Web Biz или Wormly .
+
+**2. Тестирование API электронной почты**
+
+Тестирование API позволяет разработчикам тестировать электронные письма, не выходя из среды IDE. Используя API, вы можете:
+
+* Максимально автоматизировать процесс;
+* Получать письма в коде;
+* Извлекать и проверять содержимое тестового электронного письма;
+* Применять сопоставление с образцом;
+* Отправлять тестовые письма с вложениями.
+
+Различные языки программирования запускают разные сценарии для тестирования электронной почты API. Чтобы упростить процесс, рассмотрите возможность внедрения таких инструментов, как Mandrill или MailSlurp.
+
+**3. Локальная тестовая отправка электронной почты**
+
+Еще один способ проверить электронную почту - настроить локальный сервер. Таким образом, группы контроля качества снимают нагрузку с производственной среды и отделяют тестирование от реальной кампании. Тестирование электронной почты на локальном сервере - это полезный способ убедиться, что вы не отправляете тестовую партию подписчикам по ошибке. Инструментами, которые следует рассмотреть, являются Mailhog или Mailcatcher .
+
+**4. Доставляемость электронной почты и тестирование на спам**
+
+Как мы уже упоминали, доставляемость электронной почты и тестирование на спам помогают контролировать репутацию вашего домена и IP-адреса и обнаруживать, не занесен ли адрес отправителя в черный список интернет-провайдерами. Mail-Tester или GlockApps могут пригодиться.
+
+Источники:
+
+* [Should QAs care about email testing?](https://theqalead.com/topics/should-qas-care-about-email-testing/)
+* [Подтверждать ли email](https://www.rsdn.org/forum/web/6075019.hot)
+
+Доп. материал:
+
+* [Чек-лист. Где нужно тестировать верстку email «руками»](https://vc.ru/marketing/169685-chek-list-gde-nuzhno-testirovat-verstku-email-rukami)
+* [10 best email testing tools for optimized delivery](https://theqalead.com/tools/best-email-testing-tools/)
+* [A/B тестирование для email писем. 30 идей тестов](https://habr.com/ru/company/sendpulse/blog/299932/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-igr-game-testing.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-igr-game-testing.md
new file mode 100644
index 0000000..3511103
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-igr-game-testing.md
@@ -0,0 +1,212 @@
+# Тестирование игр (Game testing)
+
+Для тестирования видеоигр, как и в других направлениях, есть “стандартные” и свои особенные подходы для решения определённых задач. Давайте рассмотрим их!
+
+**Playtesting** - это один из видов тестирования игр, который предназначен для понимания какой игровой опыт и эмоции получают игроки от игрового процесса. Для проведения плейтестов игрокам дают доступ к раннему билду (данный вид тестирования проводится до релиза игры и/или фичи). Чаще всего в плейтестах участвуют не QA специалисты, а рядовые геймеры, родственники, в общем кто угодно, кто может взглянуть на ваш продукт свежим взглядом, дать вам обратную связь на основе своего игрового опыта и впечатлений, а также будет уважать то, что написано в подписанным им NDA перед стартом плейтеста.
+
+Мнения о том, нужно ли подключать команду разработки, включая QA, в плейтестинг, сильно разняться, т.к. фидбек от знающих свою игру на зубок людей может быть не настолько ценен для вас, здесь напротив важно понять заинтересованность в игре вашей же целевой аудитории. Проводить плейтестинг внутри компании или же приглашать “внешних” людей - решение вашей компании на основе ее желаний и возможностей. Подробнее про плейтесты можно почитать [тут](https://dtf.ru/gamedev/166864-kak-rabotayut-pleytesty).
+
+Говоря о специфических для видеоигр видов тестирования, я бы выделил такую группу как **Game Design Testing**, куда включу Balance testing, Level Design testing, "Fun Factor" testing).
+
+**Balance Testing** предполагает проверку того, что баланс есть:
+
+* одно оружие не критически сильнее/слабее другого в этом же классе,
+* среди персов и их перков нет имбы в той или иной комбинации,
+* классы персонажей побеждают друг друга как задумано (как в камень-ножницы-бумага),
+* легкий уровень сложности не слишком легкий, сложный - не слишком сложный и т.п.
+
+Возможно местами даже стоит подумать о мете игры, но это уже как бонус, этим должен заниматься уже явно не Quality Assurance специалист. Однако QA может сделать заметки и поделиться с командой!
+
+**Level Design Testing** подразумевает проверку уровней (левелов). Даже самый красивый визуально уровень может содержать непроходимые места из-за, например, невидимых стен (есть модель (меш), но нет текстур), дырок в полу (к примеру из-за плохой стыковки плоскостей или моделей), попадания в так называемые Stuck points, где встрял и уже никуда дальше сдвинуться персонаж не может.
+
+Такой достаточно абстрактный вид тестирования как **Fun Factor Testing** кто-то выделяет отдельно, а кто-то считает, что это часть Playtesting. Здесь упор делается на "фановость" процесса игры. Идеально сбалансированная игра может банально не весело играться и это отпугнет аудиторию. Также тут стоит проверить такие игровые механики как навигация, прицеливание, взаимодействие с предметами, NPC и т.д. Неудачные механики, непривлекательный арт, также находится на этой стадии. Если вас в процессе ничего не фрустрирует, вы на верном пути =) Больше про плейтесты, включая Fun Factor, можно посмотреть [тут](https://www.youtube.com/watch?v=Ee77xsVEfKI), хоть я и не во всем согласен с автором.
+
+Чуть выше кто-то где-то упомянул персонажей/уровни/предметы и т.п.? Т.е. мы начинаем говорить о **Visual Components Testing** группе, куда можно внести тестирование 3D моделей/сцен, 2D (спрайты) и 2.5D.
+
+**3D Models Testing** включает в себя проверку корректности модели (хай и лоу поли) на визуальную составляющую и кол-во полигонов, выставленное в требованиях. Также проверяются все ли текстурные карты доступны и используются для моделей, есть ли отображение внутренней стороны моделей (если они видны), не ломается ли модель во время анимации (риггинг и правильный скиннинг). Во время таких проверок всегда можно заранее найти проблемы с, например, текстурными картами и запечь новые для фикса найденной проблемы.
+
+**2D и 2.5D Testing** - тестирование уже 2D и 2.5D графики. Сюда включают работу со спрайтами (2D), проверка спрайтов и/или 3D моделей для 2.5D игр, часто в таком виде делают файтинги, сайд скроллеры или рогалики. В качестве примеров тестирования, можно привести проблемы с порядком отрисовки мира и героев в изометрических проектах, с "окошком", которое показывает ГГ, если он за стеной (в качестве примера тут можно привести такие игры как Fallout 1 и 2), ну и часто встречаемые в целом нюансы с прозрачными объектами. Хоть ваш проект и в 2D/2.5D, однако такие элементы в нём могут взаимодействовать с 3D объектами и сложными эффектами, связанные с прозрачностью. Один из плохих сценариев в данном случае, когда объект из нескольких спрайтов растворяется или появляется через alpha и alpha каждого спрайта считается отдельно. Как итог вы получите на вид 3 несвязанных объекта вместо 1 ожидаемого. Для предотвращения таких случаев можно рендерить объект в текстуру и уже её использовать для эффекта, чтобы не терять целостность.
+
+Говоря о персонажах, мы не ограничиваемся только игровыми персами и их моделями. Сюда также стоит отнести NPC, а также врагов с их AI, а тут уже целое поле для группы **AI testing**, куда я включу проверку таких фичи как Pathfinding, AI Spawning, AI Reaction, Detection Range / NPCs (конус зрения) и т.п.). Ведь всегда приятно, когда массовка ведёт себя правдоподобно, не утыкаются в сцены, враги появляются не за спиной или перед игроком и так далее. Тут же проверяем, что Импостеры правильно спаунятся (импостер - это 2D спрайт в 3D массовке или очень лоу поли модели, нужны для разгрузки мощностей вашей машины). Явный пример использования импостеров можно увидеть в финальном сражении Serious Sam 4. Тут стоит упомянуть, что такая уловка используется не только для AI, но также и для отрисовки части игрового мира: которая находится достаточно далеко от игрока, но всё же видна на фоне. Это может быть что угодно: отдельные элементы, город, лес, горы, и т.д. Всё это может быть заменено импостером, пока игрок не подойдёт достаточно близко (такой подход также известен как billboard sprite). Также важно проверить Navigation Mesh (Nav Mesh), чтобы убедиться, что враги и NPC будут двигаться не в предметы и стены. Больше о толпах NPC можно посмотреть [здесь](https://www.youtube.com/watch?v=XBWTD4kn8jM).
+
+Такие хитрости как замены хай поли на лоу поли модели или даже на Импостеров, баланс и скорость отображения полигонов на загруженных сценах, обработка эффектов и т.п. очень сильно могут снизить производительность и количество кадров в секунду (FPS). Данные аспекты проверяются в рамках всем нам известного **Performance Testing**. Я бы отнес плюс/минус в эту категорию и Soak Testing, благодаря которому ищут memory leaks в играх. Также в рамках группы по тестированию производительности стоит отнести Stability testing, в рамках которого вы находите такие всеми любимые вещи как фризы, краши, черные экраны, невозможность загрузить уровень, порча сохранённых данных и прочее.
+
+Однако проблемы могут возникнуть не только при большом количестве моделей на экране, но также и при большом количестве онлайн игроков в вашей игре. Хотя и не при большом, если вы не протестировали неткод в рамках **Network Testing**. Благодаря данному виду тестирования можно также проверить лаги/дропы в соединении, matchmaking, стабильность конекшенов, инпут лаги контроллеров и многое другое. Немного отходя в сторону, я бы выделил ещё баги, которые воспроизводятся при плохом интернет соединении и, если у вас со скоростью интернета всё хорошо, то нужно эмулировать "плохое интернет соединение". Больше о неткоде и типах соединения можно посмотреть [здесь](https://www.youtube.com/watch?v=Qks4EFAupC4).
+
+Уже всё вышеописанное звучит достаточно громоздкая и сложная система. Но это ещё ничего, ведь мы больше говорили о front-end части (клиент), а ведь **Back-End часть и Back-End testing** никто не отменял. Здесь мы пробегаемся по вашему беку, который часто включает базы данных, API (к примеру REST API), телеметрию и многое другое.
+
+Выше я говорил о производительности на железе, но не уточнил о каком именно, а ведь игры нужно оптимизировать и переносить на разное железо различных платформ - Playstation 4/5, XBox Series X/S, Nintendo Switch, Steam Deck и самые различные и неповторимые конфигурации вашего персонального красавца (ПК). За это отвечает, как вы уже догадались, **Compatibility testing**. Многие платформы имеют разные режимы работы, к примеру 4K 30FPS + Raytracing, 1080p 120fps и т.д. Та же Nintendo Switch работает в 2х режимах: портативном (720р) и стационарном (1080р). Не стоит забывать и о тенденции "геймпады везде и всюду" и обязательно стоит проверить, что самые разнообразные контроллеры могут работать с вашей игрой на ПК или консоли - разнообразные контроллеры, руль и педали для авто симуляторов, джойстики, контроллеры в виде музыкальных инструментов и т.п. Все они имеют в вашей игре корректные иконки при переключении контроллеров, а также все конфигурации для них работают исправно.
+
+Также относительно недавно начал активно развиваться рынок VR и AR приложений и игр. **VR и AR Testing** я хочу выделить отдельно, т.к. данные устройства имеют слишком много особенностей, чтобы запихнуть их под одну гребенку с остальными девайсами. Как интересный факт из практики: у VR есть "физическое" ограничение, из-за которого не все смогут разрабатывать/тестировать под VR, а именно - моушн сикнес (укачивание), который возникает при использовании шлемов.
+
+Важно держать во внимании, что кроме ваших собственных стандартов качества к игре, свои стандарты есть у платформодержателей. Часто такие проверки называются Technical Requirements Checklist или TRC, а проверяются они в рамках **Compliance testing** и, часто, не вашей командой, а командой QA на стороне платформодержателя. В рамках данного тестирования вы можете также проверить внутриигровые покупки, достижения (Achievements), подписки (subscriptions), если они у вас есть, а также поддержку фич стриминговых сервисов. Часто для таких нужд "отпочковывается" отдельный билд, который доводят до ума и не аффектят его изменениями основной билд.
+
+Похожая ситуация происходит во время Альфа и Бета тестирования. **Pre-Alpha, Alpha и Beta Testing** это больше не о подходе к тестированию, это о срезе игры в определенный момент времени и проверки готовности определённого скоупа на той или иной стадии. Ранее часто подразумевалось, что Альфа - это еще внутреннее тестирование, а Бета - уже внешнее (например, закрытое бета тестирование, когда ключи от билда дают определенному количество игроков). Сейчас же много игр выходит в раннем доступе и альфа билды становятся доступны широкому количеству игроков. Живой фидбек даёт понять разработчикам что они делают (не)верно, что помогает оперативно реагировать и удовлетворять нужды игроков.
+
+Но даже на таких ранних стадиях важно, чтобы игроки могли удобно использовать различные контроллеры во время геймплея и навигации по вашей игре - вот мы и пришли к **Usability testing**. Здесь никакого секрета нету, вашей игрой должно быть интуитивно понятно и приятно пользоваться.
+
+Более чем уверен, что много читателей данной статьи - аудиалы. Звук в играх, как и в кино - один из самых важных и мощных инструментов для влияния на игрока. За тестирование таких нюансов как триггер и проигрыш музыки, звуковых эффектов (SFX), диалогов и реплик, миксовка музыки под происходящее на экране и прочее отвечает **Audio testing**. Для работы со звуком есть специализированный софт и триггеры многих эффектов и реплик можно найти в автоматическом режиме. Если вы не специализируетесь на тестировании аудио, то скорее всего ваши задачи будут лимитированы пунктами выше. В ваши задачи далеко не всегда будет поиск и использование нужных звуков, главное - заимплементировать возможность проигрыша их при определённых условиях, а далее аудио команда уже сделают оставшуюся магию за вас - вставит нужное аудио или создаст абсолютно новое! Всегда приятно, когда саунд-дизайн в вашей игре на высоте!
+
+А еще приятнее пользоваться игрой на родном для вас языке + выход на глобальный рынок подразумевает больший охват потенциальной аудитории. Вооружившись знаниями по тестированию **I18N и L10N** вы сможете сделать так, чтобы от вашей игры получали удовольствие даже в противоположной от вас части земного шара! В качестве особенности проверки локализации игр (Localization testing), стоит упомянуть разницу в часовых поясах ваших игроков и сервера, а также возможность манипуляции времени и даты на вашем устройстве через смену даты и/или времени через календарь. Часто это приводит к разнообразным ошибкам или нежелательному результату. К примеру если вы засетали какой-то контент для отображения с определённой даты, то хитренький пользователь может сменить дату на будущую и заранее увидеть всю ту красоту, что вы ему подготовили и спойлернуть это всем. Даже дата майнингом заниматься не обязательно :) Для проверки корректности языков есть специальные команды локализации, но не забывайте, что в ваших силах проверить языко-независимые вещи в рамках данного тестирования и это стоит сделать заранее!
+
+Странно, что я так долго обходил стороной упоминание основы основ -\*\* функциональное и нефункциональное тестирование\*\*. Здесь есть где разгуляться и не всегда вам нужно глубокое знание игр и их механик. Самый главный документ с требованиями, который вам точно будет нужен - это [Game Design Document](https://en.wikipedia.org/wiki/Game\_design\_document) (GDD). Здесь описаны все основные и важные нюансы по вашей игре. Есть даже мнение со стороны разработчиков, что тестировщикам не нужно разбираться в играх, чтобы их тестировать, ведь есть GDD и многие другие доки с требованиями. С этим утверждением я больше не согласен, т.к. знание механик, трендов и игр в целом помогает проводить анализ найденных ошибок и создания комплекса ивентов для предотвращения появления их в будущем или возможности найти их на самых ранних стадиях. Формально, да, можно тестировать без знания и понимания многих вещей, да и на аутсорс нередко отдают разработку и тестирование, не связанное с геймплеем или изменением основных геймплейных механик, но так можно тестировать всё, что угодно и это ничем не будет отличаться от Monkey Testing или, если QA крайне пылает энергией и энтузиазмом, но отказывается изучать особенность домена - Gorilla Testing.
+
+Мы уже поговорили о ПК, консолях, даже о VR и AR играх, но не обсудили те девайсы, которые используют большинство геймеров - мобильные телефоны. Как минимум основы **Mobile Testing** важно знать и понимать, ведь оооочень много игр выходит на мобилки и этот рынок уже давно обогнал по выручке консоли и ПК. Да, игры эти, в большинстве своём, казуальные и гиперказуальные, но и далеко не все игроки "хардкорные" и имеют достаточно времени, чтобы играть в ААА и инди игры на ПК и консолях. Все виды тестирования, упомянутые выше, действительны и для мобильных игр, но также тут важно знать специфику мобильных девайсов и приложений!
+
+Не стоит также забывать и о **Security Testing**, использование которого глобально не отличается от других сфер. В играх используются учетные записи, аккаунты от разных систем, включая онлайн сервисы и аккаунты от ваших учеток на консолях (к примеру вам нужно играть играть в Rocket League через Epic Games аккаунт, но в системе Playstation), В наше время крайне важно уделять этому аспекту достаточно внимания, ведь никто не хочет потерять даже одну игру, которую этот человек купил или донатил в ней, не говоря уже о потере целого аккаунта со всем "наработанным" добром!
+
+Также стоит упомянуть работу с DRM системами (Denuvo и т.д.) и Anti-Cheat программами (Easy Anti-Cheat и т.п.).
+
+В качестве финального пункта на сегодня в разделе "видов тестирования" важно выделить **Game Automation Testing**. Автоматизация в геймдеве является достаточно сложным процессом. Многие вещи крайне сложно поддаются автоматизации, к примеру, геймплей, ведь важно не только "знать" расположение персонажа, но и понимать, что вокруг него происходит. Если у вас есть рандомайзер, который спавнит врагов в разное время и в разном количестве или ваши элементы для "3 в ряд" появляются далеко не всегда одинаково, то вам нужно придумать что-то наподобие бота для автоматизации и осмысленных действий в рамках ваших тестов. Думаю вы уже догадались, что автоматизация UI элементов или навигации по таким экранам как "Главное Меню" не составит большого труда. Геймплей же автоматизируют при помощи написания своих ботов. Также можно использовать Image Recognition тулы, они также хорошо подходят и для автоматизации скринов без геймплея. Про одну такую интересную тулу (Airtest) я писал в своих предыдущих статьях. Вот они: [раз](https://habr.com/ru/post/461773/), [два](https://habr.com/ru/post/462587/) и [три](https://habr.com/ru/post/464181/).
+
+**Разновидности «игровых» багов**
+
+Картинки примеров см. в источнике.
+
+В категорию **Visual** багов войдут:
+
+* **Visual Artefacts** - любые визуальные баги, не подпадающие под другие виды.
+* **Missing Textures** - пропущенные/исчезнувшие текстуры. Обычно на их месте стараются ставить "заглушку" в виде яркой текстуры по умолчанию в виде шахматной доски. Это не обязательно, но благодаря такому подходу, пропущенные текстуры видны не вооруженным взглядом.
+* **Z-fighting** - данный баг появляется, когда несколько примитивов расположены на примерно одинаковом расстоянии до камеры и они имеют фактически одинаковые значения в Z-buffer, которые отслеживают глубину. Из-за этого примитивы могут частично отображаться один над другим.
+* **Screen Tearing** или "разрыв экрана" - это визуальный артефакт, при котором отображается информация из нескольких кадров на одном изображении.
+* **Culling и Clipping** - баги, относящиеся к работе рендера и графического пайплайна. Часто - пересечение двух объектов, при котором один закрывает геометрию другого, скрывая ее от взгляда. Если немного углубиться, то Culling - это отсечение того, что заведомо невидимо. В таком случае игра даже не будет пытаться отрисовать данный сегмент. Culling бывает разным и вот его примеры: rustrum culling - отсечение по пирамиде видимости, backface culling - отсечение "задних" граней, occlusion culling - отсечение граней факту их перекрытия другой геометрией, depth culling - перекрытие одной геометрии другой, которая уже была нарисована, но на основе depth buffer. А вот когда рисуется достаточно большой полигон и от него отрезается всё то, что заведомо находится за пределами экрана - это уже Clipping.
+* Также отдельно стоит выделить похожий, но в сути другой баг - **проблемы коллизий**. В видеоиграх отсечение может быть связано с набором алгоритмов, которые реагируют на взаимодействие двух смежных или перекрывающихся геометрий (collision detection). А для выявления таких багов существуют специальные режимы просмотра (view modes).
+
+В рамках **Audio bugs** группы выделю достаточно базовые, но не менее надоедливые вещи:
+
+* невозможность проиграть SFX/музыки/диалога,
+* пропуск (триггера) проигрыша,
+* плохое микширование (звук слишком тихий или громкий),
+* искажения (distortions),
+* дропы.
+
+Баги **левел дизайна**:
+
+* **Invisible Walls** (невидимые стены) могут являться как багом, так и фичей. Ранее так ограничивали передвижение персонажа игрока и не давали уйти дальше нужного. Сейчас же стараются не создавать "невидимых препятствий", а ограничивать "проходимость" при помощи левел дизайна, к примеру выставить непроходимую преграду, баррикаду, горы, ворота города и т.п. Показывать игроку, что впереди что-то есть, но при этом использовать невидимые стены для недопуска персонажа в эту зону - признаки плохого левел дизайна. Сейчас так почти не делают и невидимые стены часто могут быть следствием реконструкции уровня: к примеру какую-нибудь модель могли забыть убрать или добавили невидимых элемент в качестве временной заглушки.
+* **Map Holes** чаще всего вызваны не плотным прилеганием плоскостей объектов (пол, стены и т.п.). Это места, где пользователь может, незапланированно для разработчиков, попасть за границы игровой зоны. Такие баги часто ещё называют Out of Bounds.
+* **Баги Navigation Mesh** часто связаны с перестройкой уровня или автоматической генерацией сетки. К примеру вы передвинули предметы, однако навигационная сетка осталась старой. Как следствие, ваши NPC могут "идти в стену" или любой другой предмет, который они не смогут обойти и встрянут там (один из случаев **Stuck Points**).
+
+**Ошибки искусственного интеллекта** (AI):
+
+* NPC не двигаются, застряли, не следуют за игроком,
+* предполагаемое взаимодействие с предметами не работает,
+* застревание,
+* NPC делают то, что не задумано изначально и т.п.
+
+Раз уж у нас есть и часть движка, отвечающая за физику, то было бы странно, если бы и **багов с физикой** не было. Тут может быть почти что угодно:
+
+* левитирующие объекты,
+* нереалистичная физика,
+* ускорение свыше нормы,
+* взмывание предметов " в космос" из-за сложения векторов при обработке контактов.
+
+Баги такого рода вы могли видеть в мемах самых разных игр, например GTA 5 или, из актуалочки, Cyberpunk 2077. Хороший разбор многих багов из Cyberpunk 2077, включая только что описанные, можно посмотреть [тут](https://www.youtube.com/watch?v=K5gUgY6DCiE).
+
+**Баги стабильности и перформанса** включают в себя:
+
+* фризы,
+* краши,
+* черные экраны,
+* невозможность загрузить уровень,
+* видимая для пользователя подгрузка хай поли моделей или вообще каких-либо объектов,
+* просадка FPS,
+* дооооооооолгая загрузка,
+* микрофризы (подгрузки).
+* Сюда же добавлю слишком долгую инсталляцию игры, а также невозможность запустить игру на ПК с минимально допустимыми требованиями.
+
+Не редко встречаются и **баги совместимости**. Особенно частые примеры выглядят следующим образом:
+
+* на некоторых видеокартах могут встречаться краши (к примеру на минимально возможных требованиях или новых видеокартах на рынке),
+* контроллеры той или иной фирмы не работают,
+* игра не запускается на какой-то определённой версии ОС,
+* беспроводная гарнитура выдает звук в моно и т.п.
+
+О проблемах онлайн игр наслышаны все. **Плохое соединение, лаги, "невидимые игроки"** или же "я зашёл за угол, а меня убили", **ошибки подсчета очков**, невозможность реконнекта (если такая фича есть), потеря пакетов во время игры, расхождение в подсчётах информации между клиентом, дедикейтед сервером и бек эндом. Также при плохом соединении некоторые элементы интерфейса можно использовать по несколько раз, что-то может не прогрузиться и "пропасть" и т.д., но, как правило, это UI баги и сильно не влияют на user experience игрока.
+
+Под **баги локализации и compliance**, из нетривиального, можно отнести:
+
+* локализацию рекламы,
+* размещение разных материалов на одних и тех же местах в разных регионах и странах (например, в этой стране запрещено к показу одно, а в другой - не запрещено или же возрастной ценз, под которые подпадает игра, может не разрешить что-либо показывать в том или ином регионе).
+* манипуляции с датой на вашем устройстве и сбой работы клиента с сервером.
+* "классические" баги локализации и интернационализации.
+
+**Подходы и инструменты**
+
+**Чит коды / Чит меню (Cheat Codes / Cheat Menu)**
+
+Чит коды изначально были не пасхалками или полезными ништяками для игроков, чтобы те могли загружать определенный уровень или установить себе бесконечное здоровье/деньги и даже были придуманы не для сохранений, хоть и могут быть так применены. Чит коды использовались разработчиками для отладки игр. Их, в силу разных ограничений, нужно было вводить на определённом экране игры или меню. Со временем коды попали в народ и стали крайне востребованы по понятным “божественным” причинам.
+
+Сейчас же вместо кодов, которые нужно запоминать и долго вводить, используются Чит Меню, в которых уже есть списки чит кодов, сгруппированных в удобный для использования вид. Данный список можно вызвать практически на любом экране, однако если код не подходит под текущие условия, то он не выполнится (к примеру если вы пытаетесь заспавнить объект в главном меню). Чит меню - это не типовая функциональность, у каждой игры оно имеет и уникальный вид, и уникальный код, ответственный за его реализацию.
+
+Однако с большой силой приходит и большая ответственность - использование чит кодов может привести к багам, которые в реальных игровых условиях никак не добиться. Именно по этой причине достаточно сложные и даже "странные" баги нужно перепроверять и воспроизводить без использования чит кодов, а также всегда держать в уме весь флоу, который должен пройти игрок, чтобы наткнуться на данную проблему. Также стоит учитывать и то, что есть большая вероятность, что тот или иной баг, легко воспроизводимый при помощи читов, игрок никогда на практике и не встретит.
+
+**Игровая консоль**
+
+Консоль в игре может и часто используется в качестве полезного в тестировании инструмента. Обычно вызывается она при нажатии кнопки "\~" (тильда), выпадает либо внизу небольшой строчкой, либо сверху экрана, занимая приличную его часть. Думаю многие использовали консоль в Counter Strike 1.6, превращая вашего персонажа из правши в левшу или меняя характеристики вашего прицела. Однако консоль не была включена по-умолчанию: её нужно было предварительно активировать в Options.
+
+При помощи консоли на дев билдах (к примеру сразу из Unreal Editor) можно подключать back-end с нужными вам тестовым аккаунтам, ускорять или замедлять игру (не FPS, а именно внутриигровые действия), использовать чит коды, включать-выключать нужные вам HUD и многое другое.
+
+**Внутриигровые HUD (Heads-Up Display)**
+
+Крайне полезные инструменты, которые, впрочем, без помощи разработчиков, не получить. HUD виджеты часто вызываются при помощи консольной команды. В зависимости от того, как разработчики настроят HUD, будет выводиться та или иная информация под определённые нужды. При помощи таких элементов крайне удобно следить за нанесённым уроном, прогрессам по испытаниям (challenges), использованием предметов (consumables) и т. п.
+
+Стоит упомянуть, что такие HUD разрабатываются разработчиками специально для отладочных нужд и их вполне может не быть в вашем проекте.
+
+**Weapon room / Training room**
+
+Такого рода комнаты, как правило, содержат оружие, персонажей, врагов (включая боссов), поверхности, предметы (consumables), транспорт. В общем всё необходимое и теоретически необходимое, что может пригодиться для тестирования во время геймплея. Кроме всего вышеперечисленного, в таких пространствах могут быть созданы комнаты под определенные нужды: например в одной могут быть расставлены предметы таким образом, чтобы проверить защищает ли преграда определённого размера вас в приседе, стоя и т. п.; в другой комнате - проходит ли персонаж между объектами и т. п.
+
+Такие пространства встречаются, как правило, в достаточно больших играх, ведь для их создания нужен бюджет и разработчики, которые смогут всё необходимое собрать вместе. Далее вы уже сможете и сами "достраивать" нужные вам пространства внутри данной карты, если умеете пользоваться редактором движка.
+
+**Файлы конфигурации**
+
+Файлы конфигурации встречаются повсеместно и вы можете ими пользоваться для самых разных нужд. В дев билдах таких файлов больше, чем в релизной версии, и через них вы можете включать/выключать фичи, менять разрешения, управлять уровнем логирования, указывать к какому back-end'у конектиться, управлять настройками графики и многое другое. Часто любители "игр в возрасте" ковыряются в файлах конфигурации (например формата ".ini") для настройки работоспособности старых игры на новом железе, если для неё не выходил соответствующий патч или переиздание. Количество и объём доступных настроек и их формат могу кардинально отличаться от игры к игре, даже если игры написаны на одном движке.
+
+**Управление вашим интернет соединением**
+
+Крайне важный пункт для проверки в наше время, т.к. даже в синглплеерных играх могут (и чаще всего встречаются) элементы, завязанные на онлайн. К сожалению здесь нету какого-то уникального и всеобъемлющего инструмента. Лично мне приятно и удобно использовать инструмент Clumsy в качестве помощника в этом деле. Программа манипулирует не игрой, а вашим соединением в целом, что делает Clumsy удобным инструментом для управления вашим соединением для абсолютно любых нужд: web, standalone software и т.п. В рамках данного инструмента вы можете управлять такими возможностями испортить ваше интернет соединение как Lag, Drop, Throttle, Out of order, Duplicate и Tamper. Причём делать это вы можете как для Inbound, так и для Outbound, указав шансы на встречу данной проблемы.
+
+**Режимы просмотра (View modes)**
+
+Игровые движки обладают такой функциональностью как "режимы просмотра" (view modes), которая помогает вам увидеть тип данных, обрабатываемых в вашей сцене, а также диагностировать любые ошибки или неожиданные результаты. У самых распространенных режимах просмотра есть свои горячие клавиши и они могут отличаться от движка к движку, но вы всегда можете просмотреть их все из режима просмотра или вызвать при помощи соответствующей команды в консоли. Ниже я приведу несколько примеров на основе View Modes из Unreal Engine, а больше и подробнее вы можете почитать в документации движка. Давайте же взглянем на несколько из них.
+
+**Инструментарий игровых площадок**
+
+Все игровые площадки предоставляют разработчикам свой инструментарий для загрузки и тестирования игры через их систему. Например Steam позволяет через меню Properties вашей игры переключать языки (локализация), запускать игру с вашими собственными параметрами (например запуск игры с нужными вам параметрами или переписи значений используемых параметров), позволяет проверять целостность файлов игры, вручную проверять обновления с вашей CI/CD системы и многое другое! Ну и само-собой площадки позволяют вам загрузить и добавить в библиотеку вашу игру по специальному коду. Если же игра уже доступна для скачивания игрокам или вы хотите использовать разные окружения (environments) для разных команд, то для таких нужд игровые площадки предоставляют возможность использования разных веток (Branches). К примеру один бранч смотрит на master client - test backend ("рабочее окружение"), а второй - production client - live backend (релизное окружение).
+
+Такой способ крайне удобен в использовании и помогает всем членам одной команды или даже разным командам использовать нужные всем версии игры без влияния друг на друга. При использовании "рабочего окружения" также площадки перед запуском спрашивают о необходимости запуска анти-чит системы.
+
+Во многих случаях тестировщикам даже не нужно использовать Editor build (запуск игры через редактор игрового движка), ведь большинство нужд покрывается, по умолчанию, билдом с площадки. Также такая версия билда является максимально приближенной к тому, что получит конечный игрок, что является важным критерием для выбора данных сборок в качестве главных кандидатов для регрессионного тестирования.
+
+**Общие инструменты**
+
+Говоря об инструментах, которые напрямую не связаны с тестированием, но могут облегчить вам жизнь, я бы выделил следующие: VCS (Perforce, Git), редакторы игровых движков, Grafana и Playfab.
+
+**Тестирование в азартных играх/казино (Gambling)**
+
+Гемблинг (от англ. Gambling - азартная игра) - игра, результат в которой полностью или в значительной мере зависит от воли случая (удачи).
+
+Хотя гемблинг и является собирательным типом для многих игр, букмекерских ставок, бинарных опционов и турниров по играм, тестирование каждого конкретного подвида может отличаться. Кроме того, гэмблинг может как относиться к тестированию игр в некоторых случаях, так и не иметь с ним вообще ничего общего.
+
+Из специфического:
+
+* тестирование различной математики (алгоритмы, вероятности и т.п.);
+* взаимодействие с законодательством;
+* финансовые операции (депозиты, кошельки, бонусы, реферальные программы).
+
+Источники:
+
+* [Поиграть в игру = протестировать игру. Почему это утверждение неверно?](https://habr.com/ru/post/587734/)
+* [Разновидности «игровых» багов](https://habr.com/ru/post/587700/)
+* [Протестировать Open World? Легко!!! Какие инструменты используются при тестировании игр?](https://habr.com/ru/post/587738/)
+
+Доп. материал:
+
+* [Как боты помогают тестировать игры](https://habr.com/ru/post/571528/)
+* [Тестировать игры - это очень трудно!](https://software-testing.ru/library/testing/other-testing/2260-testing-games-is-hard)
+* [Game Testing 101 - The Ultimate Beginner’s Guide](https://www.softwaretestingmaterial.com/game-testing/)
+* [Software Testing for Hyper-Casual Games: Simple Doesn’t Mean Easy](https://blog.qatestlab.com/2021/07/28/testing-hypercasual-games/)
+* [Online casino testing: challenges and solutions](https://blog.qatestlab.com/2018/12/26/online-casino-testing/)
+* [ISTQB Gambling Industry Tester](https://www.istqb.org/certification-path-root/gambling-industry-tester.html)
+* [Podlodka #252 - Теория игр](https://www.youtube.com/watch?v=ClSI4w4AcpQ)
+* [Как тестировать игровой баланс?](https://www.youtube.com/watch?v=Xf\_RwCpT7hY)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-internet-magazina-ecommerce.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-internet-magazina-ecommerce.md
new file mode 100644
index 0000000..a02a2b2
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-internet-magazina-ecommerce.md
@@ -0,0 +1,225 @@
+# Тестирование интернет-магазина (eCommerce)
+
+e-commerce (также известная как электронная коммерция или интернет-торговля) относится к покупке или продаже товаров и услуг в Интернете, а также к передаче денег и данных для завершения транзакции.
+
+Бизнес-модель веб-сайта электронной коммерции аналогична любой другой торговой площадке, модель варьируется в зависимости от того, кто покупает и кто продает. Как правило, бизнес, основанный на электронной коммерции, относится к одной из следующих пяти категорий:
+
+* Модель «бизнес для бизнеса» (B2B);
+* Модель «бизнес для клиента» (B2C);
+* Модель «клиент для клиента» (C2C);
+* Модель «клиент для бизнеса» (C2B);
+* Модель ««клиент для администрации» (C2A).
+
+**1. Кейсы для Домашней страницы**
+
+Домашняя страница является наиболее важным компонентом всего веб-сайта электронной коммерции, она служит мощным маркетинговым инструментом. Здесь тестировщик должен сосредоточиться на логотипе бренда, верхней навигации, поиске по ключевым словам, поведении страницы для зарегистрированных и незарегистрированных клиентов. Инженеры по тестированию должны проверить макет страницы, видимость контента, баннеры, карусели и другие функции.
+
+Примеры:
+
+* Время загрузки страницы должно быть в допустимых пределах;
+* Главное изображение должно автоматически прокручиваться в течение заданных интервалов времени;
+* Является ли изображение героя (?hero image) кликабельным? Если да, перенаправляет ли оно на нужную страницу?
+* Кнопка регистрации/входа должна быть видна и легко находима;
+* Ссылки на главной странице должны перенаправлять на нужную страницу;
+* Верхняя навигация, гамбургер-меню, категории, подкатегории должны быть четко перечислены;
+* Цветовая кодировка на главной странице должна соответствовать информации о бренде;
+* Базовый поиск по ключевым словам должен вести к соответствующим товарам.
+
+**2. Кейсы для поиска**
+
+Функциональность поиска является наиболее часто используемой функцией в любом магазине электронной коммерции, даже с самыми исчерпывающими списками товаров и простой в использовании навигацией. Таким образом, алгоритмы поиска должны были развиваться, становясь более совершенными и точными.
+
+Тестировщики должны сосредоточиться на том, является ли релевантным товар, найденный с помощью поиска.
+
+Примеры:
+
+* Соответствующие товары должны отображаться при вводе ключевых слов, таких как название товара, название бренда или название категории, например iPhone, ноутбук, лучшие книги по тестированию программного обеспечения;
+* Прямые совпадения или сопутствующие товары должны отображаться при поиске по определенному ключевому слову;
+* Результаты поиска должны отображать название товара, изображение, отзыв клиента и информацию о цене;
+* Когда для поиска используется страница определенной категории, должны отображаться результаты из соответствующей категории;
+* В верхней части списка всегда должны быть самые актуальные товары;
+* Даже если товар указан в нескольких категориях, он должен появляться в результатах поиска только один раз;
+* Когда в ключевом слове, введенном в строку поиска, есть опечатка, должны быть перечислены предложения;
+* Для отображения на странице должна быть возможность выбрать количество результатов;
+* Для многостраничных результатов должна быть доступна навигация ;
+* Для сортировки результатов по названию бренда, цене, отзывам или рейтингам и т. д. должны быть доступны параметры сортировки;
+* Проверьте функциональность фильтра, отфильтровав товары по бренду, доступности, цене, рейтингу клиентов и т. д.;
+* Проверьте функцию сортировки, отсортировав товары по популярности, релевантности, цене от высокой к низкой, от низкой к высокой и т. д.;
+* Проверьте, добавление элемента в избранное / список желаний;
+* Проверьте функцию «Добавить в сравнение».
+
+**№3. Страница сведений о товаре**
+
+Страница сведений о товаре - это место, где начинается процесс оформления заказа. На странице сведений о товаре больше всего сведений, собранных на одной странице. Легко погрузиться в исчерпывающее тестирование на одной странице, не видя общей картины.
+
+Тестировщик должен сосредоточиться на качестве изображения, кнопке «Купить» или «Добавить в корзину», отзывах клиентов, деталях цены и т. д.
+
+Примеры:
+
+* Детали контента, такие как название товара, описание, изображение, информация о цене (скидки, если доступны), вопросы и ответы должны быть видны;
+* Звезды отзывов клиентов и текст отзыва должны быть доступны;
+* Кнопку «Добавить в корзину» должно быть легко найти;
+* Проверьте функцию «Добавить в корзину»;
+* “Похожие товары” или “клиенты также купили” этот раздел должен быть видимым;
+* Изображения товаров должны иметь возможность масштабирования;
+* Страница отображения товара должна быть одинаковой на всех устройствах;
+* Наличие товара должно быть точным, если его нет в наличии, должно появиться соответствующее сообщение;
+* Селекторы количества товара, размера, цвета и т.п. должны быть доступны и работать должным образом;
+* Товар должен быть добавлен в корзину при нажатии кнопки «Добавить в корзину».
+
+**4. Рекомендуемые товары**
+
+Рекомендуемые товары - это самая важная часть страницы, но наиболее игнорируемая часть тестирования. После того, как клиент совершает покупку, происходит последующий сеанс, на котором ему показывают больше товаров, связанных с покупкой. Если клиенты начнут покупать отсюда, это увеличит прибыль еще больше.
+
+Тестировщик должен сосредоточиться на релевантности рекомендуемого товара приобретаемому товару.
+
+Примеры:
+
+* Рекомендуемые товары должны быть видны сразу после покупки;
+* Рекомендуемые товары должны иметь отношение к покупке, совершенной клиентом.
+
+**5. Платежи**
+
+Одной из наиболее распространенных причин, по которой покупатели покидают интернет-магазин, являются неудачные транзакции и сбой платежа.
+
+Тестировщик должен визуализировать их с точки зрения клиента, проверить требования и критерии приемлемости.
+
+Примеры:
+
+* Платежный поток (Payment flow) должен работать для всех различных вариантов оплаты;
+* Сохраненный способ оплаты должен быть доступен в процессе оформления заказа;
+* Варианты оплаты, такие как Visa, Mastercard, Paypal, UPI, должны быть видны с их логотипом;
+* Применяемые дополнительные предложения или коды скидок должны снизить цену покупки;
+* Конфиденциальные данные, такие как пароли, CVV, OTP и т. д., не должны сохраняться после завершения покупки;
+* Выполнение тестов безопасности является обязательным при хранении данных кредитных карт клиентов или любой другой личной информации;
+* При оформлении заказа в качестве гостя процесс покупки должен проходить гладко и позволить гостю зарегистрироваться после оплаты;
+* Должны происходить безопасные транзакции, и после оплаты клиенту должно быть предложено вернуться в приложение/сайт электронной коммерции;
+* Идентификатор транзакции и детали, связанные с платежом, должны быть сохранены вместе с деталями заказа;
+* Выполните тестовый платеж, используя каждый способ оплаты;
+* Убедитесь, что платеж обрабатывается правильно, используя все виды способов оплаты, таких как дебетовая карта, кредитная карта, интернет-банкинг, PayPal и т. д.;
+* Подтвердить недействительный платеж;
+* Подтвердить отмену заказа.
+
+**6. Корзина**
+
+Функция «Корзина» - одна из важных функций веб-сайта электронной коммерции, поскольку она помогает покупателю добавлять товары для покупки из разных частей сайта и покупать их вместе. Функциональность корзины является важной частью процесса оформления заказа.
+
+Тестировщик должен сосредоточиться на сложных расчетах на основе временных рамок, основанных на рекламных предложениях, кодах скидок, ваучерах и т. д.
+
+Примеры:
+
+* Функции оформления заказа должны работать должным образом;
+* При нажатии на кнопку «Купить» товар должен быть добавлен в корзину, а затем должна отображаться кнопка «Продолжить покупки» вместе с кнопкой «Перейти к покупке»;
+* Если количество товара больше одного, цена и количество должны измениться соответственно;
+* Такие детали, как стоимость доставки, налоги, должны отображаться вместе с ценой товара;
+* Должен быть четкий вариант удаления товара из корзины;
+* Цена заказа должна обновляться, когда покупатель добавляет/удаляет новый товар в/из корзины;
+* Покупатели должны иметь возможность добавлять товары в корзину из любой категории магазина;
+* Добавление товара в корзину;
+* Удаление товара из корзины;
+* Изменение количества товара;
+* Изменение варианта доставки;
+* Правильность суммирования НДС и стоимости доставки;
+* Pay Now test cases;
+* Процесс оформления заказа;
+* Оформление заказа и оплаты;
+* Проверьте окончательную сумму к оплате - убедитесь, что это значение правильное, после цены товаров, НДС, доставки и любых других сборов;
+* Внесите изменения в заказываемые товары, изменив варианты доставки и т. д., и убедитесь, что окончательная сумма обновляется правильно.
+
+**7. Кейсы после заказа** (Post-Order)
+
+Пост-заказ обычно представляет собой последующую сессию после того, как клиент приобрел товар. Обычно это включает в себя сведения о подтверждении заказа, e-mail о покупке, отслеживании заказа, сведениях о доставке и процедуре возврата.
+
+Тестировщик должен сосредоточиться на важных аспектах post-order use cases, таких как отмена заказа, возврат товара, детали отслеживания, сводные данные заказа и т. д.
+
+Примеры:
+
+* Клиенты должны получать сообщения о подтверждении заказа в SMS/Mail;
+* Клиенты должны иметь возможность отменить заказ;
+* Отмена заказа и возврат должны указать причины отмены/возврата товара;
+* Идентификатор заказа и детали, указанные в сводке, должны быть одним и тем же набором записей;
+* Клиенты должны иметь возможность просматривать историю прошлых покупок;
+* Кейсы возврата платежа;
+* Проверьте, успешно ли отправляются письма с подтверждением возврата получателю;
+* Клиенты должны иметь возможность отслеживать заказ.
+
+**8. Общие Кейсы**
+
+Общие кейсы для веб-сайтов/приложений электронной коммерции должны иметь надлежащее подробное покрытие и должны быть продуманно составлены. В частности, базовый пользовательский интерфейс, функциональность входа в систему, простота навигации по категориям, общий рабочий процесс и т. д. будут подпадать под общие тестовые примеры.
+
+Примеры:
+
+* Интернационализация и локализация;
+* Вводящий в заблуждение, оскорбительный или незаконный контент;
+* Роялти-фри изображения и нарушение авторских прав;
+* Функциональность персонализации;
+* Пользователи должны иметь возможность перемещаться по всем товарам в разных категориях на всех устройствах;
+* Ссылки и баннеры на сайте должны перенаправлять в соответствующие места, ни одна ссылка не должна быть битой;
+* Логотип и название интернет-магазина должны быть видны;
+* Перечисленные категории должны иметь последовательный шаблон, а текст должен быть легко понятным;
+* Подсчет общего количества товаров, перечисленных на страницах категорий, должен быть точным;
+* Регистрация пользователя - Вход/Регистрация;
+* Срок действия сеанса - если пользователь неактивен в течение длительного времени, система должна автоматически выйти из него;
+* Проверьте страницу моей учетной записи и функции управления профилями;
+* Проверьте тестирование пользовательской базы для клиентов, продавцов, супер администраторов, администраторов, сотрудников службы поддержки и т. д.;
+* Backend to Frontend integration testing;
+* Проверка работоспособности в нужных браузерах и их версиях;
+* Проверка работоспособности при наличии расширений браузера, например, блокировщиков рекламы;
+* Проверьте такие страницы, как «О нас», «Информация о доставке», «Политика возврата», «Положения и условия», «Политика конфиденциальности» и т. д.;
+* Скидки или промо-коды должны быть введены правильно.
+
+**9. Чек-лист SEO**
+
+Каждый владелец сайта электронной коммерции ожидает, что его товары должны показываться в верхней части результатов поисковой выдачи Google, когда пользователь ищет определенный товар. Только магазин электронной коммерции с надлежащим SEO может попасть в топ поисковой выдачи.
+
+Примеры:
+
+* Проверьте структуру URL-адресов;
+* Проверьте уникальные теги заголовков для каждой страницы и страницы товара;
+* Теги Title должны включать название товара и категорию;
+* Проверьте тег мета-описания для каждой страницы и страницы товара;
+* Проверьте наличие файла robots.txt;
+* Убедитесь, что к изображениям добавлен alt text;
+* Проверьте внутренние ссылки, чтобы облегчить индексацию;
+* Проверьте наличие XML-карты сайта.
+
+**Функции, которые должны быть протестированы в интернет-магазине**
+
+Успех сайта электронной коммерции зависит от двух ключевых факторов: функциональности и удобства использования. Если электронная коммерция удобна для пользователя и к ней легко получить доступ с разных устройств, больше пользователей будут использовать магазин, что приведет к продажам. Думая с точки зрения пользователя, будет ли пользователь выполнять денежную транзакцию на сайте, в котором много ошибок? Таким образом, успех любого магазина электронной коммерции зависит от его качества.
+
+Тестировщик должен убедиться, что каждая функция, представленная в списке ниже, тщательно протестирована:
+
+* **Функциональность веб-сайта для разных пользовательских сценариев**: сайты для электронной коммерции могут иметь разные типы пользователей, такие как авторизованные и неавторизованные пользователи, продавцы, курьеры, торговые представители, менеджеры магазинов, аффилированные маркетологи и многие другие, в зависимости от типа бизнеса. Команда тестирования должна обеспечить охват каждого пользовательского сценария и варианта использования их функциональности;
+* **Рабочий процесс приложения** (Application Workflow): приложения электронной коммерции должны иметь четко определенные рабочие процессы, которые должны быть подробно описаны в требованиях. У клиентов должен быть положительный пользовательский опыт, поскольку мы проверили бы рабочий процесс с точки зрения пользователя. Рабочий процесс состоит из входа/регистрации, поиска, сортировки, фильтрации, страницы описания товара, корзины, оформления заказа, платежного шлюза, подтверждения заказа и т. д.;
+* **Совместимость с веб-браузерами**: веб-сайты электронной коммерции должны работать в любом браузере, т. е. магазин должен быть стабильным и совместимым с различными браузерами. Браузеры, такие как Chrome, Firefox, Safari, Edge, Internet Explorer, Opera и т. д., должны работать одинаково, функции и возможности магазина электронной коммерции должны быть одинаковыми во всех браузерах;
+* **Мобильное тестирование** (Mobile Responsiveness): в наши дни веб-сайты электронной коммерции получают больше трафика с мобильных устройств, чем с настольных платформ, поэтому самое время начать тестировать наше приложение на мобильных устройствах с разными разрешениями, чтобы удовлетворить требования клиентов. Мы должны проверить отзывчивость дизайна веб-сайта, а также его удобство использования и функциональность;
+* **Тестирование производительности**: для приложения электронной коммерции тестирование производительности необходимо для достижения идеальной функциональной и технической производительности. Тестирование производительности выявляет ошибки, которые могут быть не обнаружены при других видах тестирования. Тестировщик должен попробовать различные виды тестирования, такие как нагрузочное тестирование, стресс-тестирование, пиковое тестирование, тестирование на выносливость, объемное тестирование и т. д., поскольку все эти тесты будут полезны для оценки пропускной способности веб-сайта, емкости, особенно во время праздников и акций. Тестирование производительности включает тестирование различных параметров, таких как скорость загрузки веб-страницы, устойчивость к нагрузке трафика, пропускная способность, скорость передачи данных, эффективность, производительность базы данных, обработка ошибок, время безотказной работы и многое другое;
+* **Оценка безопасности и уязвимости**: на веб-сайтах электронной коммерции есть конфиденциальная информация о пользователе, такая как имя, возраст, дата рождения, а также адрес, банковские реквизиты и многое другое. Таким образом, тестирование безопасности имеет наивысший приоритет в тестировании электронной коммерции. Для проверки уязвимостей системы используются различные методологии, такие как SQL Injection, SAST, DAST, этический взлом и т. д. Если будут обнаружены баги, связанные с безопасностью приложения, это может привести даже к провалу бизнеса;
+* **Интеграция с социальными сетями**: веб-сайты электронной коммерции для интеграции с социальными сетями невероятно полезны, поскольку социальные сети являются мощным инструментом для привлечения и создания сообщества вокруг бренда. Электронная коммерция использует возможности социальных сетей с помощью параметров социальных сетей, виджетов социальных сетей, обратной связи в социальных сетях, перенаправления рекламы в социальных сетях в магазины электронной коммерции и многого другого. Эти интеграции согласованы с архитектурой веб-сайта и рабочим процессом для наилучшей стратегии;
+* **Аспекты, связанные с SEO**: сайты электронной коммерции должны иметь высокую видимость в поиске, чтобы привлечь трафик на сайт. Тестировщик должен проверить, размещены ли стратегии SEO, такие как теги заголовков, метаописания, структура URL-адресов, альтернативные теги изображений и т. д., таким образом, чтобы клиент мог легко найти веб-сайт.
+
+**Проблемы тестирования электронной коммерции**
+
+* Веб-сайт / приложение электронной коммерции постоянно меняется и развивается во время распродаж, праздников, рекламных предложений, поэтому каждые 3 месяца будет новое изменение пользовательского интерфейса с дополнительными функциями, что может стать препятствием для разработчиков и тестировщиков. Постоянные изменения на сайте делают автоматизацию невозможной;
+* Обычно веб-сайты электронной коммерции интегрируются со сторонними веб-сайтами, эта интеграция затрудняет сквозное тестирование, когда сторонний сайт не работает, может потребоваться некоторое время, чтобы выяснить, связана ли проблема с нашим сайтом;
+* Во время сезонов распродаж, таких как Черная пятница и Киберпонедельник, бизнес всегда недооценивает количество пользователей сайта, это связано с плохим тестированием производительности или людьми, которые не уделяют много внимания тестированию производительности;
+* Предпочтения клиентов время от времени меняются, не все используют веб-сайт в точном соответствии, отследить каждую покупку и сохранить их поведение может быть сложно;
+* Удобство использования веб-сайта очень субъективно, новичку может понадобиться обучающий виджет, чтобы понять, как работает сайт, тогда как опытный покупатель может счесть их ненужными, удобство использования и пользовательский опыт различаются, контекст удобства для пользователя меняется в зависимости от пользователя, поэтому трудно гарантировать эффективность нашего юзабилити-тестирования;
+* Группа тестирования может понимать требования к программному обеспечению и реализуемые функции, но не обязательно понимать бизнес-модель и ее требования;
+* Команда тестирования должна сосредоточиться на изменении тестовых случаев и среды автоматизации, поскольку веб-сайт продолжает развиваться более быстрыми темпами;
+* Тестировщик создает новую среду каждый раз, когда технология развивается;
+* Чтобы проверить все детали, стоимость доставки, налоговые реквизиты и данные кредитной карты должны быть выданы команде тестирования;
+* Взлом и вторжение довольно распространены для новых веб-сайтов, но надлежащие инструменты и средства для этих инструментов не всегда предоставляются бизнесом;
+* Несмотря на то, что сайт электронной коммерции может показаться пользователю простым, он имеет очень сложную интеграцию;
+* Регрессионные наборы должны запускаться как в автоматическом, так и в ручном режиме, чтобы проверить влияние обновлений;
+* Возможность автоматического тестирования очень низкая, поскольку электронная коммерция имеет динамическую среду, но ручное тестирование может занять много времени и есть вероятность человеческой ошибки.
+
+Источники:
+
+* [eCommerce Testing Guide: How To Test An E-commerce Website](https://www.softwaretestingmaterial.com/ecommerce-testing/)
+
+Доп. материал:
+
+* [Кейсы для корзины интернет-магазина](https://testitquickly.com/2011/02/01/ferim-ar-doamne-de-cekauturi/)
+* [Тестируем интернет-магазин](https://www.youtube.com/watch?v=2QKdhZ0Xr04)
+* [Чеклист: 217 пунктов для отличного интернет-магазина](https://vc.ru/marketing/52090-cheklist-217-punktov-dlya-otlichnogo-internet-magazina)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-interneta-veshei-iot-internet-of-things.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-interneta-veshei-iot-internet-of-things.md
new file mode 100644
index 0000000..641616c
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-interneta-veshei-iot-internet-of-things.md
@@ -0,0 +1,84 @@
+# Тестирование интернета вещей (IoT - Internet of Things)
+
+**Интернет вещей** (Internet of Things, IoT) - это множество физических объектов, подключенных к интернету и обменивающихся данными. Концепция IoT может существенно улучшить многие сферы нашей жизни и помочь нам в создании более удобного, умного и безопасного мира. Примеры Интернета вещей варьируются от носимых вещей, таких как умные часы, до умного дома, который умеет, например, контролировать и автоматически менять степень освещения и отопления. Также ярким примером служит так называемая концепция умного предприятия (Smart Factory), которое контролирует промышленное оборудование и ищет проблемные места, а затем перестраивается так, чтобы не допустить поломок. Интернет вещей занимает важное место в процессе цифровой трансформации в компаниях. Прогнозируется, что к 2030 году количество подключенных к сети устройств вырастет примерно до 24 млрд с годовой выручкой до 1,5 трлн долларов.
+
+**Архитектура IoT**
+
+* **Конечные устройства**: это объекты, которые фактически образуют «вещи» (Things) в Интернете вещей. Они играют роль интерфейса между реальным и цифровым мирами и принимают разные размеры, формы и уровни технологической сложности в зависимости от задачи, которую они выполняют в рамках конкретного развертывания IoT. Будь то микрофоны размером с булавочную головку или внушительного размера машины, практически любой материальный объект можно превратить в подключенное устройство путем добавления необходимых элементов (датчиков или приводов вместе с соответствующим программным обеспечением);
+* **Программное обеспечение**: это то, благодаря чему подключенные устройства можно назвать «умными». Программное обеспечение отвечает за связь с облаком, сбор данных, интеграцию устройств и за анализ данных в реальном времени. Также оно предоставляет возможности для визуализации данных и взаимодействия с системой IoT;
+* **Коммуникации**: уровень коммуникации включает в себя как решения для физического подключения (сотовая и спутниковая связь, LAN), так и специальные протоколы, используемые в различных средах IoT (ZigBee, Thread, Z-Wave, MQTT, LwM2M). Выбор подходящего коммуникационного решения - одна из жизненно важных частей при построении каждой IoT-системы. Выбранная технология будет определять не только способы отправки и получения данных из облака, но способы связи со сторонними устройствами;
+* **Платформа**: устройства способны «ощущать», что происходит вокруг и сообщать об этом пользователю через определенный канал связи. IoT-платформа - это место, где все эти данные собираются, анализируются и передаются пользователю в удобной форме. Платформы могут быть установлены локально или в облаке. Выбор платформы зависит от требований конкретного проекта IoT и многих факторов: архитектура и стек технологий, надежность, параметры настройки, используемые протоколы, аппаратная независимость, безопасность, эффективность, стоимость.
+
+**Виды тестирования IoT**
+
+
+
+На примере медицинского устройства:
+
+**Usability**:
+
+* Нам нужно убедиться в удобстве использования каждого из устройств, используемых здесь;
+* Используемое устройство отслеживания медицинского обслуживания должно быть достаточно портативным, чтобы его можно было перемещать в различные сегменты медицинского учреждения;
+* Оборудование должно быть достаточно умным, чтобы рассылать не только уведомления, но и сообщения об ошибках, предупреждения и т. д.;
+* Система должна иметь возможность регистрировать все события, чтобы обеспечить ясность для конечных пользователей. Если это невозможно, система также должна отправить их в базу данных для хранения;
+* Уведомления должны отображаться, а управление отображением должно выполняться должным образом на устройствах;
+* Необходимо тщательно протестировать удобство использования с точки зрения отображения данных, обработки данных, отправки рабочих заданий с устройств.
+
+**Security**:
+
+* IoT ориентирован на данные, когда все подключенные устройства/системы работают на основе доступных данных;
+* Когда дело доходит до потока данных между устройствами, всегда есть шанс, что данные могут быть доступны или прочитаны при передаче;
+* С точки зрения тестирования нам нужно проверить, защищены ли/зашифрованы ли данные при передаче с одного устройства на другое;
+* Везде, где есть пользовательский интерфейс, мы должны убедиться, что он защищен паролем.
+
+**Connectivity**:
+
+* Поскольку это решение для здравоохранения, подключение играет жизненно важную роль;
+* Система должна быть доступна все время и должна иметь беспрепятственную связь с заинтересованными сторонами;
+* Что касается подключения, очень важно проверить две вещи:
+ * Подключение, передача данных, получение рабочих заданий с устройств должны быть бесперебойными, когда соединение установлено и работает;
+ * Другим условием является сценарий отсутствия соединения. Неважно, насколько надежны система и сеть, есть вероятность, что система отключится. Мы, как тестировщики, должны протестировать и офлайн-условия. Когда система недоступна в сети, должно быть предупреждение, которое может подсказать врачам, чтобы они могли начать отслеживать состояние здоровья вручную, независимо от системы, пока она не будет запущена. С другой стороны, в системе должен быть механизм, который мог бы хранить в ней все данные в период автономной работы. Как только система подключается к сети, все эти данные должны распространяться. Потери данных не должно быть ни при каких условиях.
+
+**Performance**:
+
+* Когда мы говорим о системе для области здравоохранения, нам нужно убедиться, что система достаточно масштабируема для всей больницы;
+* Когда проводится тестирование, оно проводится для 2-10 пациентов одновременно, и данные распространяются на 10-20 устройств;
+* Когда вся больница подключена и к системе подключено 180-200 пациентов, распространяемые данные намного больше, чем тестируемые данные;
+* Как тестировщики, мы должны убедиться, что система работает так же, даже если добавленные данные множатся;
+* Мы также должны протестировать утилиту мониторинга, чтобы отображать использование системы, энергопотребление, температуру и т. д.
+
+**Compatibility**:
+
+* Глядя на сложную архитектуру системы IoT, тестирование на совместимость является обязательным.
+* Для тестирования совместимости с IoT необходимо тестирование таких элементов, как несколько версий операционной системы, типы браузеров и соответствующие версии, поколения устройств, режимы связи.
+
+**Pilot Testing**:
+
+* Что касается IoT, пилотное тестирование является обязательным.
+* Только тестирование в лаборатории гарантирует, что продукт/система работает нормально. Но это может иметь неприятные последствия при воздействии условий/шагов/сценариев в реальном времени;
+* Во время пилотного тестирования система подвергается воздействию ограниченного числа пользователей в реальных условиях. Они используют приложение и оставляют отзывы о системе;
+* Эти комментарии пригодятся, чтобы сделать приложение достаточно надежным для производственного развертывания.
+
+**Regulatory Testing**:
+
+* Эта система здравоохранения должна пройти через несколько контрольных точек регулирования / соответствия;
+* Подумайте о сценарии, в котором продукт проходит все этапы тестирования, но не проходит окончательный контрольный список соответствия;
+* Лучше всего получить нормативные требования в начале самого цикла разработки. То же самое должно быть включено в контрольный список тестирования;
+* Делая это, мы также удостоверяемся, что продукт сертифицирован по контрольному списку регулирующих органов.
+
+**Upgrade testing**:
+
+* Интернет вещей представляет собой комбинацию нескольких протоколов, устройств, операционных систем, микропрограмм, оборудования, сетевых уровней и т. д.;
+* Когда выполняется обновление, будь то для системы или для любого из задействованных элементов, как указано выше, должно быть проведено тщательное регрессионное тестирование/должна быть принята стратегия, чтобы преодолеть проблемы, связанные с обновлением.
+
+Источники:
+
+* [Что такое IoT и что о нем следует знать](https://habr.com/ru/company/otus/blog/549550/)
+* [Internet Of Things (IoT) Testing: Challenges, Tools And Testing Approach](https://www.softwaretestinghelp.com/internet-of-things-iot-testing/)
+
+Доп. материал:
+
+* IoT там, где вы не ждали. Разработка и тестирование [часть 1](https://habr.com/ru/company/jugru/blog/501922/), [2](https://habr.com/ru/company/jugru/blog/502898/), [3](https://habr.com/ru/company/jugru/blog/503064/)
+* [IoT Testing Strategy](https://medium.com/globant/iot-testing-strategy-80e3112c46de)
+* [Подборка багов в IoT: теперь вся наша жизнь может быть ошибкой](https://habr.com/ru/company/jugru/blog/649789/)
+* [ИНТЕРНЕТ ВЕЩЕЙ - это про что? / Умные дома, EDGE-технологии и микроконтроллеры/ Кирилл Овчинников](https://www.youtube.com/watch?v=NpYB\_L4Br0Y)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-messendzhera-messenger.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-messendzhera-messenger.md
new file mode 100644
index 0000000..1b28e57
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-messendzhera-messenger.md
@@ -0,0 +1,111 @@
+# Тестирование мессенджера (Messenger)
+
+Как и любой конкретный тип приложения, приложение для обмена сообщениями имеет свою специфику, требования и проблемы при тестировании.
+
+**Installation Testing**
+
+* Приложение можно без проблем установить и удалить;
+* Логин и регистрация работают корректно;
+* Правильные сообщения об ошибках отображаются когда кто-то пытается зарегистрироваться или войти с некорректными данными;
+* Регистрация или вход с неверными данными невозможны;
+* Принимаются ли только действительные номера телефонов, если приложение требует ввода номера телефона при регистрации;
+* Сколько раз пользователь может ввести неправильный код подтверждения, прежде чем его заблокируют, если во время установки отправляется код подтверждения.
+
+**Usability Testing**
+
+* Приложение интуитивно понятным и простым в использовании;
+* Плавная (smooth) навигация;
+* Интерфейс приложения должен соответствовать стандартам цвета, значков и расположению значков для хорошо зарекомендовавших себя функций в мессенджере, чтобы избежать путаницы;
+* Цвета букв и фона, размер букв и шрифт должны позволять пользователям легко читать сообщения;
+* Приложение должно быть доступным для людей с разным зрением, моторикой и возможностями.
+
+**Functional Testing**
+
+* Пользователь может отправлять и получать сообщения;
+* Время доставки сообщения и любая другая ожидаемая информация о сообщении правильно отображаются для пользователя;
+* Приложение правильно определяет статус сообщения, когда сообщение доставлено, прочитано и/или не доставлено;
+* Пользователь должен иметь возможность видеть статус «набор», когда получатель сообщения набирает ответ;
+* Push-уведомления приложения работают правильно;
+* Пользователь может изменять настройки уведомлений (включение и выключение звука уведомлений, выбор типа уведомлений для отображения и т. д.);
+* Приложение правильно реагирует на входящий телефонный звонок или другие прерывания;
+* Приложение позволяет без проблем отправлять изображения, видео- и аудио файлы и документы. Должны поддерживаться различные типы форматов файлов;
+* Ссылки, смайлики и GIF-файлы отображаются и работают корректно;
+* Пользователь может копировать и вставлять сообщения и их части;
+* Пользователь может редактировать и удалять сообщения;
+* История чата правильно отображается;
+* Пользователь может загружать изображение профиля и редактировать информацию профиля;
+* Пользователь может изменить статус в приложении на «Доступен», «Нет на месте», «Не беспокоить» и т. д.;
+* Голосовые и видеозвонки работают корректно;
+* Пользователь может отправлять аудиосообщения;
+* Возможность создания групповых чатов в мессенджере и их корректная работа;
+* Когда пользователь присоединяется к групповому чату или покидает его, соответствующее уведомление об этом должно отображаться для всех участников группового чата;
+* Пользователь может блокировать контакты в мессенджере и заблокированные контакты больше не могут взаимодействовать с пользователем;
+* Контакты телефона синхронизируются с мессенджером.
+
+**Performance Testing**
+
+* Мессенджер работает корректно при разных типах сетевого подключения (2G, 3G, 4G, 5G, WiFi), при переключении между ними, а также при общении между собой пользователей мессенджера с разными типами сетевого подключения;
+* Скорость доставки сообщений должна быть мгновенной;
+* Изображения и видеофайлы, которые пользователи отправляют в приложение, загружаются достаточно быстро и без проблем с качеством;
+* Качество голосовых и видеозвонков, в том числе очень долгих (2+ часа);
+* Нагрузочное тестирование, чтобы оценить, сколько пользователей могут одновременно использовать приложение для обмена сообщениями;
+* Проверьте, сколько пользователей может одновременно быть активным в групповом чате, чтобы он по-прежнему работал без проблем.
+
+**Compatibility Testing**
+
+* Приложение правильно работает на разных типах, моделях и версиях устройств;
+* Мессенджер работает корректно с разными операционными системами;
+* Если есть веб-версия приложения, проверьте его корректную работу в разных браузерах и их версиях.
+
+**Security Testing**
+
+* Содержимое сообщения защищено от перехвата, когда оно хранится на устройстве пользователя, отправляется на устройство получателя и сохраняется на устройстве получателя;
+* Автоматическое уничтожение сообщений через временной интервал;
+* В мессенджерах с приоритетом безопасности отключены опции копирования и пересылки сообщений.
+
+И, конечно же, всякий раз, когда исправляются какие-либо ошибки в приложении для обмена сообщениями, необходимо тщательное **регрессионное тестирование** .
+
+**Другие виды тестирования, которые могут выполняться**:
+
+* Enterprise Software Testing;
+* Web 2.0 testing;
+* Database testing;
+* SaaS Testing;
+* Web Analytics Testing;
+* Content Management testing;
+* SEO testing;
+* Online Advertisement application testing.
+
+**Дополнительные кейсы**:
+
+* Пользователь может отправлять сообщения на местных языках;
+* Корректность работы если пользователь использует несколько устройств с одного аккаунта: чаты, черновики сообщений, смена пароля;
+* Пользователь может совершать видеовызов онлайн-пользователю. Другой пользователь должен видеть приглашение принять или отклонить вызов;
+* Пользователь должен иметь возможность позвонить снова после отмены вызова;
+* Во время разговора видео может быть временно отключено, но звук может воспроизводиться. (И наоборот);
+* Чат/текст доступен вместе с видеовызовом;
+* Если один человек отключается от группового чата, это не должно влиять на остальных;
+* Функция записи видео/звука работает нормально во время видеочата;
+* Если человек не принимает запрос на вызов, журнал вызовов должен быть создан и должен отображаться для вызываемого человека;
+* Функция отключения/включения звука работает нормально;
+* Во время видеовызова между 2 пользователями, другие должны видеть этих пользователей как занятых, если это приложение видеовызова один на один;
+* Корректность работы каунтера новых сообщений на иконке приложения;
+* Непрочитанные сообщения выделены;
+* Пользователь может искать контакты в окне сообщения.
+* Пользователь может отправить запрос сообщения другому пользователю, которого нет в списке контактов;
+* Пользователь может отправить новое сообщение другу, выбранному из списка;
+* Пользователь может делиться URL-адресами с гиперссылками;
+* Сколько слов или символов можно отправить за раз;
+* Пользователь может отправлять смайлики;
+* Пользователь может отправить несколько смайлов одновременно;
+* Если пользователь печатает смайлики буквами, они будут выглядеть как его значок;
+* Если пользователь набрал какое-либо сообщение и перешел на другую вкладку, не отправив его, то сообщение не должно быть удалено;
+* Пользователь может удалить отправленное сообщение;
+* Пользователь может удалить несколько сообщений одновременно;
+* Пользователь не может отправить пустое сообщение;
+* Полоса прокрутки отображается везде, где это необходимо.
+
+Источники:
+
+* [How to Test a Messenger App](https://blog.qatestlab.com/2021/04/14/how-to-test-a-messenger-app/)
+* [How do I test a chat application?](https://www.quora.com/How-do-I-test-a-chat-application)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-migracii-dannykh-etl.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-migracii-dannykh-etl.md
new file mode 100644
index 0000000..28d995f
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-migracii-dannykh-etl.md
@@ -0,0 +1,105 @@
+# Тестирование миграции данных (ETL)
+
+**ETL** (Extract, Transform, Load) - это процесс, объединяющий три этапа: извлечение, преобразование и загрузка данных из одного источника в другой, т.е. процесс перемещения данных из одного места в другое, из одного формата в другой или из одного приложения в другое. Как правило, это результат внедрения новой системы или места хранения данных. Бизнес-драйвером обычно является миграция или консолидация приложений, при которых устаревшие системы заменяются или дополняются новыми приложениями, использующими тот же набор данных.
+
+Миграция часто начинается, когда компании переходят от локальной инфраструктуры и приложений к облачным хранилищам и приложениям для оптимизации или преобразования своего бизнеса.
+
+**ETL-тестирование** - это вид тестирования, выполняемый для гарантии того, что данные, перенесенные из исходной в целевую базу данных, являются точными и соответствуют действующим правилам преобразования.
+
+Пример:
+
+Давайте рассмотрим пример слияния двух компаний - компании A и компании B. После слияния их операции будут объединены, а их клиенты, сотрудники и другие данные будут храниться в единой централизованной базе данных. Предположим, что компания A использует базу данных Oracle для хранения всей информации, а компания B использует MySQL. Теперь для объединения своей информации обе компании могут использовать процесс ETL для переноса данных из своих отдельных баз данных в одну согласованную базу данных. В процессе ETL, поскольку две базы данных различны, данные обеих компаний будут в разном формате, будут использоваться разные соглашения об именах, будут использоваться разные структуры таблиц и так далее. Из-за этих различий компаниям необходимо удостовериться, что перед загрузкой данных в целевую базу данных она была должным образом очищена и может сформировать нужный формат. При тестировании ETL тестировщики должны убедиться, что:
+
+* данные обеих баз данных были преобразованы в формат целевой базы данных;
+* необходимые функции преобразования были выполнены;
+* в процессе не было потеряно никаких данных, и данные являются точными.
+
+**Миграция состоит из 7 этапов:**
+
+* Premigration planning: Оценить перемещаемые данные на предмет стабильности;
+* Project initiation: Определить и проинструктировать ключевых лиц, принимающих решения;
+* Landscape analysis: Создайте надежный процесс управления правилами качества данных и проинформируйте бизнес о целях проекта, включая отключение устаревших систем;
+* Solution design: Определите, какие данные необходимо переместить, а также качество этих данных до и после перемещения.
+* Build & test: Закодируйте логику миграции и протестируйте миграцию с копией рабочей среды.
+* Execute & validate: Продемонстрируйте, что миграция соответствует требованиям и что перемещенные данные пригодны для использования в бизнесе.
+* Decommission & monitor: Выключите и утилизируйте старые системы.
+
+Это может показаться огромным объемом работы, но не все эти шаги необходимы для каждой миграции. Каждая ситуация уникальна, и каждая компания подходит к решению задачи по-своему.
+
+**Как разработать стратегию тестирования переноса данных?**
+
+Учитывая эту сложность, точное тестирование должно начинаться задолго до фактического переноса данных, чтобы обеспечить необходимый уровень осведомленности и ресурсов. Чтобы гарантировать, что проект получит необходимое ему внимание, сосредоточьтесь на самом провокационном элементе миграции - на том факте, что устаревшая система будет отключена. Надежная стратегия тестирования обязательна!
+
+Следовательно, этапы стратегии тестирования теста миграции, которые будут проводиться , могут быть классифицированы как Pre-Migration Testing; Migration Testing; Post Migration Testing.
+
+**Тестирование перед миграцией (Pre-Migration testing)**
+
+Эта фаза тестирования игнорируется или не учитывается в более простых приложениях. Но когда необходимо мигрировать сложные приложения, необходимо выполнить действия перед миграцией. Вот действия, которые предпринимаются на этом этапе:
+
+* Установите четкий объем данных - какие данные должны быть включены, какие данные должны быть исключены, какие данные требуют преобразования/конвертации и т. д.;
+* Выполнение сопоставление данных (data mapping) между устаревшим и новым приложением - для каждого типа данных в устаревшем приложении сравните соответствующий тип в новом приложении, а затем сопоставьте их - Сопоставление более высокого уровня (Higher level mapping);
+* Изучите схему данных нового приложения - имена полей, типы, минимальные и максимальные значения, длину, обязательные поля, проверки на уровне полей и т. д.;
+* Изучите интерфейсы в новом приложении и их подключения. Данные, проходящие через интерфейс, должны быть надежно защищены и настроены;
+* Подготовьте тестовые случаи, тестовые сценарии и используйте их для новых условий в новых приложениях;
+* Выполните набор тестовых случаев с набором пользователей и сохраните результаты, журналы. То же самое необходимо проверить после того, как произошла миграция, чтобы убедиться, что устаревшие данные и функциональность не повреждены;
+* Количество данных и записей должно быть четко записано, его необходимо проверить после миграции, чтобы доказать, что никакие данные не были потеряны.
+
+**Миграционное тестирование (Migration testing)**
+
+В идеале миграция начинается с резервного копирования данных на ленту, чтобы в любой момент можно было восстановить устаревшую систему. Все сценарии и шаги должны быть правильно задокументированы без какой-либо двусмысленности.
+
+Запись фактического времени, затраченного на миграцию с момента начала миграции до успешного восстановления системы, является одним из тестовых случаев, которые необходимо выполнить, и, следовательно, «Время, необходимое для миграции системы», должно быть записано в final test report, который будет предоставлен как часть результатов миграционного тестирования, и эта информация будет полезна во время запуска в прод. Время простоя, записанное в тестовой среде, экстраполируется для расчета приблизительного времени простоя в работающей системе. Именно в устаревшей системе будет выполняться миграция.
+
+Во время этого тестирования все компоненты среды обычно отключаются и удаляются из сети для выполнения действий по миграции. Следовательно, необходимо отметить «Время простоя», необходимое для теста миграции. В идеале оно будет таким же, как и время миграции. Как правило, действия по миграции, определенные в документе «Руководство по миграции» (Migration Guide), включают:
+
+* Фактическая миграция приложения;
+* Брандмауэры, порты, хосты, аппаратные и программные конфигурации - все они изменяются в соответствии с новой системой, на которую переносится старая версия;
+* Утечки данных, проверки безопасности;
+* Проверяется связность между всеми компонентами приложения;
+
+Тестировщикам рекомендуется проверить вышеизложенное в бэкенде системы или путем проведения тестирования белого ящика. После завершения миграции все серверы будут запущены, и будут выполнены базовые тесты, связанные с проверкой успешной миграции, что гарантирует, что все сквозные системы правильно подключены и все компоненты взаимодействуют друг с другом, БД запущен и работает, фронт успешно взаимодействует с бэком. Эти тесты должны быть идентифицированы заранее и записаны в документе «Спецификация тестов миграции» (Migration Test Specification document). Есть вероятность, что программное обеспечение поддерживает несколько разных платформ. В таком случае Миграцию необходимо проверять на каждой из этих платформ отдельно. Проверка сценариев миграции будет частью теста миграции.
+
+Иногда отдельный сценарий миграции также проверяется с помощью «тестирования белого ящика» в автономной среде тестирования. Следовательно, миграционное тестирование будет представлять собой комбинацию тестирования белого и черного ящиков. После завершения этой проверки, связанной с миграцией, и прохождения соответствующих тестов команда может продолжить работу по тестированию после миграции.
+
+**Тестирование после миграции (Post-Migration testing)**
+
+После успешной миграции приложения вступает в действие тестирование после миграции. Здесь сквозное тестирование системы выполняется в тестовой среде. Тестировщики выполняют определенные тестовые наборы, тестовые сценарии, варианты использования с устаревшими данными, а также с новым набором данных. В дополнение к этому, есть определенные элементы, которые необходимо проверить в перенесенных средах:
+
+* Все устаревшие данные перенесены в новое приложение в течение запланированного времени простоя. Чтобы убедиться в этом, сравните количество записей между устаревшим и новым приложением для каждой таблицы и представлений в базе данных;
+* Все изменения схемы (поля и таблицы добавлены или удалены) в соответствии с новой системой обновлены;
+* Данные, перенесенные из устаревшего приложения в новое, должны сохранять свое значение и формат, если только это не указано отдельно. Чтобы убедиться в этом, сравните значения данных между устаревшей и новой базами данных приложения;
+* Перенесенные данные в новом приложении. Охватите здесь максимальное количество возможных причин. Для обеспечения 100% охвата проверки переноса данных используйте инструмент автоматизированного тестирования ;
+* Безопасность базы данных;
+* Целостность данных для всех возможных записей выборки;
+* Ранее поддерживаемые функции в устаревшей системе работают должным образом в новой системе;
+* Поток данных в приложении, который охватывает большинство компонентов;
+* Интерфейс между компонентами должен быть тщательно протестирован, поскольку данные не должны изменяться, теряться и искажаться при прохождении через компоненты. Для проверки этого можно использовать интеграционные тестовые случаи;
+* Избыточность устаревших данных. Никакие устаревшие данные не должны дублироваться во время миграции;
+* Случаи несоответствия данных, такие как изменение типа данных, изменение формата хранения и т. д.;
+* Все проверки на уровне поля в устаревшем приложении также должны выполняться в новом приложении;
+* Любое добавление данных в новое приложение не должно отражаться на устаревшем;
+* Обновление данных устаревшего приложения через новое приложение должно поддерживаться. После обновления в новом приложении оно не должно отражаться на устаревшем;
+* Удаление данных устаревшего приложения в новом приложении должно поддерживаться. После удаления в новом приложении оно также не должно удалять данные в устаревшем;
+* Убедитесь, что изменения, внесенные в устаревшую систему, поддерживают новые функции, предоставляемые как часть новой системы;
+* Убедитесь, что пользователи устаревшей системы могут продолжать использовать как старые, так и новые функциональные возможности, особенно те, которые связаны с изменениями. Выполнение тестовых случаев и результатов тестирования, сохраненных во время тестирования перед миграцией;
+* Создайте новых пользователей в системе и проведите тесты, чтобы убедиться, что функциональность как старого, так и нового приложения поддерживает вновь созданных пользователей и работает нормально;
+* Проведите тесты функциональности на различных выборках данных (разные возрастные группы, пользователи из разных регионов и т.д.);
+* Также необходимо проверить, включены ли «Флаги функций» для новых функций, а их включение/выключение позволяет включать и выключать функции;
+* Тестирование производительности важно для того, чтобы убедиться, что переход на новые системы/программное обеспечение не ухудшил производительность системы;
+* Также требуется проведение нагрузочных и стресс-тестов для обеспечения стабильности системы;
+* Убедитесь, что обновление программного обеспечения не открыло никаких уязвимостей в системе безопасности, и, следовательно, проведите тестирование безопасности, особенно в той области, где в систему были внесены изменения во время миграции;
+* Удобство использования - это еще один аспект, который необходимо проверить, в котором, если макет графического интерфейса пользователя / интерфейсная система изменились или изменилась какая-либо функциональность, какова простота использования, которую конечный пользователь чувствует по сравнению с устаревшей системой;
+
+Поскольку скоуп тестирования после миграции становится очень большим, идеально разделить важные тесты, которые необходимо выполнить в первую очередь, чтобы удостовериться, что миграция прошла успешно, а затем выполнить оставшиеся позже.
+
+Также рекомендуется автоматизировать сквозные функциональные тестовые случаи и другие возможные тестовые случаи, чтобы можно было сократить время тестирования и быстро получить результаты.
+
+Источники:
+
+* [What is Data Migration Testing](https://blog.qatestlab.com/2021/08/11/what-is-data-migration-testing/)
+
+Доп. материал:
+
+* Как QA в управлении хранилища данных эволюционировал: [часть 1](https://habr.com/ru/company/tinkoff/blog/543416/), [часть 2](https://habr.com/ru/company/tinkoff/blog/547990/)
+* [Top 20 ETL Testing Interview Questions & Answers](https://www.softwaretestingmaterial.com/etl-testing-interview-questions/)
+* [ETL Testing or Data Warehouse Testing Tutorial: What is ETL?](https://www.guru99.com/utlimate-guide-etl-datawarehouse-testing.html)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-mikroservisnoi-arkhitektury-msa-microservices.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-mikroservisnoi-arkhitektury-msa-microservices.md
new file mode 100644
index 0000000..c299420
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-mikroservisnoi-arkhitektury-msa-microservices.md
@@ -0,0 +1,115 @@
+# Тестирование микросервисной архитектуры (MSA/Microservices)
+
+Подход к тестированию микросервисной архитектуры отличается от всем привычного. Она представляет собой совокупность мелких сервисов, каждый из которых отвечает за определенный функционал, а вместе они представляют собой готовое приложение и решают определенную глобальную задачу.
+
+Главным преимуществом и одновременно трудностью тестирования является то, что они располагаются на различных серверах и написаны на разных языках программирования, таких как Java и .Net. Фактически разработчики определённого микросервиса не знают, что делают остальные микросервисы, что усложняет процесс тестирования. Но зато мы можем быстро обновить и протестировать отдельный микросервис, не затронув другие.
+
+Само тестирование можно разделить на следующие виды:
+
+* unit тестирование;
+* контрактное тестирование;
+* интеграционное тестирование;
+* end-to-end тестирование;
+* нагрузочное тестирование;
+* UI или функциональное тестирование.
+
+**Unit тестирование**
+
+Идея в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже протестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. Unit тестирование бывает позитивное, то есть направленное на проверку поведения методов в нормальных условиях, и негативное, которое призвано проверить устойчивость системы к нештатным ситуациям.
+
+У нас процессы были построены так, что девелоперы на этапе разработки функционала самостоятельно пишут Unit-тесты. Каждый из них сам лучше знает, как его код работает, и может эффективнее справится с этой задачей, чем тестировщики.
+
+Unit тестами у нас покрыто 70% функционала, и так как мы применяем CI/CD, пока они не пройдены, приложение не задеплоится.
+
+**Контрактное тестирование**
+
+Как я уже упомянул, над микросервисами всегда работает несколько команд: бэкенд, фронтенд и тестировщики. Все они должны между собой договориться: какой эндпоинт работает с какими параметрами, и что будет принимать и возвращать каждый тип данных.
+
+Для этого нужен контракт между командами (в нашем случае мы используем Pact), который будет содержать все методы и возвраты для всех сервисов.
+
+Например, бэкэнд-разработчик написал код, проставил аннотации и сделал swagger-документацию. Но если swagger не провалидируется фронтендом, а QA его уже протестируют - мы просто зря потратим время. Поэтому и создается контракт: например, у сервиса 8 эндпоинтов, и мы знаем, в каком формате он отдаёт и принимает данные.
+
+Контрактное тестирование необходимо для того, чтобы убедится, что все действительно так и работает. По сути, это тестирование черного ящика: как происходят процессы внутри сервиса неважно, если какая-то схема работает не по пакту - это баг.
+
+У нас оно работает следующим образом: с самой ранней стадии есть техническое задание, согласованное со всеми стейкхолдерами. На основе ТЗ проходит оценка задачи и создается схема, согласно которой все будут работать.
+
+Так QA может писать первичные сценарии проверки бэкэнда, который еще даже не существует. Контракт помогает понять, что ожидать. Конечно, на практике не все всегда работает гладко, не по всем микросервисам удалось создать контракт до начала разработки. Фронтенд-разработчиков у нас меньше, чем бэкенд, и им приходится подтягиваться уже после разработки.
+
+**Интеграционное тестирование**
+
+Это один из самых критичных тестов всей архитектуры. При положительном исходе тестирования мы можем быть уверены, что она спроектирована верно, и все независимые микросервисы функционируют как единое целое в соответствии с ожиданиями.
+
+Так как процесс тестирования был внедрен на ранних этапах разработки, каждый отдельный сервис пришлось поднимать локально, а все зависимости других модулей - мокать. В качестве языка была выбрана Java (с момента основания компании этот язык используется для написания тестов).
+
+Что касается сборщика, то все тоже максимально просто: наша текущая архитектура изначально использует Gradle.
+
+Если рассмотреть нашу инфраструктуру автоматизации, то это по большей части кастомный проект, в основе которого Java и Gradle, плюс куча библиотек, таких как Junit5, Feign, Rest Assured и т.д.
+
+Feign и Rest Assured используется вместе потому, что до перехода на микросервисную архитектуру наш проект прекрасно жил на Feign. Как библиотека для покрытия API это было лучшее решение. Но после перехода на новую архитектуру по факту вся платформа была переписана на микросервисы, которые нужно покрыть верхнеуровневыми тестами в короткий срок для возможности дальнейшего проведения интеграционного тестирования. Тут мы и подключили вторую библиотеку Rest Assured, что позволило быстро покрывать огромные куски функционала (для многих данное решение будет спорным, но на тот момент большинство новых QA работало именно с Rest Assured, что и стало решающим фактором при выборе новой библиотеки).
+
+Для развертывания окружения в docker-контейнерах локально или на CI-сервере используется Java-библиотека TestContainers, которая позволяет оркестрировать docker-контейнерами непосредственно из кода тестов (testcontainers.org). При развертывании окружения поднимаются сам тестируемый сервис, а также используемые сервисом базы данных, брокер сообщений и эмулятор, который и мокает все внешние сервисы.
+
+Так как все контейнеры мы поднимаем локально и на ранних этапах разработки, то потребовалось очень много времени на то, чтобы настроить перманентное окружение. Например, у нас есть сервис Settings, которому для работы нужны Сервисы 1 и 2, и какие-то данные с Kafka и MINO. Все это берется из переменных окружения, и за счет огромного количества зависимостей тяжело контролировать процесс поднятия одного сервиса.
+
+Тестирование формально делится на автоматизированное и ручное. Мануальные тестировщики проводят тесты руками, не поднимая среды, и пишут тест-кейсы для автоматизаторов, упрощая им задачу. У нас два мануальщика покрывают пять автоматизаторов - очень удобно.
+
+**End-to-end тестирование**
+
+По сути своей E2E тестирует бизнес-логику, так же, как и в интеграционном, но уже не изолированно, а в масштабе всей системы.
+
+В end-to-end тестировании мы проверяем взаимодействие всех сервисов c платформой:
+
+регистрация, авторизация, игровая деятельность, пополнение и снятие денежных средств, другими словами, проверяем способность всего приложения удовлетворить все запросы конечного пользователя. Точно также, как при интеграционном тестировании - микросервисы поднимаются локально, но данные уже не мокаются. Сервисы общаются друг с другом. По факту на локальной машине поднимается конечный продукт. Сценарий максимально приближенный к запуску.
+
+**Нагрузочное тестирование**
+
+Процесс нагрузочного тестирования будем формально разделять на 4 небольших этапа:
+
+* тестирование производительности (Performance Testing) - исследование времени отклика ПО при выполнении операций на разных нагрузках, в том числе на стрессовых нагрузках;
+* тестирование стабильности или надежности - исследование устойчивости ПО в режиме длительного использования с целью выявления утечек памяти, перезапуска серверов и других аспектов, влияющих на нагрузку;
+* стресс-тестирование - исследование работоспособности ПО в условиях стресса, когда нагрузка превышает максимально допустимые значения, для проверки способности системы к регенерации после стрессового состояния, а также для анализа поведения системы при аварийном изменении аппаратной конфигурации;
+* объемное тестирование (Volume Testing) - исследование производительности ПО для прогнозирования долгосрочного использования системы при увеличении объемов данных, то есть анализ готовности системы к долгосрочному использованию.
+
+Для тестов мы используем JMeter, а сами нагрузочные скрипты написаны на Groovy.
+
+Мы используем около пяти виртуальных машин, развернутых на AWS и у нас есть 7 физических машин. Последние используем, если нужно создать большую нагрузку - 15,000 RPS и больше. Виртуальные машины, так как они, по сути, являются «откусанными» частями одной большой машины, таких цифр показать не могут - каждый реквест нужно отправлять с подписью шифрования, и это сильно нагружает процессор. Так что VM используем для фоновой или статической нагрузки в районе 2000 RPS.
+
+Статистику собираем в Grafana - анализируем все показатели, нагрузку на CPU, GPU, сеть, диски и т.д.
+
+Сначала сравниваем с эталонными показателями, потом экспериментируем, например, нагружаем какое-то время процессор на 30%, делаем короткий скачок до 90%-100%, и смотрим, сколько битых запросов нам нападает.
+
+**UI или функциональное тестирование**
+
+Это завершающий этап тестирования. Если в предыдущих тестах фигурировал только API, теперь тестируется и фронт. Проводим как мануальное тестирование, так и автотесты.
+
+Первостепенная задача - это минимальное функциональное тестирование. Тестируются готовые сборки, которые уже можно показать заказчикам. Пока оно не пройдено, смысла дальше тестировать нет.
+
+Мы используем Java, Cucumber и самописную библиотеку для описания логики сценариев (раньше использовали Akitа сценарии, но поддержка библиотеки закончилась на Java 8, нам пришлось написать свою библиотеку для работы с UI-тестами, но в основе лежат методы именно оттуда). Cucumber используем для удобства написания самих тестов.
+
+Так как проект большой, нам необходимо запускать огромное количество скриптов одновременно, для решения этой проблемы мы используем Selenide, который развернут на одном окружении с Jenkins.
+
+В Jenkins создается pipeline, в котором прописываем, сколько контейнеров необходимо поднять для запуска теста.
+
+Например, нужно протестировать email-шаблоны, которых у нас 100-200. В один поток это займет 15-20 минут. Поэтому создаем pipeline в Jenkins, который этот скрипт разбивает на много маленьких контейнеров, которые поднимаются в Selenide.
+
+Можно сказать, что Selenide - это виртуальный браузер, а Selenium - виртуальный пользователь. Одновременно поднимаются 10 контейнеров, и все тесты проходят за пару минут. Все пайплайны тоже написаны на Groovy.
+
+После этого собираем это все в отчеты в зависимости от проекта: UI в Cucumber reports, а API-тесты - в Azure.
+
+Все скрипты пишутся на основе тест-кейсов и юз-кейсов, которые делают мануальные тестировщики. Перед началом разработки у мануальщиков есть ТЗ, в котором описана бизнес-логика приложения, и макеты от дизайнеров.
+
+Источники:
+
+* [Тестируем микросервисную архитектуру](https://dou.ua/forums/topic/33851/)
+
+Доп. материал:
+
+* [Тестирование микросервисов: разумный подход](https://habr.com/ru/company/oleg-bunin/blog/349632/)
+* [How to test microservices?](https://rishikesh-dhokare.medium.com/testing-microservices-1f4d7a83b8df)
+* [Testing Strategies in a Microservice Architecture](https://martinfowler.com/articles/microservice-testing/)
+* [Лучшие практики тестирования микросервисов](https://habr.com/ru/company/typeable/blog/645991/)
+* [Микросервисы (Microservices)](https://habr.com/ru/post/249183/)
+* [How to Test Microservices](https://www.functionize.com/blog/how-to-test-microservices)
+* [Microservices Testing Strategies, Types & Tools: A Complete Guide](https://www.simform.com/blog/microservice-testing-strategies/)
+* Testing Microservices: an Overview of 12 Useful Techniques - [Part 1](https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/), [Part 2](https://www.infoq.com/articles/twelve-testing-techniques-microservices-tradeoffs/)
+* [Best testing strategies in a Microservice architecture](https://www.cigniti.com/blog/microservices-architecture-testing-strategies/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-oblachnykh-reshenii-cloud-testing.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-oblachnykh-reshenii-cloud-testing.md
new file mode 100644
index 0000000..885f4e1
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-oblachnykh-reshenii-cloud-testing.md
@@ -0,0 +1,82 @@
+# Тестирование облачных решений (Cloud testing)
+
+**Облачные вычисления** - это предоставление по требованию вычислительных услуг, таких как серверы, хранилища данных, базы данных, сети, программное обеспечение и т. д., как правило, через Интернет и с оплатой по мере использования.
+
+Облако построено на одном или нескольких серверах, объединенных между собой системами виртуализации. Также технологии виртуализации позволяют разделить аппаратные мощности на части, которые соответствуют текущим потребностям пользователей, обращающихся к аппаратному обеспечению, как к услуге. В результате пользователь переходит от приобретения, управления и амортизации аппаратных ресурсов к покупке серверного времени, дискового пространства, сетевой пропускной способности, необходимой для выполнения своих задач.
+
+
+
+В облачных вычислениях различают несколько видов сервисов, для удобства в их обозначении используют аббревиатуру «as a service», то есть «как сервис», или «в виде услуги»:
+
+* **SaaS** (Software as a service; программное обеспечение как услуга) - модель предоставления программного обеспечения, при которой поставщик разрабатывает веб-приложение и самостоятельно управляет им, предоставляя пользователям доступ к нему через интернет;
+* **PaaS** (Platform as a service; платформа как услуга) - это предоставление интегрированной платформы для разработки, тестирования, развертывания и поддержки приложений как услуги. В облаке функционирует некоторый набор программ, основных сервисов и библиотек, на основе которых предлагается разрабатывать свои приложения. Помимо этого, под PaaS понимают также и отдельные части сложных систем, например системы базы данных или коммуникаций;
+* **IaaS** (Infrastructure as a service; инфраструктура как услуга) - это предоставление аппаратных ресурсов, как правило, объединенных на основе виртуализации, как услуги. IaaS состоит из трех основных компонентов - аппаратное обеспечение (серверы, системы хранения данных, клиентские системы, сетевое оборудование), операционные системы и системное ПО (средства виртуализации, автоматизации, основные средства управления ресурсами), и связующее ПО для управления аппаратным и программным обеспечением.
+
+
+
+**Тестирование SaaS**
+
+Это процесс тестирования программного обеспечения, в котором программное приложение, созданное в рамках модели «Программное обеспечение как услуга», тестируется на соответствие как функциональным, так и нефункциональным требованиям. Целью тестирования SaaS является обеспечение качества путем тестирования безопасности данных, целостности, производительности, совместимости и масштабируемости программного приложения.
+
+Облачное тестирование фокусируется на основных компонентах, таких как:
+
+* Приложение: охватывает тестирование функций, сквозные бизнес-процессы, безопасность данных, совместимость с браузерами и т. д.;
+* Сеть : включает в себя тестирование различных пропускных способностей сети, протоколов и успешной передачи данных по сетям;
+* Инфраструктура : охватывает тестирование аварийного восстановления, резервное копирование, безопасное соединение и политики хранения. Инфраструктура должна быть проверена на соответствие нормативным требованиям.
+
+Другие типы тестирования в облаке включают:
+
+* Performance;
+* Availability;
+* Compliance;
+* Security;
+* Scalability;
+* Multi-tenancy;
+* Live upgrade testing.
+
+**Примеры тест-кейсов**:
+
+* **Performance Testing**:
+ * Сбой из-за одного действия пользователя в облаке не должен влиять на производительность других пользователей;
+ * Ручное или автоматическое масштабирование не должно вызывать сбоев;
+ * На всех типах устройств производительность приложения должна оставаться одинаковой;
+ * Избыточное резервирование на стороне поставщика не должно снижать производительность приложения.
+* **Security Testing**:
+ * Только авторизованный клиент может получить доступ к данным;
+ * Данные должны быть хорошо зашифрованы;
+ * Данные должны быть полностью удалены, если они не используются клиентом;
+ * Администрация со стороны поставщиков не должна получать доступ к данным клиентов;
+ * Проверьте различные настройки безопасности, такие как брандмауэр, VPN, антивирус и т. д.
+* **Functional testing**:
+ * Допустимый ввод должен давать ожидаемые результаты;
+ * Сервис должен правильно интегрироваться с другими приложениями;
+ * Система должна отображать тип учетной записи клиента при успешном входе в облако;
+ * Когда клиент решил переключиться на другие службы, работающая служба должна автоматически закрыться.
+* **Interoperability & Compatibility Testing**:
+ * Проверка требований совместимости тестируемой системы;
+ * Проверьте совместимость браузера в облачной среде;
+ * Определите Дефект , который может возникнуть при подключении к облаку;
+ * Любые неполные данные в облаке не должны переноситься;
+ * Убедитесь, что приложение работает на другой облачной платформе;
+ * Протестируйте приложение во внутренней среде, а затем разверните его в облачной среде.
+* **Network Testing**:
+ * Тест протокола, отвечающий за подключение к облаку;
+ * Целостность данных при передаче;
+ * Правильность подключения к сети;
+ * Проверьте, не отбрасываются ли пакеты брандмауэром с обеих сторон.
+* **Load and Stress Testing**:
+ * Проверка служб при доступе нескольких пользователей к облачным службам;
+ * Определите дефект, ответственный за сбой оборудования или среды;
+ * Проверьте, не выходит ли система из строя при увеличении удельной нагрузки;
+ * Проверить, как система меняется со временем под определенной нагрузкой.
+
+Источники:
+
+* [Облачные вычисления (обзор)](https://habr.com/ru/post/69038/)
+* [What is Cloud Testing? SaaS Testing Tutorial](https://www.guru99.com/cloud-testing-tutorial-with-saas-testing-primer.html)
+
+Доп. материал:
+
+* [Введение в Облачные Вычисления для Всех от Инженера Microsoft, Ex-Amazon](https://habr.com/ru/post/585064/)
+* [Хаб “Облачные вычисления” на хабре](https://habr.com/ru/hub/cloud\_computing/)
+* [SaaS Testing Guide: What You Should Know](https://www.softwaretestingmaterial.com/saas-testing/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-planirovaniya-resursov-predpriyatiya-erp-enterprise-resource-planning.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-planirovaniya-resursov-predpriyatiya-erp-enterprise-resource-planning.md
new file mode 100644
index 0000000..d1dc348
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-planirovaniya-resursov-predpriyatiya-erp-enterprise-resource-planning.md
@@ -0,0 +1,25 @@
+# Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
+
+Планирование ресурсов предприятия, также известное как ERP, представляет собой комплексное программное обеспечение, которое объединяет различные функции организации в единую систему. Программное обеспечение имеет общую базу данных, содержащую всю информацию, относящуюся к различным функциям или подразделениям организации. Система ERP помогает оптимизировать процессы и доступ к информации в организации в режиме 24×7.
+
+Приложения ERP стали критически важными для бесперебойной работы предприятий. Поскольку они включают множество модулей, функций и процессов, необходимость их проверки становится критической. Предприятия осознают необходимость использования модели SMAC (Social, Mobile, Analytics, and Cloud) для ускорения роста. Однако перестройка основных процессов, управляемых устаревшими приложениями ERP, не менее важна. ERP-приложения помогают предприятиям управлять различными функциями, отделами и процессами, включая генерируемые в них данные. Эти приложения помогают предприятиям работать как единое целое и в процессе получать такие результаты, как повышение производительности, повышение эффективности, сокращение трат, повышение качества обслуживания клиентов и повышение рентабельности инвестиций. Ввиду важности приложений ERP для организаций их следует тестировать и валидировать. Тестирование приложений ERP может обеспечить бесперебойную работу нескольких задач в организациях. Они могут включать в себя отслеживание запасов и транзакций клиентов, управление финансами и человеческими ресурсами и многое другое.
+
+**Подход к тестированию ERP-приложений**
+
+Предприятиям крайне важно разработать надежную стратегию тестирования. Стратегия должна определять приоритеты тестирования процессов в зависимости от краткосрочных и долгосрочных целей.
+
+* Установление KPI (Setting up KPIs): вначале тестировщики должны установить ключевые показатели эффективности или показатели производительности и оценить, как они повлияют на общую цель организации, а также на цели отдела. Таким образом, установление KPI поможет определить правильную рентабельность инвестиций для организации.
+* Всеохватывающий (All-encompassing): внедрение ERP для крупной организации с большим количеством отделов и процессов может оказаться сложной задачей. Однако важно, чтобы все заинтересованные стороны пользовались доверием и участвовали в процессе. Этот процесс также включает в себя необходимые инвестиции в обучение. Когда все вовлечены во внедрение ERP , управление программным обеспечением становится более слаженным;
+* Перенос данных (Data migration): организация может планировать свои стратегические шаги, если она может использовать свои данные, полученные от различных процессов за определенный период времени. Чтобы реальные данные не были потеряны или искажены каким-либо образом во время проверки и тестирования ERP, следует заранее спланировать соответствующий процесс миграции;
+* Выбор правильных инструментов автоматизации: поскольку программное обеспечение ERP может иметь множество переменных, взаимодействующих с различными процессами, их необходимо проверять. Это требует выбора правильных инструментов автоматизации тестирования - с открытым исходным кодом или премиум-класса. Автоматизированное тестирование ERP может проверить большое количество переменных для различных процессов на соответствие ожидаемым результатам. Правильный инструмент автоматизации поможет тестировщикам писать и выполнять тестовые случаи;
+* Идентификация тестовых случаев: поскольку невозможно исчерпывающе протестировать приложения ERP, следует написать соответствующие тестовые примеры, чтобы обеспечить максимальное покрытие тестами. Таким образом, тестировщики должны определить контрольные примеры для каждого теста и также задокументировать их. Кроме того, поскольку процессы ERP связаны друг с другом и даже со сторонними приложениями или модулями, они должны проходить автоматизированное тестирование ERP;
+* Проведение тестов производительности, регрессии и безопасности: поскольку система ERP помогает управлять операциями предприятия как единым целым, она должна выполнять некоторые критические тесты. К ним относятся регрессионные тесты, тесты производительности, интеграции, безопасности и удобства использования. Таким образом, предприятие может обеспечить непрерывный мониторинг системы, сэкономить время и деньги, а также предотвратить любые внезапные простои или задержки;
+* Правильная документация: после тестирования компонентов в системе ERP документированные сбои должны быть проанализированы, чтобы предотвратить любой сбой в реальной среде. Кроме того, отчеты могут быть использованы для дальнейшего использования.
+
+Источники:
+
+* [How To Approach The Testing of ERP Application](https://www.softwaretestingmaterial.com/approach-the-testing-of-erp-applications/)
+
+Доп. материал:
+
+* Тестируем ERP систему. [Часть 1](https://habr.com/ru/post/91996/), [2](https://habr.com/ru/post/92235/), [3](https://habr.com/ru/post/93448/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platezhnogo-shlyuza-payment-gateway.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platezhnogo-shlyuza-payment-gateway.md
new file mode 100644
index 0000000..d6090cc
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platezhnogo-shlyuza-payment-gateway.md
@@ -0,0 +1,87 @@
+# Тестирование платежного шлюза (Payment Gateway)
+
+**Платежный шлюз** - это сервис, который помогает нам совершать денежную транзакцию в Интернете, он принимает кредитные карты, дебетовые карты, интернет-банкинг и другие способы оплаты от клиента для выполнения транзакции. Службы платежных шлюзов шифруют конфиденциальную информацию, такую как номера карт, CVV, пароли, пин-коды и т. д. Они интегрированы с платформами электронной коммерции для совершения и получения платежей. С ростом цифровых платежей на платформах электронной коммерции мы должны предоставлять клиентам безопасные и удобные платежные шлюзы, которые могут выдерживать высокие нагрузки без каких-либо сбоев в работе. Некоторыми из распространенных примеров платежных шлюзов являются Paypal, Paytm, Razor pay, Instamojo и т. д.
+
+**Терминология**:
+
+* Торговец (Merchant): это лицо или компания, которые продают товар или услугу, они могут быть поставщиком услуг, продавцом товара, магазином электронной коммерции и т. д. Они принимают онлайн-платежи для своего бизнеса;
+* Банк-эквайер (Acquiring bank): это банк продавца, когда клиент платит через платежный шлюз, сумма зачисляется в банк-эквайер;
+* Банк-эмитент (Issuing bank): это банк клиента, когда продавец получает платеж, сумма вычитается из банка-эмитента;
+* Транзакция: это платеж, сделанный в кассе платежного шлюза. Он генерирует уникальный идентификатор, который называется идентификатором транзакции;
+* Авторизация: платежный шлюз отправляет запросы авторизации на счет клиента (банк-эмитент) для вычета суммы. Запрос авторизации может быть отклонен или одобрен банком-эмитентом;
+* Аутентификация - это метод, с помощью которого банк проверяет личность клиента, совершающего платеж, это может быть CVV, OTP, PIN-код, пароль и т. д.
+
+**Поток транзакций платежного шлюза**
+
+
+
+* Клиент выбирает товар или услугу и получает страницу оплаты;
+* Он вводит данные своей карты, такие как номер, CVV, срок действия и т. д. Эта информация надежно передается платежному шлюзу;
+* Платежный шлюз шифрует данные карты и выполняет проверку на мошенничество, прежде чем отправить данные в банк-эквайер;
+* Банк-эквайер надежно отправляет информацию в схемы карт, выполняет еще одну проверку на мошенничество и отправляет ее в банк-эмитент;
+* Банк-эмитент проводит еще одну проверку на мошенничество и авторизует транзакцию. Сообщение об одобрении/отклонении отправляется Эквайреру через карточные схемы;
+* Платежный шлюз получает это сообщение о принятии/отклонении, которое передает сообщение продавцу. Если платеж одобрен, Эквайрер получает платеж от банка-эмитента и вносит средства на счет продавца.
+
+**Предварительные условия** (prerequisites) для тестирования платежного шлюза
+
+* Соберите тестовые данные для тестовых дебетовой/кредитной карте;
+* Соберите информацию, связанную с типом платежного шлюза, который мы собираемся протестировать;
+* Определите параметры для тестирования производительности;
+* Соберите информацию о кодах ошибок, которые могут возникнуть в платежном шлюзе, чтобы мы знали, возникла ли ошибка с нашей стороны или она связана с платежным шлюзом;
+* Настройте среду Sandbox для проверки платежных систем без фактической оплаты.
+
+**Виды тестирования платежного шлюза**
+
+* **Functional Testing**: мы проводим функциональное тестирование для новых или непопулярных систем. Это жизненно важно, поскольку гарантирует, что система полностью функциональна и ее функции работают должным образом. Это помогает проверить как приложение, так и шлюз;
+* **Security testing**: гарантирует, что платежный шлюз защищает данные, которые он обрабатывает во время оплаты. Он защищает систему от кибератак, хакеров и других уязвимостей безопасности. Мы должны убедиться, что мы заботимся о конфиденциальной информации, предоставленной клиентом;
+* **Performance testing**: гарантирует, что приложение не выйдет из строя, если большое количество пользователей отправят платеж одновременно. Этот тип тестирования имеет решающее значение, особенно во время больших распродаж или праздничных сезонов;
+* **Integration testing**: обычно платформа электронной коммерции или любое другое приложение, требующее оплаты, нуждается в интегрированном в систему платежном шлюзе. Интеграционное тестирование гарантирует, что платежный шлюз легко интегрируется с веб-сайтом продавца. Здесь мы проверяем размещение заказа, обработку платежей, подтверждение заказа, т.е. полный поток транзакций.
+
+**Примеры тест-кейсов**:
+
+* **Functional**:
+ * Каждый вариант оплаты можно выбрать, в текстовые поля можно печатать;
+ * Сохраненная кредитная/дебетовая карта доступна на странице оплаты;
+ * Можно установить карту по умолчанию;
+ * Клиент получает соответствующее уведомление по электронной почте и текст после успешного/неудачного платежа;
+ * Платежный шлюз перенаправляет обратно в приложение после завершения платежа;
+ * Правильно рассчитываются сумма, налоги, скидки, кредиты магазина и т. д.;
+ * Система меняет формат валюты и языка по запросу пользователя;
+ * Платеж не проходит, если какое-либо обязательное поле пусто;
+ * Поведение системы при отключении интернета во время оплаты;
+ * Поведение системы если сессия заканчивается;
+ * Проверка двойной оплаты;
+ * Проверка различных комбинаций действительных и недействительных данных для номера карты + срока действия + CVV;
+ * Проверка работоспособности при наличии расширений браузера, например, блокировщиков рекламы;
+ * Каждый вариант оплаты направляется в соответствующий поток платежей (payment flow).
+* **Performance**:
+ * Работоспособность платежного шлюза, когда несколько пользователей одновременно пытаются совершить транзакцию;
+ * Быстро ли реагирует процессор;
+ * Соответствует ли время, необходимое для того, чтобы приложение достигло платежного шлюза, требованиям;
+ * Зачислена ли та же сумма клиенту во время возврата, а также проверьте сроки возврата в соответствии с положениями и условиями;
+ * Обновляются ли детали транзакции в базе данных в правильном формате.
+* **UI**:
+ * labels и boxes видны;
+ * Номер карты маскируется астерисками при вводе;
+ * Логотип/название компании платежного шлюза видны;
+ * Все варианты оплаты видны;
+ * Цветовая схема соответствует спецификациям;
+ * Правильные сообщения отображаются при успешном/неудачном платеже;
+ * Разделы промокод, подарочная карта, купон видны;
+ * Все ошибки или опечатки пользователя выделены красным цветом.
+* **Security**:
+ * Реквизиты карты маскируются;
+ * Конфиденциальная информация шифруется;
+ * Приложение защищено от межсайтового скриптинга, спуфинга и т. д.;
+ * Онлайн-транзакция происходит по безопасному каналу, такому как HTTPS;
+ * Проверьте все настройки предотвращения мошенничества/безопасности приложения.
+ * Клиент получает одноразовый код (OTP) при инициировании транзакции со своих банковских реквизитов;
+ * Также проверьте тот же сценарий с несколькими картами, привязанными к разным телефонным номерам в одной учетной записи.
+
+Источники:
+
+* [Payment Gateway Testing Guide: How To Test Payment Gateway Functionality](https://www.softwaretestingmaterial.com/payment-gateway-testing/)
+
+Доп. материал:
+
+* [Payment Gateway A/B Testing Guide - How to effectively test different payment providers and methods](https://securionpay.com/blog/payment-gateway-ab-testing/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platformy-elektronnogo-obucheniya-e-learning-platform.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platformy-elektronnogo-obucheniya-e-learning-platform.md
new file mode 100644
index 0000000..409c011
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-platformy-elektronnogo-obucheniya-e-learning-platform.md
@@ -0,0 +1,63 @@
+# Тестирование платформы электронного обучения (E-learning platform)
+
+Платформа электронного обучения, как и все подобные проекты, создана для конечного пользователя. Это означает, что пользовательский опыт - один из важнейших критериев. Когда речь идет о тренировках и обучении, можно сказать, что ожидания еще более завышены. Баги в компьютерной игре и баги в платном уроке, из-за которых пользователь не получил жизненно важных знаний, имеют разный вес. Проблемы с качеством в платформе электронного обучения приводят к потере доверия среди студентов и влияют на эффективность образовательного процесса. Это значит, что в следующий раз при выборе платформы ваш клиент обратит внимание на конкурентов.
+
+**QA в электронном обучении: почему и когда**
+
+Итак, давайте представим, что вы создали платформу электронного обучения. Сейчас вы находитесь на стадии пререлиза. Конечно, вы очень хотите, чтобы продукт был качественным, чтобы пользователям нравился, был эффективным, любимым и настоятельно рекомендовался.
+
+Как вы планируете это обеспечить?
+
+Вы должны начать с того, что посмотрите на платформу глазами пользователя. Кто тот человек, который будет использовать ваш продукт? На каком устройстве он будет его запускать/в каком браузере/на какой ОС? Насколько удобно будет пользователям ориентироваться? Понятно, как пройти процесс обучения, как найти необходимые материалы, как произвести оплату? Это лишь некоторые из вопросов, которые вы должны задать себе. QA - это всегда сложный процесс, так как нужно проверить множество вещей. Поэтому поставщикам программного обеспечения для электронного обучения иногда очень сложно помнить обо всех элементах. И это нормально! Вот для чего нужен процесс обеспечения качества.
+
+[Наши кейсы тестирования продуктов электронного обучения](https://blog.qatestlab.com/2019/03/11/e-learning-focus-testing/) показывают, что такие продукты обычно включают в себя множество элементов, таких как тексты, видео, изображения, могут предоставлять потоки, викторины и так далее. Необходимы погружения и комплексные проверки каждого из элементов.
+
+Инженер QA гарантирует, что ваш продукт соответствует его спецификации. У него уже есть многочисленные чек-листы требований, а также возможные баги и дефекты. А также, он уже прописал и автоматизировал процессы по их устранению. С помощью специальных инструментов и методов тестирования QA-специалисты могут выявить даже те ошибки, о которых никто не знал. Это убережет вас от изобретения велосипеда и натыкания на ошибки, которые уже были совершены до вас.
+
+Есть 3 типовых этапа подключения тестирования к обучающему продукту:
+
+* Привлечение тестировщиков на начальном этапе разработки проекта. Это поможет предотвратить большинство классических ошибок. В результате вы сэкономите время и трудозатраты на последующее исправление ошибок и сразу же выйдете на рынок, максимально избегая негативных отзывов о качестве. Кроме того, вам будет намного проще создать продукт, который понравится пользователям;
+* Привлечение тестировщиков на одном из этапов работы над платформой или перед ее выпуском. Это выгодно еще и тем, что позволяет избежать негатива, связанного с выпуском не очень качественного продукта. Но, скорее всего, сроки релиза могут сгореть, ведь исправление некоторых критических ошибок, обнаруженных на предрелизном этапе, потребует времени и даже серьезных изменений;
+* Привлечение тестировщиков после релиза платформы, на этапе появления отзывов. Отрицательный отзыв показался бы катастрофой. Но не паникуйте. Во-первых, все или почти все можно исправить и обновить. Во-вторых, вы будете получать баллы лояльности от клиентов, когда баги и неудобства исправлены, и их мнение очень важно для вас.
+
+**Общие виды тестирования:**
+
+* Performance testing;
+* Graphical User Interface Testing;
+* Localization Testing;
+* UX/Usability/Accessibility Testing;
+* Compatibility Testing;
+* Integration Testing;
+* Functional Testing;
+* Security Testing;
+* Regression Testing.
+
+**Специфичные кейсы:**
+
+* Учебное содержание;
+* Аудио, озвучка и музыка;
+* Тесты и оценки;
+* Грамматика и типографика;
+* Навигация по курсу;
+* Технологии;
+* Визуальные элементы - графика и изображения;
+* Интерактивность.
+
+**Какие возможны ошибки и как их избежать?**
+
+* Орфографические и грамматические ошибки. Думаете, ничего серьезного? «Как они могут меня учить, если даже грамматики не знают» - так думает пользователь. Так что проверьте это дважды;
+* Огромные текстовые блоки. Длинные тексты всегда сложны и откровенно скучны. И ваша цель состоит в том, чтобы создать эффективный опыт обучения. Поэтому сделайте его более простым и читабельным;
+* Смешанные шрифты. Это обычное дело, когда берешь материал из разных источников. И выглядит действительно безвкусно;
+* Плохая визуализация. Картинки и фотографии помогают учащимся более эффективно воспринимать информацию. Убедитесь, что они качественные и актуальные;
+* Слишком много дизайна или плохой дизайн. Слишком много изображений на одной странице, разных и не сочетающихся цветов и так далее. Вкус - субъективная характеристика, поэтому постарайтесь узнать мнение других людей;
+* Плохое качество звука/видео. Мультимедийные инструменты необходимы, чтобы сделать учащихся более вовлеченными. И эти элементы также требуют дополнительного контроля качества. Все должно работать и иметь хорошее качество звука и изображения;
+* Неработающие ссылки, неактивные кнопки. Неактивные элементы на странице - это катастрофа для пользователей. Так что щелкайте все, что следует щелкнуть, и проверяйте все ссылки;
+* Отсутствует или неправильная навигация. Все кнопки навигации должны перемещать правильно. Переход от одного курса к другому, от одной категории знаний к другой должен быть интуитивно понятным и правильным, поэтому пройдите все возможные пути, которые пользователи могут пройти на курсе;
+* Непонятная инструкция. Одна из самых раздражающих и напрягающих вещей - это когда ученик не может понять задание с самого начала. Постарайтесь сделать это максимально ясным;
+* Отсутствие контактных форм/FAQ. Студенты будут думать, что их мнение не имеет ценности. Вы должны убедиться, что пользователи могут легко связаться с вами и задать свои вопросы;
+* Плохая производительность. Никто не любит ждать. Ваша платформа должна быть быстрой. Клиент ожидает отзывчивый продукт, поэтому убедитесь, что он работает нормально;
+* Работает не на всех устройствах/браузерах. Ваш продукт должен быть гибким, поэтому будьте готовы протестировать его на всех популярных устройствах. Лучше сначала определить предпочтения вашей аудитории. Кстати, такие сервисы, как Browserstack, позволяют проводить тестирование в разных средах, но если проект нужно запустить на устройстве с сенсорным экраном, то тестировать его нужно на реальном устройстве.
+
+Источники:
+
+* [What you should know about testing your E-learning platform](https://blog.qatestlab.com/2021/05/05/e-learning-software-testing/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-servis-orientirovannoi-arkhitektury-soa-service-oriented-architecture.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-servis-orientirovannoi-arkhitektury-soa-service-oriented-architecture.md
new file mode 100644
index 0000000..371a1cb
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-servis-orientirovannoi-arkhitektury-soa-service-oriented-architecture.md
@@ -0,0 +1,119 @@
+# Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
+
+SOA - это метод интеграции бизнес-приложений и процессов вместе для удовлетворения потребностей бизнеса. В программной инженерии SOA обеспечивает маневренность и гибкость бизнес-процессов. Изменения в процессе или приложении могут быть направлены на конкретный компонент, не затрагивая всю систему. Разработчики программного обеспечения в SOA либо разрабатывают, либо покупают куски программ под названием сервисы.
+
+* Сервисы могут быть функциональными единицами приложения или бизнес-процесса, которые могут повторно использоваться или повторяться любым другим приложением или процессом. Например, платежный шлюз - это сервис, который может повторно использоваться любым сайтом электронной коммерции. Всякий раз, когда необходимо произвести платеж, сайт электронной коммерции вызывает/запрашивает сервис платежного шлюза. После оплаты на шлюзе ответ отправляется на сайт электронной коммерции.
+* Сервисы легко собрать и легко переконфигурировать их компоненты.
+* Сервисы можно сравнить со строительными блоками. Они могут создать любое необходимое приложение. Добавлять и удалять их из приложения или бизнес-процесса очень просто.
+* Сервисы определяются в большей степени бизнес-функцией, которую они выполняют, а не фрагментами кода.
+
+**Веб-сервисы**
+
+Веб-сервисы - это независимые компоненты приложений, доступные через Интернет. Их можно опубликовать, найти и использовать в Интернете. Они могут общаться через Интернет.
+
+
+
+* Поставщик услуг публикует услугу в Интернете;
+* Клиент ищет конкретную веб-службу в реестре веб-служб;
+* Возвращается URL-адрес и WSDL для требуемой веб-службы (при использовании WSDL и URL-адреса связь между поставщиком услуг и запрашивающей стороной осуществляется посредством сообщений SOAP);
+* Когда потребитель вызывает веб-службу, с провайдером устанавливается HTTP-соединение. Сообщение SOAP создается, чтобы указать поставщику для вызова требуемой логики веб-службы;
+* Ответ, полученный от поставщика, представляет собой сообщение SOAP, которое будет встроено в ответ HTTP. Этот HTTP-ответ представляет собой формат данных, понятный потребительскому приложению.
+
+**Тестирование SOA**
+
+
+
+Тестирование SOA должно быть сосредоточено на трех уровнях:
+
+
+
+**Методы тестирования SOA**
+
+**1. Тестирование на основе бизнес-сценариев на основе данных** (Business scenario driven data based testing)
+
+* Следует проанализировать различные бизнес-аспекты, связанные с системой;
+* Сценарии следует разрабатывать на основе интеграции:
+ * Различные веб-сервисы приложения;
+ * Веб-сервисы и приложения;
+* Настройка данных должна выполняться на основе описанных выше сценариев;
+* Настройка данных должна быть выполнена так, чтобы охватить сквозные сценарии.
+
+**2. Заглушки** (Stubs)
+
+* Будут созданы фиктивные интерфейсы для тестирования сервисов;
+* Через эти интерфейсы могут быть предоставлены различные входные данные, а выходные данные могут быть проверены;
+* Когда приложение использует интерфейс к внешней службе, которая не тестируется (сторонняя служба), во время интеграционного тестирования может быть создана заглушка.
+
+**3. Regression testing**
+
+* Регрессионное тестирование приложения следует проводить при наличии нескольких выпусков, чтобы обеспечить стабильность и доступность систем;
+* Будет создан комплексный набор регрессионных тестов, охватывающий службы, которые составляют важную часть приложения;
+* Этот набор тестов можно повторно использовать в нескольких версиях проекта.
+
+**4. Service Level Testing**
+
+Тестирование уровня обслуживания включает тестирование компонента на функциональность, безопасность, производительность и совместимость. Каждая служба должна быть сначала протестирована независимо.
+
+**5. Functional Testing**
+
+* Служба предоставляет правильный ответ на каждый запрос;
+* Правильные ошибки принимаются для запросов с неверными данными, неверными данными и т. д.;
+* Проверяйте каждый запрос и ответ для каждой операции, которую служба должна выполнять во время выполнения;
+* Проверяйте сообщения об ошибках при возникновении ошибки на уровне сервера, клиента или сети;
+* Убедитесь, что полученные ответы имеют правильный формат;
+* Убедитесь, что данные, полученные в ответ, соответствуют запрошенным данным.
+
+**6. Security Testing**
+
+* Веб-служба должна соблюдать отраслевой стандарт, определенный WS-Security;
+* Меры безопасности должны работать безупречно;
+* Шифрование данных и цифровые подписи на документах;
+* Аутентификация и авторизация;
+* Инъекции SQL, вредоносное ПО, XSS, CSRF и другие уязвимости должны быть протестированы на XML;
+* Атаки отказа в обслуживании.
+
+**7. Performance Testing**
+
+* Производительность и функциональность сервиса необходимо тестировать под большой нагрузкой;
+* Производительность сервиса необходимо сравнивать при работе отдельно и в приложении, с которым он связан;
+* Необходимо провести нагрузочное тестирование сервиса:
+ * проверить время отклика;
+ * проверить наличие узких мест;
+ * для проверки использования процессора и памяти;
+ * прогнозировать масштабируемость.
+
+**8. Integration level testing**
+
+* Service level testing обеспечивает правильную работу только сервисов по отдельности, но не гарантирует работу связанных компонентов;
+* Интеграционное тестирование проводится с упором на интерфейсы;
+* Этот этап охватывает все возможные бизнес-сценарии;
+* Нефункциональное тестирование приложения должно быть выполнено еще раз на этом этапе. Безопасность, соответствие требованиям и тестирование производительности обеспечивают доступность и стабильность системы во всех аспектах;
+* Коммуникационные и сетевые протоколы должны быть протестированы для проверки согласованности передачи данных между службами.
+
+**9. End to End testing**
+
+Эта фаза гарантирует, что приложение соответствует бизнес-требованиям как функционально, так и нефункционально.
+
+* Все сервисы работают как положено после интеграции;
+* Обработка исключений;
+* Пользовательский интерфейс приложения;
+* Надлежащий поток данных через все компоненты;
+* Бизнес-процесс.
+
+**Проблемы тестирования SOA**
+
+* Отсутствие интерфейсов для Сервисов;
+* Процесс тестирования охватывает несколько систем, что создает сложные потребности в данных;
+* Приложение представляет собой набор различных компонентов, которые имеют свойство меняться. Потребность в регрессионном тестировании возникает чаще;
+* Из-за многослойной архитектуры трудно изолировать дефекты;
+* Так как служба будет использоваться в разных интерфейсах, трудно предсказать нагрузку, что усложняет планирование тестирования производительности;
+* SOA представляет собой набор разнородных технологий. Для тестирования приложения SOA требуются люди с разным набором навыков, что, в свою очередь, увеличивает затраты на планирование и выполнение;
+* Поскольку приложение представляет собой интеграцию нескольких сервисов, тестирование безопасности имеет свою долю проблем. Проверка аутентификации и авторизации довольно сложна.
+
+Источники:
+
+* [What is SOA Testing? Tutorial with Example](https://www.guru99.com/learn-soa-testing.html)
+
+Доп. материал:
+
+* [Сервис-ориентированная архитектура (SOA)](https://habr.com/ru/company/vk/blog/342526/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-sistem-roznichnoi-torgovli-pos-point-of-sale.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-sistem-roznichnoi-torgovli-pos-point-of-sale.md
new file mode 100644
index 0000000..5bc3c24
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-sistem-roznichnoi-torgovli-pos-point-of-sale.md
@@ -0,0 +1,126 @@
+# Тестирование систем розничной торговли (POS - Point Of Sale)
+
+Современные POS-системы представляют собой комбинацию программных и аппаратных решений, позволяющих проводить платежные операции и облегчающих ежедневные бизнес-процессы. Говоря о POS-ах, обычно имеют в виду кассовые аппараты, терминалы оплаты и другие привычные составляющие торговых магазинов. Однако, архитектура POS не ограничивается только этими элементами.
+
+
+
+Система является более сложной, чем вы думаете, и тесно интегрирована с другими программными системами, такими как Склад, Инвентарь, Заказ на поставку, Цепочка поставок, Маркетинг, Планирование товаров и т. д. Знание предметной области POS важно для тестирования.
+
+
+
+Сначала покупатель проводит картой по считывателю терминала для оплаты своих покупок. Данные кредитной карты поступают в терминал, откуда отправляются в POS-систему. Далее, POS-система связывается с PSP (Payment Service Provider), который, в зависимости от типа кредитной карты, обращается в банк для прохождения процедуры авторизации транзакции. Как раз в этот момент покупателю предлагается ввести PIN-код для подтверждения транзакции. Если все прошло успешно, код авторизации возвращается из банковской сети в PSP и передается в POS-систему и терминал. Все вышеописанные коммуникации происходят в течении пары секунд.
+
+**Бизнес-процессы**
+
+Рассмотрим, например, классический сетевой магазин. В магазине есть менеджер, скорее всего, их несколько. Каждое утро менеджеру необходимо открывать магазин, а затем и POS-терминалы. Хочется заметить, что POS-терминалы - это не то же самое, что и платежные терминалы.
+
+Во время запуска POS-терминалы синхронизируют время и получают обновленные параметры с сервера магазина, включая цены на товары, информацию об их наличии и другие служебные данные. После этого кассиры могут залогиниться за своими рабочими местами и начать работу. Очевидно, что каждое действие на кассе логируется.
+
+В конце дня менеджеру необходимо повторить процедуру в обратном порядке: сначала закрыть кассы, а после - магазин. После этого действия ни одна транзакция не может быть проведена до открытия магазина. Во время закрытия POS-терминалы отправляют свои логи на сервер. Это и есть те бизнес-процессы, о которых упоминалось выше. Именно их POS-системы позволяют упростить и облегчить.
+
+На рынке POS-систем решений довольно много, и подразделяются они на группы продуктов для малых, средних и крупных организаций.
+
+**Test Architecture for POS Application**:
+
+* **POS-терминал** (POS terminal):
+ * Device and hardware testing (RFID, Scanner, Printer, Barcode reader);
+ * Interoperability Testing;
+ * BI and Analytics Testing;
+ * Performance Testing.
+* **Сервер магазина** (store server):
+ * Security Testing;
+ * BI & Analytics Testing;
+ * Disaster Recovery Testing;
+ * Interface Testing.
+* **Корпоративный сервер** (enterprise server):
+ * Security Testing;
+ * BI & Analytics Testing;
+ * Disaster Recovery Testing;
+ * Interface Testing.
+
+**Types of Testing for POS system**:
+
+* **Application Level**:
+ * Functionality Testing;
+ * Compatibility Testing;
+ * Payment Gateway Testing;
+ * Report Testing.
+* **Enterprise Level**:
+ * Compliance Testing;
+ * Performance Testing;
+ * Interoperability Testing;
+ * Data Migration;
+ * Mobility.
+
+**Примеры тест-кейсов**:
+
+* **Деятельность кассира**:
+ * Правильность записи товаров, приобретенных покупателем;
+ * Тестовые скидки применяются корректно;
+ * Платежные карты магазина (value cards) могут быть использованы;
+ * Управление мелкой денежной наличностью работает правильно;
+ * Соответствие итогов и закрытий (totals and closings);
+ * Денежный ящик кассы работает правильно;
+ * Система POS совместима с периферийными устройствами, такими как считыватель RFID, сканер штрих-кода и т. д.
+* **Процессинг платежного шлюза** (Payment Gateway Processing):
+ * Проверьте действительность номера CVV кредитной карты;
+ * Тестовое считывание карт с обеих сторон и чипов;
+ * Данные карты правильно зашифрованы и расшифрованы.
+* **Продажи**:
+ * Проверьте обычный процесс продажи;
+ * Продажи могут быть обработаны дебетовой / кредитной картой
+ * Покупка по карте лояльности;
+ * Проверьте правильность отображения цен на купленный товар;
+ * Тест на «0» или нулевую транзакцию;
+ * Привязка UPC или штрих-кодов с поставщиками;
+ * Проверка платежных данных или данных о доставке в диспетчере платежей;
+ * Тест для reference транзакции;
+ * Проверьте формат печати сгенерированного чека№
+ * Убедитесь, что правильный код генерируется для одобренных, приостановленных или отклоненных транзакций.
+* **Возврат и обмен**:
+ * Внутренние запасы хорошо интегрированы с другими торговыми точками или цепочкой поставок;
+ * Чек на обмен или возврат товара наличными
+ * Проверьте, реагирует ли система на обмен или возврат товара с помощью кредитной карты.
+ * Проверка системы обработки продажи с чеком или без чека;
+ * Система позволяет вводить штрих-код вручную, если сканер не работает;
+ * Система отображает как текущую сумму, так и сумму скидки при обмене товара, если это применимо;
+* **Производительность**:
+ * Проверьте скорость или время, необходимое для получения ответа или отправки запроса;
+ * Проверьте, применимы ли правила, основанные на транзакциях (скидки/налоги/уступки и т. д.);
+ * Убедитесь, что правильный код генерируется для одобренных, приостановленных или отклоненных транзакций.
+* **Негативные сценарии**:
+ * Тест с просроченной картой;
+ * Тест с неверным PIN-кодом;
+ * Проверьте инвентарь/склад/перечень (?inventory), введя неправильный код товара;
+ * Проверьте, как реагирует система при вводе неправильного номера счета;
+ * Тест на отрицательную транзакцию;
+ * Проверьте реакцию системы при вводе неверной даты для рекламных предложений в Интернете.
+* **Управление акциями и скидками**:
+ * Тест для различных скидок;
+ * Тест для различных рекламных предложений по определенным позициям;
+ * Тест системы оповещения, которая уведомляет об окончании или начале сезонных предложений;
+ * В чеке указаны скидки;
+ * Тест для размещения неправильных предложений или товаров со скидками в Интернете;
+ * Тест процесса управления заказами;
+ * Проверка точности данных о товаре, полученных после сканирования штрих-кода.
+* **Отслеживание данных клиента**:
+ * Тест на реакцию системы при неправильном вводе данных клиента;
+ * Тест для разрешения санкционированного доступа к конфиденциальным данным клиента;
+ * Протестируйте базу данных для записи истории покупок клиентов (что они покупают, как часто они покупают и т. д.)..
+* **Безопасность и соответствие нормативным требованиям**:
+ * Проверка POS-системы на соответствие нормативным требованиям;
+ * Тест системы оповещения, которая уведомляет защитников безопасности;
+ * Убедитесь, что вы можете аннулировать платеж;
+ * Протестируйте профили пользователей и уровни доступа в программном обеспечении POS№
+ * Проверка согласованности базы данных№
+ * Проверьте конкретную информацию о каждой наличности/платежном средстве/заявке (?tender), идентификатор купона, номер чека и т. д.
+* **Отчетность**:
+ * Trend analysis report;
+ * Тест информации, связанная с транзакцией по кредитной карте, должна отражаться в отчетах;
+ * Проверка индивидуальных и сводных отчетов по истории покупок клиентов;
+ * Тест для создания онлайн-отчетов.
+
+Источники:
+
+* [POS, безопасность и вот это вот все. Разбираем уязвимости популярной Retail-системы](https://habr.com/ru/company/dsec/blog/347432/)
+* [Testing Retail Point Of Sale(POS) Systems: Example Test Cases](https://www.guru99.com/testing-for-retail-pos-point-of-sale-system.html)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-strakhovogo-po-insurance.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-strakhovogo-po-insurance.md
new file mode 100644
index 0000000..d8b1d41
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-strakhovogo-po-insurance.md
@@ -0,0 +1,155 @@
+# Тестирование страхового ПО (Insurance)
+
+Страховые компании в значительной степени полагаются на программное обеспечение для ведения своего бизнеса. Программные системы помогают им заниматься различными видами страховой деятельности, такими как разработка стандартных форм полисов, обработка процесса выставления счетов, управление данными клиентов, предоставление качественных услуг клиенту, координация между филиалами и так далее.
+
+В страховой компании есть много ветвей , которые требуют тестирования:
+
+* Системы администрирования полисов (Policy Administration Systems);
+* Системы управления страховыми требованиями (Claim Management Systems);
+* Системы управления распределением (Distribution Management Systems);
+* Системы управления инвестициями (Investment Management Systems);
+* Сторонние системы администрирования (Third party Administration Systems);
+* Решения по управлению рисками (Risk Management Solutions);
+* Регулирование и соответствие (Regulatory and Compliance);
+* Актуарные системы (Оценка и ценообразование) (Actuarial Systems (Valuation & Pricing)).
+
+**Что тестировать в страховании?**
+
+Сектор страхования представляет собой сеть небольших подразделений, которые прямо или косвенно занимаются обработкой страховых требований. Для бесперебойного функционирования страховой компании необходимо, чтобы каждое из этих подразделений было тщательно проверено для достижения желаемого результата.
+
+Тестирование включает в себя:
+
+* Колл-центр (**Call Center**):
+ * Интеграционное тестирование IVR (IVR Integration testing);
+ * Маршрутизация и назначение вызовов (Call routing and assignment);
+ * Безопасность и доступ (Security and access);
+ * Рефлексивные вопросы (Reflexive Questions).
+* Политика обслуживания (**Policy Serving**):
+ * Тестирование жизненного цикла политики (Policy life cycle testing);
+ * Изменения в финансовой и нефинансовой политике (Financial and Non-financial policy changes);
+ * Прекращение действия политики и восстановление (Policy lapse and Re-instatement);
+ * Оповещения о страховых выплатах (Premium due alerts);
+ * Оценка NPV/NAV (Valuation of NPV/NAV).
+* Претензии (**Claims**):
+ * Сортировка и уступка требований (Claims triage and assignment);
+ * Тестирование жизненного цикла претензий (Testing claims life cycle);
+ * Учет требований / резервирование (Claims accounting/reserving);
+ * EDI / обмен сообщениями от третьих лиц (Third party EDI/messaging).
+* Прямые переходы (**Direct channel**):
+ * Мобильный доступ (Mobile access);
+ * Кросс-браузерность / кроссплатформенность (Cross browser/cross platform accessibility);
+ * Производительность приложения (Application performance);
+ * Удобство использования приложения (Usability of application).
+* Отчеты / BI (**Reports/BI**):
+ * Соблюдение нормативных требований (Behaving to regulatory requirements);
+ * Генерация качественных данных для отчетности (Generate quality data for reporting);
+ * Создание массовых данных для сводных отчетов (Create bulk data for roll-up reports);
+ * Тестирование полей на основе формул в отчетах (Testing formula based fields in reports).
+* Андеррайтинг (**Underwriting**):
+ * Качество андеррайтинга (Underwriting quality);
+ * Ручная и прямая обработка (Manual and Straight through processing);
+ * Сложные бизнес-правила (Complex business rules);
+ * Рейтинг эффективности (Rating efficiency);
+ * Управление требованиями (Vendor Interfacing) (Requirements Management)
+* Интеграция (**Integration**):
+ * Интеграция данных (Data integration);
+ * Комплексная интеграция интерфейса (Complex interface integration);
+ * Форматы источника / назначения (Source/Destination formats);
+ * Производственный интерфейс (Production like interface);
+ * Эффективность пулла/пуша веб-сервиса (Web service pull/push efficiency).
+* Новый бизнес (**New Business**):
+ * Проверить комбинации коэффициентов (Validate rates-factor combinations);
+ * Расписания и запуски заданий (Batch job schedules and runs);
+ * Ввод в эксплуатацию расчетов урегулирований (Commissioning calculations settlements);
+ * Быстрое и подробное назначение цен (Quick and detailed quote);
+ * Иллюстрация преимущества (Benefit illustration);
+ * Валидация суммарной выгоды (Benefit summary validation).
+
+**Особенности тестирования страховых приложений**
+
+**Удобство использования**. В 2020 году деятельность большего числа предприятий и организаций была ограничена, а некоторых даже приостановлена. Эти изменения не обошли стороной и страховой бизнес. Однако сохранить и даже увеличить свою долю на рынке смогли только те компании, продукты которых имели наиболее понятный и приветливый интерфейс.
+
+По итогам 2020 года в десятке лидеров страховых компаний по объему продаж произошли весомые изменения: некоторые компании, занимавшие далеко не первые места, смогли вырваться в ТОП-10. А какие-то наоборот: заняли более низкие позиции в рейтинге, по сравнению с 2019 годом. Данный факт обусловлен резким уходом продаж в онлайн. Немаловажным фактором здесь стало удобство приобретения продукта, не выходя из дома.
+
+К примеру, у “ВТБ Страхование” выручка снизилась примерно в десять раз по сравнению с 2019 годом. Это послужило уходом компании из первой десятки рейтинга. Компания “Сбербанк страхование” также потеряла почти треть выручки относительно 2019 года, и в итоге со второго места в рейтинге опустилась на пятое.
+
+Но есть и примеры компаний, которым повезло больше. Например, “СОГАЗу” в 2020 году удалось увеличить выручку почти в 1,5 раза, что позволило ей сохранить первое место. Общий объем страховых премий компании составил 287 млрд рублей, а темпы прироста оказались одними из самых высоких на рынке (+47,8%, четвертое место в ТОП-10). Благодаря таким показателям, “СОГАЗ” занимает первое место с большим отрывом от других страховых компаний.
+
+На втором месте - компания “АльфаСтрахование”. Их премии составили 115 млрд рублей. Кстати, в 2019 году “АльфаСтрахование” занимала третье место. Третьей компанией по объему собранных премий стала “РЕСО-Гарантия” (была на пятом месте в 2019). Ее результат составил 108 млрд рублей.
+
+**Интеграция с другими сервисами**. Это особенно актуально для таких продуктов, как электронное страхование КАСКО и ОСАГО, так как иногда у сторонних сервисов бывают технические проблемы и сбои. Не исключено также возникновение каких-либо изменений, на которые нужно оперативно отреагировать: например, доработать продукт, протестировать его, выпустить новый релиз и т.п.
+
+Также в случае сбоев на стороне других сервисов необходимо обязательно информировать об этом клиентов. К сожалению, сбои происходят довольно часто, а восстановление данных сервисов не зависит напрямую от страховой компании.
+
+О проблемах интеграций неоднократно говорили и сами страховые компании. В 2020 году о технических проблемах с системой АИС ОСАГО 2.0, в том числе с запросами КБМ, говорили в пресс-службе «Ренессанс страхование». В компания «Тинькофф Страхование» было замечено снижение продаж полисов примерно на 20%, отмечая, что сервис КБМ часто бывает недоступен со стороны РСА.
+
+**Устойчивая работа сервера**. По умолчанию необходимо мониторить нагрузку на сервер, а также то, как он справляется с данной загрузкой, не допускать утечки памяти и т.д. Для компаний, которые реализуют электронные полисы ОСАГО, данный вопрос особенно актуален. Это связано с предусмотренной ответственностью за ограничения в работоспособности сайта, согласно которой суммарная длительность перерыва в работе сайта страховщика не должна превышать 30 минут в сутки. Если же требуется провести плановые технические работы, то страховая компания обязана проводить их в определенные часы, а именно с 22:00 до 8:00 по московскому времени. Также необходимо не менее, чем за сутки до начала работ разместить уведомление на основной странице сайта с указанием даты и времени окончания технических работ.
+
+Исходя из вышесказанного, можно сделать вывод, что стабильность работы сайта/приложения имеет высокий приоритет. Соответственно, помимо мониторинга состояния сервера, желательно проводить и нагрузочное тестирование. Это необходимо для того, чтобы оценить возможности сервера.
+
+Также хотелось бы отметь, что при использовании сложных select-запросов в БД рекомендуется использовать хинт “WITH (nolock)” для избежании блокировки БД.
+
+**Скорость работы при медленном интернете**. Разумеется, каждый пользователь хочет совершить покупку легко, быстро и не задумываясь над каждым шагом. Этот пункт выделен отдельно, так как он относится и к удобству использования, и к работе сервера. А также нужно понимать, что у пользователей не всегда бывает устойчивое и качественное интернет-соединение, поэтому большое количество запросов на сервер могут заметно снизить скорость работы сайта или приложения, вынудив пользователя покинуть страницу или приложение соответственно. Следовательно, нужно уделить особое внимание скорости получения конечной стоимости полиса, так как при медленном соединении и неоптимизированных запросах сервера пользователь может столкнуться с ошибкой сервера: 504 “Gateway Timeout”.
+
+Оптимальная скорость загрузки веб-страницы - 2 секунды. В соответствии со статистикой, если скорость загрузки увеличивается хотя бы на 200 мс, количество посещений сайта снижается на треть в последующие полтора месяца. При увеличении до 400 мс посещаемость снижается более, чем на половину.
+
+**Персональные данные**. Разумеется, для покупки любого страхового продукта необходимо указывать персональные данные. Необходимо получить не только согласие на обработку персональных данных, но и обеспечить их сохранность. Тестирование уязвимостей играет здесь важную роль.
+
+Пропущенные баги, связанные с согласием на обработку персональных данных, могут обойтись очень дорого. Если информация о персональных данных будет обрабатываться без согласия пользователя, то штраф может составить до 18 млн руб. (ч. 9 ст. 13.11 КоАП РФ).
+
+**Ценообразование**. Наверное, самое интересное и сложное, с чем могут столкнуться аналитики и тестировщики на проекте страхования - это тарификатор. Важно обращать внимание на следующие факторы:
+
+* правильность требований к формулам, значениям коэффициентов;
+* правильность использования формул, значений и коэффициентов;
+* правильное использование версий формул, значений и коэффициентов;
+* соблюдение законодательного регулирования по имеющимся значениям;
+* правильность округления. Это стоит учитывать и в самих формулах, и при загрузке/вводе в БД. Нужно понимать, что даже незначительное округление может сильно повлиять на стоимость страхового продукта.
+
+**Печатные формы**.
+
+На практике есть случаи, когда люди, купившие электронные полисы КАСКО или ОСАГО, не получили их на почту и обращались в техподдержку страховых компаний.
+
+На что стоит обратить внимание, тестируя печатные формы:
+
+* Печатные формы должны скачиваться и приходить на почту без ошибок и задержек по времени, с правильными названиями и в полном объеме: полисы, памятки, чеки и т.д.
+* Шаблон печатной формы должен соответствовать законодательству.
+* Информация в печатных формах должна соответствовать тем данным, которые указывал и видел пользователь на сайте или в приложении.
+* Текст должен размещаться в установленных границах.
+* Если использовалось шифрование документов, то этот момент обязательно проверяется.
+
+Пролонгация и внесение изменений. Отдельно хотелось бы отметить пункт про продление страховых полисов, а также внесение изменений в них. Во-первых, у юзера могут меняться значения коэффициентов, например, в зависимости от возраста и стажа или попадания в ЧС. Соответственно, стоимость полиса может заметно измениться, и не всегда в пользу пользователя. Во-вторых, не всегда интеграционные сервисы позволяют продлить полис или внести изменения в него.
+
+Ну и, в целом, у многих страховых компаний на данных момент эта функциональность является “ахиллесовой пятой”. А ведь правильная интеграция с другими сервисами, например, РСА, и как следствие, безошибочное продление полисов КАСКО и ОСАГО, позволяет удержать прежних клиентов, а, значит, укрепить позиции на рынке.
+
+**Примеры тест-кейсов**:
+
+* Проверить правила страховых требований;
+* Претензия может относиться к максимальному и минимальному платежу;
+* Данные точно передаются во все подсистемы, включая учетные записи и отчетность;
+* Претензии могут быть обработаны по всем каналам, например через Интернет, мобильные телефоны, звонки и т. д.;
+* Тест на 100% охват и точность расчетов, определяющих ставки страховых взносов;
+* Формула для расчета дивидендов и выплаченных сумм дает правильное значение;
+* Стоимость выкупа рассчитывается в соответствии с требованиями полиса;
+* Проверка фидуциарных реквизитов и требований бухгалтерского учета;
+* Протестируйте сложные сценарии на предмет прекращения и возобновления полиса;
+* Проверка различных условий значений суммы сохранности страхования;
+* Тестовые сценарии прекращения действия полиса;
+* Учетная запись главной книги ведет себя так же, как и при согласовании с вспомогательной книгой;
+* Тестовый расчет чистых обязательств для оценки;
+* Тестирование условий для продления срока страхования;
+* Проверка полиса для варианта суммы сохранности страхования;
+* Различные условия страхования ведут себя как ожидается;
+* Размер премии соответствует плану продукта;
+* Протестируйте автоматическую систему обмена сообщениями, чтобы информировать клиентов о новых продуктах;
+* Проверяйте все данные, введенные пользователями по мере прохождения рабочего процесса, чтобы инициировать предупреждения, соответствие требованиям, уведомления и другие события рабочего процесса;
+* Убедитесь, что шаблон страхового документа поддерживает формат документа MS-Word;
+* Тестовая система для автоматического создания счета и отправки его клиенту по электронной почте.
+
+Источники:
+
+* [Особенности тестирования программных продуктов для страховых компаний](https://quality-lab.ru/blog/%D0%BE%D1%81%D0%BE%D0%B1%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D1%8B/)
+* [Testing Insurance Domain Applications with Sample Test Cases](https://www.guru99.com/testing-insurance-applications-with-sample-testcases.html)
+
+Доп. материал:
+
+* [Тестирование системы расчета КАСКО](https://quality-lab.ru/blog/casco-insurance-testing/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-v-sfere-telekommunikacii-telecom.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-v-sfere-telekommunikacii-telecom.md
new file mode 100644
index 0000000..6b62db7
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-v-sfere-telekommunikacii-telecom.md
@@ -0,0 +1,89 @@
+# Тестирование в сфере телекоммуникаций (Telecom)
+
+Любое решение по информационно-телекоммуникационным технологиям перед развертыванием в «продуктивной среде» требует практического тестирования, даже если оно кажется соответствующим нормам стандартов, работоспособным и надёжным. Именно поэтому во всем мире существуют тестовые и испытательные лаборатории, в которых делаются тесты различных параметров инновационных ИТ- и телеком-решений, а также сравнительные тесты решений различных разработчиков и вендоров.
+
+**Важность тестирования телеком-решений** обусловлена следующим:
+
+* Возможности разночтений положений стандартов различными вендорами. Например, в одном из испытаний оборудования связи следующего поколения (NGN) в Технопарке ЦНИИС была выявлена несовместимость оборудования двух всемирно известных вендоров. Причина оказалась очень проста: в Стандартах Международного Союза Электросвязи МСЭ был указан диапазон IP-портов, через которые могут пересылаться управляющие сигналы (скажем, десять портов от XYZ1 до XYZ0). В процессе тестирования выяснилось, что один вендор считал, что порт XYZ0 входит в диапазон разрешенных портов, и использовал именно его. А другой вендор считал, что разрешен диапазон только от XYZ1 до XYZ9, а XYZ0 - уже нет. Это вызвало несовместимость решений и необходимость доработки решения одним из вендоров.
+* Необходимость тестирования всех возможных ситуаций практического применения решения (use case). Например, в одном из проектов регионального российского оператора при внедрении одного из решений контроля для пакетных сетей NGN от известного вендора, при приемо-сдаточных испытаниях было выявлена неработоспособность решения в традиционной сети с коммутацией каналов (у оператора пакетная сеть была внедрена лишь частично). То есть решение было разработано исключительно для сетей с коммутацией пакетов. Это вызвало необходимость срочной доработки «готового» решения и сдвиг сроков внедрения.
+* Необходимость сравнительного тестирования параметров решений различных вендоров. При применении на «живой сети», нередки ситуации, когда заводские тесты показывали отличные результаты, превосходящие решения других вендоров, а при практическом применении выяснялось, что заявленные параметры не соответствуют показанным в практической реализации, и решение другого вендора оказывалось эффективнее.
+* Необходимость импортозамещения в критичных областях и необходимость тестирования вновь разрабатываемых, в связи с этим, отечественных решений, что ещё больше поднимет важность тестирования.
+* Цифровая трансформация отрасли, а также переход на виртуализированные сетевые решения и развитие IoT/M2M ещё больше поднимает важность тестирования.
+
+**Бизнес-процессы в телекоммуникационной отрасли**
+
+Для тестирования телекоммуникаций важна сквозная проверка услуг. Для обеспечения эффективного тестирования необходимо хорошее понимание различных бизнес-процессов. Прежде чем составлять тестовые сценарии, вам необходимо понять каждую стадию предоставления услуг. Телекоммуникационные услуги основаны либо на системе поддержки бизнеса (business support), включающей IVR, колл-центры, выставление счетов и т. д., либо на системе операционной поддержки (operation support), включающей маршрутизаторы, коммутаторы, вышки сотовой связи и т. д.:
+
+* Предпродажа (**Pre-sales**): обрабатывает всю информацию о продажах, такую как скидки, услуги, акции и т. д.;
+* Заказ (**Ordering**): подача заявки на новое подключение или отключение;
+* Обеспечение (**Provisioning**): занимается физическим соединением между клиентами и TSP (поставщиком услуг связи);
+* Биллинг (**Billing**): выполняется вся работа по выставлению счетов;
+* Сервисное обслуживание (**Service Assurance**): в случае каких-либо сбоев этот отдел исправляет проблему;
+* Системы инвентаризации (**Inventory Systems**): это хранилище всей информации;
+* Отслеживание (**Tracking**): это подразделение отслеживает систему заказов и статус заказа.
+
+**Типы протоколов, используемых в телекоммуникационной отрасли**
+
+* VoIP technologies: VoIP, IMS, MPLS, ISDN, PSTN;
+* Signaling and Protocols: SIP, ISDN, Codecs, H.323;
+* Wireless technologies: GPRS, CDMA, GSM, UMTS;
+* Network Management: SNMP;
+* Layer 2 Protocols: ARP, STP, L2TP, PPP;
+* Layer 3 protocols/routing: ICMP, BGP, ISIS, MPLS;
+* Infrastructure/Security: ATM, TCP/IP, LAN/VLAN, SSH.
+
+**Виды тестирования, используемых в телекоммуникационной отрасли**
+
+* Interconnection Testing;
+* Conformance Testing;
+* IVR Testing;
+* Performance Testing;
+* Security Testing;
+* Interoperability Testing;
+* Protocol Testing;
+* Functional Testing;
+* Automation Testing.
+
+**Примеры тест-кейсов**:
+
+* **Биллинговая система** (Billing System):
+ * Номер телефона клиента зарегистрирован на оператора связи;
+ * Номер работает;
+ * Введенный номер действителен, и это 10-значный номер;
+ * Номер не заблокирован по каким-либо причинам;
+ * Проверьте, есть ли у номера какие-либо неоплаченные счета, если они есть, отобразите их на экране;
+ * Все предыдущие счета на этом номере очищены;
+ * Система позволяет генерировать выписки в соответствии с требованиями клиента;
+ * Система точно записала количество звонков;
+ * План, выбранный клиентом, отображается в биллинговой системе;
+ * Общая сумма счета точна и соответствует предлагаемой услуге.
+* **Тестирование приложений** (Application Testing):
+ * Протоколы, подача сигнала, полевые испытания для IOT;
+ * Использование и функциональное тестирование основных приложений мобильных телефонов, таких как звонки, SMS, передача/удержание и т. д.;
+ * Тестирование различных приложений, таких как финансы, спорт, геолокационные сервисы и т. д.
+* **Тестирование системы поддержки операций/системы поддержки бизнеса** (OSS-BSS Testing):
+ * Выставление счетов, обращение с клиентами, выставление счетов за интерконнект, управление заказами и мошенничеством, обеспечение доходов;
+ * Управление сетью, посредничество, подготовка и т. д.;
+ * EAI, CRM и ERP, хранилища данных и т. д.
+* **Тестирование на соответствие** (Conformance Testing):
+ * Совместимость с электрическим интерфейсом;
+ * Соответствие протокола;
+ * Соответствие транспортных уровней.
+* **IVR-тестирование** (IVR Testing):
+ * Интерактивные тестовые сценарии;
+ * Обнаружение энергии голоса;
+ * Широкополосные звуковые сигналы;
+ * Обширные условные последовательности ветвления;
+ * Ввод DTMF.
+
+Источники:
+
+* [Тестирование телекоммуникационных решений: почему это особенно важно в эпоху цифровой трансформации](https://www.connect-wit.ru/aleksej-shalaginov-br-br-testirovanie-telekommunikatsionnyh-reshenij-pochemu-eto-osobenno-vazhno-v-epohu-tsifrovoj-transformatsii.html)
+* [Testing Telecom Domain with Sample OSS/BSS Test cases](https://www.guru99.com/testing-telecom-application-with-sample-testcases.html)
+
+Доп. материал:
+
+* [Telecom Testing Tools & Solutions](https://www.gl.com/telecom-test-solutions/index.html)
+* [Protocol Testing Tutorial: L2 & L3](https://www.guru99.com/protocol-testing.html)
+* [Цифровая трансформация телекома, или как операторы «идут» в ИТ](https://habr.com/ru/company/comptek/blog/353870/)
+* [Чему я научился, разрабатывая биллинговую систему](https://habr.com/ru/company/vdsina/blog/551068/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-veb-saita-ili-veb-prilozheniya-web-application.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-veb-saita-ili-veb-prilozheniya-web-application.md
new file mode 100644
index 0000000..c6dded2
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-veb-saita-ili-veb-prilozheniya-web-application.md
@@ -0,0 +1,289 @@
+# Тестирование веб-сайта или веб-приложения (Web application)
+
+Включает в себя:
+
+* Documentation Testing;
+* Functionality Testing;
+* GUI Testing;
+* Usability Testing;
+* Interface Testing;
+* Database Testing;
+* Compatibility Testing;
+* Performance Testing;
+* Security Testing;
+* Crowd Testing.
+
+**1. Documentation Testing**
+
+Плохая документация может повлиять на качество продукта. Хорошая документация по продукту играет решающую роль в конечном продукте. Таким образом, тестирование документации играет жизненно важную роль в тестировании программного обеспечения. Тестирование задокументированных артефактов, разработанных до, во время и после тестирования продукта, называется тестированием документации.
+
+Ниже приведены некоторые часто используемые артефакты:
+
+* Requirement documents;
+* Test Plan;
+* Test Cases;
+* Traceability Matrix (RTM).
+
+Подробно о тестировании документации написано в видах тестирования.
+
+**2. Functionality Testing**
+
+Функциональное тестирование - тестирование того, что делает система. Проверить, что каждая функция программного приложения ведет себя так, как указано в документе с требованиями. Тестирование всех функций путем предоставления соответствующих входных данных, чтобы проверить, соответствует ли фактический результат ожидаемому результату. Оно используется для проверки рабочих процессов, всех ссылок веб-страниц, тестирования форм, тестирования файлов cookie и подключения к базе данных. Обычно функциональное тестирование включает в себя следующие задачи:
+
+* **Testing UI Workflows**: тестируются end to end workflow или бизнес-сценарии. Рекомендуется написание тестовых сценариев или тестовых случаев, чтобы охватить различные сценарии и установить критерии прохождения;
+* **Тестирование гиперссылок**: все ссылки на веб-сайте работают правильно, и нет неработающих ссылок. Типы ссылок включают внутренние ссылки, исходящие ссылки, якорные ссылки, схемы mailto и т. д.;
+* **Тестирование форм** (проверка полей ввода): формы используются для интерактивного общения с конечными пользователями. Тестировщик должен убедиться, что все формы работают должным образом. Тестирование форм включает в себя:
+ * заполняются ли значения по умолчанию;
+ * отображается ли сообщение об ошибке, когда пользователь не заполняет обязательное поле;
+ * принимает ли форма недопустимые значения;
+ * формы оптимально отформатированы для лучшей читабельности;
+ * поля AJAX правильно заполняют значения во время выполнения;
+ * загружаются ли раскрывающиеся списки с параметрами.
+* **Проверка файлов cookie**: подробно о тестировании кук написано в теме про cookie в сетях;
+* **Проверка HTML и CSS**: Тестировщик должен проверить, имеет ли сайт чистую структуру HTML и оптимизированный CSS в соответствии со стандартами W3C. Также нужно убедиться, что поисковые системы могут легко сканировать сайт.
+ * нет синтаксических ошибок HTML;
+ * цветовые схемы читаемы;
+ * карта сайта точна.
+
+Примеры функциональных тест-кейсов:
+
+* Кнопки:
+ * Enter должна срабатывать как submit;
+ * Tab должен переводить курсор на следующий элемент.
+* Поля ввода:
+ * trimming («убирание») пробелов в полях ввода;
+ * пустота/пробелы в поле ввода;
+ * все способы редактирования (Insert, Delete, Backspace, Ctrl+C/V/X/Z и т. д.);
+ * дроби ( 1.5/ 1,5/ ⅕).
+* Поиск:
+ * wildcard symbols (\*, вертикальный слеш, ?);
+ * написание поискового запроса слитно/раздельно/через дефис должно вести к одному результату;
+ * ввод текста в другой раскладке.
+* Сообщения об ошибках:
+ * пробуем отключить в настройках браузера.
+* Календарь:
+ * 31 июня;
+ * 29 февраля + не високосный год;
+ * прошлое/будущее (например, купить билет на уже прошедшее число).
+* Время:
+ * синхронизация с сервером (на сервере приложения может быть выставлено другое время, отличающееся от таймзоны пользователя);
+ * временные зоны.
+* E-mail:
+ * логин (63 символа) @ домен (253 символа (может быть ip)).
+* Всплывающие окна / подсказки:
+ * пробуем закрыть разными способами (нажатие на кнопку (если есть), на «крестик», клавишей ESC, просто нажатием в другую область экрана);
+ * рефреш страницы особенно в момент запроса на сервер (например, совершение транзакции по покупке) иногда может приводить к появлению ошибок.
+* Все обязательные поля должны быть валидированы.
+* Звездочка должна отображаться для всех обязательных полей.
+* Не должно отображаться сообщение об ошибке для дополнительных полей.
+* Числовые поля не должны принимать буквы и должно отображаться соответствующее сообщение об ошибке.
+* Проверьте наличие отрицательных чисел, если это разрешено для числовых полей.
+* Тестовое деление на ноль должно быть правильно обработано.
+* Проверьте максимальную длину каждого поля, чтобы убедиться, что данные не усекаются.
+* Текст всплывающего сообщения («Это поле ограничено 500 символами») должен отображаться, если данные достигают максимального размера поля.
+* Проверьте, должно ли отображаться подтверждающее сообщение для операций обновления и удаления.
+* Величины должны быть в подходящем формате.
+* Проверьте все поля ввода на ввод специальных символов.
+* Проверьте функциональность тайм-аута.
+* Проверьте функциональность сортировок.
+* Проверьте, что FAQ и Политика конфиденциальности четко определены и доступны для пользователей.
+* Проверьте, все ли работает и не перенаправляется ли пользователь на страницу ошибки.
+* Все загруженные документы открываются правильно.
+* Пользователь должен иметь возможность скачать загруженные файлы.
+* Проверьте функциональность электронной почты системы. Тестируемый скрипт корректно работает в разных браузерах (IE, Firefox, Chrome, Safari и Opera).
+* Проверьте, что произойдет, если пользователь удалит файлы cookie, находясь на сайте.
+* Проверьте, что произойдет, если пользователь удалит файлы cookie после посещения сайта.
+* Проверка работоспособности при наличии расширений браузера, например, блокировщиков рекламы.
+
+**3. GUI**
+
+Верстка - размещение элементов веб-приложения (изображения, текст, кнопки, видео...) в соответствии с макетом или требованиями.
+
+Проверяем:
+
+* наличие всех элементов;
+* их размер и цвет;
+* расположение относительно друг-друга.
+* Сравнение с макетом - метод наложения готового эталонного макета (обычно psd-файл) на приложение в экране браузера, все несовпадения можно рассматривать как ошибки (для этого есть хороший инструмент [Pixel Perfect](https://www.welldonecode.com/perfectpixel/)).
+* Измерение размеров элемента - если это имеет значение, то померять размеры элемента и сравнить их со спецификацией можно с помощью, например [Page Ruler](https://blarg.co.uk/tools/page-ruler).
+* Правильность шрифтов (название, размер, цвет) - [WhatFont](https://chrome.google.com/webstore/detail/whatfont/jabopobgcpjmedljpbcaablpmlmfcogm).
+* Цвета интерфейса - [ColorZilla](https://www.colorzilla.com/chrome/screenshots.html).
+* Контент - проверить на наличие орфографических и грамматических ошибок ([SpellChecker](https://chrome.google.com/webstore/detail/spell-checker-for-chrome/jfpdnkkdgghlpdgldicfgnnnkhdfhocg)).
+* Появление курсора - довольно часто мы забываем проверить, появляется ли вообще и как выглядит курсор в полях ввода, на кликабельных элементах.
+* Фавикон - такая маленькая незначительная вещица, но может изрядно подпортить впечатление пользователя (в моей практике были случаи, когда разработчики или дизайнеры шаблона оставляли фавикон с логотипом своей компании на сайте у заказчика).
+* Обозначение возможности переноса элементов.
+* Кодировка (UTF8...).
+* Стандарты HTML/CSS - достаточно неплохие решения для быстрой проверки предлагает [W3C](https://validator.w3.org).
+* Заголовки по всему приложению должны быть приведены к одному стандарту.
+* Title страницы - о нем мы тоже часто забываем, также как и разработчики :)
+* Back button - достаточно часто встречается ошибка при переходе на какую-то страницу и нажатии на браузерную кнопку Back, предыдущая страница крашится или возврат на нее вовсе не осуществляется.
+* Масштабируемость - особенно это важно при тестировании на смартфонах и планшетах. Где пользователь часто меняет масштаб экрана ([Window Resizer](https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh)), а также режим адаптивного дизайна (например в FireFox Developer Edition).
+* Кроссбраузерность - одна и та же страница может выглядеть по-разному в разных браузерах.
+* Проверяем Scroll.
+* Браузерные расширения, которые могут влиять на внешний вид приложения (например, AdBlock) - пробуем включить и отключить.
+* Проверить контент при отключенных (режим WebDeveloper) изображениях, flash, JavaScript.
+
+Локализация - что мы знаем об этом? Обычно наши знания сводятся к невнятным «ну, это язык», «кодировка», «раскладка», еще реже «геолокация». Что еще мы так часто забываем проверять в рамках тестирования локализации?
+
+* Проверяем тестовый образец на правильность перевода - тут, конечно, хорошо бы подключить переводчика или носителя языка, но за неимением таких, берем тестовый образец и переводим через любой онлайн-переводчик (ну и все мы помним, как прекрасно и весело читать описание товаров на русском языке на AliExpress).
+* Длина переведенных слов - количество символов в переведенном слове может быть гораздо больше, что может привести к «расползанию» интерфейса при переводе.
+* Сокращения/аббревиатуры - существуют правила, по которым их либо переводят, либо транслитерируют, либо оставляют как есть.
+* Валюта.
+* Параметры шрифта могут также значительно отличаться в зависимости от языка ввода.
+* Проверить работу поиска во всех локализациях - например, на AliExpress результаты поиска одного и того же слова «смартфон» дают разный результат по количеству найденных товаров, причем разница исчисляется десятками тысяч.
+* Мета-информация (keywords/title/description) - столь незначительное для пользователя, невидимое, но такое важное для поисковых машин и продвижения сайта в гугле и других поисковиках.
+* RTL (right to left languages) - языки c обратным написанием (арабский, иврит) имеют свои особенности: числа пишутся слева направо, значки и иконки отзеркаливаются, названия программ не переводятся, нет переносов, кнопки редактирования Backspace и Delete работают наоборот.
+
+**4. Usability Testing**
+
+Юзабилити-тестирование стало важной частью любого веб-проекта. Его могут провести тестировщики или небольшая фокус-группа, похожая на целевую аудиторию веб-приложения чтобы проверить, является ли приложение удобным для пользователя, и было ли комфортно использовать его конечному пользователю:
+
+* Соответствует ли приложение ожиданиям конечного пользователя;
+* Логичность интерфейса;
+* Самое нужное «сверху»;
+* Продуманная навигация;
+* Локализация (да, да, она относится и сюда тоже);
+* Совместимость с другим софтом (соцсети) и железом;
+* Скорость работы приложения;
+* Информативность (сообщения / обязательные поля);
+* Возможность отмены действий пользователя;
+* Help - должна быть инструкция, как работать с приложением;
+* Возможность печати (если нужно).
+
+Примеры юзабилити тест-кейсов:
+
+* Текст подсказки должен быть там для каждого поля.
+* Домашняя ссылка должна быть на каждой странице.
+* Сообщение о подтверждении должно отображаться для любого вида операции обновления и удаления.
+* Полоса прокрутки должна появляться только при необходимости.
+* Если при отправке появляется сообщение об ошибке, информация, заполненная пользователем, должна быть там.
+* Название должно отображаться на каждой веб-странице.
+* Все поля (текстовое поле, раскрывающийся список, переключатель и т. д. ) и кнопки должны быть доступны с помощью сочетаний клавиш, и пользователь должен иметь возможность выполнять все операции с помощью клавиатуры.
+
+**5. Interface Testing**
+
+Тестирование интерфейсов предназначено для проверки интерфейса между веб-сервером и сервером приложений, правильно ли взаимодействуют сервер приложений и сервер баз данных. Это гарантирует положительный пользовательский опыт. Он включает в себя проверку процессов связи, а также проверку правильности отображения сообщений об ошибках.
+
+* Приложение: тестовые запросы правильно отправляются в базу данных и вывод на стороне клиента отображается правильно. Ошибки, если таковые имеются, должны быть обнаружены приложением и должны отображаться только администратору, а не конечному пользователю;
+* Веб-сервер: тестовый веб-сервер обрабатывает все запросы приложений без какого-либо отказа в обслуживании;
+* Сервер базы данных: запросы, отправленные в базу данных, дают ожидаемые результаты. Проверьте реакцию системы, когда невозможно установить соединение между тремя уровнями (Приложение, Интернет и База данных) и соответствующее сообщение отображается конечному пользователю.
+
+**6. Database Testing**
+
+Тестирование баз данных (back-end тестирование, тестирование данных) включает проверку целостности данных на front end с данными на back end. Оно проверяет схему, таблицы базы данных, столбцы, индексы, хранимые процедуры, триггеры, дублирование данных, потерянные записи, ненужные записи. Оно включает в себя обновление записей в базе данных и их проверку на внешнем интерфейсе.
+
+Тестирование будет включать в себя:
+
+* Отображение ошибок при выполнении запросов;
+* Целостность данных поддерживается при создании, обновлении или удалении данных в базе данных;
+* Тестирование производительности базы данных;
+* Тестирование процедур, триггеров и функций.
+
+Примеры тест-кейсов для тестирования базы данных:
+
+* Проверьте имя базы данных: имя базы данных должно соответствовать спецификациям.
+* Проверьте таблицы, столбцы, типы столбцов и значения по умолчанию: все должно соответствовать спецификациям.
+* Проверьте, допускает ли столбец null значение.
+* Проверьте первичный и внешний ключ каждой таблицы.
+* Проверьте, установлена ли сохраненная процедура или нет.
+* Проверьте имя хранимой процедуры
+* Проверьте имена параметров, типы и количество параметров.
+* Проверьте требуемые параметры.
+* Проверьте хранимую процедуру, удалив некоторые параметры
+* Проверьте, когда выход равен нулю, это должно повлиять на нулевые записи.
+* Проверьте хранимую процедуру, написав простые запросы SQL.
+* Проверьте, возвращает ли хранимая процедура значения
+* Проверьте хранимую процедуру с образцами входных данных.
+* Проверьте поведение каждого флага в таблице.
+* Убедитесь, что данные правильно сохраняются в базе данных после каждой отправки страницы.
+* Проверьте данные, если выполняются операции DML (Обновить, удалить и вставить).
+* Проверьте длину каждого поля: длина поля на Frontend и backend должна быть одинаковой.
+* Проверьте имена баз данных QA, UAT и production. Имена должны быть уникальными.
+* Проверьте зашифрованные данные в базе данных.
+* Проверьте размер базы данных.
+* Также проверьте время ответа каждого выполненного запроса.
+* Проверьте данные, отображаемые на Frontend, и убедитесь, что они совпадают с backend.
+* Проверьте достоверность данных, вставив неверные данные в базу данных.
+* Проверьте триггеры.
+
+**7. Compatibility Testing**
+
+Тестирование совместимости предназначено для проверки совместимости приложения в разных браузерах и на различных устройствах.
+
+* Тестирование совместимости браузера: кросс-браузерное тестирование - это тип нефункционального теста, который помогает нам убедиться, что наш веб-сайт или веб-приложение работают должным образом в различных веб-браузерах. При тестировании веб-сайта нам необходимо убедиться, что он отображается одинаково во всех браузерах. Нам нужно предоставить одинаковый опыт для пользователей, независимо от того, какой тип ОС и какой браузер они используют. Не все используют одну и ту же среду. Несмотря на то, что Google Chrome является самым популярным на текущем рынке, все же множество пользователей используют Mozilla Firefox, Safari и другие. Если веб-сайт не работает должным образом в конкретном браузере, это ухудшает взаимодействие с пользователем. Нужно проверить, правильно ли отображается ваше веб-приложение в браузерах, работает ли JavaScript, AJAX и аутентификация. Вы также можете проверить рендеринг веб-элементов, таких как кнопки, текстовые поля и т. д.
+* Тестирование совместимости устройств: этот тест подтверждает, что веб-приложение responsive и работает на устройствах разного размера и с разными операционными системами.
+
+Примеры тестов на совместимость:
+
+* Протестируйте сайт в разных браузерах (IE, Firefox, Chrome, Safari и Opera) и убедитесь, что сайт отображается правильно.
+* Используемая версия HTML совместима с соответствующими версиями браузера.
+* Проверьте правильность отображения изображений в разных браузерах.
+* Протестируйте шрифты, которые можно использовать в разных браузерах.
+* Протестируйте код Javascript в разных браузерах.
+* Проверьте анимированные GIF-файлы в разных браузерах.
+
+**8. Performance Testing**
+
+Тестирование производительности определяет или подтверждает характеристики скорости, масштабируемости и/или стабильности тестируемой системы или приложения. Производительность связана с достижением времени отклика, пропускной способности и уровня использования ресурсов, которые соответствуют целям производительности для проекта или продукта. Тестирование производительности веб-приложений проводится для снижения риска доступности, надежности, масштабируемости, быстродействия, стабильности и т. д. системы. Тестирование производительности включает в себя ряд различных типов тестирования, таких как нагрузочное тестирование, объемное тестирование, стресс-тестирование, тестирование емкости, тестирование выдержки/выносливости и пиковое тестирование, каждое из которых предназначено для выявления или решения проблем с производительностью в системе.
+
+Примеры тестов:
+
+* Имитируем нагрузку пользователями (JMeter);
+* Пробуем загрузить большие объемы данных, файлы, медиа;
+* Нагружаем БД;
+* Понижаем скорость инета (NetLimiter);
+* Понижаем скорость передачи данных (Throttling);
+* Тестируем восстановление системы после падений.
+
+**9. Security Testing**
+
+Тестирование безопасности - это процесс, позволяющий определить, защищает ли система данные и поддерживает ли она функциональность, как предполагалось. Тестирование безопасности направлено на выявление всех возможных лазеек и слабых мест системы на самом начальном этапе, чтобы избежать нестабильной работы системы, неожиданного сбоя, потери информации, потери дохода, потери доверия клиентов. Тесты безопасности включают тестирование на наличие уязвимостей, таких как:
+
+* SQL-инъекция (SQL Injection);
+* Межсайтовый скриптинг (XSS);
+* Управление сеансом (Session Management);
+* Сломанная аутентификация;
+* Подделка межсайтовых запросов (CSRF);
+* Неправильная конфигурация безопасности;
+* Невозможность ограничить доступ к URL-адресу;
+* Раскрытие секретных данных;
+* Небезопасная прямая ссылка на объект;
+* Отсутствует контроль доступа на функциональном уровне;
+* Использование компонентов с известными уязвимостями;
+* Непроверенные перенаправления и возвраты.
+
+Примеры тестовых сценариев для тестирования безопасности:
+
+* веб-страница, содержащая важные данные, такие как пароль, номера кредитных карт, секретные ответы на секретный вопрос и т. д. , Должна быть отправлена через HTTPS (SSL).
+* важная информация, такая как пароль, номера кредитных карт и т. д. , должна отображаться в зашифрованном виде.
+* правила проверки пароля применяются на всех страницах аутентификации, таких как Регистрация, забытый пароль, смена пароля.
+* если пароль изменен, пользователь не должен иметь возможность войти со старым паролем.
+* сообщения об ошибках не должны отображать важную информацию.
+* если пользователь вышел из системы или сеанс пользователя истек, пользователь не должен перемещаться по сайту авторизованным.
+* проверьте доступ к защищенным и незащищенным веб-страницам напрямую без входа в систему.
+* опция «Просмотр исходного кода» отключена и не должна быть видна пользователю.
+* учетная запись пользователя заблокирована, если пользователь вводит неправильный пароль несколько раз.
+* куки не должны хранить пароли.
+* если какая-либо функция не работает, система не должна отображать информацию о приложении, сервере или базе данных. Вместо этого она должна отображать пользовательскую страницу ошибки.
+* проверьте атаки SQL-инъекций.
+* проверьте роли пользователей и их права. Например, запрашивающая сторона не должна иметь доступа к странице администратора.
+* важные операции записаны в файлы журналов, и эта информация должна быть отслеживаемой.
+* значения сеанса находятся в зашифрованном формате в адресной строке.
+* информация о файлах cookie хранится в зашифрованном формате.
+* проверьте приложение на брутфорс-атаки
+
+**10. Crowd Testing or Crowdsourced testing**
+
+Краутестинг или краудсорсинговое тестирование - это новая тенденция в тестировании программного обеспечения, которая использует толпу (crowd/большое количество людей) для выполнения тестов, которые в противном случае были бы выполнены выбранной группой людей в компании. Краудсорсинговое тестирование представляет собой интересную и перспективную концепцию и помогает выявить многие незамеченные дефекты. Оно включает в себя практически все типы тестирования, применимые к вашему веб-приложению.
+
+Источники:
+
+* [Web Application Testing Tutorial (How To Test A Website)](https://www.softwaretestingmaterial.com/web-application-testing-tutorial/)
+* [Web Application Testing Checklist: Example Test Cases for Website](https://www.guru99.com/complete-web-application-testing-checklist.html)
+* [Ничего не забыть: универсальная схема для тестирования веб-приложений](https://dou.ua/lenta/articles/scheme-for-qa/)
+
+Доп. материалы:
+
+* [Тестирование веб-проектов. Основные этапы и практические советы.](https://www.youtube.com/watch?v=GyE-TMG1HUA)
+* [Best Web Application Testing Tools (Free and Paid) for 2022](https://www.softwaretestingmaterial.com/web-application-testing-tools/)
+* [Чек-лист тестирования WEB приложений](https://habr.com/ru/post/542422/)
diff --git a/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-vr-programmnogo-obespecheniya.md b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-vr-programmnogo-obespecheniya.md
new file mode 100644
index 0000000..d3a6736
--- /dev/null
+++ b/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-vr-programmnogo-obespecheniya.md
@@ -0,0 +1,136 @@
+# Тестирование VR программного обеспечения
+
+В виртуальной реальности пользователи полностью погружаются в сгенерированную компьютером реальность. Надев на голову дисплей или гарнитуру VR, пользователь перемещается среди виртуальных объектов на экране. Некоторые технологии виртуальной реальности, такие как Google Cardboard и Samsung Gear VR, полагаются на использование смартфона, закрепленного в очках, в то время как другие, такие как Oculus Go, представляют собой автономную гарнитуру виртуальной реальности.
+
+Тестирование программного обеспечения в VR-индустрии трудно переоценить не только за счет внимания к рынку, но и ввиду того, что технологии нашли свое применение не только в привычном секторе развлечений, но и в отраслях, где цена багов в сценариях может быть очень высокой - например, в военно-промышленном комплексе и медицине.
+
+Во многом тестирование VR не отличается от традиционного тестирования игр (в случае игр) или обычного ПО, но и особенностей хватает.
+
+**Подготовка**
+
+Перед тестированием решим вопросы с софтом для захвата изображений и видео (возможно, потребуется записывать и сам процесс тестирования со стороны), не будем объедаться и приоткроем окно в помещении. Само помещение должно быть подходящим и иметь достаточно пространства для тестов. Желательно иметь напарника, который не даст убиться об стену.
+
+Во время тестирования будем делать перерывы и обращать внимание на следующее:
+
+* Motion sickness и то, что может его вызывать: FPS, перемещение по сцене, воздействие на игрока;
+* Высота камеры;
+* Сохранение эффекта погружения;
+* Корректное переключение LOD’ов и читабельность текста;
+* Проходимость уровней, невозможность срезать путь;
+* Интерактивные объекты: выкидывайте ключевые предметы и хватайте все, что можно.
+
+**Как делать скриншоты?**
+
+Поскольку при тестировании VR проектов мы, как правило, находимся не у компьютера и не видим его из-за надетого шлема, нужно заранее подумать над тем, как мы будем фиксировать различные баги, встречающиеся в игре.
+
+В Steam предусмотрена возможность делать скриншоты с помощью комбинации кнопок на VR контроллере (на Oculus комбинация та же: кнопка меню + триггер), но данное сочетание срабатывает не всегда..
+
+Оптимальный вариант - попросить разработчиков привязать захват скриншотов к одной из кнопок контроллера: это сэкономит вам кучу времени, которое вы потратите, если будете бегать каждый раз до компьютера, увидев новый баг. А ведь может случиться так, что вы не успеете добежать, и тогда придётся заново проходить фрагмент уровня для фиксации важного недочета.
+
+Если же разработчики не привязали логику к кнопке, или Steam’овское сочетание не работает, придется пользоваться сторонним софтом. Мой выбор - NVIDIA GeForce Experience, т.к. с его помощью можно не только делать скриншоты, но и записывать видео с наименьшей нагрузкой на систему.
+
+**На что еще обратить внимание?**
+
+* Осторожнее с едой перед тестами: вам, скорее всего, придётся активно двигаться или постоянно падать куда-то в виртуальном пространстве. А если и не придётся, то любая просадка FPS, вызывающая эффект Motion Sickness (об этом чуть позже), может серьёзно подпортить день. Лучше выпейте мятного или имбирного чаю: это натуральный способ, помогающий справляться с укачиванием.
+* Отдыхайте: все мы разные и по-разному переносим нагрузки, но лично мне жизненно необходим небольшой перерыв после каждых 25-30 минут в VR. Важно давать глазам и вестибулярному аппарату восстановиться после всего пережитого в виртуальных мирах.
+* Свежий воздух: обеспечьте приток свежего воздуха, открыв окно или хотя бы направив на себя вентилятор. Это поможет избежать укачивания.
+
+**Насколько комфортно играть?**
+
+**Motion Sickness (укачивание)**
+
+Тестирование VR продуктов - увлекательное приключение, в том числе и потому, что некоторые неоптимизированные проекты легко могут дать вам нагрузки похлеще тех, что испытывают на себе космонавты, готовясь к полету.
+
+Motion Sickness или, по-нашему, укачивание, возникает при рассинхронизации вестибулярного аппарата и органов зрения. Проще говоря, вы стоите на месте, а в VR вас начинает куда-то тащить неведомая сила. Подобный эффект также может быть вызван низкой частотой FPS.
+
+Чтобы помочь разработчикам выпустить продукт, от которого людям не будет физически плохо, вам во время тестов следует обратить внимание на следующее:
+
+* **FPS**: попросите разработчиков добавить виджет (в версии 4.20.2 значения, выводимые командой stat FPS - нечитабельны в шлеме), показывающий частоту кадров в секунду, чтобы оперативно замечать проблемные участки локаций, эффекты, события и фиксировать частоту кадров на скриншотах.
+* **Перемещение игрока**: главная причина укачивания в VR проектах. Прислушайтесь к своим ощущениям во время перемещения по уровню. Если вам становится плохо, обязательно указывайте это в отчете. Возможно, разработчикам следует предусмотреть альтернативные способы передвижения или добавить эффекты, уменьшающие укачивание (например, небольшое затемнение экрана при телепортации).
+* **Воздействия на игрока**: крайне нежелательно воздействие на игрока сторонних сил, затрагивающее камеру. Например, отбрасывающие монстры, трясущаяся перед обрушением пещера и.т.п. В одном из проектов, в разработке которого я принимал участие, нужно было "вытягивать" игрока со дна моря после 5 минут нахождения под водой, что непременно привело бы к укачиванию, т.к вытянуть кого-то с глубины \~140 метров - задача долгая. Поломав немного голову над тем, как угодить клиенту, которому обязательно нужен был подъём вверх, и игрокам, которые были бы от этого не в восторге, мы приняли решение показывать процесс подъёма в течение нескольких секунд, а потом включать затемнение экрана.
+
+**Высота камеры**
+
+Различные VR гарнитуры могут по-разному определять рост игрока, из-за этого высота "глаз", которыми игрок смотрит на виртуальный мир, может значительно отличаться. Проблемы возникают, когда разработчики, делая проект, например, на HTC Vive, до последнего не тестируют билд на Oculus, думая, что они верно прикинули рост персонажа для всех платформ. Однако зачастую решает каждый лишний или недостающий сантиметр роста игрока. Именно поэтому стоит обращать внимание, на какой высоте находится ваша камера при использовании различных девайсов. Это позволит избежать не только неловких моментов с заглядыванием игрока за потолок в небольших помещениях, но и сохранит задуманный разработчиками комфорт от игры. Согласитесь, лучше, когда интерактивный объект находится, как предполагалось, на уровне пояса, а не на уровне колен. Во втором случае игроку будет не до интерактива: всё внимание будет приковано к ноющей пояснице.
+
+Помните, что продуктом, который вы тестируете, будут пользоваться разные люди. Для имитации небольшого роста я обычно играю сидя, а вот для проверки ситуации с высоким игроком придётся обратиться за помощью к самому большому другу или изобрести какое-нибудь нехитрое приспособление типа подставки :) Убедитесь, что рост игрока не ломает существующие механики и не дает ему преимущества.
+
+**Погружение**
+
+Виртуальная реальность способна обеспечить потенциально более глубокий уровень погружения игрока в происходящие в шлеме события за счёт отслеживания положения головы и рук (контроллеров). Однако погружение - понятие очень хрупкое и легко может быть разрушено неопытностью разработчиков. Как этого избежать?
+
+Обращайте внимание на габариты предметов, которые могут по-другому восприниматься в виртуальной реальности. Габариты, отличные от реальных, могут негативно сказаться на чувстве погружения.
+
+Интерактивные объекты должны иметь верную коллизию, корректно лежать на других объектах и иметь реалистичный вес при взаимодействии с ними других объектов.
+
+Положение виртуальных рук игрока должно соответствовать положению рук пользователя и иметь правильный угол наклона.
+
+**Визуальная часть**
+
+Значение, отвечающее за то, сколько каждый объект занимает на экране места, в виртуальной реальности отличается от того же значения при обычном запуске игры. Это может привести к тому, что переключение [LOD’ов](https://docs.unrealengine.com/4.27/en-US/WorkingWithContent/Types/StaticMeshes/HowTo/AutomaticLODGeneration/) объекта, которое как раз опирается на размер объекта на экране, может работать не так, как в редакторе и тестах не в VR.
+
+Для проверки LOD’ов я пользуюсь консольной командой show LODColoration, окрашивающей объекты в цвета, соответствующие текущим уровням детализации. Подробнее - [в документации](https://docs.unrealengine.com/4.27/en-US/BuildingWorlds/LevelEditor/Viewports/ViewModes/).
+
+Помимо детализации объектов следует обратить внимание на читабельность текста. Часто бывает, что отлично выглядящий в редакторе текст невозможно читать в VR.
+
+**Проходимость**
+
+Некоторые разработчики считают, что обычные коллизии и невидимые стены могут остановить игроков в VR от попадания в запрещённые места и срезания пути. К сожалению, с виртуальной реальностью, в отличие от обычных игр, этот приём не работает.
+
+Как пользователи могут сломать систему перемещения и как это предотвратить?
+
+Во-первых, всегда пытайтесь попадать в недоступные места, перемещаясь физически в пределах игрового пространства. Например, есть ворота, для открытия которых нужно убить 100 кабанов, сделать 5 квестов и только после этого получить заветный ключ. Телепортируйтесь вплотную к воротам и просто сделайте несколько шагов в реальном мире в направлении ворот и, вероятно, вы окажетесь за ними и сможете идти дальше, миновав кабанов.
+
+Таким же образом падайте во все пропасти: даже если разработчики запретили телепортироваться в яму, поставив невидимую стену, следует быть уверенным, что случайно зашедшие туда игроки не останутся сидеть на дне, а умрут от падения (а ещё лучше, вообще не будут долго падать: см пункт motion sickness).
+
+Вышеупомянутые невидимые стены также должны быть проверены: игрок не должен иметь возможность срезать путь независимо от выбранного режима перемещения.
+
+Ещё одна хитрость, к которой игроки могут прибегнуть для преодоления тех самых ворот, проверяется так: подойдите вплотную к воротам и просуньте за них руку, которой можно телепортироваться. Сможете переместиться за препятствие?
+
+**Интерактив**
+
+Свобода действий, которую игроки имеют в VR, может легко сломать любую запланированную разработчиками последовательность. Чтобы этого не произошло, во время тестов вы должны основательно покидаться вещами: выкидывайте необходимые для прохождения объекты, бейте их другими предметами, чтобы они улетали в пропасть или залетали в недоступные места. Качественный продукт сможет пройти до конца даже самый буйный игрок.
+
+Обязательно попробуйте хватать зафиксированные интерактивные объекты (рычаги, штурвалы и.т.п) с разных сторон: они не должны дёргаться в момент, когда вы захватываете их. Рывок в начале взаимодействия связан, как правило, с тем, что разработчики забывают учитывать при вычислении нового положения объекта точку, в которой игрок взял объект, компенсируя тем самым рывок объекта в сторону руки.
+
+**Проверка производительности**
+
+На этапе проверки производительности необходимо отрегулировать уровень кадровой частоты (frame per second, FPS) на протяжении всего сценария приложения. Этот показатель критически важен для VR приложений, так как его стабильный уровень обеспечивает тот самый «эффект погружения». В играх, запускаемых на ПК или консоли, кратковременная просадка FPS может остаться незамеченной, но в VR это может разрушить ощущение присутствия, а также вызвать головокружение.
+
+Для VR-приложений золотой стандарт на гарнитуре Oculus Quest FPS 90. Однако, все платформы размещения VR-контента, кроме Oculus Store, не требуют сурового соответствия гайдлайнам, и поэтому допускают контент, который не обязуется соблюдать стабильный fps или иметь определенные правила взаимодействия с пользователем, модерируется только спорный контент, который и так подпадает под общие правила игровых площадок.
+
+При тестировании можно проверять уровень вручную или с помощью алгоритма.
+
+Задача алгоритма - проверка всех наиболее вероятных (вероятность основана на расположении интерактивных и статичных предметов, возможных вариантов взаимодействия с ними) локаций вызывающих просадки fps, места и моменты появления эффектов или даже спавна предметов, когда появляется ранее отсутствующая геометрия.
+
+В случае если такой алгоритм, оказавшись в некоторой точке или совершив в ней действие, получит долговременное понижение кадровой частоты, он пишет в лог положения, цепочку событий и предметов, которые привели к этому и прикладывает скриншот игровой камеры, чтобы затем разработчик мог легко повторить требуемые действия.
+
+Если у нас очень большая локация, то алгоритм использует поведенческую модель, в которой за прохождение сценария алгоритм зарабатывает определенное число очков, взаимодействия с предметами в нужном порядке, находясь в локациях наиболее вероятных проблем с fps. Для всех нештатных ситуаций и просадок fps, получаемые очки максимальны и стимулируют алгоритм повторять действия, приводящие к ошибкам приложения.
+
+**Пользовательское тестирование**
+
+Тестирование VR-приложения может быть усилено за счет теста на специальных фокус-группах, особенно если приложение рассчитано на массового потребителя. Этот этап позволяет понять, насколько хорошо в целом идея принимается рынком.
+
+Пользователям ставятся определенные задачи, которые нужно выполнить внутри приложения. Все действия, реакции и эмоции записываются на аудио и видео для дальнейшего анализа на предмет необходимых корректировок.
+
+**Что еще учитывать при тестировании**:
+
+* Ограничения по “железу”;
+* Ограничения устройств вывода;
+* Разнообразие контроллеров;
+* Калибровка устройств;
+* Целевая аудитория (в частности, продукт рассчитан на новичка или опытного VR юзера?);
+* Индивидуальные особенности психики и организма;
+* Конфиденциальность данных об окружении пользователей и их действиях.
+
+Источники:
+
+* [Особенности тестирования VR продуктов](https://ue4daily.com/blog/VR-QA-howto)
+* [Как происходит тестирование VR программного обеспечения](https://tproger.ru/articles/kak-proishodit-testirovanie-vr-programmnogo-obespechenija/)
+* [Секция QA: Особенности тестирования VR/AR](https://www.youtube.com/watch?v=wYJ2wuHV2jA)
+
+Доп. материал:
+
+* [Тестирование VR - Испытательная Троица (русский перевод)](https://www.youtube.com/watch?v=l5xgaSW6nRE)
+* [VR App Testing Guide - Automation and Performance](https://developer.oculus.com/resources/automation-performance-testing/)
+* [A Guide to Virtual Reality Application Testing](https://www.qaoncloud.com/vr-app-testing/)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/README.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/README.md
new file mode 100644
index 0000000..b7d8368
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/README.md
@@ -0,0 +1,2 @@
+# Тестовая документация и артефакты (Test Deliverablestest artifacts)
+
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bag-report-defect-bug-report.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bag-report-defect-bug-report.md
new file mode 100644
index 0000000..7a15a73
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bag-report-defect-bug-report.md
@@ -0,0 +1,69 @@
+# Баг-репорт (Defect/bug report)
+
+_Отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. (IEEE 829)_
+
+«Смысл написания отчета о проблеме (отчета об ошибке) состоит в том, чтобы исправить ошибки» - Джем Канер. Если тестировщик неправильно сообщает об ошибке, то программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима. Или потратит кучу лишнего времени на то, чтобы сделать вашу работу за вас. Едва ли такой тестировщик будет выгоден бизнесу, приятен коллегам и долго задержится на своем месте.
+
+Главное при написании отчета - он должен быть сразу и однозначно понят читающим, а дефект однозначно воспроизведен по указанным шагам в указанном окружении.
+
+**Основные поля баг-репорта**:
+
+* Уникальный идентификатор (**ID**);
+* Описание (**Summary**): краткое, емкое и понятное описание ошибки;
+* Окружение (**Environment**): ссылка на билд/коммит/версия ПО и всего окружения;
+* Шаги воспроизведения (**Steps to reproduce**): полный перечень шагов для воспроизведения;
+* Ожидаемый результат (**Expected result**): какой результат должен был быть без ошибки;
+* Фактический результат (**Actual result**): какой результат получился на самом деле;
+* Вложения (**Attachments**): логи, скриншоты, видео - всё что необходимо для понимания ошибки.
+
+**Дополнительные**:
+
+* Предварительные условия (Prerequisites);
+* Тестовые данные (Test Data);
+* Серьезность дефекта (Defect Severity);
+* Комментарии (Remarks);
+* Проект (Project);
+* Продукт (Product);
+* Версия релиза (Release Version);
+* Модуль (Module);
+* Обнаружено в версии (Detected Build Version);
+* Вероятность возникновения дефекта (Defect Probability);
+* Приоритет дефекта (Defect Priority);
+* Автор отчета (Reported By);
+* Назначено на (Assigned To);
+* Статус (Status);
+* Fixed Build Version.
+
+В случаях использования TMS поля будут настроены лидом/менеджером и в зависимости от размеров проекта могут быть пункты вроде milestone, epic, feature и т.п.
+
+Помимо прочего, баг-репорты могут создаваться не только тестировщиками, но и любыми членами команды, приходить от пользователей или техподдержки. Во втором случае необходимо будет воспроизвести ошибку, составить баг-репорт по всем правилам или дополнить присланный, затем провести ретроспективу на тему того, как ошибка попала в прод и как этого избежать в будущем.
+
+**Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке:**
+
+* В одном отчете один баг;
+* Воспроизведите его 2-3 раза;
+* Убедитесь, что используете актуальную версию ПО и окружения;
+* Проверьте по поиску багтрекинговой системы наличие отчета о таком же дефекте;
+* Локализуйте ошибку, чтобы выяснить ее первопричину;
+* Напишите подробные шаги и полное окружение для воспроизведения ошибки;
+* Напишите хорошее summary дефекта по формуле “Что? Где? При каких условиях?” (3 Ws, WWW - What? Where? When?);
+* Следите за словами в процессе написания сообщения об ошибке, они не должны обвинять, оскорблять людей, содержать какую-либо точку зрения по поводу произошедшего. В общем, только факты по делу;
+* Проиллюстрируйте проблему с помощью правильных скриншотов, видео и логов;
+* Перед отправкой перепроверьте ваш отчет об ошибке. А потом еще раз;
+
+Источники:
+
+* [How To Write Good Bug Report](https://www.softwaretestingmaterial.com/write-good-bug-report/)
+
+Доп. материал:
+
+* [Defect Probability](https://softwaretestingfundamentals.com/defect-probability/)
+* [Как правильно писать отчеты о дефектах на английском языке](https://www.youtube.com/watch?v=UEY5hGNPSvA)
+* [Не пишите в баге «Ввести 6,9»!](https://okiseleva.blogspot.com/2016/06/69.html)
+* [Воспроизводится ли баг по твоим шагам? Проверь!](https://okiseleva.blogspot.com/2019/07/blog-post\_28.html)
+* [Нужна авторизация? Дай данные](https://okiseleva.blogspot.com/2019/09/blog-post\_2.html)
+* [Эмоций в баге быть не должно!](https://okiseleva.blogspot.com/2019/01/blog-post\_13.html)
+* [4 типичные ошибки оформления бага новичком](https://okiseleva.blogspot.com/2018/09/4.html)
+* [Шаблон бага](http://okiseleva.blogspot.com/2015/05/blog-post\_25.html)
+* [Как воспроизвести баг](https://www.youtube.com/watch?v=1NLd5cvaBAI)
+* [О записи багов, или Найди кота](https://habr.com/ru/company/developersoft/blog/456132/)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bazis-testirovaniya-test-basis.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bazis-testirovaniya-test-basis.md
new file mode 100644
index 0000000..3c6db4b
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/bazis-testirovaniya-test-basis.md
@@ -0,0 +1,39 @@
+# Базис тестирования (Test basis)
+
+_Базис тестирования (test basis): Документ, на основании которого определяются требования к компоненту или системе. Документация, на которой базируются тестовые сценарии. Если правка данного документа может быть осуществлена только в процессе формальной процедуры внесения изменения, то такой базис тестирования называется замороженным базисом тестирования. (ISTQB)_
+
+_Базис тестирования (test basis): Свод знаний, используемых в качестве базы проекта тестирования и контрольных примеров. Примечание - Базис тестирования может иметь форму документов, таких как спецификация требований, спецификация проекта или спецификация модуля, но может также представлять собой недокументированное понимание требуемого поведения. (ГОСТ 56920)_
+
+_Тестовое условие (test condition): Тестируемый аспект компонента или системы, такой как функция, транзакция, возможность, атрибут качества или структурный элемент, идентифицированные как базис тестирования. (ГОСТ 56920)_
+
+Базис тестирования определяется как источник информации или документ, необходимый для написания кейсов, а также как данные для начала анализа тестов. Им может выступать:
+
+* System Requirement Document (SRS);
+* Functional Design Specification;
+* Technical Design Specification;
+* User Manual;
+* Use Cases;
+* Source Code;
+* Business Requirement Document (BRD);
+* ?User story;
+* ?Vision;
+* ?Mockup;
+* ?Prototype.
+
+По [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) примерами базиса тестирования являются:
+
+* ожидания по формату и содержанию документации, обычно в форме стандартов и/или контрольных списков;
+* ожидания потребителя/пользователя по программной системе, новой или уже существующей, обычно спецификаций требований в письменной форме. Они могут быть представлены как функциональные/нефункциональные описания с употреблением глагола "должен", содержащие варианты использования, истории пользователя или другие формы неформально или формально записанные требования. Сюда могут быть включены нормативные требования, которые должны соблюдаться для определенных типов продуктов, например, для критичного к безопасности программного обеспечения для фармацевтической промышленности или для транспортных систем, таких как поезд или самолет;
+* опыт тестера или экспертов в другой предметной области по работе с функциями, необходимыми пользователям, или с историей продукта;
+* ожидания по прямым и/или косвенным интерфейсам между компонентами программной системы и/или по сосуществованию компонентов программной системы, обычно в форме проекта архитектуры в виде схем и/или формального письменного определения протокола;
+* ожидания по реализации компонентов программной системы в коде, обычно в форме детального проекта.
+
+Базис тестирования должен быть четко определен и должным образом структурирован, чтобы можно было легко определить условия тестирования, из которых можно получить тестовые примеры.
+
+_Тестовое условие (test condition): Объект или событие в компоненте или системе, которое должно быть проверено одним или несколькими тестовыми наборами. Например: функция, транзакция, параметр, атрибут качества или структурный элемент. (ISTQB)_
+
+Тестовое условие - тестируемый аспект в test basis.
+
+Источники:
+
+* [Test Basis in Software Testing](https://www.professionalqa.com/test-basis)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/chek-list-check-list.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/chek-list-check-list.md
new file mode 100644
index 0000000..e332285
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/chek-list-check-list.md
@@ -0,0 +1,24 @@
+# Чек-лист (Check List)
+
+Контрольный список/лист проверок - это список проверок, которые помогают тестировщику протестировать приложение или отдельные функции. Основная цель чеклиста состоит в том, чтобы вы не забыли проверить всё, что планировали. Классический чеклист состоит из:
+
+* 1-й столбец: заголовки тест-кейсов, структурированные по разделам/функционалу, или любые определенные составителем пункты;
+* 2-й столбец для отметки: пусто (еще не проверялось)/успех/ошибка;
+* 3-й столбец опционально под заметки.
+
+Если привести простой пример из жизни, то когда вы планируете дела на день или готовитесь к важному мероприятию, вы записываете, или хотя бы составляете мысленно список дел. Это и есть пример чек-листа.
+
+Чек-лист не обязательно является некоторой заменой тест-кейсов, это более глобальная сущность, в виде которой можно записывать множество планов и предстоящих действий: критерии начала и окончания тестирования, проверки перед началом каждой фазы, действия по их завершении, подспорье при исследовательском тестировании, накидать проверок с mind map функционала продукта, шеринг опыта с коллегами и т.п.
+
+**Разница между тест-кейсом и чек-листом**
+
+Сила тест-кейса в том, что в нем все расписано очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но создание и поддержка кейсов требует времени, сил и является рутиной. Помимо прочего, очевидно, тест-кейс часто подразумевает только один конкретный тест, когда в чек-листе подразумевается целый перечень разных проверок.
+
+Сила чек-листа в том, что он простой. Там нет глубокой детализации, это просто памятка. К тому же, он довольно наглядный с точки зрения отчетности. Минус в том, что другому человеку может быть сложно вникнуть в суть проверок без деталей и шагов. Чек-листы стали популярнее с приходом гибких моделей разработки, когда писать детальные кейсы может не быть времени и смысла, т.к. всё меняется слишком быстро, к тому же команда может быть небольшой и расписывать кейсы просто не для кого.
+
+Доп. материал:
+
+* [Чек-листы: полная лекция](https://www.youtube.com/watch?v=UOhg7moss9U)
+* [Составление чек-листов](https://www.youtube.com/watch?v=b3E5SbU1rEM)
+* [Cheat-sheet](https://tmguru.ru/baza-znanij/upravlenie-testami/cheat-sheet/)
+* Примеры: [раз](https://strongqa.com/qa-portal/testing-docs-templates/checklist)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/kriterii-priemki-acceptance-criteria.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/kriterii-priemki-acceptance-criteria.md
new file mode 100644
index 0000000..9312ffb
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/kriterii-priemki-acceptance-criteria.md
@@ -0,0 +1,44 @@
+# Критерии приемки (Acceptance Criteria)
+
+_Критерии приемки (acceptance criteria): Критерии выхода, которым должны соответствовать компонент или система, для того, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом. (IEEE 610)_
+
+Критерии приемки - это условия, которым должен удовлетворять программный продукт, чтобы быть принятым пользователем, заказчиком или, в случае функциональности системного уровня, потребляющей системой. Проще говоря - это список деталей (также известных как требования) о том, как новая функция (feature) программного обеспечения должна работать / выглядеть. Это гарантирует, что:
+
+* Функция разработана хорошо. В противном случае важный или полезный аспект может быть упущен - и никто этого не заметит до самого конца.
+* Это работает так, как было задумано. Если описание расплывчато, разработчикам, возможно, придется сделать предположения о том, как должна работать каждая область. С критериями приемки разработчики точно знают, какой дизайн и функциональность ожидаются.
+* QA знает, чего ожидать во время тестирования. Даже если функция не выглядит сломанной, она может работать не так, как хотели менеджеры по продукту. Если критерии приемки отсутствуют, тестировщики не могут сообщать о подобных проблемах.
+
+Хорошие критерии приемки должны быть простыми для понимания, но с достаточной детализацией, чтобы убедиться, что они не слишком расплывчаты. Это не всегда универсальный подход. Но они всегда должны предоставлять достаточно информации для разработчиков, чтобы создать функцию, а для QA - для ее тестирования. Это не значит, что в процессе разработки программного обеспечения не возникнет вопросов. Но в целом функция должна быть понятной.
+
+Формат / макет / шаблон критериев приемки (Acceptance Criteria Format/Layout/Template): существует два основных типа критериев приемки, основанные на сценариях и правилах:
+
+* Критерии приемлемости, основанные на сценариях (Scenario-based acceptance criteria), используют шаблон для подробного описания конкретного поведения / последовательности действий пользователя;
+* Критерии приемлемости на основе правил (Rule-based acceptance criteria) - это скорее простой список того, как функция должна выглядеть / работать;
+
+**Scenario-based acceptance criteria** соответствует формату “Дано/Когда/Тогда” (“Given/When/Then”) (основан на BDD - [behavior driven development](https://en.wikipedia.org/wiki/Behavior-driven\_development)):
+
+* Given /_какой-то аспект, связанный с поведением пользователя_/
+* When /_пользователь выполняет определенное действие_/
+* Then /_происходит определенный результат_/
+
+Между ними в случае нескольких условий можно добавлять “И” (“AND”).
+
+**Rule-Based Acceptance Criteria** - это простой список «правил» о том, как функция должна выглядеть / работать:
+
+* Все кнопки должны быть определенного цвета;
+* Кнопка входа должна перенаправлять пользователя в определенный раздел;
+* Кнопка регистрации должна находиться в определенной области;
+* Все кнопки должны быть серыми, если не выполняются определенные требования;
+* и многое другое;
+
+Хотя критерии, основанные на правилах, имеют более простой формат, нет причин, по которым они не могут быть длинными и подробными.
+
+**Кто пишет критерии приемки?** Обычно в создании критериев приемки участвуют несколько человек или команд. Тем не менее, это в первую очередь делает product manager (или “product owner”). Разработчики несут ответственность за обеспечение функциональности функции, а QA - за подтверждение ее удобства использования. Но критерии приемки создаются человеком или командой, ответственной за решение, какие новые функции добавить в продукт (независимо от типа приложения или веб-сайта).
+
+Большая часть Agile включает внесение изменений по мере развития проекта. Так **могут ли критерии приемки измениться в середине спринта?** Ответ: «Это зависит от обстоятельств». Если спринт начался, но разработчики еще не завершили эту функцию, можно изменить требования. Но важно всегда сначала согласовывать с разработчиками и держать других (например, QA) в курсе. Тестировщики могли написать test cases, которые больше не актуальны после изменений. Кроме того, новый объем работы может оказаться слишком большим, чтобы разработчики могли завершить его вовремя.
+
+\*\*User Stories vs Acceptance Criteria: \*\*пользовательские истории и критерии приемки идут рука об руку. Пользовательская история описывает основную цель новой функции - обзор того, как она поможет пользователям. Критерии приемки перечисляют способы работы функции с технической точки зрения. Обычно в тикетах (например, в Jira или Trello) вверху указывается пользовательская история, за которой следуют критерии приемки
+
+**Definition of Done:** чтобы заявка (или функция) считалась «выполненной», все критерии должны работать. Например, предположим, что пользовательская история была: “Как пользователь, я хочу иметь возможность войти в систему, чтобы получить доступ к панели управления моей учетной записи”. Как уже упоминалось, пользователь может войти в систему, чтобы получить доступ к панели управления своей учетной записи. Но тикет не считался бы «done», если бы он также содержал следующие критерии приемки: “Кнопка входа должна быть бирюзовой”, а фактически кнопка входа была бы, например, желтой. Иногда команда решает запустить функцию даже с незначительными несоответствиями. Таким образом, они могут пометить тикет как выполненный (или создать отдельный для решения оставшихся аспектов), даже если не все критерии работают. Но с точки зрения технического определения, это не «готово», пока не пройдут все критерии приемки.
+
+Источник: [What is Acceptance Criteria?](https://www.mindfulqa.com/acceptance-criteria/)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/matrica-trassiruemosti-rtm-requirement-traceability-matrix.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/matrica-trassiruemosti-rtm-requirement-traceability-matrix.md
new file mode 100644
index 0000000..be35be3
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/matrica-trassiruemosti-rtm-requirement-traceability-matrix.md
@@ -0,0 +1,49 @@
+# Матрица трассируемости (RTM - Requirement Traceability Matrix)
+
+_Трассируемость (traceability): Способность идентифицировать связанные объекты в документации и программном обеспечении, например, требования со связанными с ними тестами. (ISTQB)_
+
+_Матрица трассируемости (traceability matrix): Двумерная таблица, описывающая связь двух сущностей (например, требований и тестовых сценариев). Таблица позволяет производить прямую и обратную трассировку от одной сущности к другой, обеспечивая таким образом возможность определения покрытия и оценки влияния предполагаемых изменений. (ISTQB)_
+
+
+
+В тестировании многое можно представить в виде удобной и наглядной матрицы (таблицы): Requirement Traceability Matrix, Test matrix, Compliance Matrix, Risk Matrix, RACI Matrix и т.д.
+
+**Матрица трассируемости** (Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix) используется для документирования связей между требованиями и тест-кейсами по этим требованиям и наглядного отображения трассируемости в виде простой таблицы.
+
+Матрица трассируемости может служить одновременно в качестве матрицы покрытия. Наличие такой матрицы позволяет объективно оценить, какая часть продукта покрыта тестами, а какая нет.
+
+**Виды трассируемости**:
+
+* _Вертикальная трассируемость (vertical traceability): Отслеживание требований через уровни разработки к компонентам. (ISTQB)_
+* _Горизонтальная трассируемость (horizontal traceability): Трассировка требований к уровню тестирования по отношению к уровням документации (например, план тестирования, спецификация проектирования теста, спецификация тестовых сценариев и спецификация процедуры тестирования или автоматизированный сценарий тестирования). (ISTQB)_
+
+Другой источник:
+
+* Прямая трассируемость (Forward Traceability): гарантирует, что проект продвигается в желаемом направлении и что каждое требование тщательно проверяется;
+* Обратная трассируемость (Backward Traceability): гарантирует, что текущий разрабатываемый продукт находится на правильном пути. Это также помогает определить, что дополнительные неуказанные функции не добавляются и, таким образом, это не влияет на объем проекта;
+* Двунаправленная трассируемость (Bi-Directional Traceability = Forward + Backward): содержит ссылки от тестовых примеров к требованиям и наоборот. Это гарантирует, что все тестовые примеры можно отследить до требований, и каждое указанное требование содержит точные и действительные тестовые примеры для них.
+
+RTM актуальна на всех этапах программного проекта. Давайте разберемся с этим через водопадную модель SDLC:
+
+* RTM начинается вместе с началом фазы сбора требований (Requirements Gathering phase);
+* продолжается через управление требованиями (Requirements Management);
+* проектирование (Design);
+* разработку (Development);
+* тестирование (Testing);
+* внедрение (Implementation);
+* и поддержку (Support).
+
+При прохождении всех этих этапов трассируемость требований поддерживается с помощью этого документа. После того, как требования были внесены в таблицу, детали дизайна для этих требований будут сопоставлены с требованиями. На основе этих деталей проекта будет производиться разработка программного обеспечения / модуля. Детали репозитория кода из SVN, TFS, Bitbucket, Github будут сопоставлены. Теперь вы знаете, где находится дизайн и код каждого требования. Это трассируемость. Отслеживайте каждое требование от начала до его конечного результата по мере его использования пользователем приложения! На этапе поддержки RTM будет чрезвычайно полезен для понимания и решения проблем, пройдя через все соответствующие детали функции / требования. Улучшение функции стало бы возможным благодаря отслеживанию и пониманию логики, дизайна и кода. С точки зрения владения RTM, RTM принадлежит менеджерам проекта или бизнес-аналитикам. В организациях CMMi команда TQM также будет проверять это как стандартный результат в проектах программного обеспечения.
+
+\*Когда на основе требований к продукту составляются тест-сценарии и выполняется тестирование, это называется Requirement based testing.
+
+Источники:
+
+* [How To Create Requirements Traceability Matrix (RTM): Example And Sample Template](https://www.softwaretestinghelp.com/requirements-traceability-matrix/)
+* [What is the difference between Test matrix and Traceability matrix?](https://www.quora.com/What-is-difference-between-Test-matrix-and-Traceability-matrix)
+
+Доп. материал:
+
+* [Матрица трассабилити](https://habr.com/ru/company/simbirsoft/blog/412677/)
+* [Reinventing the QA process](https://blog.picnic.nl/reinventing-the-qa-process-25854fee51f3)
+* [Traceability Matrix как инфраструктура общения QA и AQA спец-ов через призму Test Pyramid и ROI 2.0](https://www.youtube.com/watch?v=Vurf7G1JgG8)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/metriki-testirovaniya-software-test-metrics.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/metriki-testirovaniya-software-test-metrics.md
new file mode 100644
index 0000000..97e18d7
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/metriki-testirovaniya-software-test-metrics.md
@@ -0,0 +1,100 @@
+# Метрики тестирования (Software Test Metrics)
+
+_Метрика (metric): Шкала измерений и метод, используемый для измерений (ISO 14598)_
+
+“Вы не можете контролировать то, что не можете измерить” - Том Демакро.
+
+Основная цель тестирования заключается в предоставлении информации, необходимой для управления рисками. Чтобы контролировать и управлять тестированием, а также предоставлять своевременную информацию заинтересованным сторонам, необходимы эффективные измерения процесса тестирования. Для измерения процесса тестирования нужно определить, какая информация должна быть предоставлена, как ее получить и как она должна быть представлена. Таким образом, для всех действий тестирования необходимо определить и использовать метрики, а также предоставить показатели измерений, как для продуктов, так и для процессов.
+
+Метрики тестирования программного обеспечения подразделяются на два типа:
+
+* **Метрики процесса** (Process metrics): используются в процессе подготовки и выполнения тестирования.
+ * **Продуктивность подготовки тест-кейсов** (Test Case Preparation Productivity): используется для расчета количества подготовленных тест-кейсов и усилий (Effort), затраченных на их подготовку.
+
+ _Test Case Preparation Productivity = (No of Test Case) / (Effort spent for Test Case Preparation)_
+ * **Охват тестового дизайна** (Test Design Coverage): процент покрытия тест-кейсами требований.
+
+ _Test Design Coverage = ((Total number of requirements mapped to test cases) / (Total number of requirements)\*100_
+ * **Продуктивность выполнения тестов** (Test Execution Productivity): определяет количество тест-кейсов, которые могут быть выполнены в час.
+
+ _Test Execution Productivity = (No of Test cases executed) / (Effort spent for execution of test cases)_
+ * **Покрытие выполненных тестов** (Test Execution Coverage): предназначено для измерения количества выполненных тест-кейсов по сравнению с количеством запланированных тест-кейсов.
+
+ _Test Execution Coverage = (Total no. of test cases executed / Total no. of test cases planned to execute)\*100_
+ * **Успешные тест-кейсы** (Test Cases Passed): для измерения процента пройденных успешно тест-кейсов.
+
+ _Test Cases Pass = (Total no. of test cases passed) / (Total no. of test cases executed) \* 100_
+ * **Неуспешные тест-кейсы** (Test Cases Failed): для измерения процента заваленных тест-кейсов.
+
+ _Test Cases Failed = (Total no. of test cases failed) / (Total no. of test cases executed) \* 100_
+ * **Заблокированные тест-кейсы** (Test Cases Blocked): для измерения процента блокированных тест-кейсов.
+
+ _Test Cases Blocked = (Total no. of test cases blocked) / (Total no. of test cases executed) \* 100_
+* **Метрики продукта** (Product metrics):
+ * **Уровень обнаружения ошибок** (Error Discovery Rate): для определения эффективности тест-кейсов.
+
+ _Error Discovery Rate = (Total number of defects found /Total no. of test cases executed)\*100_
+ * **Процент выявления дефектов** (Defect Detection Percentage (DDP)): _Количество дефектов, выявленных в фазе тестирования, поделенное на число дефектов, найденных в этой фазе тестирования, а также во всех последующих фазах. См. также ускользнувший дефект. (ISTQB)_
+ * **Уровень исправления дефектов** (Defect Fix Rate): помогает узнать качество сборки (build) с точки зрения устранения дефектов.
+
+ _Defect Fix Rate = (Total no of Defects reported as fixed - Total no. of defects reopened) / (Total no of Defects reported as fixed + Total no. of new Bugs due to fix)\*100_
+ * **Плотность дефектов** (Defect Density): _количество дефектов, обнаруженных в компоненте или системе, поделенное на размер компонента или системы (выраженный в стандартных единицах измерения, например строках кода, числе классов или функций). (ISTQB)_
+
+ _Defect Density = Total no. of defects identified / Actual Size (requirements)_
+ * **Утечка дефектов** (Defect Leakage): используется для проверки эффективности процесса тестирования перед UAT.
+
+ _Defect Leakage = ((Total no. of defects found in UAT)/(Total no. of defects found before UAT)) \* 100_
+ * **Эффективность устранения дефектов** (Defect Removal Efficiency): позволяет сравнивать общую (дефекты, обнаруженные до и после поставки) эффективность устранения дефектов.
+
+ _Defect Removal Efficiency = ((Total no. of defects found pre-delivery) /( (Total no. of defects found pre-delivery )+ (Total no. of defects found post-delivery)))\* 100_
+
+**Тестовое покрытие (Test Coverage)**
+
+Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Сложность современного ПО и инфраструктуры сделало невыполнимой задачу проведения тестирования со 100% тестовым покрытием. Поэтому для разработки набора тестов, обеспечивающего более-менее высокий уровень покрытия можно использовать специальные инструменты либо техники тест дизайна.
+
+Существуют следующие подходы к оценке и измерению тестового покрытия:
+
+* [Покрытие требований (Requirements Coverage)](http://www.protesting.ru/testing/testcoverage.html#requirements) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceability matrix).
+* [Покрытие кода (Code Coverage)](http://www.protesting.ru/testing/testcoverage.html#code) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей ПО.
+* [Тестовое покрытие на базе анализа потока управления](http://www.protesting.ru/testing/testcoverage.html#flow) - это одна из техник тестирования белого ящика, основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.
+
+Различия:\
+Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами разработанной части продукта (исходного кода), а анализ потока управления - на прохождении путей в графе или модели выполнения тестируемых функций (Control Flow Graph).
+
+Ограничения:
+
+* Метод оценки покрытия кода не выявит нереализованные требования, так как работает не с конечным продуктом, а с существующим исходным кодом.
+* Метод покрытия требований может оставить непроверенными некоторые участки кода, потому что не учитывает конечную реализацию.
+
+_**Альтернативное мнение**_
+
+Покрытие кода - совершенно бесполезная метрика. Не существует «правильного» показателя. Это вопрос-ловушка. У вас может быть проект с близким к 100% покрытием кода, в котором по-прежнему остаются баги и проблемы. В реальности нужно следить за другими метриками - хорошо известными показателям CTM (Codepipes testing Metrics).
+
+
+
+* **PDWT** (процент разработчиков, пишущих тесты) - вероятно, самый важный показатель. Нет смысла говорить об антипаттернах тестирования ПО, если у вас вообще нет тестов. Все разработчики в команде должны писать тесты. Любую новую функцию можно объявлять сделанной только если она сопровождается одним или несколькими тестами.
+* **PBCNT** (процент багов, приводящих к созданию новых тестов). Каждый баг в продакшне - отличный повод для написания нового теста, проверяющего соответствующее исправление. Любой баг должен появиться в продакшне не более одного раза. Если ваш проект страдает от появления повторных багов даже после их первоначального «исправления», то команда действительно выиграет от использования этой метрики.
+* **PTVB** (процент тестов, которые проверяют поведение, а не реализацию). Тесно связанные тесты пожирают массу времени при рефакторинге основного кода.
+* **PTD** (процент детерминированных тестов от общего числа). Тесты должны завершаться ошибкой только в том случае, если что-то не так с бизнес-кодом. Если тесты периодически ломаются без видимой причины - это огромная проблема.\
+ \
+ Если после прочтения о метриках вы по-прежнему настаиваете на установке жесткого показателя для покрытия кода, я дам вам число 20%. Это число должно использоваться как эмпирическое правило, основанное на законе Парето. 20% вашего кода вызывает 80% ваших ошибок
+
+Источники:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996)
+* [Software Test Metrics - Product Metrics & Process Metrics](https://www.softwaretestingmaterial.com/test-metrics/)
+* [Антипаттерны тестирования ПО](https://habr.com/ru/post/358178/)
+
+Доп. материал:
+
+* [What Metrics Should You Be Using?](https://blog.gurock.com/qa-metrics/)
+* [Different Software Quality Metrics used by Expert Test Managers](https://www.softwaretestinggenius.com/different-software-quality-metrics-used-by-expert-test-managers/)
+* [Code Coverage: How to Measure You've Done Enough Testing](https://hackernoon.com/code-coverage-how-to-measure-youve-done-enough-testing)
+* [Understanding time to quality](https://theqalead.com/topics/time-to-quality-concept-explained/)
+* [Метрики в тестировании](https://www.youtube.com/watch?v=OyCnB2LvAtQ\&t=656s)
+* [Самый полный список метрик тестирования на русском языке](https://habr.com/ru/post/546562/)
+* [Code Coverage Best Practices](https://testing.googleblog.com/2020/08/code-coverage-best-practices.html)
+* [Лекция 4: Оценка оттестированности проекта: метрики и методика интегральной оценки](https://intuit.ru/studies/courses/48/48/lecture/1430)
+* [Тестовое покрытие по Бейзеру // Бесплатный урок OTUS](https://www.youtube.com/watch?v=jqjJ256CZhk)
+* [Оцениваем риски в тестировании с помощью open source-проекта Drill4j](https://www.youtube.com/watch?v=zN-F71rEXh4)
+* [Метрики в тестировании. Матрица трассировки](https://www.youtube.com/watch?v=OyCnB2LvAtQ)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/plan-testirovaniya-test-plan.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/plan-testirovaniya-test-plan.md
new file mode 100644
index 0000000..ec9ca47
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/plan-testirovaniya-test-plan.md
@@ -0,0 +1,61 @@
+# План тестирования (Test plan)
+
+_“План тестирования (test plan): Документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств.” (IEEE 829)_
+
+В то время как стратегия излагает общие принципы или теорию, план детально описывает практические аспекты того, как проект будет протестирован в реальности.
+
+Хотя есть рекомендации по составлению тест плана (IEEE 829 ([1](https://www.ecs.csun.edu/\~rlingard/comp480/TestPlanTemplate.pdf), [2](https://jmpovedar.files.wordpress.com/2014/03/ieee-829.pdf)), [RUP](https://tmguru.ru/wp-content/uploads/2015/01/TestPlanTemplate\_RUP.pdf)), нет единственно правильного шаблона или формата для написания тест-планов. В обзорных статьях можно встретить и свои варианты:
+
+[Такой](https://theqalead.com/topics/leadership-in-test-test-planning/):
+
+* Перечень планируемых тестовых активностей ([Test Activities](https://theqalead.com/wp-content/uploads/2021/06/Test-activities-infographic-1024x579.png));
+* Тестовая логистика ([Test Logistics](https://theqalead.com/wp-content/uploads/2021/06/Test-logistics-infographic-1024x579.png));
+* Необходимые ресурсы ([Resources](https://theqalead.com/wp-content/uploads/2021/06/Resources-infographic-1024x579.png));
+* Необходимые коммуникации ([Your Support Network](https://theqalead.com/wp-content/uploads/2021/06/Typical-requirements-infographic-1024x579.png));
+* Оценки трудозатрат (Estimates);
+* Зависимости и риски (Dependencies, Risks and Assumptions);
+* Порядок обсуждений и отчетности в процессе работы (Communication, Commitment and Progress Reporting);
+
+Или:
+
+* Какие ресурсы требуются и когда;
+* Когда задачи нужно начинать и заканчивать, и кто их будет выполнять;
+* Навыки, необходимые для выполнения задач;
+* Инструменты и технологии, поддерживающие план;
+* Результаты и когда они будут доставлены;
+* Затраты на усилия и необходимые ресурсы;
+* Процесс продвижения проекта / процесса по стадиям;
+* Риски, угрожающие доставке.
+
+В какой-то момент можно заметить, что все они предлагают плюс-минус похожую структуру и пункты, а итоговый вариант всё равно будет уникальным для каждого конкретного проекта. Весомая часть литературы по данной теме предполагает работу по водопадной модели разработки и эта информация не так актуальна в наше время. Это не значит, что в гибких методологиях не бывает тест-планов. Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования - по крайней мере, на высоком уровне - процесса выпуска на ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется на свет. Планирование - это непрерывное обучение, а не задача с конечным результатом.
+
+В гибких методологиях всё чаще говорят о концепции одностраничного тест-плана, а в случае необходимости дополнений и уточнений просто создаются ссылки на внешние страницы/документы. Такой план может быть и в гугл-таблицах, в виде дашборда, mind map, и как вам самим вздумается. Тест-план призван отвечать на те вопросы, ради которых его создают. Порой весомую часть пользы от данной активности можно получить на этапе самого планирования и составления плана, а не от самого документа. Если команда понимает, что никакой практической “боли” этот документ и его создание не решает, на него нет времени, то можно прекрасно обойтись и без его формализации, т.к. в некоей словесной форме он всё равно будет существовать всегда.
+
+_“В зависимости от размеров команды, сложности продукта, количества зависимостей и строгости критериев качества эти вопросы могут быть иными. Если процесс тестирования имеет большое количество зависимостей, например разные команды должны выполнять разные этапы тестирования в строго определенном порядке - это необходимо фиксировать. Без этого ты не только не сможешь планировать работу команд, но и несколько раз выстрелишь себе в ногу, когда команды будут блокировать друг друга из-за того, что заранее не проговорили зависимости. Чем более комплексным является объект тестирования (и как результат само тестирование), тем более подробного описания требует методология тестирования, применяемые подходы и практики - просто за счёт увеличения объема того, что необходимо проверить. Без этого сложно оценивать объемы работ, давать эстимейты и строить планы по релизам. Чем более точно и строго необходимо оценивать уровень качества, тем более детально должны быть описаны критерии прохождения тестирования, ключевые метрики и_ [_quality gate_](https://habr.com/ru/post/542676/)_\`ы. Потому что без их формализации нельзя будет однозначно оценить результаты тестирования. Люди, находящиеся за пределами команды тестирования (а иногда и команды разработки в целом) хотят понимать, что вообще происходит на этапе тестирования и как обеспечивается качество продукта. Иногда это связано с регуляторикой отрасли, иногда для согласования объемов работы с заказчиком, иногда из-за высокой степени рисков или просто потому, что работа этих людей напрямую зависит от результатов процесса обеспечения качества.“ (с)_ [_Shoo and Endless Agony: What's the plan?_](https://t.me/shooandendlessagony/76)__
+
+**Виды тест-планов**:
+
+* **Мастер Тест-План** ([Master Test Plan](https://tryqa.com/what-are-master-test-plans-level-test-plan-examples-when-to-use/)): \_“Главный план тестирования (master test plan, project test plan): План тестирования, обычно охватывающий несколько уровней тестирования.” (ISTQB). \_Это может быть как единственный базовый план, так и главный в иерархии нескольких планов, самый статичный и высокоуровневый. Нужен когда:
+ * продукт имеет множество релизов или итераций, между которыми сохраняется общая информация, которую нет смысла повторять;
+ * различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа;
+* **Детальный Тест-план** (Phase Test plan): _“Уровневый план тестирования (level test plan): План тестирования, обычно относящийся к одному уровню тестирования.” (ISTQB)._ Детальный план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта и является динамическим, т.е. может претерпевать изменения по необходимости. Его основная цель - кратко и доходчиво отразить задачи тестирования. Детальных планов может быть несколько для отдельных модулей ПО или команд тестирования. Кроме того, могут быть созданы планы для отдельных уровней тестирования (Level Test Plan) или видов тестирования. В Agile проектах могут быть планы итерационного тестирования ([iteration testing plans](https://tryqa.com/what-is-release-and-iteration-planning-in-agile-methodology/)) для каждой итерации;
+* **План приемочных испытаний** (Acceptance Test Plan, ПСИ):\*\* \*\*план приемочного тестирования отличают от обычного плана тестирования факторы, которые приводят к принятию бизнес-решения. План приемочного тестирования - это один из жизненно важных документов, который содержит руководство по выполнению приемочного тестирования для конкретного проекта. Пишется на основе бизнес-требований (Business Requirements). Ревью этого плана обычно выполняется by Managers/Business Analysts/Customers.
+
+Источники:
+
+* [Leadership in test: test planning](https://theqalead.com/topics/leadership-in-test-test-planning/)
+* [Acceptance Testing Documentation With Real-Time Scenarios](https://www.softwaretestinghelp.com/acceptance-test-plan/)
+
+Доп. материал:
+
+* [The Inquiry Method for Test Planning](https://testing.googleblog.com/2016/06/the-inquiry-method-for-test-planning.html)
+* [Тест-план не для галочки, или 8 вопросов к заказчику на старте проекта](https://dou.ua/lenta/columns/creating-quality-test-plan/)
+* [Blog: What Should A Test Plan Contain?](https://www.developsense.com/blog/2008/12/what-should-test-plan-contain/)
+* [The One Page Test Plan](https://www.ministryoftesting.com/dojo/lessons/the-one-page-test-plan)
+* [TEST PLAN: What is, How to Create (with Example)](https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html)
+* [Developing a solid yet simple test plan](https://www.softwaretestingnews.co.uk/developing-a-solid-yet-simple-test-plan/)
+* [Тест-план и тест-стратегия: преимущества, состав, советы по ведению](https://dou.ua/forums/topic/35324/?from=fpcol)
+* [Действительно ли вам нужен тест-план?](https://telegra.ph/Dejstvitelno-li-vam-nuzhen-test-plan-11-03)
+* [Что такое тест план и как его написать?](https://testengineer.ru/chto-takoe-test-plan-i-kak-ego-napisat/)
+* [End-to-end, приди и порядок наведи](https://habr.com/ru/company/arcadia/blog/653773/)
+* Примеры: [раз](https://testerchronicles.ru/wp-content/uploads/2018/03/2018-03-12\_16-33-10.png), [два](https://hsto.org/getpro/habr/upload\_files/5be/94e/842/5be94e842c3417a918830cc9f5f1b785.png); [Acceptance Test Plan Template](https://www.softwaretestinggenius.com/docs/tplatp.doc)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/politika-kachestva-i-politika-testirovaniya-quality-policy-and-test-policy.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/politika-kachestva-i-politika-testirovaniya-quality-policy-and-test-policy.md
new file mode 100644
index 0000000..ef5a6cb
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/politika-kachestva-i-politika-testirovaniya-quality-policy-and-test-policy.md
@@ -0,0 +1,39 @@
+# Политика качества и политика тестирования (Quality policy and Test policy)
+
+_Политика Тестирования выражает в бизнес-терминах ожидания менеджмента организации и подход к тестированию программного обеспечения. Она ориентирована на руководителей и старших менеджеров, хотя и может быть полезна для каждого, кто связан с тестированием. Политика Тестирования также руководит предпочтительным направлением и динамикой формирования и выполнения Организационной Стратегии Тестирования и процессов тестирования организации. (ГОСТ 56920)_
+
+**Политика качества** - это заявления, сделанные организациями для передачи своих долгосрочных стратегических целей, задач, видения в отношении производства и поставки качественного продукта. В этих политиках излагаются основные принципы организации, которые помогают им следовать установленным процедурам при разработке и тестировании продукта и постоянно стремиться к улучшению как продукта, так и процесса. Политика в области качества отражает основные ценности организации, что помогает понять их представления об атрибуте качества, о том, что для них означает качество, подходах, ключевых областях внимания и приоритетах при обеспечении качества для своих клиентов. Наличие четко определенной политики в области качества в соответствии со стандартами ISO 9001 является обязательным требованием для организации. Quality policy составляют CEO и Quality Manager.
+
+При написании политики подчеркиваются следующие ключевые области:
+
+* Внимание клиентов: потребности и ожидания клиентов являются важнейшим ключевым критерием, который помогает в достижении перспектив качества продукта. Таким образом, основное внимание следует уделять информированию о текущих и будущих потребностях клиента, а также их выполнению;
+* Лидерство: должна быть в состоянии моделировать и создавать мотивационную и восторженную среду, чтобы извлекать максимум из каждого человека для достижения качества;
+* Постоянное улучшение: должна стремиться к постоянному совершенствованию процедуры и подхода, чтобы улучшить качество;
+* Процесс: должна отражать соблюдение и следование всем стандартным методам и процессам, что способствует повышению качества;
+* Отношения: должна быть направлена на укрепление отношений с клиентом / покупателем;
+* Создание и распространение осведомленности: информирование людей как внутри (персонал), так и за пределами (целевые клиенты) организации о стандартах, принципах и практиках, которым следует организация.
+
+Кроме того, она должна обеспечивать прочную основу для достижения целей в области качества и периодически пересматриваться и обновляться, чтобы постоянно соответствовать существующим требованиям и ожиданиям. Вкратце можно сказать, что политика в области качества, определяемая организациями, действует как зеркало и отражает их виртуальный образ в реальном мире, на основе которого внешние организации могут воспринимать и понимать свои основные принципы и обязательства по отношению к вкладу в качество.
+
+_Политика тестирования (test policy): Документ высокого уровня, описывающий принципы, подход и основные цели организации в отношении тестирования. (ISTQB)_
+
+**Политика тестирования** объясняет философию тестирования компании в целом и указывает направление, которого отдел тестирования должен придерживаться и которому следует следовать. Это должно относиться как к новым проектам, так и к проектам на поддержке. Установление старшими менеджерами соответствующей политики тестирования обеспечивает прочную основу, в которой могут работать специалисты-практики. Это поможет обеспечить максимальную стратегическую ценность каждого проекта.
+
+Политика тестирования является частью политики качества, если она есть, в таких случаях политика качества разъяснит общую цель менеджмента в отношении качества. В ином случае этот документ верхний в иерархии тестовой документации. Политика тестирования содержит следующее:
+
+* Обозначение преимуществ тестирования и коммерческой ценности, которые оправдывают [затраты на качество](https://tryqa.com/what-is-cost-of-quality-in-software-testing/);
+* Определяет [цели тестирования](https://tryqa.com/what-is-the-software-testing-objectives-and-purpose/), такие как укрепление доверия, обнаружение дефектов и снижение рисков для качества;
+* Описывает методы измерения эффективности тестирования и результативности выполнения задач тестирования;
+* Обобщает [процессы](https://tryqa.com/what-is-fundamental-test-process-in-software-testing/), используемые при тестировании;
+* Описывает для организации способы [улучшения процессов](https://tryqa.com/software-testing-process-improvements-for-test-qa-managers/) тестирования.
+
+Политика тестирования также должна включать действия по тестированию, необходимые для поддержки текущего проекта, а также разработки новых проектов.
+
+Источники:
+
+* [Quality Policy](https://www.professionalqa.com/quality-policy)
+* [What is Test Policy? What does it contain?](https://tryqa.com/what-is-test-policy-what-does-it-contain/)
+
+Доп. материал:
+
+* [ISO 9001 Quality Policy - How to Write & Communicate your Policy Statement](https://www.iso-9001-checklist.co.uk/5.2-quality-policy.htm)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/polzovatelskie-istorii-user-stories.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/polzovatelskie-istorii-user-stories.md
new file mode 100644
index 0000000..1edf5c6
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/polzovatelskie-istorii-user-stories.md
@@ -0,0 +1,57 @@
+# Пользовательские истории (User stories)
+
+_Пользовательская история (user story): Высокоуровневое пользовательское или бизнес-требование, обычно использующееся в гибких методологиях разработки программного обеспечения. Обычно состоит из одного или нескольких предложений на разговорном или формальном языке, описывающих функциональность, необходимую пользователю, любые нефункциональные требования и включающих в себя критерии приемки. (ISTQB)_
+
+В индустрии разработки ПО слово «требование» определяет нашу цель, что именно нужно клиентам и что заставит нашу компанию развивать свой бизнес. Будь то продуктовая компания, которая производит программные продукты, или сервисная компания, которая предлагает услуги в различных областях программного обеспечения, основной базой для всех из них является требование, а успех определяется тем, насколько хорошо эти требования выполняются. Термин «требование» имеет разные названия в разных методологиях проекта. В Waterfall это называется Requirement/Specification Document, в Agile или SCRUM требования документируются в виде «Epic» и «User Story». В модели Waterfall документы с требованиями представляют собой огромные документы на сотни страниц, поскольку весь продукт реализуется за один этап. Но это не относится к Agile / SCRUM, потому что в этих случаях требования предъявляются к небольшим функциям или фичам, поскольку продукт готовится поэтапно.
+
+Пользовательская история определяет требования к любой функциональности или фиче, в то время как критерии приемки (Acceptance Criteria) определяют критерии готовности (Definition of done) для пользовательской истории или требования.
+
+
+
+**Пользовательская история** - это требование для любой функциональности или фичи, которое записано в 1-2 строки. Пользовательская история обычно является самым простым из возможных требований и касается одной-единственной функции/фичи.
+
+**Формат**:
+
+Как /_роль пользователя или клиента_/, я хочу /_цель, которую нужно достичь_/, чтобы я мог /_причина цели_/.
+
+Например, “Как _пользователь WhatsApp_, я хочу, чтобы _значок камеры в поле ввода чата позволял захватывать и отправлять изображения_, чтобы я мог _щелкнуть и поделиться своими фотографиями одновременно со всеми своими друзьями_.”
+
+Это стандартный формат, но далеко не обязательный или единственно-возможный. Главное в пользовательской истории - это ценность, которую пользователь получит от функции, т.е. User Story - это приём записи требований, который помогает команде разработки понять нужду клиента и после обсуждения выбрать, описать и утвердить то решение, которое удовлетворит эту нужду.
+
+**Job Stories**
+
+В целом Job Stories - схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности. Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
+
+“Тело” JS делится на три части:
+
+* Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение;
+* Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции;
+* Expected Outcome: описывает, что получит юзер после использования функции.
+
+Job Stories могут писаться по двум форматам:
+
+* В одну строку: When X I want to Y so I can Z" или "When X, actor is Y so that Z;
+* В три строки:
+ * When X
+ * I want to Y
+ * So I can Z.
+
+Пример: When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
+
+Источники:
+
+* [What Is User Story And Acceptance Criteria (Examples)](https://www.softwaretestinghelp.com/user-story-acceptance-criteria/)
+* [Гайд по User Stories](https://habr.com/ru/post/577420/)
+
+Доп. материал:
+
+* [User Stories Full Study: внутри и снаружи](https://www.youtube.com/watch?v=E07TXH\_QpY0)
+* [10 советов для написания хороших пользовательских историй](https://habr.com/ru/company/otus/blog/546518/)
+* [Гайд по Job Stories в помощь к написанию user stories](https://dkapaev.medium.com/%D0%B3%D0%B0%D0%B9%D0%B4-%D0%BF%D0%BE-job-stories-c7d513f72e8f)
+* [Юзер-стори идеальная, а багов 100500? Как мы тестируем документацию](https://habr.com/ru/company/testit-tms/blog/564666/)
+* [Job Stories Offer a Viable Alternative to User Stories](https://www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories)
+* [25 sample user stories](https://www.yodiz.com/help/agile-user-stories-and-groomed-product-backlog/)
+* [User Stories](https://www.agilealliance.org/glossary/user-stories/#q=\~\(infinite\~false\~filters\~\(postType\~\(\~'page\~'post\~'aa\_book\~'aa\_event\_session\~'aa\_experience\_report\~'aa\_glossary\~'aa\_research\_paper\~'aa\_video\)\~tags\~\(\~'user\*20stories\)\)\~searchTerm\~'\~sort\~false\~sortDirection\~'asc\~page\~1\))
+* [User stories to acceptance criterias examples](https://i.pinimg.com/originals/35/4c/32/354c320f1bf9722791a7ccdbb40476cd.png)
+* [The User Story Value Hypothesis](https://qablog.practitest.com/the-user-story-value-hypothesis/)
+* [Use case или User story? Хватит выбирать - даешь все и сразу](https://www.youtube.com/watch?v=KNsznqqcUgI)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/strategiya-testirovaniya-test-strategy.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/strategiya-testirovaniya-test-strategy.md
new file mode 100644
index 0000000..f1f6c2d
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/strategiya-testirovaniya-test-strategy.md
@@ -0,0 +1,36 @@
+# Стратегия тестирования (Test strategy)
+
+_Стратегия тестирования (test strategy): Высокоуровневое описание уровней тестирования, которые должны быть выполнены, и тестирования, входящего в эти уровни, для организации или программы из одного или более проектов. (ISTQB)_
+
+Стратегия тестирования - это статический документ высокого уровня, обычно разрабатываемый менеджером проекта. Это документ, который отражает подход к тестированию продукта и достижению целей, и дает четкое представление о том, что команда тестирования будет делать для всего проекта. Обычно он выводится из Спецификации бизнес-требований (BRS). Как только стратегия тестирования готова, группа тестирования начинает писать подробный план тестирования и продолжает дальнейшие этапы тестирования. В мире Agile некоторые компании не тратят время на подготовку плана тестирования из-за минимального времени для каждого выпуска, но они поддерживают документ стратегии тестирования. Это один из важных документов в test deliverables, которым команда тестирования делится с заинтересованными сторонами для лучшего понимания объема проекта, рисков, подходов к тестированию и других важных аспектов.
+
+Содержание стратегии будет разным в зависимости от проекта, поэтому нет единого для всех шаблона. Можно найти эвристики в помощь, множество зарубежных статей на тему составления стратегии и некоторые общие пункты, которые чаще используются:
+
+* **Обзор и объем** (Scope and overview): объем работ по тестированию (что тестировать и зачем тестировать) и обзор тестируемого продукта;
+* **Подход к тестированию** (Test Approach):
+ * Уровни тестирования (Test levels);
+ * Виды тестирования (Test Types);
+ * Роли и обязанности (Roles and responsibilities);
+ * Требования к окружениям (Environment requirements);
+* **Инструменты тестирования** (Testing tools): инструменты, необходимые для проведения тестов (TMS, багтрекинговая система, стек автоматизации);
+* **Отраслевые стандарты**, которым необходимо следовать (Industry standards to follow): В этом разделе описывается отраслевой стандарт для производства высококачественной системы, которая соответствует ожиданиям клиентов или превосходит их. Обычно менеджер проекта определяет модели и процедуры тестирования, которым необходимо следовать для достижения целей проекта;
+* **Результаты тестирования** (Test deliverables): документация, которую необходимо создать до, во время и по окончании тестирования;
+* **Метрики тестирования** (Testing metrics): метрики, которые следует использовать в проекте для анализа статуса проекта;
+* **Матрица отслеживания требований** (RTM);
+* **Риски и способы их снижения** (Risk and mitigation): все риски тестирования и план по их снижению;
+* **Инструмент отчетности** (Reporting tool): как будут отслеживаться дефекты и проблемы;
+* **Результаты тестов** (Test Summary): виды сводных отчетов о тестах, которые будут создаваться, с указанием периодичности. Сводные отчеты о тестах будут генерироваться ежедневно, еженедельно или ежемесячно, в зависимости от критичности проекта.
+
+Источники:
+
+* [The Complete Guide To Writing Test Strategy](https://www.softwaretestingmaterial.com/test-strategy/)
+
+Доп. материал:
+
+* [Большая качественная подборка материалов по теме](https://www.huibschoots.nl/wordpress/?page\_id=441#strategy)
+* [Practical test strategy using heuristics](https://huddle.eurostarsoftwaretesting.com/resources/test-management/practical-test-strategy-using-heuristics/)
+* [Creating a Quality Strategy](https://thinkingtester.com/creating-a-quality-strategy/)
+* [Стратегия обеспечения качества и вопросы в процессе ее составления](https://testengineer.ru/strategiya-obespecheniya-kachestva/)
+* [6 Ways to Come Up with a Solid Test Strategy](https://blog.gurock.com/solid-test-strategy/)
+* [Creating a quality strategy](https://theqalead.com/topics/creating-a-quality-strategy/)
+* Примеры: [раз](https://www.experimentus.com/itm/15\_Project\_Test\_Strategy\_Agile.pdf), [два](https://strongqa.com/qa-portal/testing-docs-templates/test-strategy), [три](https://www.template.net/business/strategy-templates/sample-test-strategy-template/)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/test-keis-test-case.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/test-keis-test-case.md
new file mode 100644
index 0000000..90bcdf0
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/test-keis-test-case.md
@@ -0,0 +1,58 @@
+# Тест-кейс (Test case)
+
+_Тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. (IEEE 610)_
+
+_Тестовый сценарий высокого уровня (high level test case): Тестовый сценарий без конкретных (уровня реализации) значений входных данных и ожидаемых результатов. Использует логические операторы, а экземпляры реальных значений еще не определены и/или доступны. (ISTQB)_
+
+_Тестовый сценарий низкого уровня (low level test case): Тестовый сценарий с конкретными (уровня реализации) значениями входных данных и ожидаемых результатов. Логические операторы из тестовых сценариев высокого уровня заменяются реальными значениями, которые соответствуют целям этих логических операторов. (ISTQB)_
+
+**Test case** (тест-кейс, тестовый пример/случай) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части. Более строго - формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным.
+
+**Содержание тест-кейса**:
+
+* Идентификатор набора тестов (**Test Suite ID**): Идентификатор набора тестов, в которых входит этот кейс;
+* Идентификатор тестового кейса (**Test Case ID**): Идентификатор самого кейса;
+* Заголовок кейса (**Test Case Summary**): Краткое и емкое название проводимой проверки;
+* Связанное требование (**Related Requirement**): Идентификатор требования, к которому относится / отслеживается данный тестовый пример;
+* Предварительные условия (**Prerequisites**): Любые предпосылки или предварительные условия, которые должны быть выполнены перед выполнением теста;
+* Шаги выполнения (**Test Script / Procedure**): Шаги выполнения теста;
+* Тестовые данные (**Test Data**): Тестовые данные или ссылки на тестовые данные, которые должны использоваться при проведении теста;
+* Ожидаемый результат (**Expected Result**): результат, который мы ожидаем получить после выполнения шагов теста;
+* Статус пройден или не пройден (**Status**): Другие статусы могут быть «Не выполнено», если тестирование не проводится, и «Заблокировано», если тестирование заблокировано;
+* Заметки (**Remarks**): Любые комментарии к тесту или выполнению теста;
+* Создано (**Created By**): Имя автора тестового примера;
+* Дата создания (**Date of Creation**): Дата создания тестового примера (опционально модификации);
+* Выполнено (**Executed By**): Имя человека, выполнившего тест;
+* Дата выполнения (**Date of Execution**): Дата выполнения теста;
+* Тестовое окружение (**Test Environment**): оборудование / программное обеспечение / сеть, в которых выполнялся тест, т.е. все необходимые сведения об окружении, чтобы можно было воспроизвести полученный результат.
+
+В иностранной литературе часто делят кейсы на две категории:
+
+* **Высокоуровневый тест-кейс** (high level test case или logical test case) - тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне smoke. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
+* **Низкоуровневый тест-кейс** (low level test case) - тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно - намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.
+
+**Нужно ли вообще писать кейсы?** Ответ тот же, что и для любого документа - если написание кейсов решает определенную задачу и это обоснованно, то писать. Если вы один, не путаетесь в небольшом проекте, пользуетесь чек листами/mind map/.., можете и без TMS/test runs reports наглядно предоставлять актуальные сведения о протестированности/качестве заинтересованным лицам, то не писать.
+
+**Может ли быть несколько ожидаемых результатов?** Может, если это необходимо, но сразу после каждого шага.
+
+**Можно ли объединять позитивные и негативные тест-кейсы?** Позитивные можно, негативные нельзя, поскольку сложно будет понять, что именно влияет на результат.
+
+Источники:
+
+* [Test Case](https://softwaretestingfundamentals.com/test-case/)
+
+Доп. материал:
+
+* [Тест-кейсы: полная лекция из ШНАТ](https://www.youtube.com/watch?v=0xuOOlhb5SQ)
+* [Составление тест-кейсов](https://www.youtube.com/watch?v=VG8hAQjxAkI)
+* [12 характеристик высокоэффективных тестов](https://software-testing.ru/library/testing/test-analysis/3495-12-traits-of-highly-effective-tests)
+* [Blog: Evaluating Test Cases, Checks, and Tools](https://www.developsense.com/blog/2021/04/evaluating-test-cases-checks-and-tools/)
+* [How to write Test Cases for a Login Page](https://www.softwaretestingmaterial.com/test-scenarios-login-page/)
+* [Как писать тест-кейсы: полное руководство](https://testengineer.ru/kak-pisat-test-kejsy-polnoe-rukovodstvo/)
+* [Основные методики создания тест-кейсов](https://testengineer.ru/osnovnye-metodiki-sozdaniya-test-kejsov/)
+* [Вложил в тест-кейс аттач? Поясни его!](https://okiseleva.blogspot.com/2018/11/blog-post\_23.html)
+* [Результат в тест-кейсе - один или много?](https://okiseleva.blogspot.com/2020/05/blog-post\_14.html)
+* [Правила написания предварительных шагов в тест-кейсах](https://okiseleva.blogspot.com/2019/12/blog-post\_24.html)
+* [Название тест-кейса - как оформлять](https://okiseleva.blogspot.com/2020/12/blog-post\_17.html)
+* [5 атрибутов хорошего тест-кейса. Правила написания тест-кейсов. Тест-кейсы в TestRail.](https://www.youtube.com/watch?v=S4UyfH\_QNec)
+* Примеры: [раз](https://drive.google.com/uc?export=download\&id=0ByI5-ZLwpo25eXFlcU5ZMTJsT28), [два](https://www.softwaretestingmaterial.com/wp-content/uploads/2016/02/Sample-Test-Case-Template-1.png)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-orakul-test-oracle.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-orakul-test-oracle.md
new file mode 100644
index 0000000..026c1f4
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-orakul-test-oracle.md
@@ -0,0 +1,38 @@
+# Тестовый оракул (Test oracle)
+
+_Тестовый предсказатель (test oracle): Источник, при помощи которого можно определить ожидаемые результаты для сравнения с реальными результатами, выдаваемыми тестируемой системой. В роли тестового предсказателя могут выступать уже имеющаяся система (для эталонного тестирования), руководство пользователя, профессиональные знания специалиста, однако им не может быть программный код. (ISTQB)_
+
+**Тестовый оракул** - это механизм для определения того, прошел ли тест или нет. Использование оракулов включает сравнение (для заданных входных данных тестового примера) выходных данных тестируемой системы с выходными данными, которые, по определению оракула, должен иметь продукт. Термин «тестовый оракул» впервые был введен в статье Уильяма Э. Хаудена. Дополнительная работа над различными видами оракулов была исследована Элейн Вейкер.
+
+**Категории тестовых оракулов**:
+
+Определенные (**Specified**): Эти оракулы обычно связаны с формализованными подходами к моделированию программного обеспечения и построению программного кода. Они связаны с formal specification, model-based design, который может использоваться для создания тестовых оракулов, state transition specification, для которой могут быть получены оракулы, чтобы помочь model-based testing and protocol conformance testing, and design by contract, для которого эквивалентный тестовый оракул является утверждением (assertion). Указанные тестовые оракулы имеют ряд проблем. Формальная спецификация основана на абстракции, которая, в свою очередь, может иметь элемент неточности, поскольку все модели не могут зафиксировать все поведение;
+
+Полученные (**Derived**): полученный тестовый оракул различает правильное и неправильное поведение, используя информацию, полученную из артефактов системы. Они могут включать в себя документацию, результаты выполнения системы и характеристики версий тестируемой системы. Regression test suites (or reports) являются примером производного тестового оракула - они построены на предположении, что результат из предыдущей версии системы может быть использован в качестве помощника (оракула) для будущей версии системы. Ранее измеренные характеристики производительности могут быть использованы в качестве оракула для будущих версий системы, например, чтобы задать вопрос о наблюдаемом потенциальном ухудшении производительности. Текстовая документация из предыдущих версий системы может использоваться в качестве основы для определения ожиданий в будущих версиях системы. Псевдо-оракул попадает в категорию полученных тестовых оракулов. Псевдо-оракул, по определению Вейукера, представляет собой отдельно написанную программу, которая может принимать те же входные данные, что и тестируемая программа или система, так что их выходные данные могут быть сопоставлены, чтобы понять, может ли быть проблема для исследования. Частичный оракул - это гибрид указанного тестового оракула и производного тестового оракула. Он определяет важные (но не полные) свойства тестируемой системы. Например, при метаморфическом тестировании (Metamorphic testing) такие свойства, называемые метаморфическими отношениями, используются при нескольких запусках системы.
+
+Примеры:
+
+* формальная спецификация, используемая в качестве входных данных для model-based design and model-based testing;
+* документация, которая не является полной спецификацией продукта, такая как руководство по использованию или установке, или запись характеристик производительности или минимальных требований;
+* оракул согласованности, сравнивающий результаты выполнения одного теста с другим на предмет сходства;
+* псевдо-оракул: вторая программа, которая использует другой алгоритм для вычисления того же математического выражения, что и тестируемый продукт;
+* Specified+derived: во время поиска Google у нас нет полного оракула, чтобы проверить правильность количества возвращенных результатов. Мы можем определить метаморфическое отношение так, что последующий суженный поиск будет давать меньше результатов.
+
+Неявные (**Implicit**): Неявный тестовый оракул полагается на подразумеваемую информацию и предположения. Например, может быть какой-то подразумеваемый вывод из сбоя программы, то есть нежелательное поведение - оракул, чтобы определить, что может быть проблема. Существует несколько способов поиска и тестирования нежелательного поведения, независимо от того, называют ли это отрицательным тестированием, где есть специализированные подмножества, такие как фаззинг. У неявных тестовых оракулов есть ограничения, поскольку они полагаются на подразумеваемые выводы и предположения. Например, сбой программы или процесса может не быть приоритетной проблемой, если система является отказоустойчивой и поэтому работает в форме самовосстановления / самоуправления. Неявные тестовые оракулы могут быть подвержены ложным срабатываниям из-за зависимостей от среды;
+
+Человек (**Human**): Если предыдущие категории оракулов не могут быть использованы, то потребуется участие человека. Это можно рассматривать как количественный и качественный подходы. Количественный подход направлен на поиск нужного количества информации, которую нужно собрать о тестируемой системе (например, результатов тестирования), чтобы заинтересованная сторона могла сделать решения о соответствии или выпуске программного обеспечения. Качественный подход направлен на определение репрезентативности и пригодности входных данных тестирования и контекста выходных данных тестируемой системы. Примером может служить использование реалистичных и репрезентативных данных испытаний и понимание результатов (если они реалистичны). При этом можно руководствоваться эвристическими подходами, такими как интуиция, эмпирические правила, вспомогательные контрольные списки и опыт, чтобы помочь адаптировать конкретную комбинацию, выбранную для тестируемой программы / системы.
+
+Примеры:
+
+* Качественный: эвристический оракул предоставляет репрезентативные или приблизительные результаты по классу тестовых входных данных;
+* Количественный: статистический оракул использует вероятностные характеристики, например, с анализом изображений, где определен диапазон достоверности и неопределенности для того, чтобы тестовый оракул решил о совпадении.
+
+Источники:
+
+* [Test oracle](https://en.wikipedia.org/wiki/Test\_oracle)
+
+Доп. материал:
+
+* [Оракулы в тестировании](https://telegra.ph/Orakuly-v-testirovanii-10-17)
+* [Oracles from the inside out](https://www.developsense.com/blog/2015/09/oracles-from-the-inside-out/)
+
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-scenarii-test-scenario.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-scenarii-test-scenario.md
new file mode 100644
index 0000000..2f7dd92
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/testovyi-scenarii-test-scenario.md
@@ -0,0 +1,34 @@
+# Тестовый сценарий (Test scenario)
+
+_Сценарий выполнения (test scenario): См. спецификация процедуры тестирования. (ISTQB)_
+
+_Спецификация процедуры тестирования (test procedure specification): Документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования. (IEEE 829) См. также спецификация теста_
+
+_Спецификация теста (test specification): Документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и/или спецификации процедуры тестирования (ISTQB)_
+
+**Тестовый сценарий** (Test scenario) - последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им проверок корректности поведения продукта в ходе этих действий. Иными словами, это последовательность шагов, которые пользователь может предпринять, чтобы использовать ваше программное обеспечение. Сценарии тестирования должны учитывать все возможные способы выполнения задачи (функции) и охватывать как положительные, так и отрицательные тестовые примеры, потому что конечные пользователи могут не обязательно предпринимать шаги, которые вы от них ожидаете. Используя тестовые сценарии, мы оцениваем работу приложения с точки зрения конечного пользователя. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.
+
+**Как писать сценарии**:
+
+* Тщательно ознакомьтесь с требованиями (Спецификация бизнес-требований (BRS), Спецификация требований к программному обеспечению (SRS), Спецификация функциональных требований (FRS)) тестируемой системы (SUT), use cases, книгами, руководствами и т. д.;
+* Для каждого требования выясните, как пользователь может использовать программное обеспечение всеми возможными способами;
+* Составьте список сценариев тестирования для каждой функции тестируемого приложения (AUT);
+* Создайте матрицу прослеживаемости и свяжите все сценарии с требованиями. Это позволит вам определить, сопоставлены ли все требования с тестовыми сценариями или нет;
+* Отправьте сценарии тестирования руководителю, чтобы он рассмотрел и оценил их. Даже сценарии тестирования дополнительно проверяются всеми заинтересованными сторонами.
+
+Не стоит путать Test scenario с **Test Suite** (набор тестов, тест-свит).
+
+_Набор тестов (test suite): Комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего. (ISTQB)_
+
+Test Suite - это некоторый набор формализованных Test case, объединенных между собой по общему логическому признаку, которые позволяют проверить одну из частей или вариантов сценария. Test Scenario представляет собой некий пользовательский сценарий по тестированию некой функциональности. Что-то, что пользователь может захотеть сделать с вашей системой, и вы хотите это проверить. Сценарий может иметь один или несколько Test Suite.
+
+Источники:
+
+* [How To Create Test Scenarios With Examples](https://www.softwaretestingmaterial.com/test-scenarios/)
+* [Каких ответов я жду на собеседовании по тестированию](https://habr.com/ru/post/254209/)
+
+Доп. материал:
+
+* [Test Scenarios Registration Form](https://www.softwaretestingmaterial.com/test-scenarios-registration-form/)
+* [Test Scenarios of GMail](https://www.softwaretestingmaterial.com/test-scenarios-of-gmail/)
+* [Шаблон сценария](https://www.softwaretestingmaterial.com/wp-content/uploads/2021/11/Sample-Test-Scenario-Template.xlsx)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/trebovaniya-requirements.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/trebovaniya-requirements.md
new file mode 100644
index 0000000..1a1d10c
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/trebovaniya-requirements.md
@@ -0,0 +1,180 @@
+# Требования (Requirements)
+
+_Требование (requirement): Условия или возможности, необходимые пользователю для решения определенных задач или достижения определенных целей, которые должны быть достигнуты для выполнения контракта, стандартов, спецификации, или других формальных документов. (IEEE 610)_
+
+_Спецификация (specification): Документ, описывающий (в идеале - исчерпывающе, однозначно и доступно) требования, дизайн, поведение или иные характеристики компонента или системы. Зачастую в спецификацию включаются процедуры контроля исполнения. (ISTQB)_
+
+_Спецификация компонента (component specification): Описание функций компонента в терминах его выходных значений для заданных входных значений при определенных условиях, а также требуемого нефункционального поведения (например, использование ресурсов). (ISTQB)_
+
+_Спецификация проектирования теста (test design specification): Документ, описывающий тестовое условие (элементы покрытия) для элемента тестирования, детализированный подход к тестированию, и идентифицирующий соответствующие тестовые сценарии высокого уровня. (IEEE 829)_
+
+_Спецификация процедуры тестирования (test procedure specification): Документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования. (IEEE 829)_
+
+_Спецификация теста (test specification): Документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и/или спецификации процедуры тестирования._
+
+_Спецификация тестовых сценариев (test case specification): Документ, описывающий комплект тестовых сценариев - цель, входы, тестовые операции, ожидаемые результаты и предусловия выполнения для объекта тестирования. (IEEE 829)_
+
+Требования являются отправной точкой для определения того, что проектная команда будет проектировать, реализовывать и тестировать. Вне зависимости от того, какая модель разработки ПО используется на проекте, чем позже будет обнаружена проблема, тем сложнее и дороже будет ее решение. Если проблема в требованиях будет выяснена на начальной стадии, ее решение может свестись к исправлению пары слов в тексте, в то время как недоработка, вызванная пропущенной проблемой в требованиях и обнаруженная на стадии эксплуатации, может даже полностью уничтожить проект.
+
+**Источники и пути выявления требований**
+
+Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) и выявление (elicitation) осуществляются с помощью следующих основных техник:
+
+* **Интервью**. Самый универсальный путь выявления требований, заключающийся в общении проектного специалиста (как правило, бизнес-аналитика) и представителя заказчика (или эксперта, пользователя и т.д.). Интервью может проходить в классическом понимании этого слова (беседа в виде «вопрос ответ»), в виде переписки и т.п. Главным здесь является то, что ключевыми фигурами выступают двое - интервьюируемый и интервьюер (хотя это и не исключает наличия «аудитории слушателей», например, в виде лиц, поставленных в копию переписки).
+* **Работа с фокусными группами**. Может выступать как вариант «расширенного интервью», где источником информации является не одно лицо, а группа лиц (как правило, представляющих собой целевую аудиторию, и/или обладающих важной для проекта информацией, и/или уполномоченных принимать важные для проекта решения).
+* **Анкетирование**. Этот вариант выявления требований вызывает много споров, т.к. при неверной реализации может привести к нулевому результату при объемных затратах. В то же время при правильной организации анкетирование позволяет автоматически собрать и обработать огромное количество ответов от огромного количества респондентов. Ключевым фактором успеха является правильное составление анкеты, правильный выбор аудитории и правильное преподнесение анкеты.
+* **Семинары и мозговой штурм**. Семинары позволяют группе людей очень быстро обменяться информацией (и наглядно продемонстрировать те или иные идеи), а также хорошо сочетаются с интервью, анкетированием, прототипированием и моделированием - в том числе для обсуждения результатов и формирования выводов и решений. Мозговой штурм может проводиться и как часть семинара, и как отдельный вид деятельности. Он позволяет за минимальное время сгенерировать большое количество идей, которые в дальнейшем можно не спеша рассмотреть с точки зрения их использования для развития проекта.
+* **Наблюдение**. Может выражаться как в буквальном наблюдении за некими процессами, так и во включении проектного специалиста в эти процессы в качестве участника. С одной стороны, наблюдение позволяет увидеть то, о чём (по совершенно различным соображениям) могут умолчать интервьюируемые, анкетируемые и представители фокусных групп, но с другой - отнимает очень много времени и чаще всего позволяет увидеть лишь часть процессов.
+* **Прототипирование**. Состоит в демонстрации и обсуждении промежуточных версий продукта (например, дизайн страниц сайта может быть сначала представлен в виде картинок, и лишь затем сверстан). Это один из лучших путей поиска единого понимания и уточнения требований, однако он может привести к серьезным дополнительным затратам при отсутствии специальных инструментов (позволяющих быстро создавать прототипы) и слишком раннем применении (когда требования еще не стабильны, и высока вероятность создания прототипа, имеющего мало общего с тем, что хотел заказчик).
+* **Анализ документов**. Хорошо работает тогда, когда эксперты в предметной области (временно) недоступны, а также в предметных областях, имеющих общепринятую устоявшуюся регламентирующую документацию. Также к этой технике относится и просто изучение документов, регламентирующих бизнес-процессы в предметной области заказчика или в конкретной организации, что позволяет приобрести необходимые для лучшего понимания сути проекта знания.
+* **Моделирование процессов и взаимодействий**. Может применяться как к «бизнес-процессам и взаимодействиям» (например: «договор на закупку формируется отделом закупок, визируется бухгалтерией и юридическим отделом…»), так и к «техническим процессам и взаимодействиям» (например: «платежное поручение генерируется модулем “Бухгалтерия”, шифруется модулем “Безопасность” и передаётся на сохранение в модуль “Хранилище”»). Данная техника требует высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обработкой большого объема сложной (и часто плохо структурированной) информации.
+* **Самостоятельное описание**. Является не столько техникой выявления требований, сколько техникой их фиксации и формализации. Очень сложно (и даже нельзя!) пытаться самому «придумать требования за заказчика», но в спокойной обстановке можно самостоятельно обработать собранную информацию и аккуратно оформить ее для дальнейшего обсуждения и уточнения.
+
+**Уровни и типы требований**
+
+
+
+* **Бизнес-требования** (business requirements) выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль). Результатом выявления требований на этом уровне является общее видение (vision and scope) - документ, который, как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-требований:
+ * Нужен инструмент, в реальном времени отображающий наиболее выгодный курс покупки и продажи валюты;
+ * Необходимо в два-три раза повысить количество заявок, обрабатываемых одним оператором за смену;
+ * Нужно автоматизировать процесс выписки товарно-транспортных накладных на основе договоров.
+* **Пользовательские требования** (user requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объема работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вариантов использования (use cases), пользовательских историй (user stories), пользовательских сценариев (user scenarios). Несколько простых, изолированных от контекста и друг от друга примеров пользовательских требований:
+ * При первом входе пользователя в систему должно отображаться лицензионное соглашение;
+ * Администратор должен иметь возможность просматривать список всех пользователей, работающих в данный момент в системе;
+ * При первом сохранении новой статьи система должна выдавать запрос на сохранение в виде черновика или публикацию.
+* **Бизнес-правила** (business rules) описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д. Несколько простых, изолированных от контекста и друг от друга примеров бизнес-правил:
+ * Никакой документ, просмотренный посетителями сайта хотя бы один раз, не может быть отредактирован или удален;
+ * Публикация статьи возможна только после утверждения главным редактором;
+ * Подключение к системе извне офиса запрещено в нерабочее время.
+* **Атрибуты качества** (quality attributes) расширяют собой нефункциональные требования и на уровне пользовательских требований могут быть представлены в виде описания ключевых для проекта показателей качества (свойств продукта, не связанных с функциональностью, но являющихся важными для достижения целей создания продукта - производительность, масштабируемость, восстанавливаемость). Атрибутов качества очень много, но для любого проекта реально важными является лишь некоторое их подмножество. Несколько простых, изолированных от контекста и друг от друга примеров атрибутов качества:
+ * Максимальное время готовности системы к выполнению новой команды после отмены предыдущей не может превышать одну секунду;
+ * Внесенные в текст статьи изменения не должны быть утеряны при нарушении соединения между клиентом и сервером;
+ * Приложение должно поддерживать добавление произвольного количества неиероглифических языков интерфейса.
+* **Функциональные требования** (functional requirements) описывают поведение системы, т.е. ее действия (вычисления, преобразования, проверки, обработку и т.д.). В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: «приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции»). Несколько простых, изолированных от контекста и друг от друга примеров функциональных требований:
+ * В процессе инсталляции приложение должно проверять остаток свободного места на целевом носителе;
+ * Система должна автоматически выполнять резервное копирование данных ежедневно в указанный момент времени;
+ * Электронный адрес пользователя, вводимый при регистрации, должен быть проверен на соответствие требованиям RFC822.
+* **Нефункциональные требования** (non-functional requirements) описывают свойства системы (удобство использования, безопасность, надежность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения. Здесь приводится более техническое и детальное описание атрибутов качества. В контексте проектирования нефункциональные требования в основном влияют на архитектуру системы. Несколько простых, изолированных от контекста и друг от друга примеров нефункциональных требований:
+ * При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов;
+ * Ни при каких условиях общий объем используемой приложением памяти не может превышать 2 ГБ;
+ * Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов.
+
+Следующие требования в общем случае могут быть отнесены к нефункциональным, однако их часто выделяют в отдельные подгруппы (здесь для простоты рассмотрены лишь три таких подгруппы, но их может быть и гораздо больше; как правило, они проистекают из атрибутов качества, но высокая степень детализации позволяет отнести их к уровню требований к продукту).
+
+* **Ограничения** (limitations, constraints) представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта. Несколько простых, изолированных от контекста и друг от друга примеров ограничений:
+ * Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана от 800x600 до 1920x1080;
+ * Не допускается использование Flash при реализации клиентской части приложения;
+ * Приложение должно сохранять способность реализовывать функции с уровнем важности «критический» при отсутствии у клиента поддержки JavaScript.
+* **Требования к интерфейсам** (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой. Несколько простых, изолированных от контекста и друг от друга примеров требований к интерфейсам:
+ * Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON;
+ * Протоколирование событий должно вестись в журнале событий операционной системы;
+ * Соединение с почтовым сервером должно выполняться согласно RFC3207 («SMTP over TLS»).
+* **Требования к данным** (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования. Несколько простых, изолированных от контекста и друг от друга примеров требований к данным:
+ * Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB;
+ * Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную;
+ * Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.
+
+**Свойства качественных требований** (требования к самим требованиям)
+
+* **Завершенность** (completeness). Требование является полным и законченным с точки зрения представления в нем всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». Типичные проблемы с завершенностью:
+ * Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли должны храниться в зашифрованном виде» - каков алгоритм шифрования?);
+ * Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т.д.» - что мы должны понимать под «и т.д.»?);
+ * Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»).
+* **Атомарность, единичность** (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершенности и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью:
+ * В одном требовании, фактически, содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» - здесь зачем-то в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах);
+ * Требование допускает разночтение в силу грамматических особенностей языка (например: «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату» - здесь описаны три разных случая, и это требование стоит разбить на три отдельных во избежание путаницы). Такое нарушение атомарности часто влечёт за собой возникновение противоречивости;
+ * В одном требовании объединено описание нескольких независимых ситуаций (например: «когда пользователь входит в систему, ему должно отображаться приветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» - все эти три ситуации заслуживают того, чтобы быть описанными отдельными и куда более детальными требованиями).
+* **Непротиворечивость, последовательность** (consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Типичные проблемы с непротиворечивостью:
+ * Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» - тогда как он успешно вошёл в систему, если не имел такого права?);
+ * Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей» - так всё же красной или синей?);
+ * Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» - разрешение есть у экрана, у окна есть размер).
+* **Недвусмысленность** (unambiguousness, clearness). Требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью:
+ * Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объемов данных» - насколько «больших»?) Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно (adequate), быть способным (be able to), легко (easy), обеспечивать (provide for), как минимум (as a minimum), быть способным (be capable of), эффективно (effectively), своевременно (timely), применимо (as applicable), если возможно (if possible), будет определено позже (to be determined, TBD), по мере необходимости (as appropriate), если это целесообразно (if practical), но не ограничиваясь (but not limited to), быть способно (capability of), иметь возможность (capability to), нормально (normal), минимизировать (minimize), максимизировать (maximize), оптимизировать (optimize), быстро (rapid), удобно (user-friendly), просто (simple), часто (often), обычно (usual), большой (large), гибкий (flexible), устойчивый (robust), по последнему слову техники (state-of-the-art), улучшенный (improved), результативно (efficient). Вот утрированный пример требования, звучащего очень красиво, но совершенно нереализуемого и непонятного: «В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно»;
+ * Использование неочевидных или двусмысленных аббревиатур без расшифровки (например: «доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений» - ФС здесь обозначает файловую систему? Точно? А не какой-нибудь «Фиксатор Сообщений»?);
+ * Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» - и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности.
+* **Выполнимость** (feasibility). Требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта. Типичные проблемы с выполнимостью:
+ * Так называемое «озолочение» (gold plating) - требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для конечных пользователей (например: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»).
+ * Технически нереализуемые на современном уровне развития технологий требования (например: «анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»).
+ * В принципе нереализуемые требования (например: «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»).
+* **Обязательность, нужность** (obligatoriness) и актуальность (up-to-date). Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета (см. «проранжированность по…»). Также исключены (или переработаны) должны быть требования, утратившие актуальность. Типичные проблемы с обязательностью и актуальностью:
+ * Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет;
+ * Требованию выставлены неверные значения приоритета по критериям важности и/или срочности;
+ * Требование устарело, но не было переработано или удалено.
+* **Прослеживаемость** (traceability). Прослеживаемость бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability). Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirements management tool) и/или матрицы прослеживаемости (traceability matrix). Типичные проблемы с прослеживаемостью:
+ * Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрестных ссылок;
+ * При разработке требований не были использованы инструменты и техники управления требованиями;
+ * Набор требований неполный, носит обрывочный характер с явными «пробелами».
+* **Модифицируемость** (modifiability). Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно говорить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а ее изменение не приводит к нарушению иных описанных в этом перечне свойств. Типичные проблемы с модифицируемостью:
+ * Требования неатомарны (см. «атомарность») и непрослеживаемы (см. «прослеживаемость»), а потому их изменение с высокой вероятностью порождает противоречивость (см. «непротиворечивость»);
+ * Требования изначально противоречивы (см. «непротиворечивость»). В такой ситуации внесение изменений (не связанных с устранением противоречивости) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость;
+ * Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов).
+* **Проранжированность по важности, стабильности, срочности** (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования. Типичные проблемы с проранжированностью состоят в ее отсутствии или неверной реализации и приводят к следующим последствиям:
+ * Проблемы с проранжированностью по важности повышают риск неверного распределения усилий проектной команды, направления усилий на второстепенные задачи и конечного провала проекта из-за неспособности продукта выполнять ключевые задачи с соблюдением ключевых условий;
+ * Проблемы с проранжированностью по стабильности повышают риск выполнения бессмысленной работы по совершенствованию, реализации и тестированию требований, которые в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности);
+ * Проблемы с проранжированностью по срочности повышают риск нарушения желаемой заказчиком последовательности реализации функциональности и ввода этой функциональности в эксплуатацию.
+* **Корректность** (correctness) **и проверяемость** (verifiability). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных). В дополнение можно отметить, что проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. К типичным проблемам с корректностью также можно отнести:
+ * опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну осмысленную аббревиатуру в другую также осмысленную, но не имеющую отношения к некоему контексту; такие опечатки крайне сложно заметить);
+ * наличие неаргументированных требований к дизайну и архитектуре;
+ * плохое оформление текста и сопутствующей графической информации, грамматические, пунктуационные и иные ошибки в тексте;
+ * неверный уровень детализации (например, слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту);
+ * требования к пользователю, а не к приложению (например: «пользователь должен быть в состоянии отправить сообщение» - увы, мы не можем влиять на состояние пользователя).
+
+**Источники требований**:
+
+* Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения);
+* Нормативное обеспечение организации (регламенты, положения, уставы, приказы);
+* Текущая организация деятельности объекта автоматизации;
+* Модели деятельности (диаграммы бизнес-процессов);
+* Представления и ожидания потребителей и пользователей системы;
+* Журналы использования существующих программно-аппаратных систем;
+* Конкурирующие программные продукты.
+
+**Виды документов требований**:
+
+* **Спецификация требований к программному обеспечению** (SRS - Software Requirement Specification): представляет собой документ, подготовленный группой системных аналитиков (system analysts), который используется для описания программного обеспечения, которое будет разработано, основной бизнес-цели и функциональности определенного продукта, а также того, как он выполняет свои основные функции. В организациях, которые используют SRS, они обычно очень похожи на то, что описывается в PRD и FSD. SRS - это основа любого проекта, поскольку он состоит из структуры, которой будет следовать каждый член команды. SRS также является основой контракта с заинтересованными сторонами (пользователями / клиентами), который включает в себя все подробности о функциональности будущего продукта и о том, как он должен работать. SRS широко используется разработчиками программного обеспечения в процессе разработки продукта или программы. SRS включает как функциональные, так и нефункциональные требования, а также варианты использования. В идеальном документе SRS учитывается не только то, как программное обеспечение будет взаимодействовать с другим программным обеспечением или когда оно встроено в оборудование, но также потенциальных пользователей и способы их взаимодействия с программным обеспечением. Он также содержит ссылки на таблицы и диаграммы, чтобы получить четкое представление обо всех деталях, связанных с продуктом. Документ SRS помогает членам команды из разных отделов оставаться в единстве и обеспечивать выполнение всех требований. Этот документ также позволяет минимизировать затраты и время на разработку программного обеспечения.;
+* **Спецификация бизнес-требований** (BRS - Business Requirement Specification): BRS - это спецификация бизнес-требований, цель которой - показать, как удовлетворить бизнес-требования на более широком уровне. Документ BRS является одним из наиболее широко распространенных документов со спецификациями. Это очень важно, и BRS обычно создается в самом начале жизненного цикла продукта и описывает основные цели продукта или потребности, которые клиент хочет достичь с помощью определенного программного обеспечения или продукта. Он обычно создается бизнес-аналитиком (business analyst) на основе спецификаций других заинтересованных сторон и после тщательного анализа компании-клиента. Обычно окончательная версия документа проверяется клиентом, чтобы убедиться, что ожидания всех заинтересованных сторон бизнеса верны. BRS включает в себя все требования, запрошенные клиентом. Как правило, он состоит из цели продукта, пользователей, общего объема работ, всех перечисленных функций и возможностей, требований к удобству использования и производительности. В этот тип документа не включены варианты использования, а также диаграммы и таблицы. BRS используется в основном высшим и средним менеджментом, инвесторами в продукты, бизнес-аналитиками;
+* **Спецификация функциональных требований** (FRS - Functional Requirement Specification): документ, в котором описаны все функции, которые должно выполнять программное обеспечение или продукт. Фактически, это пошаговая последовательность всех операций, необходимых для разработки продукта от начала до конца. FRS объясняет подробности того, как определенные программные компоненты будут вести себя во время взаимодействия с пользователем. Этот документ создан квалифицированными разработчиками и инженерами и считается результатом тесного сотрудничества между тестировщиками и разработчиками. Основное отличие от документа SRS заключается в том, что FRS не включает варианты использования. Он также может содержать диаграммы и таблицы, но это не обязательно. Этот документ является наиболее подробным, поскольку в нем подробно объясняется, как программное обеспечение должно функционировать (включая бизнес-аспекты, соответствие требованиям, требования безопасности), поскольку оно также должно удовлетворять всем требованиям, упомянутым в документах SRS и BRS. FRS помогает разработчикам понять, какой продукт они должны создать, а тестировщики программного обеспечения лучше разбираются в различных тестовых примерах и сценариях, в которых ожидается тестирование продукта;
+* **Документ бизнес-требований** (BRD - Business Requirements Document, Business Needs Specification, Business Requirements): BRD фокусируются на определении бизнес задач проекта. BRD определяет одну или несколько бизнес задач стоящих перед пользователями, которые могут быть решены с помощью продукта компании. После этого предлагается решение - обычно это новый продукт или усовершенствование существующего продукта в нужной части. Он также может включать какой-то предварительный бизнес анализ - прогноз прибылей, анализ рынка и конкурентов, а также стратегию продаж и продвижения. Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком. В маленьких компаниях это может быть даже директор или владелец фирмы;
+* **Документ требований рынка** (MRD - Market Requirements Document): MRD фокусируется на определении требований рынка к предлагаемому новому продукту. Если BRD определяет круг проблем и предлагает вариант их решения - то MRD более подробно описывает детали предлагаемого решения. Он может включать несколько или все нижеприведенные аспекты:
+
+ * Функциональные возможности, необходимые для решения бизнес задач;
+ * Анализ рынка и конкурентов;
+ * Функциональные и нефункциональные требования;
+ * Приоритезацию требований и функциональных возможностей;
+ * Варианты использования;
+
+ Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком совместно с Системным аналитиком. Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в следующей - и может содержать более 50 страниц;
+* **Документ требований к продукту** (PRD - Product Requirements Document): PRD фокусируется на определении требований к предлагаемому новому продукту. Если MRD фокусируется на требованиях с точки зрения нужд рынка, PRD фокусируется на требованиях с точки зрения самого продукта. Обычно он более детально описывает возможности и функциональные требования и может даже содержать скриншоты и лэйауты пользовательских интерфейсов. В организациях, где MRD не включает детализацию требований и варианты использования, PRD закрывает эту брешь. Обычно он пишется Менеджером по продукту, Бизнес аналитиком или Продуктовым аналитиком;
+* **Функциональная спецификация** (FSD - Functional Specifications Document): FSD детально определяет функциональные требования к продукту с фокусировкой на реализации. FSD может определять продукт последовательно форму за формой и одну функциональную возможность за другой. Это документ, который уже может непосредственно использоваться командой разработчиков для создания продукта. Если MRD и PRD фокусируются на требованиях с точки зрения потребностей рынка и продукта, FSD фокусируется на определении деталей продукта, в форме, которая может быть использована разработчиками. FSD может также включать законченные скриншоты и детальное описание пользовательских интерфейсов (UI). Обычно он пишется Системным аналитиком, Архитектором решения или Главным разработчиком - т.е. автор обычно сам относится к разработчикам;
+* **Спецификация продукта** (PSD - Product Specifications Document): PSD - это наименее популярная аббревиатура, но в тех организациях, которые используют эти документы, они обычно соответствуют по содержанию и объему Функциональной спецификации (Functional Specifications Document FSD) описанный выше;
+* **Спецификация функционального дизайна** (FDS - Functional Design Specification);
+* **Спецификация технического дизайна** (TDS - Technical Design Specification);
+* …
+
+Техники тестирования требований см. в теме “Тестирование документации” в видах тестирования.
+
+Источники:
+
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). Глава 2.
+* [Требования к программному обеспечению](https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F\_%D0%BA\_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%BC%D1%83\_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8E)
+* [Important Software Testing Documentation: SRS, FRS and BRS](https://dzone.com/articles/important-software-testing-documentation-srs-frs-a)
+* [BRD, MRD, PRD, FSD и прочие ТБА](https://www.sites.google.com/site/sloutskov/brd-mrd-prd-fsd-%D0%B8-%D0%BF%D1%80%D0%BE%D1%87%D0%B8%D0%B5-%D1%82%D0%B1%D0%B0)
+
+Доп. материал:
+
+* [Критерии качества требований и как им следовать](https://dou.ua/forums/topic/35139/)
+* [IEEE Guide to the Software Engineering Body of Knowledge](https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf). Chapter 1.
+* [Software Requirements Engineering: What, Why, Who, When, and How By Linda Westfall](http://www.westfallteam.com/Papers/The\_Why\_What\_Who\_When\_and\_How\_Of\_Software\_Requirements.pdf)
+* Карл Вигерс «Разработка требований к программному обеспечению»
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). Раздел 2.2.8. “Типичные ошибки при анализе и тестировании требований”.
+* [Не только функциональные требования](https://www.youtube.com/watch?v=3U7oxrpc7ek)
+* [Нефункциональные требования. Как не упустить качество продукта](https://www.youtube.com/watch?v=IEWlrZcqXCw)
+* [Интервью. Как говорить с людьми про требования](https://www.youtube.com/watch?v=Izw0086q8iM)
+* [«File Converter» Project Requirements SAMPLE](https://drive.google.com/file/d/1MV7IPacZZ77W0YGs6d3UHhCt-8Drpe6r/view)
+* [Системные требования и требования к программному обеспечению](https://intuit.ru/studies/curriculums/15720/courses/174/lecture/4714?page=2)
+* [Ицыксон В.М. ПТППО - Управление требованиями](http://kspt.icc.spbstu.ru/media/files/2010/course/se/requirements-management.pdf)
+* [Почему требования так важны для тестировщика](https://dou.ua/forums/topic/34549/)
+* [Явные и неявные требования](https://www.youtube.com/watch?v=4AYoRhbViwA)
+* [Сколько вопросов задавать по ТЗ](https://okiseleva.blogspot.com/2019/02/blog-post\_28.html)
+* [Сбор требований по TROPOS](https://studopedia.ru/9\_168380\_metodologiya-proektirovaniya-Tropos.html)
+* [Принципы CustDev при сборе требований на разработку](https://www.youtube.com/watch?v=h7tZGDKVvvs)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-otchetov-reports.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-otchetov-reports.md
new file mode 100644
index 0000000..a530157
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-otchetov-reports.md
@@ -0,0 +1,63 @@
+# Виды отчетов (Reports)
+
+Отчет - это документ, содержащий информацию о выполненных действиях, результатах проведённой работы. Обычно он включает в себя таблицы, графики, списки, просто описывающую информацию в виде текста. Их пропорция и содержание определяют пользу и понятность отчета.
+
+Нам важно понять, для кого, для чего и в каких условиях мы это делаем и на сколько это улучшит восприятие излагаемой нами информации. Надо помнить, что каждое действие преследует определенную цель. В случае отчета нам важно понять, для кого, для чего и в каких условиях мы это делаем.
+
+Ниже перечислены наиболее известные варианты отчетов в тестировании.
+
+**Отчет по инциденту (incident report)**
+
+_Отчет по инциденту (incident report): Документ, описывающий событие, которое произошло, например, во время тестирования, и которое необходимо исследовать. (IEEE 829)_
+
+Отчет об инцидентах можно определить как письменное описание инцидента, наблюдаемого во время тестирования. Чтобы лучше понять, давайте начнем с того, что такое «инцидент». Инцидент при тестировании программного обеспечения можно определить как наблюдаемое изменение или отклонение поведения системы от ожидаемого. Это может быть отклонение от функционального требования или от настроек среды. Очень часто инцидент называют дефектом или ошибкой, но это не всегда так. Инцидент - это в основном любое неожиданное поведение или реакция программного обеспечения, требующая расследования.
+
+Инцидент необходимо расследовать, и на основании расследования инцидент может быть преобразован в дефект. Чаще всего это оказывается дефектом, но иногда это может произойти из-за различных факторов, например:
+
+* Человеческий фактор;
+* Требование отсутствует или неясно;
+* Проблема среды, например отсутствие ответа от внутреннего сервера, вызывающее периодическое непредвиденное поведение или ошибку. Либо неправильная конфигурация среды;
+* Ошибочные тестовые данные;
+* Некорректный ожидаемый результат.
+
+Incident report призван зафиксировать и сообщить об инциденте заинтересованным лицам, провести расследование. Составляется аналогично баг-репорту, возможно с упором на расследование, обсуждение, влияние (impact) и может быть назначен не на разработчиков для уточнения деталей.
+
+**Отчет о результатах тестирования (test result report)**
+
+Отчет о результатах тестирования - периодический отчет, в котором документируется подробная информация о выполнении теста и его результате. Также он содержит условия, предположения, ограничения теста, какой элемент теста кем тестируется. Помимо этого вносится подробная информация об оставшейся работе, чтобы показать, сколько еще работы необходимо выполнить в проекте.
+
+**Отчет о выполнении теста (Test Execution Report)**
+
+Отчет о выполнении теста содержит детали выполнения и результат выполнения теста. Обычно его готовят для отправки вышестоящему руководству от группы тестирования, чтобы показать состояние выполнения теста и ход тестирования. Когда мы доставляем программное обеспечение клиенту, мы вкратце отправим полную информацию о выполнении теста. Это даст клиенту лучшее понимание выполненного теста и покрытия.
+
+**Отчет о ходе тестирования (test progress report)**
+
+_Отчет о ходе тестирования (test progress report): Документ, подводящий итог задачам и результатам, составляемый с определенной периодичностью с целью сравнения прогресса тестирования с базовой версией (например, с исходным планом тестирования) и извещения о рисках и альтернативах, требующих решения руководства. (ISTQB)_
+
+**Аналитический отчет о тестировании (test evaluation report)**
+
+_Аналитический отчет о тестировании (test evaluation report): Документ, создаваемый в конце процесса тестирования и подводящий итог тестовым активностям и результатам. Также в нем содержится оценка процесса тестирования и полученный опыт. (ISTQB)_
+
+**Итоговый отчет о тестировании (test summary report)**
+
+_Итоговый отчет о тестировании (test summary report): Документ, подводящий итог задачам и результатам тестирования, также содержащий оценку соответствующих объектов тестирования относительно критериев выхода. (IEEE 829)_
+
+Сводный отчет о тестировании содержит подробную информацию о тестировании, проведенном на протяжении жизненного цикла разработки программного обеспечения. Элементы в итоговом отчете по тестированию различаются от организации к организации, а также различаются для разных проектов. Информация в отчете об испытаниях основывается на аудитории отчета об испытаниях. Аудитория может быть клиентом, менеджментом, бизнес-аналитиком, разработчиками, членами команды тестирования, членами организации и т. д.
+
+**Отчет о пользовательском приемочном тестировании (User acceptance test report)**
+
+Отчет о пользовательском приемочном тестировании создается во время и после UAT. В нем указываются подробности проведенного пользователем приемочного теста и результат пользовательского приемочного теста. В нем также перечислены дефекты, не учтенные при UAT.
+
+Источники:
+
+* [Создание понятных отчетов о тестировании](https://habr.com/ru/company/performance\_lab/blog/207512/)
+* [What Is Incident Report In Software Testing?](https://www.softwaretestingclass.com/what-is-incident-report-in-software-testing/)
+* [Software Testing Artifacts - Test Reports](https://www.softwaretestingclass.com/test-report-artifacts/)
+
+Доп. материал:
+
+* [48+ SAMPLE Test Report Templates](https://www.sample.net/reports/test-report/)
+* [Отчет по результатам тестирования сайта](https://www.performance-lab.ru/wp-content/themes/pureengineering/images/sitetesting/test\_report\_example.pdf)
+* [Отчет о тестировании релиза](https://vk.com/@usetalkrostov-otchet-o-testirovanii-reliza)
+* [Test report templates](https://strongqa.com/qa-portal/testing-docs-templates/test-report)
+* [Test Summary Reports Tutorial: Learn with Example & Template](https://www.guru99.com/how-test-reports-predict-the-success-of-your-testing-project.html)
diff --git a/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-testovoi-dokumentacii.md b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-testovoi-dokumentacii.md
new file mode 100644
index 0000000..39bc0a5
--- /dev/null
+++ b/testovaya-dokumentaciya-i-artefakty-test-deliverablestest-artifacts/vidy-testovoi-dokumentacii.md
@@ -0,0 +1,75 @@
+# Виды тестовой документации
+
+_Тестовая поставка (test deliverable): Любой тестовый (рабочий) продукт, который должен быть доставлен кому-то другому, кроме автора тестового (рабочего) продукта. (ISTQB)_
+
+_Тестовое обеспечение (testware): Артефакты, создаваемые во время процесса тестирования и требующиеся для планирования, разработки и выполнения тестов. Например: документация, сценарии, входы, ожидаемые результаты, процедуры установки и удаления, файлы, базы данных, окружение и любое другое дополнительное программное обеспечение или инструменты, используемые в тестировании. (Fewster and Graham)_
+
+**Артефакт** (artifact) - это один из многих видов материальных побочных продуктов, возникающих в процессе STLC. Это не только документация, а в принципе всё, что создаётся для того, чтобы быть задействованным в тестировании.
+
+**Результаты тестирования** (Test Deliverables) - это артефакты, которые передаются заинтересованным сторонам проекта программного обеспечения в течение жизненного цикла разработки программного обеспечения. На каждом этапе жизненного цикла разработки программного обеспечения существуют разные результаты тестирования. Некоторые результаты тестирования предоставляются до этапа тестирования, некоторые - на этапе тестирования, а некоторые - после завершения циклов тестирования.
+
+Наличие или отсутствие документации, ее актуальность, как и используемые виды варьируются от компании к компании и даже от проекта к проекту. Создание и ведение документации требует весомого количества времени (и компетенций), а потому важно знать основные документы и их роль в процессах, учитывать требования всех заинтересованных лиц, нормативную и законодательную базу, политику и стандарты компании и особенности проекта чтобы понимать, какие из них необходимы (и обоснованны для бизнеса) в каждом случае. Существует огромное количество вариантов документов, часть из которых вы можете никогда и не встретить в реальной работе.
+
+По Куликову документацию можно разделить на два больших вида в зависимости от времени и места ее использования:
+
+* Продуктная документация (product documentation, development documentation) используется проектной командой во время разработки и поддержки продукта. Она включает:
+ * План проекта (project management plan) и в том числе тестовый план (test plan);
+ * Требования к программному продукту (product requirements document, PRD) и функциональные спецификации (functional specifications document, FSD; software requirements specification, SRS);
+ * Архитектуру и дизайн (architecture and design);
+ * Тест-кейсы и наборы тест-кейсов (test cases, test suites);
+ * Технические спецификации (technical specifications), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.;
+* Проектная документация (project documentation) включает в себя как продуктную документацию, так и некоторые дополнительные виды документации и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). Она включает:
+ * Пользовательскую и сопроводительную документацию (user and accompanying documentation), такую как встроенная помощь, руководство по установке и использованию, лицензионные соглашения и т.д.;
+ * Маркетинговую документацию (market requirements document, MRD), которую представители разработчика или заказчика используют как на начальных этапах (для уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для продвижения продукта на рынке).
+
+Можно встретить и другие классификации.
+
+* Внутренняя документация подробно описывает процесс разработки продукта, например стандарты, проектную документацию, заметки о деловой переписке и т. д. Внешняя документация относится к документам, которые подробно описывают сам продукт, например, Системная документация и Пользовательская документация.
+* К внешней документации можно отнести Test policy, Test strategy, различные отчеты, Defect Report, Замечание, Запрос на изменение (улучшение), к внутренней всё от чеклиста до плана тестирования, тестовые данные и т.п. Пользовательская документация (User documentation) - это вся документация, которая будет передана конечному пользователю в комплекте с ПО.
+
+**Виды документации**:
+
+* **Политика качества** (Quality policy): отражает видение компании в отношении производства и поставки качественного продукта;
+* **Политика тестирования** (Test policy): документ высокого уровня, в котором описаны принципы, методы и все важные цели тестирования в организации;
+* **Стратегия тестирования** (Test strategy): статический документ документ высокого уровня (high-level), обычно разрабатываемый менеджером проекта (project manager). Это документ, который отражает подход к тестированию продукта и достижению целей. Обычно он выводится из Спецификации бизнес-требований (BRS - Business Requirement Specification). На основе стратегии тестирования готовится План тестирования;
+* **План тестирования** (Test plan): документ, который содержит план всех действий по тестированию, которые необходимо выполнить для получения качественного продукта. План тестирования является производным от описания продукта (Product Description), SRS (Software requirements specification) или сценариев использования (Use Case) для всех будущих действий проекта. Обычно его готовит руководитель тестирования или менеджер по тестированию (Test Lead or Test Manager);
+* **Отчет об оценке усилий** (Effort Estimation Report): в этом отчете группы тестирования оценивают усилия для завершения процесса тестирования;
+* **Сценарий тестирования** (Test Scenario): элемент или событие программной системы, которое может быть проверено одним или несколькими тестовыми случаями;
+* **Тестовый набор/комплект** (Test Suite): _“Комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего.” (ISTQB)_. Некоторый набор формализованных Test case, объединенных между собой по общему логическому признаку;
+* **Тестовый случай/пример** (Test case): набор положительных и отрицательных исполняемых шагов тестового сценария, который имеет набор предварительных условий, тестовых данных, ожидаемого результата, пост-условий и фактических результатов;
+* **Тест сурвей (Test Survey)**: в рунете только [один источник](https://www.a1qa.ru/blog/obespechivaem-kachestvo-mobilnyh-prilozhenij-shag-2-planirovanie-testovyh-aktivnostej/) о нем, но есть упоминания в истории чатов коммьюнити. Test Survey по детализации занимает место посередине между чек-листом и тест-кейсом, а именно содержит в себе только summary и expected result. Т.е. подробнее чек-листов, где только заголовки, но с ожидаемым результатом и без шагов и прочего как в тест-кейсах;
+* **Чек-лист** (Check List): перечень формализованных Test case в упрощенном виде удобном для проведения проверок, часто только список из заголовков кейсов;
+* **Матрица прослеживаемости требований** (Requirements Traceability Matrix): документ, который соотносит требования с тестовыми примерами;
+* **Тестовые данные** (Test Data): “\_данные, которые существуют (например, в базе данных) на начало \_
+* _выполнения теста и влияют на работу, или же испытывают влияние со стороны тестируемой системы или компонента.” (ISTQB). “Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования.” (ГОСТ 56920)_
+* **Отчет о дефектах** (Defect Report): цель документа заключается в том, чтобы зафиксировать факт ошибки и передать разработчикам подробную информацию о ней;
+* **Отчет о выполнении теста** (Test Execution Report): содержит результаты тестирования и сводку действий по выполнению тестов;
+* **Сводный отчет о тестировании** (Test summary report): представляет собой документ высокого уровня, в котором резюмируются проведенные действия по тестированию, а также результаты тестирования;
+* **Графики и метрики** (Graphs and Metrics): предназначены для мониторинга и управления процессом и продуктом. Это помогает без отклонений вести проект к намеченным целям. Метрики отвечают на разные вопросы. Важно решить, на какие вопросы вы хотите получить ответы;
+* **Отчет о тестовых инцидентах** (Test incident report): содержит все инциденты, разрешенные или неразрешенные, обнаруженные во время тестирования;
+* **Отчет о завершении тестирования** (Test closure report): содержит подробный анализ обнаруженных ошибок, удаленных ошибок и несоответствий, обнаруженных в программном обеспечении;
+* **Отчет о статусе тестирования** (Test status report): предназначен для отслеживания статуса тестирования. Его готовят периодически или еженедельно. В нем указаны работы, выполненные до настоящего времени, и работы, которые еще не завершены;
+* **Еженедельный отчет о статусе** (менеджер проекта для клиента): Weekly status report похож на отчет о статусе тестирования, но генерируется еженедельно;
+* **Отчет об улучшении** (?Enhancement report): описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя;
+* **Запрос на модификацию** (Modification Request): запрос клиента на изменение существующей функциональности;
+* **Примечания к выпуску** (Release Note): примечания к выпуску будут отправлены клиенту, заказчику или заинтересованным сторонам вместе со сборкой. Он содержит список новых выпусков, исправления ошибок;
+* **Руководство по установке / настройке** (Installation/configuration guide): это руководство помогает установить или настроить компоненты, из которых состоит система, и ее аппаратные и программные требования;
+* **Руководство пользователя** (User guide): это руководство помогает конечному пользователю понять как пользоваться продуктом;
+* Различные **документы требований**.
+
+
+
+Источник:
+
+* [Test Deliverables in Software Testing - Detailed Explanation](https://www.softwaretestingmaterial.com/test-deliverables/)
+
+Доп. материал:
+
+* [ГОСТ Р 56922-2016/ISO/IEC/IEEE 29119-3:2013 Часть 3: “Документация тестирования”](https://docs.cntd.ru/document/1200134998)
+* [ГОСТ Р ИСО/МЭК 15910-2002: “Процесс создания документации пользователя программного средства”](https://docs.cntd.ru/document/1200030141)
+* [ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 “Описание архитектуры”](https://docs.cntd.ru/document/1200139542)
+* [Podlodka#223 - Техническая документация](https://www.youtube.com/watch?v=S8kiPiG0jW8)
+* [Пользовательская документация](https://habr.com/ru/post/542288/#:\~:text=2.%C2%A0-,%D0%9F%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F,-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D1%86%D0%B8%D1%8F)
+* [What Is Test Data? Test Data Preparation Techniques With Example](https://www.softwaretestinghelp.com/tips-to-design-test-data-before-executing-your-test-cases/)
+* [Что такое тестовая документация и зачем она нужна?](https://testengineer.ru/chto-takoe-testovaya-dokumentaciya-i-zachem-ona-nuzhna/)
+* [Шаблон улучшения](http://okiseleva.blogspot.com/2015/10/blog-post\_16.html)
diff --git a/vidy-metody-urovni-testirovaniya/README.md b/vidy-metody-urovni-testirovaniya/README.md
new file mode 100644
index 0000000..e638fc9
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/README.md
@@ -0,0 +1,3 @@
+# Виды-методы-уровни тестирования
+
+Примечание: понятие типов, методов и видов в англоязычной литературе часто не разделяется и может быть перечислено вообще вперемешку, а также зачастую там выделяют только функциональное и нефункциональное тестирование. Не зацикливайтесь на категоризации и терминологии, пытайтесь понять саму суть.
diff --git a/vidy-metody-urovni-testirovaniya/a-b-testirovanie-a-b-testing.md b/vidy-metody-urovni-testirovaniya/a-b-testirovanie-a-b-testing.md
new file mode 100644
index 0000000..c6208ca
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/a-b-testirovanie-a-b-testing.md
@@ -0,0 +1,63 @@
+# A/B тестирование (A/B Testing)
+
+Для проведения A/B Testing (split testing,bucket testing) мы создаем и анализируем два варианта чего-либо (экрана приложения, страницы сайта, элементов GUI, механики работы, воронки продаж и т.п.), чтобы найти, какой вариант работает лучше с точки зрения пользовательского опыта, потенциальных клиентов, конверсий или любой другой цели. Предположим, у нас есть интернет магазин и каталог отображается определенным образом. В какой-то момент (новые маркетинговые исследования/пожелания клиента и т. д.) решено изменить дизайн выдачи товаров в каталоге. Независимо от того, сколько проведено анализа, выпуск нового пользовательского интерфейса будет большим изменением и может иметь неприятные последствия.
+
+В этом случае мы можем использовать A / B-тестирование. Мы создадим интерфейс нового варианта и перенаправим часть трафика пользователей на него. Например - мы можем распределить пользователей в соотношении 50:50 или 80:20 между двумя вариантами - A и B. После этого в течение определенного периода времени мы будем наблюдать за статистикой и коэффициентами конверсии обоих вариантов. Таким образом, тестирование A/B помогает принять решение о выборе лучшего варианта.
+
+Исходный вариант (А) называется контроль (control), а альтернативный (B) - вариация (variation). При проведении A / B-тестирования мы получаем данные / статистику от чемпионов, претендентов и вариаций (champions, challengers, and variations). Эти версии дают представление о коэффициентах конверсии ваших посетителей.
+
+**Терминология**:
+
+* **Вариант** (Variant): разные версии веб-страниц или любой другой маркетинговый актив, может быть несколько форм одной и той же страницы с небольшими изменениями;
+* **Чемпион** (Champion): чемпионом будет веб-страница, которая хорошо работает или показывала хорошие результаты в прошлом. Обычно чемпион сравнивается с другими вариантами, и вариант с более высоким коэффициентом конверсии становится вариантом чемпиона;
+* **Претендент** (Challenger): это новый вариант вашей веб-страницы, который сравнивается с вашим существующим чемпионом;
+* **Трафик** (Traffic): он относится к пользователям, посещающим ваш сайт, и измеряется количеством пользователей, проводящих время на вашем сайте;
+* **Коэффициент конверсии** (Conversion Rate): коэффициент конверсии - это процент пользователей, которые совершают желаемое действие, запланированное на веб-сайте, например, подписываются на список рассылки для оплаты продукта, деленное на количество посетителей;
+* **Оптимизация коэффициента конверсии** (CRO - Conversion Rate Optimization): это практика оптимизации работы веб-сайта или целевой страницы на основе поведения посетителей веб-сайта. Это помогает владельцу сайта понять, как посетители сайта совершают желаемые действия (конверсии), такие как нажатие «добавить в корзину», покупка продукта, подписка на услугу, заполнение формы или нажатие на ссылку, становясь клиентов на соответствующей странице и что им мешает достичь своих целей;
+* **Гипотеза** (Hypothesis): хорошо структурированная гипотеза поможет вам понять, является ли она успешной, неудачной или неубедительной. Пример: больше людей будут нажимать кнопку, если она синяя, потому что она контрастирует с другими цветами на странице;
+* **Интуиция** (Insights): это комбинация аргументированных идей и выводов, сделанных на основе систематического сбора и анализа данных;
+* **Копирайт** (Copy): ad copy or sales copy представляет собой письменный контент, который направлен на повышение узнаваемости бренда, чтобы убедить человека или группу совершить определенное действие;
+
+**Что тестируется с помощью A/B Testing**:
+
+* **Лендинги** (Landing pages): это веб-страница, на которую пользователь попадает после нажатия на объявление, ссылку в вашей почтовой кампании или в любом другом цифровом месте. Обычно на этих одностраничниках есть четкий призыв к действию (CTA - call to action), чтобы купить продукт или просто присоединиться к вашему списку. Ваша целевая страница должна быть оптимизирована для привлечения пользователей к любому предложению, которое вы им представляете. Перед запуском A / B-тестирования для сбора данных и гипотез используйте тепловую карту, т. е. Визуальное представление внимания, вовлеченности и взаимодействий с посетителями, это поможет вам сосредоточиться на том, что требует внимания;
+* **Заголовки** (Headlines): могут иметь очень важное значение, поскольку это первое, на что смотрит любой пользователь, заходя на ваш сайт. Если ваш заголовок не привлекает их внимания, не ожидайте, что они задержатся на вашем сайте. Вы должны быть осторожны при создании copy, шрифта, размера, цвета и сообщения;
+* **Макет страницы** (Page layout): должен быть простым, но мощным, чтобы посетители могли получить к нему доступ. Достаточно правильного дизайна и макета с четкой информацией, понятным содержанием, четким призывом к действию, а также медиа, улучшающих визуальный аспект страницы. Будь то ваша домашняя страница, целевая страница, сообщение в блоге или страница с описанием продукта, убедитесь, что дизайн UI / UX не загроможден и ориентирован на конверсии;
+* **Навигация** (Navigation): посетитель должен беспрепятственно перемещаться по вашему сайту. Их не должны перегружать или сбивать с толку разные элементы вашего веб-сайта. Разместите панель навигации в верхнем левом углу и логотип вашего сайта в верхнем правом углу, нажав на нее, вы вернетесь на главную страницу. Следуйте этим основным форматам, которые используют большинство веб-сайтов, чтобы пользователь мог быстро найти то, что ищет. В худшем случае ваш посетитель заблудится на вашем сайте;
+* **Формы** (Forms): это способ получить информацию о вашем потенциальном клиенте. Формы - лучший способ связаться с вашим потенциальным клиентом. Убедитесь, что они подходящего размера. Если они слишком длинные, ваш посетитель может просто отказаться от них, если они слишком короткие, вы можете не собрать информацию, чтобы убедиться, что посетители являются потенциальными клиентами;
+* **Длина страницы, глубина содержимого** (Page length, Content depth): некоторые посетители хотели бы иметь четкий и полезный контент, в то время как некоторые посетители предпочитают контент для глубокого погружения. С помощью A / B-тестирования вы можете определить предпочтения вашей целевой аудитории и удовлетворить их потребности;
+* **Призыв к действию** (Call To Action): это самая важная вещь, которая напрямую влияет на коэффициент конверсии. CTA побуждает вашего посетителя совершить любое действие - купить ваш продукт / услугу, подписаться на рассылку электронной почты, послушать ваш подкаст, это может быть что угодно. Но на вашей странице должен быть только один призыв к действию, чтобы посетители не запутались;
+* **Медиа** (Media): играют огромную роль в вашей воронке продаж. У вас может быть канал на YouTube, подкаст, Instagram и т. д., Которые направляют вашу аудиторию на ваш сайт. Этот фото / аудио / видео контент может дать вам представление о том, сколько людей из вашей аудитории посмотрели ваш сайт и сколько из них обратилось к вашему клиенту. Таким образом, вы можете оптимизировать свой контент, чтобы привлечь трафик на ваш сайт;
+
+**Многовариантное тестирование** (Multivariate Testing): несколько элементов на странице изменяются в комбинации, она сравнивается с текущей версией веб-страницы. Цель проведения многовариантного тестирования - измерить эффективность каждой комбинации дизайна. Многовариантное тестирование дает более быстрые результаты, но может быть сложным для новичка.
+
+| A/B Testing | Multivariate Testing |
+| ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| позволяет экспериментировать с одним или несколькими вариантами веб-страницы друг против друга. | помогает вам поэкспериментировать с несколькими вариантами нескольких элементов на веб-странице одновременно |
+| Здесь ваш трафик будет разделен на две разные веб-страницы: версия A и версия B. | Здесь ваш трафик будет разделен на несколько веб-страниц с несколькими вариантами. |
+| Вам не понадобится большой трафик, чтобы попробовать это тестирование. | Для реализации многовариантного тестирования ваш сайт должен иметь огромные объемы трафика. |
+|
Пример: изменение цвета кнопки покупки.
Версия A: цвет по умолчанию
Версия B: красный цвет
|
Пример: изменение основных элементов целевой страницы.
Версия A: Headline_3, Img_2, CTA_1
Версия B: Заголовок_1, Img_3, CTA_2
Версия C: Headline_2, Img_4, CTA_1
Версия D: Headline_4, Img_1, CTA_3
|
+
+**Тестирование разделением URL** (Split URL Testing): вы создаете два или более вариантов для своей веб-страницы. Затем протестируйте эти несколько версий вашего веб-сайта по разным URL-адресам. Здесь варианты представляют собой полностью разработанные веб-страницы и хранятся на сервере, доступ к которому осуществляется через разные URL-адреса;
+
+| A/B Testing | Split URL Testing |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Это маркетинговый инструмент, позволяющий выяснить, что лучше всего работает для повышения конверсии, путем разделения трафика между контрольным и вариантом. | Это маркетинговый инструмент, позволяющий выяснить, что лучше всего работает для повышения конверсии, путем разделения трафика по разным URL-адресам. |
+| Для создания вариантов будут внесены лишь незначительные изменения в элементы в HTML. | Здесь варианты обычно представляют собой полностью разработанную веб-страницу, которая хранится на сервере и к которой можно получить доступ через другой URL-адрес. |
+| Лучше всего использовать при оптимизации отдельных веб-страниц и часто используется для проведения быстрых тестов. | Можно использовать для больших изменений, например, для новых редизайнов |
+
+**Мультистраничное тестирование** (Multi-Page Testing): При многостраничном тестировании мы экспериментируем, изменяя определенный элемент на нескольких страницах. Здесь вы должны показывать пользователям сочетание и совпадение вариантов вместо того, чтобы показывать согласованные варианты по набору страниц. Таким образом, мы можем тщательно протестировать один вариант против другого;
+
+Источник:
+
+[A/B Testing Guide: How To Perform AB Testing](https://www.softwaretestingmaterial.com/ab-testing/)
+
+Доп. материал:
+
+* [A/B тестирование как механизм улучшения продукта](https://www.youtube.com/watch?v=weHBjjlSBss)
+* [How to Do A/B Testing: A Checklist You’ll Want to Bookmark](https://medium.com/elfsight-blog/how-to-run-a-b-testing-a-checklist-youll-want-to-bookmark-99c75aa9860b)
+* [Ошибки в дизайне A/B тестов, которые я думала, что никогда не совершу](https://habr.com/ru/company/skyeng/blog/518164/)
+* [A/B Тестирование: Основы](https://habr.com/ru/company/otus/blog/546168/)
+* [Как выбрать уровень статистической значимости для AB-теста и как интерпретировать результат](https://habr.com/ru/post/554194/)
+* [Время - деньги: анализируй А/В-тесты разумно](https://habr.com/ru/company/mailru/blog/557308/)
+* [Взгляд на A/B-тестирование со стороны тестировщика](https://t.me/qa\_chillout/96)
diff --git a/vidy-metody-urovni-testirovaniya/destruktivnoe-i-nedestruktivnoe-testirovanie-dt-destructive-testing-and-ndt-non-destructive-tes.md b/vidy-metody-urovni-testirovaniya/destruktivnoe-i-nedestruktivnoe-testirovanie-dt-destructive-testing-and-ndt-non-destructive-tes.md
new file mode 100644
index 0000000..968d556
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/destruktivnoe-i-nedestruktivnoe-testirovanie-dt-destructive-testing-and-ndt-non-destructive-tes.md
@@ -0,0 +1,27 @@
+# Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
+
+_Негативное тестирование (negative testing): Тестирование, нацеленное на демонстрацию того, что система или компонент не работают. Негативное тестирование относится в большей степени к позиции тестировщика, нежели к определенному подходу к тестированию или метод проектирования тестов, например - тестирование с некорректными входными значениями или тестирование обработки исключений. (ISTQB)_
+
+**Destructive testing (негативное, Rainy day, Apocalypses day)** - тип тестирования ПО для поиска точек отказа в ПО, который проверяет систему на обработку исключительных ситуаций (срабатывание валидаторов на некорректные данные), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора. Неожиданные условия могут быть чем угодно, от неправильного типа данных до хакерской атаки. Целью Destructive testing является предотвращение сбоя приложений из-за некорректных входных данных. Просто проводя положительное тестирование, мы можем только убедиться, что наша система работает в нормальных условиях, но помимо этого мы должны убедиться, что наша система может справиться и с непредвиденными условиями. Типичные примеры: ввести неправильно составленный e-mail и номер телефона, загрузить файл не предусмотренного расширения или размера.
+
+Для деструктивного тестирования существует множество способов его проведения:
+
+* Метод анализа точек отказа: это пошаговое прохождение системы, проводящее оценку того, что может пойти не так в разных точках. Для этой стратегии может быть использована помощь BA (Business Analyst);
+* Экспертная проверка тестировщика: проанализируйте или дайте на ревью ваши Test cases коллеге-тестировщику, который менее знаком с системой/функцией ;
+* Бизнес-анализ тест-кейсов: конечные пользователи или эксперты могут подумать о многих допустимых сценариях, которые иногда тестировщики могут их не учитывать или упустить, так как все их внимание будет сосредоточено на тестировании требований;
+* Проведение предварительного тестирование с использованием контрольных таблиц (run sheets): исследовательское тестирование с использованием контрольных таблиц поможет определить, что было проверено, повторить тесты и позволит вам контролировать охват тестами;
+* Используйте другой источник: вы можете попросить кого-нибудь сломать программный продукт и проанализировать различные сценарии;
+
+**Non Destructive testing (позитивное, Happy path, Sunny Day)** - это тип тестирования программного обеспечения, который включает в себя правильное взаимодействие с ПО. Оно дает ожидаемые результаты и доказывает, что программное обеспечение ведет себя так, как ожидалось. Пример: - Ввод правильных данных в модуль входа в систему и проверка, принимает ли он учетные данные и переходит на следующую страницу
+
+Источник:
+
+[What is Destructive Testing? Methods, Techniques and Examples](https://www.guru99.com/destructive-testing.html)
+
+Доп. материал:
+
+* [Destructive Testing And Non Destructive Testing Tutorial](https://www.softwaretestinghelp.com/destructive-non-destructive-testing/)
+* [Топ 10 негативных кейсов](https://testmatick.com/ru/top-10-negativnyh-test-kejsov-ispolzuemyh-vo-vremya-testirovaniya-po/)
+* [Частное мнение: Sunny day / Rainy day / Apocalypses day testing scenarios](https://qsusha.wordpress.com/2018/04/25/%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%BE%D0%B5-%D0%BC%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-sunny-day-rainy-day-apocalypses-day-testing-scenarios/)
+* [Где граница «позитив-негатив»?](https://okiseleva.blogspot.com/2018/12/blog-post\_24.html)
+* [Негативное тестирование: что это](https://testengineer.ru/negativnoe-testirovanie-chto-ehto/)
diff --git a/vidy-metody-urovni-testirovaniya/etalonnoe-i-bazovoe-testirovanie-benchmark-and-baseline-testing.md b/vidy-metody-urovni-testirovaniya/etalonnoe-i-bazovoe-testirovanie-benchmark-and-baseline-testing.md
new file mode 100644
index 0000000..744ed35
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/etalonnoe-i-bazovoe-testirovanie-benchmark-and-baseline-testing.md
@@ -0,0 +1,35 @@
+# Эталонное и базовое тестирование (Benchmark and Baseline Testing)
+
+_Эталонный тест (benchmark test):_
+
+_(1) стандарт, согласно которому может производиться измерение или сравнение._
+
+_(2) тест, который может использоваться для сравнения компонентов или систем друг с другом_
+
+_или на соответствие стандарту, указанному в (1). (IEEE 610)_
+
+_Базовая версия (baseline): Спецификация или программный продукт, который был формально отрецензирован или согласован, впоследствии используется как базовая версия для дальнейшей разработки, и который может быть изменен только в процессе формального контроля процесса изменений. (IEEE 610)_
+
+**Эталонное тестирование** (Benchmark Testing) - это набор стандартов, метрик или контрольных точек (reference point), по которым оценивается (assessed or evaluated) качество работы продукта или услуги, через нагрузочное тестирование модуля или всей комплексной программной системы для определения ее производительности. Оно определяет повторяемый набор экспериментальных результатов, которые помогают определить функциональные возможности как для текущих, так и для будущих выпусков программного обеспечения.
+
+**Тестирование базовой версии** (Baseline Testing) - это подход к тестированию, в котором за точку отсчета берется базовая линия - это показатель конкретного ориентира, который служит основой для нового тестирования. В Baseline Testing тесты прогоняют, сохраняют все результаты и сравнивают с базовым уровнем. Этот базовый уровень относится к последним принятым результатам испытаний. Если в исходном коде есть новые изменения, то для повторного выполнения тестов необходимо сформировать текущий базовый уровень. Если последние результаты будут приняты, то текущая базовая линия станет базовой.
+
+Самым первым этапом жизненного цикла разработки программного обеспечения является сбор и анализ требований. Этот тест играет важную роль, так как в случае, если начальная фаза не протестирована должным образом, в дальнейшем могут возникнуть серьезные проблемы. Это также может повлиять на стоимость, сроки, бюджет и репутацию клиента. После того, как требование собрано бизнес-аналитиком, он обсуждает то же самое с менеджером проекта для тестирования требования и его осуществимости. В случае неясности прототип требования создается разработчиком и представляется клиенту. Если это соответствует ожиданиям клиента и одобрено, командам предоставляется документ с требованиями для начала дальнейшего процесса. На основе этого документа с требованиями создаются другие документы для разработки и тестирования программного обеспечения, такие как план проекта, проектный документ, план тестирования, тестовые примеры и т. д. Поэтому очень важно правильно выполнить базовый тест. Если документ с требованиями не подтвержден должным образом, дальнейшие документы и процессы не пройдут. После завершения тестирования начинается процесс разработки и тестирования.
+
+**Разница между Baseline и Benchmark testing**:
+
+| Benchmark testing | Baseline Testing |
+| ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
+| Метрики уже созданы для оценки производительности приложения. Оно сравнивает характеристики продукта с отраслевыми стандартами; | Метрики создаются после завершения тестирования производительности. Набор тест-кейсов запускается для сбора информации о производительности; |
+| Проводится с точки зрения бизнеса. SLA создаются на основе того же; | Выполняется на самом начальном этапе, с которого начинаются разработка, внедрение, тестирование и сравнение; |
+| Можно пользоваться для всех продуктов / программного обеспечения в организации; | Проводится для конкретных продуктов / программного обеспечения; |
+| Это состояние, в котором вы хотите достичь или превзойти то, чего вы уже достигли; | Выполняется на самом начальном этапе, с которого начинаются разработка, внедрение, тестирование и сравнение; |
+| Предназначено для измерения производительности приложения вместе с другим приложением, имеющим аналогичные функции; | Определяет производительность приложения для сравнения в будущем; |
+
+**Пороговый тест (Threshold Test)** - это тест, вставленный в Deployment Pipeline, который отслеживает некоторое измеримое явление, сравнивая значение в текущей сборке с пороговым значением. Если значение текущей сборки превышает пороговое значение, тест завершается неудачно, и сборка не выполняется. Типичный пример использования пороговых тестов - производительность. Команда берет репрезентативный набор операций и засекает их. Затем они устанавливают пороговый тест и если эти операции занимают значительное количество времени, превышающее текущее значение, тест завершается неудачей.
+
+Источники:
+
+* [What Is Benchmark Testing In Performance Testing](https://www.softwaretestinghelp.com/benchmark-testing-tutorial/)
+* [What Is Baseline Testing And Its Benefits For Software Quality](https://www.softwaretestinghelp.com/what-is-baseline-testing/#Baseline\_Vs\_Benchmark\_Testing)
+* [Threshold Test](https://martinfowler.com/bliki/ThresholdTest.html)
diff --git a/vidy-metody-urovni-testirovaniya/fazzing-testirovanie-fuzz-testing.md b/vidy-metody-urovni-testirovaniya/fazzing-testirovanie-fuzz-testing.md
new file mode 100644
index 0000000..ce504b6
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/fazzing-testirovanie-fuzz-testing.md
@@ -0,0 +1,24 @@
+# Фаззинг-тестирование (Fuzz testing)
+
+FUZZ testing (fuzzing) - это тип тестирования безопасности, который обнаруживает ошибки кодирования и лазейки в программном обеспечении, операционных системах или сетях. Фаззинг включает в себя ввод огромного количества случайных данных, называемых fuzz, в тестируемое программное обеспечение, чтобы заставить его дать сбой или прорвать его защиту. Фаззинг часто выявляет уязвимости, которые могут быть использованы с помощью SQL-инъекции, переполнения буфера, отказа в обслуживании (DOS) и XSS. Fuzz-тестирование выполняется с помощью фаззера - программы, которая автоматически вводит полуслучайные данные в программу и обнаруживает ошибки. Fuzz-тестирование обычно выполняется автоматически.
+
+Обычно fuzzing обнаруживает наиболее серьезные ошибки или дефекты безопасности. Это очень экономически эффективный метод тестирования. Fuzzing - один из самых распространенных методов хакеров, используемых для обнаружения уязвимости системы (сюда относятся популярные SQL- или скриптовые инъекции). Примеры фаззеров:
+
+* Mutation-Based Fuzzers: Этот тип фаззера проще всего создать, поскольку он изменяет существующие образцы данных для создания новых тестовых данных. Это относится к тупому фаззеру, но его можно использовать с более интеллектуальными фаззерами. Мы можем сделать это, выполнив некоторый уровень анализа образцов, чтобы гарантировать, что он изменяет только определенные части или не нарушает общую структуру ввода;
+* Generation-Based Fuzzers: Этот тип фаззера требует большего интеллекта для создания тестовых данных с нуля, т.е. новые тестовые данные создаются на основе входной модели. Обычно он разбивает протокол или формат файла на фрагменты, которые затем выстраиваются в допустимом порядке, и эти фрагменты случайным образом распределяются независимо друг от друга;
+* PROTOCOL-BASED-fuzzer: самый успешный фаззер - это детальное знание тестируемого формата протокола. Понимание зависит от спецификации. Это включает в себя запись массива спецификации в инструмент, а затем с помощью метода генерации тестов на основе модели проходится спецификация и добавляется неравномерность в содержимое данных, последовательность и т. д. Это также известно как синтаксическое тестирование, грамматическое тестирование, тестирование надежности, и т. д. Fuzzer может генерировать Test case из существующего или использовать допустимые или недействительные входные данные;
+
+Типы ошибок, обнаруживаемых Fuzz testing:
+
+* Сбои ассертов и утечки памяти (Assertion failures and memory leaks). Эта методология широко используется для больших приложений, где ошибки влияют на безопасность памяти, что является серьезной уязвимостью;
+* Некорректный ввод (Invalid input). Фаззеры используются для генерирования неверного ввода, который используется для тестирования процедур обработки ошибок, и это важно для программного обеспечения, которое не контролирует его ввод. Простой фаззинг может быть способом автоматизации отрицательного тестирования;
+* Исправление ошибок (Correctness bugs). Fuzzing также может использоваться для обнаружения некоторых типов ошибок «правильности». Например, поврежденная база данных, плохие результаты поиска и т. д.;
+
+Источники:
+
+* [Fuzz Testing Guide](https://www.softwaretestingmaterial.com/fuzz-testing/)
+* [Fuzz Testing(Fuzzing) Tutorial: What is, Types, Tools & Example](https://www.guru99.com/fuzz-testing.html)
+
+Доп. материал:
+
+[Фаззинг тестирование веб-интерфейса. Расшифровка доклада](https://habr.com/ru/company/tensor/blog/527304/)
diff --git a/vidy-metody-urovni-testirovaniya/funkcionalnoe-testirovanie-functional-behavioral-testing.md b/vidy-metody-urovni-testirovaniya/funkcionalnoe-testirovanie-functional-behavioral-testing.md
new file mode 100644
index 0000000..cb36001
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/funkcionalnoe-testirovanie-functional-behavioral-testing.md
@@ -0,0 +1,48 @@
+# Функциональное тестирование (Functional/Behavioral testing)
+
+_Функциональное тестирование (functional testing): Тестирование, основанное на анализе спецификации функциональности компонента или системы. См. также тестирование методом черного ящика. (ISTQB)_
+
+Функциональное тестирование выполняется чтобы убедиться, что каждая функция программного приложения ведет себя так, как указано в документе с требованиями. В большинстве случаев это выполняется методом black box testing.
+
+**Для функционального тестирования принято использовать две техники**:
+
+* Тестирование на основе требований: содержит все функциональные спецификации, которые составляют основу для всех тестов, которые будут проводиться;
+* Тестирование на основе бизнес-сценариев: содержит информацию о том, как система будет восприниматься с точки зрения бизнес-процесса;
+
+**Основные виды функционального тестирования**:
+
+* Unit Testing: модульное тестирование обычно выполняется разработчиком и влечет за собой написание тестов, которые будут вызывать методы в каждом модуле и проверять их, передавая требуемые параметры и проверяя соответствие возвращаемого значения ожидаемому. Покрытие кода - важная часть модульного тестирования, где должны существовать test cases, охватывающие:
+ * Line coverage;
+ * Code path coverage;
+ * Method coverage;
+* Smoke Testing: тестирование, которое проводится после выпуска каждой сборки. Это также называется build verification testing;
+* Sanity Testing: тестирование, которое проводится для того, чтобы убедиться, что все основные и жизненно важные функции приложения / системы работают правильно. Обычно это делается после Smoke Testing;
+* Regression Tests: тестирование проводится для того, чтобы убедиться, что добавление нового кода, улучшений, исправление ошибок не нарушает существующую функциональность или не вызывает нестабильности и ПО все еще работает в соответствии со спецификациями. Регрессионные тесты не должны быть такими обширными, как фактические функциональные тесты, но должны гарантировать объем покрытия, подтверждающий стабильность функциональности;
+* Integration Tests: когда система полагается на несколько функциональных модулей, которые работают по отдельности, но должны работать согласованно когда объединены вместе, чтобы достичь сквозного сценария, проверка таких сценариев называется интеграционным тестированием;
+* Beta/Usability Testing: продукт демонстрируется реальному пользователю в среде, приближенной к проду, и они тестируют продукт. Это похоже на User Acceptance testing;
+* System testing: тестирование, которое выполняется для всей системы, чтобы проверить, работает ли она должным образом после интеграции всех модулей или компонентов;
+* End to end testing: проводится для проверки функциональности продукта. Это тестирование выполняется только после завершения тестирования системной интеграции, включая функциональные и нефункциональные требования;
+
+**Критерии начала функционального тестирования**:
+
+* Requirement Specification document определен и утвержден;
+* Подготовлены тест-кейсы;
+* Созданы тестовые данные;
+* Среда для тестирования готова, все необходимые инструменты доступны и готовы;
+* Всё или часть приложения разработано, модульно протестировано и готово к тестированию;
+
+**Критерии окончания функционального тестирования**:
+
+* Выполнение всех функциональных тестов завершено;
+* Нет критических или открытых ошибок P1, P2;
+* Сообщенные ошибки были подтверждены;
+
+**Этапы функционального тестирования**:
+
+* Самый первый шаг заключается в определении функциональности продукта, который необходимо протестировать, и он включает в себя тестирование основных функций, условий ошибок и сообщений, тестирование удобства использования, то есть, является ли продукт удобным для пользователя или нет, и т. д.
+* Следующим шагом является создание входных данных для проверяемой функциональности в соответствии со спецификацией требований.
+* Позже, из спецификации требований, определяется результат для тестируемой функциональности.
+* Подготовленные тест-кейсы исполняются.
+* Фактический результат, то есть результат после выполнения тест-кейса, и ожидаемый результат (определенный из спецификации требований) сравниваются, чтобы определить, работает ли функциональность должным образом или нет.
+
+Источник: [Complete Functional Testing Guide With Its Types And Example](https://www.softwaretestinghelp.com/guide-to-functional-testing/)
diff --git a/vidy-metody-urovni-testirovaniya/installyacionnoe-testirovanie-installation-testing.md b/vidy-metody-urovni-testirovaniya/installyacionnoe-testirovanie-installation-testing.md
new file mode 100644
index 0000000..74efee7
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/installyacionnoe-testirovanie-installation-testing.md
@@ -0,0 +1,56 @@
+# Инсталляционное тестирование (Installation Testing)
+
+_Тестирование устанавливаемости (installability testing): Тип тестирования переносимости для оценки того, могут ли должным образом элемент тестирования или совокупность элементов тестирования быть установлены во всех указанных средах. (ГОСТ 56920)_
+
+Тестирование инсталляции (установки) направлено на проверку успешной установки, настройки, обновления и удаления ПО, как десктопного, так и мобильного.
+
+**Примеры кейсов**:
+
+**Установка**.
+
+* Установка должна начаться при клике по кнопке, подтверждающей данное действие;
+* Установки во всех поддерживаемых окружениях и на всех поддерживаемых платформах;
+* Установки в неподдерживаемых окружениях, а также в нужных окружениях с некорректными настройками;
+* Права, которые требует инсталляция (чаще всего они должны быть админскими), проверить установить приложение как гость;
+* Установки в clean state (при отсутствии любых возможных связанных файлов и предыдущих версий);
+* Подсчитывается ли при установке количество свободного места на диске и выдается ли предупреждение если места недостаточно;
+* Установки загруженного ранее приложения, а также прямая установка с использованием сети/беспроводного соединения;
+* Восстановится ли процесс установки при внезапном его прерывании (отключение устройства, отказ сети, отключение беспроводного соединения);
+* Установка приложения, его запуск, удаление приложения должны возвращать систему в исходное состояние;
+* Распознается ли наличие в системе приложений/программ, необходимых для корректной работы устанавливаемого приложения;
+* Повторный запуск установки приложения при уже текущем должен выдавать корректное сообщение, двойная установка должна быть исключена;
+* Процесс установки может быть настраиваемый/дефолтный. Убедиться, что оба корректно работают
+* Наличие кнопки, которая предложит сохранить приложение в определенную папку, а также указывает дефолтное местоположение (“C:/programs/.”);
+* Правильно ли установлены, сохранены ли в корректных папках файлы приложения;
+* Наличие созданных ярлыков, корректно ли они расположены;
+* После установки в системной вкладке “ Программы и компоненты” должны быть доступны: название приложения, иконка, имя издателя, размер приложения, дата установки и номер версии;
+* Настройки переменных сред PATH;
+* Убедиться, что лицензионный ключ сохраняется в Windows Registry library;
+* Поддерживает ли приложение функции ‘UnInstall’, ‘Modify’, ‘ReInstall’ и корректно ли они работают;
+* Работа приложения с уже существующими DLL-файлами, с DLL-файлами приложений, которые необходимы для корректной работы устанавливаемого приложения;
+* Наличие информации/сообщение о том, когда истекает срок действия установленной пробной версии приложения;
+
+**Обновление**:
+
+* Поддерживает ли приложение функцию обновления/автообновления;
+* При попытке установить ранее установленную версию приложения система должна ее распознать и выдать корректное сообщение;
+* Сохраняются ли пользовательские настройки при попытке загрузить новую версию/обновить старую версию;
+* При попытке обновить версию должны быть доступны функции удалить приложение и восстановить приложение;
+* Стандартные проверки как при первичной установке приложения;
+* Убедиться, что номер версии приложения сменился новым;
+* Запустить приложение и убедиться, что оно работает корректно;
+
+**Откат до предыдущей версии**:
+
+* Попробовать установить старую версию на более новую;
+* Наличие корректного сообщения при попытке отката;
+* Убедиться, что приложение работает корректно;
+
+**Удаление приложения**:
+
+* Не остается ли в системе никаких папок/файлов/ярлыков/ключей реестра после полного удаления приложения;
+* Корректно ли работает система после установки и последующего удаления приложения;
+
+Источник:
+
+[Тестирование инсталляции](https://qaevolution.ru/testirovanie-installyacii/)
diff --git a/vidy-metody-urovni-testirovaniya/integracionnoe-testirovanie-integration-testing.md b/vidy-metody-urovni-testirovaniya/integracionnoe-testirovanie-integration-testing.md
new file mode 100644
index 0000000..02a004e
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/integracionnoe-testirovanie-integration-testing.md
@@ -0,0 +1,110 @@
+# Интеграционное тестирование (Integration testing)
+
+_Интеграционное тестирование (integration testing): Тестирование, выполняемое для обнаружения дефектов в интерфейсах и во взаимодействии между интегрированными компонентами или системами. См. также тестирование интеграции компонентов, системное интеграционное тестирование. (ISTQB)_
+
+_Системное интеграционное тестирование (system integration testing): Тестирование интеграции систем и пакетов программ, тестирование интерфейсов связи с внешними системами (интернет и т.д.). (ISTQB)_
+
+_Интеграционное тестирование в малом (integration testing in the small): См. тестирование интеграции компонентов. (ISTQB)_
+
+_Интеграционное тестирование в целом (integration testing in the large): См. системное интеграционное тестирование. (ISTQB)_
+
+_Изоляционное тестирование (isolation testing): Тестирование отдельных компонентов в изоляции от окружающих компонентов в окружении компонентов, которые при необходимости эмулируются заглушками и драйверами. (ISTQB)_
+
+_Попарное интеграционное тестирование (pairwise integration testing): Вид интеграционного тестирования, нацеленного на пары компонентов, работающих совместно соответственно графу вызовов. (ISTQB)_
+
+Интеграционное тестирование предназначено для проверки насколько хорошо два или более компонента ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). С технологической точки зрения интеграционное тестирование является количественным развитием компонентного, поскольку также оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки (Stub) на месте отсутствующих модулей. Основная разница между компонентным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. В частности, на уровне интеграционного тестирования часто применяются методы, связанные с покрытием интерфейсов, например, вызовов функций или методов, или анализ использования интерфейсных объектов, таких как глобальные ресурсы, средства коммуникаций, предоставляемых операционной системой.
+
+**Уровни интеграционного тестирования**:
+
+* **Компонентный интеграционный уровень** (CIT - [Component Integration testing](https://www.testing.guru/what-is-component-integration-testing/)): Проверяется взаимодействие между компонентами одной системы после проведения компонентного тестирования. Программные компоненты или модули могут быть определены в разное время совершенно разными группами спецификаций, component integration testing выполняется чтобы убедиться, что даже после различий в разработке модулей интеграция всего работает вместе. В этом случае также важно учесть отрицательные случаи, так как компоненты могут делать предположения относительно данных;
+* **Системный интеграционный уровень** (SIT - [System Integration testing](https://www.softwaretestinghelp.com/system-integration-testing/)): - это полное тестирование всей системы, состоящей из множества подсистем. Основная цель SIT - обеспечить правильное функционирование всех зависимостей программных модулей и сохранение целостности данных между отдельными модулями всей системы. SUT ([System Under Test](https://www.tutorialspoint.com/software\_testing\_dictionary/system\_under\_test.htm)) может состоять из аппаратного обеспечения, базы данных, программного обеспечения, комбинации аппаратного и программного обеспечения или системы, требующей взаимодействия с человеком (HITL - [Human in the Loop](https://en.wikipedia.org/wiki/Human-in-the-loop) Testing). SIT имеет предварительное условие, при котором несколько базовых интегрированных систем уже прошли системное тестирование. Затем SIT проверяет необходимые взаимодействия между этими системами в целом. Результаты SIT передаются в UAT (пользовательское приемочное тестирование);
+
+**Интеграция может быть как программной, так и софт-железо**:
+
+* **HSIT** - Hardware Software Integration Testing: представляет собой процесс тестирования компонентов компьютерного программного обеспечения (CSC - Computer Software Components) на предмет функциональности высокого уровня в целевой аппаратной среде. Тестирование черного ящика - это основной тип тестирования, используемый на этом уровне тестирования. Целью тестирования интеграции аппаратного / программного обеспечения является проверка поведения разработанного программного обеспечения, интегрированного в аппаратный компонент. Цель тестирования интеграции аппаратного и программного обеспечения на основе требований (Requirement based Hardware-Software Integration Testing) - убедиться, что программное обеспечение на целевом компьютере удовлетворяет высокоуровневым требованиям (high-level requirements);
+* **SSIT** - Software Software Integration Testing: это Computer Software Component Testing, работающего в среде целевого компьютера при моделировании всей системы (других CSC), и на функциональности высокого уровня. Оно фокусируется на поведении CSC в смоделированной среде хоста / цели. Для проверки интеграции программного обеспечения используются разные подходы;
+
+**Подходы к интеграционному тестированию**:
+
+* **Подход Большого взрыва (Big Bang Approach)**: _“Вид подхода к интеграционному тестированию, при котором элементы программного или аппаратного обеспечения, или и то и другое, собираются в компонент или в целую систему сразу, а не по этапам.” ( IEEE 610)_. Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если Test case и их результаты записаны неверно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования;
+* **Инкрементальный подход (Incremental Approach)**: при таком подходе тестирование выполняется путем объединения двух или более логически связанных модулей. Затем другие связанные модули поэтапно добавляются и тестируются для правильного функционирования. Процесс продолжается до тех пор, пока все модули не будут соединены и успешно протестированы. Осуществляется разными методами:
+ * **Нисходящий подход (Top-Down Approach)**: Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Преимущества: Локализация неисправностей проще. Возможность получить ранний прототип. Основные недостатки дизайна могут быть найдены и исправлены в первую очередь. Недостатки: Нужно много заглушек. Модули на более низком уровне тестируются недостаточно;
+ * **Восходящий подход (Bottom-Up Approach)**: В восходящей стратегии каждый модуль на более низких уровнях последовательно тестируется с более высокоуровневыми модулями, пока не будут протестированы все модули. Требуется помощь драйверов для тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения. Пример низкоуровневого модуля - модуль, который заведует хранением токенов авторизации. Высокоуровневый - модуль авторизации, в состав которого помимо прочего входит модуль токенов. Преимущества: Локализация ошибок проще. Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва. Недостатки: Критические модули (на верхнем уровне архитектуры ПО), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам. Ранний прототип невозможен;
+ * [**Гибридный/сэндвич-подход**](https://www.ques10.com/p/38806/describe-bi-directionalsandwitch-integration-testi/) **(Sandwich/Hybrid/Bi-Directional Approach)**: Представляет собой комбинацию восходящего и нисходящего подходов. Здесь целью является средний слой, в то время как драйверы заменяют верхний слой, а заглушки нижний пока компоненты этих слоев не будут разработаны;
+
+**Критерии начала и окончания Integration Testing**:
+
+Обычно при выполнении интеграционного тестирования используется стратегия [ETVX](https://vijaybn.wordpress.com/2012/09/06/etvx-entry-task-validation-exit/) (Entry Criteria, Task, Validation, Exit Criteria).
+
+* Критерии начала:
+ * завершено модульное тестирование;
+* На входе:
+ * Software Requirements Data;
+ * Software Design Document;
+ * Software Verification Plan;
+ * Software Integration Documents;
+* Действия:
+ * На основе требований высокого и низкого уровня (High and Low-level requirements) создайте test cases and procedures;
+ * Комбинируйте сборки низкоуровневых модулей, которые реализуют общую функциональность;
+ * Разработайте тестовую обвязку (test harness);
+ * Протестируйте сборку;
+ * После прохождения теста сборка объединяется с другими сборками и тестируется до тех пор, пока система не будет интегрирована как единое целое;
+ * Повторите все тесты на целевой processor-based platform и получите результаты;
+* Критерии выхода:
+ * Успешное завершение интеграции Программного модуля на целевое Hardware;
+ * Правильная работа программного обеспечения в соответствии с указанными требованиями;
+* На выходе:
+ * Integration test reports;
+ * SVCP - Software Test Cases and Procedures;
+
+[_Test Harness_](https://www.softwaretestinghelp.com/what-is-test-harness/)_- (тестовая обвязка): Тестовое окружение, включающее в себя заглушки и драйверы, необходимые для проведения теста. (ISTQB)_
+
+[Test Driver и Test Stub](https://www.geeksforgeeks.org/difference-between-stubs-and-drivers/) являются искусственными заменами компонентов программы на время тестов по аналогии с моками в тестировании API. Тестовый драйвер - то, что вызывает тестируемый компонент. Тестовая заглушка - то, что возвращает тестируемому компоненту фиктивный ответ. Т.е. заглушки и драйверы не реализуют всю логику программного модуля, а только моделируют обмен данными с тестируемым модулем.
+
+[**Тестирование интерфейса**](https://www.softwaretestinghelp.com/what-is-interface-testing/) - это тип интеграционного теста, который проверяет, правильно ли установлена связь между двумя различными программными системами или их частями (модулями). Соединение, которое объединяет два компонента, называется интерфейсом. Этот интерфейс в компьютерном мире может быть чем угодно, как API, так и веб-сервисами и т. д. Тестирование интерфейса включает в себя тестирование двух основных сегментов:
+
+* Интерфейс веб-сервера и сервера приложений
+* Интерфейс сервера приложений и базы данных
+
+**Тестирование потоков (Thread testing)** - это вид тестирования программного обеспечения, который проверяет основные функциональные возможности конкретной задачи (потока). Обычно проводится на ранней стадии фазы интеграционного тестирования. Тестирование на основе потоков является одной из дополнительных стратегий, принятых в ходе System Integration Testing. Поэтому его, вероятно, следует более правильно назвать «тестом взаимодействия потоков» (thread interaction test).
+
+Thread Testing подразделяется на две категории:
+
+* Однопоточное тестирование (Single thread testing) включает одну транзакцию приложения за раз;
+* Многопоточное тестирование (Multi-thread testing) включает одновременно несколько активных транзакций;
+
+Как проводить Thread Testing:
+
+* Тестирование на основе потоков является обобщенной формой тестирования на основе сеансов (session-based testing), в котором сеансы являются формой потока, но поток не обязательно является сеансом;
+* Для тестирования потока, поток или программа (небольшая функциональность) интегрируются и тестируются постепенно как подсистема, а затем выполняются для всей системы;
+* На самом низком уровне оно предоставляет интеграторам лучшее представление о том, что тестировать;
+* Вместо непосредственного тестирования программных компонентов требуется, чтобы интеграторы сосредоточились на тестировании логических путей выполнения в контексте всей системы;
+
+Советы:
+
+* Протестируйте свою многопоточную программу, многократно выполняя ее с другим набором запущенных приложений;
+* Протестируйте свою многопоточную программу, активировав одновременно несколько экземпляров программы;
+* Выполняйте многопоточную программу на разных моделях оборудования с различными уровнями нагрузки и рабочими нагрузками;
+* Инспекция кода;
+* Собирайте только ошибки и сбои, которые произошли в потоках, отличных от основного;
+
+Источники:
+
+* [Integration Testing](https://www.guru99.com/system-integration-testing.html)
+* [Лекция 5: Модульное и интеграционное тестирование](https://intuit.ru/studies/courses/48/48/lecture/1432)
+* [What is Thread Testing in Software Testing?](https://www.guru99.com/thread-testing.html)
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “D.4 Подпроцесс интеграционного тестирования”
+* [Ручное интеграционное тестирование в банковском секторе. Что внутри?](https://habr.com/ru/post/595379/)
+* [Интеграционные тесты в микросервисах](https://tproger.ru/articles/integracionnye-testy-v-mikroservisah/)
+* [Лекция 6: Интеграционное тестирование и его особенности для объектно-ориентированного программирования](https://intuit.ru/studies/courses/48/48/lecture/1434)
+* [Для чего нужно интеграционное тестирование?](https://habr.com/ru/post/556002/)
+* [Component / System integration testing examples](https://www.scnsoft.com/software-testing/integration-testing-example)
+* [#11 Артем и Сева. Моки(Mocks) и стабы(Stubs)](https://www.youtube.com/watch?v=VbVcGpS8HV4\&ab\_channel=Heisenbug)
+* [Mocks Aren't Stubs](https://martinfowler.com/articles/mocksArentStubs.html)
+* [Почему мы решили создать отдел кросс-системного тестирования](https://habr.com/ru/company/mvideo/blog/559542/)
+* [Кто такой кросс-системный тестировщик и почему он не должен быть «agile»?](https://habr.com/ru/company/mvideo/blog/560030/)
+* [What Is Thread Testing In Software Testing](https://www.softwaretestinghelp.com/what-is-thread-testing/)
+* [Юнит-тесты vs интеграционные тесты](https://testengineer.ru/unit-testy-vs-integracionnye-testy/)
diff --git a/vidy-metody-urovni-testirovaniya/issledovatelskoe-testirovanie-exploratory-testing.md b/vidy-metody-urovni-testirovaniya/issledovatelskoe-testirovanie-exploratory-testing.md
new file mode 100644
index 0000000..d938c69
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/issledovatelskoe-testirovanie-exploratory-testing.md
@@ -0,0 +1,53 @@
+# Исследовательское тестирование (Exploratory testing)
+
+_Исследовательское тестирование (exploratory testing): Неформальный метод проектирования тестов, при котором тестировщик активно контролирует проектирование тестов в то время, как эти тесты выполняются, и использует полученную во время тестирования информацию для проектирования новых и улучшенных тестов. (Bach)_
+
+_Исследовательское тестирование (exploratory testing): Тестирование, основанное на опыте, при котором тестер спонтанно разрабатывает и выполняет тестирования на основе существующих соответствующих знаний тестера, предшествующих исследований элемента тестирования (включая и результаты предыдущих тестирований) и эвристических "эмпирических правил" для общего поведения программного обеспечения и типов отказа. Примечание - Исследовательское тестирование направлено на выявление скрытых свойств (включая и скрытое поведение), которые сами по себе, с одной стороны, вполне возможно, безобидны, но, с другой стороны, могут повлиять на другие свойства тестируемого программного обеспечения и тем увеличить риск того, что программное обеспечение перестанет работать. (ГОСТ 56920)_
+
+Исследовательское Тестирование - одновременно является и техникой, и видом тестирования. В общем виде мы так или иначе всегда используем комбинацию сценарного и исследовательского подходов. Exploratory testing подразумевает под собой одновременно изучение проекта, функционала, тест-дизайн в уме и тут же исполнение тестов, после чего данный цикл может повторяться необходимое количество раз, каждый раз улучшая создаваемые кейсы и документируя пройденные сессии.
+
+Джеймс Бах указал на важную характеристику исследовательского тестирования - тестировщик участвует когнитивно. Он активно, целенаправленно, с любопытством исследует тестируемое программное обеспечение, всегда принимая на себя ответственность каждую минуту решать, какой путь к тому, что он выбрала для исследования, является наиболее многообещающим. Нет никаких искусственных ограничений на разведку. Тестировщик может свободно использовать любые доступные источники информации, включая спецификации, записи службы технической поддержки, реализации сопоставимого программного обеспечения конкурентами и (конечно) эксперименты (тесты), которые эмпирически раскрывают информацию. Нет никаких ограничений на методы тестирования, которые могут использовать исследователи - например, любая степень автоматизации подойдет. Однако исследователь не просто перезапускает старые тесты, а тестирует чтобы учиться. Вероятно, он будет внимательно изучать поведение программы во время ее тестирования, ища новые идеи о том, как она может выйти из строя, как ее можно было бы в дальнейшем протестировать или измерить, и насколько полезны эти тесты на данном этапе разработки. Выполнение тестов можно автоматизировать, а мышление - нет. Антитезой исследования является тестирование по сценарию, в котором тестировщик (или машина) следует набору процедур, изложенных давно, сравнивая наблюдаемое поведение с любыми результатами, которые разработчик тестов считал актуальными или интересными в то время. Познание произошло тогда, а не сейчас. Объем исследования такой же, как и объем самого тестирования. Разница в том, что исследователь выполняет их в любой полезной последовательности, смешивая исследование, дизайн, выполнение, интерпретацию и общение, чтобы постоянно открывать новую информацию и идти в ногу с текущими изменениями на рынке, платформе, дизайне и реализации тестируемого программного обеспечения.
+
+**Подход к тестированию**:
+
+* Используйте эвристики для управления тестированием;
+* Выполнение и создание тест-кейсов идут рука об руку;
+* Тест-кейсы продолжают развиваться на основе наблюдений и обучения тестировщиков;
+* К ET могут применяться различные методы тестирования, такие как анализ граничных значений, классы эквивалентности и т. д.;
+* ET можно использовать сессионно , чтобы сделать его более структурированным и сфокусированным;
+* Тестировщики могут развивать свои идеи, но никогда не отклоняться от своей миссии;
+* Тестирование ET не использует сценарии, а зависит от интуиции, навыков и опыта тестировщика;
+
+**Туры в исследовательском тестировании**: Чтобы систематизировать исследовательское тестирование можно использовать идею туров. Туры - это идеи и инструкции по исследованию программного продукта, объединенные определенной общей темой или целью. Туры, как правило, ограничены по времени - длительность тестовой сессии не должна превышать 4 часа. Идею туров развивали в своих работах Канер, Бах, Хендриксон, Болтон, Кохл и другие. Джеймс Виттакер (James A. Whittaker), хоть и не придумал саму идею туров, но предложил свой подход к исследовательскому тестированию с использованием туров и в своей книге “Exploratory Software Testing” в доступной форме озвучил идею туров и описал сами туры.
+
+Тур - это своего рода план тестирования, он отражает основные цели и задачи, на которых будет сконцентрировано внимание тестировщика во время сессии исследовательского тестирования. При этом Виттакер использует метафору, что тестировщик - это турист, а тестируемое приложение - это город. Обычно у туриста (тестировщика) мало времени, поэтому он выполняет конкретную задачу в рамках выбранного тура, ни на что другое не отвлекаясь. Город (ПО) разбит на районы: деловой центр, исторический район, район развлечений, туристический район, район отелей, неблагополучный район.
+
+
+
+Источники:
+
+* [What Is Exploratory Testing In Software Testing (A Complete Guide)](https://www.softwaretestinghelp.com/what-is-exploratory-testing/)
+* [BBST - Exploratory Testing](http://www.testingeducation.org/BBST/exploratory/)
+* [Исследовательское тестирование и исследовательские туры Виттакера](https://www.software-testing.by/blog/exploratory-testing-exploratory-tours/)
+
+Доп. материал:
+
+* [Rapid Software Testing Methodology](https://www.satisfice.com/rapid-testing-methodology)
+* [Exploratory Testing](https://www.satisfice.com/exploratory-testing)
+* [Sample test cases of Exploratory Testing of the IRCTC website](https://www.softwaretestinghelp.com/wp-content/qa/uploads/2019/12/IRCTC-Exploratory-Testing.xlsx)
+* [Exploratory Testing an Indispensable Nonsystematic Software Testing Technique](https://www.softwaretestinggenius.com/exploratory-testing-an-indispensable-nonsystematic-software-testing-technique/)
+* [Исследовательское тестирование: пустая трата времени или мощный инструмент?](https://habr.com/ru/post/535094/)
+* [Исследовательское тестирование - полезно или вредно для проекта?](https://www.youtube.com/watch?v=wNOGbU5bcvI)
+* [Exploratory Testing](http://www.testingeducation.org/BBST/exploratory/BBSTExploring.pdf)
+* [Exploratory Testing Dynamics](https://silo.tips/download/exploratory-testing-dynamics)
+* [A Tutorial in Exploratory Testing](https://www.kaner.com/pdfs/QAIExploring.pdf)
+* [Plan your next exploratory testing session](https://medium.com/@cristina.mtys/tips-for-your-next-exploratory-testing-session-22b4421b9620)
+* [Исследовательское тестирование - обезьянья работа?](https://telegra.ph/Issledovatelskoe-testirovanie--obezyanya-rabota-04-22-2)
+* [Exploratory Testing](https://martinfowler.com/bliki/ExploratoryTesting.html)
+* [How To Use Tours To Ensure Complete And Thorough Exploratory Testing](https://www.softwaretestinghelp.com/exploratory-testing-tours/)
+* [Туры в исследовательском тестировании. Личный перевод из книги Д. Виттакера «Исследовательское тестирование ПО»](https://habr.com/ru/post/328990/)
+* [Переводы туров для исследовательского тестирования](https://www.software-testing.ru/library/testing/testing-for-beginners/2965-exploratory-software-testing)
+* [Туры в исследовательском тестировании](https://telegra.ph/Tury-v-issledovatelskom-testirovanii-07-23)
+* [Множество способов поговорить об исследовательском тестировании](https://software-testing.ru/library/testing/other-testing/3717-there-are-plenty-of-ways-to-talk-about)
+* [Исследовательские сценарии как метод раскрытия преступления](https://www.youtube.com/watch?v=S1VNifFxYy4)
+* [Вспомнить всё... о контекстном тестировании](https://www.youtube.com/watch?v=JSSnOvNFDLU)
diff --git a/vidy-metody-urovni-testirovaniya/kak-protestirovat-produkt-bez-trebovanii.md b/vidy-metody-urovni-testirovaniya/kak-protestirovat-produkt-bez-trebovanii.md
new file mode 100644
index 0000000..73861f4
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/kak-protestirovat-produkt-bez-trebovanii.md
@@ -0,0 +1,8 @@
+# Как протестировать продукт без требований?
+
+Продукта без требований не существует, просто они могут быть не формализованы и не записаны. Если вам дали протестировать какое-то готовое решение, к которому нет документации, то нужно попытаться восстановить все явные и неявные требования: изучив функционал (какую проблему решает продукт? для чего его создали?), целевую аудиторию (для кого его создали?), попытаться найти тех, кто мог знать что-то и уже не в команде; список источников получения неявных требований вообще огромен. На основе всего этого уже как минимум можно составить user stories для покрытия основными тестами.
+
+Доп. материал:
+
+* [Тестирование без требований. Где искать требования к продукту, если отсутствует ТЗ?](https://telegra.ph/Testirovanie-bez-trebovanij-Gde-iskat-trebovaniya-k-produktu-esli-otsutstvuet-TZ-04-13)
+* [Testing without requirements](https://testzius.wordpress.com/2016/12/13/testing-without-requirements/)
diff --git a/vidy-metody-urovni-testirovaniya/konfiguracionnoe-testirovanie-configuration-testing.md b/vidy-metody-urovni-testirovaniya/konfiguracionnoe-testirovanie-configuration-testing.md
new file mode 100644
index 0000000..fbcdfbb
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/konfiguracionnoe-testirovanie-configuration-testing.md
@@ -0,0 +1,43 @@
+# Конфигурационное тестирование (Configuration testing)
+
+Конфигурационное тестирование (Configuration testing) - специальный вид тестирования, направленный на проверку работы ПО при различных аппаратных и программных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д.).
+
+**Configuration =** performance + compatibility:
+
+* performance аспект: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы;
+* compatibility аспект: проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм;
+
+**Уровни конфигурационного тестирования** для клиент-серверных приложений (для некоторых типов приложений может быть актуален только один):
+
+* Серверный: Основной упор здесь делается на тестирование с целью определения оптимальной конфигурации оборудования, удовлетворяющего требуемым характеристикам качества (эффективность, портативность, удобство сопровождения, надежность). Тестируется взаимодействие выпускаемого ПО с окружением, в которое оно будет установлено:
+ * Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т. д.);
+ * Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т. д.);
+* Клиентский: ПО тестируется с позиции его конечного пользователя и конфигурации его рабочей станции. На этом этапе будут протестированы следующие характеристики: удобство использования, функциональность. Для этого необходимо будет провести ряд тестов с различными конфигурациями рабочих станций:
+ * Тип, версия и битность операционной системы (подобный вид тестирования называется кроссплатформенное тестирование);
+ * Тип и версия Web браузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование);
+ * Тип и модель видеоадаптера (при тестировании игр это очень важно);
+ * Работа приложения при различных разрешениях экрана;
+ * Версии драйверов, библиотек и т. д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки);
+
+**Prerequisites**:
+
+* создать матрицу покрытия (Coverage Matrix, BCM - Basic Configuration Matrix - это таблица, в которую заносят все возможные конфигурации);
+* провести приоритезацию конфигураций (на практике, скорее всего, все желаемые конфигурации проверить не получится);
+* шаг за шагом, в соответствии с расставленными приоритетами, проверять каждую конфигурацию;
+
+Уже на начальном этапе становится очевидно, что чем больше требований к работе приложения при различных конфигурациях рабочих станций, тем больше тестов нам необходимо будет провести. В связи с этим, рекомендуем, по возможности, автоматизировать этот процесс, так как именно при конфигурационном тестировании автоматизация реально помогает сэкономить время и ресурсы. Конечно же автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником.
+
+**Примечание**: в ISTQB вообще не говорится о таком виде тестирования как конфигурационное:\
+“configuration testing: See portability testing.”\
+**Тестирование переносимости** (Portability testing) - _тип тестирования, проводимого для оценки простоты переноса элемента тестирования из одних аппаратных средств или программной среды в другие, включая уровень его изменений, необходимых для выполнения в средах различных типов. (ГОСТ 56920)._ Результаты тестирования, полученные в результате тестирования переносимости, помогают выяснить, насколько легко программный компонент из одной среды можно использовать в другой среде. Термин «среда» относится к переходу от одной операционной системы к другой, от одного браузера к другому или от одной версии базы данных к другой версии базы данных. Измерение переносимости - это усилия, необходимые для перемещения программного компонента из одной среды в другую. Одна единица измерения переносимости - это стоимость адаптации программного обеспечения к новой среде по сравнению со стоимостью повторной разработки программного обеспечения. Переносимость может включать в себя Installability, Adaptability, Replaceability, Compatibility or Coexistence, Interoperability, Localization.
+
+**Portability vs. Compatibility**:
+
+* Совместимость касается того, могут ли два или более компонента работать в одной и той же среде одновременно, не влияя отрицательно на поведение друг друга. Пример: можно сказать, что текстовый процессор и калькулятор, работающие в одной ОС, такой как Windows 10, совместимы друг с другом, поскольку запуск одного приложения не повлияет на поведение другого приложения;
+* Переносимость касается перемещения компонента из одной среды в другую. Пример: игра, работающая в Windows XP, считается переносимой, если та же игра может быть запущена в Windows 7 без каких-либо изменений в ее поведении;
+* Проще говоря, тестирование переносимости касается программного компонента в разных средах, в то время как тестирование совместимости касается тестирования разных приложений в одной среде;
+
+Источники:
+
+* [Configuration Testing Tutorial With Examples](https://www.softwaretestinghelp.com/what-is-configuration-testing/)
+* [Portability Testing Guide With Practical Examples](https://www.softwaretestinghelp.com/what-is-portability-testing/)
diff --git a/vidy-metody-urovni-testirovaniya/krossbrauzernoe-testirovanie-cross-browser-testing.md b/vidy-metody-urovni-testirovaniya/krossbrauzernoe-testirovanie-cross-browser-testing.md
new file mode 100644
index 0000000..757262c
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/krossbrauzernoe-testirovanie-cross-browser-testing.md
@@ -0,0 +1,41 @@
+# Кроссбраузерное тестирование (Cross-browser testing)
+
+Кроссбраузерное тестирование - вид тестирования, направленный на поддержку и правильное полное отображение программного продукта в разных браузерах, мобильных устройствах, планшетах, экранах различного размера. Это нормально, если сайт выглядит немного по-разному в разных браузерах, главное он должен обеспечивать полную функциональность и доступность (accessibility). Приложения и сайты в разных браузерах могут вести себя по-разному. Это связано с тем, что любой из браузеров имеет собственные движки, надстройки, плагины, а также различия в десктопной и мобильной версиях.
+
+Приступать к тестированию сайта в популярных браузерах следует уже после того как он проверен на дефекты другими видами тестирования. Только в этом случае можно будет сказать, что выявленные некорректные сценарии имеют отношение именно к особенностям браузера, а не были пропущены на других стадиях. Разумеется, при этом ошибка должна проявляться не во всех браузерах.
+
+После этого нужно приоритезировать список необходимых браузеров, ОС и платформ исходя из статистики пользователей текущей версии сайта или статистики по целевым регионам.
+
+Вы должны попытаться протестировать его на реальных физических устройствах, где это возможно. Если у вас нет средств для тестирования всех этих различных комбинаций браузеров, операционных систем и устройств на физическом оборудовании, вы также можете использовать эмуляторы (эмулировать устройство с помощью программного обеспечения на вашем настольном компьютере) и виртуальные машины (программное обеспечение, которое позволяет вам эмулировать несколько комбинаций операционной системы/программного обеспечения на вашем настольном компьютере). Это очень популярный выбор, особенно в некоторых случаях - например, Windows не позволяет одновременно устанавливать несколько версий Windows на одну машину, поэтому использование нескольких виртуальных машин часто является единственным вариантом. Наконец, вы можете стать умнее при тестировании, используя инструменты аудита или автоматизации; это разумный выбор по мере того, как ваши проекты становятся больше, поскольку выполнение всего этого тестирования вручную может занять очень много времени. Вы можете настроить собственную систему автоматизации тестирования (популярным приложением является Selenium), которая может, например, загружать ваш сайт в различных браузерах. Вы также можете пойти дальше, если хотите. Существуют коммерческие инструменты, такие как Sauce Labs, Browserstack, LambdaTest, TestingBot и CrossBrowserTesting, которые делают это за вас, не беспокоясь о настройке, если вы хотите вложить деньги в тестирование.
+
+Также часто бывает полезно протестировать предварительные версии браузеров.
+
+**Cross-browser Testing Checklist**
+
+* Функциональное тестирование;
+* Специальные возможности (accessibility);
+* Проверка CSS;
+* Проверка HTML или XHTML;
+* Проверка страницы с включенным JavaScript и без него;
+* Функциональность Ajax и JQuery;
+* Проверка размера шрифта;
+* Макет страницы в разных разрешениях;
+* Все изображения и выравнивание;
+* Разделы верхнего и нижнего колонтитула;
+* Выравнивание содержимого страницы по центру, по левому или правому краю;
+* Стили страницы;
+* Форматы даты;
+* Специальные символы с кодировкой HTML;
+* Функция увеличения и уменьшения масштаба страницы.
+
+Источники:
+
+* [Кроссбраузерное тестирование: цели и задачи](https://luxhard.com/krossbrauzernoe-testirovanie-tseli-i.html)
+* [Top 10 Cross Browser Testing Tools In 2022 (Latest Ranking)](https://www.softwaretestinghelp.com/best-cross-browser-testing-tools-to-ease-your-browser-compatibility-testing-efforts/)
+
+Доп. материал:
+
+* [Why Cross Browser Testing is Important](https://www.mindfulqa.com/cross-browser-testing/)
+* [Ликбез по браузерам для Windows в 2020](https://habr.com/ru/post/518834/)
+* [Comparison of web browsers](https://en.wikipedia.org/wiki/Comparison\_of\_web\_browsers)
+* [Live cross browser testing. Running Microsoft Edge and Android with Selenoid](https://www.youtube.com/watch?v=ZwnbuLCZYU4)
diff --git a/vidy-metody-urovni-testirovaniya/metody-testirovaniya-white-black-grey-box.md b/vidy-metody-urovni-testirovaniya/metody-testirovaniya-white-black-grey-box.md
new file mode 100644
index 0000000..e94c688
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/metody-testirovaniya-white-black-grey-box.md
@@ -0,0 +1,8 @@
+# Методы тестирования (White/Black/Grey Box)
+
+Самым высоким уровнем в иерархии подходов к тестированию будет понятие метода. Некоторые виды тестирования могут выполняться методом как черного ящика, так и белого. Если упростить, то отличаются они знанием внутреннего устройства объекта тестирования.
+
+Доп. материал:
+
+* [Черный, белый, серый ящик. Методы тестирования / Урок 11 / Тестировщик с нуля](https://www.youtube.com/watch?v=AqoMSfErDSE)
+* [What is red box, yellow box and green box testing?](https://stackoverflow.com/questions/3620990/what-is-red-box-yellow-box-and-green-box-testing)
diff --git a/vidy-metody-urovni-testirovaniya/modulnoe-yunit-komponentnoe-testirovanie-module-unit-component-testing.md b/vidy-metody-urovni-testirovaniya/modulnoe-yunit-komponentnoe-testirovanie-module-unit-component-testing.md
new file mode 100644
index 0000000..67a3606
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/modulnoe-yunit-komponentnoe-testirovanie-module-unit-component-testing.md
@@ -0,0 +1,59 @@
+# Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
+
+С этими терминами часто происходит путаница. Если ссылаться на глоссарий ISTQB, то все они - синонимы:
+
+* _**Модуль, юнит (module, unit): См. компонент.**_
+* _**Модульное, юнит тестирование (module testing, unit testing): См. компонентное тестирование.**_
+* _**Компонент (component): Наименьший элемент программного обеспечения, который может быть протестирован отдельно.**_
+* _**Компонентное тестирование (component testing): Тестирование отдельных компонентов программного обеспечения (IEEE 610).**_
+
+Тем не менее, некоторые источники описывают ситуацию несколько иначе и я решил выписать другую точку зрения.
+
+**Модульное тестирование (оно же юнит-тестирование)** используется для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками. Целью тестирования модуля является не демонстрация правильного функционирования модуля, а демонстрация наличия ошибки в модуле, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования. Изоляция тестируемого блока достигается с помощью заглушек (stubs), манекенов (dummies) и макетов (mockups).
+
+**Компонентное тестирование** - тип тестирования ПО, при котором тестирование выполняется для каждого отдельного компонента отдельно, без интеграции с другими компонентами. Его также называют модульным тестированием (Module testing), если рассматривать его с точки зрения архитектуры. Как правило, любое программное обеспечение в целом состоит из нескольких компонентов. Тестирование на уровне компонентов (Component Level testing) имеет дело с тестированием этих компонентов индивидуально. Это один из самых частых типов тестирования черного ящика, который проводится командой QA. Для каждого из этих компонентов будет определен сценарий тестирования, который затем будет приведен к Test case высокого уровня -> детальным Test case низкого уровня с предварительными условиями.
+
+Исходя из глубины уровней тестирования, компонентное тестирование можно классифицировать как:
+
+* Тестирование компонентов в малом (CTIS - Component testing In Small): тестирование компонентов может проводиться с или без изоляции остальных компонентов в тестируемом программном обеспечении или приложении. Если это выполняется с изоляцией другого компонента, то это называется CTIS;
+* Тестирование компонентов в целом (CTIL - Component testing In Large) - тестирование компонентов, выполненное без изоляции других компонентов в тестируемом программном обеспечении или приложении;
+
+| **Module/Unit testing** | **Component testing** |
+| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
+| Тестирование отдельных классов, функций для демонстрации того, что программа выполняется согласно спецификации | Тестирование каждого объекта или частей программного обеспечения отдельно с или без изоляции других объектов |
+| Проверка в(на) соответствии с design documents | Проверка в(на) соответствии с test requirements, use case |
+| Пишутся и выполняются разработчиками | Тестировщиками |
+| Выполняется первым | Выполняется после Unit |
+
+Другой источник:
+
+По-существу эти уровни тестирования представляют одно и тоже, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном/unit тестировании - конкретные значения.
+
+\*В контексте юнит-тестирования еще можно встретить понятие [golden testing](https://ro-che.info/articles/2017-12-04-golden-tests). Оно означает те же юнит тесты, но с ожидаемыми результатами хранящимися в отдельном файле. Таким образом после прогона выходные значения тестов сравниваются с golden (эталонным) файлом.
+
+\*Иногда юнит-тесты называют одинокими (solitary) в случае тотального применения имитаций и заглушек или общительными (sociable) в случае реальных коммуникаций с другими участниками.
+
+\*Правило трех А(AAA) (arrange, act, assert) или триада «дано, когда, тогда» - хорошая мнемоника, чтобы поддерживать хорошую структуру тестов.
+
+Источники:
+
+* [What is Component Testing? Techniques, Example Test Cases](https://www.guru99.com/component-testing.html)
+* [Лекция 5: Модульное и интеграционное тестирование](https://intuit.ru/studies/courses/48/48/lecture/1432)
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “D.11 Подпроцесс покомпонентного тестирования”
+* [Я сомневался в юнит-тестах, но…](https://habr.com/ru/company/skyeng/blog/521324/)
+* [Юнит-тесты переоценены](https://habr.com/ru/company/qiwi/blog/510608/)
+* [Elliotte Rusty Harold - Effective Unit Testing](https://www.youtube.com/watch?v=QYj7MLumImM\&ab\_channel=Heisenbug)
+* [Kevlin Henney - What we talk about when we talk about unit testing](https://www.youtube.com/watch?v=-WWIeXmm4ec\&ab\_channel=Heisenbug)
+* [Андрей Сербин - Компонентное тестирование инфраструктуры](https://www.youtube.com/watch?v=hRg\_HKB4Fbc\&ab\_channel=Heisenbug)
+* [Анатомия юнит тестирования](https://habr.com/ru/post/507594/)
+* [Unit Test](https://martinfowler.com/bliki/UnitTest.html)
+* [Component Test](https://martinfowler.com/bliki/ComponentTest.html)
+* [Анатомия юнит-теста](https://habr.com/ru/post/554808/)
+* [Почему большинство юнит тестов - пустая трата времени? (перевод статьи)](https://habr.com/ru/post/557824/)
+* [Unit Testing Guide](https://www.softwaretestingmaterial.com/unit-testing/)
+* [Лекция 2: Тестирование программного кода (методы+окружение)](https://intuit.ru/studies/courses/1040/209/lecture/5385)
+* [Starting to Unit Test: Not as Hard as You Think](https://www.amazon.com/Starting-Unit-Test-Hard-Think-ebook/dp/B00KIZ6JAC/)
+* [6 оправданий для того, чтобы не писать юнит-тесты](https://testengineer.ru/opravdaniya-dlya-togo-chtoby-ne-pisat-yunit-testy/)
diff --git a/vidy-metody-urovni-testirovaniya/mozhno-li-otnesti-testirovanie-bezopasnosti-ili-nagruzochnoe-testirovanie-k-funkcionalnym-vidam-test.md b/vidy-metody-urovni-testirovaniya/mozhno-li-otnesti-testirovanie-bezopasnosti-ili-nagruzochnoe-testirovanie-k-funkcionalnym-vidam-test.md
new file mode 100644
index 0000000..24ee79d
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/mozhno-li-otnesti-testirovanie-bezopasnosti-ili-nagruzochnoe-testirovanie-k-funkcionalnym-vidam-test.md
@@ -0,0 +1,15 @@
+# Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
+
+Данные виды принято относить к нефункциональным видам тестирования, однако если конкретно безопасность или производительность является основным функционалом приложения, а не его атрибутами, то можно отнести и к функциональным. Как пример я бы привел программу-шифровальщик флешки (можно обсудить в коммьюнити, накидают вариантов).
+
+_Есть функциональное требование: “Пользователь должен иметь возможность перевести деньги со своей карты на другую карту по номеру"._
+
+_Это функциональное требование (ну, на самом деле это целая тонна требований, но обобщим их до одной user story)._
+
+_Оно отвечает на вопрос "какие операции должен уметь выполнять сервис"._
+
+_К этой функциональности может предъявляться еще куча требований - по безопасности, по скорости, по отказоустойчивости, и т.д. Они описывают то, КАК система должна работать, а не ЧТО она должна уметь._
+
+_\_Нефункциональные требования могут быть критичными, могут блокировать выпуск той или иной функциональности. Но это все еще свойство фичи, а не какая-то самостоятельная ее функция._
+
+_В то же время, есть, например, функциональные требования безопасности, типа "автоматически блокировать транзакции обладающие характеристиками А, Б, В". (с)_ [azshoo](https://t.me/qajuniors/253022)
diff --git a/vidy-metody-urovni-testirovaniya/nagruzochnoe-testirovanie-load-testing.md b/vidy-metody-urovni-testirovaniya/nagruzochnoe-testirovanie-load-testing.md
new file mode 100644
index 0000000..3dd4a4f
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/nagruzochnoe-testirovanie-load-testing.md
@@ -0,0 +1,65 @@
+# Нагрузочное тестирование (Load testing)
+
+_Нагрузочное тестирование (load testing): Вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимально допустимого уровня нагрузки для исследуемого компонента или системы. (ISTQB)_
+
+_Нагрузочное тестирование (load testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при ожидаемых условиях переменной нагрузки, обычно для ожидаемых условий низкого, типичного и пикового использования. (ГОСТ 56920)_
+
+Нагрузочное тестирование - это тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе. Этот подвид тестирования производительности выполняется для диагностики поведения системы при увеличении рабочей нагрузки.
+
+Пример. Предположим, что требование нашего клиента для страницы входа составляет 2-5 секунд, и эти 2-5 секунд должны быть всегда, пока нагрузка не достигнет 5000 пользователей, а также если количество пользователей постепенно увеличивается, то сколько ЦП, памяти будет потребляться, каково состояние сети, время отклика, пропускная способность и т.д.
+
+
+
+**Подход к нагрузочному тестированию**:
+
+**Определите критерии приемки нагрузочного теста**. Например:
+
+* Время отклика страницы входа не должно превышать 5 секунд даже в условиях максимальной нагрузки;
+* Загрузка ЦП не должна превышать 80%;
+* Пропускная способность системы должна составлять 100 транзакций в секунду;
+
+**Определите бизнес-сценарии, которые необходимо протестировать**. Не тестируйте все потоки, постарайтесь понять основные business flows, которые, как ожидается, будут происходить в производственной среде. Если это уже существующее приложение, мы можем получить информацию из логов. Если это новое приложение, нам нужно работать с бизнес-группами, чтобы понять закономерности потока, использование приложения и т. д. Иногда команда проекта проводит семинары, чтобы дать обзор или подробности о каждом компоненте приложения;
+
+**Моделирование рабочей нагрузки**. Получив подробную информацию о бизнес-потоках, шаблонах доступа пользователей и количестве пользователей, нам нужно спроектировать рабочую нагрузку таким образом, чтобы она имитировала фактическую навигацию пользователя в производственной среде или как она ожидается в будущем, когда приложение будет в производстве. Ключевые моменты, которые следует помнить при разработке модели рабочей нагрузки, - это увидеть, сколько времени потребуется для завершения конкретного бизнес-потока. Здесь нам нужно назначить время обдумывания (think time) таким образом, чтобы пользователь мог более реалистично перемещаться по приложению. Схема рабочей нагрузки обычно будет с нарастанием, спадом и устойчивым состоянием (Ramp up, Ramp down and a steady state).
+
+
+
+Устойчивое состояние обычно представляет собой одночасовое испытание под нагрузкой с нарастанием 15 минут и замедлением 15 минут.
+
+**Пример модели рабочей нагрузки**: Предположим, что это интернет-магазин, где пользователи войдут в приложение и получат широкий выбор платьев для покупок и могут перемещаться по каждому продукту. Чтобы просмотреть подробную информацию о каждом продукте, им нужно щелкнуть по продукту. Если им нравится цена и качество продукта, они могут добавить его в корзину и купить продукт, выполнив проверку и произведя оплату. Список сценариев:
+
+* Обзор - здесь пользователь запускает приложение, входит в приложение, просматривает различные категории и выходит из приложения;
+* Обзор, Просмотр продукта, Добавить в корзину - здесь пользователь входит в приложение, просматривает различные категории, просматривает сведения о продукте, добавляет продукт в корзину и выходит из системы;
+* Обзор, просмотр продукта, добавление в корзину и оформление заказа - в этом сценарии пользователь входит в приложение, просматривает различные категории, просматривает сведения о продукте, добавляет продукт в корзину, оформляет заказ и выходит из системы;
+* Обзор, Просмотр продукта, Добавить в корзину, Оформить заказ и произвести оплату - здесь пользователь входит в приложение, просматривает различные категории, просматривает сведения о продукте, добавляет продукт в корзину, оформляет заказ, производит оплату и выходит из системы.
+
+| Business Flow | Количество транзакций | Виртуальная пользовательская нагрузка | Время отклика (сек) | % Допустимая частота отказов | Транзакций в час |
+| ------------- | --------------------- | ------------------------------------- | ------------------- | ---------------------------- | ---------------- |
+| 1 | 17 | 1600 | 3 | Менее 2% | 96000 |
+| 2 | 17 | 200 | 3 | Менее 2% | 12000 |
+| 3 | 18 | 120 | 3 | Менее 2% | 7200 |
+| 4 | 20 | 80 | 3 | Менее 2% | 4800 |
+
+Приведенные выше значения были получены на основе следующих расчетов: Транзакций в час = Количество пользователей \* Транзакции, совершенные одним пользователем за один час. Количество пользователей = 1600. Общее количество транзакций в сценарии просмотра = 17. Время отклика для каждой транзакции = 3. Общее время, за которое один пользователь совершил 17 транзакций = 17 \* 3 = 51, округленное до 60 секунд (1 мин). Транзакций в час = 1600 \* 60 = 96000 Транзакций.
+
+1. Дизайн / разработка нагрузочных тестов - Нагрузочный тест должен быть разработан с использованием данных, которые мы уже собрали, то есть бизнес-потоков, количества пользователей, пользовательских шаблонов, показателей, которые необходимо собрать и проанализировать. Более того, тесты должны быть максимально реалистичными.
+2. Выполнение нагрузочного теста - перед тем, как мы выполним нагрузочный тест, убедитесь, что приложение запущено и работает. Среда нагрузочного тестирования готова. Приложение функционально протестировано и работает стабильно. Проверьте параметры конфигурации среды нагрузочного тестирования. Она должна быть такой же, как и в производственной среде. Убедитесь, что доступны все тестовые данные. Не забудьте добавить необходимые метрики для отслеживания производительности системы во время выполнения теста. Всегда начинайте с небольшой нагрузки и постепенно увеличивайте ее. Никогда не начинайте работу с полной нагрузкой.
+3. Анализ результатов нагрузочного теста - имейте baseline test, чтобы всегда сравнивать его с другими тестами. Соберите метрики и журналы сервера после запуска теста, чтобы найти узкие места. Некоторые проекты используют инструменты мониторинга производительности приложений для мониторинга системы во время тестового запуска, эти инструменты APM (Application Performance Monitoring) помогают легче определить основную причину и сэкономить много времени.
+4. Отчетность - после завершения тестового прогона соберите все показатели и отправьте сводный отчет теста соответствующей группе со своими наблюдениями и рекомендациями.
+
+Источники:
+
+* [Load Testing Complete Guide For Beginners](https://www.softwaretestinghelp.com/load-testing/)
+* [Do you really know all types of Performance Tests (Non-Functional Tests)?](https://perfmatrix.blogspot.com/2017/01/type-of-performance-test.html)
+* [Нагрузочное тестирование игровых серверов](https://habr.com/ru/company/vk/blog/572742/)
+* [Методология и практика нагрузочного тестирования. Опыт Miro](https://habr.com/ru/company/miro/blog/573338/)
+* [Нагрузочное тестирование сайта на Microsoft Azure](https://habr.com/ru/post/578192/)
+* [Стенд для нагрузочного тестирования: от DEV до PROD](https://habr.com/ru/company/rtlabs/blog/577580/)
+* [Поговорим о нагрузочном тестировании](https://habr.com/ru/company/veeam/blog/578942/)
+* [Как не надо проводить нагрузочное тестирование](https://xwizard-test.blogspot.com/2015/01/blog-post\_30.html)
+* [Планируем нагрузочное тестирование](https://testengineer.ru/planiruem-nagruzochnoe-testirovanie/)
+* [Нагрузочное тестирование X5 QA meetup #2](https://www.youtube.com/watch?v=apDoQM6Ys1k)
+
+Доп. материал:
+
+* [Профиль нагрузочного тестирования. С чего начать?](https://www.youtube.com/watch?v=KOdmFxyB\_Ok)
diff --git a/vidy-metody-urovni-testirovaniya/nefunkcionalnoe-testirovanie-non-functional-testing.md b/vidy-metody-urovni-testirovaniya/nefunkcionalnoe-testirovanie-non-functional-testing.md
new file mode 100644
index 0000000..8f1184e
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/nefunkcionalnoe-testirovanie-non-functional-testing.md
@@ -0,0 +1,73 @@
+# Нефункциональное тестирование (Non-Functional testing)
+
+Нефункциональное тестирование проводится для проверки нефункциональных требований приложения, таких как производительность, безопасность, совместимость, надежность, удобство использования и т. д. В большинстве случаев это выполняется методом black box testing. Оно проверяет, соответствует ли поведение системы требованиям по всем аспектам, не охваченные функциональным тестированием. В нашем повседневном тестировании много внимания уделяется функциональному тестированию и функциональным требованиям и клиенты также заинтересованы в выполнении функциональных требований, которые напрямую связаны с функциональностью приложения, но когда ПО выходит на рынок и используется реальными конечными пользователями, у них есть шансы столкнуться с проблемами. Эти проблемы не связаны с функциональностью системы, но могут негативно повлиять на пользовательский опыт.
+
+**Нефункциональные требования могут быть отражены как**:
+
+* Пользовательские / Технические истории (User /Technical Stories): запись нефункциональных требований в виде пользовательской истории такая же, как и запись любых других требований. Единственная разница между пользователем и технической историей заключается в том, что пользовательская история требует обсуждения и имеет видимость (? visibility);
+* В критериях приемки (Acceptance criteria): это точка, которая определяется для принятия продукта заказчиком. Нефункциональное требование должно быть включено в критерии приемки, но иногда невозможно проверить нефункциональные требования с каждой историей, то есть с каждой итерацией. Следовательно, требования следует добавлять или тестировать только с соответствующей итерацией;
+* В артефактах (Artifact): для нефункциональных требований следует подготовить отдельный артефакт, это, в свою очередь, поможет лучше понять, что нужно тестировать и как это можно делать в итерациях;
+
+**Документ подхода к тестированию (Approach Document)**:
+
+Разработайте конкретный подход к этапу тестирования, уточнив общую стратегию тестирования. Этот подход к тестированию помогает при планировании и выполнении всех задач тестирования:
+
+* Объем испытаний (Test Scope);
+* Метрики тестирования;
+* Инструменты тестирования;
+* Основные даты и результаты;
+
+**Виды нефункционального тестирования (список не полный)**:
+
+* Тестирование производительности (Performance Testing)
+* Нагрузочное тестирование (Load Testing)
+* Стрессовое тестирование (Stress Testing)
+* Объемное тестирование (Volume Testing)
+* Тестирование восстановления (Recovery Testing)
+* Тестирование отказоустойчивости (Failover Testing)
+* Тестирование эффективности (Efficiency Testing)
+* Тестирование аварийного восстановления (Disaster Recovery Testing)
+* Тестирование установки (Installation Testing)
+* Тестирование документации (Documentation Testing)
+* Тестирование на удобство использования (Usability Testing)
+* Тестирование графического интерфейса пользователя (User Interface Testing)
+* Тестирование совместимости (Compatibility Testing)
+* Тестирование обслуживаемости (Maintainability Testing)
+* Тестирование безопасности (Security Testing)
+* Тестирование масштабируемости (Scalability Testing)
+* Тестирование выносливости (Endurance Testing)
+* Тестирование надежности (Reliability Testing)
+* Тестирование соответствия (Compliance Testing)
+* Тестирование локализации (Localization Testing)
+* Тестирование интернационализации (Internationalization Testing)
+* Тестирование переносимости (Portability Testing)
+* Тестирование на основе базового уровня (Baseline Testing)
+
+**Примеры чек-листов**:
+
+Тестирование производительности:
+
+* Время отклика (The response time) приложения, то есть сколько времени требуется для загрузки приложения, за какое время любой ввод, предоставленный приложению, обеспечивает вывод, время обновления браузера и т. д.;
+* Пропускную способность (Throughput) следует проверять по количеству транзакций, завершенных во время нагрузочного теста;
+* Настройка среды (Environment) должна быть такой же, как и в реальной среде, иначе результаты не будут такими же;
+* Время процесса (Process time) - такие действия, как импорт и экспорт Excel, любые вычисления в приложении должны быть протестированы;
+* Совместимость (Interoperability) должна быть проверена, т.е. программное обеспечение должно иметь возможность взаимодействовать с другим программным обеспечением или системами;
+* Необходимо проверить время ETL, то есть время, затраченное на извлечение, преобразование и загрузку данных из одной базы данных в другую;
+* Необходимо проверить возрастающую нагрузку (Load) на приложение;
+
+Тестирование безопасности:
+
+* Аутентификация (Authentication): только достоверный пользователь может войти в систему;
+* Авторизация (Authorized): пользователь должен иметь возможность входить в те модули, для которых он авторизован или к которым пользователю был предоставлен доступ;
+* Пароль: Требование пароля должно быть подтверждено, т.е. пароль должен соответствовать тому, как это требование определяется, то есть длине, специальным символам, числам и т. д.;
+* Тайм-аут: если приложение неактивно, оно должно истечь по таймауту в указанное время;
+* Резервное копирование данных: резервное копирование данных должно быть выполнено в указанное время и данные должны быть скопированы в безопасное место;
+* Внутренние ссылки на веб-приложение не должны быть доступны, если размещены непосредственно в браузере;
+* Вся коммуникация должна быть зашифрована;
+
+Тестирование документации:
+
+* Пользовательская и системная документация;
+* Документы для учебных целей;
+
+Источник: [A Complete Non-Functional Testing Guide For Beginners](https://www.softwaretestinghelp.com/what-is-non-functional-testing/)
diff --git a/vidy-metody-urovni-testirovaniya/obemnoe-testirovanie-volume-testing.md b/vidy-metody-urovni-testirovaniya/obemnoe-testirovanie-volume-testing.md
new file mode 100644
index 0000000..802c3ac
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/obemnoe-testirovanie-volume-testing.md
@@ -0,0 +1,33 @@
+# Объемное тестирование (Volume testing)
+
+_Объемное тестирование (volume testing): Тип тестирования уровня производительности, проводимого для оценки способности элемента тестирования обработать определенные объемы данных (обычно равных или близких к максимальным указанным потенциальным возможностям) с точки зрения потенциальных возможностей пропускной способности, емкости памяти или того и другого. (ГОСТ 56920)_
+
+Объемное тестирование (также flood testing) предназначено для прогнозирования того, может ли система / приложение обрабатывать большой объем данных в плане проверки объема данных, обрабатываемых базой данных. Это тестирование сосредоточено на наполнении БД продукта в реальных сценариях использования, отслеживании производительности приложения при различных объемах БД. Обычно продолжительность проверки объема составляет 1 час или время, необходимое для обработки n записей; оно может варьироваться в зависимости от вашего SLA / требований.
+
+
+
+**Причины для проведения этого тестирования**:
+
+* Самая основная потребность - проанализировать производительность вашей системы при увеличивающемся объеме данных. Создание огромного объема данных поможет вам понять производительность вашей системы с точки зрения времени отклика, потери данных и т. д.;
+* Выявление проблем, которые могут возникнуть с огромными данными, а также пороговой точки (threshold point);
+* За пределами устойчивой или пороговой точки (то есть при сбое БД) система перестает отвечать на запросы или появляются таймауты;
+* Реализация решений по перегрузке БД и даже их проверка;
+* Выявление крайней точки вашей БД (которая не может быть исправлена), за которой система выйдет из строя, и, следовательно, необходимо принять меры предосторожности;
+* В случае наличия более одного сервера БД, выявление проблем с коммуникациями между БД;
+
+**Примеры тест-кейсов**:
+
+* Добавление данных может быть выполнено успешно и отражено ли оно в приложении или на веб-сайте;
+* Удаление данных может быть выполнено успешно и отражается ли оно в приложении или на веб-сайте;
+* Обновление данных может быть выполнено успешно, и отражается ли оно в приложении или на веб-сайте;
+* Отсутствуют потери данных и вся информация отображается в приложении или на веб-сайте должным образом;
+* Время ожидания приложения или веб-страниц не истекло из-за большого объема данных;
+* При большом объеме данных нет сообщений о крешах;
+* Данные не перезаписаны и отображаются соответствующие предупреждения;
+* Другие модули вашего веб-сайта или приложения не завершают работу аварийно или не работают по таймауту из-за большого объема данных;
+* Время отклика базы данных находится в допустимом диапазоне;
+
+Источники:
+
+* [Volume Testing Tutorial: Examples And Volume Testing Tools](https://www.softwaretestinghelp.com/what-is-volume-testing/)
+* [Do you really know all types of Performance Tests (Non-Functional Tests)?](https://perfmatrix.blogspot.com/2017/01/type-of-performance-test.html)
diff --git a/vidy-metody-urovni-testirovaniya/ocenka-uyazvimosti-zashishennosti-vulnerability-assessment.md b/vidy-metody-urovni-testirovaniya/ocenka-uyazvimosti-zashishennosti-vulnerability-assessment.md
new file mode 100644
index 0000000..5c3a0e7
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/ocenka-uyazvimosti-zashishennosti-vulnerability-assessment.md
@@ -0,0 +1,130 @@
+# Оценка уязвимости/защищенности (Vulnerability Assessment)
+
+**Уязвимость** - это любые ошибки или недостатки в процедурах безопасности системы, разработке, реализации или любом внутреннем контроле, которые могут привести к нарушению политики безопасности системы.
+
+**Оценка уязвимости** - это процесс оценки рисков безопасности в программной системе с целью уменьшения вероятности угрозы. Целью оценки уязвимости является снижение возможности несанкционированного доступа для злоумышленников (хакеров).
+
+Анализ проникновения зависит от двух механизмов, а именно от оценки уязвимости и тестирования на проникновение (VAPT - Vulnerability Assessment and Penetration testing).
+
+**Классификация уязвимостей**:
+
+* Уязвимость оборудования - это недостатки, возникающие из-за проблем с оборудованием, таких как чрезмерная влажность, пыль и незащищенное хранение оборудования;
+* Уязвимость программного обеспечения. Недостаток в методике разработки проекта, несоответствующее тестирование и отсутствие своевременного аудита активов приводят к уязвимости программного обеспечения;
+* Уязвимость сети: из-за использования открытых сетевых подключений, незащищенной сетевой архитектуры и слабого канала связи возникают проблемы этого типа;
+* Физическая уязвимость: если система расположена в зоне, подверженной сильному дождю, наводнению, нестабильному электроснабжению и т. д., тогда она подвержена физической уязвимости;
+* Уязвимость организации: эта уязвимость возникает из-за использования несоответствующих инструментов безопасности, правил аудита и ошибок в административных действиях;
+
+**Наиболее распространенные уязвимости** сетевой безопасности:
+
+* **USB-накопители**. Использование USB-накопителей - самый обычный способ воздействия на любую сетевую систему и даже брандмауэр не сможет остановить вирусную атаку, поскольку они используются между многими компьютерами для обмена большим объемом информации и могут переносить большие объемы данных внутри себя. USB-накопители, зараженные вирусами, такими как червь, автоматически устанавливаются в ОС и подключаются к USB-порту, поскольку большая часть ОС по умолчанию позволяет запускать эти программы.
+
+ Способ устранения: мы можем остановить автоматическую установку их в ОС, изменив настройки по умолчанию в операционных системах, и можем сделать их более безопасными от вирусных атак с USB-накопителей.
+* **Ноутбуки**. Такие устройства, как лэптопы и ноутбуки очень удобны и портативны, оснащены всеми новейшими драйверами, ОС и имеют порт Ethernet, через который их можно легко подключить к любой сетевой системе. Ноутбуки очень небезопасны с точки зрения организации, ноутбук сотрудника содержит конфиденциальные данные, такие как зарплата сотрудника, адрес, контактная информация, личные данные, важная база данных компании, личные банковские пароли и т. д. Любая организация не может допустить утечки всей этой информации, так как это повлияет на бизнес, и организация может пострадать от бизнес-потерь.
+
+ Способ устранения: все конфиденциальные и важные данные должны храниться в зашифрованном виде, чтобы третьи лица не могли легко получить к ним доступ. Права доступа к базе данных должны быть ограничены. В дополнение к этому, должен быть включен только порт LAN, а все остальные порты должны быть отключены администратором.
+* **Разные USB-устройства**. Помимо флэш-накопителей USB, в сети присутствуют некоторые другие устройства, которые могут считывать и хранить данные в них и могут подвергнуть вашу систему уязвимости. Зараженные этим вирусом устройства, такие как цифровая камера, принтер, сканер, MP3-плеер и т. д., вступят в контакт с вашей системой через порт USB и могут нанести вред вашей сетевой системе.
+
+ Способ устранения: установите такие политики, которые могут контролировать автоматический запуск программ порта USB в вашей системе.
+* **Оптические носители**. Оптические носители являются носителями важных пакетов данных, которыми обмениваются в сетевой системе WAN для связи на большие расстояния. Следовательно, данные по этим ссылкам также могут быть пропущены или использованы не по назначению третьей стороной в интересах кого-то другого, как в случае с USB-устройствами.
+
+ Способ устранения: руководство должно ввести такие политики и правила контроля активов, которые могут отслеживать и контролировать неправомерное использование данных.
+* **Электронная почта**. Электронная почта является наиболее распространенным источником связи внутри организации или между различными организациями в деловых целях. Любая компания использует электронную почту для отправки и получения данных. Но электронной почтой чаще всего злоупотребляют, так как ее легко переслать кому угодно. Кроме того, иногда электронные письма содержат вирусы, которые могут узнать учетные данные целевого хоста, а затем хакер может легко получить доступ к электронной почте этого сотрудника организации из любого места. Они также могут использовать его для другого несанкционированного доступа.
+
+ Способ устранения: использование политик безопасности электронной почты и частая смена паролей системы через определенный промежуток времени - лучшее решение для этого.
+* **Смартфоны и другие цифровые устройства**. Смартфоны и другие планшетные устройства могут работать как компьютер в дополнение к выполнению различных задач, таких как интеллектуальные вызовы, видеозвонки, большой объем памяти, камера с высоким разрешением и огромная система поддержки приложений. Риск утечки конфиденциальных данных также высок, поскольку сотрудник организации, использующий смартфон, может щелкнуть изображение секретного бизнес-предложения или расценок и может отправить их любому, кто пользуется мобильной сетью 4G.
+
+ Способ устранения: необходимо внедрить политики, которые могут контролировать доступ к устройству при входе в среду сетевой системы и выходе из нее.
+* **Слабая безопасность учетных данных**: использование слабых паролей в сетевой системе легко подвергает сеть различным вирусным атакам.
+
+ Способ устранения: пароль, используемый для сетевой безопасности, должен быть надежным, как уникальная комбинация буквенно-цифровых символов и символов. Кроме того, нельзя использовать один и тот же пароль в течение длительного времени, необходимо регулярно менять системный пароль для получения лучших результатов.
+* **Плохая конфигурация и использование устаревшего брандмауэра**: брандмауэр играет очень важную роль в процессе управления сетевой безопасностью. Если администратор неправильно настроит брандмауэр на различных уровнях сети, она станет уязвимой для атак. Помимо этого, программный патч брандмауэра должен постоянно обновляться для правильного функционирования брандмауэра. Использование устаревшего оборудования и программного обеспечения брандмауэра бесполезно.
+
+ Способ устранения: Регулярное обновление программного обеспечения межсетевого экрана и правильная реализация.
+
+**Этапы оценки уязвимости:**
+
+* **Сбор данных**: первым шагом оценки является сбор всех необходимых данных, касающихся ресурсов, используемых в системе, таких как IP-адреса системы, используемые носители, используемое оборудование, тип антивируса, используемого системой, и т. д.;
+* **Выявление возможных сетевых угроз**: теперь, имея входные данные, мы можем определить возможные причины и лазейки сетевых угроз в сети, которые могут нанести вред нашей системе. Здесь нам также необходимо определить риски и приоритетность угроз (The impact of Risk, The threshold of Risk, Risk strategy, business impact);
+* **Анализ паролей маршрутизаторов и WI-FI**: необходимо проверить, что пароли, используемые для входа в маршрутизатор, и пароль, используемый для доступа в Интернет, достаточно надежны, чтобы их было сложно взломать. Кроме того, здесь важно убедиться, что пароль меняется через регулярные промежутки времени, чтобы система стала более устойчивой к атакам;
+* **Анализ стойкости (strength) сети организации**: Следующим шагом является оценка стойкости сети системы по отношению к обычным атакам, включая распределенную атаку типа «отказ в обслуживании» (DDoS), атаку «человек посередине» (MITM) и сетевое вторжение. Это, в свою очередь, даст нам четкое представление о том, как наша система будет реагировать в случае этих атак, и способна ли она спастись или нет;
+* **Оценка безопасности сетевых устройств**: теперь проанализируйте реакцию сетевых устройств, таких как коммутатор, маршрутизатор, модем и ПК, на сетевые атаки. Здесь будет подробно рассказываться о реакции устройств со ссылкой на угрозы;
+* **Сканирование на выявленные уязвимости**: последний шаг оценки - сканирование системы на предмет известных угроз и уязвимостей, которые уже присутствуют в сети. Это делается с помощью различных инструментов сканирования;
+* **Создание отчета**: Очень важна документация по процессу оценки уязвимости сети. Она должна содержать все действия, выполненные от начала до конца, и угрозы, обнаруженные во время тестирования, а также процесс их устранения;
+* **Повторное тестирование**: следует постоянно проверять и анализировать систему на предмет новых возможных угроз и атак и принимать все возможные меры для их смягчения;
+
+Процесс оценки уязвимости выступает в качестве входных данных для политики сетевой безопасности (network security policy).
+
+**Классификации сканеров уязвимостей:**
+
+**По типу активов/ресурсов (assets):**
+
+* **Сетевые сканеры** (Network-based scanners). Вы можете использовать сетевые сканеры для обнаружения неавторизованных устройств или неизвестных пользователей в сети. Эти сканеры позволяют сетевым администраторам определять, существуют ли в сети скрытые лазейки по периметру, такие как несанкционированный удаленный доступ. Сетевые сканеры не имеют прямого доступа к файловой системе. Таким образом, они не могут проводить проверки безопасности низкого уровня;
+* **Хост-сканеры** (Host-based scanners). Как следует из названия, сканер на основе хоста находится на каждом хосте в отслеживаемой сети. Он обнаруживает и идентифицирует уязвимости на рабочих станциях, серверах или других сетевых узлах, обеспечивая большую видимость настроек конфигурации ваших активов;
+* **Сканеры приложений** (Application scanners). Сканеры приложений находят уязвимости на веб-сайтах. Их режим работы аналогичен режиму работы поисковых систем - они «ползут» по веб-сайтам, отправляя ряд зондов на каждую веб-страницу на веб-сайте, чтобы найти слабые места;
+* **Сканеры беспроводной сети** (Wireless network scanners). Сканеры беспроводных сетей, также называемые анализаторами беспроводных протоколов (wireless protocol analyzers), представляют собой инструменты, которые вы можете использовать для обнаружения открытых беспроводных сетей в вашей среде. Организации, которые запрещают использование беспроводных сетей, могут использовать эти сканеры беспроводных сетей для обнаружения любых неавторизованных сетей Wi-Fi;
+* **Сканеры баз данных** (Database scanners). Вы можете использовать сканеры баз данных для выявления уязвимостей в вашей базе данных. Сканеры баз данных могут помочь вам предотвратить вредоносные взломы, такие как атаки с использованием SQL-инъекций;
+
+**По источнику:**
+
+* **Сканеры внешних уязвимостей**. С помощью внешних сканеров вы выполняете сканирование уязвимостей вне сети компании. Внешние сканеры обычно нацелены на ИТ-инфраструктуру, доступную в Интернете, включая открытые порты в сетевом брандмауэре и брандмауэрах веб-приложений;
+* **Сканеры внутренних уязвимостей**. В отличие от внешних сканеров, внутренние сканеры проводят сканирование уязвимостей изнутри корпоративной сети. Это сканирование позволяет защитить и укрепить критически важные приложения, обнаруживая внутренние угрозы, например вредоносные программы, проникшие в сеть;
+
+**По авторизованности:**
+
+* **С аутентификацией**. Сканирование с проверкой подлинности - также называемое сканированием с учетными данными - позволяет администратору сети войти в систему как пользователь и определить слабые места сети с точки зрения доверенного пользователя. Поскольку вы вошли в систему, вы можете глубже проникнуть в сеть, чтобы обнаружить многочисленные угрозы;
+* **Без аутентификации**. При сканировании без аутентификации вам не нужно входить в сеть для выполнения сканирования. Хотя вы можете получить представление о сети посторонним, вы, скорее всего, упустите большинство уязвимостей при использовании сканирования без аутентификации;
+
+**Тестирование на проникновение (Penetration testing)**:
+
+Это имитация атаки, в ходе которой компьютерная система, сеть или приложение проверяются на наличие слабых мест в системе безопасности. Эти тесты основаны на сочетании инструментов и методов, которые настоящие хакеры использовали бы для взлома. Это похоже на то, как банк нанимает кого-то, чтобы в роли грабителя попытаться проникнуть в их здание и получить доступ к хранилищу. Если «грабитель» добьется успеха и проникнет в банк или хранилище, банк получит ценную информацию о том, как им нужно усилить меры безопасности. Другие распространенные названия тестов на проникновение - это white hat attacks and ethical hacking. Данный вид тестирования выполняется как вручную, так и автоматически и может быть как Black Box, так и Grey и White. Ввиду необходимости наличия специфических знаний и опыта для выполнения этого вида тестирования привлекается отдельный специалист - пентестер.
+
+**Примеры кейсов** тестирования на проникновение:
+
+* Тест на проникновение в сеть:
+ * выявление уязвимостей сетевого и системного уровня;
+ * определение неправильных конфигураций и настроек;
+ * выявление уязвимости беспроводной сети;
+ * мошеннические услуги;
+ * отсутствие надежных паролей и наличие слабых протоколов.
+* [Тест на проникновение приложений](http://withsecurity.ru/pentest-mobilnyh-prilozheniy-na-chto-obratit-vnimanie):
+ * выявление недостатков прикладного уровня;
+ * подделка запросов;
+ * применение злонамеренных скриптов;
+ * нарушение работы управления сеансами;
+* Тест на физическое проникновение:
+ * взлом физических барьеров;
+ * проверка и взлом замков;
+ * нарушения работы и обход датчиков;
+ * вывод из строя камер видеонаблюдения;
+
+**Отличия Vulnerability Assessment от Penetration testing**
+
+VAPT = Vulnerability Assessment + Penetration testing
+
+
+
+| Vulnerability Assessment | Penetration Testing |
+| ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| Это метод поиска и измерения уязвимости системы | Находит уязвимости и использует их |
+| Конечным результатом является список уязвимостей, которые приоретизируются по их влиянию | Тест на проникновение более целенаправлен. Он помогает наметить путь, по которому злоумышленник проникнет в систему |
+| В основном автоматизированно | В основном вручную |
+| Быстрее | Дольше |
+| Дешевле | Дороже |
+| Направлено вширь | Направлено вглубь каждой уязвимости для достижения конкретных целей |
+| Выполняется в критически важных системах в реальном времени | Выполняется на некритичных системах |
+| Оценка уязвимости должна проводиться не реже одного раза в квартал, в основном после обновления оборудования или серьезных изменений в сети | Тестирование на проникновение следует проводить ежегодно после значительных изменений |
+| Подробно описывается, какие уязвимости существуют и что изменилось с момента последнего анализа | Эффективно идентифицирует информацию, которая была скомпрометирована |
+
+Источники:
+
+* [Network Vulnerability Assessment And Management Guide](https://www.softwaretestinghelp.com/vulnerability-assessment-management/)
+* [What Is Vulnerability Assessment, and Why Is It Important?](https://www.parallels.com/blogs/ras/vulnerability-assessment/)
+* [Penetration Testing vs Vulnerability Assessment](https://www.educba.com/penetration-testing-vs-vulnerability-assessment/)
+
+Доп. материал:
+
+* [Top 10 Most Powerful Vulnerability Assessment Scanning Tools In 2021](https://www.softwaretestinghelp.com/vulnerability-assessment-tools/)
+* [A Complete Penetration Testing Guide With Sample Test Cases](https://www.softwaretestinghelp.com/penetration-testing-guide/)
+* [Взрослый разговор о пентесте и хакинге](https://www.youtube.com/watch?v=sTmAf0Pa\_eM)
+* [50 000 $ в месяц - не проблема, или Сколько на самом деле зарабатывают пентестеры](https://habr.com/ru/company/skillfactory/blog/548012/)
+* [TWAPT - пентестим по-белому в домашних условиях](https://habr.com/ru/company/pentestit/blog/551978/)
diff --git a/vidy-metody-urovni-testirovaniya/odnovremennoe-mnogopolzovatelskoe-testirovanie-concurrency-multi-user-testing.md b/vidy-metody-urovni-testirovaniya/odnovremennoe-mnogopolzovatelskoe-testirovanie-concurrency-multi-user-testing.md
new file mode 100644
index 0000000..7e44561
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/odnovremennoe-mnogopolzovatelskoe-testirovanie-concurrency-multi-user-testing.md
@@ -0,0 +1,13 @@
+# Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
+
+Concurrency testing - это подвид нагрузочного тестирования, при котором проверяется поведение системы (веб-приложение, веб-страница или API) в момент, когда одновременно происходят два или более событий, или выполняется одновременный вход нескольких пользователей в систему с выполнением одного и того же действия. Во время теста наблюдаются и записываются определенные метрики, а также измеряется время отклика системы в периоды устойчивой большой нагрузки. Зачем оно нужно:
+
+* Определяет влияние одновременного доступа к одним и тем же записям базы данных, модулям или коду приложения;
+* Определяет и измеряет уровень взаимоблокировки, блокировки и использования однопоточного кода и ограничения доступа к общим ресурсам;
+
+Concurrency Testing Techniques: Reviewing code, Static Analysis, Con testing, Reachability Testing, Fuzz Testing, Random testing, Extending [concolic testing](https://en.wikipedia.org/wiki/Concolic\_testing).
+
+Источники:
+
+* [Concurrency Testing: Challenges, Techniques & Process](https://www.softwaretestingclass.com/concurrency-testing-challenges-techniques-process/)
+* [LoadView - Concurrent User Testing](https://www.loadview-testing.com/concurrent-user-testing/)
diff --git a/vidy-metody-urovni-testirovaniya/osnovnye-vidy-testirovaniya-po.md b/vidy-metody-urovni-testirovaniya/osnovnye-vidy-testirovaniya-po.md
new file mode 100644
index 0000000..81c8a53
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/osnovnye-vidy-testirovaniya-po.md
@@ -0,0 +1,48 @@
+# Основные виды тестирования ПО
+
+_Тип тестирования (test type): Совокупность тестирующих действий, которая фокусируется на определенных показателях качества. (ГОСТ 56920) Прим.: в русскоязычной среде это “вид”._
+
+* Функциональные виды («Что?» - проверяет весь функционал продукта):
+ * Функциональное тестирование (Functional testing)
+ * Тестирование взаимодействия (Interoperability testing)
+* Нефункциональное («Как?»):
+ * Производительности (Performance)
+ * Тестирование емкости (Capacity testing)
+ * Нагрузочное (Load testing)
+ * Стрессовое (Stress testing)
+ * Масштабируемости (Scalability test)
+ * Объемное тестирование (Volume testing)
+ * Выносливости (Soak/Endurance testing)
+ * Устойчивости (Resilience testing)
+ * Стабильности/надежности (Stability / Reliability testing)
+ * Отказ и восстановление (Failover and Recovery testing)
+ * Эталонное и тестирование базовой версии (Benchmark and Baseline Testing)
+ * Тестирование безопасности (Security and Access Control testing)
+ * Удобство пользования (Usability testing)
+ * Тестирование доступности (Accessibility testing)
+ * Тестирование установки (Installation testing)
+ * Тестирование на соответствие (Conformance/Compliance testing)
+ * Конфигурационное (Configuration testing)
+ * Тестирование локализации, глобализации и интернационализации
+* Связанное с изменениями:
+ * Регрессионное (Regression testing)
+ * Тест работоспособности (Sanity testing)
+ * Дымовое (Smoke testing)
+
+Вообще виды тестирования можно классифицировать по самым разным критериям, поэтому можно встретить и такие схемы:
+
+[Схема от Святослава Куликова](https://svyatoslav.biz/wp-pics/software\_testing\_classification\_ru.png) + [текстовая версия](https://docs.google.com/spreadsheets/d/13GVO1Bz5NnGDO1F7jIjyixodnjImQ6WxQyk-WnWNDpE/edit#gid=0)
+
+.jpeg)
+
+
+
+
+
+Еще классификаций на десерт: exploratory vs scripted; traditional vs agile; testing vs checking; standards-driven vs context-driven; phased vs. threaded.
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) 5.6 Методики тестирования
+* [Types of Testing - Software Testing Types Every QA Should Know](https://artoftesting.com/types-of-testing)
+* [Phased vs Threaded Testing](https://medium.com/@AWGHodder/phased-vs-threaded-testing-c4a16057ca28)
diff --git a/vidy-metody-urovni-testirovaniya/piramida-urovni-testirovaniya-test-pyramid-testing-levels.md b/vidy-metody-urovni-testirovaniya/piramida-urovni-testirovaniya-test-pyramid-testing-levels.md
new file mode 100644
index 0000000..28f8b6f
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/piramida-urovni-testirovaniya-test-pyramid-testing-levels.md
@@ -0,0 +1,27 @@
+# Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
+
+«Пирамида тестов» - метафора, которая означает группировку динамических тестов программного обеспечения по разным уровням. Она также дает представление, какое количество тестов должно быть в каждой из этих групп. Основной принцип разделения уровней - тест должен быть на том же уровне, что и тестируемый объект. В тесте более высокого уровня вы не тестируете всю условную логику и пограничные случаи, которые уже покрыты тестами более низкого уровня.
+
+
+
+ Уровни тестирования:
+
+* Unit/component/program/module testing - тестируется минимально-атомарный модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего;
+* Integration testing - несколько модулей программы тестируются вместе;
+* System testing - вся программа тестируется полностью;
+* Acceptance testing - программа принимается заказчиком на соответствие заявленным требованиям либо тестировщики проходят end-to-end сценарии с точки зрения пользователя;
+
+Доп. материал:
+
+* [Test Pyramid](https://martinfowler.com/bliki/TestPyramid.html)
+* [The Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html) + перевод на русский [Пирамида тестов на практике](https://habr.com/ru/post/358950/)
+* [От песочных часов к пирамиде: как усовершенствовать структуру тестов](https://habr.com/ru/company/badoo/blog/652025/)
+* [Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html)
+* [How Much Testing is Enough?](https://testing.googleblog.com/2021/06/how-much-testing-is-enough.html)
+* [Software Testing Anti-patterns](http://blog.codepipes.com/testing/software-testing-antipatterns.html)
+* [Пирамида Автоматизации Тестирования: Версия 2021 года](https://telegra.ph/Piramida-Avtomatizacii-testirovaniya-Versiya-2021-goda-03-24)
+* [Антипаттерны тестирования ПО](https://habr.com/ru/post/358178/)
+* [Unit, API и GUI тесты - чем отличаются](https://telegra.ph/Unit-API-i-GUI-testy--chem-otlichayutsya-02-11)
+* [Почему тестировать должны не только QA. Распределяем тест-кейсы между Dev, Analyst и QA](https://dou.ua/lenta/columns/test-cases-dev-qa-analyst/)
+* [Пирамида тестирования на практике. Как работает QA в Jiji](https://dou.ua/lenta/columns/testing-in-jiji/)
+* [Почему «осмысленное тестирование» - это важно?](https://habr.com/ru/post/650937/)
diff --git a/vidy-metody-urovni-testirovaniya/priemochnoe-testirovanie-at-acceptance-testing.md b/vidy-metody-urovni-testirovaniya/priemochnoe-testirovanie-at-acceptance-testing.md
new file mode 100644
index 0000000..32534f9
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/priemochnoe-testirovanie-at-acceptance-testing.md
@@ -0,0 +1,28 @@
+# Приемочное тестирование (AT - Acceptance testing)
+
+_Приемочное тестирование (acceptance testing): Формальное тестирование по отношению к потребностям, требованиям и бизнес процессам пользователя, проводимое с целью определения соответствия системы критериям приемки и дать возможность пользователям, заказчикам или иным авторизированым лицам определить, принимать систему или нет. (IEEE 610)_
+
+_Эксплуатационное приемочное тестирование (operational acceptance testing): Эксплуатационное тестирование в фазе приемочного тестирования, обычно выполняемое пользователем и/или сотрудниками с администраторским доступом, в рабочей среде (возможно, стимулированной), фокусируясь на функциональных аспектах. Например, восстанавливаемость, поведение ресурсов, устанавливаемость и техническое соответствие. (ISTQB)_
+
+После того, как процесс тестирования системы завершен командой тестирования, весь продукт передается клиенту и/или нескольким его пользователям для проверки приемлемости (acceptability). Е2Е бизнес-потоки проверяются аналогично в сценариях в реальном времени. Подобная производственной среда будет тестовой средой для приемочного тестирования (Staging, Pre-Prod, Fail-Over, UAT environment). Это метод тестирования черного ящика, при котором проверяется только функциональность, чтобы убедиться, что продукт соответствует указанным критериям приемки.
+
+**Виды приемочного тестирования**:
+
+* **Пользовательское** приемочное тестирование (UAT - User Acceptance Testing, validation, end-user testing) выполняется пользователем или клиентом чтобы определить, может ли ПО быть принято (accepted) или нет и проверить ПО на соответствие бизнес-требованиям. Могут существовать такие бизнес-требования и процессы, которые известны только конечным пользователям, и они либо пропускаются, либо неправильно интерпретируются, поэтому приемочное тестирование выполняется конечными пользователями, знакомыми с бизнес-требованиями;
+* **Бизнес -** приемочное тестирование (BAT - Business Acceptance Testing) необходимо для оценки того, соответствует ли Продукт бизнес-целям и задачам. BAT в основном фокусируется на бизнес-преимуществах (финансах), которые являются довольно сложными из-за меняющихся рыночных условий / прогрессирующих технологий, так что текущая реализация может претерпеть изменения, которые приведут к дополнительным затратам. Даже Продукт, отвечающий техническим требованиям, может не пройти BAT по этим причинам;
+* **Контрактное** приемочное тестирование (CAT - Contract Acceptance Testing) - это контракт, который определяет, что после того, как Продукт будет запущен в течение заранее определенного периода, должен быть проведен приемочный тест, и он должен пройти все приемочные тест-кейсы. Подписанный здесь контракт называется Соглашением об уровне обслуживания (SLA), которое включает условия, по которым платеж будет производиться только в том случае, если услуги Продукта соответствуют всем требованиям, что означает, что контракт выполнен. Иногда этот контракт может заключаться до того, как Продукт будет запущен. В любом случае, контракт должен быть четко определен с точки зрения периода тестирования, областей тестирования, условий по проблемам, возникающим на более поздних этапах, платежей и т. д.;
+* **Правовое** приемочное тестирование (RAT - Regulations/Compliance Acceptance Testing) необходимо для оценки того, нарушает ли Продукт правила и нормы, установленные правительством страны, в которой он выпускается. Это может быть непреднамеренным, но отрицательно скажется на бизнесе. Обычно разрабатываемый Продукт / приложение, предназначенный для выпуска во всем мире, должен пройти RAT, поскольку в разных странах / регионах действуют разные правила и положения, определенные его руководящими органами. Если какие-либо правила и нормы нарушаются для какой-либо страны, то этой стране или конкретному региону в этой стране не будет разрешено использовать Продукт и это будет считаться отказом (Failure). Вендоры Продукта несут прямую ответственность, если Продукт будет выпущен даже при наличии нарушения;
+* **Эксплуатационное** приемочное тестирование ([OAT - Operational Acceptance testing](https://en.wikipedia.org/wiki/Operational\_acceptance\_testing)) - это тип тестирования программного обеспечения, который оценивает эксплуатационную готовность программного приложения до его выпуска в производство. Целью эксплуатационного тестирования является обеспечение бесперебойной работы системы в ее стандартной эксплуатационной среде (SOE - standard operating environment). В основном это тестирование восстановления, совместимости, ремонтопригодности, доступности технической поддержки, надежности, восстановления после сбоя, локализации и т. д (recovery, compatibility, maintainability, technical support availability, reliability, fail-over, localization);
+* **Альфа-тестирование** ([Alpha Testing](https://www.softwaretestinghelp.com/alpha-testing/)) проводят для оценки продукта в среде разработки / тестирования специализированной командой тестировщиков, обычно называемой альфа-тестерами. Здесь отзывы и предложения тестировщиков помогают улучшить использование Продукта, а также исправить определенные ошибки;
+* **Бета-тестирование, полевые испытания** ([Beta Testing](https://www.softwaretestinghelp.com/beta-testing/), Field Testing) проводят для оценки Продукта, предоставляя его реальным конечным пользователям, обычно называемым бета-тестерами / бета-пользователями, в их среде. Собирается постоянная обратная связь от пользователей, и проблемы устраняются. Кроме того, это помогает в улучшении Продукта, чтобы обеспечить удобство работы пользователей. Тестирование происходит неконтролируемым образом, что означает, что у пользователя нет ограничений на использование Продукта;
+
+Источники:
+
+* [What Is Acceptance Testing (A Complete Guide)](https://www.softwaretestinghelp.com/what-is-acceptance-testing/)
+* [What Is User Acceptance Testing (UAT): A Complete Guide](https://www.softwaretestinghelp.com/what-is-user-acceptance-testing-uat/)
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “D.2 Подпроцесс приемочного испытания”
+* [Business-facing tests](https://martinfowler.com/bliki/BusinessFacingTest.html)
+* [Как проводить приемочное тестирование](https://www.youtube.com/watch?v=BKWgBk3gktw\&ab\_channel=Podlodka)
diff --git a/vidy-metody-urovni-testirovaniya/raznica-testirovaniya-po-i-zheleza-software-vs.-hardware-testing.md b/vidy-metody-urovni-testirovaniya/raznica-testirovaniya-po-i-zheleza-software-vs.-hardware-testing.md
new file mode 100644
index 0000000..bc32ed2
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/raznica-testirovaniya-po-i-zheleza-software-vs.-hardware-testing.md
@@ -0,0 +1,31 @@
+# Разница тестирования ПО и железа (Software Vs. Hardware testing)
+
+**Программное обеспечение** ([Software](https://en.wikipedia.org/wiki/Software)) - это управляющий набор инструкций и данных. В информатике и разработке программного обеспечения программное обеспечение - это вся информация, обрабатываемая компьютерными системами, включая программы и данные. Программное обеспечение включает программы, библиотеки и связанные с ними неисполняемые данные, такие как онлайн-документация или цифровые носители. Программное обеспечение и оборудование требуют друг друга, и ни одно из них не может реально использоваться по отдельности. На самом низком уровне программирования исполняемый код состоит из инструкций машинного языка, поддерживаемых отдельным процессором - обычно центральным процессором (ЦП) или графическим процессором (ГП). Машинный язык состоит из групп двоичных значений, обозначающих инструкции процессора, которые изменяют состояние компьютера по сравнению с его предыдущим состоянием.
+
+**Аппаратное обеспечение** (Hardware) - это физическое электронное устройство, промышленное оборудование или компонент компьютера. Примерами оборудования компьютера являются CPU, MB, устройства ввода/вывода и хранения данных (HDD или SSD). Без оборудования программному обеспечению не на чем будет работать. Аппаратное и программное обеспечение взаимодействуют друг с другом, и программное обеспечение сообщает аппаратному обеспечению, какие задачи оно должно выполнять.
+
+**Разница в тестировании ПО и железа**:
+
+В глобальном смысле нам не сильно важна природа объекта тестирования, т.к. принципы особо не меняются. Однако, как говорится, есть нюансы:
+
+* “Железный” баг может легко физически безвозвратно сломать единственный рабочий прототип. Критерии отбора тестов должны учитывать и анализ рисков;
+* Само взаимодействие с железом, как и снятие показателей результатов / метрик может потребовать дополнительное оборудование, физические модификации, а также почти наверняка инженерный ум и прямые руки из нужного места;
+* Тесты программного обеспечения в отличии от тестов железа виртуальны, их можно копировать и переиспользовать и прогонять сколько потребуется. ПО можно легко изменить и развить с помощью нескольких релизов, в то время как оборудование требует более высоких затрат на изменение и не может быть подвергнуто рефакторингу после производства. Тестировщики должны понимать, что когда оборудование создается, они не могут добавлять к нему новые возможности. Таким образом, тесты подходят только для этой линейки оборудования, и для следующего продукта необходимо будет создать другой набор критериев оценки. Конструкции оборудования также значительно более ограничены из-за конкретных деталей или отраслевых рекомендаций;
+* В результате первого различия существуют в тест-кейсах. При использовании кейсов для ПО для выполнения всех запланированных тестов может потребоваться от 50 до 100 шагов, это результат того, что нужно учесть бесчисленное множество вещей и высокого уровня автоматизации тестирования, связанного с гибкой разработкой программного обеспечения. Команды могут использовать инструменты тестирования качества, чтобы отслеживать эти операции и гарантировать, что все идет так, как ожидалось. С другой стороны, этапы тестирования оборудования намного короче и проще и включают всего несколько этапов, чтобы проверить, работает ли продукт. Во-первых, прошивка может быть проверена на исправность. Затем оборудование оценивается, чтобы убедиться, что оно хорошо интегрируется с другими системами и должным образом работает с необходимыми приложениями и операционными системами. Наконец, вся система оценивается по тому, насколько хорошо она соответствует требованиям заказчика и высокоуровневым спецификациям, таким как соответствие (compliance). Аппаратное обеспечение нельзя сильно менять перед выпуском, поэтому важно, чтобы группы выполняли полные тесты для выявления любых слабых мест, которые могут быть присущи продукту.
+* Что касается программного обеспечения, управляющего оборудованием, здесь резко может возрасти необходимый технический уровень для тестирования (низкоуровневое понимание работы железа, связки с прошивкой, программирование микроконтроллеров, ассемблер и вот это всё):
+ * Embedded operating systems;
+ * Device driver and service testing;
+ * Multi threaded communications;
+ * Synchronising data from multiple external sources;
+ * Using data scopes to isolate errors (Hardware vs Software);
+
+Источники:
+
+* [Difference between Hardware and Software](https://www.guru99.com/hardware-vs-software-difference.html)
+* [The Difference between Software Testing and Hardware Testing](https://www.techwell.com/techwell-insights/2017/03/difference-between-software-testing-and-hardware-testing?\_\_cf\_chl\_captcha\_tk\_\_=pmd\_dMswbG.OAQqO6tWy60YvKfgPLiHrKsEnWLd1kCA6LF0-1632916018-0-gqNtZGzNAxCjcnBszQjR)
+* [software vs hardware testing](http://www.sqaforums.com/forums/general-discussion/43191-software-vs-hardware-testing.html)
+
+Доп. материал:
+
+* [Hardware vs Software Product Testing](https://medium.com/somiacx/hardware-vs-software-product-testing-7c61fb083ddf)
+* [Siemens hardware and software testing solutions](https://www.plm.automation.siemens.com/global/en/products/simulation-test/testing.html)
diff --git a/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing.md b/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing.md
new file mode 100644
index 0000000..29231e2
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing.md
@@ -0,0 +1,124 @@
+# Регрессионные виды тестирования (Regression testing)
+
+_Регрессионное тестирование (regression testing): Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении. (ISTQB)_
+
+**Регресс** - это противоположность прогресса. Любое ПО по мере прогресса в функционале неизбежно усложняется, увеличиваются взаимосвязи в функциях и т.п., и чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование. И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения. Но этого недостаточно. По-сути, проблема намного серьезнее - мы каждый раз не знаем, что принесет с собой новая функциональность в системе. Нам каждый раз надо предположить/узнать/протестировать новые взаимодействия в системе, а не тестировать только новые функции в изоляции от остальных. Старый функционал с новым если начинают пересекаться - надо заново расчехлять аналитику, выявлять новые ситуации, которые могут возникнуть, писать новые тест-кейсы, которые затрагивают уже не столько функциональные, сколько интеграционные аспекты. Поэтому выяснение "не наступил ли регресс" (внимание, не путать с "не наступила ли регрессия") - постоянная задача, которую также необходимо решать в контексте maintenance testing.
+
+**Регрессионное тестирование** (Regression Testing) - собирательное название для всех видов тестирования программного обеспечения связанных с изменениями, направленных на обнаружение ошибок в уже протестированных участках исходного кода, на проверку того, что новая функциональность не зааффектила (affect) старую. Такие ошибки - когда после внесения изменений в программу перестаёт работать то, что должно было продолжать работать, - называют регрессионными ошибками (regression bugs). Регрессионные тесты должны быть частью релизного цикла (Release Cycle) и учитываться при тестовой оценке (test estimation).
+
+При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках maintenance testing, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям. Регрессионное тестирование обычно проводится перед релизом новой версии приложения. Это происходит следующим образом: в течение какого-то времени делаются какие-то фичи и другие задачи, они тестируются по отдельности и сливаются в общую ветку (мастер/девелоп - чаще всего эта ветка называется в зависимости от процессов в проекте). Дальше, когда время подходит к релизу от ветки девелопа создается ветка релиза, из которой собирается релиз-кандидат и на нем уже проводят регресс.
+
+Главной задачей maintenance testing является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям.
+
+Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться. Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
+
+Можно заключить, что регрессионное тестирование выполняется чтобы минимизировать регрессионные риски. То есть, риски того, что при очередном изменении продукт перестанет выполнять свои функции. С регрессионным тестированием плотно связана другая активность - импакт анализ (Impact Analysis, анализ влияния изменений). Итоговая область регрессии называется Regression Scope / Scope of Regression.
+
+**Классификация регрессионного тестирования**:
+
+* Проверить всё (Retest All): Как следует из названия, все тест-кейсы в наборе тестов повторно выполняются, чтобы гарантировать отсутствие ошибок, возникших из-за изменения кода. Это дорогостоящий метод, поскольку он требует больше времени и ресурсов по сравнению с другими методами;
+* Минимизация набора тестов (test suite minimization) стремится уменьшить размер тестового набора за счет устранения избыточных тестовых примеров из тестового набора;
+* Задача выбора теста (test case selection) связана с проблемой выбора подмножества тестов, которые будут использоваться для проверки измененных частей программного обеспечения. Для этого требуется выбрать подмножество тестов из предыдущей версии, которые могут обнаруживать неисправности, основываясь на различных стратегиях. Большинство задокументированных методов регрессионного тестирования сосредоточены именно на этой технике. Обычная стратегия состоит в том, чтобы сосредоточить внимание на отождествления модифицированных частей SUT (system under test) и для выбора тестовых случаев, имеющих отношение к ним. Например, техника полного повторного тестирования (retest-all) - один из наивных типов выбора регрессионного теста путем повторного выполнения всех видов тестов от предыдущей версии на новой. Она часто используется в промышленности из-за её простого и быстрого внедрения. Тем не менее, её способность обнаружения неисправностей ограничена. Таким образом, значительный объём работ связан с разработкой эффективных и масштабируемых селективных методов;
+* Задача определения приоритетов теста (test case prioritization). Ее цели заключаются в выполнении заказанных тестов на основе какого-либо критерия. Например, на основе истории, базы или требований, которые, как ожидается, приведут к более раннему выявлению неисправностей или помогут максимизировать некоторые другие полезные свойства;
+* Гибридный: Гибридный метод представляет собой комбинацию выборочного и приоритезации. Вместо того, чтобы выбирать весь набор тестов, выберите только те тест-кейсы, которые повторно выполняются в зависимости от их приоритета;
+
+**Типы регрессии по Канеру**:
+
+* Регрессия багов (Bug regression) - попытка доказать, что исправленная ошибка на самом деле не исправлена;
+* Регрессия старых багов (Old bugs regression) - попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться;
+* Регрессия побочного эффекта (Side effect regression) - попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения;
+
+**Регрессия в Agile**:
+
+В Agile продукт разрабатывается в рамках короткой итерации, называемой спринтом, которая длится 2-4 недели. В Agile существует несколько итераций, поэтому это тестирование играет важную роль, поскольку в итерациях добавляется новая функциональность или изменения кода. Набор регрессионных тестов должен быть подготовлен на начальном этапе и обновляться с каждым спринтом. В Agile проверки регрессии делятся на две категории:
+
+* Регрессия уровня спринта (Sprint Level Regression): выполняется в основном для новых функций или улучшений, внесенных в последний спринт. Тест-кейсы из набора тестов выбираются в соответствии с новыми добавленными функциями или сделанными улучшениями;
+* Сквозная регрессия (End to End Regression): включает в себя все тест-кейсы, которые должны быть повторно выполнены для сквозного тестирования всего продукта, охватывая все основные функции;
+
+**Смоук тестирование (Smoke testing)**
+
+_Тест "на дым" (smoke test): Выборка из общего числа запланированных тестовых сценариев, покрывающая основную функциональность компонента или системы. Проводится с целью удостовериться, что базовые функции программы в целом работают корректно, без углубления в детали. Ежедневная сборка и тест "на дым" являются передовыми практическими методами. См. входной тест, тест верификации сборки. (ISTQB)_
+
+_Тест верификации сборки (build verification test): Набор автоматических тестов, валидирующих целостность каждой новой сборки и верифицирующих ее ключевую/базовую функциональность, стабильность и тестируемость. Данный вид тестирования используется там, где присутствует высокая частота сборок (например, проекты с использованием гибких методологий разработки) и выполняется для каждой новой сборки перед передачей ее в тестирования. См. также регрессионное тестирование, тест "на дым". (ISTQB)_
+
+Smoke testing, BVT - Build Verification Testing, BAT - Builds Acceptance Testing, Breath Testing, Shakeout/Shakedown Testing, Intake test, а также в русскоязычных вариантах дымовое, на дым, дымное, тестирование сборки и т.п. - это подмножество регрессионного тестирования, короткий цикл тестов, выполняемый для каждой новой сборки для подтверждения того, что ПО после внесенных изменений стартует и выполняет основные функции без критических и блокирующих дефектов. В случае отсутствия таковых дефектов Smoke testing объявляется пройденным, и команда QA может начинать дальнейшее тестирование полного цикла, в противном случае, сборка объявляется дефектной, что делает дальнейшее тестирование пустой тратой времени и ресурсов. В таком случае сборка возвращается на доработку и исправление. Smoke testing обычно используется для Integration, Acceptance and System Testing.
+
+Если мы говорим про сайт интернет-магазина, то сценарий может быть следующим:
+
+* Сайт открывается
+* Можно выбрать случайный товар и добавить его в корзину
+* Можно оформить и оплатить заказ
+
+Если мы говорим про мобильное приложение, например, messenger, то:
+
+* Приложение устанавливается и запускается
+* Можно авторизоваться
+* Можно написать сообщение случайном контакту
+
+Небольшая шпаргалка по степени важности:
+
+* **smoke** - самое важное. Тест-кейсы играют очень важную роль на этом уровне тестирования, поэтому предел метрик (metric limit) часто соответствует 100% или примерно 100%;
+* **critical path** - повседневное. Тесты критического пути запускаются для проверки функциональности, используемой типичными пользователями в их повседневной деятельности. Есть много пользователей, которые обычно используют определенную часть функциональности приложения, которую необходимо проверить, как только smoke этап будет успешно завершен. Здесь лимит метрик немного ниже, чем у smoke, и соответствует 70-80-90% в зависимости от цели проекта;
+* **extended** - все. Выполняется для изучения всей функциональности, указанной в требованиях. Проверяется даже функциональность с низким приоритетом. При этом в этом тестировании нужно понимать, какой функционал наиболее ценный, а какой менее важный. При условии, что у вас достаточно времени или других ресурсов, тесты на этом уровне можно использовать для требований с низким приоритетом;
+
+Примечание. В русском языке термин ошибочно переводят как проверка дыма, корректнее уж говорить “на дым”. [История термина:](https://ru.wikipedia.org/wiki/Smoke\_test) Первое свое применение этот термин получил у печников, которые, собрав печь, закрывали все заглушки, затапливали ее и смотрели, чтобы дым шел только из положенных мест. Повторное «рождение» термина произошло в радиоэлектронике. Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме. Если первое включение не выявило перегрева, то прибор включается снова на большее время. Проверка повторяется. И так далее несколько раз. Выражение «smoke-test» используется инженерами в шуточном смысле, так как появления дыма, а значит и порчи частей устройства, стараются избежать.
+
+**Санити тестирование (Sanity testing)**
+
+_Тест работоспособности (sanity test): См. тест "на дым". (ISTQB)_
+
+Другие источники:
+
+Sanity testing также является подмножеством регрессионного тестирования и выполняется до или вместо полной регрессии, но после smoke. Эти два подвида похожи, но в целом Sanity используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений.
+
+Примечание. Санитарным это тестирование в русскоязычной среде назвалось по совершенно непонятным причинам, но гуглится только так. На самом же деле дословно переводится как тестирование на вменяемость / разумность / работоспособность / согласованность или по версии ISTQB “Тест работоспособности”.
+
+**Подтверждающее, повторное тестирование (**[**confirmation testing**](https://www.softwaretestingmaterial.com/confirmation-testing/)**,** [**re-testing**](https://www.softwaretestingmaterial.com/retesting/)**)**
+
+_Подтверждающее тестирование (confirmation testing): Тестирование, при котором выполняются тестовые сценарии, которые были не пройдены при последнем запуске, с целью подтвердить успешность исправлений. (ISTQB)_
+
+Повторное тестирование - это тип тестирования, выполняемый в новой сборке по проваленному на старой сборке тест-кейсу с тем же окружением и данными, для проверки того, что этот дефект теперь устранен. Ре-тест выполняется перед sanity-тестированием, приоритет ре-теста выше регрессионных проверок, поэтому оно должно выполняться перед ними.
+
+**Тестирование N+1 (N+1 testing)**
+
+Вариант регрессионного тестирования представлен как N+1. В этом методе тестирование выполняется в несколько циклов, в которых ошибки, обнаруженные в тестовом цикле «N», устраняются и повторно тестируются в тестовом цикле N + 1. Цикл повторяется, пока не будет найдено ни одной ошибки.
+
+**Разница между повторным и регрессионным тестированием:**
+
+* Регрессионное тестирование проводится для подтверждения того, что недавнее изменение программы или кода не оказало неблагоприятного воздействия на существующие функции. Повторное тестирование проводится для подтверждения того, что тест-кейсы, которые не прошли, проходят после устранения дефектов;
+* Цель регрессионного тестирования подтвердить, что новые изменения кода не должны иметь побочных эффектов для существующих функций. Повторное тестирование проводится на основе исправлений дефектов.;
+* Проверка дефектов не является частью регрессионного тестирования. Проверка дефекта является частью повторного тестирования;
+* В зависимости от проекта и наличия ресурсов, регрессионное тестирование может проводиться параллельно с повторным тестированием. Приоритет повторного тестирования выше, чем регрессионное тестирование, поэтому оно проводится перед регрессионным тестированием;
+* Регрессионное тестирование называется общим (generic) тестированием. Повторное тестирование - это плановое (planned) тестирование;
+* Регрессионное тестирование проводится для пройденных Test case. Повторное тестирование проводится только для неудачных тестов;
+* Регрессионное тестирование проверяет наличие неожиданных побочных эффектов. Повторное тестирование гарантирует, что первоначальная ошибка была исправлена;
+* Test case для регрессионного тестирования могут быть получены из функциональной спецификации, user tutorials and manuals, а также defect reports в отношении исправленных проблем. Test case для повторного тестирования не могут быть получены до начала тестирования;
+
+**Может ли быть ситуация, когда регрессия проводится не после изменений в коде?**
+
+Да, в ситуациях с внешними факторами: изменения в БД, версии ОС и т.п.
+
+Источники:
+
+* [Maintenance, Regression testing and Re-testing](https://software-testing.ru/forum/index.php?/topic/31783-maintenance-regression-testing-and-re-testing/)
+* [Регрессионное тестирование](https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D1%80%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5\_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
+* [Тестировщики нужны - пост “Регресс для самых маленьких”](https://t.me/qa\_chillout/92)
+* [QA Outsourcing: Smoke Testing, Critical Path Testing, Extended Testing](https://testing-companies.com/qa-outsourcing-smoke-testing-critical-path-testing-extended-testing/)
+* [What Is Regression Testing? Definition, Tools, Method, And Example](https://www.softwaretestinghelp.com/regression-testing-tools-and-methods/)
+* [В чём разница Smoke, Sanity, Regression, Re-test и как их различать?](https://habr.com/ru/post/358142/)
+* [Difference Between Retesting and Regression Testing](https://www.guru99.com/re-testing-vs-regression-testing.html)
+* [Top 150 Software Testing Interview Questions and Answers for Freshers and Experienced](https://www.guru99.com/software-testing-interview-questions.html)
+
+Дополнительный материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “D.6 Подпроцесс регрессионного тестирования”, “D.7 Подпроцесс повторного тестирования”
+* [Лекция 11: Регрессионное тестирование: цели и задачи, условия применения, классификация тестов и методов отбора](https://intuit.ru/studies/courses/48/48/lecture/1444?page=1)
+* [Black Box Software Testing PART 11 - REGRESSION TESTING by Cem Kaner](http://testingeducation.org/k04/bbst11\_2004.pdf) + [2005 year version](https://present5.com/black-box-software-testing-spring-2005-regression-testing/)
+* [Епифанов Н. А. - Методы реализации регрессионного тестирования по расширенным тестовым наборам](https://elib.spbstu.ru/dl/577.pdf/view)
+* [Anti-Regression Approaches: Impact Analysis and Regression Testing Compared and Combined - Part I: Introduction and Impact Analysis](https://gerrardconsulting.com/blog/2010/04/anti-regression-approaches-impact-analysis-and-regression-testing-compared-and-combined-part-i-introduction-and-impact-analysis/)
+* [Anti-Regression Approaches - Part II: Regression Prevention and Detection Using Static Techniques](https://gerrardconsulting.com/blog/category/impact\_analysis/)
+* [Как сохранить нервы тестировщика или ускорить регресс с 8 до 2 часов](https://habr.com/ru/company/vivid\_money/blog/559024/#habracut)
+* [Регрессионное тестирование или Regression Testing](https://intellect.icu/regressionnoe-testirovanie-ili-regression-testing-6093)
+* [QA Outsourcing: Smoke Testing, Critical Path Testing, Extended Testing](https://testing-companies.com/qa-outsourcing-smoke-testing-critical-path-testing-extended-testing/)
+* [Антирегрессионное тестирование - минимизируйте затраты](https://habr.com/ru/company/typeable/blog/583062/)
+* [Способы сокращения регрессионного тестирования](https://www.youtube.com/watch?v=pEJfP52GWTg)
diff --git a/vidy-metody-urovni-testirovaniya/sistemnoe-testirovanie-system-testing.md b/vidy-metody-urovni-testirovaniya/sistemnoe-testirovanie-system-testing.md
new file mode 100644
index 0000000..5e07dc9
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/sistemnoe-testirovanie-system-testing.md
@@ -0,0 +1,54 @@
+# Системное тестирование (System Testing)
+
+Системное тестирование означает тестирование всей системы в целом, оно выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом. В основном это тестирование типа «черный ящик», которое оценивает работу системы с точки зрения пользователя с помощью документа спецификации и оно не требует каких-либо внутренних знаний о системе, таких как дизайн или структура кода.
+
+**Основное внимание уделяется следующему**:
+
+* Внешние интерфейсы;
+* Многопрограммность и сложный функционал;
+* Безопасность;
+* Восстановление;
+* Производительность;
+* Гладкое (smooth) взаимодействие оператора и пользователя с системой;
+* Возможность установки;
+* Документация;
+* Удобство использование;
+* Нагрузка / стресс;
+
+**Зачем нужно системное тестирование**?
+
+* Очень важно завершить полный цикл тестирования, и ST - это этап, на котором это делается;
+* ST выполняется в среде, аналогичной production environment, и, следовательно, заинтересованные стороны могут получить хорошее представление о реакции пользователя;
+* Это помогает свести к минимуму устранение неполадок после развертывания и количество обращений в службу поддержки;
+* На этом этапе STLC тестируются архитектура приложения и бизнес-требования. Это тестирование очень важно, и оно играет важную роль в предоставлении клиенту качественного продукта;
+
+**Критерии начала системного тестирования**:
+
+* Система должна соответствовать критериям окончания интеграционного тестирования, то есть все test cases должны быть выполнены, и не должно быть открытых критических ошибок или ошибок с приоритетом P1, P2;
+* System Test Plan должен быть одобрен и подписан;
+* Test cases/scenarios/scripts должны быть готовы к выполнению;
+* Все нефункциональные требования должны быть доступны, и для них должны быть созданы test cases;
+* Среда тестирования должна быть готова;
+
+**Критерии окончания системного тестирования**:
+
+* Все test cases должны быть выполнены;
+* В открытом состоянии не должно быть критических, приоритетных или связанных с безопасностью ошибок;
+* Если какие-либо ошибки со средним или низким приоритетом находятся в открытом состоянии, они должны быть исправлены с согласия клиента;
+* Отчет о выходе (Exit Report) должен быть отправлен;
+
+**Чем отличается системное тестирование от сквозного** (E2E - end-to-end testing)?
+
+Сквозное тестирование - это методология тестирования программного обеспечения для тестирования flow приложения от начала до конца. Целью сквозного тестирования является моделирование реального пользовательского сценария и проверка тестируемой системы и ее компонентов на предмет интеграции и целостности данных.
+
+Системное тестирование - этап предпоследний этап STLC и уровень тестирования, а E2E - подход к тестам. Обычно сквозные тесты выполняют после системного тестирования и перед приемочным, а также после внесения изменений (smoke и regression). E2E выполняется от начала до конца в реальных сценариях, таких как взаимодействие приложения с оборудованием, сетью, базой данных и другими приложениями. Основная причина проведения этого тестирования - определение различных зависимостей приложения, а также обеспечение передачи точной информации между различными компонентами системы.
+
+Источники:
+
+* [What Is System Testing - A Ultimate Beginner’s Guide](https://www.softwaretestinghelp.com/system-testing/)
+* [What Is End To End Testing: E2E Testing Framework With Examples](https://www.softwaretestinghelp.com/what-is-end-to-end-testing/#Why\_Do\_We\_Perform\_E2E\_Testing)
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “D.10 Подпроцесс тестирования системы”
+* [Лекция 7: Разновидности тестирования: системное и регрессионное тестирование](https://intuit.ru/studies/courses/48/48/lecture/1436)
diff --git a/vidy-metody-urovni-testirovaniya/staticheskoe-i-dinamicheskoe-testirovanie-static-testing-dynamic-testing.md b/vidy-metody-urovni-testirovaniya/staticheskoe-i-dinamicheskoe-testirovanie-static-testing-dynamic-testing.md
new file mode 100644
index 0000000..c687920
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/staticheskoe-i-dinamicheskoe-testirovanie-static-testing-dynamic-testing.md
@@ -0,0 +1,14 @@
+# Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
+
+_Тестирование, как статическое так и динамическое, должно быть направлено на получение обоих типов подтверждения (верификация и валидация), хотя и должно допускать, что подтверждение не будет получено немедленно из-за обнаружения дефектов. (ГОСТ 56920)_
+
+**Статическое тестирование** (Static Testing, Non-execution technique или verification) подразумевает проверку вручную или с помощью инструментов программного кода без его запуска, а также проверку документации.
+
+Почему требуется статическое тестирование:
+
+* Обнаружение ошибок / недостатков на ранних этапах: при создании ПО нельзя полагаться исключительно на динамическое тестирование, поскольку оно выявляет ошибки или недостатки программного продукта на более позднем этапе, что может стоить разработчикам много времени и усилий для отладки;
+* Увеличение размера ПО: по мере увеличения размера программного продукта становится трудно справиться с ним, поскольку эффективность покрытия кода снижается;
+* Динамическое тестирование занимает много времени: несмотря на то, что динамическое тестирование выявляет ошибку и предоставляет некоторые подробности относительно ошибки, исправление ошибки по-прежнему требует времени и усилий, поскольку оно включает в себя обнаружение сбоя от тестового примера до основной причины, что в целом усложняет процесс;
+* Динамическое тестирование дорогое: как упоминалось ранее, для динамического тестирования требуются тестовые примеры, и выполнение этого само по себе является дорогостоящим, потому что тестовые примеры должны быть сначала созданы, затем выполнены и проверены, а также должны поддерживаться, что требует большой работы со стороны тестировщиков;
+
+**Динамическое тестирование** (Dynamic Testing, Execution technique или validation) подразумевает запуск кода для проведения функциональных и нефункциональных проверок ПО. Основная цель этого тестирования - подтвердить, что программный продукт работает в соответствии с требованиями бизнеса. Преимуществами динамического тестирования являются выявление сложных дефектов, которые не могут быть обнаружены статическим тестированием, обнаружение угроз безопасности, проблем с производительностью и т.п.
diff --git a/vidy-metody-urovni-testirovaniya/stressovoe-testirovanie-stress-testing.md b/vidy-metody-urovni-testirovaniya/stressovoe-testirovanie-stress-testing.md
new file mode 100644
index 0000000..6f4935f
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/stressovoe-testirovanie-stress-testing.md
@@ -0,0 +1,41 @@
+# Стрессовое тестирование (Stress testing)
+
+_Стрессовое тестирование (stress testing): Вид тестирования производительности, оценивающий систему или компонент на граничных значениях рабочих нагрузок или за их пределами, или же в состоянии ограниченных ресурсов, таких как память или доступ к серверу. (IEEE 610)_
+
+_Стрессовое тестирование (stress testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при условиях загрузки, выше ожидаемой или указанной в требованиях к производительности, или при доступности ресурсов, ниже минимальной, указанной в требованиях. (ГОСТ 56920)_
+
+Стрессовое тестирование выполняется самым первым, если нет отдельного Capacity тестирования, хотя по факту это все равно будет Capacity, т.к. нагрузка берется «с потолка». Стресс-тестирование - это отрицательное / негативное тестирование, которые проводят при больших нагрузках или нагрузках, выходящих за допустимые пределы, чтобы определить поведение системы при таких обстоятельствах, точку отказа системы (числовые показатели метрик), показываются ли корректные ошибки при этом и не теряются ли данные. Это тестирование также называют Fatigue testing.
+
+
+
+**Виды стресс-тестирования**:
+
+* Распределенное стресс-тестирование: тесты выполняются для всех клиентов с сервера для отслеживания их статуса, а также для выявления сбоев из-за чрезмерного стресса;
+* Стресс-тестирование приложения: основное внимание в этом тестировании уделяется обнаружению дефектов в программном обеспечении, связанных с блокировкой данных (locking and blocking), проблемами сети и узкими местами производительности;
+* Транзакционное стресс-тестирование: транзакционное тестирование выполняет стресс-тестирование одной или нескольких транзакций между различными программными продуктами или приложениями. Его основная цель - точная настройка и оптимизация системы для повышения ее производительности;
+* Систематическое стресс-тестирование: интегрированное стресс-тестирование, систематическое стресс-тестирование, используется для тестирования нескольких систем, работающих на одном сервере. Это позволяет группе тестирования обнаруживать дефекты, когда данные одного программного обеспечения блокируют другое программное обеспечение;
+* Исследовательское стресс-тестирование: используется для тестирования системы в необычных условиях, которые маловероятны в реальном сценарии. Эти сценарии стресс-тестирования позволяют группе обнаруживать различные необнаруженные проблемы и ошибки в системе;
+
+**Подход / процесс** содержит те же этапы, что описаны в нагрузочном, и то же самое в остальных подвидах, поэтому дублировать нет смысла.
+
+**Примеры**:
+
+* Стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S);
+* MS Word может выдать сообщение об ошибке «Не отвечает» при попытке скопировать файл размером 7-8 ГБ. Вы засыпали Word файлом огромного размера, и он не смог обработать такой большой файл, и в результате он завис;
+* Когда большое количество пользователей одновременно получают доступ к логину / регистрации;
+* Когда несколько пользователей пытаются загрузить один файл одновременно;
+* База данных отключается, когда к ней обращается большое количество пользователей;
+* Много пользователей заходят на веб-сайт, в то время как на сервере запускается сканирование на вирусы;
+* Огромный объем данных копируется из буфера обмена и сохраняется в веб-форме большим количеством пользователей одновременно;
+* Огромное количество пользователей одновременно нажимают кнопку «Добавить в корзину» на сайте покупок;
+
+**Пиковое тестирование** (Spike Testing) - это разновидность стресс-тестирования, проводится для проверки характеристик производительности, когда тестируемая система подвергается моделям рабочей нагрузки и объемам нагрузки, которые многократно увеличиваются за пределы ожидаемых производственных операций в течение коротких периодов времени. Обычно продолжительность теста составляет 1 час; он может отличаться в зависимости от вашего SLA / требований.
+
+[](https://1.bp.blogspot.com/-JejjJzmeIVs/WGpFkuprnzI/AAAAAAAAAh8/bzZN9uAtgNARNRnZknIl\_7\_cH0f3f52-wCLcB/s1600/STG.JPG)
+
+Источники:
+
+* [What is Stress Testing?](https://blog.testlodge.com/what-is-stress-testing/)
+* [Stress Testing](https://www.professionalqa.com/stress-testing)
+* [Stress Testing Guide For Beginners](https://www.softwaretestinghelp.com/stress-testing/)
+* [Do you really know all types of Performance Tests (Non-Functional Tests)?](https://perfmatrix.blogspot.com/2017/01/type-of-performance-test.html)
diff --git a/vidy-metody-urovni-testirovaniya/svobodnoe-intuitivnoe-testirovanie-adhoc-ad-hoc-testing.md b/vidy-metody-urovni-testirovaniya/svobodnoe-intuitivnoe-testirovanie-adhoc-ad-hoc-testing.md
new file mode 100644
index 0000000..614e8fb
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/svobodnoe-intuitivnoe-testirovanie-adhoc-ad-hoc-testing.md
@@ -0,0 +1,43 @@
+# Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
+
+_Свободное тестирование (ad hoc testing): Тестирование, выполняемое неформально; без формальной подготовки тестов, формальных методов проектирования тестов, определения ожидаемых результатов и руководства по выполнению тестирования. (ISTQB)_
+
+_Парное тестирование (pair testing): Два человека (двое тестировщиков, разработчик и тестировщик, или конечный пользователь и тестировщик), работающих вместе над поиском дефектов. Обычно они работают за одним компьютером, в течение работы, передавая управление друг другу. (ISTQB)_
+
+Свободное тестирование (ad-hoc testing) - это вид тестирования, который выполняется без подготовки к тестированию продукта, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Оно не требует никакой документации, планирования, процессов, которых следует придерживаться при выполнении тестирования. Такой способ тестирования в большинстве случаев дает большее количество заведенных отчетов об ошибке. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основной функциональной части продукта и выполняет как позитивные, так и негативные варианты возможных сценариев.
+
+Чаще всего такое тестирование выполняется, когда владелец продукта не обладает конкретными целями, проектной документацией и ранее поставленными задачами. При этом тестировщик полагается на свое общее представление о продукте, сравнение с похожими продуктами, собственный опыт. Однако при тестировании ad-hoc тестировщик должен иметь полные знания и осведомленность о тестируемой системе, особенно если проект очень сложный и большой. Поэтому нужно хорошее представление о целях проекта, его назначении, основных функциях и возможностях.
+
+**Виды свободного тестирования** (ad-hoc testing):
+
+* Buddy testing - процесс, когда 2 человека, как правило разработчик и тестировщик, работают параллельно и находят дефекты в одном и том же модуле тестируемого продукта. Сразу после того, как разработчик завершает модульное тестирование, тестировщик и разработчик вместе работают над модулем. Этот вид тестирования позволяет обеим сторонам рассматривать эту функцию в более широком масштабе. Разработчик получит представление обо всех различных тестах, выполняемых тестером, а тестировщик получит представление о том, какова внутренняя конструкция, которая поможет ему избежать разработки недействительных сценариев;
+* Pair testing - в этом тестировании два тестировщика (лучше с разным опытом) работают вместе над одним модулем. Идея, лежащая в основе этой формы тестирования состоит в том, чтобы заставить двух тестировщиков провести мозговой штурм идей и методов, чтобы выявить ряд дефектов. Оба могут разделять работу по тестированию и делать необходимую документацию по всем сделанным наблюдениям;
+* Monkey testing - произвольное тестирование продукта с целью как можно быстрее, используя различные вариации входных данных, нарушить работу программы или вызвать ее остановку (простыми словами - сломать);
+
+**Основные преимущества ad-hoc testing**:
+
+* нет необходимости тратить время на подготовку документации;
+* самые важные дефекты зачастую обнаруживаются на ранних этапах;
+* часто применяется, когда берут нового сотрудника. С помощью этого метода, человек усваивает за 3 дня то, что, разбираясь тестовыми случаями, разбирал бы неделю - это называется форсированное обучение новых сотрудников;
+* возможность найти трудновоспроизводимые и трудноуловимые дефекты, которые невозможно было бы найти, используя стандартные сценарии проверок;
+
+| Adhoc Testing | Exploratory Testing |
+| -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
+| Начинается с изучения приложения, а затем - с фактического процесса тестирования | Начинается с тестирования приложения, а затем его понимания посредством исследования |
+| Самостоятельный вид тестирования | Разновидность Adhoc Testing |
+| Не требуется никакой документации | Обязательно наличие документации по деталям тестирования. |
+| Adhoc Testing проводят тестировщики, обладающие глубокими знаниями о приложении | Для изучения приложения не обязательно иметь эксперта. |
+| Тестирование начинается после того, как будут собраны все данные для проведения тестирования | Сбор данных и тестирование происходят одновременно. |
+| Это работает для отрицательных сценариев тестирования | В основном это касается положительных сценариев |
+| Ориентировано на улучшение процесса тестирования | Ориентировано на изучение приложения |
+| Зависит от творческих способностей и интуиции тестировщика | Зависит от любопытства и понимания тестировщика |
+| Нет ограничений по времени | Это ограниченный по времени метод |
+
+Источники:
+
+* [Ad-Hoc Testing: How To Find Defects Without A Formal Testing Process](https://www.softwaretestinghelp.com/ad-hoc-testing/)
+* [Adhoc Testing Guide - What You Should Know](https://www.softwaretestingmaterial.com/adhoc-testing/)
+
+Доп. материал:
+
+* [Что такое ad-hoc тестирование?](https://testengineer.ru/chto-takoe-ad-hoc-testirovanie/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-api-api-application-programming-interface.md b/vidy-metody-urovni-testirovaniya/testirovanie-api-api-application-programming-interface.md
new file mode 100644
index 0000000..03ae1e6
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-api-api-application-programming-interface.md
@@ -0,0 +1,120 @@
+# Тестирование API (API - Application Programming Interface)
+
+Каждый день используя любимые мобильные приложения и веб-ресурсы вы незаметно взаимодействуете с API, скрытым под интерфейсом пользователя.
+
+API действует как интерфейс между двумя программными приложениями и позволяет им связываться друг с другом на оговоренных правилах и не залезая в реализацию предоставляемых функций, при том правила - не договоренность, а контракт. Простой пример: вы можете встроить на свою главную страницу сайта маленький виджет прогноза погоды, который будет отправлять определенный правилами запрос к API некоего сервиса погоды и получать определенный правилами ответ, содержащий посылку с данными.
+
+Еще более простой пример: примите официанта в качестве API ресторана. В ресторане вы даете заказ на основе блюд, определенных в меню. Официант принимает ваш заказ и на этом ваше участие заканчивается и вам не интересно, что там произойдет дальше. От официанта вы ожидаете только итог - вам приносят заказанное блюдо.
+
+Можете попробовать взаимодействие с API сами: отправляете GET запрос на [https://reqres.in/api/users](https://reqres.in/api/users), и получаете в ответ список пользователей. Это очень удобно, когда вы хотите предоставить интерфейс взаимодействия со своим сервисом сторонним лицам. Например, у google, instagram, vk и, в общем-то, всех популярных продуктов есть открытая часть API. То есть у вас есть документ с перечнем того, что и как можно спросить и что вам на это придет в ответ. Взаимодействовать с API можно и с веб-страницы, и с помощью специальных инструментов и напрямую из кода. Помимо прочего, API бывает не только в контексте сетей, например, в той же системе Android есть внутреннее системное API.
+
+**Тестирование API** - это тип тестирования (хотя правильнее наверное сказать не тип или вид, а еще один вариант взаимодействия с системой) который включает в себя тестирование API напрямую, а также в рамках интеграционного тестирования, чтобы проверить, соответствует ли API ожиданиям с точки зрения функциональности, надежности, производительности и безопасности приложения. В тестировании API наш основной упор будет сделан на уровне бизнес-логики архитектуры программного обеспечения.
+
+
+
+Типы тестирования API:
+
+* Unit testing: Для проверки функциональности отдельной операции;
+* Functional testing: Чтобы проверить функциональность более широких сценариев с помощью блока результатов unit-тестирования, протестированных вместе;
+* Load testing: Чтобы проверить функциональность и производительность под нагрузкой;
+* Runtime/Error Detection: Мониторинг приложения для выявления проблем, таких как исключения и утечки ресурсов;
+* Security testing: Чтобы гарантировать, что реализация API защищена от внешних угроз;
+* UI testing: Это выполняется как часть end-to-end integration тестов, чтобы убедиться, что каждый аспект пользовательского интерфейса функционирует должным образом;
+* Interoperability and WS Compliance testing: Совместимость и WS Compliance testing - это тип тестирования, который применяется к SOAP API. Функциональная совместимость между API-интерфейсами SOAP проверяется путем обеспечения соответствия профилям функциональной совместимости веб-служб. Соответствие WS- \* проверено, чтобы гарантировать, что стандарты, такие как WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security и WS-Trust, должным образом реализованы и используются;
+* Penetration testing: Чтобы найти уязвимости при атаках злоумышленников;
+* Fuzz testing: Для проверки API путем принудительного ввода в систему некорректных данных для попытки принудительного сбоя;
+* Usability testing: проверяет, является ли API функциональным и удобным для пользователя и хорошо ли интегрируется с другой платформой;
+* Documentation testing: команда тестирования должна убедиться, что документация соответствует требованиям и предоставляет достаточно информации для взаимодействия с API. Документация должна быть частью окончательного результата;
+
+**Примеры проблем, которые обнаруживает тестирование API:**
+
+* Некорректная обработка условий ошибки;
+* Неиспользуемые флаги;
+* Отсутствующие или повторяющиеся функции;
+* Вопросы надежности;
+* Сложность подключения и получения ответа от API;
+* Проблемы с безопасностью;
+* Проблемы с многопоточностью;
+* Проблемы с производительностью. Время отклика API очень велико;
+* Неправильные ошибки / предупреждение вызывающему абоненту;
+* Неправильная обработка допустимых значений аргументов;
+* Данные ответа неправильно структурированы (JSON или XML);
+
+**Контрактное тестирование API**
+
+В общем случае контрактное тестирование или Consumer Driven Contract (CDC) является связующим звеном между модульным и интеграционным тестированием.
+
+Каждый интерфейс имеет поставщика (supplier) и потребителя (consumer). Само собой, сервисы поставщика и потребителя распределены между разными командами, мы оказываемся в ситуации, когда четко прописанный интерфейс между ними (или контракт) просто необходим. Обычно многие подходят к этой проблеме следующим образом:
+
+* Пишут подробное описание спецификации интерфейса - контракт;
+* Реализуют сервис поставщика согласно спецификации;
+* Передают спецификацию интерфейса потребителю;
+* Ждут реализации от другой стороны;
+* Запускают ручные системные тесты, чтобы всё проверить;
+* Держат кулачки, что обе стороны будут вечно соблюдать описанный интерфейс;
+
+Сегодня многие компании заменили последние два шага на автоматизированные контрактные тесты, которые регулярно проверяют соответствие описания и реализации у поставщика и потребителя определенного контракта. Что является набором регрессионных тестов, которые обеспечивают раннее обнаружение отклонения от контракта.
+
+Разберемся во взаимодействии на примере REST архитектуры: поставщик создает API c некоторым endpoint, а потребитель отправляет запрос к API, например, с целью получения данных или выполнения изменений в другом приложении. Это контракт, который описывается с помощью DSL (domain-specific language). Он включает API описание в форме сценариев взаимодействия между потребителем и поставщиком. С помощью CDC выполняется тестирование клиента и API с использованием заглушек, которые собираются на основе контракта. Основной задачей CDC является сближение восприятия между командами разработчиков API и разработчиков клиента. Таким образом, участники команды потребителей пишут CDC тесты (для всех данных проекта разработки), чтобы команда поставщика смогла запустить тесты и проверить API. В итоге команда поставщика с легкостью разработает свой API, используя тесты CDC. Результатом прогона контрактных тестов является понимание, что поставщик уверен в исправной работе API у потребителя. Следует обратить внимание, что команда потребителя должна регулярно осуществлять поддержку CDC-тестов при каждом изменении, и вовремя передавать всю информацию команде поставщика. Если регулярно фиксируем неудачно выполненные CDC-тесты, то следует пойти (в буквальном смысле слова, к пострадавшей стороне теста и узнать, в рамках какой задачи были изменения (что привело к падению теста).
+
+Из того, что было описано выше, можно выделить следующие тезисы для выполнения контрактного тестирования:
+
+* Команда разработчиков (тестировщиков) со стороны потребителей пишет автоматизированные тесты с ожидаемыми параметрами со стороны потребителей.
+* Тесты передаются команде поставщика.
+* Команда поставщика запускает контрактные тесты и проверяет результат их выполнения. Если происходит падение тестов, то команды должны зафиксировать сбой и перепроверить документацию (согласованность разработки).
+
+Минусы CDC:
+
+* CDC тесты не заменяют E2E тесты. По факту я склонен отнести CDC к заглушкам, которые являются моделями реальных компонентов, но не являются ими, т.е. это еще одна абстракция, которую нужно поддерживать и применять в нужных местах (сложно реализовать сложные сценарии);
+* CDC тесты не заменяют функциональные тесты API. Лично придерживаюсь золотого правила - если убрать контракт и это не вызывает ошибки или неправильную работу клиента, то значит он не нужен. Пример: Нет необходимости проверять все коды ошибок через контракт, если клиент обрабатывает их (ошибки) одинаково. Таким образом контракт то, что важно для клиента сервиса, а не наоборот;
+* CDC тесты дороже в поддержке, чем функциональные тесты;
+* Для реализации CDC-тестов нужно использовать (изучать) отдельные инструменты тестирования - Spring Cloud Contract, PACT;
+
+**Отличие API от SDK**:
+
+SDK (software development kit) - это набор функционала (библиотек) и утилит для разработки. Собственно SDK и предоставляет реализацию некоторого API, это оболочка API's, которая упрощает работу для разработчиков.
+
+* API: набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением для использования во внешних программных продуктах. Это интерфейс, похоже на спецификацию телефонной системы или электропроводки в вашем доме. Это список того, что можно вызывать и какого ждать результата;
+* SDK: набор реальных инструментов внедрения. Это как чемодан деталей и инструментов, который позволяет вам подключиться к телефонной системе или электрической проводке. Это библиотеки, в которых реализованы вызываемые функции + файлы необходимые для подключения этих библиотек;
+
+**Тестирование API без документации/черным ящиком**:
+
+Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определитесь, насколько все плохо и какая у Вас есть информация об объекте тестирования. Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints? Если дело совсем плохо - просканируйте порты, например, с помощью netcat. Открытые порты сохраните в файл. Эта операция займет довольно много времени. Можете почитать советы по работе с Nmap и Netcat. Если Вам известен нужный порт и соответствующий endpoint - переберите все возможные HTTP методы. Начните с наиболее очевидных POST, PUT, GET. Для ускорения процесса напишите скрипт, например, на Python.В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придется перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.\
+Разработчики обычно не особо заморачиваются и закладывают минимально-необходимую информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты. Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
+
+Источники:
+
+* [API Testing Tutorial: What is API Test Automation? How to Test](https://www.guru99.com/api-testing.html)
+* [A Comprehensive API Testing Guide](https://www.softwaretestingmaterial.com/api-testing/)
+* [API Testing Tutorial: A Complete Guide For Beginners](https://www.softwaretestinghelp.com/api-testing-tutorial/#i\_Functional\_Testing)
+* [Spring Cloud Contract. Что такое контрактное тестирование и с чем его едят](https://habr.com/ru/company/testit-tms/blog/570544/)
+* [Чем отличается api от sdk?](https://ru.stackoverflow.com/questions/796323/%D0%A7%D0%B5%D0%BC-%D0%BE%D1%82%D0%BB%D0%B8%D1%87%D0%B0%D0%B5%D1%82%D1%81%D1%8F-api-%D0%BE%D1%82-sdk/796340#796340)
+* [Тестирование API без документации](https://www.andreyolegovich.ru/testing/api\_testing.php#nospec)
+
+Доп. материал:
+
+* [Игорь Гольшмидт. АPI тестирование без документации](https://www.youtube.com/watch?v=9VnBVmo1Muc)
+* [Курс Тестирование ПО. Занятие 29. Тестирование API - QA START UP](https://www.youtube.com/watch?v=7D7AMmgxt\_I\&t=1540s\&ab\_channel=QASTARTUP-ITTrainingCenter)
+* [Курс Тестировщика с нуля / 27 урок/ Тестирование API с помощью Postman](https://www.youtube.com/watch?v=vBkEptmug7c)
+* [Rest Assured и Postman - два подхода к тестированию API](https://testit.software/blog/post/rest-assured-i-postman-dva-podhoda-k-testirovaniyu-api)
+* [Эвристики и мнемоники в тестировании: шаблоны для тестирования API](https://dou.ua/lenta/columns/testing-heuristics-mnemonics-2/)
+* [От шока до принятия: пять стадий тестирования API](https://dou.ua/lenta/columns/api-testing-stages/)
+* [Тестирование API](https://software-testing.ru/library/testing/testing-automation/3382-api-testing)
+* [Swagger/OpenAPI Specification как основа для ваших приемочных тестов](https://habr.com/ru/company/jugru/blog/525298/)
+* [История одного сервера и тестировщика Васи](https://habr.com/ru/company/nix/blog/534156/)
+* [What Is an API?](https://www.howtogeek.com/343877/what-is-an-api/)
+* [Тестирование API простыми словами за 8 минут / Тестировщик API](https://www.youtube.com/watch?v=kUPWQMalWNk\&feature=youtu.be\&ab\_channel=ArtsiomRusauQALife)
+* [Тестирование Web API - From Zero To Hero](https://beqa.pro/blog/all-you-need-for-api-testing/#learn-api-testing-roadmap)
+* [Стратегия тестирования REST API: что именно вам нужно тестировать?](https://habr.com/ru/post/568360/)
+* [Test Design and Automation for Rest API. Part 1. Иван Катунов. Comaqa Spring 2018](https://www.youtube.com/watch?v=VTVx5Rx6rsY) + [Test Design and Automation for Rest API. Part 2. Иван Катунов. Comaqa Spring 2018](https://www.youtube.com/watch?v=Tq2thhEiQJE) + [pdf](https://testconf.ru/wp-content/uploads/2018/04/6-H1-19-%D0%98%D0%B2%D0%B0%D0%BD-%D0%9A%D0%B0%D1%82%D1%83%D0%BD%D0%BE%D0%B2-Test-Design-and-Automation-for-REST-API\_TestConf-min.pdf)
+* [What is the Difference Between an API and an SDK?](https://nordicapis.com/what-is-the-difference-between-an-api-and-an-sdk/)
+* [Introduction to API Testing](https://docs.katalon.com/katalon-studio/docs/introduction\_api\_testing.html)
+* [19:05 «Контрактное тестирование Rest API»](https://www.youtube.com/watch?v=1cdMYN\_u4lA\&t=1145s) + [презентация](https://drive.google.com/drive/folders/1WERT2pCAJ73qdFaXredTSEmClPuSNs6N)
+* [Организация контрактного тестирования микросервисов и графического портала](https://automated-testing.info/t/organizacziya-kontraktnogo-testirovaniya-mikroservisov-i-graficheskogo-portala/22763)
+* [Introduction To Contract Testing With Examples](https://www.softwaretestinghelp.com/contract-testing/)
+* [Микросервисы для разработчиков Java: Контрактное тестирование](https://coderlessons.com/articles/programmirovanie/mikroservisy-dlia-razrabotchikov-java-testirovanie#:\~:text=7.-,%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D0%BE%D0%B5%20%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5,-%D0%92%20%D1%81%D0%BB%D0%B0%D0%B1%D0%BE%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BD%D0%BE%D0%B9)
+* [Как тестировать GraphQL API? Гайд для начинающих](https://testengineer.ru/kak-testirovat-graphql-api/)
+* [Что такое API](https://telegra.ph/CHto-takoe-API-11-01)
+* [Что такое API](http://okiseleva.blogspot.com/2019/08/api.html?m=1)
+* [Как передать в API фото формата base64](https://www.youtube.com/watch?v=Nstuin6XfxE)
+* [API: под каким углом на них смотреть](https://www.youtube.com/watch?v=rin-PKE7-9Q)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-bezopasnosti-security-and-access-control-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-bezopasnosti-security-and-access-control-testing.md
new file mode 100644
index 0000000..71154d4
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-bezopasnosti-security-and-access-control-testing.md
@@ -0,0 +1,126 @@
+# Тестирование безопасности (Security and Access Control testing)
+
+Это тип тестирования ПО, который выявляет уязвимости, угрозы и риски. Целью тестов безопасности является выявление всех возможных лазеек и слабых мест в ПО, которые могут привести к потере информации, доходов, репутации компании, сотрудников или клиентов. Общая стратегия безопасности основывается на трех основных принципах:
+
+* Конфиденциальность - сокрытие определенных ресурсов или информации;
+* Целостность - ресурс может быть изменен только в соответствии с полномочиями пользователя;
+* Доступность - ресурсы должны быть доступны только авторизованному пользователю, внутреннему объекту или устройству;
+
+Тестирование безопасности обычно выполняет отдельный специалист по безопасности. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:
+
+* попытки узнать пароль с помощью внешних средств;
+* атака системы с помощью специальных утилит, анализирующих защиты;
+* перегрузка системы (в надежде, что она откажется обслуживать других клиентов);
+* целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;
+* просмотр несекретных данных в надежде найти ключ для входа в систему;
+
+При неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему. Задача проектировщика системы - сделать цену проникновения более высокой, чем цена получаемой в результате информации.
+
+**Типы тестирования безопасности**:
+
+* Сканирование уязвимостей/оценка защищенности (Vulnerability Scanning) выполняется с помощью автоматизированного ПО для сканирования системы на наличие известных сигнатур уязвимостей;
+* Сканирование безопасности (Security Scanning) включает в себя выявление слабых сторон сети и системы, а затем предоставляет решения для снижения этих рисков. Это сканирование может быть выполнено как вручную, так и автоматизированно;
+* Тестирование на проникновение (Penetration testing) имитирует атаку злоумышленника. Это тестирование включает анализ конкретной системы для проверки потенциальных уязвимостей при попытке внешнего взлома;
+* Оценка рисков (Risk Assessment) включает анализ рисков безопасности, наблюдаемых в организации. Риски классифицируются как Низкие, Средние и Высокие. Это тестирование рекомендует меры по снижению риска;
+* Аудит безопасности (Security Auditing) - внутренняя проверка приложений и операционных систем на наличие уязвимостей. Аудит также может быть выполнен путем построчной проверки кода;
+* Этический взлом (Ethical hacking) - совершается с целью выявления проблем безопасности в системе. Это делается White Hat хакерами - это специалисты по безопасности, которые использует свои навыки законным способом для помощи в выявлении уязвимостей системы, в отличии от Black Hat (преступников);
+* Оценка состояния (Posture Assessment) объединяет сканирование безопасности, этический взлом и оценки рисков, чтобы показать общее состояние безопасности организации;
+
+| SDLC фаза | Security Processes |
+| ----------------------- | --------------------------------------------------------------------------------------------------------------- |
+| Requirements | Анализ безопасности для требований и проверка случаев злоупотребления / неправильного использования |
+| Design | Анализ рисков безопасности для проектирования. Разработка плана тестирования с учетом тестирования безопасности |
+| Coding and Unit testing | Статическое и динамическое тестирование безопасности и тестирование белого ящика |
+| Integration testing | Тестирование черного ящика |
+| System testing | Тестирование черного ящика и сканирование уязвимостей |
+| Implementation | Тестирование на проникновение, сканирование уязвимостей |
+| Support | Анализ воздействия патчей |
+
+Тестирование безопасности может выполняться методом любого ящика, а также Tiger Box: этот взлом обычно выполняется на ноутбуке с набором операционных систем и инструментов для взлома. Это тестирование помогает тестерам на проникновение и тестерам безопасности проводить оценку уязвимостей и атаки.
+
+**Методы тестирования безопасности**:
+
+**Доступ к приложению**. Будь то настольное приложение или веб-сайт, безопасность доступа обеспечивается функцией «Управление ролями и правами». Часто это делается неявно при описании функциональности, Например, в системе управления больницей администратор меньше всего беспокоится о лабораторных исследованиях, поскольку его работа состоит в том, чтобы просто зарегистрировать пациентов и назначить их встречи с врачами. Таким образом, все меню, формы и экраны, относящиеся к лабораторным тестам, не будут доступны для роли «регистратора». Следовательно, правильная реализация ролей и прав гарантирует безопасность доступа.
+
+Как протестировать доступ к приложению: Чтобы это проверить, необходимо выполнить тщательное тестирование всех ролей и прав. Тестировщик должен создать несколько учетных записей пользователей с разными, а также с несколькими ролями. Затем он должен использовать приложение с помощью этих учетных записей и убедиться, что каждая роль имеет доступ только к своим собственным модулям, экранам, формам и меню. Если тестировщик обнаруживает конфликт, он должен с полной уверенностью зарегистрировать проблему безопасности. Некоторые из тестов аутентификации включают в себя проверку правил качества пароля, проверку входа в систему по умолчанию, проверку восстановления пароля, проверку проверки подлинности, проверку функциональности выхода, проверку смены пароля, проверку контрольного вопроса / ответа и т. д. Аналогичным образом, некоторые из тестов авторизации включают в себя тест на обход пути, тест на отсутствие авторизации, тест на проблемы горизонтального контроля доступа и т. д.
+
+**Защита данных**. Есть три аспекта безопасности данных. Во-первых, пользователь может просматривать или использовать только те данные, которые он должен использовать. Это также обеспечивается ролями и правами. Например, TSR (представитель по телефону) компании может просматривать данные об имеющихся запасах, но не может видеть, сколько сырья было закуплено для производства. Итак, этот аспект тестирования безопасности уже объяснен выше. Второй аспект защиты данных связан с тем, [как эти данные хранятся в БД](https://www.softwaretestinghelp.com/database-security-testing/). Все конфиденциальные данные должны быть зашифрованы, чтобы сделать их безопасными. Шифрование должно быть надежным, особенно для конфиденциальных данных, таких как пароли учетных записей пользователей, номера кредитных карт или другой критически важной для бизнеса информации. Третий и последний аспект является продолжением этого второго аспекта. При передаче конфиденциальных или важных для бизнеса данных необходимо принять надлежащие меры безопасности. Независимо от того, перемещаются ли эти данные между разными модулями одного и того же приложения или передаются в разные приложения, они должны быть зашифрованы для обеспечения безопасности.
+
+Как протестировать защиту данных: Тестировщик должен запросить в базе данных «пароли» учетной записи пользователя, информацию о выставлении счетов клиентов, другие важные для бизнеса и конфиденциальные данные и убедиться, что все такие данные хранятся в зашифрованной форме. Точно так же он должен убедиться, что данные передаются между различными формами или экранами только после надлежащего шифрования. Более того, тестировщик должен убедиться, что зашифрованные данные должным образом расшифрованы в месте назначения. Особое внимание следует уделить различным действиям «отправить». Тестировщик должен убедиться, что информация, передаваемая между клиентом и сервером, не отображается в адресной строке веб-браузера в понятном формате. Если какая-либо из этих проверок завершится неудачно, значит, в приложении определенно есть баги безопасности. Тестировщик также должен проверить правильность использования соления (salting - добавление дополнительного секретного значения к конечному вводу, например пароля, что делает его более надежным и трудным для взлома). Небезопасная случайность также должна быть проверена, поскольку это своего рода уязвимость. Другой способ проверить защиту данных - проверить использование слабого алгоритма. Например, поскольку HTTP - это протокол открытого текста, если конфиденциальные данные, такие как учетные данные пользователя, передаются через HTTP, то это угроза безопасности приложения. Вместо HTTP конфиденциальные данные следует передавать через HTTPS (защищенный через SSL, туннель TLS). Однако HTTPS увеличивает поверхность атаки, поэтому необходимо проверить правильность конфигурации сервера и гарантировать действительность сертификата;
+
+**Атака грубой силы** (Brute-Force Attack, атака полным перебором) в основном выполняется некоторыми программными инструментами. Идея состоит в том, что, используя действительный идентификатор пользователя, программное обеспечение пытается подобрать связанный пароль, пытаясь войти в систему снова и снова. Простым примером защиты от такой атаки является приостановка учетной записи на короткий период времени, как это делают все почтовые приложения, такие как Yahoo, Gmail и Hotmail. Если определенное количество последовательных попыток (в основном 3) не позволяют войти в систему, эта учетная запись блокируется на некоторое время (от 30 минут до 24 часов).
+
+Как протестировать атаку грубой силы: Тестировщик должен убедиться, что какой-то механизм блокировки учетной записи доступен и работает правильно. Он должен попытаться войти в систему с недопустимыми идентификаторами пользователя и паролями, в качестве альтернативы, чтобы убедиться, что программное обеспечение блокирует учетные записи, если предпринимаются постоянные попытки входа с недопустимыми учетными данными. Если приложение делает это, оно защищено от атаки методом перебора. В противном случае тестировщик должен сообщить об этой уязвимости системы безопасности. Тестирование перебором также можно разделить на две части - тестирование черного ящика и тестирование серого ящика. При тестировании «черного ящика» метод аутентификации, используемый приложением, обнаруживается и тестируется. Тестирование серого ящика основано на частичном знании пароля и данных учетной записи, а также на атаках компромисса памяти ([подробнее](https://wiki.owasp.org/index.php/Testing\_for\_Brute\_Force\_\(OWASP-AT-004\)#Gray\_Box\_testing\_and\_example)).
+
+Вышеупомянутые три аспекта безопасности следует учитывать как для веб-приложений, так и для настольных приложений, в то время как **следующие моменты относятся только к веб-приложениям**.
+
+[**SQL-инъекции**](https://owasp.org/www-community/attacks/SQL\_Injection#Alternative\_Expression\_of\_.27or\_1\_.3D\_1.27) **и** [**XSS**](https://cheatsheetseries.owasp.org/cheatsheets/Cross\_Site\_Scripting\_Prevention\_Cheat\_Sheet.html) (межсайтовый скриптинг). С концептуальной точки зрения, темы обеих попыток взлома схожи, поэтому они обсуждаются вместе. В этом подходе вредоносный сценарий используется хакерами для манипулирования веб-сайтом. Есть несколько способов застраховаться от таких попыток. Для всех полей ввода веб-сайта длины полей должны быть достаточно малыми, чтобы ограничить ввод любого скрипта. Например, поле «Фамилия» должно иметь длину поля 30 вместо 255. Могут быть некоторые поля ввода, в которых требуется ввод больших данных, для таких полей необходимо выполнить правильную проверку ввода до сохранения этих данных в приложении. Более того, в таких полях должны быть запрещены любые HTML-теги или ввод тегов скрипта. Чтобы спровоцировать XSS-атаки, приложение должно отклонять перенаправления скриптов от неизвестных или ненадежных приложений.
+
+Как тестировать SQL-инъекцию и XSS: Тестер должен убедиться, что максимальная длина всех полей ввода определена и реализована. Он также должен гарантировать, что заданная длина полей ввода не соответствует вводу сценария, а также вводу тега. Оба они могут быть легко протестированы. Например, если 20 - максимальная длина, указанная для поля «Имя», а входная строка «\
thequickbrownfoxjumpsoverthelazydog» можно проверить оба этих ограничения. Тестировщик также должен убедиться, что приложение не поддерживает методы анонимного доступа. Если какая-либо из этих уязвимостей существует, приложение находится в опасности. В основном, тестирование SQL-инъекции может быть выполнено следующими пятью способами:
+
+* Методы обнаружения;
+* Стандартные техники SQL-инъекций;
+* [Отпечаток базы данных](https://www.sqlinjection.net/database-fingerprinting/);
+* Эксплойты;
+* [Методы внедрения в сигнатуру SQL-инъекции](https://www.imperva.com/docs/IMPERVA\_HII\_SQL-Injection-Signatures-Evasion.pdf) (SQL Injection Signature Invasion Techniques);
+
+**Точки доступа к сервису** (закрытые и безопасные открытые).
+
+
+
+Сегодня компании зависят друг от друга и сотрудничают друг с другом, то же самое относится и к приложениям, особенно к веб-сайтам. В таком случае оба участника должны определить и опубликовать несколько точек доступа друг для друга. Пока сценарий кажется довольно простым и понятным, но для некоторых веб-продуктов, таких как торговля акциями, все не так просто и легко. Когда существует большое количество целевой аудитории, точки доступа должны быть достаточно открытыми, чтобы облегчить работу всех пользователей, достаточно приспособленными для выполнения всех запросов пользователей и достаточно безопасными, чтобы справиться с любой опасностью.
+
+Как протестировать точки доступа к сервису (Service Access Points): позвольте мне объяснить это на примере веб-приложения для торговли акциями; инвестор (желающий приобрести акции) должен иметь доступ к текущим и историческим данным о ценах на акции. Это требует, чтобы приложение было достаточно открытым. Под удобством и безопасностью я подразумеваю, что приложение должно облегчить инвесторам возможность свободно торговать (в соответствии с законом). Они могут покупать или продавать 24/7, и данные транзакций должны быть защищены от любых хакерских атак. Более того, большое количество пользователей будет взаимодействовать с приложением одновременно, поэтому приложение должно предоставлять достаточно точек доступа, чтобы удовлетворить всех пользователей. В некоторых случаях эти точки доступа могут быть закрыты для нежелательных приложений или людей. Это зависит от бизнес-домена приложения и его пользователей, например, настраиваемая веб-система управления офисом может распознавать своих пользователей на основе IP-адресов и отказывать в установлении соединения со всеми другими системами (приложениями), которые не попадают в диапазон допустимых IP-адресов для этого приложения. Тестировщик должен гарантировать, что весь межсетевой и внутрисетевой доступ к приложению осуществляется доверенными приложениями, машинами (IP) и пользователями. Чтобы убедиться, что открытая точка доступа достаточно безопасна, тестировщик должен попытаться получить к ней доступ с разных машин, имеющих как доверенные, так и ненадежные IP-адреса. Следует опробовать различные типы транзакций в реальном времени сразу, чтобы быть уверенным в производительности приложения. Таким образом, пропускная способность точек доступа приложения также будет четко отслеживаться. Тестировщик должен убедиться, что приложение обрабатывает все запросы связи от доверенных IP-адресов и приложений только тогда, когда все остальные запросы отклоняются. Точно так же, если в приложении есть открытая точка доступа, тестировщик должен убедиться, что она разрешает (при необходимости) загрузку данных пользователями безопасным способом. Под этим безопасным способом я имею в виду ограничение размера файла, ограничение типа файла и сканирование загруженного файла на вирусы или другие угрозы безопасности.
+
+**Управление сессией**. Веб-сеанс - это последовательность транзакций HTTP-запроса и ответа, связанных с одним и тем же пользователем. Тесты управления сеансом проверяют, как управление сеансом обрабатывается в веб-приложении. Вы можете проверить истечение срока действия сеанса после определенного времени простоя, завершение сеанса после максимального времени жизни, завершение сеанса после выхода из системы, проверить объем и продолжительность сеанса cookie, проверить, может ли один пользователь иметь несколько одновременных сеансов и т. д.
+
+**Обработка ошибок.** Тестирование на обработку ошибок включает:
+
+* проверку кодов ошибок, которые возвращаются с подробным сообщением. Эти сообщения не должны содержать критической информации, которая может быть использована для взлома;
+* проверку трассировки стека: в основном это включает в себя передачу в приложение некоторых исключительных данных, так что возвращаемое сообщение об ошибке содержит трассировки стека, которые содержат интересную информацию для хакеров;
+
+**Конкретные опасные функции.** В основном, две рискованные функции - это платежи и загрузка файлов. Эти функции следует очень хорошо протестировать. Для загрузки файлов вам необходимо в первую очередь проверить, ограничена ли загрузка нежелательных или вредоносных файлов. Для платежей вам необходимо в первую очередь протестировать на наличие уязвимостей инъекций, небезопасного криптографического хранилища, переполнения буфера, подбора пароля и т. д.
+
+Источники:
+
+* [What is Security Testing? Types with Example](https://www.guru99.com/what-is-security-testing.html)
+* [Security Testing (A Complete Guide)](https://www.softwaretestinghelp.com/how-to-test-application-security-web-and-desktop-application-security-testing-techniques/)
+
+Доп. материал:
+
+* [Список книг по наступательной информационной безопасности](https://habr.com/ru/company/vk/blog/282700/)
+* [Топ-10 уязвимостей мобильных приложений и способы их устранения](https://habr.com/ru/company/ruvds/blog/537456/)
+* [Безопасность веб-приложений: от уязвимостей до мониторинга](https://habr.com/ru/post/526878/)
+* [Социотехническое тестирование: какое лучше выбрать в 2021 году?](https://habr.com/ru/company/group-ib/blog/535092/)
+* [Анализ безопасности веб-проектов](https://www.youtube.com/playlist?list=PLrCZzMib1e9owORdnWTvZIkSCqRFFbHGA)
+* [Безопасность интернет-приложений](https://www.youtube.com/playlist?list=PLrCZzMib1e9qiiSWgZ6pI5HiQzFc4hhdo)
+* [Red Teaming - комплексная имитация атак. Методология и инструменты](https://habr.com/ru/company/varonis/blog/524308/)
+* [cHack](https://www.youtube.com/channel/UCGfxztXUoBeGNVv6UTpUQHw/videos)
+* [OWASP Top Ten](https://owasp.org/www-project-top-ten/)
+* [SQL-инъекции' union select null,null,null --](https://habr.com/ru/post/542190/)
+* [Чек-лист устранения SQL-инъекций](https://habr.com/ru/company/pentestit/blog/546232/)
+* [Что такое XSS-уязвимость и как тестировщику не пропустить ее](https://www.software-testing.ru/library/testing/security/3398-ross-site-scripting)
+* [What Is Database Security Testing - Complete Guide](https://www.softwaretestinghelp.com/database-security-testing/)
+* [QA-митап Redmadrobot 19/11, QA vs Hackers: безопасность в web, Вика Бегенчева](https://www.youtube.com/watch?v=AXD0eyTGbBM)
+* [Как я получил награду Facebook по баунти-программе дважды](https://habr.com/ru/company/timeweb/blog/549864/)
+* [Безопасность REST API от А до ПИ](https://habr.com/ru/post/503284/)
+* [Тестирование безопасности API - Катерина Овеченко. QA Fest 2019](https://www.youtube.com/watch?v=46N\_zodwzKA)
+* [Как провести тестирование на безопасность: руководство для Manual QA](https://dou.ua/lenta/articles/security-testing-vulnerabilities/)
+* [Типы атак и уязвимостей](https://docs.wallarm.ru/attacks-vulns-list/)
+* [Open Web Application Security Project (OWASP) TOP 10 2017](https://owasp.org/www-project-top-ten/2017/#)
+* [Что такое OWASP Top-10 и как использовать указанные риски и уязвимости](https://blog.themarfa.name/chto-takoie-owasp-top-10-i-kak-ispolzovat-ukazannyie-riski-i-uiazvimosti/)
+* [SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL\_Injection\_Prevention\_Cheat\_Sheet.html)
+* [Web Authentication, Session Management, and Access Control Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session\_Management\_Cheat\_Sheet.html)
+* [Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot\_Password\_Cheat\_Sheet.html)
+* [Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication\_Cheat\_Sheet.html)
+* [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password\_Storage\_Cheat\_Sheet.html)
+* [Cross Site Scripting (XSS) Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross\_Site\_Scripting\_Prevention\_Cheat\_Sheet.html)
+* [Unvalidated Redirects and Forwards Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated\_Redirects\_and\_Forwards\_Cheat\_Sheet.html)
+* [Безопасность iOS-приложений: гайд для новичков](https://habr.com/ru/company/wrike/blog/544754/)
+* [Уязвимости Android 2020](https://habr.com/ru/company/otus/blog/547160/)
+* [Обман обманщиков: форк-бомба нового уровня](https://habr.com/ru/company/ruvds/blog/554158/)
+* [Software security](https://www.synopsys.com/blogs/software-security/software-security/)
+* [When might you need security testing?](https://www.softwaretestingnews.co.uk/when-might-you-need-security-testing/)
+* [Иван Румак - Эффективный поиск XSS-уязвимостей](https://www.youtube.com/watch?v=EmJnUqFgaK8)
+* [Тестирование безопасности / OWASP TOP 10 уязвимостей](https://www.youtube.com/watch?v=fgtuLbT4joI)
+* [TOP 10 уязвимостей 2020 by HackerOne](https://habr.com/ru/company/otus/blog/526768/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-dokumentacii-documentation-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-dokumentacii-documentation-testing.md
new file mode 100644
index 0000000..968a7d1
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-dokumentacii-documentation-testing.md
@@ -0,0 +1,42 @@
+# Тестирование документации (Documentation testing)
+
+Плохая документация может повлиять на качество продукта. Тестирование артефактов, разработанных до, во время и после тестирования продукта, называется тестированием документации. Это нефункциональный тип тестирования программного обеспечения. Мы знаем, что дефекты, обнаруженные на этапе тестирования, более дорогостоящие, чем если бы они были обнаружены на этапе требований. Стоимость исправления ошибки увеличивается тем больше, чем позже вы найдете ее. Таким образом, тестирование документации может начаться с самого начала процесса разработки программного обеспечения, чтобы сэкономить большую сумму денег. Некоторые часто проверяемые артефакты:
+
+* Requirement documents
+* Test Plan
+* Test case
+* Traceability Matrix (RTM)
+
+**Техники тестирования требований:**
+
+**Взаимный просмотр** (peer review). Взаимный просмотр («рецензирование») является одной из наиболее активно используемых техник тестирования требований и может быть представлен в одной из трех следующих форм (по мере нарастания его сложности и цены):
+
+* Беглый просмотр (walkthrough) может выражаться как в показе автором своей работы коллегам с целью создания общего понимания и получения обратной связи, так и в простом обмене результатами работы между двумя и более авторами с тем, чтобы коллега высказал свои вопросы и замечания. Это самый быстрый, дешевый и часто используемый вид просмотра. Для запоминания: аналог беглого просмотра - это ситуация, когда вы в школе с одноклассниками проверяли перед сдачей сочинения друг друга, чтобы найти описки и ошибки.
+* Технический просмотр (technical review) выполняется группой специалистов. В идеальной ситуации каждый специалист должен представлять свою область знаний. Тестируемый продукт не может считаться достаточно качественным, пока хотя бы у одного просматривающего остаются замечания. Для запоминания: аналог технического просмотра - это ситуация, когда некий договор визирует юридический отдел, бухгалтерия и т.д.
+* Формальная инспекция (inspection) представляет собой структурированный, систематизированный и документируемый подход к анализу документации. Для его выполнения привлекается большое количество специалистов, само выполнение занимает достаточно много времени, и потому этот вариант просмотра используется достаточно редко (как правило, при получении на сопровождение и доработку проекта, созданием которого ранее занималась другая компания). Для запоминания: аналог формальной инспекции - это ситуация генеральной уборки квартиры (включая содержимое всех шкафов, холодильника, кладовки и т.д.).
+
+**Вопросы**. Следующей очевидной техникой тестирования и повышения качества требований является (повторное) использование техник выявления требований, а также (как отдельный вид деятельности) - задавание вопросов. Если хоть что-то в требованиях вызывает у вас непонимание или подозрение - задавайте вопросы. Можно спросить представителей заказчика, можно обратиться к справочной информации. По многим вопросам можно обратиться к более опытным коллегам при условии, что у них имеется соответствующая информация, ранее полученная от заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы полученный ответ позволил улучшить требования;
+
+**Тест-кейсы и чек-листы**. Мы помним, что хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет нам определить, насколько требование проверяемо. Если вы можете быстро придумать несколько пунктов чек-листа, это ещё не признак того, что с требованием всё хорошо (например, оно может противоречить каким-то другим требованиям). Но если никаких идей по тестированию требования в голову не приходит - это тревожный знак. Рекомендуется для начала убедиться, что вы понимаете требование (в том числе прочесть соседние требования, задать вопросы коллегам и т.д.). Также можно пока отложить работу с данным конкретным требованием и вернуться к нему позднее - возможно, анализ других требований позволит вам лучше понять и это конкретное. Но если ничто не помогает - скорее всего, с требованием что-то не так. Справедливости ради надо отметить, что на начальном этапе проработки требований такие случаи встречаются очень часто - требования сформированы очень поверхностно, расплывчато и явно нуждаются в доработке, т.е. здесь нет необходимости проводить сложный анализ, чтобы констатировать непроверяемость требования. На стадии же, когда требования уже хорошо сформулированы и протестированы, вы можете продолжать использовать эту технику, совмещая разработку тест-кейсов и дополнительное тестирование требований.
+
+**Исследование поведения системы**. Эта техника логически вытекает из предыдущей (продумывания тест-кейсов и чек-листов), но отличается тем, что здесь тестированию подвергается, как правило, не одно требование, а целый набор. Тестировщик мысленно моделирует процесс работы пользователя с системой, созданной по тестируемым требованиям, и ищет неоднозначные или вовсе неописанные варианты поведения системы. Этот подход сложен, требует достаточной квалификации тестировщика, но способен выявить нетривиальные недоработки, которые почти невозможно заметить, тестируя требования по отдельности.
+
+**Рисунки (графическое представление)**. Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т.д. Графическое представление удобно одновременно своей наглядностью и краткостью (например, UML-схема базы данных, занимающая один экран, может быть описана несколькими десятками страниц текста). На рисунке очень легко заметить, что какие-то элементы «не стыкуются», что где-то чего-то не хватает и т.д. Если вы для графического представления требований будете использовать общепринятую нотацию (например, уже упомянутый UML), вы получите дополнительные преимущества: вашу схему смогут без труда понимать и дорабатывать коллеги, а в итоге может получиться хорошее дополнение к текстовой форме представления требований.
+
+**Прототипирование**. Можно сказать, что прототипирование часто является следствием создания графического представления и анализа поведения системы. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется, что реализованное в прототипе (возможно, с небольшими доработками) устраивает заказчика.
+
+Подробный разбор примера тестирования требований можно прочитать в книге Святослава Куликова “Тестирование программного обеспечения. Базовый курс” в разделе 2.2.7. “Пример анализа и тестирования требований”.
+
+Источники:
+
+* [What is Documentation Testing in Software Testing](https://www.softwaretestingmaterial.com/documentation-testing-in-software-testing/)
+* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software\_testing\_book/). Глава 2.
+
+Доп. материал:
+
+* [Как тестировать документацию. Простой алгоритм](https://habr.com/ru/post/595773/)
+* [Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят](https://habr.com/ru/company/plesk/blog/550550/)
+* [Чек-лист тестирования требований](https://habr.com/ru/post/543340/)
+* [Как тестировать документацию. Простой алгоритм](https://habr.com/ru/post/595773/)
+* [Тестировщик с нуля / Урок 4 / Тестирование требований](https://www.youtube.com/watch?v=JY55bMex9Hw)
+* [Не все проверки бесполезны или несколько способов ревизии требований](https://www.youtube.com/watch?v=hfYlf2XGoIw)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-dostupnosti-accessibility-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-dostupnosti-accessibility-testing.md
new file mode 100644
index 0000000..01e9098
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-dostupnosti-accessibility-testing.md
@@ -0,0 +1,63 @@
+# Тестирование доступности (Accessibility testing)
+
+_Тестирование доступности (accessibility testing): Тестирование, которое определяет степень легкости, с которой пользователи с ограниченными способностями могут использовать систему или ее компоненты (ISTQB)._
+
+_Тестирование доступности (accessibility testing): Тип тестирования удобства использования, предназначенный для оценки степени возможности управления элементом тестирования пользователями с самыми разными характеристиками и способностями. (ГОСТ 56920)_
+
+Тестирование доступности (accessibility testing) - это подмножество юзабилити-тестирования. Его цель - убедиться в том, что наш продукт удобен в использовании людям с различными видами ограничений, инвалидности или особенностями восприятия. Это могут быть проблемы со зрением, слухом или ограничения в подвижности рук. Что наиболее важно, существуют определенные законы и инструкции по тестированию доступности, которые также должны соблюдаться, например, Рекомендации по доступности веб-контента ([Web content accessibility guidelines](https://www.w3.org/TR/WCAG21/)). Ваш продукт должен правильно работать с соответствующим ПО. Примеры такого программного обеспечения:
+
+* Speech Recognition Software - ПО преобразует произнесенное слово в текст, который служит вводом для компьютера;
+* Программа для чтения с экрана - используется для озвучивания текста, отображаемого на экране;
+* Программное обеспечение для увеличения экрана - используется для увеличения масштаба элементов и облегчения чтения для пользователей с нарушениями зрения;
+* Специальная клавиатура, облегчающая ввод для пользователей, у которых проблемы с двигательными функциями;
+
+Еще один из примеров - люди с цветовой слепотой (дальтонизмом). Эта особенность довольно широко распространена. Различными видами цветовой слепоты страдают около 8 % мужчин и 0,4 % женщин - не так уж мало!
+
+Цвет не должен быть единственным способом передачи информации. Если вы используете цвет для того, чтобы, допустим, отобразить статус, эту информацию стоит продублировать еще каким-то образом - геометрическими фигурами, иконками или текстовым комментарием.\
+Хорошая контрастность. Хорошая контрастность обеспечивает нормальную видимость элементов управления и текста даже для людей, не различающих те или иные оттенки.\
+Есть отличный инструмент для тестирования веб-сайтов на предмет доступности для людей с различными формами цветовой слепоты: Color Blind Web Page Filter.
+
+
+
+Если вы хотите сократить количество тестов, можно ограничиться только тремя фильтрами: дейтеранопия, протанопия и тританопия. Это наиболее выраженные формы цветовой слепоты (не считая крайне редкого черно-белого зрения). Остальные люди с особенностями цветовосприятия видят больше оттенков, и если ваш UI достаточно хорошо виден с этими тремя фильтрами, то и для остальных будет отображаться корректно.
+
+Пример чек-листа:
+
+* Предоставляет ли приложение клавиатурные эквиваленты для всех действий мышью и окон?
+* Предоставляются ли инструкции как часть пользовательской документации или руководства? Легко ли понять и использовать приложение, используя документацию?
+* Упорядочены ли вкладки логически для обеспечения плавной навигации?
+* Предусмотрены ли сочетания клавиш для меню?
+* Поддерживает ли приложение все операционные системы?
+* Четко ли указано время отклика каждого экрана или страницы, чтобы конечные пользователи знали, как долго ждать?
+* Все ли надписи правильно написаны?
+* Являются ли цвета подходящим для всех пользователей?
+* Правильно ли используются изображения или значки, чтобы их было легко понять конечным пользователям?
+* Есть ли звуковые оповещения?
+* Может ли пользователь настроить аудио или видео элементы управления?
+* Может ли пользователь переопределить шрифты по умолчанию для печати и отображения текста?
+* Может ли пользователь настроить или отключить мигание, вращение или перемещение элементов?
+* Убедитесь, что цветовое кодирование никогда не используется в качестве единственного средства передачи информации или указания на действие
+* Видна ли подсветка с инвертированными цветами?
+* Тестирование цвета в приложении путем изменения контрастности
+* Правильно ли слышат люди с ограниченными возможностями все имеющее отношение к аудио и видео?
+* Протестируйте все мультимедийные страницы без мультимедиа-оборудования.
+* Предоставляется ли обучение пользователям с ограниченными возможностями, что позволит им ознакомиться с программным обеспечением или приложением?
+
+Источники:
+
+* [Accessibility Testing Tutorial (A Complete Step By Step Guide)](https://www.softwaretestinghelp.com/what-is-web-accessibility-testing/)
+* [Accessibility Testing Tutorial: What is, Tools & Examples](https://www.guru99.com/accessibility-testing.html)
+
+Доп. материал:
+
+* [Чеклист на соответствие гайдлайнам по доступности (WCAG)](https://www.a11yproject.com/checklist/)
+* [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/)
+* [Understanding Accessibility: WCAG’s 13 Guidelines with Kasey Bonifacio](https://www.youtube.com/watch?v=RjpvOqZigao)
+* [Accessibility Testing: Color Blindness](https://www.luxoft-training.com/news/accessibility-testing-color-blindness/)
+* [QA и его роль в создании ресурсов для людей с ограниченными возможностями](https://habr.com/ru/company/redmadrobot/blog/504110/)
+* [Чеклист по UX из 30 пунктов для мобильных приложений](https://habr.com/ru/company/edison/blog/474472/)
+* [Web Content Accessibility Guidelines](https://cdn2.hubspot.net/hubfs/5358007/WCAG\_2.1\_Checklist.pdf)
+* [Говорим о практике в области UX/UI-тестирования в Университете ИТМО - подкаст «ITMO Research»](https://habr.com/ru/company/spbifmo/blog/559964/)
+* [Accessibility Testing Tutorial: What is, Tools & Examples](https://www.guru99.com/accessibility-testing.html)
+* [Everything You Should Know About Accessibility Testing](https://blog.qatestlab.com/2021/08/18/accessibility-testing/)
+* [Тестирование доступности. Теория, инструменты и чеклист.](https://testengineer.ru/chto-takoe-testirovanie-dostupnosti/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-emkosti-capacity-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-emkosti-capacity-testing.md
new file mode 100644
index 0000000..ce4696c
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-emkosti-capacity-testing.md
@@ -0,0 +1,35 @@
+# Тестирование емкости (Capacity testing)
+
+_Тестирование потенциальных возможностей (capacity testing): Тип тестирования уровня производительности для оценки уровня, при котором с увеличением нагрузки (числа пользователей, транзакций, элементов данных и т.д.) элемент тестирования подвергается угрозе не обеспечивать требуемую производительность. (ГОСТ 56920)_
+
+Capacity - базовый тест, который обычно выполняется первым. Все последующие тесты на среднее время ответа, регенерацию системы, утилизацию ресурсов нужно выполнять с оглядкой на результаты Capacity.
+
+Тестирование емкости гарантирует, что приложение и среда могут беспрепятственно обрабатывать максимальное количество пользователей или транзакций в соответствии с требованиями к производительности, определенными в вашем соглашении об уровне обслуживания (SLA). Тестирование емкости нацелено на тестирование максимальной емкости вашей системы с точки зрения трафика, при этом обеспечивая оптимальное взаимодействие с пользователем. Общие примеры SLA по производительности включают время загрузки домашней страницы, время ответа веб-страницы, продолжительность транзакции (например, - время входа в учетную запись, время поиска и платежа). Общая цель состоит в том, чтобы идентифицировать «зону безопасности» системы и удерживать ее в максимально возможной степени. Тестирование емкости помогает определить, в какой степени она может быть расширена без ущерба для опыта конечного пользователя.
+
+Емкость системы измеряется в rps (requests per second). Используемый подход: ступенчато повышаем нагрузку до момента, когда время ответа начнет расти экспоненциально. Экспоненциальный рост времени ответа, как правило, связан с полной утилизацией одного из ресурсов, из-за которого запросы вместо моментальной обработки выстраиваются друг за другом и ждут своей очереди на обработку.
+
+
+
+Обратите внимание: от 1 до 12 rps процентиль времени ответа практически не изменяется. Только на 13 и 14 rps мы видим незначительный рост, который не изменяется с течением времени. Это значит, что мы практически исчерпали ресурс, в который упремся, но очередь еще не образуется. На 15 rps время ответа начало расти экспоненциально, значит это и есть наш предел. Таким образом, можно сделать вывод, что емкость =14 rps. Следующий шаг - поиск ресурса который исчерпался и не дает системе обрабатывать больше 14 rps.
+
+
+
+Capacity point - точка, где перестает расти пропускная способность и увеличивается время ответа.
+
+Исходя из этого тестирования выбираются значения для stress, load и soak/endurance тестов. Для stress берется значение близкое к capacity point, но немного меньше. Для load количество пользователей из зоны деградации.
+
+Важно, ваша цель - не получить кол-во rps, при котором все взрывается, а понять, какой именно ресурс станет узким местом при повышении нагрузки. Поэтому, если обстреливаемый вами сервер не покрыт мониторингом - можете даже не начинать тест. Общий подход к сбору телеметрии - чем больше метрик собирается, тем лучше. Начать стоит с минимального набора:
+
+* Основные физические, функциональные, компоненты сервера(железо): процессор, память, сеть, жесткий диск.
+* Метрики операционной системы: прерывания, переключение контекстов, среднее значение загрузки системы за 1, 5 и 15 минут.
+* Метрики программного обеспечения, используемого на сервере.
+* По возможности постарайтесь определять в каких пропорциях ресурсы используются вашим программным обеспечением.
+
+Источники:
+
+* [All You Need to Know About Capacity Testing](https://www.radview.com/blog/all-you-need-to-know-about-capacity-testing/)
+* [Тестируем производительность: как определить емкость системы](https://medium.com/@sheidaievkostiantyn/capacity-testing-273c87ff03b4)
+
+Доп. материал:
+
+* [Как оценить ёмкость сервиса и не упасть под нагрузкой](https://habr.com/ru/company/yandex/blog/481134/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-graficheskogo-interfeisa-vizualnoe-testirovanie-gui-graphical-user-interface-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-graficheskogo-interfeisa-vizualnoe-testirovanie-gui-graphical-user-interface-testing.md
new file mode 100644
index 0000000..be28072
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-graficheskogo-interfeisa-vizualnoe-testirovanie-gui-graphical-user-interface-testing.md
@@ -0,0 +1,67 @@
+# Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
+
+**Интерфейс** - это то, с помощью чего происходит “общение” между ПО и окружением. Существует два типа интерфейсов:
+
+* **Интерфейс командной строки** (CLI - Command Line Interface), где вы вводите текст в терминал, и компьютер отвечает на эту команду;
+* **Графический интерфейс пользователя** (GUI - Graphical User Interface) , где вы взаимодействуете с компьютером, используя графическое представление, а не текст;
+
+**Тестирование графического интерфейса пользователя** (GUI) проводят с целью проверить функциональность и корректность отображения интерфейса пользователя (меню, панели инструментов, цвета, шрифты, размеры, значки, контент, кнопки и т. д., как они реагируют на ввод пользователя).
+
+**Техники тестирования GUI**:
+
+* **Manual testing**: При таком подходе тестеры вручную проверяют графические экраны в соответствии с требованиями, изложенными в документе бизнес-требований (business requirements document);
+* **Capture & replay testing или Record and Replay**: Мы также можем провести тестирование графического интерфейса пользователя, используя некоторые инструменты автоматизации, разработанные специально для этого. Идея состоит в том, чтобы запустить приложение и записать взаимодействие, которое должно происходить между пользователем и самим приложением (движения мыши и т. д.), после чего эти тесты будут прогоняться, а фактический результат сравниваться с ожидаемым;
+* **Model based testing**: Модель - это графическое описание поведения системы. Это помогает нам понять и спрогнозировать поведение системы. Модели помогают в создании эффективных тестовых примеров с использованием системных требований. Процесс:
+
+ * Построение модели;
+ * Определение входных данных для модели;
+ * Расчет ожидаемых результатов для модели;
+ * Запуск тестов;
+ * Сравнение фактических результатов с ожидаемыми;
+ * Решение о дальнейших действиях по модели;
+
+ Некоторые методы моделирования, на основе которых могут быть получены тестовые примеры:
+* Графики - отображает состояние системы и проверяет состояние после некоторого ввода;
+* Таблицы решений - таблицы, используемые для определения результатов для входных данных;
+
+ Тестирование на основе моделей - это развивающийся метод создания тестовых примеров на основе требований. Его главное преимущество по сравнению с двумя вышеупомянутыми методами заключается в том, что он может определять нежелательные состояния, которых может достичь ваш графический интерфейс.
+
+**Примеры проверок**:
+
+* **Тип и размер шрифта**: шрифт одинаковый на всех экранах или хотя бы одного семейства, одинаковый размер шрифта заголовков, основного текста и т. д.;
+* **Цвета**: должны быть сочетаемы. Придерживайтесь одних цветов и следуйте гайдлайнам. Вы не можете использовать 4 разных варианта оранжевого (если только он не является частью дизайна). Посмотрите на гиперссылки, фон, кнопки, основной текст и т. д.;
+* **Стили значков**: вам не следует выбирать 5 разных стилей значков, если вы выбираете «плоские» значки, оставайтесь с плоскими значками;
+* **Визуальные несоответствия**: постоянство всегда является ключевым моментом. Внешний вид во всем приложении должен быть одинаковым. Помимо внешнего вида, аббревиатуры также должны быть последовательными;
+* **Несоответствия диалоговых окон**: если вы используете «выход» в одних диалоговых окнах, вы должны использовать «выход» в других;
+* **Обязательные поля**: всегда лучше указать, что поле является обязательным, добавив к нему звездочку и предоставив пользователю своего рода предупреждение, если данные не указаны;
+* **Ошибки типов данных**: всегда проверяйте, что указан правильный тип данных (даты, возраст, вес и т. д.);
+* **Один и тот же документ, несколько открытий**: когда документ открывается / загружается более одного раза, вместо перезаписи вы можете переименовать его, добавив номер к имени файла;
+* **Ширина полей**: очевидно, если разрешено определенное количество символов и введенные данные не должны превышать определенное число, вы должны прояснить это;
+* **Экранные инструкции:** экраны (непонятные) должны содержать какие-то экранные инструкции, которые помогут / направят пользователя;
+* **Индикаторы выполнения**: когда ждете результатов, индикаторы выполнения хороши, чтобы пользователи понимали, что им нужно чего-то ждать и что процесс все еще продолжается;
+* **Подтверждение сохранения**: если вы можете вносить изменения в приложение без необходимости сохранения, всегда полезно убедиться, что пользователь не хочет сохранять, прежде чем перейти к другому экрану;
+* **Подтверждение удаления**: поскольку мы подтверждаем сохранение, всегда полезно подтвердить, что пользователь хочет удалить элемент. Я уверен, что многие из вас (как и я) удаляли что-то на странице, не желая этого;
+* **Ввод перед Drop down list**: когда у вас есть сотни вариантов на выбор в выпадающем меню, гораздо лучше иметь возможность сначала вводить текст, чем просматривать весь список;
+* **Недопустимые параметры**: иногда чтобы выбрать какие-то параметры вам необходимо подтвердить другие. Эта опция должна отображаться как доступная, когда все требования выполнены;
+* **Пункты меню**: показывать только те пункты меню, которые доступны в данный момент, вместо отображения всех пунктов, даже если они недоступны;
+* **Сообщения об ошибках**: сообщения об ошибках должны быть информативными;
+* **Рабочие шорткаты:** если в вашем приложении есть шорткаты, убедитесь, что все они работают, независимо от того, какие браузеры используются;
+* **Разные разрешения**: проверить корректность верстки при масштабировании и на разных разрешениях;
+* **Полосы прокрутки**;
+* **Изображения**: сжатие, выравнивание и т.п.;
+* **Проверка орфографии**;
+
+Источники:
+
+* [A Guide To GUI Testing](https://apiumhub.com/tech-blog-barcelona/ui-testing/)
+* [GUI Testing Tutorial: User Interface (UI) TestCases with Examples](https://www.guru99.com/gui-testing.html)
+* [GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide](https://www.softwaretestinghelp.com/gui-testing/)
+
+Доп. материал:
+
+* [Эффективное тестирование верстки](https://habr.com/ru/company/oleg-bunin/blog/499638/)
+* [#9 Артем, Сева и Визуальное тестирование](https://www.youtube.com/watch?v=d91Ca1Yz5q0\&ab\_channel=Heisenbug)
+* [Кроссбраузерное визуальное тестирование - выбор подходящего инструмента для дизайн-системы NewsKit](https://telegra.ph/Krossbrauzernoe-vizualnoe-testirovanie---vybor-podhodyashchego-instrumenta-dlya-dizajn-sistemy-NewsKit-03-31)
+* [О бедном мокапе замолвите слово](https://habr.com/ru/post/170549/)
+* [A Pattern Library for Interaction Design](http://www.welie.com/patterns/index.php)
+* [Основы IT для тестировщика / Виды интерфейсов / Что такое GUI, API, CLI?](https://www.youtube.com/watch?v=zs13PZhW9lM)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-kachestva-dannykh-data-quality-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-kachestva-dannykh-data-quality-testing.md
new file mode 100644
index 0000000..f19ef92
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-kachestva-dannykh-data-quality-testing.md
@@ -0,0 +1,34 @@
+# Тестирование качества данных (Data Quality Testing)
+
+_Качество данных (data quality): Атрибут данных, показывающий их корректность согласно некоторым предопределенным критериям: бизнес-ожиданиях, требованиям по полноте данных или их непротиворечивости. (ISTQB)_
+
+Сегодняшний мир переживает очередную технологическую революцию, одним из аспектов которой является использование всевозможными компаниями накопленных данных для раскрутки собственного маховика продаж, прибылей и пиара. Представляется, что именно наличие хороших (качественных) данных, а также умелых мозгов, которые смогут из них делать деньги (правильно обработать, визуализировать, построить модели машинного обучения и т. п.), стали сегодня ключом к успеху для многих. Естественно, это потребовало технической организации этого процесса - подсоединиться к источнику данных, выкачать их, проверить, что они загружены в полном объёме и т. п. Количество таких процессов стало расти, и на сегодняшний день мы получили огромную потребность в Data Quality инженерах - тех, кто следил бы за потоком данных в системе (data pipelines), за качеством данных на входе и на выходе, делал бы выводы об их достаточности, целостности и прочих характеристиках. Обязанности Data Quality инженера не ограничиваются только рутинными ручными/автоматическими проверками на «nulls, count и sums» в таблицах БД, а требуют глубокого понимания бизнес нужд заказчика и, соответственно, способностей трансформировать имеющиеся данные в пригодную бизнес-информацию.
+
+Data Quality - один из этапов Data Management и первый пункт плана управления данными ([data management plan](https://dataladder.com/data-quality-management-plan/)).
+
+Аспекты качественных данных ([dimensions](https://smartbridge.com/data-done-right-6-dimensions-of-data-quality/)):
+
+* Точность (Accuracy): насколько хорошо информация отражает реальность?
+* Полнота (Completeness). Соответствует ли вашим ожиданиям от того, что является всеобъемлющим?
+* Согласованность (Consistency): соответствует ли информация, хранящаяся в одном месте, релевантным данным, хранящимся в другом месте?
+* Своевременность (Timeliness): доступна ли ваша информация тогда, когда она вам нужна?
+* Срок действия, соответствие (Validity aka Conformity): имеет ли информация определенный формат, тип или размер? Соответствует ли она бизнес-правилам / передовой практике?
+* Целостность (Integrity): можно ли правильно объединить разные наборы данных, чтобы отразить общую картину? Хорошо ли определены и реализованы отношения?
+
+Сам процесс тестирования не подразумевает строгое копирование этих признаков в тест-кейсы и их проверку. В Data Quality, как и в любом другом виде тестирования, необходимо прежде всего отталкиваться от требований по качеству данных, согласованных с участниками проекта, принимающими бизнес-решения.
+
+Пример самого обобщенного перечня активностей Data Quality инженера:
+
+* Подготовить тестовые данные (валидные\невалидные\большие\маленькие) через автоматизированный инструмент.
+* Загрузить подготовленный набор данных в исходный источник и проверить его готовность к использованию.
+* Запустить ETL-процессы по обработке набора данных из исходного хранилища в окончательное или промежуточное с применением определённого набора настроек (в случае возможности задать конфигурируемые параметры для ETL-задачи).
+* Верифицировать обработанные ETL-процессом данные на предмет их качества и соответствие бизнес-требованиям.
+
+При этом основной акцент проверок должен приходиться не только на то, что поток данных в системе в принципе отработал и дошёл до конца (что является частью функционального тестирования), а по большей части на проверку и валидацию данных на предмет соответствия ожидаемым требованиям, выявления аномалий и прочего.
+
+Источники + доп. материал:
+
+* [Тестировщик больших и маленьких данных: тренды, теория, моя история](https://habr.com/ru/company/epam\_systems/blog/495478/)
+* [Data Quality Testing: Ways to Test Data Validity and Accuracy](https://lakefs.io/data-quality-testing/)
+* [Data Quality Testing - A Quick Checklist to Measure and Improve Data Quality](https://dataladder.com/data-quality-test-checklist/)
+* [Кто такой и чем занимается Data QA Engineer](https://habr.com/ru/company/skillfactory/blog/591061/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-khranilisha-storage-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-khranilisha-storage-testing.md
new file mode 100644
index 0000000..e46aced
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-khranilisha-storage-testing.md
@@ -0,0 +1,32 @@
+# Тестирование хранилища (Storage testing)
+
+Тестирование хранилища (Storage testing, Storage Performance testing) - это вид тестирования ПО, используемого для проверки того, как тестируемое ПО хранит данные в соответствующих каталогах и достаточно ли в них места для предотвращения неожиданного завершения работы из-за недостатка места на диске. ПО должно обрабатывать такие исключения и отображать предупреждающее сообщение для пользователя.
+
+**Зачем оно нужно?**
+
+* Медленное хранилище означает медленное время отклика, длительные запросы и более низкую доступность (availability) приложений;
+* Медленное хранилище - это накладные расходы на обслуживание серверной инфраструктуры;
+* Помогает найти практические ограничения хранилища перед развертыванием;
+* Это помогает понять, как система отреагирует на замену или обновление оборудования;
+
+**Типы**:
+
+* Application testing: Тестирование приложений с примерами запросов в среде, похожей на боевую:
+ * Сравните время ответа [OLTP](https://www.oracle.com/database/what-is-oltp/);
+ * Сравните время выполнения batch;
+ * Сравните стабильные скорости потоковой передачи;
+* Application Simulation: тестирование с использованием стандартного программного обеспечения, аналогичного целевому приложению:
+ * Протестировать на пиковые значения IOPS для баз данных
+ * Протестируйте на пиковые значения для среды потоковой передачи данных;
+ * Проверка задержек хранилища для обмена сообщениями или других однопоточных приложений;
+* Benchmarking: Провести тестирование с использованием стандартного программного обеспечения;
+ * Проверка на повреждение данных;
+
+Источник:
+
+[Storage Testing Tutorial: What is, Type, Concepts](https://www.guru99.com/storage-testing.html)
+
+Доп. материал:
+
+* [Производительность распределенного хранилища: препродакшн тесты](https://habr.com/ru/company/selectel/blog/547314/)
+* [Тестирование хранилищ данных (Data Warehouse)](https://habr.com/ru/company/tinkoff/blog/302670/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-klientskoi-chasti-i-servernoi-frontend-testing-vs.-backend-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-klientskoi-chasti-i-servernoi-frontend-testing-vs.-backend-testing.md
new file mode 100644
index 0000000..cc23b3a
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-klientskoi-chasti-i-servernoi-frontend-testing-vs.-backend-testing.md
@@ -0,0 +1,19 @@
+# Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
+
+
+
+**Frontend testing** - это тип тестирования, который проверяет уровень представления (Presentation layer) в 3-уровневой архитектуре (3 Tier Architecture). С точки зрения непрофессионала, вы проверяете GUI - все, что видно на экране, на стороне клиента. Для веб-приложения интерфейсное тестирование будет включать проверку функциональных возможностей, таких как формы, графики, меню, отчеты и т. д., а также связанный Javascript. Frontend testing - это термин, охватывающий различные стратегии тестирования, включая оценку производительности фронтенда, которая является хорошей практикой перед тестированием приложения с высокими пользовательскими нагрузками. Тестировщик должен хорошо понимать бизнес-требования для выполнения этого типа тестирования. Ранее оптимизация производительности означала оптимизацию на стороне сервера. Это было связано с тем, что большинство веб-сайтов были в основном статичными, а большая часть обработки выполнялась на стороне сервера. Однако сегодня веб-приложения становятся более динамичными и в результате код на стороне клиента нередко становится причиной низкой производительности.
+
+Тестирование клиентской части невозможно в некоторых случаях: бэкенд разрабатывают быстрее, чем фронтенд; очевидно, если клиентская часть отсутствует в принципе ( самодостаточное приложение, терминальная команда).
+
+**Backend testing** - это тип тестирования, который проверяет уровень приложений и базы данных 3-уровневой архитектуры. В сложном программном приложении, таком как ERP, внутреннее тестирование повлечет за собой проверку бизнес-логики на уровне приложений. Для более простых приложений бэкэнд-тестирование проверяет серверную часть или базу данных. Это означает, что данные, введенные в интерфейс, будут проверены в базе данных. Базы данных проверяются на наличие свойств ACID, операций CRUD, их схемы, соответствия бизнес-правилам. Базы данных также проверяются на безопасность и производительность. Производится проверка целостности данных, Проверка достоверности данных, Тестирование функций, процедур и триггеров. При внутреннем тестировании нет необходимости использовать графический интерфейс. Вы можете напрямую передавать данные с помощью браузера с параметрами, необходимыми для функции, чтобы получить ответ в некотором формате по умолчанию. Например, XML или JSON. Вы также подключаетесь к базе данных напрямую и проверяете данные с помощью SQL-запросов.
+
+Источник:
+
+[Frontend Testing Vs. Backend Testing: What’s the Difference?](https://www.guru99.com/frontend-testing-vs-backend-testing.html)
+
+Доп. материал:
+
+* [Как найти границы на клиенте и сервере](https://habr.com/ru/post/510458/)
+* [Как Иван ошибку в бэкенде локализовывал](https://habr.com/ru/company/funcorp/blog/518248/)
+* [Круглый стол "Почему не стоит тестировать бэкенд руками"](https://www.youtube.com/watch?v=XSeoWpSlcig\&feature=youtu.be\&ab\_channel=PodlodkaPodcast)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-lokalizacii-globalizacii-i-internacionalizacii-localization-globalization-internatio.md b/vidy-metody-urovni-testirovaniya/testirovanie-lokalizacii-globalizacii-i-internacionalizacii-localization-globalization-internatio.md
new file mode 100644
index 0000000..72e75f0
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-lokalizacii-globalizacii-i-internacionalizacii-localization-globalization-internatio.md
@@ -0,0 +1,52 @@
+# Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
+
+Глобализированное ПО - это ПО, функционирующее одинаково качественно независимо от географической, культурной и национальной среды. Тестирование глобализации концентрируется на выявлении потенциальных проблем в дизайне продукта, которые могут испортить глобализацию. Например, разработчик должен заложить в CSS основу для вертикального текста, если в будущем планируется локализовать продукт на язык с вертикальным письмом, обработку почтовых индексов для разных стран (где-то цифры, где-то цифры с буквами и т.п.). Оно гарантирует, что код может обрабатывать желаемую международную поддержку без нарушения какой-либо функциональности. А также, что не будет никакой потери данных и проблем с отображением.
+
+**Globalization = Internationalization + Localization**.
+
+**Интернационализация ПО** (Internationalization (I18N)) - это особый процесс, при котором веб-софт создается таким образом, чтобы оно было равноудаленным от какой-либо культуры и (или) специфики определенного географического региона. Например, одна из задач по интернационализации ПО - корректное редактирование логики всех подключенных параметров форматирования (формат даты, времени, цифровое и валютное форматирование). Также, тестировщики во время проверки на соответствие ПО требованиям I18N тестируют работу продукта на одинаковую работу в разных регионах и культурах мира. Основной задачей тестирования интернациональности является проверка того, может ли программный код работать со всей международной поддержкой без нарушения функциональности, что может привести к потере данных или проблемам целостности информации. В основном, фокус тестирования интернационализации направлен на:
+
+* Тестирование языковой совместимости: это включает проверку того, может ли продукт правильно работать в определенной языковой среде;
+* Тестирование функциональности: это включает выполнение регрессионных тестов функциональности в различных языковых средах и ввод строк на родном языке. Это включает в себя проверку того, правильно ли отображается и принимается на ввод валюта, дата, время, индекс и т.п.;
+* Проверка пользовательского интерфейса: пытается выявить любые визуальные проблемы, такие как проблемы с графикой, наложение текста, усечение текста и т. д.;
+* Тестирование совместимости: это включает тестирование программного обеспечения на целевых кросс-платформах, операционных системах, версиях приложений и т. д.;
+* Тестирование юзабилити: проверяет простоту использования приложения;
+* Тестирование установки: это включает попытку установить приложение на разных родных языках и проверить, правильно ли отображаются все сообщения об установке в языковых настройках;
+
+**Локализация ПО** (Localization (L10N)) - деятельность по модификации ПО в соответствии с определенными региональными настройками (языком, географической территорией, культурными особенностями). В данный вид проверки входит необходимость выполнения работ по переводу всего контента программного обеспечения для конечного пользователя. Во время перевода должны учитываться иконки, информационная графика, справочные материалы, техническая документация и иные культурные особенности регионов (например, онлайн-сервис по заказу бургеров не будет показывать корову на главной странице в Индии или свинью в мусульманских странах). На что обратить внимание:
+
+* Длина переведенных слов;
+* Параметры шрифта пользовательского интерфейса;
+* Ввод текста в разных локализациях;
+* RTL-языки (справа-налево) или вертикальные;
+* Перевод сокращений или аббревиатур;
+* Мета-теги (проблемы с SEO или отображением имени вкладки (title, description, keywords));
+* Соответствие мер исчисления, валюты, postal code и т.п.;
+
+**Примеры проверок**:
+
+* **Языковой словарь**: Глобализированный продукт поддерживает множество языков. Чем больше языков он поддерживает, тем больше потребность в тестировании. Вы можете использовать языковые переводчики и по одному проверять, использует ли приложение правильный словарный запас для каждого языка;
+* **Пользовательский интерфейс:** Как вы знаете, у каждого языкового сценария свой стиль письма (некоторые пишутся слева направо, а некоторые - справа налево), и пространство, необходимое для слов, может варьироваться от одного языка к другому. Таким образом, необходимо протестировать макет пользовательского интерфейса на каждом языке, чтобы убедиться, что пользовательский интерфейс чистый и отсутствуют такие проблемы, как перекрытие текста, несовпадение текста, проблемы с навигацией и т. д.;
+* **Обозначение даты и времени:** Форматы отображения даты и времени зависят от региона. Например, наиболее распространенный формат даты в США - мм / дд / гггг. В отличие от этого, наиболее распространенный формат даты в Европе - дд / мм / гггг. С другой стороны, Канада принимает как ДД / ММ / ГГГГ, так и ММ / ДД / ГГГГ. Точно так же некоторые страны используют 24-часовую нотацию, в то время как другие используют 12-часовую нотацию. Поэтому очень важно убедиться, что дата и время отображаются в соответствующем формате при переключении на другие регионы / страны;
+* **Корректность даты / времени:** Это не только формат, но и фактическая дата и время варьируются от региона к региону в зависимости от часового пояса. Например, 11:53 субботы по индийскому стандартному времени (IST) - 1:23 субботы по восточному времени (ET). Значит, необходимо проверить правильность отображения даты и времени в приложении при переключении в разные страны;
+* **Формат валюты и обработка курсов конвертации:** Если ваше приложение включает электронную коммерцию, проверка валюты становится критически важной. Числовые форматы валют варьируются от страны к стране. Итак, вам следует позаботиться о форматировании. Еще одна важная вещь - отображать правильный символ валюты вместе с единицами измерения. Например, если цена товара составляет 100 рупий, но в приложении он упоминается как «100», это может сбить с толку покупателя, так как это 100 рупий или 100 долларов. Следующим важным тестом должно быть подтверждение того, позаботились ли о коэффициентах конверсии. Также рекомендуется отображать обменный курс для пользователя, чтобы сделать его более удобным и полезным;
+* **Формат номера телефона, адреса и почтового индекса:** Порядок отображения адресов зависит от языка. Например, на японском языке порядок адресов - это почтовый индекс, штат, город, а на английском языке порядок адресов - это имя, город, штат, почтовый индекс и т. д. Итак, вам необходимо проверить, нормально ли работает отображение порядка адресов при переключении между разными языками, поддерживаемыми вашим приложением. Точно так же длина и формат телефонного номера также различаются от страны к стране. В наши дни у нас также есть [рекомендация E.164](https://en.wikipedia.org/wiki/E.164) для форматирования чисел в соответствии с общей международной нотацией;
+
+Примечание автора: частный случай задачи на тестирование локализации в android/ios приложениях может быть и в контексте файлов strings, в которых приложение хранит все текстовые строки. Строки могут быть с динамически подставляемыми параметрами чтобы содержимое строки динамически изменялось в зависимости от чего-либо. Например: “Вы сможете запросить код повторно через %s” или “Закрыто. До открытия %1$d ч.”, В данном случае потребуется проверить переводы на предмет того, что динамические аргументы в строках не были сломаны переводчиками. Лично я для этого писал скрипт на python, он есть в другом репозитории.
+
+Источники:
+
+* [What Is Globalization Testing (A Complete Guide)](https://www.softwaretestinghelp.com/globalization-testing/)
+
+Доп. материал:
+
+* [Тестировщик с нуля / Урок 8 / Тестирование локализации](https://www.youtube.com/watch?v=VQC0bVopwXg)
+* [Sample International Test Cases](https://docs.microsoft.com/en-us/globalization/testing/sample-international-test-cases)
+* [Страх и ненависть локализации в больших проектах. Доклад Яндекса](https://habr.com/ru/company/yandex/blog/545698/)
+* [Локализационное тестирование: зачем оно нужно приложению или сайту?](https://habr.com/ru/company/alconost/blog/521330/)
+* [Почему интернационализация и локализация имеют значение](https://habr.com/ru/company/otus/blog/523112/)
+* [Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist](https://habr.com/ru/post/532836/)
+* [Accelerate localization from code to delivery](https://lokalise.com)
+* [Internationalization & localization testing](https://www.slideshare.net/Robin0590/internationalization-localization-testing)
+* [Android Developers - Docs - Reference - Formatter](https://developer.android.com/reference/java/util/Formatter.html)
+* [Тестирование локализации](https://www.software-testing.ru/library/testing/testing-for-beginners/3746-localization-testing)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-masshtabiruemosti-scalability-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-masshtabiruemosti-scalability-testing.md
new file mode 100644
index 0000000..fc04fc0
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-masshtabiruemosti-scalability-testing.md
@@ -0,0 +1,12 @@
+# Тестирование масштабируемости (Scalability testing)
+
+Тестирование масштабируемости проводится для определения способности приложения масштабироваться с точки зрения пользовательской нагрузки, количества транзакций, объема данных и т. д. Цель теста масштабируемости отличается от стрессового или нагрузочного тестирования. Например, компания ожидает шестикратного увеличения нагрузки на серверы в течение следующих двух месяцев. Им может потребоваться увеличить производительность сервера и сократить время обработки запроса, чтобы лучше обслуживать посетителей. Если приложение масштабируемое, вы можете сократить это время, обновив оборудование сервера, например, вы можете увеличить частоту ЦП и добавить больше ОЗУ. Также вы можете улучшить производительность запросов, изменив программное обеспечение сервера, например, заменив хранилища данных в текстовых файлах базами данных SQL Server. Чтобы найти лучшее решение, вы можете сначала протестировать изменения оборудования, затем изменения программного обеспечения, а затем сравнить результаты тестов.
+
+
+
+Пример: если тестирование масштабируемости определяет максимальную нагрузку в 10 000 пользователей, то для обеспечения масштабируемости системы разработчикам необходимо принять меры по таким факторам, как уменьшение времени отклика после достижения лимита в 10 000 пользователей или увеличение размера ОЗУ для соответствия растущему количеству пользовательских данных.
+
+Источники:
+
+* [What Is Scalability Testing? How To Test The Scalability Of An Application](https://www.softwaretestinghelp.com/what-is-scalability-testing/)
+* [Do you really know all types of Performance Tests (Non-Functional Tests)?](https://perfmatrix.blogspot.com/2017/01/type-of-performance-test.html)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-metodom-belogo-yashika-white-box-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-metodom-belogo-yashika-white-box-testing.md
new file mode 100644
index 0000000..f8d09a1
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-metodom-belogo-yashika-white-box-testing.md
@@ -0,0 +1,64 @@
+# Тестирование методом белого ящика (White Box Testing)
+
+_Тестирование методом белого ящика (white-box testing): Тестирование, основанное на анализе внутренней структуры компонента или системы (ISTQB)._
+
+_Тестирование на основе структуры (structure-based testing): Динамическое тестирование, для которого тесты являются результатом анализа структуры элемента тестирования. Примечание. Тестирование на основе структуры не ограничено использованием на уровне компонентов, а может использоваться на всех уровнях, например при покрытии пункта меню, как части тестирования системы. (ГОСТ 56920)_
+
+Тестирование методом белого ящика (также: прозрачного, открытого, стеклянного ящика; основанное на коде или структурное тестирование) - метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тому, кто её тестирует. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации - обязательны для этой техники. Тестирование белого ящика - углубление во внутреннее устройство системы, за пределы ее внешних интерфейсов.
+
+Техника белого ящика применима на разных уровнях тестирования - модульном, интеграционном и системном, но чаще применяется для юнит-тестирования этого участка кода самим разработчиком или SDET. Тестирование белого ящика - это больше, чем тестирование кода: это **тестирование путей**. Обычно тестируемые пути находятся внутри модуля (модульное тестирование). Но мы можем применить эту же методику для тестирования путей между модулями внутри подсистем, между подсистемами внутри систем, и даже между целыми системами.
+
+**Тестирование белого ящика - это покрытие требований в коде**:
+
+* Code coverage;
+* Segment coverage: каждый оператор кода выполняется один раз;
+* Branch Coverage or Node Testing: покрытие каждой ветки кода из всех возможных было выполнено;
+* Compound Condition Coverage: Для нескольких условий проверяется каждое условие с несколькими путями и комбинацией разных путей для достижения этого условия;
+* Basis Path Testing: каждый независимый путь в коде взят на тестирование;
+* Data Flow Testing (DFT): в этом подходе вы отслеживаете конкретные переменные посредством каждого возможного вычисления, тем самым определяя набор промежуточных путей через код. DFT имеет тенденцию отражать зависимости, но в основном это происходит через последовательности манипуляций с данными. Короче говоря, каждая переменная данных отслеживается, и ее использование проверяется. Этот подход имеет тенденцию обнаруживать ошибки, такие как переменные, которые используются, но не инициализируются, или объявлены, но не используются, и т.д. (компиляторы/линтеры/IDE уже вполне способны на это сами);
+* Path Testing: тестирование пути - это определение и покрытие всех возможных путей прохождения через код;
+* Loop Testing: эти стратегии относятся к тестированию одиночных циклов, составных (concatenated) циклов и вложенных циклов;
+
+Используя покрытие Statement и Branch, вы обычно достигаете 80-90% покрытия кода, что является достаточным.
+
+**Процесс** **White box testing**:
+
+* Анализируется реализация программы;
+* В программе определяются возможные маршруты;
+* Выбираются такие входные данные, чтобы программа выполнила выбранные пути. Это называется
+* сенсибилизацией путей. Заранее определяются ожидаемые результаты для входных данных;
+* Тесты выполняются;
+* Результаты анализируются;
+
+**Преимущества White box testing**:
+
+* тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;
+* можно провести более тщательное тестирование, с покрытием большого количества путей выполнения программы;
+
+**Недостатки White box testing**:
+
+* Количество выполняемых путей может быть настолько большим, что не удастся проверить их все. Как правило, попытка протестировать все пути выполнения с помощью тестирования белого ящика так же невозможна, как и тестирование всех комбинаций всех входных данных при тестировании черного ящика;
+* Выбранные тест-кейсы могут не содержать данные, которые будут чувствительны к ошибкам. Например: p=q/r; может выполняться корректно, за исключением случая, когда r=0. y=x^2; тест не выявит ошибок в случаях, когда x=0, y=0 и x=2, y=4;
+* Тестирование белого ящика предполагает, что поток управления правильный (или близок к правильному). Поскольку эти тесты основаны на существующих путях, с помощью нельзя
+* обнаружить несуществующие пути;
+* Тестировщик должен обладать навыками программирования для того, чтобы понять и
+* оценить тестируемое программное обеспечение;
+
+**White box testing нужно**:
+
+Чтобы убедиться, что:
+
+* Все независимые пути в модуле были проверены хотя бы один раз;
+* Все логические решения проверены на их истинное и ложное значения;
+* Все циклы выполняются на своих границах и в пределах своих рабочих границ валидности внутренних структур данных;
+
+Чтобы обнаружить следующие типы ошибок:
+
+* Логическая ошибка имеет тенденцию закрасться в нашу работу, когда мы разрабатываем и реализуем функции, условия или элементы управления, которые не входят в программу;
+* Ошибки проектирования из-за разницы между логическим потоком программы и фактической реализацией;
+* Типографические ошибки и проверка синтаксиса;
+
+Источники:
+
+* [White Box Testing: A Complete Guide With Techniques, Examples, & Tools](https://www.softwaretestinghelp.com/white-box-testing-techniques-with-example/)
+* Ли Копланд - “A Practitioner's Guide to Software Test Design”, Секция II. Методы тестирования белого ящика
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-metodom-chernogo-yashika-black-box-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-metodom-chernogo-yashika-black-box-testing.md
new file mode 100644
index 0000000..1727984
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-metodom-chernogo-yashika-black-box-testing.md
@@ -0,0 +1,194 @@
+# Тестирование методом черного ящика (Black Box Testing)
+
+_Тестирование методом черного ящика (black box testing): Тестирование, функциональное или нефункциональное, без знания внутренней структуры компонента или системы (ISTQB)._
+
+_Тестирование на основе спецификации (specification-based testing): Тестирование, основным базисом которого являются внешние вводы и выводы элемента тестирования, обычно на основе спецификации, а не ее реализация в исходном коде или исполнимом программном обеспечении. (ГОСТ 56920)_
+
+Другие названия: Behavioral Testing, Specification-Based Testing, Input-Output Testing, непрозрачный ящик (opaque-box), закрытый ящик (closed-box), тестирование на основе спецификации (specification-based testing) или тестирование с глазу на глаз (eye-to-eye testing).
+
+**Тестирование методом «черного ящика»** - это стратегия, в которой тестирование основано исключительно на требованиях и спецификациях, при этом мы не знаем, как устроена внутри тестируемая система и работаем исключительно с внешними интерфейсами тестируемой системы или компонента. Тестирование черного ящика может быть применено на всех уровнях - модульном, интеграционном, системном и приемочном.
+
+**Functional Testing**: этот тип касается функциональных требований или спецификаций приложения (functional requirements or specifications). Здесь различные действия или функции системы тестируются путем предоставления входных данных и сравнения фактического выхода с ожидаемым выходом. Например, когда мы тестируем раскрывающийся список, мы нажимаем на него и проверяем, что он раскрывается и все ожидаемые значения отображаются. Вот несколько основных типов функционального тестирования:
+
+* Smoke Testing;
+* Sanity Testing;
+* Integration Testing;
+* System Testing;
+* Regression Testing;
+* User Acceptance Testing;
+
+**Non-Functional Testing**: Помимо функциональности требований, есть несколько нефункциональных аспектов, которые необходимо протестировать, чтобы улучшить качество и производительность приложения. Несколько основных типов нефункционального тестирования включают:
+
+* Usability Testing;
+* Load Testing;
+* Performance Testing;
+* Compatibility Testing;
+* Stress Testing;
+* Scalability Testing;
+
+**Преимущества Black box testing**:
+
+* Тестировщику не обязательно иметь технический опыт. Важно проводить тестирование, оказываясь на месте пользователя и думая с его точки зрения;
+* Тестирование можно начинать после завершения разработки проекта / приложения. И тестировщики, и разработчики работают независимо, не мешая друг другу;
+* Это более эффективно для больших и сложных приложений;
+* Дефекты и несоответствия можно выявить на ранней стадии тестирования;
+
+**Недостатки Black box testing**:
+
+* Без каких-либо технических или программных знаний есть вероятность пропустить возможные условия тестируемого сценария;
+* В оговоренное время есть вероятность протестировать не все входные и выходные значения;
+* Полный Test Coverage невозможен для больших и сложных проектов;
+
+**Парадигмы тестирования методом черного ящика (Paradigms of Black Box Software Testing)**
+
+Парадигма создает основное направление мышления - она дает понимание и направление для дальнейших исследований или работы. Парадигма тестирования будет определять типы тестов, которые (для человека, работающего в рамках этой парадигмы) актуальны и интересны. Список парадигм:
+
+* **Domain driven**
+ * Ключевые идеи:
+ * «Попробуйте диапазоны и варианты»;
+ * «Разделите мир на классы»;
+ * Основной вопрос или цель:
+ * Стратегия стратифицированной выборки. Разделите большое пространство возможных тестов на подмножества. Выберите лучших представителей из каждого набора;
+ * Примеры кейсов:
+ * Анализ эквивалентности простого числового поля;
+ * Тестирование совместимости принтеров;
+ * Сильные стороны:
+ * Нахождение ошибок с наибольшей вероятностью с помощью относительно небольшого набора тестов;
+ * Интуитивно понятный подход, хорошо обобщает;
+ * Слепые зоны:
+ * Ошибки, выходящие за рамки границ, или в очевидных особых случаях;
+ * Кроме того, фактические домены часто остаются неизвестными;
+* **Stress driven**
+ * Ключевые идеи:
+ * «Сокруши продукт»;
+ * «Проведи его через отказы;
+ * Основной вопрос или цель:
+ * Узнать о возможностях и слабых сторонах продукта, проведя его через отказ и за его пределами. Что сбои в экстремальных случаях говорят нам об изменениях, необходимых в работе программы в нормальных случаях?
+ * Примеры кейсов:
+ * Большие объемы данных, подключения устройств, длинные цепочки транзакций;
+ * Условия нехватки памяти, сбои устройств, вирусы и другие проблемы;
+ * Сильные стороны:
+ * Выявление слабых мест, в т.ч. дыр в безопасности;
+ * Слепые зоны:
+ * Слабости, которые не становятся более заметными из-за стресса;
+* **Specification driven**
+ * Ключевые идеи:
+ * «Проверяйте каждое требование»;
+ * Основной вопрос или цель:
+ * Проверяйте соответствие (conformance) продукта каждому заявлению в каждой спецификации, документе с требованиями и т. д.;
+ * Примеры кейсов:
+ * Матрица прослеживаемости, отслеживает тестовые случаи, связанные с каждым элементом спецификации;
+ * Сильные стороны:
+ * Критическая защита от гарантийных претензий, обвинений в мошенничестве, потери доверия со стороны клиентов;
+ * Слепые зоны:
+ * Любые проблемы, не указанные в спецификациях или плохо решенные в спецификациях;
+* **Risk driven**
+ * Ключевые идеи:
+ * «Сначала найди наибольшие ошибки»;
+ * Основной вопрос или цель:
+ * Расставьте приоритеты при тестировании с точки зрения относительного риска различных областей или проблем, которые мы могли бы проверить;
+ * Примеры кейсов:
+ * Переформулированный анализ классов эквивалентности;
+ * Тестируйте в порядке частоты использования;
+ * Стресс-тесты, тесты на обработку ошибок, тесты безопасности, тесты для поиска прогнозируемых или предполагаемых ошибок;
+ * Образец из списка предсказанных ошибок;
+ * Сильные стороны:
+ * Оптимальная приоритезация (при условии, что мы правильно идентифицируем и расставляем по приоритетам риски);
+ * Тесты высокой мощности;
+ * Слепые зоны:
+ * Риски, которые не были идентифицированы или которые на удивление более вероятны;
+* **Random / statistical testing**
+ * Ключевые идеи:
+ * «Объемное тестирование с новыми кейсами»;
+ * Основной вопрос или цель:
+ * Пусть компьютер создает, выполняет и оценивает огромное количество тестов;
+ * Примеры кейсов:
+ * Валидация функции или подсистемы (например, тестирование эквивалентности функций) на основе оракулов (Oracle-driven);
+ * Стохастическое (переход между состояниями) тестирование для выявления конкретных сбоев (ассерты, утечки и т. д.);
+ * Оценка статистической надежности;
+ * Частичный или эвристический оракул, чтобы найти некоторые типы ошибок без общей проверки;
+ * Сильные стороны:
+ * Регрессия не зависит каждый раз от одного и того же старого теста;
+ * Частичные оракулы могут быстро и дешево находить ошибки в молодом коде;
+ * Меньше вероятность пропустить невидимые извне внутренние оптимизации;
+ * Может обнаруживать сбои, возникающие из-за длинных сложных цепочек, которые было бы трудно создать в соответствии с запланированными испытаниями;
+ * Слепые зоны:
+ * Нужно уметь отличать pass от failure. Слишком много людей думают: «Not crash = not fail»;
+ * Кроме того, эти методы часто охватывают многие типы рисков, но затемняют необходимость в других тестах, которые не поддаются автоматизации;
+* **Function Testing**
+ * Ключевые идеи:
+ * «Модульное тестирование черного ящика»;
+ * Основной вопрос или цель:
+ * Тщательно проверяйте каждую функцию по очереди;
+ * Примеры кейсов:
+ * Таблица, тестируйте каждый элемент по отдельности;
+ * База данных, тестируйте каждый отчет по отдельности;
+ * Сильные стороны:
+ * Тщательный анализ каждого протестированного элемента;
+ * Слепые зоны:
+ * Упускает взаимодействия, пропускает исследование преимуществ предлагаемые программой;
+* **Regression Testing**
+ * Ключевые идеи:
+ * «Повторить тестирование после изменений»;
+ * Основной вопрос или цель:
+ * Управляйте рисками, связанными с тем, что (а) исправление ошибки не устраняет ошибку или (б) исправление (или другое изменение) имело побочный эффект (side effect);
+ * Примеры кейсов:
+ * Регрессия ошибок, регрессия старых исправлений, общая функциональная регрессия;
+ * Наборы автоматизированной регрессии графического интерфейса;
+ * Сильные стороны:
+ * Обнадеживает, укрепляет доверие, удобен для регуляторов;
+ * Слепые зоны:
+ * Все, что не вошло в регрессионную серию. Кроме того, поддержание этого стандартного списка может быть очень дорогостоящим;
+* **Scenario / use case / transaction flow**
+ * Ключевые идеи:
+ * «Делай что-нибудь полезное и интересное»;
+ * «Делайте одно за другим»;
+ * Основной вопрос или цель:
+ * Сложные случаи, отражающие реальное использование;
+ * Примеры кейсов:
+ * Оценивайте продукт на предмет соответствия бизнес-правилам, данным о клиентах и продукции конкурентов;
+ * Тестирование жизненного цикла / Life history testing ([Hans Buwalda’s “soap opera testing”](https://www.agileconnection.com/sites/default/files/presentation/file/2018/W11\_14.pdf));
+ * Варианты использования (Use cases) - это более простая форма, часто основанная на возможностях продукта и пользовательской модели, а не на естественном наблюдении за системами такого типа;
+ * Сильные стороны:
+ * Сложные, реалистичные события. Может помогать справляться в ситуациях, которые слишком сложны для моделирования;
+ * Выявляет сбои, которые происходят (развиваются) с течением времени;
+ * Слепые зоны:
+ * Отказ одной функции может сделать этот тест неэффективным;
+ * Необходимо хорошо подумать, чтобы добиться хорошего покрытия;
+* **User testing**
+ * Ключевые идеи:
+ * Стремитесь к реализму;
+ * Давайте попробуем это с настоящими людьми (для разнообразия);
+ * Основной вопрос или цель:
+ * Выявить сбои, которые могут возникнуть по вине человека, то есть сбои в общей системе человек / машина / программное обеспечение;
+ * Примеры кейсов:
+ * Бета-тестирование;
+ * Собственные эксперименты с использованием стратифицированной выборки целевого рынка;
+ * Сильные стороны:
+ * Проблемы дизайна более достоверны;
+ * Может продемонстрировать, что некоторые аспекты продукта непонятны или приводят к высокому проценту ошибок при использовании;
+ * Внутренние тесты можно контролировать с помощью логов, видео, отладчиков и других инструментов;
+ * Внутренние тесты могут быть сосредоточены на областях / задачах, которые, по вашему мнению, являются (или должны быть) спорными;
+ * Слепые зоны:
+ * Покрытие не гарантировано (серьезные пропуски бета-тестирования, других пользовательских тестов);
+ * Тестовые примеры могут быть плохо спроектированы, тривиальны, вряд ли выявляют малозаметные ошибки;
+ * Бета-тестирование стоит денег;
+* **Exploratory testing**
+ * Ключевые идеи:
+ * «Интерактивное, одновременное исследование, разработка тестов и тестирование»;
+ * Основной вопрос или цель:
+ * ПО поступает тестировщику без документации. Тестировщик должен одновременно узнавать о продукте и о тестовых примерах / стратегиях, которые позволят выявить продукт и его дефекты;
+ * Примеры кейсов:
+ * Полное тестирование test-it-today;
+ * Сторонние компоненты;
+ * Горилла-тестинг;
+ * Сильные стороны:
+ * Продуманная стратегия получения результата в неизвестности;
+ * Стратегия выявления несоответствия ожиданиям клиентов;
+ * Слепые зоны:
+ * Чем меньше мы знаем, тем больше рискуем упустить.
+
+Источники:
+
+* [Black Box Testing: An In-Depth Tutorial With Examples And Techniques](https://www.softwaretestinghelp.com/black-box-testing/)
+* [Cem Kaner, James Bach - “Paradigms of Black Box Software Testing”](http://kaner.com/pdfs/swparadigm.pdf)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-metodom-serogo-yashika-grey-box-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-metodom-serogo-yashika-grey-box-testing.md
new file mode 100644
index 0000000..cc5a62d
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-metodom-serogo-yashika-grey-box-testing.md
@@ -0,0 +1,14 @@
+# Тестирование методом серого ящика (Grey Box Testing)
+
+Тестирования методом серого ящика вообще нет в ISTQB, тем не менее много где можно встретить упоминания этого типа тестирования. В целом оно определяется как метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов или как дополненный черный ящик. Т.е., внутреннее устройство/код известны/используется лишь частично, и, например, имея доступ к внутренней структуре и алгоритмам работы ПО, можно написать более эффективные тест-кейсы, но само тестирование проводится с помощью техники черного ящика, то есть, с позиции пользователя.
+
+Примеры: тестирование с проверкой корректности записей в БД; работа с логами и метриками для поиска root cause проблем.
+
+**Техники**:
+
+* **Матричное тестирование (Matrix Testing)**: разработчики предоставляют все переменные в программе, а также связанные с ними технические и бизнес-риски. Методика матричного тестирования проверяет риски, определенные разработчиками. Матричный метод устанавливает все используемые переменные в программе. Этот метод помогает идентифицировать и удалять переменные, которые не используются в программе, и, в свою очередь, помогает увеличить скорость работы программного обеспечения;
+* **Регрессионное тестирование (Regression Testing)**: регрессионное тестирование выполняется, когда в программное обеспечение вносятся какие-либо изменения или исправляется какой-либо дефект. Это делается для того, чтобы новое изменение или исправление не повлияло на существующие функциональные возможности программного обеспечения;
+* **Тестирование ортогональных массивов или OAT (Orthogonal Array Testing or OAT)**: этот метод тестирования больше используется для сложных функций или приложений, когда требуется максимальное покрытие кода с минимальным количеством test cases и имеет большие тестовые данные с n числом комбинаций;
+* **Pattern testing**: тестирование по образцу выполняется на основе предыдущих дефектов, обнаруженных в ПО. Записи о дефектах анализируются на предмет причин дефектов, и создаются test cases на основе этих дефектов и их причин;
+
+Источник: [Grey Box Testing Tutorial With Examples, Tools And Techniques](https://www.softwaretestinghelp.com/grey-box-testing-tutorial/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-na-otkaz-i-vosstanovlenie-failover-and-recovery-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-na-otkaz-i-vosstanovlenie-failover-and-recovery-testing.md
new file mode 100644
index 0000000..f29d8eb
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-na-otkaz-i-vosstanovlenie-failover-and-recovery-testing.md
@@ -0,0 +1,26 @@
+# Тестирование на отказ и восстановление (Failover and Recovery testing)
+
+_Тестирование отказоустойчивости (failover testing): Тестирование при помощи эмуляции отказов системы или реально вызываемых отказов в управляемом окружении. После вызванного отказа проверяется механизм отказоустойчивости с целью удостовериться, что данные не потеряны или не испорчены, и достигнут оговоренный уровень обслуживания (например, доступности функций или время отклика) (ISTQB)._
+
+Тестирование на отказ и восстановление (Failover and Recovery testing, Disaster Recovery Testing) - подвид тестирования производительности, проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками ПО, отказами оборудования или проблемами связи/сети. Failover - проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта. Методика подобного тестирования заключается в симулировании различных условий сбоя, последующем изучении и оценке реакции защитных систем. В процессе подобных проверок выясняется, была ли достигнута требуемая степень восстановления системы после возникновения сбоя. В отличие от тестирования надежности (Reliability Testing), которое проводится, чтобы найти отказ в конкретной точке, где он происходит, Recovery Testing проводится для проверки того, насколько хорошо система восстанавливается после сбоя или аварии.
+
+Для наглядности рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие как:
+
+* Проблемы с сетью;
+* Сбой питания;
+* Внешний сервер недоступен (External server not reachable);
+* Сервер не отвечает (Server not responding);
+* Отсутствует файл dll;
+* Перегрузка базы данных;
+* Остановленные сервисы/службы;
+* Физические условия;
+* Внешнее устройство не отвечает;
+* Потеря сигнала беспроводной сети;
+
+Источники:
+
+* [What Is Recovery Testing In Software Testing](https://www.softwaretestinghelp.com/recovery-testing-tutorial/)
+
+Доп. материал:
+
+* [Importance of Failover Testing during Test Planning of Safety Critical Systems](https://www.softwaretestinggenius.com/importance-of-failover-testing-during-test-planning-of-safety-critical-systems/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-na-sootvetstvie-conformance-compliance-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-na-sootvetstvie-conformance-compliance-testing.md
new file mode 100644
index 0000000..66ab260
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-na-sootvetstvie-conformance-compliance-testing.md
@@ -0,0 +1,15 @@
+# Тестирование на соответствие (Conformance/Compliance testing)
+
+_Соответствие (compliance): Способность программного продукта соответствовать стандартам, соглашениям или правилам законодательства и другим подобным предписаниям. (ISTQB)_
+
+Compliance - официальное соответствие ПО различным стандартам, законам, сертификация и т.п.
+
+Conformance - неофициальные, внутренние стандарты организации, добровольное обязательство делать что-либо признанным образом, либо стремление к Compliance, но которое не закончено / не подтверждено формально.
+
+Источники:
+
+* [Compliance Vs. Conformance](https://visionintegrity.ca/compliance-vs-conformance/)
+
+Доп. материал:
+
+* [Невидимый регулятор. Как подстроить систему под закон?](https://www.youtube.com/watch?v=y7wspIeTD1k)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-nadezhnosti-reliability-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-nadezhnosti-reliability-testing.md
new file mode 100644
index 0000000..9f0c01e
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-nadezhnosti-reliability-testing.md
@@ -0,0 +1,26 @@
+# Тестирование надежности (Reliability Testing)
+
+_Надежность (reliability): Способность программного продукта функционировать при заданных условиях на протяжении определенного периода времени, или для определенного количества операций. (ISO 9126)_
+
+Надежность (Reliability) - это «вероятность безотказной работы программного обеспечения в течение определенного периода времени в определенной среде», т.е. это результат, к которому стремятся разработчики, способом достижения которого является устойчивость. Тестирование надежности связано с качеством программного обеспечения и стандартизацией продуктов. Если мы можем повторять тест-кейсы и постоянно получать один и тот же результат, то продукт считается «надежным». Тестирование надежности выполняется, чтобы убедиться, что программное обеспечение надежно, соответствует цели, для которой оно создано, и в течение определенного периода времени в данной среде способно обеспечить безотказную работу. Тестирование надежности может включать в себя Feature Testing, Security testing, Load Testing, Regression Testing и др.
+
+**Основные варианты для оценки надежности**:
+
+* Надежность повторного тестирования (Test-retest Reliability): при тестировании функционала одинаковыми тест-кейсами в разное время каждый раз мы получаем высокую корреляцию результатов. Тогда мы можем сказать, что тест «надежен». Обычно надежность 0,8 или более означает, что систему можно рассматривать как высоконадежный продукт;
+* Параллельная или альтернативная форма надежности (Parallel or Alternate form of Reliability): разные версии одного теста должны давать одинаковый результат;
+* Надежность между оценщиками (Inter-Rater Reliability): Надежность между оценщиками иначе известна как надежность между наблюдателями (Inter-Observer) или кодировщиками (Inter-Coder). Это особый тип надежности, состоящий из нескольких оценщиков или судей. Он касается согласованности рейтинга, выставляемого разными оценщиками / наблюдателями;
+
+**План тестирования надежности**:
+
+Имея правильную модель, мы можем предсказать качество продукта. К двум типам моделей относятся:
+
+* Модель прогноза (Prediction Model): В прогнозном тестировании (Predictive testing) мы прогнозируем результат на основе исторических данных, статистики, машинного обучения. Все, что нам нужно, это написать отчет. В прогнозной модели мы получаем только некоторую историческую информацию. Используя эту информацию, мы можем экстраполировать имеющиеся данные на будущее;
+* Модель оценки (Estimation Model): Этот тип модели выполняется перед самой стадией разработки или тестирования. В оценочном тестировании (Estimation Testing), помимо использования исторических данных, мы будем использовать текущие данные. Здесь мы можем спрогнозировать надежность продукта в настоящее время или в будущем. Этот тип тестирования выполняется на последних этапах жизненного цикла разработки программного обеспечения.
+
+Источники:
+
+* [What Is Reliability Testing: Definition, Method And Tools](https://www.softwaretestinghelp.com/reliability-testing/)
+* [Reliability Series #1: Reliability vs. resilience](https://www.microsoft.com/security/blog/2014/03/24/reliability-series-1-reliability-vs-resilience/)
+* [Approaches to Reliability Testing and Setting of Reliability Test Objectives](https://www.softwaretestinggenius.com/approaches-to-reliability-testing-and-setting-of-reliability-test-objectives/)
+* [Reliability Testing and Assessment of Risks due to Poor Reliability](https://www.softwaretestinggenius.com/reliability-testing-and-assessment-of-risks-due-to-poor-reliability/)
+* [Fail-Fast vs. Fail-Safe: What is the Most Reliable Software Strategy?](https://hackernoon.com/fail-fast-vs-fail-safe-what-is-the-most-reliable-software-strategy)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-osnovannoe-na-riskakh-risk-based-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-osnovannoe-na-riskakh-risk-based-testing.md
new file mode 100644
index 0000000..be3f6bd
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-osnovannoe-na-riskakh-risk-based-testing.md
@@ -0,0 +1,34 @@
+# Тестирование, основанное на рисках (Risk-Based Testing)
+
+_Тестирование, основанное на рисках (risk-based testing): Подход к тестированию с целью минимизирования уровня рисков продукта и информирования заинтересованных лиц о текущем состоянии рисков с начальных стадий проекта. Подразумевает под собой управление процессом тестирования, исходя из идентифицированных рисков продукта и использования уровней риска. (ISTQB)_
+
+Риск - это возникновение неопределенного события, которое положительно или отрицательно влияет на измеримые критерии успеха проекта. Это могут быть события, которые произошли в прошлом или текущие события, или что-то, что может произойти в будущем. Эти неопределенные события могут повлиять на стоимость, бизнес, технические и качественные цели проекта. Позитивные риски упоминаются как возможности и помощь в устойчивости бизнеса. Например, инвестирование в новый проект, изменение бизнес-процессов, разработка новых продуктов. Отрицательные риски называются угрозами, и для успеха проекта должны быть реализованы рекомендации по их минимизации или устранению.
+
+Тестирование на основе рисков помогает обнаруживать наиболее важные и критические ошибки на ранней стадии. Это тип тестирования, основанный на вероятности риска. Он включает в себя оценку риска на основе сложности, критичности бизнеса, частоты использования, видимых областей, областей, подверженных дефектам, и т. д. Он включает определение приоритетов тестирования модулей и функций тестируемого приложения на основе влияния и вероятности отказов. Если вовремя не выявить какой-либо риск, это может помешать завершению проекта. Самым первым шагом является определение рисков, а затем их оценка, т.е. определение приоритетов, а затем обработка рисков. После того, как риски идентифицированы, необходимо оценить риск, чтобы определить риски с точки зрения их воздействия, то есть того, какой ущерб он может нанести.
+
+Приоритет любого риска зависит от вероятности возникновения и его воздействия на продукт, то есть от того, насколько серьезным является воздействие: Priority = Probability \* Severity.
+
+* Управление рисками (Risk Management) должно начинаться на ранней стадии жизненного цикла, чтобы с рисками можно было справиться на ранней стадии. Категории рисков:
+ * Project Risks: бюджет, ресурсы, график, проблемы, связанные с клиентами и т. д.
+ * Technical Risks: Технический риск включает риски на этапах проектирования, внедрения, тестирования и разработки. Большинство технических рисков возникает либо на этапе требований, либо во время кодирования, поскольку неясность требований может привести к серьезным рискам во время разработки. Во-вторых, на этапе разработки, если разработчики недостаточно хорошо знакомы с Продуктом, это также может привести к серьезным рискам.
+ * Business Risks: Бизнес-риски включают проблемы с бюджетом и созданием проекта, который не соответствует требованиям заказчика, потерю клиента.
+* Оценка рисков (Risk Assessment): риск оценивается на основе того, насколько серьезным является воздействие.
+* Контроль рисков (Risk Control): Риском можно управлять с помощью трех стратегий:
+ * Предотвращение риска (Risk Avoidance): избежание риска - это избежание риска проекта с согласия клиента. Например. Чтобы избежать риска задержки реализации проекта из-за нехватки ресурсов, ресурсы можно оставить на скамейке запасных для замены, если какой-либо ресурс уйдет в отпуск. Объем работ можно сократить, чтобы избежать рисковУ
+ * Снижение риска (Risk Reduction): снижение риска включает в себя планирование управления рисками и минимизации их последствий. Например. Чтобы снизить риск, для реализации Проекта следует использовать инкрементальный подход;
+ * Передача риска (Risk Transfer): эта стратегия включает покупку страховки или любого компонента, разработанного третьей стороной, чтобы избежать возникновения рисков;
+
+Процесс Risk-based Testing:
+
+
+
+Риск идентифицируется и анализируется, т. е. рассчитывается влияние (impact) и серьезность (severity) риска, и принимаются меры в соответствии с приоритетом риска. Как только приоритет определен, начинается тестирование, т. е. создаются объем (test scope) и план тестирования, а затем выполняется тесты.
+
+Доп. материал:
+
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Часть 1: “Понятия и определения”](https://docs.cntd.ru/document/1200134996) 5.4 Тестирование на базе рисков
+* [Stages of Risk Management Encountered by the Software Testing Managers](https://www.softwaretestinggenius.com/stages-of-risk-management-encountered-by-the-software-testing-managers/)
+* [Risk Based Testing: Approach, Matrix, Process & Examples](https://www.guru99.com/risk-based-testing.html)
+* [Leadership in test: risk-based testing](https://theqalead.com/topics/risk-based-testing/)
+* [Как управлять объемами тестирования на основе рисков](https://www.performance-lab.ru/blog/testirovanie-na-osnove-riskov)
+* [Что такое риск-тестирование?](https://testengineer.ru/chto-takoe-risk-testirovanie/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-podderzhki-maintenance-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-podderzhki-maintenance-testing.md
new file mode 100644
index 0000000..ead96cd
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-podderzhki-maintenance-testing.md
@@ -0,0 +1,74 @@
+# Тестирование поддержки (Maintenance testing)
+
+_Сопровождение (maintenance): Модификация программного продукта после его поставки с целью исправления дефектов, улучшения производительности или других характеристик или для адаптации продукта к изменившемуся окружению. (IEEE 1219)_
+
+_Сопровождаемость (maintainability): Легкость изменения программного продукта для исправления дефектов, для соответствия новым требованиям, с целью облегчения последующего сопровождения или для адаптации к изменившемуся окружению. (ISO 9126)_
+
+_Тестирование сопровождаемости (maintainability testing): Тип тестирования, проводимого для оценки степени эффективности и продуктивности возможных изменений элемента тестирования. (ГОСТ 56920)_
+
+**Maintenance** является последней стадией SDLC. По мнению многих экспертов, по мере того, как изменения после релиза вносятся в существующее приложение, каждое изменение может рассматриваться как начало нового цикла SDLC, но точнее будет сказать, что проект в это время находится в жизненном цикле обслуживания программного обеспечения (SMLC - Software Maintenance Life Cycle). Многие проекты проводят большую часть своего времени именно в SMLC после релиза, а не в SDLC перед ним.
+
+**Maintenance testing** (тестирование поддержки/обслуживания/эксплуатации/сопровождения) - это модификация программного продукта после его выпуска с целью исправления дефектов, улучшения производительности или других характеристик или для адаптации продукта к изменившемуся окружению. (IEEE 1219). После того, как программное обеспечение или приложение задеплоены, оно начинает эксплуатироваться годами и даже десятилетиями. В это время система и ее операционная среда часто исправляются, изменяются или расширяются. Пользователю могут потребоваться некоторые добавленные или новые функции в текущем программном обеспечении, которые требуют внесения изменений в текущее программное обеспечение, и эти изменения должны быть протестированы. Конечным пользователям может потребоваться миграция программного обеспечения на другую самую последнюю аппаратную платформу или изменение среды, например версии ОС, варианта базы данных и т. д., что требует тестирования всего приложения на новых платформах и в новой среде. После того, как продукт релизится, он время от времени требует некоторого обслуживания в целях профилактики сбоев.
+
+**Основные активности** (principal activities):
+
+* Динамическое обслуживание (Dynamic maintenance)
+* Корректирующее обслуживание (Corrective maintenance)
+* Адаптивное обслуживание (Adaptive maintenance)
+
+Задача выполнения Maintenance testing становится более эффективной, когда программное обеспечение имеет хорошую характеристику обслуживаемости (maintainability).
+
+**Reliability, maintainability** в ISO 9126 определяется как «легкость, с которой программный продукт может быть изменен для исправления дефектов, модифицирован для соответствия новым требованиям, модифицирован для облегчения будущего обслуживания или адаптирован к изменившейся среде».
+
+Maintainability состоит из:
+
+* Анализируемость: это относится к усилиям, требуемым (обычно разработчиками) для диагностики дефектов или выявления частей программной системы, требующих изменений;
+* Изменяемость: это касается усилий, необходимых для фактического исправления дефектов или внесения улучшений;
+* Стабильность: вероятность возникновения непредвиденных побочных эффектов в результате внесения изменений в программное обеспечение. Это то, что мы имеем в виду, когда иногда говорим, что программное обеспечение хрупкое (brittle);
+* Тестируемость: описывает усилия, необходимые для тестирования измененного программного обеспечения. Это один из основных атрибутов качества программного обеспечения, который напрямую влияет на нашу работу;
+
+**Причины плохой Maintainability:**
+
+| Основные риски (Maintainability Risks) | Последствия |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Усилия, необходимые для исправления дефектов и внесения изменений, могут быть больше, чем планировалось | Если размер группы поддержки (maintenance team), выполняющей эти задачи, будет фиксированным (обычная ситуация), это также приведет к увеличению временных затрат |
+| Время, затрачиваемое на задачи обслуживания, превышает фиксированные окна обслуживания (maintenance windows) | Это может отрицательно сказаться на производстве (например, сотрудники, прибывающие на работу, обнаруживают, что сервер приложений недоступен из-за проскальзывания окна планового ночного обслуживания) |
+| Поддержка (Maintainers) могут быть вынуждены сокращать сроки, чтобы не выходить за рамки согласованных периодов обслуживания. Им может потребоваться сделать предположения относительно реализации необходимых изменений (возможно, из-за плохой документации) | |
+| Если применяются Соглашения об уровне обслуживания, могут налагаться штрафы | |
+| Долгосрочное накопление плохой поддерживаемости в результате кумулятивного эффекта плохой практики разработки программного обеспечения | Уровень надежности постепенно снижается |
+| Увеличивается количество функциональных дефектов, вносимых изменениями (регрессии) | |
+| На исправление дефектов уходит больше времени | |
+| На персонал поддержки оказывается все большее давление, что может даже привести к дальнейшему ухудшению ситуации | |
+
+**Виды Maintenance testing**:
+
+* **Подтверждающее** тестирование (Confirmation Maintenance Testing): тестирование измененной функциональности. Вы должны тщательно протестировать все модификации (небольшие или большие), внесенные в программное обеспечение, и убедиться, что нет проблем с функциональностью и простоев. Тестовая среда должна быть копией реальной среды вместе с тестовыми данными;
+* **Регрессионное** тестирование (Regression Maintenance Testing): тестирование существующей функциональности на предмет регрессии. Это делается после фазы подтверждающего тестирования. Вы должны протестировать всю систему, чтобы убедиться, что измененная функциональность (работы по обслуживанию) не должна влиять на функциональность существующего программного обеспечения;
+
+Для поддерживающего релиза (maintenance release) может потребоваться поддерживающее тестирование на нескольких уровнях тестирования с использованием различных типов тестов в зависимости от его объема. **Объем технического обслуживания зависит от**:
+
+* Степень риска изменения, например, степень, в которой измененная область программного обеспечения общается с другими компонентами или системами;
+* Размер существующей системы;
+* Размер изменения;
+
+**Триггеры для Maintenance**. Существует несколько причин, по которым проводится обслуживание программного обеспечения, а значит, и тестирование обслуживания, как для запланированных, так и для незапланированных изменений. Мы можем классифицировать триггеры для обслуживания следующим образом:
+
+* Модификации, такие как запланированные улучшения (например, на основе выпуска), корректирующие и срочные изменения, изменения операционной среды (например, плановые обновления операционной системы или базы данных), обновления программного обеспечения COTS и исправления для дефектов и уязвимостей;
+* Миграция, например, с одной платформы на другую, которая может потребовать операционных тестов новой среды, а также измененного программного обеспечения, или тестов преобразования данных, когда данные из другого приложения будут перенесены в поддерживаемую систему;
+* Вывод из эксплуатации, например, когда срок поддержки приложения подходит к концу. Когда приложение или система выводятся из эксплуатации, это может потребовать тестирования миграции или архивирования данных, если требуются длительные периоды хранения данных;
+* Также может потребоваться тестирование процедур восстановления / извлечения после архивирования в течение длительного периода хранения;
+* Регрессионное тестирование может потребоваться, чтобы убедиться, что все функциональные возможности, которые остаются в эксплуатации, по-прежнему работают;
+
+Например, для систем Интернета вещей (IoT) тестирование обслуживания может быть инициировано введением в общую систему совершенно новых или модифицированных вещей, таких как аппаратные устройства и программные услуги. При тестировании обслуживания таких систем особое внимание уделяется интеграционному тестированию на разных уровнях (например, уровень сети, уровень приложений) и аспектам безопасности, в частности, тем, которые относятся к персональным данным.
+
+**Impact Analysis** для Maintenance. Анализ воздействия оценивает изменения, которые были внесены в поддерживающую версию, чтобы определить предполагаемые последствия, а также ожидаемые и возможные побочные эффекты (side effects) изменения, а также определить области в системе, на которые это изменение повлияет. Анализ влияния также может помочь определить влияние изменения на существующие тесты. Побочные эффекты и затронутые области в системе необходимо протестировать на предмет регрессии, возможно, после обновления любых существующих тестов, затронутых изменением. Анализ воздействия может быть проведен до внесения изменения, чтобы помочь решить, следует ли вносить изменение, исходя из возможных последствий в других областях системы.
+
+Источники:
+
+* [Importance of Maintainability to a Good Software & Role of Maintenance Testing](https://www.softwaretestinggenius.com/importance-of-maintainability-to-a-good-software-role-of-maintenance-testing/)
+* [Maintenance Testing Guide](https://www.softwaretestingmaterial.com/maintenance-testing/)
+* [Maintenance Testing](https://betterqa.co/software-testing-services/maintenance-testing/)
+
+Доп. материал:
+
+* [IEEE Guide to the Software Engineering Body of Knowledge](https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf). Chapter 5.
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-proizvoditelnosti-performance-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-proizvoditelnosti-performance-testing.md
new file mode 100644
index 0000000..ea80117
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-proizvoditelnosti-performance-testing.md
@@ -0,0 +1,124 @@
+# Тестирование производительности (Performance testing)
+
+Тестирование производительности - это нефункциональный вид тестирования программного обеспечения, используемый для проверки скорости, времени отклика, стабильности, надежности, масштабируемости и использования ресурсов программного приложения при определенной рабочей нагрузке, обычно регрессионным образом, когда в приложение ежедневно или еженедельно вносятся небольшие изменения. Основная цель тестирования производительности - выявить и устранить узкие места производительности в программном приложении. Это подмножество performance engineering, также известное как «Perf Testing». Само по себе оно не призвано находить дефекты, но оно помогает в обнаружении узких мест в системе.
+
+Обычно продолжительность теста производительности составляет 1 час (устойчивое состояние) на средней / ожидаемой нагрузке; это может варьироваться в зависимости от вашего SLA / требований.
+
+
+
+Примечание 1: все подвиды тестирования производительности отличаются, грубо говоря, только параметрами (тип возрастания нагрузки, ее количество, длительность и т.п.) и собираемыми метриками (без которых это тестирование бессмысленно). Точкой отсчета для всех подвидов принято брать результаты Capacity testing.
+
+
+
+Примечание 2: несмотря на необходимость понимания многих математических и статистических концепций, многие тестировщики и менеджеры либо не имеют достаточных знаний в области математики и статистики, либо не пользуются ими. Это приводит к значительным искажениям и неверной интерпретации результатов тестирования производительности (те же перцентили).
+
+**Общие проблемы с производительностью**.
+
+Большинство проблем с производительностью связаны со скоростью, временем отклика, временем загрузки и плохой масштабируемостью. Скорость часто является одним из самых важных атрибутов приложения. Медленно работающее приложение потеряет потенциальных пользователей. Тестирование производительности проводится для того, чтобы убедиться, что приложение работает достаточно быстро, чтобы удерживать внимание и интерес пользователя. Взгляните на следующий список распространенных проблем с производительностью и обратите внимание на то, что скорость является общим фактором во многих из них:
+
+* Длительное время загрузки - обычно время загрузки - это начальное время, необходимое приложению для запуска. Обычно оно должно быть сведено к минимуму. Хотя некоторые приложения невозможно загрузить менее чем за минуту, время загрузки должно быть меньше нескольких секунд, если это возможно;
+* Плохое время отклика. Время отклика - это время, которое проходит с момента ввода пользователем данных в приложение до того, как приложение выдаст ответ на этот ввод. Как правило, это должно происходить очень быстро. Опять же, если пользователю приходится ждать слишком долго, он теряет интерес;
+* Плохая масштабируемость - программный продукт страдает от плохой масштабируемости, когда он не может обрабатывать ожидаемое количество пользователей.
+* Узкие места (Bottlenecking)- это препятствия в системе, которые ухудшают общую производительность системы. Узкое место - это либо ошибки в коде, либо проблемы с оборудованием, которые вызывают снижение пропускной способности при определенных нагрузках. Узкие места обычно устраняются путем исправления плохо работающих процессов или добавления дополнительного оборудования. Некоторые общие узкие места производительности:
+ * Загрузка ЦП;
+ * Использование памяти;
+ * Использование сети;
+ * Ограничения операционной системы;
+ * Использование диска;
+
+**Как проводить тестирование производительности?**
+
+* Определите необходимую среду тестирования (testing environment): перед тем, как начать процесс тестирования, изучите детали аппаратного, программного обеспечения и сетевых конфигураций, используемых во время тестирования. Это поможет тестировщикам создавать более эффективные тесты. Это также поможет определить возможные проблемы, с которыми тестировщики могут столкнуться во время процедур тестирования производительности;
+* Определите критерии приемки: сюда входят цели и ограничения по пропускной способности, времени отклика и распределению ресурсов. Также необходимо определить критерии успеха проекта, выходящие за рамки этих целей и ограничений. Тестировщики должны иметь право устанавливать критерии и цели производительности, потому что часто спецификации проекта не включают достаточно широкий спектр тестов производительности. Иногда их может и вовсе не быть. Если возможно, найти похожее приложение для сравнения - это хороший способ установить цели производительности;
+* Планирование и проектирование тестов производительности: Определите, как использование может варьироваться среди конечных пользователей, и определите ключевые сценарии для тестирования всех возможных вариантов использования. Необходимо смоделировать различных конечных пользователей, спланировать данные тестирования производительности и наметить, какие метрики будут собраны;
+* Настройка тестовой среды: Подготовьте тестовую среду перед выполнением. Также подготовьте инструменты и другие ресурсы;
+* Имплементирование тест-дизайна: Создайте тесты производительности в соответствии с вашим тест-дизайном;
+* Запуск тестов: Выполнить и промониторить тесты;
+* Анализ, настройка и повторное тестирование: объединяйте, анализируйте и делитесь результатами тестирования. Затем выполните точную настройку и снова проверьте, есть ли улучшение или снижение производительности. Поскольку улучшения обычно становятся меньше с каждым повторным тестом, остановитесь, когда узкое место вызвано ЦП. Тогда вы можете рассмотреть вариант увеличения мощности процессора.
+
+**Метрики тестирования производительности (Performance Testing Metrics):**
+
+* **Использование процессора** (Processor Usage): время, затрачиваемое процессором на выполнение non-idle потоков;
+* **Использование памяти** (Memory use): объем физической памяти, доступной процессам на компьютере;
+* **Время диска** (Disk time): время, в течение которого диск занят выполнением запроса на чтение или запись;
+* \*\*Время отклика \*\*(Response time): время с момента ввода пользователем запроса до получения первого символа ответа. Подробнее: [раз](https://www.guru99.com/response-time-testing.html), [два](https://www.tutorialspoint.com/what-is-response-time-testing);
+* **Задержка** (Latency): временной интервал между запросом и ответом;
+* **Пропускная способность** (Throughput): фактическое количество запросов (или пользователей), которое может обработать система за определенное время. В то время как время задержки говорит вам только о времени, метрика пропускной способности информирует об объеме данных, полученных и обработанных в момент времени. Важно не отделять показатели времени задержки от пропускной способности, т.к. высокий показатель времени задержки часто прямо связан с увеличением показателей метрики пропускной способности. Пропускная способность обычно измеряется в rps - (кол-во) запросов в секунду (requests per second).
+* **Ширина пропускания канала** (Bandwidth): максимальное число запросов (или пользователей), которое может обработать система. В отличие от пропускной способности ширина пропускания канала измеряет максимальный объем, который может обработать приложение.
+* **Частные байты** (Private bytes): количество байтов, выделенных процессом, которые не могут использоваться другими процессами. Они используются для измерения утечек и использования памяти;
+* **Выделенная память** (Committed memory) - объем используемой виртуальной памяти;
+* **Страниц памяти в секунду** (Memory pages/second) - количество страниц, записываемых на диск или считываемых с диска для устранения аппаратных ошибок страниц. Сбои аппаратной страницы - это когда код не из текущего рабочего набора вызывается из другого места и извлекается с диска;
+* **Ошибок страниц в секунду** (Page faults/second) - общая скорость, с которой страницы ошибок обрабатываются процессором. Это происходит, когда процессу требуется код из-за пределов своего рабочего набора;
+* **Число прерываний процессора в секунду** (CPU interrupts per second): это среднее количество аппаратных прерываний, которые процессор принимает и обрабатывает каждую секунду;
+* **Длина дисковой очереди** (Disk queue length): среднее количество запросов на чтение и запись, поставленных в очередь для выбранного диска в течение интервала выборки;
+* **Длина сетевой выходной очереди** (Network output queue length): длина очереди выходных пакетов в пакетах. Значение больше двух означает, что необходимо убрать задержку и возникновение узких мест;
+* **Всего сетевых байтов в секунду** (Network bytes total per second): скорость, с которой байты отправляются и принимаются интерфейсом, включая символы кадрирования;
+* **Количество пулов соединений** (Amount of connection pooling): количество запросов пользователей, которые удовлетворяются объединенными соединениями. Чем больше запросов будет выполнено подключениями в пуле, тем выше будет производительность;
+* **Максимальное количество активных сессий** (Maximum active sessions): максимальное количество сессий, которые могут быть активны одновременно;
+* **Коэффициент хитов** (Hit ratios): это связано с количеством операторов SQL, которые обрабатываются кэшированными данными вместо дорогостоящих операций ввода-вывода. Это хорошее начало для решения проблем, связанных с узкими местами;
+* **Хитов в секунду** (Hits per second): количество хитов веб-сервера в течение каждой секунды нагрузочного теста;
+* **Сегмент отката** (Rollback segment): объем данных, который можно откатить в любой момент времени;
+* **Блокировки баз данных** (Database locks) - блокировки таблиц и баз данных необходимо отслеживать и тщательно настраивать;
+* **Максимальное время ожидания** (Top waits) - отслеживаются, чтобы определить, какое время ожидания можно сократить при работе с тем, насколько быстро данные извлекаются из памяти;
+* **Количество потоков** (Thread counts): состояние приложения можно измерить по количеству потоков, которые работают и в настоящее время активны;
+* **Сборка мусора** (Garbage collection): это связано с возвратом неиспользуемой памяти обратно в систему. Сборку мусора необходимо отслеживать на предмет эффективности;
+* \*Процент ошибок рассчитывается как отношение невалидных ответов к валидным за промежуток времени. Про Average, медианы, перцентили и т.п. углубляться в рамках этой статьи не буду, есть в гугле.
+
+**Тестирование производительности клиентской части и серверной, в чем разница?**
+
+Оценка скорости работы клиентской и серверной частей веб-приложения осуществляется двумя разными видами тестирования: для Frontend применяется тестирование клиентской части, или Client-Side testing, а для Back-end - тестирование серверной части.
+
+Основная цель тестирования клиентской части состоит в измерении времени, необходимого браузеру для загрузки HTML-страницы. Наиболее важными показателями здесь являются количество загружаемых данных, их объем, а также количество выполненных запросов.
+
+Собрать данную статистику можно как с использованием встроенных инструментов браузера (DevTools), так и с помощью специализированных инструментов и онлайн-сервисов, которые позволяют замерить необходимые показатели с учетом интересующего региона.
+
+Помимо общего веса страницы, инструменты предоставляют детализированную информацию по каждому из компонентов. Изучив параметры запросов, можно обнаружить ряд проблем, приводящих к ухудшению скорости отображения страницы. К примеру, подгружается слишком большая картинка, медленный Javascript, или отправляется значительное количество запросов.
+
+Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.
+
+Тестирование серверной части направлено на анализ выполнения запросов и получения соответствующего ответа от Back-end.
+
+Цели данного вида тестирования:
+
+* Измерить время отклика самых важных бизнес-транзакций;
+* Определить предельный уровень допустимой нагрузки;
+* Выявить «узкие» места в производительности системы;
+* Составить рекомендации по улучшению производительности;
+* Найти возможные дефекты, проявляющиеся только при одновременной работе большого количества пользователей.
+
+**Примеры проверок**:
+
+* Время отклика не превышает 4 секунды при одновременном доступе к сайту 1000 пользователей;
+* Время отклика приложения под нагрузкой находится в допустимом диапазоне при медленном сетевом подключении;
+* Проверьте максимальное количество пользователей, с которыми приложение может справиться, прежде чем оно выйдет из строя;
+* Проверить время выполнения базы данных при одновременном чтении / записи 500 записей;
+* Проверьте использование ЦП и памяти приложением и сервером базы данных в условиях пиковой нагрузки;
+* Проверьте время отклика приложения в условиях низкой, нормальной, средней и высокой нагрузки;
+
+Во время фактического выполнения теста производительности расплывчатые термины, такие как допустимый диапазон, большая нагрузка и т. д., Заменяются конкретными цифрами. Инженеры по производительности устанавливают эти числа в соответствии с бизнес-требованиями и техническим ландшафтом приложения.
+
+Источники:
+
+* [Performance Testing Tutorial: What is, Types, Metrics & Example](https://www.guru99.com/performance-testing.html)
+* [Do you really know all types of Performance Tests (Non-Functional Tests)?](https://perfmatrix.blogspot.com/2017/01/type-of-performance-test.html)
+
+Доп. материал:
+
+* [General system performance](https://load.qa)
+* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “D.5 Подпроцесс тестирования производительности”
+* [Анализ результатов нагрузочного тестирования](https://habr.com/ru/company/tinkoff/blog/514314/)
+* [Нагрузочное тестирование выполнять сложно, а инструменты далеки от совершенства. Почему?](https://habr.com/ru/company/vdsina/blog/536304/)
+* [Нагрузочное тестирование: особенности профессии](https://tproger.ru/articles/nagruzochnoe-testirovanie-osobennosti-professii/)
+* [Андрей Акиньшин - Анализируем перформанс с пользой для себя и окружающих](https://www.youtube.com/watch?v=jZ0quqA1Fn8\&ab\_channel=Heisenbug)
+* [Антон Поцюс - Нагрузочное тестирование игрового сервера](https://www.youtube.com/watch?v=Migve-fhHAY\&ab\_channel=Heisenbug)
+* [Сергей Махетов - Воркшоп (часть 1): Стартуем в тестировании производительности](https://www.youtube.com/watch?v=wuFRw-NzeSk\&ab\_channel=Heisenbug)
+* [Сергей Махетов - Воркшоп (часть 2): Стартуем в тестировании производительности](https://www.youtube.com/watch?v=Cr0zfnSz7rk\&ab\_channel=Heisenbug)
+* [Инструментарий для нагрузочного тестирования и не только](https://habr.com/ru/post/554266/)
+* [Представляем RAIL: модель оценки производительности сайта](https://habr.com/ru/company/webo/blog/308026/)
+* [30+ Performance Testing Interview Questions And Answers](https://www.softwaretestingmaterial.com/performance-testing-interview-questions/)
+* [Leadership in test: managing performance testing](https://theqalead.com/topics/managing-performance-testing/)
+* [Введение в тестирование производительности](https://www.youtube.com/watch?v=vyo1fuB7NJQ)
+* [Тестирование производительности веб-сервисов - теория и инструменты](https://testengineer.ru/testirovanie-proizvoditelnosti-veb-servisov/)
+* [Performance testing for beginners (Анна Клюева, Grid Dynamics)](https://www.youtube.com/watch?v=-6Pm74nz8Lo\&list=PLhhTXwj6\_Fl0xbR1Msto-zvCsWVoASRCd\&index=6)
+* [Тестирование производительности](http://okiseleva.blogspot.com/2021/08/blog-post\_25.html)
+* [Подходы к тестированию производительности MQ-сервисов](https://www.youtube.com/watch?v=ZoUSXL8D\_4c)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-rabochego-processa-vorkflou-workflow-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-rabochego-processa-vorkflou-workflow-testing.md
new file mode 100644
index 0000000..947b03c
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-rabochego-processa-vorkflou-workflow-testing.md
@@ -0,0 +1,21 @@
+# Тестирование рабочего процесса/воркфлоу (Workflow testing)
+
+Это тип тестирования программного обеспечения, который проверяет, что каждый software workflow точно отражает данный бизнес-процесс путем тестирования Software Workflows в документе с бизнес-требованиями (BRD - Business Requirements Document). Workflow - это серия задач для получения желаемого результата, которая обычно включает несколько этапов или шагов. Тестирование рабочего процесса также будет включать в себя части системных и интеграционных тестов. Test Model включает тестирование таких артефактов, как: test cases, test procedures, test components, test sub-system, etc.
+
+Процесс Workflow testing:
+
+* Начальная фаза (Inception phase): эта фаза включает начальное планирование испытаний и тестирование прототипа;
+* Фаза разработки (Elaboration phase): эта фаза включает baseline архитектуры тестирования;
+* Фаза строительства (Construction phase): эта фаза включает в себя значительные испытания в каждой сборке;
+* Фаза перехода (Transition phase): эта фаза включает в себя регрессионные тесты и повторные тесты исправлений;
+
+Кто проводит Workflow testing:
+
+* Test engineer: планирует цели теста и график. Определяет Test case и процедуры. Оценивает результаты теста;
+* Component engineer: Разработка тестовых компонентов. Автоматизирует некоторые тестовые процедуры;
+* Integration Tester: Выполнение интеграционных тестов и выявление дефектов
+* System Testers: Выполнение системных тестов и отчеты о дефектах;
+
+Источник:
+
+[What is Workflow Testing in Software Testing? with Examples](https://www.guru99.com/workflow-testing.html)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-servisa-service-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-servisa-service-testing.md
new file mode 100644
index 0000000..64aa63b
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-servisa-service-testing.md
@@ -0,0 +1,26 @@
+# Тестирование сервиса (Service Testing)
+
+Качество обслуживания, предоставляемого веб-приложением, может быть определено включением всех его атрибутов, таких как функциональность, производительность, надежность, удобство использования, безопасность и так далее. Однако для наших целей здесь мы выделяем три конкретные задачи обслуживания (?service objectives), которые подвергаются тщательной проверке в рамках того, что мы называем «?тестированием услуг»:
+
+* Performance;
+* Reliability;
+* Manageability;
+
+Во всех трех случаях нам необходимо моделировать пользовательскую нагрузку для эффективного проведения тестов. Цели производительности, надежности и управляемости существуют в контексте реальных клиентов, использующих сайт для бизнеса. Скорость отклика (в данном случае время, необходимое одному системному узлу для ответа на запрос другого) сайта напрямую зависит от ресурсов, доступных в технической архитектуре. Чем больше клиентов используют эту услугу, тем меньше технических ресурсов доступно для обслуживания запросов каждого пользователя, и время отклика сокращается. Очевидно, что слабо загруженная служба с меньшей вероятностью выйдет из строя. Большая часть сложности программного и аппаратного обеспечения существует для удовлетворения требований к ресурсам в рамках технической архитектуры, когда сайт сильно загружен. Когда сайт загружен (или перегружен), конфликтующие запросы ресурсов должны управляться различными компонентами инфраструктуры, такими как серверные и сетевые операционные системы, системы управления базами данных, продукты веб-серверов, брокеры объектных запросов, промежуточное ПО и т. д. Эти компоненты инфраструктуры обычно более надежны, чем код специально созданного приложения, которому требуются ресурсы, но сбои могут произойти в одном из следующих случаев:
+
+* Компоненты инфраструктуры выходят из строя, потому что код приложения (из-за плохой разработки или реализации) предъявляет чрезмерные требования к ресурсам.
+* Компоненты приложения могут выйти из строя, потому что требуемые им ресурсы не всегда могут быть доступны (вовремя).
+
+Моделируя типичные и необычные производственные нагрузки в течение длительного периода, тестировщики могут выявить недостатки в конструкции или реализации системы. Когда эти недостатки будут устранены, те же тесты продемонстрируют устойчивость системы. Для всех служб обычно существует ряд критических процессов управления, которые необходимо выполнить для обеспечения бесперебойной работы службы. Можно было бы закрыть службу для выполнения планового обслуживания в нерабочее время, но большинство онлайн-служб работают 24 часа в сутки. Рабочий день сервиса никогда не заканчивается. Неизбежно, что процедуры управления должны выполняться, пока служба работает и пользователи находятся в системе. Эти процедуры необходимо тестировать при наличии нагрузки на систему, чтобы убедиться, что они не оказывают отрицательного воздействия на живую службу, известную как тестирование производительности.
+
+**Тестирование управления услугами** (Service Management Testing). Когда служба развертывается в производственной среде, ею необходимо управлять. Для поддержания работоспособности службы необходимо, чтобы ее отслеживали, обновляли, создавали резервные копии и быстро исправляли, когда что-то пойдет не так. Процедуры, которые менеджеры служб используют для выполнения обновлений, резервного копирования, выпусков и восстановлений после сбоев, критически важны для обеспечения надежной службы, поэтому им необходимо тестирование, особенно если служба претерпит быстрые изменения после развертывания. Необходимо решить следующие конкретные проблемы:
+
+* Процедуры не дают желаемого эффекта;
+* Процедуры неработоспособны или непригодны;
+* Процедуры нарушают прямую трансляцию;
+
+По возможности тесты должны проводиться реалистично.
+
+Источник:
+
+[Leadership in test: service testing](https://theqalead.com/topics/service-testing/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-sovmestimosti-vzaimodeistviya-compatibility-interoperability-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-sovmestimosti-vzaimodeistviya-compatibility-interoperability-testing.md
new file mode 100644
index 0000000..60ba148
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-sovmestimosti-vzaimodeistviya-compatibility-interoperability-testing.md
@@ -0,0 +1,52 @@
+# Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
+
+_Тестирование совместимости (compatibility testing): Тип тестирования, который измеряет степень того, насколько удовлетворительно элемент тестирования может функционировать параллельно с другими независимыми продуктами в общей среде (сосуществование) и, по мере необходимости, обменивается информацией с другими системами или компонентами (функциональная совместимость). (ГОСТ 56920)_
+
+Взаимодействие (**Interoperability**) - это способность одной системы взаимодействовать с другой системой. Это взаимодействие между двумя разными системами или двумя разными приложениями вместе. Часто взаимодействие путают с интеграцией, совместимостью и портируемостью.
+
+**Interoperability = Inter + operable**
+
+Inter - означает «между собой», «друг между другом», «взаимно».
+
+Operable - означает «способный выполнить поставленную задачу».
+
+Пример №1: Возьмем пример бронирования вашего рейса. Считайте, что вам нужно поехать из Нью-Дели в Нью-Йорк. Сейчас у вас нет прямого рейса. Вы должны лететь из Нью-Дели в Лондон, а затем лететь стыковочным рейсом из Лондона в Нью-Йорк. Поскольку у вас есть некоторые ограничения по времени, вы бронируете свой рейс из Нью-Дели в Лондон на авиалинии «Jet Airways» и из Лондона в Нью-Йорк на «Virgin Atlantic». Это означает, что все данные о ваших пассажирах были переданы от Jet Airways до Virgin Atlantic. Итак, здесь Jet Airways и Virgin Atlantic, оба являются независимыми приложениями вместе, и при бронировании вашего рейса ваши данные о бронировании передаются от Jet Airways в Virgin Atlantic в полном объеме, без предварительного уведомления.
+
+Пример №2. Аналогичным образом представьте себе систему управления больницей, где записи пациентов обмениваются между одним отделением и другим отделением. Итак, здесь можно связать отдел с приложением. Информация о пациенте передается из одного приложения в другое без предварительного уведомления.
+
+**Уровни Interoperability testing:**
+
+* Физический (Physical Interoperability);
+* Типы данных (Data-type Interoperability);
+* Уровень спецификации (Specification level Interoperability);
+* Семантический (Semantic Interoperability);
+
+**Как провести Interoperability testing?**
+
+Мы можем следовать колесу Деминга (Deming wheel или цикл PDCA), чтобы провести Interoperability testing:
+
+**Plan**: планирование - это самый важный этап определения стратегии выполнения практически любых задач при разработке программного обеспечения. Прежде чем мы на самом деле спланируем определение процедуры выполнения IOT, необходимо понять каждое приложение или систему, развернутую в сети. Мы должны знать обо всех приложениях - их функциональность, поведение, вводимые данные и раскрываемые результаты вывода. Я также рекомендовал бы, чтобы каждое приложение было полностью функционально протестировано и было без дефектов, прежде чем готовить его к interoperability testing. Поэтому, когда вы планируете, не думайте только об одном или двух приложениях, думайте обо всех приложениях как о едином блоке. Планируя этот метод тестирования, вы должны смотреть с высоты птичьего полета. Излишне говорить - задокументируйте свой план. Мы можем использовать план тестирования и немного адаптировать его в соответствии с требованиями к документированию планирования IOT. После того, как ваш план тестирования составлен, переходите к определению условий тестирования (test conditions). Основное внимание при получении условий тестирования не должно ограничиваться отдельными приложениями; вместо этого он должен быть основан на потоке данных через все приложения. Условия должны быть спроектированы таким образом, чтобы проходились если не все, но большинство приложений в сети. После определения условий тестирования переходите к разработке или написанию сценария (в случае, если вы планируете автоматизировать) ваших тест-кейсов. Вы можете создать RTM (матрицу прослеживаемости требований), чтобы сопоставить ваши тест-кейсы с условиями тестирования и ваши условия тестирования с условиями / требованиями приемочного тестирования. Когда вы работаете в сети, также важно спланировать нефункциональное тестирование. Это может быть нигде не записано или не задокументировано, но обязательно для проверки нефункциональных аспектов системы в целом. Эти нефункциональные области будут включать производительность и безопасность. При необходимости вы можете составить отдельный план для функционального тестирования, тестирования производительности и тестирования безопасности; или создайте единый план и разные документы с условиями тестирования для каждого из этих типов тестирования;
+
+**Do:** это промежуток времени, в течение которого вы прогоняете тест-кейсы. Соответственно планируйте свое время для выполнения функционального и нефункционального тестирования. Мы следуем циклу тестирования (testing cycle) на этом этапе выполнения кейсов, логируем дефекты, команда разработчиков их устраняет, после чего мы выполняем повторное тестирование и регрессионное тестирование системы в целом, и предоставляем отчет о результатах тестирования;
+
+**Check** - это этап, на котором мы пересматриваем результаты наших тестов и пытаемся сопоставить их с RTM и проверить, выполнены ли все ожидаемые требования и все ли приложения пройдены. Мы проверяем, что данные передаются и обмениваются правильно и плавно между приложениями / системами. Нам также нужно будет убедиться, что данные, которые мы просматриваем, не изменяются. Также подумайте о том, чтобы сделать ретроспективу всего процесса interoperability testing. Определите области, которые хорошо сработали, те, которые не удались, и любые элементы действий, о которых необходимо позаботиться.
+
+**Act** - действовать по ретроспективным элементам. Пункты, которые были определены как «good practices», продолжают выполняться, а для пунктов, над которыми можно было бы лучше поработать, определяются шаги по их исправлению. Имейте в виду одну вещь: области или шаги, которые не сработали, НЕ должны повторяться. В конце концов, мы должны учиться на своих ошибках, а не повторять их.
+
+**Совместимость (Compatibility, Coexistence)** - это метод, с помощью которого проверяется совместимость 2 или более приложений в одной среде. MS Word и Калькулятор - это два разных приложения, и они показывают ожидаемое поведение независимо в одной и той же операционной системе. Итак, мы говорим, что эти 2 приложения совместимы друг с другом. Другой пример: если сайт Google.com совместим, он должен открываться во всех браузерах и операционных системах. Тестирование совместимости - это нефункциональное тестирование для обеспечения удовлетворенности клиентов. Оно предназначено для определения того, может ли программное обеспечение или продукт работать в различных браузерах, базах данных, оборудовании, операционной системе, мобильных устройствах и сетях. На приложение также может влиять различные версии, разрешения, скорости интернета, конфигурации и т. д. Следовательно, важно тестировать приложение всеми возможными способами, чтобы уменьшить сбои и избежать затруднений, связанных с утечкой ошибок (bug’s leakage). Тест на совместимость всегда должен выполняться в реальной среде, а не в виртуальной. Протестируйте совместимость приложения с различными браузерами и операционными системами, чтобы гарантировать 100% покрытие.
+
+**Типы тестирования совместимости**:
+
+* Тестирование совместимости браузера (Browser compatibility testing): очень популярно при тестировании совместимости. Это необходимо для проверки совместимости программного приложения с различными браузерами, такими как Chrome, Firefox, Internet Explorer, Safari, Opera и т. д.;
+* Аппаратное обеспечение (Hardware): Это необходимо для проверки совместимости приложения / программного обеспечения с различными конфигурациями оборудования;
+* Сети (Networks): Это для проверки приложения в разных сетях, таких как 3G, WIFI и т. д.;
+* Мобильные устройства (Mobile Devices): Это необходимо для проверки совместимости приложения с мобильными устройствами и их платформами, такими как android, iOS, windows и т. д.;
+* Операционная система (Operating System): Это необходимо для проверки совместимости приложения с различными операционными системами, такими как Windows, Linux, Mac и т. д.;
+* Версии (Versions): Важно тестировать программные приложения в разных версиях программного обеспечения. Существует два разных типа проверки версии:
+ * Тестирование обратной совместимости (Backward Compatibility Testing) - тестирование приложения или программного обеспечения со старыми или предыдущими версиями. Это также известно как обратная совместимость (downward compatible);
+ * Тестирование прямой совместимости (Forward Compatibility Testing) - тестирование приложения или программного обеспечения с новыми или будущими версиями. Это также известно как прямая совместимость (forward compatible);
+
+Источники:
+
+* [A Simple Guide To Interoperability Testing (With Examples)](https://www.softwaretestinghelp.com/interoperability-testing/)
+* [What Is Software Compatibility Testing?](https://www.softwaretestinghelp.com/software-compatibility-testing/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-udobstva-polzovaniya-usability-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-udobstva-polzovaniya-usability-testing.md
new file mode 100644
index 0000000..5991e05
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-udobstva-polzovaniya-usability-testing.md
@@ -0,0 +1,54 @@
+# Тестирование удобства пользования (Usability testing)
+
+_Тестирование практичности (usability testing): Тестирование с целью определения степени понятности, легкости в изучении и использовании, привлекательности программного продукта для пользователя при условии использования в заданных условиях эксплуатации (ISO 9126)_
+
+Тестирование удобства пользования - это нефункциональный вид тестирования программного обеспечения, являющийся подмножеством тестирования пользовательского опыта - UX, “Ю-Экс”, user experience. В целом оно подразделяется на понятность, обучаемость, работоспособность, привлекательность и соответствие (understandability, learnability, operability, attractiveness, and compliance). Юзабилити-тестирование предназначено для определения того, насколько программный продукт понятен, легок в освоении, прост в эксплуатации и привлекателен для пользователей при определенных условиях и требованиях. Этот тип тестирования обычно выполняется реальными пользователями.
+
+**Категории юзабилити-тестирования**:
+
+* **Исследовательская**: обычно мы рассматриваем эту категорию на ранних этапах процесса тестирования программного обеспечения. Чем раньше выполняется тестирование юзабилити в процессе тестирования, тем меньше риски в продукте. На этом этапе обычно рассматривается дизайн продукта и концепции, относящиеся к продукту или услуге;
+* **Оценочная**: эта категория описывает оценку выполнения Е2Е теста, а также анализирует эффективность продукта и удовлетворенность пользователей;
+* **Сравнительная**: в этой категории два или более схожих продукта сравниваются по разным атрибутам, таким как дизайн продукта, преимущества и недостатки, что помогает выбрать продукт, который обеспечивает лучший пользовательский опыт;
+
+**Методы юзабилити-тестирования**:
+
+* **Промежуточное** (? hallway) тестирование. Этот метод является одним из наиболее эффективных и экономичных по сравнению с другими доступными методами. При использовании этого метода веб-сайт или продукт для тестирования получают несколько случайных людей, а не обученные специалисты. Поскольку случайные люди тестируют службу без предварительного знания продукта, они тестируют ее более эффективно и предоставляют более точные результаты и честную обратную связь для улучшения, если таковые имеются;
+* **Удаленное** тестирование. Как следует из названия, удаленное тестирование юзабилити проводится людьми, которые находятся в удаленных местах. Обратная связь может быть записана и отправлена случайными людьми, а не экспертом по технологиям. Иногда удаленное тестирование выполняется с помощью видеоконференцсвязи. Этот тип юзабилити-тестирования снижает стоимость по сравнению с другими типами тестирования;
+* **Экспертная оценка**. Эксперта в данной области просят протестировать продукт или услугу и предоставить отзыв, а затем представить результаты. Обычно это быстро, но и стоит дорого. Эксперт находит лазейки и обнаруживает недостатки в продукте или услуге;
+* **Бумажный прототип**. Тестирование бумажных прототипов - один из самых традиционных подходов к тестированию юзабилити. Этот метод включает в себя пробный запуск теста, ручной набросок, рисование моделей или прототипа. Обсуждение последовательности операций и их рисование на бумаге, а также рассмотрение всех возможных исходных данных, сценариев и условий - вот цель этого типа тестирования. Это один из основных типов тестирования, который чаще всего применяется во всех проектах для устранения основных проблем. Выполняя тестирование бумажного прототипа, можно получить больше ясности в процессе выполнения. Тестирование бумажного прототипа обычно проводится в проектной группе. Следовательно, это рассматривается на ранних этапах процесса тестирования. Это относительно более дешевый метод тестирования юзабилити, но не самый эффективный способ тестирования, поскольку он временами занимает больше времени, и существует более высокая вероятность того, что даже после тестирования мы можем пропустить несколько проблем;
+* **Автоматизированное**. Как следует из названия, этот метод тестирования выполняется путем написания сценариев автоматизации. После выполнения теста результаты записываются и отправляются. Для этого типа метода тестирования компании необходимо нанять ресурс, который хорошо знаком с написанием сценариев и построением среды автоматизации. Это один из наиболее часто используемых методов тестирования;
+
+Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
+
+* производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т. д.? (меньше - лучше)
+* правильность (accuracy) - сколько ошибок сделал пользователь во время работы с приложением? (меньше - лучше)
+* активизация в памяти (recall) - как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя)
+* эмоциональная реакция (emotional response) - как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше)
+
+Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке - тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода, и как следствие улучшить качество продукта в целом.
+
+Отсюда становится очевидно, что тестирование удобства пользования может производиться на разных уровнях разработки ПО: модульном, интеграционном, системном и приемочном.
+
+Источники:
+
+* [Usability Testing Tutorial: A Complete Getting Started Guide](https://www.softwaretestinghelp.com/usability-testing-guide/)
+* [What is Usability Testing? UX(User Experience) Testing Example](https://www.guru99.com/usability-testing-tutorial.html#3)
+* [Usability Testing : How To Perform, Test Cases, Checklist, Methods](https://www.softwaretestingmaterial.com/usability-testing/#h-usability-testing-test-cases)
+
+Доп. материал:
+
+* [Вкусный и здоровый гайд по юзабилити-тестированиям](https://vc.ru/marketing/200995-vkusnyy-i-zdorovyy-gayd-po-yuzabiliti-testirovaniyam)
+* [Юзабилити-тестирование на удаленке. Выводы и лайфхаки по итогам года работы](https://habr.com/ru/company/ncloudtech/blog/547956/)
+* [User Interface Elements](https://www.usability.gov/how-to-and-tools/methods/user-interface-elements.html)
+* [Design for Fingers, Touch, and People, Part 1](https://www.uxmatters.com/mt/archives/2017/03/design-for-fingers-touch-and-people-part-1.php)
+* [Дизайн-системы](https://tilda.education/courses/web-design/designsystem/#rec43493282)
+* [Виталий Фридман - От birthday selector до inline validation: Всё, что нужно знать о веб-формах (ч.1)](https://www.youtube.com/watch?v=SuCz4gWvhiY\&list=PLsVTVVvrKX9td9Zm\_4nF6Ywlz6gC5\_e7K\&index=23)
+* [Виталий Фридман - От birthday selector до inline validation: все, что нужно знать о веб-формах (ч.2)](https://www.youtube.com/watch?v=Vs\_TCmY1IGI\&list=PLsVTVVvrKX9td9Zm\_4nF6Ywlz6gC5\_e7K\&index=24)
+* [Коридорное тестирование: получаем быстрый фидбек по макетам](https://habr.com/ru/post/219699/)
+* [Usability and UX reviews as part of QA](https://theqalead.com/topics/usability-ux-reviews-in-qa/)
+* [Игра терминов: UX, UXD, CX, UI, IxD](https://medium.com/%D0%BD%D0%B0%D1%87%D0%B8%D0%BD%D0%B0%D1%8E%D1%89%D0%B5%D0%BC%D1%83-cx-%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD%D0%B5%D1%80%D1%83/%D0%B8%D0%B3%D1%80%D0%B0-%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%BE%D0%B2-ux-uxd-cx-ui-ixd-96f637e6223e)
+* [Тестируем интерфейс без юзеров и регистраций, но с эвристической оценкой Нильсена](https://dou.ua/forums/topic/35289/)
+* [Gamification In UX - 3 Examples Of Using Gamification In UX](https://uxstudioteam.com/ux-blog/gamification-ux/)
+* [Почему хорошее ТЗ еще не означает хороший UI?](https://www.youtube.com/watch?v=xjLwq-gVaiU)
+* [Как обосновать usability баг без придирок и вкусовщины](https://www.youtube.com/watch?v=ocDqHsFWxBo)
+* [Наука о пользовательском опыте. Использование когнитивных искажений в разработке качественных продуктов](https://habr.com/ru/post/512842/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-ustoichivosti-resilience-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-ustoichivosti-resilience-testing.md
new file mode 100644
index 0000000..cf341dc
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-ustoichivosti-resilience-testing.md
@@ -0,0 +1,20 @@
+# Тестирование устойчивости (Resilience testing)
+
+Тестирование устойчивости направлено на обеспечение хорошей работы приложений в реальных или хаотичных условиях. Другими словами, оно проверяет отказоустойчивость приложения или способность противостоять стрессовым или сложным факторам, а также включает в себя тестирование на соответствие (compliance), выносливость (endurance), нагрузочное тестирование и тестирование восстановления (recovery testing). Эту форму тестирования иногда также называют chaos engineering. Поскольку отказов невозможно избежать, тестирование устойчивости гарантирует, что программное обеспечение может продолжать выполнять основные функции и избежать потери данных даже в критических условиях, например, при сбое сети, отказе базы данных, при необходимости выдавая соответствующие сообщения об ошибках. При тестировании на устойчивость запланированным результатом является надежность (Reliability). Устойчивость также известна как восстанавливаемость (recoverability). Тестирование устойчивости можно рассматривать как часть плана обеспечения непрерывности бизнеса (BCP - business continuity plan) организации.
+
+**Шаги**:
+
+* Определение метрик: Разработчики должны выбрать, какие показатели следует измерять, чтобы отразить производительность программного обеспечения. Это может включать скорость ввода и вывода, пропускную способность, время восстановления, задержку и взаимосвязь между метриками;
+* Определение базового уровня производительности;
+* Ввести и измерить сбои: шаг, на котором вводятся проблемы, чтобы попытаться сломать систему. Взлом системы может быть осуществлен различными способами, например, нарушением связи с внешними зависимостями, введением злонамеренного ввода, манипулированием управлением трафиком, ограничением полосы пропускания, отключением систем сопряжения, удалением источников данных и потреблением системных ресурсов. После завершения этих сценариев следует измерить показатели и построить график в соответствии с тем, как каждый из них влияет на производительность;
+* Делайте выводы и реагируйте на результаты: результаты следует использовать для начала обсуждения, исправления программного обеспечения и оценки практики команды разработчиков. Команды также должны использовать эти результаты для улучшения последующих сценариев тестирования;
+
+Источники:
+
+* [software resilience testing](https://searchsoftwarequality.techtarget.com/definition/software-resilience-testing)
+
+Доп.материал:
+
+* [Хаос на практике: зачем ломать production?](https://habr.com/ru/company/domclick/blog/542264/)
+* [Resilience testing: Which tool to choose?](https://www.nagarro.com/en/blog/chaos-engineering-resilience-testing-tools)
+* [The Importance of Resilience Testing](https://www.softwaretestingnews.co.uk/the-importance-of-resilience-testing/)
diff --git a/vidy-metody-urovni-testirovaniya/testirovanie-vynoslivosti-stabilnosti-endurance-soak-stability-testing.md b/vidy-metody-urovni-testirovaniya/testirovanie-vynoslivosti-stabilnosti-endurance-soak-stability-testing.md
new file mode 100644
index 0000000..e2ec5f2
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/testirovanie-vynoslivosti-stabilnosti-endurance-soak-stability-testing.md
@@ -0,0 +1,11 @@
+# Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
+
+_Тестирование износостойкости (endurance testing): Тип тестирования уровня производительности для определения того, может ли элемент тестирования постоянно выдерживать требуемую нагрузку в течение установленного периода времени. (ГОСТ 56920)_
+
+Тестирование на выносливость ([Endurance Testing](https://www.softwaretestinghelp.com/endurance-testing/), оно же [Stability Testing](https://www.softwaretestinghelp.com/stability-testing-tutorial/), [Soak Testing](https://www.softwaretestinghelp.com/soak-testing-tutorial/), [Longevity Testing](https://www.softwaretestinghelp.com/longevity-testing/)) включает в себя тестирование системы со значительной нагрузкой в течение длительного периода времени, чтобы выяснить, как система ведет себя при длительном использовании. То есть для обеспечения того, чтобы производительность и / или время отклика после некоторого длительного периода устойчивой активности были не хуже, чем в начале теста. В основном используется для проверки утечек памяти, времени отклика, правильности подключения и закрытия подключения к модулям (например, БД) и т.п. Обычно продолжительность испытания на выносливость составляет 6-8 часов; может отличаться в зависимости от вашего SLA / требований.
+
+
+
+Источники:
+
+* [Do you really know all types of Performance Tests (Non-Functional Tests)?](https://perfmatrix.blogspot.com/2017/01/type-of-performance-test.html)
diff --git a/vidy-metody-urovni-testirovaniya/vyborochnoe-khaoticheskoe-testirovanie-random-monkey-testing.md b/vidy-metody-urovni-testirovaniya/vyborochnoe-khaoticheskoe-testirovanie-random-monkey-testing.md
new file mode 100644
index 0000000..87488f4
--- /dev/null
+++ b/vidy-metody-urovni-testirovaniya/vyborochnoe-khaoticheskoe-testirovanie-random-monkey-testing.md
@@ -0,0 +1,44 @@
+# Выборочное/хаотическое тестирование (Random/monkey testing)
+
+В ISTQB и некоторых других источниках эти понятия разделяются:
+
+* _Выборочное тестирование (random testing): Разработка тестов методом черного ящика, при котором тестовые сценарии выбираются для соответствия функциональному разрезу, обычно с помощью алгоритма псевдослучайного выбора. Этот метод может использоваться для тестирования таких нефункциональных атрибутов, как надежность и производительность._
+* _Хаотическое тестирование (monkey testing): Тестирование случайным выбором из большого диапазона входов, случайным нажатием кнопок, без соотнесения с тем, как в реальности будет использоваться система._
+
+В других же источниках они используются как синонимы. В любом случае, отдельно по Random testing мне не удалось найти хорошего большого материала, так что оставлю пока как есть.
+
+Monkey Testing - это метод тестирования черного ящика, при котором тестировщик предоставляет случайные входные данные и применяет случайные действия в программном приложении для проверки поведения системы. Это помогает нам оценить, дает ли система сбой при получении таких неожиданных входных данных. Здесь входными данными могут быть данные, которые вводятся в приложение, или нажатие кнопки для следующего действия, или нажатие на ссылку для перехода на другую страницу.
+
+В Monkey testing тестировщиком (иногда и разработчиком) считается «Обезьяна». Если обезьяна использует компьютер, она будет произвольно выполнять любую задачу в системе из своего понимания. Точно так же, как тестировщик будет применять случайные Test case в тестируемой системе, чтобы находить bugs/errors без предварительного определения тестового примера. В некоторых случаях Monkey testing также посвящен модульному тестированию или GUI-тестированию. Основная задача: попытаться сломать систему.
+
+Типы Обезьян:
+
+* Тупая обезьяна (Dumb Monkey): тестировщики не имеют представления о системе и ее функциональных возможностях, флоу, валидности ввода. Затруднено воспроизведение ошибок;
+* Умная обезьяна (Smart Monkey): тестировщик имеет четкое представление о системе, ее назначении и функциональности. Тестировщик перемещается по системе и предоставляет действительные данные для выполнения тестирования. Всё это полезно при воспроизведении ошибок. Также умная обезьяна больше сосредоточена на попытках сломать приложение, чем на поиске случайных ошибок.
+* Выдающаяся обезьяна (Brilliant Monkey): тестировщики обладают глубокими знаниями о приложении, выполняют тестирование в соответствии с поведением пользователя и могут указать некоторые вероятности возникновения ошибок в будущем;
+
+Gorilla testing проводится в соответствии с методом ручного тестирования, при котором тестировщик многократно тестирует модуль, чтобы проверить его надежность. Здесь разработчик и тестировщик объединяются, чтобы протестировать конкретный модуль во всех аспектах. При тестировании Gorilla каждый модуль приложения берется по одному, и для проверки этих модулей вводится диапазон допустимых и недопустимых входных данных. Эти входные значения берутся случайным образом. Тестирование Gorilla направлено на изучение возможностей отдельных модулей. При тестировании Gorilla каждый второстепенный код приложения проверяется до тех пор, пока он не начнет разваливаться или не даст ожидаемых результатов.
+
+* Поскольку Gorilla testing фокусируется на тестировании отдельных модулей, оно может обнаруживать ошибки на ранней стадии, тем самым снижая затраты при высоком покрытии;
+* Gorilla testing гарантирует, что даже заблудший пользователь не столкнется с какими-либо сбоями;
+* Gorilla testing помогает команде понять уровень толерантности системы.
+
+| **Monkey Testing** | **Gorilla Testing** |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Не использует никаких тестовых примеров для тестирования приложения, это просто случайные входные данные | Гарантирует, что у модуля нет проблем, выполняя повторяющиеся задачи по вставке случайных входных данных в модуль |
+| Синоним Random testing | Также известно как повторяющееся тестирование или Тестирование на пытки или Тестирование на отказоустойчивость (repetitive testing or Torture Testing or Fault Tolerance Testing) |
+| Проверяет выполнение всего приложения, используя случайные входные данные, чтобы гарантировать, что система не выйдет из строя из-за неожиданных значений | стремится тщательно протестировать отдельный модуль |
+| Может быть выполнено любым стейкхолдером проекта | Для проведения тестирования gorilla требуется разработчик или тестировщик с хорошим знанием приложения |
+| Фокусируется на сбое (crashing) всей системы из-за случайного ввода | фокусируется на тестировании функциональности конкретного модуля |
+
+| **Monkey Testing** | **Ad-hoc Testing** |
+| --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| Фокусируется на ломании приложения случайным вводом | Фокусируется на поиске ошибок, которые не были обнаружены существующими кейсами |
+| Ошибки обнаруживаются на основе случайных входных значений | Ошибки обнаруживаются на основе неисследованных областей приложения |
+| Тестировщики не знают приложение, они тестируют приложение, случайным образом щелкая или вводя данные, чтобы проверить, не приводит ли это к ошибке | Тестировщик должен хорошо разбираться в приложении и понимать его функции |
+| От тестировщика не требуется быть экспертом в данной области или иметь какие-либо глубокие знания о приложении. | Тестировщик будет знать точный рабочий процесс приложения вместе со знанием предметной области |
+| Может быть выполнено любым стейкхолдером | Обычно выполняется тестировщиком, который знает приложение |
+
+Если мы говорим о ручном тестировании, он может быть менее эффективным, чем другие методы черного ящика. Но если мы добавим тулы автоматизации, она станет мощным инструментом. Просто представьте, что кейсы с различными наборами входных данных генерируются, выполняются и оцениваются автоматически в непрерывном цикле, что позволяет вам запускать тысячи и миллионы кейсов в течение разумного времени.
+
+Источник: [Monkey Testing Guide](https://www.softwaretestingmaterial.com/monkey-testing/)