Меня зовут Владислав Романенко, я Senior iOS QA Engineer в Badoo и Bumble. Мы регулярно внедряем новые фичи в приложения, и автоматизация тестирования — один из способов не пропустить баги. Фактически автотесты входят в жизненный цикл всех частей наших приложений: бэкенда, сервисов, фронтенда и мобильных клиентов. Чем раньше мы обнаружим ошибку, тем дешевле будет её исправить.
Сегодня я расскажу об автоматизации тестирования в iOS, потому что на протяжении всей своей карьеры в Badoo я плотно занимался тестированием наших нативных iOS-приложений, которые написаны на Objective-C и Swift. Хотя кое-где я буду упоминать характерные для iOS инструменты и термины (например, XCTest), общие принципы и подходы универсальны. Так что, даже если в вашем проекте используется совсем другой стек, статья будет вам полезна.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Повсеместно распространено убеждение, что "предотвращение проблем на ранней стадии процесса разработки ПО приведет к продуктам более высокого качества, нежели тестирование на более поздних стадиях". Это не так.
Это неправда, но не по той причине, которая может прийти в голову большинству. Проблема не в том, что ранний поиск проблем – плохая идея. Обычно это действительно отличная идея.
Проблема в том, что утверждение бессвязно. Тестирование само по себе, неважно, рано или поздно выполненное, вообще не приводит к продуктам более высокого качества.
Предотвращение проблем, улучшение продукта и тестирование – это разные процессы внутри цикла разработки. Эти виды деятельности связаны друг с другом, но тестирование не может ни предотвращать проблемы, ни улучшать продукт. Помимо тестирования, должно произойти что-то еще.
Исходящее от меня, учителя и адвоката грамотного тестирования, это утверждение может показаться безумным, но это истина: тестирование не улучшает продукт.
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
Написать код приложения
Собрать проект
Поднять его на сервере приложения
Сегодня я расскажу про второй этап. Сборку приложения можно проводить вручную, но есть также специальные инструменты для этого, которые называются «сборщик продукта». О них мы и поговорим.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Каждый пытавшийся заняться своим здоровьем знает, что здоровье начинается со здоровых привычек: уход за зубами, регулярный спорт, здоровая диета, и так далее. Быстрые решения вроде таблеток для похудения и вялой пробежки вокруг квартала улучшают ситуацию на время, но на получение долгоиграющих результатов работают только здоровые привычки.
Недавно я осознала, что то же самое верно и для качества ПО! Недостаточно хвастать новенькой системой управления кейсами или внедрять последний тест-фреймворк: настоящее качество ПО – это результат здоровых тест-привычек! Ниже – шесть здоровых тест-привычек, которые стоит внедрить в вашей команде.
В данном случае под локализацией понимается не понимается не локализация бага (поиск первопричины возникновения), а локализация ПО — перевод на разные языки.
Это когда вы можете переключать язык в интерфейсе, обычно "Рус / Eng", но бывают и многоязычные приложения! Что тестировать в таком случае?
Адекватность перевода — при наличии знания языков. Скорее всего, тексты лежат где-то в одном месте в коде, файлики с русскими фраза, английскими и другими языками. Можно вычитать сами файлики.
Пункты меню — все ли переведены?
Кнопки — про них часто забывают. В итоге сайт весь на английском, и большая кнопка «Купить»
Рисунки — про них обычно даже не думают. Переключаешь язык, а там картинка на главной с другим языком осталась...
Длинные фразы — часто любят вылезать за пределы области. Что в одном языке нормально влезает, в другом займет много места. Например, «Поздравляем!» и «Congratulations!». Найти такие фразы помогут файлики с переводом в коде.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Нельзя посидеть перед компьютером и случайно скомпилировать работающую программу, поэтому люди – интуитивно и совершенно верно – полагают, что программировать сложно. Но кто угодно может посидеть перед компьютером и наткнуться на баги, поэтому люди – интуитивно и в корне неверно – верят, что тестировать легко!
Тестировщикам, серьезно относящимся к тестированию, сложно объяснить окружающим, как это работает.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Недавно я встречалась с коллегами, намеренными улучшить наши практики непрерывной поставки. Они размышляли над способами измерения прогресса автоматизации, и одним из первых предложений было измерение покрытия кода.
"Нет", сказала я. "Измерение покрытия кода ничем не поможет, потому что оно не говорит о том, хороши ли наши тесты – оно только показывает, что наши тесты затрагивают определенные части кода".
Следующим предложением был подсчет строк кода. "Нет", сказала я. "Это тоже не поможет. Количество страниц в книге ничего не говорит о ее качестве, а количество строк кода ничего не говорит о качестве тестов".
"ОК", сказали они. "Как насчет количества тестов? Ну уж это-то покажет наш прогресс".
"Нет, и это не поможет", ответила я. "У вас могут быть сотни тестов, и каждый из них может быть ненадежным, или тестировать не то, что нужно".
Тут они спросили "Так как же тогда выглядит ХОРОШИЙ тест?" Ответ на этот вопрос – тема этой статьи! Ниже – шесть признаков хорошего автотеста.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Web-доступность означает простоту использования сайта и его понимания людьми, имеющими визуальные, аудиальные, физические или когнитивные особенности. Знаете ли вы, что существуют специальные гайдлайны доступности для сайтов? Эти гайдлайны называются "Гайдлайны доступности веб-контента", или WCAG. Они были созданы Web Accessibility Initiative, частью Консорциума World Wide Web (W3C). Эти гайдлайны можно увидеть в этом кратком руководстве.