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


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

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


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

Текст сообщения и комментарии...

Из-под пера Maksim Grinevich

Тэги: , | 3 ответов, оставьте свой...

Искусство управленческой борьбы

Недавно с подачи моего друга Игоря Колосовского начал читать слушать книгу "Искусство управленческой борьбы" от В.К. Тарасова.
Должен сказать, что книга местами неоднозначна, как собственно и все в нашей жизни: ведь и атом изначально придумывали как мирный, а получилось "как всегда". Пусть местами я не согласен с автором, но все равно советую послушать/почитать.


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

Скачать книгу в mp3:


Текст сообщения и комментарии...


Будь реалистом...

Очередная цитата из народа после долгого перерыва:


«Будь реалистом - требуй невозможного!»



Текст сообщения и комментарии...


Вырастим себе замену?

«вы - письмо Христово, через служение 
наше написанное не чернилами, но Духом 
Бога живаго, не на скрижалях каменных,
 но на плотяных скрижалях сердца.» 
Библия (2-е Коринф. 3:3)


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

Думаю, что ситуацию я обрисовал вполне конкретно.

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

Так а в чем проблема тогда, если лучше всего учиться у коллег, они всегда рядом, но людей то не хватает?


Думаю, что проблема собственно в самих менеджерах и лидерах команд. Они не стремятся воспитать себе замену. Их больше заботит — что конечно же правильно — работа команды, её продуктивность, выполнение конкретных задач. Но ведь если ты нацелен на рост. Ты знаешь, что рано или поздно ты будешь подниматься по должности и званию, так почему же не вложить в своих коллег? Почему не сделать свой рост себе же легче — ведь если будет кому занять Ваше место, тем раньше вы сможете занять место «по выше», «по теплее». Тут конечно есть много не обозначенных моментов (а вдруг вырастет коллега на столько ,что его поставят на то место, где я вижу себя; а вдруг он уволиться, а я планировал его на свое место и т.д.), но, на мой взгляд, лучше попробовать, чем ничего не делать и получить потом себе в подчинение неадекватного лидера команды или менеджера проекта.

Текст сообщения и комментарии...


Успеть везде или оправдать ожидания.


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

И тогда всем Вам будет счастье:
 Ваш начальник будет повышать Вас в должности и поднимать Вам зарплату;
 Ваша жена и дети будут самыми счастливыми людьми на свете (ещё бы: не каждой муж дарит миникупер и всячески проявляет свою любовь и преданность, не каждый папа дни напролет проводит в парке с детьми и дарит им самые последние «модные» игрушки ); (если Вы жена и мама, то представьте адекватный сценарий)
 Ваши друзья будут счастливы видеть Вас на рыбалке и в бане и т.д.

Но умудренный опытом человек правильно возмутиться: «Да на это всё и в таких количествах не хватит и трех жизней!!»

Так как же успеть ВСЁ? Оставим пока в стороне семейную жизнь и вернемся к тестированию:
 Как успеть проверить все багофичи? и при этом
 ... обновить документацию по проекту в соответствии с текущими изменениями требований? и при этом
 ... собрать метрики по отделу/проекту/билду ? и при этом
 ... прояснить ожидания от тебя начальника/ сослуживцев(тестировщиков, программистов и других обитателей IT компании) ? и при этом
 ... замечать изменения в отношении к работе коллег по отделу, их заинтересованность в одних проектах и не желание работать с другими? и при этом
 ... и много чего ещё при этом, но за 8 часов в день и 40 часов в неделю?

Частично в этом могут помочь:
— классная снежинка от Славы Панкратова
— интересная Помидорная техника
— ну и куда же мы денемся от Дэвида Аллена и его GTD
— расставление приоритетов согласно проектным нуждам
— ставьте цели и добивайтесь их! А может и не надо!
— А вдруг что-то ворует ваше время? Защита от темных искусств.

НО — почему всегда есть это «НО»?

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

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

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

Текст сообщения и комментарии...


Артефакты тестирования: быть или не быть?

Вот наконец-то до меня добралась запись моего выступления на Test Labs 2009. Это моя первая копеечка в копилку слайдкастов.

В середине и в конце презентации идут вопросы-ответы, поэтому некоторые паузы явно слышны.
Буду рад прочитать ваши замечания/дополнения/комментарии.

Приятного время препровождения ;)


