Уровень 2
Место тестирования в процессе разработки
Добро пожаловать в новый уровень, мой юный падаван! Перед тем, как ты узнаешь новые тайны силы тестирования, я хотел бы разобрать с тобой домашнее задание. На видео магистр Ки-Ади-Мунди покажет, как он протестировал сайт из практического задания. Он поделится тайнами практического тестирования, расскажет на что обращать внимание и какой подход применять.
Итак, приступим к нашей теме - "Место тестирования в процессе разработки". Возможно, ты будешь уверять, что ты совсем не готов еще, но уже на втором уровне тебе придется встретиться с силами зла! Как ты догадываешься - главные силы зла - это программисты или разработчики. Именно они создают коварный код, который содержит все эти ужасные баги.
Кто-то скажет, что в жизни они добродушные бородатые толстячки, которые и мухи не обидят. И это тоже правда. Но на поле разработки ПО - это наши главные враги.
Мой юный падаван, сегодня мы идем на рискованное мероприятие, мы будем наблюдать за тем как идет процесс на звезде смерти (у программистов) и сравнивать их рабочий процесс с нашим, чтобы быть максимально эффективными. Ибо врага нужно знать лучше чем друга!
Стадии тестирования и разработки
Уровень 2 Galaxy QA Academy, еще не доступен в мобильной версии, пожалуйста воспользуйтесь десктопной. Извините за неудобства.
Development process
Testing process
Проектирование тестов. Например тест кейсов
Программирование (coding)
Cоздание версий продукта который вы тестируете (build)
Выполение тестов (прохождение тест кейсов, запуск автотестов)
Отладка тестов
(адаптация тест кейсов к изменившемуся функционалу)
Результат тестирования
(test result)
Поддержка продукта
Поддержка продукта
Далее схема организации взаимодействия разработки и тестирования ПО. Про каждый этап вы можете узнать подробнее перейдя по ссылке, хотя большинство этих понятий вы еще встретите на следующих уровнях более подробно.
Подробнее о стадиях тестирования
Тестирование
программного продукта
Планирование процесса тестирования
Проектирование тестов
Выполнение
тестов (testing cycles)
Отладка тестов
Системное тестирование
(System Testing)
Стадии статического тестирования:
-
Анализ требований - изучение спецификаций, функциональных требований к системе. Получение данных для составления плана проведения тестирования
-
Планирование процесса тестирования - определение объемов тестирования, подходов, ресурсов и расписание выполнения намеченных действий
-
Проектирование тестов - определение цели тестирования, спецификации входных данных, архитектуры тестов для упорядочивания тестов по группам
Стадии динамического тестирования :
-
Выполнение тестов (testing cycles) - непосредственная проверка спроектированных тестов, анализ всевозможных тестовых случаев
-
Отладка тестов - Пересмотр и отладка тестовых случаев
-
Системное тестирование (System Testing) - Функциональная проверка, тестирование для определения рабочих характеристик
-
Приемочные испытания (Acceptance Testing): Альфа-тестирование, Бета-тестирование
-
Эксплуатация и поддержка - Проверка результатов, исправление дефектов
Приемочные испытания
(Acceptance Testing)
Эксплуатация и
поддержка
Мы увидели концепцию процесса тестирования и разработки, так сказать - с высоты птичьего полета. Теперь пора спуститься на землю и рассмотреть конкретные вещи.
Давайте рассматривать вещи от простого к сложному:
-
Анализ требований - уровень 8
-
Планирование - уровень 7
-
Проектирование тестов - вот тут давайте поподробнее
Все пункты далее мы начнем рассматривать сейчас и плавно продолжим над ними работать в следующем уровне. Начнем тему с того, что поймем что же такое Тест.
Определение теста и тестового набора
Тест – «триплет» Вход/Состояние/Выход
Тест - это последовательность шагов/действий, которая переводит систему из одного состояния в другое
Тест описывается аббревиатурой ISO, где:
-
[I] – is input data or action (входные данные или действия)
-
[S] – is State of system at which data will be input (состояние системы, которая получает входные данные или воздействие)
-
[O] – is the expected Output (ожидаемые Выход, выходные данные или выходное состояние системы)
Тестовый набор
-
Набор тестов, реализующих законченную бизнес задачу, автоматизированную функциональностью системы под тестом
-
Тестовый набор включает, кроме непосредственно тестовых сценариев, также и тестовые данные или правила их создания/генерации
Тестовый набор – практические соображения
-
После объединения тестов в наборы не должно оставаться незадействованных тестов
-
При проектировании тестов «сверху вниз», тест кейсы будут являться частями тестовых наборов
-
Рекомендуется применять именно проектирование тестов «сверху вниз»
Тестовое покрытие – практические соображения
-
Количество тестов не определяет качество тестового покрытия
-
% тестового покрытия не определяет степень доверия к результатам тестирования, если он не равен 100%
-
100% покрытие в условиях реальных разработок практически недостижимо
-
Увеличивайте порог тестового покрытия в случае возникновения ошибок в тестовой области или компоненте
Разработка тестовых сценариев – практические соображения
Существуют формальные методы разработки тестовых сценариев
-
Методология разработки тестовых случаев на основе сценариев использования
-
Методология разработки тестовых случаев на основе ортогональной классификации дефектов
Существуют формальные методики оценки объемов работ требуемых для минимального тестового покрытия
-
Метод расчета цикломатической сложности основанный на метрике МакКаби (McCabe)
Смешанные методики - комбинация подходов
Классификация тестирования по уровню «готовности» системы
Unit level - модульный уровень
-
Тестирование целостности кода на уровне логических модулей
-
Выполняется разработчиками
-
Контролируется группой тестирования с помощью инструментов анализа покрытия кода unit-тестами (unit test coverage tools)
Комментарий: согласно TDD концепции, тестировщик должен требовать от программистов покрытия кода unit-тестами (элементарное тестирование каждого модуля). Не всегда является обязанностью тестировщика. C точки зрения мануального тестирования модульный уровень - это тестирование отдельно стоящей формы входа (login + password)
Integration level - кросс модульное взаимодействие
-
Тестирование промежуточных результатов интеграции системы
-
Выполняется разработчиками и тестировщиками
Комментарий: c точки зрения мануального тестирования это перенос вашей формы входа на страницу сайта и проверка взаимодействия формы и страницы сайта.
System level - уровень системы в целом
Валидация полностью построенной системы на соответствие сформулированным требованиям
Под - уровни системного тестирования:
-
Alpha Testing
Выполняется группой тестирования внутри команды/организации разработки
-
Beta Testing
Выполняется группой тестирования в среде дружественно настроенных клиентов
-
Acceptance Testing
Выполняется клиентом с целью определить будет ли система принята в эксплуатацию
-
«Дымовое тестирование» (smoke testing) Выполняется группой тестирования с целью определения будет ли система принята в тестирование. Применяется для того чтобы определить рабочая ли программа в принципе и стоит ли начинать цикл тестирования.
Комментарий: c точки зрения мануального тестирования это тестирования формы в рамках всего проекта. Пример - проверка базы данных пользователей в которой должна появится новая запись после регистрации пользователя на вашем готовом сайте через форму входа
Поздравляю! Половина второго уровня пройдена.
Самое время сделать перерыв и размять спину, выпить чайку, глубоко вдохнуть и снова погрузиться в мир тестирования
Классификация тестирования по применяемому подходу
Black box (Functional) Testing
-
Тестирование с точки зрения конечного пользователя
-
Зачастую комбинируется с методиками «белого ящика»
-
Наиболее распространённые методики тестирования для user-oriented систем и приложений
Думаю ты готов идти дальше, мой друг. Удачи!
White box (Structural) Testing
-
Анализ приложения на уровне кода
-
Выделяют ручное – экспертное тестирование кода и автоматизированное тестирование инструментами статического анализа
-
Один из наиболее «дорогостоящих» методов тестирования, требующий квалификации высокого уровня
Grey box testing (серый ящик)
-
Смешанная адаптивная методика, применяемая опытными тестировщиками или разработчиками при отладке
-
Анализ приложения с точки зрения выполнения операций конечным пользователем и контроля полученных результатов с применением знаний о коде приложения и подробностей реализации функций приложения
Функциональное тестирование
Функциональное тестирование – первичный вид тестирования, который направлен на проверку соответствий функциональных требований ПО к его реальным характеристикам. Основной задачей функционального тестирования является подтверждение того, что разрабатываемый программный продукт обладает всем функционалом, требуемым заказчиком.
В зависимости от цели, функциональное тестирование может проводиться:
• На основе функциональных требований, указанных в спецификации. При этом для тестирования создаются тестовые случаи (Test cases). Их составление учитывает приоритетность функций ПО, которые необходимо покрыть тестами. Таким образом мы можем убедиться в том, что все функции разрабатываемого продукта работают корректно при различных типах входных данных, их комбинаций, количества и тому подобное.
• На основе бизнес-процессов, которые должно обеспечить ваше приложение. В этом случае нас интересует, не так работоспособность отдельных функций ПО, как корректность выполняемых операций с точки зрения сценариев использования системы. В данном случае тестирование будет основываться на вариантах использования системы (usecases).
• На основе здравого смысла. Так как, и в документации проекта и даже в уме архитектора может быть ошибка (что-то забыли, что-то не учли) тестировщик должен быть всегда на чеку. Противоречие составленного ТЗ здравому смыслу и опыту должно вызывать естественную реакцию - тут баг!
Нефункциональное тестирование
В отличии от функционального тестирования, целью которого является проверка
явной работоспособности программы, нефункциональное тестирование может быть не указанно в требованиях. В это понятие вмещается все то что влияет на качество программы, но не относится к ее бизнес логике напрямую.
Нефункциональные требования характеризуют продукт с таких сторон, как:
-
Надежность - способность программной системы стабильно работать длительное время без вмешательства человека
-
Производительность - работоспособность системы под различными плановыми нагрузками
-
Масштабируемость - требования к горизонтальному или вертикальному масштабированию приложения. Приложение должно красиво адекватно изменять верстку при добавлении или удалении структурных елементов. То же относится и к архетиктуре приложения
-
Безопасность - защищенность пользовательских данных от взлома, защита системы от постороннего воздействия, не авторизированного доступа и защищенность данных пользователя от ошибок системы
-
Тестирование установки (Installation testing) – проверка успешности установки приложения, его настройки и удаления. Снижает риски потери пользовательских данных, потери работоспособности приложения и прочее
-
Тестирование удобства использования (Usability testing) – характеризует систему с точки зрения удобства использования конечного пользователя
-
Конфигурационное тестирование (или тестирование портируемости) – исследование работоспособности программной системы в условиях различных программных конфигураций
-
Тестирование на отказ и восстановление (Failover and Recovery Testing) – исследование программной системы на предмет восстановления после ошибок, сбоев. Оценивание реакции защитных свойств приложения
-
Стресс тестирование – это вид тестирования, который характеризует систему с точки зрения устойчивости ее работы при условиях, превышающих нормальные. Не путайте с тестированием производительности, ведь в этом случае речь идет только о пиковых нагрузках, а не о расчетных
-
Тестирование производительности – это комплекс типов тестирования, целью которого является определение работоспособности, стабильности, потребления ресурсов и других атрибутов качества приложения в условиях различных сценариев использования и нагрузок. Тестирование производительности позволяет находить возможные уязвимости и недостатки в системе с целью предотвратить их пагубное влияние на работу программы в условиях использования. В этом случае речь идет только о плановых нагрузках, описаных в требованиях к продукту
-
Тестирование взаимодействия и совместимости (compatibility) – вид тестирования, нацеленный на оценку качества взаимодействия компонент программной системы или всего приложения с другими компонентами или программным обеспечением
Классификация тестирования по типам проверки
Верификация (verification) – это процесс оценки системы или её компонентов с целью определения того, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. То есть выполняются ли задачи, цели и сроки по разработке продукта.
Валидация (validation) – это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.
Следующая таблица поможет выделить ключевые отличия между этими понятиями:
Usability и GUI тестирование
Usability и GUI тестирования тесно связаны, потому что у них пересекаются объекты тестирования - интерфейсы. Также эти виды тестирования удобно проводить одновременно. К юзабилити и GUI тестированию относится:
Экспертная оценка удобства использования
В этом случае вы прикидываетесь крутым дизайнером и осуществляете экспертную оценку вашего приложения в соответствии с целями проекта, функциональными и нефункциональными требованиями к ПО. Процедуры экспертной оценки включают в себя:
-
анализ информационной архитектуры приложения
-
анализ интерфейса и элементов интерфейса
-
анализ функционального соответствия интерфейса
-
cоответствие дизайна проекта корпоративному дизайну
Пример: выполняете всяческую тонкую оценку, единый стиль приложения, качество картинок, лишние линии и даже пиксели, масштабируемость и растягиваемость GUI приложения, грамматические ошибки и т.д.
Имитация поведения пользователей
В этом случае вы принимаете роль самого примитивного юзера и выполняете проверку поведения приложений путем имитации его поведения. Ваша задача забыть приложение и начать им пользоваться с нуля. Задача - получить представление о пользовательском впечатлении в целом. Найти все моменты которые могут испортить настроение пользователю. Багом тут будет все, что неочевидно и непонятно новому пользователю.
Пример: ожидание результата без прелоадера более трех секунд - баг или ссылка которая не подчеркнута, неверная форма курсора при наведении - usability баг. Отсутствие подсказок при сложном процессе регистрации и тому подобное.
Последний нырок в функциональное тестирование
Виды тестирования, итог:
Это моя любимая схема. Стоит ее принять к сердцу близко. Очень часто на собеседованиях по тестированию дают подобное задание - протестировать какой-либо предмет. Оно показывает насколько гибок ум тестировщика в плане видов и объекта тестирования. Ведь не важно что перед вами, а важно понимать логическую концепцию видов тестирования. Просмотри и впитай эту схему НАВЕЧНО, если тестировщиком вознамерился стать.
Далее будут перечислены виды тестирования которые являются разделами либо вариациями функционального тестирования. При этом также проверяется правильность работы приложения, но есть свои особенности ...
Регрессионное тестирование (regression testing) – это набор тестов, направленных на обнаружение дефектов в уже протестированных участках приложения. Делается это совсем не для того, чтобы окончательно убедиться в отсутствии багов, а для поиска и исправления регрессионных ошибок, то есть ошибок в том, что уже работало исправно до этого. Такие ошибки, как правило, вызваны исправлением других ошибок либо добавлением нового функционала, причем в совсем другое место. Ведь программа как Кубик Рубик, повернул одну грань, а цвета изменились по всему поясу.
Автоматизированное тестирование - предполагает использование специального программного обеспечения (или написанного вами кода) для контроля выполнения тестов и сравнения ожидаемого и фактического результата работы программы. Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия задачи. И мы этому научимся!
Негативное тестирование (negative testing) - является подразделом функционального тестирования и предусматривает отработку тех сценариев, которые могут произойти с системой, если, скажем, пользователь допустит ошибку при вводе данных или намерено попытался вывести ее из строя. В данном случае, система должна быть готова «ответить» на запрос пользователя сообщением об ошибке.
Пример: при ожидаемом вводе от 0 до 10 ввести -1 и пустое значение.
Стратегия тестирования
Стратегию тестирования вам предстоит применить на практике при тестировании плеера. Но пока не все виды, а только те что отмечены желтым.
Типы тестирования в обычной стратегии:
-
Функциональное тестирование
-
Негативное тестирование
-
Тестирование бизнес-циклов
-
Usability тестирование
-
Тестирование пользовательского интерфейса
-
Тестирование данных и целостности базы данных
-
Нагрузочное тестирование
-
Тестирование безопасности и управления доступом
-
Конфигурационное тестирование
-
Инсталляционное тестирование
-
Инструментальные средства
Понял ли ты урок? Ответь на вопросы
Практическое задание
Наступило время применить новые знания на практике.
Для начала попрактикуйся в видах тестирования.
Первое задание - выбрать предмет из списка, который тебе более по нраву и написать по одному тесту для каждого вида тестирования.
Сделай это аналогично тому, как тестировали карандаш, но в виде таблицы (вид тестирования - тест). Задание нужно оформить в Google doc по этому шаблону и отправить через форму.
Второе задание - тест по теории. Узнай, насколько ты понял материал. Не забудь залогиниться в систему тестирования.
Третье задание еще более практичное. Попробуй использовать виды тестирования при тестировании сайта. Все найденые баги также запиши в отдельный Google doc и отправь через форму. Я верю у тебя все получится!
Предметы для первого задания:
1. Стул
2. Бутылка минералки
3. Степлер
4. Дырокол
5. Папка для бумаг
6. Настольная лампа
7. Пульверизатор
8. Линейка
9. Скотч
10. Нож для бумаги
11. Отвертка
Я в восторге от твоих успехов! Щелкаешь уровни как семечки. Я думаю уже становится понятно что стать тестировщиком совсем не сложно. Но это только начало пути и впереди еще 19 уровней, каждый из которых уникален как по содержанию, так и по дизайну. Делай шаг дальше и открывай новые загадки силой тестирования.
Я с удовольствием проверю результат твоей работы после того как ты подкинешь старому магистру пару кредитов на новый световой меч, а то старый уже, то барахлит...
Для перехода на уровень 3, необходимо набрать минимум 20,6 балла за задания уровня 2.
