Home

Продолжение чек-листа Майкла Хантера с идеями, которые могут вас подстегнуть для дальнейшего тестирования.

Начало статьи, окончание статьи

Автор: Майкл Хантер (Michael Hunter)

Оригинал статьи: http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf

Перевод: Ольга Алифанова

Поведение диалоговых окон

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

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

Интерактивность диалоговых окон

Вы не закончили тестировать, если вы не проверили диалоговые окна как следует:

• Убедитесь, что в заголовке диалогового окна отображаются нужные контрольные элементы (например, некоторые окна можно увеличивать, а некоторые – нет), и что они работают как надо.
• Убедитесь, что дефолтные положения элементов, отвечающих за фокус и редактирование, находятся в правильном положении.
• Убедитесь, что диалоговое окно можно отменить, нажав:
• Escape (вне зависимости от положения фокуса на контрольных элементах)
• Системную кнопку "Закрыть" (крестик в диалоговых окнах MS Windows)
• Кнопку отмены на диалоговом окне.

• Убедитесь, что навигация через TAB следует в правильном порядке.
• Убедитесь, что у всех контрольных элементов есть сочетание клавиш, позволяющее их активировать, что оно работает, и что оно уникально в рамках этого диалогового окна.
• Убедитесь, что подсказки для всех элементов окна верны.
• Убедитесь, что взаимоисключающие контрольные элементы правильно работают одновременно.
• Проверьте все состояния диалогового окна (например, различные наборы контрольных элементов, отображающиеся в зависимости от состояния системы, или кнопки "Развернуть" и "Свернуть").
• Убедитесь, что все контрольные элементы, которые могут принимать неопределенное состояние (например, кнопка полужирного начертания примет неопределенное состояние, если в выбранном тексте есть как полужирное начертание, так и какое-либо другое), работают корректно.
• Убедитесь, что редактирование неопределенного значения ведет к соответствующему результату (например, применяет новое состояние ко всем выбранным элементам – если вернуться к примеру с полужирным начертанием, то весь текст становится полужирным).
• Убедитесь, что каждый контрольный элемент верно реагирует на правильный и неправильный ввод, включая граничные значения. К примеру, неверный ввод может выводить на экран сообщение, или подсвечивать элемент каким-то образом.
• Убедитесь, что диалоговое окно отображается и функционирует корректно:
• При различных цветовых схемах
• При различных настройках шрифтов
• В режиме высокой контрастности
• В режиме высокого DPI

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

Внешний вид диалоговых окон

Вы не закончили тестировать, не проверив следующее:

• Убедитесь, что команды меню, инициирующие открытие диалогового окна, заканчиваются многоточием (например, "Создать новый файл…"). Так принято в MS Windows. Если вы используете другую операционную систему, загляните в руководство по ее стилям.
• Убедитесь, что размер каждого элемента и расстояние между каждой парой элементов соответствует вашему руководству по стилю.
• Убедитесь, что размер диалогового окна соотносится с его контрольными элементами.
• Убедитесь, что элементы, находящиеся в неопределенном состоянии, выглядят так, как должны выглядеть согласно вашему руководству по стилю (обычно они становятся серыми или еще каким-то явным образом демонстрируют, что состояние не определено).
• Убедитесь, что образцы работы в диалоговом окне правильно отражают содержание и форматирование актуального документа. Если это не так, лучше вообще не показывайте их! Диалоговые окна, связанные с изменением форматирования, часто демонстрируют, к какому эффекту приведут внесенные изменения. Демонстрация актуального документа (или подходящей его части, например, выделенного в данный момент текста) увеличивает ценность предпросмотра работы функции. Если в вашем предпросмотре отображается какой-то абстрактный пример, который (возможно) чем-то похож на реальный документ – лучше вообще ничего не показывайте.

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

Ввод в текстовые поля

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

