Что тестировать

Перевод статьи Хэмиша Макнейла в блоге компании Realmac Software

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

Прежде чем продолжить чтение, важно помнить, что роль QA состоит не в том, чтобы ломать приложения, а в том, чтобы обеспечить достижение должного уровня качества. У нас в Realmac Software уровень качества определяет одна простая цель: проектировать и разрабатывать лучшие приложения в мире.

Мы очень любим копаться в самых мельчайших деталях. Команда QA в этом смысле ничем не отличается от других. Я, например, люблю заводить отдельные задачи даже на самые незначительные опечатки, глюки производительности и подобные мелкие неприятности. При этом во время тестирования приложения нам необходимо сохранять целостность продукта и держать полную картину в голове. Если сосредоточиться на попытках сломать приложение, можно легко потерять виденье общего образа, чувства и цели, ради которых мы работаем. Поэтому я хочу поговорить о необходимости быть реалистом и знать, что именно нужно тестировать и на что обращать внимание при выпуске каждого обновления.

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

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

Данные

1. Перенос данных между локальным хранилищем и iCloud.
2. Онлайн/оффлайн-обработка конфликтов объединения изображений, связанных метаданных и заметок.
3. Тестирование состояния сети, прав доступа к «Документам и данным» iCloud и обработка ошибок.
4. Обновление с предыдущей версии.

UX

1. Обновление сценария первого запуска.
2. Новые пункты в меню, горячие клавиши и сервисы шаринга.

UI

1. Изображения для (не)HiDPI-моделей дисплеев.
2. Локализация для всех новых или обновленных функций, уведомлений и ошибок.

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

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

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

QA — это командная работа. Тесная работа с нашими разработчиками, в частности, — источник ценных знаний о слабых местах в приложении. Общение с разработчиками может очень помочь понять, где можно ожидать регрессию. Уверенность разработчика в добавленном исправлении может подсказать, сколько дополнительного времени должна занимать проверка работоспособности кода без возвращения к старым проблемам.

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

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

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

Оригинал статьи в блоге компании Realmac Software: http://realmacsoftware.com/blog/what-to-test