Home

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

Начало статьи, продолжение статьи

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

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

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

API

Если ваше приложение устанавливает в систему EXE, DLL, LIB или любые другие файлы (исчерпывающе описывает любые приложения, с которыми я сталкивался), вам нужно протестировать API. А может (по идее), не нужно – если только ваше приложение использует эти DLL, или только один API – если EXE не поддерживает аргументы командной строки. Но, как знает любой тестировщик, "по идее" не всегда коррелирует с "на самом деле".

• Убедитесь, что все публично доступные API на самом деле доступны. Как вариант, проведите ревью кода. Альтернатива – инструменты, которые существуют на любом языке и проверяют именно это. В Microsoft мы использовали .Net Reflector. Для исполняемых файлов начните с вызова приложения через "-<command>', ":<command>", "/<command>", "\<command>" и "<command>"-аргументов командной строки, заменяя "command" на "?" или "help", или название файла. Если одна из вспомогательных команд работает, вы убедитесь, что приложение понимает аргументы командной строки, и узнаете, в каком именно формате оно их понимает.
• Убедитесь, что непубличные API не могут причинить вам вреда, если к ним получен "нелегальный" доступ. То, что API не публичен, не означает, что его нельзя вызвать. Языки управляемого кода обычно позволяют любому желающему получить доступ к непубличным методам и свойствам, а таблицы методов можно взломать. В большинстве случаев, конечно, те, кто так делают, не будут жаловаться, стреляя себе в ногу в результате, но убедитесь, что таким образом невозможно получить доступ к конфиденциальной информации. К примеру, просто скрыть от посторонних глаз ключ шифрования или код, проверяющий лицензию – недостаточная мера.
• Просмотрите все внешние и внутренние API, имеющие отношения к вашему продукту. Имеют ли они смысл? Соответствуют ли их уровни видимости желаемым? Понятно ли из их названия, что они делают и зачем?
• Убедитесь, что все публичные объекты, методы, свойства и процессы протестированы.
• Убедитесь, что все опциональные аргументы корректно работают, когда они определены и не определены.
• Убедитесь, что все возвращаемые значения и исключения верны и имеют ценность.
• Убедитесь, что все объекты, методы, свойства и процессы, ориентированные на многопоточность, действительно таковыми являются.
• Убедитесь, что каждый API можно использовать на всех поддерживаемых языках. К примеру, ActiveX должен управляться (как минимум) через C++, VB, VB.Net, C#.
• Убедитесь, что для всех публичных объектов, методов, свойств и процессов существует документация, и она верна. Удостоверьтесь, что образцы кода в документации компилируются и запускаются.

Платформа

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

• Все поддерживаемые версии Windows, как минимум, Windows XP SP2, Windows XP SP последней версии, Windows Server 2003 SP последней версии, Windows Vista SP последней версии, Windows 7, 8 и 10.
• Apple OS X
• Ваша любимая сборка Linux
• Ваш любимый Unix
• 32-битная версия операционной системы при 32-битном железе.
• 32-битная версия операционной системы при 64-битном железе.
• 64-битная версия операционной системы при 64-битном железе.
• Различные SKU операционной системы.
• Совместимость различных SKU операционной системы.
• Совместимость различных операционных систем (к примеру, открытие файла через Windows-компьютер, если файл расположен в сетевом окружении Linux).
• Все поддерживаемые браузеры и их версии (IE, Opera, Firefox, Chrome).
• Работа с антивирусом и без.
• Работа с файерволом и без.

Просмотрите также требования Windows Logo. Если даже вы не собираетесь им соответствовать, или ваше приложение не предназначено для Windows, это неплохая отправная точка для новых тест-кейсов!

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

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

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

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

• Процессоры от различных производителей (Intel и AMD, если ваше приложение рассчитано на Windows).
• Несколько версий различных брэндов (к примеру, для Intel – мобильные и десктоп-Celeron, и Pentium)
• Однопроцессорные, двухпроцессорные, мультипроцессорные системы
• Одноядерные, двухъядерные, многоядерные процессоры.
• Процессоры с технологией гиперпотока (HyperThread) и без
• Полноформатные компьютеры и ноутбуки.
• 32-битные и 64-битные конфигурации.

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

Вы не закончили тестировать, если не определились с конфигурациями железа, которые нужно включить или изъять из тестовой матрицы:

