Уиттакер . - Как тестируют в Google

Тут можно читать онлайн Уиттакер . - Как тестируют в Google - бесплатно полную версию книги (целиком) без сокращений. Жанр: Прочая старинная литература, издательство Издательский дом Питер, год 2014. Здесь Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.

Уиттакер . - Как тестируют в Google краткое содержание

Как тестируют в Google - описание и краткое содержание, автор Уиттакер ., читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru

Как тестируют в Google - читать онлайн бесплатно полную версию (весь текст целиком)

Как тестируют в Google - читать книгу онлайн бесплатно, автор Уиттакер .
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Рис. 3.5. Связь компонентов и атрибутов в GTA

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

Числовые значения в ячейках показывают количество возможностей, которые может предложить компонент для выполнения атрибута. Чем число выше, тем больше тестов связано с таким пересечением. Например, компонент «Просмотр страницы» взаимодействует с атрибутом «доступный» в трех возможностях:

— сделать документ доступным для сотрудников;

— дать возможность сотрудникам редактировать документ;

— показывать положение сотрудника на странице.

Итак, эти возможности проясняют моменты, которые нужно протестировать для пары «Просмотр страницы» и «доступный». Мы можем написать тест-кейс для каждой из них или протестировать комбинацию возможностей, объединив их в более крупный сценарий использования или тестовый сценарий.

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

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

— Возможность должна предоставлять тестировщику достаточно информации, чтобы он понял, какие переменные надо учитывать при написании тест-кейса. Например, дана возможность — «Обработать финансовые операции с помощью HTTPS». В данном случае тестировщик должен понимать, какие финансовые операции может выполнить система, какой механизм будет проверять осуществление операции через HTTPS. Да, работа немалая! Если вы думаете, что какие-то финансовые операции могут быть упущены, скажем, новым тестировщиком, то продублируйте эту возможность для разных типов операций. Опять же, если команда тестирования собаку съела на HTTPS, то общей формулировки будет вполне достаточно. Не усложняйте себе задачу и позволяйте возможностям оставаться общими, оставьте тест-кейсам и исследовательским тестировщикам самим определить нужный уровень детализации36.

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

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

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

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

— Многие возможности требуют более одного тест-кейса. Каждый раз, когда во входной информации есть отклонения, последовательности ввода, системные переменные, тест-кейсов нужно делать несколько. Атаки, описанные в книге «How to Break Software», и туры в «Exploratory Software Testing» здорово описывают принципы выбора тестовых примеров и подход к выбору данных, которые легко превращают возможность в тест-кейс, вылавливающий баг.

— Не все возможности равны. Есть те, которые важнее других. На следующем шаге процесса возможности связываются с рисками и определяют степень их важности.

Завершив ACC-анализ, мы знаем все, что мы могли бы протестировать при неограниченном бюджете и времени. Но поскольку часто не хватает то одного, то другого, будет полезно выделить главное. В Google такая расстановка приоритетов называется анализом рисков , и это будет нашей следующей темой.

Пример: определение атрибутов, компонентов и возможностей Google+

ACC-анализ можно быстро выполнить в текстовом документе, таблице или даже на салфетке! Ниже следует сокращенный вариант ACC-процесса для Google+.

Атрибуты Google+(список сформирован на основе наблюдения за дискуссией руководства Google).

— Социальный: позволяет пользователю обмениваться информацией и мыслями.

— Выразительный: пользователи используют возможности продукта для самовыражения.

— Простой: пользователь легко понимает, как сделать то, что он хочет.

— Релевантный: показывает только ту информацию, которая интересует пользователя.

— Расширяемый: интегрируется с другими ресурсами Google, сторонними сайтами и приложениями.

— Конфиденциальный: данные пользователя не будут открытыми.

Компоненты Google+(получены из архитектурной документации).

— Профиль: информация и настройки текущего пользователя.

— Люди: профили людей, с которыми связан пользователь.

— Лента: ранжированная лента сообщений, комментариев, оповещений, фотографий и т.д.

— Круги: группы контактов («друзья», «коллеги» и т.д.).

— Оповещения: обозначения упоминания пользователя в сообщении.

— Интересы, или «+1»: обозначения материалов, которые понравились пользователю.

— Записи: сообщения о записях пользователей и их кругов.

— Комментарии: комментарии к сообщениям, фотографиям, видеороликам и т.д.

— Фотографии: фотографии, загруженные пользователями и их друзьями.

Возможности Google+.

Профиль:

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

— Выразительный: создавать онлайн-версию самих себя.

— Выразительный: взаимодействовать с Google+ по-своему.

— Простой: легко вводить, обновлять и распространять информацию.

— Расширяемый: передавать данные профилей приложениям с соответствующими правами доступа.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать


Уиттакер . читать все книги автора по порядку

Уиттакер . - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




Как тестируют в Google отзывы


Отзывы читателей о книге Как тестируют в Google, автор: Уиттакер .. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x