Кто-то может решить, что эта запись - пиар курса Орлова и Панкратова. Если и так, то это не специально :) На самом деле, я просто хочу похвастаться и сказать:
Я СЧАСТЛИВА, ЧТО Я - ТРЕНЕР!
Логичный вопрос: "Почему?". Ниже - логичные ответы :)
1. Я общаюсь с умными людьми. На тренинги не ходят глупые люди, в итоге происходит существенный и однозначно приятный фильтр круга общения.
2. Я общаюсь с динамичными людьми. Динамика для меня важнее всего. Никогда нет чувства "болота". Всегда есть ощущение стремлений, роста. Развивающиеся ученики непрерывно транслируют развитие. Это мотивирует и привносит позитив!
3. Я бываю в разных городах. Только благодаря тренингам я смогла пообедать на 80 тысяч рублей. До сих пор хвастаюсь! :))
Ах, да, это были белорусские рубли в Минске.
Через 2 недели лечу в Киев - мой самый-самый любимый город!
4. Я всё время развиваюсь. Меня развивают ученики вопросами. У меня выписан огромный план по развитию, который я вижу необходимым, чтобы быть эффективным тренером. Надо не отставать от отрасли, надо всегда быть "на волне" - новые инструменты, новые техники. Тренинговая деятельность меня мотивирует развиваться ещё больше!
5. У меня много друзей. И, кстати, в разных городах. И, кстати, они очень умные и динамичные. Угадайте, где мы познакомились?
6. Чтобы провести 2х часовую онлайн-встречу, мне нужно в среднем 12-15 часов на подготовку. Обычно, я готовлюсь по ночам. С ноутбуком. В кафе. С чашечкой любимого латте с карамелью. Работа в подходящем графике и прекрасном окружении - для меня это важно!
7. И да, я на последок оставила самое главное. Я ОБОЖАЮ проводить тренинги, ОБОЖАЮ когда вижу прогресс у учеников, когда они делятся результатами и рассказывают про свершения. Мне это НРАВИТСЯ. I'm obsessed with it!!!
А теперь представьте себе человека, который делает то, что обожает, в сфере, которую считает самой интересной в мире, при этом он непрерывно общается с наиболее динамичными и умными представителями этой отрасли, находит себе новых друзей в этой сфере и мотается в разные интересные города.
Представили?
Это я!
четверг, 25 ноября 2010 г.
суббота, 20 ноября 2010 г.
SQA Days в 2:00 АМ
Я нахожусь в эпицентре тестерской жизни. Чуть позже я обязательно расскажу вам о самых интересных докладах, стараниях и достижениях организаторов и выложу слайдкасты.
Но...
Если вы думаете, что доклады - самое интересное, то вы ошибаетесь :)
Для тех, кого здесь нет, поделюсь фотоотчётом ночной жизни SQA Days.
Почему бы в 2 АМ не обсудить протоколы?
На этой фото - эпичесий момент. Борис (кодовое имя "Форм") рассказывает Олегу (кодовое имя "Актив") личную историю про ванну, кота и свечи:
Это не просто бородатый человек. Это мой самый любимый бородатый человек в мире :)
Хвастаться не хорошо. Но майка классная :)))
Результаты конкурса на самого красивого бармена:
2 Великие Женщины:
На заднем плане пытаются обсуждать тестирование...
Подозреваю, что безуспешно :)
Но...
Если вы думаете, что доклады - самое интересное, то вы ошибаетесь :)
Для тех, кого здесь нет, поделюсь фотоотчётом ночной жизни SQA Days.
Почему бы в 2 АМ не обсудить протоколы?
На этой фото - эпичесий момент. Борис (кодовое имя "Форм") рассказывает Олегу (кодовое имя "Актив") личную историю про ванну, кота и свечи:
Это не просто бородатый человек. Это мой самый любимый бородатый человек в мире :)
Хвастаться не хорошо. Но майка классная :)))
Результаты конкурса на самого красивого бармена:
2 Великие Женщины:
На заднем плане пытаются обсуждать тестирование...
Подозреваю, что безуспешно :)
суббота, 13 ноября 2010 г.
Школа Успешных Тестировщиков
По последним данным разведки, 25 ноября, в 16:00 по МСК, начнётся онлайн-курс "Школа успешных тестировщиков".
Она будет проводиться впервые, поэтому я немного боюсь :)
НО это не главное.
Главное - то, что она планирует быть интересной, насыщенной и очень многогранной. В ней я постаралась объединить техническую и методологическую информацию, заправить карьерными IDDQD и сдобрить командной работой в закрытой группе.
Гарантированный результат:
- пропеллер в одном месте (кажется, это называется "мотивация"...)
- раскладывание всего и вся по полочкам
- 438 секретов про то, как Тестировщики-Джедаи находят и заводят баги всех видов, получая от процесса максимум удовольствия
- инструменты тестирования, тест-дизайна, автоматизации и не только
- тайны успешных коммуникаций с разработчиками, руководством и коллегой справа
По-хорошему, здесь надо дать ссылку на программу. Но настоящий тестировщик её и сам найдёт, а ненастоящих мы не берём :)
Так что, если Вы хотите быть Творцом и Исследователем в тестировании - Welcome!
А если не хотите - то лучше не записывайтесь!
Она будет проводиться впервые, поэтому я немного боюсь :)
НО это не главное.
Главное - то, что она планирует быть интересной, насыщенной и очень многогранной. В ней я постаралась объединить техническую и методологическую информацию, заправить карьерными IDDQD и сдобрить командной работой в закрытой группе.
Гарантированный результат:
- пропеллер в одном месте (кажется, это называется "мотивация"...)
- раскладывание всего и вся по полочкам
- 438 секретов про то, как Тестировщики-Джедаи находят и заводят баги всех видов, получая от процесса максимум удовольствия
- инструменты тестирования, тест-дизайна, автоматизации и не только
- тайны успешных коммуникаций с разработчиками, руководством и коллегой справа
По-хорошему, здесь надо дать ссылку на программу. Но настоящий тестировщик её и сам найдёт, а ненастоящих мы не берём :)
Так что, если Вы хотите быть Творцом и Исследователем в тестировании - Welcome!
А если не хотите - то лучше не записывайтесь!
Про микроменеджмент
У каждого руководителя есть свой индвидуальный стиль. Различные подходы, идеи, взгляды и особенности формируют уникальный стиль менеджмента. Если разделить его на кусочки, то почти ничто нельзя назвать "плохим" и "хорошим", потому что все факторы взаимосвязаны.
Хотя...
Пожалуй, есть одна отличительная особенность в управлении, которая всегда, всегда, всегда плохая. По крайней мере, если мы говорим об управлении командой ИТ-шников.
Это - МИКРОМЕНЕДЖМЕНТ.
Микроменеджмент - это подход, при котором сотрудникам даются маленькие задачки. За их выполнением зачастую непрерывно следят на каждом этапе. Сотрудникам чётко определяют, КАК что сделать. За них всё разжёвывают, стоя за спиной и говоря: "Нажми сюда, теперь сюда, таааак, чуть левее..."
Финиш.
И знаете, что самое ужасное?
Микроменеджмент проявляется почти у всех!
Почему микроменеджмент - это плохо?
1. Потому что он отнимает рабочее время у руководителя.
Вместо того, чтобы делегировать сотруднику задачу, такой руководитель разжёвывает всё на кусочки, в труху. В итоге у руководителя аутлук похож на праздничную гирлянду из красных флажочков, и нет ни одной задачи, в которую он не должен засунуть свой нос.
2. Потому что он препятствует развитию сотрудников.
Вместо смелой команды, готовой к свершениям, микроменеджеры получают микросотрудников, решающих нанозадачи.
3. Потому что он демотивирует сотрудников.
Я Вам не скажу про всю Одессу, но инициативные и стремящиеся к развитию сотрудники ненавидят, когда им всё слишком строго определяют. Им нужно ТВОРЧЕСТВО. А вместо этого микроруководиль превращает работу своих сотрудников в РУТИНУ.
4. Потому что он приводит к концентрации на мелочах.
Глаза в глаза лица не увидеть. Микроменеджеры настолько сконцентрированы на нанолабуде, что у них нет времени трезво окинуть ситуацию взглядом, приоритезировать свою работу и увидеть наиболее важные задачи. Потому что они очень, очень заняты. Микрозадачами.
5. Потому что он вызывает bottleneck. В лице руководителя.
Потому что ему везде надо сунуть свой нос. Но он сконцентрирован на мелочах. И он очень занят. Ну, вы понимаете, результат неизбежен.
6. Потому что он препятствует развитию потенциала команды.
Если микроменеджер определяет, КАК решать задачу - то он задействует ресурс своих сотрудников на 5 процентов. 5 низкоквалифицированных процентов нажимателей на кнопки. Вместо того, чтобы задействовать остальные 95% творцов, исследователей и идеегенераторов.
Получается, микроменеджмент - это плохо. Это очевидно, неизбежно, однозначно плохо (я не уверена насчёт заводов и армии, и говорю лишь о тестировании). Но почему менеджеры, которые обладают достаточным уровнем интеллекта, продолжают, продолжают страдать этой фигнёй?
Почему?
1. Так привычнее.
Откуда появились менеджеры? Не из отдельной капустины и не из соседнего института. Менеджеры - бывшие исполнители. Им привычно, уютно и комфортно решать исполнительские задачи. А бремя ответственности эффективного менеджера, умеющего делегировать - некомфортно и неуютно.
2. Так круче.
Представьте, насколько обидно неуверенным в себе менеджерам, если их получасовое опаздание на работу не вызовет панику, потоп и пожар одновременно? Зато, если они сделают себя узким горлышком, они всегда, всегда, всегда будут самыми важными и незаменимыми. Хм, и вправду круто!
3. Им интересно.
"Давайте поиграем в решение задачки Х", думают микроменеджеры. И играют :) Забывая, что это НЕ ИХ игра.
4. Они никому не верят.
Ни себе, ни окружающим. А вдруг он не справится? Нет уж, лучше я ему помогу заранее. Тогда мы точно не успеем сделать самые главные проектные задачи, но вот эту нанохреновинку мы прикрутим как надо!!
5. Им страшно.
Они боятся второго вселенского потопа и зачитываются статьями о теории заговора. И естественно они боятся, что их сотрудники будут слишком круты и посягнут на Босса. Поэтому, они очень хотят, чтобы их сотрудники были всё менее и менее толковыми, свободными и развивающимися.
И всё равно просыпаются по ночам в холодном поту :)
Если мой босс - микроменеджер, ТО...
Надо валить. И побыстрее. Исправить это почти невозможно, развиваться и двигаться в такой ситуации - тоже.
Если я - микроменеджер, ТО...
Надо что-то исправлять. Потому что:
- карьерная планка микроменеджера, не умеещего развивать своих сотрудников, невысока
- работа - сплошной геморрой
- результаты всегда хуже чем хочется
- а вся команда состоит из несчатных, которые ещё в 17:00 начинают сверлить часы взглядом и умаляя стрелки двигаться быстрее.
p.s. При ответе на вопрос "Я микроменеджер?" важно быть честным с собой :)
Хотя...
Пожалуй, есть одна отличительная особенность в управлении, которая всегда, всегда, всегда плохая. По крайней мере, если мы говорим об управлении командой ИТ-шников.
Это - МИКРОМЕНЕДЖМЕНТ.
Микроменеджмент - это подход, при котором сотрудникам даются маленькие задачки. За их выполнением зачастую непрерывно следят на каждом этапе. Сотрудникам чётко определяют, КАК что сделать. За них всё разжёвывают, стоя за спиной и говоря: "Нажми сюда, теперь сюда, таааак, чуть левее..."
Финиш.
И знаете, что самое ужасное?
Микроменеджмент проявляется почти у всех!
Почему микроменеджмент - это плохо?
1. Потому что он отнимает рабочее время у руководителя.
Вместо того, чтобы делегировать сотруднику задачу, такой руководитель разжёвывает всё на кусочки, в труху. В итоге у руководителя аутлук похож на праздничную гирлянду из красных флажочков, и нет ни одной задачи, в которую он не должен засунуть свой нос.
2. Потому что он препятствует развитию сотрудников.
Вместо смелой команды, готовой к свершениям, микроменеджеры получают микросотрудников, решающих нанозадачи.
3. Потому что он демотивирует сотрудников.
Я Вам не скажу про всю Одессу, но инициативные и стремящиеся к развитию сотрудники ненавидят, когда им всё слишком строго определяют. Им нужно ТВОРЧЕСТВО. А вместо этого микроруководиль превращает работу своих сотрудников в РУТИНУ.
4. Потому что он приводит к концентрации на мелочах.
Глаза в глаза лица не увидеть. Микроменеджеры настолько сконцентрированы на нанолабуде, что у них нет времени трезво окинуть ситуацию взглядом, приоритезировать свою работу и увидеть наиболее важные задачи. Потому что они очень, очень заняты. Микрозадачами.
5. Потому что он вызывает bottleneck. В лице руководителя.
Потому что ему везде надо сунуть свой нос. Но он сконцентрирован на мелочах. И он очень занят. Ну, вы понимаете, результат неизбежен.
6. Потому что он препятствует развитию потенциала команды.
Если микроменеджер определяет, КАК решать задачу - то он задействует ресурс своих сотрудников на 5 процентов. 5 низкоквалифицированных процентов нажимателей на кнопки. Вместо того, чтобы задействовать остальные 95% творцов, исследователей и идеегенераторов.
Получается, микроменеджмент - это плохо. Это очевидно, неизбежно, однозначно плохо (я не уверена насчёт заводов и армии, и говорю лишь о тестировании). Но почему менеджеры, которые обладают достаточным уровнем интеллекта, продолжают, продолжают страдать этой фигнёй?
Почему?
1. Так привычнее.
Откуда появились менеджеры? Не из отдельной капустины и не из соседнего института. Менеджеры - бывшие исполнители. Им привычно, уютно и комфортно решать исполнительские задачи. А бремя ответственности эффективного менеджера, умеющего делегировать - некомфортно и неуютно.
2. Так круче.
Представьте, насколько обидно неуверенным в себе менеджерам, если их получасовое опаздание на работу не вызовет панику, потоп и пожар одновременно? Зато, если они сделают себя узким горлышком, они всегда, всегда, всегда будут самыми важными и незаменимыми. Хм, и вправду круто!
3. Им интересно.
"Давайте поиграем в решение задачки Х", думают микроменеджеры. И играют :) Забывая, что это НЕ ИХ игра.
4. Они никому не верят.
Ни себе, ни окружающим. А вдруг он не справится? Нет уж, лучше я ему помогу заранее. Тогда мы точно не успеем сделать самые главные проектные задачи, но вот эту нанохреновинку мы прикрутим как надо!!
5. Им страшно.
Они боятся второго вселенского потопа и зачитываются статьями о теории заговора. И естественно они боятся, что их сотрудники будут слишком круты и посягнут на Босса. Поэтому, они очень хотят, чтобы их сотрудники были всё менее и менее толковыми, свободными и развивающимися.
И всё равно просыпаются по ночам в холодном поту :)
Если мой босс - микроменеджер, ТО...
Надо валить. И побыстрее. Исправить это почти невозможно, развиваться и двигаться в такой ситуации - тоже.
Если я - микроменеджер, ТО...
Надо что-то исправлять. Потому что:
- карьерная планка микроменеджера, не умеещего развивать своих сотрудников, невысока
- работа - сплошной геморрой
- результаты всегда хуже чем хочется
- а вся команда состоит из несчатных, которые ещё в 17:00 начинают сверлить часы взглядом и умаляя стрелки двигаться быстрее.
p.s. При ответе на вопрос "Я микроменеджер?" важно быть честным с собой :)
понедельник, 8 ноября 2010 г.
Шаблон чек-листов
Чек-листы иногда бывают нужны, иногда полезны, иногда необходимы. А знать, какими они бывают и как их можно использовать, нужно всегда.
Я свела в одной табличке 5 самых простых видов Ч-Л, снабдив их небольшими примерами и сравнением характеристик.
На полноту результатов не претендую, если есть что добавить - welcome!
Скачать сие творение мысли можно здесь:
http://quality-lab.ru/files/checklists.xls
Я свела в одной табличке 5 самых простых видов Ч-Л, снабдив их небольшими примерами и сравнением характеристик.
На полноту результатов не претендую, если есть что добавить - welcome!
Скачать сие творение мысли можно здесь:
http://quality-lab.ru/files/checklists.xls
понедельник, 1 ноября 2010 г.
Ода тестированию производительности, или ХВАТИТ ПУТАТЬ ЕГО С НАГРУЗОЧНЫМ!
В нашу эру центрального отопления и повальной распространённости веб-сервисов многие люди, даже мэтры тестирования, предлагают рассматривать нагрузочное тестирование и тестирование производительности лишь в связке. Причина проста: тестируем веб, вот и смотрим скорость отклика (производительность) под разной нагрузкой: от одного до 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!
В результате такого восприятия теряется понимание тестирования производительности, которое является НУ ОЧЕНЬ важным, потому что:
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!
Подписаться на:
Сообщения (Atom)