Текст сообщения и комментарии...


Вызвать C#.Net dll в QuickTestPro (VBScript)


Есть у меня необходимость использования в рамках автоматизации внутренних библиотек dll, написанных на C#. Однажды гуглив столкнулся с фразой, что некомовские (non-COM) библиотеки нельзя использовать в VBScript. Тогда на этом шаге остановился и обошелся переносом кода тогда ещё маленькой функции на VBScript.

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

Стоит сказать, что попытки реализовать предоженный метод были и раньше, но почему-то они не увенчались успехом. Теперь же всё получилось, поэтому решил написать этот пост.
Создаем новую C# dll с кодом:
namespace namespacename
{
    public class classname
    {
        public int GetValue()
        {
            return 1;
        }
    }
}

Теперь в QTP пишем:
Set obj = DotNetFactory.CreateInstance("namespacename.classname", "c:\\namespacename.dll")
MsgBox obj.GetValue()
Вот и всё, теперь наша библиотека работает в QuickTest'e.
Есть небольшой нюанс: по своей глупости мне казалось необходимым после пути к dll ещё одним параметром ставить micString - тип возвращаемого значения. И в таком виде оно не работало - ругалось на меня почти матными словами.

Удач в использовании QTP ;)

Текст сообщения и комментарии...


Первые шаги в Google Wave


Тут давеча уважаемый Samat Jukeshov прислал приглашение в Google Wave. Уже много раз слышал про этот новый сервис от Google'a. Теперь пришло время пощупать.

Сейчас пользователям дана только Preview версия, но это только начало. Они обычно вообще не спешат выходить на релизы с такими штуками - помните сколько их почтовый сервис висел в Beta версии?

Тем, кто ещё не слышал про это, будет полезно посмотреть вот это видео (1 час 20 минут!! ).



Мой пост скорее направлен к тем, у кого аккаунт к этому чудо-сервису уже есть: давайте wave'иться, господа. Заодно и протестируем сей сервис! Мой Wave Address: maksim.hr@googlewave.com

Буду рад познакомиться и поговорить. Дабы не нести чепуху или флуд, предлагаю несколько тем для обсуждения (реальное использование - есть лучшее тестирование):
- внедрение автоматизации там, где её до сих пор не было: проблемы, known issues, know how, etc. Ссылка на волну
- внедрение процессов (создание отдела/группы/команды) тестирования там, где их до сих пор не было. Ссылка на волну.
Обе темы мне интересны самому, признанным экспертом не являюсь, поэтому ожидаю конструктивное общение.
- но можно-таки и просто пофлудить :)  (+ обсудить этот блог) Ссылка на волну.

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

Судя по комментам всех беспокоит возможность получения приглашения. Его можно получить здесь www.inviter.ru

UPD2: Сейчас только ленивый не получил ещё приглашение. Но если Вы таков, то я готов Вас пригласить. Один момент: совсем незнакомых людей звать не буду. Вот вы бы хотя бы в читателях отметьтесь :).
Текст сообщения и комментарии...


Тестирование GUI или сферический конь в вакууме


Тестирование GUI (graphical user interface) очень редко проходит отдельно от основного функционального тестирования. Конечно:
- бывают большие проекты, где этому уделяется внимание;
- бывают пропущены серьезные проблемы, после которых все тестировщики проекта некоторое (зачастую недолгое) время тестируют ГУЙ / ГУИ / УЙ / УИ / UI / GUI
Вот скажите мне, разве можно тестировать то, принципы чего сам до конца не понимаешь? Разве можно найти ошибки в калькуляторе, если не знаешь таблицы умножения?
Многие менеджеры считают, что можно! И тогда все тестировщики становятся не только ГУИтестерами, они сразу ещё и ГУИтворители (ведь программисты исправят ровно так, как это скажет тестировщик).

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

Ладно, от теории перейдем к практике.

Предположим, что у нас есть окошко, где нужно выбрать период выпуска на прогулку сферического коня из вакуума. У нас есть два поля для ввода даты: Date From и Date To и кнока Submit.

Кроме дизайно-цветового решения всё выглядит даже ничего: можем задать даты и нажать кнопку Сабмит.
Умный тестировщик проверит эти поля на ввод разных значений: прошлый век, наше время, будущее время, (возможно) проверит ситуацию From >To и т.д. А вот когда этим начнет пользоваться конюх сферического коня в вакууме и реально захочет настроить даты выгула этого животного, он встретит реальные проблемы.

