QA из Skype поделятся знаниями 9го апреля

Сегодня, 9 апреля 2012, в Киеве состоится событие, на котором некоторые хотели бы побывать, но не смогут. QA Club Kiev совместно со Skype (!) организуют встречу с презентациями людей из Skype. Они поделятся с нами своим опытом и расскажут про видео тестирование (?).

Для тех, кто не может быть там мой знакомый darkproger у себя на сайте будет вести онлайн трансляцию события http://live.darkproger.net :)

Детали на http://www.ciklum.net/join/community/Building-network-QAs-gathering-in-Kiev-April2012/

Очень полезная штука jmeter plugins

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

Вот краткий их анализ, который я со временем дополню

Графики

Хронология

• PerfMon Метрики коллектор
• Активные темы во времени
• Коды ответов в секунду
• Время отклика во времени
• Ответ Задержки во времени
• Операций в секунду
• Сервер просмотров за секунду
• Пропускная способность в байтах во времени
• Сводный график хронологии

Сводные графики

• Время отклика и потоки (виртуальные пользователи)
• Пропускная транзакций и потоки )виртуальные пользователи)

Распределение

• Распределение времени отклика
• Квантили времени отклика

Что бы я писал в тест плане

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

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


Кто?
Надо описать команду, роли и какая на каком лежит ответственность. Например,

Тест Аналитик - отвечает за тест дизайн, анализ результатов и отчетность - Петя Ёшкин

И никто не мешает при этом написать, что Тим Лид у вас тоже Петя Ёшкин, но тут другие обязанности. Почему бы со временем не стать тестовым аналитиком другому человеку (или лидером команды, а что?). А роль останется.

Что?
Определяем фронт работ. Что мы будем проверять, а что нет. Причем, второе важнее. Например,

Проверяем:Установку приложения
Доступ к функциям приложения согласно правам доступа
Основную функциональность приложения
   Календарь
   Формы отчетности
   Управление пользователями
   и т.п. штуки
Не проверяем:Управление пользователями (доменный доступ)
Логин в систему (доменный доступ)
Печать отчетов

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

Как?
Определяем подход к работе. Лучше всего разбивать по типам тестирования.
Окружение, общие сценарии запуска тестов (если необходимо). Например, для производительности:

1. Ставим приложение на сервер
2. Разворачиваем нагрузочное окружение
3. Настраиваем параметры теста
4. Прогоняем в тестовом режиме
5. Запускаем
6. Хватаем результаты и анализируем

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

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

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

Главное - не думать шаблонами.
Enjoy :)

З.Ы. А еще у меня где-то завалялся шаблон, кажется, RUP'a, который когда-то я бережно сохранил с сайта одного заграничного коллеги. Покопаюсь и как найду, то поделюсь ссылкой или пакетом

QAConf 1.0. Анонс

17 сентября буду с небольшим докладком на тему использования и воспринимания тестировщиками Burndown'ов на QAConf.

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

Yahoos filling up the Burn down chart

Как бы я писал тестовые сценарии

Хочу вкратце осветить подход как я люблю писать тесты. Хотя между делом я это не очень люблю и потом постарался максимально удобный для себя подход подобрать.

Итак, что важно:
Создавать сценарии, а не отдельные тесты. Это может быть набор из тестов связаных друг с другом. Это экономит время. Например,
Выделять в большом сценарии отдельные точки проверки (verification points) с ожидаемыми результаами и отмечать их по мере прохождения. А  не ставить большую кучу в конце. Как-то в процессе вы должны были ожидать вот это. Видел такое, и не в полугодовом наколеночном проекте. А в зрелой большой успешной компании
В отчетах учитывать каждую точку проверки. Она влияет прошел сценарий/сьют/модуль/набор или нет
Но для общей статистики избегать дублирующий учет точек проверки. Учитывать vp только где это необходимо. Например, если в каждом сценарии вы проходите логин, то не надо считать, что это каждый раз отдельная точка проверки. Либо исключите его как точку проверки: уберите оттуда ожидаемый результат и не ставьте резолюцию. либо при отчетности не учитывать его кроме как только один раз во время проверки самого логина: оставьте ожидаемый результат (жалко копипаста?), но не ставьте резолюцию. Но обязательно оставьте коментарий и пометьте, что в данном случае тест провалился на логине, если только в этом тесте свалился логин. Или только он запускается сейчас.

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

