Юля Нечаева

Игра "Нереальное тестирование" на SQA Days, ИТОГИ.

2011-12-08T11:10:00.000-08:00

На конференции SQA Days – 10 мы (Иннова) были спонсорами.

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

Судя по отзывам в твиттере и тому, что по просьбам посетителей мы продлили стенд ещё на один день, это удалось!

Фотографии здесь (при клике по фоткам откроются альбомы в ФБ):

Специально для конференции мы придумали игру: Нереальное тестирование (ТМ).

Правила:

Два на первый взгляд одинаковых сайта. Но только не для зоркого глаза тестировщика!
Задача игроков была - найти максимальное количество отличий в двух сайтах за игровую сессию.

У игрока было 10 минут, которые начинались по нажатию на кнопку Старт на первом сайте.

У сайтов были отличия 3х типов:

-- Статические (k=1) – можно обнаружить, на странице не действуя, как пользователь;
-- Динамические (k=2) – могут быть найдены только в ходе «использования» сайтов,
-- Сложные (k=5) – без специальных инструментов не найти!

И были Пасхальные яйца (win, k=7):
Мы заложили в Подвиги несколько пасхальных яиц, нахождение каждого давало 7 очков!
Появление на экране сообщения WIN свидетельствовало о нахождении игроком пасхального яйца.

Фиксировать найденные игроками отличия помогали девочки-модераторы, они же вносили результаты в админку, которая пересчитывала финальный результат.

Счет игрока складывался исходя из количества найденных отличий с учетом коэффициента категории. Общий рейтинг составлялся на основании заработанных игроками очков за одну сессию.

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

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

По результатам первого дня поиграть удалось пятидесяти участникам. Легендой стенда стал Петр Родин, который несколько раз отвоевывал первое место, но в итоге занял 4е.

Второй день был менее динамичен, да и длилась игра на 2 часа меньше. Поиграло 33 человека, два призовых места взяли Катя и Вика, выбрав стратегию объединения.

Очень было интересно наблюдать, как люди с разным опытом по-разному подходили к задаче.

Одни сразу же открывали исходники двух «главных» страниц, даже не авторизуясь, проводили в сравнении 6-7 минут, потом заходили внутрь сайтов и тут только понимали, что исследовали лишь малую часть.
Другие первым делом оценивали объем страниц и функциональности сайтов, и лишь потом приступали к поиску.
Одни делали упор на отличия в верстке, другие – в функциональности.
Одни старались найти как можно больше простых отличий, другие выбирали стратегию «мало, но WIN’ов».

Многие меняли стратегию после первого раза.

Отличная иллюстрация для исследовательского тестирования, на самом деле!

Мы оставили сайты в открытом доступе ещё на неделю, до 15 числа можно поиграть вот здесь:
http://inn.webumka.ru/test1/
http://inn.webumka.ru/test2/

На любые вопросы я отвечу в этой ветке форума, здесь же можно меряться результатами. Единственное правило – не спойлить!

15 декабря я опубликую список тех отличий, которые были внесены в приложения санкционированно, то есть – по ТЗ. Интересно сравнить с вашими списками.

Удачи!

SQA Days 10: Команда, где каждый лидер

2011-12-05T06:38:00.000-08:00

Моя презентация с SQA-Days 10.

Хочу поделиться теми принципами, которые помогли мне построить 2 суперэффективные команды тестирования в моей компании. В двух словах: в моих командах каждый специалист является лидером.

Основная фишка в том, что у лидера есть ответственность, но нет формальных полномочий. Являясь боссом в своем направлении, он является исполнителем в направлении своего коллеги.

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

Команда, где каждый лидер on Prezi

Eurostar. Introduction. The first post of our new blog.

2011-11-22T11:00:00.000-08:00

Привет!

Мы открыли блог команды тестирования Инновы. Подробнее про нас и про то, зачем мы это делаем, можно прочесть первом поcте: http://www.innovatesting.info/2011/11/about-us.html

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

Первый пост про вчерашнюю 8-часовую сессию Майкла Болтона: вот он.

Пост про выступление Дороти Грэхем: вот
Фотопост с доклада Гойко Адзика: вот

Нужен младший волшебник по тестированию веб-приложений

2011-08-01T13:06:00.000-07:00

Привет!

Я ищу коллегу в команду веб-тестирования: молодого специалиста по ручному тестированию.

UPD: специалист найден!

Мы работаем над самыми разными проектами:

- личный кабинет пользователя Фогейм, где самое важное – это удобство и логичность сценариев пользователей;

- система биллинга (связанная с платежными шлюзами, системами рассылок SMS и mail-нотификаций), в которой сейчас более 10 млн зарегистрированных пользователей (из них более 3 млн активных), которая позволяет держать более чем 100 000 «одновременных» коннектов, где самое важное – надежность и производительность;

- внутренние проекты, которыми пользуются сотрудники различных отделов в работе;

- интеграционные проекты, которые с одной стороны являются красивой витриной для пользователей, а с другой – имеют сложную систему интеграции с игровой и биллинговыми базами;

- бесчисленное количество промо-страниц, где самое важное - это корректное отображение в различных браузерах;

В нашем тестировании несколько направлений:

- автоматизированное тестирование бэкендов (собственный фреймворк на языке Java)
- ручное тестирование (используем Mind Map для фиксации тестов)
- автоматизированное тестирование интерфейсов (Selenium + Java)

Важно: у нас нет выделенной должности тест-дизайнера, каждый сотрудник в его роли проектирует свои тесты. Мы синхронизируем их на уровне планирования и на этапе финализации.

Профиль нашего будущего коллеги:

Молодой человек (или девушка, как подсказывают мне через плечо разработчики :)) с недолгим опытом работы в тестировании. Горящий, верящий в то, что тестирование влияет на качество, которого заводит видеть, как люди пользуются его продуктами. Который считает тестируемый продукт своим и лично заинтересован в его развитии и улучшении.

Если более формально, то:

- опыт тестирования 0.5 – 1.5 года;
- опыт написания тестов (можно небольшой);
- понимание принципов тестирования (не назубок рассказывать определения, а понимать, что, где и зачем применяется);
- понимание устройства веб-приложений;
- хороший вкус к программным продуктам: быть пользователем многих сервисов, понимать как пользователь их плюсы и минусы, уметь анализировать причины такой реализации;
- неуемное желание развиваться и учиться;
- уметь обосновывать свои мысли и доказывать свою правоту.

Очень хорошо, если на текущем месте работы вам некуда расти – приходите к нам, у нас есть куда!

Мы готовы помочь вам из "ручного" тестировщика стать тест-дизайнером, тест-аналитиком и специалистом по автоматизированному тестированию в одном лице, если захотите.

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

Мы с удовольствием поощряем желание учиться: конференции, тренинги, книги, локальные обсуждения и семинары.

Добро пожаловать!
Принимаю резюме на yulia DOT nechayeva AT inn DOT ru

как Тестированию не задерживать Разработку: часть 2

2011-03-08T06:43:00.000-08:00

Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.

Спасибо Максу Дорофееву за вдохновение.

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

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

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

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

А теперь представим, что вторая активность не обязательно может быть начата после завершения первой задачи, а уже после выполнения небольшого её участка. Если это учитывать, то можно значительно сократить общее время жизни задачи и приблизить момент её завершения.

Теперь посмотрим на сервисный отдел тестирования. Ему поступают одновременно три задачи от разных заказчиков на тестирование.

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

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

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

Но здесь как раз тот случай, в котором исправление багов не обязательно может начаться после завершения всего тестирования задачи. Мы же помним, что тестировщики придерживаются правил 1-5, и первым делом бьют в самые приоритетные области.

Давайте посмотрим, что будет, если тестировщики будут давать фидбек после выполнения первоприоритетных тестов, и заказчики тут же будут приступать к фиксу:

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

А если мы можем выпустить задачу ДО завершения финального цикла (с известными минорными багами), то посмотрите, насколько раньше это можно сделать!

Теперь вспомним, что перед тестированием была собственно реализация задачи заказчиком, и посмотрим на картинку:

Видим, что от времени жизни задачи на тестирование зависит время жизни всей задачи.

И в такой схеме легко находится Полезное-потом время.

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

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

И – что очень важно – такая система позволяет сотрудникам отдела принимать решения: какую задачу взять первой, на каком этапе пора давать фидбек заказчику, какие задачи брать из пула внутренних задач. Они составляют пул внутренних задач, потому что постоянно анализируют свою работу на эффективность. Они придумывают полезные штуки, потому что это интересно и полезно. Они развиваются и от этого тестирование становится более эффективным.

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

Обязательные условия для того, чтобы это работало:

- опытные высококвалифицированные специалисты в отделе тестирования
--- новички не смогут сразу принимать решения, оценивать приоритеты и проводить исследовательское тестирование

- хорошие коммуникации с заказчиками (как рабочие, так и личные)
--- нужно вырабатывать общие подходы с каждым заказчиком, договариваться о способах постановки задачи, о способе репорта о багах, о том, как действовать, если задача сверхсрочная

- небольшое количество людей и небольшой поток задач (в единицах)
--- я не уверена, будет ли это работать на отделе в десятки человек и входящем потоке десятки задач в день

- небольшое количество итераций тест-ретест
--- если оно большое, то получаем дополнительные лаги на переключение, чем, скорее всего, затрём выигрыш по времени за счет раннего фидбека

Продолжение следует...

как Тестированию не задерживать Разработку. часть 1

2011-03-08T03:23:00.000-08:00

На конференции Agile Days рассказывала про то, как сервисному отделу не стать бутылочным горлышком на примере отдела тестирования.

Презентация вот:

Agile Days on Prezi

Видео будет чуть позже.

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

Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.

Постановка задачи и метод решения.

Начну с правды: Тестирование не самодостаточно.

Тестирование само по себе не несет для продукта никакой бизнес-ценности. (Я здесь не говорю про компании-аутсорсеры, которые этим зарабатывают, я имею ввиду тестирование в процессе разработки продукта).

Задача на тестирование – это всегда часть старшей задачи: задачи на разработку, задачи, на верстку, на архитектурное решение, на текст, на сценарий, на идею, в конце концов.

И бизнес-ценность для продукта имеет именно та, старшая задача.

Для простоты назовем команду, выполняющую старшую задачу, заказчиком тестирования.

Понятно, что методы и подходы к тестированию зависят от старшей задачи. И – что самое важное – процессы. Процессы тестирования зависят от процессов, по которым выполняется старшая задача.

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

Если тестирование неотрывно от выполнения старшей задачи (как это происходит в большинстве скрам-команд), то проблемы здесь намного меньше: задача просто попадает в состояние ТЕСТИРОВАТЬ, возможно, тем же человеком, который делал старшую.
Но что, если тестирование – это сервисное подразделение в компании? Которое работает на несколько команд.

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

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

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

Если мы говорим о задачах на тестирование длиной менее одного дня каждая, то планирование здесь практически невозможно. Я не верю в выполнение тремя заказчиками плана по постановке задачи на тестирование с точностью до часа. Если вы запланировали, что одна задача придет к вам в 11 часов, другая в 15 и третья в 17, то будьте уверены, что они все придут к вам в 17-30 =)

Время, которое старшая задача проводит в тестировании, можно условно разделить на три вида:

Полезное-сейчас время – это время, когда задачу непосредственно тестируют: выполняют тестовые сценарии, гоняют тесты. Сюда же отнесем время на оформление баг-репортов, потому что этот продукт потребляет наш заказчик.

Полезное-потом время – это время на подготовку тестирования: настройка тестовой среды, тест-планы, написание тестов, сбор и анализ метрик, анализ результатов тестирования, составление отчетов, актуализация тестов. Это то, что помогает тестированию оптимизировать работу, делать её более эффективной, и давать более полную оценку качеству продукта.

Бесполезное время – это время, когда задача в тестирование передана, но в тестировании не находится. Она ждет в очереди. Либо сейчас тестировщики заняты другой задачей, либо они не успели подготовить все к началу выполнения.
Понятно, что одно и то же время может быть одновременно Бесполезным для заказчика и Полезным-потом для тестирования.

И в целях уменьшения времени на выполнение старшей задачи, очень важно оптимизировать время на тестирование. Ключевой момент – старшая задача должно КАК МОЖНО МЕНЬШЕ ждать, пока задача вернется с тестирования. При этом экономия времени не должна влиять на качество работы тестирования.

Задача тестирования - максимально эффективно тратить Полезное-сейчас время, максимально сокращать для заказчика Бесполезное время и сделать невидимым Полезное-потом время.

Хороший сервис тестирования должен работать по трем основным принципам:

- как можно быстрее приступать к задаче (минимизировать Бесполезное время)
- как можно быстрее давать первый фидбек (оптимизировать Полезное время)
- как можно быстрее давать оценку качеству (помогать заказчику спланировать и скорректировать время на багфиксы)

Чтобы этого добиться, есть несколько инструментов:

1) максимально мелкие задачи на тестирование

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

2) правильно расставлять приоритеты в тестировании

-- «Первым бей, где больно»: по тяжести возможных найденных ошибок.

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

-- «Первым выталкивай, что долго»: по длине цикла исправления возможных найденных ошибок.

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

3) практики тест-дизайна

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

-- по глубине тестирования (например: смоук, акцептенс, функциональные)

-- по объектам тестирования (например: дизайн – верстка – функциональность фронт-энда – функциональность бек-энда)

-- по сценариям тестирования (позитивные-негативные)

-- по эмулируемым пользователям ( наиболее распространенное поведение, более редкое, практически невозможное)

И выполнять их нужно, разумеется, соответственно выбранным приоритетам.

3) разумно подбирать момент оформления багов

-- Сразу же после каждого найденного бага (оправдано, если тесты маленькие, не требуют подготовки к каждому из них и легко прерываемы, плюс время на оформление бага тоже мало).

-- Сразу же после завершения тестирования подзадачи (логически завершенный участок работы тестировщика).

Иногда, если баг очевиден, нужно сказать вслух, и пока разработчик его правит – оформить.

4) давать предварительную оценку качеству

Работая не первый день над проектом, тестировщик всегда может оценить в сравнении качество реализации текущей задачи заказчиком от других. Это можно делать на основании метрик, например, «количество багов, найденных в результате прогона тестов приоритета 1» , или «количество багов на единицу системы (сценарий, страница, таблица)».

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

5) кроссфункциональность сотрудников

В идеале, все сотрудники отдела тестирования должны уметь выполнять все задачи с одинаково высокой эффективностью. Но так не бывает. У разных людей разные таланты, разные способности, они наиболее эффективны в разных областях.

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

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

6) исследовательское тестирование

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

Умение без специальной подготовки сесть и выполнить задачу на тестирование, использую подходы 1, 2, 3 и 4 – вот, что значит исследовательское тестирование.

Ну и плюс некоторые практики:

- сессионность
-- сессия 1: тестирование + оформление багов
-- сессия 2: запись выполненных тестов
-- сессия 3: анализ выполненных тестов, расширение, приоритизация
-- сессия 4: выполнение расширенного набора тестов

- парное тестирование:
-- пилот выполняет тесты
-- штурман подсказывает и записывает

7) Полезное-потом время должно быть обязательно!

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

Если в отделе тестирования этого не делается, значит тестирование работает как загнанная лошадь, на постоянном потоке, без остановки. И обязательно придет момент, когда отдел не справится с задачей вовремя, а то и вовсе не справится, потому что не готов. Потому что нет подходов, нет инструментов. Потому что уже нет мотивации разбираться. Загнали.

Так как задачи из серии Полезное-потом не несут непосредственной ценности для заказчика тестирования, но правильно будет сделать так, чтобы они его не задерживали. Для этого можно пойти двумя путями:

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

-- Жестко запланировать время, например: каждую пятницу с 15-00 отдел тестирования задачи у заказчиков не принимает, а занимается внутренними. Если этого правила придерживаться очень жестко, то все привыкнут и будут планировать свои задачи так, чтобы отдавать их на тестирование до пятничного утра.

продолжение следует...

Соратники needed

2011-02-28T11:40:00.000-08:00

Привет!

Ищем пополнение в команду тестирования Инновы. Про наши проекты можно посмотреть здесь. На наши мордашки можно поглазеть здесь.

Как устроен отдел.
Как работают игровые тестировщики.
Как работает веб-направление - буду рассказывать на agiledays.

