Ода тестированию производительности, или ХВАТИТ ПУТАТЬ ЕГО С НАГРУЗОЧНЫМ!

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

В результате такого восприятия теряется понимание тестирования производительности, которое является НУ ОЧЕНЬ важным, потому что:

1) Вы любите, когда что-то тормозит? Клиенты тоже не любят, обычно баги производительности являются критичными.
2) Чаще всего проблемы с производительностью являются архитектурными. Когда клиенты их репортят, исправлять их уже поздно.
3) Локализовать ошибки производительности - это сложно, это действительно искусство.
4) Неграмотное тестирование производительности ("здесь что-то тормозит") почти всегда ведёт к тому, что критичный баг переходит в разряд KNOWN ISSUES. Чтобы этот баг мог быть исправленным, тестировщику придётся потрудиться!

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

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

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

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

Что важно:

- автоматизация. КАЖДЫЙ билд значит КАЖДЫЙ, это важно и чтобы вовремя заметить проблему, и чтобы чётче локализовать причины для разработчиков. Тесты на скорость работы - первые кандидаты в автоматизацию.

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

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

2) Сравниваем себя с конкурентами. В то время как маркетологи всё ещё гоняются за "фичез-листами", пользователи уже давно ищут телефоны без фотокамер. Пользователям важно ПРОСТО и БЫСТРО. Ну, и ещё 5-10% от функционала Вашего ПО. Поэтому, нам надо проверять, насколько наша скорость сопоставима со скоростью конкурентов. И если мы в 2, 3, 5 раз медленнее - бить в колокол.

Что важно:

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

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

3) Ищем "провалы" производительности, зависящие от внешних факторов.
Часто бывает такое, что пользователи жалуются "медленно", а мы вроде бы (по своим замерам) в несколько раз быстрее конкурентов. Поддельные тестировщики в ответ на такие жалобы в support отвечают "у нас всё хорошо". Настоящие тестировщики уже знают, в чём причина!
Узнаём всё, что может влиять на скорость работы. Типы файлов? Размеры архива? Файловая система? Операционка? Размер кластера? День недели? Расположение звёзд? И проводим тесты, сравнивающие производительность в зависимости от этих факторов. Зачастую бывает такое, что из-за использования неграмотного драйвера сохранение архива на фат может занимать в 30 раз больше времени, чем на нтфс, который входит в Вашу "стандартную" конфигурацию. Пользователи просто не дождутся результата!!
ОДНИМ из параметров тестов МОЖЕТ БЫТЬ количество подключений в клиент-серверном ПО. Все остальные тесты НЕ имеют отношения к нагрузочному тестированию.

Что важно:

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

- исследовать архитектуру продукта, делать тестирование производительности grey-box техникой. Поговорите с разработчиками. Они конечно же скажут, что ничто не может влиять на результат - у них работа такая :) Узнайте, какие ветви кода вызываются в зависимости от каких условий. Подумайте, как Вы можете вызвать не проверенные ветки кода, как задействовать эти условия?

4) Ищем узкие горлышки aka bottleneck'и. Если наш продукт неэффективно использует ресурсы компьютера, то мы либо теряем огромный запас в скорости работы, либо становимся почти неработоспособными на конкретных "железках". Свой продукт надо знать в лицо! Что ограничивает его скорость?
При проведении тестов, обязательно включаем все возможные мониторы. Какой ресурс занят на 100%?

Никакой, и до 100% всем далеко? Проблема алгоритма, мы написали немасштабируемый софт!

Один, а остальные близки к нулю? Очень велика вероятность того, что мы не используем огромный запас скорости!

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

5) Общие советы.
Чтобы сделать тестирование производительности эффективным:

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

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

- сделайте ОЧЕНЬ понятный отчёт. Если вывести в текстовый лог результаты операций, то есть шанс, что вы не поймёте результатов вообще. Где бага, где всё хорошо?
Грамотно сгруппируйте результаты замеров, чтобы результат был понятен и очевиден.

no pasaran!

Почему тестирование - это тупо и скучно?

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

Позавчера я тестировала свой небольшой веб-проект.

За 4 часа я завела 25 дефектов.

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

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

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

Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!

И я задумалась. Кто пишет про "скучно", "рутина" и "тупая работа"? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.

1. "Не моё". Я обожаю тестировать и проводить тренинги, но я ненавижу звонить по телефону. НЕ МОЁ! Тестирование - это набор конкретных действий, которые мы выполняем. Кому-то нравится этот процесс, кому-то нет. Если это не ваше - ищите своё! Явно есть вещи, которые увлекут так же, как тестирование - меня.

2. "Не умею". Тестировать - это навык. Я помню, как я тестировала в начале карьеры. Тынканье на кнопки, просмотр UI... нудно и скучно. Тогда я не использовала на лету интересные техники тест-дизайна, тогда я не понимала как правильно локализовывать дефекты и вообще не понимала насколько важно (и обычно сложно) их точно локализовать. Это была и впрямь тупая работа, это было скучно. Знание методологии меняет всё! Тестирование становится творческим и значительно более интересным!