Одна из них - как мне настроить выгул коня только на один день? Поставить Date From = 10/07/2009 и Date To = 10/07/2009? Такое правило зачастую не сработает, ведь мудрые девелоперы сохраняют в базу данных ещё и время, а для обоих дат это будет 00:00:00. Можно поставить Date From = 10/07/2009 и Date To = 11/07/2009, но откуда мне как пользователю знать, что мой конь не будет гулять два дня, вместо одного?

Только методом проб и ошибок, запросов на изменение и приперательств с поставщиком ПО.

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

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

Текст сообщения и комментарии...


Как я ездил на Test Labs 2009...


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

По организации конференции претензий нет - всё сделано умеренно хорошо. Без вложения денег в несущественные вещи (майки, пластиковые бэджи и т.д.), но в то же время обед, на пример, был вкусным.

Ладно, перейдем к делу. В самом начале у меня была проблема: в одно время выступали два человека(Максим и Алексей), попасть на которых мне очень хотелось. Оказалось, что одного доклада не будет и все разрулилось. Первым я пошел на доклад Алексея Баранцева "Во что верят тестировщики?". Заметил, что многие признанные учителя в области плавно переходят из рассказов о конкретных вопросах к общей философии: в качестве примера приведу твиттер у James Marcus Bach - он уже давно философствует о тестировании (и просит спрашивать, если вас волнует что-то конкретно). Так и Алексей решил убедить всех относится более философски к работе тестировщика... Из-за нехватки времени (спасибо задержке на 15 минут открытия конфы) доклад местами получился скомканный, но, надеюсь, у него получилось сказать то, что он хотел. Над этим докладом нужно много думать...


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

Затем подошла очередь выступить мне... Говорил об артефактах тестирования, когда их стоит писать, когда нет. Вопросы по ходу презентации и после порадовали увлеченностью слушателей. Честно говоря, думал, что все заснут на первых порах. Т.к. храпа не было слышно, считаю свою задачу выполненной... :)
Если присланный фидбек будет иметь не низкий результат, обязательно напишу об этом...

Как я писал ранее - обед удался!


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


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

Хотелось послушать Юлию Нечаеву и Александра Александрова, но... надеюсь следующий раз получится.

Ещё отзывы о конференции написали:

Организаторы обещали выложить материалы на сайте конференции.

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

Текст сообщения и комментарии...


5 способов ответить на нечестные вопросы начальства

Автор: Matt Heusser
Перевод: Максим Гриневич

Читая черновик этой статьи, я понял, что хочу перевести её на русский язык и разместить у себя в блоге.
Оригинал статьи от Matt Heusser размещен здесь.
Если вы проработаете в тестировании достаточно времени, то не раз встретите ситуации, когда вам зададут вопросы. Часть из них будет вполне разумными и честными, другая часть – наоборот. В этой статье я помогу вам обнаружить и обезоружить такие вопросы, начиная с самого известного «Почему тестировщики пропустили эту ошибку?»
Около 20 лет назад Tom DeMarco говорил о нечестных вопросах IT в своей статье Why does software cost so much?. Конечно, DeMarco не задает вопросы, он утверждает или предлагает тактику ведения переговоров. Такие вопросы часто так же возникают и в тестировании ПО. Вот мои любимые:
  • «Почему тестировщики не нашли эту ошибку?»
  • «Почему именно тестирование является «узким местом» проекта?»
  • «Почему у нас столько ошибок?»
  • «Что мы можем сделать, чтобы улучшить производительность отдела тестирования?»
  • «Мы уже закончили тестирование?»

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

  • «Тестировщики должны были найти эту ошибку»
  • «Тестирование – слабое место проекта»
  • «У нас слишком много ошибок»
  • «Тестирование занимает слишком много времени»
  • «Тестирование должно быть завершено сейчас.»

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


Доверие и безопасность.