Итак, нам нужен инженер по автоматизации тестирования. Это человек, которому мы доверяем самое основное - ядро проекта. Он читает код, он пишет код, он не только находит баги, но и локализует их. Скажу по секрету, его даже могут привлекать к код-ревью =)

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

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

Знаете, что самое, на мой взгляд, крутое на этой позиции? Таких вещей две.

Первая - свобода. Свобода для реализации своих идей. Можно менять тулы, можно пробовать подходы, можно участвовать в планировании разработчиков - можно не участвовать =) Вы будете лидером направления.

Вторая - быстрый фидбек. Мы релизим обновления системы самое редкое - раз в три недели. И каждого пользователи ждут, занеся палец над кнопкой мыши. Если мы оплошали - то видим это через минуту. Очень держит в тонусе.

Если Вы вместо Java знаете Python и умеете читать код на C++, я вам открою секрет, мне скоро понадобится и такой специалист.

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

Ну и напоследок, ведущие игровые тестировщики в два легендарных проекта Lineage II и Aion. Нам нужны люди, которые любят игру настолько, что готовы на ней работать. Которые готовы отдавать игре не 5 часов прогулянных пар, а 8 часов рабочего дня. Вы увидите мир игры изнутри. Вы узнаете пользователей с другой стороны.
Если Вы игрок и тестировщик - велкам.

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

Мы - хороший отдел тестирования. Руководство никогда не отказывает нам в расширении штата или приобретении инструментов. Чтобы стать ещё лучше - нам нужны новые коллеги.

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

Если не боитесь - пишите мне на yulia DOT nechayeva AT inn DOT ru. До встречи!

Тестирование игр в Иннове: рассказ о работе отдела

2011-02-20T05:40:00.000-08:00

Это словесная экскурсия в группу игрового тестирования моего отдела. Это как раз те ребята, о которых говорят, что они "играют на работе" :)

Внешняя среда

Начну с описания внешней системы. У нас 13 игровых проектов. Они разного размера, их разрабатывают разные компании (чаще всего корейские), у них разные процессы, разный жизненный цикл, разная частота обновлений, разное качество и разные изначальные требования к качеству.

На первый взгляд кажется, что Иннова занимается только локализацией, и, казалось бы, что тут тестировать? Нам же дают готовый продукт, тестируйте только локализацию. Но вот эти разные изначальные требования к качеству продуктов играют свою роль. Разные компании-разработчики считают нормальным выпускать продукт на свой (корейский) рынок с определенным количеством известных багов. И это количество у всех, как вы понимаете, разное.

Мы же стараемся свести это количество к минимуму во всех наших играх. Потому что как только мы выпускаем игру в России, она становится «нашей». Мы так считаем.

Процесс тестирования

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

То есть, план тестирования обновления выглядит примерно так:

- тестирование локализации:
--- списки для проверки, сроки

- тестирование новой функциональности:
--- чек-листы для проверки, приоритеты, сроки

- тестирование сборки:
--- смоук-тесты, сроки

- бета-тестирование:
--- задание для игроков, сроки

Я рассказывала про полный цикл тестирования локализованной игры на примере Атлантики.

Процесс взаимодействия с разработчиками зависит от проекта и от компании-разработчика. Баг-репорты могут оформляться в BTS, на нашей или на их стороне, могут собираться в Excel или Google-docs. Взаимодействуют по их исправлению с разработчиками чаще всего тестировщики, но кое-где вся коммуникация проходит через руководителя проекта. Мы подстраиваемся под проект, но вносим в процессы изменения для их оптимизации.

Тестовая среда

Помимо боевых серверов (которых у разных игр от одного до тринадцати) есть система Публичный Тестовый Сервер (ПТС) и внутренний тестовый сервер (QA-стенд). На ПТС может зайти любой игрок при желании. Там проводятся все бета-тестирования. Для того, чтобы туда попасть, не нужно особых сложностей, даже не нужен отдельный аккаунт, подойдет тот, которым играешь на боевых серверах.

На QA-стенде проводится внутреннее тестирование, до того, как отдать игрокам на ПТС.

Не любое обновление игры проходит весь путь QA-стенд -> ПТС -> боевые сервера. Некоторые обновления невозможно поставить на ПТС, не задев боевую систему. Такие сразу идут в бой после внутреннего тестирования. Некоторые наоборот, не могут быть нормально протестированы на внутреннем стенде, и они сразу идут вовне к нашим бета-тестерам.

Качество боевого продукта

И все же, приходится выпускать продукты с известными багами. И – бывает, что с критичными. Например, последнее большое обновление легендарного проекта Lineage II High Five Part 4, установленное на сервера 28 декабря, принесло серьезный баг: случайным образом у пользователей клиент игры вылетал с критической ошибкой при телепорте.

Это может зависеть от того, что, например, этот баг проявляется при нагрузке на серверы. И тогда он всплывает только в боевой эксплуатации. Мы не воссоздаем нагрузку в нашем цикле тестирования, потому что это делает компания-разработчик. Но, не всегда результативно. Так как часто обновления запускаются в одно время с Кореей и часто раньше Европы, мы идем на риск запуска с неизвестными багами.

Это может зависеть, например, от запланированного срока запуска обновления, которого ждут все игроки.

Это может зависеть от неопределенных сроков по решению проблемы от разработчиков.

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

Конечно же, об известных ошибках игрокам сообщается. И статус их решения постоянно обновляется. И, конечно же, они недовольны ответом «Отправлено компании-разработчику, они работают над этим»!

Организация команды

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

В его задачи входит:

- планирование тестирования проекта (или его обновлений)
- организация тестирования проекта (или его обновлений)
-- внутреннее тестирование
-- внешнее тестирование (с помощью бета-тестеров)
- информирование всех заинтересованных лиц о статусе тестирования и состоянии продукта

Тест-менеджер взаимодействует по работе:

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

«Заводы стоят, одни менеджеры в стране», - скажете вы :) Конечно же, тест-менеджер – это не должность, а роль. В эту роль мой сотрудник входит тогда, как на его проекте есть активность по тестированию. В остальное время – он тестировщик. Он – «руки другой головы». Один человек никогда не справится в срок с тестированием большого обновления большой игры. Поэтому, когда ему нужно, вся команда к его услугам. В момент активности его проекта – он главный, он ставит задачи и собирает результат.

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

Планирование работы команды на день происходят на утренних стендапах. Основные вопросы, которые обсуждает команда, это:

- «Я сегодня буду заниматься этим»
- «Мне сегодня нужно 4 человека на тестирование этого»
- «Я сегодня не загружен, кому нужно помочь?»

Подход владельца

У нас в компании есть понятие «драйвер задачи». Это значит «быть её владельцем», быть самым заинтересованным в её решении. Понятно, что тестировщик многого не может сделать самостоятельно:

- он не может напрямую повлиять на скорейшее исправление бага разработчиками
- он не может напрямую повлиять на ускорение установки
- он не может управлять инженером
и т.д.

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

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

Мои тестировщики – это менеджеры своих проектов. Проектов по тестированию проектов. Владельцы процесса.

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

Я считаю неправильным самой делать это за всех, поэтому я учу делать это своих ребят. Это развивает их, и это дает свободу мне как руководителю заниматься более стратегическими задачами.

Side-effect

Правда, side-effect у такого подхода тоже есть. Ребята видят все стороны проекта, общаются со всеми участниками проекта, с почти всеми отделами в компании. Их видят, за ними наблюдают. И они растут.

Некоторые растут в другие отделы. Двое из моих игровых тестировщиков ушли в младшие менеджеры проектов. При этом один из них – на том проекте, на котором работал, а второго цапнул руководитель соседнего проекта. Прямо сейчас он (мой бывший тестировщик) в Сеуле налаживает коммуникации с компанией-разработчиком. Ещё один уходит в отдел аналитики игровых продуктов, как раз сейчас ищу ему замену. Я радуюсь за них. Значит, я хорошо работаю.

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

На уровне компании

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

Или он может не заказывать её по другим причинам. Например, в нескольких небольших проектах тестирование осуществляется самой командой проекта. Потому что цикл тестирования обновления очень небольшой (несколько часов), контента немного, и внутри команды проще выделить время «Вот прямо сейчас все сели и побежали», чем ставить задачу в мой отдел.

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

В таких проектах мы выступаем как носители экспертизы: можем подсказать, помочь написать тесты, подсказать, как правильно оформить артефакты.

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

Спасибо вам, ребята!

Отдел тестирования: цель первой итерации достигнута

2011-02-20T05:27:00.000-08:00

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

Надо отметить, что тестировать у нас надо не только игрушки. У нас серьезный отдел разработки, который не дает нам скучать. Как, впрочем, и мы ему. Наш основной продукт разработки – это система, связывающая воедино все наши игры, игроков и партнеров. Пользователям он известен как Фогейм.

Сейчас отдел тестирования компании Иннова состоит из 2 подразделений. Группа тестирования игровых приложений и группа тестирования веб-приложений. Так исторически получилось, это действительно два совершенно различных направления тестирования, требующие от ребят в разных группах разных знаний и навыков. Тем не менее, связь между проектами очень тесная, и мы все вместе радуемся и злимся, отдыхаем и флудим в чатике.

Но, обо всем по порядку…

Когда я пришла, готовился к запуску Айон. Подключение Айона к боевой системе я (тогда ещё единственный тестировщик во всей компании) я проверяла по-живому. Как сейчас помню свои ощущения, когда через несколько минут после запуска озвучили онлайн в десятки тысяч и такое же количество прошедших платежей!

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

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

После Атлантики, ребята уже самостоятельно организовывают тестирование больших обновлений. Почти каждый из них – тест-менеджер своего проекта. Работа организована так: «Чей проект сейчас активен, тот и главный». Это значит, что если сейчас в работе обновление Lineage II, то тест-менеджер может рассчитывать на руки и головы всей команды. Но во время тестирования другого проекта он сам станет тестировщиком на нём, попадая под управление своего коллеги.

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

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

Тестировать приходится по описаниям изменений в виде «Добавлено 20 новых квестов для асмодиан в Бездне» или «Изменены показатели умений Огня» . Поэтому мы проверяем только на работоспособность внесенных изменений и проводим регрессионное тестирование. На «логичность» изменений проверяют наши бета-тестеры. Именно они, люди, которые знают мир игры лучше всех, могут сказать, что «похоже, разработчики ошиблись. Не может этот шлем давать такой бонус! Это подорвет экономику сервера». И они часто оказываются правы.

Работа с бета-тестерами – это то достижение, которым мой отдел может гордиться. У моих ребят очень теплые отношения с бета-тестерами. Это отдельные группы людей, которым интересно нам помогать, и они сидят в скайп-конференциях, пишут в закрытой группе на форуме, выполняют задания и ждут новых обновлений. Заменить, например, группу из 40 человек постоянных помощников по тестированию Lineage II можно, конечно, группой специалистов по тестированию. Но это был бы худший вариант, так как точечные удары людей, хорошо знающих контент, в нашем случае намного эффективнее планомерного прочесывания со знанием подходов.

Но, игры сама по себе существовать не может, ей нужна очень большая инфрастуктура.
Основной проект нашей компании – Фогейм. Это не просто сайт. За ним стоит огромная система биллинга, связывающая пользователей с лицевыми счетами, нашу внутреннюю бухгалтерию с партнерскими, учитывающая юридические моменты, и, что самое главное, позволяющая с единым аккаунтом играть во все наши проекты. Которых будет становиться все больше!

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

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

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

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

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

В моих целях на 2010 одной из ключевых было написано:

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

Ну что ж, получилось! Мы успешная часть успешной команды.

Если вы стали QA-менеджером

2010-10-02T10:13:00.000-07:00

Представляю перевод статьи Джеймса Виттакера "Если вы стали QA менеджером". Оригинальному тексту почти год, я прочла его первый раз как раз, когда сама оказалась на месте героя поста. За это время у меня появились комментарии к мнению Джеймса, поэтому, можно сказать, что мы соавторы получившейся статьи.

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

________________________

Начните жить своим продуктом!

Джеймс:
Итак, вы оказались новым QA менеджером. Первое, что вам нужно сделать, это начать жить своим продуктов, загореться им.

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

QA-менеджер должен быть также увлечен своим продуктом, как и менеджер разработки, но нам нужно сдерживать нашу страсть доказательствами. Будьте уверены, что команда тестирования не прекратит тестировать функциональность, стоящую за жарким рекламным спичем.

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

К примеру, я сейчас живу без лаптопа и использую в своей повседневной работе только Chrome OS Netbook. Так как люди видят меня с ним в коридорах, мне доводится произносить рекламные спичи по многу раз каждый день. Великолепная практика, скажу я вам! Мне же доводится жить и с огрехами, и записывать штуки, которые ещё надо доделывать. Это хворост для пламени спора между разработчиками и другими стейкхолдерами, и это тоже заставляет меня взвешивать конкурирующие продукты. Когда у меня не получается сделать что-нибудь, что мне нужно, на моем Chrome OS Netbook и я вынужден использовать конкурирующий продукт, это порождает здоровую дискуссию о том, как пользователи воспринимают недостатки наших продуктов, и о том, как мы можем правильно преподнести плюсы и минусы нашего продукта потребителям.

И это прекрасный путь для начинания нового продукта, кстати ;-)

Юля:
Если вы приходите не просто в продукт, выпускаемый вашей компанией, а в новую компанию, начните жить вашей компанией. Её культурой. Поймите, почему она выпускает именно такие продукты. Чтобы приносить людям пользу, чтобы отвечать на их вопросы, чтобы решать их проблемы? Чтобы веселить их? Чтобы что?

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

Поняв, как это происходит на уровне всей компании, гораздо легче понять, как это работает для для вашего продукта. Вы поймете, кто в команде идет in-line с компанией, а чьи цели лежат в другой плоскости. Вы поймете, кто на вашей стороне (а вы ведь – именно тот человек, который хочет сделать ваш продукт лучше для пользователя и успешнее для компании, правда же?), а кого нужно ещё переманивать. На кого-то можно махнуть рукой, а кто-то просто мешает работе над продуктом. Это шанс улучшить ситуацию. Потому что вы - новый человек со свежим взглядом, и во-вторых – потому что тестирование – это фильтр.

Вы, как тест-менеджер всегда будете аккумулятором информации от менеджера, разработчиков, аналитиков и пользователей. Именно на вас сходится много дорог, и именно вы говорите менеджеру: «Эй, мы сделали классную штуку, этим ребятам понравится! К тому же, она не падает под тестами вот уже вторую итерацию», и именно вы приносите ему вести, рискуя цельностью головы: «Ты знаешь, вот эта новая фича не может выйти на стабильность вот уже 2 недели, постоянно ломает почтовую рассылку. Надо больше времени на отладку, давай не будем включать в релиз».

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

Фокусируйтесь на тест-плане, сделайте это высшим приоритетом

Джеймс:
Если вы заняли уже существующую роль тест-менеджера в уже существующем продукте, есть вероятность, что тест-план уже тоже существует и что этот тест-план неактуален. Я не наезжаю на вашего предшественника, я просто искренен. Большинство тест-планов являются «временными» документами.

Объясню, что я имею ввиду под этим.

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

Тестировщики очень любят жаловаться на это: «Как мы можем тестировать продукт без полного описания того, что он делает?»

Но разве не то же самое мы зачастую делаем со своими тест-планами? Мы наскоро клепаем тест-план, но как только мы начинаем писать тесты (автоматические или мануальные), как они начинают жить своей собственной жизнью. Довольно скоро тесты начинают расходиться с тест-планом, так как мы догоняем новые разработки или наш опыт подсказывает нам новый тестерский инсайт.

Тест-план стал в точности, как спецификация: Документ-Который-Был.

Юля:
Тест-план (как и все тестирование, конечно же), может работать на вас, а может на продукт. Иными словами, часто хочется применить все свои теоретические знания и накопленный опыт и отразить все предыдущие годы работы в документе под названием Тест-План-Всего.

Он будет оформлен по всем канонам, он будет включать сотни страниц, подробно объясняя его читателям каждый термин и расписывая каждую задачу. Но подумайте над тем, что, если вы не продаете тест-план как отдельную активность заказчику, то продукту чхать на термины и пропущенный пункт «Обоснование необходимости нагрузочного тестирования».

