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

Привет, Хабр! Меня зовут Ирина Иванова, я работаю QA-инженером в команде разработки внутренних проектов в Учи.ру. Мы занимаемся такими сервисами, как виджет поддержки, личный кабинет сотрудников пользовательской поддержки, карьерный сайт и так далее. 

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

Качество программного продукта — важный критерий. Однако не каждый способен его четко обозначить, а тем более объяснить, как его достичь. Как правило, у каждого члена команды свое представление о качестве. Это связано с тем, что в оценке в большей степени учитываются субъективные мнения. Правильнее сказать, что качество представляет собой набор критериев или параметров. И этот набор может отличаться в зависимости от личного опыта или профессиональной деятельности участника команды: пользователя, разработчика, тестировщика, аналитика, заказчика или др.

Введение

Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки. Такое случается в потрясающе огромном проценте компаний и проектов. Даже если компании знают о существовании такого понятия, как QA, и что его нужно выполнять, все усилия обычно приводят лишь к большому спринту QA прямо перед релизом. Это стрессовый период, в который мы пытаемся заставить ПО хотя бы немного работать. Разумеется, весь этот хаос повторяется на следующем цикле релиза без малейших улучшений.

Чему нас учат в вузах

Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО. Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее. Кроме того, по крайней мере, в моей учёбе, был семестр, посвящённый методикам управления проектами и Scrum. Всё это замечательно, но тут совершенно отсутствует QA. Пренебрежение QA — это огромная потеря, потому что больше 90% всех студентов после завершения учёбы работает в контексте компаний. Они должны будут выпускать ПО вовремя и без багов.

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

С тех пор как мы это поняли, автоматические тесты стали просто необходимы. Это привело к массовому внедрению шаблонов для старта работы. Однако просто начать работу недостаточно.

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

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

Это может касаться как простых ошибок, на которые не хочется тратить время специалистов, так и неочевидных ошибок, у которых иногда непросто определить причину.

Меня зовут Николай, и я инженер в мобильной платформенной команде Яндекс Еды. В этой статье я расскажу, как мы повышаем качество кода автотестов Android-приложения. И в этом нам помогает статический анализ.

Привет, Хабр!

С развитием  и усложнением ИТ- продуктов, стоимость регрессионного тестирования увеличивается, а требования к качеству и надежности программного обеспечения становятся всё более высокими. Мы обнаружили, что традиционные методы тестирования не всегда эффективны для масштабных  и многофункциональных  систем, поэтому начали применять новые техники. В этой статье мы рассмотрим композиционное тестирование, основанное на комбинаторике и системном анализе, которое значительно помогает в автоматизации процессов регресса.

Привет! Меня зовут Таня, я куратор в SM Lab. В этом посте я расскажу вам о нашем пути оптимизации тестирования — узнаете, какие на нашем продукте были проблемы в процессах тестирования, как мы их решали, почему не надо отвлекать тестировщиков и в чём польза интуитивного тестирования.

Для того чтобы понять суть процессных изменений, нужно знать, как же мы работали до них.

Итак, основа. 

У нас есть две доски в Jira. Первая отвечает непосредственно за релизные задачи и хотфиксы, вторая — за задачи сопровождения и инциденты. Рассмотрим подробнее первую доску с задачами и хотфиксами.

На ней есть три колонки, с которыми и работают тестировщики:

Всем привет, это моя первая статья по тестированию. До этого я писал от лица Scrum-мастера, а теперь уже и от лица QA. В тестировании я уже более 2-х лет. Работал на двух проектах одновременно, и было супер весело менять проект на протяжении дня: утром ты тестируешь веб-сервис, а вечером со студентами делаешь тест-план по мобильному приложению. Не жизнь, а сказка!

Из названия мы с вами понимаем, что тема статьи интересна и, как воздух, необходима.

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

Не будем петь серенады, как это сложно, и приступим к делу.

Вас посвящают в суть проекта, и главный шаг - уточнить у аналитика или того героя, кто выполняет эту роль, "Есть какая-нить дока?" (далее - спецификация).

Какая может быть спецификация на проекте? Будьте внимательны, я не использую термин документация, потому-что дока - это текстовый формат, а в виде спецификации может выступать:

1) документация; обновленная в последний раз в 90-х

2) макеты; вообще не похожи на прод

3) тикеты в Jira; обычно там один заголовок, но верим в чудо

4) user-story;

5) тест-кейсы, чек-листы; если был тестировщик до

6) звонок с владельцем продукта; Product owner

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

Всем привет, меня зовут Александр, в последние 2 года занимаюсь автоматизированным тестирование. Хочу поделиться своим наработанным опытом по созданию API тестов. Для написания автотестов в компании используем selenium webdriver, behave.

Behave — это фрейморк для программирования через поведение системы в python-стиле. Behave использует тесты, написанные на “естественном”, то есть, английском языке.

Selenium webdriver широко используется и думаю в представлении не нуждается, но всегда можно загуглить.

Структура тестов behave очень проста, если feature файлы в которых описываются сценарии и папка steps в которой находятся шаги для выполнения этих сценариев.

Первое на что можно обратить внимание это на структуру feature файлов (в этих файлах находятся сами тесты, которые состоят из различных шагов):

Привет, Хабр!

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

Так какие особенности сопутствуют тестированию десктопных приложений?

Всем привет! Я Ирина Матевосян, системный аналитик в направлении продуктового и системного анализа в отделе Tinkoff Mobile Core. Мы разрабатываем общие библиотеки, которые используют все мобильные приложения экосистемы Тинькофф. 

Расскажу о протоколе gRPC. На Хабре много статей о тонкостях реализации, рассчитанных на разработчиков, я же хочу познакомить с ним своих коллег. Разберем, как работает протокол и как написать контракт так, чтобы вас поняли, но не будем погружаться в тонкости программной реализации, а скорее расширим кругозор. Возможно, для кого-то gRPC станет крутым решением в работе.

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