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