Продукту нужен рабочий тест-план. И всей команде нужен рабочий тест-план. Отлично, если ваш тест-план – это список модулей на доске и написанные маркером же рядом номера задач в таск-трекере и тегов в свне. Отлично, если актуализация вашего тест-плана – это merge еженедельномитинговых фоллоу-апов. Отлично, если он отражает суть вашего подхода к тестированию продукта и понятен любому члену команды.

Если вы делаете его для того, чтобы потешить свое чувство сертифицированного тест-менеджера – будьте честными в этом признаться. Хотя бы себе.

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

Разберитесь с процессом и приоритетами релиза

Поздний цикл предрелизного тестирования – это самая нервная часть всего цикла разработки. Тест-менеджеры должны поддерживать баланс между правильным тестированием и обеспечением гармоничного релиза. Я советую посещать все девелоперские совещания, но чем ближе к релизу – тем точнее вы не должны пропустить ни одного. Будьте очень внимательны к их беспокойствам и проблемам. Самые ужасные предположения имеют тенденцию претвориться в действительность. Добавляйте тесты в ваш набор проверок, чтобы убедиться, что эти сценарии не случатся.

Юля:
Будьте всегда готовы ответить себе, команде и инвесторам, почему этот баг встретился 20 процентам пользователей и породил тысячи петиций. Почему вы не наняли ещё троих тестировщиков, чтобы протестировать тщательно все области, а не только самые приоритетные? Почему вы держите именно такой баланс между знанием о качестве и затратами на его контроль? Почему вы в последний момент кинули все силы на эту область, хотя в недельной давности тест-плане она шла вторым приоритетом?

Главное, чтоб вы четко понимали это сами.

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

Я обнаружил, что в Гугле увеличение фокуса команды на мануальном тестировании искренне приветствовалось командой разработчиков. Найдите комфортную зону вашей команды разработки и удерживайте баланс между тем, чтобы всё-таки правильно тестировать, и тем, чтобы сделать финальные часы (дни) как можно безболезненнее.

Тестируйте ваш процесс тестирования

Джеймс:
Начните с чтения каждого теста-кейса и просмотра всей информации. Можно ли привязать эти тесты к тест-плану? Сколько тестов у вас есть на один компонент? А на фичу? Если баг находится за пределами процесса тестирования, создаете ли вы на него тест-кейс? Есть ли у вас процесс исправления или выбрасывания испорченных или неактуальных тест-кейсов?

Полноценность и основательность набора тестов – это ваша работа как QA менеджера. Вы можете не участвовать в написании или выполнении большого количества тестов, но они вы должны держать их все в голове и быть первым, кто выявляет прорехи. Это должно быть тем, за что новый менеджер возьмется с самого начала и должно оставаться ключевым для него всегда.

Юля:
Чем критичнее вы относитесь к своей работе, тем больше у вас права критично относиться к чужой. Считается, что тестировщик не должен ошибаться и не должен пропускать баги. В то время, как программисту вполне позволено их делать. Чтобы изменить это мнение, нужно действительно крепко тестировать не только работу программистов, но и свою собственную. Вы должны всегда видеть ещё возможности протестировать что-то лучше, тщательнее, если представится такая возможность. И вы должны четко понимать, от чего вы осознанно отказываетесь. И уметь объяснить это всей команде.

Чем более требовательны вы к своим тестам, тем более требовательными у вас получится быть к разработчикам.

Ищите пути для инноваций

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

Как новый менеджер, ваша работа – не дать им отделаться так легко! Вы должны сделать список тех частей процесса, которые вас настораживают, и тех частей, которые кажутся чересчур громоздкими или неэффективными. Это те места, где стоит применить инновации. Будьте готовы к нервозности со стороны разработчиков, но покажите, что ваши старания приносят пользу и заключите долгосрочное пари!

Юля:
Очень важно выдерживать баланс между «так у нас принято» и «я знаю, как сделать лучше». Когда вы приходите в новой роли в новую команду, у вас есть огромный плюс и страшное оружие: «свежий взгляд». Если его применять правильно – вы взорвете тестирование на проекте (в хорошем смысле). Будьте готовы столкнуться с «это не заработает, потому что…», «мы это пробовали, это фигня…», «да ну , бред какой-то, лучше делать по-старому…». Жизненно важно отличать реальные причины того, почему здесь делается именно так, от пустых отговорок, за которыми люди скрывают привычку и нежелание двигаться.

Если вы возьмете правильный опыт этой команды и дадите ему новое дыхание – будет бомба!

Джеймс:
Нет совета, который мне показался бы универсально применимым касательно "Как лучше внедрять новшества". Что работает для меня – так это найти звезд в своей команде и убедиться, что они работают над тем же, чем горят. Как менеджер, это одна самая важная штука, которую вы можете сделать, чтобы повысить продуктивность и внедрить новшество.

Юля:
Так что - дерзайте! И удачи вам.

ищу себе в команду волшебника (UPD: волшебник найден)

2010-08-17T05:58:00.001-07:00

Компания Иннова известна в России как локализатор и издатель онлайн-игр, таких как Lineage II, Aion, Atlantika, Point Blank и другие.

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

И вот, мы ищем коллегу в команду тестирования веб-приложений.

Мы ждём, что он (или она):

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

Дополнительными плюсами будет знание Unix, опыт настройки сетей, знание языка программирования.

С свою очередь, мы обещаем:

- профессиональную команду
- хороших и интересных людей в коллективе
- интересные задачи
- не мешать расти и приветствовать инициативу
- и разные плюшки от компании

Мы находимся на метро Павелецкая.

Писать мне на yulia DOT nechayeva AT inn DOT ru

Нам в www.it4business.ru нужен Программист

2010-07-29T01:00:00.000-07:00

Да-да, именно нам и именно в it4business. Мы со Славой Панкратовым решили поработать вместе!

И для создания нового звездолета социальной направленности нам нужен программист. Нет не так, нам нужен Программист - умный, в меру упитанный мужчина (мы верим, что большие люди - добрые люди, а доброта и терпение для Программиста в работе с нами это важный фактор, ага), который возьмет наши требования (3.5 страницы ворда), посмотрит на то решение, к которому надо прикрутить звездолет и скажет сколько времени и денег ему для этого нужно. Ну а потом возьмет и в указанное время все сделает. Мы, конечно, на все-все вопросы ответим и даже какие-то загадочные "доступы" дадим, ну или что там будет нужно.

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

Отзовитесь ссылками на свои работы, а мы пришлем требования.

И, да, нам ещё понадобится тестировщик :)

С аналитиками про тестирование

2010-07-27T02:12:00.000-07:00

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

И этой честной компании я рассказывала про тестирование требований:

Тестирование требований: Зачем - понятно, а вот Как?

View more webinars from greesha.

"Очень просто объяснить, зачем тестировать требования. Немного сложнее - убедить проектную команду, что это делать действительно нужно. Но когда доходит до дела – начинаются реальные проблемы. Я не знаю ни одной хорошей, понятной, удобной и эффективной методики тестирования требований. Я покажу вам те, которые известны и используются, и мы увидим их несовершенство.

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

Вот тут есть видео

О тестировании одной игры с картинками

2010-07-04T05:45:00.000-07:00

Мир геймдева для обитателей мира разработки «человеческого», как я его называю, софта, это что-то непонятное и сказочное. Тестировать гномов, заводить баг на эльфа, моделировать тестовое окружение для осады замка. Я рассказывала на SQA days 7, в чем специфика тестирования игр.

Недавно мы запустили Атлантику. Это игра от корейского разработчика NDoors, которую можно охарактеризовать двумя словами: ММОРПГ и пошаговый_бой.

Все, больше про саму игру ничего не будет. А будет про её тестирование.

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

Что тестировать в локализованной игре?

Как я уже рассказывала в своем докладе, тестирование игры делится на тестирование функциональности, контента и геймплея. Так как игра, которая локализуется, уже запущена в других странах (как минимум, в Корее, а в случае Атлантики – и в Европе, и в США), то геймплей мы считаем за наименее рискованную область. Потому что, во-первых, эта часть обкатана на продакшне в других странах, то есть количество ошибок здесь меньше всего, а во-вторых, эти ошибки в геймплее эффективнее оставлять на откуп игрокам бета-тестерам.

Поэтому мы тестируем контент и функциональность

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

Да, надо отдельно сказать, что, конечно же, для тестирования контента 100 уровня нам не приходилось неделями качаться, а для получения нужного квеста искать NPC (Non Player Character) по лесам. Имея аккаунт с определенным свойством в базе, получаешь доступ к инструменту администрирования, который позволяет сделать с существующим контентом игры практически все: перемещаться по координатам, призывать NPC, получать нужные предметы, оружие и одежду, повышать и понижать уровни, учить умения пачками и т.д.

Вернемся к тестированию

Типичный чек-лист для проверки выглядел так (на примере игрового предмета):

- предмет вызывается
- присутствует модель
- отображаемое название соответствует вызываемому предмету
- название не содержит ошибок
- название помещается при показе
- название соответствует модели
- предмет появляется в инвентаре
- информация о предмете соответствует названию
- информация не содержит ошибок (грамматических)
- информация отображается правильно (полностью, помещается в интерфейс)
- информация соответствует работе предмета (если написано +10 к защите – реально дает +10 к защите)
- правильное сообщение при невозможности использовать предмет
- предмет выкидывается персонажем
- правильное сообщение при выкидывании предмета
- другие связанные сообщения

Всё это выглядит в экселе примерно так:

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

Немного цифр

Та версия Атлантики, которую мы начинали тестировать, содержала около 2000 NPC и монстров, почти 7000 предметов, 500 локаций, около 800 умений, много интерфейсов и очень много квестов. Втроем этот объем осилили за 2 месяца (с перерывом на новогодние праздники).

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

Я бедный крестьянка, пустить ночевать, моя бежать долго-долго

Самый простой пример ошибки локализации – неверный пол. «When I was in Rome», говорит безликий ресурсный файл переводчику. «Когда я был в Риме», - басом говорят нам буквы с экрана. А на самом деле это хрупкая барышня.

Небольшое лирическое отступление о процессе перевода текстов игры. Он происходит в два этапа: сначала просто перевод, а потом редактура. В этих активностях участвуют разные люди, с разными специализациями. Но и те, и другие первоначально работают только с текстами. Так что реплика «Да вы что, промптом переводили?» - это на самом деле не минус переводчикам, а минус тестированию, которого, возможно, вообще не было.
Ни переводчику, ни редактору невдомек, что слово «Mammoth» может быть переведено иначе, чем «Мамонт», но глаза тестировщика явно видят баг:

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

Или, например, квесты, которые подразумевали ввод правильного ответа в текстовое поле.

Ответ, принимаемый программой, почему-то не был вынесен в ресурсные файлы, а был упрятан в код, поэтому квест, где нужно было дать ответ на вопрос: «А в каком городе Вы встретили Японского городового?» принимал поначалу ответ «Tokyo», что совершенно неочевидно для русскоязычного пользователя.

Переведите картинку!

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

Не всегда, кстати, исправления посвящались действительно ошибкам в прямом смысле этого слова. Например, сообщение ВАШ ХОД при переходе хода во время боя после обсуждения трансформировалось в ТВОЙ ХОД, что к тому времени с легкой руки наших дизайнеров стало слоганом игры.

Фикированная длина кнопки – головная боль игрового тестировщика

Отдельно прогонялись все интерфейсы, проверялось здесь правильное размещение надписей по элементам интерфейсов, соответствие надписи смыслу элемента, одинаковое название элемента в различных местах.
Вот, как выглядела книга информации об игре в первой версии:

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

Были и нерешаемые случаи. Например, для кнопки, смысл которой «Собрать одним действием все, упавшее со всех убитых врагов после боя», нам было выделено всего 7 символов. Даже самый короткий вариант, который приходил на ум «Взять всё» содержал аж 9 символов. Игроки тоже не смогли придумать подходящий вариант. Попытка обозвать это действие «Мародер» тоже ни к чему не привела. В итоге, эта кнопка так и называется "Обыскать всех", что откровенно не помещается в предназначенную для надписи область, но решили пожертвовать красотой в угоду понятности.

Я не знаю правил пер
еноса текста, ты во
обще о чем?

Изначально, все тексты в игре при переходе на новую строку просто рвали слово. В корейском языке слова переносятся по слогам (иероглифам), без дефиса и в любом месте. Мы были удивлены, узнав, что в Европе и США играют с такими переносами. Мы добились частичного исправления, и теперь в игре переносы в текстах диалогов с NPC реализованы по словам. Но, как видим, не везде.

Было	Стало

К слову сказать, тексты в чатах и системных диалогах Атлантики до сих пор рвутся на букве при окончании строки, так и не смогли это пофиксить.

Кавычки нам ни к чему

Или такой случай: имеем список из ~500 книг типа Книга «Смертельный выстрел», прочтя которую, персонаж обучается умению. В команде призыва предмета в игре при тестировании вводим полное название – получаем предмет без кавычек в названии.

Идем к редакторам, те в ужасе! Оказывается, от переводчиков пришли файлы без кавычек и ребята руками добавляли кавычки во все названия, чтобы соответствовало правилам русского языка, да и вообще, лучше воспринималось глазом. И вот, в игре ни одной кавычки. Проверяем в системе, откуда разработчики берут файлы для сборки билда – есть кавычки. В игре – нет кавычек. Выяснили, что на уровне игры все кавычки вырезаются, потому что их наличие приводит к проблемам.

Ресурсные файлы для слабаков!

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

Чаще всего, каждое упоминание термина содержало именно его название, а вовсе не ссылку на переменную. И одно и то же понятие вполне себе могло было быть переведено по-разному (переводчик-то не один):

Или так:

Локализация – это не только перевод

Специально для выпуска игры в России разработчики создали локации Москва и Санкт-Петербург. В них легко можно узнать знакомые архитектурные сооружения.
С локальными NPC сложнее, без подписей иногда трудно догадаться :)

Для того, чтобы опознать Курбского, придется дождаться, пока он перестанет делать facepalm:

Тестируем не только тексты

Плюс, конечно же, смоук-тест каждой сборки клиента (даже если он включает только исправления текстов). Такой смоук-тест содержит проверку основной функциональности игры и занимает 1-2 часа работы одного человека + полчаса групповой игры.

Меня часто спрашивают, зачем вы тестируете саму игру, если она уже давно в работе в других странах. Отвечаю: не думайте, что в остальных странах она без багов. Их там много, поверьте. Поэтому наше тестирование не лишнее.

И даже это не самое важное. Самое важное – баги сборки. Нет гарантии, что в следующей сборке не забудут положить папку с текстурами NPC в Москве, и игроки не будут бродить по пустынному городу в поисках хоть кого-то, кто дал бы им квест.
Нет гарантии, что новый билд правильно установится. Потому что малейшая ошибка в шифровании, чексуммы не сошлись, и сервер не видит часть своих компонентов.

Или даже вот такая штука:
В книге-информации об игре все описания NPC съехали на одну позицию. Внезапно. Смотришь крестьянина, а информация тебе показывается о Путешественнице – следующему по списку NPC. К слову, этот баг очень долго не могли исправить. Если я не ошибаюсь, больше месяца он продержался.

Помощь пользователей

Тестирование любой игры делится на 3 части: внутреннее тестирование, закрытое бета-тестирование и открытое бета-тестирование. Тестирование локализованной игры – не исключение.

Мы добавили ещё и до-ЗБТ, обозвав его альфа-тестированием. Пригласили на него опытных игроков в Атлантику, которые играли на европейских серверах и с удовольствием перешли бы на русские после их открытия.
Эти ребята нам сильно помогли отточить качество переводов. Только они могли подсказать, что правильный с точки зрения русского языка текст на самом деле содержит смысловую ошибку:

В итоге, за период альфа тестирования (2 недели) было найдено и исправлено 95 багов локализации и 31 баг самой игры.

Как научить пользователя правильно описывать баг

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

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

Закрытое бета-тестирование

После окончания фазы внутреннего тестирования, мы раздали аккаунты зарегистрировавшимся, открыли публичный сервер и началось ЗБТ.

В ЗБТ версии открыли + 20 уровней контента, поэтому основная масса ошибок пришлась именно на эту, неоттестированную область. Тем не менее, для проекта неправильно задерживать ЗБТ ради выкатки пользователям полностью «вылизанной» версии. Во-первых, им хочется поскорее, во-вторых, они хотят помогать! Здесь важно выбрать good enough, подходящий для аудитории данной игры.
Судя по отзывам наших бета-тестеров, мы оправдали их ожидания довольно высоким качеством.

