Представьте, что перед Вами поставили задачу: протестировать API веб-сервиса. На этом этапе возникает довольно много вопросов, начиная от “Что именно требуется протестировать? Функционал? Нагрузку? Юзабилити?” до “Чем отличается список проверок для тестирования API от чек-листа для проверки UI”? В данной статье я поделюсь своим опытом составления проверок и кейсов для функционального тестирования SOAP API крупного государственного проекта со сложной логикой; мы обсудим, как лучше писать проверки и на что следует обратить особое внимание; в конце я представлю примерный вид документа с результатами тест-дизайна, которым будет удобно пользоваться и который не стыдно показать менеджеру или заказчику.
Желаем вам найти сотни важных багов и не дать им проскользнуть в релиз, изучить новые технологии и инструменты, покорить сложнейшие проекты и стать образцом для подражания!
Начинающие тестировщики – желаем успешно найти отличную работу и быстро стать мастерами своего дела!
Тест-аналитики – пусть документация будет внятной, а заказчики – отзывчивыми!
Автоматизаторы – чистого вам кода и надежного инструментария!
Тест-менеджеры – пусть ваша команда всегда работает, как часы!
С наступающим Новым Годом и Рождеством, наше любимое сообщество! Есть ли у вас профессиональные планы и цели на Новый Год? Поделитесь на форуме, и все новогодние обещания обязательно исполнятся!
Мы подготовили для вас вредные советы – постарайтесь не следовать им в наступающем году, и тогда все ваши профессиональные мечты обязательно сбудутся!
Публикуем запись доклада Антонины Фанталиной "Автоматизация регресса бекендов. Без СМС и автотестов" с прошедшего в Новосибирске QA DevDay.
Тоня тестирует навигатор в 2ГИС. Проект объёмный, а имеющиеся unit-/функциональные/интеграционные тесты не всегда находят проблемы. В своём выступление Тоня рассказала, как проверить API на изменения с помощью diff-ответов от сервера, и поделилась муками выбора между Diffy, Karate и кастомным решением.
Тренер по тестированию Ольга Назина подготовила для читателей нашего портала новогодний подарок — подборку переводов исследовательских туров от James A. Whittaker из книги Exploratory Software testing!
Исследовательское тестирование — серьезная тема, провести его полноценно может только опытный тестировщик. Это ведь не просто «потыкать рандомно», все равно нужен план тестирования.
James A. Whittaker нашел способ проводить исследовательское тестирование даже начинающими тестировщиками. Он составил методику туров, которые может выполнить любой. Фактически каждый тур — это тот самый план, по которому мы будем тестировать. План, уже составленный за нас!
Если вы еще не пользовались методикой, обязательно попробуйте. А Ольга Назина подготовила подборку любимых туров, которые находят баги практически везде:
Сегодня мы рассмотрим POST-запросы. Они, пожалуй, наиболее важные из всех REST-запросов, потому что добавляют новые записи в базу данных приложения. Очень важно как следует их протестировать, потому что они напрямую влияют на качество данных вашей базы.
Усилия по тестированию прилагаются на различных уровнях автоматизации в приложении. Вот некоторые из них, которые я, согласно личному опыту, нахожу интересными:
Автоматизация на юнит-уровне – она редко касается кого-либо, кроме разработчиков, и я считаю, что это правильно. В норме цель юнит-тестов – это предоставление быстрой обратной связи о правильности работы кода. Конечно, они подвержены тем же болезням, что и автоматизация в целом – "утверждающе-демонстративному" образу мышления при создании тестов. Даже если тесты используются в методологии управления через тестирование, они не особенно полезны, если сообщают только о том, что продукт работает. Фактически любой тест, который не подвергает систему суровым испытаниям с целью выявления проблем – это просто показуха.
Тут важно помнить, что очень глупо полагать, что наличие юнит-тестов означает, что что-то вообще тестировалось, или же что нужда в других уровнях тестирования благодаря наличию юнит-тестов снизилась. Юнит-тесты просто сообщают, что наш код готов двигаться дальше по цепочке тестирования. Не больше, не меньше!
Открыта регистрация и прием докладов на юбилейную 25-ю международную конференцию по тестированию ПО - SQA Days-25.
Организаторы пригласили большое количество ключевых докладчиков и запланировали различные интересные активности. Ну и, конечно же, организаторы постараются создать для Вас атмосферу праздника в рамках юбилейного мероприятия.
Конференция пройдет 31 мая - 01 июня 2019 в Санкт-Петербурге в гостинице Crowne Plaza Airport (будет организована доставка участников от ст. м. "Московская").
Приглашаем Вас поделиться экспертизой и предложить доклад. Помимо шанса получить классный приз, это возможность получить признание аудитории и обратную связь, которая поможет дальнейшему развитию. Кроме того, это Ваш вклад в историю отрасли.
Меня зовут Виталий Котов и я работаю в компании Badoo. В одной из предыдущих статей я рассказывал, что у нас есть некий интерфейс, который помогает взаимодействовать с автотестами как тестировщикам, так и разработчикам.
Не раз и не два меня просили рассказать о нём подробнее.
Под катом я (наконец!) расскажу о том, как писал этот интерфейс и что он умеет. Расскажу о фичах, которые прижились, и о тех, которые оказались невостребованными по тем или иным причинам. Возможно, некоторые идеи вам покажутся интересными, и вы тоже задумаетесь о подобном «помощнике».
Все больше и больше компаний переходит на микросервисы в своих приложениях. Это означает, что разные секции приложения могут иметь отдельные хранилища данных и отдельные команды для взаимодействия с ними. Преимущество такого подхода в том, что в небольшой компонент внедрять изменения куда проще, нежели менять все приложение. Это также означает, что если упадет один микросервис, оставшаяся часть приложения продолжит функционировать. К примеру, представьте, что у вас есть сайт проката велосипедов. У него есть микросервис системы бронирования, и еще один – для учета оборудования. Если микросервис оборудования упадет, пользователи все равно смогут бронировать велосипеды, используя кэшированные данные сервиса оборудования.
Большинство микросервисов используют API – программные интерфейсы приложения, которые представляют собой наборы команд, описывающих, как можно использовать службу. Большая часть API использует REST-запросы (Representational State Transfer — «передача состояния представления») для отправки и получения данных.
Однако, несмотря на широкое применение REST API в современных приложениях, многие тестировщики даже не подозревают, как легко их тестировать! Эта статья – введение в REST-запросы и их использование в тестировании API.
Вышел выпуск рассылки за первую половину декабря, его содержание доступно 
