Привет! Меня зовут Арсений Батыров, я работаю в Яндексе, а также веду курсы по тестированию. В работе мне часто приходится выбирать девайсы для проведения тестирования в различных условиях. Помимо очевидных параметров вроде dpi и ОС я часто опираюсь на статистику распространенности устройств, чтобы точно покрыть все наиболее популярные комбинации. В этой статье перечислены сервисы с различной статистикой, которыми я пользуюсь при подборе устройств. Если для вас эта проблема актуальна — добро пожаловать под кат.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Тестирование производительности, как и ряд другой терминологии тестирования ПО, может интерпретироваться по-разному разными людьми. Некоторые объединяют под этим термином все типы тестов, замеряющих поведение приложения, и включают в него нагрузку и стресс-тестирование. Прочие используют его, говоря об отклике приложения при обычных условиях. Я буду пользоваться вторым вариантом определения.
Я общался с десятками 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) Оригинал статьи Перевод: Ольга Алифанова
Тут в игру вступает автоматизированное тестирование мобильных приложений. К счастью, в наши дни целое море продуктов и сервисов способны помочь автоматизировать наши мобильные тесты. Сегодня я расскажу о пяти из них, но сначала давайте рассмотрим семь советов, которые помогут вам преуспеть в автоматизации мобильного тестирования. Зайдите в любой салон связи, и вы увидите широкую линейку телефонов. Конечно, все стремятся убедиться, что ваше приложение хорошо работает на всех и каждом из них – а также на старых моделях, которыми до сих пор пользуется ваша аудитория. Однако прогон даже самого простенького набора ручных тестов на телефоне или планшете занимает время. Умножьте это время на количество предположительно поддерживаемых устройств, и у вас появится невпроворот работы!
Командная строка позволяет многое сделать как на вашем локальном компьютере, так и на удаленном. Особенно важно владеть ей в совершенстве когда другого способа взаимодействия (например, через GUI) с компьютером нет.
Некоторые команды бывают одновременно часто используемыми и длинными. Речь может идти либо о большом количестве параметров для использования одной команды, либо о длинной цепочке из набора команда. Любая опечатка или ошибка в таком случае может привести к непредвиденным обстоятельствам, не говоря уже о том, что печатание таких команда на регулярной основе съедает кучу времени.
Алиасы решают эту проблему, максимально упрощая работу с командной строкой. Если вы хотите работать с консолью эффективно, без алиасов вам не обойтись.
Подписывайтесь, чтобы регулярно получать новые видео по тестированию!
