QA

Что такое QA и где его место 

Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом (ISO/IEC TR 19759:2005). 

Quality Assurance engineer — это специалист по обеспечению качества, деятельность которого направлена на улучшение процесса разработки ПО, предотвращение дефектов и выявление ошибок в работе продукта. 

Основная задача QA — обеспечение качества. QA-инженер фокусирует внимание на процессах разработки ПО, улучшает их, предотвращает появление дефектов и проблем. 

Этапы тестирования : 

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

Виды тестирования и критерии классификации 

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

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

Гибкие методологии разработки и тестирование в спринте 

Гибкие методологии разработки и тестирование в спринте 

1. Agile, Agile Manifesto, Agile Umbrella 

2. Scrum. Обзор методологии, роли, митинги, артефакты. Понятия инкрементальности и итеративности 

3. Канбан и канбан доска 

4. XP методология 

5. Особенности тестирования в спринтах 

Agile, Agile Manifesto, Agile Umbrella 

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. 

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

• Фокусируют команду на нуждах и целях клиентов. 

• Упрощают оргструктуру и процессы.

• Предлагают работу короткими циклами. 

• Активно используют обратную связь.

• Предполагают повышение полномочий сотрудников. 

• Имеют в своей основе гуманистический подход. 

• Не являются конечным состоянием, а, скорее, образом мышления и жизни. 

12 принципов Agile: 

1. Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения; 

2. Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта); 

3. Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); 

4. Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; 

5. Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; 

6. Рекомендуемый метод передачи информации — личный разговор (лицом к лицу); 

7. Работающее программное обеспечение — лучший измеритель прогресса; 

8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок; 

9. Постоянное внимание улучшению технического мастерства и удобному дизайну; 

10. Простота — искусство не делать лишней работы; 

11. Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; 

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

Agile Umbrella - это семейство итеративных, инкрементальных методов 

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

2. Scrum Master - является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством: устранения препятствий, помощи, обучения и мотивации команде. 

3. Team - многофункциональная команда специалистов, которая работает над продуктом с начала и до конца. 

Основные обязанности Скрам Мастера: 

• Создает атмосферу доверия; 

• Участвует в митингах в качестве фасилитатора; 

• Устраняет препятствия; 

• Делает проблемы и открытые вопросы видимыми; 

• Отвечает за соблюдение практик и процесса в команде; 

• Ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog. 

Обязанности Product Owner: 

• формулирует требования; 

• приоритизирует требования; 

• корректирует приоритеты на каждом спринте; 

• несет персональную ответственность за ценность требований для рынка/пользователей; 

• отвечает за взаимодействие с рынком. 

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно: 

• продолжительность спринта; 

• емкость (capacity) команды; 

• размер её фокус фактора (коэффициент слаженности); 

• трудоемкость требований, которые будут реализованы в спринте; • очередность выполнения задач и много другое. 

2. Daily Scrum — это встреча Команды Разработки, которая проводится каждый день во время Спринта. Встреча не должна занимать более 15 минут, за которые Команда разработки планирует свою работу на ближайшие 24 часа. Команда оптимизирует взаимодействие между её членами и повышает свою производительность, анализируя сделанное за последние сутки и прогнозируя оставшуюся на этот Спринт работу. Для упрощения Ежедневный Скрам проводится каждый день в одно и то же время. 

3. Sprint Review — Обзор Спринта, проводится в конце Спринта с целью инспекции Инкремента и, по необходимости, адаптации Бэклога Продукта. Скрам-команда и заинтересованные лица во время Обзора Спринта совместно обсуждают то, что было сделано за Спринт. 

4. Sprint Retrospective — это возможность для Скрам-команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем Спринте. Ретроспектива Спринта проводится после Обзора Спринта и перед Планированием следующего Спринта. Максимальная продолжительность Ретроспективы – 3 часа для Спринта длительностью один месяц. Для более коротких Спринтов, как правило, отводится меньше времени. 

5. Backlog Refinement — обсуждение элементов бэклога и подготовка к следующему спринту. В рамках этой встречи можно обсудить приоритетность элементов и разделить элементы бэклога на более мелкие составляющие. 

Sprint Planning Meeting (встреча по планированию спринта): 

• выполняется всей командой перед началом спринта; 