ЗБТ – это такая стадия, в которой ещё находится много багов. Просто в силу закона больших чисел. Если 1000 игроков прочесывают все одно и то же, то вероятность, что они найдут баг, пропущенный одним человеком, очень велика.

Именно на этапе ЗБТ уже становится возможным выявить баги конфигурации сервера, например, что турнир начинается каждый день в 18-00 и заканчивается через 5 минут, если не набралось 10 участников (каждая цифра – это параметр), или что ограничение на охоту снимается в 6 утра только для персонажей, соответствующих определенным условиям.

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

Были и перлы. Естественно, мы не можем ограничить ни возрастной, ни образовательный уровень, ни уровень энтузиазма игроков, поэтому многие «баги» с форума так и не перекочевали в багтрекинговую систему.

Пропущен мягкий знак, сообщает нам пользователь – ну не знаком человек с высоким слогом:

Зато слог геймеров – это отдельный язык. Чего стоят баг-репорты типа:

- «хоть я и нуб,не умею ставить изображения,но в "Морской дворец" есть дыра,там где 1-ые боссы,адмиралы последите за ними,и 1 из них зайдет в то место,где находится дырка»
- «не берётся почта пробовал в разных разрещениях но всё равно»

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

Или вот ещё феноменальный отчет:

- «Не помню где и куда бежал - заметил что тень от дерева передвигается по мере моего приближения» - репорт без видео.

За период ЗБТ было найдено и исправлено 93 бага локализации и 22 бага игры.

Открытое бета-тестирование

Между ЗБТ и ОБТ последовал небольшой перерыв, так как готовили новый сервер, рассчитанный уже на другие объемы игроков.

ОБТ – это такой этап, когда уже могут играть все, кто хочет, но при этом игра ещё имеет право содержать баги. И игра в это время абсолютно бесплатная. Если у неё бизнес-модель абонплаты, то люди не платят подписку, если у неё модель free-to-play, и она зарабатывает на продаже внутриигровых предметов, то в этот период эти предметы в ней просто нельзя купить. В игру еще не встроен магазин и она не подключена к биллингу.

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

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

Итого за период ОБТ было найдено 36 багов локализации и 9 багов игры.

Лучший баг Атлантики за время ее тестирования

«Оставил чара на ночь АФК рыбачить. Был дисконнект по причине смены IP-адреса провайдером. С утра не смог зайти, выкидывало в окно логина при попытке подключиться к серверу.
Люди в игре сказали что мой чар он-лайн и продолжает рыбачить.»

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

Тестируем деньги

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

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

С Днем рождения!

И вот релиз. Сначала один сервер, а через 2 недели открыли второй.
После релиза тестировщики уже не общаются с игроками, потому что это уже не бета-тестеры, а пользователи. С ними общается служба поддержки. Она передает нам обращения пользователей, связанные с ошибками в игре, и дальше идет обычная работа с багом.

Чуть позже начнется работа по подбору и организции группы бета-тестеров, которые будут помогать нам тестировать обновления, но это потом.

Заключение

Это первый проект моей команды в Иннове, и, могу сказать, что мы провели тестирование хорошо.

Это мой первый в жизни игровой проект, подлежащий тестированию. Очень интересный опыт.

Я не рассказала здесь о тестировании сайта, о тестировании инсталлеров, о тестировании системы автоапдейта, о тестировании интеграции с защитой игры Frost, о тестировании скачивания клиента с файлоотдачи, о тестировании интеграции игры с биллингом, о конфигурационном тестировании, о тестировании реферальной системы, о выстраивании процесса работы с локализаторами и с корейскими разработчиками. Это все обычные для вас вещи. О них интересно было бы послушать игрокам. А вам я рассказываю штуки, которые банальны для них.

Конечно, мы решили не все проблемы. Вот некоторые из тех, которые остались:

- большое количество файлов в клиенте не способствуют быстрой скачке: 4 гиговый клиент содержит больше 30 000 тысяч файлов
- перенос слов в чатах и системных сообщениях по-прежнему осуществляется простым разрывом слова
- не переведены некоторые всплывающие во время боя сообщения: Bonus, Skill Up, Exp+ и т.п.
- не помещаются трехстрочные описания миссий, несмотря на наличие места в интерфейсе:

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

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

Живут, как тестировщик с программистом

2010-06-20T05:25:00.000-07:00

Часто задают вопрос: как быть с тем, что программисты не любят тестировщиков, считают их работу второстепенной, пишут неряшливо – «все равно ведь проверят» либо мстят за каждый найденный баг и пытаются не признавать их за баги.
Или наоборот, программисты жалуются, что тестировщики злорадствуют, найдя баг, и считают личным достижением, если программист наделал много ошибок.

Cтандартные в таких случаях советы: объясняйте, мирите, аргументируйте, - выглядят, как будто перед программистами оправдывают существование тестировщиков. Постфактум решать такую проблему (а это очень критичная проблема) очень трудно. Нужно закладывать правильную атмосферу при построении команды и носить это правильное отношение к работе за собой из команды в команду, из компании в компанию.

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

Конечно, все работают ради разного: кто-то ради зарплаты, кто-то ради решения интересных задач, кто-то ради получения бесценного опыта. Но для достижения личных целей нужно работать в направлении целей проекта, продукта, компании. Тогда будет и зарплата, и опыт, и интересные задачи. Судите сами, если бы целью программиста был выпуск качественного продукта, успех проекта, процветание компании, и он бы работал на это, то это бы просто автоматически работало на его личную цель. И при таком раскладе никогда не прозвучит «это не баг», потому что любое подозрение на баг таким специалистом принимается и рассматривается.

Как раз сейчас я краем глаза смотрю запись гран-при Канады Формулы 1.

Феноменальный пример слаженной, однонаправленной командной работы. Есть 2 части команды: собственно, перформер, пилот, человек, который на виду, который пожинает лавры в глазах публики, но который на каждой пресс-конференции говорит про работу всей команды, и есть та самая команда-тыл, которая смотрит на его работу на трассе, анализирует её и говорит в шлемофон: «Кубица сменил резину на жесткую, Барикелло тоже, не дай себя обойти». А теперь представьте, что команда отлавливает ошибки пилота и злорадно сообщает ему «Из-за того, что ты не сменил резину на прошлом пит-стопе, потерял 2 секунды во время дождя». Как только части команды начинают работать друг против друга – она обречена на провал!

Давайте посмотрим на команду разработки. Нам явно нужна классификация. Сначала хотелось назвать описываемых героев Хорошими Тестировщиками (или Программистами) и Плохими Тестировщиками (или Программистами). Потом подумала, что тогда в этом мире получится очень много плохого, а это не так. Поэтому у меня будут Просто Программисты (или Тестировщики) и Правильные Программисты (или Тестировщики).

Признаки того, что ваши программисты и тестировщики не Правильные:

- от тестировщиков звучат фразы «наколбасил им багов, пусть теперь разгребают»

Это идет от старших тестировщиков и от общей атмосферы в коллективе. Я ещё не видела ни одного неопытного тестировщика, который бы думал так с самого начала.
Если старший коллега хочет вырастить злобное чудовище, которое радуется при нахождении бага не потому, что теперь пользователь получит на одну ошибку меньше, а потому, что насолил программисту, то ему стоит продолжать в духе «Давай, сынок, покажем этим кодерам, что за какашку они выпустили бы без нас ». Но если он хочет, чтобы тестирование работало не против программирования, а совместно с ним на качество продукта, и ведет себя соответственно, то никогда в его команде не будет такого.

- от программистов слишком часто звучит презрительное «это не баг»

Это значит, что каждый баг воспринимается как личный тычок: «Это твоя личная ошибка, слышишь? Ты непрофессионал. Хорошие программисты пишут без ошибок, а ты баг сделал, эх, ты». Думаю, что здесь проблемы надо искать в личности такого специалиста. Адекватный человек, направленный на развитие, использует любую критику для совершенствования, а не для обид. Тем более, когда критикуют работу, воспринимать это как личную критику – выглядит как болезнь.

- программист не проверяет результат своей работы перед передачей в тестирование

«Моё дело писать код, а их дело проверять», «Ну а их-то зачем понанимали?» - можно услышать в таких командах. Это элементарное отсутствие гигиены, работа ради «отписаться». Где вы видели журналиста, который не перечитывает свою статью перед тем, как передать её в редактуру? Если в коллективе есть программист, который проповедует такой подход, его нужно как можно скорее ликвидировать. Какой бы он ни было классный специалист.

- тестировщики заносят баги, не интересуясь их дальнейшей судьбой

Это позиция «с моей стороны пуля вылетела» с другой стороны.
Цель тестирования – найти как можно больше ошибок в приложении, безусловно, имеет право на жизнь на определенных этапах тестирования. Только в этом определении не хватает второй части. Исправить. В силах тестировщиков донести важность важных багов до программистов и честно сказать про низкий приоритет низкоприоритетных. Если программисты знают, что их тестировщики зря хайприорити не поставят, то они серьезно относятся к каждому такому багу. А вот массированная атака багами без интереса к их дальнейшей судьбе, без подвижек в сторону облегчения их локализации, действительно является результатом работы только на себя.

- эффективность работы тестировщиков измеряется количество найденных багов, а мера качества работы программистов обратно зависит от этого количества

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

В то время, как только подход «максимум найти и тот же максимум обезвредить» эффективен, на мой взгляд, и работает действительно на цели продукта.

Уверена, что список можно продолжить.

При этом, чувствуете? В первом и четвертом случае корень проблемы в Просто Тестировщиках, во втором и третьем - в Просто Программистах, а в пятом - в Просто Менеджерах. Если у вас одна их таких ситуаций, смотрите, от кого исходит этот вирус и искореняйте его.

Тестирование игр: фан или тяжелый труд?

2010-06-15T10:11:00.000-07:00

Индустрия геймдева по очень нехорошей тенденции далека от индустрии разработки обычного, "человеческого" софта. Люди, работающие в этих двух мирах, очень редко переходят из одного в другой. Человек, поработавший в геймдеве, либо прикипит к нему всей душой и ни на что не променяет, либо сбежит отсюда очень быстро и никогда не вернется.

Попав в Иннову, компанию, издающую игры в России, я была поражена одной вещью: тут вообще не стоит проблема "как зажечь человека". Если ты не горишь сам - ты уходишь. Ты просто не выживешь. Ты обожжешься о многих других, которые любят свою работу, любят свои продукты. Саше Орлову здесь работы в этой области не найдется :)

Конечно же, очень явно для меня видны отличия в области тестирования. Об этом я рассказывала на SQA Days 7, которая проходила в мае этого года в Харькове.
Рассказать хотелось очень много, поместилось, как всегда, очень мало :)

А/Б сплит тестирование: что общего у оптимизаторов и тестировщиков?

2010-05-22T23:08:00.000-07:00

Попытавшись найти в яндексе информацию про A/Б сплит тестирование, обнаружила, что все ссылки ведут на сайты для оптимизаторов и "продвигателей" сайтов.

Ни одной ссылки на сайт для маркетологов, продакт-менеджеров или тестировщиков.А ведь это так замечательно вписывается в концепцию Business Driven Testing: инструмент, который позволяет понять, нравится ли пользователю то, что мы сделали?

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

Большинство из вас знает концепцию A/Б сплит тестирования как метод определения, какие из элементов на странице способствуют цели веб-страницы, а какие нет.
Например, типичным тестом является сравнение двух разных хидеров на главной странице. Один из них может превосходить по показателям другой, и – опа! – вы в курсе, как привести страницу к лучшей производительности (здесь под производительностью имеются ввиду маркетинговые показатели, дальше станет ясно).

На самом деле, с помощью A/Б сплит тестирования можно делать намного больше.

1) Можно использовать A/Б сплит тестирование для того, чтобы лучше понимать желания ваших посетителей и их приоритеты во время посещения вашего сайта;

2) Можно использовать A/Б сплит тестирование для решения специфических проблем с вашими страницами. Другими словами, у вас в руках инструмент диагностики, призванный показать, что не так и как это исправить;

3) Можно использовать A/Б сплит тестирование для того, чтобы в корне опровергнуть предположения, живущие в вас в голове, о том, как наилучшим способом разработать или написать страницу. (Здесь речь не только о тестировании минорных элементов, но также и о полном и кардинальном ре-дизайне всей страницы).

Тут встает существенный вопрос. Тестирование приносит значимые результаты только тогда, когда вы тестируете постоянно. Одиночный тест сообщит вам очень мало. Но когда у вас появляется «привычка» постоянно тестировать, собирать тесты со временем, это даст существенный взнос в успех вашего сайта.

Наши собственные результаты, перечисленные в этом рассказе, как раз показывают, как много может быть достигнуто и изучено с помощью «простого» А/Б сплит теста.

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

ТЕСТ1: Тестирование влияния Новостей на количественные показатели реакций на имейлы.

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

В имейле 1 мы написали «продажнический» текст в контексте эмоционально заряженной новости, которая заодно была и заголовком.

В имейле 2 мы написали текст без специального упоминания о событии, но все также ссылающегося на «последние события в новостях»

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

Мы протестировали нашу рассылку на 337 466 емейлах-участниках.
Мы подвели итоги после 12 дней, хотя клики продолжали потихоньку сыпаться и после.

Вот результаты после первых 12 дней:

Результаты тестирования имейлов
	Имейл A	Имейл Б
Послано имейлов	168 733	168 733
Кликов	5 119	4 395
Кликов к показам (CTR)	3.03%	2.60%
Продаж	175	122
Конверсия (Клики в продажи)	3.42%	2.78%
Конверсия (Имейлы в продажи)	0.104%	0.072

Что здесь нужно понять: Имейл А (специально упоминавший новость и события, связанные с ней) значительно опережает имейл Б. CTR вырос на 16,5%, а полная конверсия (имейлов к продажам) на 43,4%.

Имейл, раскрывающий суть данной новости, сгенерировал на 53 заказа больше (что означает 43,4% рост), чем имейл, который лишь ссылался на события, окружающие рассказ, без специфических упоминаний.

ТЕСТ 2: Тестирование определенной проблемы

В нашем втором тесте мы были уверены, что наши клиенты, посещающие наш сайт с 800x600 или 1024x768 разрешением монитора, не находили релевантных ссылок на продажи на основном сайте продукта до тех пор, пока не проскролливали страницу до самого низа.

Мы устроили A/Б/В сплит тест для тестирования этой гипотезы:

Страница А была оригинальной страницей.

Страница Б – содержала сильно укороченные данные и использовала «click here» текст, чтобы привлечь посетителей вниз страницы. Эта страница отображала процесс заказа на 1024x768 мониторе, а на 800x600 мониторе она показывала копию заказа основного продукта

Страница В была радикально переделана таким образом, что процесс заказа был частично виден на мониторах с разрешениями 800x600 и выше. Здесь использовались 2 колонки, чтобы сделать доступной больше информации «выше перегиба».

И вот результаты нашего тестирования:

А/Б/В сплит тест
	Страница A	Страница Б	Страница В
Процент показов	34%	33%	33%
Новых продаж	244	282	114
Изменение	N/A	15.57%	- 53.28%

Что здесь нужно понять: Страница Б превзошла первоначальную на 15,57%, страница В оказалась совершеннейшим фейлом.

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

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

ТЕСТ 3: Опровержение предположения тестированием «очевидного» и извлечение уроков из результатов.

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

В версии А мы добавили некоторые персонализированные элементы на страницу, включая фотографию автора, личное представление и подпись. Другими словами, мы создали личное «продажническое письмо» на веб-странице.

В версии Б продажнический текст был практически таким же, но без персонализированных элементов: ни фото, ни приветствия, ни подписи.

Какая же из версий выиграла? Общепринятая точка зрения нашептывала нам, что персонализированная версия выиграет. И вот результаты нашего тестирования:

A/Б сплит тест

Версия A (персонализированная)

Версия Б

(безличная)

Конверсия

34.6%

39.9%

Что здесь нужно понять: Версия Б превзошла версию А на 15,3%.
В этом случае, наши ожидания касательно выигрыша персонализированной страницы не оправдались.

И здесь нужно отметить 2 момента:

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

Во-вторых, это был всего лишь один тест. Что если бы мы взяли персонализированную страницу и удвоили бы её длину? А если ещё и добавить индивидуальную рекламку? Что если бы мы каким-нибудь образом изменили фото, или расположили бы её в другом месте на странице?