Такие вопросы – это своеобразный трюк или техника. Руководство предполагает, что в ПО слишком много ошибок, и тестировщики несут за это прямую ответственность.
Лучшим ответом на эти вопросы будет занятие позиции, при которой они просто не будут заданы, - предотвратить это можно через обучение и общение. Стоит начать с внесения ясности руководству о том, что будет протестировано, в самом начале проекта. Затем, когда вы найдете ошибку, вы можете сказать: «4 недели назад мы договорились о том, что будет протестировано – за рамки этого я не вышел.» Другой способ – образование: я знаю одного менеджера , который подарил своему начальству в качестве новогоднего подарка копию Perfect Software: And Other Illusions about Testing.
Предупреждение проблем – это хорошая цель, но боюсь, что это не поможет тестировщикам, которым приходится отвечать на такие вопросы прямо сейчас. Итак, моя цель сейчас – обезоружить вопрос, показать что такое осуждение не эффективно и направить команду на путь движения к честности, безопасности и командной работе. Делая это последовательно в итоге можете получить следующую ситуацию. Ваш новый вице президент задает похожий вопрос и тогда кто-нибудь из программистов или Product Managers объясняет ему на сколько данный вопрос нечестен. По крайней мере на это можно надеяться.
Думаю, что теории достаточно. Давайте представим, что вы только что услышали в свой адрес «Почему тестировщики пропустили эту ошибку?». Вот возможные пути ответа:



1. Выбор исходных данных.

Утверждают, что тестировщики должны были найти эту ошибку. Мы можем ответить, что действительно существует заслуживающая внимание причина, почему эта ошибка не была найдена. Далее несколько разъяснений, как я это использовал:
  • Ошибка воображения: Ошибка прошла потому, что никто даже и предположить не мог о её существовании в этом месте . Программист не подумал о такой возможности, ведь именно он создал её. Команда , работающая над созданием требований, не представила возможности появления ошибки в этом месте, ведь иначе они бы написали более явные требования относительно этого места.Мне кажется, что вся команда допустила ошибку в этом месте. Возможно, в будущем,если группа тестирования будет иметь больше времени для обдумывания путей тестирования (кроме обычных действий), они придут к написанию таких сценариев, которые найдут эту ошибку.

Давайте теперь немного поговорим о давлении расписания и как это влияет на фантазию тестировщиков…
  • Успешное управление рисками: хорошо. Одна ошибка смогла пройти незамеченной. Достаточно честно. Теперь давайте поговорим о том, что команда тестировщиков работала на протяжении последних двух недель и при этом они смогли найти 15 блокирующих ошибок, 19 критичных и 54 ошибки с приоритетом Normal. Если мы хотим, чтобы эта область была протестирована, мы должны уделить меньше времени другим областям. Итак, какой из 15 блокирующих тасков вы бы хотели, чтобы мы пропустили, потратив время на эту функциональность?
  • Проблема коммуникации (общения): Мы не можем проверить все возможные комбинации входных данных, поэтому мы вынуждены их сортировать, выбирая более представительные. В данной ситуации мы ошиблись с выбором правильной выборки. Теперь, когда мы знаем о возможны проблемах, мы постараемся уделить больше внимания данной функциональности при тестировании. В будущем, если аналитики, программисты или другие участники проекта будут знать о возможных проблемах, они должны сообщать это команде тестирования.

2. Проблемы исходных данных.

Минуточку: Должны ли были тестировщики найти эту ошибку? Было ли у них достаточно времени? Где был человек, который знал о возможности проблемы? Был ли запрос на использование программных средств, которые позволят найти ошибки такого рода? Такая ситуация может быть хорошим временем, чтобы сказать «Используя данные условия среды разработки/тестирования, мы не должны ожидать, что тестировщики найдут ошибки такого рода. Если же мы хотим не отдавать такие ошибки заказчику, нужно изменить...»



3. Ответ вопросом.

Вместо ответа «вот почему мы не нашли эту ошибку», вам стоит ответить своим вопросом. Это меняет вашу роль, вы перестаете быть жертвой, и становитесь... кем-то, кто действительно пытается повысить качество.

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

Делая так, вы даете возможность интерпретировать эту ошибку шире – на пример, как эта ошибка появилась – это может спасти вас от враждебности и претензий.

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



4. Направление дискуссии.

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

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



5. Измени тему.

В своей книге Quality Software Management, Volume III Jerry Weinberg говорит, что не подходящее поведение может спасти команду от критики. Он приводит такой пример: «Посмотрите, какой пятнистый кот на крыше. Как он туда попал?» Тяжело критиковать кого-то, когда смотришь на котенка. Но вам стоит знать людей, с которыми разговариваете, ведь часть людей будут задавать эти вопросы раз за разом.

