Оглядываясь на свой опыт работы в тестировании, я осознаю, что получила крупные поучительные уроки, и сейчас они кажутся мне очень понятными и очевидными. Однако все эти годы я писала о своей позиции, и могу оценить, насколько мои взгляды менялись со временем. Поначалу я нервничала, если писала о том, что мне казалось верным (хотя это могло быть абсолютно не так), но блог помог мне справиться с волнением и обращать внимание на положительный эффект от него.
Множество фундаментальных перемен я предсказать не могла – они происходили постепенно в течение длительного времени. Ретроспективно они очень существенны, и их легко воспринимать как то, что я знала всегда. О четырех из них я хочу рассказать подробнее – они резко изменили мою систему ценностей и стимулировали поиск новых возможностей.
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)
Баг-хантинг – распространенная практика в мировых тест-организациях. Однако некоторые тест-менеджеры думают, что баг-хантинг – это поиск багов на границах через неформальные эксперименты с приложением.
Что такое баг-хантинг (и чем он не является)?
Баг-хантинг – это неформальные упражнения по тестированию. Не надо путать их с ситуацией, когда вы развлекаетесь с приложением без цели и смысла, а также не смешивайте их с исследовательским тестированием. Вот почему:
Баг-хантинг – это групповая деятельность, а исследовательское тестирование может проводиться единолично.
Цель баг-хантинга – подключить к процессу тех, кто не является тестировщиком, и найти неочевидные баги. Исследовательское тестирование нацелено на "обычные" баги, и им обычно занимаются исключительно тестировщики.
Исследовательским тестированием можно заниматься на любой стадии процесса разработки. Баг-хантинг приносит пользу, если приложение достаточно стабильно.
Вопрос от тестировщиков: "Зачастую мне дают продукт на тестирование, но не выделяют достаточно времени. Как мне одобрить релиз, если я недостаточно протестировал?"
Вот мой ответ.
Если вы тестировщик, то мне странно слышать, что вы отвечаете за одобрение релиза. Решение, выходить ли в релиз – это бизнес-решение, а совсем не техническое. Оно, безусловно, базируется на технических соображениях, и вполне естественно предоставить отчет об этих соображениях. С точки зрения бизнеса было бы глупо игнорировать этот отчет. Однако не менее глупая ситуация возникнет, если бизнес спихнет бизнес-решение на технический персонал. Мы служим бизнесу, а не управляем им, и технари зачастую не имеют доступа к бизнес-информации.
Идея, что тестировщики могут разрешить или запретить релиз, легко проверяется. Попробуйте отказаться от релиза, пока не будете достаточно довольны тем, что вы знаете о продукте и тем, сколько именно вы знаете. Вы быстро получите результат.
Поговорим про интернет вещей. Согласно Gartner, в мире уже уже используется более 7 миллиардов IoT-устройств, а к 2020 году превысит 20 миллиардов. Как тестировать эти устройства, такие как холодильники, самостоятельно заказывающие продукты через интернет, или самоуправляемые автомобилями — вот вопрос, который будут задавать себе их производители ближайшие несколько лет.
В Перфоманс Лаб этим вопросом тоже задались и провели тестирование простого IoT устройства на платформе Renesas. Получилось очень интересно, решили снять небольшое видео, на котором Дмитрий Химион, подробно рассказывает о нашей технологии и показывает крутые мигающие лампочки.
Надеемся, что этот материал поможет многим командам, найти свой подход к тестированию умных устройств.
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно здесь и здесь).
Тестировщик всегда работает в условиях недостатка времени: беклог не уменьшается, релиз на носу, а протестировать нужно еще многое. Чтобы обеспечить качество продукта, нужно постоянно повышать эффективность собственной работы. Один из способов - освоить некоторые инструменты, облегчающие рутинные действия в тестировании.