3. "Не понимаю зачем". Когда я тестирую свой собственный проект, мне это важно и я понимаю, зачем я это делаю. Когда я участвовала в выпуске продуктов с мировым именем, которыми я гордилась и горжусь, я понимала важность тестирования для миллионов (МИЛЛИОНОВ!) пользователей. Это добавляет работе значимость и интерес. Работая в компании, в которой качество не ценится, испытывать удовольствие от тестирования сложно - оно же никому не нужно!
Работаете в такой компании? Бегите!

4. Неоправданно жёсткие процессы. Тестировать по 100 лет назад созданным тест-кейсам, повторяющимся каждый день, не просто скучно, но и бесполезно. В итоге и интереса нет, и ответственность не чувствуется. Надо уметь выбирать оптимальное соотношения исследования к документированию. Да, документы нужны. Иногда чек-листы, иногда даже тест-кейсы, иногда они даже необходимы. Но НЕ ВСЕГДА!

Может, есть ещё какие-то причины неинтереса.

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

то либо тестирование - это мега-супер-пупер-аж-захватывает-дух интересно, либо НЕ ВАШЕ!

Usability- тестирование

Долго писала комментарий к интересной теме, а он потерялся :(
Напишу ещё подробнее и здесь :)

Usability тестирование в сфере разработки ПО - это проверка удобства использования продукта. На эту тему есть как минимум одна интересная книжка:


Я постараюсь сформулировать своё мнению про юзабилити-тестирование, основанное как на чтении книжек/статей, так и на собственном опыте. Я не претендую на полноту описания и на полноценность списка способов. Отнюдь! Но это - те базовые шаги, которые являются 20% действий по закону Паретто и которые принесут угадайте сколько результата :)

1) Самое главное в тестирование юзабилити - определить его цели. Что будет делаться по результатам тестирования юзабилити? Будут ли исправляться дефекты, есть ли приоритет, направленность проекта/компании в целом на юзабилити? Если нет - Вы попусту тратите время. Почему это пункт 1? Потому что в России такого приоритета зачастую нет. А своё время надо экономить ;)

2) Если всё же смысл в юзабилити-тестировании есть, то следующий важный шаг - узнать Вашу ЦА, целевую аудиторию.
Почему важно понять, кто Ваши пользователи? Приведу пример с общеизвестными продуктами: антивирусами, средствами архивирования, графическими редакторами. Зачастую, приложения для домашних пользователей и корпоративных пользователей имеют идентичный функционал. Но антивирус для домохозяйки имеет все базовые предустановки, и в большинстве случаев ей просто надо нажать на кнопку. Но если это корпоративный антивирус, который настраивают админы, то им нужна панель управления космическим кораблём :)
Функционал один - количество кнопок, настроек, их сложность и т.д. - разные. Найти соприкосновение для таких целевых аудиторий будет сложно.
Аналогично - с графическим редактором. В MS Paint'e есть почти всё, что нужно простому смертному, который испугается менюшек фотошопа. Зато дизайнера явно не устроит MS Paint...

3) Целевая аудитория - это те люди, чьё мнение для Вас важно. Но помимо этого, Вам надо понимать, как обычно используется Ваш софт в "боевых условиях". Говоря простым языком, Вам нужно составить ментальную модель пользователя :)))
Когда ИТ-шники тестируют софт для бухгалтерии, они обычно ориентируются на свои предпочтения и свою специфику отрасли. Запуская одни и те же программы каждый день, мы привыкаем к любому неудобству. Потому, что мы тестируем, а не используем. Это - две большие разницы :) Цель создания ментальной модели - понять, как продукт ИСПОЛЬЗУЕТСЯ, и его тестирование соответствующим образом.
Как Ваш софт запускают? Из каких менюшек куда заходят? Что используют часто, а что - редко? Что важно? Какие проблемы и задачи решает пользователь при помощи Вашего софта?
Один раз я столкнулась с неприятным опытом. В продукте, который я зарелизила, среди прочих был один всем известный дефект, который казался нам непринципиальным. (Нам = 40 тестеров, 60 разработчиков и парочке аналитиков). Мы были уверены, что этот функционал никто не использует.
Как же мы удивились, когда получили массу жалоб и отказов именно из-за этой "мелочи"!
Этот полученный опыт я считаю хоть и негативным, но очень важным. Тестировщики всё же не пользователи. Надо узнавать настоящих пользователей, чтобы "отстаивать их права" :)

Теперь, переходим к процессу и техникам :)

4) Не торопитесь устраивать исследования. Тестируйте сами. В этом Вам помогут знание пользователей, common sence и общепринятые нормы юзабилити. Чтобы их узнать, погуглите usability guidelines. Они бывают для разных ОС, для ВЕБа и т.д. По ним, сначала проверьте сами и оцените, насколько соответствует им Ваш софт и насколько готова Ваша команда править ошибки. Если этот этап пройден успешно - идём дальше!

