Есть такое мнение, что качество кода автотестов не так важно в сравнении с основной кодовой базой. Однако это тоже код, который приходится поддерживать с соответствующими накладными расходами. Если не следить за его качеством, то и тут могут возникать проблемы.
И у каждой ошибки есть своя цена. Было бы здорово, если бы о них можно было узнать:
на этапе локальной отладки и, соответственно, быстрее (например, запустив одну команду и получив отчёт) — движение в сторону Fail Fast и сокращения Feedback Loop;
не занимая ресурсы CI сборкой кода, который заведомо придётся исправлять, — Quality Gates;
снимая часть нагрузки с ревьюера и меньше переключая контекст специалистов;
работая с унифицированным кодом и не тратя время на обсуждение мелочей.
Это может касаться как простых ошибок, на которые не хочется тратить время специалистов, так и неочевидных ошибок, у которых иногда непросто определить причину.
Меня зовут Николай, и я инженер в мобильной платформенной команде Яндекс Еды. В этой статье я расскажу, как мы повышаем качество кода автотестов Android-приложения. И в этом нам помогает статический анализ.
Использование тест-кейсов в качестве бэклога для тест-автоматизации – очень распространенная практика. QA разрабатывают тест-кейсы на основании юзер-стори в ходе обычного тестирования, а затем автоматизируют эти тесты. В каждой последующей итерации тестируется больше стори, автоматизируется больше тест-кейсов, и набор автоматизированных тестов растет. Ведущие инженеры продвигают метрики вроде «процента автоматизированных кейсов» и поощряют добившихся высоких показателей. В некоторых командах даже нанимают специализированных «инженеров-автоматизаторов», чья единственная задача – взять тест-кейсы и автоматизировать их.
Сегодня я хочу поделиться своим опытом тестирования десктопных приложений, который может быть особенно полезен для тех, кто сталкивается с вакансиями десктопного тестировщика.
Так какие особенности сопутствуют тестированию десктопных приложений?
Автор: Мануэль Матузович (Manuel Matuzović) Оригинал статьи Перевод: Ольга Алифанова
Предупреждение: это не статья о Lighthouse, другие инструменты тестирования дадут схожий результат. Это статья про нас, разработчиков, и про то, что мы не должны бездумно полагаться на автоматизированное тестирование.
Встроенный в Google инструмент тестирования Lighthouse оценивает доступность наших сайтов по шкале от 0 до 100. Похвально иметь высокий рейтинг, однако то, что вы набрали 100, не значит, что у сайта прекрасная доступность. Чтобы это доказать, я провел небольшой эксперимент.
Всегда приятно видеть посты с высоким Lighthouse-рейтингом в социальных сетях, демонстрирующие, как здорово люди оптимизировали свой или клиентский сайт. Сразу видно, что их волнует качество того, что они сделали.
При автоматизации нагрузочных тестов специалисты рано или поздно приходят к мысли о том, как сравнивать результаты проводимых тестов. И не только сравнивать, но и демонстрировать результаты команде и бизнесу. Часто сравнение результатов нагрузочных тестов напоминает игру «найди 10 отличий» на почти одинаковых картинках. И если для специалистов в тестировании производительности это не проблема, то для коллег, не погруженных в теорию, это может стать таковой. Тут необходим какой-то простой и наглядный индикатор, который легко позволит определить — показатели стали лучше или хуже в процессе работы над проектом.
«Я разговаривал с топ-менеджерами, работающими в сотнях разных бизнесов и отраслей. Вне зависимости от национальности, продукта, сервиса или группы, никогда не разочаровываюсь. Кто-нибудь обязательно скажет «Вам надо признать, что наш бизнес – это нечто особенное». Обычно они видят только свой бизнес и поэтому никогда не осознают, насколько бизнесы похожи. Конечно, технология и методы распределения могут сильно отличаться. Но задействованные люди, их мотивация, их реакции – всегда одинаковы».
Говорят, молчание — золото, но чтобы стать хорошим тестировщиком, нужно уметь договариваться (с разработчиками, дизайнерами, продукт-менеджерами), убеждать, лавировать между оппонентами и примирять конфликтующие стороны. Словно я описываю посредника в переговорах, но сегодня не о нем речь.
Из каждого утюга сегодня звучит призыв двигаться в сторону IT. Информационные технологии — это уже не только про математику, но и про дизайн, менеджмент, аналитику и тестирование. Причём о тестировании говорят как о чём-то очень лёгком для начала карьеры. Мол, стать тестировщиком может каждый. Но стать — это одно, а стать профессионалом — совсем другое.
Эту статью я хочу посвятить непростой работе QA-инженера, которую так легко обесценивает реклама курсов по «входу в IT». При этом все хотят работать только с профессионалами, но хорошего тестировщика днём с огнём не найдёшь. Потому что тестировщик — это командный игрок, который создаёт синергию для выпуска хорошего продукта. В слаженной команде QA-инженер становится T-shaped специалистом: умеет погружаться в код, может дать дизайнеру идеи по UX и т. д. То есть социальные навыки у QA должны быть развиты не хуже технических.
Граничные случаи интересны своей незаметностью, невидимостью. Они могут быть сложными, если находятся на пересечении множества вещей и демонстрируют уникальное поведение. Они необязательно симметричны на концах или похожи на поведение в середине.
Разработчик, сконцентрированный на решении проблемы в обычных, распространенных ситуациях, может не учитывать интересные граничные значения. К примеру, мы все сделали верно для системы в нормальном состоянии, но упустили, что же будет, если система развернута впервые. Ниже перечислено восемь эвристик, обнаруженных мной при тестировании нашего сервисного ПО.
В этой статье я расскажу, как последние пятнадцать лет изменили мое понимание тестируемости. Надеюсь, по прочтении вы разделите мой энтузиазм в отношении тестируемости. Я обнаружил, что концентрация всей команды на тестируемости – один из немногих рычагов разработки ПО, способный положительно повлиять на производительность команды.
