« Я тестер ! »

Эффект горизонта

noreply@blogger.com (Maksim Grinevich) — Tue, 04 Oct 2011 16:32:00 +0000

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

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

Как же этот эффект проявляется в тестировании:

Неправильно выбираются тесты для автоматизации
Ошибки в выборе тестов для прогона при ограниченном времени
Ошибки при планировании тестирования
Ошибки в выборе средств тестирования(от багтреккера до документов) и автоматизации

Методы сглаживания эффекта или как с этим бороться?

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

Расширить уровень горизонта за счет поиска «интересных» мест и продвижения «тихих» или «громких» ходов (Quiescence search)
Минимизировать потери при максимизации прибыли (Minimax| Maximin) и его уточнение с помощью отбрасывания более «слабых» уже найденных ходов (Alpha-beta pruning)

Теперь же о главном…

Как можно применить указанное выше:

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

Вместо заключения:

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

Тестирование оптимизации...

noreply@blogger.com (Maksim Grinevich) — Wed, 21 Sep 2011 15:40:00 +0000

В процессе тестирования поставок клиентам часть задач (около 10%) связана с оптимизацией кода на SQL.

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

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

Куча первая - проблемы БД:

фоновые процедуры (служебные job'ы и процедуры приложения, выполняемые в фоновом режиме)
"служебные" активности БД: пересчет индексов, высвобождение temp'овых таблиц, оптимизация хранения данных на жестком диске

Куча вторая - проблемы данных и процессов приложения:

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

Мелкие камешки в повторении состава "железа" и скорости работы исполнителя разбросаем вокруг.

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

Зачем все танцы с бубном, которые займут ещё и кучу времени, если мы изобретаем велосипед для нагрузочного тестирования?

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

Но тогда возникает резонный вопрос у заказчика - ~~а был ли мальчик?~~ А исправили ли медленную работу ПО?

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

----------------

*Рассматриваем ситуации оптимизации процедур и функций в рамках произведения комплексных процессов: закрытия операционного дня банка; пересчет PnL и PV позиций; обработки 1000К сообщений для отправки и т.д. (код, а не бизнес-логика этапов процесса)

P.S.: все хотел куда-нибудь серых человечков добавить :)

Боец тестирования банковского ПО в Минске, Гродно или Бресте будет успешно принят на работу

noreply@blogger.com (Maksim Grinevich) — Fri, 25 Mar 2011 14:28:00 +0000

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

Ко мне в команду нужны бойцы невидимого фронта тестирования.

Требования:

- быть готовым за очень короткие сроки овладеть большим объемом информации

- знать, что такое функциональное тестирование (и чем оно отличается, скажем, от нагрузочного)

- разговаривать с компьютером на «ты»

Плюсом будет:

- знание любого скриптового языка

- знание SQL

- опыт тестирования

- огромное желание стать тестировщиком

- знание правил бухгалтерского учета

Если ты студент(ка) или не имеешь опыта работы, но безумно трудолюбив(а) и талантлив(а) – пиши, возможно именно для тебя осталось место!

Писать на colvir[гав]yatester.ru или нашему HR - ohaetckaya[гав]colvir.ru

О компании.

Кстати, знание английского вовсе не требуется – совещаемся и пишем по-русски J

Никогда не говори никогда и другие 10 никогда...

noreply@blogger.com (Maksim Grinevich) — Fri, 25 Feb 2011 06:48:00 +0000

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

1. Здесь багов нет - я гарантирую.
2. Всё равно, никто не использует Firefox!
3. Cem Kaner и James Bach вообще не понимают, о чем говорят.
4. Это срочно? Я тут просто в Farmville играю.
5. У меня на компьютере все работает!
6. Я только что написал в твиттере о дыре в нашей системе безопасности...
7. Использовать инструменты для тестирования? Я справлюсь без них!
8. На самом деле я отличный тестировщик, пока не трезв..
9. Ты прав, мне тоже кажется что сообщение об ошибке - это новая фича.
10. Если здесь остались баги, их найдут beta-пользователи...

Источник

Возможно ли построить идеальный процесс тестирования?

