Начинать с конца

Заказать приложение
Close
Close
Свяжитесь с нами
Telegram
Whatsapp
Messenger
Mail
А давайте я вам про качество в мобильной разработке расскажу?

Итак, качество - это соответствие ожиданиям.

Заказчик ожидает, что продукт будет в рабочем состоянии и успешно решит проблемы пользователя (на самом деле проблемы заказчика, но кто ж признается?).

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

Команда разработки ожидает, что поставленные ей задачи – требования, user story, макеты и прототипы – будут понятными, и их можно успешно реализовать, а тестировщик ожидает, что все вышеперечисленное будет поддаваться тестированию.


Все чего-то ждут.


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

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


Внимание: приступать к тестированию нужно до того, как написана хоть одна строчка кода.


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

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

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

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




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

Еще один инструмент тестировщика – это чек-листы. Чеклист, в отличие от кейса, не содержит лишних подробностей про конкретные шаги и не описывает сценарии. Чеклист – это краткий список проверок, которые нет смысла описывать в тест-кейсах. Например, это могут быть списки имен, которые обязательно нужно проверить в форме регистрации (вот ужас будет, если не принимаются двойные или очень короткие имена), разные варианты написания почты, поисковые запросы. Иногда в чеклисты вносят также базовое тестирование безопасности, заранее придумывая XSS и SQL-инъекции, чтобы убедиться, что приложение обрабатывает их правильно и не выдаст злоумышленнику ключи от квартиры, где деньги лежат.

И, наконец, тестировщики пользуются ментальными картами (mind maps). Ментальная карта может использоваться для анализа продукта (какую задачу он решает? Что в нем сможет делать пользователь), и служить базой для более подробного сценарного тестирования по кейсам/чеклистам. А еще ее можно использовать и как основной инструмент тестирования – это делается в исследовательском тестировании, когда время на тестирование сильно ограничено, и на кейсы с чеклистами нет времени.

И кейсы, и чеклисты, и карты дают возможность предоставить заказчику подробную отчетность. По результатам прогона этой документации можно легко увидеть, что проверялось, что нет, и какие результаты были получены тестировщиком. Специальные инструменты для чеклистов (Sitechco) и кейсов (TestLink, TestRail) позволяют вести статистику прогонов, учет багов, и даже интегрироваться с баг-трекерами, чтобы отслеживать статус задач, созданных в результате тестирования.

Однако для создания таких списков и сценариев проверок специальные инструменты в общем-то не требуются. При отсутствии инструментов или доступа к ним тест-документацию можно вести в любом текстовом редакторе (Word, Excel), ведь главное – результат! А списки проверок для API и вовсе ведутся в специальных инструментах работы с API (Postman, SoapUI, Fiddler) – там их можно сразу запустить и посмотреть, как они отрабатывают.


Итак, если хотите получить качественное приложение:

  1. Возьмите тестировщика.

  2. Начинайте тестирование как только согласовали ТЗ;

  3. Продолжайте тестирование во время разработки - по мере добавления функций;

  4. Не забудьте все еще раз проверить перед релизом.

23 октября / 2018

Made on
Tilda