Анализ результатов тестирования производительности

Писал свой отзыв о конференции QA Dnepr Mini Conf. И вот добрался написать про то, о чем там рассказывал.
Предлагаю рассмотреть на примере анализ результатов тестирования производительности.

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

Для простоты собираем:

• Время отклика
• Хронологию отсылки запросов (календарное время)
• Код ответа сервера
• Объем пакета запроса
• Ответ сервера в случае ошибки

Внутренняя жизнь гугла в жалобах

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

Так вот у Oleg Eterevsky наткнулся на записку "Гуглеры жалуются на жизнь". Комментировать не буду

The free gym is too far for me to walk to. I need a free gym in my building so I can get some exercise without walking far.

The employee handbook is spread across multiple pages. 

These free $100 headphones mess up my hair

Every time I get a midday massage, I end up with pillow wrinkles on my face for the rest of the day.

5 of the 8 free t-shirts I got this year are black. Kinda irritating. I prefer blue. 

During our Google skydiving offsite, they promised a 50 seconds free fall, but watching the video I noticed it was only 41 seconds.

My 30" monitor blocks my view of the mountains.

The "Relax", "Refresh", and "Rejuvenate" settings for the massage chair feel exactly the same.

Sometimes when I go to get something to drink out of the micro-kitchen, it has just been restocked, so the drinks aren't even cold yet. Pretty frustrating.

The couch in my cubicle isn't quite long enough for me to fully lie down on.

The fact that Google provides 14 meals a week makes it cheaper to eat out on the weekend than stock my kitchen. As a result, I haven't had an opportunity to cook for like a year and my cooking skills are suffering.

There was no pizza left so I had to eat steak.

When the company pays for me to travel to other offices overseas the free snacks in the microkitchens are unfamiliar to me and I don't know which ones to choose.

It feels like every time I get used to a free phone, they go and give us a new one, and then I have to learn how to use that one.

Unlimited free food is making me fat.

I got sunburned a little on our Hawaii offsite.

Lady Gaga came to speak at Charlie's and I had to go the long way around to get my free lunch.

When I'm working from home I have to make my own breakfast, lunch *and* dinner.

I eat so much at the free breakfast that I'm not hungry enough in time for the free lunch.

The game room only had one beanbag, so I had to sit on a chair while playing Call of Duty.

The selection of classic arcade games in our building is too limited, and sometimes I have to walk to another building.

We built a catapult out of the custom furniture, but the ceiling is too low to launch oranges at people more than 150 feet away.

I can't see the Harbour Bridge in the morning because the sun rises over my panoramic views of the Sydney skyline and I have to lower the blinds.

I haven't gotten a free T-shirt in at least 3 months.

The sushi chef did not put enough aioli on my soft shell crab handroll.

The chalk for the pool cues is the wrong color for the table.

We have a view of the Bay Bridge from the office, but I want a view of the Golden Gate Bridge. It's prettier.

My desk is equally close to two microkitchens and I'm forced to decide which one to use.

Что я видел на QA Dnepr Mini Conference

В субботу состоялась первая QA Dnepr Mini Conference. Я там делился своими соображениями по анализу результатов нагрузочного тестирования.
Понравилась идея организаторов об отзывах докладчикам. Каждому участнику в раздаточных материалах выдали и одну бумажку небольшого блокнотного формата. И если участнику понравился доклад он писал свой отзыв на листочке и отдавал докладчику. Или не писал и отдавал докладчику. Я получил 9 таких и не знаю как у меня там с рейтингом отзывов, но ВСЕМ ОГРОМНОЕ СПАСИБО ЗА ЭТО. Я получил помимо спасибо еще и пару комментариев. Моя неспешность была взята на заметку :) К середине доклада я, конечно, проснулся и у нас получился с ребятами неплохая беседа по теме.
Если бы меня попросили придумать номинации, то в номинации "Самый спорный доклад" я бы отметил доклад Артема Розуменко "Как и зачем разрабатывать собственный фреймворк?". Его стандартный подход к автоматизации не вызвали бы такого ажиотажа в ранние субботние 10 утра, если бы не нестандартное применение. Больше всего споров было про независимость вызова фреймфорка: интегрировать c Continious Integration системами или нет. Как я понял - никто не мешает интегрировать, но у вас должна быть возможность запуска и без них или IDE. А также должен ли быть Ваш фреймворк project specific или нет. Немного неправильная с моей точки зрения постановка вопроса, да и Артем имел в виду то, что ядро должно быть независимым (ожидание ajax запросов, логирование, отчетность), а вот вспомогательные методы как логин, отсылка форм и т.п. всегда будет специализированным для проекта.
А как "Самый вызывающий доклад" - доклад Николая Алименкова "Жизнь без тестировщиков: миф или реальность?". Хотя что вы еще ожидали от доклада на конференции с почти 150ью тестировщиками, когда им со сцены говорят, что есть подходы позволяющие обойтись без тестировщиков в команде :) Вот народ с вызовом принял все доводы. Но, благодаря девушке из зала, Николай сознался, что тестировщика им не хватает. Хотя я бы использовал (и используем некоторые) такие подходы для улучшения качества выпускаемого продукта.
В общем и целом получилась очень хорошая конференция с домашней атмосферой, интересными докладами, конкурсами от спонсоров и подарками.

Надеюсь на приглашение организаторов на следующую конференцию.

Почему винчестер не назвали автоматом или байтометом?

