Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
Ранее я писал статью с примерами того, как задавать данные в фича-файлах Cucumber в форме таблиц, чтобы спецификации было легче читать, и показал, как интерпретировать данные в разных табличных форматах.
В конце этой статьи я обещал написать продолжение про концепцию трансформеров таблиц данных, чтобы работать с табличными структурами данных Cucumber-JVM другим, более эффективным путем. Это заняло некоторое время, но вот это продолжение.
Я большой поклонник SpecFlow, BDD-фреймворка для .NET. Одна из наиболее симпатичных мне функций SpecFlow – это SpecFlow.Assist helpers, позволяющие быстро трансформировать таблицы из спецификаций в списки экземпляров C#-объектов, а также сравнивать списки объектов с таблицами – и все это путем одного вызова метода SpecFlow.Assist helper.
В этой статье я покажу вам, как сделать нечто похожее в Cucumber-JVM через использование трансформеров таблиц данных.
Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:
какие проверки можно объединить?
какие и вовсе выкинуть?
Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...
Автор: Кейт Полк (Kate Paulk) Оригинал статьи Перевод: Ольга Алифанова
Высшее руководство многих компаний по разработке ПО сложно убедить, что компании нужно нанять больше тестировщиков. К сожалению, ряд причин не нанимать тестировщиков заставляет всех тестировщиков (и приличное количество разработчиков) недоумевать, в какое количество мифов о тестировании верят люди, принимающие решения.
Ниже – десять распространенных и наиболее ошибочных причин не нанимать тестировщиков.
При приёмке задач мы уделяем большое внимание проверке клиент-серверного взаимодействия. Опыт проведения собеседований показывает, что новички в тестировании мобильных приложений ограничиваются интерфейсными проверками, упуская из виду то, что за каждым изменением интерфейса стоит отправка запроса к серверу и получение ответа от него. Здесь и возникает пространство для ошибок.
Если повезло, то кандидат знает о необходимости проверки сетевого взаимодействия, но, за редким исключением, его знания ограничены Rewrite или Breakpoints.
Сегодня я расскажу, с какими задачами сталкиваются тестировщики мобильных приложений и как в этом помогает Charles Proxy.
Автор: Теодор Жеррад (Theodore Gerrad) Оригинал статьи Перевод: Ольга Алифанова
Если вы интересуетесь тест-автоматизацией, то в какой-то момент зададитесь одним (или всеми) из следующих вопросов – что такое Page Object Model (POM)? Важна ли тест-автоматизация? Надо ли этому учиться? Сколько времени это обучение займет? Если вы похожи на меня – а вы, скорее всего, похожи – то вы впадете в панику, быстро и последовательно спрашивая себя обо всем этом. Хоть я и не эксперт (пока что), я могу предложить свой взгляд на эту проблему. Хоть я и не могу явно ответить на все эти вопросы, я хотел бы поделиться рядом мыслей в этой статье.
Меня зовут Георгий Костуров, я лид фронта в одной из команд СберМаркета. Хочу рассказать про виды тестов и рассмотреть несколько подходов к тестированию. В основном здесь примеры из frontend, но идеи подойдут и для backend. В статье нет конкретных примеров кода (хотя присутствуют ссылки на материалы, где они есть), но изложены идеи и общие правила написания тестов.
Автор: Марсель Гелен (Marcel Gehlen) Оригинал статьи Перевод: Ольга Алифанова
Недавно я проводил воркшоп об исследовательском тестировании. Более того, коллеги хотят использовать сессионное тестирование в другом проекте, но пока что у них маловато опыта такой работы. Одна из тем, о которой обе группы хотели узнать больше – это генерация тест-чартеров. Как найти миссии, которые нужно исследовать в ходе тест-сессии?
Краткий ответ – "концентрируйтесь на предполагаемых рисках в вашем ПО и на неотвеченных вопросах". Однако само по себе это предложение не очень-то кому поможет, поэтому я осбрал список источников, которые могут помочь с поиском интересных тест-областей и чартеров. Они также хороши для вычисления предполагаемых рисков.
Группируя эти источники, я обнаружил полезную мнемонику – CDMET.
Привет, я Black из Scalable, QA Lead в команде бэкенда по разработке биржевого ядра. Так как уже долгое время занимаюсь развитием высоконагруженной платформы, решил написать о том, как нам удалось поставить QA-процесс с 20 000 тест-кейсов, создать гибкую инфраструктуру для автоматизированного тестирования в нескольких типах API, включая асинхронные бинарные протоколы, и пройти путь разработки от отладочных утилит до специализированных тестовых фреймворков для интеграционного и компонентного тестирования.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Много лет назад я выступил с миссией.
Покрытие, казалось, было важным словом в тестировании, но я начал осознавать, что думал о нем как-то туманно, попросту. Я чувствовал, что я в этом не одинок.
Я хотел знать, что люди имеют в виду, говоря о покрытии. Я хотел знать, что я имею в виду, говоря о покрытии.
В материалах курса Rapid Software Testing Джеймс Бах описывал покрытие как "пропорцию протестированного продукта". Это не имело для меня смысла.
Для всех, кто соскучился по живому общению, команда организаторов Heisenbug сделала отдельный офлайн-день. На нем вас ждут доклады, дискуссионные зоны (вживую, а не в видеочате), партнерские стенды с докладами и мерчем и вечеринка для участников.
— «Assert, как много в этом слове...»Посмотрим, как современные инструменты позволяют писать тесты так, чтобы их падение было проще анализировать, а сами тесты было проще поддерживать.
Также в программе будет BoF-сессия «Способы улучшения качества в условиях постоянного сокращения Time To Market».Обсудим актуальную проблему на многих продуктовых проектах: использование shift-left testing и автоматизацию процессов QA. Будет актуально для QA-менеджеров, тимлидов и продукт-менеджеров.
Место проведения:Санкт-Петербург, Park Inn by Radisson Pulkovskaya.
Дата: 21 июня.
Вместе с билетом на офлайн-день вы получите доступ к записям более чем 30 докладов и других активностей с онлайн-части конференции. Подробности и билеты вы можете найтипо ссылке.
Если покупаете билет за свой счет (а не за счет компании), то воспользуйтесь промокодом softwaretesting2022JRGpc для получения скидки. Промокод работает только для билетов категории «для частных лиц».