Консультант по командной работе Pollyanna Pixton предлагает другой вариант: Просто откажитесь отвечать на неудобный или нечестный вопрос.

Другими словами, если кто-то задает вам неудобный вопрос, ничего не говорите и смотрите на него, будто у него выросла ещё одна голова. Если вас продолжают спрашивать, продолжайте пристально глядеть. В итоге, он остановится. Точно вам говорю.


«Тряпка» или политик?

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

Да, это возможно. Традиционные альтернативы – отступление и успокаивание – могут быть менее болезненны. Если не считать того, что вы становитесь «тряпкой». Мой вам совет: знайте себе цену, и у вас будет что сказать в момент, когда вам зададут нечестный вопрос.

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

Прочитать эту статью на языке оригинала (English) можно на этом сайте.
Узнать больше об авторе заметки можно на professional web page of Matthew Heusser.


Текст сообщения и комментарии...


Лишние знания мешают?

В своем посте "What Makes A Good Software Tester?" Dr. James McCaffrey описывает восемь характеристик настоящего тестировщика. Одной из таких характеристик является: существенные технические данные. Причем, здесь он имеет ввиду, кроме всего прочего, умения/знания программирования:
A great software tester must have significant coding skills in order to understand the system under test, communicate with developers, and write test automation. ...  I believe that a great tester must have at least 7.5-on-a-scale-of-1–10 (applications) development skills.
То, что автоматизатору было бы не плохо быть раньше программистом или иметь хоть какойто опыт написания программ это точно.

Текст сообщения и комментарии...


Мысли по организации тестовых сценариев (test cases)

Прежде, чем забить применить новую концепцию отношения к тестовым сценариям (test cases), описанную в посте А так ли нужны test cases ?, я хотел изменить способ хранения этих самых сценариев описанным ниже образом.
Предлагаю оценить возможность использования данного подхода. Конечно, пока это только теория, но как только у меня будет возможность/ресурсы попытаюсь её воплотить в жизнь.

Итак, копия моего предложения с вырезанными project specific местами:

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

Минусы отсутствия твердой структуры с лихвой покрываются возможностью не думать над тем в какую папку засунуть сей документ, когда он с легкостью может быть как в одной папке, так и в другой.
Думаю, что чтото подобное мы можем сделать и с нашими кейсами. Возможно, что полного отказа от типизации и строгости не будет (в базах же присутствуют как типы данных, так и строго заданные таблицы, но непосредственно в файлах все хранится без строгого разграничения)
ЧТО я предлагаю:
------ Требования и организация ---------------
1. Точно определить, что должно быть в полях типа: Module(s), SubModule(s) . Если с остальными всё более менее ясно, то в этих полях каждый тестер пишет то, что ему вздумается. Следующим шагом будет переименование этих полей соответственно тому, что в них будет находится.
2. Добавить поле Feature. Куда для ВСЕХ записей будет записываться фича, которую проверяет данный конкретный кейс. Если кейс точно нельзя определить, как проверяющий конкретную фичу, то там будем писать чтото типа Global или Main. Это поле должно разрешать вписывать несколько значений через запятую(так сейчас у нас хранится инфа о конфигурациях для конкретного кейса).
3. Список  стоит вынести на отдельную страницу и при добавлении новых кейсов для новой фичи, название фичи добавлять в этот список. И там же связывать ещё раз, в каких конфигурациях эта фича МОЖЕТ быть активизирована.
4. Нужно создать дефолтовый документ, куда будут вноситься все дополнения и изменения. А так же пустой документ, но с готовой структурой, сюда должно быть удобно скопировать кейсы из дефолтового дока. 
5. Правильно настроить фильтрацию, возможно понадобится написать пару VBScript'овых макросов.
------- Как этим пользоваться ----------
1. Если нужно проверить конкретную конфигурацию.
1.1. Выделяем с помощью автофильтров необходимые кейсы. Копируем их в пустой приготовленный и производим тестинг. Сохраняем результаты в отдельный файлик.
Или
1.2. После фильтрации создаем новую версию Results for build_version и производим тестинг. На все остальные кейсы, которые не нужно проверять в рамках этого тестирования ставим статус Not required 
2. Если нужно сделать из наших кейсов Acceptance cases. Опять таки фильтруем данные. Можем уже ничего никуда не копировать.
------------------------------------
В чем наша выгода:
1. Нам не нужно напрягаться о порядке дабавления кейсов даже для одной фичи. Фильтрация по имени фичи точно покажет все кейсы, которые её касаются.
2. Страничка с перечислением фич сразу покажет, какие фичи добавлены,  а какие — нет. При этом здесь мы можем попробовать сделать структуру, которая покажет к чему относится конкретная фича.