• команда выбирает требования из Product Backlog и формирует Sprint Backlog; 

• если требуется учесть взаимосвязи между операциями, то это делается здесь; 

• команда декомпозирует требования на задачи (tasks); 

• каждая задача проходит оценку в трудозатратах или универсальных единицах; 

• во время встречи Product Owner отвечает на вопросы команды. 

Daily Meeting (ежедневная встреча команды): 

• проходит ежедневно и только в одно и то же время; 

• длительность встречи не более 15 минут; 

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

Sprint Review — сдача спринта Product Owner: • команда зачитывает требования из Sprint Backlog; • по каждому критерию приемки происходит демонстрация полученных результатов; • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже • каждое новое требование Product Owner’a записывается, чтобы позже включить его в Product Backlog. 

Sprint Retrospective: 

• Какие решения должна принять команда, чтобы сделать процесс более предсказуемым? 

• Какие проблемы мешают команде выполнять взятые на себя обязательства? 

• Как улучшить взаимодействие с Product Owner’ом? 

• Какие ошибки совершает команда и почему? 

• Рассказываем, чем занимались в итерацию (плюсы, минусы, проблемы, решения). 

Артефакты в Scrum 

1. Product backlog: 

• Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным. 

• Требования составлены так, что очевидно и понятно какую ценность они представляют для пользователя. 

• Требования отсортированы по приоритетам, которые пересматриваются каждый спринт. 

2. Sprint Backlog — это обязательство команды: что они должны выполнить за ближайшие 2 недели. 

Каждое требование разделено на задачи: 

• Это список всех требований, которые нужно сделать в ближайший спринт. 

• В течение спринта, новые требования не могут появится в Sprint backlog. 

• Все требования должны быть разделены на задачи и оценены. 

3. Burndown Chart: 

• дословно «диаграмма сгорания»; 

• в качестве «сгорающих» элементов выступают человеко-часы или «идеальные единицы» (Story Points). 

• диаграмма обновляется каждый раз, когда завершается какая-либо задача. 

• инкремент продукта (Product increment) – ощутимый результат работы одного спринта. Например, внедрение новой функции на сайт, прототип мобильного приложения. Команда должна показать целевой аудитории, что она сделала за это время. Это нужно для получения обратной связи и планирования следующих задач по улучшению продукта. 

4. Scrum Artefacts Инкремент ( Increment) — это сумма завершенных во время cпринта элементов Бэклога Продукта и всех инкрементов предыдущих cпринтов. К концу спринта Инкремент должен быть «Готов», что подразумевает его соответствие критериям готовности Скрам-команды и готовность к использованию. Инкремент — это совокупность выполненных работ, которая поддерживает эмпирический̆ подход и которую можно инспектировать в конце спринта. Можно сказать, что это шаг на пути к видению или цели. Он должен быть готов к использованию, вне зависимости от положительного или отрицательного решения Product Owner о его выпуске. 

Результатом каждого Спринта является потенциально готовый к поставке Инкремент Продукта. Работа всех команд должна быть интегрирована до конца каждого Спринта – интеграция должна проводиться во время Спринта. Это позволяет: 

• поддерживать Фокус на Всем Продукте; 

• увеличивать Прозрачность и снижать риски, при этом у нас не возникает сюрпризов с неготовой работой; 

• повышать гибкость (или маневренность) за счет сокращения незавершенной работы (work in progress); 

• сохранять короткие циклы обратной связи, чтобы мы могли постоянно совершенствоваться. 

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

Инкрементирование – приращение результатов предыдущего этапа. 

To do — спринт бэклог. 

In progress — задачи, которые разрабатываются в данный момент. 

Ready for deploy — задачи, которые уже выполнены, но не представлены в тестовом окружении. 

QA — задачи, готовые к тестированию. 

PO/PM approving — готовые задачи проходят проверку project owner-ом или проектным менеджером. 

Done — выполненные (завершённые) задачи текущего спринта. 

Kanban имеет такие достоинства: 

• Гибкость планирования. Команда концентрируется только на текущей работе, приоритет задачи выставляется менеджером. 

• Высокое вовлечение команды в процесс разработки. Благодаря постоянным собраниям, прозрачности процессов и возможностям самоорганизации работники сплачиваются и проявляют искренний интерес. 

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