• Слабый компьютер
• Сильный компьютер
• Слабый ноутбук
• Мощный ноутбук
• Минимально допустимое разрешение экрана (в некоторых случаях это 640/480, но это зависит от ваших пользователей).
• Экстремально высокое разрешение экрана (да-да, воспользуйтесь этой отмазкой, пусть руководство купит этот огромный плоский экран!)
• Другие форм-факторы, относящиеся к делу
• Максимально мощная супер-машина
• Машина с минимальной конфигурацией
• Ноутбук с отключенными настройками управления питанием.
• Ноутбук с настройками управления питанием, выставленными на максимум.
• Ноутбук с настройками управления питанием, максимизирующими работу батареи.
• Конфигурации процессоров.

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

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

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

• Покопайтесь в исходном коде, API и интерфейсе в поиске:
• Проблем переполнения буфера
• Проблем, связанных с атаками типа "Отказ в обслуживании"
• Проблем, связанных с SQL-инъекциями
• Вирусных атак
• Нарушения конфиденциальности пользовательских данных (к примеру, включение данных пользователя в сохраненные файлы).

• Для MS Windows – воспользуйтесь Application Verified, чтобы убедиться, что приложение не создает NULL DACLS, а также для поиска других потенциальных проблем.
• Убедитесь, что уровень безопасности для ссылок и макросов достаточен, и безопасность обеспечивается.
• Убедитесь, что относительные именования файлов (например, "…\...\file") корректно обрабатываются.
• Убедитесь, что временные файлы создаются в нужном месте и имеют правильные настройки прав доступа.
• Убедитесь, что ваше приложение корректно функционирует при использовании с различными ролями и правами пользователей.
• Убедитесь, что приложение правильно функционирует при сценарии частичного доверия.
• Убедитесь, что каждый ввод проверен на граничные значения.
• Убедитесь, что вы защитились от наиболее вероятных атак.

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

Вы не закончили тестировать, если не проверили ваше приложение на отсутствие проблемы-2000. Несмотря на то, что мы давно уже пережили эту дату, проблемы, связанные с ней, продолжают возникать в приложениях. Если вы используете какую-либо форму Unix (к примеру, Apple-компьютер) – то ожидайте проблем в 2038 году, когда откажет 32-битная структура хранения времени. О, и раз уж вы занялись датами, поищите заодно и другие характерные для них дефекты – например, обработку високосного года.

• Убедитесь, что если год вводится двумя цифрами, то даты с 1 января 00 по 31 декабря 29 воспринимаются, как 2000-2029 годы соответственно.
• Убедитесь, что если год вводится двумя цифрами, то даты с 1 января 30 по 31 декабря 99 воспринимаются, как 1930-1999 годы соответственно.
• Убедитесь, что поддерживаются даты как минимум вплоть до 2035 года.Убедитесь, что даты високосных лет обрабатываются верно:
• 29 февраля 1900 года не принимается
• 29 февраля 1996 года принимается
• 29 февраля 2000 года принимается
• 31 декабря 2000 года принимается и идентифицируется как 366 день
• 29 февраля 2001 года принимается

• Проверьте другие интересные даты, включая:
• 31 декабря 1999
• 1 января 2000 года непротиворечиво демонстрируется
• 10 января 2000 года (первая семизначная дата)
• 10 октября 2000 года (первая восьмизначная дата)
• Запрет на ввод 13 месяца для 2000 года.

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

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

У меня нет простых ответов на эти вопросы, но тут можно рассмотреть ряд сценариев и условий:

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

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

Стресс-тестирование

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

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

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

Конфигурация

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

Совместимость

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

Взаимодействия окон

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

Установка

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

