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

• Какие ресурсы требуются и когда.
• Когда и кто будет выполнять задачи.
• Навыки, необходимые для выполнения задач.
• Инструменты и технологии, необходимые для выполнения плана.
• Какие результаты должны получить и в какой срок.
• Стоимость ресурсов.
• Процесс продвижения проекта/процесса по этапам.
• Риски, угрожающие выполнению проекта.

Жизнеспособность плана зависит от того, знают ли все участники проекта, что они делают и как.

Тестирование API — это тестирование ПО, при котором API тестируются на уровне сообщений, например, веб-сервисы SOAP, REST API и т.д.  

API не получится тестировать вручную. Их функциональность нельзя протестировать с помощью фронтенда, поскольку в интерфейсе нет взаимодействия с пользователем. Поэтому для тестирования API необходимы инструменты.

Тестирование API особенно полезно при agile с ее короткими циклами разработки, что повышает необходимость автоматизировать тестирование.

Сегодня День знаний, с чем вас и поздравляю! По этому случаю собрал для вас различные бесплатные ресурсы и платформы для обучения профессии "тестировщик".

Все материалы использовал или использую сам.

Всем привет! Работаю QA аналитиком на достаточно крупном проекте в области WEB и мобильных приложений. Программистом не являюсь, но периодически скрипты для себя пишу, поэтому за качество кода прошу строго не судить. Но сегодня хочется принести немного data science в жизнь тестировщиков и показать, что если не куплены средства автоматического анализа, то кое-что можно написать и самому.

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

С точки зрения команды QA же было интересно узнать больше о нашем процессе регрессионного тестирования. Трудность проекта состоит в большом количестве подключаемых функций и кастомизаций. Количество Feature Flags подключающих те или иные опции стремится к 700. Регресс выполняется еженедельно, успеть протестировать всё возможности нет.

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

Туториал по работе с логами в Kibana для начинающих специалистов по тестированию ПО.

У Kibana имеется свой язык запросов KQL (Kibana Query Language) - официальный источник. С помощью этого языка можно составлять запросы, которые помогают отфильтровывать и найти необходимую информацию.

Подключение к Kibana для просмотра логов.

Многие, кто приходил в любую новую сферу, задавались вопросами: «какими инструментами необходимо владеть, чтобы…», «а точно ли это весь перечень?», «а какие навыки необходимы, чтобы пройти собеседование?». Таких вопросов больше у новичков, которые уже начали обучение или только в поисках обучения, пытаются понять минимум необходимый для старта.

Давайте разберёмся с вопросами по ручному и автоматизированному тестированию, которые задают в том числе и студенты курса «Инженер по тестированию».
В статье мы пройдём по нужным навыкам, инструментам. Дадим полезные ссылки для углубления в темы и составим карту компетенций.

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

Если бы мне задали такой вопрос, то я не смог бы на него правильно ответить. Ведь начинал я с ручного тестирования, а сейчас мы департаментом раскатываем на весь банк гигантский «дашборд», который привязан буквально ко всем данным компании, и позволяет оценить качество работы любой команды. Меня зовут Иван Боклач, я руководитель направления развития экспертизы QA в Центре Координации и Повышении эффективности разработки в Альфа-Банк. Я занимаюсь развитием новых технологий, метриками, стандартизацией и автоматизацией процессов.

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

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

Но помимо hard-инструментов есть и soft-составляющая. Она не столь очевидна, но тоже помогает повысить качество сервиса. Меня зовут Николай Котов, я старший QA-инженер в Тинькофф и сегодня расскажу, как социальные связи влияют на качество проекта, и поделюсь советами по укреплению этих связей.

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

Помните, как вы были студентами, и готовились к экзаменам по ночам?

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

Изучите теорию на примерах и закрепите на 13 практических задачах по SQL.

Всем привет! Меня зовут Константин, и я работаю ведущим тестировщиком в дружной команде back-end компании Solit. Мои коллеги уже не раз делились различными хитростями и ноу-хау, которые они применяют в своих проектах. Я же решил пойти немного другим путём и поделиться с вами набором сервисов и утилит, которые помогают нам прийти к недостижимой цели — работа приложений без дефектов.

 В мою подборку попали те приложения, которые прижились в нашей команде и ими пользуется более одного человека. Конечно, есть очевидные вещи, типа Notepad++. Но есть и более редкие «звери», типа JWT.

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

Приложения для генерации данных

Правильная подготовка тестовых данных — уже половина успешного тестирования. В этом разделе я собрал приложения, которые помогают быстро сгенерировать большие (я бы даже сказал, очень БОЛЬШИЕ) объёмы тестовых данных.

pgCodeKeeper

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

 В нашем случае она прижилась именно как генератор тестовых данных для БД Postgres. Подробнее о том, как он работает, можно прочитать в официальной справке pgCodeKeeper.

Меня зовут Виктор Мясников, я отвечаю за качество продукта в «Юле». Я закончил Бауманку и хотел строить ракеты, но с ними не вышло, поэтому теперь профессионально строю «велосипеды» для QA, а ещё люблю уничтожать рутину. Я расскажу, как мы проектировали BDD-фреймворк и зачем он вообще нам понадобился.

Queue (очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers (потребителям). Queue представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.

Binding (привязка) — правило, которое сообщает обменнику в какую из очередей должны попадать сообщения.

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

Мы рассмотрим приемочные (Acceptance), функциональные (Functional) и юнит-тесты или модульные тесты (Unit-Tests).