• Меньше узких мест. Лимиты РВП позволяют быстро находить узкие и проблемные места, которые появились из-за дефицита внимания, людей или навыков. 

• Наглядность. Когда все исполнители имеют доступ к данным, то узкие места легче заметить. Kanbanкоманды, помимо самих карточек, обычно используют два общих отчета: графики управления и совокупного потока. 

Канбан имеет и недостатки: 

• система плохо работает с командами численностью более 5 человек; • он не предназначен для долгосрочного планирования 

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

Особенности тестирования в спринтах

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

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

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

• Автоматизированное тестирование играет ключевую роль для гибкой разработки. Автотесты предупреждают возникновение множества проблем и помогают сэкономить время. 

• Тестировщики принимают активное участие в планировании текущих и следующих спринтов. 

• АРI-автоматизация также входит в компетенцию тестировщика. 

Вся тестовая документация 

1. Стратегия тестирования 

2. Тест план 3. Тест кейс 

4. Тест комплект 

5. Чек-лист 

6. Таблица прослеживаемости покрытия тестами (RTM) 

7. Тест отчёт 

8. Отчёт о дефекте (Bug report 

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

Цели создания Тест плана: 

• Согласование объёмов и стратегии тестирования различных составляющих тестируемого ПО с другими участниками проектной команды. 

• Приоритизация задач по тестированию. 

• Своевременное планирование ресурсозатрат на тестирование. 

• Учёт требуемых ресурсов (ПО, оборудование), необходимых для тестирования. 

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

Уровни детализации тест-плана: 

1. Мастер Тест-План (Master Plan or Master Test Plan) Мастер тест-план создаётся в двух случаях: 

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

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

• Общая информация о продукте, ссылки на документацию, баг-трекер и прочие проектные ресурсы. 

• Общие правила тестирования: требования к заводимым дефектам, условия принятия сборки на тестирование. 

• Критерии готовности продукта к выпуску, метрики качества. 

• Используемые инструменты и техники 

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

• Перечень областей тестирования с приоритетами; 

• Стратегия тестирования; 

• Проектные риски; 

• Ресурсы, необходимые для выполнения задач; 

• Проектный план (сроки готовности ключевых задач). 

Структура Тест плана: 

1. что надо тестировать (объект тестирования: система, приложение, оборудование); 

2. что будете тестировать (список функций и компонент тестируемой системы); 

3. как будете тестировать (стратегия тестирования – виды тестирования и их применение по отношению к тестируемому объекту); 

4. тестовые окружения, на которых необходимо проверять программный продукт; 

5. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, учёт зависимостей тестовых активностей от задач разработки и смежных групп); 

6. риски и стратегии по их разрешению; 

7. перечень согласовывающих лиц; 

8. принятые стандарты и шаблоны; 

9. критерии начала и окончания тестирования. 

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

Возможные результаты выполненного тест кейса: 

1. Положительный результат (passed), если фактический результат равен ожидаемому результату. 

2. Отрицательный результат (failed), если фактический результат не равен ожидаемому результату. В этом случае, найдена ошибка. 

3. Выполнение теста блокировано (blocked), если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка. 

Чего не должно быть в тест-кейсе: 

1. Зависимостей от других тест-кейсов; 

2. Нечеткой формулировки шагов или ожидаемого результата; 

3. Отсутствия необходимой для прохождения тест-кейса информации; 

4. Излишней детализации. 

Совокупность тест-кейсов (находящихся, как правило, в одном документе), которые проверяют какую-то определенную часть нашего интернет-проекта и/или определенный спек, называют тесткомплектом (test case suite). 

Атрибуты шапки тест-комплекта: 

• Author — автор тест-кейсов.

• Spec ID — номер (или иной уникальный ID) спека. 

• Priority — приоритет тест-комплекта (например, от 1 до 4), обычно соответствующий приоритету спека. 

• Producer — продюсер, написавший спек. 

• Developer — программист, пишущий код в соответствии со спеком. 

• Overview — вкратце рассказывается, чему посвящен этот тест-комплект. 

• GLOBAL SETUP and ADDITIONAL INFO — здесь мы говорим о повторяющихся вещах, которые будем использовать в более чем одном тест-кейсе, и вообще - о любой другой полезной информации для всего тест-комплекта. 

Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта. 

