20151218

"V" значит "Дискуссия"

Привет! Хочу немного рассказать о природе договорок и о том, что я для себя сформулировал как "V-модель дискуссии".
Давно хотел что-то такое написать, а в итоге вчера сидел, у окна, курил, общался с коллегами по скайпу и моделька выкристаллизовалась в сознании.

Картинка для привлечения внимания:


20151120

Хроники Отдела Тестирования. Часть 5: Двадцать пятые кадры!

Всем привет! Я скучал без своих героев. Надеюсь и вы тоже :)
Время летит, растем мы, растут и они. 
Итак, хочу представить вам неожиданное для самого себя продолжение.

Хроники Отдела Тестирования. 
Часть 5: Двадцать пятые кадры!

День 1.
Ура! Спустя почти год спокойного житья и обучения я решил уйти на вольные хлеба.
Жаль было уходить, но кризис... И Иваныч так обрадовался.
Нанялся в одну конторку.
Что делают пока непонятно, но я теперь тимлид!

20151027

Pause!

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

http://radio-qa.com/
https://www.facebook.com/radioqa?_rdr=p
https://vk.com/radioqa
https://twitter.com/radio_qa

Подписывайтесь :)

20150701

"Правильные" и "неправильные" баги.




Как правильно писать заголовок бага?
Да как угодно.
Если это устраивает всех участников процесса и продуктивность от этого выше чем от названий, указанных в каких-то методичках, то почему бы и нет?

Какая должна быть длина заголовка бага?
Да любая, лишь бы информативно.
Если ваш менеджер настолько туп, что не может удержать в голове предложение из больше чем 10 слов - поздравляю, вы работаете с дебилом.
А уж если он закрывает баги не глядя, то явно долго не продержится на своем месте.

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

Подискутируем?

20150629

Отвечаем на вопросы



Раньше был такой формат "Армянское радио" (если кто помнит).
Накреативил тут пару шуток в его формате.
Итак, слушатели задают вопросы RadioQA:


20150610

BDD. Gherkin+Ruby или автотесты для гуманитариев

Вот и наступило долгожданное "попозже" и я публикую свой основной доклад с конференции SQA Days 17.


Мероприятия " www.system-approach.ruК сожалению, видео сказало, что не будет аттачиться, ибо весит больше сотни, поэтому прикладываю ссылкой.

Вот.
https://vimeo.com/130289556

Спасибо всем тем, кто пришел на мой доклад и задавал вопросы во время, после доклада и на следующий день! Вы хорошие :)

Бонусный доклад с SQA Days 17

Всем привет!
Я тут уже писал небольшой отчет об SQA Days 17, но есть кое-что, что вы могли пропустить.
Поскольку перед моим докладом образовалась большая пауза, а терять людей я не хотел, я взял на себя смелость почитать доклад, который подготовил и хотел прочесть на Летнем Тест Практикуме. Но, раз уж так вышло, то почему бы и нет?
Доклад не технический, а скорее на "подумать". Он не был особо отрепетирован и вычитан, поэтому получился таким коротким.
В дальнейшем я, возможно, расширю его и он станет более интересным.
Ну а пока, спешу с вами поделиться!


20150603

SQA Days 17. Frontend and Backend.

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

Начну, пожалуй, издалека.

20150523

Как развлечь себя на конференции.

image

1. Опоздайте к открытию. 
Там всё равно нет никакой важной информации. Здоровый сон важнее.

2. Самое главное на конференции - это печеньки и пакетики с кофе и чаем.
Рекомендую выкинуть раздатку, а в пакет напихать плюшек.
Их всё равно никто не считает и регулярно выкладывают новые.

20150521

I hear you, Joanna (c) "Sweeny Todd - demon-barber from Fleet street"

И снова про коммуникации.

Дорогая, я иногда тебя не понимаю

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

20150520

И ещё немного о мотивации.

Очень крутая паста.

Эдвардс Деминг на своих семинарах наглядно показывал, почему мотивация без технологии не стоит ничего. Сначала он просил участников семинара — а это были директора и топ-менеджеры, многие с дипломом MBA, перечислить все известные им способы мотивации. И записывал в столбик. Потом 

20150517

Протухшие фибдеки.

Всем привет.

А давайте сегодня поговорим о договоренностях?
Точнее не так. Правильней будет назвать это "информирование и фидбек".
Это очень важная штука для правильного планирования.
Фидбеки нужны для того, чтобы правильно распределять время, ресурсы или задачи.
Штука безусловно полезная. Но и у неё есть свой TTL.

КПЗ: "Договоренность"
Выпуск 4. - Русские горки (Кемерово, договор)

Приведу пример.
-Через сколько закончите тестирование?
-Через три дня.
-Отлично! Тогда демонстрацию назначаю чрез три дня.
-Да да. Супер. Всё будет сделано, Будьспок!

Проходит три дня. 2 часа до презентации.


20150515

Тестировщики шутят.

Привет! Вот небольшая пятничная подборочка поизитва.

Когда тестировщику скучно
image


Oooops, I did it again!

Ура, ура! Кэп вернулся и выходит на связь!

