Текст предоставлен JUG.RU Group – организаторами конференции по тестированию Гейзенбаг. Ближайшая конференция Гейзенбаг 2017 Moscow состоится в декабре в Москве. Подробности: https://heisenbug-moscow.ru/
При тестировании распределенных систем нефункциональные требования выходят на первое место, а для обнаружения сложных дефектов приходится применять специальные методы. Мы уже говорили о них с Андреем Сатариным в предыдущем интервью и сегодня попытаемся развить эту тему.
Андрей Сатарин занимается тестированием распределенных систем в Яндексе. Принимал участие в совершенно разных проектах: тестировал игру в Mail.ru, систему облачного детектирования в Лаборатории Касперского, а также систему расчета валютных цен в Deutsche Bank.
— Отказоустойчивость — одно из важнейших нефункциональных требований к распределенным системам. Как проводится тестирование отказоустойчивости?
Андрей Сатарин: Сбои можно эмулировать в тестовой среде, так работает известный инструмент Jepsen, созданный Кайлом Кингсбери (Kyle Kingsbury). Второй подход предполагает внедрение сбоев в продуктивном окружении и обычно ассоциируется с Chaos Monkey компании Netflix, из которого выросло целое движение — хаос-инжиниринг. Он избавляет нас от проблем с повторением продуктовой среды и дает высокую уверенность в работоспособности системы, но более опасен и требует определенной зрелости продукта.
Есть и третий подход, позволяющий проверить работоспособность алгоритмов еще до написания кода с помощью специальных инструментов, таких, например, как TLA+. Два наиболее известных примера его использования: разработка Amazon Web Services и Azure Cosmos DB.
Советы от QA-менеджера Crytek по тестированию игр, которые требуют регулярного обновления.
Чем дольше живёт проект — тем критичнее случайные баги. Внезапно появившиеся ошибки могут оттолкнуть значительную часть аудитории. QA-менеджер Crytek Евгений Скачков поделился на конференции Games Gathering 2016 опытом контроля качества проекта Warface, разработанного киевским филиалом компании.
Warface — онлайн free-to-play-шутер. Практически пять лет игра находится на стадии оперирования и больше восьми лет — в разработке. Это самый большой free-to-play-шутер на территории СНГ. Три года назад мы поставили официально зарегистрированный рекорд Гиннесса — 145 тысяч пользователей в онлайне на одном сервере.
Если посчитать по всем территориям, PCU (peak concurrent users) больше — около 200 тысяч человек. Ежедневно в игру заходят около 700 тысяч уникальных пользователей. Каждый год мы выдаём около 12 крупных обновлений.
Как происходит разработка обычного, «коробочного» продукта? Программисты и дизайнеры что-то создают, придумывают креативы, прототипируют и в какой-то момент решают, что игра готова. Её нужно протестировать. Что-то они проверяют своими силами, но этого недостаточно. Собираются QA-команды, и начинается «zerg rush».
Вы встречались с ошибками, которые возникают время от времени в продакшне, но никак не воспроизводятся локально? Бывает, изучаешь такой баг и вдруг понимаешь, что он проявляется только при одновременном параллельном выполнении скриптов. Изучив код, понимаешь как это исправить, чтобы такого больше не повторялось. Но на такое исправление хорошо бы написать тест…
В статье я расскажу о своем подходе к тестированию таких ситуаций. А также приведу несколько наглядных (и наверное даже классических) примеров багов, которые удобно протестировать с помощью этого подхода. Все примеры багов живые — то, что встречается в работе.
Забегая вперед сразу скажу, что в конце статьи будет ссылка на github, куда я выложил готовое решение, позволяющее тестировать параллельные консольные процессы легко и просто.
Пример номер один. Параллельное добавление одного и того же
Задача. У нас есть приложение с базой данных (PostgreSQL) и нам надо наладить импорт данных из сторонней системы. Допустим, есть таблица account (id, name) и связи идентификаторов с внешней системой в таблице account_import (id, external_id). Давайте набросаем простой механизм приема сообщений.
При приеме сообщения будем сперва проверять — есть ли такие записи у нас в базе. Если есть, то будем обновлять имеющиеся. Если нет, то будем добавлять в базу.
Как часто заказчики ПО хотят, чтобы их детище работало у любого пользователя, в любых условиях и окружениях? Здесь будет уместен ответ — всегда. Что же скрывается за этой фразой? Что именно требуется для проверки от тестировщика? И как он будет воплощать требования в жизнь? Не секрет, что WEB-приложения имеют отличия от десктопных. Самое главное отличие и опасение — это то, что мы не знаем, в каком браузере и уж тем более — в какой версии этого браузера откроет приложение наш пользователь.
Исследовательское тестирование – прекрасная идея, позволяющая нам использовать свободу нашего выбора, тестируя, учиться на ходу и позволить этому обучению влиять на выбор, который мы совершаем. Система, которую мы тестируем – это наше "внешнее" воображение, и наша задача – дать ему шанс прошептать нам всю нужную информацию.
Когда мы тестируем, мы можем растягивать свои рамки исследования – хоть немного, да можем. Даже наиболее ориентированная на тест-кейсы организация попросит вас поразмыслить, поучиться, посмотреть вокруг, запуская тесты. Именно это делает вас хорошим тестировщиком.
Чтобы еще растянуть эти рамки, эти организации позволяют пару часов потестировать свободным поиском, чтобы найти баги, которые не покрыты вашими обычными тест-кейсами и которые вы в норме даже не заметите.
Другие – например, я – занимаются исследовательским тестированием постоянно. В этом режиме тест-кейсы (если они вообще существуют) – это результат процесса, а не его исходная точка, и они создаются, когда мы знаем о фиче или продукте максимально много. Мы многому научаемся, когда завершаем тестирование.
Вне зависимости от того, используете ли вы исследовательское тестирование как технику (расширяя ваши кейсы), как задачу (отводите время на свободный поиск) или как подход (влияющий на то, как вы воспринимаете тестирование), всем вам очень нужен важный навый самоуправления. Вы хотите исследовать, имея в голове четкую цель, следить за тем, что вы узнаете, чему учитесь, и чему еще нужно научиться. Все это будет последовательно нарастать, когда вы начнете тестировать этим способом.
Несколько месяцев назад я собеседовал кандидата на должность тестировщика и спросил про его имеющийся опыт. Ответ кандидата прозвучал в духе "ну, это, конечно, ни о чем, но я участвовал в бета-тестировании видеоигр". Неделей позже я наткнулся на дискуссию в Slack-чате Ministry of Testing, где народ обсуждал, кто как попал в тестирование. Несколько человек упомянули, что считают очень полезным начинать с тестирования игр, но, по их мнению, тестировщиков игр зачастую презирают. Это побудило меня подключиться к обсуждению и поделиться своей историей, потому что я обожаю игры! На самом деле именно эта страсть определила мою карьеру после университета.
Как я уже говорил, тестировать игры трудно, и я также упоминал, что создал игру для собеседования тестировщиков. Думаете, я много внимания уделяю умению мыслить как игрок? Именно так. Это связано с тем, что, исходя из моего опыта, люди, мыслящие как игроки – это самые лучшие тестировщики. Об этом я и хочу поговорить.
Начну с того, что я не имею в виду игроков как таковых – я говорю о тех, кто, играя в игры, размышляет о них не только на уровне базовой механики.
В общем-то, тестирование игр не особо отличается по сложности от тестирования других приложений. Сложности иногда возникают при попытке определить, как протестировать их наилучшим образом, учитывая типичное для игр богатство интерфейсов и способов взаимодействия. Что еще тяжелее, так это локализация специфических (и довольно странных) багов, с которыми в них сталкиваешься. Недавно я обнаружил именно такой баг, тестируя популярную игру.
В свободное время я иногда работаю на игровые компании. Недавно я столкнулся с довольно-таки любопытным багом, тестируя игру Star Wars: The Old Republic. Баг я нашел чисто случайно – я не искал его прицельно, и даже не пытался найти что-то на него похожее. Когда баг был найден, было абсолютно неясно, что же конкретно тут происходит. Правда, знакомая история? Однако тут были свои нюансы.
Если вы не в курсе, то Star Wars: The Old Republic (SWTOR) – это массовая многопользовательская онлайн-игра (MMO), в которой вы создаете себе персонажа и исследуете вселенную Звездных Войн, выполняя квесты. Квесты, как правило, выглядят как видео-врезки, в течение которых ваш персонаж болтает с нейтральными персонажами (NPC). После завершения врезки вы отправляетесь выполнять полученное задание.
Как и в других ММО, вам придется сражаться с группами персонажей ("мобами") и в случае победы вы сможете подобрать "лут", который может содержать экипировку (броню, ботинки, перчатки, шлемы, и так далее) и другие ценности. Некоторые из них – например, броню и оружие – персонаж может надеть на себя. К тому же у вашего персонажа есть компаньон – контролируемый игрой соратник, который сопровождает вас в ваших приключениях и помогает в боях. Компаньона тоже можно одевать, передавая ему найденные на поле боя вещи.
Все программы, которые мы тестируем, работают с информацией. Когда одна и та же информация хранится в разных местах, то это вызывает проблемы при работе — неясно, где самая актуальная информация; при изменении надо найти все копии и синхронно их изменить; сложно разделять права доступа. Это является источником потенциальных проблем.
Во вводной лекции курса "SQL для тестировщиков" мы рассказываем, как реляционные базы данных помогли решить эти проблемы и заняли лидирующее положение в области хранения данных. Банки, страховые компании, интернет магазины используют реляционные базы данных в своих приложениях.
Чтобы не пропустить ошибок при тестировании программ, работающих с базами данных, нужно учитывать их особенности. Лекция знакомит вас с основами реляционных баз данных — объясняет структуру хранения информации, принципы связей между данными и существующие ограничения.
Запись доклада Алексея Петрова на онлайн-конференции Fun ConfeT&QA.
Тестирование, как правило, начинают тогда, когда в трекере Вам пришел тикет на тестирование, а разработчики залили нужный код на тестовую площадку. В дополнение ситуация приправляется жесткими делайнами и горящими сроками, тестировщик рвет на себе волосы и пытается успеть все и везде..
Меня такой подход не устроил достаточно давно и я начал использовать процедуру тестирования документации, как превентивный способ раннего обнаружения потенциальных ошибок. Данная практика предполагает, что к тестированию Вы приступаете еще до момента разработки, эдакий упрощенный TDD руками тестировщиков. Тестировщик может не только указать на явные логические ошибки в постановке задачи, отметить функциональные пробелы в ТЗ или сообщить об угрозах реализации в контексте проекта, но и составить первичный тест-план или даже чек-лист проверок по данной задаче! При чем сделает он это задолго до написания первой строчки кода разработчиком, тем самым принеся не только качественный и временной профит, но и солидную денежную экономию, ведь, указав на ошибки до их появления и сопродив задачу списком предстоящих проверок, Вы тем самым сокращаете трудозатраты разработчика на решение данной задачи.
В своем докладе я расскажу о тестировании документации, а именно:
что это такое
зачем это нужно
кому это нужно
как внедрить это
перспективы его использования
Мой доклад будет содержать не только абстракции и размышления на тему, но и реальные случаи применения тестирования документации из жизни.
Оригинальная публикация: 
Автор: Маарет Пиаярви (Maaret Pyhäjärvi)
Автор: Мэтью Бреттен (Matthew Bretten)