• Null (при тестировании API)
• Пустое поле
• Один символ
• Два символа
• Несколько символов
• Много символов
• На 1 меньше максимального количества символов
• Максимальное количество символов
• На 1 больше максимального количества символов
• Пробелы
• Спецсимволы (запятая, нижнее подчеркивание) в тексте
• Пунктуационные символы
• Символы ASCII
• Символы из расширенной таблицы ASCII
• Немецкие символы
• Японские символы
• Символы иврита
• Арабские символы
• Символы Unicode из разных диапазонов
• Управляющие символы.

Обработка текста иногда прямо-таки кишит ошибками. Если ваше приложение на 100% в Unicode, считайте, что вам повезло. Но даже в этом случае попробуйте импортировать или экспортировать данные из кодировок, отличных от Unicode. Если приложение обрабатывает ASCII-текст – развлекитесь тестированием страниц в разных кодировках (попробуйте сменить кодировку во время ввода текста и посмотрите, что произойдет). А если приложение использует двухбайтовую или мультибайтовую кодировку – может, вам стоит задуматься о смене профессии.

Отмена и возврат

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

• Подумать, должно ли отменяться любое пользовательское действие.
• Подумать, должна ли быть доступной возможность вернуть любое пользовательское действие.
• Протестировать один уровень отмены.
• Протестировать несколько уровней отмены.
• Протестировать один уровень возврата.
• Протестировать несколько уровней возврата.
• Воспользоваться возвратом большее количество раз, чем отменой. В некоторых приложениях "возврат" может означать "повтор действия".
• Протестировать смешанную последовательность отмены и возврата.
• Убедиться, что каждое отмененное и возвращенное действие правильно выводится в интерфейсе этих функций.
• Протестировать отмену и возврат при сохранении документов (некоторые приложения сбрасывают возможные для отмены и возврата действия после сохранения).
• Протестировать отмену и возврат, закрыв и переоткрыв документ.
• Протестировать отмену и возврат на разных билдах, если ваше приложение создает билды или использует другие билды (например, позволяет пользователю ссылаться на другие библиотеки). Содержание билда может измениться – как вернуть действие, субъект которого отсутствует в библиотеке?

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

Может, вы решите, что один человек будет тестировать отмену и возврат во всем приложении. Лично для меня лучше работает, если люди проверяют отмену и возврат по отдельности, каждый в своей области.

Печать

Вы не закончили тестировать, если не проверили, как ваше приложение выводит информацию на печать. Если помните, в старые "добрые" времена, до того, как операционные системы фактически стерли различия между принтерами, каждому приложению требовалось вступать с принтером в интимное знакомство, чтобы воспользоваться им. Теперь все иначе, и у вас больше времени поинтересоваться вот чем:

• Убедитесь, что смена ориентации страницы работает правильно. Попробуйте поменять ее для свежесозданного документа, для документа, с которым уже велась работа. Попробуйте изменить ориентацию напрямую через диалоговое окно приложения (например, через меню), и через диалоговое окно печати.
• Убедитесь, что печать на локальный принтер осуществляется.
• Убедитесь, что печать на сетевой принтер осуществляется.
• Убедитесь, что печать в файл работает. Все ОС, с которыми я знаком, позволяют печатать в файл вне зависимости от установленного принтера.
• Убедитесь, что печать на PCL-принтер работает. PCL родился, как язык управления для принтеров Hewlett-Packard, но в итоге стал практически стандартом.
• Убедитесь, что печать на PostScript-принтер работает. Этот язык управления был создан Adobe и тоже стал фактически стандартом. В нем легко разобраться, поэтому можно протестировать принтер, исследовав полученный файл, и сэкономив таким образом бумагу.
• Убедитесь, что печать в PDF работает. Существует множество бесплатных или очень дешевых редакторов, позволяющих это. Рассмотрите также возможность приобретения Adobe Acrobat, чтобы "официально" протестировать подобную печать.
• Убедитесь, что отмена печати, когда печать уже в процессе, работает. Мой нынешний принтер делает вид, что согласен с отменой, но продолжает плеваться страницами. Бесит!
• Убедитесь, что изменение настроек печати, поддерживаемых вашим приложением, дает желаемый эффект: например, количество копий, разбор по копиям, нумерация страниц.
• Убедитесь, что настройки, специфичные для принтера, работают. Они по идее должны соответствовать настройкам вашего приложения, но никогда не знаешь, где наткнешься на баг.

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

