Панбагон. Лифт передумал ехать вниз

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

О лифте и речь. Люди часто клацают на все кнопки вызова разом (дайте мне таблеток от жадности, и ПОБОЛЬШЕ, ПОБОЛЬШЕ), а потом или спрашивают людей в лифте "а вы вверх или вниз?", или просто садятся и едут на минус первый, хотя им надо наверх.

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

Так вот. После тренировки захожу с коллегами по спорту в лифт на 4 этаже. Он последний. Выбираем 1 этаж и начинаем ехать. Лифт останавливается на 3 этаже. Заходит девушка и нажимает четвертый. Хм, ну и ладно, значит, поедет с нами до первого, а потом уже наверх, логично? А вот и нет! Я смотрю на мониторчик и глаза откругляются — лифт поехал наверх!

Лифт ехал с 4 на 1, но потом передумал

Панбагон. Загадочный дом — ваша игра не зарегистрирована.

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

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

Там баг в коде был, поправил, тестируй!

Тестирую сравнивалку типа «Araxis merge»

Araxis merge сверяет два текста и подсвечивает 

различия между ними

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

И правда, разработчик «пришел, увидел, победил», за 15 минут исправил и передал в тестирование с комментарием «Поправил, документы там нормальные, просто косячок был».

Просто косячок был? о_О

И как мне это тестировать теперь? Как проверять, что исправлено? Что исправлялось то? «Косячок»...

Песня о жизни моих студентов

Я веду курс для начинающих тестировщиков. Это суровая школа, но зато выстраданные десятками пересдач знания отпечатываются в голове настолько прочно, что среди ночи разбуди — студент все вспомнит!

Моя гениальная выпускница Ольга Алифанова выпустилась 10 курсов назад (нифига себе, почти год прошел, чтоли?!), но все еще помнит, каково это. На последнем курсе она подключалась к чату в качестве помощницы, освежила воспоминания и написала чудесную песенку:

Это не баг, ты просто криво собрала билд

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

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

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

Поэтому, когда я жалуюсь Васе (разработчику), что у меня не проходит тест, он сначала пытается отмахнуться:
— А startdate в таблице связей заполнила?
— А id_cat в таблице cat точно равно id_cat в таблице animals? (see foreign key)
— А это сделала?

Мой разработчик, когда у меня падает автотест

Конечно, иногда такой вопрос наводит меня на мысли, но я же обучаюсь)) И типовые проблемы проверяю сама перед тем, как идти с вопросом.... К чему это я? А к тому, что пока ты баг не локализуешь, хрен докажешь, что он есть! И хорошо, когда код полностью готов. Показываешь, что вручную падает на том же месте — значит, ошибка не в автотесте, а в коде. Живой случай из практики:

Планировать декабрь? Забудьте

Наша компания выпускает коробочный продукт. Мы вносим улучшения в ядро функционала в рамках развития продукта и выполняем платные доработки по требованиям Заказчиков.

Релиз длится 3 недели. На последней недели пара дней закрываются последние задачи, потом регрессия и поставки (передача продукта Заказчику). Перед релизом проводим планирование. Так было и в декабре — собрались, обсудили, набрали задач. У меня отпуск не намечается, но есть задачи по поддержке, поэтому планируем мне дней 10 из 15. Релиз удачный — пара недель перед новым годом как раз на новые фичи и еще неделя в 2016, чтобы не торопясь провести регрессию и переключаться на транк.

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

Просто чем ближе новый год, тем больше Заказчиков приходило к нам с запросами на улучшения, которые нужно сделать «в этом году». Раз доработка, два доработка, три доработка... «Какой такой новый релиз? Не, не слышал...».

Почему так происходит?

Заказчики работают в банках и страховых. На ИТ-департамент на год выделяется бюджет. Вначале года его расходовать опасно, мало ли какая внезапная потребность вылезет? А бюджет уже тю-тю, закончился. Что делать? Поэтому вначале года только то, что нужно кровь из носа.

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

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

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

В этом году я буду умнее. Ну, я надеюсь, что к декабрю я не забуду этот пост =)
Декабрьский релиз нужно планировать иначе. Выделять на него больше времени — времени в новом году. И оставлять 2-3 недели разработчика и тестировщика на тестирование внезапно приплывших срочных задач. Аминь 

Тайм-менеджмент. Брайан Трейси

Ссылка на OZON.

Не первая моя книга про тайм-менеджмент. Подкупило то, что она небольшая, 144 страницы довольно крупным текстом. Книга специально написана «без воды», тут собраны лучшие из лучших методик, опробованных авторами. 2 страницы = 3 методики.

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

Зато потом, после введения! Кратко, но емко про каждую технику. Из книг авторы рекомендуют: «Думай медленно... Решай быстро» Д. Канемана — «одна из лучших и мудрейших книг, которые вышли в свет за последние несколько лет» ©.

Развитие интенсива 18. Хорошая подборка отзывов!

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

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

Наталья: у тебя на курсе прям уровень эмоций в обе стороны зашкаливает
Наталья: вот у Леши особо никто не жалуется
Наталья: но и конфеты не отправляет
Наталья: феномен

Хочу подчеркнуть в этой цитате «в обе стороны». 9 из 10 выпускников невероятно счастливы и довольны курсом, 9 из 10 незакончивших в той же степени расстроены и разочарованы.

Обычно отзывы пишут только довольные студенты, но в этот раз подборка хорошая, показывает реальность:

Ваш курс — говно!

Главная фишка моего курса для начинающих тестировщиков — его интенсивность. Хочешь откладывать на потом? Не успеешь сдать. Хочешь получить разжеванный ответ вместо метода Сократа? Увы. Ну и так далее, на странице описания курса вынесены все моменты, которые вызывают как восторг, так и ярость.

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

Во время последнего курса генеральный директор моей студентки написал письмо Наталье Баранцевой о том, какой курс фиговенький. Приведу его целиком с согласия автора, убрав реальные данные:

**********************************************************************

Добрый день, Наталья.

Меня зовут Иван Иванов, я руководитель компании ООО "Ромашка". Мы отправили своего сотрудника Х на ваш 3-х недельный курс "онлайн-интенсив для начинающих тестировщиков". Судя по описанию, это был прекрасный способ обучить начинающего сотрудника до начала работы.

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

Быть счастливее. Тал Бен-Шахар

Ссылка на OZON.

Люблю читать книги, особенно от издательства «Манн, Иванов и Фербер» (МИФ). Когда бумажные книги заканчиваются, я иду на OZON и ищу что-то новенькое и интересненькое. Смотрю свои рекомендации, «также покупают» к уже купленному и книги МИФ.

Эту книгу захватила «от жадности», набивая себе корзину в последний раз  Искала про менеджмент, нашла заголовок «Пашете как загнанная лошадь?» =) Не удержалась. В проф блоге пишу о книге потому, что оттуда таки можно почерпнуть что-то полезное для работы. Хотя лучшей книгой о счастье считаю книги Адама Джексона.