В докладе вы узнаете о проблематичных зонах в тестировании клиентской части мобильного приложения на примере команды звездолета Дискавери, которая тестировала свой новый фичер - споровый двигатель.
А также подумаем, что с ними (зонами) делать, чтобы не повторять ошибки команды и получить приложение наивысшего качества.
Давайте вначале разберемся, что подразумевается под словом "план". Мы с Джеймсом Бахом говорим о планировании (и учим планировать в курсе Rapid Software Testing), понимая план как сумму или пересечение стратегии и логистики. Стратегия – это набор идей, направляющих ваш тест-дизайн. Логистика – это набор идей, направляющих распределение ваших ресурсов. Объедините их, и получится план. Тут очень важно отметить, что план – это не физический предмет - это набор идей. Следовательно, важно различать план и документацию по планированию – то есть документы, содержащие какую-то касающуюся плана информацию.
Вопрос, что должно входить в тест-план, можно интерпретировать двояко – во-первых, как вопрос про "план", а во-вторых, как вопрос о документации планирования. Начнем с плана.
8 недель курса мы объясняли сложные термины простым языком, давали домашние задания, отправляли обратную связь и отвечали на вопросы. Мы сказали всё, что было возможно, во время занятий. А теперь пришло время дать слово нашему первому выпуску ПОИНТ (Первый Онлайн ИНститут Тестировщиков).
1 344 часа обучения. Как это было?
«Я прошла курс ПОИНТ на одном дыхании! Грамотно выстроенный процесс помогает плавно влиться в курс. Всё идёт в порядке возрастания и нагрузка не так ощутима. Преподаватели всегда разъясняют, что к чему, постоянно на связи. В самом курсе много информации, но она структурирована; и даже если кажется, что вы это уже знаете, то обязательно почерпнете для себя что-нибудь полезное. Ставлю курсам твёрдую 5! Вы большие молодцы. Однозначно рекомендую, курсы полезные»
Мария Б.
«Эти 2 месяца были очень насыщенными, интересными и, лично для меня, полны открытий. Придя на курс, я уже имела опыт работы в IT, хоть он был и до декрета, и также имела представление о тестировании (книга Савина и некоторые материалы из рассылки Форума тестировщиков). Основной целью было систематизировать и освежить свои знания.
В результате я получила значительно больше! Мне очень понравилось, что вы дали значительный список инструментов, с которыми я не была знакома. Да и навряд ли я освоила бы некоторые из них самостоятельно. Материал в целом подавался очень доходчиво, но порой его не хватало и хотелось больше».
Только 4 декабрявсе технологии по нагрузочному тестированию из первых уст от Перформанс Лаб, Сбербанк Технологии, Райффайзен банка.
Рады сообщить, что 4 декабря в Москве пройдет V юбилейная конференция по нагрузочному тестированию, организованная компанией Перфоманс Лаб, при поддержке известных вендоров и лидеров в данной отрасли. Из маленькой «дружеской» конференции тестировщиков, мероприятие переросло в марафон от ведущих компаний России, которые готовы открыто поделиться своим опытом.
Конференция не такая, как все. И вот почему:
1. Все практики и технологии только по теме Нагрузочное Тестирование. Ничего лишнего!
2. На конференции выступают спикеры известных IT-компаний России, вендоры. Они делятся реальным практическим опытом. Только технические доклады, никакой рекламы.
3. Материал доносится в понятной и доступной форме.
4. По окончании мероприятия каждый участник получит сертификат участника конференции.
5. Профессиональная среда и новые контакты.
Какие новые знания Вы получите на конференции:
1. Узнаете какие подходы будут использоваться для тестирования распределенных сетей в будущем и зачем нужен блокчейн в нагрузочном тестировании.
2. Узнаете какие выбрать инструменты при работе с высоконагруженными проектами, с примерами и тонкостями использования.
3. Как составлять профиль нагрузки в сложных ситуациях, и как поступить если вы встретились с криптографией в проекте по тестированию.
4. Как автоматизировать нагрузочное тестирование, и применить навыки DevOps.
В данной статье я бы хотел рассказать об особенностях мобильного тестирования и переходе от ручного тестирования к автоматизации на примере одного из наших проектов, в котором мы тестировали приложение для фитнес-девайса.
Специфика проекта
Данный проект был международным и распределенным территориально. Все коммуникации, процессы и артефакты были на английском языке. В проекте участвовали команды из Индии, центральной России, Москвы и Эль–Сальвадора, главный офис заказчика – в Калифорнии.
Мы занимались тестированием приложения, написанного для конкретного фитнес-девайса: приложение нельзя было просто скачать из магазина и приступить к работе. Также требовалось уделить особое внимание взаимодействию девайса с телефоном и приложением.
Наше общение с Заказчиком началось с того, что они не смогли самостоятельно пройти предрелизные проверки для добавления своего приложения в AppStore и Google Play. Как следствие, для начала нам потребовалось провести тестирование по гайдлайнам от Apple и Google.
Как это нередко бывает в мобильной разработке, iOS версия опережала на пару спринтов Android и все новые фичи сначала появлялись для IOS.
На старте проекта не было документации, и она появлялась только на новые фичи.
Оглядываясь на свой опыт работы в тестировании, я осознаю, что получила крупные поучительные уроки, и сейчас они кажутся мне очень понятными и очевидными. Однако все эти годы я писала о своей позиции, и могу оценить, насколько мои взгляды менялись со временем. Поначалу я нервничала, если писала о том, что мне казалось верным (хотя это могло быть абсолютно не так), но блог помог мне справиться с волнением и обращать внимание на положительный эффект от него.
Множество фундаментальных перемен я предсказать не могла – они происходили постепенно в течение длительного времени. Ретроспективно они очень существенны, и их легко воспринимать как то, что я знала всегда. О четырех из них я хочу рассказать подробнее – они резко изменили мою систему ценностей и стимулировали поиск новых возможностей.
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)
Баг-хантинг – распространенная практика в мировых тест-организациях. Однако некоторые тест-менеджеры думают, что баг-хантинг – это поиск багов на границах через неформальные эксперименты с приложением.
Что такое баг-хантинг (и чем он не является)?
Баг-хантинг – это неформальные упражнения по тестированию. Не надо путать их с ситуацией, когда вы развлекаетесь с приложением без цели и смысла, а также не смешивайте их с исследовательским тестированием. Вот почему:
Баг-хантинг – это групповая деятельность, а исследовательское тестирование может проводиться единолично.
Цель баг-хантинга – подключить к процессу тех, кто не является тестировщиком, и найти неочевидные баги. Исследовательское тестирование нацелено на "обычные" баги, и им обычно занимаются исключительно тестировщики.
Исследовательским тестированием можно заниматься на любой стадии процесса разработки. Баг-хантинг приносит пользу, если приложение достаточно стабильно.