Даже когда диалоговое окно печати абсолютно, стопроцентно стандартное, я пробегаюсь по нему просто для самоуспокоения. То же самое касается настроек принтера. Да. все ДОЛЖНО работать нормально, но я буду счастливее, когда я ЗНАЮ, что оно так работает!

В общем случае это связано с оценкой рисков вашего приложения. Баги МОГУТ быть где угодно – где, с вашей точки зрения, вы их вероятнее всего найдете? Начинайте с этих областей, затем переходите к следующей группе риска, и так далее. Подключайте исследовательское тестирование, потому что баги любят кучковаться в местах, куда вы даже не подумаете заглянуть!

Особые режимы и состояния

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

• Разные уровни масштабирования, если это применимо. Я сталкивался с приложением, для которого были написаны тысячи автотестов, и все было отлично. Потом кто-то попробовал изменить масштабирование и нашел целую кучу багов. Упс.
• Безопасный режим. Windows, стартующая в этом режиме, загружает только самое важное – базовый драйвер дисплея, голые сетевые стеки – и не запускает приложения и сервисы, находящиеся в автозапуске. Сможет ли ваш продукт выжить в таких условиях?
• Документы, находящиеся в совместном доступе для нескольких пользователей/компьютеров, одновременно и последовательно. Это особенно важно, если программа имеет доступ к базе данных (что произойдет, если кто-то одновременно с вами редактирует запись?), но если вы можете открывать документы из сетевых расположений или общих папок на локальной машине, кто-то еще может сделать то же самое с тем же документом, который вы редактируете.
• Файл не открыт, открыт несохраненный файл, открыт несохраненный файл с автосохранением, открыт сохраненный файл.
• Полноэкранный режим и другие варианты просмотра.
• Различные размеры окна приложения (и окна документа, если ваше приложение поддерживает интерфейс с несколькими документами), особенно размер по умолчанию при запуске, минимизированный, максимизированный, не максимальный, но растянутый до пределов экрана, очень маленький.
• Спровоцируйте режим ожидания, гибернацию и другие энергосберегающие режимы, работая с приложением. Через боль и отчаяние я узнал, что когда у приложения открыто модальное окно, это блокирует переход операционной системы в спящий режим.
• Выведите компьютер из различных режимов ожидания. Начатые до перехода в этот режим операции возобновились? Перезапустились? Или зависли?
• Изменение системных настроек. Поиграйте со скоростью мыши. Измените длительность повторного нажатия клавиш. Поменяйте системные цвета. Подхватит ли ваше приложение новые значения, когда запустится? Подхватит ли оно их, если оно уже запущено?
• Связывание и внедрение объектов (OLE). Если ваше приложение поддерживает OLE, вы попали в Диснейленд тестировщика! Правильно ли работает внедрение других OLE-объектов в ваше приложение? Как насчет встраивания документов из вашего приложения в другие, поддерживающие OLE? Правильно ли активируются и деактивируются внедренные приложения? Связанные OLE-документы изменятся, если изменен источник связи? как ваше приложение обращается со связями, если приложение, поддерживающее источник, более недоступно?
• Множественный выбор. Что произойдет, если вы измените форматирование текста при нескольких выделенных областях? А если нажмете "Вставить" в той же ситуации? Как должно работать?

Еще два специальных состояния не относятся к контексту прогона тестов. Это скорее дополнительные тесты, которые можно провести после других:

• Функция "отправить". Многие приложения имеют опцию отправки документа по электронной почте. Я видал случаи, когда попытка ей воспользоваться крашила приложение, или делала что-нибудь похуже.
• Вырезать, скопировать, вставить. "Сам в себя", в другой документ, в другие приложения, в документы, поддерживающие другие версии данных (например, копирование из Wordб вставка в текстовый редактор), в приложения, не поддерживающие никакую версию данных (что произойдет, если вы скопируете что-то из проводника и вставите в приложение) – надеюсь, вы уловили суть.

