Главный инженер по тестированию
Привет! Меня зовут Артем. Уже несколько лет я генерирую полезный контент в области функционального тестирования, а также являюсь создателем нескольких крупных сообществ, которые помогают начинающим тестировщикам.
На данный момент существует большое количество площадок, групп и чатов, которые помогают специалистам разного уровня в аспектах обучения, общения, взаимопомощи. У меня появилась идея собрать их вместе и поделиться с сообществом. Все ресурсы бесплатные.
Прежде чем приступить к автоматизации тестирования желательно проанализировать приложение. Чем больше приложение готово к автоматизации, тем меньше проблем будет в дальнейшем при разработке автотестов и анализе результатов.
Возвращаемся к нашему любимому вопросу - много теории, мало практики. Где тренироваться тестированию самоучке или человеку, которому не хватает практических заданий на курсах?
Привет всем, я, Надежда Дудник, главный инженер по тестированию в СБЕРе, а ещё ментор по тестированию ПО.
Как два года введу блог по тестированию, помогаю начинающим специалистам по тестированию развивать хард скиллы, дополнительно сочиняю тесты для закрепления знаний по основам тестирования и не только.
В рамках своего блога я поделилась информацией как составлять тест-кейсы по бэкенду, и захотелось также поделиться этой информацией здесь.
Хочу вам рассказать о важности написания тест-кейсов по API, а именно про стратегию составления тест-кейсов по бэку (backend), где результатом будет являться хорошо структурированный тест-кейс.
На работе я постоянно провожу ревью тестовых моделей по бэку, даю обратную связь, чтобы было качественное тестовое покрытие согласно требованиям.
Как вы знаете, что каждый тест состоит из предусловий, шагов и ожидаемых результатов.
При выполнении каждого запроса API нам необходимо и важно проверить:
Всем привет! Меня зовут Константин, и я работаю ведущим тестировщиком в дружной команде back-end компании Solit. Мои коллеги уже не раз делились различными хитростями и ноу-хау, которые они применяют в своих проектах. Я же решил пойти немного другим путём и поделиться с вами набором сервисов и утилит, которые помогают нам прийти к недостижимой цели — работа приложений без дефектов.
В мою подборку попали те приложения, которые прижились в нашей команде и ими пользуется более одного человека. Конечно, есть очевидные вещи, типа Notepad++. Но есть и более редкие «звери», типа JWT.
Ещё я постарался разбить всё на хоть сколько-то вменяемые категории. В общем, давайте переходить к делу. Надеюсь, вы найдёте для себя что-то полезное или сможете поделиться своими полезностями в комментариях.
Приложения для генерации данных
Правильная подготовка тестовых данных — уже половина успешного тестирования. В этом разделе я собрал приложения, которые помогают быстро сгенерировать большие (я бы даже сказал, очень БОЛЬШИЕ) объёмы тестовых данных.
pgCodeKeeper
Вообще, эту утилиту можно использовать для различных целей. Её основная цель — поиск различий между объектами баз данных, создание скриптов миграции и тому подобных вещей.
В нашем случае она прижилась именно как генератор тестовых данных для БД Postgres. Подробнее о том, как он работает, можно прочитать в официальной справке pgCodeKeeper.
Привет, хабр. Меня зовут Кияшева Екатерина и я руковожу тестированием. Сегодня хочу поделиться своим чит‑листом обо всем.
Чит‑лист — набор стандартных проверок для многократного использования в различных приложениях, одинаковых по какой‑либо характеристике.
Я использую чит‑лист с тремя целями: передаю его своим коллегам, чтобы маст-хэв тесты не были забыты, заглядываю в него перед проверкой тестового покрытия коллег на малознакомом проекте, проверяю себя в ходе вычитки техзадания и при тест‑дизайне.
Хочу, чтобы его было полезно и удобно использовать, поэтому буду рада предложениям и комментариям по его расширению и упрощению.
Вторая часть подборки материалов от QA для начинающих специалистов (и не только). Под катом квалификационные требования, практические пособия и классика книг по тестированию.
Ниже моя история прохождения тестирования ISQTB Foundation Level, переживания, пробы, ошибки и советы по эффективной подготовке, актуальные для 2021 года.
Часто в начале спринта у тестировщика нет задач. Ну а что, тестировать еще нечего, приходится ждать готового функционала.
Давайте рассмотрим стандартные этапы разработки новой фичи: создание дизайна, верстка, разработка, тестирование. И всё здесь так, но где-то между ними затесалось создание тестовой документации.
Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»
Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.
Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.
После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =)
За пять лет работы в «Аркадии» — компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, — мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая — с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.
Небольшие проекты у нас скорее редкость, и к ним не очень подходят стратегия и тактика тестирования, применяемые для длительных проектов. В этой статье я расскажу, как составляю стратегию тестирования в краткосрочных проектах и внедряю её на практике.
Никто не любит наступать на одни и те же грабли. Чтобы избегать их на этапе анализа и тестирования требований, мы завели общую шпаргалку. Она включает в себя те вопросы, которые в идеале должны быть выявлены и зафиксированы до разработки. Мы используем её как чек-лист, с помощью которого стараемся глубже вникнуть в логику мобильного приложения и разобраться, какие потенциальные проблемы могут возникнуть у пользователя.
Статья ориентирована на тестировщиков, которых просят провести ревью ТЗ и найти в нём несоответствия, и на аналитиков, которым разработчики после прочтения ТЗ часто задают вопросы формата: «А что должно быть, если …?».
Как подготовиться к собеседованию на вакансию QA? Как обычно, информации можно найти очень много, в этой статье постарались собрать "самый сок" знаний для того, чтобы начать развиваться в сфере тестирования.
Что такое попарное тестирование и почему оно является эффективной техникой тест-дизайна? Поговорим об этом ниже. Статья предназначена для начинающих специалистов по тестированию.