# Введение

<figure><img src="/files/k1PARFnDhrSfVLnZWCPt" alt=""><figcaption></figcaption></figure>

**Что это за проект?**

“[**Библия QA**](https://vladislaveremeev.gitbook.io/qa_bible/)” - это обновляемая база знаний объемом 560+ страниц:

* Ответы на самые популярные вопросы новичков о профессии и старте карьеры;
* Крупнейшая подборка ссылок и полезных ресурсов;
* Конспект всевозможной теории и ответов на вопросы с реальных собеседований.

**Дисклеймер**:

* Материал не проектировался как обучающий, за этим на хорошие курсы или в фундаментальные книги;
* Здесь можно найти очень многое, но это не значит, что всё это нужно знать. Это копилка, а не учебник. Перечень тем для джунов есть в f.a.q;
* Конспект теории авторский и составлен одним простым человеком, который не senior. Каждую из тем наверняка можно написать полнее и правильнее, ссылки подобрать получше, но на это уйдет еще не один год;
* Проект находится в свободном доступе, не содержит рекламы и открыт для контрибьютинга.


# FAQ для новичков


# Ответы на самые популярные вопросы новичков в чатах

**Хочу войти в айти (в разработку) через тестирование, хороший план?**

Это работало несколько лет назад, потому что тогда к новичкам-тестировщикам могло вообще не быть никаких требований кроме здравомыслия, но общий технический уровень в индустрии сильно вырос, а после эпидемии и агрессивной рекламы работы в 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://habr.com/ru/post/665526/)

**Хочу зарабатывать много денег, мне сюда?**

Первые зарплаты будут небольшими (особенно учитывая конкурс на места), а подняться выше по карьерной лестнице без искреннего интереса не получится, тестирование - слишком обширная область знаний. Без внутренней мотивации к ежедневному самообучению не получится зарабатывать больше чем в любой другой профессии на старте. Так что сферу деятельности стоит менять только если вы всю жизнь чувствовали, что занимаетесь не тем, а тут ёкнуло и хочется взахлеб осваивать именно тестирование. Но даже в этих случаях нужно понимать, что тестирование - не рекордсмен по зарплатам. Далеко не всем компаниям требуются эксперты тестировщики, как это может быть в случае с разработчиками. Именно по этой причине существует отток уже проработавших какое-то время в тестировании специалистов, в другие направления: менеджмент, чистая автоматизация, разработка. Фактически они просто не смогли найти дальнейшие пути развития своих навыков или спрос на свои навыки в текущем рынке при желаемых условиях. Соответственно и зарплаты здесь в среднем ниже, чем на многих специальностях в 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)
* [Почему все «прутся» в 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)

**Хочу работать удаленно джуном, это возможно?**

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

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

Доп. материал:

