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.
Автор: Саймон Найт (Simon Knight) Оригинал статьи Перевод: Ольга Алифанова
Если вы в тестировании не первый день, и особенно если вы долго тестируете один и тот же продукт, то вы наверняка заметили, что ваш мозг начинает мыслить о тестируемом продукте определенным устоявшимся образом.
Через какое-то время вы уже знаете, где находятся самые сложные области вашего продукта, и, начиная тестировать, вы сразу нацеливаетесь на эти области, потому что они уже показали себя плодотворной почвой для сочных багов.
Но как же вы попали в эту область системы? Каким маршрутом вы шли, что вы могли упустить по дороге?
Что, если вместо того, чтобы прямой наводкой идти к этой области, вы бы свернули в совершенно ином направлении?
Тестировщики часто сталкиваются с багами, которые зависят от окружения. Иногда приходится долго настраивать все необходимые программы, чтобы проверить какую-то функциональности или запустить автотесты. А уж переезд с одной машины на другую — вечная боль.
Благо, некоторое время назад появился Docker — среда для контейнеризации софта, позволяющая легко создавать и передавать отдельные контейнеры с софтом, которые работают везде одинаково. Долгое время Docker был популярен только среди DevOps, но в последнее время он все чаще используется в тестировании.
И действительно, ведь можно один раз настроить все нужные приложения, положить их в свои контейнеры — а потом запускать где угодно и сколько угодно раз. Это значительно сокращает время тестирования и повышает его удобство.
Про устройство Docker и его преимущества вы можете узнать из видео:
А если вы хотите узнать больше — подписывайтесь на наш youtube-канал и приходите на курс “Docker: инструменты тестировщика”, где вы всего за 2 недели сможете научиться работать с этим инструментом на достаточном для QA уровне.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Все читатели моего блога знают, как я увлечена тестированием API. Мне также очень нравится пользоваться Postman для такого тестирования, потому что, по моему мнению, это самый простой способ проверки API-запросов. Поэтому меня печалит, когда я вижу, что люди тестируют API, убеждаясь только в том, что получили ответ 200! Сегодня я возьму простой GET-запрос и покажу пример 16 тестов, которые можно прогнать вместе с ним.
Автор: Ричард Брэдшоу (Richard Bradshaw) и Сара Дири (Sarah Deery) Оригинал статьи Перевод: Ольга Алифанова
Для любых тест-методов и техник верно то, что глубокое понимание того, что это такое, когда их применять, и каковы их сильные и слабые стороны – это важнейший залог их эффективного использования. Эвристики – не исключение. Вы не можете применять чек-лист эвристических техник в любых контекстах и ожидать одинаковых результатов или решения своих проблем. Их нужно применять со знанием дела, мудро и осторожно.
Как тестировщик, вы, скорее всего, знакомы с использованием эвристик для структурированного создания тестов, генерации новых тест-идей и исследования границ системы, но слышали ли вы об эвристическом праксисе? Праксис – это то, что происходит, когда тест-теория применяется к тест-практике. Это расхождение между теорией и практикой. Теория без практики – сотрясание воздуха. Практика без теории пустой звук. Лучшие тестировщики – это те, кто знает об этом и работает внутри праксис-разрыва.
Знакомая картинка? А вы ведь постоянно сталкиваетесь с этой архитектурой — когда покупаете билет в кино онлайн, бронируете путевку на море или записываетесь к врачу.
На клиент-серверной архитектуре построены все сайты и интернет-сервисы. Также ее используют десктоп-программы, которые передают данные по интернету. Поэтому ИТ-специалисту нужно понимать, что это такое и как работает.
Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
Автор: Рози Шерри (Rosie Sherry) Оригинал статьи Перевод: Ольга Алифанова
Вам когда-нибудь ставили задачу распланировать ваше тестирование? Чувствовали ли вы, что что-то упустили? И вследствие этого беспокоились ли, что ПО начнет падать, и все начнут обвинять вас?
Использование этого чеклиста по планированию тестирования поможет вам справиться с волнением.
Конечно, он не универсальное решение. Он предназначен для того, чтобы помочь вам задуматься о проекте, с которым вы работаете, идентифицировать потенциальные пробелы, и, потенциально, послужить катализатором новых идей о подходе к тестированию.
Конечно, это не может и не будет всегда покрывать все, что нужно учитывать, но это шаг в правильном направлении, чтобы задуматься и проанализировать тестируемый продукт.
Модульное тестирование (unit testing) применяется повсеместно. Кажется, уже никто без него не обходится, все пишут тесты, а их отсутствие в сколь-нибудь серьёзном проекте вызывает, как минимум, непонимание. Однако, многие воспринимают тестирование как некий ритуал, совершаемый для того, чтобы не разгневать "бога программирования". Мол, так надо. Почему? Потому что.
Буду говорить страшные вещи.
Не важно, что брать за единицу тестирования. Не важно, как сгруппированы тесты. Не важно, пишутся ли они до кода или после. TDD или не TDD? Всё равно. Доля покрытия? Наплевать. В конце концов, тестов может совсем не быть. Всё это совершенно не важно. Важно, чтобы выполнялись требования, предъявляемые к ПО.
Модульные тесты — это не ритуал, а хороший, рабочий инструмент, позволяющий приблизиться к выполнению этих требований. И этот инструмент нужно уметь правильно использовать.