Ключевой момент: Каждый тест дает ответы. Но каждый тест должен также стимулировать на дальнейшие размышления и дополнительные раунды тестирования для выяснения нового.

Резюмируя А/Б тестирование:

Использовали ли вы А/Б тестирование раньше или нет, следующие шаги могут помочь вам формализовать обычный порядок тестирования и улучшить ваши результаты.

Правила А/Б сплит тестирования для «Landing Pages» (страница, на которую попадает посетитель клацнув на рекламу, либо перейдя по ссылки с результата поискового запроса):

1) Развивайте ваши возможности и выбирайте правильные инструменты.

Инструменты для А/Б сплит тестирования могут варьироваться от простых CGI скриптов до сложных приложений. Но, даже без сложных возможностей А/Б сплит тестирования, последовательные тесты – это возможность для вас открыть много нового про ваши страницы.

2) Определите вашу контрольную страницу.

Ваша контрольная страница будет той страницей, по отношению к которой вы будет тестировать всю последующую работу по оптимизации. Если вы только начинаете А/Б Тестирование, вашей контрольной страницей будет ваша текущая «landing page» до оптимизации. Когда новая страница превзойдет существующую контрольную страницу, тогда она станет контрольной в последующем тестировании.

3) Установите Цели и Параметры вашего тестирования.

Чего вы пытаетесь достигнуть с помощью А/Б тестирования? Вы гонитесь за подписчиками, за повышением конверсии или за увеличением ROI ваших PPC (pay-per-click) кампаний. Ваши цели будут определять ваши параметры тестирования, которые в свою очередь определят потенциальный успех ваших усилий по тестированию.

4) Определите ваш интервал «достаточности тестирования».

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

5) Создайте 1-3 радикальных редизайна.

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

6) Измерьте такие редизайны с помощью А/Б Сплит тестов.

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

7) Определите вашу новую контрольную страницу, базируясь на результатах.

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

8) С помощью традиционного Variable-Specific А/Б тестирования оптимизируйте переменные для тестирования:

Заголовка
Призыва к действию (call to action)
Картинок и графики
Цветов
Конфигураций элементов страницы и т.д.

Заключительные комментарии.

Вам нужно запомнить несколько важных моментов про A/Б тестирование:

1) Даже если вы не можете провести настоящий А/Б тест (где 2 версии страницы показываются одна после другой для разделения посетителей вашего сайта), очень легко провести последовательный А/Б сплит тест.

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

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

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

3) Тестирование предлагает компаниям неоценимую возможность произвести на руководство компании и менеджмент сильное впечатление предложенными изменениями для улучшения.

Убедить менеджмент на основании субъективной экcпертизы - само по себе является маловероятным. Но, если у вас есть ясные и понятные результаты тестирования, процесс убеждения становится намного проще.

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

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

5) Обеспечьте процесс тестирования ваших веб-сайтов и имейлов. В рассказе выше мы обозначили для вас правила «как начать». В дополнение, держите документ – шаблон для A/Б тестирования, который поможет вам вести процесс экспериментирования.

ABTestingTemplate.doc

Удачи!

Тестирование - это не просто тестирование

2010-05-03T23:04:00.000-07:00

Мой рассказ на Softwarepeople 2010, плавно перетекший в диалог со слушателями. Рассказываю, что тестирование может работать на успех продукта, а не только на корректность функциональности приложения.
Я уже очень давно думала про Business Driven Testing, и вот, наконец-то, собралась рассказать о таком подходе.

Тестирование - это не просто тестирование

View more presentations from Julia Nechaeva.

Прекрасное про обращение с багами

2010-04-14T08:44:00.000-07:00

Спасибо, Рома.

2 вебинара и 5 конференций за 3 месяца

2010-04-04T10:33:00.000-07:00

Сегодня утром, взглянув на количество стикеров с датами на холодильнике, я ужаснулась и поняла, что пора вести ивенттрекинговую систему. С планированием, комментариями, жизненным циклом, ответственными за определенные задачи и т.п. Мой первый план на 3 месяца вот.

8 апреля – я читаю вебинар на базе Software-testing.ru на тему «Работа с требованиями: Анализ, тестирование. Версия 2.0». Посмотрев на материалы и отзывы первого вебинара, я немного переработала структуру, добавила ещё 2 метода тестирования требований (в зависимости от формата их представления) и практически убрала из вебинара работу слушателей. Она все равно неуправляема, людям неинтересно работать в одиночестве перед монитором, не советуясь с коллегами, не обмениваясь шутками :) Поэтому всю практику я покажу своими руками на одном примере, а работу слушателей всю вынесу в домашнее задание. Вот у меня и появилось место для больше методов :) И домашнее задание тоже немного видоизменю, учтя пожелания слушателей предыдущего вебинара.

Кстати, если вы читаете этот пост, то с вероятностью 100 процентов организаторы дадут вам 10 процентную скидку на оба вебинара из серии «Аналитика для тестировщиков 2.0»

17 апреля – Training Labs, здесь я презентую этот же тренинг, но уже в живом виде. Тут будет минимум теории и максимум работы с аудиторией. Все с ног на голову – работать в классе, а теорию читать дома :)

22 апреля – второй вебинар из серии «Аналитика для тестировщиков 2.0» - «Работа с требованиями: управление изменениями».

22 апреля же, сразу после окончания вебинара я бегу на SoftwarePeople, где я рассказываю про то, как тестирование может влиять на успех продукта. Хватит уже отводить нам роль проверяльщика за программистом! Мы хотим приносить больше пользы! Мы не можем видеть, как прекрасный с точки зрения надежности и устойчивости продукт, в котором исправлены все баги с важностью выше, чем «вообще-вообще-неважно», оказывается никому не нужным!

Ну, и хочу послушать, что думают об этом люди.

23 апреля я просто слушаю доклады второго дня Softwarepeople": Саша Орлов, Сурен Самарчян, Стас Фомин, Гриша Печенкин, Сергей Архипенков, Влад Балин, Макс Дорофеев, Стас Давыдов, Костя Кондратюк, Стас Калканов, Асхат с Никитой… Я правда не знаю, как тут не разорваться.

13 мая я хочу поговорить о тестировании на Dev-Labs у Славы Панкратова в Киеве. Вот как раз думаю, о чем бы рассказать. Скорее всего, поделюсь своими мыслями о значимости тестирования на уровне всего продукта и с киевскими коллегами. Разумеется, уже учитывая опыт общения с московскими.

14-15 мая я в своем родном городе Харькове провожу 2 дня на SQA Days. Расскажу о том, чем работа в тестировании игр отличается от работы в тестировании «обычного» софта. И отличается ли вообще? ;-) Конечно же, буду присутствовать на таком значимом событии, как встреча организаторов Харьковского QA Club’a с питерскими активистами Ромой Твердохлебовым и Лешей Лянгузовым. Обмен опытом организации сообщества в своем городе – это что-то уникальное. Хочу также пригласить туда некоторых из своих бывших студентов, чтобы они посмотрели на все многообразие подходов и методик, проблем и задач, решений и озарений в тестировании.

И как член программного комитета совершенно официально заявляю, срок подачи докладов продлен до 15 апреля. Подача докладов приветствуется, благо – форматы разные, на любой вкус. А аудитория в Украине благодарная, ребята интересные, вы уж мне поверьте.

Май богат на события, 14-16 мая в Москве пройдет Конференция разработчиков игр 2010. Куда я не попадаю из-за моей верности профессии, а не отрасли =) Хотя, интересно безумно. Но туда пойдет мое Дневное Лицо большая умница Степа Корчагин, которому будет всучен диктофон и список докладов, которые надо записать.

5 июня я буду в Черновцах «тормошить IT-сообщество» города, по выражению пригласивших меня организаторов =) Зарождение профессионального сообщества – это всегда маленькое чудо и колоссальная работа. Надо поддержать ребят, которые задумали эту конференцию.

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

Swiss Testing Day отчет

2010-03-31T12:49:00.000-07:00

Конференция Swiss Testing Day проходила в Цюрихе, в здании Конгрессхауса, что сродни московскому Дому союзов, только современнный. Зайдя туда, я, если честно, удивилась. Мне показалось, что я попала на тусовку по случаю защиты докторской. Или, на крайний случай, прием по случаю назначения нового директора банка. Множество людей в костюмах, средний возраст где-то около 40.
Регистрация открывается в 8 утра, открытие конференции в 9. В 8-05 уже полно народу, который активно между собой общается.

Выставка спонсорских стендов. Это именно что выставка. Не стенд со скучающим человечком рядом, а ряд 2х2 секторов, в каждом из которых по несколько человек, монитор, материалы и конфеты-кепки-футболки =)

Открыл конференцию главный организатор Адриан Звингли, открыл на немецком языке, поэтому при всем желании, оценить его приветственное слово не могу. Но зал реагировал живо.

В 9-10 начал говорить Джеймс Виттакер. В течение почти часа Джеймс, размахивая руками и приводя примеры из области медицины, рассказывал о том, как они в Гугле подходят к тестированию. Он вообще непревзойден, на мой взгляд, в способности приводить жизненные примеры к тестировщицким ситуациям и проблемам. Задумываешься.

Доклад Building a Successful QA Organisation проводился в довольно необычной форме: парный доклад от руководителя подразделения компании, предоставляющей услуги по тестированию и контролю качества, и представителя компании-вендора, которая пользуется их услугами на протяжении 7 лет. Такой себе, двухсторонний взгляд на вещи. Докладчики рассказали об эволюции их отношений по цепочке: need based – reliability - trust - partnership.

Проработав в аутсорсинговой компании 4 года, я много знаю о построении отношений между командой тестирования и заказчиком. Но как-то очень мало задумывалась о стратегическом пласте аутсорсинга тестирования. О том, как найти заказчика, как понять его потребность, какие решения выбрать для него, что ему предложить, какому заказчику отказать, потому что «мы так не работаем» и как выбрать это самое «как мы работаем». Ещё миллион вопросов, от решения которых высшее руководство обычно заботливо укрывает тест-менеджеров. И тест-менеджерам лишь остается не подводить свое руководство =)

А тут рассказали именно о том уровне. О том, как однажды стало понятно, что нельзя продавать ресурсы, надо предоставлять услугу. О том, что принимать ключевые решения они оставляют вендору, давая ему все на то вводные. О том, как перейти от resource based модели к service based модели отношений с заказчиком.

И, все-таки, для того, чтобы построить успешные отношения в любой отрасли – нужна любовь =) (Егор Егоров, привет!)

Worldwide Testing - Join the Crowd. Это как раз то, что я сейчас внедряю у себя в компании. Бета-тестирование. Правда, у нас с Эвальдом немного неравные позиции =) У меня уже есть сотни тысяч пользователей наших продуктов, из которых можно найти нужное количество лояльных и готовых помогать. Но, тем не менее, у него эта практика достаточно успешна.
Не соглашусь с подходом докладчика, где во главе угла такого подхода он ставит дешевость такого метода.

Обратите внимание, что левый угол у него пустой. В то время как такой подход наоборот, главным своим профитом содержит именно ранний допуск пользователей к продукту, что для них очень ценно. Создатели продукта получают заранее лояльных пользователей – что может быть дороже?

То есть, это опять же, про любовь =)

Полуторачасовой перерыв на ланч, при условии, что Конгрессхаус находится в 150 метрах от озера… мммм =)

Ну и да, по возвращению почти к концу ланчу, обратила внимание на то, что еда ещё в доступе и неостывшая.

How we Test Software at Microsoft – Биджей менее эмоционален, чем Джеймс, да и вообще, Гугловцы кажутся более бесшабашными, чем Майкрософт. В плане новаторства и всяких интересных плюшек. Всегда интересно послушать,как это делают монстры. Применять ли - другой вопрос.

Why not use the Fast Lane to reach a higher Test Maturity Level? – про Model Based Testing и про тул, который разработали в Сименсе и успешно используют. Надо сказать, что это не первый доклад, который я слушаю про Model Based Testing, но это первый, который заставил меня об этом задуматься.

Четвертый доклад меня не порадовал, но скорее потому, что тема мне оказалась неинтересной, поэтому и писать ничего про него не буду.

Ну а потом, как вы уже знаете, было St. Patrick’s Day Party =)

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

St Patrick's Day in Zurich with celebrities in Testing

2010-03-18T03:12:00.000-07:00

Это жизнеутверждающий пост, которым я хочу сказать: не сдавайтесь, если чего-то очень хотите. Идите к цели, работайте в нужном направлении, показывайте миру, что вам это важно, и он откликнется.

Пишу этот пост на борту самолета Москва-Цюрих, в 16:40, 16 марта 2010 года. Лечу навстречу событию, которое должно было случиться больше 4 месяцев назад.

Днем позже, 17 марта, мне доведется посетить конференцию Swiss Testing Day, куда я попала приглашенным гостем по ходатайству Джеймса Виттакера, известной в тестировщицкой среде специалиста, который сейчас работает в Сиэттловском Гугле на должности Test Director.

Вечером того же дня, который ко всему ещё и День Святого Патрика, будет сделано это фото, которое показывает, что тестировщики тоже люди, тоже любят пиво и тоже ценят языческие праздники =) На ней слева направо: Биджей Роллисон (Microsoft), я, Тимур Хайруллин (Яндекс) и Джеймс Виттэкер (Google)

О самой конференции отчет я напишу обязательно, как только она закончится, а сейчас, пока лечу, хочу рассказать о том, как это все произошло. Такая себе, простая тестировщицкая сказка =)

А началось все в августе 2009. Когда Тимсон рассказал мне о конференции GTAC и дал линк на выступление Джеймса Виттакера на GTAC 09, тогда ещё он работал в майкрософте. Ну, мои отношения с конференциями вы знаете, да? (Начиная с 2008 года я побывала на 9 конференциях в области тестирования и разработки софта, выступила на 7, дважды была в оргкомитете и вот уже третий раз вхожу в программный комитет). Я очень ценю то, что на конференциях можно пообщаться с людьми, которые делают что-то, что меня интересует. Они делают это хорошо, и они готовы рассказать, как они это делают. А тут – Гугл, Виттакер, Цюрих, АААААААААА…...

По правилам GTAC 09, регистрация происходила в течение августа, принимались заявки до 28 августа, затем в течение нескольких дней оргкомитет рассматривал их и, начиная с 3 сентября, рассылались утвержденные приглашения и отказы.
Я была просто уверена в том, что получу подтверждение, ведь при подаче заявки я расписала свою активность в русскоязычном сообществе тестировщиков в графе «Why do you think you should get the GTAC conference».
И вот, 4 cентября я получаю письмо с текстом «Thank you very much for applying to attend GTAC 2009. Unfortunately due to an overwhelming response we do not have a place for you this year». Это, правда, было очень неожиданно. Хорошо, что у меня большой монитор, который скрыл мои эмоции от коллег.

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

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

«Let me explain why I’m striving to get GTAC……………………………………………

The main purpose of GTAC is to give people an opportunity to share their experience and knowledge on testing field. You really do a great job. Thanks for this.
I do the same for Russian-speaking testers. I often speak at different conferences and seminars because I do see a lack of lore in testing community. I am sure that we should communicate more with each other, speak about our problems and ideas and get common solutions…………………

My contribution in it is organizing a conference for Russian-speaking testers. I am a member of Organizing Committee of ‘Software Quality Assurance Days’ conference that is the biggest event for QA and QC engineers all over ex-USSR area………………….

We give a chance to our testers to find people who are also hands-on with testing and to swap their knowledge……………………………………………………

So we are working in the same field with you. I do believe that there are a lot of things I can learn from you. Also I’m sure that you are happy with such events and communities existing. We work hard to let people work easier…………………………………………………

So I’d like to ask you to review my request for getting GTAC one more time. I hope that you let me participate it because grain of knowledge I’ll get there will be planted into fertile ground. I promise.»

Однако же через 2 дня я получаю отрицательный, но, надо отметить, достаточно человечный ответ от организаторов:

«Julia - thank you for your enthusiastic plea for re-consideration - unfortunately, we decided on the participants and waiting list, have informed all of them, and will have to see what level of cancellation there will be - so far, very very few have declined the invites.»

Ненене, ребята из гугла. Вы, наверное, не понимаете, как я хочу попасть на эту конференцию =)

