Home

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

Автор: Юлия Багрий, ведущий специалист по тестированию компании "Лаборатория качества" 

Не так давно в нашем блоге рассказывалось об освоении тестирования через REST API. Я же хочу поделиться опытом тестирования SOAP, «старшего брата» REST.

SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).

Тестирование SOAP с точки зрения техник тестирования ничем принципиально не отличается от работы с другими API, но для его проведения требуются предварительная подготовка (в плане теории протокола) и специальные инструменты для тестирования. В данной статье я хотела бы сформулировать небольшой чек-лист необходимых знаний и навыков, который будет одинаково полезен как тестировщику SOAP (зачастую не представляющему, «за что хвататься» после постановки задачи), так и менеджеру, вынужденному оценивать знания тестировщиков и разрабатывать планы по обучению.

Оригинал статьи: http://www.testingexcellence.com/bad-requirements-software-testers-nightmare/

Автор: Намита Коли Арора (Namita Kohli Arora)

Перевод: Ольга Алифанова

Реальный мир никогда не бывает переполнен розовыми пони, и то же самое справедливо для наших рабочих задач. Я множество раз сталкивалась с тест-проектами, которые были крайне далеки от идеала: в них отсутствовала даже самая базовая документация, и не было никакого намека на централизованное управление тестированием. Худшее, с чем я встречалась – это проекты, в которых или вообще не было требований, или эти требования были записаны абы как. Работа над такими проектами сводит меня с ума и стоит мне многих бессонных ночей (я не преувеличиваю – попытки разобраться в разрозненных информационных потоках заставляют мозг работать 24/7). Но нравится мне это или нет, такие проекты – наша реальность, и у нас нет выбора: с ними приходится иметь дело.

"Плохие требования" – довольно широкое понятие. К примеру, это могут быть:

Оригинальная публикация: https://habrahabr.ru/post/329966/

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

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

Эти определения неверны.

Вот вам дедуктивное умозаключение:

Вписываясь в тестирование, мы желаем добавить продукту значимость (ценность) –
Добавление ценности продукту происходит за счет увеличения качества и надежности продукта – 
Добавление надежности продукта происходит путем поиска и удаления ошибок.

Поэтому не занимайтесь тестированием. Не занимайтесь тестированием для того, чтобы показать, что все работает; начните с аксиомы – программа содержит ошибки (кстати, это верно для большинства программ), и далее тестируйте так, чтобы найти их столько, сколько это вообще возможно, будто это Ваш последний день (в тестировании).

Автор: Олег Грабко, ведущий специалист по тестированию компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/key-principles-of-web-testing/

Доводилось ли вам тестировать веб-приложения? Практически любой специалист по тестированию программного обеспечения с опытом более года даст утвердительный ответ на этот вопрос, ведь существуют вполне объективные причины такого положения дел:

- на данный момент в сети Интернет действует более миллиарда сайтов, и пользуются ими более 3,5 млрд. людей по всему миру (по данным Международного союза электросвязи на июль 2016 года);
- в России более 70% взрослого населения являются интернет-пользователями, а общий оборот средств на российском рынке интернет-торговли за первое полугодие 2016 года вырос на 26% в сравнении с аналогичным периодом 2015 года и достиг 405 млрд. рублей.

При взгляде на эти баснословные цифры становится понятным, почему в мире разрабатывается так много новых веб-приложений. Этот процесс приводит к необходимости привлечения большого количества специалистов. То, что веб (в широком смысле) будет продолжать наращивать темпы своего развития, подтверждается и набирающим силу «мейнстримом»: всё «переезжает» в облака. Облачные технологии становятся новой реальностью современного Интернета: даже некогда привычные нам десктопные Word и Excel сегодня представлены в виде веб-альтернатив от Microsoft. Исходя из сказанного, можно утверждать, что потребность в хороших инженерах по обеспечению качества, специализирующихся на веб-продуктах, будет только расти.

Представленная вниманию читателей статья посвящена вопросам особенностей тестирования веб-приложений. Будет правильным начать повествование с основ и определиться, что именно мы подразумеваем под понятием «веб-приложение» и какие нюансы в реализации этих приложений добавляют работу тестировщикам.