Зачем нужен чек-лист? 

• Не забыть требуемые тесты; 

• Для деления задач по уровню квалификации; 

• Для сохранения отчётности и результатов тестирования. 

Чек-лист содержит: 

• Список проверок (с требуемой степенью детализации). 

• Окружение проверки: o сборка, на которой проводилось тестирование; o тестовое окружение (если применимо); o информация о тестировщике. 

• Результат проверки. 

Правила составления чек-листов: 

• Один пункт – одна операция. Пункты чек-листа – это однозначные атомарные и полные операции. Например, добавление товара в корзину сайта и оплата заказа – две разные задачи. В списке проверок подобные операции оформлены отдельными пунктами: добавлен товар в корзину, оплата отправлена. 

• Пункты начинаются с существительного. Цель чек-листа – учесть все действия для наиболее полного покрытия тестами ПО, поэтому составляя пункты следует придерживаться унифицированной формы. Для понятного и однозначного представления пункты лучше начинать именовать с существительного – «Проверка», «Добавление», «Отправка» или глагола неопределенной формы – «Проверить», «Добавить», «Отправить». 

• Составление чек-листа по уровням детализации. Для удобства прохождения чек-листа лучше всего составлять тесты в том виде, который будет последовательным, исходя из логики использования функционала. В рамках раздела «Регистрация и Личный профиль»: регистрация на сайте, редактирование профиля. Раздел «Форма обратной связи»: валидация полей, отправка письма, доставка письма. 

Матрица прослеживаемости покрытия тестами - это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). 

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

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

• номер и описание задачи на разработку из таск трекера; • логический блок, к которому принадлежит задача (опционально); 

• атомарное требование или приемочный критерий (acceptance criteria); 

• приоритет; 

• номер и описание соответствующего тестового артефакта. 

Варианты связей в матрице трассируемости Привязка требования и тест-кейса может быть: 

• 1 к 1 (атомарное требование, которое покрывается одним тест-кейсом, данный тест-кейс покрывает только это требование); 

• 1 к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают только это требование); 

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

Можно выделить следующие этапы составления Traceability Matrix: 

1. В начале требования декомпозируются и подлежат приоритизации командой QA и\или product-owner. Результатом этапа становится структурированный и приоритизированный список всех требований по данной функциональности. 

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

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

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

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

Тест отчёт 

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

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

Можно выделить три группы целевых аудиторий: 

1. Технические пользователи — Test-manager. Для них приоритетно понимание хода тестирования, какие возникают проблемы, как они решаются, построение самого процесса тестирования, описание применяемых методов и технологий. 

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

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

Содержание отчёта 

• Информация о проекте. 

• Цель теста. 

• Сводка тестов: 

1) Количество выполненных тестовых случаев; 

2) Число пройденных тестовых случаев; 

3) Количество неудавшихся тестовых случаев; 

4) Пропущенные процентные ставки; 

5) Неверный процент тестовых случаев; 

6) Комментарии; 

• Дефекты: 

1)Общее количество обнаруженных ошибок; 

2) Статусы ошибок (открытые, закрытые, фиксированные и т. д.); 

3) Количество ошибок по каждому статусу (открытое, закрытое, фиксированное и т. д.); 

4) Серьезность и приоритетность поломки. 

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

Тест дизайн 

1. Что такое тест дизайн 

2. Цели тест дизайна 

3. Задачи тест дизайна 

4. Необходимые для тест дизайна скиллы 

5. Техники тест дизайна 

Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования. 

Test design [ISTQB Glossary of terms]: The process of transforming general testing objectives into tangible test conditions and test cases. 

Тест дизайн задачи:

• Проанализировать требования к продукту; 

• Оценить риски, возможные при использовании продукта; 

• Написать достаточное минимальное количество тестов; 

• Разграничить тесты на приемочные, критические, расширенные. 

Необходимые навыки: 

• Умение разделять систему на составляющие (делать декомпозицию). То есть, нужно уметь видеть систему как целое, но и уметь раскладывать ее на составные части. 

• Умение собирать и анализировать требования к продукту. Если нет формально описанных требований – нужно уметь их собирать у разработчиков, у аналитиков, у пользователей. 

