Начинать с конца
А давайте я вам про качество в мобильной разработке расскажу?
Итак, качество - это соответствие ожиданиям.
Заказчик ожидает, что продукт будет в рабочем состоянии и успешно решит проблемы пользователя (на самом деле проблемы заказчика, но кто ж признается?).
Пользователь ожидает, что продуктом будет удобно пользоваться, легко устанавливать, и что он не упадет в самый неподходящий момент, похоронив всю проделанную работу.
Команда разработки ожидает, что поставленные ей задачи – требования, user story, макеты и прототипы – будут понятными, и их можно успешно реализовать, а тестировщик ожидает, что все вышеперечисленное будет поддаваться тестированию.
Все чего-то ждут.
Ожидания всех значимых лиц могут принимать разные формы – это и здравый смысл, и формализованные требования, и предыдущий опыт (хотите увидеть сконфуженного пользователя – поставьте кнопку "ОК" справа, а "Отмену" слева). Часть ожиданий можно описать в форме сценариев – тест-кейсов. Тест-кейсы пошагово описывают основные пользовательские сценарии, причем настолько подробно, чтобы не вызвать никаких вопросов у проходящего по этим шагам человека. Они также четко фиксируют ожидаемый от этих действий результат, который должна выдать система.
Занимается составлением кейсов тестировщик, и он должен приступать к ним сразу же после того, как у него на руках есть хоть что-то, относящееся к продукту. Их можно составлять даже по дизайн-макетам! А уж если в наличии есть хорошие подробные требования, то к кейсам уж точно можно смело приступать.
Внимание: приступать к тестированию нужно до того, как написана хоть одна строчка кода.
Важно как можно раньше передать тестированию требования к приложению. Во-первых, тестировщик сразу приступает к анализу продукта – еще не написана ни одна строчка кода, а тестировщик уже составил себе ментальную карту приложения, выявил его основные функциональные блоки, и начал составлять план тестирования и поддерживающие его кейсы и чек-листы. К моменту, когда разработке будет что показать, тестированию не придется тратить дополнительное время на составление сценариев.
Во-вторых, составленные заранее сценарии могут вызывать у тестирования вопросы по работе приложения. Если прояснить их заранее, привлекая заказчика или аналитика, это, опять же, сократит расходы на тестирование, когда приложение уже попадет тестировщику в руки.
В-третьих, даже если у тестировщика не возникает вопросов, всегда полезно заранее показать заказчику планируемое тестирование. Заказчик лучше знает, какого конкретно поведения он хочет от приложения, и не все можно описать в требованиях, поэтому отлично, когда у него есть возможность пробежаться по сценариям тестирования и пополнить их при необходимости.
На самом деле - это хороший повод для самого заказчика узнать что он собственно рискует получить в результате. В этот момент иногда происходят чудеса.
И, наконец, если планируется хотя бы частичная автоматизация тестирования, заранее составленные кейсы можно передавать как задачи на автоматизацию. А автоматизаторы смогут заранее уточнить у разработки специфику кода, чтобы знать, к чему подцепить свои тесты.
Еще один инструмент тестировщика – это чек-листы. Чеклист, в отличие от кейса, не содержит лишних подробностей про конкретные шаги и не описывает сценарии. Чеклист – это краткий список проверок, которые нет смысла описывать в тест-кейсах. Например, это могут быть списки имен, которые обязательно нужно проверить в форме регистрации (вот ужас будет, если не принимаются двойные или очень короткие имена), разные варианты написания почты, поисковые запросы. Иногда в чеклисты вносят также базовое тестирование безопасности, заранее придумывая XSS и SQL-инъекции, чтобы убедиться, что приложение обрабатывает их правильно и не выдаст злоумышленнику ключи от квартиры, где деньги лежат.
И, наконец, тестировщики пользуются ментальными картами (mind maps). Ментальная карта может использоваться для анализа продукта (какую задачу он решает? Что в нем сможет делать пользователь), и служить базой для более подробного сценарного тестирования по кейсам/чеклистам. А еще ее можно использовать и как основной инструмент тестирования – это делается в исследовательском тестировании, когда время на тестирование сильно ограничено, и на кейсы с чеклистами нет времени.
И кейсы, и чеклисты, и карты дают возможность предоставить заказчику подробную отчетность. По результатам прогона этой документации можно легко увидеть, что проверялось, что нет, и какие результаты были получены тестировщиком. Специальные инструменты для чеклистов (Sitechco) и кейсов (TestLink, TestRail) позволяют вести статистику прогонов, учет багов, и даже интегрироваться с баг-трекерами, чтобы отслеживать статус задач, созданных в результате тестирования.
Однако для создания таких списков и сценариев проверок специальные инструменты в общем-то не требуются. При отсутствии инструментов или доступа к ним тест-документацию можно вести в любом текстовом редакторе (Word, Excel), ведь главное – результат! А списки проверок для API и вовсе ведутся в специальных инструментах работы с API (Postman, SoapUI, Fiddler) – там их можно сразу запустить и посмотреть, как они отрабатывают.
Итак, если хотите получить качественное приложение:
Итак, качество - это соответствие ожиданиям.
Заказчик ожидает, что продукт будет в рабочем состоянии и успешно решит проблемы пользователя (на самом деле проблемы заказчика, но кто ж признается?).
Пользователь ожидает, что продуктом будет удобно пользоваться, легко устанавливать, и что он не упадет в самый неподходящий момент, похоронив всю проделанную работу.
Команда разработки ожидает, что поставленные ей задачи – требования, user story, макеты и прототипы – будут понятными, и их можно успешно реализовать, а тестировщик ожидает, что все вышеперечисленное будет поддаваться тестированию.
Все чего-то ждут.
Ожидания всех значимых лиц могут принимать разные формы – это и здравый смысл, и формализованные требования, и предыдущий опыт (хотите увидеть сконфуженного пользователя – поставьте кнопку "ОК" справа, а "Отмену" слева). Часть ожиданий можно описать в форме сценариев – тест-кейсов. Тест-кейсы пошагово описывают основные пользовательские сценарии, причем настолько подробно, чтобы не вызвать никаких вопросов у проходящего по этим шагам человека. Они также четко фиксируют ожидаемый от этих действий результат, который должна выдать система.
Занимается составлением кейсов тестировщик, и он должен приступать к ним сразу же после того, как у него на руках есть хоть что-то, относящееся к продукту. Их можно составлять даже по дизайн-макетам! А уж если в наличии есть хорошие подробные требования, то к кейсам уж точно можно смело приступать.
Внимание: приступать к тестированию нужно до того, как написана хоть одна строчка кода.
Важно как можно раньше передать тестированию требования к приложению. Во-первых, тестировщик сразу приступает к анализу продукта – еще не написана ни одна строчка кода, а тестировщик уже составил себе ментальную карту приложения, выявил его основные функциональные блоки, и начал составлять план тестирования и поддерживающие его кейсы и чек-листы. К моменту, когда разработке будет что показать, тестированию не придется тратить дополнительное время на составление сценариев.
Во-вторых, составленные заранее сценарии могут вызывать у тестирования вопросы по работе приложения. Если прояснить их заранее, привлекая заказчика или аналитика, это, опять же, сократит расходы на тестирование, когда приложение уже попадет тестировщику в руки.
В-третьих, даже если у тестировщика не возникает вопросов, всегда полезно заранее показать заказчику планируемое тестирование. Заказчик лучше знает, какого конкретно поведения он хочет от приложения, и не все можно описать в требованиях, поэтому отлично, когда у него есть возможность пробежаться по сценариям тестирования и пополнить их при необходимости.
На самом деле - это хороший повод для самого заказчика узнать что он собственно рискует получить в результате. В этот момент иногда происходят чудеса.
И, наконец, если планируется хотя бы частичная автоматизация тестирования, заранее составленные кейсы можно передавать как задачи на автоматизацию. А автоматизаторы смогут заранее уточнить у разработки специфику кода, чтобы знать, к чему подцепить свои тесты.
Еще один инструмент тестировщика – это чек-листы. Чеклист, в отличие от кейса, не содержит лишних подробностей про конкретные шаги и не описывает сценарии. Чеклист – это краткий список проверок, которые нет смысла описывать в тест-кейсах. Например, это могут быть списки имен, которые обязательно нужно проверить в форме регистрации (вот ужас будет, если не принимаются двойные или очень короткие имена), разные варианты написания почты, поисковые запросы. Иногда в чеклисты вносят также базовое тестирование безопасности, заранее придумывая XSS и SQL-инъекции, чтобы убедиться, что приложение обрабатывает их правильно и не выдаст злоумышленнику ключи от квартиры, где деньги лежат.
И, наконец, тестировщики пользуются ментальными картами (mind maps). Ментальная карта может использоваться для анализа продукта (какую задачу он решает? Что в нем сможет делать пользователь), и служить базой для более подробного сценарного тестирования по кейсам/чеклистам. А еще ее можно использовать и как основной инструмент тестирования – это делается в исследовательском тестировании, когда время на тестирование сильно ограничено, и на кейсы с чеклистами нет времени.
И кейсы, и чеклисты, и карты дают возможность предоставить заказчику подробную отчетность. По результатам прогона этой документации можно легко увидеть, что проверялось, что нет, и какие результаты были получены тестировщиком. Специальные инструменты для чеклистов (Sitechco) и кейсов (TestLink, TestRail) позволяют вести статистику прогонов, учет багов, и даже интегрироваться с баг-трекерами, чтобы отслеживать статус задач, созданных в результате тестирования.
Однако для создания таких списков и сценариев проверок специальные инструменты в общем-то не требуются. При отсутствии инструментов или доступа к ним тест-документацию можно вести в любом текстовом редакторе (Word, Excel), ведь главное – результат! А списки проверок для API и вовсе ведутся в специальных инструментах работы с API (Postman, SoapUI, Fiddler) – там их можно сразу запустить и посмотреть, как они отрабатывают.
Итак, если хотите получить качественное приложение:
- Возьмите тестировщика.
- Начинайте тестирование как только согласовали ТЗ;
- Продолжайте тестирование во время разработки - по мере добавления функций;
- Не забудьте все еще раз проверить перед релизом.
23 октября / 2018