Вы возможно сталкивались с тем, что надо бы писать тесты или хочется тестировать, аж тестировщицкие трубы горят. Но требований нет. Концепта приложения – нет. Аналитиков – нет.

Если программисты могут описывать бизнес-логику, то и у нас есть богатство выбора, чем же заняться:

• Беседовать с заказчиком до потери пульса… Простите, до окончательного уточнения требований.
• Писать тесты для бизнес логики.
• Готовить тестовое окружение.
• Помочь заказчику и программистам найти общий язык и выработать совместное видение проекта.

И именно о 4м пункте я и расскажу.

На помощь, в этой задаче, к нам приходят макеты (концепт-скрины, если угодно). Для обсуждения названий контролов, для обсуждения того, что и на какую форму приложения необходимо поместить – это хорошая помощь. И, бывает так, что макет влияет на бизнес-логику: когда заказчик увидит прототипы, может оказаться, что его видение Кунг-фу вовсе не подразумевало ленивого медведя в роли Мастера…

Примеры создания макетов будут демонстрироваться с использованием инструмента Balsamiq.

От некоторых своих коллег я слышал, что success stories это скучно и не интересно. Я расскажу про fail`ы в то время как я был джуниором именно глазами джуниора.

Иногда я себе, а иногда мне друзья/коллеги задавали, например следущие вопросы:

• Почему я должен работать когда остальные балду пинают? / А почему они вообще балду пинают?
• Почему я должен ехать на конференцию за свой счет?
• Что надо чтобы начать постить баги? / Что надо чтобы ваши джуниоры начали постить баг.
• В какую сторону развиваться? / В какую сторону развивать
• Сколько я стою? / Как не потерять талантливого джуниора
• Чего я ещё не знаю?

Возможно, что для кого-то ответы на них очевидны, я расскажу какие ответы на эти и другие вопросы нашел я. Может я и не открою для вас что-то новое, но я надеюсь, что у вас будет над чем задуматься.

Каждый человек понимает, что такое usability ПО/приложения/сайта по своему. Это приводит к тому, что регулярно возникают споры внутри компании. В результате тратится время, а результат так может и не появится или не устроить все заинтересованные стороны.

Существует решение, с которое позволит уменьшить споры и облегчить работу тестировщикам при проверке. Необходимо заранее создать список правил, которых должны придерживаться все: дизайнеры, аналитики, разработчики.

Эти правила можно сформулировать в виде списка требований и использовать при тестировании usability. Очень удобно, что этот набор можно составить один раз, а потом для каждого проекта выбирать только нужные пункты. Эти требования не зависят от платформы разработки, от способа использования (десктопное приложение, веб или с мобильного устройства). Теперь каждый специалист по тестированию сможет проводить первичное тестированию usability, не тратя большое количество усилий для выяснения: а что же, собственно говоря, надо проверять.

О создании такого списка и возможностях его применения и пойдет речь в моем докладе.

Вы умеете снимать скриншоты? Наверняка. А насколько хорошо вы умеете это делать?

Минимальный набор инструментов — кнопка PrintScreen и простейший текстовый редактор Paint. Кто-то вполне обходится этими средствами. Однако при этом существуют навороченные и даже платные специализированные инструменты. Кому и зачем они нужны? Что они умеют делать такого, чего нельзя сделать кнопкой PrintScreen? А может быть у вас уже есть такая программа-скриншотер? Тогда скажите, какую часть её возможностей вы используете?

Хороший современный скриншотер — это сочетание трёх факторов: 1) много режимов «захвата», 2) хороший графический редактор, 3) удобные средства публикации результата.

Я расскажу про скриншотеры, которыми пользуюсь сам — на что они способны, чем они мне нравятся, чем не нравятся, почему их несколько (неужели нет идеального?)

Скриншот, как наглядное средство демонстрации, является важным аргументом в руках тестировщика, особенно когда вы сообщаете о найденных дефектах. Я расскажу вам, как добывать эти аргументы и делать их сильнее.

Тестирование, как правило, начинают тогда, когда в трекере Вам пришел тикет на тестирование,
а разработчики залили нужный код на тестовую площадку. В дополнение ситуация приправляется жесткими делайнами
и горящими сроками, тестировщик рвет на себе волосы и пытается успеть все и везде..

Меня такой подход не устроил достаточно давно и я начал использовать процедуру тестирования документации, как превентивный способ раннего обнаружения потенциальных ошибок. Данная практика предполагает, что к тестированию Вы приступаете еще до момента разработки, эдакий упрощенный TDD руками тестировщиков. Тестировщик может не только указать на явные логические ошибки в постановке задачи, отметить функциональные пробелы в ТЗ или сообщить об угрозах реализации в контексте проекта, но и составить первичный тест-план или даже чек-лист проверок по данной задаче! При чем сделает он это задолго до написания первой строчки кода разработчиком, тем самым принеся не только качественный и временной профит, но и солидную денежную экономию, ведь, указав на ошибки до их появления и сопродив задачу списком предстоящих проверок, Вы тем самым сокращаете трудозатраты разработчика на решение данной задачи.

В своем докладе я расскажу о тестировании документации, а именно:
– что это такое
– зачем это нужно
– кому это нужно
– как внедрить это
– перспективы его использования

Мой доклад будет содержать не только абстракции и размышления на тему,
но и реальные случаи применения тестирования документации из жизни.

По специфике своей работы я провожу десятки собеседований и общаюсь со множеством начинающих и имеющих некоторый опыт специалистов в области тестирования. Как правило у них есть масса вопросов, связанных как с работой и ее организацией так и со своей ролью и перспективах в компании.

Большинство из них желает скорейшего карьерного роста и повышения зарплаты и перед ними встает вопрос: как проявить себя, как сделать так чтобы твои старания заметили? Ведь одних амбиций и желания проявить себя недостаточно. Если вы хотите самоутвердиться, получить повышение или просто прибавку к зарплате вам недостаточно быть хорошим специалистом, вам необходимо выглядеть «лучше» остальных, выделяться.

В своем выступлении я дам ряд советов из личного опыта, как обратить на себя внимание тех, чьего признания вы добиваетесь и от кого зависит решение о вашем продвижении.

Часто в форуме появляются вопросы, которые обобщенно звучат так: «Есть фича. Помогите протестировать», без уточнения контекста использования. В итоге набирается некоторый набор позитивных и негативных кейсов, проверяющий, что конкретная функция работает, так называемый, чит-шит. Основной акцент в таких кейсах, как правило, делается на проверку ввода через пользовательский и нтерфейс и обработки разный значений с учетом используемых технологий.

Но можно ли считать, что выполнив этот набор кейсов, фича будет хорошо протестирована?

Увы, часто получающийся набор проверяет рабостоспособность функционала лишь с технической точки зрения (и фактически может быть заавтоматизирован), но не учитывает взаимодействие этого функционала с остальными частями системы. И если ограничить тестирование лишь этими проверками, то не будет получен ответ на такой важный вопрос, как «решает ли данный функционал проблему пользователя?».

В докладе на примере тестирования поиска будет показано, как можно дополнить технические тест-кейсы, анализируя функционал с разных точек зрения: цели пользователя, взаимодействие с остальными частями системы, настройки по умолчанию. Такой анализ помогает не только более полно протестировать функционал, но и выступить с предложениями по его улучшению

В жизни каждого тестировщика рано или поздно возникает задача, с которой он ранее не сталкивался. Хорошо, когда есть рядом человек, обладающий необходимым опытом и знаниями, который готов помочь и подсказать, с какой стороны подходить к задаче, с чего начать и что использовать. Но как показывает практика, такие люди есть не всегда.

Дано: веб-сервисов с SOAP-интерфейсом, паспорт сервиса, требования.
Нужно: Требуется проверить работу сервиса в соответствии с требованиями.
Сроки: к вчера, так как уже не укладываемся в график.
Опыт в решении подобных задач: отсутствует или минимален

Целевая аудитория моего доклада – специалисты, не имеющие опыта в вопросах тестирования сервисов. Я расскажу вам про инструмент soapUI Pro 4.0.1, который очень хорошо показал себя в условиях ограниченного времени и отсутствия опыта.

Все мы любим делать свою работу быстро и качественно. А что же может помочь ручному тестировщику web-приложений? Конечно, тонкая настройка своего основного инструмента – браузера.
За 20 минут Вы узнаете:
• Чем можно нашпиговать свой браузер, чтобы в нем была масса полезных примочек?
• Что с этими примочками можно сделать полезного? Как можно работать эффективнее?
• Какие есть расширения для популярных браузеров?
• Какие профили создают себе ведущие тестировщики отрасли?

Обычный тестировщик начинает карьеру с тест-кейсов, и ими же завершает свой прекрасный жизненный цикл.

Крик из толпы: «Камон! Долой тест-кейсню!»

Мы вооружаемся плюсами тестирования без тест-кейсов, мы минимизируем минусы этого прекрасного подхода, мы захватываем почту-телеграф-телефон-твиттер!

С площади гудит: «Дааааааайошь старые порядки взад!»

Нам с трибуны докладывает Мурка в кожаной тужурке: «Товарищи! Доколе мы терпим засилье тест-кейсов?! Нам нужен Fun! Fun, товарищи! Fun!»

Давайте начнем прямо сейчас, давайте «Отречемся от старого мииииииира»…

Из своих почти 9 лет тестирования 9 лет я проработал в распределенных проектах. Поначалу был тестировщиком, потом руководил командами и отделами тестирования. Проекты были разного размера – от 7 до 150 человек, с разными технологиями и количеством тестировщиков в них.

Кто там говорит про скорость коммуникаций и сидение в одной комнате? Мы работали в двух, трех и даже пяти городах с абсолютной разницей в часовых поясах. А коммуникации нещадно обрубались юридическими отделами корпораций. :) При всем этом удавалось выпускать на рынок продукты, которыми пользовались миллионы людей, и что самое удивительное заказчики практически всегда были довольны нашей работой.

Оглянувшись назад и проанализировав свой опыт, удалось сделать несколько выводов о том, как команде тестирования работать в распределенных командах в условиях сверх-медленных коммуникаций. Этими выводами я и хотел бы поделиться.

Тестирование – это драйв, позитив, удовольствие. От поиска багов, от их обнаружения, от их заведения…

Хотите получать от работы энергию, а не уставать? Наталья Руколь на примере покажет, как это нужно делать!