Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Меня часто спрашивают об идеальном соотношении разработчиков и тестировщиков. Я всегда отвечаю, что это зависит от контекста. Хорошее соотношение тестировщиков и разработчиков определяется рядом факторов. Тут надо подумать о том, работаете ли вы с последней технологией или с давно существующим продуктом, о таланте и опыте членов команды, и об ожидаемом ритме релизов. На самом деле сработать могут самые разнообразные соотношения, но у каждого есть достоинства и недостатки. Разберем несколько примеров.
Всем привет! На связи Анастасия Макеева. В Утконос Онлайн я работаю лидом автоматизации тестирования на проекте витрины. В мои обязанности входит организация и реализация автоматизированного тестирования сайта, систем и сервисов.
Свой путь в Утконосе я начинала с мануального тестирования, поэтому в этой статье хочу поделиться с вами подходом, который я применила для создания удобной структуры и информативного содержания тестовой документации.
Давным-давно… Когда мир еще знать не знал, что такое covid. Когда коллеги дружно работали в офисе. Когда ходили на встречи в переговорки, а не в Teams или Zoom. Когда обедали вместе. Я пришла работать в Утконос.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Если вы используете Cypress, то, возможно, знакомы с цепочками команд. Так ли это? Я вижу, что многие пользователи Cypress знают об этом, но иногда не улавливают их внутреннюю логику.
В этой статье я хочу разобрать ряд основополагающих принципов цепочек Cypress и то, как их понимание улучшит ваши тесты.
Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.
Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.
Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.
Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.
При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?
С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».
Пока что умение специалистов и команд выявлять и формулировать такие ограничения представляет собой скорее искусство, а не ремесло, и не инженерию.
Автор: Джеймс Бах (James Bach) Оригинал статьи Перевод: Ольга Алифанова
Этот вопрос возник в ходе недавнего онлайн-тренинга Rapid Sofware Testing Explored. Донатас сказал "Предположим, мы нашли проблему в приложении или самом процессе разработки. Однако она не получает должного, с нашей точки зрения, внимания. Как убедить остальных? Что рекомендуется для взаимодействия с разработчиками, менеджерами и продакт-оунерами в этом случае?"
Это одна из больших проблем 0в тестировании. Как тестировщик, вы находите проблемы. Однако, если ваши клиенты не согласны с вами в определении проблемы, вас не будут расценивать, как значимого члена команды. Вы станете печальным привидением, слоняющимся по чердаку.
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно, например, здесь)
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Эта история – комбинация недавнего опыта, который я просуммировал в едином рассказе. Паттерн впечатлений и откровений один и тот же, но, как говорят по телевизору, имена и детали были изменены для защиты невинных душ.
Недавно я участвовал в тестировании онлайн-магазина. В приложении есть функция, отправляющая уведомления по электронной почте.
На экране настроек этой функции для администратора в правом верхнем углу есть кнопки "Сохранить" и "Отмена". Эти кнопки не привязаны ни к каким клавишам. Пользователь должен или кликнуть на них мышкой, или перейти на них табуляцией и нажать Enter.
Автор: Марина Кудрявцева, iSpring, Инженер по качеству
Стажёр-тестировщик — это новичок, у которого нет реальной практики в тестировании. Потому что одно дело решать учебные проекты, пусть даже и приближённые к боевым задачам, а другое дело — работать в большом реальном проекте, в котором много сложных бизнес-процессов.
Расскажу, с какими сложностями сталкиваются стажёры, и как мы помогаем эти сложности преодолеть и погрузиться в сложный проект.
Меня зовут Марина, я наставник и тимлид в команде тестировщиков. Когда ко мне в проект приходят стажёры-тестировщики, я их обучаю и помогаю им адаптироваться.
Уверена, что мой опыт пригодится наставникам и тимлидам, которые также вводят новых QA. Делитесь в комментариях и своим опытом.
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
Ранее я писал статью с примерами того, как задавать данные в фича-файлах Cucumber в форме таблиц, чтобы спецификации было легче читать, и показал, как интерпретировать данные в разных табличных форматах.
В конце этой статьи я обещал написать продолжение про концепцию трансформеров таблиц данных, чтобы работать с табличными структурами данных Cucumber-JVM другим, более эффективным путем. Это заняло некоторое время, но вот это продолжение.
Я большой поклонник SpecFlow, BDD-фреймворка для .NET. Одна из наиболее симпатичных мне функций SpecFlow – это SpecFlow.Assist helpers, позволяющие быстро трансформировать таблицы из спецификаций в списки экземпляров C#-объектов, а также сравнивать списки объектов с таблицами – и все это путем одного вызова метода SpecFlow.Assist helper.
В этой статье я покажу вам, как сделать нечто похожее в Cucumber-JVM через использование трансформеров таблиц данных.
Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:
какие проверки можно объединить?
какие и вовсе выкинуть?
Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...
Автор: Кейт Полк (Kate Paulk) Оригинал статьи Перевод: Ольга Алифанова
Высшее руководство многих компаний по разработке ПО сложно убедить, что компании нужно нанять больше тестировщиков. К сожалению, ряд причин не нанимать тестировщиков заставляет всех тестировщиков (и приличное количество разработчиков) недоумевать, в какое количество мифов о тестировании верят люди, принимающие решения.
Ниже – десять распространенных и наиболее ошибочных причин не нанимать тестировщиков.
