Автор: Панкадж Парашар (Pankaj Parashar) Оригинал статьи Перевод: Ольга Алифанова
Я провожу в DevTools много времени, как, уверен, и вы. Иногда я даже жонглирую ими, особенно при дебаге кроссбраузерных проблем. DevTools очень похожи на сами браузеры – не все инструменты конкретного браузера схожи или поддерживаются инструментами другого.
Однако ряд функций DevTools будет общим для всех – даже малоизвестные возможности, о которых я вам сейчас расскажу.
Для краткости я говорю Chromium, имея в виду все браузеры на основе Chromium (Chrome, Edge, Opera). DevTools в них, как правило, идентичны, поэтому я объединяю их в одну группу.
Всем привет! На связи снова Петрова Марина — QA Lead в Сloud.ru. Сегодня поделюсь опытом оценки и оптимизации процессов тестирования с помощью модели зрелости TMMi. Наша команда использует TMMi с третьего квартала 2022 года: за это время мы не раз оценили процессы и адаптировали модель для команд, которые работают в Agile-парадигме, но обо всем по порядку.
«В сущности, все модели неправильны, но некоторые полезны» —Джордж Бокс, британский статистик
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Cypress из коробки дает вам структуру проекта, но по мере его роста в нем появляются различные файлы, нуждающиеся в своем месте. К тому же идет вечный спор, использовать ли Page Object, а если не использовать, то где альтернатива? В этой статье я хочу поделиться своим видением создания и структурирования успешного проекта. Статья основана на моем почти семилетнем опыте создания различных проектов с Cypress.
Есть такое мнение, что качество кода автотестов не так важно в сравнении с основной кодовой базой. Однако это тоже код, который приходится поддерживать с соответствующими накладными расходами. Если не следить за его качеством, то и тут могут возникать проблемы.
И у каждой ошибки есть своя цена. Было бы здорово, если бы о них можно было узнать:
на этапе локальной отладки и, соответственно, быстрее (например, запустив одну команду и получив отчёт) — движение в сторону 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 должны быть развиты не хуже технических.
