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