noreply@blogger.com (Maksim Grinevich) — Fri, 29 Oct 2010 09:31:00 +0000

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

ИПТ

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

Что такое?

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

ИПТ не существует

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

ИПТ существует

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

Как?

Создание ИПТ сопряжено с набором следующих действий, которые следует повторять в течении проекта:

I. Описать то место в проекте, времени и команде, в котором вы находитесь;

II. Идентифицировать проблемные места
1. идти от проблемы
2. с точки зрения цели:

удобный для достижения цели
предсказуемый результат
понятный объем работ

III. Приоритизировать проблемы
   1 решать по одной из каждой выделенной области в единицу времени
   2 параллельное решение из несмежных областей

IV. Внести изменения
   1 мотивация команды
   2 обратная связь
   3 довести изменение до конца

V. Проанализировать результат

Несколько примеров

Пример первый.

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

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

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

Пример – второй.

Крупная оффшорная компания. Выделенный центр разработки для одного западного информационного агентства составом в Х человек, из которых 30-40 человек – группа тестировщиков.

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

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

В дополнение хочу показать карту памяти, которую я использовал для подготовки этого сообщения:

Спасибо mindmeister за сервис.

Why? Why not? Why not me? Why not now?

noreply@blogger.com (Maksim Grinevich) — Tue, 26 Oct 2010 06:51:00 +0000

Не совсем про тестирование, но очень понравилось:

"For true success ask yourself these four questions: Why? Why not? Why not me? Why not now?"

(с) James Allen

"Для настоящего успеха задайте себе следующие четыре вопроса: Почему? Почему бы и нет? Почему не я? Почему не сейчас? "

(с) Джеймс Аллен

20 причин почему не надо тестировать

noreply@blogger.com (Maksim Grinevich) — Sun, 24 Oct 2010 19:09:00 +0000

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

1) Нам не требуется такого уровня тестирования.
2) Это стоит ~~до{хрена}~~ кучу денег.
3) Слишком долго будете копаться.
4) Тестирование никогда «не завершится полностью».
5) Мы никогда не знаем, сколько времени уйдет на тестирование.
6) Слишком академично, мы же не NASA.
7) А его собственно и в плане то не было.
8) Тестирование сильно тормозит выход продукта.
9) Кастомер просто весь в нетерпении, а ваши тестеры тормозят процесс.
10) Тестирование выставляет нас идиотами.
11) А какой толк вообще от тестирования?.
12) Пока тестеры нароют все баги – рынок ушагает от нас.
13) Да и вообще всем пофигу на эти баги.
14) А собственно тестирование вообще не дает ответа ни на какой вопрос.
15) Разрабы сами все протестят.
16) Не надо ломать систему, и так работает не очень.
17) Пользователь сам найдет баг и мы все пропатчим.
18) Ну нет у нас времени, чтобы написать требования.
19) И вообще, тестеры никогда не находят самые нужные баги.
20) Тестирование все равно никогда не найдет всех багов.

Верное отношение...

noreply@blogger.com (Maksim Grinevich) — Wed, 21 Jul 2010 12:21:00 +0000

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

Хорошее отношение менеджеров и лидов проекта к введению тестирования или преобразованию от «потестить что-то» к более менее результативному процессу значит:

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

— отсутствие явных противодействий, «палок в колесах»...

Как минимум нейтральное отношение рядовых программистов говорит:

— о желании делать хороший продукт, а не «хотфиксы» :)

— стремлении улучшить себя и свою работу (они ведь знают, что теперь за ними будут - следовательно стараются делать лучше)

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

Как это сделать? — Ответ для каждого случая свой, но для себя выделил несколько простых вопросов, которые помогают в разговоре:

1. Какая выгода менеджеру/девелоперу лично?

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

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

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

3. А проект/задача от этого выиграют?

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

4. «Улучшения» выглядят как улучшения или как очередные заморочки тех, у кого работы не много?

5. Получено ли подтверждение/разрешение от «высокого» менеджмента?

Удар ниже пояса, но некоторых приходится «убеждать» именно так :(

Процесс это не про документы, это про людей.

noreply@blogger.com (Maksim Grinevich) — Tue, 06 Jul 2010 07:35:00 +0000

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

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

Процесс разработки/тестирования, как пицца - основа в большинстве случаев одна/две/три, а ингридиентов множество :)

