Во второй части интервью для компании «Точка качества» Адам Найт рассказывает о применении исследовательского тестирования и автоматизированных регрессионных проверок при работе с большими объемами данных.
Напомним, Адам Найт – профессиональный тестировщик и активный участник различных профессиональных сообществ. Адам ведет свой блог a-sisyphean-task.com и часто выступает на таких мероприятиях как Agile Testing Days, UKTMF, STC Meetups и EUROStar.
Если вы пропустили первую часть интервью, вы можете найти ее
здесь.
Продолжим нашу беседу, Адам. Вы являетесь сторонником проведения исследовательского тестирования при работе с big data. Почему вы считаете важным проводить такого рода тестирование?
Я бы не сказал, что исследовательское тестирование – это нечто важное само по себе. Скорее, это наиболее эффективный способ тестирования систем бизнес-аналитики, с которыми я работаю.
При тестировании таких систем я стараюсь придерживаться следующего подхода:
- Сначала проводится ручная оценка продукта или разработанной функциональности.
- Вместе с тем проводится автоматизация проверок поведения, которое считается важным для получения релевантной оценки.
- Если проверки выявляют отклонения от планируемого поведения, проверка проводится повторно.
- Если вам становится известно об изменениях продукта, которые ставят под сомнение объективность проведенной оценки, проверка проводится повторно.
Главная ценность исследовательского подхода состоит в том, что он позволяет специалисту оперативно проанализировать продукт на начальном этапе. Но, что еще важнее, тестировщик получает возможность быстро среагировать на обнаруженные отклонения в поведении системы и ранее неизвестные риски.
Сочетание исследовательского тестирования и автоматизированных регрессионных проверок – это эффективный инструмент для тестирования не только систем с большими объемами данных, но и других видов программного обеспечения.
Расскажите об особенностях проведения исследовательского тестирования.
Интересный вопрос. Характерной чертой исследовательского тестирования является необходимость постоянного обучения при его проведении. На мой взгляд, именно это делает данный тип тестирования эффективным.
Для всех исследовательских тестов характерно то, что они направляют работу тестировщика в проблемную область, тем самым позволяя получить максимальную отдачу от выполнения тестов за выделенное на проект время.
Как тестировщику найти верный баланс между исследовательским и сценарным тестированием?
К сожалению, выбор наиболее подходящего подхода не всегда зависит от тестировщика. Я уверен в том, что команды и отдельные специалисты вправе сами выбирать эффективные методы тестирования. Однако во многих организациях принято диктовать условия сверху. Многие тестировщики, которые работают в таких компаниях, проводят исследовательское тестирование в дополнение к своим рабочим обязанностям.
Тем специалистам, которые все же имеют право голоса при выборе тестового подхода, я советую экспериментировать и проводить повторные проверки. Проведение исследований и детального изучения продукта поможет найти баланс между исследовательским и сценарным, ручным и автоматизированным тестированием.
Какие основные трудности при тестировании систем с Big Data?
Главной трудностью, с которой я столкнулся за все время работы с аналитическими системами, стало отсутствие единого определения термина «Big Data». Оказалось, что границы данного понятия очень размыты.
Наиболее точное определение указывало на то, что термин «большие данные» относится к информации, которую невозможно эффективно обработать традиционными способами из-за ее масштабов.
Исходя из данного определения, можно предположить, в чем будут заключаться основные сложности тестирования таких данных: многие проблемы, которые можно решить с использованием технологий Big Data, проявляют себя при тестировании таких технологий.
Проблемы в виде нехватки места для архивации тестовых данных или невозможности управления данными с одного сервера оказывают такое же влияние на процесс тестирования, как и на систему производственных данных. Обычно специалисты, отвечающие за тестирование систем данных, не имеют доступа к управлению емкостью системы или времени на проведение тестирования на производственной платформе.
Некоторые из систем, над которыми я работал, использовали 8 высококачественных серверов. Все они работали на износ в течение шести месяцев, чтобы обработать все полученные данные и достичь производственных мощностей.
На проведение тестирования таких систем короткими agile-спринтами у нас не хватало времени. Поэтому в таких случаях мы подробно изучали все аспекты работы системы, уделяя особенное внимание механизмам масштабируемости.
Любая система, призванная решить проблему обработки больших объемов информации, имеет свойство увеличиваться. Если вы можете понять, как при этом происходит разрастание всех ее уровней (будь то базы метаданных, параметры или файловые структуры), тогда вы можете быть уверены и в правильной работе каждого уровня. Это избавит вас от необходимости каждый раз тестировать систему целиком с загрузкой всех мощностей.
Подытоживая, отмечу, что тестирование больших данных требует от тестировщика понимания работы системы и точности в проведении тестовых сценариев. Грубый подход к тестированию производительности и масштабируемости едва ли приведет к желаемым результатам.