Тест лидер и проектный менеджер?

На самом деле я тест лид. И младший product owner и иногда не младший тоже. И менеджер команды (проекта). И просто automated QA Engineer. И в то же время все эти люди не я, и я не все эти люди, уж тем более одновременно.

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

Вспомню еще что - допишу :)

Мелкие кремниевые полезности

Selenium - это бесплатное и очень удобное средство автоматизации веб приложений. Работает как библиотека на разных языках (Java, C#, Ruby, PHP, Perl, Python), подключаемая к вашему тестовому сьюту. Там большое количество атомарных методов, но для большего удобства постоянно приходится немного дорабатывать различными дополнительными методами.

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

Приведу пару примеров, а заодно сохраню их у себя :)

Быстро, не значит плохо

Вчерашняя встреча PM Zone с Томом Альберсом вдохновила меня на самоанализ и как следствие ряд мыслей.

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

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

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

P.S. Вот помнится на Agileee двое ребят очень забавно рассказывали о таком подходе. Жаль Видео нет

The sword and Other Tales

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

Помнится мне что-то такое еще с университетских времен. А тут посмотрел и понял конкретное применение в управлении проектами и командами в ИТ. И это точно надо "заложить" себе и тому кто прочтет.

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

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

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

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

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

Гармония важна в любом аспекте жизни. :)

SQA Days 7, Харьков. Часть первая

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

Началось все утром в пятницу, 14 мая. Проводили в Радмир Экспохолле, хотя где еще можно это проводить в Харькове пока придумать не могу.
Пока народ прибывал и регистрировался, я немного поправил здоровье горячим чаем и уточнил программу конференции. Очень приятно, что программа конференции была отдельно в раздатках, потому что в последний день произошли изменения и было бы неприятно бегать в поисках нужного доклада. Хоть рецензий на изменения и не было в распечатаном сборнике тезисов. Также в раздаточных материалах был диск с материалами конференции. Приятно порадовал бонус в виде материалом по SQA Days 4 и 5.

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

В начале слушал "Сокращение времени выполнения регрессионного тестирования", Павел Моцарь. Как человек выступал понравилось. Суть в том, что в их компании начиная с момента, когда еще не было ни Hudson, ни СruiseControl развернули систему управления версиями и, самый важный момент, добились установки системы на тестовую конфигурацию одним кликом.
Далее автоматизация тестирования. Она как раз и используется для регрессионного тестирования. Да, также запуск скриптов в одно касание :). Но тесты, хотя на данный момент идея не так уж и нова, из-за огромного их количества и большого времени прогона, разбиты на suites и каждый suite запускается на отдельной тестовой конфигурации.
Интересный момент, что клиент этой системы автоматизированного тестирования запущены на большинстве рабочих машин работников. И система может запросить хардварные ресурсы рабочей машины работника, чтобы обеспечить свою производительность. :) Мне, правда, сразу вспомнился LoadRunner.

Далее был "Метод Всех пар, или как не убиться тестируя комбинации", Александра Барановского. Кстати по манере изложения один из самых качественных докладов был. И идея полезная, хотя тоже не новая. Суть в том, чтобы сократить число тестов при тестировании взаимодействующих параметров, таких как настройки системы. Метод рассмотрели еще и на конкретном примере. И специальную тулзовину посоветовал.
Почитать можно и в интеренете, но суть в том. Чтобы вычленить все имеющиеся параметры (контролы формы настроек), их значения. А потом можно загрузить в предложенную тулзовину (PICT от Microsoft) и получить упрощенный вариант тестов. В двух словах описать математическую составляющую метода мне тяжело.
Этот метод не дает замену полному перебору. Но предлагает оптимальное количество тестов, при котором можно выловить большую часть ошибок.

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