Первоисточник дороже всего!

noreply@blogger.com (Maksim Grinevich) — Wed, 23 Jun 2010 12:56:00 +0000

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

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

Ошибается каждый, но детские ошибки делать НЕ позволительно!

Это была лирика, а теперь выводы.

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

Попросите 2-3 человека описать Красную площадь или Статую свободы - получите ли вы одно и то же описание? А если посмотите сами на картинку..а если потом "вживую" - сколько разных описаний вы получите?

Мир с ног на голову

noreply@blogger.com (Maksim Grinevich) — Mon, 07 Jun 2010 07:10:00 +0000

Гляньте-ка вот на эту карту мира!

(по клику - увеличивается)

Странного ничего не находите?..

А это всего лишь южно-ориентированная карта мира.

Пару заметок для тестировщиков далее...

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

1. Переключитесь на другую задачу на пару дней/часов.

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

2. "Прогуляйтесь" по продукту с кем-нибудь из команды.

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

3. Посмотрите демку конкурентов.

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

4. Попросите конечного пользователя или Project manager'а рассказать о продукте его словами

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

Источник на английском: Joel Montvelisky qablog.practitest.com

Effective writing

noreply@blogger.com (Maksim Grinevich) — Thu, 20 May 2010 18:08:00 +0000

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

Несколько пунктов, влияющих на то, как должно быть написано письмо:

WHO		HOW
Позиция и авторитет		Тон письма: подчиненый - > начальник начальник - > подчиненый равный к равному
Количество знаний о теме сообщения		Степень детализации информации
Отношение к теме письма		Положительное, отрицательное, нейтральное
Суть сообщения		Какие факты нужно упоминать и в каком количестве?

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

Процесс, который проходит сообщение:

Привлечение внимания
Понимание
Согласие
Дествие

На каждом из этапов отсеивается порядка 10%. Итого, будет хорошо, если только 67% (0,9*0,9*0,9*0,9) посланных сообщений дойдут до стадии Действие - цели письма.

У каждого запроса/письма должна быть цель достигнуть Действия получателя. Бездействие - это одна из форм действия (например, Вас не уволили - какое приятное бездействие)

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

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

Ещё говорили о:
- культуре/национальность получателя (линейно-активная, мульти-активная, реактивная) и её влиянии на восприятие информации
- как говорить "нет" politely
- о 3S (Short, Simple, Specific) и 5H+W (Why, Where, What, Who, When + How )
- многом-многом другом

Не думаю, что тренер попадет на мой блог, но все равно говорю ему спасибо.
Тренер: Сергей Кузин

1, 0 и 10

noreply@blogger.com (Maksim Grinevich) — Tue, 11 May 2010 08:50:00 +0000

Давеча посмотрел фильм ПОП Владимира Хотиненко. Там главный герой рассказывает нерадивому мужу о семейных отношениях между мужем и женой (мой вольный пересказ):

... Без жены я (мужчина, поп) всего лишь единица. Жена без меня — 0. А вместе мы образуем 10 (десятку)...
... Жена — это мой точильный камень. Благодаря ей, то что я делаю получается значительно лучше, чем без неё...

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

Программирование без тестирования способно что-то делать — назовем результат 1. А вот при включении в разработку тестирования (которое само по себе 0) — получаем в результате 10 (десять).А про то, как тестировщики в процессе работы помогают программистам «заточить» продукт, и говорить нечего.

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

P.P.S.: уважаемые девушки, по поводу того, что в притче девушка названа 0 — претензии к автору романа или сценаристу фильма :)

Иллюзионисты в тестировании...

noreply@blogger.com (Maksim Grinevich) — Wed, 21 Apr 2010 12:55:00 +0000

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

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

Первая иллюзия - тестировщик лично отвечает за качество ПО.

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

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

Вторая иллюзия - тестировщик слабое место проекта.

Если Вы в такой ситуации, то нужно быть настоящим мастером иллюзии (как например Граф Александр Калиостро), чтобы неспеша, но четко, показать: кто на самом деле пишет ошибки/задерживает своими ошибками релиз/подставьте нужное.

