Автор: Даниил Майстренко, Perfomance Lab

Оригинальная публикация

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

Специфика проекта

• Данный проект был международным и распределенным территориально. Все коммуникации, процессы и артефакты были на английском языке. В проекте участвовали команды из Индии, центральной России, Москвы и Эль–Сальвадора, главный офис заказчика – в Калифорнии.
• Мы занимались тестированием приложения, написанного для конкретного фитнес-девайса: приложение нельзя было просто скачать из магазина и приступить к работе. Также требовалось уделить особое внимание взаимодействию девайса с телефоном и приложением.
• Наше общение с Заказчиком началось с того, что они не смогли самостоятельно пройти предрелизные проверки для добавления своего приложения в AppStore и Google Play. Как следствие, для начала нам потребовалось провести тестирование по гайдлайнам от Apple и Google.
• Как это нередко бывает в мобильной разработке, iOS версия опережала на пару спринтов Android и все новые фичи сначала появлялись для IOS.
• На старте проекта не было документации, и она появлялась только на новые фичи.

Автор: Маарет Пиаярви (Maaret Pyhäjärvi)

Оригинал статьи

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

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

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

Вышел выпуск рассылки за вторую половину октября, его содержание доступно по ссылке. 

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Подписаться на рассылку можно по ссылке.

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

Автор: Святослав Логин

Оригинальная публикация

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

SQLmap — это инструмент с открытым исходным кодом для тестирования на проникновение, который автоматизирует процесс выявления и эксплуатирования уязвимостей SQL-инъекций и захват серверов баз данных.

Автор: Андрей Петров

Оригинальная публикация

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

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

За последние пять лет, по данным Google Trends,  значительно вырос интерес к тестированию API. Такая тенденция отражает сдвиг парадигмы в сторону web и мобильных приложений, а также разделение серверных служб и пользовательских интерфейсов.

Тестирование API - это тестирование, которое включает в себя проверку и валидацию API и веб-служб. В отличие от традиционного тестирования, в котором основное внимание уделяется функциональности графического интерфейса и взаимодействию с конечным пользователем, тестирование API проверяет программные интерфейсы, находящиеся на среднем уровне приложения, которые используются разработчиками (например, headless или GUI-less компоненты, обычно невидимые для конечных пользователей).

В обычном web или мобильном приложении, Web-API могут объединять между собой различные компоненты, такими компонентами могут быть особенные представления или пользовательский интерфейса c веб-сервером. Тем самым, автоматизация тестирования API становится все более привлекательным выбором в современном тестировании программного обеспечения. (Подробнее о тестировании API)

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

Чтобы помочь вам разобраться, какие же все-таки инструменты лучше всего подходят для автоматизации тестирования API, в этой статье для вас будет представлены обзор и сравнение трех популярных инструментов для тестирования API: SoapUI, Postman и Katalon Studio. SoapUI и Postman специализируются исключительно на тестировании API, в то время как, Katalon Studio предоставляет полный набор инструментов для тестирования API, Web и мобильных приложений. (Подробнее о 5 лучших и бесплатных инструментах для тестирования API)

Автор: Джоэл Монтвелиски (Joel Montvelisky)

Оригинал статьи

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

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

Что такое баг-хантинг (и чем он не является)?

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

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

Автор: Майкл Болтон (Michael Bolton).

Оригинал статьи

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

Вопрос от тестировщиков: "Зачастую мне дают продукт на тестирование, но не выделяют достаточно времени. Как мне одобрить релиз, если я недостаточно протестировал?"

Вот мой ответ.

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

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