Международная доступность

Вы не закончили тестировать, если вы не убедились, что ваше приложение готово к использованию в различных странах. Даже если вы уверены, что оно никогда не будет использоваться за пределами вашей страны, стоит хотя бы одним глазком взглянуть на список ниже. Ваша команда может решить, что найденные в результате проблемы не заслуживают исправления, но вы хотя бы будете знать, где эти проблемы живут. И вы действительно на 100% уверены, что житель верхней Элбонии не захочет пользоваться вашем продуктом?

• Обратите внимание на культурно-специфичные изображения и термины. К примеру, красный цвет – сигнал опасности в ряде западных стран, а в других странах он обозначает счастье или удачу.
• Поисследуйте геополитические тонкости. К примеру, это могут быть карты, демонстрирующие спорные территории. Если ваше приложение отображает карты, готовьтесь к проблемам, как только оно выйдет за пределы вашей страны!
• Убедитесь, что ваше приложение поддерживает переключение системных языков, языковых пакетов, и кодировок – как до запуска, так и после него.
• Убедитесь, что ваше приложение поддерживает изменение региональных настроек, как до запуска, так и после него: форматы времени и даты, символы и форматы валют, порядок сортировки, и т. д. Некоторые (или все) подобные настройки различаются для разных стран и языковых пакетов. Большинство операционных систем позволяют менять эти настройки отдельно от изменения языка или локали. В Windows это можно сделать через панель региональных настроек. К примеру, если ваше приложение работает с валютами, посмотрите, что будет, если вы измените символ валюты на "abc". Я встречал приложение, которому это совсем не понравилось!
• Убедитесь, что ваше приложение корректно работает с мультибайтными (например, японским), сложными (например, арабским) языками, и языками с записью справа налево (например, ивритом). Правильно ли перемещается по тексту курсор? Что произойдет, если смешать текст с написанием слева направо, и со "справа налево"?
• Убедитесь, что все контрольные элементы правильно взаимодействуют с IME. Это особенно важно, если вы планируете продавать ваш продукт в странах восточной Азии.
• Убедитесь, что ваше приложение умеет работать с различными раскладками клавиатуры. Региональные настройки (а также некоторые локали и языковые пакеты) применяют специфические раскладки клавиатур. Раскладку также можно менять и напрямую при необходимости.
• Убедитесь, что ваше приложение корректно работает с текстом ANSI, Unicode, а также мультибайтным текстом и нестандартными символами при вводе, отображении, редактировании и выводе.
• Убедитесь, что используется правильный порядок сортировки. Сортировка – это очень трудно! Спросите любого, кто хоть раз напоролся на распространенный баг с турецкой "i" при сортировке. Если вы опираетесь на правила сортировки операционной системы, то скорее всего, у вас все в порядке, но если в вашем приложении есть специфические виды сортировки – скорее всего, вы найдете баг.
• Убедитесь, что системная, пользовательская и постоянная локаль применяются так, как должны применяться. Используйте пользовательскую локаль, чтобы отображать данные для пользователя, системную – для работы с не-Unicode строками, и постоянную, чтобы форматировать данные для хранения.
• Убедитесь, что функции, зависимые от языка, работают нормально.
• Убедитесь, что ваши тест-кейсы учитывают эти проблемы. По моему опыту, тестировщики делают тут ошибку, аналогичную ошибкам разработчиков – не удивляйтесь, если разработчик укажет на баг в вашем кейсе!

Локализация

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

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

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

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

Помимо всего этого, есть вещи, которые стоит держать в уме, тестируя (надеюсь, что псевдо-) локализованный билд:

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

Прололжение следует....

В следующих частях будут чек листы для:

API

Платформа

Конфигурации процессора

Конфигурации железа

Безопасность

Даты и проблема-2000

Производительность и стресс-тестирование

Конфигурация и совместимость

Установка

Установка: особые случаи

Обновления

Документация

+ будет опубликован pdf файл с полным чек-листом

Обсудить на форуме