Иллюзия третья - ошибки становятся ошибками только в руках тестировщика.

Чтобы объяснять эту мысль стоит вспомнить фрагмент фильма Трасса 60(Interstate 60)(если Вы его не видели, то стоит обратить на него свое внимание):

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

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

Кроме того, часто бывает, что тестировщики (как и все люди) строят иллюзии относительно себя.

Само - иллюзия №1: Тестирование - это одно из ключевых позиций в разработке.

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

Само - иллюзия №2: Крутое/качественное/великолепное/внимательное/"и все остальные превосходные комплименты" тестирование приведет к такой же "популярности", как и программирование.

Много вы знаете людей, которые стали известны благодаря своим "тестировщицким" успехам? Только называйте русские имена! (Пару человек возможно и назовете) Большинство известных людей стали стоить дорого как футболисты только благодаря своей переквалификации в менеджеры/книгописатели/тренингочитатели/и т.д.

Представьте, что вам нужно в двух-трех словах сказать о достигнутых успехах. "Я тестировал продукт Х!", "Я написал столько-то/для такого-то софта/в такой-то фирме тестовых сценариев!" - звучит как-то не очень убедительно. Думаю, вы не откажитесь признать, что слова "Я разработал/написал/управлял созданием продукта Х (Linux RedHat / Windows / GoogleMail / GoogleWave / add yours)" и подобные - звучат на много интереснее.

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

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

P.S.: А вы считаете себя иллюзионистом/ской?

QTP и Silktest в одном флаконе?

noreply@blogger.com (Maksim Grinevich) — Thu, 08 Apr 2010 08:13:00 +0000

При поиске подходящего средства автоматизации на новом месте работы столкнулся с проблемой совместной установки QuicktestPro и SilkTest.

На компьюетр установлен QTP - запущен и таки или иначе проверн на совместимость с тестируемым продуктом.

Затем от проиводителя получена триальная версия SilkTest'а. Она успешна прошла установку и даже запуск! Но при попытке использовать распознование объектов или запись - валяться ошибки подобные следующим (причем они выглядят как просто сообщения от рекордера и не приводится стектрейс):

com/mercury/javashared/agentloader/agentbootstrap
com.mercury.javashared.infra.native
java.lang.exceptionininitializerError

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

Чтобы поправить ситуацию нужно:

Удалить или почистить глобальные переменные IBM_JAVA_OPTION, _JAVA_OPTION и JAVA_TOOL_OPTIONS.

Более подробно можно прочитать здесь.

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

Помогай помогающему тебе

noreply@blogger.com (Maksim Grinevich) — Tue, 23 Mar 2010 14:37:00 +0000

Многим из нас кажется, что помогающие нам люди не нуждаются в нашей помощи.

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

Разве важно помогать коллеге с написанием тестовых сценариев и ревью, если он это делает с моими?

Разве необходимо сообщать лидеру группу о запросах от стейкхолдеров/изменениях в требованиях, ведь он и так об этом знает и сообщает команде?

Я скажу: Нужно, Важно, Необходимо...

Каждый из членов проекта — составная его часть. Если вы только будете что-то «брать», ничего не возвращая, то скоро станете ненужным в проекте. Задача каждого игрока команды своими действиями помогать коллегам, ведь именно тогда общий delivery от группы/команды/фирмы будет выше/лучше/"зеленее". Даже если вы в большой фирме и ваш вклад незаметен не только при первичном осмотре, но и при использовании микроскопа — все равно вносите свой посильный вклад. Вы не знаете, когда ваши действия достигнут результата (вдруг это случится при следующей раздаче премии/повышении или чем-то другом не менее вкусном).

——————
Получилось не про тестирование, но надеюсь, что суть понятна ;)

Какова же цель/задача тестировщика?

noreply@blogger.com (Maksim Grinevich) — Mon, 15 Mar 2010 12:48:00 +0000

Алексей Баранцев здесь говорит:

«Главная деятельность тестировщиков заключается в том, что они предоставляют участникам проекта по разработке программного обеспечения отрицательную обратную связь о качестве программного продукта.»

