Время гигантов

Оставлю тут себе на память

Время гигантов, Гуськов Алексей

Открыл велосезон

Внезапно.

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

Все же это не шипованный МТБ с покрышками 2,5'', который по ходовым больше напоминает утюг.

Гуру на Урале через месяц

Событие на таймпаде.
Пост в сообществе тестировщиков

Спасибо Насте и СКБ Контуру. К нам едет Баранцев с двумя телегами:

1. О Знании и Незнании

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

 Но иногда бывают ситуации, когда знание вредно, а незнание полезно. Знание притупляет чувства. Мы знаем, чего ожидать, и это создает ложные предпосылки, мы склонны замечать то, что ожидаем увидеть, и игнорируем то, что не вписывается в наши ожидания. Как с этим бороться? Нужно постоянно подвергать свои знания критическому анализу. Отправлять свои знания обратно в незнаемое, и переоткрывать их вновь, с обостренными чувствами.

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

 2. Я бы в тестеры пошёл…

Читая лекции студентам в одном из технических вузов (а я им рассказывал про тестирование), я заметил, что никто из них не планировал в будущем стать тестировщиком. Я учил будущих разработчиков, менеджеров, дизайнеров, системных администраторов — и ни одного будущего тестировщика. Но при этом по статистике процентов 20 из них в итоге всё таки попадали в тестировщики, и нисколько не были разочарованы. Почему? Что это за профессия такая? Непрестижная или просто неизвестная? Чем вообще тестировщик отличается от разработчика или системного администратора? С точки зрения постороннего человека все они «компьютерщики» или «айтишники». Но заглянув на внутреннюю кухню разработки компьютерных программ, можно выяснить, что некоторые разработчики отличаются друг от друга гораздо сильнее, чем тестировщик отличается от разработчика. Приходите, я расскажу вам о том, чем занимаются эти странные люди, про которых все думают, что они «ломают программы». 

Ненависть

https://habrahabr.ru/post/278941/?reply_to=8800783#comment_8800783

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

С тем, что кто-то не прав в интернете, я смирился, от ошибок в профессии пока еще бомбит.

Сообщество тестировщиков в Екатеринбурге

Мы - Максим Захаров, Илья Вахрушев и Настя Ронжина - собираем сообщество тестировщиков.
Про это даже будет доклад на Дампе:http://dump-conf.ru/section/14/

Мы подняли сайт и уже собираем информацию по тестированию на урале: http://uraltester.ru/

Там же - будут события и анонсы оффлайн мероприятий.

Нам нужна твоя помощь. Ответь, пожалуйста, на несколько вопросов
http://goo.gl/forms/YIZw12eBn5

Если можешь - попроси знакомых тестировщиков тоже ответить.

Две полоски

Великолепное. Из http://voron-vp.livejournal.com/42033.html
Все так.

 JIRA ISSUE #182355 Type: BUG Priority: MEDIUM Created: 21.02.12 18:21 Description: С "Дзуйкаку" взлетает "Зеро" с маркировкой авианосца "Кага".

21.02.12 18:30 Elena Ivanova [community manager] commented:
наблюдательные товарищи пишут в интернете что у нас на утекших в сеть скриншотах на самолетах не та маркировка цветные полосы а должны быть белые

22.02.12 11:51 Elena Ivanova [community management] reassigned to Sergei Lodkin [qa lead]
оформите баг чтобы исправили а то позоримся

05.03.12 15:41 Sergei Lodkin [qa lead] reassigned to Mihail Dorenkov [qa engineer]

11.03.12 10:42 Mihail Dorenkov [qa engineer] reassigned to Alexander Rozhko [art director]
Надо нанести на самолеты две белые полосы.

06.04.12 11:13 Alexander Rozhko [art director] reassigned to Semen Kemshakov [3d artist]

17.04.12 15:50 Semen Kemshakov [3d artist] reassigned to Tatiana Severina [textures artist]
Нужны две одинаковые белые текстуры для полосок. Очень надо!

