Тестировщик с нуля

Тестировщик с нуля.
Автор: Artsiom Rusau
https://www.youtube.com/channel/UCiDbqnoBNx3pRHyYAgrnwBg - ютуб канал
https://t.me/qachanellflood - телеграм канал
https://www.instagram.com/rusau.qalife/ - инстаграм
2021 год
Оглавление
Урок 1. С чего начать? Как стать тестировщиком? ..............................................................................3
Урок 2. Принципы тестирования. Что такое парадокс пестицида? .................................................... 5
Урок 3. QA, QC, тестирование. Верификация и валидация. ............................................................... 7
Урок 4. Уровни тестирования. "Позитивность" тестов. ......................................................................10
Урок 5. Что такое регрессионное тестирование и smoke тестирование? ........................................ 13
Урок 6. Нефункциональное тестирование. Черный, белый и серый ящик. ..................................... 15
Урок 7. Моделирование ПО. Водопадная, итерационная и V-модель. ............................................ 19
Урок 8. Тестовая документация. Чек-лист и тест-кейс. .....................................................................22
Урок 9. Техники тест-дизайна. Классы эквивалентности и граничные значения. ........................... 26
Урок 10. Отчет о дефекте (баг-репорт) в Jira. Severity и Priority. ЖЦ дефекта. ............................... 28
Урок 11. Клиент-серверная архитектура. Веб-сайт, веб-приложение и веб-сервис. ...................... 37
Урок 12. HTTP-протокол для чайников. Ошибка 404. Модель TCP/IP. Методы HTTP.................... 40
Урок 13. URL адрес. Что такое IP адрес и маска подсети? DNS сервер. Кэш и куки...................... 46
Урок 14. Что такое DevTools для тестировщика? Инструменты разработчика Chrome. ................ 50
Урок 15. Основы HTML и CSS для тестировщика. .............................................................................55
Урок 16. Тестирование полей ввода и тестирование веб-форм. ..................................................... 57
Урок 17. Тестирование веб-сервисов. SOAP и XML, REST и JSON для тестировщика. ................ 65
Урок 18. Как тестировать API с помощью Postman, SoapUI. Отличия GET и POST. ...................... 71
Урок 19. Базы данных для тестировщиков и QA. ...............................................................................75
Урок 20. SQL для тестировщика. Как создать таблицы в MySQL для QA. ...................................... 79
Урок 21. Запросы SELECT в SQL/MySQL для тестировщика. .......................................................... 82
Урок 22. Запросы Join в SQL/MySQL на примерах для тестировщика............................................. 87
Урок 23. Как тестировать мобильные приложения? Тестировщик мобильных приложений. ........ 91
Урок 24. Android Studio (SDK), эмуляторы для тестировщика мобильных приложений. ................ 97
Урок 25. Особенности тестирования мобильных приложений. ........................................................ 98
Урок 26. Как тестировать требования? Тестирование требований. ............................................... 102
Урок 27. Agile и Scrum для тестировщика. Гибкая методология разработки................................. 107
Урок 1. С чего начать? Как стать тестировщиком?
https://www.youtube.com/watch?v=CrfRUS2oudE
Сегодня я хочу анонсировать новый бесплатный курс по тестированию программного обеспечения. Для
всех тех, кто интересуется этой темой и решил в дальнейшем связать свою жизнь с обеспечением качества,
думаю, что стоит начать с того, что же такое тестирование.
Моё любимое определение: тестирование - это поиск несоответствий между фактическим и
ожидаемым результатом. Т.е., если заказчик хочет видеть определённые иконки на странице - это будет
ожидаемый результат. А уже как это будет реализовано в нашем продукте - это результат фактический. Если
они отличаются между собой, то это можно отнести к дефекту, поиском которого и занимается тестер. Роль
тестировщика на проекте, как по мне, является одной из самых ключевых. Любая крупная IT компания не может
обойтись без этого человечка на проекте.
Жизненный цикл ПО (SDLC- Software Development LifeCycle).
Давайте немного поговорим о том, какие основные этапы есть в жизненном цикле программного
обеспечения, либо как еще его называют SDLC (software development lifecycle). Есть несколько моделей такого
жизненного цикла.
Первый этап - инициация (идея). Т.е. некоторый бизнес понимает, что у его пользователя (потребителя)
есть некоторая потребность в продукте, этот продукт действительно выстрелит. Он собирает некоторые данные
по тому, что он хочет всё-таки показать своему пользователю, и у него появляется идея.
Второй этап – разработка и сбор требований. С этой идеей он приходит в IT компанию и, если возникает
договоренность о том, что этот продукт будут разрабатывать в этой компании, к делу подключаются бизнесаналитики и начинают собирать требования. Они общаются с заказчиком, с конечным пользователем,
формируют пул требований, которые нужно будет реализовать в конечном продукте.
Третий этап – дизайн. Дальше уже подключаются web-дизайнеры, которые на основании требований
рисуют (если мы говорим о web-приложении), к примеру, мокапы, либо шаблоны того сайта, который хочет
видеть наш заказчик.
Четвёртый этап – разработка. Если у заказчика нет вопросов к дизайну, тогда подключаются
разработчики. Начинается непосредственно разработка.
Пятый этап – тестирование. Разработчики пишут код, который в дальнейшем попадает на тестирование
к тестировщику.
Шестой этап – ввод в эксплуатацию. После того, как продукт протестирован, он передается в
эксплуатацию конечного пользователя.
Седьмой этап – вывод из эксплуатации. Если бизнес понимает, что этот продукт больше не
востребован, либо придумывает что-то новенькое и забивает на поддержку старого продукта, происходит вывод
из эксплуатации.
Давайте подумаем, на каком из этапов подключается тестировщик? Конечно, было бы логично
предположить, что этот этап называется тестирование. Но на самом деле это не так. Тестировщик подключается
к тестированию уже на этапе разработки и сбора требований. В чем же это заключается? Давайте поговорим о
каждом из этапов. Например, на этапе разработки и сбора требований тестировщик тестирует сами требования
на предмет их соответствия их основным свойствам, насколько они правильно написаны, не противоречат ли
они между собой, полные ли они. Если всё ок, то на этапе разработки дизайна тестировщику можно тестировать
как сам шаблон, на предмет соответствия требованиям, так и юзабилити тестирование. Т.е. насколько
пользователю будет удобно пользоваться нашим продуктом. На этапе разработки тестируется уже
непосредственно то, что написали наши разработчики (developers). Т.е. здесь можно тестировать User Interface
(то, что мы видим на экране, когда открываем тот или иной сайт). Также можно тестировать и то, что находится
под капотом, т.е. то, что не может видеть рядовой пользователь. Что касается ввода в эксплуатацию, то здесь
может проводиться приёмочное тестирование, Альфа, Бета-тестирование.
Обязанности тестировщика.
1) разработка тестовой документации (тест-кейсы, чек-листы и др.); 2) проведение тестов, если по итогу
находим отличие ожидаемого результата от фактического, то 3) оформление баг-репорта. Баг-репорт
отправляется к разработчику - фикс бага и возврат на тест - повторное тестирование.
Урок 2. Принципы тестирования. Что такое парадокс пестицида?
https://www.youtube.com/watch?v=vVr2FqiTC_g
Сегодня мы узнаем о 7 принципах тестирования, которые должен знать каждый уважающий себя тестер.
Принцип №1 - тестирование показывает наличие дефектов. Тестирование может показать, что в
продукте существуют дефекты, но не сигнализирует о том, что дефектов не существует вообще. Т.е. в процессе
тестирования мы снижаем вероятность того, что в продукте остались дефекты. Но, даже если мы их вообще не
обнаружили, то мы не можем говорить о том, что их нет. Из моей практики, баги в продукте есть всегда.
Принцип №2 - исчерпывающее тестирование невозможно. Протестировать абсолютно всё в продукте
невозможно. И даже если вам кажется обратное, то вы потратите огромное количество времени на это, а как
известно - время деньги. А как тогда быть уверенным в том, что продукт работает корректно? Всегда есть риски
и приоритеты. Для того, чтобы минимизировать риски, есть специальные техники тест-дизайна, которые
помогают тестерам проектировать свои тесты так, чтобы с минимальными усилиями покрыть как можно больше
тестовых случаев и функциональностей.
Принцип №3 - это раннее тестирование. Т.е. тестовые активности должны начинаться как можно раньше
и всегда преследовать определенные цели. В данном случае экономия средств заказчика.
Принцип №4 - скопление дефектов. Он гласит так: в небольшом количестве модулей сокрыто большое
количество дефектов. И если мы вспомним с вами правило Парето, то оно применимо и к данному принципу:
80% дефектов находится в 20% функций. Т.е. мы должны понимать, что наибольшее количество дефектов
сконцентрировано не во всём приложение, а в какой-то определенной из его функциональностей, поэтому
тестеры должны распределять свои усилия пропорционально. Например, если он понимает, что в модуле логина
пользователя в систему всегда происходят какие-то физические дефекты, то он должен больше время
сконцентрировать на нахождение и устранение этих дефектов именно в этой функциональности.
Принцип №5 - парадокс пестицида. Прогоняя одни и те же тесты вновь и вновь, вы столкнетесь с тем,
что они находят всё меньше новых ошибок, поскольку системы эволюционируют. Многие из ранее найденных
дефектов исправляют и старые тесты больше не срабатывают. Чтобы преодолеть этот парадокс, необходимо
периодически вносить изменения в используемые наборы тестов, корректировать их так, чтобы они отвечали
новому состоянию системы и позволяли находить как можно большее количество дефектов. Для этого также
нужно постоянно изучать новые методы тестирования и внедрять их свою работу. Для преодоления данного
препятствия можно давать прогонять тесты другим участникам команды, либо же производить ротацию кадров,
чтобы разные тестировщики в разное время тестировали одну и ту же функциональность. Кстати, вопрос по
минимизации данного риска часто задают на собеседовании, так что обязательно запомните ответ на него.
Почему же этот принцип называется парадокс пестицида? Всё очень просто. Проведите аналогию с
применением какого-то химиката против насекомых, либо же каких-то сорняков. Если их постоянно травить
одним и тем же инсектицидом или пестицидом, то у них возникает привыкание, они адаптируются и меньшее
количество живности вымирает, либо уничтожается под действием того или иного токсиканта. Также работает
принцип пестицида для тестирования.
Принцип №6 - тестирование зависит от контекста. Выбор методологии, техники или типа тестирования
будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицины
требует более тщательной проверки, чем компьютерная игра. Или же сайт с большей посещаемостью должен
пройти через серьёзное тестирование производительности, чтобы показать возможность работы в условиях
высокой нагрузки. Поэтому тестировщик всегда должен ответственно подходить к выбору той среды, в которой
он будет тестировать, к выбору той документации, которую будет тестировать. Например, если продукт
сложный, то лучше выбрать тест-кейсы, а не чек-листы.
Принцип №7 - это заблуждение об отсутствии ошибок. Каждому тестировщику не стоит полагать, что
если тестирование не обнаружило дефект, то программа готова к релизу. Нахождение и исправление дефектов
будут не важны, если система окажется неудобна в использовании и не будет удовлетворять нуждам
пользователя.
Урок 3. QA, QC, тестирование. Верификация и валидация.
https://www.youtube.com/watch?v=f3Yjzjsh0aM
Сегодня речь пойдет про развитие таких понятий, как Quality Assurance, Quality Control and Testing, а также
о верификации и валидации. Стоит отметить, что это одни из самых любимых вопросов на собеседовании.
Начнём с того, что многие до сих пор путают эти понятия, что, в общем-то, и неудивительно, так как в странах
СНГ они могут использоваться для описания одних и тех же процессов, а также для поиска соискателей и
специалистов. Я думаю всем понятно, что testing является частью Quality Control, а уже Quality Control является
частью Quality Assurance. Давайте теперь разберемся в отличии каждого из этих понятий.
Testing.
Testing, либо тестирование - это самый нижний и первый уровень, который представляет собой проверку
создаваемого программного продукта на соответствие требованиям к этому продукту. По факту - это рутинная
работа. Т.е. тебе выдали какой-то перечень функциональности, ты их проверил, нашёл какие-то дефекты,
описал их, предоставил разработчику, разработчик их пофиксил, предоставил тебе исправленные баги на
проверку. В принципе, на этом работа заканчивается. Именно эта рутинная работа помогает выявлять дефекты
на уже созданном программном обеспечении, но не более того. Это не значит, что тестирование - это очень
просто. По сути, тестирование - это база и минимум, без которого выпускать продукт нельзя. Основная задача
тестирования - это выявить и зафиксировать дефекты. Этой работой на проекте занимаются начинающие
тестировщики, т.е. junior.
Quality Control.
Второй этап - это Quality Control (контроль качества). Он включает в себя тестирование, но не
ограничивается только им. Quality Control обеспечивает не только проверку продукта на соответствие
требованиям, но и соответствие заранее согласованному уровню качества продукта и готовность к выпуску
продукта в Production. Основная задача контроля качества - это предоставить объективную картину того, что
происходит с качеством продукта на разных этапах разработки. По сути, этой работой занимается middle, т.е.
специалист уже среднего звена с некоторым опытом работы.
Quality Assurance.
И последний, самый всеобъемлющий этап - это, конечно же, Quality Assurance (обеспечение качества).
Это третий уровень, куда доходят далеко не все специалисты. Обычно это лиды, либо менеджеры и этот уровень
включает в себя мероприятия на всех этапах разработки и, по-хорошему, даже использование продукта. Для
обеспечения согласованного уровня качества продукта - это уже проактивная работа. Что это значит? Основная
задача обеспечения качества - это выстроить систему, которая будет превентивно работать на качество
продукта, т.е. предупреждать какие-то дефекты, либо же наладить процесс так, чтобы эти дефекты были
найдены как можно раньше, еще до того, как продукт попадёт к разработчику. Огромное поле для фантазии.
Наша основная задача - это минимизировать количество найденных дефектов в зависимости от специфики
проекта. Сюда может включаться тестирование документации, ревью кода на соответствие стандартам
внедрения каких-то методик по работе с качеством, коммуникационн активности и методики, и так далее.
С первого взгляда перечисленное выше может показаться сложным и непонятным. А давайте разберём
всё это на примере: конструирование машины. С помощью тестирования и контроля качества мы можем
определить: работают ли все детали и сама машина в целом так, как мы ожидаем, из правильных ли материалов
она сделана, с применением нужных методик и инструментов или нет. Т.е. подразумевается, что объект уже
существует и готов к проверке задачи. Quality Assurance же является обеспечение соответствия всех этапов
конструирования нашей машины, определенный стандарт качества, начиная с планирования и создания
чертежей, и заканчивая сборкой уже готового автомобиля. Т.е. качеству объекта уделяется внимание еще до
того, как сам объект был создан.
Верификация и валидация.
Отличие процессов верификации и валидации, по моей практике, - это один из самых распространенных
вопросов на собеседовании, у меня наверное на 50% собеседование спрашивали вообще об этих процессах и
просили привести примеры, которые были бы максимально приближены к реальной действительности.
Процесс верификации. Давайте поговорим о ключевых особенностях данного процесса. Что же это
такое? Это статическая практика проверки документов, дизайна, архитектуры, кода и так далее. Это значит, что
процесс верификации проходит без запуска кода. Верификация всегда отвечает на вопрос "делаем ли мы
продукт правильно?". Эта проверка связана с тем, что мы убеждаемся в том, что система хорошо
спроектирована и безошибочно. Верификация всегда происходит ДО валидации.
Процесс валидации - это процесс оценки конечного продукта, когда необходимо проверить:
соответствует ли программное обеспечение ожиданиям и требованиям клиента. Это динамический процесс, в
отличии от верификации. Этот процесс всегда включает в себя запуск кода программы и отвечает на вопрос
"делаем ли мы правильный продукт?". Процесс валидации всегда происходит ПОСЛЕ верификации, поэтому на
этапе валидации можно уловить ошибки, которые процесс верификации не позволил нам найти.
Что же касается практики, отличия верификации и валидации имеют большое значение. Заказчика
интересует в первую очередь validation, т.е. удовлетворение собственных требований, а исполнителя, т.е. нас,
нашу компанию, волнует не только соблюдение всех норм качества, т.е. верификация реализации продукта, но
и соответствие всех особенностей продукта желаниям заказчика, поэтому тестировщик должен обязательно в
своей практике использовать И процесс верификации И процесс валидации.
Что же касается примеров, возвращаясь к нашей машине, которую мы описывали ранее, здесь
верификация покажет нам, выполнен ли автомобиль из соответствующих спецификации материалов, подогнаны
ли детали по высоте, установлен ли заявленный двигатель, что был прописан в нашей спеке. Валидация
покажет, сможет ли автомобилем пользоваться невысокий человек, вообще поедет ли автомобиль, удобно ли
выполнены сиденья, поместится ли в багажнике огромный чемодан, т.е. насколько наш продукт будет отвечать
нуждам нашего пользователя. Ещё один пример: программное обеспечение. У вас есть форма для логина в
систему, в которой есть поля. Согласно спеке размер полей строго установлен. Вы проверяете так ли это,
примерно размер поля 16 пикселей и, если это так, то всё ок. Это процесс верификации. Но вот если вы оставите
поле с логином пустым и нажмёте кнопку войти в систему, то покажут ошибку, т.е. работает валидация, так как
это поле должно быть обязательно заполнено. Простой вывод: при верификации проверяется НАЛИЧИЕ чегонибудь, при валидации - РАБОТОСПОСОБНОСТЬ чего-нибудь.
Урок 4. Уровни тестирования. "Позитивность" тестов.
https://www.youtube.com/watch?v=PpJC5WQ1XS8
Классификация тестирования. Существует огромное количество вариаций этой систематики, поэтому не
удивляйтесь, если в разных источниках вы найдете отличия. Давайте начнём с типизации тестирования по
уровням, на которых оно проводится. Их всего 3. Первое - это компонентное (модульное или Юнит
тестирование). В разных источниках оно может называться по-другому. Второй уровень - это интеграционное
тестирование. И третье - это системное тестирование. Из названия этих типов тестирования можно
предположить, что тестируют на каждом из этих уровней. На компонентном уровне происходит тестирование
отдельных модулей. Например, если мы говорим об интернет-магазине, то это будет тестирование корзины или
тестирование оплаты заказа. На интеграционном происходит проверка взаимодействия этих модулей. А на
системном - полная проверка приложения.
Классификация тестирования по уровням.
Unit тестирование (компонентное, модульное) - занимается разработчик программного кода, так как
именно Unit testing позволяет протестировать отдельные компоненты исходного кода программы. На примере
интернет-магазина к таким модулям можно отнести страницу авторизации, поиск товара, перемещение его в
корзину, оплата заказа.
Интеграционное тестирование. Под ним понимают тестинг части системы, состоящей из двух и более
модулей, например, как мы можем со страницы корзины произвести оплату посредством платежной системы.
Существует две разновидности интеграционного тестирования. Давайте поговорим о каждой из них:
1. Тестирование интеграции компонентов, т.е. как отдельные модули одного приложения
взаимодействуют между собой.
2. Системное интеграционное тестирование, под которым понимают тестирование
взаимодействия между всеми компонентами системы, либо взаимодействия разных систем
между собой, либо тестирование интерфейсов с помощью которых взаимодействуют системы.
Именно об интерфейсах я хочу поговорить более подробно. Существует три вида интерфейсов:
●
Интерфейс программирования приложений, либо API. Этот набор методов можно
использовать для доступа к функциональности другой программы. Например, API используется
для того, чтобы наладить какую-то платежную систему для того или иного ресурса. Например,
интернет-магазин, для него разработчик налаживает интеграцию с системой посредством
данного интерфейса. Ему не нужно разрабатывать свою платежную систему, таких систем
существует огромное количество. Самые известные из них это API взаимодействия с
социальными сетями той же в Facebook или ВКонтакте.
●
●
CLI (command line interface), интерфейс командной строки, там, где инструкция компьютеру
даётся путем ввода с клавиатуры текстовых строк, по-простому - это обычная командная строка
в системе Windows.
GUI (graphical User Interface). В нём программные функции предоставляются графическими
элементами экрана. Например, это то, что мы видим в окне браузера, когда открываем страницу
в интернете.
Системное тестирование. Выполняется на полной интегрированной системе с целью проверки
соответствия системы исходным требованиям. Например, если мы говорим об интернет-магазине, то здесь мы
будем смотреть как вообще все модули, которые были разработаны для этого магазина, работают между собой.
Можно ли пройтись по всему Business Flow данного приложения, т.е. можем ли мы зарегистрироваться, найти
товар, положить его в корзину, оплатить наш заказ, отслеживать этот товар в пути. Т.е. мы тестируем всё
приложение целиком.
Приёмочное тестирование. Конечно же, говоря об уровнях тестирования, стоит также отметить
приёмочное тестирование. Пожалуй, я внесу его в эту же классификацию. Что же представляет собой
приемочное тестирование? Это вид тестирования, проводимый на этапе сдачи готового продукта, либо же какойто его готовой части заказчику. Целью приемочного тестирования является определение готовности продукта и
достигается это путем прохода тестовых сценариев, случаев, которые построены на основе спека и требований
к нашему продукту. По сути это финальный этап тестирования продукта перед его релизом. Обычно тестируется
только основной функционал, который не требует тщательных проверок. Существует несколько типов
приемочного тестирования, которые тоже необходимо знать. Давайте поговорим о них более подробно:
1. Пользовательское приемочное тестирование (UAT, User acceptance testing). Привыкайте
называть все типы тестирования на английском языке, так как в дальнейшем вы будете
сталкиваться с английскими аббревиатурами. Пользовательское приемочное тестирование
проводится пользователями конечного продукта. Например, когда мы знаем, что наш продукт готов
к релизу, тогда мы можем собрать некоторую группу конечных пользователей, которая его
протестируем, посмотреть, действительно ли данный продукт соответствует их ожиданиям. Они
дадут нам какое-то заключение, мы исправим все критичные баги и сможем спокойно выпустить
наш продукт.
2. Эксплуатационное тестирование. Обычно данное тестирование выполняется либо
пользователями, либо же администратором в среде, которая имитирует реальные условия
рабочего окружения. На этом этапе проводится проверка тестирования резервного копирования
или, позже, аварийного восстановления системы, также его безопасность.
3. Тестирование на соответствие контракту. Данное тестирование представляет собой
проверку на соответствие спека какому-то другому документу, нормативному акту. Например, в
стране существует ГОСТ, который определяет, как наш продукт должен соответствовать данному
нормативному правовому акту, т.е. определяет его основные ключевые особенности. Мы должны
обязательно разрабатывать продукт в полном соответствии к этому нормативному акту. Либо же
один из самых известных документов - определяет требования к защите пользовательских данных.
Если мы не учтем данные требования при разработке продукта, то можем получить огромные
штрафы в дальнейшем.
4. Альфа-тестирование - эксплуатационное тестирование, проводится на стороне разработчика,
но не в рамках нашей компании.
5. Бета-тестирование проводится на внешней стороне и без участия разработчиков. Обычно
бета-тестирование проводится небольшой группой пользователей, чтобы получить их отзыв до
выхода продукта на рынок, это известная практика для компьютерных игр. Я думаю что те, кто из
вас является заядлым геймером, знают о таком тестировании. Т.е. заказчик выбирает некую
ключевую группу пользователей и выпускает для них версию продукта, на основании их фидбека
будет проводиться фикс каких-то критичных багов, либо же мы будем просто понимать, что продукт
соответствует их ожиданиям и его можно уже выпускать.
Классификация тестирования по позитивности.
Также сегодня хотелось бы уделить небольшое внимание вопросу классификации тестирования по
позитивности тестовых сценариев. Логично предположить, что таких видов тестирования будет два. Позитивное
и негативное тестирование.
Позитивное тестирование - это такое тестирование, когда применяются сценарии, которые
соответствуют нормальному ожидаемому поведению системы. С его помощью можно определить, что система
делает то, для чего и была создана. Например, если мы возьмём калькулятор, то при сложении 2+2 мы получим
4. Это будет позитивный тест.
Негативное тестирование. Тестирование в рамках которого применяются сценарии, которые
соответствуют внештатному поведению системы. Например, это могут быть какие-то исключительные ситуации
или неверные данные. На примере нашего калькулятора это может быть деление на ноль, т.е. мы заведомо
знаем что делить на 0 нельзя. Т.е. мы должны получить какое-то сообщение об ошибке.
Многие начинающие тестировщики заблуждаются, что сначала нужно проводить негативное
тестирование, пытаются сломать систему. На самом деле это далеко не так. В первую очередь выполняется
позитивный тест, особенно в режиме ограниченного времени. А время для тестирования всегда ограничено.
Просто представьте, каково будет заказчику, если вы направите все усилия на выполнении негативных тестов,
но не проверите основные функциональности и их работу заявленным требованиям и передадите такой продукт
заказчику. Представьте, какова будет его реакция, когда он не сможет попросту залогиниться в систему,
используя валидные данные. А вы в свою очередь проверяли только ввод 9999 символов в строку логин.
Урок 5. Что такое регрессионное тестирование и smoke тестирование?
https://www.youtube.com/watch?v=H158MGHtWKg
Классификация тестирования. Сегодняшнюю лекцию мы начнем с типов тестов по степени важности
тестируемых функций. Всего их три. Это smoke testing, тест критического пути и расширенный тест.
Классификация тестирования по степени важности тестируемых функций.
Smoke testing (дымное, дымовое). Проводится на начальном этапе, например после нового билда. Это
некая промежуточная версия нашего продукта. Направлено на проверку готовности разработанного продукта к
проведению расширенного тестирования и определение общего состояния качества продукта. Обычно это
короткий цикл тестов, либо же вообще один тест, который подтверждает, либо отрицает факт того, что
приложение стартует, либо выполняет свои основные функции. На примере уже полюбившегося нам интернетмагазина, smoke тестирование представляет собой один тест-кейс, когда мы логинимся в систему, ищем
необходимый нам товар, добавляем его в корзину производим оплату, подтверждаем и получаем наш заказ. Т.е.
все вот эти вот шаги можно смело вносить в один тестовый случай. Если он будет проходить, т.е. ожидаемый и
фактический результат будут одинаковыми - получаем наш товар, то smoke тестирование считается успешным.
Для smoke теста есть только два варианта развития событий. Мы можем сказать либо да, либо нет. В случае,
если мы говорим нет, то дальнейшее тестирование не проводится, мы направляем баг на разработчика и
останавливаем процесс тестирования полностью. Стоит отметить, что smoke тесты должны быть быстрыми и
легковесными для того, чтобы их можно было запускать очень часто. Забавный факт, как вообще появилось
такое название, как smoke тестирование? Одна версия про печников, т.е. когда печники заканчивали
строительство той или иной печи, то они зажигали в ней огонь и, если из некоторых отверстий, которые по сути
должны были быть цельными, выходил дым, то тогда люди понимали, что был нарушен какой-то процесс
строительства, либо конструирование данной печи. А вторая версия связана со схемотехниками. Т.е. когда
запускали какой-либо станок, либо суперкомпьютер, если платы начинали дымится после какой-то высокой
нагрузки, то люди понимали, что был нарушен какой-то технологический процесс и, опять же, нужно что-то
исправлять. Поэтому за этим типом тестирования и закрепилось такое название, как smoke, либо дымное
тестирование.
Тест критического пути (critical path test). Основной тип тестовых испытаний, во время которого
значимые элементы и функции приложения проверяются на предмет правильности работы при стандартном
использовании. Т.е., это типичный пользователь, в типичной повседневной жизни, выполняет какие-то свои
типичные задачи. И именно эти типичные задачи мы проверяем чаще всего. На практике на данном уровне
тестирования проверяется основная масса требований к продукту. Например, выбор шрифта, возможность
набора текста, вставка картинок и так далее. Может быть как позитивным, так и негативным.
Расширенный тест (extended test). Под данным тестированием подразумевается проверка
нестандартного использования программного продукта. Например, если мы будем вводить специальные
символы в поле логина, либо же нелогично кликать по кнопкам, работать на многие вкладках одновременно, т.е.
максимально загружать нашу систему, либо выполнять какие-то выдуманные негативные тесты. Это то, что я
хотел рассказать о тестах по степени важности.
Классификация тестирования по цели тестирования.
New feature test (тестирование новой функциональности). Это проверка качества новой
функциональности, поставленной на тестирование. Обычно new feature test тестируется полным тестом, т.е.
проходит все этапы, начиная со smoke, Затем идёт тест физического пути и заканчивается расширенным тестом.
Тестировщики практически каждый день сталкиваются с new feature test, т.е., по сути, новая функциональность
приходит к тестерам во время какого-то спринта. Вы должны представлять, что спринт - это некоторый
промежуток времени в котором команда доставляет некоторую новую функциональность до нашего заказчика и
представляет её. И вот именно в этом спринте часто приходят какие-то новые фичи, новые функциональности,
которые в дальнейшем будут тестироваться в рамках new feature тест.
Регрессионное тестирование (Regression testing). Стоит отметить самую важную часть тестирования,
которая занимает у тестировщиков больше всего времени - это регрессионное тестирование. Что же такое
regression testing? Это тестирование ранее проверенной функциональности, с целью удостовериться, что
изменения в коде, например добавление новой функциональности, либо же исправления какого-либо дефекта,
не повлияли на работу старой функциональности. Регрессионное тестирование может быть проведено как на
уровне smoke, так и на уровне critical path test, а также на уровне extended test. Я хочу более подробно
остановиться на данном виде тестирования, потому что часто на собеседованиях могут спросить некоторые
подводные камни, связанные именно с этим видом тестирования, и в принципе для того, чтобы у вас сложилось
некоторое понимание, почему этот тип тестирования так важен в нашей работе. Данный вид тестирования
обязательно проводится в каждом новом билде. Как вы помните, build - это промежуточная версия нашего
продукта. Данный вид тестирования может включать в себя проверку исправленных багов, их степень влияния
на весь продукт, либо же на какую-то определенную функциональность. Вам нужно понимать, что регрессионное
тестирование обычно не покрывает всё приложение, а только те участки, которые тем или иным способом
соприкасаются с изменением их кода. Например, если мы говорим о странице авторизации пользователя в
систему, то если вдруг проводили какое-то изменение, связанное со сбросом пароля (обычно эти две
функциональности - логин в систему и сброс пароля, либо его восстановление) взаимосвязаны между собой,
поэтому обязательно, в случае вот таких вот изменений нужно проверять взаимосвязанные
функциональности. Также регрессионное тестирование рекомендуется проводить несколько раз, а, так как
функциональностей в приложении может быть очень много, то регрессионное тестирование любят очень часто
автоматизировать, для того, чтобы сэкономить время тестировщиков и вообще в целом время для
тестирования. Стоит отметить, что финальное регрессионное тестирование в этом большом цикле, состоящем
из трех-пяти регрессий, обычно определяется после выставления некоторых приоритетов, а приоритеты, в свою
очередь, определяются наибольшим количеством найденных ошибок в системе. Часто на собеседовании опять
же могут спросить, как осуществить выбор тестов для регрессии. Есть очень простой алгоритм, который вам
расскажу. Во-первых, в регрессию всегда нужно включать тесты, которые покрывают тестирование
безопасности, либо каких-то критичных важных функций для бизнеса. Обязательно нужно включать в регрессию
те области, которые чаще всего меняются в ходе разработки. Также, из одного из принципов тестирования
вытекает еще один принцип выборки теста для регрессии - обязательно нужно включать тесты функции с
высокой вероятностью ошибки.
Re-test. Это проверка результата работы над дефектом, проверка правильности исправления дефекта.
Т.е., когда разработчик направляет на вас уже пофикшеный баг, то вы проводите ретест. Т.е. убеждаетесь в том,
что девелопер на самом деле пофиксил данный дефект и функциональность действительно отрабатывается
так, как было задумано в требованиях.
Урок 6. Нефункциональное тестирование. Черный, белый и серый ящик.
https://www.youtube.com/watch?v=S1pCvIPag_c
Классификация тестирования по степени автоматизации.
Я думаю, что для вас не секрет, что существует два типа тестирования по степени автоматизации: ручное
тестирование, которое мы изучаем в рамках данного курса, и автоматизированное тестирование. При ручном
тестировании тестировщики вручную выполняют тесты, не используя никаких средств автоматизации. Что
касается автоматизированного тестирования, то оно предполагает использование специального
программного обеспечения, помимо того, что мы тестируем, для контроля выполнения тестов и сравнения
ожидаемого и фактического результатов работы программы. Этот тип тестирования помогает автоматизировать
часто повторяющиеся, но необходимые для максимизации тестового покрытия задач. Основными объектами
для автоматизации являются: регрессионное тестирование, которое занимает огромное количество времени и
представляет собой рутину и повторение тех тестов, которые мы уже проводили, а также smoke тестирование,
которое проводится самым первым. Бытует такое мнение, что автоматизированное тестирование заменит
ручное. На самом деле это не так, так как не все функциональности можно проверить только написанными
автоматизированными тестами, либо скриптами, поэтому ручники будут актуальны всегда, и работа для них
тоже будет находиться всегда. Сейчас популярны гибридные тестировщики. Иногда ручные тестировщики пишут
какие-то тестовые сценарии, отдают их автоматизаторам, которые в дальнейшем пишут программный код,
скрипт и выполняет уже данные тесты, т.е. получается некий симбиоз.
Классификация тестирования по знанию кода.
Тестирование черного ящика (black box). Мы не знаем, как устроена тестируемая система. Также, вы
можете найти такие названия этого тестирования, как тестирование, основанное на спецификации или
тестирование поведения. Что это значит? Эта техника тестирования основана на работе исключительно с
внешними интерфейсами тестируемой системы, т.е. мы вообще не знаем программный код. Примером может
быть когда тестировщик проводит тестирование веб-сайта, не зная особенности его реализации, используя
только предусмотренные разработчиком поля ввода и кнопки. Источником ожидаемого результата будут
спецификации т.е. мы тестируем только GUI (графический) интерфейс.
White box testing (тестирование белого ящика). В отличие от тестирования черного ящика, white box
testing (тестирование белого ящика) представляет собой следующее: нам известны все детали реализации
тестируемой программы, т.е. это такой метод тестирования, который предполагает, что внутренняя структура,
устройство и реализация, известны тестировщику. Примером может быть то, когда тестировщик, который как
правило, является либо автоматизатором, либо возможным программистом, изучает реализацию кода поля
ввода на веб-странице, определяет все предусмотренные, как правильные, так и неправильные
пользовательские вводы и сравнивает фактический результат выполнения программы с ожидаемым. При этом
ожидаемый результат определяется именно тем, как должен работать код программы.
Gray box test (серый ящик). Здесь нам уже известны только некоторые особенности реализации
тестируемой системы. Это такой метод тестирования ПО, который предполагает комбинацию двух предыдущих,
т.е. внутреннее устройство программы нам известно лишь частично. Например, мы знаем внутреннюю структуру
и алгоритм работы программного обеспечения для того, чтобы написать максимально эффективные тест-кейсы,
но само тестирование проводится с помощью техники черного ящика, т.е. с позиции нашего конечного
пользователя.
Функциональное тестирование.
Вот так мы и подошли к самой интересной части нашего сегодняшнего занятия, а именно
функциональному и не функциональному тестированию. Что же это такое функциональное тестирование? Это
один из видов тестирования, направленного на проверку соответствия функциональных требований ПО его
реальным характеристикам. Ключевое здесь - функциональные требования, т.е. мы проверяем, что наша
система делает. Основная задача функционального тестирования - подтверждение того, что наш
разрабатываемый продукт обладает всем функционалом, который требует заказчик. Это тестирование
проводится на всех уровнях и, как я уже сказал, проверяет то, что система делает.
Нефункциональное тестирование.
Целью нефункционального тестирования является проверка соответствия свойств приложения с его
нефункциональными требованиями, т.е. при данном виде тестирования мы проверяем, как наша система
работает. По сути, это тестирование свойств, которые не относятся к функциональности системы. Данные
свойства определяются их функциональными требованиями.
Тестирование на отказ и восстановление. К таким свойствам можно отнести, например, надежность,
т.е. реакцию системы на непредвиденные ситуации и в данном случае к данному свойству будет применимо
такое тестирование. Т.е. это исследование программных систем на предмет восстановления после ошибок и
сбоев.
Тестирование производительности. Второе свойство - это производительность, т.е. работоспособность
системы под разными нагрузками. На самом деле тестирование производительности - это огромный пласт
навыков и инструментариев, поэтому есть отдельные тестировщики, которые занимаются именно этим видом
тестирования. Т.е., если вы им заинтересуетесь, конечно же, можно переходить на специализированные курсы,
учиться читать специальную литературу и использовать уже техники тестирования производительности в своей
практике. Что же это такое, тестирование производительности? Это комплекс типов тестирования, целью
которого является определение работоспособности, стабильности потребления ресурсов и других атрибутов.
Качество приложения в условиях различных сценариев использования и нагрузок, и, в свою очередь,
тестирование производительности также можно разделить на несколько видов тестирования:
1. Нагрузочное тестирование. Мы проверяем производительность при нормальных условиях, т.е.
если у нас заявлено, что на сайте должны одновременно присутствовать тысячи пользователей,
мы создаем такие специальные условия, например, в программе jmeter, когда нагружаем нашу
систему на количество пользователей, которое будет чуть меньше этой тысячи и проверяем, что
все действительно ок.
2. Стресс-тестирование. Мы проверяем работоспособность нашей системы при экстремальных
нагрузках, когда, например, на сайте присутствуют именно тысячи пользователей, возможно даже
больше.
3. Тестирование стабильности. Представляет собой проверку нашего приложения при длительной
работе.
4. Объемное тестирование - тестируем нашу систему при увеличенных объемах обрабатываемых
данных, т.е., например, когда те же самые тысячи пользователей отправляют одновременно энное
количество мегабайт информации.
Тестирование удобства использования, т.е. исследование удобства работы с приложением с точки
зрения пользователя. Это можно протестировать с помощью не заберёте юзабилити testing, т.е. тестирование
удобства использования. Проверка юзабилити приложения заключается в том, что мы оцениваем соответствие
дизайна приложения к его функциональности, которое задается заказчиком. Также здесь мы можем исследовать
используемые графические элементы, цветовые оформления с точки зрения восприятия нашим пользователем,
удобство навигации и ссылки, которые есть у нас на данном сайте, анализ текстового наполнения сайта. Также
существует такая характеристика как обучаемость, например, если наш пользователь первый раз зашел на тот
или иной ресурс, насколько быстро он сможет сообразить, как им пользоваться. Например, на своем каком-то
предыдущем эксперименте, когда он пользовался подобным приложением от нашего конкурента, поэтому, если
мы не учтем все эти аспекты, пользователь, скорее всего, перейдет к нашему конкуренту, если будет неудобно
использовать наш продукт. Сейчас это тестирование очень распространено. Оно имеет огромное значение и,
опять же, существуют целые группы тестировщиков, специалистов, которые заточены именно на тестирование
удобства использования. Также есть специализированные курсы, которые позволяют обучиться данным
техникам.
Тестирование безопасности, т.е. защищенность пользовательских данных. Это тоже достаточно
обширное направление в тестировании. Существуют специальные тестировщики, которые занимаются именно
тестированием безопасности. Есть отдельные направления, например, здесь мы можем протестировать
насколько просто неавторизованный пользователь получит доступ к системе, либо же насколько просто
постороннему лицу получить доступ к данным. Т.е. мы тестируем то, как реализована защищенность нашего
программного продукта.
Ещё одно свойство - это портируемость, т.е. переносимость нашего приложения на различные
платформы. Здесь мы можем использовать такие типы тестирования, как тестирование установки и
конфигурационные тестирование.
Тестирование установки. Здесь мы проверяем успешность установки приложения, его настройку
обновления и удаления.
Конфигурационное тестирование. Здесь мы исследуем работоспособность программной системы в
условиях различных программных конфигураций. К данному виду тестирования можно отнести
кроссплатформенное и кроссбраузерное тестирование. Я думаю здесь не стоит очень подробно объяснять, что
это такое, думаю всем понятно.
1. Кроссплатформенное - значит, что мы тестируем наш продукта на различных типах и версиях
оперативных систем. Например, мобилки – android, либо ios.
2. Кроссбраузерное тестирование - мы используем наше приложение на различных браузерах.
Chrome, Mozilla, Opera.
Также стоит рассказать о тестировании локализации (l10n) и тестирование интернационализации (i18n).
Очень часто вы можете найти такие сокращения, не пугайтесь, если вы их увидите, возможно где-то на
собеседование будет какой-либо тест, либо вас спросят, как можно сократить эти названия, просто запомните.
Это, по сути, сокращение от их английских названий.
Тестирование локализации (l10n) - это процесс адаптации нашего программного продукта к языку и
культуре клиента. Например, если мы выходим на какой-то другой рынок, например, англоязычный, то мы
должны проверить, насколько наш продукт полностью переведён на этот язык, либо же, возможно, там
используются какие-то финансовые обозначения, например, фунта. Это мы тоже должны проверить. Ещё можно
к этому отнести контроль формата даты и времени, правовые какие-то особенности того государства, на которое
мы выходим, контроль раскладки клавиатуры пользователя, контроль символики и цветов, и другие аспекты,
которые могут быть связаны с той или иной локацией, на которой мы будем представлять наш продукт.
Тестирование интернационализации (i18n). В отличие от локализации, это тестирование включает в
себя: насколько наш продукт может в дальнейшем адаптироваться для той, либо иной локации. Например, при
создании продукта мы должны учесть возможность кодировки unicode, т.е. такого стандарта кодирования,
который поддерживается, практически, во всех языках мира, либо же мы должны предусмотреть в приложении
возможность поддержки элементов, которые невозможно локализовать обычным образом. Например, это может
быть вертикальный текст азиатских стран, либо же чтение справа налево в арабских странах, т.е. даже если мы
на данный момент не используем наше приложение в азиатских странах, то всё равно нужно досмотреть в
будущем, что данное приложение может выйти и на эти рынки, поэтому мы должны также протестировать
интернационализацию.
Тестирование GUI (графического интерфейса) пользователя. Т.е. это проверка соответствия
приложения требованиям к графическому интерфейсу, насколько профессионально оно выглядит, выполнено
ли оно в едином стиле, т.е. на том ли месте находятся те кнопки, которые у нас есть на том мокапе, т.е. шаблоне,
который предоставил нам дизайнер. Т.е. всё это мы проверяем при тестировании GUI
Классификация тестирования по исполнению сценария.
Иногда на собеседованиях спрашивают, например: что такое ad-hoc тестирование? И не все могут
ответить на этот вопрос. Давайте немножко разберемся, что это такое. Здесь можно выделить три вида
тестирования. Это исследовательское тестирование, ad-hoc тестирование и сценарное тестирование.
Ad-hoc тестирование - представляет собой тестирование без использования каких-либо спецификаций,
планов и разработанных тест-кейсов. Это ваша чистая импровизация, т.е., например, вы в первый раз получили
приложение и на каком-то своем эмпирическом, на традиционном уровне, понимаете, как с ним нужно работать.
Исследовательское тестирование, в отличие от ad-hoc, более формальная версия тестирование. Она
не требует написания тест-кейсов, но в то же время подразумевает, что каждый последующий тест выбирается
на основании результатов предыдущего теста. Даже если вы знаете, как работает ваше приложение, т.е. вы его
не в первый раз видите, то вы можете также следовать какому-то плану. Не обязательно его документировать.
Т.е. вы знаете, что в таком-то модуле есть такой-то ожидаемый результат и вы это тестируете, но не оформляете
это посредством тестовой документации.
Сценарное тестирование, т.е. это наше классическое тестирование по предварительно написанным и
уже задокументированным тестовым сценариям.
Классификация тестирования по запуску кода.
Если вы вспомните урок верификации и валидации, мы говорили с вами о том, что верификация - это
статическая проверка, а валидация - это динамическая проверка. Это применимо и к данной классификации,
т.е. есть статическое тестирование и динамическое тестирование.
Статическое тестирование. Не предполагается, что программный код во время тестирования будет
выполняться. Т.е. мы его не запускаем. Статическое тестирование начинается на ранних этапах жизненного
цикла программного обеспечения и является соответствующей частью процесса верификации. Сюда можно
включить тестирование любых форм документации, например, вычитку кода, инспекцию проектной
документации, функциональных спецификаций и наших требований.
Динамическое тестирование. Это такой тип тестирования, который предполагает запуск программного
кода. Таким образом анализируется поведение программы во время ее работы.
И есть еще такое интересное направление, как тестирование доступности (accessibility testing). Т.е.
здесь мы проверяем соответствие по общепризнанным стандартам доступности. Оно должно быть доступно для
использования людьми с ограниченными возможностями. Есть отдельный документ, который регламентирует
то, как наше приложение должно быть доступно для таких людей. Опять же, это отдельное направление в
тестировании, поэтому я не буду более подробно останавливаться на нем, но оно очень интересное. Стоит
отметить, что многие заблуждаются в том, что люди с ограниченными возможностями должны иметь какие-то
проблемы со здоровьем, которые мешают им пользоваться нашим программным обеспечением. На самом деле
это не совсем так. К таким людям, например, можно отнести тех, кто, к примеру, едет в машине и
сконцентрирован на движении, т.е. смотрит на дорогу, однако, в то же время, он пользуется каким-то гаджетом,
т.е. он ограничен в своих возможностях, он не может видеть всё, что происходит на экране своего смартфона,
но может, например, слышать. Либо, если у женщины есть ребенок, она его держит на одной руке и пользуется,
опять же, нашим гаджетом, смартфоном. Она должна пользоваться только одной рукой, это ограничивает ее в
движениях, и также мы должны предусмотреть такую возможность. Поэтому не всегда люди с ограниченными
возможностями - это люди, у которых есть какие-то проблемы со здоровьем.
Урок 7. Моделирование ПО. Водопадная, итерационная и V-модель.
https://www.youtube.com/watch?v=5uYZvf9o4MM
Мы продолжаем изучение тестирования и поговорим о моделях разработки программного обеспечения,
за исключением, пожалуй, гибких методологий Agile. Эта тема достаточно объемная, поэтому ей будет посвящен
отдельный урок.
И первая модель, о которой мы с вами поговорим, - это классическая модель разработки программного
обеспечения. Она называется водопадная (каскадная, waterfall). В этой модели каждый этап разработки
соответствующей стадии жизненного цикла ПО продолжает предыдущий. Что хотелось бы отметить из
особенностей данной модели? Как вы видите, для того, чтобы перейти на новый этап, мы полностью должны
завершить текущий. Т.е. если мы говорим об этапе сбора требований, мы не можем прийти на этап анализа,
пока не закончен сбор требований. Тоже касается этапа дизайна, кодирования, разработки тестирования и
поддержки нашей системы. Каскадная модель достаточно проста и понятна, но она уже немножко устарела и не
так практична, как раньше, так как сейчас у нас эпоха динамично изменяющихся и развивающихся требований.
Такой вот структурированный процесс может из преимуществ, которые раньше давала эта система,
превратиться в некоторые недостатки. Давайте поговорим о таких плюсах и минусах водопадной модели. Что
касается плюсов каскадной модели, то к ним можно отнести полное документирование каждого этапа, т.е. нам
всегда будут доступны четкие требования. Также мы всегда можем четко спланировать наши сроки и затраты,
и для заказчика наши процессы будут достаточно прозрачны, потому что он будет знать в какое время
запускается тот или иной этап, сколько времени потратят на его реализацию, и может спокойно это отследить.
Что касается минусов водопадный модели, то к ним можно отнести следующие. Во-первых, до начала проекта
необходимо утвердить полный объем требований к системе. В случае необходимости внесения изменений
требований позднее - мы не сможем вернуться к первой стадии, нам будет необходимо переделать заново
всю нашу работу. Также к минусам можно отнести увеличение затрат средств и времени в случае
необходимости изменения требований. Как я уже сказал, мы в таком случае должны будем вернуться на самый
первый этап, начать работу заново. Мы описали все плюсы и минусы, давайте теперь поговорим когда же
вообще используется такая модель разработки ПО. Во-первых, в проектах с четко определенными
требованиями, для которых не предусматривается их изменение в процессе разработки. Самый первый пример,
который приходит мне в голову, - это некоторые госучреждения, либо какие-то банковские структуры. Обычно
именно в них используется данная модель разработки. Также она используется для проектов, которые
мигрируют с одной платформы на другую, т.е. требования остаются такими же и меняется только некое
системное окружение, либо же когда от компании разработчика не требуется проводить тестирование, к
примеру, если компания занимается только разработкой программного кода, а уже тестирование будет делать
сам заказчик, либо какая-то другая сторона.
К следующей модели разработки можно отнести V-образную модель разработки программного
обеспечения. Она является модифицированной версией классической каскадной модели. Здесь уже, как вы
можете видеть на схеме, на каждом этапе происходит контроль текущего процесса для того, чтобы убедиться в
возможности перехода на следующий уровень. В этой модели тестирование начинается еще со стадии
написания требований, причем для каждого последующего этапа предусмотрен свой уровень тестового
покрытия. Здесь процесс разработки представлен некой нисходящей последовательностью в левой части
условной нашей буквы V, а стадия тестирования на её правом ребре. Соответствие этапов разработки и
тестирования показано горизонтальными линиями. Плюсами и минусами V-модели являются следующие. Вопервых, у нас есть строгие этапы, это мы говорим о плюсах. Во-вторых, планирование тестирования и
верификация самой системы производится на ранних этапах (раннее тестирование), что соответствует
принципу тестирования. И у нас есть такой этап, как промежуточное тестирование, т.е. когда мы говорили о
каскадной модели, мы не могли проводить крошечное тестирование, оно была строго за этапом разработки
нашего ПО. Здесь же мы можем проводить тестирование на каждом этапе. Что касается минусов, все равно
здесь у нас остается негибкость нашей модели. Само написание и создание программы происходит на этапе
написания кода, т.е., как мы видим из нашей схемы, то на середине процесса разработки, и у нас нет
возможности динамического внесения каких-либо изменений, потому что всё равно здесь все этапы идут друг
за другом. Когда же у нас используется данная модель разработки? Обычно в проектах, в которых существуют
какие-то временные и финансовые ограничения, и для таких задач, которые предполагают более широкое, по
сравнению с предыдущей каскадной моделью, тестовое покрытие.
До этого мы с вами говорили о последовательных моделях разработки программного обеспечения, но не
все модели жизненного цикла последовательные. Существуют также итерационные, либо же
инкрементальные модели, в которых используется совсем другой подход. Здесь вместо одной
продолжительной последовательности действий, весь жизненный цикл продукта разбит на ряд отдельных минициклов, и стоит отметить, что каждый такой цикл состоит из тех же этапов, что и в других моделях разработки
программного обеспечения. И вот такие вот мини-циклы называют - итерации. В каждой итерации происходит
разработка отдельного компонента системы, после чего этот компонент добавляется к уже ранее
разработанному функционалу. И вот это вот всё вместе называется - инкремент. Я думаю каждому из вас
знакома такая модель, как “plan do check act”. И каждый этап разработки соответствует какому-либо из этих
секторов. Например, PLAN - это будет этап планирования и сбора требований, сектор DO - это когда мы
анализируем и что-то рисуем, создаем дизайн, а также пишем программный код. Сектор CHECK - testing. Сектор
ACT - фаза review, т.е. оценка, пересмотр текущих требований и предложения по дополнению к ним. И в
конечном итоге достигается точка, когда все требования будут воплощены в нашем продукте, далее происходит
релиз. Давайте теперь поговорим о плюсах и минусах данной модели. Во-первых, к плюсам можно отнести то,
что у нас происходит ранее создание работающего ПО, так как итерации у нас обычно небольшие по времени,
мы можем добавлять какую-то часть функциональности и нашего продукта за небольшой промежуток времени
и очень быстро. Также можно отнести к плюсам то, что такие системы обычно очень гибки, т.е. они готовы к
изменениям требований на любом из этапов разработки. Как я уже сказал выше, такие итерации занимают
небольшой промежуток времени. Если мы говорим о таком фреймворке в гибкой методологии, как agile, то
обычно это от двух недель до четырех. Именно итерационная модель и стала родоначальником таких вот гибких
методологий, поэтому всегда проще провести тестирование и анализ рисков именно для такой небольшой части
нашего жизненного цикла продукта. Если мы говорим о минусах, то каждая фаза, - это самостоятельная какаято единица, и отдельные итерации друг на друга не накладываются, в отличие от более классических моделей.
Например, если даже взять ту же каскадную модель, не всегда все требования известны с начала
проектирования, это также может усложнить работу и реализацию общей архитектуры нашей системы. Когда же
всё-таки применять итерационную модель? Обычно она хорошо подходит для каких-то крупных проектов, когда
нам известны не все требования, но известны хотя бы какие-то ключевые milestone и ключевые требования.
Когда мы точно знаем, что требования будут меняться в процессе разработки.
Урок 8. Тестовая документация. Чек-лист и тест-кейс.
https://www.youtube.com/watch?v=IdjlZhVdiO4
Тестовые артефакты - тест-кейсы и чек-листы. Именно от их правильного создания, в первую очередь,
будет зависеть эффективность вашего тестирования. Также они дают возможность другим участникам команды,
будь то тестировщик, либо же даже разработчик, беспрепятственно разобраться в проведении теста и его
запуске. Существует два основных вида тестовой документации для того, чтобы провести правильный тест. Это
чек-лист и тест-кейс.
Чек-лист.
Давайте с вами начнём с более простого вида тестовой документации, а именно чек-лист. Если мы
говорим о чек-листе, то в первую очередь это некий список проверок, в котором показано, что мы будем
тестировать и, как следствие, результат и статус данных проверок. Сам этот список содержит в себе то, что мы
собрались вообще сделать, что мы не хотим забыть и что непосредственно мы будем проверять. Т.е. это некий
высокоуровневый набор идей наших тестов. Давайте с вами взглянем на основные моменты, которые могут
быть в хорошем чек-листе:
●
●
●
●
●
●
Версия нашей сборки (Build, билд). Окружение (Environment, инвайранмент), на котором проводилось
тестирование.
Дата проведения нашего теста.
Тестировщик, который проводил данное тестирование.
Тип тестов, который был использован для тех или иных проверок.
Название самих проверок.
Результат нашего тестирования, т.е. прошла эта проверка или нет.
Для упрощения нашей работы взяты какие-то отдельные модули нашего приложения, основные модули и
для них уже расписаны все проверки. Как вы видите, название чек-листа отражает название приложения. Нашим
тестовым приложением был калькулятор, т.е. для него мы использовали вот такой перечень проверок. Также в
чек-листе может содержаться список уникальных идентификаторов для каждой проверки, чтобы также
можно было спокойно найти их в нашей системе и дать на них ссылку, список каких-то других артефактов,
которые мы будем использовать при тестировании, также может быть ссылка на обнаруженный нами баг,
если, опять же, у нас данный чек-лист уже используется в баг-трекинговой системе. Уже по результату какойлибо проверки можем завести баг, если фактический результат отличается от ожидаемого. Чек-лист - это
список проверок, который показывает ЧТО тестировать и обязательно должен содержать в себе
результат наших проверок .
Тест-кейс.
Давайте теперь поговорим о другом виде артефакта тестовой документации - о тест-кейсах. Данный вид
тестовой документации отличается следующим: во-первых, здесь у нас уже будут шаги, т.е. это некий пошаговый
сценарий, здесь уже будут низкоуровневые проверки, т.е. они будут более детализированы и, в отличие от чеклиста, в котором мы говорили ЧТО мы будем тестировать, здесь мы уже расписываем КАК мы будем
тестировать. Опять же, здесь будет результат наших проверок. Также в тест-кейсе обязательно должен быть
заголовок. Возможно будет приоритет, либо же порядок выполнения нашего тест кейса и еще ряд некоторых
атрибутов, про которые я расскажу вам чуть позже. Самое главное, что вы должны усвоить при составлении
тест-кейса, что здесь у вас есть некоторая троица основных атрибутов. Это наше выполняемое действие, т.е.
пошаговый сценарий, ожидаемый результат и фактический результат.
В дальнейшем наши тест-кейсы могут собираться в набор из тест-кейсов, которые называются тест-suite.
Тест-suite - это набор тест-кейсов, в котором результат выполнения каждого тест-кейса является
некоторым предусловием для начала выполнения следующего, т.е. эти кейсы идут друг за дружкой по
порядку.
Давайте с вами теперь посмотрим, как вообще составляется тест-suite, как это может выглядеть.
Специально для этого мы создадим отдельный документ, в котором и будем в дальнейшем вводить наши тесткейсы.
Давайте назовём каждый столбец согласно тем атрибутам, которые должны быть в хорошем тест-кейсе:
●
Идентификатор, он будет уникальный для каждого нашего тест queries. Например, номер 1.
●
●
●
●
●
●
●
●
Приоритет, либо же в данном столбце может быть написано "вид теста", который используется для
данной проверки. Здесь либо мы расписываем приоритет выполнения, например, это будет первый
порядковый номер, т.е. мы запускаем этот тест первым, либо же здесь мы можем написать вид теста,
который мы используем, к примеру, это будет smoke.
Ссылка на требования с которыми связан наш тест-кейс, т.е. те требования, которые мы проверяем
в ходе данной проверки. Так как в данном примере требований у нас нет, возьмём какой-нибудь из
головы, например, REQ1.
Название модуля. Например, "регистрация нового пользователя".
Заглавие, в котором будет отражаться основная суть нашего тест-кейса. Например, "регистрация нового
пользователя с помощью мобильного телефона".
Шаги по воспроизведению тест-кейса. Например, "1) открыть сайт, 2) ввести в поле "мобильный" номер
телефона, 3) дождаться sms с кодом, 4) ввести код в появившееся поле, 5) нажать кнопку "регистрация".
И теперь по каждому шагу мы должны написать наш ожидаемый результат.
Ожидаемый результат, обычно он расписывается по каждому шагу, однако не всегда это необходимо,
и порой результат расписывают только для последнего шага. В нашем примере: 1) открыть сайт загружается сайт; 2) ввести в поле "мобильный" номер телефона - номер телефона отображается в поле
"мобильный"; 3) дождаться sms с кодом - код приходит на номер телефона; 4) ввести код в появившееся
поле - код отображается в новом поле; 5) нажать кнопку "регистрация" - появляется сообщение об
успешной регистрации.
Фактический результат.
Дефект. Мы будем вставлять номер нашего дефекта, чтобы в дальнейшем можно было отследить где
он находится и с каким нашим тест-кейсом он связан.
Если мы говорим о тест-кейсах для обучения будущих сотрудников, например, если вы прийдёте в какуюто компанию и там будут расписаны хорошо тест-кейсы, т.е. будут хорошо задокументированы шаги по
воспроизведению данного тест-кейса, а также расписан ожидаемый результат на каждый шаг, вам будет проще
обучиться работе в данной системе, узнать про нее. Т.е. тест-кейсы очень часто используются для обучения
сотрудников для того, чтобы сформировалось представление о программе, это способствует быстрому
усвоению информации и onboarding (адаптация) специалиста на проекте.
Сейчас мы с вами создали шаблон для заполнения тест-кейсов в рамках Excel, в небольших компаниях
могут использовать, к примеру, google таблицы для того, чтобы управлять своими тест-кейсами и делиться ими
с другими участниками команды. Или если мы говорим о таких компаниях, которые могут себе позволить какието платные ресурсы для трекинга тест-кейсов и их исполнения, то тогда можно приобрести, к примеру, Testrail и
работать в нём, либо же есть такая система, как Test Link. Есть также плагин Zephyr (зефир), который позволяет
хранить тест-кейсы, запускать их, т.е. это всё зависит от тех финансовых возможностей, которыми обладает
компания. Также вы можете для себя зарегистрироваться в Testrail, там есть триальная версия на 30 дней и
также попробовать заводить там тест-кейсы, позапускать их, посмотреть как она работает, эта система,
прощупать.
Стоит отметить, что у вас в голове должна устояться такая модель создания тест-кейсов. В первую
очередь мы создаем простые тест-кейсы, затем мы создаем сложные. Проще говоря, сначала мы создаем
позитивные сценарии. Вкратце напомню, что сначала мы создаем всегда позитивный сценарий, так как в первую
очередь мы проверяем тот факт, что наша система работает согласно нашему требованию, как это было
запланировано нашим заказчиком. Будет интересно сначала узнать, что действительно система отрабатывает
позитивные сценарии, и может спокойно уже запускаться для наших пользователей.
Очень часто работодатели высылают тестовые задания, в которых просят писать тестовые кейсы для
определенного модуля, либо проверки какой-либо функциональности, поэтому вам нужно хорошо разобраться
в создании тестовых кейсов, набить себе руку и в дальнейшем использовать вот такой вот шаблон для того,
чтобы успешно проходить такие тестовые задания. Также на самих собеседованиях очень часто показывают
какую-либо функциональность, например скрин экрана какого-нибудь приложения, в котором также просят
написать какие-либо тест-кейсы уже в рамках вашего технического собеседования, технического интервью.
Также хотелось бы отметить тот факт, что, как вы уже могли заметить, здесь используются обезличенные
глаголы, т.е. мы никогда не пишем такие глаголы, как "открываем, открою", т.е. всегда мы ставим себя на место
какого-то неизвестного пользователя, который будет выполнять эту задачу, поэтому здесь должно быть всё
максимально безлично, чтобы человек, просто читая ваши шаги и ожидаемый результат, мог без привязки к
какой-либо личности провести этот тест-кейс.
Критерии для выбора той или иной тестовой документации на проекте. Во- первых, это зависит от
сложности нашего проекта. Если мы говорим о каком-то простом проекте, то вполне достаточно использовать
чек-лист, если же наш проект усложняется, там есть очень много требований, которые достаточно сложны в
реализации и в них есть очень много аспектов, которые мы должны проверять, необходимы какие-то более
подробные проверки, то тогда, конечно же, лучше использовать тест-кейсы. Второй аспект - это длительность
нашего проекта. Если мы говорим о каких-то небольших проектах по длительности, то логичнее использовать
чек-листы, если же наш проект долгий, то тогда используют тест-кейсы. Также со сложностью проекта связан и
его размер, т.е. чем больше проект, чем больше людей задействованы в нем, если есть вероятность того, что в
команду нашу будут приходить новые специалисты, которых нужно будет обучать, то, опять же, здесь лучше
использовать тест-кейс. Если говорить о самой команде, если она часто меняется, т.е. такой аспект, как
стабильность, опять же используют тест-кейсы. Если наши требования не подвержены очень сильным
изменениям, то тогда также лучше использовать тест-кейсы, так как их достаточно сложно поддерживать, т.е.
если мы изменяем наши требования очень часто, нужно постоянно вносить изменения в тест-кейс. С чек-листом
работать проще. Как вы видели - это простой документ, т.е. там расписаны просто какие-то общие вещи о нашей
необходимой проверке и внести изменения в них очень просто. И не стоит забывать о том, что во многом выбор
той или иной тестовой документации может зависеть от желания нашего заказчика, например, даже если наш
проект простой и быстрый, а наш заказчик хочет быть более вовлечен в процесс, чтобы этот процесс был для
него прозрачен, он может выбрать такую тестовую документацию, как тест-кейсы. В таком случае мы не сможем
отказать ему и будем использовать именно их в своей работе.
Урок 9. Техники тест-дизайна. Классы эквивалентности и граничные
значения.
https://www.youtube.com/watch?v=HJPF5qJx7jg
На данном уроке мы поговорим о двух самых известных и популярных техниках тест-дизайна, которые я
использую в своей работе и которые чаще всего спрашивают на собеседовании, а также при выполнении
тестовых заданий. На самом деле таких техник тест-дизайна существует гораздо больше. Более подробно со
всеми ними вы можете ознакомиться в книге Lee Copeland “A Practitioner’s Guide to Software Test Design”.
Test design - это этап процесса тестирования нашего программного обеспечения, на котором
проектируются и создаются тест-сьюты, либо тест-кейсы, в соответствии с определенными ранее
критериями качества и целями тестирования. Т.е., простыми словами, - это придумывание наших тестов, т.е.
их разработка. У тест-дизайна есть две основные цели. Во-первых, это то, что мы должны придумать. Такие
тесты, которые могли бы обнаружить наиболее серьёзные ошибки для нашего продукта. Вторая цель - это
минимизация количества таких тестов.
Давайте поговорим об этих двух популярных методиках, которые используют тестировщики в своей работе
чуть ли не каждый день. Во-первых, это эквивалентное разбиение, либо же тестирование классов
эквивалентности. А второй тип - это анализ граничных значений.
Эквивалентное разбиение.
И начнем, конечно же, с эквивалентного разбиения. Давайте с вами сначала разберемся, что же такое
класс эквивалентности? Класс эквивалентности - это входные данные, которые обрабатываются нашим
приложением: одинаковые, либо же обработка которых приводит к одному и тому же результату.
Для того, чтобы разобраться в классе эквивалентности, сразу приступим к разбору следующего примера:
представим, что существует некоторая компания, в которой в зависимости от возраста соискателей будет
приниматься решение - брать этого человека на работу или нет. Условия для нашего примера будут следующие:
если возраст нашего соискателя от 0 до 13 - мы не нанимаем такого сотрудника, если возраст от 14 до 17 - то
здесь будет у нас part time, если от 18, предположим, до 55 - это full-time, и от 56 до 99 - не нанимаем таких
сотрудников. Как мы с вами видим, мы уже сформировали 4 класса эквивалентности. Как я уже сказал, это некий
диапазон значений, которые обрабатываются нашей системой одинаково, либо же обработка диапазона
которого приходит к одинаковому результату. Т.е., например, для возраста от 0 до 13 результат - мы не
нанимаем таких сотрудников. Вот это уже можно взять как один класс эквивалентности. Как вы видите, у нас уже
есть 4 класса, т.е. это некоторые позитивные классы. Но также, если мы с вами вспомним о позитивных и
негативных тестах, также есть и позитивные и негативные классы эквивалентности. Если мы говорим о возрасте
сотрудников, которых мы не нанимаем, также мы с вами сможем уйти за пределы 0. Т.е. взять, например, такой
диапазон, как от минус бесконечности до 0. Такие значения также можно принять и если мы говорим о
сотрудниках, которых мы не нанимаем. Также сюда можно отнести от 100 до + бесконечности. Это тоже классы
эквивалентности. Плюс ко всему, мы скорее всего будем использовать именно эти числа. В поле ввода мы
можем ввести, к примеру, буквы, либо же спец символы, и это также у нас будет классом эквивалентности негативными классами эквивалентности, т.е. все это мы можем учесть при нашем тестировании.
Правила эквивалентного разбиения:
первое правило - это определение классов эквивалентности;
второе правило - проведение хотя бы одного теста для одного класса. Т.е. мы должны взять хотя бы
одно значение из класса эквивалентности для того, чтобы подтвердить тот факт, что система обрабатывает все
значения в этом классе одинаково.
Возвращаясь к нашим основным позитивным классам. Т.е. мы берем из каждого класса по одному
значению, чаще всего советуют брать значение из середины данного класса, например, если мы говорим от 0
до 13, то серединой здесь будет либо 6, либо 7. Т.е. это значение мы и будем тестировать. Так мы делаем для
каждого класса, включая наши негативные классы эквивалентности, про которые я говорил чуть раньше. Это то,
что касается техники эквивалентного разбиения. Т.е. мы уже с вами видим, как мы упростили нашу работу и в
дальнейшем повысили эффективность и время на проведение наших тестов. Один из принципов тестирования
гласит, что исчерпывающее тестирование невозможно, и именно данная техника тест-дизайна позволяет нам
действительно использовать только одно значение и не проводить, к примеру, как здесь, 14 тестов на данный
класс эквивалентности.
Анализ граничных значений.
Вторая техника тест-дизайна, которая очень сильно связана с эквивалентным разбиением, либо же
тестированием класса эквивалентности, - это анализ граничных значений. Возвращаясь к нашим
определенным классам эквивалентности, к позитивным, здесь мы видим границы этих классов, т.е. это 0, 13, 14,
17, 18, 55, 56, 99, плюс также эти границы есть и для наших негативных классов. Давайте с вами остановимся
более подробно на позитивных. Что же под собой подразумевает данный анализ граничных значений?
Правила анализа граничных значений:
Первое правило - определение классов эквивалентности.
Второе правило - определение границ этих диапазонов.
Третье правило - проведение трёх тестов: для границ на самой границе, на значение выше этой
границы и на значение меньше этой границы.
Давайте с вами теперь вернёмся к нашему примеру и посмотрим, как это работает на практике. Смотрите,
мы определили с вами границы для каждого класса и давайте, для примера, возьмем такой диапазон, как от 18
до 55. Что же гласят наши правила? Мы берем обязательно вот эти граничные значения - 18, 55, а также еще
два значения на этой границе, т.е. значение меньше и значение больше, в данном случае это будет значение
17, 18 (сама граница) и 19, и также значение 54, 55 (сама граница) и 56. Если бы мы говорили о том, что наша
система может обрабатывать десятичные дроби, тогда бы значение было бы максимально приближено к нашей
границе, т.е. было бы значение, например, 54,9 и 55,1, если бы у нас использовался бы только один знак после
запятой. Вы должны это помнить и обязательно использовать данные значения. Как вы могли заметить, когда
мы используем технику анализа граничных значений, мы также проверяем и тестируем класс эквивалентности,
т.е. эквивалентное разбиение. Также у нас задействовано, т.е. мы берём значение, которое также входит в класс
эквивалентности, например, 54, т.е. оно входит в этот класс от 18 до 55 и вполне возможно не проводить
дополнительное тестирование. По этой технике тест-дизайна мы убиваем с вами двух зайцев, но, как я уже
говорил в начале нашего урока, я бы вам посоветовал ещё тестировать значение на середине данного
диапазона, так как это улучшит качество вашего теста и с большей вероятностью позволит вам не пропустить
какое-либо значение, которое обрабатывается нашей системой. Именно эти две техники очень часто
спрашивают на собеседовании.
Урок 10. Отчет о дефекте (баг-репорт) в Jira. Severity и Priority. ЖЦ
дефекта.
https://www.youtube.com/watch?v=6YrgKBTzb5o
На данном занятии мы поговорим с вами о таком тестовом артефакте, как отчёты о дефекте (баг-репорт).
Именно создавать и реагировать на исправление данного тестового артефакта вы будете чаще всего в своей
работе. Также, мы с вами рассмотрим, как на практике заводить дефект в такой популярной баг-трекинговой
системе, как Jira. И в конце данного занятия поговорим о жизненном цикле дефектов.
Дефект (баг) - это несоответствие фактического результата выполнения программы ожидаемому
результату.
Дефекты обнаруживаются на этапе тестирования ПО, когда мы с вами, тестировщики, проводим
сравнения полученных результатов работы программы, либо же её компонента или дизайна с некоторым
ожидаемым результатом, описанным, например, в спецификации, либо требованиях. Как только мы
обнаруживаем баг, мы должны его задокументировать. Документ, который позволяет нам это сделать, это багрепорт, т.е. этот документ содержит полное описание нашего бага и включает информацию как о самом баге,
так и об условиях возникновения данного бага.
Атрибуты баг-репорта.
Описание нашей проблемы. Если мы говорим о такой баг-трекинговой системе, как jira, то обычно в
описании также прописывают шаги воспроизведения данного бага, которые приведут к тому, что человек,
который прочитает данный отчет пройдёт по всем этим шагам и увидит наш фактический результат, который
получился после того, как он выполнит все шаги.
Проект. Т.е. это название нашего проекта, к примеру, интернет-магазин. Тогда здесь, в этом поле,
указывается название этого проекта. Для того, чтобы в дальнейшем мы могли спокойно проследить - к какому
проекту относится наш баг-репорт.
Компонент, в котором непосредственно был обнаружен данный дефект.
Версия билда, т.е. версия той сборки, на которой обнаруженный дефект воспроизводится.
Серьезность (severity), т.е., по сути, это критичность нашего бага. Т.е. степень влияния данного бага на
наше приложение. В баг-трекинговой системе severity обычно обозначает тестировщик.
Приоритет (priority) - обозначает очередь исправления данного бага. Обычно его выставляет РМ, т.е.
Product Manager, и он решает, какой баг будет фиксится первым.
Статус, т.е. это статус нашего бага в его жизненном цикле.
Автор, т.е. тот человек, который нашел наш баг. Это может быть как тестировщик, так и другой участник
проекта, либо команды, который обнаружил какой-либо баг в системе.
Назначение.
Severity и Priority (серьёзность и приоритет).
Давайте теперь более подробно поговорим о таких атрибутах, как severity и priority. Как я уже сказал,
дефекты могут классифицироваться с точки зрения severity и priority по-разному. Давайте поговорим о такой
классификации. На разных проектах, в разных компаниях, классификация severity и priority может отличаться
между собой, однако я приведу вам самую распространенную, которая в дальнейшем сможет помочь вам
соотнести те степени влияния, которые есть у вас, к примеру, на проекте с тем, что буду рассказывать вам я.
Классификация Severity:
Blocker - такой тип ошибки, который приводит нашу программу в нерабочее состояние. Если мы
обнаруживаем такой дефект, то дальнейшие работы с программой или её функциями попросту невозможны.
Critical - это критические дефекты. Они приводят наш ключевой функционал в нерабочее состояние. Также
это могут быть существенные отклонения от бизнес-логики нашего приложения, либо же какая-то неправильная
реализация требуемых функций. Возможна потеря пользовательских данных, в отличие от blocker, наше
приложение не приходит в абсолютно нерабочее состояние, и в принципе другие функции могут работать
нормально, поэтому есть такая градация, как critical.
Major (мажорные) - это какие-то серьёзные ошибки, которые свидетельствуют об отклонении от бизнес
логики или нарушающие работу программы, но в то же время они не имеют физическое воздействие на наше
приложение, возможно есть некоторый обходной путь, либо его еще могут называть workaround. А когда мы
можем в принципе задействовать эту функцию - она будет работать каким-то другим способом, но всё-таки,
опять же, говоря о степени влияния, о её серьезности для нашего продукта, она достаточно велика.
Minor (минорные) - это какой-то незначительный дефект, не нарушающий функционал нашего
приложения, но который является несоответствием ожидаемого результата. Например, это может быть ошибка
нашего дизайна.
Trivial - какие-то тривиальные баги. По самому названию, я думаю, вам уже понятно, что это баг, который
не имеет влияния на функционал или работу нашей программы, но который может быть обнаружен визуально.
Например, это может быть какая-то опечатка в тексте, т.е. она не является какой-то серьёзной ошибкой, но всётаки есть отклонения ожидаемого и фактического результата.
Опять же, говоря о различных баг-трекинговых системах и принятии решения на проекте о том, какие
атрибуты должны характеризовать серьёзность, например, может не быть такого класса, как блокеры, либо же
могут отсутствовать тривиальные ошибки, возможно могут быть только critical, major, minor. На проекте
существует документация по процессу, который описывает, какие баги должны относиться к каждому из этих
классов, если же такой информации на проекте у вас нет, то основная информация - теория, связана именно с
такой классификацией, которую я вам дал.
Давайте теперь перейдем к такому атрибуту, как priority, либо приоритет. Как я уже сказал, это некая
приоритезация исправления наших дефектов, т.е. порядок исправления на проекте. Обычно приоритет
выставляет PM, но если PM нет, это вполне может сам тестировщик, который работает с этим багом, возможно
даже аналитики, которые знают, как должна работать ваша система и какие функциональности в данный момент
критичные для нашего пользователя, и которые нужно в обязательном порядке доставить заказчику в первую
очередь, тогда это может выставлять и аналитик.
Классификация Priority:
High - от каких дефектов будут избавляться в первую очередь. Т.е. этот баг должен быть исправлен как
можно быстрее, так как он критически влияет на работоспособность нашей программы.
Medium - этот дефект также должен быть обязательно исправлен, но он не оказывает какое-то критическое
воздействие на работу приложения.
Low - ошибка также должна быть исправлена, но она не имеет критического влияния на программу и
устранение может быть отложено на какой-то более длительный срок, в зависимости от наличия других
дефектов.
Говоря о том, совпадает ли между собой severity и priority, т.е., например, если тестировщик решает, что
данная функциональность для нашего приложения очень-очень критична и выставляет severity, к примеру,
critical, либо blocker, но в то же время РМ понимает, что это можно отложить на более длительный срок, и на
самом деле это не так критично для нашего приложения, то он может выставлять другой приоритет, например,
medium вместо хай.
Часто на собеседованиях просят привести пример багов с высокой severity и низкой priority. Если мы
говорим о таких багах, то, например, если у нас есть какая-то функциональность, которая достаточно редка в
использовании у нашего пользователя, то, если мы понимаем, что она не работает, мы можем поставить severity,
к примеру, блок, либо critical, но в то же время наш РМ понимает, что данная функциональность не пользуется
большим спросом, она не является критичной для работы в нашей системе и мы можем обойтись на данный
момент без неё, тогда он решает, что приоритет будет низкий. Это самый распространенный пример, когда у
нас высокая северити и низкий приорити. Если мы говорим о другой стороне медали, когда у нас высокий
приорити и низкий северити, к примеру, тут часто приводят сайт google, его главную страницу. Когда вы её
открываете и видите опечатку, например, написано не google, а gogle, этот бренд достаточно узнаваемый и
такие опечатки могут очень сильно повлиять на репутацию данного бренда, но в то же время серьёзность этой
ошибки минимальна, т.е. это какая-то опечатка, это тривиальная ошибка.
Давайте теперь вернёмся к атрибутам, которые еще могут быть в нашем баг-репорте:
Окружение (Environment). Всегда необходимо указывать окружение, на котором был обнаружен данный
дефект. Операционная система, разрядность, service pack, браузер, в котором был обнаружен данный дефект,
его версия. Т.е. мы подробно здесь расписываем в каком именно окружении был обнаружен наш дефект. Также
в окружении может быть прописано, к примеру, если у нас на проекте есть несколько окружений, например, есть
окружение для разработчиков DEV, есть окружение стабильной версии STAGE, и есть окружение продакшна
PROD, когда уже в нем работает наш конечный пользователь. Давайте с вами пометим эти три вида окружения.
Я расскажу вам тоже немножко более подробнее о них. Как я уже сказал, на каждом из этих окружений работает
определенный круг лиц.
●
●
●
DEV окружение - обычно работают разработчики, т.е. они туда заливают какие-то фичи, возможно также
подключаются тестировщики к тестированию каких-то отдельных фич на DEV окружении, и также могут
заводить дефекты. Если мы обнаруживаем такие дефекты на этом окружении, мы прописываем в этом
поле DEV.
STAGE окружение - на него попадает уже какая-то стабильная версия нашего приложения, на нем чаще
всего работают тестировщики и именно на stage доводят это приложение до определенного
предрелизного состояния.
PROD окружение - если на stage не остаётся дефектов, то такое приложение переводится на стадию
прод, где у нас работают наши конечные пользователи.
Опять же, на многих курсах не говорят об этих трёх окружениях и часто у начинающих тестировщиков
возникает некоторый вопрос на первых митингах, на которые они приходят, что это вообще такое. Думаю, что
после такого краткого экскурса в эти окружения вам будет немножко понятнее и вы не будете смотреть
большими глазами на наличие нескольких окружений в вашей будущей компании.
Возвращаясь к атрибуту «Описание», как я уже сказал, здесь могут быть прописаны шаги воспроизведения
и, чаще всего, они действительно там прописываются, если нет отдельного поля, например, в той багтрекинговой системе, с которой я работаю на своей работе, она называется devops, есть отдельное поле для
шагов воспроизведения (Steps To Reproduce - STR). Также прописывается наш фактический результат (actual
result). Следующее - ожидаемый результат (expected result). Т.е., еще раз повторюсь, фактический результат это результат, который мы получаем, выполнив все шаги по воспроизведению. Ожидаемый результат - это
результат, который должен быть в соответствии с нашими требованиями, то, что мы действительно должны
получить. Также стоит отметить, что в ожидаемом результате необходимо писать согласно чему вы пришли к
такому выводу, что именно такой результат должен быть по совершению шагов воспроизведения. Это может
быть ссылка на какое-то требование, либо же ссылка на мокап по дизайну нашей страницы в интернете. Т.е.
обязательно необходимо ссылаться на что-то. Просто говорить о том, что такой результат должен быть без
подкрепления какой-то доказательной базы, не стоит.
Прикреплённые файлы. Здесь может быть фото, скриншот вашего экрана, где будет наглядно видно, где
воспроизводится ваш дефект. Либо же это может быть видео по тем шагам, которые вы выполняете для
воспроизведения вашего дефекта. Обязательно, если мы говорим о скриншоте, необходимо указывать, какимито элементами, пусть будет, к примеру, красная рамка, стрелка, какая-то надпись, которая будет
характеризовать, что вот именно в этом месте происходит дефект, чтобы разработчик, только взглянув на
данный скриншот, мог сразу понять, что действительно происходит по результатам шагов воспроизведения. Так
как чаще всего разработчик может даже не читать ваши шаги воспроизведения, он знает, как работает система,
и, взглянув только на скриншот, он может по-быстрому пофиксить обнаруженный баг. Особенно, если мы
говорим о каких-то багах, связанных с дизайном, с какими-то опечатками. Если мы говорим о видео, обязательно
смотрите, наблюдайте за тем, чтобы у вас был отключен звук окружения, если мы, конечно, не говорим о какихто дефектах, именно связанных с аудиофайлами. Это также не очень хорошо. Видео не должны быть очень
длинными, вы можете опускать некоторые шаги воспроизведения, если считаете, что они не так важны, а
записывать какую-то последнюю часть. Также в эти прикрепленные файлы можно закидывать логи каких-то
ваших ошибок, либо же какие-то архивы.
Особенно обратите внимание на блок, связанный с серьезностью и приоритетом, потому что это
достаточно часто спрашивают на собеседованиях.
Баг-трекинговая система Jira.
https://www.atlassian.com (официальный сайт jira).
Баг-трекинговая система, которая позволяет нам вести все наши баг-репорты в ней. А также она позволяет
вообще работать с нашим проектом, т.е. сюда добавляются все юзер сторис, требования, которые мы должны
в дальнейшем реализовать. Здесь ведется работа с багами. Здесь вообще хранится полностью всё, начиная от
требований от наших бизнес-аналитиков, либо продукт менеджеров, заканчивая нашими багами, которые мы
вводим в систему.
Создадим наш первый баг-репорт.
CREATE - создать баг.
Project* - выбрать проект.
Issue type* - тип сущности, выбираем BUG.
TASK - те задания, которые выполняет тот или иной участник команды, когда планирует свою работу на
итерацию.
STORY – это наше конкретное требование, обычно прописывается в формате user story.
EPIC - набор наших требований, которые объединены между собой, т.е. это большая функциональность,
которую мы должны доставить нашему пользователю.
Summary* - название бага.
Description – описываем шаги по воспроизведению, фактический и ожидаемый результаты.
Preconditions - расписываем какие-то предусловия, например, что для того, чтобы воспроизвести наш
дефект, в системе уже был создан user с такими-то данными. Это надо для того, чтобы просто не перегружать
наши шаги по воспроизведению, и разработчик уже будет знать, что ему необходимо сделать для того, чтобы в
дальнейшем воспроизвести наш дефект.
Reporter* - автор.
Labels – или тэгз, ярлыки, которые позволяют нам в дальнейшем провести поиск по jire наших багов, т.е.
как то их тоже классифицировать между собой, объединять.
Environment - это окружение.
Attachment – сюда мы загружаем какие-то скриншоты, видеофайлы.
Linked Issues и Issue - можем линковать наши требования, которые связаны с нашим багом.
Assignee - это тот человек, который в дальнейшем будет фиксить наш баг. Обычно асэйни на крупных
проектах назначает продакт-менеджер, но если проект небольшой, это вполне может быть и тестировщик.
Epic link - это линка на наш epic.
Sprint - та итерация, в которой необходимо будет пофиксить наш баг.
Давайте попробуем завести какой-нибудь баг-репорт, например, возьмём страницу логина в нашем
приложении, допустим там съехала какая-то кнопка. Необходимо правильно заполнить поле SUMMARY*
(название).
Правило названия бага. В заголовке вы обязательно должны ответить на три вопроса: ГДЕ? ЧТО?
КОГДА?
Где? - это может быть название вашего модуля, в котором вы обнаружили ваш баг.
Что? - это непосредственно что происходит, когда вы обнаруживаете ваш баг, т.е. то, к чему привёл ваш
дефект.
Когда? - при каких условиях это происходит.
Например, если мы говорим о странице с логином системы, «login page: The button ‘Sign In’ is displaced
after clicking on the page» - «на странице логина (ГДЕ) – кнопка ‘Sign In’ смещается (ЧТО) – после нажатия на
страницу (КОГДА)».
Description. Для того, чтобы наш дефект был понятен разработчику и тем людям, которые в дальнейшем
будут работать с ним, лучше всего его форматировать, т.е. применять какие-то стили к его оформлению,
например, выделить жирным шрифтом ключевые моменты.
STR (Steps To Reproduce) - шаги по воспроизведению -расписываем всё, что приведёт в дальнейшем к
воспроизведению нашего дефекта. 1)Open the login page - если бы мы работали на реальном проекте, у нас,
возможно, уже была бы линка на неё, и мы могли бы её вставить сюда, чтобы упростить себе работу и сразу
могли перейти на вот эту страницу. Шаги можно выделять цифрами, либо же #, чтобы было наглядно видно
отдельные блоки шагов. В принципе, таких шагов воспроизведения вполне достаточно для того, чтобы
разработчик смог в дальнейшем наш баг воспроизвести. Старайтесь не выдумывать огромное количество
шагов, можно их объединять между собой. Рекомендуют использовать от 7 до 10 шагов максимально, но лучше
даже меньше. Каждый шаг должен быть понятен. Если их нельзя логически объединить – лучше их не
объединяйте.
Actual result (фактический результат) - у нас будет таким же, как и заголовок. Вообще рекомендуют
придумывать другое наименование для заголовка, но я, обычно, пользуюсь таким методом. Так как это
достаточно упрощает работу и, в принципе, здесь всё понятно. Не нужно выдумывать велосипед.
Expected result (ожидаемый результат) - что мы действительно должны были увидеть после того, как
нажимаем на какое-то пустое место на странице. Например, напишем, что кнопка «sign in» должна быть
расположена на странице, как в мокапе. Если бы у нас были какие-то мокапы, шаблоны, мы могли бы просто
скопировать ссылку на этот мокап и с помощью гиперссылки вставить сюда ,и так же, после нажатия на эту
гиперссылку, разработчик сразу переходил бы на необходимый мокап и мог увидеть, как действительно должна
себя была вести система и где должна была находиться кнопка «sign in».
Fix versions – это поле заполняется уже после того, как баг пофиксили. Обычно это делает разработчик.
Priority – так как баг в примере у нас незначительный, то приоритет выставим Low. Обычно приоритет
выставляет продукт менеджер.
Хорошие программы–скриншотеры, которые позволяют удобно и быстро редактировать фотографии для
баг-репортов – ShareX (бесплатная), Snagit (платная).
Жизненный цикл дефектов.
Давайте представим, что вы нашли какой-то баг. Он появился в жизни вашего проекта и, как у любой
жизненной формы, у него есть жизненный цикл. Когда мы с вами говорили об атрибутах баг-репорта, мы
говорили о его статусах. Вот именно про эти статусы и идёт разговоров в блоке, посвященному жизненному
циклу.
Смотрите, как только наш баг-репорт создаётся в системе, его статус NEW. Т.е. он новый. Тестировщик
нашёл баг, дефект успешно был занесён в баг-трекинговую систему (в некоторых баг-трекинговых системах
статус NEW может называться PROPOSED).
После этого, наш дефект переходит в статус OPENED, либо ASSIGNED, либо ACTIVE, когда наш дефект
уже был направлен на работу девелоперу нашим продукт менеджером, либо же вами, если мы говорим о
небольшом каком-то проекте, небольшой команде. И в зависимости от решения нашего продукт-менеджера,
наш баг может быть также отложен, т.е. исправление данного бага не несёт какой-то ценности на данном этапе
разработки, или по каким-то другим причинам его исправление будет проведено в дальнейшем, может быть в
других итерациях, в других спринтах, опять же, это решает наш продукт-менеджер.
Если же всё-таки наш дефект был взят, назначен статус ASSIGNED, то когда development team (команда
разработчиков) фиксят данный баг, он переходит в статус RESOLVED и назначается обратно на тестировщика.
Но, в то же время, данный баг может быть отклонён, т.е. он может быть в статусе RESOLVED, но могут быть
следующие резолюции по данному багу:
●
●
●
●
●
●
●
●
FIXED – пофикшен;
DUPLICATE - если данный баг уже существует в системе, но мы почему-то пропустили этот факт;
WONTFIX - данный баг не будет вообще фиксится;
INVALID - возможно данный баг был заведён по ошибке;
WORKSFORME - кто-то из команды QA тестировал эту ошибку и не смог воспроизвести её,
используя предоставленные шаги и/или тестовый документ и другие резолюции.
FunctionAsDesign - если действительно всё работает согласно нашей спецификации, нашим
требованиям.
Либо атрибут - когда данный баг не очень понятен нашему девелоперу, он просит чтобы
тестировщик переписал его так, чтобы в дальнейшем было понятно, что это такое и с чем его едят.
Fix them directly - когда наш баг пофикшен каким-то уже баг-фиксом другого нашего бага и
действительно этот функционал заработал.
После RESOLVED – FIXED баг попадает к нашему тестировщику. Тестировщик верифицирует, что баг
действительно пофикшен и баг переходит в статус VERIFIED. Если действительно наш баг окончательно
пофикшен, например, он не воспроизводится на Dev, Stage, Prod окружении, то мы его закрываем и он переходит
в статус CLOSED.
Если же мы понимаем, что наш баг опять воспроизводится, мы можем его переоткрыть, как на этапе
VERIFIED, так и на этапе CLOSED, и тогда он попадает в статус REOPEN. И уже продукт-менеджер решает,
какой разработчик должен им заняться, либо же баг переходит сразу к самому разработчику, который работал
над этим дефектом.
И цикл повторяется опять: REOPEN – VERIFIED – REOPEN – VERIFIED – CLOSED – REOPEN – VERIFIED
– CLOSED, пока баг не будет пофикшен.
Данный урок получился достаточно объёмным, но он очень важен для вашей дальнейшей работы, так как
баг репорты вы будете создавать чаще всего на ваших проектах. Разобраться в них - просто «маст хэв» для
всех начинающих тестировщиков, да и вообще для всех тестировщиков, так как это основная сущность, с
которой работают все, начиная от вас, тестировщиков, заканчивая теми же самыми девелоперами, бизнесаналитиками, либо же продукт-менеджерами. Т.е. все участники проекта могут подключаться к баг-репорту.
Поэтому это очень полезный навык, когда вы умеете писать качественные баг-репорты, знаете что такое
жизненный цикл дефекта и применяете все эти знания в своей практике.
Урок 11. Клиент-серверная архитектура. Веб-сайт, веб-приложение и вебсервис.
https://www.youtube.com/watch?v=00z-6hyIvG0
Сегодня мы начинаем погружение в очень интересную и объемную тему - тестирование в
ориентированных приложениях. Стандартное начало любого курса по тестированию веб-приложений
заключается в разборе понятия и модели клиент-серверной архитектуры, поэтому давайте поговорим немножко
о ней.
Что же такое клиент-серверная архитектура? Это такая архитектура, в которой сетевая нагрузка
распределяется между поставщиками услуг, которые называются серверами, и заказчиками услуг,
которые называются клиентами.
Фактически, клиент и сервер - это некое программное обеспечение. Обычно эти программы расположены
на разных вычислительных машинах и взаимодействуют между собой через сетевые протоколы, но также
клиент и сервер могут располагаться на одной машине. Самый распространенный протокол это HTTP. Клиентсерверная архитектура построена, в основном, на взаимодействии через данный вид протокола. Если мы с вами
сейчас глянем на данную схему, то, как вы видите, у нас здесь есть клиент и есть сервер, есть сервер базы
данных. Это и есть стандартная схема клиента и сервера. Иногда базы данных в данной схеме нет.
Когда мы говорим только о том, что у нас есть клиент и сервер, которые взаимодействуют между собой,
клиент отправляет запрос (request) на сервер, сервер его обрабатывает и отправляет клиенту обратно
ответ (response), т.е. ответ от сервера.
Если же мы говорим о дополнительном элементе, таком, как база данных, то здесь все просто. Клиент
отправляет запрос на сервер, сервер отправляет запрос в базу данных, база данных отравляет ответ на сервер,
затем сервер уже взаимодействуют с нашим клиентом, отправляя ответ по той информации, которую он
запросил.
Одна программа-сервер может выполнять запросы от нескольких программ-клиентов. Как вы видите, у нас
их здесь три. Может быть и намного больше. Сервер обычно размещают на специально выделенной
вычислительной машине, как правило, с какими-то другими программами серверами, поэтому
производительность данной машины должна быть очень высокой.
Давайте в двух словах поговорим о недостатках и преимуществах данной модели.
Плюсы:
●
Отсутствует дублирование кода программы сервера программами клиента, так как все вычисления
выполняются на сервере, то требование к компьютерам, на которых установлен клиент, снижаются.
●
Все данные хранятся на сервере, который, как правило, хорошо защищен, лучше, чем большинство
клиентов, и на сервере проще организовать контроль полномочий, чтобы разрешать доступ к данным
только клиентам с соответствующими правами доступа. Обычно этим занимается отдельно выделенный
человек - системный администратор.
Минусы:
●
●
●
Если у нас, например, не работает сервер, то вся вычислительная сеть также не будет работать.
Для поддержки данной системы требуется отдельный специалист, системный администратор.
Серверное оборудование стоит очень дорого.
Также, говоря о клиентах и серверах, стоит поговорить о так называемой трехуровневой архитектуре. Т.е.,
если у нас есть только клиент и сервер, то такая архитектура двухуровневая, но когда у нас появляется база
данных, то это трехуровневая.
Например, если мы говорим о какой-то социальной сети, когда клиент отправляет информацию на сервер
с запросом того, что, например, ищет, и эта информация содержится в базе данных, то серверу необходимо
обратиться к ней, чтобы получить данную информацию, т.е. у нас добавляется дополнительно база данных и её
сервер, и тогда у нас есть вот этих три звена, т.е. информация с базы данных уходит обратно на сервер и через
сервер попадает обратно на клиент.
Часто на собеседованиях просят нарисовать такую схему клиент-серверной архитектуры, поэтому
запомните, чем отличается двухуровневая и трехуровневая схема.
Самым распространённым примером клиента является браузер. Все мы с вами знаем, что это такое.
Например, это google, chrome, либо сафари, либо mozilla, либо опера. Т.е. мы вводим туда какие-то наши
запросы, по сути, это то, что мы вводим в адресную строку, и этот запрос уходит на сервер.
Два типа клиентов - тонкие и толстые. Часто на собеседованиях просят привести примеры тонких и
толстых клиентов.
Тонкий клиент - это компьютер, либо же какая-то программа-клиент в сетях с клиент-серверной
архитектурой, которая переносит все или большую часть задач по обработке информации на сервер. Примером
такого тонкого клиента может быть браузер, который используется для работы с приложением. Почему его
называют тонким клиентом? Потому что вся основная бизнес-логика, все вычислительные мощности у нас
расположены на компьютере сервера. По сути, это какое-то простое программное обеспечение, которое
помогает нам отправлять запросы на сервер.
Толстый клиент. Если же мы говорим о толстом клиенте, то это такое приложение, которое обеспечивает
расширенную функциональность независимо от центрального сервера. Часто сервер в этом случае является
лишь каким-то хранилищем данных, а вся работа по обработке и представлению этих данных переносится на
машину клиента. Например, если взять такое сложное программное обеспечение, как 1с бухгалтерия, т.е. в нем
содержится вся основная бизнес-логика, на сервер у нас передаются только те данные, которые необходимо
сохранить в базе данных, либо же когда нам будет необходимо их получить обратно, отправить какой-то запрос
и получить из базы данных ответ. А всё остальное основное находится именно вот на этом толстом клиенте в
1с. Также к такому толстому клиенту можно отнести все онлайн игры. Иногда на собеседовании достаточно
просто назвать эти примеры, без каких-либо уточнений по поводу того, какая бизнес-логика содержится в
толстом и тонком клиенте.
Дальше мы с вами разберемся, что же такое запрос, из чего он состоит, что вообще мы можем отправлять
на сервер, в каком виде эта информация приходит к нам на клиент, как мы можем это посмотреть, используя
встроенные инструменты в браузерах наших клиентов, сможем протестировать какие-то веб-сервисы и вообще
в целом узнаем как тестировать веб-сайты.
Веб-сайты обычно носят какой-то информационный характер, т.е. они состоят из неких веб-страниц,
объединённых друг с другом в единый ресурс, имеют какую-то простую архитектуру на основе html кода. Такие
вот веб-сайты, по сути, служат в качестве платформы для предоставления контента для посетителей, они
содержат какие-то текстовые файлы, изображения, возможно музыку. Сайты не предоставляют возможности
взаимодействия с нашей программой, т.е. пользователи не имеют доступа к размещению своей информации,
кроме как заполнение формы для получения, к примеру, подписки. Наиболее яркими примерами типичных
сайтов могут быть новостные, кулинарные сайты, прогнозы погоды.
Веб-приложения. В отличие от веб-сайта, веб-приложения - это такие интерактивные компьютерные
приложения, которые специально разрабатываются для сети интернет и позволяет пользователям вводить,
получать и манипулировать данными с помощью взаимодействия. Такие программы имеют очень тесную связь
с нашим сервером и отправляют на него очень много запросов. Такие приложения могут быть встроены в ПО
страницы, либо же сами веб-страницы могут являться приложениями. К ним можно отнести, к примеру, фейсбук,
gmail, youtube, ebay, twitter, различные соцсети. Тот же вконтакте, если взять приложение, используют имя
пользователя и пароль для аутентификации и позволяют своим посетителям обмениваться, например,
мгновенными сообщениями. Если мы говорим о соцсетях, либо же каких-то блогах - создавать контент на основе
пользовательских предпочтений, обеспечивать к нему неограниченный доступ, также там могут быть встроены
какие-то мини-программы для развлечений. И еще одно отличие от веб-сайтов то, что многие интернет
приложения могут не иметь реального информативного содержания. Что же это значит? Т.е. они используются
для выполнения каких-то дополнительных задач, т.е. это могут быть какие-то интернет переводчики,
мессенджеры, конвертеры файлов, конвертеры валют, все, что угодно.
Веб-сервисы. Если мы с вами вспомним один из первых уроков, посвященных уровням тестирования, то
один из них был интеграционный, и вот именно логика интеграционного уровня привязана к веб-сервису. Это
прикладной программный интерфейс (API), который работает на сервере и предоставляет клиенту данные через
http протокол, через стандартизированную систему обмена сообщениями. Веб-сервисы, в свою очередь,
подразделяются на SOAP и REST. Вам нужно знать, что в современном сценарии большинство сервисов
предпочитают использовать именно архитектурный стиль REST, потому что SOAP - это протокол, т.е. он какойто стандартизированный, а REST - он более гибкий, т.е. нет каких-то строгих правил, по которым мы должны с
ним сотрудничать и его использовать, поэтому он более интересен с точки зрения web-разработки. SOAP
является протоколом стандартизированным и он использует XML (расширенный язык разметки, он очень похож
на HTML). По объёму информации, которую мы вкладываем в SOAP - она намного больше чем в REST, там мы
используем json и объём информации немного меньше, т.е. мы можем здесь сократить время на вот эти все
ответы и запросы на сервер.
Просто запомните, что веб-сайты - это некие простые веб-страницы, которые представляют собой
информационную какую-то нагрузку, а веб-приложения уже позволяют пользователю взаимодействовать с
этими разными веб-страницами, вводить свои какие-то данные, взаимодействовать с контентом, а веб-сервис это наш какой-то прикладной интерфейс программы, который позволяет различным веб-приложениям
взаимодействовать между собой.
Урок 12. HTTP-протокол для чайников. Ошибка 404. Модель TCP/IP.
Методы HTTP.
https://www.youtube.com/watch?v=OA3jExxIkew
Продолжаем изучение тестирования web ориентированных приложений. и данный урок будет посвящен
HTTP протоколу. Мы поговорим о том, из чего состоит response, request, также затронем такую тему, как статус
коды, какие версии http протокола существуют, либо существовали, и еще о некоторых вещах, которые связаны
непосредственно с данным протоколом.
Для начала давайте разберемся, что же такое протокол? Протокол - это набор правил передачи
информации, т.е. с помощью протоколов мы регламентируем, как наша информация будет передаваться в сети
интернет.
HTTP протокол (HyperText Transfer Protocol - протокол передачи гипертекста) - это протокол
прикладного уровня.
Существует несколько моделей сетей. Есть модель OSI и модель TCP/IP, наиболее современная модель,
которая сейчас повсеместно применяется в сетях интернет. Модель OSI уже устарела и в рамках данного урока
мы не будем более подробно останавливаться на каждой из этих моделей, однако я расскажу вам то, что
необходимо знать для того, чтобы вы понимали, какие вообще протоколы есть, какие уровни есть в этих моделях
и к какому из них относятся эти все протоколы. Сейчас мы с вами видим две модели, которые я упомянул выше,
это TCP/IP модель (4 уровней) и OSI модель (7 уровней).
Первый уровень - это уровень сетевых интерфейсов, т.е. в данном случае передаются какие-то
физические импульсы, т.е. сюда можно отнести, например, оптоволокно.
Второй уровень - это уровень сетевой, т.е. здесь уже происходит передача физических сигналов в виде
битов или байтов, здесь уже, например, можно выделить такой протокол, как IP.
Третий уровень - транспортный уровень, здесь уже происходят какие-то транспортные взаимодействия
в нашей сети, здесь выделяют два вида протоколов - TCP и UDP. Стоит обратить внимание, что эти два
протокола отличаются между собой и частенько на собеседованиях спрашивают, чем именно. Если мы говорим
про TCP протокол, т.е. это такой надежный транспортный протокол, в результате которого при передаче файлов
происходит гарантия того, что информация доходит до нашего клиента. Если же в рамках передачи информации
происходит то, что информация не проходит, т.е. нет никакого убеждения и гарантии, что клиент получил эту
информацию, то происходит повторная отправка информации. Если мы говорим про UDP, то здесь не нужно
убеждаться в том, что наша информация дошла, т.е. это происходит непрерывным потоком. Информация
передается и нет никаких механизмов, которые говорили бы о том, что гарантированно наша информация
попала к клиенту, либо серверу. Это основное отличие этих двух протоколов. Если мы говорим про о UDP
протокол, то на практике он применяется, например, в онлайн-играх,где не нужно убеждаться в том, что
информация передалась от клиента к серверу. Если мы говорим про TCP протокол, то такой протокол может
применяться в почтовых сервисах, мы должны убедиться, что действительно наш клиент получил какое-то
письмо.
Четвертый уровень - это application (прикладной) уровень. Это специфический уровень для нашего
приложения. Т.е. уже то, как в нашем приложении происходят различные взаимодействия, - это самый
последний уровень.
И, как я уже сказал, http протокол относится именно к протоколам прикладного уровня. Давайте теперь
подробнее поговорим из чего состоит вообще http протокол, запросы и ответы.
Обязательно выделяют основную часть - payload, т.е., по сути, это то, что мы вообще должны передать.
Также основную часть еще называют полезной нагрузкой. Также в запросе, либо ответе могут находиться так
называемые header, либо заголовки. Это служебная информация, т.е. здесь уже описывается то, как наша
основная часть файла должна передаваться. Если мы говорим про http протокол и вспомним его полное
название - гипертекст трансфер протокол, то у вас могло закрасться сомнение, что мы должны обязательно
передавать гипертекст, т.е. какие-то текстовые файлы в полезной нагрузке в основной части, однако это не так.
На самом деле, в основной части можно передавать не только текст. Можно передавать картинки, можно
передавать какой-то код, т.е. все это также может быть зашифровано в нашей основной части.
Чаще всего ответы приходят в формате html, это такой специальный язык разметки. Я надеюсь, что все
мы с вами помним, чем отличается запрос от ответа. Запрос посылает клиент на сервер, а сервер в свою
очередь реагирует на запрос и отдает свой response, т.е. ответ.
Из чего состоит request: у нас указывается метод, далее идет версия нашего протокола, хост машина, т.е.
там, где вообще находится наше приложение, т.е. это наш сервер. Также в request у нас содержатся headers
(заголовки), как я уже сказал, это некая служебная информация, которая характеризует нашу основную часть.
Она как может быть, так может и не быть, они могут отличаться в каждом отдельном request. Также в первой
строке может содержаться URL, т.е. то, к какому ресурсу мы обращаемся.
Если мы говорим с вами про http response, то здесь у нас также содержится информация о версии
протокола, также содержится status code, который говорит об успешности того, как отвечает нам сервер. Каждый
status code имеет цифровое обозначение и текстовую информацию. Дальше у нас содержится дата, когда
вообще был отправлен ответ от сервера, информация о сервере и также какие-то хедеры, которые
характеризуют нашу основную нагрузку. Также здесь обычно ставится пустая строка и, если наш ответ содержит
в себе какую-то полезную нагрузку, то дальше идет информация именно с этой полезной нагрузкой. Например,
документ в формате html.
Вот так выглядят эти request и response. Давайте теперь более подробнее поговорим о составных частях
каждой из этих сущностей.
Во-первых, давайте поговорим о методах. Существует несколько основных методов, которые
используются при формировании запросов - get и post, самые основные два. Также есть метод PUT, DELETE,
CONNECT, они уже не всегда используются и не являются основными.
GET - его характеризуют именно запросы информации от нашего сервера, т.е. наш клиент просто
отправляет какую-то информацию, запрашивает ее от сервера.
POST - здесь уже происходит отправка полезной нагрузки на сервер. Т.е. у нас содержится вот эта
основная часть - payload, например, в теле нашего запроса, т.е. это может быть какая-то картинка, либо текст,
которые мы отправляем на сервер подобным способом.
PUT. Также действует метод PUT, т.е. тоже отправляется какая-то информация на сервер, обычно он
используется для того, чтобы у нас создавался какой-то объект на сервере.
DELETE, т.е. это удаление данных с нашего сервера, либо с сервера базы данных.
Еще один метод - это CONNECT.
Но, помимо http протокола, есть еще такой протокол, как HTTPS. Отличие этих двух протоколов в том, что
наша информация попадает на сервер в каком-то зашифрованном виде, поэтому чаще всего сейчас используют
именно https протокол, более надёжная информация, она зашифрована, какие-то злоумышленники не могут ее
получить так просто, поэтому обязательно обращайте внимание на это.
Возвращаясь к response, т.е. ответу от сервера, я упоминал такой аспект, как статус код и статус message.
Как я уже сказал, эти статус коды характеризуют успешность нашего обращения на сервер и действительно ли
он может дать нам ответ, либо есть какие-то преграды для этого. Существует пять основных групп - это 100,
200, 300, 400 и 500. 100 - информационные какие-то сообщения, 200 - сообщения об успехе операций, 300 сообщение о перенаправлении, 400 - ошибки на стороне клиента, 500 - ошибки на стороне сервера. Нас, как
тестировщиков, в первую очередь интересует 200, 400 и 500, так как они говорят о том, что у нас происходит,
какие-то критические ошибки.
200. Основной код, который нас интересует - 200, который говорит о том, что все прошло успешно как на
стороне клиента, так и на стороне сервера. Т.е. сервер обработал наш запрос от клиента, дал на него ответ и
действительно у нас произошел некий success.
300 - говорит о том, что информацию нам сервер вернул в ответе, однако он нашел ее в другом месте,
здесь нас будет интересовать такой код, как 301 - т.е. клиент обратился к какой-то странице, однако данная
страница перемещена и находится по новому адресу, сервер это дело смог переварить и в хедере он вернул
новый адрес. Чем плохи 301 ошибки? Мы должны всегда обращать на них внимание, потому что это
потенциальные угрозы, у нас не всегда может содержаться информация о новом адресе нашего ресурса, т.е.
она может просто куда-либо пропасть, и тогда 301 ошибка может перерасти в более серьезную ошибку,
например в 404. 304 код тоже важен, это код not modified, как вы знаете, информация о наших сайтах хранится
в кэше, т.е. на локальном нашем компьютере. Для того, чтобы в дальнейшем, когда клиент обращался к серверу,
не проходила загрузка дополнительных ресурсов, т.е. эта информация сохраняется в кэш, информация о нашем
сайте, какие-нибудь картинки, и берет информацию уже с локальной машины. И вот именно 304 код not modified
говорит о том, что информация о данном сайте хранится в кэше, и в таком случае при запросе на сервер он
может вернуть эту ошибку и забрать какую-то полезную нагрузку уже с нашего локального компьютера, да он
может, в принципе, эту нагрузку не забирать и заново подгрузить там какие-то данные сервера, это очень хорошо
для производительности, если у нас действительно работает кэш.
400 - это ошибки на клиенте. Если мы говорим об основных, на которые стоит обратить внимание, - это
непосредственно сама 400 ошибка, которая говорит о том, что запрос не смог быть обработан сервером, он был
составлен неверно, и в случае такой ошибки необходимо обязательно скопировать всю информацию о данном
запросе в наш баг-репорт, чтобы разработчик, получив информацию о данном отчете, о данном дефекте, смог
без труда понять, в чем кроется основная причина данного бага. 401 - характеризует то, что мы ввели какой-то
неправильный логин и пароль, и тогда наша система ругается. 403 говорит о том, что даже при том условии, что
мы вели правильный логин или пароль, наша система ввела какие-то restriction, или у нас есть ограничения,
возможно у нас не хватает прав для того, чтобы зайти на тот или иной ресурс. Если, например, у вас в системе
есть разные роли: просто пользователь, модератор, администратор, то нужно обязательно проверять этот факт,
что когда мы вводим пароль и логин, например, пользователя, он не может вносить какие-то существенные
изменения в работу нашего сайта. 404 - когда наш клиент обращается к ресурсу, которого уже нет на сервере.
500 - если мы видим эту ошибку, то мы обязательно должны завести баг - critical или blocker, т.е. в данном
случае что-то произошло на сервере, какая-то фатальная ошибка, которая не позволяет ему ответить на ваш
запрос, поэтому это очень серьезно для нашего программного обеспечения.
И последнее, о чем я хотел поговорить сегодня, это о версиях http протокола. Как я уже сказал, эта
информация есть как в request, так и в response. Самая первая версия http протокола 0.9, т.е. даже не 1. Потому
что эта версия была придумана стихийно и ей просто не могли присвоить какой-то определенный номер, затем
уже была версия 1.0, т.е. когда уже были какие-то стандартизированные вещи, в ней не было информации о
методах гет, пост и пут и уже потом была версия 1.1. Если мы говорим о версии 2.0 - его придумала компания
google для того, чтобы поднять производительность данного протокола, так как уже на этапе современных
технологий данный протокол не устраивал. Но в дальнейшем все остальные компании подхватили, поняли, что
необходимы какие-то улучшения версии и данный протокол взяли и стандартизировали, и теперь он называется
http 2.0.
HTTP 1.1:
●
●
●
использует текстовый формат, из-за чего намного больше места занимает и дольше передается, это
влияет на производительность.
Если мы изучим различные реквесты и респонсы, то там часто встречаются сдваивания заголовков.
Каждый наш запрос, будь то отправка html-кода, отправка css, отправка java скрипта, они проходят по
отдельному TCP соединению. Если мы с вами вспомним про транспортный протокол, т.е. каждый запрос
- это отдельные соединения. Все запросы идут друг за дружкой, т.е., например, сначала мы получаем
какую-то текстовую информацию html, затем мы получаем информацию о стилях css, затем мы получаем
информацию по javascript по какому-то динамическому обновлению нашей страницы, и вот эти все
соединения проходят друг за другом.
HTTP 2.0:
●
●
использует бинарный формат, т.е. нули и единицы. Как вы понимаете, использование нулей и единиц
намного уменьшает количество той информации, которую необходимо передавать на сервер и серверу
передавать обратно на клиент.
Сокращение информации за счёт сжатия заголовков.
●
●
Все запросы проходят по одному единственному TCP соединению, т.е. нет такого различия, какую
информацию передают они на сервер, они всегда идут по одному соединению.
Мультиплексирование. Есть одно соединение и информация передается одновременно, как со стороны
запроса, так и со стороны ответа от сервера. Всё происходит одномоментно.
Урок 13. URL адрес. Что такое IP адрес и маска подсети? DNS сервер. Кэш
и куки.
https://www.youtube.com/watch?v=6gZ2OKkKzjw
На сегодняшнем уроке продолжим изучение тестирования web-приложений и поговорим об основных
понятиях, которые облегчат для вас понимание этой предметной области и дадут необходимую теоретическую
базу для продолжения нашей с вами совместной работы.
Начнем с простого, давайте представим, что мы открываем браузер, и что мы делаем в первую очередь?
Скорее всего вводим в адресную строку URL (Uniform Resource Locator) - это уникальный адрес сайта в
сети, который определяет его местонахождение в сети интернет. Также существует еще два понятия - URN
(Uniform Resource Name) и URI (Uniform Resource Identifier).
URN - это неизменяемая последовательность символов, определяющая только имя некоторого
ресурса. Это имя определяет только название самого ресурса, но не говорит как к нему подключаться.
URI - наш какой-то уникальный идентификатор, это обобщенное понятие множества
идентификаций нашего ресурса, которая включает как URL, так и URN, и может включать их по
отдельности, либо же все вместе. Т.е. мы можем считать, что идентификатор - это наш локатор, либо же
идентификатор - это имя, либо же идентификатор - это и наше URL и URN.
Давайте посмотрим на примерах, чтобы вам было более понятно, как между собой отличаются эти три
вида сущности. Наш локатор (URL) определяет способ, как мы к нему будем заходить, и саму адресную строку,
т.е. непосредственно адрес местонахождения в сети. Если мы говорим про имя (URN), то нас не интересует
способ, как мы будем вот к данному файлу приходить, нас интересует, в первую очередь, только его название,
поэтому название протокола и непосредственно адреса нас в данном случае не интересует. Идентификатор
(URI) - включает в себя как локатор, так и название, но также может включать их по отдельности.
Раз мы заговорили про адреса, то, конечно же, если мы говорим о сети интернет, то необходимо обратить
внимание на ip-адрес. Что же это такое? IP-адрес - это уникальный сетевой адрес узла в компьютерной
сети, построенный по протоколу ip. IP-адрес представляет собой 32-битовое (по версии ipv4), либо же 128битовое (по версии ipv6) двоичное число. Вот у нас здесь есть четыре двоичных числа, каждое из которых может
включать в себя 8 битов. Всего таких кластера 4, поэтому 32 бита, либо же 4 байта. Но использовать двоичную
систему счисления для записей адреса не очень удобно, они получаются громоздкие, поэтому чаще всего ipадрес вы видите в виде десятичных чисел, т.е. их просто переводят в них. И каждое такое десятичное число не
может быть больше 255.
Иногда на собеседованиях могут спросить - как переводить ip-адреса из десятичной системы счисления в
двоичную и наоборот. Давайте с вами рассмотрим, как это легко и просто можно сделать. Давайте с вами
переведем число из десятичной системы счисления в двоичную. Для примера возьмем 19. Как это можно
сделать, не используя калькулятор, либо же конвертер? Для этого мы берем само число 19 и делим его в столбик
на 2. Здесь действуют обычные правила арифметики, т.е. если мы не сможем делить это число без остатка, то
мы берем максимально приближенное к нему, которое делится на 2, записываем его, и этот остаток у нас будет
единица. Дальше то число, которое у нас получилось в результате деления, в данном случае 9, опять делим на
два, опять повторяется такая ситуация, т.е. мы опять записываем максимально приближенное число и в остатке
у нас остаётся единица. Так мы продолжаем делать вплоть до того, пока у нас не получится так, что мы не
сможем дальше продолжать наше деление на 2. Т.е. в данном случае у нас последней оказалась единица, когда
мы делим её на 2, мы получаем число не целое - 0,5, записываем это как 0. Пишем в остаток этот ноль. Мы не
учитываем последнее, а учитываем только то, что у нас спокойно делится на двойку, и дальше мы записываем
это число, начиная с самого последнего получившегося - к самому первому. это число у нас и получится в в
двоичной системе. Надеюсь, что вам понятно, как это сделать. Если же мы говорим про обратную ситуацию,
когда нам нужно из двоичной системы перевести в десятичную, тогда мы берем наше число в двоичной системе
и, начиная с последнего, нумеруем его, т.е. 0, 1, 2, 3, 4, всего у нас пять цифр в данном числе. Дальше мы
начинаем умножать наши цифры в этом числе на двойку в той степени, которая будет указана сверху, т.е.
порядковый номер данного числа. После этого мы плюсуем все значения, которые у нас получились, и получаем
наше число в десятичной форме.
Следующий аспект, который я хотел бы затронуть в рамках ip-адреса, это маска подсети. Когда ip-адрес
присваивается интерфейсу, например, сетевому адаптеру компьютера или маршрутизатора, то кроме самого
адреса данного устройства (ip-адреса), ему назначают еще и маску подсети. Компьютерная маска подсети нужна
для определения границ самой подсети, чтобы каждый мог определить, кто находится с ним в одной сети
подсети, а кто за ее пределами. Маска подсети, по сути, это тоже 32 бита, но, в отличие от ip-адреса, нули и
единицы в ней не могут чередоваться. Всегда сначала идут несколько единиц, потом несколько нулей.
Например, если мы с вами посмотрим на маску подсети (subnet mask), то, как увидите, у нас сначала прописаны
только единицы, а потом 0. Т.е. такого, как в ip-адресе у нас быть не может, когда есть чередование. Я думаю,
что после рассмотрения ip-адреса вам стало понятно, что такая запись в двоичной системе исчисления не очень
удобна, поэтому используют упрощенную версию. Прописывают просто количество единиц, которые у нас есть
в маске подсети, т.е. здесь у нас их 25, поэтому после ip-адреса могут поставить “/25”. Думаю, что те, кто когдалибо настраивал браузер, либо же подключение к сети в системе windows, то вы обращали внимание на ipадреса и на то, как там прописывается маска подсети. Т.е. иногда можно встретить такую запись через “/” и
прописано количество вот этих самых единиц, которые у нас содержатся в маске подсети. Но также вы могли
встретить и другую запись, когда у нас не прописывается через “/” эта маска подсети, а вообще прописана
граница нашей подсети вот в таком вот виде. Здесь уже учтена и маска подсети, и сам ip-адрес. Как вообще
происходит определение границ подсети? Берется наш ip-адрес, берется маска подсети и каждая цифра,
которая содержится в этих адресах, перемножается друг на друга. В итоге у нас получается вот такая вот запись,
которую в дальнейшем также переводят в десятичную систему счисления для удобства записи.
Когда говорят про ip-адрес, есть статический и динамический. Динамический ip-адрес - назначается
автоматически при подключении устройства к сети и используется в течение ограниченного промежутка
времени, как правило, до завершения сеанса подключения. Со статическим такого не происходит. У нас он
всегда один.
Также стоит упомянуть еще и такое понятие как mac-адрес. Это физический адрес нашего устройства, он
прописывается при производстве сетевой карты. Т.е. если у вас на собеседованиях спросят сколько вообще
mac-адресов есть системе, то вы всегда должны сказать, что столько же, сколько сетевых карт у нас установлено
в оборудовании, которое к этой системе принадлежит. Т.е. если у нас есть сетевая карта в нашем принтере, то
она тоже будет с mac-адресом и учитываться в этом общем количестве. Т.е. не всегда верно говорить так, что
если у вас, например, есть сетевая карта в компьютере, которая отвечает за наше подключение через вай-фай,
то она одна. Всегда считаем все устройства, которые подключены к компьютеру и у которых есть mac-адрес, т.е.
они могут выходить в сеть.
Теперь мы с вами знаем, что же такое ip-адрес, т.е. это уникальный номер каждого устройства в сети
интернет. Чтобы попасть на сайт, нам необходимо знать ip-адрес устройства, на котором расположен данный
сайт. Давайте с вами представим, сколько вообще сайтов вы посещаете каждый день? Если бы они все были
зашифрованы в этом цифровом виде, в виде ip адресов, то представьте, какое количество цифр вы должны
были бы держать в своей голове, это нереально. Поэтому для нашего удобства, для удобства в работе в сети
интернет, еще в 80-х годах была создана система доменных имен (dns domain name system). Смысл её в
том, что каждому цифровому ip-адресу присваивается понятное буквенное имя, либо же его еще называют
домен. Т.е. когда вы вводите в браузере доменное имя, вот эти сервера dns преобразуют его в ip-адрес. Т.е. у
каждого нашего домена, у каждого нашего URL, есть соответствующий ip-адрес сервера. С помощью dns эта
информация в буквенном значении преобразуется в числовое, и уже севера могут понимать что от них хотят и
какую информацию хотят получить. Поэтому мы получаем уже информацию от серверов в этом буквенном виде
с помощью преобразования в dns.
И последняя часть нашего занятия будет посвящена кэшу браузера и cookies. Что же такое кэш браузера
и для чего он вообще необходим? Когда вы серфите на просторах интернета, загружаете, просматриваете вебстраницы, ваш браузер автоматически сохраняет определенные данные на жесткий диск вашего компьютера.
Это могут быть различные элементы дизайна сайта - картинка, изображение, видеофайлы, музыка и так далее.
Это делается для того, чтобы при следующем обращении к странице она загрузилась быстрее, благодаря тому,
что часть информации загружается уже не с сервера, а непосредственно с вашего жесткого диска. Это и есть
наш кэш, т.е. это данные, которые загружаются с нашего компьютера для того, чтобы упростить нам работу на
тех сайтах, которые мы раньше посещали, т.е. ускорить ее и не загружать так сервер, как это могло бы быть,
если бы вы каждый раз обращались к нему в поисках необходимой информации.
Если же мы говорим про cookies, то это тоже временные файлы, которые хранятся на жестком диске
компьютера пользователя, однако cookies служат для хранения персональных данных пользователя. Что же это
может быть? Это могут быть данные авторизации, наш логин и пароль, настройки на определенных сайтах, ваши
предпочтения. В тот момент, когда мы заходим на страницу, браузер отсылает эти данные на сервер, благодаря
чему мы, например, сразу попадаем на нашу личную страничку социальной сети без необходимости постоянного
ввода логина и пароля на странице авторизации в данную сеть. Также эти данные могут учитываться при выдаче
вам контекстной рекламы, т.е. они тоже сохраняют ваши предпочтения в браузере, и на основании них уже будет
подбираться та реклама, которая вам будет интересна в первую очередь.
Урок 14. Что такое DevTools для тестировщика? Инструменты
разработчика Chrome.
https://www.youtube.com/watch?v=a3vRm9neKhs
Сегодня мы с вами поговорим о devtools. Это специальный пакет для разработки web-приложений, также
он используется для тестирования и встроен непосредственно в сам браузер, будь то google chrome, либо же
mozilla. Сегодня будем рассматривать именно этот инструмент в рамках браузера google chrome, так как он
является на данный момент самым распространенным, самым используемым. Почему мы будем с вами изучать
данный инструмент? Так как он достаточно распространен в среде разработки, помогает разрабатывать
приложения, тестировать их.
На chrome devtools написана отличная документация, вы можете прочитать, изучить, узнать все фичи,
которые предполагают использование именно devtools (https://developers.google.com/web/tools/chrome-devtools).
Как же нам вызвать chrome devtools? Есть несколько способов. Самое простое, это нажатие правой
кнопкой мыши и нажать “просмотреть код”, либо клавиша “f12”. Вам откроется html-файлик на том элементе,
который вы хотели проинспектировать, т.е., если вы нажимаете “просмотреть код”, то открывается строка, в
которой прописано, как этот элемент должен выглядеть на странице.
Elements - можно посмотреть вообще как он записан в верстке в файле, просмотреть его размеры. Также
вы можете непосредственно здесь изменять сам этот файлик, изменение в данном коде, в данном атрибуте,
будет непосредственно отображаться уже и на вашей странице.
Например, если мы с вами просмотрим код какого-нибудь заголовка и начнем его изменять, например,
уберем слово “мобильные”, то изменится и информация на самой странице. Таким образом можно тестировать,
например, заголовки, когда вы вводите большое количество символов и как они будут отображаться, не будут
ли они заезжать на другие элементы на странице. Это используется в тестировании.
Styles, здесь уже будет непосредственно информация о CSS, о дизайне эти всех элементов, т.е. будут
описаны размеры, шрифты, которые используются при написании. Т.е. когда вы будете тестировать UI (user
interface), открывать какие-то mockup и шаблоны вашей страницы, которые вам предоставили дизайнеры, на
них также будет указана информация о том, какие шрифты, какого размера, какие картинки должны
использоваться, и вы должны обязательно проверить, действительно ли разработчик учел это при написании
кода, при верстке данной странице. Вы просто сравниваете, если это так и совпадает с нашим
непосредственным шаблоном.
Console. В консоли у нас прописываются ошибки javascript исполнения и вообще в этой консоли можно
исполнять различные скрипты, написанные на javascript. В дальнейшем мы это обязательно все должны изучать,
и в случае обнаружения таких ошибок, нам необходимо заводить баги. Вы непосредственно пишите, при каких
условиях воспроизводится та или иная ошибка, которая отображается в консоли, т.е. что вы открыли, какие шаги
воспроизведения, и затем копируете просто всю информацию, которая у вас есть в консоли по данной ошибке,
и прикрепляете эту информацию к багу. Разработчик уже в дальнейшем, получив эту информацию, может ее
обработать и узнать, в чем кроется основная причина. Т.е. нам, как мануальным тестировщикам, особенно на
уровне джуна, не нужно знать все особенности java скрипта, как он у нас обрабатывается, почему возникает
такая ошибка, это уже задача разработчика. Нам главное найти эту ошибку, оформить, написать отчет, багрепорт и посмотреть, действительно ли разработчики пофиксили ту или иную ошибку. Все ошибки мы
обязательно должны репортить с северити critical, либо же blocker, в зависимости от того, какие у вас есть
северити на проекте. Если есть какие-то варнинги (warning), здесь они выделены желтым цветом, их тоже нужно
обязательно репортить, так как они в дальнейшем могут привести к каким-то серверным ошибкам серьезным,
поэтому тоже их оформляем в наших баг-трекинговых системах. Обычно все эти ошибки прописывают сами
разработчики, т.е. они не используют дефолтные, но если разработчик ленится, тогда уже используете
дефолтные ошибки, которые наш браузер может выдавать нам.
Sources. Здесь у нас информация о серверах, к которым обращается наш клиент, есть информация,
которая находится непосредственно на сервере самого сайта, но также, например, какие-то картинки, либо же
информация о курсах валют, возможно медиафайлы, берутся из других каких-то серверов, поэтому здесь также
можно посмотреть откуда они берутся.
Network - Самая главная вкладка, которая используется при тестировании. Здесь у нас находится
информация об общении нашего сервера и клиента. Это важная вкладка, потому что здесь мы можем видеть
запросы, которые отправляет клиент, и ответы, которые возвращает сервер.
XHR - содержится информация о запросах напрямую к веб-серверу и загрузка самих ответов с этих
серверов, которые напрямую вызывают скрипты. Это наша основная вкладка внутри network. Также здесь есть
вкладка
ALL - отображаются запросы всех типов.
JS - информация о java скрипте, который у нас запускается на странице.
CSS - информация непосредственно о css.
IMG - информация о картинках.
MEDIA - информация о различных медиа файлах.
FONT - информация о шрифтах.
DOC - это та информация, которую мы вводим в адресную строку и отправляем запрос на сервер.
WS - это websocket, протокол, который позволяет обмениваться сообщениями между браузером и
сервером в режиме реального времени, т.е. здесь отображаются сообщения нашего клиента и сервера.
Manifest - это специальные json файлы, специальная информация о нашем веб-приложении для нашего
браузера.
OTHER - всё остальное.
Возвращаясь к XHR, т.е. нашей основной вкладке, в которой мы работаем в network, то здесь мы видим
непосредственно название нашего запроса, метод, который использует наш http запрос, статус код, который
возвращает сервер, версия протокола, тип, инициатор - файлы и сайт, который инициировал данный запрос,
size - размер, time - время на обработку, и waterfall - показывает как у нас вообще развивались события, тут
можем увидеть сколько времени вообще было потрачено на отправку запроса, на получение ответа от сервера,
т.е. можно это все тоже анализировать для того, чтобы понимать, если у вас какие-то проблемы с
производительностью.
Также здесь есть такой checkbox “disable cache”, мы отключаем сохранение кэша на данной странице.
Это нужно для того, чтобы мы с вами при тестировании, когда отправляем какие-то запросы, не использовали
те данные, старые, которые могли как-то повлиять на дальнейший исход нашего с вами какого-то действия.
Поэтому кэш отключают.
Preserve log - это запись нашего лога, т.е. логирование процесса для того, чтобы ошибки, которые
появляются в результате нашей работы, мы могли сохранить в этот лог и передать его разработчику для
дальнейшего анализа.
Также есть возможность имитации различных условий, т.е. мы можем выставлять так, как будто бы у нас
быстрый 3g интернет подключен, либо медленный 3g, либо вообще мы в режиме оффлайн, что вообще будет
происходить в нашей странице, какие статус коды будут посылаться, все это можно здесь настраивать. Не
нужно, например, подключаться к специальному какому-то выделенному сетевому адаптеру, который
использует, к примеру, 3g, либо 4g, либо вай-фай.
Perfomance. Необходима для того, чтобы мы с вами следили за быстродействием работы нашего сайта.
Нажимаем рекорд, обновляем нашу страницу и нажимаем стоп. Здесь вы сможете увидеть информацию о том,
за сколько времени происходили те или иные процессы на нашем сайте. Loading - это время загрузки нашей
страницы. Scripting - это время работы скриптов на нашей странице, каких-то математических расчетов.
Rendering - это время процесса рендеринга, т.е. расположение бесцветных слоев и блоков на нашей странице.
Painting - это уже когда эти бесцветные слои, блоки и раскрашиваются. System - это некие системные процессы.
Idle - это время бездействия вообще которое у нас было за время нашей записи.
Security. Здесь вы можете посмотреть вообще какие у вас протоколы применяются на той странице,
которую вы тестируете, http или https. Например, если у вас на проекте есть какая-то финансовая информация,
пароли, адреса, явки, то небезопасно передавать эту информацию через http протоколы. Т.е. когда вы изучите
эту информацию, увидите, что у вас есть действительно есть такие сайты, к которым обращается
непосредственно этот ресурс, который вы тестируете, эти сайты используют протокол http, то вы также должны
сообщить об этом разработчику, что используется потенциально небезопасный протокол на вашем сайте и
нужно что-то с этим делать. Лучше еще раз переспросить у разработчика, бизнес-аналитика продукт оунера,
действительно ли можно использовать этот протокол непосредственно на данном сайте и не является ли это
проблемой.
Также есть возможность имитировать различные среды просмотра сайта - например, как он будет
видеться на экране телефона, можно выставлять скорость интернет соединения, активировать различные
сенсоры и датчики и т.д.
Урок 15. Основы HTML и CSS для тестировщика.
https://www.youtube.com/watch?v=IOk-S5h8rpc
Начнем с HTML. HTML говорит браузеру о том, какие элементы должны быть на странице, т.е. именно с
помощью него мы прописываем какие-то текстовые блоки, информацию в них, как они должны отображаться на
нашей странице, т.е. верстаем наш сайт. Плюс ко всему, можно задавать также какие-то стили простые,
описывать шрифты, добавлять какие-то элементы на страницу, либо же добавлять картинки. Но именно
кастомайзить по-крупному нам позволяет СSS.
HTML (HyperText Markup Language) - это язык гипертекстовой разметки. Сразу хочу отметить, что
HTML не является языком разработки, языком программирования. Поэтому не ведитесь на то, когда вас спросят,
например, какие языки программирования вы знаете, не нужно говорить HTML. HTML это подвид XML (eXtensible
Markup Language), т.е. это расширенный язык разметки и он используется для тестирования API, он
прописывается в SOAP протоколе.
Единица информации в HTML - это тэг, который обрамлен в скобки, <tag>.
<a> - это тэг гиперссылки, т.е. мы здесь можем прописывать гиперссылки.
<b> - говорит о том, что наш текст должен быть написан жирным шрифтом. И у таких тегов должна быть
закрывающая часть со слешем, <b>бла бла бла</b>. Между нашими двумя тэгами содержится какая-то
информация.
Но также есть тэги, которые не нужно закрывать. Например, к таким можно отнести тэг <input/>, тэг <img/>,
т.е., как вы видите, необходимо просто поставить перед второй скобкой закрывающий слэш.
В чем же отличие таких вот тэгов с закрывающим элементом и тэгов без него? В том, что если между
этими тэгами заключается какая-то информация, например, если мы говорим о тэгах <b>, которые говорят о
том, что шрифт наш жирный, то здесь может быть какой то текст <b>бла бла бла</b>, и этот текст и будет
жирным шрифтом у нас отображаться на странице.
<input/>, например, говорит о том, что это поле ввода, т.е. говорит о том, что у нас на странице
отображается поле для ввода.
Если мы говорим про <img/>, то тогда необходимо добавить какой-то атрибут со ссылкой на нашу
картинку.
Что же такое атрибут? Он используется для того, чтобы уточнить информацию. Как я уже сказал,
например, расположение нашей картинки. Если мы говорим про атрибуты тэга гиперссылки <a>, т.е. такой
атрибут <a href=”ya.ru”>Яндекс</a>. На странице, которую мы верстаем отобразится вот этот Яндекс в виде
гиперссылки, т.е. он будет синим шрифтом подчеркнут, и при нажатии на эту гиперссылку, которая у нас ya.ru,
мы перейдем на этот сайт. Есть такой атрибут как src, это уже ссылка на нашу картинку, т.е. информация о
расположении данной картинки либо же в нашем локальном сервере, либо же в сети интернет. <img
src=”c/img/1.png>, тогда на наш сайт ставится картинка, которая находится вот поэтому расположению.
Также немаловажно знать о том, какая структура есть у html документа.
Html разметку очень редко используют для целей тестирования фронтенда. В основном это будут какието mockup, по которым вы будете смотреть размеры тех или иных элементов, инспектировать с помощью наших
devtools эти элементы, смотреть их размеры, смотреть шрифты, которые там используются, смотреть какие-то
расстояния от одного элемента до другого, т.е. это все расписано во всех инструментах для разработки и
дизайна и мокапов. Т.е. никаких проблем у вас с этим возникнуть не должно.
CSS (Cascading Style Sheets). Формальный язык описания внешнего вида документа, который написан
на HTML. Простыми словами - это то, как должны выглядеть элементы на нашей странице. CSS может
задаваться в трех разных местах.
Во-первых, можно задавать внутри самого html, внутри тэга style. <style></style> внутри этого тэга будет
расписан, например, размер шрифта, расположение этого элемента на странице и др.
Второй способ - это внутри атрибута, <img style=”background-color: black;”/>.
Третий способ - это когда мы задаем какие-то стилевые особенности внутри отдельного документа,
например style.css. Т.е. расширение этого документа css и мы внутри нашего html делаем ссылку на этот
документ с помощью тэга <link>. Посмотреть CSS можно в девтулс браузера - “Elements-Styles”.
Урок 16. Тестирование полей ввода и тестирование веб-форм.
https://www.youtube.com/watch?v=ZCdw3Js887E
Сегодня мы узнаем, как можно тестировать различные веб-формы. Этим занимаются все начинающие
функциональные тестировщики. У каждой формы есть свои особенности в тестировании. Чтобы понимать,
например, как тестировать текстовые поля, либо же какие-то текстовые области, необходимо для начала
разобраться в вопросе валидации. На страницах существует два типа валидации.
Валидация на стороне клиента и валидация на стороне сервера. Когда мы говорим про клиентскую
валидацию, то эта валидация происходит до момента отправки запроса на сервер. Т.е., к примеру, у нас есть
текстовое поле, в которое мы можем вводить имя и фамилию. У этого поля есть ограничения на количество
введенных символов, например, 15 символов. Если мы вводим, например, 16 символов, то система ругается,
выдает валидационное сообщение, какое-то всплывающее окно, оно нам показывает, что количество символов
в это поле максимально можно ввести 15. Это валидация на стороне клиента. Т.е. еще до того момента, как наш
запрос попадает на сервер, клиент уже это обрабатывает и говорит нам о том, что у нас есть какая-то ошибка.
Это прописывается в самом коде при разработке фронтенда, и такая валидация считается не самой лучшей.
Поэтому всегда есть серверная валидация, потому что на стороне клиента мы можем изменять нашу
верстку, как мы с вами уже видели на примере html, мы можем вводить какие-то данные, менять те же самые
валидационные сообщения, которые отображаются на фронтэнде и регулировать количество символов.
Поэтому на севере всегда есть своя валидация, которая также проверяет, что, например, в поле “имя” у нас
введено не больше 15 символов и действительно такая информация может быть обработана сервером. Если
же в это поле у нас введено 16 символов, этот запрос попадает на сервер, и сервер возвращает уже свою какуюто ошибку, например status code о том, что у нас введено большее количество символов, и данный запрос не
может быть обработан сервером.
Поэтому всегда должна быть и валидация на стороне клиента и валидация на стороне сервера. И всегда
мы должны проверять тот факт, что и клиент обрабатывает эту валидацию, если у нас это прописано в
требованиях, и также сервер. Т.е. не может быть такого, что на клиенте, к примеру, у нас показывается
валидационное сообщение об ошибке, что у нас здесь большее количество символов, чем запланировано, т.е.
вместо 15 - 16, но север эту информацию благополучно обрабатывает и не понимает, что это ошибка, т.е. это
уже будет критичный баг, потому что такие ошибки на сервере могут быть, к примеру, связаны с безопасностью.
Теперь же давайте перейдем непосредственно к самим формам, которые у нас могут быть применены на
сайте при разработке дизайна, при написании нашего кода, и как мы можем эти формы проверять, какие мы
должны проводить обязательные проверки.
Text Field. Первое поле, о котором я уже немножко поговорил, это просто наше текстовое поле, куда мы
будем вводить некий текст. Что здесь мы должны проверять? Как вы видите, эти два поля у нас обязательные,
поэтому логично предположить, что одна из проверок будет связана с тем, что мы оставляем какое-то из полей
пустым, либо же два поля мы оставляем пустыми. Например, пытаемся зарегистрироваться в систему, система
должна нам показать какую-то информацию об ошибке, что эти поля обязательные и должны быть заполнены.
Т.е. проверяем каждое из этих полей и два поля вместе. Также у нас, скорее всего, здесь будет ограничение на
количество символов, как я уже говорил ранее в примерах клиентской и серверной валидации, и здесь мы
должны ввести количество символов, которое будет превышать этот допустимый лимит, либо же быть равным
этому лимиту, и обязательное значение, которое будет на 1 меньше, чем допустимый лимит (тестирование
граничных значений). Что же касается минимальных значений, которые мы можем ввести в это поле, проверяем
значение от минимального -1, значение, на самой границе и значение минимальное + 1. А если, например, здесь
прописано, что можно вводить только латинские символы, то мы должны проверить и другие символы,
например, кириллицу. Как будет система реагировать на данный ввод, будет ли показывать какие-то
валидационные сообщения о том, что в данное поле можно навести только латинские символы. То же касается
различных цифр, каких-то спецсимволов. Также мы можем ввести “пробел”. Нужно проверить при вводе 1
пробела в начале, 1 пробела в конце, попробовать ввести пробелы в середине нашего ввода. Также, говоря о
безопасности, мы обязательно должны проверить ввод различных тэгов. Злоумышленник может
воспользоваться этим и ввести сюда какой-либо зловредный скрипт, который, к примеру, будет получать вашу
информацию при вводе ее непосредственно в это поле. Поэтому мы обязательно проверяем этот факт. Также
проверяем тэги, например, <b>, жирный шрифт, не срабатывает ли наша система, т.е. скушает ли она этот тэг,
и, к примеру, не сможет ли она отобразить введенные нами значения жирным шрифтом. Опять же, это будет
показывать на то, что система понимает эти тэги, и не воспринимает их, как просто текст. Т.е. это, опять же,
потенциальные наши проблемы, связанные с безопасностью. Также в этих полях необходимо проверять
обязательно ввод наших данных из буфера обмена (ctrl+c, ctrl+v).
Text area. Те же самые правила применены и каким-то текстовым областям. Т.е. текстовое поле у нас,
например, ограничено на количество символов 15, а текстовая область - это уже некая большая область, куда
мы можем ввести большой текст. Обычно эти области также могут растягиваться, т.е. здесь будет треугольник
в углу, за который можно растягивать область, мы должны это проверить. На сколько она растягивается, как
текст адаптируется под размеры этого поля.
Link Prefix. Префиксы при ссылках. Обычно это название протоколов http://, ftp://, https:// и др. Мы
проверяем тут факт, когда оставляем пустым это поле, т.е. не вводим какой-то префикс, либо же вводим его, и
различные виды протоколов. Если, например, мы знаем, что наш сайт работает на https, поэтому мы вводим
сюда https. Если мы сюда, к примеру, введем ftp и ссылку на наш сайт, то, по идее, система должна показать
нам какое-то валидационное сообщение и не найти этот сайт, потому что здесь уже применен другой протокол.
Link. Непосредственно саму линку можем проверить. Здесь уже мы вводим с нашим www, без него,
вводим максимальное количество символов, которые можно ввести в это поле, если она ограничена, опять же,
вспоминаем наши проверки на границах, минус 1, плюс 1 и на самой границе, вводим какие-то русские символы,
к примеру, если у нас система их может скушать и обработать, то ок, если нет, то должна появиться какая-то
ошибка, либо же загружаемый нами ресурс должен показать какое-то сообщение, либо status code о том, что
данная страница не найдена. Всё будет зависеть от того, насколько у вас прописана клиентская валидация.
Обычно всё это прописано в требованиях. Т.е. вы открываете требования и, судя по ним, решаете, что у вас
должно появляться, является ли это багом. Если в требованиях, например, не прописано, что когда вы вводите
русские символы, система не выдает валидационное сообщение, но хорошей практикой является то, чтобы это
сообщение появлялось и предупреждало о том, что вы вводите русские символы в это поле, то вы можете
придумать такой improovement и занести его в систему баг-трекинга, и, возможно, в будущем его рассмотрят и
напишут требования о том, что да, действительно, это сообщение должно появляться. Всегда помним о том, что
мы работаем над улучшением нашего качества, и это не только то, что мы находим какие-то баги, но и в целом
улучшаем качество нашего готового продукта, приносим какие-то идеи, которые могут повлиять на улучшение
юзабилити самого продукта, чтобы наш пользователь больше понимал, как работать с этой системой. Мы можем
смотреть какие-то другие ресурсы, на которых реализованы те же самые механизмы, те же самые фичи, как это
там сделано, как мы можем улучшить именно наш продукт, так как это в дальнейшем может привести к удобству
использования у нашего пользователя и принести нам деньги, потому что мы будем значительно лучше
выделяться среди других подобных продуктов.
Сheckbox. Такие квадратики, в которых мы ставим галочки и выбираем необходимые нам опции. Также
они могут быть в виде списков, которые можно разворачивать и уже внутри них тоже выбирать необходимые
нам опции. Обязательно смотрим, как себя ведет система, когда мы ничего не выбираем, выбираем один
чекбокс, когда выбираем несколько чекбоксов, когда мы выбираем все. Опять же, хорошей практикой является
то, что когда очень много различных опций, то должен быть такой checkbox, который позволит выбрать сразу
все. Стоит отметить тот факт, что хорошей практикой также является то, что не только та область, которая
находится внутри этого квадратика является кликабельный, но и область возле него, т.е. когда мы нажимаем
где-то рядом также должен поставится checkbox.
Radiobutton. Особенностью данного элемента является тот факт, что мы можем выбрать только один
параметр. Нельзя как в чекбоксах выбрать несколько. Обычно, по умолчанию, уже выбран какой-то элемент,
который можно потом в дальнейшем изменить. И также стоит обращать внимание, что в radiobutton не может
быть такого варианта, что не выбран ни один элемент, т.е. всегда должен быть выбран один элемент. Проверяем
тот факт, что мы не можем выбрать несколько элементов. Проверяем тот факт, что когда мы нажимаем рядом
с этим элементом, а также у нас происходит check той опции, которую мы выбираем.
Multiple selector. Мы можем выбрать несколько параметров из большого количества. Здесь мы проверяем
тот факт, что мы можем выбрать один параметр, можем выбрать несколько параметров, ничего не выбираем.
Проверяем, как ведет себя система, например, если у вас есть возможность drag-and-drop, т.е. когда мы берем
какой-то элемент и перетягиваем его в список выбранных элементов. Есть возможность как добавить элемент с
помощью плюс, так и удалить его, проверяем можем ли мы это сделать, добавляем элементы нажатием на плюс
и удаляем его нажатием на минус. Если у нас есть какие-то сортировки или фильтрация, также проверяем тот
факт, что у нас все сортируется и фильтруется правильно. Если есть возможность удалить все элементы удаляем их, если есть возможность добавить все элементы - добавляем их. Если у вас есть возможность
осуществить какой-то поиск, то вводим в поисковую строку и смотрим, действительно ли у нас отрабатывает это
поиск.
Upload file. Элемент, который позволяет нам загружать какие-либо файлы. Здесь мы можем проверить,
во-первых, не выбрать никакой файл для загрузки, посмотреть как будет себя вести система. Также проверяем
саму загрузку этого файла. Здесь у нас написано, что максимальный размер загруженного файла 10 мегабайт.
Проверяем, опять же, на самой границе 10 мегабайт, проверяем 10,01 и 9,99 мегабайт. Есть специальные
ресурсы, которые могут генерить необходимые нам файлы, если у нас есть требование к формату. Т.е. мы
можем загружать файлы doc, xls и картинки, то проверяем все невалидные форматы файлов, которые могут
прийти в голову. Проверяем валидные форматы файлов. Как мы с вами помним, первые проверки, которые мы
всегда делаем, они позитивные. Позитивные проверки - это те, которые соответствуют нашим изначальным
требованиям. Если есть возможность ввести, к примеру, информацию о пути к данному файлу, тоже сюда
вводим, смотрим, действительно ли это обрабатываестся. Если есть ограничение на количество введенных
символов, опять же проверяем их по тем же самым техникам, как и текстовые поля, текстовые области. Т.е. у
вас должен отложиться в голове вот этот паттерн (образец), какие обязательные проверки вы проводите для
полей ввода. Когда вы это запомните, то в дальнейшем просто на автомате будете помнить, что вам необходимо
сделать, к примеру, если будете сами создавать какие-то чек-листы для полей ввода. Вы напишете для себя
отдельный чек-лист, где пропишите все эти остальные проверки, и в случае проверки данных полей будете к
нему обращаться и проверять, что все действительно соответствует данному чек-листу. Если мы загружаем этот
файл - обязательно смотрим файлы, которые не весят вообще ничего, т.е. 0 мегабайт, как себя будет вести
система поведет. По-хорошему, этот файл должен подгрузится, если нет никаких требований, связанных с тем,
что мы не можем загружать файлы равные 0 , 00 мегабайт. Мы видим у нас здесь не прописано, это значит вот
такие файлы должны загружаться. И проверяем обязательно появление валидационных сообщений в случае
того, если мы не соответствуем каким-либо требованиям.
Phone. Поле ввода наших номеров телефонов. Как видите, здесь могут быть какие-то ваши обычные
номера телефонов, мобильные, факсы, всё, что угодно, всё, что придет в голову вашему бизнес-аналитику и
будет соответствовать требованиям вашего заказчика. Проверяем тот факт, когда мы вводим какой-то номер
телефона, когда мы оставляем это поле пустым, является ли это поле обязательным. Все эти проверки
одинаковы для всех полей ввода. Обычно в полях также можно ввести знаки плюс-минус. Смотрим, как система
обрабатывает ввод текстовых символов, букв кириллицы и латиницы. Хорошая практика, когда есть какой-то
плейсхолдер, к примеру, либо информация о том, как должен выглядеть номер телефона, как он должен
вводиться (серым шрифтом в поле указан пример ввода). В полях ввода мы проверяем тэги, проверяем
специальные символы, проверяем ввод данных из буфера. Иногда могут быть какие-то маски. К примеру, у вас
есть маска, что здесь первые символы будут 555, как код и дальше вводите номер телефона. Т.е. обязательно
проверяем тот факт, что, к примеру, вы можете видоизменить эту маску, т.е. вместо 555 написать 375, в
зависимости от кода страны, в которой вы находитесь. Также здесь может быть зашифрован такой шаблон, что
когда вы вводите, например, 8 символов, то первые три символа, потом остальные два, еще два символа,
выделяются знаками минус, знаками тире. Проверяем факт, что да, это действительно так происходит и
автоматически ваши введенные символы разграничиваются такими вот элементами.
Email. Помимо основных проверок, обязательно мы должны проверить ввод кириллических символов, так
как email у нас не могут их содержать, т.е. как система себя поведет, будет ли она ругаться. Обязательно
проверяем тот факт, что мы вводим @, т.е. как себя ведет система, если мы эту собачку пропускаем, либо
вводим две собачки, т.е., опять же, это нарушение паттерна для емэйлов. Если хорошо порыться в интернете,
можно найти информацию о том, какие вообще могут сюда водиться валидные e-mail и как система их
обрабатывает. Т.е. можно создать для себя такие тестовые данные с различными видами емэйлов, потому что
здесь могут быть и цифры, могут быть и спецсимволы, могут быть пробелы, т.е. всё, что угодно может
обрабатываться системой, как валидные емейл.
Password. Помимо наших стандартных проверок, связанных с минимальным и максимальным
количеством символов, с оставлением пустым данного поля, также мы здесь проверяем, если у нас есть какието валидации, связанные с тем, какая сложность должна быть у пароля. Что значит сложность пароля? Т.е. у
вас, к примеру, есть требование, что в пароле обязательно должны быть латинские символы, обязательно
должна быть одна буква прописная, обязательно должна быть цифра, обязательно должен быть один
спецсимвол, т.е. все это мы здесь должны учесть и проверить. Т.е. вводим пароли, которые будут содержать
все эти необходимые элементы и пароли, которые не будут содержать эти все необходимые элементы, каждый
элемент по отдельности. Всё это мы прописываем, когда создаем нашу тестовую документацию, будь то
checklist, будь то тест-кейс. Тэги, спецсимволы и т.д.
Captcha. Если у нас появляется картинка с цифрами, либо же буквами, которые мы должны ввести в эту
captcha, то проверяем, действительно ли срабатывает при полном соответствии картинки, которая появляется
и информация в этом поле, и мы можем войти в систему. Обязательно проверяем тот факт, что при перезагрузке
нашей картинки она действительно изменяется, и проверяем, сможем ли мы зайти в систему таким образом.
Если же здесь есть воспроизведение каких-то звуков, воспроизводим и слушаем, что все хорошо. Вводим этот
код, проверяем. Можем сюда ничего не вводить, смотрим, как ведет себя система.
Dropdown. Также есть такой элемент, как dropdown. Это выпадающий список. Что касается dropdown, т.е.
как обычные dropdown, так и комбинированные. Здесь мы проверяем, как себя ведет система, когда мы
выбираем один, к примеру, элемент. В некоторых dropdown есть поиск по элементам, т.е. здесь мы можем
ввести, например, первую букву и у нас автоматически выберется элемент, у которого первая буква
соответствует нашему поиску, также проверяем это. Проверяем максимальное и минимальное количество
символов, которые мы можем сюда ввести, цифры, буквы, кириллица, опять же, все, чт.е. в ваших требованиях.
Проверяем какие-то сортировки, скролл (прокрутка).
Listbox. Проверяем, можем ли мы их выбрать, добавить. Что будет когда мы выбираем опцию “none”.
Проверка выбора нескольких элементов с помощью кнопки control или shift. Проверяем какие-то сортировки,
скролл (прокрутка).
Date/time picker. Выбор дат или времени. Проверяем какую-то определенную дату. Смотрим, как себя
ведёт система, если мы вводим дату в текстовое поле, она должна обязательно подтянуться из календаря.
Выбираем, когда у нас, к примеру, дата раньше нашей текущей, год можем изменить, либо же дата позже.
Обязательно требование должно быть прописано, какую максимальную дату от текущей мы можем выбрать. К
примеру, если мы говорим о каких-то медицинских системах, и у вас есть система, связанная с тем, что вы
планируете какие-то процедуры в будущем, т.е. на какое количество дней в будущем максимально вы можете
назначить эту процедуру. Либо же, к примеру, если вы уже оказали эту процедуру, то у вас должна быть
заблокирована возможность изменять дату в ней. Либо же, к примеру, если мы говорим о выборе даты вашего
рождения, то здесь мы можем проверять тот факт, если на сайт могут заходить лица старше 18 лет, что мы не
можем выбрать дату рождения, которые не будут соответствовать тому факту, что вам исполнилось 18 лет.
Обязательно проверяем максимальный ранний срок, который мы можем выбрать и максимальный поздний срок,
который мы можем выбрать в этом календаре. Если тестируем поле ввода времени, проверяем, что не можем
ввести больше двадцати четырех часов, не можем ввести отрицательные числа. Также мы проверяем тот факт,
что мы не можем сюда ввести буквы, спецсимволы и пробелы.
Также я хотел бы еще обратить внимание на некоторые элементы, которые могут также вам попасться на
страницах. Switch toggle - мы можем изменить какое-то положение этого тумблера.
Breadcrumbs (хлебные крошки). Как вы видите, это путь к тому или иному файлу, либо же папке.
Например, C:\Users\Desktop\1.avi. Мы, как по хлебным крошкам, можем переходить к более высокоуровневым
элементам, папкам, дискам и прочему.
Поисковая строка. Есть поисковые строки, в которых, когда мы что-то вводим - появляются
соответствующие этому запросу данные. Например, есть требование, что поиск начинает работать после ввода
трёх символов и появляется дропдаун, проверяем это. Вводите три символа, вводите два символа, вводите
четыре символа.
Button (кнопка).
Слайдер. Если вы открываете какую-то страницу, у вас появляется какая-то картинка и внизу под ней ещё
несколько точек, по нажатию на которые происходит изменение этой картинки на другую. Это называется
слайдер. Эти картинки автоматически меняются. Либо может быть какой-то пейджинатор (стрелки
влево,вправо,номера страниц или картинок) при нажатии на которые меняется картинка.
Пагинатор. Элемент, в котором содержится информация о тех страницах, которые у вас есть. Нажимая
на определенный номер страницы, вы переходите на нее.
Loading. Лоудинги, лоудеры. Показывает, что идёт загрузка.
Урок 17. Тестирование веб-сервисов. SOAP и XML, REST и JSON для
тестировщика.
https://www.youtube.com/watch?v=_cfmDnIIQTU
Сегодня я дам вам теоретический базис, расскажу о том, какие существуют протоколы, какие есть
архитектурные стили, с помощью чего web-сервисы общаются друг с дружкой и т.д. Даже начинающему
тестировщику, джуну, необходимо знать основные аспекты и базис того, как тестировать веб-сервисы.
Веб-сервис, либо же веб-служба - это программа, которая организовывает взаимодействие между
сайтами. Т.е. информация с одного портала передается на другой, если говорить простыми словами. Если
завернуть это немножко по-умному, то это такая веб-ориентированная технология, которая позволяет
программам общаться между собой, используя стандартные форматы, такие как XML и JSON, посредством
специального протокола SOAP и архитектурного стиля REST.
К примеру, у вас есть некая авиакомпания, у нее большое количество рейсов и, следовательно, очень
много билетов. Информация через веб-службу попадает на сайт агрегатора тура путешествий, т.е. с нашей
компании, с помощью API мы можем подключить, встроить некоторый функционал, который будет напрямую
взаимодействовать с пользователем. Когда пользователь заходит на данный агрегатор, то он сможет напрямую
купить на этом же сайте, не заходя на сайт компании, какие-то авиабилеты. Либо же другой пример webсервисов, это сайты отслеживания погоды, которые содержат какие-то сведения о метеоусловиях в конкретном
городе или в стране. Данная информация также используется сторонними приложениями, либо же какими-то
другими сайтами. Т.е. мы просто встраиваем вот эту вот формочку, где у нас прописана информация о погоде.
Также курсы валют. Т.е. вы часто видели, что на сайте встраиваются какие-то формы, где вы можете онлайн
осуществить конвертацию одной валюты в другую. Либо же также работает авторизация с помощью каких-то
социальных сетей, будь то google, вконтакте, facebook. Т.е. когда вы, например, заходите на какой-то сайт и у
вас написано, что вы можете зарегистрироваться, используя ваши аккаунты в других соц. сетях, это также
работает посредством API.
SOAP протокол (Simple Object Access Protocol — простой протокол доступа к объектам). Это
протокол обмена структурированными сообщениями в распределенной вычислительной среде. Звучит очень
тяжело, но сейчас вам все объясню. Т.е. этот протокол используют для обмена произвольными сообщениями в
формате XML. Мы с вами когда-то говорили о HTML, но у XML, по сути, сама форма написания одинаковая, но
есть свои особенности. SOAP может использоваться с любым протоколом прикладного уровня. Если мы с вами
вспомним такую модель, как OSI, то там был прикладной уровень - http, smtp, ftp, https и др. В SOAP могут
использоваться и данные виды протоколов. Однако взаимодействие данного протокола с другими имеет какието свои особенности.
XSD (XML Shema Definition). В SOAP для передачи какой-либо информации используются xml файлы, и
вот именно XSD описывает структуру нашего документа и типы данных, которые там могут храниться. Т.е. у вас
в сервисе есть такой вот файлик XSD и с помощью него мы можем задавать различные элементы, данные
внутри наших xml, и передавать их посредством сети интернет.
WSDL (Web Services Description Language). Это такой файлик *.wsdl с таким расширением, он написан
на языке wsdl. Этот файлик описывает сообщение, заголовки, события, которые свойственны для нашего вебсервиса. Т.е. данный файлик описывает структуру нашего веб-сервиса. И он обязателен для SOAP протокола.
Без этого файлика мы просто не сможем использовать SOAP протокол. В дальнейшем, при тестировании,
именно этот файл облегчает очень сильно работу, так как в отличие от REST архитектурного стиля, где нет
такого документа, в котором была бы четко структурирована работа нашего веб-сервиса, тестировать там
бывает тяжеловато. Каждый документ WSDL можно разделить на следующие логические части. Message элементы данных, т.е. это сообщения, которые использует наш веб-сервис. Type - тип данных, эта информация
определяет виды открываемых и получаемых сервисом xml сообщений (например, string - т.е. это обычные
строки). Porttype - это список операций, которые могут быть выполнены с нашими сообщениями.
Вам нужно запомнить, что одно из отличий SOAP от REST - это наличие файлов WSDL, сообщения
обмениваются xml, структура которых описана в XSD. Обязательно необходимо запомнить правила, которые
используются при написании XML документа. На собеседовании очень часто их спрашивают. XML похож на html,
но у него, как видите, другая расшифровка, т.е. это расширенный язык разметки. Если HTML у нас используется
именно для разметки страницы, для верстки, то XML уже хранит в себе некоторую информацию, с помощью него
эту информацию можно передавать при общении наших web-сервисов.
Структурными единицами XML являются элементы. Вот здесь есть схема таких элементов.
У нас есть открывающий тэг, закрывающий тэг, контент, который хранится между этими двумя тэгами и
атрибуты. Всё очень похоже на HTML, однако, что вам необходимо знать при написании, либо же тестировании
XML, на что необходимо обращать внимание?
Во-первых, у XML есть только один корневой элемент. Т.е. смотрите, у нас здесь есть корневой элемент
<person>, это правильное написание, есть открывающий тэг <person>, закрывающий тэг </person> и больше у
нас никаких корневых элементов нет.
Дальше у нас прописан неправильный формат, когда у нас, как вы видите, есть корневой элемент <person>
и он у нас почему-то дублируется. Т.е. такого не должно быть. У нас просто должен быть открывающий и
закрывающий тэг для данного корневого элемента.
Следующий аспект - все элементы должны иметь закрывающие тэги. Как вы видите, у нас здесь есть два
тэга, <person> и <familyname>, они есть как открывающие, так и закрывающие, однако есть один элемент,
который не имеет закрывающего тэга (помечен красным), т.е. так неправильно. Мы не должны оставлять просто
один открывающий тэг.
Название наших тэгов регистрозависимые. Тэги чувствительны к прописным буквам, либо же к строчным.
Всегда должны использоваться одни и те же символы.
Элементы не должны пересекаться. Если мы внутри тэга ставим другой тэг, то и закрыть его должны
внутри первого тэга, а не после него.
Все значения атрибутов должны быть в кавычках.
<,>,& знаки больше, меньше, амперсанд нельзя использовать в текстовых блоках. Мы должны записывать
их в текстовом формате. &lt - <, &gt - >, &amp - &, &apos - ‘, &quot - “. Иначе система может их неправильно
обработать.
Объявления XML - это всегда первая строка. Это отдельная строка, в которой содержится информация о
номере версии нашего xml, указания на кодировку наших символов и параметр standalone, который указывает
запрещены ли ссылки на внешние документы.
На собеседовании вам, например, могут дать XML с ошибками и попросить вас найти их, поэтому нужно
быть к этому готовым.
Архитектурный стиль REST (Representational State Transfer — «передача состояния
представления»). В чем разница архитектурного стиля REST и протокола SOAP? К архитектурному стилю не
применяются какие-то жёсткие правила, здесь не нужны никакие wsdl, хотя есть тут такой формат документов,
как WADL, но не обязательно. Т.е. если его нету, то как бы все о.к., и поэтому REST предпочитают сейчас
использовать все чаще? так как этот архитектурный стиль позволяет записывать информацию в более удобном
формате? который занимает меньше места и повышает производительность нашей системы. И также он,
скажем так, не правилозависим. Т.е. к нему предъявляется гораздо меньше требований, поэтому его используют
сейчас гораздо чаще. Чем отличается REST от RESTFUL? Если REST - архитектурный стиль, с помощью
которого у нас описывается структура передачи информации у веб-сервисов, вообще в целом там какие т.е.
правила, связанные с тем, как эта информация должна передаваться, то RESTFUL - это уже характеристика
наших веб-сервисов. Т.е. это такие web-сервисы, которые полностью отвечают требованиям REST, которые
предъявляет этот архитектурный стиль. Т.е. REST по сути описывает структуру нашего сервиса, а RESTFUL это
уже сам веб-сервис, который отвечает требованиям REST.
В отличие от SOAP, в REST у нас используется уже JSON (JavaScript Object Notation). В отличие от XML
для JSON нет прямо-таки строгих правил, он гораздо более гибкий, занимает меньше места, с ним гораздо
удобнее работать. И давайте поговорим об основных элементах, которые у нас содержатся в JSON.
Во-первых, документы в формате JSON состоят из объектов. Объекты - это неупорядоченное множество
пар “имя - значения”. Объект обычно заключается в фигурные скобки и внутри него содержатся, как я уже сказал,
пары “имя - значения”. Имя “name”, значение “Петр”. Между собой эти пары разделяются запятой, а имя и само
значение между собой разделяются “:”. Просто запоминаем, что есть фигурные скобки, что наше имя и значение
заключены в кавычки, между собой имя и значение разделяется “:”, а пары имя и значения разделяются запятой.
Имя - это всегда строка, т.е. тип данных для него - это строка, а само значение, как здесь у нас, например, “Петр”,
может быть как строкой в двойных кавычках, так и числом, каким-то логическим значением булевым (true или
falls), массивом или значением “NULL”. О массивах мы с вами поговорим чуть дальше, а значение null - это
значение 0. Если мы говорим о таком типе данных, как строка, то это упорядоченное множество из нуля или
более символов юникода, заплетённые в двойные кавычки.
Если мы говорим о простых числах, то их не нужно заключать кавычки. Как раз на примере индекса можно
заметить разницу, если у нас используется в значении число, то кавычки не записываем, и тогда наша система
воспринимает эти данные как числовые. Как только мы с вами используем кавычки для записи нашего числа, то
автоматически этот тип данных превращается в строку и воспринимается системой как текст. Аналогично с
булевскими значениями true, falls.
И последний тип данных - это массивы. Это множество наших объектов. Как мы с вами помним, объекты
- это некоторое количество пар “имя и значения”. Как только у нас используется несколько таких вот объектов,
то тогда мы заключаем их в массивы. Массив заключается в квадратные скобки, а значения внутри этого массива
отделяются запятыми.
Очень часто на собеседованиях спрашивают в чем разница между REST и SOAP веб-сервисами. Давайте
перечислим эти различия. REST - поддерживает различные форматы. Самый распространенный JSON, но также
можно использовать XML и текстовые форматы. Но SOAP - только XML. REST работает только по протоколам
http и https. SOAP - с различными протоколами. SOAP на основе чтения не может быть помещен в кэш. Rest
можно кэшировать. REST - это архитектурный стиль без строгих правил. SOAP - протокол, который сильно
ограничен правилами.
Что необходимо выбирать на проекте, REST или SOAP? Простота против стандарта. REST - у вас будет
скорость, расширяемость, поддержка многих форматов. SOAP - у вас будет больше возможностей по
безопасности, а также больше возможности провести тестирование качественно, так как сразу в SOAP у вас
будут WSDL, где будут прописаны образцы ваших запросов. Т.е. не нужно будет лишний раз обращаться к
разработчику, просить его, чтобы он предоставил вам информацию, какие-то примеры запросов. Сразу можно
брать и тестировать. SOAP более ресурсоемкий, занимает больше места, он медленнее. Разработка на SOAP
дольше.
Урок 18. Как тестировать API с помощью Postman, SoapUI. Отличия GET и
POST.
https://www.youtube.com/watch?v=VqjaDULOYOM
По-хорошему, на всех проектах, у вас должны быть примеры запросов, т.е. вы обращаетесь к
разработчику, он выдает вам некий пример запроса и, возможно, ответы на этот запрос. С помощью этих
входных данных тестируете. Если такого нет, то, конечно, жизнь ваша усложняется. Но в любом случае, вы
должны начинать свою работу с коммуникации с разработчиком, если документации на проекте нет. Если
документация есть, то обращаемся напрямую к ней.
Confluence - это такая вики система, где собираются все данные о проекте, документация. Т.е. обычно на
проектах всегда есть такие вики-подобные системы. Если мы говорим про Jira - это confluence, если мы говорим
про devops - это просто вики. Т.е. там с помощью языка разметки, по аналогиии, как это написано в википедии,
собирают информацию о проекте, требования, спеки, входные данные какие-то, все хранится там. Т.е. вы всегда
можете обратиться к вики системе и узнать на каком этапе находится проект. Обычно внутри различных
требований дают ссылки на вики, где хранится эта информация.
SoapUI. https://www.soapui.org/ Приложение для тестирования веб-сервисов сервис-ориентированных
архитектур (SOA) и передачи состояний представлений (REST). Его функциональные возможности включают
проверку веб-службы, запуск, разработку, моделирование и макетирование, функциональное тестирование,
тестирование нагрузки и соответствия. Когда вы приходите на проект, где используется SOAP, то в принципе
никаких сложностей не будет, вам выдадут SoapUI, вы зайдете, создадите свои проекты и начнете тестировать.
Postman. https://www.postman.com Чем хорош postman - тем, что может одновременно работать целая
команда тестировщиков, разработчиков, они могут делиться своими какими-то тест-кейсами, также здесь можно
проводить автоматизацию, писать какие-то скрипты на языке java скрипта, делиться опять же этой информации
с вашей командой, создавать различные коллекции ваших запросов, работать в разных рабочих средах,
создавать различные параметры. Т.е. инструмент очень интересный, многоплановый.
Методы тестирования web-приложений. Метод - это тип http запроса, который указывает серверу на то,
какое действие мы хотим произвести с ресурсом. 4 основных метода. GET (R), POST (C, U, D), PUT (C, U),
DELETE (D). На что направлены эти методы?
GET - направлен на то, чтобы получить информацию от нашего сервера.
POST - служит для добавления информации на наш ресурс. Например, если мы хотим загрузить какую-то
музыку, либо же ввести пароль и логин нового поля ввода и отправить их на сервер, либо же загрузить какой-то
текст на наш сервер.
PUT - служит для того, чтобы заменить какую-то информацию, изменить её на сервере.
DELETE - служит для удаления данной информации.
Также в разных источниках пишут о том, что метод POST может также отвечать за изменение информации,
как и метод PUT, либо же для удаления информации. Метод PUT также может использоваться для добавления
информации. Т.е. опять же все будет зависеть от того, как разработчики решают использовать данные методы.
Можно создавать также свои кастомные методы, которые будут выполнять какие-либо функции.
Что вам нужно знать еще о методах? Методы отвечают за так называемые CRUD (Create, Read, Update,
Delete) операции. Вы будете очень часто встречать в тестировании именно эту аббревиатуру. Всегда, когда мы
что-либо тестируем, мы должны рассматривать объект тестирования с точки зрения этих четырех действий. К
примеру, у вас есть какой-то рядовой пользователь, у которого есть права только на чтение, есть модератор,
который может изменять какие-то данные в вашей системе, есть еще какой-нибудь super user, который обладает
способностью создавать что-то в системе, опять же, читать это, апдейтить, и, например, есть администратор,
который может выполнять все эти четыре действия одновременно.
Также очень часто на собеседованиях спрашивают, чем отличаются между собой get и post методы.
Поэтому вам нужно обязательно это запомнить. GET метод очень легко обнаружить, идентифицировать. Так как
GET метод - это всегда наша адресная строка. Т.е. то, что мы пишем в адресную строку, мы хотим получить
какую-то информацию в сети интернет, и там мы можем внести какие-то параметры, которые нас интересуют,
все всегда обращают внимание на адресную строку. GET - адресная строка. В отличие от метода POST, у GET
нет тела запроса. Т.е. мы не можем с помощью GET какую-то информацию загрузить. В теле запроса у нас
может быть различные payload, различная полезная нагрузка, т.е. это текст, музыка, код, все, что угодно. И
именно это загружается на наш сервер, поэтому у POST - есть тело запроса, у GET - нет тела запроса. У GET
запроса всегда есть параметры, которые содержатся в адресной строке, GET ограничен длиной адресной
строки. Всегда можно протестировать это, если вы знаете, что у вас есть ограничения в GET на количество
символов, можно посмотреть, как себя будет вести система, будет ли выдавать какую-то ошибку, будет ли
вообще обрабатываться данный запрос. GET кэшируется на стороне клиента. Данные из GET запросов
попадают в кэш, и, так как это, по сути, наша адресная строка, то его всегда можно сохранить в закладку в нашем
браузере. Лучше выучить и другие методы, помимо этих четырёх.
Как писать тест-кейсы для тестирования. Начнём с плана работы. Он стандартный, как и для любого
тестирования любой фичи. Сначала мы изучаем требования, либо же пишем их, если их нет. Затем на основании
этих требований пишем наши тест-кейсы, и, конечно же, тестируем требования. Требования - это
непосредственно наша документация, это *.wadl, это *.wsdl, примеры наших запросов, примеры ответов,
которые вы можете получить у разработчика. Кейсы мы пишем на основании этой документации. Включаем
техники тест-дизайна для этого. Ну и тестирование с помощью SoapUI, Postman.
Требования/входные данные. Какие параметры, атрибуты есть у сервиса? Это, например, если у нас
есть *.wsdl мы можем там посмотреть. Какие-то образцы запросов, которые мы можем попросить у девелопера.
Какие тест-кейсы? Разделяем их на три наших основных. Smoke (один реквест на метод), Critical Path
(все валидные), Extended (все невалидные).
Специфические тесты. Для веб-сервисов и для наших запросов, как я уже говорил, мы можем отправлять
в параметрах какие-то пустые значения, посмотреть, как ведет себя система, должна выдавать ошибки, если
это значение обязательно, если же это значение не обязательно, то допустимо, чтобы ошибок не было, если
это оговорено в требованиях. Можем пробовать отправлять, в тех же самых json, комментарии (это такие строки,
которые оформляются, либо же заключается в несколько слоев, либо оформляются звездочками, они не
воспринимаются нашей системой как исполняемый код, т.е. это просто какие-то заметки). Можем посмотреть,
как ведет себя система, не воспринимает ли она комментарии, как исполняемый код.
Валидность ответов согласно схеме (при наличии) - если имеются *.wsdl, *.wadl, просто их открываем и
начинаем тестировать, т.е. вводим в эти параметры, в эти наши тэги информацию, которую мы передаем на
сервер, и смотрим, как сервер её воспринимает, какие нам статус коды возвращает.
Проверки с обязательными и необязательные атрибутами - смотрим что у нас require и mandatory
обязательно должно отправляться в запросе, и как себя ведет система.
Проверки с дополнительными и не допустимыми значениями - также добавляем какие-то параметры,
которые у нас указаны в тестовой документации, либо же в примерах наших запросов, смотрим, как ведет себя
система, либо же, если у нас, например, указан в параметрах числовой тип, а мы пишем буквы, то сервер тоже
должен ругнуться и выдать нам неправильный ответ.
Различные типы данных (вместо строки числа) сопоставим с “Проверки с дополнительными и не
допустимыми значениями”.
Дубликаты атрибутов (элементов) - берем наш элемент, к примеру, пароль, копируем несколько раз,
отправляем, смотрим, как ведет себя система.
Порядок атрибутов (элементов) - если у нас задан четкий порядок и мы, например, его нарушаем, то
система должна ругаться, всегда должна прислать нам какой-то статус код о том, что не была обработана наша
информация, которую мы отправляем на сервер.
Длины строк и чисел - играемся с этими значениями. Невалидные данные (синтаксис JSON и XML).
Что смотреть в ответах? Статус-код, тело ответа, текст ошибок. Если в документации указано, что
должен приходить определённый статус-код, либо текст ошибки, но они не совпадают - заводим баг-репорт.
Пример нашего тест-кейса.
Урок 19. Базы данных для тестировщиков и QA.
https://www.youtube.com/watch?v=vhYZYALBL8M
Зная теорию тестирования веб-приложений и базы данных, вы уже сможете проходить собеседование на
должность начинающего тестировщика.
Базы данных - это очень полезный инструмент, который используется не только в тестировании, но и в
самой разработке, даже в бизнес анализе, т.е. это довольно мощный инструмент, так как данные - наше всё.
Хотел бы сразу обратить ваше внимание на следующее. Перед вами сейчас знакомая форма для входа
на сайт. Такую форму очень часто показывают на собеседованиях и просят вас рассказать, как бы вы её
протестировали. Самая главная ошибка начинается с того, что вы начинаете говорить о том, что я бы, например,
вводил максимальное количество символов в поле логин или пароль, и проводил все проверки, о которых мы с
вами говорили в рамках тестирования веб-форм. Да, это верно, но это не самый первый этап, который вы
должны сделать. Чаще всего кейс, user story, требования от вашего интервьюера звучит так: пожалуйста,
протестируйте то, что вы можете залогиниться в систему. Как мы можем это сделать? Все данные о логинах и
паролях, либо же другой информации, которая может содержаться на этой форме, хранятся в базе данных. Т.е.
наша формочка, т.е. клиент, отправляет запрос на сервер с некоторыми данными, т.е. он там прописывает то,
что “пожалуйста, верни мне информацию о том, есть ли такой user, с таким логином и с таким паролем в
системе”. Т.е. совпадают они, либо нет, есть ли они в базе данных. И уже сервер отправляет этот запрос дальше,
в базу данных. Если это совпадает, то база данных говорит об этом серверу, сервер получает эту информацию
и отправляет ее уже непосредственно клиенту, и мы входим на наш сайт. Т.е. обязательно наш первый пункт
состоит в том, что мы должны зайти в базу данных и проверить, есть ли там информация о данном пользователе
с помощью специальных запросов. Это ваш самый первый шаг, а уже потом, после того, когда мы проверили,
что да, действительно, мы можем войти в систему, зашли в базу данных, что там содержится необходимая нам
информация, только потом мы приступаем, непосредственно, к тестированию самой формы, вводя
недопустимые значения, либо допустимые значения в заданном диапазоне, которые есть в требованиях.
Также работает абсолютно все, что связано с базами данных, так как хранить всю информацию и все
данные внутри того же документа верстки, либо css, попросту невозможно, поэтому мы прибегаем к некоторому
хранилищу, в котором содержатся наши данные, это и есть база данных. База данных - это набор сведений,
хранящийся в упорядоченном виде. Существует три основных типа базы данных. Иерархическая база
данных, сетевая и реляционная.
Иерархическая БД - у нас есть какой-то один корневой узел и от него идут разветвления к другим.
Непосредственно у этого узла, который принадлежит нашему корневому, есть еще какие-то узелки, и так они
разветвляются все дальше. Система предок-потомок. Т.е. предок - это наш, например, корневой узел, потомки
- это те узлы, которые отходят от него. Для уровня 3 предком будет уровень 2, а уровень 3 будет являться
потомком, и так далее.
Сетевая БД. Когда у нас также есть некоторый набор данных, но эти данные также зависят от других. Т.е.
у них есть некоторая такая взаимосвязь, т.е. не просто у нас взаимосвязь один-ко-многим, а здесь у нас уже
могут быть такие взаимосвязи, как многие ко многим, многие к одному.
Реляционная БД. Используется всеми сейчас. Когда у нас есть некоторое множество таких вот двумерных
таблиц, в которых содержатся наши данные, и эти таблицы также могут между собой быть связаны. Есть так
называемый первичный ключ (primary key), который является однозначным идентификатором данной строки, и
он обязательный. Потому что он уникальный, а если, например, мы возьмем значение “имя” столбца, то мы
увидим, что здесь могут быть одинаковые имена, и, в таком случае, наша база данных будет отрабатывать,
порой, некорректно, когда мы будем запрашивать какое-то одно имя и у него будет много одинаковых значений,
и она будет выдавать нам очень много значений по одному этому запросу, поэтому всегда есть такие
идентификаторы, которые уникальны и определяют строки в нашей базе данных. И есть, так называемые,
вторичные ключи (foreign key) - служат для того, например, если у нас есть две таблицы, в которых есть
связанные данные, то как нам эти таблицы между собой можно связать? С помощью вторичного ключа, т.е. мы
вводим какие-то одинаковые идентификаторы для этих двух таблиц, и с помощью этого индикатора мы
связываем наши таблицы. Вторичный ключ не обязателен, он появляется только тогда, когда у нас есть
несколько таблиц и нам необходимо найти какие-то закономерности, связи между ними. Строки в таких таблицах
называются записями, а столбцы называются полями.
Нормализация - это процесс приведения таблиц к нормальному виду. Давайте разберемся, что такое
нормальный вид, либо же нормальные формы? Это требования, предъявляемые к таблице в теории
реляционных баз данных. Т.е. у нас есть некоторые правила, по которым должны создаваться наши таблицы
для того, чтобы они адекватно обрабатывались нашей системой управления базы данных. Две основных
формы.
Первая нормальная форма (1NF) - требует, чтобы каждый элемент таблицы имел только одно значение,
т.е. был атомарным.
Вторая нормальная форма (2NF) - требует, чтобы таблица находилась в первой нормальной форме + все
поля должны зависеть от первичного ключа, а не от его какой-либо части. Т.е. смотрите, в данной таблице у нас
здесь есть два ключа Department и Position, и наша зарплата зависит от этих двух ключей, а вот необходимость
того, чтобы на рабочем месте был компьютер, зависит только от Position, т.е. Department на это не влияет, это
неправильно. Поэтому мы должны сделать так, чтобы у нас данная форма соответствовала второй нормальной
форме.
Также есть процесс денормализации. Нередко приходится соединять до десятка, а то и больше таблиц, а
каждое соединение - это очень ресурсоемкая операция, как следствие, такие запросы требуют огромного
количества ресурсов сервера и выполняются очень медленно, поэтому в дело вступает процесс
денормализации. Есть несколько способов, как это можно осуществить, например, денормализация путем
сокращения количества таблиц, т.е. лучше объединять в одну таблицу несколько имеющих небольшой размер,
содержащих редко изменяемую информацию, причем информация, по смыслу, тесно должна быть связана
между собой, таким образом, мы сокращаем количество запросов к нашей базе данных и к тому количеству
информации, которую необходимо обработать. И второй распространенный способ - это денормализация путем
ввода дополнительного поля в одной из таблиц. При этом появляется некоторая избыточность наших данных,
поэтому необходимы дополнительные действия для сохранения целостности нашей базы данных, чтобы
запускать процесс денормализации. Нужно очень хорошо знать нашу базы данных, как она себя ведет с тем
количеством данных, которые в ней есть, сколько времени необходимо на обработку, поэтому я думаю, что вам,
как начинающим тестировщикам, не нужно в эту операцию залазить с головой. Просто необходимо знать, что не
всегда приведение к нормальным формам и к требованиям может очень хорошо влиять на производительность
нашей базы данных.
Отношения в БД.
Отношения один к одному - это означает, что каждая запись в одной таблице соответствует только одной
записи в другой таблице.
Отношения один-ко-многим - означает, что для каждой записи в одной таблице соответствует одна или
несколько записей в другой таблице.
Отношения многие к одному - являются точно такими же как, “один ко многим”, просто такой тип
отношений зависит от вашей точки зрения.
Отношения многие ко многим - когда возникают отношения между двумя таблицами в тех случаях, когда
каждой записи в одной таблице соответствует 0, 1, 2 или более записи в другой таблице, и наоборот.
Система управления БД - это совокупность языковых и программных средств, которые позволяют
создавать, изменять, удалять наши данные, осуществляют доступ к ним и обеспечивают безопасность
наших данных. Очень часто спрашивают, чем отличается БД от СУБД? БД - это, во-первых, объект и это всегда
просто набор каких-то данных, а СУБД - это субъект, который, скажем так, управляет нашими данными, и в
первом приближении это просто программа, некое программное обеспечение. Т.е. БД - просто данные, СУБД программа. Виды СУБД - MySql, MS SQL, Oracle, Postgre Sql, MongoDB и другие. SQL (structured query language
— «язык структурированных запросов»).
Урок 20. SQL для тестировщика. Как создать таблицы в MySQL для QA.
https://www.youtube.com/watch?v=fXxB2pN3_30
https://www.mysql.com/ - скачать MySQL Community Server.
Сегодня познакомимся с MySQL, как установить сервер, на котором мы будем работать, с теми командами,
которые помогут нам взаимодействовать с базой данных и с таблицами, которые в ней находятся. Это занятие
будет полностью посвящено именно первичной работе, изменению, удалению, добавлению таблиц базы
данных.
Типы данных. Посмотрим, какие типы данных используются в базах данных и с чем мы сегодня будем
работать, когда будем создавать таблички, видоизменять их. Сначала поговорим о типах данных. Существуют
определенные типы данных, которые мы можем вводить в нашей табличке и использовать эти данные. В
принципе, они стандартные, они даже используются при программировании.
INT (целые числа) - именно их мы и будем использовать в наших базах данных, это наши целые числа.
DEC (десятичные числа).
BLOB/TEXT/MEMO - большой объем текстовой информации. TEXT - 65 тысяч символов, примерно.
CHAR/VARCHAR - строки, текст. Т.е. небольшой объём текстовой информации. От 1 до 250 символов.
DATE, TIME, YEAR - форматы даты.
FLOAT, DOUBLE - данные с плавающей точкой.
TIMESTAMP - хранит 4-байтное целое число, равное количеству секунд, прошедших с полуночи 1 января
1970 года по усреднённому времени гринвича (т.е. нулевой, точка отсчёта часовых полюсов). Такой тип данных,
который позволяет нам судить о том, когда у нас был создан, к примеру, тот или иной элемент в нашей базе
данных. И обычно TIMESTAMP зависит от того, в каком часовом поясе вы находитесь. Т.е. для различных
часовых поясов, в различных базах данных, он может отличаться.
BOOLEAN - true/false.
NULL - нулевые значения. Т.е. обязательно для данной строки, для данного поля, должны быть, к примеру,
эти значения либо же пустыми, либо же, если мы говорим про NOT NULL, должны обязательно чем-то быть
заполнены.
На самом деле типов данных намного больше, это просто одни из самых распространённых.
SHOW databases; - показать БД.
CREATE database students; - создать БД с именем students.
DROP database test; - удалить БД с именем test.
USE students; - использовать БД с именем students, дальнейшая работа происходит внутри этой БД.
SHOW tables; - показать все таблицы, которые есть в выбранной БД.
CREATE table courses; - создать таблицу с именем courses.
CREATE table courses - создание полей в таблице.
> (id INT(11) NOT NULL PRIMARY KEY, - id (название поля), INT (целые числа), 11 - количество символов встроке, NOT NULL - не может быть пустым.
пустым.
> faculty VARCHAR(55) NULL, - faculty (название поля), VARCHAR (строка, используются буквы), 55 - количество символов в строке, NULL - может быть
> number INT(2) NULL);
DESC courses; - описание таблицы.
DROP courses; - удаление таблицы с именем courses.
INSERT INTO courses VALUES (1, “bio”, 1); - вставить в таблицу значения (по порядку: 1 - id, “bio” факультет, кавычки, потому что строковый тип данных VARCHAR, 1 - номер).
SELECT * FROM courses; - показать таблицу.
DELETE FROM courses WHERE faculty=”gum”; - удалить значения из таблицы, где факультет=gum.
UPDATE courses SET faculty=”gum” WHERE faculty=”geo”; - меняем значение gum на geo в таблице.
ALTER TABLE courses DROP COLUMN id; - удалить из таблицы столбец id.
ALTER TABLE courses ADD COLUMN id INT AFTER number; - добавить столбец id после столбца number.
Урок 21. Запросы SELECT в SQL/MySQL для тестировщика.
https://www.youtube.com/watch?v=4uyxTMh0g4E
Поговорим о select-ах, которые чаще всего спрашивают на собеседованиях и разберем основные запросы,
которые вам нужно будет выучить, и практиковаться в их написании, чтобы вы успешно прошли ваше интервью.
Давайте сначала выведем все значения из таблицы.
SHOW databases; - показать все БД.
USE students; - использовать БД с именем students, дальнейшая работа происходит внутри этой БД.
SELECT * FROM courses: - вывести таблицу courses из БД students. Ключевой запрос, либо же ещё
называется оператор.
Если мы хотим, чтобы нам не показывали дублирующие поля, т.е., к примеру, у нас в number два
дублирующих поля, мы не хотим, чтобы у нас показывали всех первокурсников, а только одну запись.
SELECT DISTINCT number FROM courses; - выбрать дубликаты из поля number в таблице courses.
В итоге, как мы видим, у нас отсекаются дублирующие значения и мы видим только то, что не содержит
дубликатов.
Допустим, мы хотим вывести только первые две строки из нашей таблицы. Чаще всего у вас база данных
не состоит из вот таких вот 5 строк из 5 записей, а там содержатся сотни, а иногда и тысячи значений, поэтому
нам не нужно столько значений. Давайте выведем первые 2 записи.
SELECT * FROM courses LIMIT 2;
Есть такая возможность, как псевдонимы (ALIASES) - это временное название наших полей. К примеру,
мы не хотим, чтобы у нас поле “number” выводилось, а хотим, чтобы было название “номер”. Но это временное
значение, оно не сохраняется в таблице, просто для удобства работы в данный момент (на случай, если мы
будем делать какие-то сложные запросы, просто для наглядности).
SELECT number AS номер FROM courses;
Сравнение, либо же точное совпадение каких-то значений. Т.е. у нас есть наш select, мы хотим ввести
какое-то поле из таблицы, название нашей таблицы, и мы должны присвоить какое-то условие, по которому мы
будем искать эти значения.
SELECT faculty, number FROM courses WHERE faculty = ”bio”; - показать столбцы “факультет” и “номер”,
где значение факультета=био.
SELECT number FROM courses WHERE number > 1; - показать number, где значение больше 1.
Можно делать выборку >, <, =, а также >=, <= (больше равно, меньше равно, именно в такой
последовательности).
Логические операции И/ИЛИ. (AND/OR).
SELECT * FROM courses WHERE number = 1 AND faculty = “bio”;
SELECT * FROM courses WHERE number = 1 OR faculty = “gum”;
Поиск похожих значений. К примеру, мы хотим найти слова, в которых у нас в конце содержится буква “О”.
Тогда мы должны использовать следующий вид запроса.
SELECT * FROM courses WHERE faculty LIKE “%o”;
%о - не важно сколько символов, но последний - о.
_о - одно подчёркивание - один символ.
_о% - первый символ не важно какой, второй символ - о, последующие - сколько угодно символов.
Диапазон значений. Например, чтобы не писать очень много раз условия, что, например, “where number =
1”, “where number = 2”, “where number = 3”, и так до бесконечности, можно сделать это проще
SELECT * FROM courses WHERE number BETWEEN 2 AND 4;
От противного:
SELECT * FROM courses WHERE NOT number BETWEEN 2 AND 4;
Точное попадание:
SELECT * FROM courses WHERE number IN (1,4);
Объединение логических функций. Покажутся все значения, которые соответствуют всем этим условиям.
SELECT * FROM courses WHERE (faculty = “teo” OR faculty = “bio” AND number = 1;
Сортировка. К примеру, мы хотим отсортировать все значения в нашей таблице в алфавитном порядке.
SELECT * FROM courses ORDER BY faculty;
SELECT * FROM courses ORDER BY faculty DESC; - сортировка в обратном алфавитном порядке.
Агрегатные функции. SUM (поле) - сумма, MIN/MAX - минимальное, максимальное число, COUNT (поле) количество записей (заполненных), AVG (поле) среднее.
SELECT AVG(number) FROM courses; - среднее значение в поле number.
SELECT SUM(number) FROM courses; - сумма чисел в поле number.
SELECT MIN(number) AS min_number FROM courses; - показать мин. значение в поле number и назвать
поле min_number.
SELECT COUNT(faculty) FROM courses; - количество заполненных значений в faculty.
Урок 22. Запросы Join в SQL/MySQL на примерах для тестировщика.
https://www.youtube.com/watch?v=e-kPUCAkZyU
MySQL workbench - расширенное приложение для компьютера, более удобное, чем командная строка.
Join - это такие запросы, которые позволяют нам объединять две и более таблиц по какому-либо полю,
которые в этих таблицах одинаковые. Т.е. если нам необходимо объединить несколько похожих таблиц в одной
базе данных, то мы можем использовать join. Существует три типа join.
Inner join - т.е. внутреннее объединение. Если у нас есть две таблицы и в них есть поле, которое
идентично для А и B, значение в нем совпадает, то мы можем провести такое внутреннее объединение. Т.е.
одна таблица соединяется с другой.
Пример. У нас есть две таблицы, general и courses.
SELECT courses.faculty, general.fname, general.lname FROM courses JOIN general ON courses.id =
general.id;
У нас просто объединились значения, в которых айдишники совпали и вывелась такая вот общая табличка.
Т.е. теперь мы можем узнать, на каком факультете учится тот или иной человек.
Смотрите, у нас есть табличка general, где есть id=6, а в табличке courses id=7, так как у нас они не
совпадают, значения id 6 и 7 в этих двух таблицах, то и в результирующей табличке нашей, в которой мы провели
объединение, не будет этих двух строк.
Поэтому на помощь к нам приходит LEFT JOIN и RIGHT JOIN. В левостороннем объединении мы
объединяем как бы по левой табличке, в правостороннем - по правой табличке. Т.е. у нас будут показываться
все строки из таблицы А, даже если их нет в таблице B. И то же самое для правостороннего объединения, нам
будут показываться все строки из таблички B, даже если их нет в табличке А.
Табличка А – courses, табличка B – general.
SELECT courses.number, general.fname, general.gender FROM courses LEFT JOIN general ON
courses.id = general.id;
NULL - заменяются значения из таблички B, т.е. general, у которых нет совпадения с табличкой А (courses).
SELECT courses.id, general.fname, general.lname, general.gender, courses.faculty FROM courses RIGHT
JOIN general ON courses.id = general.id;
Теперь появилась информация по шестому айди, которого у нас не было в таблице courses, но, так как у
нас объединение по right join, то нам показывают все значения из таблички general, даже вне зависимости от
того, что у нас этот айдишник отсутствует в табличке courses.
Вложенные подзапросы. Если мы не можем с помощью одного нашего selecta и тех условий, которые в
нем укажем, вывести значение, которое нас интересует, мы можем использовать еще один select внутри нашего
запроса.
SELECT fname,lname,gender,id FROM general WHERE age IN (SELECT age FROM general WHERE id>1
and age >=21); - выбрать имя, фамилию, пол, id из таблицы general, где возраст подходит под условие (выбрать
возраст из таблицы general, где id > 1 И возраст >=21).
Урок 23. Как тестировать мобильные приложения? Тестировщик
мобильных приложений.
https://www.youtube.com/watch?v=PIupBjDxeps
https://developer.android.com/about/dashboards - статистика Android
https://developer.apple.com/support/app-store - статистика iOS
https://mixpanel.com/ - Android vs iOS
https://gs.statcounter.com/vendor-market-share/mobile - статистика по использованию устройств
https://www.appbrain.com/stats/top-android-phones-tablets-by-country?country=gl - статистика по
использованию устройств
https://www.browserstack.com/test-on-the-right-mobile-devices - рекомендации по формированию парка
девайсов для тестирования мобильных приложений
https://developer.android.com/guide/topics/ui - гайдлайн по UI для Android
https://developer.apple.com/design/human-interface-guidelines/ - гайдлайн по UI для Apple
https://developer.android.com/studio - Android Studio - эмулятор Android
https://developer.apple.com/xcode/ - Xcode – эмулятор Apple
https://www.genymotion.com/ - онлайн эмулятор бесплатно на 60 минут.
Тестирование мобильных приложений. Что такое мобильные приложения, как с ними работать, как
подбирать инструмент для работы с ними, как работать в самих инструментах и устанавливать их на свой
компьютер, как тестировать мобильные приложения, какие специфические проверки мы должны использовать,
также я поделюсь с вами некоторыми чек-листами, которые помогут вам в дальнейшем с минимальными
потерями времени проводить ваши проверки.
Что самое первое мы должны сделать перед тем как начинать тестировать мобильные приложения?
Конечно же выбрать на какой платформе мы хотим осуществлять нашу разработку, какие девайсы мы хотим
использовать, какой форм-фактор, т.е. нам необходимо собрать нужную статистику. Обычно этим занимаются
не тестировщики, но также вас могут привлекать к этим вопросам, потому что именно вам необходимо будет
проводить это самое тестирование.
Поэтому первый аспект, который мы затронем - это сбор статистики по мобилке. Во-первых, у нас есть
два официальных ресурса, где собрана вся информация для разработчиков тех или иных мобильных
приложений, будь то платформа android или ios. https://developer.android.com и https://developer.apple.com.
Здесь есть информация о версиях и платформах, какие версии на данный момент наиболее
распространены, о размерах экранов и разрешений и прочее. Тестировщикам необходимо смотреть, какие
версии наиболее распространены и сформировать необходимый пул устройств, которые будем тестировать.
Например, не все версии ios поддерживаются на всех телефонах, поэтому нам нужно выбрать оптимальный
для нас вариант, чтобы затронуть как можно большее количество версий и в дальнейшем проводить
тестирование.
Неплохой ресурс https://mixpanel.com, где у нас собирается статистика по тому, насколько распространены
девайсы на платформе android и на платформе ios, т.е. можно здесь посмотреть, что, к примеру, на данный
момент android девайсов больше. Здесь можно сделать сортировку по тому периоду, который нас интересует,
мы можем узнать, например, как в 2020 году изменялась эта статистика. И много всего другого.
https://gs.statcounter.com также неплохой ресурс, здесь тоже можно, например, найти информацию о том,
насколько распространены модели тех или иных компаний телефонов, т.е., опять же, для выбора наших
девайсов для тестирования мы можем ей воспользоваться, и, к примеру, понимать, что нам необходимо
закупить телефоны samsung и apple для нашей работы. Также здесь можно выбрать непосредственно в той
стране, на которую мы хотим выйти. К примеру, если вас интересует Беларусь, мы смотрим по ней. И другая
информация.
https://www.appbrain.com, в принципе он работает аналогично, опять же, мы выбираем страну, которая нас
интересует, возьмем Гренландию, и здесь прописано, сколько было продано телефонов именно в этой стране.
https://www.browserstack.com может вам помочь, к примеру, для того, чтобы вы определились с
необходимыми мобильными девайсами, если у вас, например, ограничен бюджет у вашей компании. Этот
ресурс хорош тем, что здесь есть информация о том, к примеру, если у вас не так много денег, вы только
начинаете какой-нибудь стартап, и вам необходимо покрыть как можно больше количество кейсов, версий,
платформ, то здесь прописаны те устройства, которые вам необходимо закупить.
Типы мобильных приложений. Нативные, гибридные, веб.
Web-приложения - это более раскрученные с точки зрения функциональности веб-сайты, и в принцип, по
сути, это вебсайт, который адаптирован для наших мобильных приложений, для экранов мобильных
приложений. Самый простой пример - Вконтакте. Т.е. если мы просто перейдем на него, то нам откроется
обычный веб-сайт в приложении для нашей с вами работы на десктопе. Но также у этого веб-сайта есть
мобильная версия, и именно она уже адаптирована для мобильных устройств. Т.е. это вот и есть мобильное
приложение.
Давайте с вами теперь поговорим о том, какие есть плюсы и минусы именно у мобильных веб-приложений.
Начнем с плюсов. Веб-приложение представляет собой одну версию для всех платформ, т.е. нам не нужно
разрабатывать отдельное приложение для ios, для android, не знаю, там, для windows phone, для blackberry, т.е.
не нужно нам это все разрабатывать. Есть одна версия для всех платформ. Это вебсайт, который адаптирован
для работы с мобильным устройством. Также из плюсов можно вынести то, что обновление этого ресурса
осуществляется на сервере, т.е. нам не нужно привлекать юзеров к этой работе, всё происходит в
автоматическом режиме. Веб-приложения достаточно просты в разработке, потому что здесь используются вебтехнологии.
Из минусов можно отнести то, что для веб-приложения всегда необходимо интернет-соединение для
работы. Нет возможности использовать функции мобильного устройства. Т.е. у мобильника есть камера, есть
push-уведомления, есть доступ к gps, всё это веб-приложение не может использовать. Данное приложение
нельзя загрузить из магазина (appstore, playmarket), их там нет, потому что это, в принципе, веб-сайт. Данные
приложения не очень хорошо защищены, так как они написаны на HTML, например, и можно спокойно скачать
код этого приложения и получить какие-то данные.
Нативные приложения - это те приложения, которые мы непосредственно скачиваем с нашего магазина,
с плей маркета, либо же appstore. Они разрабатываются непосредственно на тех инструментах, тулах, на тех
языках, которые нужны и используются именно для платформы, они специфические. Приложения для ios, к
примеру, разработаны на языке swift. Приложения для android разрабатываются на java, либо kotlin. Это
специфические языки именно свойственные для данных платформ.
Плюсы: нативные приложения работают без интернет-соединения. Имеют доступ к возможностям
мобильного устройства, т.е. можно отсылать push-уведомления, можно использовать ресурсы камеры, можно
использовать gps и т.д., если пользователь это разрешает делать. Эти приложения распространяются через
магазины. Эти приложения достаточно высокоскоростные и более интересные, чем другие виды приложений,
потому что могут использовать функции устройства.
Минусы: разработка отдельной версии приложения осуществляется для каждой платформы. У каждой
платформы, для каждого магазина, есть свои требования к разработке того или иного приложения, к его дизайну.
Мы не можем выпускать одинаковые приложения, написанные на одном и том же языке для двух платформ.
Нам требуется больше денег и времени для разработки. Больше денег, к примеру, может пойти на покупку
различных тестовых девайсов на ios устройства или на android. Этих устройств очень много, их нужно покупать
в различных вариациях. Обновление и загрузка этих приложений происходит с привлечением юзера. Т.е. мы не
можем в автоматическом режиме проводить эти обновления, когда нам захочется. User обязательно должен это
скачать. Это также вызывает некоторые риски, потому что если у вас есть какой-то критический баг для работы
вашего приложения, а юзер долго не скачивал это обновление, то юзер может воспринять это, как
некачественный продукт, оставить негативный отзыв.
Гибридные приложения. Включают в себя как веб-элементы, так и элементы нативных приложений.
Плюсы: кроссплатформенные. Потому что чаще всего они пишутся с использованием различных языков вэба,
веб-технологий, т.е. там нет такой привязки именно к тому, что мы должны написать только на java или kotlin,
swift. Нам не нужно разрабатывать отдельные версии для различных маркетов. Гибридное приложение имеет
доступ к функциям телефона, т.е. мы можем их подключать, у них есть доступ к внутренним данным телефона.
Они дешевле в разработке, чем нативные, потому что не нужно разрабатывать сто пятьсот версий для
различных версий платформ и самих платформ, и не нужно такое количество большое устройств, которые нам
необходимы для тестирования.
Минусы: низкая скорость работы, так как у нас здесь используются веб-технологии, мы не можем
некоторые моменты оптимизировать. Они не практичны в виду долгого обновления фреймворка. Т.е. если мы,
например, используем наше приложение и написали его на каком-то фреймворке, то на его обновление может
уйти, например, от 3 до 6 месяцев, это очень долго. Гибридные приложения не защищены, потому что могут
быть написаны на веб-технологии, например, HTML5, где есть дыры по безопасности. Также могут быть
проблемы с гайдлайном по дизайну приложений в магазинах, если они изменятся, нужно будет быстро вносить
изменения, чтобы нам не отклонили загрузку данного приложения в наш market.
Нативные приложения - instagram, Shazam. Веб-приложения - maps.google.com. Гибридные - агрегаторы
новостей, различные приложения, связанные с фотографированием, Heartcamera для ios, Tripcase.
Следующий момент - это гайдлайн. Это требование к нашему дизайну. Если мы говорим про android, у
нас есть непосредственно гайды, где содержится информация по юзер интерфейсу и навигации. Когда мы
нажимаем на необходимый нам элемент - открывается информация о том, как это должно выглядеть, как должно
работать, и мы должны обязательно соответствовать всему тому, что здесь написано. Если мы этому не будем
соответствовать - ваше приложение просто declined, и скажут, что вы не соответствуете нашим требованиям.
Если вы для себя решили выбрать путь тестирования мобильных приложений - вы должны выучить эти гайдлайн
и основные принципы, которые в них используются. Часто на собеседованиях спрашивают именно эти гайдлайн
и насколько вы их знаете, спрашивают по элементам, какие могут быть отличия в ios устройствах, какие отличия
в android устройствах. То же самое про гайдлайны и для ios.
Где всё-таки нам взять устройство для тестирования? На помощь нам приходят эмуляторы. Для своей
работы мы используем статистику. Мы узнали, к примеру, что у нас есть две наших платформы и узнали версии,
которые нас интересуют, которые сейчас наиболее распространены, выбрали устройство и выбрали формфактор, планшет, либо телефон. Самый простой вариант, конечно же, их купить. Мы смотрим, какие устройства
наиболее распространены, какие их модели, и просто отправляем заказчику этот большой список того, что нам
необходимо прикупить для тестирования мобильных приложений. Если же у нас такой возможности нет, то на
помощь приходят эмуляторы и симуляторы мобильных приложений.
По умолчанию для эмуляции используются два эмулятора. Android - Android Studio, ios - Xcode.
Урок 24. Android Studio (SDK), эмуляторы для тестировщика мобильных
приложений.
https://www.youtube.com/watch?v=DjsTreMcXcQ
https://developer.android.com/studio - установка эмулятора
https://support.bluestacks.com/hc/ru/articles/360043236951# - как включить аппаратную виртуализацию в BIOS
Эмулятор Android studio.
Урок 25. Особенности тестирования мобильных приложений.
https://www.youtube.com/watch?v=dP8IBDRxrsg
https://bit.ly/2GoTulN - чек-лист для тестирования мобильных приложений
https://bit.ly/2Gsjtsy - чек-лист для тестирования мобильных приложений
Сегодня расскажу вам о тех проверках, которые нужно проводить на наших мобильных приложений
непосредственно для того, чтобы убедиться, что они отрабатывают свои функциональности. Существует
несколько типов основных проверок, которые нужно осуществлять на нашем мобильном телефоне.
Проверки на прерывание. Т.е. когда у нас работа нашего приложения прерывается чем-то извне.
Входящие/исходящие вызовы. К примеру, нам кто-то звонит и мы сидим в каком-то приложении, в игрушке, либо
в нашем браузере, и мы должны обязательно проверить, что происходит с приложением после того, когда
заканчивается вызов. Например, оно может крашиться, вылетать, либо же зависать. Т.е. мы должны убедиться
в том, что все отрабатывается корректно. То же касается и входящих вызовов, т.е., к примеру, если мы свернули
наше приложение в трей и мы кому-то звоним, а потом хотим обратно вернуться в наше приложение, то мы
должны посмотреть, всё ли там хорошо, действительно ли осталась информация о том, что мы делали, в
оперативной памяти и эта информация прогрузилась и показалась нам в том же неизменном виде. Также есть
такие типы прерываний, как всплывающее окно уведомлений (push-уведомления). Т.е., к примеру, вы во что-то
играете и вам приходит сообщение из какой-то социальной сети, появляется push-уведомление, мы можем это
проверить, посмотреть, как реагирует на это основное приложение, в котором мы сейчас работаем. Следующий
вид - прерывание при разрядке, подзарядке. Т.е., к примеру, если наш телефон находится на минимальном
пороге по уровню зарядки - как ведет себя приложение, опять же, может появляться какое-то уведомление о
том, что вам нужно поставить телефон на зарядку, или что телефон переведен в экономный режим. Т.е. смотрим
на то, что наше приложение работает корректно. Подзарядка значит то, что, к примеру, мы берем наш телефон
и ставим его на зарядную станцию, смотрим, всё ли работает корректно в нашем приложении, т.е. не вылетает
ли оно, не сворачивается в трей, не начинает тормозить. Сворачивание/разворачивание приложений. Если мы
наше приложение сворачиваем в трей и обратно его разворачиваем, смотрим, что там действительно
сохранилась информация, если нам позволяет это сделать количество оперативной памяти на нашем
телефоне, так как если у нас этой памяти мало и наше приложение, к примеру, какая-нибудь тяжелая игрушка,
то, конечно же, у нас есть вероятность того, что просто именно из-за оперативной памяти не осуществляется
загрузка этих данных.
Тестирование установки. Проверяем, что наше приложение устанавливается корректно, что мы его
можем удалить с какого-то маркета, то либо же можем удалить непосредственно с телефона, посредством,
например, долгого зажатия, нажав на крестик, и все действительно удаляется. Либо же из табеля приложения
внутри настроек удалить. Это всё мы должны проверить и посмотреть, что да, действительно, у нас всё хорошо,
проходит переустановка, опять же, если мы удалили это приложение когда-то и решили его обратно
переустановить. Возможно у нас сохранилась какая-то папка с данными от этого приложения, как это может
повлиять на то, что мы переустанавливаем это приложение и приложение, возможно из-за этого, не может
работать корректно. Ну и конечно обновление, когда мы осуществляем какой-то апдейт из нашего маркета,
посмотреть, что переход на новую версию никак не влияет на наше основное приложение, на его работу.
Проверка интернет-соединения. Мы должны проверить, как работает наше приложение на различных
типах соединения, будь то вай-фай, 2g, 3g, 4g, 5g и т.д. Проверить качество соединения, т.е. когда у нас плохое
соединение, когда хорошее, когда отличное, когда у нас, например, вообще отсутствует интернет, когда потеря
связи, например, блокируют интернет в стране, или просто уехал на природу и там нет интернета. Смотрим, как
работает наше приложение, и изменяем типы соединений, к примеру, мы сидим на 3g, меняем на 4g и др.,
смотрим, всё ли будет работать хорошо, не будет ли прерываться соединение.
Все эти функции проверок реализованы на эмуляторах, т.е. вам не обязательно это все делать на
реальном девайсе, хотя рекомендовано на реальном девайсе, но если такой возможности нет, вы можете
симулировать.
Работа с функциями телефона. У нас есть какие-то встроенные функции телефона, например, gps, фото,
видео и др. Если мы тестируем gps, то смотрим, что, к примеру, с помощью api мы можем подключаться к api
телефона и использовать a-gps, смотрим, действительно ли наша геолокация отрабатывает корректно. Камера
- проверить фронтальную камеру, тыльную, ширик, телекамеру и т.д. Размер экрана, разрешение, ориентация.
Мы должны проверить размер экрана, разрешение, ориентацию на различных форм-факторах. Например, если
заявлено, что наш продукт может работать на планшете, на телефоне, где разрешение fullHD, или fullHD+, или
HD, всё должны проверить, корректно ли всё отображается на всех устройствах, прорисовываются ли все наши
страницы в нашем приложении. Обязательно смотрим на ориентацию, т.е. если у нас заявлено, что может
работать в горизонтальном и вертикальном режиме, действительно ли это происходит, когда мы
переворачиваем телефон, для этого в телефоне есть акселерометр, для определения положения в
пространстве. Работа с жестами. Проверяем тап на различные части нашего экрана телефона, проверяем
сворачивание, разворачивание. На некоторых телефонах сейчас есть поддержка, к примеру, удара костяшек
пальцев, т.е. тоже как-то это должно срабатывать. Всё вот это мы должны проверить, все наши жесты, свайпы,
увеличения, уменьшения нашей картинки.
Тестирование производительности. Проверяем скорость нашего приложения, как оно быстро работает,
отзывчивость, например, если мы тапаем на него, то оно должно быстренько переходить на следующую
страницу, либо же если мы свайпаем, тоже должно после него наступать какое-то действие, как это быстро
происходит. Загрузка оперативной памяти - обязательно смотрим, чтобы, к примеру, наше приложение было
хорошо оптимизировано для той или иной платформы и не нагружало очень сильно телефон. Зависимость от
заряда батареи - т.е. это взаимосвязи с прерываниями, также смотрим не тормозит ли наше приложение, когда
уровень батареи падает на определенное количество процентов, можем проверить чуть ли не каждые 10
процентов. Всё зависит от вашей фантазии и от того, что от вас хочет получить конечный пользователь и сам
бизнес. Запуск с внутренней памяти/flash накопителя. Это больше актуально для android приложений. Мы
можем установить приложение как на внутреннюю память нашего телефона, так и установить на флешку.
Посмотреть, как работает наше приложение, к этому уже подключаются и остальные все проверки. Обязательно
проверить установку на флэш-накопитель, удаление с flash накопителя, обновления на flash накопителе при
установке на флэш-накопитель.
Количество проверок зависит только от того, насколько тщательно вам нужно это все провести и сколько
у вас есть время на это тестирование. Это основной перечень проверок мобильных приложений. Помимо этого,
существуют и наши стандартные все проверки, все наши типы тестирования, которые мы также можем
применять для наших мобильных приложений.
Documentation testing - мы можем также протестировать документацию и требования.
Функциональное тестирование - помимо того, что мы проверяем всё то, что описано выше (проверки на
прерывания, установку и прочее), мы обязательно должны проверить, что те функции, которые заявлены в
нашем приложении, которые есть в требованиях, они также осуществляются. Я бы вообще сказал, что
функциональное тестирование - самое важное, что вы должны провести в первую очередь.
Юзабилити-тестирование - наши кнопочки, хорошо ли расположены, соответствуют ли они гайдлайным
android, либо apple, т.е. всё мы это должны проверить. Чем хорошо мобильное тестирование? Несмотря на то,
что здесь есть огромное количество проверок, всегда есть доступные документации. Есть документация в виде
тех же самых гайдлайнов, там очень подробно расписано всё, как должно выглядеть ваше приложение, как
должны размещаться кнопки, как они должны реагировать на ваши какие-то действия. У вас уже упрощается
работа именно в сборе и анализе требований для вашего мобильного приложения.
Compatibility (configuration) testing - смотрим тестирование совместимости, конфигурации.
Security testing - это тестирование безопасности, т.е. смотрим, что если мы даём доступ и разрешение
использовать какие-то функции наших телефонов, что мы внутри нашего приложения не используем какие-то
другие функции, которые не заявлены вот в этом доступе, который нам дал пользователь, так как это может
вызвать огромные убытки и риски для вас, как разработчика, так и для вашего заказчика, и вызвать большой
скандал, так как вопрос, связанный с чувствительными данными ваших пользователей, очень критичный. Можно
влететь на очень большую сумму денег.
Recovery testing - тестирование на отказ и восстановление.
Localization testing - очень часто локализуют какие-то игры для различных стран, различных языков, мы
тестируем наши локализации, либо же интернет реализацию, в зависимости от того, какие цели мы преследуем
в рамках данной функциональности и нашего приложения.
Certification testing - это соответствие требованиям того же apple, гугл, гайдлайны и т.д.
Есть такой тестовый артефакт, как тест-план, который позволяет нам еще в начале, скажем так, нашего
тестирования, прописать вообще какие виды тестирования мы будем использовать, какие тулы будем
использовать, какие проверки будем проводить, и это может очень сильно ограничить те проверки, которые вам
нужно провести. Обращайте на это внимание и спрашивайте у вашего тимлида, например, если вы в первый
раз приходите, либо же у человека, который отвечает за вашу команду, менеджера, как это все реализовано у
вас.
Можно использовать google chrome devtools, используя наш девайс. То есть подключить телефон к
компьютеру, настроить девтулс на компе, и всё, что мы будем делать на телефоне, будет отображаться на
компьютере в девтулс.
Урок 26. Как тестировать требования? Тестирование требований.
https://www.youtube.com/watch?v=Ct8mK-lFw1Q
Всем известно такое выражение, как “театр начинается с вешалки”, так и процесс разработки, по сути,
начинается с требований. Т.е. без требований, без какой-либо идеи, без реализации и документации мы не
можем приступить к работе и реализовать то, что так хочет получить бизнес и пользователь.
Существует три основных уровня требований. Уровень бизнес требований, уровень пользовательских
требований и уровень продуктных требований.
Бизнес требования. Это что-то, что необходимо нашему бизнесу, т.е. цель, ради которой создается наш
продукт, для чего, какая польза и как получить с этого продукта прибыль. К примеру, у бизнеса есть цель создать
некий сайт, который будет промоутить их продукцию. Это их основное бизнес требование.
Дальше мы переходим на уровень пользовательских требований. Т.е., понятно, что этот сайт не будет
существовать без пользователей, которые будут его использовать. Поэтому уровень пользовательских
требований покрывает задачи, которые пользователь может выполнять с помощью продукта. Например,
регистрироваться, общаться, искать информацию о продукте. Т.е. всё, что может выполнять наш пользователь.
Уровень продуктных требований - это то, как это все будет реализовано в нашем продукте с точки
зрения разработки, учитывая контекст бизнес требований и контекст пользовательских требований. Он
разделяется на функциональные требования (что наша система должна делать) и нефункциональные
требования (как наша система должна это делать). Эти понятия взаимосвязаны с функциональным и
нефункциональным тестированием.
Обязательно запомните их названия, что они обозначают, для каких целей используются, потому что часто
на собеседованиях могут спросить, какие требования вы знаете и расскажите немножко о них. Плюс,
постарайтесь найти в интернете дополнительные примеры для каждого уровня.
Как мы можем выявлять наши требования? Чаще всего этим занимаются бизнес-аналитики. В небольших
компаниях функцию аналитиков могут выполнять и QA инженеры. Интервью. Во-первых, мы можем
побеседовать с нашим заказчиком, бизнесом, либо пользователями, какой-то фокус группой, которая будет
работать с нашим продуктом и узнать у них, что они хотят видеть в нем, узнать все эти требования. Наблюдение.
Дальше, к примеру, уже существует какой-то продукт, который используется в той компании, которая заказала
наши услуги, и мы пытаемся разработать какую-то новую версию этого продукта, более лучшую, поэтому мы
можем понаблюдать за работой пользователей в этом продукте и выяснить, что их интересует, что бы они
хотели улучшить в их продукте. Также есть такая вещь, как самостоятельное описание. Т.е., к примеру, мы не
знаем, как работает наш продукт, нет некоторых прототипов, тогда мы можем включить здравый смысл и
самостоятельно описать эти требования, учитывая, например фазу интервью и наблюдение и написать их.
Прототипирование. Если у нас, к примеру, есть некий сайт и мы разрабатываем конкурента этому сайту, то мы
можем на него перейти и посмотреть, как он работает, как на нём реализованы те или иные функции, и также
прописать их в наших требованиях.
Постоянно необходимо задавать уточняющие вопросы по поводу того, как та та или иная
функциональность должна реализовываться в нашем продукте, и не нужно стесняться их задавать. Когда вы
приходите на проект, вам тоже необходимо узнать обязательно одним из самых первых пунктов - где вообще
хранятся требования в этой компании. К примеру, если они хранятся в какой-то трекинговой системе, по типу
Jira, либо это какие-то спецификации, которые хранятся в ворде или вики. Мы узнаем всё это, мы узнаем как эти
требования изменяются, кто отвечает за сбор требований, с кем мы можем поговорить, если мы что-то не
понимаем. Чтобы в дальнейшем наша работа складывалась наиболее удобно для нас и для людей, для которых
мы этот продукт разрабатываем.
На что мы определяем эти требования? Существуют, так называемые, свойства хорошего требования.
У требования есть еще требования к их написанию и составлению. Именно этим мы в основном и будем
заниматься, когда будем изучать те или иные требования. Например, ставим ситуацию, что аналитик, либо
product owner, собрал информацию у нашего заказчика, оформил эти требования в виде юзер сторис и нас
подключают к рецензированию данного требования. Что мы должны в нем проверять?
Завершённость - требование должно содержать всю информацию, необходимую для разработчиков,
тестировщиков, либо других людей, которые будут с ним работать. Т.е. мы должны проверить то, чт.е. вся
информация в этом требовании и мы не должны отвлекаться и переходить на другие требования, которые у нас
есть в этой системе.
Непротиворечивость. К примеру, у вас есть некие картинки в вашем требовании, или mockup, шаблоны,
которые будут реализованы в продукте в рамках этой функциональность, и есть текст, к примеру, exception’s
критерии, которые есть у нас в user story (user story - это, по сути, критерии приёмки, т.е. те критерии, которые
определяют, что наше требование реализовано в данной функциональности). И, к примеру, эта картинка, этот
mockup не соответствует этому тексту, который написан в требовании. Вот это и значит, что данные в этом
требовании противоречат между собой. То же касается различных таблиц. Либо же если мы знаем, что в какомто требовании написано одно, а в другом требовании прописано совсем другое, возникает противоречие, такого
быть не должно. Мы должны написать нашему бизнес-аналитику и сказать о том, что данное требование
противоречит.
Корректность - требование должно четко указывать на то, что должно выполнять приложение. Не должно
быть каких-то двусмысленных слов, т.е. система должна отрабатывать корректно. Мы должны ввести валидные
данные. Мы должны четко понимать, какие именно данные мы должны ввести, если это валидные данные, и
должно быть чётко прописано, что это буквы, либо же это цифры, либо же это десятичные дроби, либо же это
спецсимвол, либо и то и другое. Всё это должно быть корректно прописано.
Недвусмысленность - мы должны четко понимать, что в этом требовании у нас написано. К примеру, два
человека смотрят на шестерку с двух сторон, один человек видит шестерку, а второй человек видит девятку,
такого быть не должно. Мы должны все работать в одном информационном поле, в одном контексте.
Проверяемость - требование должно быть однозначно проверенным на предмет того, выполняется оно
или нет. Если вы понимаете, что вы не сможете это никак проверить, т.е. нет таких инструментов, тулов, то такое
требование не нужно прописывать. Нужно обязательно сказать об этом бизнес-аналитику, либо продукт оунеру
и придумать, как другим способом можно реализовать ту или иную функциональность. Есть такое определение
“озолочение”. Если мы хотим реализовать в нашем продукте какую-то фичу, которая очень долго будет
реализовываться и стоит очень больших денег, т.е. мы должны потратить как своё время, так и время
разработчиков, также купить какую-то очень дорогую тулу, которая позволяет нам описать эту
функциональность, тогда такое требование мы должны проверить на то, что действительно - необходима ли
нам эта фича, соизмеримы ли затраченные силы с тем, что мы в итоге получим.
Модифицируемость - набор наших требований должен быть таким, чтобы его можно было легко
модифицировать, при этом не изменяя требования в других местах. Очень хорошо, когда в требованиях нет
ссылок на другие требования, мы должны стараться этого избегать. Мы должны проверять требования на то,
что мы это требование в дальнейшем можем изменить так, чтобы оно не повлияло сильно на систему, и чтобы
это изменение провести в максимально короткие сроки и с минимальными потерями.
Прослеживаемость - наши требования должны быть прослеживаемыми, т.е. там должны быть, к примеру
id у этого требования. Это требование обязательно должно быть взаимосвязано с другими требованиями, если
всё-таки линки у нас есть, хотя это не особо рекомендуется использовать. Либо же, к примеру, мы можем
привязать к этому требованию наш баг-репорт. Может быть это не сильно связано с этим требованием и
прослеживаемостью, но вообще прослеживаемость всех артефактов в нашей системе должна быть
обязательна. Также еще сюда можно отнести проранжированность, к примеру, если мы приоритезируем наши
какие-то требования, что оно должно быть выполнено самым первым. Например, заказчику вот-вот прямо сейчас
нужно, чтобы это требование было реализовано, тогда мы выполняем его первым. Т.е. проранжированность
также сюда можно отнести.
Существуют и другие требования к хорошему требованию, но это основные.
Как можно упростить работу с требованиями? Как только мы получаем эти требования, мы можем
сразу же написать какие-то тест-кейсы, а если мы их не можем написать, то мы возвращаемся к такому
свойству, как проверяемость. Т.е., по сути, мы не можем придумать такие проверки, которые бы покрыли это
требование. Нужно подумать, проверяем ли мы это требование или нет. Можем ли мы это сделать или нет. Если
нет - обращаемся к нашему бизнес-аналитику и обсуждаем этот вопрос, чтобы он связался с заказчиком и они
как-то переформулировали это требование, и узнали точно ли нужна эта функциональность, может быть её не
стоит проверять, если мы не можем это сделать. Заказчик, возможно, на это согласиться. Т.е. у нас должен быть
некий медиатор между заказчиком и нами, если у нас нет доступа к самому заказчику и мы не можем задавать
ему вопросы, тогда мы обращаемся либо к аналитику, либо к продукт оунеру.
Задать вопрос. Обращаемся к нашему аналитику, либо же к нашему заказчику, если у нас есть такая
возможность и задаём уточняющие вопросы по нашему требованию, либо же пишем о том, что это требование
чему-то не соответствует, его нужно переделать.
Нарисовать схему. Можем нарисовать схему. Есть интеллект-карты, такие, как наши презентации,
mindmap. Берём наше большущее требование, разбиваем его на какие-то маленькие функциональности и
каждую функциональность разбиваем еще на более мелкие. Тогда мы более четко понимаем вообще, что у нас
прописано в требованиях, как мы можем с ними работать. А есть use-cases - это так называемые варианты
использования, которые описывают все действия, которые наш пользователь может произвести, и реакцию
системы на эти действия.
Рецензирование. Когда кто-то пишет требование и мы выступаем рецензором этого требования. Есть
формальное рецензирование, есть неформальное рецензирование. Также рецензирование можно проводить
для кейсов, которые мы пишем.
Способы представления наших требований.
Use-cases. У нас есть так называемые актеры, которые выполняют наши действия. Т.е. в данном случае у
нас представлена система для написания каких-то квизов, и у нас есть администратор и студент. Дальше
прописаны наши функциональности, которые мы реализовываем. Всё, что можно произвести внутри этого блока
создания наших квизов. Администратор может логиниться в систему, управлять нашими квизами, добавлять их,
удалять, апдейтить и т.д. Студент - регистрироваться, логиниться и т.д.
User story. Во-первых, у нас есть описание нашей user story, что мы хотим получить в рамках этой
функциональности. Как она пишется? Сначала мы пишем следующую фразу: “как участник конференции, как
пользователь, я хочу иметь возможность регистрироваться онлайн для того, чтобы регистрироваться быстро и
снизить количество бумажной работы”. Здесь есть три логических блока. Т.е., как пользователь, я хочу получить
такую функциональность, которая позволяла бы мне сделать следующее. Дальше у нас прописан acceptance
criteria - это критерии приемки. То, что у нас должно быть реализовано в нашем требовании в нашей user story
для того, чтобы мы в дальнейшем смогли сказать, что ваша функциональность реализована. Что делает
тестировщик? Он получает эту юзер стори и должен придумать тест-кейсы для каждого statement, который
прописан в acceptance criteria для того, чтобы убедиться, что да, действительно, функциональность реализована
правильно и все работает корректно. Т.е. мы берем каждый этот statement и проверяем его. Этим занимаются
аналитики и продукт оунеры, т.е. написанием самих требований, поэтому наша задача проревьюить,
протестировать сами требования на предмет того, что они соответствуют как свойствам хорошего требования,
так и в принципе здравого смысла.
UI-mockup. Это шаблон для мобильного приложения, т.е. мы здесь подробно расписываем как выглядит
каждая кнопка, какие поля есть в нем, что мы должны вводить, какие навигационные сообщения у нас
выскакивают, т.е. этим занимается больше UI-дизайнер. Чаще всего шаблоны уже появляются после того, когда
написаны требования, но также, к примеру, если заказчик проявит, скажем так, свою инициативу, и он хочет,
чтобы действительно всё выглядело так, то он может предоставить уже разработанные шаблоны. Это может
выглядеть просто в виде некой схемы, к примеру, там просто прописаны все блоки которые, у нас должны быть
в нашем приложении и для каждого блока прописано, что должно быть на каждой из этих страниц, т.е. и такой
вариант написания требований может быть. Иногда вообще это может быть просто клочок бумаги, на котором
прописано, что я хочу получить то-то, то-то и то-то, просто как-то высокоуровнево, без каких-то уточнений на эту
тему.
Спецификации. Это такие документы, в которых тоже прописаны наши требования. Их написанием уже
занимаются непосредственно бизнес-аналитики. Спецификациями проверяем точно так же. Мы находим
требования, мы проверяем эти требования внутри спецификации согласно свойствам хорошего требования и
выносим вердикт для того, чтобы в дальнейшем смогли это поправить и наше требование соответствовало всем
необходимым свойствам.
Урок 27. Agile и Scrum для тестировщика. Гибкая методология
разработки.
https://www.youtube.com/watch?v=bv4L_32J-5A
Agile - это набор методов и принципов гибким управлением проектами. Мы с вами помним основные
методологии и модели разработки программного обеспечения. Мы говорили с вами о водопадной модели, о V-
модели, об итерационных моделях. Вот как раз-таки итерационная модель и является основополагающей в
Scrum, в этом фреймворке.
Чем же хороши вот эти гибкие методы управления проектами? Как мы с вами помним, у водопадной
модели все этапы разработки шли друг за дружкой, т.е. сначала был сбор идей, написание требований, потом
шла разработка, потом шло тестирование, и мы не могли вернуться на предыдущий этап, если мы уже
находимся на каком-то из них. Т.е. мы должны были обязательно начинать всё с самого начала. Гибкие методы
хороши тем, что мы можем изменять наши требования, мы можем возвращаться к предыдущим этапам нашей
разработки программного обеспечения без вот этой вот взаимосвязи с другими этапами. Поэтому в 2001 году
17 разработчиков собрались где-то на курорте в Канаде или в Америке и собрали все свои замечания по поводу
того, как они работают именно с гибкими методами в разработке и создали Agile-манифест.
Agile-манифест. В нём существует четыре основополагающих ценности, которые и стали прародителями
дальнейших вот этих вот всех фреймворков и вообще самой системы Agile. Люди и взаимодействие важнее
процессов и инструментов. Например, если в вашей команде есть какие-то принципы, структуры,
инструменты, условия, которые могут помешать вашей работе, то от них нужно избавиться. Самое главное, что
люди должны сами выбирать способ этой организации, набор каких-то процессов, инструментов и именно эти
инструменты и процессы должны помогать работе, а не мешать. Поэтому мы в первую очередь обращаем
внимание на людей и взаимодействие. Но сразу хотел бы отметить тот факт, что даже когда мы говорим, что
что-то важнее чего-то, мы не забываем про то, что процессы, инструменты всё равно должны присутствовать в
нашем управлении проектами и мы без них всё равно не сможем как-то работать. То же касается и остальных
пунктов.
Работающий продукт важнее исчерпывающей документации. Это не значит, что у нас вообще не
должно быть никакой документации на проекте, но эта документация не должна быть избыточна и на нее не
нужно тратить огромное количество времени и ресурсов. Нам главное доставить наш работающий продукт, нашу
функциональность непосредственно заказчику. Это наша задача номер один. Поэтому иногда мы можем
пожертвовать исчерпывающей документацией. Но, опять же, без документов мы в принципе существовать тоже
не можем.
Сотрудничество с заказчиком важнее согласования условий контракта. Не должно быть каких-то
избыточных привязанностей к нашим контрактам, какой-то документации, которые регулируют наши
взаимоотношения с заказчиком. В первую очередь мы должны обращать внимание на то, чтобы нам было
комфортно сотрудничать друг с другом. Мы не хотим портить отношения с нашим заказчиком. Любые наши
документы, соглашения, контракты и прочее должны способствовать нашим положителтным взаимоотношениям
с клиентами, но никак не портить их.
Готовность к изменениям важнее следования первоначальному плану. Даже если у нас есть какойто план проекта, если у нас прописыны четко какие-то требования, мы всегда должны иметь в виду, что мы со
временем будем вносить какие-то изменения. Даже если, к примеру, у нас была какая-то юзер стори, которую
мы реализовали в какой-то прошлой итерации, но все равно, со временем, у бизнеса могут появиться другие
потребности, эта функциональность в дальнейшем может решать какие-то другие задачи. Возможно нужно
будет расширить. Поэтому важно помнить о том, что всегда в Agile есть изменения и для этого и была создана
эта система.
Также, помимо вот этих четырех ценностей, Agile-манифесте есть 12 принципов, но мы не будем на них
более подробно останавливаться, потому что, по сути, они просто уточняют вот эти вот 4 ценности.
https://agilemanifesto.org
Мы с вами делаем такое небольшое overview, смотрим на то, как эти процессы могут быть реализованы в
вашей компании, какие будут церемонии, какие есть митинги, встречи, артефакты и прочее, чтобы вы просто не
испугались, когда вы придете на проект, и вас, к примеру, пригласят на какой-нибудь там iteration planning, либо
spring cleaning. Т.е. вы не будете уже боятся этого митинга, вы будете знать какие задачи преследует именно
этот митинг для вас, для тестировщика, как участника команды разработки. В последствии вас обучат тому, как
эти процессы устроены в вашей компании. Не всегда в компаниях используется чистый Scrum, есть какие-то
улучшайзеры.
Scrum=фреймворк. В скраме выделяют три основные части, Scrum команда, События, Артефакты, ну и
есть ещё Метрики (позволяют нам оценивать эффективность работы вашей команды, эффективность каждого
отдельного члена команды, и позволяют делать какие-то различные репорты, отчеты для менеджмента и для
вашего заказчика).
Scrum команда. Три звена: Product owner, Development team, Scrum master. Product owner - управляет
бэклогом продукта, т.е. набором тех требований, которые мы вообще должны реализовать полностью для того,
чтобы наш продукт был готов. Этот бэклог постоянно обновляется, в него добавляются новые какие-то фичи,
новые user story, новые требования, но вот именно Product owner занимается сбором этих требований, и
занимается, скажем так, описанием бэклога, уточнением, делает его прозрачным, понятным для команды
разработки, которая в дальнейшем и будет заниматься реализацией этой функциональности, этой юзер стори.
В чистом скраме нет такой позиции, как бизнес-аналитик, т.е., по сути, Product owner в какой-то степени
выполняет задачи бизнес-аналитика. Основная задача Product owner - это собрать наш бэклог, привести его в
такую форму, чтобы все участники скрам команды понимали требования, которые они должны реализовать.
Также Product owner приоритезирует выполнение этих задач в нашем бэклоге, чтобы мы понимали, что мы
делаем первым, что мы делаем вторым.
Development team (команда разработки). Обычно в команду разработки у нас входит порядка 3-9
человек, т.е. больше не нужно, больше скрам нам не советует включать. Потому что, чем больше у нас людей в
команде, тем больше у нас происходит распыление внимания и наша команда перестает быть такой гибкой, как
она была бы в том случае, если бы эта команда была намного меньше. Команды самоорганизующаяся, т.е. нам
не нужен никакой руководитель над нами, который бы говорил нам, что нам нужно делать, т.е. все участники
команды равнозначно влияют на то, что мы будем делать, каждый голос участника команды должен быть
услышан. Кроссфункциональность - каждый участник команды обладает всеми необходимыми компетенциями
для того, чтобы делать вообще всё внутри вашей команды, т.е. мы не разделяем наших участников команды на
разработчиков, на тестировщиков, на аналитиков, мы говорим о том, что в случае, если этому человеку будет
необходимо, к примеру, написать код, он его сможет написать, даже несмотря на то, что он тестировщик. Это в
идеале, на деле каждый знает лишь свою область, но надо стремиться к идеалу. (Единственная роль разработчик, также относится к кроссфункциональности, всё должен делать разработчик в чистом скраме).
Коллективная ответственность - если даже ты тестировщик, т.е. отвечаешь за качество продукта, но мы
должны всегда помнить, что за качество продукта отвечает каждый участник в команде, т.е. даже включая
законы какой-то простой логики, мы можем сказать, что в принципе разработчик допустил вероятность того, что
у нас в коде и в его реализации появляется какой-то баг, т.е. он тоже несет ответственность за это качество,
даже несмотря на то, что тестировщик у нас пропускает этот баг и не смог его в полной степени найти в нужное
время в нужном месте, потому что исчерпывающее тестирование невозможно и невозможно выпустить продукт,
в котором вообще не будет багов. В любом случае когда-то что-то всплывет. Все несут коллективную
ответственность за создание нашего инкремента (это вот эта часть нашей функциональности плюс все
остальные функциональности, которые уже были ранее реализованы, это называется инкремент).
Scrum master - это отдельный человек, еще называют лидер-слуга, т.е. это человек, который
фасилитирует работу в команде, согласно скраму. Т.е. он знает абсолютно всё насчет скрама, как он должен
работать, какие основные этапы у нас есть в скраме, какие церемонии и артефакты, помогает нам, обучает на
случай, если у вас возникают какие-то вопросы, связанные со скрамом, как он должен быть реализован,
направляет нас. Но он не участвует в разработке нашего инкремента. Он просто дает нам советы и может
подсказать, как нам лучше сделать. Наша задача, как Development team, которая решает как мы будем себя
вести во время итерации, что мы будем делать, к какому сроку мы это реализуем, как мы оценим те или иные
требования, как мы их приоритезируем уже после того, когда их приоритезирует product owner, скрам мастер он просто помогает. Скрам мастер фасилитирует работу команды и отвечает за то, чтобы мы работали согласно
скраму, если у нас принят такой процесс в компании. Поэтому, скорее всего, когда вы придете в компанию, к
примеру, как новичок, и у вас действительно будет работать всё по-старому, то скрам мастер вас научит, обучит,
расскажет, как это должно работать, расскажет, как устроены процессы у вас в компании и будет морально вас
поддерживать, чтобы у вас не возникали вопросы, связанные именно с функционированием скрам внутри вашей
команды, внутри вашего проекта.
События. Спринт (sprint). Вы часто можете слышать такое название, как итерация. Спринт - это некий
временной отрезок, примерно 2 - 4 недели, т.е. в течении которого у нас создается инкремент продукта, готовый
к использованию, т.е. который уже полностью соответствует тем требованиям, которые мы берем в работу во
время спринта и которые мы можем с полной уверенностью, по окончанию спринта, сказать, что они готовы для
того, чтобы их использовал наш конечный пользователь, наш заказчик.
Планирование спринта (Sprint Planning). Либо же планирование итерации. Обычно на планировании
спринта у нас собирается вся скрам команда, т.е. это и продукт оунер, и development team, и скрам мастер.
Проводится оно именно в начале нашего спринта. Во время этого планирования мы решаем, каким будет наш
инкремент в конце нашего спринта и как организовать нашу работу во время вот этой итераций, чтобы получить
готовый проект продукта. Во время нашего планирования спринта у нас есть backlog продукта, где у нас хранятся
абсолютно все требования, которые предъявляются к нашему продукту. Но во время вот именно планирования,
мы выбираем какие именно требования мы будем реализовывать во время нашего спринта, что мы будем брать
в эту итерацию, над чем мы будем работать. Это основная цель этого мероприятия. Отделить бэклог спринта
от бэклога продукта. Бэклог спринта - набор требований, который мы реализуем в нашем спринте и в нашей
итерации.
Ежедневный Scrum (Daily Scrum). Обычно он проводится раз в день и на нём вы говорите о том, что вы
сделали за вчерашний день, что вы будете делать сегодня и какие у вас есть препятствия для выполнения цели.
Если говорим про тестирование, то вчера я описал тест-кейс для такой то user story, сегодня я буду писать тесткейс для следующей юзер стори, и какие препятствия - мне не совсем ясно, как разработчики будут
реализовывать данную user story, поэтому я хочу сегодня связаться с разработчиком, на которого записано это
требование и выяснить у него, как это будет реализовано, что он будет делать. Вот это вы говорите. Если вы не
знаете, как избавиться от этого препятствия, не знаете, что вам нужно сделать, то команда приходит к вам на
помощь и подсказывает, чем мы можем тебе помочь. И так это проходит для каждого члена вашей команды
разработки. Они рассказывают о всех своих работах запланированных, либо проведенных, о проблемах, с
которыми они столкнулись, и, обычно, это занимает порядка 15 минут ежедневно. Для того, чтобы просто
держать руку на пульсе и знать над чем вы сейчас работаете.
Обзор спринта (Sprint Review). Задачей которого является то, что мы подводим итоги того, что было у
нас сделано во время нашего спринта. Т.е. проводим некий такой обзор: что мы реализовали во время этого
спринта, какие цели и задачи у нас были выполнены, все ли user story закрыты и т.д. Demo - демонстрация
нашего инкремента уже нашему продукт оунеру, либо заказчику, в зависимости от того, как у вас устроен этот
процесс. И не нужно путать тот факт, что на обзоре спринта мы должны показать,как работает этот инкремент,
показать эту демонстрацию. Обычно это отдельное мероприятие, которое проходит уже после обзора спринта.
Как это проходит? Вы просто показываете ту или иную user story продукта продукт оунеру, он говорит да,
действительно всё реализовано так, как мы хотели, т.е. это вот такие вот небольшие демонстрации.
Ретроспектива (Sprint Retrospective). Не стоит путать обзор спринта и ретроспективу. На ретроспективе
у нас основная цель в том, чтобы мы выяснили, все ли задачи мы выполнили, но по отношению к людям, к
команде разработки. И на этой встрече мы выясняем то, что мы могли бы улучшить, исходя из результатов
вашей итерации. Вы отвечаете на ряд вопросов. У нас в компании это было так: у нас была доска, расчерченная
на 4 столбца. Первый столбец - что хорошо шло в спринте, второй - какие у нас проблемы были в спринте,
третий - как можно улучшить работу, четвёртый - идеи по ходу ретроспективы. Если, например, у нас возникают
какие-то идеи уже по ходу ретроспективы, мы добавляем это на доску. Обычно просто клеят какие-то стикеры.
Если работа удалённо - просто расшаривают общий экран на всех участников. Затем выбирают некий топ,
основные такие проблемы и придумывают, как их улучшить, исправить, назначаются ответственные лица. На
следующей ретроспективе выясняют, смогли ли исправить.
Это, скажем так, основные вот такие четыре церемонии, которые у нас связаны со спринтом.
Артефакты. Бэклог продукта (Product Backlog). Мы с вами сегодня уже много говорили о бэклоге
продукта, т.е. о тех юзер сторис, которые мы должны реализовать для того, чтобы наш продукт вышел в свет.
Это абсолютно все user story, абсолютно все требования, которые есть у наших заказчиков и которые продукт
оунер добавил в наш backlog.
Уточнения бэклога продукта (Product Backlog Refinement). Основной целью этого мероприятия
является уточнение, оценка и упорядочивание элементов в бэклоге продукта. Собирается скрам команда и
product owner представляет вам какие-то новые юзер стори, которые он написал. Если у вас возникают какие-то
вопросы, вы чего-то не понимаете, вы задаете вопросы продукт оунеру, он это объясняет и, в случае если нужно
переработать ту или иную историю, он ее перерабатывает. К примеру, у меня в команде на рефайнментах также
происходит оценка юзер сторис, т.е. мы решаем, сколько стори пойнтов мы присваиваем той или иной юзер
стори, т.е., по сути, это сложность выполнения той или иной user story, но никак не время, которое мы
затрачиваем на её выполнение.
Критерий подготовленности (Definition of Ready). Критерий подготовленности фокусируются на уровне
бэклога, т.е. мы оцениваем юзер стори, которые предлагает нам product owner на степень того, насколько мы их
понимаем, насколько четко они прописаны, нет ли там каких-либо несоответствий согласно свойствам хороших
требований. И вот этот критерий подготовленности (DoR) помогает заказчику создавать хорошо написанные
пользовательские истории, которые готовы для разработки.
Критерий готовности (Definition of Done). Фокусируются на уровне спринта или релиза. Относятся
непосредственно к оценке степени готовности нашей функциональности. Если, к примеру, критерий
ПОДготовленности мы с вами устанавливаем на моменте ДО планирования итерации, то критерий готовности
мы уже с вами используем НА САМОМ ПЛАНИРОВАНИИ итерации, на планирование спринта. И здесь мы
выставляем какие-то ключевые точки, по которым мы будем оценивать, готова ли та или иная функциональность
или нет. Т.е. DoD - помогает проверить работу в соответствии со всеми требованиями проекта, а не только
продемонстрировать, что функциональности работают. К примеру, к критериям готовности можно отнести
следующие: что у нас написаны интеграционные тесты и они все прошли, у нас написаны юнит-тесты и они все
прошли, к примеру, количество критических багов у нас менее десяти процентов. Ну вот, выбираем такие
критерии готовности продукта. DoD позволяет нам оценить то, что у нас готов тот или иной участок работы, та
или иная функциональность и мы используем именно критерии готовности в данном случае.
Пользовательские истории (User Stories). Это формулировка намерения, описывающая что-то, что
система должна делать для пользователя. Это какое-то требование, которое мы должны реализовать. и она
состоит из следующего: AS A (role) - I CAN (Functionality) - SO THAT (Rationale) - ACCEPTANCE CRITERIA. КАК
Я (какая-то роль в системе) - МОГУ - ДЕЛАТЬ ЧТО-ТО - ДЛЯ ЧЕГО-ТО. “Делать что-то” - это какая-то
функциональность, которая у нас прописана в юзер стори, а “для чего-то” - это какая-то ценность для, скажем
так, нашего бизнеса. К примеру, “как новый пользователей в системе, я бы хотел купить телефон, чтобы
порадовать себя”, - вот такая user story. Дальше у нас есть acceptance criteria, т.е. критерии приёмки, где мы уже
подробненько расписываем, как эта функциональность будет реализована для того, чтобы мы достигли вот эти
ценности для бизнеса. И обычно вот эти вот acceptance критерии, когда мы говорим о тестировании, мы их берем
во внимание и тестируем, каждый вот этот критерий приёмки. Мы должны в наших тест-кейсах описать каждый
критерий приёмки, если мы говорим о каких-то позитивных сценариях. Ну так же, исходя из этого, мы пишем
негативные наши сценарии и можем использовать их, к примеру, для проектирования extended test,
расширенных тестов.
Покер планирование (Planning Poker). Как я уже говорил, мы оцениваем наши юзер сторис. Оцениваем
их по сложности в каких абстрактных штуках, которые называются стори поинты. Существует несколько
способов оценки наших юзер сторис. Один из самых популярных - это покер планирование. Есть ряд онлайн
тулов, которые позволяют нам давать оценку. Например, https://www.planitpoker.com. Мы создаём такую комнату,
где прописываем все user story, которые у нас будут реализованы, которые мы должны оценить. Собирается вся
команда разработки и они решают, сколько присвоить стори поинтов в зависимости от того, какой опыт у
разработчика, какой опыт у тестировщика, сколько он работает на проекте, новый человек ты или нет, могут
выставлять абсолютно разные стори поинты. После этого, когда все проголосовали, смотрим, совпадают ли у
нас эти стори поинты. Если мнения не совпадают - обсуждаем, приводим аргументы за и против, приходим к
единому мнению, заново голосуем, и так по кругу. Когда уже большее количество участников команды
проголосуют одинаково, равномерно, и не будет сильно выпадающих значений, тогда мы принимаем решение,
сколько присваивать стори поинтов той и иной user story. Частенько многие ошибаются, говоря о том, что стори
поинт - это сколько времени займет выполнение, нет это привязка к сложности выполнения той или иной задачи,
основанная на каком-то нашем предыдущем опыте.
Возвращаясь к нашим бэклогам, мы с вами поговорили про бэклог продукта, т.е. где у нас будут
сохраняться абсолютно все требования, которые предъявляются к нашему продукту, который мы
разрабатываем. Также есть бэклог спринта, как я уже сказал, мы выбираем, что именно мы будем
реализовывать в данном спринте, т.е. просто перетягиваем из бэклога продукта сторьки в бэклог спринта.
Инкремент продукта (Product Increment). Инкремент продукта - это всё то, что мы разработали ДО и
разработаем в конце данной итерации. Никогда не нужно говорить, что инкремент - это то, что мы
разрабатываем в данной конкретной итерации. Инкремент продукта - это то, что у нас уже было разработано до
этой итерации плюс вот эта часть функциональностей, которые мы разработаем в данной конкретной итерации.
Метрики. Они регламентируют сколько, к примеру, задач мы можем взять в ту или иную итерацию, как
быстро мы можем их выполнить, и вообще просмотреть, в динамике, как у нас изменяется количество задач,
которые мы выполняем с течением времени.
Velocity (скорость). Это скорость нашей скрам команды. Она рассчитывается как среднее
арифметическое значение завершенных стори поинтов в предыдущих спринтах. Т.е., к примеру, у нас какая-то
новая команда и мы не знаем velocity, потому что у нас ещё не закончилась первая итерация, поэтому мы берем
какое-то определенное количество стори поинтов в данную итерацию, выполняем их и смотрим, сколько мы
смогли выполнить. И так с каждой итерацией. Когда у нас уже соберется некоторое количество исторических
данных, мы сможем собрать арифметическое значение, среднее, по этим нескольким итерациям, и сказать, что
вот у нас, согласно статистике, мы можем брать в итерацию 30 сторей поинтов, ни больше, ни меньше.
Capacity (ёмкость). Количество доступного времени членов команды. Как она рассчитывается? Просто
берём те часы, которые у нас есть в итерации на каждого конкретного штатного разработчика в нашей команде.
Если итерация занимает 10 дней, из которых 2 дня выходных, мы отнимаем эти 2 дня выходных, у нас остается
8 дней. И мы знаем, что рабочий день 8 часов, т.е. умножаем 8часов на 8дней = 64 часа. Это наша емкость.
наша capacity на одного разработчика. И эти 64 часа мы перемножаем на общее количество разработчиков в
нашей команде. Сюда нужно закладывать различные риски (болезнь, пандемия и т.д., праздничные дни). Этим
занимается уже скрам мастер.
Диаграмма сгорания задач (Burndown Chart).
Накопительная диаграмма потока (Cumulative Flow diagram).
В конце хотел бы Вас поздравить с тем, что мы закончили курс тестировщик с нуля. Я очень надеюсь, что
данный курс действительно поможет вам разобраться в тестировании и найти вашу первую работу.