Ту же самую идею недавно описал Д. Спольски в своей статье «Why testers?»

«A great tester gives programmers immediate feedback on what they did right and what they did wrong.»

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

Может быть на самом деле несколько вариантов (список не ограничен — ваши версии всегда уместны в комментариях):

1. Тестировщик — не влияет на проект.

В данном случае, на самом деле, от тестировщика ждут всего лишь информации.

2. Тестировщик влияет на проект.

Тестировщик добывает информацию для себя, чтобы определить, может ли он САМ выпустить релиз и взять на себя ответственность за качество выпускаемого продукта. Такая ситуация не менее распространена, чем первая. Причем, считаю её более важной. Ведь сама постановка вопроса: дать информацию или подписаться под выпуском продукта — ведет к более серьезному подходу. Люди разные, воспринимают мир индивидуально, но если тестировщик не несет ответственности за релиз, его руки развязаны — задержки релиза, выпуск не достаточно качественных версий и т.д. Конечно, гильотину не стоит показывать в качестве возможного исхода событий, но серьезная доля ответственности вполне приемлема.

3. Тестировщик — мега мозг проекта/релиза.

Такое встречается очень редко и зачастую выходит за стандартные задачи тестировщика.

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

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

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

Как стать экспертом в тестировании

noreply@blogger.com (Maksim Grinevich) — Tue, 09 Feb 2010 09:32:00 +0000

Вот оно! Теперь понятно, как стать настоящим экспертом в тестировании, нужно всего лишь...

Спасибо уважаемому Andy Glover'y за тестирование в комиксах!

The Rise And Fall of Waterfall

noreply@blogger.com (Maksim Grinevich) — Fri, 05 Feb 2010 16:58:00 +0000

Наконец-то уважаемый Zenegment (в жизни Максим Дорофеев) завершил свой короткометражный фильм The Rise And Fall of Waterfall.

Этот фильм-клип обещал быть интересным ещё по трейлеру.

Смотрите здесь или идите в его ЖЖ, там можно и откомментировать :).

Самая острая память

noreply@blogger.com (Maksim Grinevich) — Thu, 04 Feb 2010 10:06:00 +0000

И вновь я возвращаюсь к теме цитат из народа.

«Самая острая память тупее самого тупого карандаша».

Если хотите что-то запомнить — запишите.

Сниму квартиру в Москве

noreply@blogger.com (Maksim Grinevich) — Mon, 25 Jan 2010 14:02:00 +0000

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

Все требования и пожелания далее по тексту...

Квартира нашлась - cian.ru обошел даже активных риелторов :).

Суеверия тестировщиков

noreply@blogger.com (Maksim Grinevich) — Mon, 18 Jan 2010 15:10:00 +0000

Суеверие — суетная вера — вера в пустое.

Тестировщики, как и все остальные земляне, не остаются в стороне и верят. Верят, порой не имея особых на это оснований...

Профессиональное:

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

Менеджерское (о тестировании):

тестировщики стоят дешевле программистов
если на проекте появляется новый тестировщик, вырастает количество ошибок, которые напишут программисты
чем больше времени на тестирование, тем меньше ошибок попадет к заказчику
тестировщики не просят дополнительного времени на тестирование — «они что там совсем не работают?»

Программистское:

приход / письмо / «typing» в мессенджере от тестировщика — к багу
тестировщик долго тестирует и молчит / нервно курит / ехидно улыбается / щебечет с такими же, как сам — к бООльшому багу

~~Пост~~ Кризисное:

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

А во что верите вы?

P.S.: Возможно не все из перечисленного суеверия...

Приключения майора Звягина

noreply@blogger.com (Maksim Grinevich) — Wed, 13 Jan 2010 11:52:00 +0000

Недавно Денис Петелин дал почитать довольно интересную книгу Михаила Веллера «Приключения майора Звягина».

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

Книга о том:

