Тестирование - очень важный этап разработки мобильных приложений. Можно провести аналогию между созданием мобильного приложения и строительством дома. Всем предельно ясно, что ни один объект не введут в эксплуатацию без проверки инженера, в случае с приложением “инженером” выступает тестировщик. IW Group объяснит почему тестирование играет такую важную роль и расскажет какие подходы использует в своей практике.
Согласитесь, что исправить ошибку, до того как она будет у миллиона пользователей куда проще, чем обрабатывать тот же миллион негативных отзывов. Да и даже когда ошибка будет исправлена, пройдут дни или даже недели перед тем, как пользователь обновит приложение и оно будет работать корректно. А как раз за это время он не только напишет гневный отзыв в Google Play или Appstore, но и обязательно поставит самую низкую оценку, что однозначно повлияет на рейтинг приложения и опустит его в самый низ списка, и как результат - новые пользователи даже при большом желании никаким образом не смогут о нем узнать. Да и вы наверняка слышали выражение: “Удовлетворенные потребители мало рассказывают о своем положительном опыте, а один неудовлетворенный потребитель рассказывает о своем отрицательном опыте в среднем 11-ти знакомым…”, - исходя из этого, стоит понимать, что при выявлении пользователями серьезного бага надеяться на рекомендацию по сарафанному радио не стоит.
Именно поэтому нельзя недооценивать важность тестирования. Тестирование - это прежде всего процесс проверки текущего приложения на соответствие требованиям, которые к нему выдвигаются. К его основным задачам можно отнести:
- уточнение спорных моментов;
- проверка продукта на соответствие заявленным требованиям;
- выявление ошибок для их оперативного устранения;
- получения информации для принятия дальнейших решений.
Разберем немного подробнее. Возможно, это будет неочевидно, но процесс тестирования начинается не на момент завершения реализации продукта, а тогда когда поступает документация от заказчика. Когда к нам приходит документ, в котором формализованы какие-либо требования, он передается в отдел разработки и соответственно в отдел тестирования. Первые оценивают что им необходимо сделать, чтобы реализовать заявленные функции, а вторые оценивают сколько времени уйдет на само тестирование и, соответственно, как это необходимо будет протестировать. Возможно, понадобятся какие-либо дополнительные программы или необходимо будет определенное количество пользователей; возможно, придется сгенерировать специфические тестовые данные для проверки отдельного блока, - все это нужно понять до момента тестирования, чтобы приступить к нему уже подготовленными. В связи с этим, можно сказать, что на первом этапе мы готовимся к тестированию, для того чтобы когда поступил готовый продукт от разработчиков, качественно его проверить на соответствие всем заявленным требованиям.
Также на первоначальном этапе важно понимать, что существует такое понятие как “области умолчания”. К примеру, когда заказчик объясняет какие-либо детали по предстоящему проекту он может упустить важный блок информации, потому что считает его само собой разумеющимся и понятным, но, к сожалению, для нас это не настолько очевидно. Именно поэтому после составления ТЗ или предоставления иных документов, включающих в себя информацию о разработке, важно этот файл “протестировать”. Иначе может произойти ситуация, когда мы сделаем “вроде, как то что надо, но не так”. Поэтому столь важно провести проверку и зафиксировать все требования до начала разработки во избежание недопонимания.
К сожалению, природа человека такова, что все мы совершаем ошибки, конечно, есть какой-то процент гениев, которых обходит стороной такая проблема, но все-таки будем честны, что это абсолютно нормальный процесс и в этом нет ничего критичного. Даже самые классные разработчики в таких компаний как Google или Microsoft ошибаются, об этом мы с вами часто читаем в сводках новостей, поэтому не стоит спускать всех собак на создателей приложения, тут как раз и приходит на помощь тестировщик. Он осуществляет проверку продукта на соответствие заявленным требования и сравнивает фактический результат с ожидаемым.
Если с первыми тремя пунктами все в принципе понятно, то зачем информация для принятия дальнейшего решения может быть неясно. Можно ведь сначала дать разработчикам задачу, они что-то сделают, а тестировщики уже потом будут проверять, зачем все усложнять? “Вот смотрите, должно быть вот так, сделать нужно вот так, а потом уже сравнивайте и проверяйте”, - мнение типичного заказчика. Это плохой подход, IW не одобряет. На стадии прочтения требований можно найти “узкие места”, особенно когда продукт развивается и развитие рассчитано на долгосрочную перспективу. Возникают спорные моменты, когда новый функционал или идет вразрез со старым или в принципе после его внедрения перестанет работать то, что было заложено изначально в самой первой версии приложения. Поэтому важно сначала тестировать документацию, а уже потом сам продукт.
Каким образом мы оформляем дефект или в просторечии бага?
В нашей компании существует стандартный шаблон, которым пользуются все тестировщики, он состоит из следующих элементов:
- название - очень кратко дается описание о чем конкретно эта ошибка.
- описание - более подробно отображается в чем проблема, описываются шаги, которые нужно предпринять, чтобы воспроизвести эту багу, в том числе отображается ожидаемый результат, то есть то, что должно быть, если следовать по описанному выше пути и что получается по факту на данный момент.
- Также прилагается скриншот или ряд скриншотов. В ситуации, когда скриншот по каким-то причинам является неинформативным - записывается видео. Если проблема существует на бэкенде, то прикрепляются логи сервера, это файлы, который хранятся на сервере и содержат всю информацию о нем.
Вот так профессиональная команда тестировщиков компании IW Group подстраивается под любой запрос заказчика в контроле качества.