Оригинал статьи: https://testzius.wordpress.com/2017/02/13/sun-tzu-was-a-tester/

Автор: Майкл Фритциус (Michael Fritzius)

Перевод: Ольга Алифанова

О книге

Книга Сун Цзы "Искусство войны" была написана в 5 веке до нашей эры. С тех пор она переводилась на множество языков и использовалась не только с целью обучения военной тактике, но и в корпоративных отношениях, спорте, бизнесе, и ряде других дисциплин, требующих стратегии и тактики.

Периодически я наталкиваюсь на цитаты из этой книги, которые подходят и для области обеспечения качества. В какой-то степени QA похоже на войну – мы боремся с забагованным кодом, строгими дедлайнами, недостатком ресурсов и раздражением коллег.

Давайте посмотрим, как мудрость Сун Цзы применима к "Искусству тестирования".

Далее следуют цитаты из книги и их возможное приложение к тестированию. Расширенный набор цитат можно посмотреть здесь.

Применение в тестировании

"Превосходство над вражескими нациями без вступления в военные действия есть наивысшее из искусств".

Работая с другими людьми, мы должны помнить о том, что люди – существа эмоциональные. Каждый приносит на рабочее место свой личный "багаж" эмоций. Часть нашего багажа отвечает за наше отношение к другим людям. Если вы хотите напасть в ответ на чей-то укол, остановитесь и подумайте, почему люди говорят именно это? Действительно ли они хотят "достать" вас, или преследуют личные цели? Обычно это скорее второе, а не первое. Хорошая коммуникация – залог успеха: обезвредьте ситуацию, поговорив с коллегой и попытавшись понять, какие цели он преследует.

Автор: Юлия Багрий

Оригинальная публикация: http://quality-lab.ru/your-api-is-your-public-face/

Для начала нам нужно понять, что же такое API?
API (Application Programming Interface) – это интерфейс, который позволяет осуществлять взаимодействие между программами. Если человек общается с приложением через кнопки и диалоги (пользовательский интерфейс, UI), то программы обмениваются информацией друг с другом через API.

Категории взаимодействия API

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

• мобильное либо десктопное приложение синхронизирует данные с сервером;
• приложение использует вычислительные возможности сервера (к примеру, приложение Prism загружает фото и информацию о выбранном стиле на сервер, где уже происходит стилизация изображения);
• взаимодействие между веб-приложением и сервером;
• взаимодействие между микросервисами.

Основные риски, связанные с внутренним API, – это функциональные дефекты и проблемы производительности. Здесь пользователи могут лишь предполагать, из-за чего конкретно приложение работает «как-то не так».

При внешнем взаимодействии связи с другими сервисами выходят за рамки вашей системы. В данном случае вы либо используете чей-то внешний API (почти в любом приложении есть доступ к сторонним сервисам – к социальным сетям, платежам, картам и т. д.), либо сами предоставляете свой API сторонним разработчикам.

Подробно остановимся на втором варианте. Предоставление API является для некоторых главным бизнесом (те же социальные сети и платежи), для других же – приятным дополнением к основному сервису. Но в любом случае форма реализации и представления API, образно говоря, «приоткрывает дверь во внутреннюю кухню» разработки. И вот тут уже «спрятаться» за красивым дизайном и саппортом не получится.

Автор: Андрей Шальнев

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

В этой статье я хочу поделиться опытом освоения тестирования (в т. ч. автоматизации) на уровне API (Application Programming Interface – интерфейс программирования приложений, интерфейс прикладного программирования). Надеюсь, что предлагаемый материал будет представлять интерес для всех, кто ранее проводил тестирование через графический интерфейс и еще не имеет опыта работы с http-запросами.

Немного о REST API и SOAP API

Стоит отметить, что на сегодняшний день есть два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API:

• REST (от англ. Representational State Transfer – «передача состояния представления») обеспечивает общение между клиентом (как правило, это браузер) и сервером с помощью обычных HTTP-запросов (GET, POST, PUT, DELETE и т. д), передавая информацию от клиента в параметрах самих запросов, информацию от сервера – в теле ответа (который может быть, например, JSON-объектом или XML-документом). REST является архитектурным стилем, а не стандартом.
• SOAP (от англ. Simple Object Access Protocol – простой протокол доступа к объектам, вплоть до спецификации 1.2) характеризуется использованием HTTP(S)-протокола лишь как транспорта (чаще всего, методом POST). Все детали сообщений (в обе стороны – от клиента к серверу и обратно) передаются в стандартизованном XML-документе. SOAP может работать и с другими протоколами прикладного уровня (SMTP, FTP), но чаще всего он применяется поверх HTTP(S). SOAP является протоколом и имеет спецификацию.

Автор: Екатерина Зарубина

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

Прежде чем перейти к обсуждению особенностей тестирования интернет-магазинов, нужно ответить на простой вопрос: чем вообще интернет-магазин отличается от любого другого сайта? Вряд ли мы ошибемся, если скажем, что основное отличие кроется в заложенной задаче. Задача интернет-магазина (как и любого магазина вообще) – продать товар. Сделать это будет тем проще, чем меньше усилий покупателю придется приложить во время покупки. Процесс «Пришел-Купил-Получил» должен быть краток и интуитивно понятен – и тогда интернет-магазин будет успешно реализовывать свои товары.

К сожалению, на практике все обстоит далеко не так просто. Шанс допустить ошибки при разработке интернет-магазина довольно велик, ведь разработчику нужно учесть множество разнообразных факторов, начиная от особенностей целевой аудитории и заканчивая тонкими нюансами в организации страниц и форм. С какими же багами мы можем столкнуться при тестировании интернет-магазинов?

Баги верстки

Мы живем в мобильном мире, в котором люди хотят иметь возможность покупать товары, используя не только ПК. Разнообразие и массовая доступность мобильных устройств любого класса и типа сделали свое дело. Покупатели приобретают товары с любого смартфона или планшета (как с самых простых, так и с последних моделей Apple) и в любой точке планеты (начиная от поезда метро по пути на работу и заканчивая «левым склоном горы Фудзияма»). Интернет-магазин должен быть кроссбраузерным и кроссплатформенным – то есть, выглядеть идеально в любом браузере, при любом разрешении экрана и на любом устройстве.

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

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/three-digestible-diagrams-to-describe-exploratory-testing

Автор: Саймон Томес (Simon Tomes)

Перевод: Ольга Алифанова

Живой магнит для багов

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

"Может кто-нибудь сказать Томесу, чтобы он прекратил тестировать? Он просто ломает ПО и находит больше и больше багов!"

Я буквально сдулся и почувствовал себя бессмысленным. Конечно, глубоко внутри себя я знал, что мой статус магнита для багов был несправедлив, но мне не хватало способности объяснить, почему.

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

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

Зачем объяснять "для тупых", что именно мы делаем, когда занимаемся исследовательским тестированием? Зачем молчать про ту ценность, которую команда, продукт и потребитель получают от такого подхода к тестированию? Это выглядит, как неуважение к сообществу и потребителям – мы делаем ПО, но рассказываем о том, как, некорректно и нечестно.

Нажмите на картинку, чтобы увеличить изображение

Автор: Петтер Мален (Petter Måhlén)

Оригинал статьи: https://labs.spotify.com/2014/04/11/qualities-of-quality/

Перевод: Ольга Алифанова

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

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

Обычно, когда говорят о качестве, люди думают о том качестве, которое наблюдает конечный пользователь: качество продукта - баги, недостатки интерфейса, и всякое такое. Качество продукта – это нефункциональная характеристика, и ее можно приоритезировать по отношению к другим характеристикам (производительность, улучшенный дизайн, улучшенный алгоритм рекомендаций, и так далее). Тип качества, который можно назвать мета-характеристикой – это качество со стороны разработчика, что можно назвать качеством внедрения. Это такие штуки, как понятность и читабельность кода, легкость повторного использования, и отсутствие багов. Качество внедрения не влияет на пользовательский опыт, зато оно влияет на производительность команды, работающей над улучшением пользовательского опыта. Эти два вида качества пересекаются, но они – не одно и то же.