GitBook: No commit message

README.md

@@ -1,22 +1,18 @@
-![](https://i.postimg.cc/D0zVsMFv/5fb0706dfacf60e0d6152bfa2c39d6db.png)
+# Введение
 
-[**>>> ЧИТАТЬ <<<**](https://vladislaveremeev.gitbook.io/qa_bible/)
+![](https://lh4.googleusercontent.com/3vOk0NqvhT3rVjNa-n8BtCfTWXq2sdBu1dUVsZvK3-gkD8c3KhsH2BL6TPX5KDFr2lEhuSqm\_bcy3UwAQFOpY6MlE\_PEBiR5g9uzJuS5SaAZI9oyhAG77QhmJXHvXhPuFVRTa\_wK)
 
-**Что это за проект?** 
+**Что это за проект?**
 
 “Библия QA” - это обновляемая база знаний объемом 560+ страниц:
 
-
-
 * Ответы на самые популярные вопросы новичков о профессии и старте карьеры;
 * Крупнейшая подборка ссылок и полезных ресурсов;
 * Конспект всевозможной теории и ответов на вопросы с реальных собеседований.
 
 **Дисклеймер**:
 
-
-
 * Материал не проектировался как обучающий, за этим на хорошие курсы или в фундаментальные книги;
 * Здесь можно найти очень многое, но это не значит, что всё это нужно знать. Это копилка, а не учебник. Перечень тем для джунов есть в f.a.q;
 * Конспект теории авторский и составлен одним простым человеком, который не senior. Каждую из тем наверняка можно написать полнее и правильнее, ссылки подобрать получше, но на это уйдет еще не один год;
-* Проект находится в свободном доступе, не содержит рекламы и открыт для контрибьютинга. 
+* Проект находится в свободном доступе, не содержит рекламы и открыт для контрибьютинга.

avtomatizaciya-beta/README.md

@@ -0,0 +1,3 @@
+# Автоматизация (beta)
+
+_Это черновик большого раздела автоматизации тестирования. Здесь не будет подробных гайдов по инструментам с практикой и кодом. Вместо этого, в рамках своих скромных компетенций, я бы хотел рассмотреть азы, дающие представление об общей картине: что это, зачем оно надо, какая бывает автоматизация, что следует автоматизировать, общие сведения о CI/CD, инфраструктуре, месте автотестов в общем пайплайне, механизме их запуска и отчетности, а также темы, полезные для поиска работы автоматизатором._

avtomatizaciya-beta/chto-nuzhno-avtomatizirovat.md

@@ -0,0 +1,29 @@
+# Что нужно автоматизировать?
+
+![](https://lh6.googleusercontent.com/yDbU5SIioPOuXUCODDzKU\_bID9PTPggk12UDYTBN9UTdP02fGiaKqbV5YL0KgWbnz-HLpzLQje\_5ROaA1t0GHhrappPZZOQxvABAQaAHMhllGxmPmRFnMlT\_j\_R0OhVDoubluW70)
+
+**Какие модули и места следует подвергать автоматизации?**
+
+* Участки кода, исполнение которых трудно визуализировать и получить осязаемую информацию о протекающих процессах (back-end процессы, занесение в базу данных, занесение логов в файл);
+* Функциональность продукта, которая будет использоваться наиболее часто и возникновение ошибок которой связано с достаточно высоким риском. Автоматизированное тестирование узловых моментов функциональности потребует меньше времени для поиска ошибок. И соответственно, сократит время на их устранение;
+* Типовые часто выполняемые операции, которые обычно связаны с обработкой данных (CRUD). Например - формы, в которых количество заполняемых граф и полей довольно значительное. Цель - автоматизировать занесение требуемых данных в нужное поле и проверить правильность выполнения задачи после сохранения результата;
+* Сообщения об ошибках. Требуется автоматизация разнесения некорректных данных по соответствующим полям и тестирование корректности проверки правильности данных и сообщений об ошибках;
+* Комплексная проверка поведения всей системы, как целостного объекта (end-to-end testing);
+* Проверка числовых массивов, нужных для достоверных математических операций;
+* Тестирование корректности отображаемых результатов поиска в ответ на запрос по нужным данным;
+* Предложенный список только ориентировочный. Всё зависит от предъявляемых к проверяемой системе требований, возможностей, которые позволяет реализовать выбранный для автоматического тестирования инструмент.
+
+Источники:
+
+* [Какие места в проекте нужно автоматизировать в первую очередь?](https://software-testing.org/automation-testing/kakie-mesta-v-proekte-nuzhno-avtomatizirovat-v-pervuyu-ochered.html)
+
+Доп. материал:
+
+* [Автоматизировать или нет: спорные кейсы, плюсы и минусы автотестов](https://habr.com/ru/post/653721/)
+* [How To Select Correct Test Cases For Automation Testing (And Ultimately Achieve A Positive Automation ROI)](https://www.softwaretestinghelp.com/manual-to-automation-testing-process-challenges/)
+* [How To Implement Efficient Test Automation In The Agile World](https://www.softwaretestinghelp.com/automation-in-agile-world/)
+* [Right Tests for Automation](https://www.softwaretestinghelp.com/automation-testing-tutorial-1/#:\~:text=to%20strategize%20automation.-,Right%20Tests%20for%20Automation,-The%20best%20way)
+* [Решаем, что и когда автоматизировать, и нужно ли](https://testengineer.ru/reshaem-chto-i-kogda-avtomatizirovat/)
+* [Не автоматизируйте test cases](https://habr.com/ru/post/652499/)
+* [Автоматизация тестирования: что можно, а что не нужно](https://cleverics.ru/digital/2021/01/sw-testing-automation/)
+* [Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать](https://telegra.ph/Luchshie-praktiki-avtomatizacii-testirovaniya-reshenie-chto-i-kogda-avtomatizirovat-05-06)

avtomatizaciya-beta/chto-takoe-flaky-tests.md

@@ -0,0 +1,56 @@
+# Что такое flaky tests?
+
+Флейки-тесты, они же “флаки”, они же нестабильные, они же ненадежные, они же “моргающие”, они же “случайно успешные”
+
+Flaky-тест, буквально “хлопчатый”, “рассыпающийся на кусочки”, в индустрии ИТ-тестирования означает нестабильный, ненадежный тест, который иногда “pass”, иногда “fail”, и трудно понять, по какой закономерности. Убийца времени тестировщика, источник нервозности в команде.
+
+На такие тесты тратится много времени. Возникает задержка, пока команда не разберется, в чем дело. Конечно, страдает продуктивность.
+
+**Причины кратко**
+
+* Тестовый фреймворк изначально плохо собран. Его код не проверен на соответствие задачам. Совет: код фреймворка должен быть в достаточной мере чистым; должны соблюдаться принципы DRY, использоваться Object design pattern страницы, или Factory design pattern.
+* В тесте слишком много hardcoded-данных. Нестабильность результатов тестов возникает, когда эти тесты запускаются в другом окружении. Надо откорректировать hardcoded-данные (практика показывает, что это чаще всего неправильно прописанные пути к чему-то, неправильные IP-адреса и т.п.).
+* Кэширование предыдущего состояния теста и запуск нового теста с кэшированными данными. Лучше чистить кэш для каждого выполнения тестов. Проверяй данные перед каждым тестом, и очищай их состояние после каждого теста.
+* По внешней причине, не связанной с самими тестами. Плохое подключение к интернету или к конкретной базе данных; неподходящая версия браузера; утечки памяти.
+* “Потеря связи” со сторонним (3rd party) компонентом также приводит к ненадежности; здесь поможет тщательная проверка сторонних компонентов перед запуском.
+* Неэффективные селекторы элементов (например XPATH), или некорректные координаты элементов. Селекторы можно поменять достаточно легко, корректируя дизайн страницы. Рекомендуется работать с более надежными селекторами (например “id” или “name”).
+* Злоупотребление “sleep”-командами, останавливающими выполнение в ожидании чего-то. Здесь помогает замена “sleep”-ожидания на более надежное в этом плане “wait”-ожидание (пока элемент появится). Это экономит время и (почти) устраняет “моргание” тестов во многих случаях.
+
+**Что делать**
+
+Если есть время, надо документировать такие тесты, и отправлять в “карантин”. После выполнения тестов, проверь выведенные данные. Проверь логи, дампы памяти, текущее состояние системы. Возможно скриншоты, если это UI-тесты. В 90% случаев причина выяснится уже на этом этапе! Если нет, создай тикеты насчет этих тестов, и проверь их по одному в карантине, тщательно. Исключи тесты в карантине из пайплайна до конца проверки, пока не добьешься стабильности. В Google тоже бывают flaky-тесты, говорит Hala Samir из Google; как они решают эту проблему? Стандартно, например анализируют выведенные данные, проверяя корреляцию с функциями возможно вызвавшими нестабильность, по возможности без перезапуска тестов.
+
+**Еще раз о причинах**
+
+Если разделить причины по происхождению:
+
+* Тесты сами по себе имеют “склонность к нестабильности”
+* Проблемы с фреймворком
+* Проблемы в подключаемых библиотеках/сервисах
+* Проблемы в операционной системе / в устройстве
+
+**Подробнее.**
+
+Как уже говорилось выше, нестабильность результатов часто возникает из-за неправильной инициализации, или «очистки». Реже, но тоже случается - от неправильно подобранных тестовых данных. Головная боль тестировщиков - асинхронные действия, на это следует обращать особое внимание. Более простая причина - неправильный порядок запуска тестов.
+
+Проблемы с фреймворком: часто фреймворк не сконфигурирован на выделение достаточных системных ресурсов; или неправильно планирует очередность запуска тестов, из-за чего они “перекрываются” между собой.
+
+Если в проекте много сторонних библиотек или подключаемых сервисов, у них может быть свое “дерево зависимостей”, где и таятся причины нестабильности. Например переменные некорректно инициализируются; память “утекает”; какой-то ресурс не отвечает на запрос; и т.п. Чтобы исключить эти проблемы, в идеале надо стремиться к “герметичности” тестовой среды, то есть тестовая среда не должна иметь внешних зависимостей.
+
+Операционная система и тестовые устройства. Банально, но причиной иногда бывает нестабильное интернет-подключение. Также банальная причина - ошибки чтения/записи на физический носитель данных.
+
+**Статистика** 
+
+Статистически (со слов тестировщиков), основные причины нестабильности это: на первом месте по «сложности разбора» асинхронные операции (async wait); затем многопоточные операции; затем неправильный порядок запуска тестов; затем аппаратные проблемы (с сетью и синхронизацией времени, или с памятью).
+
+Ну, а если найти причину нестабильных тестов и исправить их - не получается никак, то, как говорил вице-президент Unity3D Алан Берд, “нестабильные тесты это еще хуже, чем вообще без тестов”.
+
+Источники:
+
+* [Нестабильные тесты. Почему они существуют и что с ними делать](https://testengineer.ru/nestabilnye-testy-pochemu-oni-sushchestvuyut-i-chto-s-nimi-delat/)
+
+Доп. материал:
+
+* [Blog: Flaky Testing](https://www.developsense.com/blog/2021/02/flaky-testing/)
+* [Flaky-тесты: Откуда ноги растут. Опыт Uber](https://habr.com/ru/post/565806/)
+* [Flaky тесты (они же моргающие или "случайно успешные")](https://www.maxshulga.ru/2021/04/flaky-tests-or-random-success.html)