Перед обедом пошел на доклад, "Организация процесса тестирования в Agile команде на основе матрицы квадрантов тестирования", Игорь Бондаренко. Инженерам, на плечи которых только упала ноша управления командой тестирования он бы несомненно помог систематизировать свои знания. Все сорок минут человек рассказывал о тестовых активностях и том, как их разбили на четыре группы, эти самые квадранты. К концу, правда, так и не стало понятно зачем такое разбиения, но после того как был задан этот повисший в воздухе вопрос все стало ясно. Разбиение активностей по группам помогает команде по тестированию при работе на спринте. На этапе планирования все новые фичи и планируемые таски расклеивают по этим группам на тестерском scrumboard и дальше уже проще распределять их внутри по статусам.

Потом был обед и я пока прервусь :)

"Лучше давайте побыстрее закончим"

Последнее время я очень часто слышу эту фразу: "Давайте лучше сделаем это побыстрее".
Да, все хотят успеть сделать вовремя, или как можно быстрее, если это самое "вовремя" прошло.
Причины? Различные. В моем конкретном случае я все отношу к различным "окнам бессрочности" (вот тут прочитал) всех членов команды.

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

Если все же хочется это получить поскорее, то придется поступиться остальными углами треугольника менеджмента проектов. А QA помнят, что углов в треугольнике 4: время, ресурсы, деньги и качество :)

Автоматизировать можно быстрее

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

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

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

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

Простые истины для простых тестеровщиков

Хороший QA всегда разберется в сути проблемы и поможет решить ее.
Тестеровщик всегда найдет ошибку.

Организация работы

1. Всегда озвучивайдля начальника свое понимание задания, чтобы у вы оба говорили на одном и том же языке
2. Всегда перед началом постарайся понять владеешь ли ты полностью всей необходимой информацией для выполнения задания
3. Уверен ли ты, что владеешь всеми необходимыми знаниями для выполнения задания
4. Перед выполнением убедись, что в наличие имеется все необходимое тестовое окружение
5. Держи своего руководителя в курсе выполнения и особенно в курсе проблем. Это скорее поможет решить проблемы и/или вовремя предотвратить их. Руководитель может либо думать, что все плохо; либо, что все хорошо
6. Планируй свое время так, чтобы ты смог поместиться в выделенные временные рамки

Непосредственная работа

7. Любая возникшая ошибка должна быть изучена и описана наиболее детально.
8. Сразу после выполнения ошибки:
- сделай скриншот
- повтори ошибку, чтобы убедиться в надежности и полноте шагов для воспроизведения
- изменяй шаги и настройки, чтобы убедиться в том, что ошибка не касается "соседней" функциональности
- записать отчет о найденной ошибке
9. При записи ошибки в Кратком описании необходимо указать модуль/страницу, и описать проблему в 5-8 словах
10. Нельзя использовать слова "не работает", "не получается" при описании ошибки. Если окно не открывается, то оно "не открывается", а не "не работает"; если появляется системное сообщение об ошибке, то "появляется сообщение о системной ошибке", а не "не получается выполнить функцию"
11. При описании ошибки необходимо отобразить всю найденную в процессе изучения информацию; указать шаги для воспроизведения; полученный результаты; и ожидаемый результат
12. Ошибка должна быть описана так, чтобы у другого человека хотя бы немного знакомого с проектом не возникало желания пройтись по шагам воспроизведения , чтобы понять что же все-таки не так и где
13. Все сбои в контрольном списке (check list) должны иметь в комментариях ссылки на соответствующий отчет об ошибке