• Умение расставлять приоритеты. Тест дизайнер должен уметь отличать более важное от менее важного и расставлять приоритеты тестирования. 

• Умение формулировать свои мысли (письменно и устно). Это умение важно для тестировщика в принципе. Тест дизайнеру оно здорово поможет при создании тест кейсов. 

• Знание техник тест дизайна. 

• Умение применять их на практике. 

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

Известные техники: 

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

1. Определить классы эквивалентности. Это главный шаг техники. От него во многом зависит эффективность её применения. 

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

3. Нужно выполнить тесты. На этом шаге мы выполняем тесты от каждого класса эквивалентности. 

2. Анализ граничных значений Это проверка значениями, находящимися на границах классах эквивалентности. 

Необходимо проверить каждую границу класса эквивалентности, с обеих сторон. 

Задача: Поле «пароль» принимает количество символов от 6 до 20 Какие будут граничные значения? 

Ответ: Для нижнего – 5, 6 Для верхнего- 20,21 

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

Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки. 

4. Причина / Следствие 

Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). 

Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона«, а затем, нажать кнопку "Добавить" - эта "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие". 

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

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

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

7. Таблица принятия решений 

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

8. Тестирование переходов состояний (state transition testing). Разработка тестов методом черного ящика, в котором сценарии тестирования строятся на основе выполнения корректных и некорректных переходов состояний. 

Всё о багах и багрепортинге 

1. Баг и багрепорт 

2. Алгоритм исследования бага 

3. Жизненный цикл бага 

4. Обзор основных трекинговых систем и особенности работы с ними 

Дефект (он же баг) – это несоответствие фактического результата выполнения программы ожидаемому результату. 

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

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

Атрибуты багрепорта: 

Базовые понятия сетевых технологий 

1. Архитектура «клиент-сервер» 

2. HTTP VS HTTPS 

3. HTTP request, HTTP response 

4. HTTP methods 

5. Cache, cookie 

6. IP, DNS 

«Клиент — сервер» (англ. client–server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на одной машине. 

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

Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер. Здесь всё как в жизни: клиент – это заказчик той или иной услуги, а сервер – поставщик услуг. Клиент и сервер физически представляют собой программы, например, типичным клиентом является браузер. В качестве сервера можно привести следующие примеры: все HTTP сервера (в частности Apache), MySQL сервер, локальный веб-сервер AMPPS или готовая сборка Denwer (последние два примера – это не просто сервера, а целый набор серверов) 

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

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

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай). 

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

1. строка запроса (Request Line) 

2. заголовки (Message Headers) Пустая строка (разделитель) 

3. тело сообщения (Entity Body) – необязательный параметр 

Строка запроса – указывает метод передачи, URL-адрес, к которому нужно обратиться и версию протокола HTTP. 

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

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

Запрос от браузера:

GET / HTTP/1.1 

Host: webgyry.info 

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0 

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 

Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 

Accept-Encoding: gzip, deflate 

Cookie: wp-settings 

Connection: keep-alive 

Ответ сервера: 

HTTP/1.1 200 OK 

Date: Sun, 10 Feb 2013 03:51:41 GMT 

Content-Type: text/html; charset=UTF-8 

Transfer-Encoding: chunked 

Connection: keep-alive 

Keep-Alive: timeout=5 

Server: Apache 

X-Pingback: //webgyry.info/xmlrpc.php 

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

GET 

Метод GET запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные. 

HEAD 

HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа. 

POST 

POST используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере. 

PUT 

PUT заменяет все текущие представления ресурса данными запроса. 

DELETE 

DELETE удаляет указанный ресурс. 

CONNECT 

CONNECT устанавливает "туннель" к серверу, определённому по ресурсу. 

OPTIONS 

OPTIONS используется для описания параметров соединения с ресурсом. 

TRACE 

TRACE выполняет вызов возвращаемого тестового сообщения с ресурса. 

PATCH 

PATCH используется для частичного изменения ресурса. 

Cache, cookie 

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

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

IP, DNS 

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

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

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

Версии адресов IP: IPv4 и IPv6 

IPv – это версия интернет протокола (internet protocol version), а в наши дни используют именно две версии IPv4 и IPv6, одна из них была внедрена ранее и является привычнее и возможно удобнее, но вот вторая открывает больше возможностей для работы и развития сетей. 