как надо жить, чтобы жизнь была в радость — но без пустых нравоучений
как мужественно противостоять проблемам — но без кичливого самовосхваления
как можно добиваться своих целей — но без инструкций типа «25 шагов и вы у цели»
что зачастую один человек может помочь другому — считая выгодой для себя саму возможность решить трудную головоломку
что нужно дарить радость жизни тем, у кого её нет — а на средства достижения смотреть не стоит
как управлять людьми — но так, что люди даже не подозревают об этом
как мотивировать людей — но без заезженных игр/забав/прибауток

Далеко не все методы майора Звягина приемлемы для меня, но эпилог книги очень многое объясняет. Советую прочитать, особенно тем, кто любит читать про судьбы известных/неизвестных людей. (тут этого нет в чистом виде, но жанр сохранен)

От издателя:

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

Скачать

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

В главном — единство...

noreply@blogger.com (Maksim Grinevich) — Mon, 11 Jan 2010 17:34:00 +0000

«В главном — единство,

во второстепенном — свобода,

во всем — любовь»

Августин Блаженный

Единство:

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

Только тогда проект/билд/релиз/и т.д. будет успешен, когда ВСЕ, именно все, члены команды будут работать на эту главную цель.

Когда цель ясна:

— длительные рабочие дни (которые лучше уже называть рабочими сутками) не вызывают претензий;

— успешность деятельности не соразмеряется с уровнем зарплаты;

— удовлетворенность/увлеченность работой перевешивает какие-либо межличностные конфликты;

— т.д.

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

Свобода:

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

Любовь:

Святой Августин был верующим человеком, поэтому он оперировал и таким понятием как любовь. Что же такое «любовь» в контексте IT сферы? Ведь там где бизнес и деньги, там нету места чувствам. Кажется так говорили новоявленные «бизнесмены» последних 2-х десятилетий прошлого столетия? Тогда на самом деле нужны были винтики, человеко-роботы, которые никогда не ломаются и не болеют, не имеют вредных привычек и разных характеров. Сейчас же у нас совершенно другое время: сейчас не только работодатель выбирает себе работника, но и работник зачастую перебирает — где же ему будет комфортно работать. Подробнее об этом написал «директор белорусской силиконовой долины» .

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

— интересных проектах/задачах

— финансовой компенсации проведенных за работой часов (читай зп)

— хороших условиях труда

— чего_кому_ещё_надо

С другой же стороны это выражается в:

— высокоорганизованной работе над проектами/задачами

— самоотдаче

— продуктивности

— всего_чего_надо_заказчику

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

В итоге:

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

P.S.:

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

С Рождеством Христовым!

noreply@blogger.com (Maksim Grinevich) — Thu, 24 Dec 2009 22:58:00 +0000

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

KJV: Though I speak with the tongues of men and of angels, and have not charity, I am become as sounding brass, or a tinkling cymbal.

2. Если имею [дар] пророчества, и знаю все тайны, и имею всякое познание и всю веру, так что [могу] и горы переставлять, а не имею любви, -- то я ничто.

KJV: And though I have the gift of prophecy, and understand all mysteries, and all knowledge; and though I have all faith, so that I could remove mountains, and have not charity, I am nothing.

3. И если я раздам все имение мое и отдам тело мое на сожжение, а любви не имею, нет мне в том никакой пользы.

KJV: And though I bestow all my goods to feed the poor, and though I give my body to be burned, and have not charity, it profiteth me nothing.

4. Любовь долготерпит, милосердствует, любовь не завидует, любовь не превозносится, не гордится,

KJV: Charity suffereth long, and is kind; charity envieth not; charity vaunteth not itself, is not puffed up,

5. не бесчинствует, не ищет своего, не раздражается, не мыслит зла,

KJV: Doth not behave itself unseemly, seeketh not her own, is not easily provoked, thinketh no evil;

6. не радуется неправде, а сорадуется истине;

KJV: Rejoiceth not in iniquity, but rejoiceth in the truth;

7. все покрывает, всему верит, всего надеется, все переносит.

KJV: Beareth all things, believeth all things, hopeth all things, endureth all things.

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

KJV: Charity never faileth: but whether there be prophecies, they shall fail; whether there be tongues, they shall cease; whether there be knowledge, it shall vanish away.

Библия, 1-е Коринфянам, 13:1-8

Желаю каждому иметь в сердце любовь, надежду и веру!

С Рождеством Христовым!