Тестирование — одна из важнейших частей разработки качественных программных продуктов. Сегодня мы поговорим о некоторых методологиях и библиотеках, разработанных и используемых нашей командой для написания тестов Android приложений.
Начнем с самых базовых вещей, потому более опытные разработчики могут перейти сразу к разделу об инструментах для UI тестирования. Для тех, кому хочется узнать или освежить базовые вещи — приятного чтения.
Сколько открытых багов у вас в бэклоге? 100? 1000?
А сколько времени они там лежат? Неделю? Месяц? Годы?
А почему так происходит? Нет времени? Надо делать более приоритетные задачи? «Вот сейчас все срочные фичи реализуем, а потом точно будет время на разгребание багов»?
… Некоторые используют Zero Bug Policy, у кого-то хорошо развита культура работы с багами (своевременно актуализируют бэклог, пересматривают ошибки при изменении функциональности и т.д.), а кто-то выращивает волшебников, которые пишут вообще без багов (маловероятно, но, может, и такое бывает).
Сегодня я расскажу вам про наше решение по чистке бэклога багов — проект «Багодельня».
Представьте, что у вас есть всего один тест с использованием Selenium. Что может сделать его нестабильным? Как его ускорить? Теперь представьте, что тестов стало два. Теперь представьте сотню. Как заставить быстро отработать такую кучу тестов? Что произойдет, если количество тестов продолжит расти?
В этой статье Саймон Стюарт проведет нас по нелегкому пути масштабирования, от одного теста до параллельно исполняющихся сотен тестов. Мы познакомимся и с проблемами, которые при этом появляются, и с практическими методами решения этих проблем. Будет код на Java и некоторые мысли о развитии тестовой инфраструктуры.
Прототипом этой статьи является доклад Саймона Стюарта на Heisenbug 2017 Moscow. Саймон — создатель WebDriver, технологии, которой сейчас почти 11 лет. Он стал руководителем проекта Selenium около 9 лет назад. В Google занимался масштабированием Selenium, от нескольких десятков тысяч до нескольких миллионов тестов каждый день, на их инфраструктуре. Затем перешел в Facebook. В данный момент занимается разработкой спецификации WebDriver для W3C, которая входит в группу тестирования и тулинга в W3C. Можно сказать, что на основе WebDriver и создается стандарт.
“Нам есть, что рассказать миру о белорусском DevOps,”– говорили они. “Инфраструктура тестирования меняется и скоро произойдет перелом. Нам нужна площадка для общения с правильными практиками,” – говорили они. Они говорили – они сделали Delex. А еще 300+ человек пришли, чтобы послушать доклады, познакомиться и стать свидетелями рождения нового технологического комьюнити. Были там и EPAMеры: состояли в программном комитете, читали доклады и представляли новые разработки.
В этой серии статей я хочу описать наш опыт создания полностью автоматизированной стратегии тестирования (без QA) веб приложения Nielsen Marketing Cloud, которую мы создавали последние несколько лет.
Читать полностью »
Здравствуйте, меня зовут Дмитрий Карловский и у меня, к сожалению, нет времени писать большую статью, но очень хочется поделиться некоторыми идеями. Поэтому позвольте потестировать на вас небольшую заметку о программировании. Речь сегодня пойдёт об автоматическом тестировании:
Всем привет! Друзья, приглашаем вас в субботу, 17 марта, в офис Mail.Ru Group на очередную встречу Moscow Software Testing Club. Как и всегда, участники будут обмениваться опытом и обсуждать рабочие кейсы в неформальной обстановке. Программа встречи под катом.
Читать полностью »
Коротко о событии
Конференция: Heisenbug 2017 Moscow
Дата: 8-9 декабря 2017 года
Бесплатная трансляция (только первый зал): страница трансляции на официальном сайте.
Какой самый частый вопрос в комментариях на Хабре? «Будет ли запись?» Сразу возьмём быка за рога: запись будет, как всегда, через 3-4 месяца. Но из тех, кто задавал вопрос, смотреть её будет едва ли половина.
Чтобы понять, почему так происходит, нужно разобраться — как мы смотрим видео с конференций, зачем это вообще нужно?
ftest — библиотека, упрощающая тестирование. Имеет плавучий дизайн, что уменьшает количество строк кода. Использует t.Helper() чтобы во время сбоя теста вместо кучи сообщений выводить лишь одну актуальную строку, где тест не прошел
ftest/fclient — Помощник при тестировании http приложений, основанный на ftest.
Читать полностью »
Как правило, профилировщики памяти начинают использовать тогда, когда приложение уже гарантированно «течёт», пользователи активно шлют письма, пестрящие скриншотами диспетчера задач и нужно потратить уйму времени на профилирование и поиск причины. Наконец, когда разработчики обнаруживают и устраняют утечку, выпускают новую прекрасную версию приложения, лишенную прежних недостатков, есть риск, что через некоторое время утечка вернется, ведь приложение растет, а разработчики все также могут допускать ошибки.
Автоматизированное регрессионное тестирование ошибок уже давно стало мейнстримом индустрии разработки качественного ПО. Такие тесты помогают не допустить попадание ошибки к пользователю, а также по горячим следам разобраться, какое изменение в коде привело к ошибке, тем самым минимизировав время ее исправления.
Почему бы нам не применить такой же подход к утечкам памяти?