IPv4 (Internet Protocol v. 4) — адрес, записанный в 32-битном формате. Имеет вид четырех 8-битных чисел (минимум 0, максимум 255), которые разделены друг от друга точками. Пример: 172.16.255.2. IPv6 (Internet Protocol v. 6) — адрес, записанный в 128-битном формате. Имеет вид 8 групп, в каждой из которых находится по 4 шестнадцатеричные цифры, отделенные друг от друга двоеточиями. При этом допустимо опускать ведущие нулевые группы, которые идут подряд, и заменять их двойным двоеточием, однако в одном адресе возможно только одно такое упрощение. Пример: 2001:0da8:11a4:08d6:1f84:8a3e:07a1:655d. 

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

Маршрутизатор (дома обычно эту функцию представляет Wi Fi роутер) является частью как минимум двух сетей, об этом свидетельствует его подключение к внешней сети и к домашней сети, в которой он и раздаёт автоматические внутренние IP адреса. 

А вот статистический адрес – это адрес, привязанный к компьютеру, если произвести настройки устройства самостоятельно или провайдером. Вы как их клиент совершенно в автоматическом режиме получаете свой IP адрес. Такие IP адреса в отличие от динамических, остаются неизменными при переподключении к интернету. Часто статистический адреса называют постоянными или реальными адресами, что так же верно. 

DNS (англ. Domain Name System «система доменных имён») — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись). 

Основные понятия HTML, CSS и SQL 

1. Что такое HTML, структура html-страницы 

2. Основные тэги html 

3. Что такое CSS, как подключать стили 

4. Использование CSS-стилей в HTML 

5. Что такое базы данных? 

6. Базовые примеры запросов 

Тег <html > является контейнером для всего содержимого страницы. Другими словами, весь код страницы находится между открывающимся <html> и закрывающимся </html >. 

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

Тег <body> - это основное тело нашего документа. Все, что находится между тегами <body> и </body> будет выводиться браузером на экран монитора. 

<!DOCTYPE...> - Этот тег определяет тип документа и версию HTML. 

Тег <title> используется внутри тега <head> чтобы указать название документа.<!--EndFragment--> </body> </html>

<h1> - Этот тег представляет заголовок. 

<p> - Этот тег представляет абзац. 

<!--Комментарий -->

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

Но встречается и такой метод подключения как: 

CSS может быть применён к HTML или XHTML с использованием трёх методов: связывание (linking), внедрение (embedding) и встраивание (inlining). 

link элемент в примере состоит из трёх атрибутов. Первый, rel, сообщает браузеру тип и цель ссылки. Второй, type, сообщает браузеру, какой MIME-тип файла, который мы подключаем. И наконец, третий, href, сообщает браузеру URL, чтобы найти файл. В этом примере URL является относительным, но он также может быть абсолютным. 

«style.css» с одним правилом содержит только текст следующего содержания: 

p { 

font-weight: bold; 

} 

Это говорит браузеру, что текст в параграфе (<р>) должен быть показан как полужирный. 

База данных - набор сведений, хранящихся некоторым упорядоченным способом. Можно сравнить базу данных со шкафом, в котором хранятся документы. Иными словами, база данных - это хранилище данных. Сами по себе базы данных не представляли бы интереса, если бы не было систем управления базами данных (СУБД). 

Система управления базами данных - это совокупность языковых и программных средств, которая осуществляет доступ к данным, позволяет их создавать, менять и удалять, обеспечивает безопасность данных и т.д. В общем СУБД - это система, позволяющая создавать базы данных и манипулировать сведениями из них. А осуществляет этот доступ к данным СУБД посредством специального языка - SQL. 

SQL - язык структурированных запросов, основной задачей которого является предоставление простого способа считывания и записи информации в базу данных. Итак, простейшая схема работы с базой данных выглядит примерно так: 

Команды для создания запросов: 

1. SELECT 

Самый простая и часто употребляемая команда, которая позволяет получить от сервера практически любую информацию из таблиц. Её синтаксис прост: 

SELECT [имя_поля] FROM имя_таблицы 

Если дословно: ВЫБРАТЬ поле ИЗ таблицы. Имена полей необходимо указывать через запятую или использовать * для вывода всех полей. 

2. WHERE 

