Home

Автор: Евгений Иванченко

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

Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.

Интро

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

• Недоделки. Это ошибки, которые допустили разработчики, пока пилили новый функционал. Такие ошибки находят при исследовательском или приемочном тестировании новых фич на девелоперских стендах команд.
• Баги в регрессе. Это дефекты, которые находят ручные регрессионные тесты или автоматические UI и API тесты на стенде для интеграции кода. 
• Баги с прода. Это проблемы, которые нашли сотрудники или клиенты и обратились в службу технической поддержки.

Автор: Дейв Вестервельд (Dave Westerveld)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование безопасности на мобильных устройствах – сложная задача для тестировщика. В нем объединяются проблемы мобильных устройств и сложности тестирования безопасности. Вот, к примеру, ряд сложностей, о которых я узнала, исследуя вопрос:

• Мобильные устройства изначально более безопасны по сравнению с традиционными веб-приложениями, потому что это личная вещь пользователя. Из-за этого куда сложнее "заглянуть под капот", чтобы увидеть, как работает приложение.
• Из-за вышеописанной сложности тестирование мобильной безопасности зачастую требует инструментов, которых у среднестатистического тестировщика может и не быть под рукой – к примеру, XCode Tools или Android Studio. Тестирование безопасности на физическом устройстве может также требовать рутованного или джейл-брейк телефона (это телефон, измененный таким образом, что пользователь получает администраторские права или устраняет пользовательские ограничения. Рут-права можно получить на Android, а джейл-брейк провести для iPhone. Нет, не делайте этого со своим личным устройством).
• Сложно найти информацию по тестированию мобильной безопасности, если вы начинающий – большая часть документации предполагает, что вы уже достаточно хорошо ориентируетесь в продвинутых концепциях тестирования безопасности или разработке мобильных приложений.

Меня зовут Виталий Котов, я довольно много занимаюсь автоматизацией тестирования и мне это нравится. Недавно я участвовал в проекте по настройке автоматизации «с нуля» на стеке TypeScript + Protractor + Jasmine. Для меня этот стек был новым и необходимую информацию я искал на просторах интернета.

Самые полезные и толковые мануалы мне удалось найти только на английском языке. Я решил, что на русском тоже надо такой сделать. Расскажу только основы: почему именно такой стек, что надо настроить и как выглядит самый простой тест.

Сразу оговорюсь, что довольно редко работаю с NodeJS, npm и в целом с серверным JavaScript (тем более с TypeScript). Если где-то найдете ошибку в терминологии или какое-то из моих решений можно улучшить — буду рад узнать об этом в комментариях от более опытных ребят.

Опубликован очередной выпуск рассылки за первую половину июля.

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

Содержание рассылки доступно по ссылке.

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

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Это последняя часть моего цикла статей о ретроспективных уроках автоматизации. Мне кажется, я достаточно выразил свою философию тестирования и личный опыт. Последнее, чем я хочу поделиться, относится к проекту, с которым я работаю уже год, и касается создания автоматизированных проверок API бэкэнда, который мы сейчас разрабатываем. Мы пишем тесты на PHP во фреймворке Codeception. Я не буду углубляться в особенности фреймворка – я сфокусируюсь на базовых вещах. Итак, вот они – уроки по тестированию API, которые мне нелишним было бы знать заранее – до того, как я изрядно налажал.

Опыт подготовки и проведения тестирования производительности показывает, что неправильно построенный процесс может привести к неточным результатам и трудностям в поиске решения для улучшения производительности ПО.

В данной статье мы вместе с перфоманс-командой a1qa пройдем все обязательные этапы такой проверки и рассмотрим их особенности, опираясь на реальные кейсы.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Тут в игру вступает автоматизированное тестирование мобильных приложений. К счастью, в наши дни целое море продуктов и сервисов способны помочь автоматизировать наши мобильные тесты. Сегодня я расскажу о пяти из них, но сначала давайте рассмотрим семь советов, которые помогут вам преуспеть в автоматизации мобильного тестирования.
Зайдите в любой салон связи, и вы увидите широкую линейку телефонов. Конечно, все стремятся убедиться, что ваше приложение хорошо работает на всех и каждом из них – а также на старых моделях, которыми до сих пор пользуется ваша аудитория. Однако прогон даже самого простенького набора ручных тестов на телефоне или планшете занимает время. Умножьте это время на количество предположительно поддерживаемых устройств, и у вас появится невпроворот работы!