* [Почему джунов-тестировщиков (Junior QA) не берут на работу?](https://www.youtube.com/watch?v=XwC5cn2nltw)

**Обязательно ли прохождение курсов для дальнейшего трудоустройства?**

Совершенно нет. Безусловно, у *хороших* курсов есть преимущества:

* Педагогический дизайн, последовательность и структурированность;
* Личный опыт преподавателей и примеры из практики;
* Свой тестовый проект для практики, дающий похожий опыт с реальным (или хотя бы просто задания, которые проверяет опытный наставник);
* Сообщество одногруппников;
* Выход из зоны комфорта: вы участник процесса, вы потратили кучу денег на курс;
* Меньше 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://youtu.be/6HsHMo3DCOQ?si=B_ryaBhqcI_8Mq1H)
* [Без чего можно стать тестировщиком?](https://habr.com/ru/articles/660467/)

**Я всю жизнь работал %название должности%, это может как-то пригодиться в тестировании?**

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

Доп. материал:

* [Как я перешла в тестирование](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/)
* [Как стать тестировщиком ПО, ответы на часто задаваемые вопросы](https://habr.com/ru/post/674678/)


# Качества и навыки, которыми нужно обладать тестировщику?

* Самые главные:
  * Развитые софт-скиллы;
  * Самостоятельность;
  * Прокачанное умение гуглить.
* Второстепенные, но всё еще важные:
  * Пытливый ум и желание докопаться до первопричины проблемы;
  * Крайне полезно иметь склонность к развитию T-shaped skills (когда специалист углубляется в свою профессиональную область, но также развивается поверхностно в смежных областях);
  * QA Engineer это всё же engineer, желательно иметь склонности к [problem solving](https://www.youtube.com/watch?v=1hKRsKKwtVU);
  * Общая грамотность;
  * Устойчивость к рутине;
  * Умение воспринимать текстовую информацию. Ютуб - это хорошо, но большинство доки пишется текстом.

Доп. материал:

* [Какие навыки нужны тестировщику](https://education.vk.company/news/kakie-navyiki-nuzhnyi-testirovschiku)
* [Ключевые навыки и обязанности](https://www.careerist.com/ru-insights/testirovshchik-po-znachenie-opredelenie-klyuchevye-navyki-i-obyazannosti)
* [Образ современного тестировщика. Что нужно знать и уметь](https://habr.com/ru/articles/666930/)
* [Миф об образе мышления в тестировании](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:

* [Софт-скиллы в QA: полный гайд](https://testengineer.ru/soft-skills-qa/)
* [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/)


# Что должен знать и уметь Junior? Что спросят на собеседовании?

Конкретного ответа на этот вопрос нет, всё зависит от компании и вакансии. Ожидания в двух разных компаниях и даже проектах могут не пересекаться совершенно никак. Мидл+ из одной компании может оказаться джуном- в другой.\
Если всё же пытаться вывести среднее, то вот несколько ссылок:

* [QA RoadMap 2024](https://roadmap.sh/qa)
* [QE learning roadmap](https://github.com/bnorrish/qe-learning-roadmap/blob/main/Quality%20Engineer%20Roadmap.pdf)
* [Awesome Quality Assurance Roadmap](https://github.com/fityanos/awesome-quality-assurance-roadmap)
* [Junior QA](https://www.mindmeister.com/ru/1324282825/junior-qa?fullscreen=1)
* [QA Roadmap](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. Карьера тестировщика
* [Джуниоры-тестировщики в 2024 году: какие нужны скилы и как проходит процесс найма](https://habr.com/p/790656/)

Некоторые компании подробно расписывают на своих порталах ожидания от каждой стадии развития сотрудника, по этой же теме много видео на 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) вопросы разделены по грейдам. Еще подборка: [Junior](https://www.youtube.com/watch?v=TeckTCITenI)/[Middle](https://www.youtube.com/watch?v=OGmhxliZ8sY)/[Senior](https://www.youtube.com/watch?v=UOfm9jktnR4).

**Английский**

Помимо вышеперечисленного нужно помнить об английском языке. Он нужен для чтения документации и актуальных статей, просмотра вебинаров, поиска ответов на вопросы, т.к. в русскоязычном сегменте информации в разы меньше и пока ее переведут она уже устаревает. В РБ и Украине гораздо чаще чем в РФ язык нужен для ведения проектной документации и общения с иностранными коллегами (не надейтесь особо на переводчики и авто субтитры, всё это еще далеко от совершенства). Конечно, компании работающие на внутренние рынки могут не требовать знание языка, но тут, опять же, остается открытым вопрос личного развития. Если же в вакансии указан необходимый уровень владения языком, то будьте готовы к тому, что как минимум попросят ответить на какой-нибудь простенький житейский или HR-вопрос на английском. В отдельных случаях, где явно указана необходимость разговорного уровня, все собеседование вполне может пройти на английском.

Доп. материал:

* [Что нужно знать тестировщику без опыта (Junior QA Engineer)?](https://www.youtube.com/watch?v=DCImUUyQ_Fs)
* [Собеседование 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://habr.com/ru/companies/tochka/articles/811649/)
* [Как стать 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/)
* [Практика обучения в QA отделе. Профиль тестировщика](https://habr.com/ru/company/usetech/blog/659305/)
* [Реестр профессиональных стандартов - Специалист по тестированию в области информационных технологий](https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=57024)
* [Работа в продуктовой компании: какие навыки нужны тестировщику](https://www.software-testing.by/blog/product-qa-skills/)

Английский:

* [Как тестировщику учить английский язык](https://software-testing.ru/library/around-testing/job/3591-english-for-qa-engineers)
* [Таблица уровней английского языка](https://englex.ru/english-levels-table/)
* [Английский для тестировщиков - как надо](https://habr.com/ru/post/668586/)
* Марафон “Как 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)
* [Как я осилил английский](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/)
* [Выучить английский самостоятельно вполне реально, если вы айтишник. И вот почему](https://habr.com/ru/post/671174/)
* [Пассивный залог в английском для тестировщиков](https://pointschool.ru/passivnyj-zalog-v-anglijskom-dlya-testirovshchikov/)
* [A2 English for Developers](https://www.freecodecamp.org/learn/a2-english-for-developers/)


# С чего начать обучение и куда развиваться?

*Уровень 0: базовый курс по Computer Science.*

Начать нужно с простого ознакомления с тестированием и самый частый совет для этого - книга Романа Савина “Тестирование дот ком”. Воспринимайте ее просто как худ. лит. на 1-2 вечера, т.к. местами она спорная и устаревшая, но простыми словами даст хоть какое-то представление о тестировании. После ознакомления я бы посоветовал выбрать по отзывам в коммьюнити хороший базовый онлайн-курс и пройти его, либо по возможности пойти на офлайн-курсы местной компании с возможностью последующего трудоустройства - это вообще лучший вариант. Если нет возможности, то хорошим выбором будет бесплатная [книга Святослава Куликова “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software_testing_book_download/) + бесплатный [курс в дополнение к ней](https://svyatoslav.biz/urls/stc_online/) и далее уже имея общее представление и понимая азы равномерно восполнять пробелы, подготавливаясь к собеседованиям по требованиям в вакансиях.

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

По мере роста компетенций как можно раньше стоит начать проходить собеседования и пытаться устроиться на любую стажировку, вообще любой вариант, где вы сможете применять знания и указать этот опыт в резюме, т.к. без опыта сейчас найти работу очень трудно. Если нет никаких офлайн вариантов, как было у меня, можете регистрироваться на краудтестинговых платформах (но зачастую это гиблое дело + многие работодатели игнорируют такой опыт), искать в тг-каналах возможности протестировать какие-то проекты за бесплатно (иногда там ищут волонтеров за опыт) либо придумать такой тестовый проект себе самому - снова взяться тестировать какое-либо приложение или сайт, но теперь делать это близко к тому, будто это ваша реальная работа. То есть чтобы было что потом рассказать и показать результаты (тест-кейсы, баг-репорты и т.п.). Багов хватает в любом популярном приложении/сайте, стоит только поискать, хотя баг-репорты и не главное. Главное показать понимание, что и как тестировать.

Когда вы устроитесь на свою первую работу, спустя некоторое время сможете начать готовиться к дальнейшему развитию и выбору направления, ведь никто не заставляет всю жизнь быть ручным тестировщиком. Вы можете сосредоточиться на 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 если где и смотрят, то на западе и обычно не более чем как небольшой бонус.

Доп. материал:

* [С чего начать обучение тестировщика](https://ru.hexlet.io/blog/posts/navyki-testirovschika-i-kak-im-stat)
* [Профессия тестировщика. Как прийти в IT, если ты гуманитарий?](https://youtu.be/Vc9hA6tDjYI?si=2YXWmjYT3ROzf1C3)
* [Как стать тестировщиком? Тестировщик с нуля. Пошаговая инструкция](https://youtu.be/cePD7w3_qys?si=DHJi2-laZMTmGjsI)
* [Направления развития для Junior QA в рамках процессов тестирования](https://www.youtube.com/watch?v=VUiOtjFVVAU)
* [Как стать тестировщиком с нуля](https://habr.com/ru/company/plarium/blog/561454/)
* [Взгляд на ИТ-Нарнию: путь от джуна до Senior в финтехе](https://habr.com/ru/company/smart_it/blog/672654/)
* [Как учиться, чтобы научиться](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)
* [QA-обучение без границ](https://habr.com/ru/post/661591/)
* [Тестировщик на прокачку: как 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/)
* [Крепостное право в ИТ](https://habr.com/ru/post/660337/)
* [Куда расти тестировщику? Надо ли для этого уходить из QA?](https://habr.com/ru/companies/sibur_official/articles/743546/)
* [Тестировщик: 7 путей развития](https://www.careerist.com/ru-insights/testirovshchik-7-putey-razvitiya)


# Как составить резюме?

Кратко о базовых рекомендациях.

**В каком виде**:

* Вариант минимум: PDF + расшаренная копия на google-диске. Оформить покрасивее можно [тут](https://www.canva.com/resumes/templates/), [тут](https://novoresume.com/resume-templates), [тут](https://create.microsoft.com/en-us/templates/resumes) или еще где-то;
* Вариант получше: резюме в [LinkedIn](https://www.linkedin.com/help/linkedin/answer/a551182) (мастхэв!) + в веб-версии на [github-pages](https://pages.github.com/) + 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://habr.com/p/733108/)
* [Как составить резюме тестировщика: гайд от опытного QA-инженера](https://skillbox.ru/media/code/kak-sostavit-rezyume-testirovshchika-gayd-ot-opytnogo-qainzhenera/)
* [Резюме начинающего тестировщика (и не только тестировщика) с Михаилом Портновым](https://www.youtube.com/watch?v=C6ny1evgntg)
* [Идеальное резюме кандидата: миф или реальность](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)
* [Топ-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)
* [Резюме тестировщика QA - или искусство быть замеченным](https://youtu.be/53nmsdx1Flo?si=VM8FlzwOVVejQodz)


# Где искать работу?

Подробнее см. в источнике.

* [Linkedin](https://www.linkedin.com) ([добавляйтесь в друзья](https://www.linkedin.com/in/vladislaveremeev/) :)
* [hh.ru](https://hh.ru)
* [rabota.by](https://rabota.by/)
* [career.habr.com](https://career.habr.com)
* Группы Facebook
* Telegram-каналы
* Группы Вконтакте
* Чаты специалистов или профессиональных мероприятий
* Офлайн конференции/кэмпы/мастер-классы
* Сайты или группы от крупных компаний
* Зарубежные площадки для поиска работы

Источники:

* [Где искать работу в IT?](https://habr.com/ru/post/655577/)

Доп. материал:

* [🔍 ТОП-12 джоб-сайтов: где программисту разместить резюме и найти работу](https://proglib.io/p/top-12-dzhob-saytov-gde-programmistu-razmestit-rezyume-i-nayti-rabotu-2023-07-19)
* [Где искать работу в IT? Самые эффективные каналы поиска в 2024](https://vc.ru/hr/988982-gde-iskat-rabotu-v-it-samye-effektivnye-kanaly-poiska-v-2024)
* [Сайти для пошуку роботи в Україні, в тому числі віддалено](https://dou.ua/forums/topic/37190/)
* [Стажировка для тестировщика (QA Engineer)](https://www.youtube.com/watch?v=FAyDh0tqzzc)
* [На работу не берут без опыта, а опыт без работы не получить. Что делать?](https://habr.com/ru/articles/752380/)


# Как происходит процесс найма?

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

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/)
* [Разбор тестовых заданий для Junior QA](https://youtu.be/e12TjJHux1Y?si=vatYXsdX_wR7SbVS)
* [Практическое тестовое задание на позицию тестировщика](https://youtu.be/3Ufo23ylSPU?si=D8oMEhS50UaeIw-G)
* [Большая подборка тестовых заданий для тестировщиков. Гайд и рекомендации](https://habr.com/p/790438/)


# Как проходить собеседование?

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

В случае онлайна так же необходимо быть на связи уже за 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/)
* [Типичные ошибки начинающего 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/)
* [Собеседование 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/)
* [YAMP 30.04.2022 - Александр Попсуенко (Яндекс) и Андрей Морозов (Joom) расскажут как собеседование выглядит со стороны нанимающего менеджера и поделятся на что они обращают внимание на собеседовании больше всего](https://www.youtube.com/watch?v=n3OfjZxFo04\&t=9882s)
* [Ошибки на технических собеседованиях](https://habr.com/ru/company/usetech/blog/667448/)
* [Как я проходил собеседования на QA-инженера в разных компаниях и что на них обычно спрашивали - 2024](https://habr.com/p/812705/)
* [Что должен знать junior тестировщик перед первым собеседованием](https://bbbl.dev/articles/manual-qa)

Мок-интервью:

* [QAGuild: Мок интервью на позицию Senior QA Automation](https://www.youtube.com/watch?v=KqslEN0tiMM)
* [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)
* [Вадим Ксендзов](https://www.youtube.com/@vadim_ksendzov/videos)
* [Как завалить QA интервью одним вопросом](https://youtu.be/478CD5Ll7uU?si=OJsM_Lst8pr-DAGF)
* [Публичное собеседование. Мок-интервью для QA-инженера](https://youtu.be/F0R8UfliZnU?si=3UW9EQV783DED8bF)
* [Собеседование на тестировщика ПО (Junior QA) в 2024](https://youtu.be/p3o7-cifirM?si=tYqakc4TF94Svi0Y)
* [Я провел 1000 собесов QA и вот что я понял](https://youtu.be/kWIB-VvJ50o?si=dgQGGbAYgayEJTr_)
* [Публичное cобеседование QA Junior: реальные вопросы с собеседования](https://youtu.be/feetkMxnB88?si=_EgvhlKZBkE4eR5G)
* [Публичное собеседование на позицию Head of QA](https://www.youtube.com/live/GjXkgf4EqM0?si=p1YnR6COaZfF5Lw5)


# Начало работы Junior-тестировщика

Тут снова всё индивидуально и зависит от компании и даже проекта, в частности от типа компании (инхаус, аутсорс, аутстаф), размера штата, процессов и текущих задач.

**Онбординг**

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

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

**Первые задачи**

* **Один тестировщик**: В нормальной ситуации вы проведете исследовательское тестирование, составите несколько наборов кейсов или чеклистов, задокументируете все текущие баги и в дальнейшем будете заниматься тестированием новых сборок, проверкой исправления найденных дефектов и проведением регрессии;
* **Отдел тестирования**: Вам назначат посильные, но, вероятно, рутинные задачи, вроде регрессии, актуализации артефактов и т.п.

**Советы единственному джуну тестировщику**

Вообще создавать отдел тестирования нанимают QA Lead, а если вы джун без опыта работы, то либо работодатель не понимает что делает, либо у него есть вполне конкретная “боль”, которую он с помощью тестировщика хочет решить, в таком случае проводить целое расследование не придется - наверняка все объяснят еще на собеседовании.

Начинать знакомство с проектом лучше с интервью. Станьте журналистом. Что из себя представляет структура организации, а именно кто над кем стоит и кто за что отвечает? Где больше всего багов, каким видят тестирование сейчас и какие ожидания в будущем? Оцените зрелость процессов по CMM и TMM, зрелость проекта (новый/старый-зрелый/старые-зрелые где будут глобальные изменения) и команды, определите методологию разработки. Соберите метрики, подбейте статистику, подумайте как на эту статистику можно повлиять. Проведите вводную лекцию команде: что такое QA, как оно может помочь, с какими проблемами обращаться и зачем всё это надо.

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

Доп. материал:

* [Как решить 4 главные проблемы, с которыми сталкивается любой стажёр-тестировщик](https://habr.com/ru/company/ispring/blog/664220/)
* [Менторство в QA: как погрузить новых сотрудников в проектную работу](https://habr.com/ru/company/simbirsoft/blog/663618/)
* [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)
* [Осторожно, новичок! Как сохранить качество тестирования с приходом нового специалиста](https://habr.com/ru/company/icl_services/blog/660871/)
* [Один день из жизни тестировщика (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/)
* [Как прийти в тестирование первым джуном и не лишить всех работы](https://habr.com/ru/post/666996/)
* [Осторожно, новичок! Как сохранить качество тестирования с приходом нового специалиста](https://www.software-testing.ru/library/around-testing/management/3821-cl-services)
* [Советы для начинающих тестировщиков на первом месте работы](https://www.youtube.com/watch?v=vS2UYa5Jcf4)
* [Идеальное соотношение разработчиков и тестировщиков](https://telegra.ph/Idealnoe-sootnoshenie-razrabotchikov-i-testirovshchikov-07-22)
* [Стресс-тестирование: как тестировщикам жить в беспокойном мире багов](https://habr.com/ru/company/innotech/blog/675908/)
* [Что делает тестировщик на работе? / Мой день (QA Engineer)](https://www.youtube.com/watch?v=BUDog4mFrDI)
* [Что действительно должен уметь, знать тестировщик (junior qa)](https://youtu.be/3DoeLbrYuzY?si=PF-Ell17vuxQrhak)


# Ошибки в работе у начинающих тестировщиков

1. Во всем видят дефекты. Как избежать:
   * Внимательно анализировать требования
   * Владеть информацией о том, как должен работать продукт
   * Если сомневаешься, что это дефект - спроси БА или ответственного
   * Несколько раз перепроверь прежде чем регистрировать дефект
2. Пытаются сразу все сломать. Как избежать:
   * Начинать тестирование только с положительных тестов
   * Акцентировать внимание на том, что в приоритете для заказчика
   * Не проверять редкие сценарии в первую очередь
3. Боятся задавать вопросы. Как избежать:
   * Начать понимать, что коммуникация это важная и неотъемлемая часть работы
4. Не интересуются, кто и за что отвечает, как устроены процессы. Как избежать:
   * Узнать у ПМ об областях ответственности каждого члена команды
   * Узнать у ПМ о всех процессах на проекте
5. Паникуют при малейшей трудности. Как избежать:
   * Без паники, п. 3 и 4 помогут разобраться
6. Пытаются применить сразу все, что изучили. Как избежать:
   * Помнить, что у каждого вида тестирования своя цель
   * Бюджет всегда ограничен, расставлять приоритеты
7. Задают один и тот же вопрос несколько раз.

Доп. материал:

* [Шесть тест-персон, с которыми не стоит иметь дела](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/)
* [Главные ошибки начинающих тестировщиков. Как их избежать?](https://youtu.be/TeVRUcOiQXw?si=0CB-DFG099P3hh8x)
* [Ошибки начинающих тестировщиков | QA START UP](https://youtu.be/7_aPi_YUysE?si=LnYR0fzdEIn0bJrd)
* [7 ошибок начинающего тестировщика](https://sedtest-school.ru/about-qa/7-oshibok-nachinayushhego-testirovshhika/)
* [Ошибки, которые делает почти каждый начинающий тестировщик, и как их избежать](https://www.careerist.com/ru-insights/oshibki-kotorye-delaet-pochti-kazhdyy-nachinayushchiy-testirovshchik-i-kak-ih-izbezhat)


# Как взаимодействовать с коллегами?

**Как правильно задавать вопросы?**

В чатах, коллегам, на форумах, где угодно:

* в случае общественных чатов убедитесь, что ответа нет в описании канала или в закрепленном сообщении, а также что ваш вопрос уже не задавали раньше (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)
* [Пойми меня, если сможешь. Или как донести мысль заказчику (понятно и с первого раза)](https://habr.com/ru/company/surfstudio/blog/674418/)
* [Как QA выстроить эффективное взаимодействие с разработчиками. Один возможный путь](https://habr.com/ru/articles/471576/)
* [Soft skills: общение с коллегами и командой — Камилла Самохина, Тинькофф](https://youtu.be/BFhdLITJobc?si=IkceEUI_TXOQH0Dx)


# Перспективы профессии

Сколько лет еще продержится ручное тестирование? Заменит ли автоматизация мануальщиков?

**Почему современная разработка нуждается в manual-тестировщиках**:

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

То, что у нас принято называть “пользовательским опытом” (user experience, UX) - самая первая и главная причина, почему сейчас необходимо ручное тестирование, и почему оно будет необходимо всегда. Мы все бываем критичны к чужой работе, и разработчики критикуют тестировщиков, и зачастую по делу! Но когда дело касается не функциональности, а впечатлений человека, клиента, то нет и не будет замены человеческому глазу, его внимательности, его склонности замечать приятное. Хотя простые 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/)
* [Профессия тестировщик. Востребованность и актуальность](https://www.youtube.com/watch?v=d1t6VzZ6xqM)
* [Что ждет тестировщиков в этом году (спойлер: все хорошо)](https://testengineer.ru/chto-zhdet-testirovshchikov-v-ehtom-godu/)


# Полезные ссылки


# Список полезных ресурсов на разных платформах

**Telegram**:

Must have (потому что [раз](https://t.me/general_it_talks/161), [два](https://www.youtube.com/watch?v=Rf9KJbSEmuI))! Каналы это: знакомство с коммьюнити, живое общение, уникальный опыт тысяч коллег; богатая история сообщений, где поиском по истории сообщений можно найти все что угодно; в шапке каждого канала закреплено сообщение со своим набором полезностей. Кроме того, некоторые каналы специализируются на мониторинге нового полезного материала с основных порталов, так что можно даже не погружаться с головой в хабр, доу, медиум и т.п., вам отберут все самое полезное. В конце концов, в этих каналах публикуются анонсы грядущих онлайн-мероприятий, чтобы ничего не упустить.

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

* Большая подборка чатов @[it\_chats](https://t.me/it_chats)
* [40 Telegram-каналов & чатов тестировщиков - 2024](https://willday.ru/blog/luchshie-telegram-kanaly-i-chaty-dlya-testirovshchikov-QA-inzhenerov/)
* [Список интересных групп, каналов и ботов телеграма](https://github.com/goq/telegram-list)
* Огромный чат для новичков @[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://qa-sisters.com/) - женское комьюнити
* Канал подкаста 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)
* Группа канала AllaboutQA @[AllaboutQA](https://t.me/AllaboutQA)
* [Библиотека разработчика](https://t.me/devlib)
* [automation remarks](https://t.me/automation_remarks)
* [QA Сhannel](https://t.me/qa_channel)
* Чаты по penetration testing (pen test, pentest):
  * @[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)
* Статьи, ссылки, фан:
  * @[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)
  * @[testerofqa](https://t.me/testerofqa)

**Youtube-каналы**:

* [Artsiom Rusau QA Life)](https://www.youtube.com/c/ArtsiomRusauQALife) + [бесплатный курс 2024!](https://youtube.com/playlist?list=PLKbJd47Kcbju2Vhi-FL7AI14vItVmGYk-\&si=gYkoVjcznkxqwf2O)
* [Леша Маршал](https://www.youtube.com/@leshamarshal) + [бесплатный курс!](https://youtube.com/playlist?list=PLZqgWWF4O-zg03RGSZ2GpHLE3BmO8bjKo\&si=EU_a1Mq-3ZDKmMF3)
* [Вадим Ксендзов (тренировочные собеседования!)](https://www.youtube.com/@vadim_ksendzov/streams)
* [Podlodka Podcast](https://www.youtube.com/@PodlodkaShow)
* [Heisenbug](https://www.youtube.com/@Heisenbugconf)
* [Serhii Hlivinskyi - QA START UP](https://www.youtube.com/@QASTARTUPITTrainingCenter)
* [Ilarion Halushka](https://www.youtube.com/@IlarionHalushka)
* [Компания 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/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)
* [Bogdan Ovsiyuk](https://youtube.com/playlist?list=PLof3mAh50UD2x4rcptK81NW_B4Xc_eSkn\&si=IvSZPjn1rRHLoa8P)
* [Alex QA](https://www.youtube.com/channel/UC4FsI-c69O8ui_5kwM3dalA/featured)
* [QA SoftClub](https://www.youtube.com/channel/UCcXYca9A9cWNhW0pNLlg4cw)
* [Automation Step by Step](https://www.youtube.com/@RaghavPal)
* [Плейлист “Качество и Тестирование ПО” от VK (2015)](https://youtube.com/playlist?list=PLrCZzMib1e9pDKLsabJYuODdVJrHYc4Jd\&si=FFYYN-7HvGRM8eaL)
* [Плейлист “Тестирование мобильных и веб-приложений”](https://www.youtube.com/playlist?list=PL0sm2CxWDkuuVRlcP31lWBLAafcQIikyb)
* [Плейлист "Курс QA"](https://www.youtube.com/playlist?list=PL2MvZpJt-m5nX6AKyn7k0jLIAzY8yXl3o)
* [Плейлист "Курс Тестирование ПО с нуля"](https://youtube.com/playlist?list=PLRs8EELOYKc7DYIQixlV1s4EH5SR3TdNB\&si=RFrqahdhnV1dL5O3)
* [Плейлист "Продвинутый Курс Тестирование ПО с нуля до миддла от Иллариона."](https://youtube.com/playlist?list=PLoZfdp36DZcqq6PoJJVHlS_c_1G89bkh7\&si=dkxMVoS9KmhkdeYl)
* [Плейлист "Курс тестировщика ПО с нуля!"](https://youtube.com/playlist?list=PLbuh2pN46AEtzkHzV2QJbc9sJCB0IbmTJ\&si=BzsbM-VHcU7InhWC)

**Web**:

* <https://testengineer.ru>
* [https://qarocks.ru](https://qarocks.ru/)
* <http://testbase.ru/>
* [https://www.guru99.com](https://www.guru99.com/)
* [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)
* [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)
* [http://wannatest.ru/](http://wannatest.ru)
* <http://radio-qa.com/>
* [Сайт с материалами для сдачи экзамена ISTQB](https://www.rstqb.org/ru/istqb-downloads.html)
* [Тренажер для подготовки к сдаче ISTQB (на русском).](https://istqb-training.ru/)

**Книги**:

* Очень хвалят вот эту [подборку](http://okiseleva.blogspot.com/2014/02/blog-post_6.html?m=1);
* Если выделить самые советуемые книги в коммьюнити, то получится следующее:
  * Самая спорная книга для новичков Р. Савин - “Тестирование дот ком”. Является скорее вариантом худ. лита “для чайников” на один вечер и может местами быть спорной и устаревшей;
  * [Святослав Куликов - “Тестирование программного обеспечения. Базовый курс.”](http://svyatoslav.biz/software_testing_book/) Самая советуемая книга для начинающих, по сути курс EPAM в виде книги;
  * [100-Year QA-Textbook на русском - 2024](https://mentorpiece.org/100/);
  * 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 пиратство крайне не приветствуется, упоминать такие поступки не стоит, а обсуждение в чатах может легко закончиться баном. Кроме того, вся ценность курсов именно в практике и обратной связи от опытных преподавателей.

* Stepik
  * [Тестирование ПО с нуля. Теория + Практика (Artsiom Rusau)](https://stepik.org/course/171826/promo)
  * [Тестирование ПО с нуля. Тренажер](https://stepik.org/course/188242/promo)
  * [Тестирование ПО: Postman для тестирования API](https://stepik.org/course/120679)
  * [Интерактивный тренажер по SQL](https://stepik.org/course/63054/promo)
  * [Автоматизация тестирования с помощью Selenium и Python](https://stepik.org/course/575/promo)
  * [Тестировщик. Курс](https://stepik.org/course/116387)
* Другие ресурсы
  * [freecodecamp - Quality Assurance](https://www.freecodecamp.org/learn/quality-assurance/)
  * [Test Automation University](https://testautomationu.applitools.com/)
  * [Бесплатные курсы по автоматизации с живыми вебинарами и домашними заданиями](https://redrover.school/)
  * [Software Testing Introduction (RUS)](https://learn.epam.com/detailsPage?id=a4a1b6e2-4e51-455d-ac5b-e60f23d4ed69)
  * [Computer Science Basics](https://learn.epam.com/detailsPage?id=07464fe7-306f-4aa2-abdb-fb81ba509124)

Доп. материал:

* Беда “войти в айти” или курсы тестировщика отзывы [часть 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)
* [Software Testing - QA Learning](https://play.google.com/store/apps/details?id=nir.com.qalearning)

**Другие сборники материала и ответов на вопросы**:

* **Англоязычные**:
  * [Awesome Testing](https://github.com/TheJambo/awesome-testing#readme)
  * [ISTQB](https://www.istqb.org)
  * [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)
  * [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)
  * [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/)
  * [Free QA testing Training materials](https://training.safetyculture.com/training-material/qa-testing-training-material/)
  * [Self-Access Learning Materials](https://qahighereducation.com/the-ace-team/self-access-learning-materials/)
* **Русскоязычные**:
  * [ГОСТ Р 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)
  * [Слушайте, читайте, используйте: полезные материалы для тестировщиков 2024](https://blog.skillfactory.ru/poleznye-materialy-dlya-testirovshhikov/)
  * [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\_Links](https://github.com/skydive-dz/QA_Links/blob/master/Links.md)
  * [Всё о QA: 80 бесплатных материалов по грамотному тестированию](https://tproger.ru/digest/free-software-testing-books/)
  * [Что должен уметь начинающий тестировщик](http://testbase.ru)
  * [Библиотека 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)

**Словари терминов (в т.ч. элементов интерфейса)**:

* [Словарь начинающего тестировщика ПО](https://it-testing-school.com/blog/dictionary)
* [Сленг Тестировщика](https://testgrow.ru/lecture31)
* [Словарик айтишника или Что? Где? Куда? Часть 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/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/)

**Чек-листы и идеи для тестов**:

* [Чек-листы для тестировщиков: примеры - Блог GeekBrains](https://blog.geekbrains.by/chek-listy-dlja-testirovshhikov/)
* [Как составить чек-листы для эффективного тестирования продуктов: простые шаги и примеры](https://habr.com/ru/articles/723948/)
* [Чеклисты и Тест-кейсы](https://evgenyleukhin.github.io/knowledge-bank/docs/qa/checklist-and-test-cases/)
* [Как тестировать методы REST API](https://habr.com/ru/articles/704090/)
* [Читлисты для тестировщика](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/)
* [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/)
* [Чек-лист для тестирования числового поля](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)
* [Как тестировать 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)
* [Чек-лист для начинающего автотестера на Java](https://testit.software/blog/post/chek-list-dlya-nachinayushchego-avtotestera-na-java)

[**Блоги**](https://www.maxshulga.ru/2016/06/useful-testers-resources.html?m=1):

* [Блог Artsiom Rusau QA Life (Артем Русов)](https://rusau.net/blog)
* [Блог о тестировании и качестве ПО | Точка качества](https://tquality.ru/blog/) - Cтатьи о тестировании программного обеспечения, профессиональные мнения специалистов по тестированию, опыт реальных QA проектов и интервью с известными тестировщиками.
* [LearnQA](https://www.learnqa.ru/blog) - LearnQA: Полезные статьи для тестировщиков.
* [Никита Макаров](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) - хорошие статьи, но с адским белым шрифтом на черном фоне
* [QAk-QAk - и в продакшен](https://podcast.ru/1591500271)
* [IT Блог: Программирование и QA](https://smartiqa.ru/main#!/tfeeds/749847664865/c/QA) - актуальные новости из мира разработчиков и QA, образовательные статьи и переводы.

**Instagram/TikTok**:

* [Артём Русов](https://www.instagram.com/rusau.qalife/)
* [Вадим Ксендзов](https://www.instagram.com/vadim_ksendzov/)
* [oksana.it.switcher](https://www.instagram.com/oksana.it.switcher/)
* [ladybug.qa.courses](https://www.instagram.com/ladybug.qa.courses/)
* [protestinginfo](https://www.instagram.com/protestinginfo/)
* Рекомендации айтишников: блогеры, Youtube-каналы, страницы в Instagram


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

**DevTools**:

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

* [Начало работы с Chrome DevTools](https://developer.chrome.com/docs/devtools/overview?hl=ru)
* [Имитация мобильных устройств в режиме устройства](https://developer.chrome.com/docs/devtools/device-mode?hl=ru)
* [Начало работы с просмотром и изменением DOM](https://developer.chrome.com/docs/devtools/dom?hl=ru)
* [Просмотр сетевой активности](https://developer.chrome.com/docs/devtools/network?hl=ru)
* [Анализ производительности](https://developer.chrome.com/docs/devtools/performance?hl=ru)
* [Безопасность: понимание проблем безопасности](https://developer.chrome.com/docs/devtools/security?hl=ru)
* [Удаленная отладка Android-устройств](https://developer.chrome.com/docs/devtools/remote-debugging?hl=ru)
* [Средства консоли Chrome, которыми вы, возможно, никогда не пользовались](https://habr.com/ru/company/ruvds/blog/486692/)
* [Изучаем DevTools в Google Chrome](https://youtu.be/GyKY5kIRP00?si=gY1Me2opxwkwvg98)
* [Chrome DevTools: что это - обзор на инструменты](https://blog.skillfactory.ru/glossary/chrome-devtools/)
* [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)
* [Полезные функции DevTools для тестировщиков](https://habr.com/ru/post/558694/)
* [Chrome DevTools. Обзор основных возможностей веб-инспектора](https://www.youtube.com/watch?v=C8Z-N0y6Sqo)
* [Chrome Developer Tools для тестировщика](https://testengineer.ru/chrome-developer-tools-dlya-testirovshchika/)
* [Lighthouse](https://developers.google.com/web/tools/lighthouse?hl=ru)
* [Советы по инструментам разработчика](https://developer.chrome.com/docs/devtools/tips?hl=ru)

  Официальная документация DevTools:

  * [Chrome DevTools](https://developer.chrome.com/docs/devtools)
  * [Firefox DevTools](https://firefox-source-docs.mozilla.org/devtools-user/)
  * [Safari DevTools](https://support.apple.com/ru-ru/guide/safari/sfri20948/mac)

**Тестирование API**:

API (Application Programming Interface) — это набор правил и механизмов, которые позволяют различным программным приложениям взаимодействовать друг с другом. Тестирование API — это процесс проверки правильности работы этих интерфейсов, их производительности, безопасности и функциональности. В отличие от тестирования пользовательского интерфейса (UI), тестирование API сосредоточено на уровне бизнес-логики и данных.

Основной популярный инструмент для тестирования API - [Postman](https://www.postman.com/). 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://youtu.be/zp5Jh2FIpF0?si=GG352hDvk_A6en4V)
* [Погружение 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/)
* [Swagger: что это такое, и как с ним работать?](https://highload.today/swagger-api/)
* [Основы Cypress: тестирование API](https://www.software-testing.ru/library/testing/testing-tools/3809-cypress-basics-api-testing)
* [SOAP API](https://telegra.ph/SOAP-API-05-08)
* [SOAP UI](https://telegra.ph/SOAP-UI-05-09)
* [Что нужно знать про Postman: максимально коротко о Mock Servers, Flow и Visualize](https://habr.com/ru/company/rostelecom/blog/666766/)
* [Как выбрать инструмент для тестирования API](https://habr.com/ru/company/simbirsoft/blog/675878/)
* **Открытые и тренировочные API**:
  * [Большая подборка открытых API](https://habr.com/p/769384/)
  * [Список открытых 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)
  * [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)
  * [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)

**Proxy (снифферы трафика)**:

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

Популярные инструменты Proxy (снифферы трафика):

[Fiddler](https://www.telerik.com/fiddler) - мощный инструмент для перехвата и отладки HTTP/HTTPS трафика. Он позволяет просматривать и изменять входящие и исходящие запросы.

[Charles Proxy](https://www.charlesproxy.com/) - популярный прокси-сервер, используемый для мониторинга и анализа HTTP/HTTPS трафика, а также для тестирования веб-приложений и мобильных приложений.

[Burp Suite](https://portswigger.net/burp/communitydownload) - комплексное средство для тестирования безопасности веб-приложений, включающее прокси-сервер для перехвата и изменения трафика, а также множество других инструментов для анализа безопасности.

[Wireshark](https://www.wireshark.org/) - один из самых известных снифферов, используемый для детального анализа сетевых пакетов на разных уровнях сетевой модели.

* [Web Security Academy - Burp Suite](https://portswigger.net/web-security)
* [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)
* [Начинающему 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/)
* [Плейлист Charles Proxy](https://www.youtube.com/playlist?list=PLof3mAh50UD05mFlTvNpTszOUY9eFrSDX)
* [Погружение в Charles Proxy](https://habr.com/ru/post/663926/)
* [Wireshark — подробное руководство по началу использования](https://habr.com/ru/articles/735866/)
* [Руководство и шпаргалка по Wireshark](https://habr.com/ru/articles/436226/)
* [Первые шаги с Fiddler Classic](https://habr.com/ru/articles/533138/)
* [Fiddler = удобный сниффер + прокси сервер](https://habr.com/ru/articles/554562/)

**Тестирование безопасности**:

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

Популярные инструменты для тестирования безопасности:

[Burp Suite](https://portswigger.net/burp/communitydownload) — комплексный инструмент для тестирования безопасности веб-приложений, включающий анализаторы, сканеры уязвимостей и средства для автоматизации тестирования.

[OWASP ZAP](https://www.zaproxy.org/) (Zed Attack Proxy) — бесплатный и открытый инструмент для нахождения уязвимостей в веб-приложениях, поддерживающий автоматическое и ручное тестирование.

[Metasploit](https://www.metasploit.com/) — платформа для разработки, тестирования и эксплуатации уязвимостей, широко используемая в пентестинге.

[Wireshark](https://www.wireshark.org/) — сетевой анализатор, который позволяет перехватывать и детально исследовать сетевой трафик, выявляя подозрительные активности и потенциальные угрозы.

* [Рамазан Рамазанов — Тестирование безопасности API: кейсы, инструменты и рекомендации](https://youtu.be/XNwpzNNiWzE?si=3T2RdEe4iGQIE4Pe)
* [Тестирование безопасности. Тестирование на проникновение](https://youtu.be/C0euAbFaT4s?si=4Dme6FvnbOizABt-)
* [Тестирование безопасности. OWASP TOP 10 уязвимостей](https://youtu.be/fgtuLbT4joI?si=hnNfgOJXZRn7AhtR)
* [Иван Румак — Эффективный поиск XSS-уязвимостей](https://youtu.be/EmJnUqFgaK8?si=OThcdoAeoKAcY2_j)
* [Александра Сватикова — Статическое тестирование безопасности инструментами из open source](https://youtu.be/E87YkXhdxAA?si=YuPImtFyBoqzd_HO)
* [Анна Васильева — Поиск уязвимостей IDOR (BOLA)](https://youtu.be/FQROPd_p1ME?si=XHVJpf1BJr7A_0Pr)
* [Сканирование на уязвимости: обзор продуктов, которые есть на рынке](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/)
* [Kali Linux](https://www.kali.org)
* <https://github.com/FSecureLABS/drozer>
* [Тестирование защищенности приложений при помощи SAST (Static Application Security Testing)](https://www.youtube.com/watch?v=Jk8LiaMF2aw)
* [Обзор сканера Nikto для поиска уязвимостей в веб-серверах](https://habr.com/ru/companies/first/articles/731696/)
* [«Осторожно, печеньки!»: советы начинающим тестировщикам в сфере безопасности](https://habr.com/ru/companies/redmadrobot/articles/544198/)

**GIT**:

Git - это [система контроля версий](https://git-scm.com/book/ru/v2/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9E-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B5-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8F-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9), которая упрощает работу нескольких человек над одним проектом, помогая разрешать конфликты слияния изменений, следить за историей, откатывать эти изменения и т.п.

Ваш репозиторий может быть локальным и/или находиться в: [GitHub](https://github.com), [Bitbucket](https://bitbucket.org), [GitLab](https://gitlab.com)

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

* Learn Git – Full Course for Beginners: [Видео](https://youtu.be/zTjRZNkhiEU?si=v4GP4NVP64TllnaF)
* Система контроля версий - GIT: [Плейлист](https://youtube.com/playlist?list=PLRs8EELOYKc44Y_fKFvADdPXbrYZDQqr0\&si=Ff0EFlvxWMSKCUgS)
* GIT - Полный Курс Git и GitHub Для Начинающих \[4 ЧАСА]: [Видео](https://youtu.be/O00FTZDxD0o?si=KgFX-GX6Rm920FIs)
* Git for Professionals Tutorial: [Видео](https://youtu.be/Uszj_k0DGsg?si=U6MGdVfC7HQeKuen)
* [Git and GitHub Tutorial – Version Control for Beginners](https://www.freecodecamp.org/news/git-and-github-for-beginners/)
* [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=lZdGWJtrsNw)
* [GitFlic](https://gitflic.ru) - первый российский сервис для хранения кода и работы с ним
* [Шпаргалка по консольным командам Git](https://github.com/cyberspacedk/Git-commands)
* [Шпаргалка по Git, в которой представлены основные команды](https://proglib.io/p/git-cheatsheet)
* [Работа с Git в Visual Studio Code](https://htmlacademy.ru/blog/git/git-in-vscode)
* [15 ресурсов по Git. Что почитать/посмотреть?](https://habr.com/ru/companies/yandex_praktikum/articles/768492/)
* *Практическое задание: форкнуть себе репозиторий QA bible :)*

**SQL**:

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

Самые популярные базы данных:

1. SQLite
   * Описание: Легковесная, встроенная реляционная база данных, часто используемая в мобильных и настольных приложениях.
   * Официальный сайт: [SQLite](https://www.sqlite.org)
2. MySQL
   * Описание: Одна из самых популярных реляционных баз данных, широко используемая для веб-приложений и корпоративного ПО.
   * Официальный сайт: [MySQL](https://www.mysql.com/)
3. PostgreSQL
   * Описание: Мощная, открытая реляционная база данных с поддержкой расширенных функций, таких как масштабируемость и расширяемость.
   * Официальный сайт: [PostgreSQL](https://www.postgresql.org/)
4. MongoDB
   * Описание: Документо-ориентированная база данных NoSQL, популярная благодаря своей гибкости и масштабируемости, особенно для облачных приложений.
   * Официальный сайт: [MongoDB](https://www.mongodb.com/)
5. Oracle Database
   * Описание: Мощная реляционная база данных, широко используемая в крупных корпоративных системах благодаря высокой производительности и надежности.
   * Официальный сайт: [Oracle](https://www.oracle.com/database)
6. Microsoft SQL Server
   * Описание: Реляционная база данных от Microsoft, известная своей интеграцией с продуктами Microsoft и высокой производительностью.
   * Официальный сайт: [Microsoft SQL Server](https://www.microsoft.com/sql-server)
7. Redis
   * Описание: Высокопроизводительная база данных ключ-значение, часто используемая для кэширования и временного хранения данных.
   * Официальный сайт: [Redis](https://redis.io/)

* GUI клиенты
  * [DataGrip от JetBrains](https://www.jetbrains.com/ru-ru/datagrip/)
  * [dBeaver](https://dbeaver.com)
  * [MySQL Workbench](https://www.mysql.com/products/workbench/)
  * [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 For Web Developers - Complete Database Course](https://youtu.be/KBDSJU3cGkc?si=iK8mVf9sBmgYyvnU)
  * [SQL Tutorial - Full Database Course for Beginners](https://youtu.be/HXV3zeQKqGY?si=SXl0PNhiKRS9l9ZD)
  * [Энтони Молинаро "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)
* Практика
  * [Бесплатные курсы для изучения SQL в 2024 году](https://habr.com/p/791260/)
  * [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)
  * [6 бесплатных ресурсов для практики в SQL](https://robotdreams.cc/blog/178-6-besplatnyh-resursov-dlya-praktiki-v-sql)
* 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/)
* [Плейлист "Базы данных"](https://www.youtube.com/playlist?list=PLbuh2pN46AEvM2ZI-rJL2MVguz8Ea9mrJ)
* [Памятка/шпаргалка по SQL](https://habr.com/ru/post/564390/)
* [Тестирование баз данных](https://habr.com/p/804851/)
* [База по базам. SQL для тестировщика](https://testengineer.ru/sql-for-testers/)

**Инструменты тестирования мобильных приложений**:

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

Популярные инструменты:

1. [Appium](http://appium.io/): Открытая платформа для автоматизации тестирования мобильных приложений на iOS и Android, поддерживающая различные языки программирования.
2. [Espresso](https://developer.android.com/training/testing/espresso): Инструмент от Google для автоматизированного тестирования Android-приложений, интегрированный с Android Studio.
3. [XCUITest](https://developer.apple.com/documentation/xctest): Фреймворк для тестирования iOS-приложений, интегрированный в Xcode, предоставляемый Apple.
4. [Calabash](https://github.com/calabash/calabash-android): Открытый фреймворк для написания и выполнения автоматизированных тестов для мобильных приложений на iOS и Android, использующий язык Cucumber.
5. [TestComplete](https://smartbear.com/product/testcomplete/): Коммерческий инструмент для автоматизированного тестирования мобильных приложений, поддерживающий iOS и Android, а также предоставляющий возможности для записи и воспроизведения тестов.

* [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/)
* [Как мы сделали мобильные устройства круглосуточно доступными для распределенной QA-команды и не только](https://habr.com/ru/company/kaspersky/blog/663282/)
* [Docker Emulator for Android | VK](https://github.com/VKCOM/docker-emulator-android)

**Работа с логами**:

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

* [Логи для тестировщика / Работа с логами в тестировании](https://www.youtube.com/watch?v=pAF1a_2a_6s)
* [О чём могут рассказать логи: важный инструмент в работе тестировщика](https://habr.com/ru/companies/yandex_praktikum/articles/739058/)
* [Tools for Log Analysis](https://medium.com/tensult/tools-for-log-analysis-461eb07c2d6b)
* <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)
* [Доклад: "Мониторинг приложения в проде" / Семён Мацепура (СберМаркет)](https://www.youtube.com/watch?v=lSS9eTlrNf8)
* [Как тестировщику работать с логами](https://testgrow.ru/article12)

**Тестирование производительности**:

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

Основные популярные инструменты:

1. [Apache JMeter](https://jmeter.apache.org/): Мощный инструмент с открытым исходным кодом для тестирования производительности веб-приложений.
2. [LoadRunner](https://www.microfocus.com/en-us/products/loadrunner-professional/overview): Коммерческое решение от Micro Focus для проведения нагрузочного тестирования и анализа производительности.
3. [Gatling](https://gatling.io/): Инструмент с открытым исходным кодом, написанный на Scala, для тестирования производительности и нагрузочного тестирования.
4. [BlazeMeter](https://www.blazemeter.com/): Облачная платформа для проведения нагрузочного тестирования, интегрируемая с Apache JMeter и другими инструментами.
5. [artillery.io](https://artillery.io): Позволяет создавать гибкие сценарии нагрузки с использованием простого синтаксиса YAML и запускать их с помощью командной строки. Artillery предоставляет широкие возможности для мониторинга и анализа результатов тестирования.
6. [Яндекс.Танк](https://yandex.ru/dev/tank/): это инструмент для проведения нагрузочного тестирования веб-приложений и сервисов. Он обладает мощными возможностями по настройке сценариев нагрузки и поддерживает различные протоколы, включая HTTP, HTTPS, WebSocket и многие другие. Яндекс.Танк предоставляет удобный веб-интерфейс для настройки тестов и анализа результатов.
7. [Google Lighthouse](https://developers.google.com/web/tools/lighthouse/): это автоматизированный инструмент для оценки качества веб-приложений и анализа их производительности. Он позволяет проводить аудит веб-страниц на предмет оптимизации производительности, доступности, SEO и других аспектов. Lighthouse доступен как в браузере Chrome, так и в виде командной строки для автоматизации тестирования.

Доп. материал:

* Apache JMeter + JMeter Result Analysis: [The Ultimate Guide](https://octoperf.com/blog/2017/10/19/how-to-analyze-jmeter-results/#understanding-jmeter-metrics)
* [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)
* [Топ-15 бесплатных инструментов для нагрузочного тестирования](https://testengineer.ru/besplatnye-instrumenty-dlya-nagruzochnogo-testirovaniya/)
* [Использование Gatling. Разбираемся в тестировании HTTP](https://habr.com/ru/company/tinkoff/blog/658479/)
* [Тестирование производительности API с помощью K6](https://testengineer.ru/testirovanie-proizvoditelnosti-api-s-pomoshchyu-k6/)

**Mind maps**:

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

Популярные инструменты:

1. [MindMeister](https://www.mindmeister.com/ru): Онлайн-платформа для создания и совместного использования Mind Maps.
2. [XMind](https://xmind.app/): Программа с открытым исходным кодом для создания Mind Maps с широким набором функций.
3. [MindManager](https://www.mindmanager.com/en/): Профессиональное программное обеспечение для создания, редактирования и обмена Mind Maps.
4. [Coggle](https://coggle.it/): Простой в использовании онлайн-инструмент для создания 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**:

Test Management System (TMS) - это программное обеспечение, предназначенное для управления процессом тестирования программного обеспечения. Оно помогает организовать, планировать, отслеживать и управлять тестовыми заданиями, ресурсами и результатами.

* [Test IT](https://testit.software)
* [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/)
* [FAQ по баг-трекингу JIRA](https://www.youtube.com/watch?v=rxyc1OXTijc)
* Руководство по лучшему программному обеспечению для отслеживания проблем: [часть 1](https://habr.com/ru/company/otus/blog/660821/), [часть 2](https://habr.com/ru/company/otus/blog/666360/)
* [Баг-трекинговые системы: Jira и альтернативные варианты](https://testengineer.ru/bag-trekingovye-sistemy-jira-i-alternativnye-varianty/)
* [Рациональный выбор системы управления тестированием](https://habr.com/ru/company/domrf/blog/672780/)

**Полезные расширения для браузера**:

* Simple Translate ([Google Chrome](https://chromewebstore.google.com/detail/ibplnjkanclpjokhdolnendpplpjiace?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/simple-translate/)) — обеспечивает быстрый перевод выделенного или введенного текста на веб-страницах, поддерживая Google Translate и Deep API.
* React Developer Tools ([Google Chrome](https://chromewebstore.google.com/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi), [Firefox](https://addons.mozilla.org/ru/firefox/addon/react-devtools/)) — предоставляет возможность просматривать дерево React, включая иерархию компонентов, их свойства, состояния и многое другое.
* ColorZilla ([Google Chrome](https://chromewebstore.google.com/detail/colorzilla/bhlhnicpbhignbdhedgjhgdocnmhomnp?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/colorzilla/)) — инструмент для выбора цветов с любого веб-сайта и их применения в собственных проектах.
* Bug Magnet ([Google Chrome](https://chromewebstore.google.com/detail/bug-magnet/efhedldbjahpgjcneebmbolkalbhckfi?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/bug-magnet/)) — позволяет вводить тестовые данные с помощью контекстного меню.
* Fake Filler ([Google Chrome](https://chromewebstore.google.com/detail/fake-filler/bnjjngeaknajbdcgpfkgnonkmififhfo?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/fake-filler)) — заполняет формы случайными данными для тестирования (текстовые поля, переключатели, выпадающие списки и т.д.).
* Selenium IDE ([Google Chrome](https://chromewebstore.google.com/detail/selenium-ide/mooikfkahbdckldjjndioackbalphokd?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/selenium-ide/)) — интегрированная среда разработки для тестов Selenium, позволяющая записывать, редактировать и отлаживать тесты.
* FoxyProxy ([Google Chrome](https://chromewebstore.google.com/detail/foxyproxy/gcknhkkoolaabfmlnjonogaaifnjlfnp?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/foxyproxy-standard/)) — расширенный инструмент управления прокси-серверами с открытым исходным кодом, полностью заменяющий стандартные функции браузера.
* Violentmonkey ([Google Chrome](https://chromewebstore.google.com/detail/jinjaccalgkegednnccohejagnlnfdag), [Firefox](https://addons.mozilla.org/ru/firefox/addon/violentmonkey/)), Tampermonkey ([Google Chrome](https://chromewebstore.google.com/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ru), [Firefox](https://addons.mozilla.org/ru/firefox/addon/tampermonkey/)) + [script](https://4pda.to/pages/go/?u=https%3A%2F%2Fraw.githubusercontent.com%2Fsodapng%2Fvoice-over-translation%2Fmaster%2Fvot.user.js) — пользовательские скрипты для браузеров.
* Dimensions ([Google Chrome](https://chromewebstore.google.com/detail/dimensions/baocaagndhipibgklemoalmkljaimfdj), [Firefox](https://addons.mozilla.org/ru/firefox/addon/dimensions_extension/)) — инструмент для измерения размеров элементов на экране.
* JSON Formatter ([Google Chrome](https://chromewebstore.google.com/detail/json-formatter/bcjindcccaagfpapjjmafapmmgkkhgoa), [Firefox](https://addons.mozilla.org/ru/firefox/addon/json_formatter)) — делает формат JSON удобным для чтения.
* WhatFont ([Google Chrome](https://chromewebstore.google.com/detail/whatfont/jabopobgcpjmedljpbcaablpmlmfcogm?hl=ru), [Firefox](https://addons.mozilla.org/ru/firefox/addon/zjm-whatfont/)) — позволяет узнать шрифт, используемый на веб-странице.
* Cookie-Editor ([Google Chrome](https://chromewebstore.google.com/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg), [Firefox](https://addons.mozilla.org/ru/firefox/addon/cookie-editor/)) — эффективный инструмент для создания, редактирования и удаления файлов cookie на текущей вкладке.
* axe DevTools ([Google Chrome](https://chromewebstore.google.com/detail/lhdoppojpmngadmnindnejefpokejbdd?hl=ru), [Firefox](https://addons.mozilla.org/ru/firefox/addon/axe-devtools/)) — инструмент для проверки доступности веб-страниц.
* WAVE Evaluation Tool ([Google Chrome](https://chromewebstore.google.com/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh), [Firefox](https://addons.mozilla.org/ru/firefox/addon/wave-accessibility-tool/?utm_source=addons.mozilla.org\&utm_medium=referral\&utm_content=search)) — оценивает доступность веб-страниц.
* Jam ([Google Chrome](https://chromewebstore.google.com/detail/jam/iohjgamcilhbgmhbnllfolmkmmekfmci)) — быстрый инструмент для отчетов об ошибках, сокращающий время сообщения об ошибках в 20 раз.
* Browsec VPN ([Google Chrome](https://chromewebstore.google.com/detail/omghfjlpggmjjaagoclmmobgdodcjboh?hl=ru), [Firefox](https://addons.mozilla.org/ru/firefox/addon/browsec/)) — популярный бесплатный VPN-сервис.
* Stylebot ([Google Chrome](https://chromewebstore.google.com/detail/stylebot/oiaejidbmkiecgbjeifoejpgmdaleoha), [Firefox](https://addons.mozilla.org/ru/firefox/addon/stylebot-web/)) — удобный инструмент для редактирования CSS, позволяющий тестировать и применять пользовательские стили к веб-страницам.
* Wappalyzer ([Google Chrome](https://chromewebstore.google.com/detail/wappalyzer-technology-pro/gppongmhjkpfnbhagpmjfkannfbllamg), [Firefox](https://addons.mozilla.org/ru/firefox/addon/wappalyzer/)) — определяет технологии, используемые на веб-сайтах.
* Window Resizer ([Google Chrome](https://chromewebstore.google.com/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh), [Firefox](https://addons.mozilla.org/ru/firefox/addon/window-resizer-webextension)) — изменяет разрешение экрана для тестирования адаптивного дизайна.
* Page Ruler ([Google Chrome](https://chromewebstore.google.com/detail/page-ruler/jcbmcnpepaddcedmjdcmhbekjhbfnlff), [Firefox](https://addons.mozilla.org/ru/firefox/addon/page-ruler/)) — полезная веб-линейка для точного измерения пиксельных параметров выбранной области.
* Talend API Tester - Free Edition ([Google Chrome](https://chrome.google.com/webstore/detail/talend-api-tester-free-ed/aejoelaoggembcahagimdiliamlcdmfm)) — визуальный инструмент для взаимодействия с API-интерфейсами REST, SOAP и HTTP.
* PerfectPixel ([Google Chrome](https://chrome.google.com/webstore/detail/perfectpixel-by-welldonec/dkaagdgjmgdmbnecmcefdhjekcoceebi?hl=ru), [Firefox](https://addons.mozilla.org/ru/firefox/addon/pixel-perfect-pro/)) — помогает разрабатывать сайт с попиксельной точностью.
* GoFullPage - Full Page Screen Capture ([Google Chrome](https://chrome.google.com/webstore/detail/gofullpage-full-page-scre/fdpohaocaechififmbbbbbknoalclacl)) — инструмент для захвата всей страницы (в Firefox эта функция встроена по умолчанию).
* Broken Link Checker ([Google Chrome](https://chromewebstore.google.com/detail/broken-link-checker/bjcoimpfplliplknnmgbffboiihamekf), [Firefox](https://addons.mozilla.org/ru/firefox/addon/find-broken-links/)) — проверяет веб-страницы на наличие битых ссылок.
* Ranorex Selocity ([Google Chrome](https://chromewebstore.google.com/detail/ranorex-selocity/ocgghcnnjekfpbmafindjmijdpopafoe)) — автоматически генерирует надежные селекторы XPath, link text, RanoreXPath и CSS для использования с Selenium.
* Mokku ([Google Chrome](https://chromewebstore.google.com/detail/mokku/llflfcikklhgamfmnjkgpdadpmdplmji)) — добавляет API mocker MOKKU в инструменты разработчика Chrome для беспрепятственной интеграции и тестирования.
* Responsive Viewer ([Google Chrome](https://chrome.google.com/webstore/detail/responsive-viewer/inmopeiepgfljkpkidclfgbgbmfcennb)) — позволяет тестировать адаптивный дизайн, отображая веб-страницы на различных экранах одновременно.
* Web Developer ([Google Chrome](https://chromewebstore.google.com/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm), [Firefox](https://addons.mozilla.org/ru/firefox/addon/web-developer/)) — добавляет кнопку на панели инструментов с различными полезными инструментами для веб-разработчика.
* Web Developer Checklist ([Google Chrome](https://chromewebstore.google.com/detail/web-developer-checklist/iahamcpedabephpcgkeikbclmaljebjp), [Firefox](https://addons.mozilla.org/ru/firefox/addon/webdeveloperchecklist/)) — чеклист для веб-разработчиков, помогающий проверять соответствие веб-страниц лучшим практикам.
* d3coder ([Google Chrome](https://chrome.google.com/webstore/detail/d3coder/gncnbkghencmkfgeepfaonmegemakcol)) — плагин для кодирования и декодирования различных форматов, таких как base64, rot13 и преобразования временных меток unix.
* Ruto - XPath Finder ([Google Chrome](https://chromewebstore.google.com/detail/ruto-xpath-finder/ilcoelkkcokgeeijnopjnolmmighnppp?hl=ru&), [Firefox](https://addons.mozilla.org/ru/firefox/addon/rutoxpath/)) — удобный инструмент для поиска и проверки XPath.
* HackTools ([Google Chrome](https://chromewebstore.google.com/detail/hack-tools/cmbndhnoonmghfofefkcccljbkdpamhi?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/hacktools/)) — расширение для веб-пентестеров, содержащее различные инструменты для тестирования безопасности.
* Shodan ([Google Chrome](https://chromewebstore.google.com/detail/shodan/jjalcfnidlmpjhdfepjhjbhnhkbgleap), [Firefox](https://addons.mozilla.org/ru/firefox/addon/shodan-addon/)) — плагин Shodan предоставляет информацию о местоположении веб-сайта (страна, город), владельце IP-адреса и открытых сервисах/портах.
* uBlock Origin ([Google Chrome](https://chromewebstore.google.com/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?utm_source=ext_app_menu), [Firefox](https://addons.mozilla.org/ru/firefox/addon/ublock-origin)) — бесплатное расширение для блокировки рекламы и фильтрации контента с открытым исходным кодом.
* Multi-Account Containers ([Firefox](https://addons.mozilla.org/ru/firefox/addon/multi-account-containers/)) — позволяет создавать контейнеры для использования нескольких учетных записей в разных вкладках.
* Temp mail ([Google Chrome](https://chromewebstore.google.com/detail/temp-mail-disposable-temp/inojafojbhdpnehkhhfjalgjjobnhomj?hl=en), [Firefox](https://addons.mozilla.org/en-US/firefox/addon/temp-mail/)) — обеспечивает временные, безопасные, анонимные одноразовые адреса электронной почты.

**Программы для снятия скриншотов и записи видео**:

* Скриншоты:
  * Стандартные «Ножницы» в Windows: Сочетание клавиш Win + Shift + S активирует режим продвинутого скриншота. Можно сделать снимок всего экрана, отдельного окна или нужной области. Скриншот редактируется и сохраняется в буфер обмена.
  * Стандартная утилита для macOS: Shift + Cmd + 3 активирует снимок всего экрана, Shift + Cmd + 4 позволяет захватить нужную область, Shift + Cmd + 4 + «пробел» переводит в режим захвата окна. Запись видео с экрана доступна при нажатии Shift + Cmd + 5.
  * [ShareX](https://getsharex.com) - бесплатный инструмент с открытым исходным кодом для создания скриншотов и записи экрана.
  * [Скриншотер Mail.ru](https://screenshoter.mail.ru) - простой и удобный инструмент для создания скриншотов.
  * [ФотоСКРИН](https://photo-screen.ru/) - удобный и бесплатный скриншотер на русском языке.
  * [Lightshot](https://app.prntscr.com/ru/) - одна из наиболее популярных программ для создания скриншотов.
  * [Monosnap](https://monosnap.com) - удобное создание скриншотов в один клик.
  * [Flameshot](https://flameshot.org) - мощное, но простое в использовании ПО для создания скриншотов.
  * [Screenpic](https://screenpic.net/ru/) - программа с широким функционалом для создания и редактирования скриншотов.
  * [Joxi](http://joxi.ru) - удобный инструмент для создания и обмена скриншотами.
  * [ImageOptim](https://imageoptim.com/mac) - оптимизирует изображения для более быстрой загрузки.
  * [Greenshot](https://getgreenshot.org) - легкий инструмент для создания скриншотов на Windows.
  * [BugCatcher](https://bugcatcher.pro) - создает скриншот или видео, копирует контекст (OS, browser, hardware и т.д.), копирует errorlog, отправляет в багтрекинг систему.
* Запись экрана:
  * Стандартная утилита Windows 11 «Ножницы»: Сочетание клавиш Win+Shift+R
  * [OBS Studio](https://obsproject.com/) - бесплатная программа с открытым исходным кодом для записи видео и потокового вещания.
  * [ShareX](https://getsharex.com) - бесплатный инструмент с открытым исходным кодом для создания скриншотов и записи экрана.
  * [ScreenToGif](https://www.screentogif.com) - запись экрана, вебкамеры и рисования с встроенным редактором.
  * [ScreenRec](https://screenrec.com) - удобная программа для записи экрана.
  * [Bandicam](https://www.bandicam.com/ru/) - мощный инструмент для записи экрана, игр и видеоустройств.
  * [Movavi Screen Recorder](https://www.movavi.ru/screen-capture/) - простая запись экрана в один клик.
  * [PicPick](https://picpick.app/ru/) - многофункциональная программа для захвата экрана и редактирования изображений.
  * [Free screen recorder](https://screenpal.com/screen-recorder) - бесплатный инструмент для записи экрана.
  * [Loom](https://www.loom.com) - запись видео с экрана и камеры в несколько кликов.

**Linux**

* [Уроки Linux для начинающих - Плейлист](https://youtube.com/playlist?list=PL0lO_mIqDDFUwVWvVitxG2oXA6a-Nq-Qq\&si=Mmv-hNtIvXtoOvTW) - RU
* [Command Line с нуля (Bash, Unix) - Плейлист](https://youtube.com/playlist?list=PLRs8EELOYKc42r19Gc7CACRyI1R_5a5TC\&si=9tobby0_fYHlBf3O) - RU
* [Introduction to Linux – Full Course for Beginners](https://youtu.be/sWbUDq4S6Y8?si=lv0j9UM3e6hqpkBb) - EN
* [Linux Operating System - Crash Course for Beginners](https://youtu.be/ROjZy1WbCIA?si=i__2bsctiIA2C7xE) - EN
* [Bash Scripting Tutorial for Beginners](https://youtu.be/tK9Oc6AEnR4?si=s7rMWLNse4RM7uaf) - EN
* [The 50 Most Popular Linux & Terminal Commands - Full Course for Beginners](https://youtu.be/ZtqBQ68cfJc?si=mCtmiOESTF5Cujq3) - EN
* [Linux Essentials for Ethical Hackers - Full InfoSec Course](https://youtu.be/1hvVcEhcbLM?si=x3zPx4hKru8U0Lik) - EN
* [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/)
* [Автоматизация рутины. Скачиваем файлы через bash](http://okiseleva.blogspot.com/2021/11/bash.html)
* [Статьи по Linux на freecodecamp](https://www.freecodecamp.org/news/tag/linux/)
* [Основы Linux (обзор с практическим уклоном)](https://habr.com/p/655275/)
* [Командная строка Linux: краткий курс для начинающих](https://selectel.ru/blog/tutorials/linux-for-beginners/)
* [Книги по Linux для начинающих и профессионалов: выбираем лучшее](https://habr.com/p/765308/)

**RegExp**:

* [MDN Web Docs - RegExp](https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/RegExp)
* [Регулярные выражения (regexp) - основы](https://habr.com/ru/post/545150/)
* [Регулярные выражения - Современный учебник JavaScript](https://learn.javascript.ru/regular-expressions)
* [RegExp. Регулярные выражения это просто. - Видео](https://youtu.be/wMZ6gLNtefQ?si=epmHx514OGi1_HRZ)
* [https://regex101.com/](https://regex101.com)
* [http://myregexp.com/](http://myregexp.com)
* [https://regexr.com/](https://regexr.com)

**Разное**:

* [HTML](https://developer.mozilla.org/ru/docs/Learn/HTML)/[CSS](https://developer.mozilla.org/ru/docs/Learn/CSS)/[JavaScript](https://developer.mozilla.org/ru/docs/Learn/JavaScript)
* [Подборка шпаргалок](https://overapi.com)
* [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)
* [Генератор личностей 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://tempmail.plus/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)
* [TestRail и дополнительные инструменты для тестировщика](https://www.youtube.com/watch?v=XQ7MoUT7rEk)
* [Как тестируют документацию в Test IT](https://habr.com/ru/company/testit-tms/blog/564666/)
* [Как правильно оформить баг-репорт](https://testit.software/blog/post/kak-pravilno-oformit-bag-report)
* [Webhook.site](https://webhook.site/) - generates free, unique URLs and e-mail addresses and lets you see everything that’s sent there instantly.
* [readme.so](https://readme.so/ru) - Самый легкий способ составить README


# Общее


# 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)
* [от Тестирования к Обеспечению качества](https://habr.com/ru/post/671874/)

**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/)
* [10 мифов о тестировании ПО](https://blog.serioustester.io/yT6d2L_GupR)
* [ТЕСТИРОВАНИЕ НА ПРИМЕРЕ. ЧТО ДЕЛАЕТ ТЕСТИРОВЩИК?](https://www.youtube.com/watch?v=Ut8lQ-w5fOc)
* [QA: 9 мифических заявлений](https://habr.com/ru/post/677464/)
* [Тестировщики всего-навсего проверяют критерии приемки](https://telegra.ph/Testirovshchiki-vsego-navsego-proveryayut-kriterii-priemki-07-16)


# Почему требуется тестирование ПО?

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

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

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

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

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

Источник:

* [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996)

Доп. материал:

* [ISTQB Syllabus v4.0, раздел 1.2 "Почему тестирование необходимо?"](https://www.rstqb.org/ru/istqb-downloads.html)
* [Мир без 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/)
* [Баги войны](https://testengineer.ru/bagi-voini/)
* [Эй, 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/)
* [Нужны ли в команде выделенные тестировщики?](https://serioustester.io/tpost/t2gkz3jnm1-nuzhni-li-v-komande-videlennie-testirovs)
* [Багическая работа: когда ошибки не страшные, а странные](https://habr.com/ru/company/jugru/blog/668250/)
* [10 странных причин не нанимать тестировщиков](https://www.software-testing.ru/library/around-testing/job/3836-ten-misguided-reasons-not-to-hire-testers)
* [Почему ошибаются программисты?](https://vc.ru/life/451990-pochemu-oshibayutsya-programmisty)


# Качество ПО (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)
* [Как задавать требования к качеству ПО в цифрах?](https://habr.com/ru/post/661331/)


# Принципы тестирования

1. Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
2. Исчерпывающее тестирование недостижимо (Exhaustive testing is not possible)
3. Раннее тестирование (Early testing)
4. Скопление/кластеризация дефектов (Defect clustering)
5. Парадокс пестицида/тесты устаревают (Pesticide paradox/Tests wear out)
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)
* [ISTQB Syllabus v4.0, раздел 1.3 "Принципы тестирования"](https://www.rstqb.org/ru/istqb-downloads.html)
* [Парадокс пестицида и поддержка эффективности тест-кейсов](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/)


# Верификация и валидация (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/)


# Дефекты и ошибки

Прежде всего, стоит разобраться с терминологией. В определениях 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)

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

![https://www.guru99.com/images/1-2015/012715\_0802\_BugLifeCycl1.png](https://www.guru99.com/images/1-2015/012715_0802_BugLifeCycl1.png)

**Статусы дефекта**:

* **Новый** (New): когда новый дефект регистрируется и публикуется впервые;
* **Назначен** (Assigned): после публикации бага тестировщиком руководитель тестировщика утверждает ошибку и передает ее команде разработчиков;
* **Открыт** (Open): разработчик начинает анализ и работает над исправлением бага;
* **Исправлен** (Fixed): разработчик внес необходимое изменение в код и проверил его;
* **Ожидает повторного тестирования** (Pending retest): как только дефект будет исправлен, разработчик предоставляет тестировщику конкретный код для повторного тестирования кода. Поскольку тестирование программного обеспечения остается незавершенным со стороны тестировщиков, ему присваивается статус «ожидает повторного тестирования»;
* **Повторное тестирование** (Retest): на этом этапе тестировщик выполняет повторное тестирование кода, чтобы проверить, исправлен ли дефект разработчиком;
* **Проверен** (Verified): тестировщик повторно тестирует баг после его исправления разработчиком. Если баг исправлен, то присваивается статус «проверено»;
* **Переоткрыт** (Reopen): если баг сохраняется даже после того, как разработчик исправил баг, тестировщик меняет статус на «повторно открыт». И снова баг проходит жизненный цикл.
* **Закрыт** (Closed): если баг больше не существует, тестировщик присваивает статус «Закрыто».
* **Дубль** (Duplicate): если дефект повторяется дважды или дефект соответствует той же концепции ошибки, статус изменяется на «дублировать».
* **Отклонен** (Rejected): если разработчик считает, что дефект не является таковым, он меняет статус на «отклонен»;
* **Отложен** (Deferred): если текущий баг не является приоритетным и ожидается, что он будет исправлен ​​в следующем выпуске, таким багам присваивается статус «Отложено»;
* **Не является багом** (Not a bug): если это не влияет на функциональность приложения, то багу присваивается статус «Не является багом».

![https://www.guru99.com/images/defectcyclechart.png](https://www.guru99.com/images/defectcyclechart.png)

**Утечка дефектов и релиз бага (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)
* [Где тестировщику брать ответы в случае сомнений?](https://telegra.ph/Gde-testirovshchiku-brat-otvety-v-sluchae-somnenij-07-20)


# Серьезность и приоритет Дефекта (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)


# Альфа- и бета- тестирование (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, после чего они немедленно исправляются                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | Дефекты собираются из обратной связи от пользователей и записываются как улучшения для будущей версии                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| <p><strong>Цели:</strong></p><ul><li>Оценить качество продукта;</li><li>Убедиться в готовности к бета-тестированию;</li><li>Фокус на поиске ошибок;</li><li>Работает ли ПО?</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                          | <p><strong>Цели:</strong></p><ul><li>Оценить удовлетворенность клиентов;</li><li>Убедиться в готовности к релизу (в прод);</li><li>Фокус на сборе отзывов и предложений;</li><li>Нравится ли заказчикам (customers) продукт?</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| <p><strong>Когда?</strong></p><ul><li>Обычно после System testing phase или когда продукт готов на 70-90%;</li><li>Фичи почти заморожены, и нет возможности для серьезных улучшений;</li><li>Сборка должна быть стабильной для технического пользователя;</li></ul>                                                                                                                                                                                                                                                                                                                                            | <p><strong>Когда?</strong></p><ul><li>Обычно после альфа-тестирования и продукт готов на 90-95%;</li><li>Фичи заблокированы и улучшения уже не принимаются;</li><li>Сборка должна быть стабильной для реальных пользователей;</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| <p><strong>Продолжительность теста:</strong></p><ul><li>Проведение множества циклов испытаний;</li><li>Каждый цикл тестирования длится 1-2 недели;</li><li>Продолжительность также зависит от количества обнаруженных проблем и количества добавленных новых функций;</li></ul>                                                                                                                                                                                                                                                                                                                                | <p><strong>Продолжительность теста:</strong></p><ul><li>Проведение всего 1 или 2 цикла испытаний;</li><li>Каждый цикл тестирования длится 4-6 недель;</li><li>Циклы тестирования могут увеличиваться в зависимости от отзывов / предложений реальных пользователей;</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                      |
| <p><strong>Stakeholders:</strong></p><p>Engineers (in-house developers), Quality Assurance Team, and Product Management Team</p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                               | <p><strong>Stakeholders:</strong></p><p>Product Management, Quality Management, and User Experience teams</p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
| <p><strong>Участники:</strong></p><ul><li>Технические эксперты, специализированные тестировщики с хорошими знаниями предметной области (новые или уже участвовавшие в фазе тестирования системы), предметная экспертиза (Subject Matter Expertise);</li><li>В некоторых случаях клиенты и / или конечные пользователи могут участвовать в альфа-тестировании;</li></ul>                                                                                                                                                                                                                                        | <p><strong>Участники:</strong></p><ul><li>Конечные пользователи, для которых предназначен продукт;</li><li>Customers также обычно участвуют в бета-тестировании;</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| <p><strong>Ожидания:</strong></p><ul><li>Приемлемое количество ошибок, которые были пропущены при предыдущих тестовых мероприятиях;</li><li>Неполные функции и документация;</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                         | <p><strong>Ожидания:</strong></p><ul><li>Почти готовый продукт с гораздо меньшим количеством ошибок и сбоев;</li><li>Почти готовые функции и документация;</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| <p><strong>Критерии начала (Entry Criteria):</strong></p><ul><li>Альфа-тесты, разработанные и проверенные с учетом требований бизнеса (Business requirements);</li><li>Требования покрыты тестами в Traceability matrix;</li><li>Команда тестирования со знанием предметной области (domain) и продукта;</li><li>Настройка среды и сборка для выполнения (Environment setup and build for execution);</li><li>Набор инструментов должен быть готов для регистрации ошибок и управления тестированием;</li><li>Системное тестирование, в идеале, должно быть закончено;</li></ul>                               | <p><strong>Критерии начала (Entry Criteria):</strong></p><ul><li>Бета-тесты, например, что тестировать, и процедуры, задокументированные для использования на проде;</li><li>Нет необходимости в матрице прослеживаемости;</li><li>Конечные пользователи и заказчик объединяются;</li><li>Настройка среды конечного пользователя;</li><li>Набор инструментов должен быть готов для сбора отзывов / предложений;</li><li>Alpha Testing должно быть закончено;</li></ul>                                                                                                                                                                                                                                             |
| <p><strong>Критерии окончания (Exit Criteria):</strong></p><ul><li>Все альфа-тесты должны быть выполнены, и все циклы должны быть завершены;</li><li>Critical / Major дефекты должны быть исправлены и повторно протестированы;</li><li>Должен быть завершен эффективный анализ отзывов, предоставленных участниками;</li><li>Alpha Test Summary report;</li><li>Alpha Testing должно быть закончено;</li></ul>                                                                                                                                                                                                | <p><strong>Критерии окончания (Exit Criteria):</strong></p><ul><li>Все циклы должны быть завершены;</li><li>Critical / Major дефекты должны быть исправлены и повторно протестированы;</li><li>Должен быть завершен эффективный анализ отзывов, предоставленных участниками;</li><li>Beta Test Summary report;</li><li>Beta Testing должно быть закончено;</li></ul>                                                                                                                                                                                                                                                                                                                                               |
| <p><strong>Плюсы (Pros):</strong></p><ul><li>Помогает обнаружить ошибки, которые не были обнаружены во время предыдущих тестовых мероприятий;</li><li>Лучшее представление об использовании и надежности продукта;</li><li>Анализ возможных рисков во время и после запуска продукта;</li><li>Помогает подготовиться к будущей поддержке клиентов;</li><li>Помогает укрепить доверие клиентов к продукту;</li><li>Снижение затрат на обслуживание за счет выявления и исправления ошибок перед запуском бета-версии / production версии;</li><li>Простое управление тестированием (Test Management);</li></ul> | <p><strong>Плюсы (Pros):</strong></p><ul><li>Тестирование продукта не поддается контролю, и пользователь может протестировать любую доступную функцию любым способом - в этом случае угловые области (corner areas) хорошо протестированы;</li><li>Помогает обнаружить ошибки, которые не были обнаружены во время предыдущих тестовых мероприятий (включая альфа-версию);</li><li>Лучшее представление об использовании продукта, надежности и безопасности;</li><li>Анализ точки зрения и мнение реального пользователя о продукте;</li><li>Отзывы / предложения реальных пользователей помогают в дальнейшем импровизировать продукт;</li><li>Помогает повысить удовлетворенность клиентов продуктом;</li></ul> |
| <p><strong>Минусы (Cons):</strong></p><ul><li>Ожидается, что не вся функциональность продукта будет проверена;</li><li>Ограничено только бизнес-требованиями;</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                        | <p><strong>Минусы (Cons):</strong></p><ul><li>Определенный объем (Scope) может соблюдаться или не соблюдаться участниками;</li><li>Документация больше и требует больше времени - требуется для использования инструмента регистрации ошибок (при необходимости), использования инструмента для сбора отзывов / предложений, процедуры тестирования (установка / удаление, руководства пользователя);</li><li>Не все участники гарантируют, что проводят качественное тестирование;</li><li>Не все отзывы эффективны - на рассмотрение отзывов уходит много времени;</li><li>Управление тестированием слишком сложно;</li></ul>                                                                                    |

Помимо альфа- и бета-тестирования, существуют еще гамма-тестирования и пилотное.

[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/)

Доп. материал:

* [Альфа и бета тестирование / Урок 13 / Тестировщик с нуля](https://www.youtube.com/watch?v=6g0j4N-lkpQ)


# Процесс тестирования (test process) (draft)

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

*Процесс тестирования (test process): Фундаментальный процесс тестирования охватывает планирование тестирования, анализ и дизайн тестов, внедрение и выполнение тестов, оценку достижения критериев выхода и отчетность, а также работы по завершению тестирования. (ISTQB)*

*Управление рисками (risk management): Систематическое использование процедур и практик с целью идентификации, анализа, определения приоритетов и контроля рисков. (ISTQB)*

*Управление тестированием (test management): Планирование, оценка, мониторинг и контроль тестовых активностей, обычно выполняемые руководителем тестирования. (ISTQB)*

*Менеджмент тестирования (test management): Планирование, составление графика, оценка, мониторинг, отчетность, управление и выполнение действий по тестированию (ГОСТ 56920)*

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

Вы становитесь тест-менеджером самого важного проекта в вашей компании. Задача проекта - протестировать банковскую сеть уважаемого "Guru99 Bank".

Кажется, что все отлично. Менеджер вам доверяет и на вас рассчитывает. У вас есть хороший шанс доказать, что вы справитесь со своей задачей. Но правда в том, что:

Управление тестированием - это не просто один вид деятельности. Оно состоит из целого ряда мероприятий.

**Фазы управления тестированием**

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

![https://cdn.csstricks.net/8758241/test\_management\_process\_a\_complete\_guide\_for\_testing\_project\_3.png.webp](https://cdn.csstricks.net/8758241/test_management_process_a_complete_guide_for_testing_project_3.png.webp)

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

Процесс управления тестированием состоит из двух основных частей:

* **Планирование**:
  * Анализ рисков;
  * Оценка тестирования;
  * Планирование тестирования;
  * Организация тестирования.
* **Выполнение**:
  * Мониторинг и контроль тестирования;
  * Решение проблем;
  * Отчет о тестировании и оценка.

**Анализ рисков и их решение**

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

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

Более подробно об анализе рисков и их решении вы узнаете здесь.

**Оценка теста**

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

Преимущества правильной оценки:

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

**Планирование тестирования**

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

* Стратегия тестирования;
* Цель тестирования;
* Критерии выхода/приостановки;
* Планирование ресурсов;
* Результаты тестирования.

**Что такое организация тестов при тестировании программного обеспечения?**

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

Теперь у вас есть План, но как вы будете придерживаться и выполнять его? Чтобы ответить на этот вопрос, вам нужно пройти этап организации тестирования. По существу, вам нужно организовать эффективную команду тестирования. Необходимо собрать квалифицированную команду, для эффективного управления постоянно растущим процессом тестирования. Вам нужно больше узнать об организации тестирования? Почему самоорганизованные команды так важны? Кликните [здесь](https://www.guru99.com/how-to-organize-a-test-team.html) для получения подробной информации.

**Мониторинг и контроль тестирования**

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

**Мониторинг**

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

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

* Определение цели проекта или стандарта производительности проекта;
* Наблюдение за ходом выполнения проекта и сопоставление фактической и запланированной производительности;
* Записывает и сообщает про любую обнаруженную проблему, которая происходит с проектом.

**Контроллинг**

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

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

**Решение проблем**

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

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

Риск, которого следует избегать при тестировании:

* Нарушение дедлайна;
* Превышение бюджета проекта;
* Потеря доверия заказчика.

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

**Отчет о тестировании и оценка**

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

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

Источники:

* [Процесс управления тестированием: Полное руководство по тестированию проекта](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/)
* [Как правильно (не) использовать тестировщиков](https://habr.com/ru/company/jugru/blog/661623/)
* [Почему команда работает плохо? Очень много о регламентах и процессах](https://habr.com/ru/post/673808/)
* [Как не переборщить с контролем качества?](https://telegra.ph/Kak-ne-pereborshchit-s-kontrolem-kachestva-06-16)


# Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)

*Оценка затрат на тестирование (test estimation): Рассчитанная аппроксимация результатов, связанных с различными аспектами тестирования (например, затраченные усилия, дата завершения, связанные затраты, число тестовых сценариев, и т.д.), результаты которой могут использоваться даже когда входные данные неполные, неопределенные или неточные. (ISTQB)*

Test Estimation - это управленческая деятельность, которая приблизительно показывает, сколько времени и денег потребуется для выполнения задачи. Оценка усилий для теста (Estimating effort) является одной из основных и важных задач в управлении тестированием (Test Management).

Мы поговорим о планировании в прогнозирующих методологиях, потому что в них есть время попланировать до того, как проект начался. В гибких же методологиях все происходит «здесь и сейчас»: не только регулярный planning, но и initial planning, как правило, им занимается менеджмент. Это отдельная тема.

Если мы говорим о прогнозирующих методологиях, то здесь могут быть целые этапы, которые вы можете наблюдать на слайде. Вот, к примеру, первый этап - 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);
* [Методики, основанные на опыте (Ad-hoc method/Experience-based estimation)](https://existek.com/blog/how-calculate-man-hours-software-project-explanation-example/).

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

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

Например, протестировать авторизацию. Буква «о» не проходит - можно сходу сказать 5 мин для себя. Это минимальная единица. Такое может определить даже человек, который работает всего пару месяцев. Плюс в таком методе - вам сложнее что-то забыть.

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

![https://www.software-testing.ru/images/stories/library/kovaleva/image005.jpg](https://www.software-testing.ru/images/stories/library/kovaleva/image005.jpg)

Обратите внимание на диаграмму, здесь приведена статистика для сайтов от полугода - года. Программирование занимает от 20% до 40% разработки, это не тоже самое что 20-40% от проекта, это в среднем 15% от проекта. Тестирование никогда не занимает 15% от продукта. Если у вас не закладывают столько время для тестирования, то закладывайте хоть сколько-нибудь. Желательно выяснить статистически какой процент от проекта занимает тестирование и это применимо, если у вас стабильные версии релизов, постоянный объем продуктов один и тот же.

Решение проблемы:

* Обучаем новичков:
  * Хронометраж;
  * Анализ.
* Создаем универсальный Estimation Check List для портфеля проектов;
* НЕ ругаем за ошибки в оценках.

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

Объясните своим сотрудникам, что любая неправильная оценка лучше чем ее отсутствие. Иначе вы как тест-лид не знаете ничего, не можете соотносить ресурсы и так далее. Хвалите, если они даже ошиблись. Скажите: «Ты ошибся в 2 раза. а я ошибся в 3!». Но ошибки не пропускайте, сядьте и сравните, сколько запланировано было, сколько времени потребовалось в реальности, где был big fail, и на что потребовалось больше всего времени. Самое важное - этот анализ, когда человек сам осознает, что он не учел. Тут как раз и нужна декомпозиция работ, чтобы ничего не забыть.

Тут нам может помочь - «незабудка для тестировщика».

* Ознакомление/исследование;
* Ревизия спецификации;
* Написание тестовой документации (чек-лист, тест кейсы);
* Подготовка данных;
* Выполнение тестов + рекомендации от программистов;
* Буфер/Риски.

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

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

Вы не пойдете ко всем тестировщикам, вы пойдете к первому опытному и спросите: «Давайте оценим - сколько это займет». Такой Estimation чек-лист (чек-лист по оценке), чтобы ничего не забыть. Для каждого проекта он свой. Накидайте список всех видов и типов тестирования, которыми вы пользуетесь, потому учтите, на что вы тратите время - время на анализ требований, общение с клиентами, программистами, на документирование, создание тест-кейсов, тест-планов. А потом проставляйте в чек листе, что вам нужно и не нужно.

Следующая проблема - мы не хотим оценивать. Что делать с этими людьми, а вам очень нужно?

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

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

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

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

![https://hsto.org/r/w1560/files/84a/bf1/d05/84abf1d0503d4d6997f2146022919e44.jpg](https://hsto.org/r/w1560/files/84a/bf1/d05/84abf1d0503d4d6997f2146022919e44.jpg)

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

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

Тут нам поможет сетевой график работ и Диаграмма Ганта.

![https://hsto.org/r/w1560/files/25d/fe6/be6/25dfe6be61a946549eaf6a52c9441e93.jpg](https://hsto.org/r/w1560/files/25d/fe6/be6/25dfe6be61a946549eaf6a52c9441e93.jpg)

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

Есть теория графов - это метод прохождения пути с наиболее тяжелыми весами. В данном случае «весы» - это оценки. Путь состоит из работ.

Если аксимировать это на как управление проектами, то это будет набор задач от начала проекта до конца проекта, которые не имеет запаса по времени. Красненькое - это критический путь. Если вы нарушите сроки выполнения этих работ хоть на час, то релиз задержится на час, если на 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)
* Стив Макконнелл - “Сколько стоит программный проект”
* [5 способов оценки времени на тестирование](https://telegra.ph/5-sposobov-ocenki-vremeni-na-testirovanie-05-30)
* [Александр Александров - Оценка трудозатрат на тестирование в проектах сопровождения](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/)


# Экономика тестирования/стоимость качества (Cost of quality)

*Стоимость качества (cost of quality): Общая стоимость затрат на задачи обеспечения и проблемы качества, часто разделяемая на стоимость предотвращения, стоимость оценки, стоимость внутренних отказов и стоимость внешних отказов. (ISTQB)*

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

Качество достигается за счет цены, и эта стоимость называется COQ или Cost of Quality.

Чтобы понять, как обстоят дела с тестированием на проекте, нужно проанализировать его эффективность с точки зрения качества создаваемого продукта и процессов. Тут можно рассчитывать плотность дефектов, разрывы, утечки, эффективность тест-кейсов, RC, FDP, DDP, PTC, MTTD, TDE и десятки других метрик тестирования. Но, чтобы определить рентабельность такого тестирования, необходимо считать деньги. Деньги и их возрастающий поток - основная цель заказчика в большинстве случаев разработки ПО.

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

**Цена и ценность**

Любое качество имеет свою цену. Формально стоимость качества представляют так:

![https://s.dou.ua/storage-files/1\_715laWF.png](https://s.dou.ua/storage-files/1_715laWF.png)

* 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 никто не отменял.

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

![https://s.dou.ua/storage-files/2\_9xYXzbF.png](https://s.dou.ua/storage-files/2_9xYXzbF.png)

**Как происходит оценка проекта**

Работа считается в часах, которые рассчитываются по критериям, исходя из контекста и вводных проекта:

* количество браузеров/устройств для проверки;
* сложность фич/верстки;
* документация;
* сроки;
* количество человек, которые будут участвовать в проекте и т.д.

Назовем такой подход, в основе которого лежит анализ ценности и экономической целесообразности тестирования, value based, или value driven testing, и рассмотрим его на примере.

QA team состоит из трех Manual QA. Это не Fixed Price проект, и ценообразование тут а-ля Time\&Materials. У нас 826 мануальных тестов, нехватка времени и целый вагон проблем с качеством. И стоит задача улучшить и оптимизировать тестовый процесс.

Начнем с масштабной ревизии костов. Не прибегая ни к ПСБУ, ни к МСФО, расходы можно поделить на: капитальные, или CAPEX (покупка серверов, лицензий для софта, виртуалки и так далее), операционные (расходы на прогон нагрузочных и автотестов, работу серверов, репортинг и настройку окружения), прямые (зарплата, расходы на обучение) и косвенные (дебаггинг, повторное тестирование, обновление и исправление тест-кейсов). Для себя также фиксируем постоянные и переменные расходы. Вовсе не обязательно следовать боэмовской COCOMO, всё намного прозаичнее.

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

***W = I\*T, где***&#x20;

*W - трудозатраты, I - постоянная интенсивность труда или наш перформанс, а T - время работы QA.*&#x20;

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

![https://s.dou.ua/storage-files/3\_Av7XUYJ.png](https://s.dou.ua/storage-files/3_Av7XUYJ.png)

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

![https://s.dou.ua/storage-files/4\_F8TVuP2.png](https://s.dou.ua/storage-files/4_F8TVuP2.png)

**Экономия от масштаба**

Left shit testing - основа теории тестирования. На мой взгляд, это чем-то похоже на концепцию стоимости денег во времени. Один доллар сегодня дороже, чем будет стоить завтра, так как его можно инвестировать уже сегодня. А найденный баг сегодня также ценнее, чем будет завтра, поскольку его можно раньше исправить.

Преимущество достигается за счет скорости и снижения простоев - чем быстрее мы получаем деньги и находим дефекты, тем лучше. Увеличение количества проверок при одновременном снижении себестоимости одной проверки неминуемо приводит к экономии на масштабе. Да здравствует её величество автоматизация! Рассмотрим этот процесс через призму экономики:

***c = (TFC/Q) + AVC, где***

*с - себестоимость выполнения одного теста, TFC - общая величина постоянных издержек, Q - количество запускаемых тестов, AVC - средние переменные издержки.*

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

![https://s.dou.ua/storage-files/Untitled\_design\_BWbzhU0.png](https://s.dou.ua/storage-files/Untitled_design_BWbzhU0.png)

Добавление 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, поскольку он требует меньших вложений и лучше окупается.

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

![https://s.dou.ua/storage-files/11\_MHRm7Cu.png](https://s.dou.ua/storage-files/11_MHRm7Cu.png)

*Тут 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/)


# Подход к тестированию (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/)


# Импакт анализ (анализ влияния, 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)


# Анализ первопричин (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 причины суммарно.

![https://www.performance-lab.ru/wp-content/uploads/2016/12/Image-19.jpg](https://www.performance-lab.ru/wp-content/uploads/2016/12/Image-19.jpg)

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

Представить результаты анализа первопричин можно с помощью fishbone diagram (или, если придерживаться наименования по имени создателя, диаграммы Исикавы/Ишикавы):

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

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

![https://www.performance-lab.ru/wp-content/uploads/2016/12/Image-20-e1480600742974.jpg](https://www.performance-lab.ru/wp-content/uploads/2016/12/Image-20-e1480600742974.jpg)

3. Ну и заключительный этап - это выработка решений. Проведя анализ 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)
* Карл Вигерс, Джой Битти "Разработка требований к программному обеспечению, раздел "Анализ основных причин"


# Тестирование со сдвигом влево (Shift left testing)

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

![https://miro.medium.com/max/1400/0\*OP-D\_7CcKCfYDGa0](https://miro.medium.com/max/1400/0*OP-D_7CcKCfYDGa0)

Доп. материал:

* [Меньше «сложного» тестирования, больше - «умного» тестирования](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)


# Модель зрелости возможностей (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/)


# Тестовая среда и тестовый стенд (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)


# Бизнес-логика (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)


# Политика отсутствия багов (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/)


# Независимое тестирование (Independent testing)

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

Тестирование по уровням независимости:

* Когда программист проверяет свой код: Вы бы никогда не попросили шеф-повара быть его собственным критиком. И даже если вы это сделаете, вам будет трудно поверить всему, что он говорит. Смысл - создатель никогда не может быть хорошим критиком своей собственной работы. Программист знает свой код от и до. Их цель - создать продукт и отправить его в кратчайшие сроки. Вместо того, чтобы искать ошибки со всех возможных точек зрения, они будут искушены найти способы обойти найденные ошибки. Писатель Гленфорд Майерс в своей книге «Искусство тестирования программного обеспечения» перечислил разницу в мышлении разработчика и тестировщика. Он сказал, что разработчик думает как строитель, сосредоточенный на строительстве, в то время как тестировщик ищет недостатки, которые приведут к разрушению здания, если не будут решены.
* Тестирование проводится другим программистом в организации: Компромисс - это найти кого-то в организации. Это может быть какой-то другой программист, который участвует в некоторых других проектах. Это дает определенный уровень независимости. Но проблема возникает из-за того же reporting manager. Менеджер может попросить программиста пропустить некоторые тесты, когда есть ограничения по времени. Это приведет к неполному тестированию продукта. Кроме того, если попросить других разработчиков провести тестирование, это приведет к развертыванию различных ресурсов в одном проекте. Это будет вредно для всей работы организации.
* Внутренняя команда тестирования: Наличие другой внутренней команды - это хорошее решение. Но поскольку они будут в организации, на них будут влиять ограничительные сроки. Кроме того, это будет дорого поддерживать внутреннюю команду. Это приведет к большим бюджетным и ресурсным ограничениям для команды. Команда может иметь доступ к ограниченным инструментам и программному обеспечению, таким образом, не отвечая требованиям всех проектов. Среда тестирования также будет варьироваться в зависимости от количества пользователей и числа выполненных интеграций. Затем тестирование будет проводиться в спешном порядке, что приведет к упущению некоторых ошибок, которые могут появиться после выпуска продукта. Решение, которое позаботится обо всех этих недостатках, - «Независимое тестирование».
* Независимые тестирующие организации изучат все аспекты вашей продукции. Они работают с мышлением поиска недостатков и ошибок. Они не будут использовать ярлыки в процессе тестирования. И поскольку они не были частью процесса разработки, они будут проводить тесты на нейтральной основе, чтобы прежние интересы не мешали процессу тестирования. Мысль о поиске максимальных «точек останова» пойдет на пользу вашему продукту. Почти все сторонние тестирующие организации предоставят вам подробные отчеты об ошибках и предложат корректирующие меры.

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

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

Источники:

* [Independent Testing Guide - How It Delivers Quality Driven Product](https://www.softwaretestingmaterial.com/independent-testing/)
* [ISTQB Syllabus v4.0, раздел 1.5.3 "Независимость тестирования"](https://www.rstqb.org/ru/istqb-downloads.html)


# Роли/должности в команде

![](https://hsto.org/webt/7p/ff/e-/7pffe-yx0pphzcx7qw1ydpomjyw.png)

*Полное изображение со всеми ролями по* [*ссылке*](https://habr.com/ru/company/englishdom/blog/505438/)*.*

Роли в тестировании ПО:

* 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) “Приложение Е (справочное). Роли и обязанности в тестировании”
* [YAMP 30.04.2022 - Поговорим про роль тимлида в команде с Михаилом Трошевым (Яндекс) и Александром Блиновым (hh.ru)](https://www.youtube.com/watch?v=n3OfjZxFo04\&t=6974s)
* [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)
* [Кто такие стейкхолдеры? Определения, типы и примеры](https://testengineer.ru/kto-takie-stejkkholdery/)


# Эвристики и мнемоники

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

**Мнемоника** - это тип эвристики, набор правил и приемов, которые помогают эффективно запоминать необходимые сведения (информацию), обычно это слово-аббревиатура или фраза. Например, все помнят детскую мнемонику “каждый охотник желает знать где сидит фазан”, в которой по первым буквам каждого слова можно вспомнить порядок цветов радуги.

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

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

* **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)


# Виды-методы-уровни тестирования

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


# Методы тестирования (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)


# Тестирование методом черного ящика (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)


# Тестирование методом белого ящика (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. Методы тестирования белого ящика


# Тестирование методом серого ящика (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/)


# Статическое и динамическое тестирование (Static Testing, Dynamic Testing)

*Тестирование, как статическое так и динамическое, должно быть направлено на получение обоих типов подтверждения (верификация и валидация), хотя и должно допускать, что подтверждение не будет получено немедленно из-за обнаружения дефектов. (ГОСТ 56920)*

**Статическое тестирование** (Static Testing, Non-execution technique или verification) подразумевает проверку вручную или с помощью инструментов программного кода без его запуска, а также проверку документации.

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

* Обнаружение ошибок / недостатков на ранних этапах: при создании ПО нельзя полагаться исключительно на динамическое тестирование, поскольку оно выявляет ошибки или недостатки программного продукта на более позднем этапе, что может стоить разработчикам много времени и усилий для отладки;
* Увеличение размера ПО: по мере увеличения размера программного продукта становится трудно справиться с ним, поскольку эффективность покрытия кода снижается;
* Динамическое тестирование занимает много времени: несмотря на то, что динамическое тестирование выявляет ошибку и предоставляет некоторые подробности относительно ошибки, исправление ошибки по-прежнему требует времени и усилий, поскольку оно включает в себя обнаружение сбоя от тестового примера до основной причины, что в целом усложняет процесс;
* Динамическое тестирование дорогое: как упоминалось ранее, для динамического тестирования требуются тестовые примеры, и выполнение этого само по себе является дорогостоящим, потому что тестовые примеры должны быть сначала созданы, затем выполнены и проверены, а также должны поддерживаться, что требует большой работы со стороны тестировщиков;

**Динамическое тестирование** (Dynamic Testing, Execution technique или validation) подразумевает запуск кода для проведения функциональных и нефункциональных проверок ПО. Основная цель этого тестирования - подтвердить, что программный продукт работает в соответствии с требованиями бизнеса. Преимуществами динамического тестирования являются выявление сложных дефектов, которые не могут быть обнаружены статическим тестированием, обнаружение угроз безопасности, проблем с производительностью и т.п.

Доп. материал:

* [Что такое статическое и динамическое тестирование. Верификация и валидация #5](https://www.youtube.com/watch?v=fQ_9e2ldA2k)


# Пирамида / уровни тестирования (Test Pyramid / Testing Levels)

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

![](https://lh6.googleusercontent.com/yDN1s-lXbEFI5tsd429c2fT5DkHxfDNFpTotktfGZe2tdXVAdo218WSOksJIhBx5VDJffYvMOcadII_r7ln-kvX4iKFuuQ75io5IEimepSLJq_qkkZ_JH5x5UfdSXdF2PqbBPqpV)

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

* 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/)
* [Разные подходы к тестированию: в чем их суть и какой выбирать для своих проектов](https://habr.com/ru/company/sbermarket/blog/665260/)


# Модульное/юнит/компонентное тестирование (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/)
* [Принципы юнит-тестирования. Часть первая](https://habr.com/ru/company/sportmaster_lab/blog/676840/)


# Интеграционное тестирование (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/)


# Системное тестирование (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 Подпроцесс тестирования системы”
* [What is End-to-End (E2E) Testing?](https://www.softwaretestingmaterial.com/end-to-end-testing/)
* [Лекция 7: Разновидности тестирования: системное и регрессионное тестирование](https://intuit.ru/studies/courses/48/48/lecture/1436)


# Приемочное тестирование (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)


# Основные виды тестирования ПО

*Тип тестирования (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)

![http://1.bp.blogspot.com/-bs1YvlaxYm8/VESbKf7PTPI/AAAAAAAAIYM/6zwnNU1He4A/w1200-h630-p-k-no-nu/bd6dcbbb7d7c44a485b65ae29b4c0ae4%2B(1).jpeg](http://1.bp.blogspot.com/-bs1YvlaxYm8/VESbKf7PTPI/AAAAAAAAIYM/6zwnNU1He4A/w1200-h630-p-k-no-nu/bd6dcbbb7d7c44a485b65ae29b4c0ae4%2B\(1\).jpeg)

![https://www.evkova.org/evkovaupload/job/144476/2.png](https://www.evkova.org/evkovaupload/job/144476/2.png)

![https://static.tildacdn.com/tild3137-6364-4834-b738-353565626438/photo.png](https://static.tildacdn.com/tild3137-6364-4834-b738-353565626438/photo.png)

Еще классификаций на десерт: 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)


# Функциональное тестирование (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/)


# Нефункциональное тестирование (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/)


# Тестирование производительности (Performance testing)

Тестирование производительности - это нефункциональный вид тестирования программного обеспечения, используемый для проверки скорости, времени отклика, стабильности, надежности, масштабируемости и использования ресурсов программного приложения при определенной рабочей нагрузке, обычно регрессионным образом, когда в приложение ежедневно или еженедельно вносятся небольшие изменения. Основная цель тестирования производительности - выявить и устранить узкие места производительности в программном приложении. Это подмножество performance engineering, также известное как «Perf Testing». Само по себе оно не призвано находить дефекты, но оно помогает в обнаружении узких мест в системе.

Обычно продолжительность теста производительности составляет 1 час (устойчивое состояние) на средней / ожидаемой нагрузке; это может варьироваться в зависимости от вашего SLA / требований.

![https://1.bp.blogspot.com/-Dk68xOvpYWM/WGo-EGuLf3I/AAAAAAAAAhg/DlpTlDWNZzc5\_H1EWh0kr4Q2QJXNdK3pgCEw/s1600/PT.JPG](https://1.bp.blogspot.com/-Dk68xOvpYWM/WGo-EGuLf3I/AAAAAAAAAhg/DlpTlDWNZzc5_H1EWh0kr4Q2QJXNdK3pgCEw/s1600/PT.JPG)

Примечание 1: все подвиды тестирования производительности отличаются, грубо говоря, только параметрами (тип возрастания нагрузки, ее количество, длительность и т.п.) и собираемыми метриками (без которых это тестирование бессмысленно). Точкой отсчета для всех подвидов принято брать результаты Capacity testing.

![https://lh6.googleusercontent.com/XNuV1\_4ya69jlZ7lkW-Dovc1xycy-zvrcGAKyoQxni7AITleD6eO4lsHsIp2PVA-CzpHCFrCX0MX9vBZRMHroN9i1YfDD70rIL0VdNq2593APZqVDkF-cVpLSByaOXR8XXTFuvgB](https://lh6.googleusercontent.com/XNuV1_4ya69jlZ7lkW-Dovc1xycy-zvrcGAKyoQxni7AITleD6eO4lsHsIp2PVA-CzpHCFrCX0MX9vBZRMHroN9i1YfDD70rIL0VdNq2593APZqVDkF-cVpLSByaOXR8XXTFuvgB)

Примечание 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)
* [Курс Тестирование ПО. Занятие 15. Тестирование производительности](https://www.youtube.com/watch?v=9DqXVKJTzVE)
* [Введение в тестирование производительности | Цели | Показатели | Типы | Особенности](https://www.youtube.com/watch?v=vyo1fuB7NJQ)


# Тестирование емкости (Capacity testing)

*Тестирование потенциальных возможностей (capacity testing): Тип тестирования уровня производительности для оценки уровня, при котором с увеличением нагрузки (числа пользователей, транзакций, элементов данных и т.д.) элемент тестирования подвергается угрозе не обеспечивать требуемую производительность. (ГОСТ 56920)*

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

Тестирование емкости гарантирует, что приложение и среда могут беспрепятственно обрабатывать максимальное количество пользователей или транзакций в соответствии с требованиями к производительности, определенными в вашем соглашении об уровне обслуживания (SLA). Тестирование емкости нацелено на тестирование максимальной емкости вашей системы с точки зрения трафика, при этом обеспечивая оптимальное взаимодействие с пользователем. Общие примеры SLA по производительности включают время загрузки домашней страницы, время ответа веб-страницы, продолжительность транзакции (например, - время входа в учетную запись, время поиска и платежа). Общая цель состоит в том, чтобы идентифицировать «зону безопасности» системы и удерживать ее в максимально возможной степени. Тестирование емкости помогает определить, в какой степени она может быть расширена без ущерба для опыта конечного пользователя.

Емкость системы измеряется в rps (requests per second). Используемый подход: ступенчато повышаем нагрузку до момента, когда время ответа начнет расти экспоненциально. Экспоненциальный рост времени ответа, как правило, связан с полной утилизацией одного из ресурсов, из-за которого запросы вместо моментальной обработки выстраиваются друг за другом и ждут своей очереди на обработку.

![https://miro.medium.com/max/1344/1\*B3cAJ7GfwhpgxhUX-otz-g.png](https://miro.medium.com/max/1344/1*B3cAJ7GfwhpgxhUX-otz-g.png)

Обратите внимание: от 1 до 12 rps процентиль времени ответа практически не изменяется. Только на 13 и 14 rps мы видим незначительный рост, который не изменяется с течением времени. Это значит, что мы практически исчерпали ресурс, в который упремся, но очередь еще не образуется. На 15 rps время ответа начало расти экспоненциально, значит это и есть наш предел. Таким образом, можно сделать вывод, что емкость =14 rps. Следующий шаг - поиск ресурса который исчерпался и не дает системе обрабатывать больше 14 rps.

![https://camo.githubusercontent.com/20dc14aa223c19464db011a8f71c8c61e426fee5849f1f2f36a3681901c7844e/68747470733a2f2f6c68352e676f6f676c6575736572636f6e74656e742e636f6d2f4e466265424f7a7139685f3531375a7730754b3536396571336b306b5759324242694f5251564b4b54613147716930457553334b65594e513259354e6649376670464a65786431436143345365446858447a344265396f535f727959524f4d624e486f4a2d434b4f46696e4f4878654e483472364f6835306c677848795944787855676172714777](https://camo.githubusercontent.com/20dc14aa223c19464db011a8f71c8c61e426fee5849f1f2f36a3681901c7844e/68747470733a2f2f6c68352e676f6f676c6575736572636f6e74656e742e636f6d2f4e466265424f7a7139685f3531375a7730754b3536396571336b306b5759324242694f5251564b4b54613147716930457553334b65594e513259354e6649376670464a65786431436143345365446858447a344265396f535f727959524f4d624e486f4a2d434b4f46696e4f4878654e483472364f6835306c677848795944787855676172714777)

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/)


# Нагрузочное тестирование (Load testing)

*Нагрузочное тестирование (load testing): Вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимально допустимого уровня нагрузки для исследуемого компонента или системы. (ISTQB)*

*Нагрузочное тестирование (load testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при ожидаемых условиях переменной нагрузки, обычно для ожидаемых условий низкого, типичного и пикового использования. (ГОСТ 56920)*

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

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

![](https://lh3.googleusercontent.com/KQDgZCIEO4LqnoxMqJNaTZ3F7_bxgN7oKJfQzY_uw7FUdT8ssHCirc5E1J9l6L9lF_PXaVQIg6J1M1YsQiLv7MTAaccr3w2WmB3_0BSxo454ossgqrPGDAErf2eal5Pt0IUycExM)

**Подход к нагрузочному тестированию**:

**Определите критерии приемки нагрузочного теста**. Например:

* Время отклика страницы входа не должно превышать 5 секунд даже в условиях максимальной нагрузки;
* Загрузка ЦП не должна превышать 80%;
* Пропускная способность системы должна составлять 100 транзакций в секунду;

**Определите бизнес-сценарии, которые необходимо протестировать**. Не тестируйте все потоки, постарайтесь понять основные business flows, которые, как ожидается, будут происходить в производственной среде. Если это уже существующее приложение, мы можем получить информацию из логов. Если это новое приложение, нам нужно работать с бизнес-группами, чтобы понять закономерности потока, использование приложения и т. д. Иногда команда проекта проводит семинары, чтобы дать обзор или подробности о каждом компоненте приложения;

**Моделирование рабочей нагрузки**. Получив подробную информацию о бизнес-потоках, шаблонах доступа пользователей и количестве пользователей, нам нужно спроектировать рабочую нагрузку таким образом, чтобы она имитировала фактическую навигацию пользователя в производственной среде или как она ожидается в будущем, когда приложение будет в производстве. Ключевые моменты, которые следует помнить при разработке модели рабочей нагрузки, - это увидеть, сколько времени потребуется для завершения конкретного бизнес-потока. Здесь нам нужно назначить время обдумывания (think time) таким образом, чтобы пользователь мог более реалистично перемещаться по приложению. Схема рабочей нагрузки обычно будет с нарастанием, спадом и устойчивым состоянием (Ramp up, Ramp down and a steady state).

![https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/06/Image5.png](https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/06/Image5.png)

Устойчивое состояние обычно представляет собой одночасовое испытание под нагрузкой с нарастанием 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)
* [50 оттенков нагрузочного тестирования](https://habr.com/ru/company/ozontech/blog/662800/)


# Стрессовое тестирование (Stress testing)

*Стрессовое тестирование (stress testing): Вид тестирования производительности, оценивающий систему или компонент на граничных значениях рабочих нагрузок или за их пределами, или же в состоянии ограниченных ресурсов, таких как память или доступ к серверу. (IEEE 610)*

*Стрессовое тестирование (stress testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при условиях загрузки, выше ожидаемой или указанной в требованиях к производительности, или при доступности ресурсов, ниже минимальной, указанной в требованиях. (ГОСТ 56920)*

Стрессовое тестирование выполняется самым первым, если нет отдельного Capacity тестирования, хотя по факту это все равно будет Capacity, т.к. нагрузка берется «с потолка». Стресс-тестирование - это отрицательное / негативное тестирование, которые проводят при больших нагрузках или нагрузках, выходящих за допустимые пределы, чтобы определить поведение системы при таких обстоятельствах, точку отказа системы (числовые показатели метрик), показываются ли корректные ошибки при этом и не теряются ли данные. Это тестирование также называют Fatigue testing.

![](https://lh3.googleusercontent.com/aIJG3A1Mujx5ChXCbyeoY7SBwy06KdJSOjREYmcbiBXJdUdBDMxypKzoxodqx3l4JU7ouVi2zLrmZw8OSOHy_QxwxuYZc2qh65G2VOhuqVSrponf-MQNWmAFGwacN8luIGCaoRmc)

**Виды стресс-тестирования**:

* Распределенное стресс-тестирование: тесты выполняются для всех клиентов с сервера для отслеживания их статуса, а также для выявления сбоев из-за чрезмерного стресса;
* Стресс-тестирование приложения: основное внимание в этом тестировании уделяется обнаружению дефектов в программном обеспечении, связанных с блокировкой данных (locking and blocking), проблемами сети и узкими местами производительности;
* Транзакционное стресс-тестирование: транзакционное тестирование выполняет стресс-тестирование одной или нескольких транзакций между различными программными продуктами или приложениями. Его основная цель - точная настройка и оптимизация системы для повышения ее производительности;
* Систематическое стресс-тестирование: интегрированное стресс-тестирование, систематическое стресс-тестирование, используется для тестирования нескольких систем, работающих на одном сервере. Это позволяет группе тестирования обнаруживать дефекты, когда данные одного программного обеспечения блокируют другое программное обеспечение;
* Исследовательское стресс-тестирование: используется для тестирования системы в необычных условиях, которые маловероятны в реальном сценарии. Эти сценарии стресс-тестирования позволяют группе обнаруживать различные необнаруженные проблемы и ошибки в системе;

**Подход / процесс** содержит те же этапы, что описаны в нагрузочном, и то же самое в остальных подвидах, поэтому дублировать нет смысла.

**Примеры**:

* Стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S);
* MS Word может выдать сообщение об ошибке «Не отвечает» при попытке скопировать файл размером 7-8 ГБ. Вы засыпали Word файлом огромного размера, и он не смог обработать такой большой файл, и в результате он завис;
* Когда большое количество пользователей одновременно получают доступ к логину / регистрации;
* Когда несколько пользователей пытаются загрузить один файл одновременно;
* База данных отключается, когда к ней обращается большое количество пользователей;
* Много пользователей заходят на веб-сайт, в то время как на сервере запускается сканирование на вирусы;
* Огромный объем данных копируется из буфера обмена и сохраняется в веб-форме большим количеством пользователей одновременно;
* Огромное количество пользователей одновременно нажимают кнопку «Добавить в корзину» на сайте покупок;

**Пиковое тестирование** (Spike Testing) - это разновидность стресс-тестирования, проводится для проверки характеристик производительности, когда тестируемая система подвергается моделям рабочей нагрузки и объемам нагрузки, которые многократно увеличиваются за пределы ожидаемых производственных операций в течение коротких периодов времени. Обычно продолжительность теста составляет 1 час; он может отличаться в зависимости от вашего SLA / требований.

[![](https://lh6.googleusercontent.com/cRXWK4ggaKSeH2nEPSPW3mGhAVi5DCuMmwmF2RgbnyAWo3homOIgRMjLrQihhjlBHUMZic9E80U44gYmbCnQ2v3lKJrlfSpANp2rGHSmxNhh15yVkaiWPyQZ74TrzcUceZ2513ZR)](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)


# Тестирование масштабируемости (Scalability testing)

Тестирование масштабируемости проводится для определения способности приложения масштабироваться с точки зрения пользовательской нагрузки, количества транзакций, объема данных и т. д. Цель теста масштабируемости отличается от стрессового или нагрузочного тестирования. Например, компания ожидает шестикратного увеличения нагрузки на серверы в течение следующих двух месяцев. Им может потребоваться увеличить производительность сервера и сократить время обработки запроса, чтобы лучше обслуживать посетителей. Если приложение масштабируемое, вы можете сократить это время, обновив оборудование сервера, например, вы можете увеличить частоту ЦП и добавить больше ОЗУ. Также вы можете улучшить производительность запросов, изменив программное обеспечение сервера, например, заменив хранилища данных в текстовых файлах базами данных SQL Server. Чтобы найти лучшее решение, вы можете сначала протестировать изменения оборудования, затем изменения программного обеспечения, а затем сравнить результаты тестов.

![https://3.bp.blogspot.com/-gPgmUKp\_Slo/WGpIluEQo5I/AAAAAAAAAiQ/SuqNljCUmt8237AJALoUpbH1UNyvIGhowCLcB/s1600/Scal.png](https://3.bp.blogspot.com/-gPgmUKp_Slo/WGpIluEQo5I/AAAAAAAAAiQ/SuqNljCUmt8237AJALoUpbH1UNyvIGhowCLcB/s1600/Scal.png)

Пример: если тестирование масштабируемости определяет максимальную нагрузку в 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)


# Объемное тестирование (Volume testing)

*Объемное тестирование (volume testing): Тип тестирования уровня производительности, проводимого для оценки способности элемента тестирования обработать определенные объемы данных (обычно равных или близких к максимальным указанным потенциальным возможностям) с точки зрения потенциальных возможностей пропускной способности, емкости памяти или того и другого. (ГОСТ 56920)*

Объемное тестирование (также flood testing) предназначено для прогнозирования того, может ли система / приложение обрабатывать большой объем данных в плане проверки объема данных, обрабатываемых базой данных. Это тестирование сосредоточено на наполнении БД продукта в реальных сценариях использования, отслеживании производительности приложения при различных объемах БД. Обычно продолжительность проверки объема составляет 1 час или время, необходимое для обработки n записей; оно может варьироваться в зависимости от вашего SLA / требований.

![https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/01/Connected-Data.jpg](https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/01/Connected-Data.jpg)

**Причины для проведения этого тестирования**:

* Самая основная потребность - проанализировать производительность вашей системы при увеличивающемся объеме данных. Создание огромного объема данных поможет вам понять производительность вашей системы с точки зрения времени отклика, потери данных и т. д.;
* Выявление проблем, которые могут возникнуть с огромными данными, а также пороговой точки (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)


# Тестирование выносливости/стабильности (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 / требований.

![https://2.bp.blogspot.com/-KbnavvSmd6c/WGpHUSwXs7I/AAAAAAAAAiI/vHbqTrq1QQUd6cGBdNZdz4yn2nbBS2ZEgCLcB/s1600/ET.JPG](https://2.bp.blogspot.com/-KbnavvSmd6c/WGpHUSwXs7I/AAAAAAAAAiI/vHbqTrq1QQUd6cGBdNZdz4yn2nbBS2ZEgCLcB/s1600/ET.JPG)

Источники:

* [Do you really know all types of Performance Tests (Non-Functional Tests)?](https://perfmatrix.blogspot.com/2017/01/type-of-performance-test.html)


# Тестирование устойчивости (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/)


# Тестирование надежности (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)

Доп. материал:

* [Тестирование надежности (стабильности)](http://okiseleva.blogspot.com/2022/04/blog-post.html)


# Тестирование на отказ и восстановление (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/)


# Эталонное и базовое тестирование (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)


# Тестирование хранилища (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/)


# Одновременное / многопользовательское тестирование (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/)


# Тестирование сервиса (Service Testing)

Качество обслуживания, предоставляемого веб-приложением, может быть определено включением всех его атрибутов, таких как функциональность, производительность, надежность, удобство использования, безопасность и так далее. Однако для наших целей здесь мы выделяем три конкретные задачи обслуживания (service objectives), которые подвергаются тщательной проверке в рамках того, что мы называем «тестированием услуг»:

* Performance;
* Reliability;
* Manageability;

Во всех трех случаях нам необходимо моделировать пользовательскую нагрузку для эффективного проведения тестов. Цели производительности, надежности и управляемости существуют в контексте реальных клиентов, использующих сайт для бизнеса. Скорость отклика (в данном случае время, необходимое одному системному узлу для ответа на запрос другого) сайта напрямую зависит от ресурсов, доступных в технической архитектуре. Чем больше клиентов используют эту услугу, тем меньше технических ресурсов доступно для обслуживания запросов каждого пользователя, и время отклика сокращается. Очевидно, что слабо загруженная служба с меньшей вероятностью выйдет из строя. Большая часть сложности программного и аппаратного обеспечения существует для удовлетворения требований к ресурсам в рамках технической архитектуры, когда сайт сильно загружен. Когда сайт загружен (или перегружен), конфликтующие запросы ресурсов должны управляться различными компонентами инфраструктуры, такими как серверные и сетевые операционные системы, системы управления базами данных, продукты веб-серверов, брокеры объектных запросов, промежуточное ПО и т. д. Эти компоненты инфраструктуры обычно более надежны, чем код специально созданного приложения, которому требуются ресурсы, но сбои могут произойти в одном из следующих случаев:

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

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

**Тестирование управления услугами** (Service Management Testing). Когда служба развертывается в производственной среде, ею необходимо управлять. Для поддержания работоспособности службы необходимо, чтобы ее отслеживали, обновляли, создавали резервные копии и быстро исправляли, когда что-то пойдет не так. Процедуры, которые менеджеры служб используют для выполнения обновлений, резервного копирования, выпусков и восстановлений после сбоев, критически важны для обеспечения надежной службы, поэтому им необходимо тестирование, особенно если служба претерпит быстрые изменения после развертывания. Необходимо решить следующие конкретные проблемы:

* Процедуры не дают желаемого эффекта;
* Процедуры неработоспособны или непригодны;
* Процедуры нарушают прямую трансляцию;

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

Источник:

[Leadership in test: service testing](https://theqalead.com/topics/service-testing/)


# Тестирование безопасности (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 - максимальная длина, указанная для поля «Имя», а входная строка «\<p> 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);

**Точки доступа к сервису** (закрытые и безопасные открытые).

![https://www.softwaretestinghelp.com/wp-content/qa/uploads/2011/09/Service-Access-Points-Sealed-and-Secure-Open.jpg](https://www.softwaretestinghelp.com/wp-content/qa/uploads/2011/09/Service-Access-Points-Sealed-and-Secure-Open.jpg)

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

Как протестировать точки доступа к сервису (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://www.youtube.com/watch?v=C0euAbFaT4s)
* [Список книг по наступательной информационной безопасности](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/)
* [Тестирование безопасности / защищенности](http://okiseleva.blogspot.com/2021/11/blog-post_7.html)


# Оценка уязвимости/защищенности (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

![https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/01/Vulnerbility-Assessment-and-Penetration-Testing.jpg](https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/01/Vulnerbility-Assessment-and-Penetration-Testing.jpg)

| 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/)
* [Охота за багами: как прокачаться этичному хакеру, чтобы больше зарабатывать на поиске уязвимостей](https://habr.com/ru/company/pt/blog/675748/)


# Фаззинг-тестирование (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/)


# Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести

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

*Есть функциональное требование: “Пользователь должен иметь возможность перевести деньги со своей карты на другую карту по номеру".*

*Это функциональное требование (ну, на самом деле это целая тонна требований, но обобщим их до одной user story).*

*Оно отвечает на вопрос "какие операции должен уметь выполнять сервис".*

*К этой функциональности может предъявляться еще куча требований - по безопасности, по скорости, по отказоустойчивости, и т.д. Они описывают то, КАК система должна работать, а не ЧТО она должна уметь.*

*Нефункциональные требования могут быть критичными, могут блокировать выпуск той или иной функциональности. Но это все еще свойство фичи, а не какая-то самостоятельная ее функция.*

*В то же время, есть, например, функциональные требования безопасности, типа "автоматически блокировать транзакции обладающие характеристиками А, Б, В". (с)* [azshoo](https://t.me/qajuniors/253022)


# Тестирование совместимости/взаимодействия (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/)


# Конфигурационное тестирование (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/)


# Инсталляционное тестирование (Installation Testing)

*Тестирование устанавливаемости (installability testing): Тип тестирования переносимости для оценки того, могут ли должным образом элемент тестирования или совокупность элементов тестирования быть установлены во всех указанных средах. (ГОСТ 56920)*

Тестирование инсталляции (установки) направлено на проверку успешной установки, настройки, обновления и удаления ПО, как десктопного, так и мобильного.

**Примеры кейсов**:

**Установка**.

* Установка должна начаться при клике по кнопке, подтверждающей данное действие;
* Установки во всех поддерживаемых окружениях и на всех поддерживаемых платформах;
* Установки в неподдерживаемых окружениях, а также в нужных окружениях с некорректными настройками;
* Права, которые требует инсталляция (чаще всего они должны быть админскими), проверить установить приложение как гость;
* Установки в clean state (при отсутствии любых возможных связанных файлов и предыдущих версий);
* Подсчитывается ли при установке количество свободного места на диске и выдается ли предупреждение если места недостаточно;
* Установки загруженного ранее приложения, а также прямая установка с использованием сети/беспроводного соединения;
* Восстановится ли процесс установки при внезапном его прерывании (отключение устройства, отказ сети, отключение беспроводного соединения);
* Установка приложения, его запуск, удаление приложения должны возвращать систему в исходное состояние;
* Распознается ли наличие в системе приложений/программ, необходимых для корректной работы устанавливаемого приложения;
* Повторный запуск установки приложения при уже текущем должен выдавать корректное сообщение, двойная установка должна быть исключена;
* Процесс установки может быть настраиваемый/дефолтный. Убедиться, что оба корректно работают
* Наличие кнопки, которая предложит сохранить приложение в определенную папку, а также указывает дефолтное местоположение (“C:/programs/.”);
* Правильно ли установлены, сохранены ли в корректных папках файлы приложения;
* Наличие созданных ярлыков, корректно ли они расположены;
* После установки в системной вкладке “ Программы и компоненты” должны быть доступны: название приложения, иконка, имя издателя, размер приложения, дата установки и номер версии;
* Настройки переменных сред PATH;
* Убедиться, что лицензионный ключ сохраняется в Windows Registry library;
* Поддерживает ли приложение функции ‘UnInstall’, ‘Modify’, ‘ReInstall’ и корректно ли они работают;
* Работа приложения с уже существующими DLL-файлами, с DLL-файлами приложений, которые необходимы для корректной работы устанавливаемого приложения;
* Наличие информации/сообщение о том, когда истекает срок действия установленной пробной версии приложения;

**Обновление**:

* Поддерживает ли приложение функцию обновления/автообновления;
* При попытке установить ранее установленную версию приложения система должна ее распознать и выдать корректное сообщение;
* Сохраняются ли пользовательские настройки при попытке загрузить новую версию/обновить старую версию;
* При попытке обновить версию должны быть доступны функции удалить приложение и восстановить приложение;
* Стандартные проверки как при первичной установке приложения;
* Убедиться, что номер версии приложения сменился новым;
* Запустить приложение и убедиться, что оно работает корректно;

**Откат до предыдущей версии**:

* Попробовать установить старую версию на более новую;
* Наличие корректного сообщения при попытке отката;
* Убедиться, что приложение работает корректно;

**Удаление приложения**:

* Не остается ли в системе никаких папок/файлов/ярлыков/ключей реестра после полного удаления приложения;
* Корректно ли работает система после установки и последующего удаления приложения;

Источник:

[Тестирование инсталляции](https://qaevolution.ru/testirovanie-installyacii/)


# Тестирование на соответствие (Conformance/Compliance testing)

*Соответствие (compliance): Способность программного продукта соответствовать стандартам, соглашениям или правилам законодательства и другим подобным предписаниям. (ISTQB)*

Compliance - официальное соответствие ПО различным стандартам, законам, сертификация и т.п.

Conformance - неофициальные, внутренние стандарты организации, добровольное обязательство делать что-либо признанным образом, либо стремление к Compliance, но которое не закончено / не подтверждено формально.

Источники:

* [Compliance Vs. Conformance](https://visionintegrity.ca/compliance-vs-conformance/)

Доп. материал:

* [Невидимый регулятор. Как подстроить систему под закон?](https://www.youtube.com/watch?v=y7wspIeTD1k)
* [В чем разница между CCPA, GDPR и LGPD?](https://telegra.ph/CCPA-GDPR-and-LGPD-07-08)


# Тестирование удобства пользования (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/)


# Тестирование доступности (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.

![https://az545221.vo.msecnd.net/skype-faq-media/faq\_content/skype/screenshots/fa3501/fa3501-a.png](https://az545221.vo.msecnd.net/skype-faq-media/faq_content/skype/screenshots/fa3501/fa3501-a.png)

Если вы хотите сократить количество тестов, можно ограничиться только тремя фильтрами: дейтеранопия, протанопия и тританопия. Это наиболее выраженные формы цветовой слепоты (не считая крайне редкого черно-белого зрения). Остальные люди с особенностями цветовосприятия видят больше оттенков, и если ваш 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/)


# Тестирование локализации, глобализации и интернационализации (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)


# Исследовательское тестирование (Exploratory testing)

*Исследовательское тестирование (exploratory testing): Неформальный метод проектирования тестов, при котором тестировщик активно контролирует проектирование тестов в то время, как эти тесты выполняются, и использует полученную во время тестирования информацию для проектирования новых и улучшенных тестов. (Bach)*

*Исследовательское тестирование (exploratory testing): Тестирование, основанное на опыте, при котором тестер спонтанно разрабатывает и выполняет тестирования на основе существующих соответствующих знаний тестера, предшествующих исследований элемента тестирования (включая и результаты предыдущих тестирований) и эвристических "эмпирических правил" для общего поведения программного обеспечения и типов отказа. Примечание - Исследовательское тестирование направлено на выявление скрытых свойств (включая и скрытое поведение), которые сами по себе, с одной стороны, вполне возможно, безобидны, но, с другой стороны, могут повлиять на другие свойства тестируемого программного обеспечения и тем увеличить риск того, что программное обеспечение перестанет работать. (ГОСТ 56920)*

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

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

**Подход к тестированию**:

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

**Туры в исследовательском тестировании**: Чтобы систематизировать исследовательское тестирование можно использовать идею туров. Туры - это идеи и инструкции по исследованию программного продукта, объединенные определенной общей темой или целью. Туры, как правило, ограничены по времени - длительность тестовой сессии не должна превышать 4 часа. Идею туров развивали в своих работах Канер, Бах, Хендриксон, Болтон, Кохл и другие. Джеймс Виттакер (James A. Whittaker), хоть и не придумал саму идею туров, но предложил свой подход к исследовательскому тестированию с использованием туров и в своей книге “Exploratory Software Testing” в доступной форме озвучил идею туров и описал сами туры.

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

![https://www.software-testing.by/wp-content/uploads/2015/09/328.png](https://www.software-testing.by/wp-content/uploads/2015/09/328.png)

**Помимо туров существуют:**

* **Session-Based Test Management (SBTM) или тестирование на основе сеансов (сессий)** — метод контроля исследовательского тестирования, при котором процесс разбивается на периоды определенной длины (например, 90 минут). Ставим цель, включаем таймер и тестируем;
* **Thread-Based Test Management (TBTM) или тестирование на основе цепочек** — метод контроля исследовательского тестирования, при котором возможности системы разбиваются на цепочки активностей, существующие для решения какой-либо задачи пользователя. Ограничений по времени нет, в этом случае цепочка - и есть само ограничение

Т.е. фактически при помощи SBTM и TBTM (или их сочетании) мы можем строить свои "туры", которые будут исходить в первую очередь из контекста тестируемой системы.

Источники:

* [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/)
* [Исследовательское тестирование](https://tmguru.ru/baza-znanij/protsess-testirovaniya/issledovatelskoe-testirovanie/)

Доп. материал:

* [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)


# Свободное / Интуитивное тестирование (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/)


# Тестирование поддержки (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.


# Регрессионные виды тестирования (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 этап будет успешно завершен. При изучении системы, например, с помощью [карты функциональных возможностей](http://okiseleva.blogspot.com/2020/01/mind-map.html), становятся видны самые длинные ветви — это и есть критические пути, которые, кстати, пришли к нам из одноименного [метода управления проектами](https://skillbox.ru/media/management/kak-zavershit-proekt-v-srok-s-pomoshchyu-metoda-kriticheskogo-puti-rasskazyvaem-na-primere/). Здесь лимит метрик немного ниже, чем у 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)
* [Курс Тестирование ПО. Занятие 26. Регрессионное тестирование (Regression Testing)](https://www.youtube.com/watch?v=1f3yfUnji8o)
* [История о бесконечном регрессионном тестировании](https://habr.com/ru/company/icl_services/blog/668742/)
* [Санитарное тестирование санитаров](https://testitquickly.com/2018/06/25/mens-sanita-in-corpore-sanity/)


# Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)

![https://www.guru99.com/images/1/111517\_1154\_FrontendTes1.png](https://www.guru99.com/images/1/111517_1154_FrontendTes1.png)

**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)


# Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing

**Интерфейс** - это то, с помощью чего происходит “общение” между ПО и окружением, граница двух взаимодействующих сущностей.

**Виды интерфейсов:**

* **Интерфейс командной строки** (CLI - Command Line Interface), где вы вводите текст в терминал, и компьютер отвечает на эту команду;
* **Графический интерфейс пользователя** (GUI - Graphical User Interface) , где вы взаимодействуете с компьютером, используя графическое представление, а не текст;
* **Прикладной программный интерфейс** (API - Application Programming Interface) - это набор правил и определений, который позволяет различным программам взаимодействовать друг с другом;
* **Интерфейс аппаратного обеспечения** (HI - Hardware Interface) - это физическая точка соединения между двумя устройствами, например, USB-порт.

**Тестирование графического интерфейса пользователя** (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://beseller.by/blog/interface/)

Доп. материал:

* [Тестирование GUI: полное руководство](https://testengineer.ru/testirovanie-gui-polnoe-rukovodstvo/)
* [Эффективное тестирование верстки](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)


# Тестирование API (API - Application Programming Interface)

Каждый день используя любимые мобильные приложения и веб-ресурсы вы незаметно взаимодействуете с API, скрытым под интерфейсом пользователя.

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

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

Можете попробовать взаимодействие с API сами: отправляете GET запрос на <https://reqres.in/api/users>, и получаете в ответ список пользователей. Это очень удобно, когда вы хотите предоставить интерфейс взаимодействия со своим сервисом сторонним лицам. Например, у google, instagram, vk и, в общем-то, всех популярных продуктов есть открытая часть API. То есть у вас есть документ с перечнем того, что и как можно спросить и что вам на это придет в ответ. Взаимодействовать с API можно и с веб-страницы, и с помощью специальных инструментов и напрямую из кода. Помимо прочего, API бывает не только в контексте сетей, например, в той же системе Android есть внутреннее системное API.

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

![https://cdn-images-1.medium.com/fit/t/1600/480/0\*xP5HjXhJk383Jkyz.png](https://cdn-images-1.medium.com/fit/t/1600/480/0*xP5HjXhJk383Jkyz.png)

Типы тестирования 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)

Доп. материал:

* [Список полезных статей и видео для изучения тестирования API](https://habr.com/ru/post/667634/)
* [Тестирование GraphQL](https://telegra.ph/GraphQL-05-18)
* [Удачный шаблон документации на API, который будут читать](https://habr.com/ru/post/667884/)
* [Игорь Гольшмидт. А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)


# 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.                              | Здесь ваш трафик будет разделен на несколько веб-страниц с несколькими вариантами.                                                                                                                                                             |
| Вам не понадобится большой трафик, чтобы попробовать это тестирование.                                        | Для реализации многовариантного тестирования ваш сайт должен иметь огромные объемы трафика.                                                                                                                                                    |
| <p>Пример: изменение цвета кнопки покупки.</p><p>Версия A: цвет по умолчанию</p><p>Версия B: красный цвет</p> | <p>Пример: изменение основных элементов целевой страницы.</p><p>Версия A: Headline\_3, Img\_2, CTA\_1</p><p>Версия B: Заголовок\_1, Img\_3, CTA\_2</p><p>Версия C: Headline\_2, Img\_4, CTA\_1</p><p>Версия D: Headline\_4, Img\_1, CTA\_3</p> |

**Тестирование разделением 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)
* [A/B ТЕСТИРОВАНИЕ ЗА 6 МИНУТ](https://www.youtube.com/watch?v=lK02b1uthrY)


# Деструктивное и недеструктивное тестирование (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)

Доп. материал:

* [Позитивность тестов, негативное тестирование / Урок 14 / Тестировщик с нуля](https://www.youtube.com/watch?v=b_1eXkzYc-g)
* [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/)


# Выборочное/хаотическое тестирование (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**                                                                             |
| --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Фокусируется на ломании приложения случайным вводом                                                                                                 | Фокусируется на поиске ошибок, которые не были обнаружены существующими кейсами                |
| Ошибки обнаруживаются на основе случайных входных значений                                                                                          | Ошибки обнаруживаются на основе неисследованных областей приложения                            |
| Тестировщики не знают приложение, они тестируют приложение, случайным образом щелкая или вводя данные, чтобы проверить, не приводит ли это к ошибке | Тестировщик должен хорошо разбираться в приложении и понимать его функции                      |
| От тестировщика не требуется быть экспертом в данной области или иметь какие-либо глубокие знания о приложении.                                     | Тестировщик будет знать точный рабочий процесс приложения вместе со знанием предметной области |
| Может быть выполнено любым стейкхолдером                                                                                                            | Обычно выполняется тестировщиком, который знает приложение                                     |

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

Источники:&#x20;

* [Monkey Testing Guide](https://www.softwaretestingmaterial.com/monkey-testing/)

Доп. материал:

* [Курс Тестирование ПО. Занятие 17. Monkey and Gorilla Testing](https://www.youtube.com/watch?v=xFiHnqYqNkE)


# Тестирование рабочего процесса/воркфлоу (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)


# Тестирование документации (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)


# Как протестировать продукт без требований?

Продукта без требований не существует, просто они могут быть не формализованы и не записаны. Любая информация о поведении системы, её свойстах и атрибутах может являться требованием. Если вам дали протестировать какое-то готовое решение, к которому нет документации, то нужно попытаться восстановить все явные и неявные требования: изучив функционал (какую проблему решает продукт? для чего его создали?), целевую аудиторию (для кого его создали?), попытаться найти тех, кто мог знать что-то и уже не в команде; список источников получения неявных требований вообще огромен. На основе всего этого уже как минимум можно составить 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/)


# Кроссбраузерное тестирование (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)


# Тестирование, основанное на рисках (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:

![https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/06/risk.png](https://www.softwaretestinghelp.com/wp-content/qa/uploads/2018/06/risk.png)

Риск идентифицируется и анализируется, т. е. рассчитывается влияние (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/)


# Разница тестирования ПО и железа (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)


# Тестирование качества данных (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/)


# Тест дизайн


# Тест-дизайн и техники тест-дизайна (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
    * 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) (доклад с примерами)
* [Тест-дизайн. Что это такое? Тест дизайн в тестировании ПО. Test design](https://www.youtube.com/watch?v=x8QI3vNxg-8)
* [Лекция 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)
* [Анализ тестов - как выкидывать лишнее](https://habr.com/ru/post/670428/)


# Static - Reviews

*Рецензирование (review): Оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. Примерами рецензирования могут служить: управленческое рецензирование, неформальное рецензирование, технический анализ, инспекция и разбор. (ISTQB)*

*Неформальное рецензирование (informal review): Рецензирование, которое не основано на формальной (документированной) процедуре. (ISTQB)*

*Разбор (walkthrough): Пошаговый разбор, проводимый автором документа для сбора информации и обеспечения одинакового понимания содержания документа. (IEEE 1028)*

*Равноправный анализ (peer review): Рецензирование разрабатываемого программного продукта, проводящееся сотрудниками компании-разработчика с целью нахождения дефектов и внесение улучшений. Примерами рецензирования являются: инспекция, технический анализ и разбор. (ISTQB)*

*Инспекция (inspection): Тип равноправного анализа, основанный на визуальной проверке документов для поиска ошибок. Например, нарушение стандартов разработки и несоответствие документации более высокого уровня. Наиболее формальная методика рецензирования и поэтому всегда основывается на документированной процедуре. (IEEE 610, IEEE 1028). См. также равноправный анализ.*

Методы статического тестирования делятся на две основные категории, одной из которых являются ревью. Ранжирование по уровню формальности:

![https://www.tutorialspoint.com/software\_testing\_dictionary/images/peer\_review.jpg](https://www.tutorialspoint.com/software_testing_dictionary/images/peer_review.jpg)

**Экспертные обзоры** (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: модератор проверяет, все ли ошибки устранены или нет. Затем модератор готовит отчет. Если все ошибки исправлены и устранены, модератор выпускает документ. В противном случае в отчет добавляются нерешенные вопросы и назначается еще одно инспекционное собрание;

![](https://lh3.googleusercontent.com/3Zp7j69Y1F9v2cNbZ6e6xR128Uc9GOtuq-Y-Rl44fuWU6cPb8ZC6S1E_V2AGJf1LVjIRQ6r2S2YaOc1E6-3qZBV5x9P9K4nVkbfn4C75dbz_ePadqrjDLY1XYAQjBzWnbaf5a2_Q)

Источники:

* [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/)

Доп. материал:

* [YAMP 30.04.2022 - Вместе с Кириллом Розовым (Тинькофф, Android Broadcast) проведем Android Code Review](https://www.youtube.com/watch?v=n3OfjZxFo04\&t=3945s)


# 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/)




---

[Next Page](/qa_bible/llms-full.txt/1)