Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова.
В этой части ретроспективных уроков автоматизации я постараюсь сконцентрироваться на другом ключевом вопросе – что имеет смысл автоматизировать? Почему именно это, а не то? Зачем люди тратят столько времени на UI-тесты? Чтобы перейти к этим вопросам, поговорим об интерфейсах.
Публикуем подборку докладов с конференции SQA Days 24, посвященную вопросам нагрузочного тестирования и тестирования безопасности.
Агент для симуляции трафика. Кто он – Николай Миронцев, СмартБеар Софтваре (Тула).
Интеллектуальное игровое моделирование в нагрузочном тестировании бизнес приложений – Владимир Крючков, Группа Полипластик (Москва).
CWE, CERT, MISRA, OWASP - просто модные слова или способ повысить качество программного обеспечения? – Евгений Рыжков, PVS-Studio (Тула).
Сломай меня, если сможешь! Или как протестировать устойчивость сложных распределенных системы к нештатным ситуациям? – Павел Липский, Сбербанк-Технологии (Санкт-Петербург).
Меня зовут Виталий Котов, я работаю в компании Badoo и бо́льшую часть времени занимаюсь вопросами автоматизации тестирования. Решением одного такого вопроса я и хочу поделиться в этой статье.
Речь пойдёт о том, как мы организовали процесс работы UI-тестов с A/B-тестами, коих у нас немало. Я расскажу о том, с какими проблемами мы столкнулись и к какому флоу пришли в итоге. Добро пожаловать под кат!
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова.
Сегодня мы узнаем, как тестировать на наличие IDOR. IDOR расшифровывается как Insecure Direct Object Reference (небезопасные прямые ссылки на объекты) и подразумевает ситуацию, когда пользователь может успешно получить доступ к странице, данным или файлу, доступа к которым у него быть не должно. Мы обсудим четыре способа, которыми эта уязвимость проявляется, а затем поэксплуатируем ее в тестовом приложении, используя инструменты разработчика Chrome и Postman.
В этой статье Анастасия Ронжина, тестировщик сервиса Контур.Маркет, расскажет о том, почему стоит пробовать что-то новое, менять свои взгляды, подходы, ошибаться и снова пробовать.
У меня всё хорошо, я отлично работаю, меня хвалят, зачем мне что-то менять? Вполне логичный вопрос. В ответ цитата из книги «Алиса в Зазеркалье»:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Пока мы сидим и просто тестируем задачки, мир не стоит на месте. Джеймс Бах с Майклом Болтоном проводят очередное исследование и ищут подходы к тому, чтобы за короткое время тестировать с высоким качеством.
Эволюционирует место тестировщика в процессе разработки, да и сами процессы. Например, Максим и Ирина из нашей компании рассказывали про эволюцию автотестов, о том, как можно ускорить разработку с помощью тестов и изменении взглядов на то, кто и на каком этапе их должен писать. Лена и Илария рассказывали о том, что можно менять свои инструменты, подключаться к общению с пользователем, к подготовке ТЗ и прототипов, чтобы повысить качество продукта.
26 апреля - День мастер-классов, 27 апреля - День докладов.
Что Вас ждет на конференции?
5 мастер-классов и более чем 30 докладов по следующим направлениям:
Автоматизация тестирования (12), Ручное тестирование (4), тестирование ПО для мобильных устройств (3), тестирование производительности (3), процессы в тестировании (2), тестирование требований (2), usability тестирование (1), DevOps (1).
По окончании второго дня конференции After Party для всех желающих.
Вы можете подробней ознакомиться с программой и стоимостью билетов по ссылке.
Для размещения участников нашей конференции Отель «IBB Hotel» предлагает скидку 15%. Промокод Comaqa Spring 15% Вы можете ввести при бронировании на сайте отеля или сообщить при заселении администратору. Хотим обратить внимание, что промокод не действует при бронировании через дополнительные сервисы, такие как, например, Booking.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Сегодня мы поговорим о добавлении правил в Postman-запросы. Мы уже говорили о том, что значат различные коды ответов на API-запросы, и как писать правила для них в Postman. Теперь мы добавим другие правила, которые более полно протестируют наши запросы.
Мы будем использовать созданную нами коллекцию Postman, поэтому если вы еще этого не сделали – настройте ее, прежде чем продолжать.
В современном мире востребованы приложения, которые способны максимально эффективно соблюсти интересы всех сторон. Часто это реализуется с помощью различного рода ограничений. Например, они не позволяют пользователю совершить действия, которые будут невыгодны ему самому или владельцу системы. При этом необходимо свести к минимуму дискомфорт, который вызывают такие ограничения.
К примеру, владельцу системы необходимо, чтобы в форме обратной связи номер телефона был указан в формате +7 (ХХХ) ХХХ-ХХ-ХХ для дальнейшего автоматизированного использования. Для удобства пользователя лучше использовать не просто подсказку или валидацию при отправке формы, а маску ввода, исключающую внесение данных в неверном формате. Получается, и волки сыты, и овцы целы.
Нагрузочное тестирование не так сильно востребовано и распространено, как иные виды тестирования — инструментов, позволяющих, провести такое тестирование, не так много а простых и удобных вообще можно пересчитать на пальцах одной руки.
Когда речь заходить о тестировании производительности — в первую очередь все думают о JMeter’е — он бесспорно остается самым известным инструментом с самым большим количеством плагинов. Мне же JMeter никогда не нравился из-за неочевидного интерфейса и высокого порога вхождения, как только возникает необходимость протестировать не Hello World приложение.
И вот, окрыленный успехом проведения тестирования в двух различных проектах, решил поделится информацией об относительно простом и удобном софте — Locust
Автор: Катрина Клоки (Katrina Clokie). Оригинал статьи Перевод: Ольга Алифанова.
Если вы – тестировщик в Agile-команде, то вы легко впадете в комфортабельный паттерн тестирования. Прозрачность ежедневных стендапов и размышления на ретроспективах создают иллюзию постоянного развития и улучшения. Эти рутины дают нам ощущение, что мы очень гибко работаем, но стоит копнуть чуть глубже, и может оказаться, что мы не так адаптивны, как кажется.
Если вы подумаете о последнем случае, когда вы неуютно себя ощущали на работе, то с высокой долей вероятности это чувство связано с какими-то переменами. Гибкий подход означает, что вы готовы принимать перемены и адаптироваться к ним на регулярной основе, а это значит, что вы постоянно испытываете дискомфорт.
