Исследовательское тестирование – прекрасная идея, позволяющая нам использовать свободу нашего выбора, тестируя, учиться на ходу и позволить этому обучению влиять на выбор, который мы совершаем. Система, которую мы тестируем – это наше "внешнее" воображение, и наша задача – дать ему шанс прошептать нам всю нужную информацию.
Когда мы тестируем, мы можем растягивать свои рамки исследования – хоть немного, да можем. Даже наиболее ориентированная на тест-кейсы организация попросит вас поразмыслить, поучиться, посмотреть вокруг, запуская тесты. Именно это делает вас хорошим тестировщиком.
Чтобы еще растянуть эти рамки, эти организации позволяют пару часов потестировать свободным поиском, чтобы найти баги, которые не покрыты вашими обычными тест-кейсами и которые вы в норме даже не заметите.
Другие – например, я – занимаются исследовательским тестированием постоянно. В этом режиме тест-кейсы (если они вообще существуют) – это результат процесса, а не его исходная точка, и они создаются, когда мы знаем о фиче или продукте максимально много. Мы многому научаемся, когда завершаем тестирование.
Вне зависимости от того, используете ли вы исследовательское тестирование как технику (расширяя ваши кейсы), как задачу (отводите время на свободный поиск) или как подход (влияющий на то, как вы воспринимаете тестирование), всем вам очень нужен важный навый самоуправления. Вы хотите исследовать, имея в голове четкую цель, следить за тем, что вы узнаете, чему учитесь, и чему еще нужно научиться. Все это будет последовательно нарастать, когда вы начнете тестировать этим способом.
Несколько месяцев назад я собеседовал кандидата на должность тестировщика и спросил про его имеющийся опыт. Ответ кандидата прозвучал в духе "ну, это, конечно, ни о чем, но я участвовал в бета-тестировании видеоигр". Неделей позже я наткнулся на дискуссию в 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)