Не знаю. На английском он тоже "тяжело" называется (Hard Disk Drive).

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


А вообще первый жесткий диск в том виде, как мы к нему привыкли состоял из двух пластин по 30 Мб. И его разработчики называли "30-30", что также является обозначением калибра популярного охотничьего ружья производства компании Winchester

Совет, который мне пришел на утро после QAConf 1.0

Вчера после своего выступления на QAConf разговаривали с одним молодым человеком, Test Team Lead'ом о том, можно ли использовать бёрндаун отмечая не задачи по сложности, а по количеству.
Пришли к выводу, что можно, но будет виден только прогресс, который нельзя будет хоть с какой-то достоверной точностью предвидеть. Но в любом случае он сможет помочь.

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

Как жизнь? Идет?

Хоть не понедельник и не пятница, а вторник сегодня, но какая разница какой день недели? День он и есть день, как его не назови.

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

А как выглядит твой берн даун?

Ковырялся с тем как наш берндаун составляется. Он автоматом и натолкнулся на вот такую статью http://www.scrumdesk.com/is-it-your-burn-down-chart/.

Она очень систематизирует знания о том, как интерпретировать бёрндаун и советы, что с ним делать. Использовал ее для своего начала разговора на QAConf 1.0. Перевод вольный

29 советов как оставаться креативным (Видео)

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

Посмотрите. Есть о чем подумать. А думать это полезно J

29 WAYS TO STAY CREATIVE from TO-FU on Vimeo.

IT-Jam 2011 Odessa

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

Вот видео моего выступления. Спасибо Паксли за съемку и Павлу за то, что выложил

QAConf 1.0. Анонс

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

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

Yahoos filling up the Burn down chart

Про политику и комерцию

Компании занимаются политикой в двух случаях

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

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

P.S из воспоминаний

Про ответственность

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

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

Немного про покрытие

О да, это вот маленький aftercomment к моему выступлению на IT-Jam 2011 в прошедшую субботу

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

Сертифицироваться ли на нагрузочное тестирование или нет?

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

И был коментарий в виде поста Andy Gloverа. Вот не могу быть более согласен :)

Заметка о процессах и взаимоотношениях

Что не писал я долго. И решил вот разродиться статьей на тему процессов и взаимоотношений. Версия 5ая, лаконичная:

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

Что главное в требованиях и знаниях о системе?

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

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

"Зачем?" Это ограниченое количество основополагающих фактов о системе, а огромное количество тестовых сценариев и/или сценариев использования - уже детали реализации и их можно, запросто, вывести.

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

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

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

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

Как в SQL получить то, чего в базе нет

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

Предыстория: регистрировал 1000 пользователей через http-запросы к системе. Получил отказы в 70% случаев. Регистрировал по маске u000
Задача: Выбрать список пользователей не зарегестрированых в системе. Если известен список зарегестрированых пользователей. А список пользователей, которых надо зарегестрировать соответствует определенной с буквенным префиксом и цифровым суффиксом, вырастающим инкрементально с шагом 1.

Получил решения от своих коллег разработчиков :)

Работа не должна мешать жизни, а жизнь работе

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

Где брать данные для проверки

Вещь поразительно очевидна. Самые лучшие тестовые данные - реальные данные.

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

Господа и дамы лидеры команд тестирования и не только, обновляйте тестовые ХД с серверов так часто как возможно (перед релизом это крайне полезно).

Почему мы не делаем работу на работе?

Пересматривал выступление Джейсона Фрида "Почему мы не делаем работу на работе" (Jason Fried Why Work Doesn't Happen at Work). Интересные результаты. 





Но вот при разработке программного продукта необходимо очень много командной работы. Когда действительно необходимо постоянное взаимодействие между людьми. И отвлекаться это нормально.
Хотя если надо написать тест дизайн или просто покрыть тестами функционал. Разобрать требования заказчика и проанализировать их. Проанализировать состояние проекта и написать отчет.... То тут явно хочется повесить видимую не только тебе табличку "Не беспокоить" на видимую не только тобой дверь (open space).

Overmeetinging

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

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

Следите за своими сроками

Подсмотрел у cartmendum'a тут. И не смог не перепостить :)

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

Нет элемента? Давайте посмотрим

Если просто вызвать нажатие на любой контрол, а его нет, то Selenium просто вернет соответствующую ошибку как то: null com.thoughtworks.selenium.SeleniumException: ERROR: Element Control not found


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

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

1) public void clickIfPresent(String elementLocator) {

        if (super.isElementPresent(elementLocator)){

            click(elementLocator);

        }

        else

            logHtmlSource("Element " + elementLocator + " doesn't exist");

    }

2) public void clickIfPresent(String elementLocator) {

        try {

            click(elementLocator);

        }

        catch (SeleniumException e){

            logHtmlSource("Element " + elementLocator + " doesn't exist");

        }

    }

Как тест инженер я разницы не вижу, но наши Java-разработчики говорят, что второй правильнее :)

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

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

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

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

Как бороться с ленью

Подсмотрел подход вот в статье Виктора Вертипрахова "Как перестать лениться и начать жить" (прошу прощения, если фамилию написал неправильно).

Суть проста. Если что-то лень делать -- начните делать ничего.

Не надо лениться и начинать играть или серфить в интернете. Просто перестаньте делать что-либо. Сесть и ждать пока не захочется работать. Если захочется начать что-либо делать, то надо продолжать ничего не делать. И так пока не захочется сделать что-то полезное.

Попробую!