• Установка с CD-ROM/DVD-ROM.
• Установка из сетевого размещения.
• Установка с локального диска.
• Установка в сетевом размещении.
• Установка из рекламного инсталлятора, когда иконки и другие точки запуска приложения создаются (то есть оно как бы рекламируется пользователю), но фактическая установка происходит только после первичного запуска приложения. Этот метод также известен как "установка по запросу" или "установка при первом использовании".
• Установка, не требующая вмешательства, названная так из-за отсутствия необходимости подтверждать что-то в системных сообщениях. Довольно сложный тест, так как механизм установки, встроенный в ОС, поддерживает множество опций командной строки, а ваше приложение может поддерживать еще больше. О, счастье комбинаторного тестирования!
• Массовая установка через корпоративный деплой, например, Microsoft Systems Management Server.
• Обновление с предыдущих версий. Это может стать довольно сложной задачей в зависимости от того, сколько версий вашего приложения уже вышло, и для каких из них вы поддерживаете обновления. Если все ваши пользователи всегда обновляются после выхода новой версии, можно считать, что у вас все хорошо. Но если в мире существуют пользователи, не обновлявшиеся в течение пяти-шести версий – и добросим сюда различные сервис-паки и хотфиксы – ваша задача усложняется!
• Деинсталляция. Убедитесь, что удаляются не только файлы приложения и общие файлы, но и значения в регистре и другие конфигурационные изменения. Удостоверьтесь, что компоненты, находившиеся в совместном доступе с другими приложениями не удалены (или удалены, зависит от того, существуют ли еще приложения, нуждающиеся в них). Попробуйте деинсталлировать приложения в разном порядке: установите приложение А, затем приложение В, затем удалите приложение А, а после него – приложение В.
• Повторная инсталляция после деинсталляции новой и предыдущих версий вашего приложения.
• Установка на все поддерживаемые ОС и SKU. Возможно, для Windows придется вспомнить аж про Windows 95 – для Linux определите список поддерживаемых дистрибутивов.
• Минимальная, обычная, полная и особая установка. Убедитесь, что каждый тип установки устанавливает нужные файлы, обеспечивает требуемую функциональность, и правильно устанавливает значения регистра и конфигурации. Попробуйте проапгрейдить или даунгрейдить тип установки – от минимума к полной, например, или удалить какую-нибудь функцию. Убедитесь, что добавлены или удалены верные файлы, и соответствующая функциональность появляется или исчезает.
• Установите компоненты локально, с запуском из сети, с установкой при первом использовании, и недоступные. В зависимости от способа создания установщика, установка может позволять отдельным компонентам устанавливаться локально, или запускаться из сети, или устанавливаться по запросу, или не устанавливаться вообще. Убедитесь, что каждый компонент поддерживает соответствующий тип установки – ядро вашего приложения вряд ли должно поддерживать вариант "Не устанавливать".
• Проверьте компоненты, устанавливающиеся при первом запуске. Убедитесь, что они устанавливаются тогда, когда должны (а не раньше), и что они устанавливаются в правильном месте (что произойдет, если папка назначения удалена?) и правильно регистрируются.
• Проверьте компоненты, запускающиеся из сети. Убедитесь, что приложение вообще стартует – некоторые приложения при таком раскладе даже не запустятся, особенно если сетевое расположение дает права только на чтение. Что произойдет, если сеть недоступна, когда вы пытаетесь запустить приложение? Что произойдет при обрыве сети, когда приложение уже запущено?
• Убедитесь, что установка в папки глубокой вложенности работает правильно.
• Убедитесь, что проверки, которые проводит установщик (например, достаточность места на диске) работают нормально.
• Убедитесь, что ошибки, которые должен выдавать установщик (например, при нехватке места на диске) появляются в нужный момент.
• Убедитесь, что "обычные" пользователи и пользователи с ограниченным доступом (то есть не являющиеся администраторами), могут запустить приложение, если оно было установлено при помощи администраторских прав. В этом случае особенно вероятны проблемы при сценарии "Установка по запросу".
• Убедитесь, что приложение корректно работает при удаленном (например, через Microsoft Remote Desktop/Terminal Server) и виртуальном (Microsoft Virtual PC/Virtual Server) доступе. Графические приложения обычно плохо справляются с такими ситуациями. Я видел случаи, когда приложения просто отказывались загружаться, если их запускали через Terminal Server.
• Выполните "обычную" установку, а затем попробуйте ее изменить, добавив дополнительные функции.
• Выполните "специальную" установку, а затем попробуйте ее изменить, убрав функции.
• Выполните "обычную" установку, удалите один-два установленных файла, затем попробуйте починить приложение.
• Выполните "специальную" установку, включающую нетипичные функции, удалите один или несколько установленных файлов, затем попробуйте починить приложение.
• Пропатчите предыдущие версии. Накат патчей отличается от обновления – обновление обычно заменяет все установленные файлы, а патч перезаписывает только некоторые из них.
• Выполните небольшое обновление версии, которая до этого была пропатчена.
• Примените патч к уже обновленной версии.
• Обновите приложение, которое модифицировалось после установки.
• Пропатчите приложение, которое модифицировалось после установки.

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

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

Локальное кэширование

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

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

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

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

Установка для нескольких пользователей

Что будет, если множество пользователей начнут копаться в конфигурации установки вашего приложения?

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

Сетевая установка

Можете ли вы установить свое приложение из сети, а не из локального расположения?

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

Обновления

Вы не закончили тестировать, если вы не разобрались, как ваше приложение чувствует себя при установке поверх предыдущих версий, а также при обновлении операционной системы. Может, стоит также протестировать установку предыдущей версии поверх более новой, или одновременно с новой. Подумайте, нужно ли вам проверять все три комбинации: обновление только вашего приложения, обновление только операционной системы, обновление ОС и приложения одновременно.

Обновление приложения

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

Обновление операционной системы

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

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

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

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

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

Скачать весь чек-лист в pdf-формате

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