Автор: Деннис Мартинез (Dennis Martinez) Оригинал статьи Перевод: Ольга Алифанова
Пересматривали ли вы когда-нибудь повторно тот код, который вы или команда написали для автотестов? Речь не о ревью этих тестов день или даже неделю спустя после их создания – я имею в виду "зарыться в архивы и проверить то, что сделано месяцы или даже годы назад". Если вы похожи на большинство разработчиков и тестировщиков, то ваша реакция будет чем-то средним между "О чем я только думал, когда писал этот код?" и "Я даже не знаю, работает ли это и используется ли вообще сейчас".
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Пока я не сделала свое собственное веб-приложение, то совсем не понимала важность продакт-оунеров. Это было совсем простенькое приложение (его можно увидеть на https://thinking-tester-contact-list.herokuapp.com), однако мне пришлось разбираться, как переходить со страницы на страницу, и как убедиться, что пользователь никогда не окажется в тупике. Это оказалось сложнее, чем я думала. Тогда я поняла, что работа продакт-оунера – это больше, чем просто дизайн страниц! Это необходимость убедиться, что пользователь получит отличный опыт, решая свои задачи в вашем приложении.
Тестировщики разделяют стремление сделать пользователей счастливыми, поэтому отличной идеей для них будет поработать с продакт-оунером для достижения этой цели! Ниже – четыре шага для такой работы.
Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:
какие проверки можно объединить?
какие и вовсе выкинуть?
Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...
Автор: Максим Буранбаев,
Этот 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, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
Написать код приложения
Собрать проект
Поднять его на сервере приложения
Сегодня я расскажу про второй этап. Сборку приложения можно проводить вручную, но есть также специальные инструменты для этого, которые называются «сборщик продукта». О них мы и поговорим.