Но я знаю, кто может понять.
Джеймс Виттакер. Ну конечно! Не может такой клевый и здоровский дядька не отреагировать на мое желание. Тем более что он к этому времени уже стал Test Director в Google. Тем более что он наверняка будет там выступать. Раздобываю его контакт, и мое следующее письмо летит к нему. Виттакер ответил на следующий день. В достаточно дружеском тоне он написал, что

«I am sorry you didn't get accepted to GTAC, but I understand that the number of applicants this year was exceptionally high. As it turns out, I am not going either as I have a product release I have to attend to here in Seattle.
Thanks for the note. I enjoyed reading is and am glad to see the passion you have for this discipline. I hope we'll meet in person some day.»

Я отвечаю спасибо, поздравляю его с Днем тестировщика (дело-то происходит 9 сентября) и уже складываю оружие, как вдруг получаю письмо от Джеймса, в котором он пишет 2 вещи:

1 – «The closest I will get is Norway in February where I'll be speaking. As that conference gets closer I will be sure and update you.»

2 – «My new book is out now and I'd love to get it translated. (Речь идет о его книге Exploratory Software Testing.) Any chance you can make it to Norway in February? I'll forward details of the conference when I get them. I'll also be visiting our Google office in Switzerland on that trip as well.»

Тут уже монитор меня не спас =) Да и зачем было скрывать мои эмоции =)

Забегая вперед, скажу, что с переводом книги ничего не вышло, так как правообладатель, с которым меня свел Джеймс, в довольно сухой форме проинформировал меня, что они не работают с переводчиками, а лишь передают права на издание книги локальному издательству, и те уже сами решают вопрос с переводом. На мою просьбу порекомендовать меня в качестве переводчика издательству, с которым они будут сотрудничать на предмет издания книги в России, менеджер издательства-правообладателя посоветовал мне поискать предложения по работе переводчика на сайтах российских издательств =)

Тут Виттакер был бессилен. Но зато наше общение вылилось в перевод цикла его статей «7 пороков тестирования», которые опубликованы в моем блоге и на software-testing.ru. Кстати, перевод первой статьи я выложила как раз в первый день GTAC 09, как бы в отместку =)

Вяло обмениваясь письмами в режиме 1 письмо в неделею с темой «ещё одна статья переведена и выложена» - «Oh, great, thank you», я полностью успокоилась, и меня греет финальная фраза в последнем письме от организаторов GTAC «we're looking forward to hopefully seeing you in one of the upcoming GTACs in the next years!»

И вот, 23 ноября, я получаю письмо от Джеймса :

"
It's looking likely that I will be a keynote at the Swiss Testing Days in Zurich on March 17. I am sure I can pull some strings and get you involved in the Zurich event. "

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

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

И ещё – прислушивайтесь, пожалуйста, вдруг вы можете помочь тому, кто кричит неподалеку =)

Спасибо,
А я буду дальше любоваться облаками =)

День знаний от Лаборатории качества - отзыв злого полицейского.

2010-03-08T09:34:00.000-08:00

20 февраля посетила День знаний от Лаборатории Качества. Попала туда по приглашению, с предложением послушать, оценить и написать отзыв. С опозданием, но все-таки пишу.

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

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

Сразу вопрос к ребятам-организаторам: на кого были рассчитаны доклады? Целевая аудитория хотя и была объявлена, но, боюсь, не понималась самими тренерами. Попытка сделать как можно обобщеннее сыграла злую, хотя весьма предсказуемую шутку.

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

При этом совершенно очевидно, что докладчик тему знает, на вопросы, которые я задавала с целью расширения scope доклада, отвечал хорошо, правдиво и интересно.

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

В итоге получилось непонятно, на кого этот рассказ был рассчитан:

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

- На тестировщиков-извините-обезьянок, которые попутно ещё и тесты поддерживают, а не только их проходят? Так им этого и знать не нужно, им ставь задачу – расширяй здесь, они и расширяют. Ну и, я не думаю, что ребята из ЛК рассчитывали увидеть таких на своем мероприятии.

- На тест-дизайнеров? Так любому тест-дизайнеру (неважно, выделенная это должность или просто одна из исполняемых ролей) все сказанное и так известно. Если же не известно и он пришел этому учиться – то В ПЕРВУЮ ОЧЕРЕДЬ нужно было рассказать, откуда эти изменения берутся и как их обрабатывать.

Я бы поняла, если б Саша хотел ПОКАЗАТЬ ребятам, как поддерживать и улучшать тесты, но тогда нужно было бы проводить реальный тренинг и учить их делать это руками. Выдавать тесты, выдавать условия, показывать, как надо, а потом предлагать делать самим и советовать. Голая же лекция, я ещё раз повторюсь, непонятно, кому предназначалась.

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

Павел Трубников… Человек явно не из тестирования, потому что с причинно-следственными связями в докладе (а это опять же был доклад, а не тренинг) было туго. Доклад для менеджеров почему-то все время сводился к тому, как найти работу.

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

Тем более, что это ну никак не соответствовало заявленной теме доклада. Если же Вы рассказываете для тех, кто только собирается стать профессионалом, то НЕЛЬЗЯ в голом виде подать за 30 минут всю сложность поддержания мотивации у сотрудников, которой им придется заниматься в будущем. Превратное мнение о том, что менеджер ДОЛЖЕН ДЛЯ ВСЕХ делать задачи интересными вырождается в неправильное поведение будущих менеджеров с их командой.

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

Павел начал свой доклад с того, что «я не пророк, и моё мнение не единственно верное», закончил же проповедями «забудьте о материальной мотивации», за что и был пойман аудиторией и окончательно запутан =) Уважаемый Павел! Как раз люди, которые отвечают лишь за сроки своей работы, никогда не смогут сделать продукт лучше, они смогут лишь сделать его так, как им сказали.

В общем, здесь все наоборот, слишком широкий замах, попытка смешать как минимум 4 серьезные темы в одну, при этом, не показав пути айтишника как такового.
Ну и в компетентности в области человеческой мотивации заподозрить тренера не могу.

Наташа Руколь – интересный докладчик. Если бы можно было разделить её харизму на всех – всем бы хватило и было бы веселее =) Озвучен прекрасный менеджерский подход «показывать общую картинку и место конкретной задачи в ней».

Судя по всему, тренера доклады друг друга не тестировали, иначе Наташа нашла бы критический баг в докладе Саши Федорова – несоответствие этому требованию.

Но к заявленной теме доклада все, рассказанное Наташей, относилось опять же слабо. Очень размытые понятия никак не ложились на тест-дизайн. Либо это рассказ о том, как повысить личную эффективность (непонятно, кстати, зачем), либо это заявленная тема о том, как этот скачок поможет лучше управлять тестированием. Под каждый пример можно было нарисовать конкретную задачу из тест-менеджмента и наглядно показать профит.

Доклад Михаила Давыдова послушать не получилось - убегала собираться на самолет.

Совет ребятам на будущее – четко определяйте целевую аудиторию, которую вы хотите учить, и понимайте, что она уже знает, а о чем ей нужно ещё рассказать. И обязательно приподнимайте завесу уровня (а то и нескольких уровней) выше. Ведь тестировщику, которого учат правильно описывать баги, нужно знать, как тот или иной баг повлияет на конечное качество продукта; тест-дизайнеру, пишущему тест, нужно понимать цели тестирования на каждом этапе; тест-менеджеру, принимающему решение о расширении тестового покрытия, нужно понимать, откуда взялось это дополнительное время на тестирование в проекте и что рассчитывает этим выгадать менеджер проекта. Если этот менеджер, конечно, заинтересован в успехе проекта, а не работает лишь за «сдать в срок» =)

А если в докладах ещё и будут раскрываться заявленные темы – то цены такому обучению не будет.

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

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

Жду отзыва от Ромы, который скрасил мне галерку =) Кстати, Рома готовит презентацию про классификацию тренеров, coming soon.

Ага, вот ещё, что. Нашла Очень Положительный Отзыв (тм). Хочется задать вопрос очень простой вопрос автору: чему Вы научились на тренинге?

Собственно, вот.

Тестирование для не-тестировщиков

2009-12-24T05:52:00.001-08:00

Чуть больше месяца назад, 19 ноября, ещё находясь в Харькове, я провела вебинар, организованный УЦ Люксофт, "Тестирование для не-тестировщиков". Вебинар совершенно нетехнический и очень философский. Моей целью было не передать знания и не научить, и лишь поделиться мыслями и подтолкнуть слушателей к размышлениям. Выводы каждый сделал свои.

Расшифровку выкладывать отдельно не буду, а хочу сделать цикл постов на основе материалов этого вебинара. Будет, чем заняться на каникулах :)

Описание вебинара под слайдкастом.
Приятного прослушивания.

Тестирование для не-тестировщиков

View more presentations from jnechaeva.

Тестирование

1.1 Вид сверху.

Общепринятые определения и что за ними стоит на самом деле. Анализируем.
Делаем выводы, чем чревато следование определениям.

1.2. Вид с разных сторон.

Взгляд программиста. Взгляд менеджера. Взгляд руководителя. Взгляд
тестировщика. Взгляд программного продукта :)
Анализируем. Находим общее видение.

1.3. Каким может видеться тестирование с разных сторон.

Плохим. Хорошим. Полным. Недостаточным.
Анализируем. Делаем выводы, что одного эпитета мало.

1.4. Делаем вывод, что тестирование – это часть процесса разработки программного обеспечения, которое в совокупности с действиями остальной проектной команды помогает повысить качество программного продукта.

1.5. А только ли повысить?

Измерить. Подтвердить. Опровергнуть предположение. Да практически все, что угодно.
Различные цели тестирования.

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

2. Какое тестирование нужно.

2.1. Что нам нужно проверить?

Что работает правильно? Что работает быстро? Что такое правильно? Что такое быстро?
В итоге понимаем, на основании чего ставить цели тестирования.

2.2. Виды тестирования в разрезе постановки целей.

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

3. Кто должен тестировать?

3.1. Ну, разумеется, тестировщики.

У них есть умение, навыки, знания, окружения, в конце концов, им за это платят.

3.2. Почему не программисты? - «Мы и так пишем хороший код, давайте покажу, что все работает».

Плюсы выделенного тестирования.
Программисты должны программировать!

3.3. Почему не менеджер? – «Я же лучше всех знаю, чего хочет заказчик»

Плюсы выделенного тестирования.
Оставьте менеджеру менеджерово!

3.4. Так почему же все-таки программисты? «Зачем нам тестировать перед сдачей кода? Пусть тестируют тестировщики»

Плюсы пре-тестирования разработчиками.

3.5 Так почему же все-таки менеджер? «Зачем мне прогонять аксептенс, если тестировщики уже все протестировали?»

Плюсы пост-тестирования менеджером.

Выводы:
Главное в тестировании (если это не просто поиск ошибок) – это определить его цель и сообщить о ней всей проектной команде. Тогда каждый сотрудник будет вносить свой вклад в качество программного продукта.

Целевая аудитория

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

- менеджеры, которым «навязали» тестирование, но не объяснили, зачем это, что это и что должно получиться на выходе, какого результата от них ждут. И это действительно «мертвый груз» в проекте, потому что тестировщикам также не объяснили;

- программисты, которых начальство «заставляет» тестировать, в то время как всем давно известно, что «тестировать должны тестировщики»;

- руководители и менеджеры, которые хотят объяснить:
---- программистам, что им тоже нужно тестировать;
---- программистам, что тестировщики – их соратники;
---- тестировщикам, что они – соратники программистов;
---- менеджерам, что им делать и чего ждать от отдела тестирования;
---- новоиспеченному отделу тестирования, что их задача не «воевать с программистами» и не «просто находить ошибки»;

- тестировщики, на которых возложили «обеспечивать качество продукта» и с них за это качество и спрашивают, не объяснив, что они должны для этого делать;

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

Конференция Agile Days - отчет

2009-12-21T04:36:00.000-08:00

Недавно (9 декабря) посетила конференцию AgileDays, которую делали ребята из ScrumTrek. По этому поводу хочу немного отчитаться :)

Никита Филиппов рассказал про базовое - Обзор Agile . Нужно всем конференциям перенять фишку: делать 1-2 доклада про азы. Потому что часть людей приходит затем, чтобы посмотреть, что такое аджайл (в других случаях – что такое тестирование, что такое анализ требований и пр.), и им нужно это дать, им нужно об этом рассказывать. Потому что им рано и зачастую опасно слушать про техники и инструменты, не понимая общего смысла и цели подхода, не зная основных определений, не понимая исторических особенностей возникновения той или иной техники. Задавать же вопрос «почему вы сделали так?» на докладе, который предполагает базовые знания в этой отрасли – вроде как некомильфо. Так что Никита полностью угодил своей целевой аудитории.

А вот Андрей Бибичев учел разброс в слушателях и сделал экскурс в историю возникновения описываемых им техник FDD и DDD, и рассказал как о причинах их рождения, и о проблемах, которые решили с их помощью их авторы, так и о том, какие проблемы решает он сам использованием этих методик. Здесь можно было как узнать для себя новое, так и сравнить свой подход с подходом команды Андрея. И все это на фоне завсегдашнего бибичевского юмора, когда непонятно, над кем же он сейчас на самом деле смеется: над слушателем, над методикой или над собой.

Женя Курышев покорил меня (и зал, судя по отзывам) очень легкой подачей experience report’а о том, как яндексоиды внедряли скрам в Моем Круге. Как и все, что делает Яндекс, это делалось для людей и облегчения их работы. То есть, самый правильный подход: процесс для работы, а не работа для процесса. Нужна доска – пожалуйста, сорвали 6 пробковых плиток с потолка – получили доску стоимостью 48 рублей. Распределенные команды – не вопрос, давайте юзать виртуальную доску. Не можем прийти к соглашению – давайте позовем стороннего эксперта, но тогда уже его мнение будет финальным. Вобщем, интересная история на фоне картинок про бакланов – зачет!

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

Очень хотелось попасть на доклады Максима Гапонова, Леши Кривицкого и Наташи Трениной, Стаса Фомина, Артема Марченко. Жду видео.

Что касается организации – то кроме кривоватого сайта (за что команда организации уже выслушала немало :)) и отсутствия внятных указателей на первом этаже, куда людям идти, я даже знаю, что ещё мне не понравилось. Ну да, иногда не хватало стульев, но аншлаг в зале – это признак качественного доклада. Ну да, далековато добираться, но зато – хорошее помещение и близко от метро. Ну да, не дарили кресла-мешки от mail.ru, но зато на них можно было валяться и работать. Пароль от вайфая ybrjveytcrf;e – это вообще, шедевр :)

Как и любую конференцию, я, в первую очередь, оцениваю по тому, вынесла ли я с неё что-то новое? Знакомство с Артемом Марченко, Светой Топольской, Димой Лобасевым (наконец-то), Женей Курышевым, штук 20 различных идей и мыслей в блокнотике, доделанный на кресле-мешке вебинар, я считаю – хороший результат.

Плюс общение с уже знакомыми мне интересными людьми. Компания подобралась хорошая. Асхат, Ира и Никита умеют собирать людей :)

И это все несмотря на то, что на месте конференции я была уже в 7 утра, так как вызвалась помогать на регистрации.

Вебинар "Работа с требованиями: анализ, тестирование" состоялся. Отчет.

2009-12-10T11:36:00.000-08:00

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

Структуру я построила таким образом, чтоб индукторам было легко сразу, а дедукторам не пришлось долго ждать, чтоб включиться. Поясню. Есть такое понятие в методиках обучения взрослых людей, как Цикл Колба. Для того, чтобы взрослому человеку обучиться какому-либо сложному навыку максимально эффективно, то он должен пройти по четырем стадиям:

При этом разным людям удобно включаться на разных стадиях. Кому-то нужно сначала выслушать теорию, а кому-то - сразу пощупать, а потом понять, почему оно на ощупь такое.
Напомню, что индукторами (к коим и я отношусь) я называю вторых, а дедукторами - первых.

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

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

Второй этап был теоретический:
1. Что такое требования. Методы их фиксации.
2. Какие бывают требования
3. Что с ними можно делать.
4. Где здесь тестирование. Зачем нам это?
5. На что тестировать? Критерии хороших, качественных требований.
6. Методы тестирования требований
7. Заключение

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

И получили домашнее задание.

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

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

7 plagues of Software Testing by James Whittaker - The plague of Entropy