В этом, ещё не оттестированном подходе много минусов — это я понимаю. Главный вопрос, который меня интересует: будет ли это жить или есть причины, которые видны «не вооруженным» глазом, из-за которых всё сойдет на нет?

Текст сообщения и комментарии...


Теперь домен второго уровня YaTester.ru

С мои блогом произошло несколько изменений:
— блог переехал на новую площадку YaTester.ru  — так что советую изменить ссылки на фиды (конечно старые будут поддерживаться столько времени, сколько нужно)
— появилась почта ваше_имя@yatester.ru, основанная на сервисе google.com . У меня есть ещё порядка 40 - 45 аккаунтов, которые я могу подарить всем желающим. (Можно настроить пересылку сообщений на ваши основные ящики)
Планирую добавить англоязычную версию блога по адресу YaTester.com, но пока это только планы...

Текст сообщения и комментарии...

Из-под пера Maksim Grinevich

Тэги: , , , | 0 ответов, оставьте свой...

Баг в счетчике LiveInternet

Решил глянуть свою скромную статистику на блоге, и с нерешительностью пытался понять, что же мне показывает мой счетчик LiveInternet.ru
Как вы видите на скриншоте, этот счетчик показывает количество показанных страниц за 24 часа, количество посетителей за последние 24 часа и за сегодня.
Но почему-то сей счетчик показывает, что за последние 24 часа у меня посетителей было меньше, чем за сегодня!
Сколько не фантазировал, объяснения придумать не смог.
Есть у кого-нибудь толкование этому или это обычная бага-фича?

Текст сообщения и комментарии...


Приходите ко мне с проблемой...

Сегодня очередная цитата из народа:

Приходите ко мне с проблемой, и вы получите решение. Если придете ко мне с решением – получите проблему.

Текст сообщения и комментарии...


Цитаты из народа...

Последнее время стало «модно» в своих блогах/сайта/и т.д. добавлять цитаты известных людей. Зачастую — это книги, выступления...
Я же хочу собрать подборку «цитат из народа» — это те фразы/слова/изречения, которые висят у нас на стенке, напечатаны на листе бумаги. Один из примеров - табличка «Лес». Есть только одно условие: пусть это не будут прямые цитаты из книг
Сегодня первая цитата:
«Тот, кто поднялся выше, просто полез раньше!»
Если у вас есть такие вещи, или вы видели действительно стоящие бриллианты — буду рад прочитать о них в комментах или у себя в почтовом ящике m.grinevich@yatester.ru

Текст сообщения и комментарии...


Ночью работать нельзя уходить!!!


Ночная работа... Думаю, что нет никого из опытных ITишников, кто не работал бы ночью. Как переработка (или длительное пребывание на рабочем месте в течении 12-18 часов) отражается на вашей продуктивности?
Всем известны недостатки такой работы:
— усталость: закрываются глаза, голова не хочет думать, компьютеры тормозят сильнее, всю еду уже съели;
— давление начальства (ведь задерживаемся, чтобы сделать что-то быстрее, чем обычно);
— давление домашних (они хотят видеть нас дома «как обычно», а не позже на 3-4..10 часов)
— с каждым часом растущее желание — а не пошло оно всё лесом, я хочу домой/спать/есть/и т.д., подчеркнуть необходимое
— пропущенные дефекты в виду всего выше перечисленного...

Но ведь и плюсы у такой работы тоже есть:

— не знаю, как это случается, но на протяжении первых часов продуктивность растет (вероятно, все ещё надеяться успеть туда, куда начинают опаздывать)
— команда становится более единой -ведь «столько часов вместе!!!»
— зачастую, повышенная оплата труда (это скорее плюс для работника и минус для работодателя) за отработанное время
— все чувствуют на своей шкуре, что значит придерживаться сроков и держать обещания...
Что-то у меня все плюсы какие-то очень маленькие вышли... коллеги, может я что-то пропустил? Ведь переработка не такое и редкое дело в небольших софтверных фирмах. А в преддверии выпуска продуктов — это стандартное поведение исполнителей...
Думаю, случись это раз в два-три месяца или реже, то плохого в этом ничего нет. Единственное, на что стОит обратить внимание девелоперам/тестерам — превращение исключения в практику, когда знаешь, что каждая следующая итерация заканчивается плановой переработкой.
С. Архипенков в своих прикладных мыслях "Руководство командой разработчиков программного обеспечения" пишет о том, что завершение рабочего дня вовремя — один из факторов успешности проекта:
«У проекта разработки ПО сегодня не три, а четыре фактора успеха:
...
4. Каждый участник команды уходил с работы в 18:00 с чувством успеха.»

А где вы поставите запятую в теме поста?

Текст сообщения и комментарии...


Целеполагание - важно ли?


Давеча разговаривал с James Marcus Bach в Twitter о необходимости постановки целей. И он меня весьма удивил, сказав, что не ставит перед собой цели и даже утверждал, что всякие цели — это рабство.
Лог нашей краткой беседы(maks_h — это я):

jamesmarcusbach A goal represents enslavement to your past self. Be free! Renounce goals. Embrace desire.
jamesmarcusbach What humans DO need is coffee. Goals are optional.
maks_h@jamesmarcusbach "Be free! Renounce goals. Embrace desire. ..." and at the end you'll reveal that time was wasted.
jamesmarcusbach@maks_h Ha ha! How do you define waste? How could you know what is wasted?
maks_h
@jamesmarcusbach You really think that anything you do is not a waste of time?
jamesmarcusbach@maks_h I really think I cannot know what is waste. Some apparently wasteful activities have made me lots of money.
maks_h
@jamesmarcusbach Calling people to discard goals in result bring mankind to idleness, coz most people would not do anything...
jamesmarcusbach@maks_h That's what slave owners used to say about their slaves. Of course, they were right. Slavery is still wrong, though.
jamesmarcusbach I will get out of bed tomorrow not because it is my goal, but because I am hungry and I want coffee.
jamesmarcusbach I will write letters of recommendation for two young men tomorrow not because it is my goal, but because I feel good when I please them.

jamesmarcusbach So, @maks_h, people do things without goals. We have urges that are not abstract commitments by a past self to bind a future self.
maks_h
@jamesmarcusbach Of course, not all your action can be linked with obvious goal... but it exists
jamesmarcusbach@maks_h If goals exist despite the fact that we don't think we're setting them, there's no reason for anyone to tell anyone to set goals.
maks_h
@jamesmarcusbach If u set the goal, u meet results much faster. You don't wait when you start to want to do smth what helps reach the goal
jamesmarcusbach@maks_h Don't stop with thinking only about one half the equation, think the other half: goals mean you OTHER things SLOWER.
jamesmarcusbach@maks_h I am suspicious of goals because I can't convince myself that I know what is worth doing.
maks_h
@jamesmarcusbach Lets try to see, u have 2 facilities to do, if you don't have a goal u'll try to do both. But if u prioritize them(goal)
maks_h@jamesmarcusbach u'll previously made the best. Of course u can made mistake, but u will know about it. In your case inversely...
maks_h
@jamesmarcusbach u don't know is this thing good for you or not...
jamesmarcusbach@maks_h I'd rather not prioritize. But I don't mind if you do
Задумался... спорить с умудренными опытом людьми — глупо. Но рассуждать над тем, что они говорят — только к лучшему.В итоге нашей беседы так и не пришли к единому мнению. Хотя сам я редко ставлю перед собой конкретные цели (например, записав их на бумагу), но не считаю, что это вредит человеку. Всегда считал, что целеполагание - путь к продуктивной жизни...
Сейчас же задумался, ведь на самом деле очень тяжело сказать, что есть «хорошо», а что «хуже».Мы думаем, что можем смотреть лишь в недалекое будущее, но на самом деле смотрим в прошлое(с).
Вот сейчас на меня могут пенять любители GTD, но постойте... давайте без зазрения совести скажем: до GTD вам мешала только ваша лень, ничего более. Так что цели тут не причем - нужно быть активным, тогда все получится.

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

Текст сообщения и комментарии...