Автор: Ирина Иванова, старший инженер по тестированию в образовательной платформе Учи.ру. Оригинальная публикация
Привет! Меня зовут Ирина Иванова, я работаю QA-инженером в команде разработки внутренних проектов в Учи.ру. Мы занимаемся такими сервисами, как виджет поддержки, личный кабинет сотрудников пользовательской поддержки, карьерный сайт и так далее.
Все проекты разные, у них разные задачи. И трудности, с которыми приходилось сталкиваться во время работы над ними, тоже были разными. Но одной из повторяющихся проблем стало застревание фич на этапе контроля качества, неравномерная нагрузка на инженера по тестированию и, как следствие, замедление скорости релизов. Ниже я расскажу, какое мы нашли решение.
Меня зовут Андрей Ахметов, я ведущий инженер и тестировщик системы ЕСПП в ООО «РСХБ-Интех», технологической дочке Россельхозбанка. Сегодня расскажу вам шесть небольших историй о том, какие экзотические баги бывают и как их устранять.
ЕСПП (единая система приема платежей) — мидл‑решение, расположенное в центре хитросплетений систем РСХБ. Подробнее о том, что это за система и с какими сервисами она взаимодействует можно почитать в отдельном материале на Хабре. Добавлю лишь, что за последние годы она нам стала практически родной.
Для тестирования ЕСПП мы используем широкий набор инструментов, начиная с привычного всем Postman и заканчивая самописным ПО, созданным для конкретных задач. В процессе работы мы ловим самые разные баги. Некоторые из них удостоились упоминания в этом материале.
Автор: Панкадж Парашар (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 отличий» на почти одинаковых картинках. И если для специалистов в тестировании производительности это не проблема, то для коллег, не погруженных в теорию, это может стать таковой. Тут необходим какой-то простой и наглядный индикатор, который легко позволит определить — показатели стали лучше или хуже в процессе работы над проектом.
