Home

Автор: Ольга Назина (Киселёва)

В данном случае под локализацией понимается не понимается не локализация бага (поиск первопричины возникновения), а локализация ПО — перевод на разные языки.

Это когда вы можете переключать язык в интерфейсе, обычно "Рус / Eng", но бывают и многоязычные приложения! Что тестировать в таком случае?

1. Адекватность перевода — при наличии знания языков. Скорее всего, тексты лежат где-то в одном месте в коде, файлики с русскими фраза, английскими и другими языками. Можно вычитать сами файлики.
2. Пункты меню — все ли переведены?
3. Кнопки — про них часто забывают. В итоге сайт весь на английском, и большая кнопка «Купить»
4. Рисунки — про них обычно даже не думают. Переключаешь язык, а там картинка на главной с другим языком осталась...
5. Длинные фразы — часто любят вылезать за пределы области. Что в одном языке нормально влезает, в другом займет много места. Например, «Поздравляем!» и «Congratulations!». Найти такие фразы помогут файлики с переводом в коде.

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi
Оригинал статьи
Перевод: Ольга Алифанова

В Министерстве тестирования я принадлежу к очень небольшой группе. Я участвую в независимых митапах, даже если они мне не близки, я делаю доклады, если меня приглашают (но меня не приглашают), и я тихо сижу в канале exploratory-testing в их Слаке. Сегодня я вдохновилась статьей Джамала Тодда в этом канале.

Автор: Игорь Любин

Представьте себе такую ситуацию. Вы запилили мегакрутую фичу на странице сайта и через месяц решили оценить её эффективность. Начинаете считать — и понимаете, что своим релизом вы сломали метрики на странице: случайно удалили код, отправляющий важные события аналитики, или забыли покрыть новую фичу событиями. Знакомо?

События — это действия пользователей на сайте, которые можно отслеживать: клики на кнопки, переходы и просмотры страниц. Когда пользователь совершает целевое действие, в систему аналитики отправляется событие. В итоге мы получаем отчёт о поведении пользователей на конкретной странице сайта.

Если события приходят некорректно, отчёт будет недостоверным.

Тестирование всех событий продуктовой аналитики перед каждым релизом обычно отнимает много времени. В этой статье я расскажу, как автоматизировать этот процесс.

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей вы столкнетесь с выдуманным, но реалистичным сценарием использования контрактного тестирования с Pact и Pactflow.

За последние примерно десять лет архитектура программных систем перешла от монолитной к сервисно-ориентированной, а затем – к сильно распределенной и зачастую основанной на микросервисах. В прошлом команда или отдел отвечали за разработку и поставку системы целиком, а сейчас эта ответственность зачастую распределена между разными командами, работающими на разные отделы и зачастую – на разные компании.

Этот распределенный подход к разработке ПО имеет ряд существенных преимуществ, особенно в плане гибкости и масштабируемости:

• Деплой новой версии компонента или его замена на более подходящий вариант не требует деплоя системы целиком.
• Если над разными компонентами единой системы работают разные команды, разработку можно вести параллельно, что сильно ускоряет процесс.
• Если компонент должен управляться с множеством запросов, его можно масштабировать, не масштабируя остальные компоненты.

Помимо этих, есть и другие плюсы. Однако этот подход к разработке несет и проблемы, особенно в интеграции и end-to-end тестировании. Чтобы пристальнее взглянуть на эти проблемы и пути их решения, возьмем для примера приложение, состоящие из нескольких неплотно связанных компонентов.

В жизни многих разработчиков и большого количества IT-компаний настаёт момент, когда создание open source-проектов становится не менее важным, чем написание кода для внутренней разработки. По просьбе «Лаборатории Касперского» Евгений Мацюк, один из создателей open source-фреймворка для автотестов Kaspresso, делится своими рассуждениями, почему это решение оказалось полезно как для сообщества, так и для самой компании.

Что такое современный open source

Сейчас любой проект, любую свою разработку можно легко выложить в свободный доступ в онлайн-репозиторий. Самый популярный, конечно, GitHub, там крупное и активное коммьюнити из СНГ, а зарубежных пользователей ещё больше. Но есть и альтернативные платформы, их несложно найти.

Ещё до работы в «Лаборатории Касперского» я выкладывал на GitHub свои open source-проекты, например архитектурный CookBook по оформлению Android-проектов. Kaspresso мы с командой тоже выложили на GitHub.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Нельзя посидеть перед компьютером и случайно скомпилировать работающую программу, поэтому люди – интуитивно и совершенно верно – полагают, что программировать сложно. Но кто угодно может посидеть перед компьютером и наткнуться на баги, поэтому люди – интуитивно и в корне неверно – верят, что тестировать легко!

Тестировщикам, серьезно относящимся к тестированию, сложно объяснить окружающим, как это работает.

Автор: Поздняков Антон Игоревич (Инженер по автоматизированному тестированию), ООО "Хоппер ИТ"

В прошлый раз мы уже поднимали тему написания селекторов на XPath для автоматизации тестирования веб-сервисов. Сегодня мне хотелось бы поговорить о практиках работы с XPath. Этот пост будет о том, какие приемы хорошо работают, а каких вещей лучше избегать, если вы так же как и мы сделали выбор в пользу XPath. Всех заинтересованных прошу под кат, а если у вас есть свои уже проверенные временем ноу-хау, давайте делиться ими в комментариях.

Мы постоянно работаем с большими объемами тестов, и по мере роста количества заказов в команду приходят новые инженеры. Именно обучение стало поводом для размышлений над тем, что такое “хороший XPath”, а что такое “плохой XPath”. 

На первый взгляд может показаться, что в этом вопросе нет ничего сложного: просто берете общепринятый стандарт для селекторов, сверху кладете документацию по XPath и отдаете все это новому сотруднику со словами: “Знакомься товарищ!”. Но практика показала, что просто знаний синтаксиса недостаточно. И в работе встречаются как хорошие, так и плохие практики написания селекторов. Именно исходя из этого опыта и родился этот пост. А ниже вы найдете те принципы и практики, которые мы выработали сами для себя, набив несколько шишек, потратив часы лишнего времени на исправления и так далее. 

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я встречалась с коллегами, намеренными улучшить наши практики непрерывной поставки. Они размышляли над способами измерения прогресса автоматизации, и одним из первых предложений было измерение покрытия кода.

"Нет", сказала я. "Измерение покрытия кода ничем не поможет, потому что оно не говорит о том, хороши ли наши тесты – оно только показывает, что наши тесты затрагивают определенные части кода".

Следующим предложением был подсчет строк кода. "Нет", сказала я. "Это тоже не поможет. Количество страниц в книге ничего не говорит о ее качестве, а количество строк кода ничего не говорит о качестве тестов".

"ОК", сказали они. "Как насчет количества тестов? Ну уж это-то покажет наш прогресс".

"Нет, и это не поможет", ответила я. "У вас могут быть сотни тестов, и каждый из них может быть ненадежным, или тестировать не то, что нужно".

Тут они спросили "Так как же тогда выглядит ХОРОШИЙ тест?" Ответ на этот вопрос – тема этой статьи! Ниже – шесть признаков хорошего автотеста.