В общем-то, тестирование игр не особо отличается по сложности от тестирования других приложений. Сложности иногда возникают при попытке определить, как протестировать их наилучшим образом, учитывая типичное для игр богатство интерфейсов и способов взаимодействия. Что еще тяжелее, так это локализация специфических (и довольно странных) багов, с которыми в них сталкиваешься. Недавно я обнаружил именно такой баг, тестируя популярную игру.
В свободное время я иногда работаю на игровые компании. Недавно я столкнулся с довольно-таки любопытным багом, тестируя игру Star Wars: The Old Republic. Баг я нашел чисто случайно – я не искал его прицельно, и даже не пытался найти что-то на него похожее. Когда баг был найден, было абсолютно неясно, что же конкретно тут происходит. Правда, знакомая история? Однако тут были свои нюансы.
Если вы не в курсе, то Star Wars: The Old Republic (SWTOR) – это массовая многопользовательская онлайн-игра (MMO), в которой вы создаете себе персонажа и исследуете вселенную Звездных Войн, выполняя квесты. Квесты, как правило, выглядят как видео-врезки, в течение которых ваш персонаж болтает с нейтральными персонажами (NPC). После завершения врезки вы отправляетесь выполнять полученное задание.
Как и в других ММО, вам придется сражаться с группами персонажей ("мобами") и в случае победы вы сможете подобрать "лут", который может содержать экипировку (броню, ботинки, перчатки, шлемы, и так далее) и другие ценности. Некоторые из них – например, броню и оружие – персонаж может надеть на себя. К тому же у вашего персонажа есть компаньон – контролируемый игрой соратник, который сопровождает вас в ваших приключениях и помогает в боях. Компаньона тоже можно одевать, передавая ему найденные на поле боя вещи.
Все программы, которые мы тестируем, работают с информацией. Когда одна и та же информация хранится в разных местах, то это вызывает проблемы при работе — неясно, где самая актуальная информация; при изменении надо найти все копии и синхронно их изменить; сложно разделять права доступа. Это является источником потенциальных проблем.
Во вводной лекции курса "SQL для тестировщиков" мы рассказываем, как реляционные базы данных помогли решить эти проблемы и заняли лидирующее положение в области хранения данных. Банки, страховые компании, интернет магазины используют реляционные базы данных в своих приложениях.
Чтобы не пропустить ошибок при тестировании программ, работающих с базами данных, нужно учитывать их особенности. Лекция знакомит вас с основами реляционных баз данных — объясняет структуру хранения информации, принципы связей между данными и существующие ограничения.
Запись доклада Алексея Петрова на онлайн-конференции Fun ConfeT&QA.
Тестирование, как правило, начинают тогда, когда в трекере Вам пришел тикет на тестирование, а разработчики залили нужный код на тестовую площадку. В дополнение ситуация приправляется жесткими делайнами и горящими сроками, тестировщик рвет на себе волосы и пытается успеть все и везде..
Меня такой подход не устроил достаточно давно и я начал использовать процедуру тестирования документации, как превентивный способ раннего обнаружения потенциальных ошибок. Данная практика предполагает, что к тестированию Вы приступаете еще до момента разработки, эдакий упрощенный TDD руками тестировщиков. Тестировщик может не только указать на явные логические ошибки в постановке задачи, отметить функциональные пробелы в ТЗ или сообщить об угрозах реализации в контексте проекта, но и составить первичный тест-план или даже чек-лист проверок по данной задаче! При чем сделает он это задолго до написания первой строчки кода разработчиком, тем самым принеся не только качественный и временной профит, но и солидную денежную экономию, ведь, указав на ошибки до их появления и сопродив задачу списком предстоящих проверок, Вы тем самым сокращаете трудозатраты разработчика на решение данной задачи.
В своем докладе я расскажу о тестировании документации, а именно:
что это такое
зачем это нужно
кому это нужно
как внедрить это
перспективы его использования
Мой доклад будет содержать не только абстракции и размышления на тему, но и реальные случаи применения тестирования документации из жизни.
Современные процессы разработки программных продуктов давно и успешно работают с функциональными требованиями. Однако, принимая решение о покупке продукта, потенциальный клиент в первую очередь анализирует интерфейс, простоту работы с ним, скорость и т.д. А проскочившая в прессе информация о дырах в безопасности или низкой производительности ведут к резкому спаду продаж продукта и наносят непоправимый ущерб его имиджу. В случае заказной разработки нефункциональные требования всё чаще фиксируются документально. Поэтому возникает необходимость обеспечивать соблюдение нефункциональных требований на уровне процессов.
В докладе Наталья расскажет:
какие есть нефункциональные свойства ПО;
как анализировать необходимые показатели и измерять неизмеримое;
как тестировать нефункциональные требования, и особенно — если они не зафиксированы в документации к продукту;
как, в конечном счёте, вызвать восторг ваших пользователей.
«Кросс-браузерность — свойство сайта отображаться и работать во всех популярных браузерах идентично. Под идентичностью понимается отсутствие развалов верстки и способность отображать материал с одинаковой степенью читабельности. Понятие «кросс-браузерность» очень часто путают с попиксельным соответствием, что на самом деле является разными понятиями.»
Тестирование кросс-браузерности как сущность является подвидом конфигурационного тестирования. Переведя термин на русский язык, мы увидим громоздкое словосочетание «перекрёстное тестирование под разными браузерами». В действительности же, термин тестирование-кроссбраузерности подразумевает не только проверку под разными браузерами, но об этом чуть позже…
