В современном мире востребованы приложения, которые способны максимально эффективно соблюсти интересы всех сторон. Часто это реализуется с помощью различного рода ограничений. Например, они не позволяют пользователю совершить действия, которые будут невыгодны ему самому или владельцу системы. При этом необходимо свести к минимуму дискомфорт, который вызывают такие ограничения.
К примеру, владельцу системы необходимо, чтобы в форме обратной связи номер телефона был указан в формате +7 (ХХХ) ХХХ-ХХ-ХХ для дальнейшего автоматизированного использования. Для удобства пользователя лучше использовать не просто подсказку или валидацию при отправке формы, а маску ввода, исключающую внесение данных в неверном формате. Получается, и волки сыты, и овцы целы.
Нагрузочное тестирование не так сильно востребовано и распространено, как иные виды тестирования — инструментов, позволяющих, провести такое тестирование, не так много а простых и удобных вообще можно пересчитать на пальцах одной руки.
Когда речь заходить о тестировании производительности — в первую очередь все думают о JMeter’е — он бесспорно остается самым известным инструментом с самым большим количеством плагинов. Мне же JMeter никогда не нравился из-за неочевидного интерфейса и высокого порога вхождения, как только возникает необходимость протестировать не Hello World приложение.
И вот, окрыленный успехом проведения тестирования в двух различных проектах, решил поделится информацией об относительно простом и удобном софте — Locust
Автор: Катрина Клоки (Katrina Clokie). Оригинал статьи Перевод: Ольга Алифанова.
Если вы – тестировщик в Agile-команде, то вы легко впадете в комфортабельный паттерн тестирования. Прозрачность ежедневных стендапов и размышления на ретроспективах создают иллюзию постоянного развития и улучшения. Эти рутины дают нам ощущение, что мы очень гибко работаем, но стоит копнуть чуть глубже, и может оказаться, что мы не так адаптивны, как кажется.
Если вы подумаете о последнем случае, когда вы неуютно себя ощущали на работе, то с высокой долей вероятности это чувство связано с какими-то переменами. Гибкий подход означает, что вы готовы принимать перемены и адаптироваться к ним на регулярной основе, а это значит, что вы постоянно испытываете дискомфорт.
Девушки рассказали о парном тестировании, о задачах, которые оно помогает решить, и привели пример неудачного использования практики.
В методологии XP есть практика — парное программирование. Во многих источниках написано о массе его преимуществ: высоком качестве кода, взаимозаменяемости разработчиков и т. д.
Если парное программирование настолько эффективно, то почему бы не применить аналогичные принципы в тестировании? Да, это можно сделать, парное тестирование существует давно и хорошо себя зарекомендовало. Но не стоит забывать, что любая практика является всего лишь инструментом для решения каких-либо задач.
В Википедии нет термина «парное тестирование», но есть определение для парного программирования, которое можно взять за основу. Тогда, на наш взгляд, мы получаем следующее.
Парное тестирование — это техника, при которой тестирование одной функциональности производится парой людей за одним рабочим местом. Один тестировщик («ведущий») управляет компьютером, второй («штурман») непрерывно следит за работой первого. При этом на всем протяжении работы над задачей они обмениваются идеями и обсуждают их.
Любая практика — всего лишь инструмент. Мы не хотим забивать гвозди микроскопом, поэтому всегда отталкиваемся от задачи. Давайте рассмотрим те задачи, для которых релевантно использование практики «парное тестирование».
Если вы хоть раз делали REST-запрос или изучали раздел инструментов разработчика в браузере, то наверняка видели код ответа из трех цифр, возвращенный в ответ на HTTP-запрос. Давайте поговорим о различных типах кодов ответа, которые можно получить в процессе тестирования API, и том, что они означают.
Команда, куда мы сейчас ищем специалиста, работает над мультимодальной системой учета и биометрического поиска "Grid Id". Она представляет собой продукт, позволяющий осуществлять поиск по множеству параметров, в том числе фотографическому изображению лица и голосу.
Кластерные вычисления, обработка больших объемов данных, обработка аудио, фото и видео информации, отказоустойчивость N+1 - это наши будни.
Если ты готов к решению амбициозных задач, готов принести свой положительный опыт в команду и не ищешь тихой гавани - добро пожаловать!
Выбор. Все мы делаем выбор десятки раз за день. Арахисовое масло или сыр (я, как правило, за сыр). Джинсы или слаксы (определенно джинсы). Кофе или чай (хороший кофе со стаканом воды, пожалуйста). А когда вы работаете над автоматизацией или обучаетесь ей, перед вами встает множество вариантов, которые вы можете (а иногда должны) выбирать. Многие из этих вариантов, насколько я могу судить по обсуждениям и решениям людей вокруг, не очень-то хороши. Некоторые из них – вообще ложные дихотомии. Давайте посмотрим, над какими решениями размышляют люди, и какие еще варианты им доступны из тех, что могут дать лучшие результаты и сделать их лучше как специалистов.
Тест-персона – это вымышленный персонаж, представляющий собой потенциальных пользователей системы. Еще его называют "пользовательская персона" или просто "персона".
Зачем это нужно?
Определяя проблемы и нужды персон и размышляя над ними, вы можете вскрыть сценарии и проблемы, о существовании которых вы даже не подозревали.
Сегодня мы закончим обсуждение типов REST-запросов, разобрав DELETE-запрос и специфику его тестирования. Мы также узнаем, как создать цепочку REST-запросов в коллекции Postman.