WHERE поле условие значение 

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

SELECT [имя_поля] FROM имя_таблицы WHERE поле условие значение 

В запросе можно задавать следующие условия: 

• сравнение текста; 

• сравнение численных значений; 

• логические операции AND (и), OR (или) и NOT (отрицание). 

3. ORDER BY 

ORDER BY [BINARY] имя_поля [DESC] 

Выражение в запросе позволяет отсортировать выводимые строки по заданным полям. При этом оно не влияет на получаемый результат, а только упорядочивает его вывод. Если используется выражение WHERE, то ORDER BY должно быть после него. 

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

Пример: 

SELECT name FROM users WHERE status = 1 ORDER BY access DESC; 

Инструменты повседневной работы 

1. Chrome Dev Tools 

2. Google Chrome Plugins 

3. Postman 

4. Selenium IDE 

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

Как открыть консоль в браузере Chrome: 

— клавиша F12; 

— нажав одновременно клавиши Ctrl + Shift + I; 

— ПКМ по элементу страницы –> Просмотреть код; 

— меню браузера –> Дополнительные Инструменты –> Инструменты Разработчика. 

Итого в ней есть 8 вкладок, каждая из которых отображает определенные данные: 

1 – Elements (содержит весь html/css код страницы и позволяет выбрать элементы для исследования, а также редактировать их) 

3 – Sources (позволяет наблюдать источники (файлы) из которых была отрендерена страница). Панель ресурсов позволяет просматривать исходники сайтов, в том числе IndexedDB, базы данных Web SQL, куки, и ресурсов кэша приложений. Также можно быстро проверить визуальные ресурсы, в том числе изображений, шрифтов и стилей. 

4 – Network (отслеживает время исполнения определенных запросов и сами запросы). 

5 – Performance (измеряет время загрузки страницы). 

6 – Memory (позволяет создавать JavaScript, профили CPU). 

Данная панель дает возможность профилировать время исполнения и использование памяти веб приложением или страницей, таким образом помогая понять где именно тратится много ресурсов и как можно оптимизировать код. CPU profiler предоставляет информацию по времени, затраченному на выполнение Javascript. Heap profiler отображает распределение памяти. JavaScript profile детализирует, куда именно ушло время при выполнении скриптов. 

7 – Application (позволяет просмотреть определенные сохраненные данные). 

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

2. Screencastify. Удобный и понятный инструмент для записи видео. Позволяет записывать как текущую вкладку так и весь рабочий стол, сохраняет в приемлемом по размеру формате. 

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

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

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

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

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

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

Коллекция — отправная точка для нового API. Можно рассматривать коллекцию, как файл проекта. Коллекция объединяет в себе все связанные запросы. 

Папка — используется для объединения запросов в одну группу внутри коллекции. К примеру, вы можете создать папку для первой версии своего API — "v1", а внутри сгруппировать запросы по смыслу выполняемых действий — "Order & Checkout", "User profile" и т. п. 

Запрос — основная составляющая коллекции, то ради чего все и затевалось. Запрос создается в конструкторе. Конструктор запросов - это главное пространство, с которым вам придётся работать. Postman умеет выполнять запросы с помощью всех стандартных HTTP методов, все параметры запроса под вашим контролем. Вы с лёгкостью можете поменять или добавить необходимые вам заголовки, cookie, и тело запроса. У запроса есть свои скрипты. 

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

Основные преимущества Selenium: 

• Selenium бесплатный и свободный в использовании инструмент. Вам не нужно платить за лицензию для его использования.

• Кросс-браузерная совместимость (Firefox, Chrome, Internet Explorer, Safari ). 

• Поддержка большого количества языков программирования (Java, C#, Ruby, Python, Pearl). 

• Совместимость со всеми основными платформами (Windows, Mac OS, Linux). 

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

• Возможность автоматизации скриптов. 

• Поддержка распределения тестов. 

• Регулярные и свежие усовершенствования библиотек. 

Selenium IDE - расширение браузера , которое позволяет записывать и воспроизводить действия пользователя в браузере. 

Будет удобен, если Вы хотите сделать: 

• небольшой сценарий для быстрого автоматизированного воспроизведения бага; 

• вспомогательный скрипт для выполнения отдельных рутинных действий при ручном тестировании.