20.04.12 11:10 Tatiana Severina [textures artist] reassigned to Alexandra Lebedeva [2d artist]
нужны эскизы двух белых полосок, а то я не знаю, на что они похожи

24.04.12 12:00 Alexandra Lebedeva [2d artist] reassigned to Tatiana Severina [textures artist]
У нас полный завал. Полоски сможем не раньше, чем через два месяца.

01.05.12 18:34 Tatiana Severina [textures artist] reassigned to Alexandra Lebedeva [2d artist]
можешь сверхурочно поработать? может, дома? это же пара часов, не больше. очень надо!

02.05.12 12:30 Alexandra Lebedeva [2d artist] reassigned to Tatiana Severina [textures artist]
Взяла работу на дом, ночью засела рисовать. (((((( Парень мой спрашивает: "Чего не спишь?"
А я ему: "Да понимаешь, у меня тут тут две полоски..." Обернулась - а его нет. Где теперь его искать? ((((((

02.05.12 15:54 Tatiana Severina [textures artist] reassigned to Semen Kemshakov [3d artist]
похоже, текстур не будет. возьмите пока любую похожую текстуру, потом заменим, когда сделаем

11.05.12 12:13 Semen Kemshakov [3d artist] reassigned to Andrei Hobotov [programming lead]
Я замоделил две белых полоски, лежат на системном диске. Теперь надо, чтобы движок крепил их к самолетам.

08.06.12 10:33 Andrei Hobotov [programming lead] reassigned to Alexei Mshigorotchitskii [junior programmer]
Леша, прицепи к самолетам по две белые полоски.

08.06.12 12:11 Alexei Mshigorotchitskii [junior programmer] reassigned to Andrei Hobotov [programming lead]
Вдоль или поперек?

10.06.12 17:14 Andrei Hobotov [programming lead] reassigned to Konstantin Krainihin [historical consultant]
Вдоль или поперек?

10.06.12 17:15 Konstantin Krainihin [historical consultant] reassigned to Andrei Hobotov [programming lead]
Поперек

11.06.12 18:35 Andrei Hobotov [programming lead] reassigned to Alexei Mshigorotchitskii [junior programmer]
Поперек

14.06.12 18:35 Alexei Mshigorotchitskii [junior programmer] closed issue.
Готово

17.06.12 14:30 Mihail Dorenkov [qa engineer] reopened issue.
Не видно что-то

21.06.12 11:51 Alexei Mshigorotchitskii [junior programmer] commented:
Как не видно? Вчера в релиз ушло. Тестеры в недоумении, уже триста писем с вопросами, что это за странные полоски на всех самолетах.

25.06.12 12:50 Mihail Dorenkov [qa engineer] commented:
В какой релиз? Даже альфа еще не началась.

29.06.12 20:56 Alexei Mshigorotchitskii [junior programmer] commented:
Вы, простите, в каком проекте работаете?

01.07.12 12:21 Mihail Dorenkov [qa engineer] commented:
World of Warships

01.07.12 19:30 Alexei Mshigorotchitskii [junior programmer] reassigned to: Andrei Hobotov [programming lead]
Я программист World of Warplanes. Смотрите внимательнее, кому баги перекидываете.

07.07.12 14:57 Andrei Hobotov [programming lead] reassigned to Alexei Mshigorotchitskii [junior programmer]
Леха, прикинь, в Киеве твой однофамилец работает. Только он Мщигорочицкий, а ты Мчигоротчитский.

07.07.12 14:58 Alexei Mshigorotchitskii [junior programmer] reassigned to: Andrei Hobotov [programming lead]
Я в курсе, что я там работаю. Я из за ваших гребаных полосок такой нагоняй получил. Теперь вычистить не можем - во все бранчи уже просочились.

07.07.12 14:59 Andrei Hobotov [programming lead] commented:
Упс... сорька. Опять не тому перекинул.

07.07.12 15:00 Andrei Hobotov [programming lead] reassigned to Alexei Mchigorotchitskii [junior programmer]
Леха, прикинь, в Киеве твой однофамилец работает. Только он Мщигорочицкий, а не Мчигоротчитский.

07.07.12 15:01 Alexei Mchigorotchitskii [junior programmer] closed issue.
Клево

16.07.12 13:01 Mihail Dorenkov [qa engineer] reopened issue.
Почему закрыли несделанный таск?

20.07.12 09:31 Andrei Hobotov [programming lead] commented:
Леха, ты выше-то почитай, что сделать надо.

21.07.12 15:59 Alexei Mchigorotchitskii [junior programmer] commented:
Ааааа... я думал, ты таск завел, чтобы про однофамильца рассказать.
Еще удивился, чего не по аське, в одной же комнате сидим.

21.08.12 11:09 Alexei Mchigorotchitskii [junior programmer] closed issue.
Сделано

23.08.12 14:37 Mihail Dorenkov [qa engineer] reopened issue.
Истребители перестали сбивать. Не могут стрелять.

01.09.12 13:26 Alexei Mchigorotchitskii [junior programmer] assigned to Andrei Hobotov [programming lead]
Я не понимаю, в чем дело.

15.09.12 19:03 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer]
Боря, проверь, в чем там дело.

04.11.12 09:23 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead]
Полоски закрывают пулеметы. А на них материал, в котором прописана коллизия для пуль. Пули не проходят.

11.11.12 10:00 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer]
Как полоски могут закрывать пулеметы, если полоски нанесены в задней части фюзеляжа?

14.11.12 11:11 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead]
А у нас у истребителей настоящие пулеметы как раз в задней части фюзеляжа. А в крыльях - фейковые, для вида только, пыщ-пыщ делать.
Так исторически сложилось, уже не помню, почему. Теперь долго переделывать, на это вся их баллистика завязана.

05.12.12 12:07 Andrei Hobotov [programming lead] reassigned to Semen Kemshakov [3d artist]
Зачем полоски коллизят пули? Сними с них коллизию.

12.12.12 12:03 Semen Kemshakov [3d artist] reassigned to Andrei Hobotov [programming lead]
Я не могу, у нас коллизии захардкожены в текстурах, а других текстур нет.
Эту вырезал с Флетчера, самая белая текстура, какую нашел. А у него там броня четыре сантиметра.

27.12.12 11:34 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer]
У нас правда коллизии захардкожены в текстурах? Нельзя их оттуда вынести в отдельную настройку?

14.01.13 17:00 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead]
Да как же их вынесешь? У нас же честный расчет пробития, с учетом карты нормалей текстуры, а в альфа-канале у нее усталость металла закодирована.

03.02.13 12:12 Andrei Hobotov [programming lead] reassigned to Tatiana Severina [textures artist]
Сделайте уже нормальные текстуры для полосок, только визуал. Сколько можно тянуть?

12.02.13 15:45 Tatiana Severina [textures artist] reassigned to Alexandra Lebedeva [2d artist]
как там насчет эскиза?

13.02.13 11:15 Alexandra Lebedeva [2d artist] reassigned to Tatiana Severina [textures artist]
Говорила же уже: у нас завал, сможем не раньше, чем через два месяца.
Срочно перерисовываем все миникарты, сказали поконтрастнее выделить сушу. Кто как, а я выделяю более темненькой водой.
Ночью работать больше не буду (((((((

14.02.13 11:10 Tatiana Severina [textures artist] reassigned to Andrei Hobotov [programming lead]
у нас завал. сможем не раньше, чем через четыре месяца.

01.03.13 18:20 Elena Ivanova [community manager] changed priority to HIGH
высокий проритет задачи они опять заметили что полоски неправильные говорят что не будут играть в такой отстой проект на грани провала

07.03.13 17:27 Andrei Hobotov [programming lead] reassigned to Semen Kemshakov [3d artist]
Подвинь полоски, чтобы не закрывали пулеметы.

07.03.13 17:28 Konstantin Krainihin [historical consultant] commented:
Я щас кому-то подвигаю! До миллиметра по историческим фотографиям вымеряли...

11.03.13 12:36 Andrei Hobotov [programming lead] reassigned to Boris Vovk [senior programmer]
Боря, придумай какой-нибудь хак. Ситуация безвыходная.

17.05.13 14:37 Boris Vovk [senior programmer] reassigned to Vladimir Orlov [game designer]
Пропишите пулеметам дамаг 231 вместо 2. Из него ровно 229 уйдет на пробитие полосок, дальше полетят пули с остаточным дамагом 2, как и должно быть.

27.05.13 11:22 Vladimir Orlov [game designer] reassigned to Boris Vovk [senior programmer]
Прописал пулеметам дамаг 231

29.05.13 15:01 Boris Vovk [senior programmer] closed issue.
Теперь все должно быть в порядке.

30.06.13 16:30 Sergei Lodkin [qa lead] reopened issue:
После вашего изменения Нью-Мексико вдруг начал нагибать всех, кто к нему приблизится.
Нет, не так. Нью-Мексико вдруг начал НАГИБАТЬ КРОВЬ КИШКИ РАСЧЛЕНЕНКА ВСЕХ РАСПИДАРАСИЛО В МЕЛКИЕ КЛОЧКИ.
Мы случайно взяли Нью-Мексико и два раза нагнули геймдизайнеров в товарищеском матче. Нам приятно. Спасибо.
Но теперь они тоже просекли фишку, поэтому пора исправить.

01.07.13 10:02 Boris Vovk [senior programmer] reassigned to Vladimir Orlov [game designer]
Почему Нью-Мексико начал нагибать? Вы кроме пулеметов истребителей ничего не меняли?

01.07.13 17:00 Vladimir Orlov [game designer] reassigned to Boris Vovk [senior programmer]
Оказывается, те же самые пулеметы, отскейленные в 10 раз, используются как орудия второстепенного калибра Нью-Мексико.
По форме очень похожи, вот моделлеры и решили сэкономить.
Дамаг тоже автоматически скейлится, но уже в 1000 раз, пропорционально объему ствола.
Так что у нас теперь у Нью-Мексико дамаг 231000 на выстрел второстепенного калибра.

03.07.13 18:01 Elena Ivanova [community manager] changed priority to VERY HIGH
просьба ускориться нас опять в интернете ткнули носом в этот позор не те полоски мне стыдно за тот отстой что мы делаем аааааааааа

03.07.13 19:39 Boris Vovk [senior programmer] reassigned to Andrei Hobotov [programming lead]
Хак не прокатил. Надо всю архитектуру движка менять, чтобы можно было динамически оверрайдить коллизии в текстурах. Иначе ничего не получится. А это работы на полгода.

04.07.13 10:13 Andrei Hobotov [programming lead] reassigned to Slava Makarov [makarovslava]
Такие решения должны приниматься на высшем уровне.
Ну что, отодвигаем альфу на полгода?
Слава, жду решения.

04.07.13 10:22 Andrei Hobotov [programming lead] reassigned to SerB [vice makarovslava]
Извините, что беспокою.
Это очень важный и срочный баг, его фикса ждут уже больше года.
Вы не знаете, где Слава Макаров?

04.07.13 10:28 SerB [vice makarovslava] reassigned to Andrei Hobotov [programming lead]
Нет, я не знаю, где Слава Макаров.

04.07.13 10:37 Slava Makarov [makarovslava] commented:
Извините, что не сразу ответил. Я тут подумал и решил, что проще забанить того неприятного человека.
Белые полоски делать не надо, всем отбой. Пойду думать, как бан обосновать.

04.07.13 10:39 Slava Makarov [makarovslava] closed issue.


04.07.13 18:21 Alexandra Lebedeva [2d artist] reopened issue:
Как не надо? (((((((( А зачем же я вчера всю ночь эскиз рисовала? ((((((((
Хотела сюрприз сделать ((((((

04.07.13 18:27 Alexander Rozhko [art director] commented:
Скинь эскиз на сетевой диск посмотреть. Может, куда-нибудь пристроим.

04.07.13 18:34 Alexander Rozhko [art director] commented:
А почему там не две белых полоски, а три оранжевых звездочки?

04.07.13 20:48 Alexandra Lebedeva [2d artist] commented:
Я - художник, а не маляр... ((((((( Я творчески переосмыслила... ((((( Я хочу, чтобы у нас была красивая игра... (((((((

К вопросу о качестве тестирования банковского ПО

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

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

Вместо этой ерунды там должны быть  (судя по предыдущим транзакциям) мои ПД.

Про высшее образование и онлайн курсы

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

Дальше - как обычно, где-то ботаем, где-то зачеты нашару.

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

И каких предметов? Песня же:

Современные проблемы автоматизации и управления
История и методология науки об управлении
Математическое моделирование и управление в энерготехнологиях
Алгоритмизация
Моделирование систем управления
Системное программное обеспечение
Идентификация и диагностика систем управления
Теория автоматического управления

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

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

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

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

И тут недавно мне настоятельно порекомендовали курс: "Введение в теоретическую информатику"

Читает Александр Шень. 18 модулей, модуль раз в неделю, по 2-4 часа каждый модуль. С задачами, через каждые 5-15 минут лекции. Задачки решаемые, но приходится почеркаться на листочке и подумать.

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

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

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

В примере у преподавателя: адаптивный алгоритм угадывания числа до 1000: "Число больше 512? Нет. Число больше 256? Да. Число больше..."
Тут для следующего вопроса мы должны знать предыдущий. Но при этом можно сделать его неадаптивным, если спрашивать его не ответы, а путь по дереву. "первый разряд числа в двоичной системе 1? Второй разряд числа в двоичной системе 1?"

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

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

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

О докладе "Драйверы и паттерны организации эффективной разработки ПО"

Закон Конвея:

 «Структура созданной системы отражает структуру связей в команде/коллективе задействованной в ее создании

Очень кореллирует с фразой Сэма  Канера:

Один из результатов хорошего процесса тестирования - хороший тестировщик.

 По мотивам сугубо правильного доклада Дмитрия Безуглого: Драйверы и паттерны организации эффективной разработки ПО

Подготовка стратегии тестирования под высокорисковый, высокодоходный проект

К просмотру обязательно.

Сергей Мартыненко
https://vimeo.com/149242580
Подготовка стратегии тест-ния под высокориско-ный, высокодох-ный прое from Vlad Orlikov on Vimeo.

Тезисы оттуда, без контекста:

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

Эффективный подход - test ferst, не путать с TDD

Опросник по автоматизации

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

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

Ваши версии? Ваши предложения? Буду пополнять или менять список.


Процесс
Ручное тестирование проходит на версии приложения с зелеными тестами (ручная работа применяется ПОСЛЕ автоматизации) - да
Наблюдает за результатами прохождения тестов тот, кто будет чинить приложение и тесты. - да
Тестировщики пишут недостающие кейсы для полного набора автоматизации тестирования фичи (неважно, кто при этом пишет сами тесты, тестеры или разрабы) - да
Весь объем тестов по фиче пишется до релиза - да
Весь объем тестов по фиче пишется до вливания фичи в общий код - да
Релиз происходит при условии 100% зеленых тестов (либо каждый(!) упавший тест проверяется вручную) - да
Существует ветка, в которую заливается код и в которой больше 50% сборок со 100% зелеными тестами - нет
Тестировщики регулярно проводят ревью кода приложения - нет
Тестировщики регулярно проводят ревью кода тестов - да
Разработчики пишут unit тесты - да
Разработчики пишут тесты на поднятом приложении без использования GUI - да
Разработчики пишут тесты на поднятом приложении с использованием GUI - да
Тестировщики пишут unit тесты - да
Тестировщики пишут тесты на поднятом приложении без использования GUI - да
Тестировщики пишут тесты на поднятом приложении с использованием GUI - да
План изменений в процессе и архитектуре автоматизации существует в виде артефакта - нет
Хотфиксы(срочное исправление, проходящее через процесс тестирования) случаются раз в полгода - да
Хотфиксы случаются раз в месяц - да
Хотфиксы случаются раз в неделю - нет
Хотфиксы случаются раз в день - нет
Факапы(срочное исправление, НЕ проходящее через процесс тестирования) случаются раз в полгода - да
Факапы случаются раз в месяц  - да
Факапы случаются раз в неделю - нет
Факапы случаются раз в день - нет

Техника
Все тесты проходят за сутки с момента запуска (при условии наличия очереди) - да
Все тесты проходят за 4 часа с момента запуска (при условии наличия очереди) - нет
Все тесты проходят за час с момента запуска (при условии наличия очереди) - нет
Используется современная cvs: git или mercurial - да
Юнит тестов больше, чем тестов на поднятом приложении без использования GUI - нет
Тестов на поднятом приложении без использования GUI больше, чем тестов с использованием GUI - да
Релизы новой функциональности происходят раз в неделю - да
Релизы новой функциональности происходят раз в день - нет
Релизы новой функциональности происходят чаще раза в день - нет
Сборка стенда на ветке происходит по 1й кнопке - да
Регулярно, автоматически (по коммитам) происходит сборка проекта в определенной ветке - да
Регулярно, автоматически (по коммитам, если проект компилируется) идут тесты на проект в определенной ветке - да
Регулярно, автоматически (по коммитам, если прошли тесты)  происходит релиз приложения в бой - нет
Тестировщики могут и при необходимости чинят приложение - нет
Тестировщики могут и при необходимости чинят тесты - да
Тестировщики могут и при необходимости проводят настройку инфраструктуры - да

Теория одного рукопожатия

Екатеринбург - небольшой город. А IT сообщество у нас совсем крошечное.

Общаемся намедни с коллегами:

- У нас тут тестировщица Фамилия Имя увольняется.
- Куда?
- Черт его знает. Говорит, какой-то небольшой проект, разработка на иностранцев, у них до того не было тестировщиков. Английский для этого подтягивает.

Примерно через час пью кофе уже в другой компании:

- Была тут недавно на собеседовании в компании А. Небольшой проект, разработка на иностранцев, первым тестировщиком. Не взяли, английских хороший нужен. Но говорят взяли какую-то девушку из Контура. Не знаешь, кого?

Маленькая у нас деревня.

Самоиронии пост

О ненужной автоматизации тестирования:
http://alexeybulat.blogspot.ru/2016/02/stop-automation-testing.html

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

Общественное самосознание

За последний месяц меня дважды попросили пройти в метро.

Проверили IMEI телефона на предмет ворованности. Вежливо. Недолго. Поблагодарили за потраченное время по итогам.

Я полностью согласен и рад этой практике. Я понимаю ее пользу. Мне действительно несложно и я никуда не опоздал.

В прошлом мое общение с правоохранительными органами было крайне редким и не носило негативного оттенка. Два или три справедливых  штрафа за переход в неположенном и отдельно недолгое оформление каких-то рутинных  бумаг.

В СМИ я слышал и замечал не только негативыные, но и позитивные оценки их работы.

Родственники не замечены и на несколько поколений вверх не страдали от кровавой гэбни. Ну или мне не рассказывали.

Но я все никак не пойму.

Чо ж я каждый раз на измене? Отчего так стремает?

Бизнес как игра

Намедни прочел книгу "Бизнес как игра"  Сергея @Milfgard Абдульманова.
Пруф.

К прочтению - рекомендую. Не откровение, а как это и нужно - повторение простых, понятных и работающих вещей.

Позволю себе процитировать несколько глав.
О книгах:

Книги в офисе должны быть. {...} Так вот. Возьмите книги и положите их в офисе. Ваши люди будут их читать. Ну, те, которые хотят расти. 15 тысяч рублей за библиотеку - и вот вы уже резко увеличиваете скорость роста своих активных людей внутри компании. Оно того стоит. Так обучать очень дешево и очень эффективно. 
У нас первый шкаф стоял в колл-центре. Мы купили книги, поставили. Сразу стало понятно, люди, которые читают и хотят чего-то, уйдут на повышение. Мы никогда не говорили этого явно, но результаты доказывали все лучше слов. Читать книги внезапно стало очень круто. И всем захотелось.

 Будь как Ленин:

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

 Повышения:

Был у нас как-то переезд. Мы попросили продавцов магазинов помочь, не обещая ничего взамен. {...} Мы таскали вещи на пятый этаж и потом весело ели торт. Никто не получил ничего материального. 
Но вот что странно. Каждый раз, когда нам нужен был старший точки или еще кто-то рангом выше продавца, повышался один из людей, помогавших нам при переезде. Потому что мы всех запомнили и увидели, что человек готов сделать больше, чем обязан. Это всегда заметно и об этом не надо говорить.

 Увольнение:

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

Мессенджеры:

Лучший мессенджер - почта. По одной простой причине - не она вас дергает, а вы ее. {...}  Для срочных вещей есть телефон.

DUMP

Уже в который раз мой способ пройти на конференцию - принять участие в создании.
Итак, DUMP.
В  частности, секция тестирования.

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

Интересные темы списком:

• Держим руку на пульсе: тренды, книги, люди
• Багдрайвен девелопмент
• Мобильное вообще все
• Как ручной тестировщик может залезть в смежные штуки и сам все зафигачить
• Хардкор и пентест
• Холивар с менеджерами и программистами об идеальном тестировщике
• Как жить после пропущенного бага
• Система непрерывной интеграции как ритм проекта и способ коммуникации

Набор докладчиков в секцию тестирования на дампе - открыт. Буду рад желающим поделиться опытом и мнением.

Неутешительных итогов пост

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

Итоги, как написано в сабже - неутешительны.

Измерения в днях.
Время подъема писалось с точностью до получаса и по будням с ним все в порядке - не позже 7-8 утра, как правило. Статистику тянут вниз выходные с утром в  12-14.

В остальном - так себе. Катать стоит как минимум вдвое больше. Читаю вообще неутешительно редко.

Думаю, что целевое состояние на 2016 - вдвое больше катать и 50 дней перенести из сериалов в книги.

Будем посмотреть.

О грейдах

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

1. Переезжает
2. Вводит грейды тестировщикам

Пять компаний, исключение - одно. Яндекс не переехал. В остальном завидное единодушие. Терпеть не могу переезды, но сегодня предлагаю поговорить о грейдах.

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

Раз:

Стажер-тестировщик
Младший инженер по тестированию
Инженер по тестированию
Старший инженер по тестированию
Главный инженер по тестированию
Ведущий инженер по тестированию
Руководитель группы

Два:

Стажер (Intern)
Младший тестировщик (Junior test engineer)
Тестировщик (Middle test engineer)
Старший тестировщик (Senior test engineer)
Специалист по тестированию (Expert test engineer)

Ну и для примера возьмем описание - например сеньора или старшего.
Раз:

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

Два.

Условия входа:
Middle test engineer плюс: - обучение стажеров, - консультации коллег по ТС, - принятие решений по архитектуре ТС, - ревью кода тестов программистов. Инициирует работы по развитию тестирования и ТС. Выполняет задачи на исследование. Пресекает некомпетентные распоряжения руководства. Обладает чувством юмора. Самостоятельно локализует проблемы недоконфигурирования сервиса, ОС, оборудования.

Описание:
Задает уровень качества кода ТС. Учитывает и может сформулировать риски и последствия технических решений. Может оценить время выполнения задач. Выполняет задачи, требующие участия сотрудников других групп. В курсе планов развития сервиса. Ориентируется в конфигурационных опциях сервиса и среды, самостоятельно меняет их при необходимости. Способен предложить SLA при отсутствии заданного. Администраторы и разработчики приглашают на встречи по обсуждению архитектуры, инфраструктуры и разработки сервиса.

Мне приходилось наблюдать, как грейды внедряли для групп от 4 до 200 человек.
Успешно - ни разу.

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

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

Что-то здесь не так?
Пойдем с начала. Вопрос - а зачем? Какая решается проблема? Чтобы что?

1. В доисторические времена было два вида тестеров: стажер и тестер. Максимум - три, к предыдущей паре добавлялся автотестер. И этого хватало. Но мир поменялся и их стало больше видов, возникли специализации - документация, нагрузка, инфраструктура, генерация кейсов. Также появился серьезный разрыв в качестве работы - для одной и той же роли, обязанности. И если раньше условный лид мог заказать условному hr'у просто тестера, то теперь приходится уточнять, какого именно, на какую роль, что он умеет, а что - не очень.

2. Вторая возникшая проблема - разная квалификация внутри команды и компании. Есть допустим Вася в команде А и он получает 50 денег. А есть Петя в команде Б и он получает вдвое больше. Проекты и бюджеты - разные, команды - разные. А обязанности - похожие. И команды своими Петей и Васей в целом одинаково довольны. Но тут у руководства возникает вопрос - а может они одинаковые? Может мы переплачиваем Пете? Вместе с этим у Васи возникают сомнения в мировой справедливости. Он же тоже хорошо работает, команда довольна... Необходим механизм сравнения тестеров внутри команды. а пуще того - из разных команд. Зачем - чтоб повысить уровень справедливости и снизить напряжение, соответственно раздав зарплаты и бонусы.

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

Итого, есть версия, что при появлении легитимной системы грейдов, которую поддерживает руководство мы будем легко и изящно указывать hr'ам на грейд который мы изволим нанять. Мы скажем Васе, что он получает вдвое меньше, так как он эльф 20 уровня, в Петя - 80го. Согласно табличке грейдов. И мы покажем Васе, что нужно качать, чтоб докачаться до 80, выдадим алгоритм действий.

Выглядит изящно. Почему же не взлетает?
Реальность сложно описать в четырех, десяти, даже двадцати пунктах. Даже если у каждого есть подробное описание. Особенно, если у каждого есть подробное описание.

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

Коротко? Если группа небольшая, то все по Жванецкому - фамилия становится должностью и так все ясно. Но чем больше охватываемая группа, тем более гибкими и обтекаемыми должны быть формулировки. Вплоть до того, что у нас появятся два человека с примерно равными зарплатами, уровнем ответственности, сложностью работы, но с совершенно непересекающимися требованиями и обязанностями. например тест-аналитик и нагрузочник.

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

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

Что же получается в реальности?

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

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

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

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

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

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

Базовые концепты Ветхозаветных Историй

Крайне интересный взгляд. Рекомендую прочесть все три статьи.
http://alexthunder.livejournal.com/1273699.html

Цитата, дающая представление - о чем там вообще:

Задачу решаемую Библией можно описать как практическое применение научного метода к историческому процессу в моральном контексте. Если сказать проще, то Библия утверждает наличие некоего Народа у которого есть историческая судьба. Судьба эта рассматривается как серия исторических эпизодов имевших место на протяжении очень длинного периода времени. {...} Каждый исторический эпизод рассматривается как очередной эксперимент. Суть эксперимента в том чтобы определить некий набор правил которым народ пытается следовать и потом пронаблюдать к каким это приведёт результатам. Так, систематически протоколируя различные эпизоды исторического процесса, Библия предоставляет нам ретроспективу уже ранее предпринятых попыток реализовать те или иные моральные нормативы. Нам даётся вид на то к чему приводит утверждение и последующая попытка реализации различных нормативных систем.

Фарго

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

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

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

Категорически рекомендую к просмотру.