Home

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

Автор: Евгений Иванченко

QA и QC — как камыш и рогоз. Конечно, есть ботаники, которые их различают, но большинство людей всё-таки путают. Иногда самим QA и QC легче согласиться с представлением обывателей, чем пускаться в долгие объяснения, в чём же всё-таки разница. Предлагаю сделать усилие над собой, разобраться с терминами и понятиями, увидеть отличия и больше никогда их не путать.

15-18 июня состоится онлайн-конференция по тестированию Heisenbug 2020 Piter.

Что будет:
— Десятки докладов от экспертов со всего мира о практическом и хардкорном тестировании на реальных проектах;
— Интервью, развлекательные подкасты, технические ток-шоу и дискуссии со спикерами;
— Конференция будет идти 4 дня. Чтобы участники не устали, мы разбили программу на блоки по 4-5 часов;
— Каждый день — несколько параллельных треков, между которыми можно переключаться, а доклады перематывать или ставить на паузу;
— Розыгрыши с призами от партнеров конференции;
— Обсуждение докладов с коллегами и единомышленниками.

Среди спикеров:
— Андрей Лушников, разработчик Puppeteer и участник команды разработки Playwright в Microsoft.
— Эллиот Расти Гарольд (Elliotte Rusty Harold) — мейнтейнер библиотеки Jaxen XPath, коммитер в проект Apache Maven, автор библиотеки XOM для обработки XML с помощью Java.
— Андрей Акиньшин, автор книги «Pro .NET Benchmarking» разработчик проектов BenchmarkDotNet и Rider.
— Артем Ерошенко, автор фреймворка для построения отчётов о процессе тестирования Allure.
— Адам Торнхилл (Adam Tornhill), специалист по поиску проблем в коде и борьбе с техническим долгом, создатель сервиса для анализа качества кода CodeScene.
— Анна Чернышева, Lead Software Test Automation Engineer в EPAM, эксперт в области BDD, одна из создателей Self-healing библиотеки Healenium и BDD-библиотеки Akita.

Билет со скидкой по промокоду SoftwareTesting20pc.

Автор: Саймон Найт (Simon Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Но как же вы попали в эту область системы? Каким маршрутом вы шли, что вы могли упустить по дороге?

Что, если вместо того, чтобы прямой наводкой идти к этой области, вы бы свернули в совершенно ином направлении?

Что вы могли бы найти?

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

Благо, некоторое время назад появился Docker — среда для контейнеризации софта, позволяющая легко создавать и передавать отдельные контейнеры с софтом, которые работают везде одинаково. Долгое время Docker был популярен только среди DevOps, но в последнее время он все чаще используется в тестировании.

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

Про устройство Docker и его преимущества вы можете узнать из видео:

А если вы хотите узнать больше — подписывайтесь на наш youtube-канал и приходите на курс “Docker: инструменты тестировщика”, где вы всего за 2 недели сможете научиться работать с этим инструментом на достаточном для QA уровне.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Все читатели моего блога знают, как я увлечена тестированием API. Мне также очень нравится пользоваться Postman для такого тестирования, потому что, по моему мнению, это самый простой способ проверки API-запросов. Поэтому меня печалит, когда я вижу, что люди тестируют API, убеждаясь только в том, что получили ответ 200! Сегодня я возьму простой GET-запрос и покажу пример 16 тестов, которые можно прогнать вместе с ним.

Опубликован очередной выпуск рассылки за конец апреля.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Публикуем подборку докладов с конференции Comaqa Spring 2019, посвященную карьерным и коммуникационным вопросам.

1. 1. Коммуникативная составляющая QA – Алиса Бойко (Минск).
2. 2. Способ построить карьеру в IT – Роман Сорока, ItechArt (Минск).
3. 3. Вхождение Функциональщиков в Автоматизацию – Станислав Бадов (Минск).
4. 4. Сказка о потерянном времени. QA edition – Зоя Король (Минск).

Автор: Ричард Брэдшоу (Richard Bradshaw) и Сара Дири (Sarah Deery)
Оригинал статьи
Перевод: Ольга Алифанова

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

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