2009-12-06T03:28:00.000-08:00

Порок энтропии.

Оригинал

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

Чем более неопределенные события вам приходится рассматривать, тем выше карабкается мера энтропии. Люди часто думают об энтропии как о мере случайности: чем более неопределенные события рассматриваются, тем более случаен их результат.

Тестировщики привносят энтропию в разработку добавлением ряда вещей, которые следует сделать разработчику. Когда разработчики пишут код, энтропия мала. Когда мы заводим баги, мы увеличиваем энтропию. Баги отводят внимание разработчиков от кодирования. Теперь они должны работать параллельно и над созданием, и над починкой фич. Чем больше багов, тем больше параллельных задач, и это повышает энтропию. Энтропия – одна из причин, почему баги вызывают ещё больше багов: принцип энтропии обеспечивает это. Энтропия порождает энтропию! В конце концов, математика показывает нам то, что и так интуитивно понятно: предотвращение круче лечения.

Как бы там ни было, мы ничего не можем сделать, чтобы полностью предотвратить порок энтропии, кроме как создать разработчиков, которые никогда не ошибаются. А раз это маловероятно, мы должны определять, как и когда мы сталкиваемся с энтропией, и делать все, что в наших силах, чтобы ею управлять. Чем больше мы сможем сделать во время разработки, тем лучше. Помогать в code review, вводить наших разработчиков в курс тест-планов, пользовательских сценариев и окружений, чтобы они могли кодировать с меньшим количеством багов, которые нам пришлось бы рапортовать. Выкуривать баги как можно раньше, заводить их пачками и быть уверенными, что мы создаём только высококачественные баг-репорты, причесывая их самостоятельно, концентрируя тем самым мысли программистов на разработке. Написание хороших баг-репортов и быстрая проверка исправлений удержат внимание разработчиков там, где ему положено быть. Фактически это максимизирует определенность «разработчицких событий» и минимизирует количество и влияние багов. Энтропия, таким образом, сходит на минимум

Мы не можем отогнать этот порок, но мы можем определить привнесение энтропии в разработку и согласиться с неминуемым влиянием на качество кода; мы можем держать её под контролем.

Познакомлюсь с тестировщиком. Москва.

2009-11-27T05:06:00.000-08:00

Я ищу к себе в команду инженера по контролю качества с опытом работы в тестировании не менее 2 лет. Не Гербалайф =)

Компания Innova Group.

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

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

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

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

Большим плюсом является опыт в применении автоматизированного тестирования.

Условия, предлагаемые компанией:
- Официальное оформление по ТК РФ
- Работа в офисе
- Занятость - полный рабочий день
- График работы: пн-пт, 10:00 - 19:00
- Работа в передовой и активно развивающейся компании

Зарплата по результатам собеседования и заведомо не ниже рыночной.

Мой контакт: julia.lorien DOG gmail DOT com

7 plagues of Software Testing by James Whittaker - The plague of blindness

2009-11-24T13:19:00.000-08:00

Порок слепоты

Оригинал

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

И есть множество аспектов тестирования программного обеспечения, которые скрываются в этом невидимом диапазоне. Программное обеспечение невидимо само по себе. Мы видим его только сквозь UI, а многое из того, что происходит, скрыто под покровом и находится вне области обзора. Это совершенно не похоже на производство автомобиля, где вы можете четко увидеть недостающие детали, и где множество инженеров могут смотреть на автомобиль и видеть одно и то же. Не возникнет спора о том, установлен ли бампер на машину, ведь это очевидно для любого, кто смотрит на неё. С программным обеспечением, которое существует как магнитные колебания на носителе данных, всё иначе. И это не способствует наглядности.

Тестирование во многом, как и прохождение видеоигры с завязанными глазами. Мы не можем видеть баги, мы не можем видеть покрытие, мы не можем видеть изменения в коде. Эта информация, такая ценная для нас, тестировщиков, скрыта в бесполезных статистических отчетах. И если кто-то повяжет нам на глаза настоящую повязку, мы можем даже не заметить этого.

Слепота касательно нашего продукта и его поведения создает весьма ощутимые проблемы для тестировщиков. Какие части приложения более всего были подвержены юнит-тестированию? Какие части были изменены со сменой одного билда на другой? Какую часть программы покрывает этот конкретный тест-кейс? Какие части были протестированы тщательно, а каким вообще не было уделено внимания?

Нашим народным средством от порока слепоты всегда было измерение покрытия кода, API-метод покрытия или UI покрытие. Мы берем вещи, которые видим лучше всего и измеряем их. Но действительно ли они что-нибудь нам говорят? Мы делаем так годами не потому, что это приоткрывает завесу, а потому, что это все, что позволит нам сделать наша слепота. Мы очень много взаимодейстуем с нашим приложением посредством тестов, но мы должны полагаться на другие, менее конкретные чувства для любого фидбека о нашей работе.

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

Ловушки заказного тестирования

2009-11-23T01:06:00.000-08:00

Моё выступление на совместной конференции SEC(R) 2009 + SQA Days 7.
Про отношения :)

Ловушки заказного тестирования

View more presentations from jnechaeva.

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

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

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

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

Таким образом, получается, что все эти проблемы имеют две стороны: заказчик не понимает, почему, а аутсорсеры не понимают, как заказчик может не понимать.

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

СТЕРЕОТИП ПЕРВЫЙ: ЖАДНОСТЬ

«Жадные аутсорсеры пытаются раздуть бюджет» - «Жадный заказчик не хочет платить лишнее».

В каких случаях команда тестирования может сообщить, что необходимо дополнительное время на тестирование? Может, если действительно хочет раздуть бюджет, а может, если это время на тестирование действительно нужно. По каким-то внешним причинам не вложились в заявленные сроки: увеличился объем тестируемой функциональности, поздно закончилась разработка, долго выясняли требования, и т.п. Команда говорит: «Нужно ещё 3 дня на тестирование». Заказчик говорит: «Не нужно, продукт работает, я сам видел».

Прецедент создан, стереотип родился.

Что делать команде тестирования?

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

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

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

Что делать заказчику?

- Слушать объяснения команды тестирования.

- Заранее определять критерии окончания тестирования и приемки продукта.

СТЕРЕОТИП ВТОРОЙ: ЛЕНЬ

«Команда не создает формальную документацию» - «Заказчик требует отчетов, но не хочет за них отдельно платить».

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

Прецедент создан, стереотип родился.

Что делать команде тестирования?

- Тест-план и тестовую стратегию писать всегда. Это документ, который должен быть согласован с заказчиком и командой разработки. Даже если заказчик не платит за эти активности отдельно, это не так дорого, чтобы не создать их. Это огромная экономия в будущем.

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

- Если тестовая стратегия не предусматривает создание тест-кейсов и формального тестирования, то это не повод не фиксировать, что же, собственно, и как тестируется. Даже эксплорейтори тестирование предполагает запись сценариев, осуществленных в ходе тестирования. На этом нельзя экономить время. Потраченное сейчас на запись сценариев – воздастся вам позже при регресионном тестировании. И у команды всегда будет готов ответ на вопрос «А что и как вы тестировали?»

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

Что делать заказчику?

- Утверждать тест-план и тестовую стратегию. Не на глазок, а вдумчиво. Хорошая команда всегда объяснит, почему было принято решение идти именно этим путем, и почти всегда сможет предложить другой вариант, если первоначальный заказчика не устроит. Хорошая команда всегда объяснит, чем чревато ускорение либо отказ от части активностей.

Заказчик должен быть уверен, что он экономит свои деньги разумно.

СТЕРЕОТИП ТРЕТИЙ: ТУПОСТЬ

«Команда маускликеров» - «Покажите мне сертификаты».

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

Прецедент создан, стереотип родился.

Что делать команде тестирования?

- Создавать артефакты тестирования, показывающие всю мощь работы разума тестировщиков.

- После того, как заказчик будет поражен глубиной и объемом задач по тестированию, объяснять ему, что исполняют задуманное те же специалисты, которое все это и написали. Что тот гений, который придумал эти сценарии, он же садится в другой момент, и руками настраивает среду либо фиксирует ошибки. И что ручной труд в тестировании не менее важен, чем тот, который кажется заказчику творческим. Что мало просто прокликать по кнопкам, а нужно ещё и проанализировать результаты и сделать соответствующие выводы.

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

Что делать заказчику?
- Просить аргументацию выбора специалистов именно такого уровня квалификации.

- Настаивать на более высоком, если очень хочется и готовы платить, не воспрещается.

Именно тот факт, что эти проблемы не решаются, и создает те превратные стереотипы о «жадных аутсорсерах» и «неадекватных заказчиках». Заказчики и аутсорсеры должны вместе работать над их разрушением.

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

Ссылки для смеху:

[1] Glenn Livingston, «Outsourcing Sucks, Delegating Sucks, Unless… »

[2] Niyaz PK, «Why Outsourcing Sucks»

7 plagues of Software Testing by James Whittaker - The Plague of Homelessness

2009-11-19T04:06:00.000-08:00

Порок бездомности

Оригинал

Есть 2 категории людей, которые регулярно находят баги: тестировщики, которым за это платят, и пользователи, которые сталкиваются с багами случайно. Вообще-то, пользователи не делают это специально, просто в процессе нормального использования ПО в ходе работы (или развлечения, или социализации, или ещё чего-то) случаются сбои. Частенько, именно магическая комбинация взаимодействия приложения с реальными данными пользователя на реальном компьютерном окружении пользователя приводит к сбою ПО. Не кажется ли вам очевидным, что тестер должен стремиться воссоздать такие данные и условия окружения в своей тестовой лаборатории, чтобы найти эти баги до выпуска продукта?

На самом деле, тестировщики усердно пытались добиться именно этого в течение десятилетий. Я называю это «привнесением пользователя в тестовую лабораторию», неважно как, телом или духом. Моя докторская диссертация была на тему статического тестирования использования, и я был далеко не первым человеком, кто думал об этой идее, как свидетельствует моя многостраничная библиография. Но здесь есть естественное ограничение на успех такого рода работы. Тестировщики просто не могут стать пользователями или имитировать их действия достаточно натурально, чтобы найти все важные баги. Вы будете пропускать важные дефекты, если только вы действительно не живете в этом продукте.

Это как домовладение. Не имеет значения, хорошо ли построен дом. Не имеет значения, насколько старательными были строители и подрядчики во время строительства. Дом может быть тщательно проинспектирован на каждой фазе строительства подрядчиком, домовладельцем и государственным строительным инспектором. Все равно есть проблемы, которые могут быть обнаружены только спустя некоторое время после заселения дома. Дом должны использовать, в нем должны обедать, спать, принимать душ, готовить, устраивать вечеринки, отдыхать и все остальное, что домовладельцы делают в своих домах. Нельзя обнаружить дефект в системе сточных вод, пока подросток не постоит под душем в течение часа. Нельзя обнаружить оставленный кусок арматуры в бетонной плите гаража, пока не начнут парковать машину ночью. Строитель не будет (да он и не сможет) смоделировать такое.

И время тоже имеет значение. Нужны месяцы перегорания лампочек по одной в неделю, чтобы выяснить брак в проводке. Должен пройти год, чтобы шляпки гвоздей начали торчать из стены. Все это проблемы домовладельца, а не строителя. Это эквиваленты софтовых утечек памяти и искажений данных, время – необходимый элемент для обнаружений подобных сбоев.

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

Тестировщики бездомны. Мы можем делать лишь то, что можем, и ничего более. Нужно понимать наши ограничения и быть готовыми к спискам жалоб от наших пользователей. Претендовать на то, что как только приложение выпущено, проект завершен, - как минимум, глупо. Есть ещё гарантийный период, в который мы присматриваем за приложение, и этот период - все ёще часть фазы тестирования.

Где брать тестировщиков: методы поиска, найма и обучения

2009-11-18T02:39:00.000-08:00

Многие наверняка уже видели слайдкаст моего выступления на Test Labs 2009. В дополнение я выкладываю сам текст доклада. Он не содержит вставок анализа методов набора сотрудников в зависимости от ситуации на рынке, а вот сам костяк сообщения, которое я хотела до вас донести, здесь есть.

Где брать тестировщиков

View more presentations from jnechaeva.

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

Думаю, каждый из вас сталкивался с ситуацией, когда нужного человека в нужный срок за нужные деньги подобрать не получается. Причин тому может быть множество. Сессия, – и способные студенты не ходят по собеседованиям. Или Гугл открыл филиал в вашем городе, и все хорошие специалисты уже там, и их оттуда не переманить ни деньгами, ни статусом компании, ни интересными проектами. Или на рынок вышел Слава Панкратов и набирает себе подмастерий, и тут уже даже у Гугла проблемы с набором сотрудников :)
Нам же деваться некуда – люди нужны.

Успех зависит от стратегии компании в наборе сотрудников, от её гибкости и способности к адаптации, а также от понимания ситуации на рынке, сопоставления её с потребностями и возможностями компании.

Как же можно набирать людей:

- Приглашать готовых специалистов с необходимыми знаниями;
- Набирать способных ребят без опыта работы в тестировании и обучать их не только специфике проекта, но и тестированию «взагалi»;
- Всегда иметь пул ресурсов, из которого можно выудить нужных людей в нужный момент и достаточно быстро ввести их в работу;
- Создать внешнюю систему обучения.

Да, и, конечно же, – не есть правильно просто следовать однажды выбранной стратегии независимо от ситуации на рынке и от того, какие именно специалисты, в какой срок, в какой бюджет нам нужны.

Способ 1. Набор специалистов с опытом работы в тестировании:

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

Плюсы метода:

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

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

Минусы метода:

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

Методика набора готовых специалистов оправдывает себя в том случае, если вам нужен и сразу (!) специалист с определенным набором знаний и умений и вы готовы за это платить.

Способ 2. Набор людей без опыта работы в тестировании и обучение их на производстве:

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

Плюсы метода:

- Мы сами обучаем ребят тому, что нам нужно;
- На первых порах зарплата такого сотрудника меньше: важно к моменту становления человека как специалиста достичь адекватного уровня оплаты;
- Стремление к обучению и отсутствие «звёздности»: вероятность ситуации «я уже всё знаю и мне нечему больше учиться» минимальна при условии выбора правильного человека;

Перед вами чистый лист, который вы сможете обучить так, как вы хотите, и тому, чему вы хотите. Относительно недорого. .

Минусы метода:

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

Таким образом, этот способ оправдывает себя, если вы не можете позволить себе платить большую зарплату готовому специалисту, если вам не горит вход ресурса на проект, то есть вы можете себе позволить потратить время на его обучение, если вам НУЖНЫ такие ребята, чистые и гибкие. Это может зависить от специфики проекта и специфики коллектива. .

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

- Предсказываем расширение проектов количественно и качественно;
- Не торопясь, заранее набираем специалистов;
- Вводим их на проекты по мере надобности.

Плюсы метода:

- Уменьшение зависимости от колебаний рынка;
- Доступность специалистов в любой момент;
- Предсказуемость специалистов по техническим умениям и человеческим качествам;
- Снижение рисков, связанных с уходом сотрудников.

Минусы метода:

- Дорого: это может себе позволить только большая компания;
- Риск неоправдания предсказаний существует: нельзя полагаться на бекап полностью, может не оказаться нужного специалиста, может не оказаться нужного количества и т.д.;
- Люди могут «скиснуть»: бекап должен быть правильно организован, чтобы не превратиться в скамью запасных.

Если вы – достаточно большая компания и можете себе позволить всегда держать людей про запас, если у вас постоянный и предсказуемый прирост проектов и постоянная и, ещё раз подчеркиваю, предсказуемая нужда в людях, и вы умеете организовать этот бекап так, чтоб люди не чувствовали себя в запасе, то это вам подходит. .

Способ 4. Организация бекапа снаружи компании – внешняя система обучения:

- Изучаем предложение: смотрим на ВУЗы и студентов;
- Изучаем спрос: смотрим внутрь себя, понимаем, какие специалисты нам нужны в перспективе, чему их нужно научить;
- Создаем программу обучения;
- Стартуем программу, обучаем ребят, снимаем сливки, то есть по мере необходимости приглашаем ребят на работу.

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

Плюсы метода:

- Обучаем «под себя», но достаточно широко;
- Предсказуемость ребят в плане обучаемости и желания работать;
- Предсказуемость ребят в плане способностей и склонностей;
- За время обучения ребята становятся лояльными к вашей компании;