А давайте поговорим об ошибках?
Я тут недавно накосячил, но вроде как всё обошлось.
Потом подумал, а какой правильный алгоритм исправления косяков?
Для себя сформулировал так.

Итак, у нас случилась опа. Что делать?
КПЗ "Проблема":





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

2. Мотивация на решение - это я потом внизу напишу

3. Оповещение руководства. 
Вы не поверите, но у них свои планы. Они исходят из данных, которые предоставляете им вы.
Вот, представьте, что друг должен отвезти вас в аэропорт, а машина сломалась на полпути к вам. Вас не предупредил он, потому что менял колесо или что бы то ни было.
Вот вам пример несдвигаемого дедлайна. Если бы вам вовремя сказали, что машины не будет - вы бы вызвали такси и нивелировали бы последствия.
Это очень важный пункт. Не забываем. Более того. Руководство может даже помочь в решении. Нет, правда. У меня такое было.

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

5. Расследование.
Проводим первичный анализ причин косяка для того, чтобы найти тот этап/то место, с которого "что-то пошло не так". Даже "эффект домино" начинается с одной маленькой доминошки.

6. Устранение причин.
Ну, тут всё понятно. Дебаг кода/откат базы/восстановление бэкапа, письмо руководству с отчетом. Это просто надо сделать.

7. Ретроспектива.
Проводим ретроспективу. Что произошло, почему произошло, как этого избежать в дальнейшем. Опционально (и не очень конструктивно) раздача указандюлейий.

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

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

Может немного косноязычно вышло, но как-то так.

Ошибайтесь в меру, друзья.
Много ошибок это, без сомнения, плохо.
Но без ошибок нет опыта. No pain, no gain.
Кто не падал, тот не умеет подниматься.

Stay tuned!

20150513

Немного моих порошков и пирожков

олег задал вопрос ПМу
какой релиз при трёх критах?
ПМ ответил коротко:
Пшолнах

олег, какие эстимейты?
спросил ПМ жуя безе
олег ответил обернувшись
ХЗ

-у нас релиз на той неделе
и семь дней тестов нас спасёт
ты сможешь выйти в выходные?
-Ой, всё!

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

мне срочно нужно два айфона
айпад и гэлакси восьмой!
какой ещё мобильный тестинг?
мы с пацанами завтра в клуб


КДПВ
:

20150512

Редизайн

Долгожданный редизайн.
Кому как?

Писать или не писать код

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

КПЗ: "Ошибка"



20150316

Просто запомнить.

1. Событие является неожиданным (для эксперта)
2. Событие производит значительные последствия
3. После наступления, в ретроспективе, событие имеет рационалистическое объяснение, как если бы событие было ожидаемым.

20150306

Обучение сотрудников.

В одном из тестерских чатиков проскочила тема обучения за счет компании.
Хорошо это или плохо?
Здесь есть над чем подискутировать.

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

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

Предлагаю обсудить.

20150130

Сделано Утюгом.

Немножко предлагаю отвлечься и поразвлечься.
Летом в своё время сделал переделку легендарной Fear of the dark от Iron Maiden.

Вот вам оригинал, а дальше текст.


I am the man who tests alone
And when I'm testing a source code
At night or strolling through github

20150122

Я не люблю консоль.

Я не люблю консоль.
Ещё когда у меня появился старый 386й я первым делом впилил на него нортон, а впоследствии и 3.11 для рабочих групп.
Нет, я знаю и умею консольные команды. pkunzip, arj x -r и вот это вот всё.
Но я не люблю консоль.
Потом на 486dx40 я поставил винду 95, занявшую почти все 200 мегабайт моего винта.
Потом уплотнил хард до почти 350 мегабайт и поставил 98е, вольготно занявшие почти 300 из них
Дальше я работал только с гуём.
Ведь я не люблю консоль.
В своё время я попросил своего начальника посоветовать мне хороший гит клиент.
Он сказал tortoise и я не сомневался в его решении.
Ну кто же знал каких ловушек ждать от хардкорного технаря линуксоида, человека, который научился писать в консоли раньше чем говорить слово "мама"?
Вобщем, проковырялся я с консолью и это было довольно напряжно для меня.
Пользовался я "тортом" до сих пор.
Но сейчас мне повезло. Мой нынешний начальник тоже любит гуй и от него я узнал уйму клёвых инструментов, которые позволяют мне и другим гуманитариям быть на одном уровне с теми, кто мастерски владеет консольными командами.

Хочу представить вам SourceTree - бесплатный, мощный, простой и приятный в обращении гуёвый гит-клиент от Atlassian. Всё блестит, всё переливается. Есть версии под мак и под винду. Есть русский интерфейс. Описывать функционал не буду.
Все эти ваши пше push, git branch, git clone делаются одной кнопкой.
Вобщем, всё как я люблю!
Ведь не люблю я только одно ;)

Пользуйтесь на здоровье!

КДПВ:

20150105

Работаем с огоньком!

Нашел свой доклад, занявший второе место на SQA Days 13 в Санкт-Петербурге..

Извините за рассинхрон слайдов и спича.

https://vimeo.com/135652048

Потихоньку собираю свои видеозаписи.