Онбординг тестировщику

###### tags: `Документация` # Онбординг тестировщику ## Кто такой тестировщик Если ты новоиспеченный тестировщик, то поздравляю! Добро пожаловать в увлекательный мир тестирования. Он полон приключений, интересных задач, загадочных багов, увлекательных пользовательских сценариев, замысловатых чек-листов и тест-кейсов. ### Описание роли Ответственный за проверку соблюдений требований к продукту, человек, стоящий на страже качества - это все про тестировщика. Его роль не ограничивается только тестированием, ведь он участвует на всех этапах разработки продукта начиная от постановки задачи и заканчивая выпуском релиза и поддержкой фичи. На данный момент у нас нет четкого разграничения на тестировщиков, QC и QA. ### Основные задачи Основной пул задач тестировщика выглядит таким образом: 1. Составление тестовой документации и поддержание ее в актуальном виде. Основу тестовой документации составляют требования к продукту, составленные PM, аналитиком, UX-дизайнером, поэтому в процессе ее написания: 1.1. Анализ и уточнение требований; 1.2. Поиск несоответствий и неточностей в требованиях; 1.3. Помощь и консультирование по пользовательским сценариям; 2. Ручное тестирование (приемочное, предрелизное, регрессионное); 3. Автоматизированное тестирование (начиная от автоматизации рутиных задач, заканчивая полноценными автотестами) 4. Составление стратегий тестирования для крупных фич; ### Компетенции тестировщика Для эффективной работы над нашими продуктами тестировщику небходимо обладать рядом компетенций. Ниже представлен список навыков и знаний, которыми может обладать тестировщик. Он варьируется от команды к команде. Данный список не означает, что необходимо знать и уметь абсолютно все из списка. 1. Тест-дизайн 1.1. Техники тест-дизайна (классы эквивалентности, граничные значения, попарное тестирование, тестирование состояний и переходов) 1.2. Умение грамотно применять техники на практике 1.3. Инструменты для автоматизации (PICT, AllPairs) 2. Тестовая документация 2.1. Знание и понимание различий видов тестовой документации (тест-кейсы, чек-листы, тест-планы) 2.2. Умение выбрать нужный формат в зависимости от задачи. 2.3. Практический навык составления тестовой документации 2.4. Умение пользоваться инструментами тестовой документации (TestIT) 2.5. Составление тест-плана для объемных фич 2.6. Навык составления качественных баг-репортов 3. Виды тестирования 3.1. Знание и понимание различий видов тестирования (функциональное, регрессионное, модульное, нагрузочное и т.д). 3.2. Умение выбрать и применить нужный вид тестирования для конкретной задачи. 4. Автоматизация 4.1. Умение автоматизировать рутинную операцию (Например генерация n сущностей, установка/обновление продукта) 4.2. Знание и понимание различий видов автотестов (юнит, интеграционные, e2e, браузерные) 4.3. Умение выбрать нужный вид в зависимости от задачи 4.4. Знание ЯП на уровне автоматизации тестирования (Python, JavaScript) 4.5. Библиотеки (Selenium, Puppeteer) 4.6. Знание тестовых фреймворков (PyTest, hamcrest, Mocha) 4.7. Анализ результатов автотестирования (Allure Report) 5. Linux (консоль, администрирование) 5.1. Работа с логами (поиск проблем) 5.2. Работа с файлами (создание, редактирование, удаление, перемещение, изменение прав, поиск) 6. MySQL 6.1.Знание базовых команд 6.2. Выполнение простых и сложных запросов 7. Работа с DevTools 7.1. Посмотреть запросы и ответы сервера (Network) 7.2. Умение работать с Console, Local Storage, Cookies. 8. API 8.1. Работа с документацией API 8.2. Знание методов отправки и получения данных (GET, POST, DELETE) 8.3. Отправка запросов, выполнение цепочек запросов и понимание корректности ответов сервера 8.4. Умение пользоваться инструментами для работы с API (Postman, curl, python) 8.5. Знание принципов REST API 9. Docker 9.1. Работа с контейнерами и образами (остановить контейнеры, запустить контейнеры, зайти в контейнер, спулить образы) 9.2. Работа с docker-compose.yml 10. Git 10.1. Знание и понимание GitFlow 10.2. Базовые команды (clone, commit, checkout, branch) ## Индивидуальный план развития Индвидуальный план развития - это план в соответствии с которым мы осуществляем рост и развитие сотрудника. План составляется на определенный период времени и включает в себя совокупность задач, которые удовлетворяют пожеланиям тестировщика, потребностям компании и роадмапу команды. Пример плана развития для Junior тестировщика: | Задача | Ожидания от выполнения задачи | |:--:|:---------| | Изучить процессы команды | Знание и понимание воркфлоу команды: *Статусы, теги и последовательность работы с задачами в YT; Работа с бранчами и тегами продукта; Процесс выпуска релизов; Структура проекта в TestIT, работа с артефактами, тест-планы.* | | Изучить продукт | Знание базовых вещей в продукте: *Как развернуть стенд с нуля, как обновить существующий стенд; Как зайти в БД, в каких таблицах находятся базовые сущности; Где и какие логи смотреть при возниковении ошибок; Где находятся базовые сущности в интерфейсе и как с ними взаимодействовать.*| | Взаимодействовать в команде | Понимание того, к кому идти с возникшим вопросом. Участие в командных мероприятиях, обсуждениях. | | Самостоятельно работать над задачами тестирования | Самостоятельное выполнение задач тестирования по готовым артефактам. Отсутствие критичные ошибок по результату тестирования. *Самостоятельность может включать в себя уточнения у разработчиков, стороннюю помощь в случае возникновения проблем, уточнения спорных моментов у участников команды.*| | Научиться заводить задачи и описывать замечания | Заведенные задачи и замечания выявленные при тестировании не вызывают критичных замечаний к оформлению, формулировкам. Описанные проблемы понятны и воспроизводимы по описанным шагам. | | Научиться оценивать объем задачи | Способность определить по количеству и наполнению артефактов насколько задача большая или маленькая. Будет плюсом способность примерно прикинуть время, но точной оценки не ожидаем. | | Научиться понимать приоритет задачи | Есть понимание того, что критично, а что имеет более низкий приоритет. С каким замечанием можно выпустить фичу в релиз, а с каким нет. | | Самостоятельно работать над задачами по составлению артефактов | Самостоятельное выполнение задач по написанию артефактов на небольшие по объему задачи. На ревью нет критичных замечаний связанных с пониманием логики продукта. Не пропускаются базовые проверки. *Самостоятельность может включать в себя уточнения у разработчиков, стороннюю помощь в случае возникновения проблем, уточнения спорных моментов у участников команды.* | | Работа над одной средней задачей составление артефактов + тестирование с поддержкой ментора. *Для каждого продукта задача подбирается своя задача в соответствии с роадмап.* | Написанные артефакты не вызывают критичных замечаний. Выпуск протестированной фичи в релиз в соответствии с запланированным временем в течении спринтов. Отсутствие критических багов на момент релиза. Контроль сроков выполнения. | | Работа над одной простой задачей самостоятельно. Составление артефактов + тестирование. *Для каждого продукта задача подбирается своя задача в соответствии с роадмап.* | Написанные артефакты не вызывают критичных замечаний. Выпуск протестированной фичи в релиз в соответствии с запланированным временем в течении спринтов. Отсутствие критических багов на момент релиза. Контроль сроков выполнения. | ## Источники знаний Мы черпаем знания из различных источников. Проходим курсы, читаем книги, проводим митапы, а также обмениваемся опытом внутри отдела. Если ты в самом начале пути, то рекомендуем почитать "Тестирование ПО. Базовый курс" Святослава Куликова. Постоянно обновляемую версию можно найти [тут](https://svyatoslav.biz/software_testing_book/). Так же на многих ресурсах рекомендуют, но мы бы **не рекомендовали** читать в начале пути книгу "Тестирование Дот Ком" Романа Савина. На портале ты сможешь найти записи курсов: 1. Комплексная система подготовки тестировщиков по программе ISTQB: [ссылка на курс](https://portal.ispsystem.com/workgroups/group/27/disk/path/%D0%9A%D1%83%D1%80%D1%81%20%D0%9A%D0%BE%D0%BC%D0%BF%D0%BB%D0%B5%D0%BA%D1%81%D0%BD%D0%B0%D1%8F%20%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%20%D0%BF%D0%BE%D0%B4%D0%B3%D0%BE%D1%82%D0%BE%D0%B2%D0%BA%D0%B8%20%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%20%D0%BF%D0%BE%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B5%20ISTQB/) 2. Организация автоматизированного тестирования: [ссылка на курс](https://portal.ispsystem.com/workgroups/group/27/disk/path/%D0%9A%D1%83%D1%80%D1%81%20%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F%20%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE%20%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/) 3. Автоматизация функционального тестирования: [ссылка на курс](https://portal.ispsystem.com/workgroups/group/27/disk/path/%D0%9A%D1%83%D1%80%D1%81%20%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F%20%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE%20%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/) 4. Программирование на Python для тестировщиков: [ссылка на курс](https://portal.ispsystem.com/workgroups/group/27/disk/path/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20%D0%BD%D0%B0%20Python%20%D0%B4%D0%BB%D1%8F%20%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/) 5. Школа Тест-Аналитика: [ссылка на курс](https://portal.ispsystem.com/workgroups/group/27/disk/path/%D0%9A%D1%83%D1%80%D1%81%20%D0%A8%D0%BA%D0%BE%D0%BB%D0%B0%20%D0%A2%D0%B5%D1%81%D1%82-%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0/) 6. Погружение в тестирование. Jedi point: [ссылка на курс](https://portal.ispsystem.com/workgroups/group/27/disk/path/%D0%9A%D1%83%D1%80%D1%81%20%D0%9F%D0%BE%D0%B3%D1%80%D1%83%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5%20%D0%B2%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.%20Jedi%20point/) :::info Если ты в процессе изучения курса или уже прошел какой-то курс, то не забудь загрузить его на диск. ::: В 2019 году мы проводили обучающий курс по тестированию для студентов "Школа тестировщиков". На нем было 11 лекций начиная с основ по тестированию и заканчивая более сложными видами тестирования. Запись видео лекций, а таже презентации можно найти [тут](https://portal.ispsystem.com/workgroups/group/27/disk/path/%D0%A8%D0%BA%D0%BE%D0%BB%D0%B0%20%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/). В январе-феврале 2022 провели внутри компании серию митапов по техникам тест-дизайна: [Записи митапов и презентации](https://ty.ispsystem.net/t/topic/434) Также делимся ссылками на записи докладов с конференций. В них можно найти много интересных тем и подчерпнуть что-то для себя: 1. Записи докладов [SQA Days #28](https://ty.ispsystem.net/t/sqa-days-28-2021/418) 2. Записи докладов [SQA Days #29](https://ty.ispsystem.net/t/sqa-days-29-2021/435) :::warning Если ты нашел интересные курсы или доклады, не забудь поделиться на [ty](https://ty.ispsystem.net) ::: ## Процессы Описание самых важных процессов тестировщика происходящих в течение спринта. ### 1. Изучение задач, уточнение требований В начале любого спринта в каждой команде проходит планирование и спринт наполняется задачами. Спринт может содержать как крупные фичи, так и небольшие задачки на дорабоку/исправление существующей функциональности. В момент когда все задачи запланированы и спринт наполнен команда приступает к разработке. Пока нет задач на тестирование тестировщик приступает к изучению задач с целью понять достаточно ли они описаны, понятны ли требования. Этапы проверки задачи: 1. Проверь все задачи на наличие всех артефактов (прототипы, схемы) и их описания - Если артефакты не добавлены, но они существуют, добавь артефакты (кто увидел, тот добавил) - Если артефакты не добавлены, и их вообще нет / недостаточно, уведоми ответственное лицо (ux-дизайнера, аналитика, разработчика) и напиши в задаче, что тестирование может быть запланировано только после добавления соответствующих артефактов (перечисляем, что именно нужно добавить). - Если описание задачи отсутствует или его недостаточно, проси разработчиков / другое ответственное лицо его дополнить - Если описание нельзя дополнить в текущий момент (например, есть несколько вариантов решения задачи, и конкретный пока не выбран) - напиши в задаче, что тестирование может быть запланировано только после добавления описания. :::warning Артефакты и уточнения по ним обязательно нужно подкреплять в задачу. Если тебе отправили артефакты или подробности в личку - перенеси их в задачу. ::: 2. Задавай любые вопросы и уточняй все непонятное по требованиям. Все, что удалось уточнить / выяснить - запиши в задачу (дополняем описание или выносим в комментарий) Далее если все требования уточнены, задачи наполнены описанием, можно приступать к подготовке тестовой документации. ### 2. Подготовка тестовой документации Порядок подготовки тестовой документации должен соответствовать приоритетам задач от более критичных к менее приоритетным. До подготовки артефактов необходимо определить как будет тестироваться задача. Часто бывает так, что на одну большую фичу заведен целый свимлайн декомпозированных задач. И сложно сходу определить получится ли его тестировать по частям. В большинстве случаев мы тестируем фичи целиком, но бывают исключения. Обсуди с командой разработчиков как они смогут передавать задачу в тестирование - по частям или целиком. Если по частям, то как фича разделится на части и какая будет последовательность передачи частей на проверку. В зависимости от этого определи в рамках какой задачи будет проводиться написание документации и тестирование или заведи отдельную задачу. После того как порядок тестирования определен, необходимо понять куда размещать документацию. Для этого задай себе следующие вопросы: - Задача на большую фичу? - Эту задачу в дальшейшем придется тестировать вновь? - Мои артефакты должны быть переиспользуемы в рамках других задач? Если на все или любой из вопросов ответ ДА, значит необходимо размещать документацию в TestIT. Если суть задачи в исправлении ошибки, мелком исправлении которое не влиет на описанные ранее сценарии, то это не означает, что артефакты не нужно писать. Их можно написать внутри задачи. Пример оформления чек-листа на баг: ![](https://i.imgur.com/YRnUscM.png) После того как определено куда размещать артефакты - необходимо продумать их формат. Если используешь TestIT - продумай структуру будущих секций и все ли умещается в стандартный формат TestIT. Иногда, когда количество проверок не умещается в формат тест-кейса или чек-листа - можно завести таблицу в Google Docs и оставить на нее ссылку в TestIT. Если используешь не TestIT, а пишешь чек-лист в задаче, то продумай какие основные проверки будут и как выстраить их структуру и вложеннось. Далее уже можно приступать непосредственно к написанию тестовой документации. Мы стремимся к тому, чтобы подготавливать артефакты до момента взятия задачи в работу разработчиком или хотя бы до передачи в тестирование. Это делается для того, чтобы у разработчиков была возможность перед передачей в тестирование: 1. Учесть узкие кейсы при разработке; 2. Посмотреть в тестовые артефакты и задать себе вопрос: "Все ли требования я учел при разработке?"; 3. Провести минимальное тестирование. Это позволяет нам сокращать количество возвратов задач в разработку. По такому принципу покрывай все задачи спринта тестовой документацией, но не забывай следить за тем, не появились ли задачи готовые к тестированию, имеющие более высокий приоритет. Если такие задачи появляются - необходимо перераспределить ресурсы. :::warning Не забывай прикреплять чек-листы в задачу. Ни в коем случае не складируй их локально на своем компьютере. Очень важно отражать в задаче все артефакты и всю историю тестирования. Можно сохранять копии для себя, но чек-лист обязательно должен быть прикреплен к задаче. Не стесняйся открыто выкладывать свои артефакты. Если в них будут недочеты, то коллеги обязательно помогут и подскажут как лучше их исправить. Это поможет тебе расти и не упускать важные моменты. ::: ### 3. Приемочное тестирование Приемочное тестирование как и подготовка документации должно соответствовать приоритетам задач от более критичных к менее приоритетным. Для того чтобы понимать какие задачи готовы к тестированию проверяй их на соответствие критериям начала тестирования. #### Критерии начала тестирования 1. Задача или все связанные задачи фичи (зависит от того как определили порядок тестирования см раздел 2) прошли ревью и перешли в статус "Подлежит проверке"; 2. В задаче отсутствуют спорные не решенные моменты (по логике, по ux); 3. В задаче есть все инструкции и документация (если она требуется); 4. Задача покрыта тестовой документацией в полном объеме. Конечно всегда бывают исключения. Например, если задача срочная и ее исправление не терпит отлагательств по договоренности внутри команды можем пропустить этап ревью или взять в тестирование задачу, которая не покрыта тестовыми артефактами. Но такие исключения не должны быть правилом. Когда задача соответствует критериям, можно приступать непосредственно к тестированию. Сам процесс тестирования стандартно включает в себя подготовку стенда/стендов и непосредственно прохождение чек-листов или тест-кейсов. По ходу тестирования могут возникать ошибки в разных количествах и различного приоритета. Все их необходимо описывать в рамках тестируемой задачи (если внутри команды не принято других правил). #### Оформление замечаний Описывай найденные ошибки в виде комментария в тестируемой задаче. Этот комментарий должен иметь следующий вид: 1. *Заголовок комментария в задаче.* Как правило, первый комментарий с правками называется типа “Правки” или “Исправления”, а последующие - “Правки 2.0” и т.п.. Лучше чтобы это был заголовок 3 (###) или 4 (####) уровня. 2. *№ исправления* порядковый, в рамках данного комментария (если есть другие комментарии - в них своя нумерация) 3. *Заголовок исправления*. Кратко описывает проблему, аналогично например заголовку задачи Заголовок может быть написан с уточнением приоритета, выделенным определенным цветом. У ошибки есть 3 варианта приоритета: `Критический приоритет` `Средний приоритет` `Низкий приоритет` В заголовке может быть дописано “ОБСУДИТЬ”, если данный пункт какой-то странный и может потребовать консультации с разработчиком или иными лицами 4. *Подробное описание проблемы*. Детальное описание ошибки, включая воспроизведение и артефакты при необходимости (скриншоты и скринкасты, логи и т.п.) Можно не писать, если суть ошибки позволяет описать всю проблему только заголовком Чтобы не сбивать маркдаун ютрека, воспроизведение нужно писать, отступив на 3-4 пробела от начала строки, примерно так, как на скриншоте ниже 5. *Данные стенда.* Если проблема воспроизводится на конкретном стенде - нужно указать ссылку и доступы на него. Если стенд один на весь список ошибок - можно указать его только один раз, в начале или конце комментария. Если стенды разные - лучше указывать для каждого пункта. Также, для облегчения жизни разработчиков, можно написать id проблемных сущностей на этом стенде, если такое возможно (например, есть проблема с остановленными вм-ками, вот id такой вм, на которой можно быстро все проверить). Пример оформления замечания: ![](https://i.imgur.com/hWhoLve.png) Иногда замечаний бывает слишком много, либо они могут блокировать дальнейшие проверки. В таких случаях нужно определить приостанавливать тестирование и осуществлять возврат задачи разработчику или продолжать тестирование. В этом помогут критерии. #### Критерии возврата задачи в работу Приостанови тестирование и возвращай задачу на доработку, если: 1. Обнаружена проблема, которая блокирует выполнение дальнейших тестов, или может повлиять на их результат * если затронута большая группа тестов (~75% и больше) - тестирование задачи приостанавливается * если затронута небольшая группа тестов (~25% и меньше) - тестирование задачи можно продолжить, за исключением тех кейсов, на которые повлияет найденная проблема 2. Количество кейсов с ошибками слишком велико, и тестировать дальше при таком количестве ошибок в текущих кейсах не имеет смысла - 50% и больше от всех пройденных кейсов завершаются ошибкой, но должно быть пройдено не менее 20% чек-листа 3. Произошли изменения требований, которые влекут пересмотр некоторых частей тест-дизайна (а возможно полностью изменяют суть задачи) Помимо этого приостановить тестирование можно в случае если произошли серьезные изменения в master или тестируемой ветке. * Если изменения непосредственно влияют на тестируемую задачу, то тестирование приостанавливаем до момента пока не обновим стенд до актуальной версии (например пока разработчик не подмержит master в тестируемый бранч). * Если изменения напрямую с задачей не связаны, но их много, то как и в первом случае, тестирование лучше приостановить. Также допустимо приостановить тестирование и отложить его в случае, когда появилась более приоритетная задача, на которую необходимо выделить ресурсы. После того как причины приостановки устранены, тестирование можно возобновлять. #### Критерии возобновления тестирования В зависимости от причины приостановки тестирования: * Решена блокирующая проблема * Устранены ошибки * Завершили / приостановили более приоритетные задачи * Изменения требований задокументированы (как в тестовых артефактах, так и в инструкциях, и т.п.) и готовы к тестированию * Обновленный master влит в тестируемый бранч При возобновлении тестирования может потребоваться не только проверка внесенных исправлений, но и повторное тестирование уже пройденных кейсов, если внесенные исправления затрагивают проверенную функциональность риемочное тестирование можно считать завершенным, когда выполнились следующие критерии. #### Критерии завершения тестирования - Все чек-листы и тест-кейсы пройдены; - Все критические ошибки исправлены и протестированы; - Не менее 85% найденных серьезных ошибок исправлены и протестированы (остальные должны быть исправлены вскоре после релиза). **Если запланирована стабилизация данной версии, то должно быть исправлено 100% ошибок среднего приоритета.** - Не менее 70% обычных ошибок исправлены и протестированы (исправление остальных может быть отложено). *Данный пункт имеет рекомендательный характер. Чаще ошибки обычного приоритета откладываются в бэклог потому, что не влияют на пользовательский путь и работу фичи напрямую. Однако есть случаи, когда откладывать исправление таких ошибок не стоит:* - Если количество ошибок велико и их количество создает эффект забагованности; - Проблемы с опечатками в тексте; - Ошибки влияют на впечатление о продукте/фиче. - На отложенные ошибки заведены отдельные задачи в бэклог; - Ветка/ветки фичи вмержены в master; - Задача или все задачи фичи перешли в статус Готово. :::warning После того как заканчивается каждый из вышеперечисленных этапов (уточнение требований, подготовка документации и приемочное тестирование) не забывай проставлять затраченное время. Про учет времени можно почитать в [статье](https://docs.gitlab-dev.ispsystem.net/onboarding/docs/tools/youtrack#%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8) ::: ### 4. Предрелизное тестирование После того как приемочное тестирование всех задач завершается и все цели спринта выполняются - планируется выпуск релиза. Подробное описание процесса выпуска релизов можно найти в статье [Регламент выпуска релизов](https://docs.gitlab-dev.ispsystem.net/onboarding/docs/process/release). Во всех командах перед выпуском релиза проводится предрелизное тестирование. Предрелизное тестирование - это прохождение основных пользовательских сценариев в ветках релизного бранча. Мы проводим предрелизное тестирование для того, чтобы исключить выпуск релиза с ошибками. #### Описание процесса Наступил день, когда необходимо провести предрелизное тестирование. По регламенту это всегда четверг на второй неделе спринта. Релизный бранч к моменту предрелизного должен быть собран. 1. Создать задачу в YT с заголовком "Предрелизное тестирование". Также в заголовок можно указать номер спринта или номер выпускаемой версии. 2. Создать тест-план в TestIT и подкрепить ссылку на него в описание задачи. 3. Обновить стенд до релизного бранча и убедиться что обновление проходит успешно. 4. Провести тестирование по тест-плану (аналогично процессу приемочного тестирования). 5. По результату тестирования в задачу прикрепляется комментарий состоящий из: * Списка замечаний (если они есть) и их приоритетов * Рекомендации к выпуску релиза. Если данная ветка не рекомендуется к выпуску указываем номера замечаний из списка исправление которых обязательно. 6. Если релиз не рекомендуется к выпуску - передать задачу тимлидам и проектному менеджеру на изучение рекомендаций. Далее командно принимается решение о том, что и в каком объеме исправлять. После чего вносятся необходимые правки и проводится приемочное тестирование правок (при необходимости повторное прохождение предрелизных сценариев). После внесения правок релиз выпускается во вторник. Но если релиз был выпущен не смотря на рекомендации тестировщика, а часть ошибок остались не исправлены - их исправление должно быть запланировано на следующий спринт. :::tip По мере появления в продукте новых фич и кейсов не забывай актуализировать предрелизные сценарии. Дополнять их новыми проверками ::: ## Инструменты тестировщика На текущий момент основным инструментом, которым мы пользуемся является TestIT. Его мы используем для написания/хранения/прохождения тестовых сценариев. Подробнее об этом инструменте уже писали с разделе [Инструменты и сервисы -> TestIT](https://docs.gitlab-dev.ispsystem.net/onboarding/docs/tools/testit). Какими еще инструментами мы пользуемся? * Для написания чек-листов и различной документации в markdown можно пользоваться https://hackmd.io/ . Тестировщики из многих команд уже пользовались им. В нем удобно хранить чек-листы распределяя их по группам тегами: ![](https://i.imgur.com/6n4l6YS.png) Также в hackmd удобно проводить ревью, оставляя комментарии к выбранным строкам (в отличии от чек-листа в YT). Но если пишешь чек-лист в hackmd не забывай переносить его в задачу. * Для написания документации которую невозможно уместить в рамках TestIT (например нужно построить таблицу с множеством условий)мы пользуемся GoogleDoc. Если необходимо создать документ делай это с корпоративного аккаунта и размещай его в [общей папке](https://drive.google.com/drive/folders/1TrZh45wh9D4MaXA7yjCW5YdKCaBQTZMT?usp=sharing). * Для сложных задач, решение которых может потребовать построение схем или майндкарт можно использовать [miro](https://miro.com/). * Есть множество онлайн сервисов, которые так или иначе упрощают нам жизнь. Например: * Онлайн сервис для попарного тестирования. Можно задавать различные условия совместимости. Довольно быстро происходит генерация, на выходе получаем файлик .xlsx: [ссылка](https://pairwise.teremokgames.com/) * Генератор различного рода данных: [ссылка](https://mellarius.ru/random-data) * Временная почта: [ссылка](https://temp-mail.org/ru/) * Существуют также инструменты, которые помогают при тестировании интерфейса: * Плагин для наложения скриншотов прототипа на интерфейс: [ссылка](https://addons.mozilla.org/ru/firefox/addon/pixel-perfect-pro/) * Линейка для измерения расстояний элементов: [ссылка](https://addons.mozilla.org/ru/firefox/addon/measure-element/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search) * Пипетка для определения цветов: [ссылка](https://addons.mozilla.org/ru/firefox/addon/colorzilla/) :::info Если знаешь другие полезные инструменты - поделись с коллегами :) ::: ## Стратегия тестирования Если перед тобой стоит решение большой по объему задачи или крупной фичи, которая разделена на итерации, то в таком случае привычный нам [процесс](https://docs.gitlab-dev.ispsystem.net/onboarding/docs/testers/process) не совсем подходит. Как правило в крупных задачах прежде чем приступить к написанию артефактов, нужно все тщательно продумать, иначе переписывание чек-листов неизбежно. Для этого мы составляем стратегии. **Стратегия тестирования** - это описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т.д. По сути стратегия - это некий план будущего процесса тестирования, следуя которому тестирование выстраивается более прогнозируемо и эффективно, с учетом нюансов, особенностей, ограничений. Основу любой стратегии конечно же составляют требования. Для крупных фич требования описываются в [Unified document](https://docs.gitlab-dev.ispsystem.net/onboarding/docs/process/ud) - этот документ и должен стать основой будущей стратегии. ### Порядок тестирования Для любой крупной фичи в большинстве случаев определяется порядок в котором разработчики будут писать код. Зачастую фичи делят на итерации и отдают в релиз по частям. Иногда бывает и так, что фича никак не делится на итерации в таком случае она отдается в тестирование и в релиз целиком. Эти вопросы решаются в процессе планирования фичи. Задачи, как правило, декомпозируются и команда определяет в какой очередности они будут реализованы. Если этот процесс не происходит, то нужно инициировать его, поговорить с командой разработчиков и определить очередность. В обоих случаях необходимо определиться с тем в каком порядке и по какому принципу фича будет проходить приемочное тестирование. В первом случае, когда фича делится на итерации, порядок тестирования должен соответствовать этим итерациям. Во втором случае, когда фича неделима и отдается целиком, порядок тестирования определяет в большинстве случаев приоритет. Пример определения порядка тестирования в стратегии тестирования dragon BILLmanager: ![](https://i.imgur.com/ybUpyot.png) В примере BILLmanager фича распределена на итерации. Внутри каждой итерации выделена проверяемая функциональность с определением приоритета, вида тестирования, а также отметкой о необходимости/наличии или отсутствии тестовой документации. ![](https://i.imgur.com/zfecU6z.png) ### Виды тестирования в стратегии Далеко не во всех задачах мы используем только сценарное тестирование (классическое тестирование на основе тестовой документации). Иногда гораздо логичнее применить другой вид тестирования. В целях, например, экономии времени и ресурсов на написание документации. Необходимо описать какие виды тестирования будут использованы и каким образом их применять. Пример расшифровки видов тестирования в стратегии dragon BILLmanager: ![](https://i.imgur.com/63cOtmN.png) ### Оценка времени Оценка времени - это важный этап в формировании стратегии тестирования. Необходимо понимать сколько времени понадобится на написание документации (в зависимости от применяемых видов тестирования), сколько времени понадобится на тестирование критичных и не критичных сценариев. От этой оценки будет зависить срок выпускаемой фичи. К оценке времени можно подходить по-разному. Можно оценить итерацию целиком, можно оценивать отдельную функциональность. Это зависит от фичи и определенного ранее порядка тестирования. Но по опыту, накопленному нами ранее, лучше все таки оценивать маленькие кусочки. Так меньше вероятность промахнуться с общей оценкой. Пример таблицы оценки времени в стратегии dragon BILLmanager: ![](https://i.imgur.com/nOwlL4f.png) ### Особенности тестирования Также необходимо определить какие особенности необходимо учесть. Например, нужно ли тестировать все версии продукта (если их несколько) и в каком объеме. Быть может проверки нужно распределить по версиям. Также, например, какие ОС необходимо протестировать, в каких браузерах нужно проверить работу интерфейса. Все эти особенности необходимо описать и учесть в дальнейшем при подготовке тестовой документации и непосредственно при тестировании. Пример описания особенностей тестирования в стратегии dragon BILLmanager: ![](https://i.imgur.com/QQDH3j6.png) ### Ограничения по тестированию Также в крупных фичах зачастую бывает так, что тестирование необходимо ограничить. Определить, что мы тестируем, а что нет. А так же выставить акценты на чем стоит сконцентрировать внимание в большей степени. Наобор тестов всегда конечен и протестировать все невозможно, как бы нам этого не хотелось. Пример ограничений по тестированию в стратегии dragon BILLmanager: ![](https://i.imgur.com/ucHk7gs.png) Изучить пример стратегии dragon BILLmanager можно по [ссылке](https://docs.google.com/document/d/1JvglCMnRtRkqKHfEfedUPjfMJa0NN3npynCZq43Aogs/edit#).

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.