Автор: Марина Кудрявцева, iSpring, Инженер по качеству
Стажёр-тестировщик — это новичок, у которого нет реальной практики в тестировании. Потому что одно дело решать учебные проекты, пусть даже и приближённые к боевым задачам, а другое дело — работать в большом реальном проекте, в котором много сложных бизнес-процессов.
Расскажу, с какими сложностями сталкиваются стажёры, и как мы помогаем эти сложности преодолеть и погрузиться в сложный проект.
Меня зовут Марина, я наставник и тимлид в команде тестировщиков. Когда ко мне в проект приходят стажёры-тестировщики, я их обучаю и помогаю им адаптироваться.
Уверена, что мой опыт пригодится наставникам и тимлидам, которые также вводят новых QA. Делитесь в комментариях и своим опытом.
Автор: Баз Дейкстра (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 Джеймс Бах описывал покрытие как "пропорцию протестированного продукта". Это не имело для меня смысла.