5) Проводим исследования.
* Ищем ЦА. Не просто "коридорное тестирование", чтобы найти кого-угодно, а конкретных, подходящих людей, которые будут использовать Ваш продукт!
* Мотивируем их. Мы можем предложить более качественный софт потенциальным клиентам. Мы можем предложить деньги подходящим людям. Не надейтесь, что кто-то будет серьёзно расценивать Ваши опыты просто так :)
* Не делайте многонедельных исследований. Это просто долго, и юзтестеры так же замылят глаза, как и обычные тестеры. Юзтестирование должно быть коротким и быстрым.
* Вы можете провести простое исследование, попросив пользователей
- Выполнить ~5 простых основных действий, не описывая ни в коем случае шаги! Только действия. Пусть они сами ищут, как это сделать, и опишут Вам проблемы, с которыми столкнулись.
- Потыкать кнопочки и описать, что понравилось и что не понравилось :)
- Пригласить их к себе и попросить сделать эти самые действия. Понаблюдайте, с чем они сталкиваются. В анкете они не смогут описать всего, с чем столкнулись, так как сами не заметят своих "заминок". Зато, это можете заметить Вы :)
- Используйте специальные средства для записи действий пользователей, которые Вы потом сможете проанализировать в спокойной обстановке.
- И да, я не советую Вам проводить лабораторные исследования и записывать количества движений глаз :) Во-первых, я сама этого никогда не делала, во-вторых, я ещё не работала с софтом, у которого достаточно высокий уровень юзабилити для того, чтобы эти исследования могли быть оправданными.

6) Анализируем результаты.
* Не пытайтесь исправлять всё, на что пожалуются юзтестеры. Некоторые из них такие марсиане, что их комментарии окажутся бесполезными для всех остальных пользователей. Ищите золотую середину и не забывайте про common sence.
* Найдите способ подтвердить, что исправления полезны. В принципе, это следствие из предыдущего абзаца :)
* Выработайте критерии критичности юздефектов. Невозможность найти опцию и лишний клик - это разные весовые категории.
* Не пытайтесь компенсировать юзтестированием недостаток изначального анализа. Это будет выстрел пушкой по воробьям.

QA, QC, Testing & Process Managers

Кажется, уже все всё давно знают... Но до сих пор задают вопросы :)
Кто такие QA, QC, тестировщики и процессные менеджеры?

Тестировщики.

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

Quality Control (QC)

Эти бравые ребята ставят диагноз. Типа "Жить будешь" или "Вам бы подлечиться".
Для того, чтобы поставить диагноз, нужно произвести 2 действия:
- провести анализ (температура, биохимия, МРТ :)))
- определить, что является нормой, а что - отклонением.
Так вот, первая часть - это то самое тестирование. Но - есть бонус - в диагнозе :) QC не просто говорит "здесь бага" - QC определяет качество продукта, его готовность к релизу. Для этого создаются метрики качества, зачастую возможно личное общение с заказчиками. Более того, есть особо пронырливые QC, которые хорошо разбираются в предметной области и часто учат жить аналитиков. А точнее - переписывать требования :)
В нескольких компаниях, в которых я работала, QC обладают так называемым "правом вето" - то есть, пока они не разрешат, продукт релизить нельзя. Ответственность выше, эго шире :))

Quality Assurance, QA

В древнем Китае семейные врачи зарабатывали деньги всё то время, когда их клиенты были здоровы. Если же кто-то в "подконтрольных" семьях заболевал, им прекращали платить до полного выздоровления. Это всячески способствовало ориентации врачей на здоровье.
Немного похоже на QA... Потому что эти ребята предпочитают не лечить, а проводить профилактические мероприятия. Делают прививки, учат как правильно чистить зубы и агитируют за шерстяные носки :) Тестировщики расстраиваются, если багов нету. А QA счастливо потирают руки и гордятся.
Что они для этого делают? Определяют процессы, подходы, влияют как на тестирование так и на разработку, на билды и на требования. Их главная задача - чтобы продукт был качественным :) Если в компании всё хорошо, то их слушаются. Если плохо - то их просто нет :)

Процессные инженеры, процессные менеджеры.

Иди сюда... сюда... вот так... Теперь правой.. Оп! Не получилось? Попробуем с начала :)
Если в Вашей компании есть такие зануды, то это - процессные инженеры. Они всех учат жить, поэтому зачастую их любят меньше чем тестировщиков. Хотя, при правильном подборе, эти ребята творят чудеса! Их предназначение - искать наиболее эффективные пути выполнения тех или иных задач. Как сэкономить время на сборки? Как проводить Post Mortem? Как сделать так, чтобы тестеры и девелоперы не ссорились? Эти джедаи разрулят любые ситуации, как гаишник с палочкой, если светофор не работает :) Они напишут регламент, объяснят процедуры, найдут крайних и придумают Вам новую работу. И всё - на благо дела!

Выводы:
QC и Тестирощики - это почти одни и те же ребята, только с разными подходами к своему делу и разными уровнями возможности и ответственности. Перейти из одного амплуа в другое - просто, даже в рамках одной фирмы.
QA и процессные инженеры - тоже родственники. Но миссия QA - "Качество", а миссия проессных инженеров - "Оптимизация".
QA и QC - дальние родственники, несмотря на общую букву и то, что 90% тестировщиков называют себя QA инженерами :)