Обратите внимание – это готовые специалисты! Да, без опыта, но с теоретическими знаниями, широкого профиля, гибкие, мы наблюдаем их во время обучения, то есть они не преподнесут нам сюрпризов вроде неспособности обучаться.

- Имиджевая составляющая: компания, организующая собственную систему обучения, воспринимается как стабильная, серьезная компания с далекоидущими планами;
- Колоссальный и очень полезный опыт для компании и специалистов, которые к этому имеют отношение.

Минусы метода:

- Ресурсоёмкая организация процесса: договоренности с ВУЗами, разработка самой программы, ведение и поддержка процесса обучения;
- Ведущие такого обучения должны быть преподавателями в душе, а не просто техническими специалистами;
- Риск обучения для других компаний: за время обучения нужно заинтересовать ребят работой именно в вашей компании;
- Риск недостаточности знаний человека в других отраслях, нужных ему для работы в вашей компании: спастись здесь можно отбором на старте программы.

Если вы можете себе это позволить – это очень хорошая активность, очень полезная и очень интересная. Главное – определиться с целями и потребностями.

Нет верного ответа на все времена «как лучше и эффективнее нанимать тестировщиков». Перед тем, как принимать решение, где и как мы будем искать человека, нужно сесть и подумать: ЗАЧЕМ?

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

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

Аналитика для тестировщиков

2009-11-10T03:20:00.000-08:00

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

Можно научиться методикам и инструментам работы с требованиями. Но для того, чтобы делать что-то эффективно, нужно в первую очередь понимать цель. И только затем – знать методики. Тестировщик должен уметь работать с требованиями, и он должен делать это также осознанно, как процедуру утренней чистки зубов. А то и более ;-)

Серию семинаров «Аналитика для тестировщиков» открывают два первых семинара:

«Работа с требованиями: анализ, тестирование» (10 декабря, 13:00-15:00)

Когда и зачем привлекать тестировщиков к анализу и тестированию требований.

Критерии качественного требования.

Свойства требований.

Функциональные и нефункциональные требования.

Явные и неявные требования.

Методики тестирования требований.

Полномочия и компетенции тестировщиков при работе с требованиями.

«Работа с требованиями: управление изменениями» (24 декабря, 13:00-15:00)

Требования будут изменяться. Всегда!

Влияние изменений в требованиях на тестирование.

Изменения объема.

Изменения сути.

Изменения конфигурации.

Конфликты и гибкость требований и тестов.

Трассировка изменений требований.

Повторное использование.

Семинары в формате вебинаров будут проходить совместно с порталом http://Software-Testing.Ru. Условия участия здесь.

Бытует мнение, что основная задача тестирования – проверка соответствия разработанного приложения требованиям и поиск ошибок. Но как же часто встречается ситуация, когда сами требования содержат ошибки. Ошибки нефункциональные, а логические, ошибки бизнес-логики, недомолвки, двусмысленности.

Когда Филиппа Крухтена спросили, что такое качество продукта, он ответил: «Качество — это соответствие ожиданиям Заказчика/Пользователя».

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

Составление требований – удел (хотите, называйте это обязанностью или компетенцией) аналитиков. А вот за создание качественного программного продукта ответственна вся команда. Именно поэтому все участники процесса разработки должны быть причастны к созданию продукта с самого начала и дополнять друг друга.

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

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

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

Часто встречаются ситуации, когда продукт поступил в разработку с уже готовыми требованиями. Их тем более нужно тестировать. На предмет реализуемости, на предмет тестируемости, на предмет адекватности.

Что же, если у вас в команде свои аналитики? Соглашусь с высказываением, что каждый должен заниматься своим делом. Действительно, тестировщик никогда не сравнится со «специально обученным» аналитиком. Ну и не нужно равняться. Нужно делать то, что по силам, и то, что работает на улучшение качества программных продуктов. Предотвращение дефектов – это уже не контроль качества (Quality Control), а элементы его обеспечения (Quality Assurance).

Сложно ли научиться дополнять и проверять работу аналитика? Не думаю. Ведь аналитический склад ума и так присущ нам, тестировщикам, иначе бы мы навсегда остались на уровне «маускликеров». Мы анализируем поведение приложения в различных ситуациях, придумываем эти самые ситуации, основываясь на бизнес-приоритетах и сценариях поведения пользователей. Мы выясняем все недовыясненные моменты и доказываем разработчикам, что заказчику нужно другое, отличное от реализованного.

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

Оговорюсь, что всему этому конечно же нельзя научиться за 2 часа. Моя цель – показать вам, где мы можем дополнять работу аналитика, и показать вам, что чем более осознанно мы это делаем, тем больше пользы это приносит продукту, команде и нашему профессионализму.

7 plagues of Software Testing by James Whittaker - The Plague of Boredom

2009-11-04T03:26:00.000-08:00

Порок скучности .

Оригинал.

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

Хотя начинается все не так. На заре тестерской карьеры возбуждение от охоты на баги может удерживать тестировщика в течение многих месяцев. Это происходит как опьянение от прохождения видеоигры и попыток найти ускользающий приз. И большая часть успехов в перерасчете на навыки как раз приобретается в эти ранние годы тестировщиками, которые быстро превращаются из новобранцев в достаточно хороших специалистов. Кто же будет противиться карьере, предлагающей изучение, развитие и интеллектуально интересные задачи?

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

Я считаю, что скучающие тестировщики что-то упускают. Я утверждаю, что лишь тактические аспекты тестирования становятся со временем скучными, и многие ударяются в автоматизацию дабы сгладить это. Автоматизация как зелье от скуки выполнения тест-кейсов и заполнения баг-репортов – это одно дело, но автоматизация – не замена стратегическим аспектам процесса тестирования и именно в стратегии мы находим избавление от порока скучности. Процесс тест-дизайна, принятие решения о том, что должно быть и что не должно быть протестировано, и в каком соотношении, - во всем этом автоматизация вам не поможет, и это остается интересной и побуждающей думать задачей. И ни одно из этого ещё не является стратегической задачей мониторинга тестов и определения, когда остановиться. Это и есть те тяжелые, но интересные стратегические проблемы, которые изгоняют порок скучности. Тестировщики могут поддаться пороку скучности, либо же они могут сместить свой фокус с лишь тактических задач на изящный микс из тактической работы и стратегических размышлений.

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

Скучность. Вообще-то, boredom – это скука, но скучность больше подходит для передачи именно свойства, присущего тестированию. Скука – это его следствие.

7 plagues of Software Testing by James Whittaker - Plague of Amnesia

2009-11-02T01:35:00.000-08:00

Порок амнезии.

Оригинал.

Память – это та штука, которая с возрастом слабеет первой, но в общей картине инженерии разработку ПО можно назвать старой с очень большой натяжкой.
Действительно, мы откровенно молоды в сравнении с гражданскими, механическими, электротехническими и другими инженерными дисциплинами. Мы не можем использовать возраст как оправдание амнезии.

Тестировщики ПО подвержены двум типам порока амнезии. У нас есть командная амнезия, которая заставляет нас забывать наши прежние проекты, наши прежние баги, тесты, сбои и так далее. Требуется время для построения коллективной памяти, которая помогла бы нам остановить повторение наших ошибок. Каждый проект – это не старт с нулевой точки, это всего лишь новая цель для уже более опытной команды. Звездный корабль Enterprise сохраняет бортовой журнал. Это дневник, в котором описаны все приключения его экипажа и к которому можно обратиться за деталями, которые возможно помогут людям выбраться из текущего очередного переплета. Я не пропагандирую ведение дневников для команд тестирования, но я действительно хочу иметь механизм для сохранения знаний. Идея в том, что мы как команда основываемся на наших коллективных знаниях и успехах. Чем длиннее память экипажа Enterprise, тем лучше её можно использовать.

А ну-ка, назовите мне быстренько последний крупный сбой продукта, над которым работает ваша команда. Есть ли у вашей команды коллективная память общих багов? Делитесь ли вы хорошими тестами? Если один специалист пишет тесты для проверки какой-то функциональности, знают ли об этом остальные и тратят ли они свое время на тестирование где-то в другом месте? Документируются ли проблемы, которые ломают автоматизацию, с тем, чтобы усилия на анализ этих проблем и их решение не повторялись снова? Знает ли команда, что делает каждый, с тем, чтобы их области тестирования перекрывались как можно меньше? Достигается ли это с помощью дашбордов и постоянного общения? Или мы синхронизируем наши действия лишь митингами, крадущими наше время и прерывающими нашу работу? Ответьте честно. Первый шаг к исправлению – признание существования проблемы.

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

Амнезия индустрии – это настоящая беда. Подумайте об этом в таком ключе: проблема тестирования, которая встала перед вами прямо сейчас (вставьте сюда проблему, над которой вы работаете), уже была когда-то решена. Вы тестируете операционную систему? Кто-то уже сделал это, и не только он. Веб-приложение? Да, и это уже сделано. AJAX? Клиент-сервер? Да, да и ещё раз да. Скорее всего все, что вы сейчас делаете, уже было сделано до вас. Да, есть какие-то новые проблемы тестирования, но более чем вероятно, что ваша нынешняя проблема не одна из них. Очень плохо, что с коллективной памятью в индустрии все так запущено, иначе было бы просто дотянуться до помощи.

Позвольте мне завершить эту колонку, показав пальцем внутрь: Как же мы [Гугл] будем тестировать недавно анонсированную ОС Chrome? Сколько коллективной памяти мы сохранили после Chrome и Android? Сколько из того, чему мы научились, тестируя Android, поможет? А сколько из этого будет переиспользоваться? Как легко тестовые команды Chrome и Android адаптируются к этому новому испытанию? И, конечно же, многие наши проблемы тестирования – это те, с которыми мы уже сталкивались.

Запомним ли мы?

цитаты

2009-10-27T08:44:00.000-07:00

Канер, Фолк, Нгуен, "Тестирование программного обеспечения.":

На совещаниях группы аналитиков специалистам по тестированию лучше всего быть пассивными участниками и высказываться только в случае необходимости.

А ты, чукча, покорми собак и ничего не трогай, ага.

7 plagues of Software Testing by James Whittaker - Plague of repetitiveness

2009-10-25T09:58:00.000-07:00

Порок повторяемости

Оригинал

Если бесцельность – это результат «простоделания», то повторяемость – это результат «простеделания несколько раз». Раз за разом, билд за билдом, спринт за спринтом, версия за версией мы тестируем наш продукт. Разработчики проводят инспекции, создают юнит-тесты и запускают статистические анализаторы. Но у нас есть лишь маленькие догадки по поводу всей этой работы, и мы не можем доверять им. Разработчики тестируют, но затем перетестируем мы. Мы не можем поручиться за то, что они делают, и поэтому мы подвергаем повторному тестированию всё. Наряду с ростом нашего продукта в фичах и по мере фиксов дефектов мы продолжаем наше тестирование. Новые тесты теряют свою новизну очень быстро, и все они, в конце концов, становятся устаревшими.

Существует Бейзеровский пестицидный парадокс. Пестициды убивают жуков, но опрыскайте одно и то же поле одним и тем же ядом достаточное количество раз, и у оставшихся жуков выработается иммунитет. «Прополоскать и повторить» - это алгоритм для мытья волос, а не для тестирования ПО. Последнее, чего мы хотим добиться, -- это билд, полный супер-багов, устойчивых к нашему «тестициду». Дальше – хуже: всё, что называется «успешным тестированием» будет давать нам фальшивое видение тщательности и делать наши метрики завершенности кучей опасного вранья.

Когда вы не находите баги, это не потому, что их нет, а потому, что повторение повлекло за собой пестицидный парадокс.

Феремеры знают, как изменять формулу их пестицида время от времени, знают, как подгонять формулу под специфический тип паразитов, которых они ожидают на своих полях. Они делают это, потому что вникают в историю используемого пестицида и знают, что может случиться в случае грубого повторения того же самого старого яда. Так и тестировщики должны обращать внимание на их результаты тестирования и следить за автоматизацией, которая не прибавляет полезности. На помощь приходит здравая инспекция изменений в автоматизации. Изменяйте порядок тестов, изменяйте их данные, находите новые окружения, изменяйте входные данные, делайте что-то такое, к чему баги не готовы.

7 plagues of Software Testing by James Whittaker - Plague of Aimlessness

2009-10-22T04:51:00.000-07:00

«7 plagues of Software Testing» - это цикл постов Джеймса Виттекера, который с мая 2009 года присоединился к команде Google в качестве Test Director. Этот цикл родился из его первого tech talk в Гугле, где его выводы, по признанию самого Джеймса, были признаны ребятами из Гугла достаточно провокационными. Все 7 статей опубликованы в блоге http://googletesting.blogspot.com/.

Перевод первого поста из этой серии я символично выкладываю именно сегодня, во второй день конференции Google Test Automation Conference, которая проходит именно сейчас в Цюрихе, и на которую я не попала. Именно она послужила поводом для моего знакомства с Джеймсом Виттекером. Джеймс разрешил мне переводить и публиковать его статьи, чем я, собственно, и занимаюсь.

Спасибо Тимуру Хайруллину за помощь и терпение :)

Цикл «Семь пороков тестирования» открывает первый пост: «Порок бесцельности».

Оригинал.

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

И это именно то, чего нам не хватает в тестировании. Мудрость тестирования? Вы шутите? Где она? Кто же её зажал? Не подскажете?

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

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

Когда охотники убивают, они запоминают и территорию, и обстоятельства. Они передают это знание своим преемникам. Со временем они начинают понимать повадки добычи, и коллективное знание множества охотников значительно облегчает труд будущих охотников. Когда вы видите такую территорию, вы ожидаете игры по опрделенным правилам. Можем ли мы сказать то же самое о тестировании? Как хорошо мы учимся друг у друга? Разве наши моменты озарений систематизированы таким образом, чтобы избавить будущих тестировщиков от страданий в бесцельности борьбы с тем, над чем страдали мы? Можем ли мы сказать, что когда мы видим такую функциональность, мы знаем лучший способ её протестировать?

Порок бесцельности, увы, широко распространен. И нужда в Мудрости очень остра. Nike говорит нам: ‘just do it’, но что применимо к упражнениям, не подходит к тестированию ПО. В следующий раз, поймав себя на ‘just doing’ тестирование, остановитесь на мгновение и спросите себя: «Какова моя цель?» и «Каково назначение этого теста?». И если ответ не приходит к вам моментально, вы в плену бесцельности, «just doing it», положившись на удачу и грубую силу в усилиях по поимке вашей добычи.

Удаче не место в волшебстве охоты и ей нет места в тестировании. Удача – это хорошая случайность, но она не может быть нашим планом А. Следите за пороком бесцельности. Препарируйте свои успехи, исследуйте свои неудачи и будьте уверены, что вы фиксируете то, чему научились в ходе самонаблюдения, для ваших коллег.

Станьте для них Мастером. Создавайте тестировщицкую книгу заклинаний и делитесь ей с другими в своей команде. И со временем вы избавитесь от порока бесцельности.

________________________________________________________________________________________

Тестирования. Software Testing. Я осознанно не употребляю практически нигде в тексте выражение "Тестирование программного обеспечения". И так понятно, что стоит за термином "тестирование".

Порок. В оригинале plague, что переводится как чума, мучение, напасть, бедствие. Были предложения перевести plague как "беда" или "зараза". Мне больше всего нравится "порок", это что-то такое, что было в тестирование заложено изначально и от чего практически невозможно избавиться, но можно смягчить. Мне кажется, именно это имел ввиду Джеймс.

Мудрость. В оригинале lore, что означает коллективное знание в какой-либо области (в данном случае - тестирования). Это что-то такое, что собирается многими поколениями и что всегда доступно всем страждущим. Поэтому перевожу как Мудрость. Такая себе коллективная Мудрость всея тестирования.

Кто же её зажал? Джеймс использует глагол boharted, который невозможно перевести на русский, не потеряв обаяния этого слова. Сленговое словечко to bogart родом из наркоманских 60х, означает "зажать что-то, что должно быть передано другим". "Don't bohart that joint!" - "Не зажимай косяк!"". Пруфлинк. Слово это возникло благодаря актеру Хамфри Богарту, известному своей привычкой не выпускать сигарету изо рта (основную известность ему, конечно же, принес кинематограф, а не сигарета. Очень люблю его "Касабланку").