Автор: Кристин Джеквони (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) с компьютером нет.
Некоторые команды бывают одновременно часто используемыми и длинными. Речь может идти либо о большом количестве параметров для использования одной команды, либо о длинной цепочке из набора команда. Любая опечатка или ошибка в таком случае может привести к непредвиденным обстоятельствам, не говоря уже о том, что печатание таких команда на регулярной основе съедает кучу времени.
Алиасы решают эту проблему, максимально упрощая работу с командной строкой. Если вы хотите работать с консолью эффективно, без алиасов вам не обойтись.
Подписывайтесь, чтобы регулярно получать новые видео по тестированию!
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Недавно на моем тренинге тестировщица никак не могла разобраться в одном вопросе. Вот о чем она спросила:
Почему некоторые технические руководители (к примеру, руководитель технического отдела, менеджеры разработки, тест-менеджеры и тест-лиды) сразу бросаются к тест-кейсам, если хотят обеспечить отслеживаемость, поделиться усилиями тестирования с заказчиками, и передать знания о фичах тестировщикам?
Не могу сходу ответить. Боюсь, что по большей части фиксация на тест-кейсах проистекает от невежества. Многие просто не знают другого способа думать о тестировании, и даже не пытались пробовать. К сожалению, это правдиво не только в отношении руководителей, но и в отношении тестировщиков. Большая часть тестирования как бизнеса опирается на костыли мифов, фольклора и инерции.
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Допустим, вы отвечаете за изначальную подготовку набора автотестов в вашей команде. Используя ваш основной компьютер, вы создали все сценарии, тщательно их протестировали, и теперь они готовы к использованию. Они основаны на существующем смоук-наборе тестов, и вы планируете запускать их при каждом деплое – теперь этим не нужно заниматься тест-команде. Автоматизация имеет бешеный успех и бережет кучу времени тестировщика еженедельно! Вы планируете заслуженный отпуск – всего на недельку.
Вся теория тестирования и 40 часов практики с экспертами QA:
★ Для тех, кто осваивает новую специальность
Получите все нужные знания, чтобы начать работать джуниор-тестировщиком в федеральной или международной компании.
★ Для тестировщиков с опытом 1-2 года
Приведете знания в систему, научитесь тратить на работу в 2 раза меньше времени, получите новый уровень кейсов, чтобы усилить ваше резюме на милд-позиции.
Мы ценим наших учеников и хотим стать полезнее шпината) Поэтому мы делаем наш курс полезнее, удобнее и понятнее с каждым запуском.
Читайте о том, как отзывы и пожелания наших участников помогали нам делать курс лучше и сильнее с каждым потоком. Для тех, кто дочитает до конца, сюрприз!
Я работаю QA-инженером в Miro. Расскажу о нашем эксперименте по передаче разработчикам части задач по тестированию и трансформации роли тестера в роль QA (Quality assurance).
Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.
Я работаю в команде Integration, задача которой — интеграция нашего сервиса во внешние продукты и интеграция внешних продуктов в наш сервис. Например, мы интегрировали таск-трекер Jira. Jira Cards — визуальное отображение задач, с которыми можно удобно работать на доске, не заходя в Jira.
