Статьи

Меня зовут Виталий Котов, я работаю в отделе тестирования компании Badoo. Я пишу много UI-автотестов, но ещё больше работаю с теми, кто занимается этим не так давно и ещё не успел наступить на все грабли.

Итак, сложив свой собственный опыт и наблюдения за другими ребятами, я решил подготовить для вас коллекцию того, «как писать тесты не стоит». Каждый пример я подкрепил подробным описанием, примерами кода и скриншотами.

Статья будет интересна начинающим авторам UI-тестов, но и старожилы в этой теме наверняка узнают что-то новое, либо просто улыбнутся, вспомнив себя «в молодости». :)

Поехали!

Картинка: источник

Привет! Меня зовут Илья Аблеев, я работаю в отделе мониторинга Badoo.

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

«Из коробки» узнавать о новых проблемах можно либо через веб-интерфейс, либо по почте/SMS. Это хорошо работает и до определённого момента нас устраивали эти способы.

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

Оптимальным решением, на наш взгляд, был бы вывод важных уведомлений поверх всех окон (браузеров, чатов, консолей). В этой статье речь пойдёт о том, как мы допилили Zabbix, научив отправлять их прямо на рабочий стол.

Кому подойдёт данное решение:

• дежурным администраторам, которые не только круглосуточно смотрят в монитор, но и занимаются решением других задач;
• всем остальным администраторам, которым не нравится просматривать простыню PROBLEM и OK`ов в почте или SMS, но которые хотят своевременно узнавать о критичных проблемах.

Придётся потратить время на установку, но, думаю, если вы используете Zabbix и уже использовали кастомные скрипты, для вас это не составит труда.

Привет! Меня зовут Катя, и я работаю тестировщиком мобильных приложений более пяти лет. Последние три года я тружусь в iOS-команде Badoo, и еженедельно мы релизим от трёх до семи новых фич, от трёх до пяти технических тасков и от пяти до 13 багфиксов. Как вы понимаете, приложение меняется с такой скоростью, что поддерживать классическую тестовую документацию (test cases) неэффективно: почти всегда она будет устаревшей.

Опытным путём мы выяснили, что чек-листы в качестве тестовой документации работают лучше, так как их проще создавать и использовать. Тем не менее иногда они могут быть запутанными и слишком подробными, особенно когда есть буквально пара часов на exploratory testing фичи, которая должна попасть в следующий релиз.

В этом случае визуализация позволяет сэкономить кучу времени, поэтому мы решили попробовать использовать mind maps (или «ментальные карты»), которые так же удобны в использовании, как чек-листы, но более наглядны за счёт визуального формата.

Сегодня мы подробненько разберём созданную мной mind map для тестирования iOS-приложения (далее именуемую «моя прелесть»), а также пройдёмся по ресурсам, которые можно использовать при построении mind map для мобильного приложения, чтобы покрыть максимальное количество важных сценариев.

Меня зовут Андрей Гоменюк, я тимлид одной из команд серверной разработки Badoo.

На майском Badoo Techleads Meetup, посвящённом управлению разработкой, я поделился опытом интеграции новичков в команду. А сегодня делюсь текстовым дополненным и улучшенным вариантом своего доклада.

Представьте, что сегодня ваш первый рабочий день в Badoo. Каких же знаний и умений ждёт от вас отдел и в частности я, руководитель? Как минимум таких:

Всем привет! Меня зовут Саша Зимин, я работаю iOS-разработчиком в лондонском офисе Badoo. В Badoo очень тесное взаимодействие с продуктовыми менеджерами, и я перенял у них привычку проверять все гипотезы, которые возникают у меня относительно продукта. Так, я начал писать сплит-тесты для своих проектов.

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