Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Совсем не весело стартовать рабочий день с открытия, что некоторые (или все) ночные автотесты упали. Это особенно бесит, когда вы выясняете, что они упали, так как кто-то поменял ваши тестовые данные.
Проблемы тестовых данных – частый источник раздражения тестировщиков. Неважно, тестируете ли вы вручную или автоматизируете – когда ваши любовно настроенные данные меняют, вы потратите время на выяснение, что не так с результатами тестов.
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
В ходе карьеры мне задавали массу вопросов о тест-архитектуре: как начать тестировать, если ничего не делалось годами? Сколько тест-проектов должно быть? Сколько различных типов тестирования нам нужно? Кто должен отвечать за тестирование в процентном соотношении? Как масштабировать тестирование? Как разобраться с большими приложениями? Как разобраться с существующими тестами, если в них черт ногу сломит? Какими инструментами пользоваться? В каком количестве браузеров надо тестировать (их что, больше двух?!)
Начнем с начала: все приложения уникальны, каждая компания имеет свою структуру, свои ресурсы и бюджет, и все компании находятся на разных стадиях зрелости (это не значит, что они должны стремиться на следующую ступень – возможно, они находятся именно там, где должны). Тут не существует универсальных решений, и поэтому я рекомендую проконсультироваться с экспертом. Но я хочу поделиться своим прошлым опытом на случай, если вам это поможет.
Автотесты — модная, но довольно затратная история. Автоматизаторы стоят дороже, чем ручные тестировщики, а сами автотесты требуют больше времени на разработку, причем разрабатывается не функционал продукта, а его проверка, которая окупается не явно и не сразу. Требует затрат и поддержка автотестов. Однако каждую из этих статей расходов можно минимизировать, сделав автотестирование намного эффективнее.
Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных X5 Retail Group. В этой статье я расскажу о нашем опыте внедрения автотестов и сокращении связанных с ними издержек. Надеюсь, эта информация окажется полезной для команд, которые сталкиваются с трудностями при переходе на автоматизированное тестирование.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Тестировать – значит рассказывать две параллельных истории: историю продукта и историю нашего тестирования. Тест-фрейминг – это ключевой навык, помогающий нам составлять, редактировать, рассказывать и обосновывать историю тестирования логично, связно и быстро. Цель тест-фрейминга – увязать все виды деятельности по тестированию с тест-миссией.
Автор: Саймон Найт (Simon Knight) Оригинал статьи Перевод: Ольга Алифанова
Если вы в тестировании не первый день, и особенно если вы долго тестируете один и тот же продукт, то вы наверняка заметили, что ваш мозг начинает мыслить о тестируемом продукте определенным устоявшимся образом.
Через какое-то время вы уже знаете, где находятся самые сложные области вашего продукта, и, начиная тестировать, вы сразу нацеливаетесь на эти области, потому что они уже показали себя плодотворной почвой для сочных багов.
Но как же вы попали в эту область системы? Каким маршрутом вы шли, что вы могли упустить по дороге?
Что, если вместо того, чтобы прямой наводкой идти к этой области, вы бы свернули в совершенно ином направлении?
Автор: Рози Шерри (Rosie Sherry) Оригинал статьи Перевод: Ольга Алифанова
Вам когда-нибудь ставили задачу распланировать ваше тестирование? Чувствовали ли вы, что что-то упустили? И вследствие этого беспокоились ли, что ПО начнет падать, и все начнут обвинять вас?
Использование этого чеклиста по планированию тестирования поможет вам справиться с волнением.
Конечно, он не универсальное решение. Он предназначен для того, чтобы помочь вам задуматься о проекте, с которым вы работаете, идентифицировать потенциальные пробелы, и, потенциально, послужить катализатором новых идей о подходе к тестированию.
Конечно, это не может и не будет всегда покрывать все, что нужно учитывать, но это шаг в правильном направлении, чтобы задуматься и проанализировать тестируемый продукт.
Автор: Кассандра Ланг (Cassandra H. Leung) Оригинал статьи Перевод: Ольга Алифанова
Это четвертая и последняя часть мини-цикла статей "Тестирование в реальной жизни", нацеленного на то, чтобы поделиться практическим опытом тестирования на основании реальных примеров. Этот цикл зародился из наблюдения, что множество ресурсов, с которыми я сталкивалась, концентрируются в основном на теории, а информации о том, как это реально делается или как к этому приступать, немного. Информация, которой я делюсь в этом мини-цикле, основана на моем недавнем опыте – я помогала в первичном тестировании мобильного приложения.
В этой статье я поговорю о том, во что еще должны быть вовлечены тестировщики, помимо поиска багов.
Гибкий подход (эджайл, agile) сегодня у всех на слуху. Все хотят быть гибкими, и – вуаля! – ваша компания уже на полпути к гибкому подходу. Зачем? Все статьи/обсуждения/слухи свидетельствуют о том, как это круто. Однако, бытует мнение, что это темная и грустная история, которую в прошлом году на конференции TestCon Moscow рассказал Антон Зотин.
С 31 марта по 2 апреля ждем вас на четвертом выпуске конференции TestCon Moscow 2020.
В данный момент у нас привлекательные цены на билеты, ну а всем читателям портала мы предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10
Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.
Интро
Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:
Недоделки. Это ошибки, которые допустили разработчики, пока пилили новый функционал. Такие ошибки находят при исследовательском или приемочном тестировании новых фич на девелоперских стендах команд.
Баги в регрессе. Это дефекты, которые находят ручные регрессионные тесты или автоматические UI и API тесты на стенде для интеграции кода.
Баги с прода. Это проблемы, которые нашли сотрудники или клиенты и обратились в службу технической поддержки.
