Видео нет.

Определения тест-дизайна

Вот самое простое определение понятия «тест-дизайн», одно из самых распространённых, и самых логичных:

1) Тест-дизайн — это способ

придумать поменьше тест-кейсов,

но при этом сохранить

«максимальное покрытие»

…и при этом оно же самое идиотское (бо невозможно сохранить то самое драгоценное «максимальное покрытие» при насильном уменьшении количества проверок).

Возможно, вам понравится другое, тоже распространённое определение, которое всплывает при первом же гуглеже:

2) Тест-дизайн — это

этап процесса тестирования ПО,

на котором проектируются

и создаются

тестовые случаи (тест кейсы)

Это определение неадекватно, бо тест-дизайн — это не штука для создания тест-кейсов. Неочевидно? Прекрасно!

Далее:

3) Тест-дизайн — это

«The act of careful, complete, systematic,

test design will catch as many bugs

as the act of testing» © Boris Beizer

Процитировано в предисловии к книге Lee Copeland “A Practitioner’s Guide to Software Test Design”, и звучит хорошо, но… Чего он имел ввиду?

И ещё припомнилась классика джуниорской изворотливости на собеседованиях — самое няшное и глупое определение:

4) Тест-дизайн — это

дизайн тест-кейсов!

Что там ещё:

• способ создания наборов тест-кейсов,
• выбор тестов для тестирования при определенных ограничениях,
• …

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

Давайте сомневаться.

Например, сомнительно, что вообще можно понять тест-дизайн без знания контекста, в котором он появился. Появился он очень давно, ещё до вашего/нашего/ихнего рождения. Он появился во времена царствования Waterfall. А под Waterfall постоянно подразумевается какой-то «страх и ужас» хотя бы из-за обилия документации, которая при нём постоянно подразумевается.

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

Ну, да. Это нормально. Waterfall крут. Ему много тысяч лет, его придумали задолго до появления компьютеров.

«Это работает» ©.

Максим Дорофеев тысячу лет назад нарисовал картинку про Waterfall.

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

Но 50-х годах ХХ века, когда было придумано то, что вы сейчас называете «программирование» и «тест-дизайн», эта картинка ни у кого не вызвала бы удивления, бо тогда всё было как раз наоборот.

Просто вообразите эту картину Малевича перевёрнутой.

Ибо было так: с самого начала у нас очень мало документов, и чем их больше будет, тем лучше будет.

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

Старые компьютеры и старый тест-дизайн

Вот фоторобот самого первого компьютера, который был установлен в университете Гарварда.

Он назывался «Марк-1» (а тот самый мотылек, который «сдох в микросхеме», сгорел в следующем компьютере, в «Марк-2»).

Компьютер был большой, слабый, часто ломался, и делал только то, ради чего он был создан. Был запущен в 44-м, участвовал в программе по разработке атомной бомбы в США, упокоился аж в 59-ом.

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

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

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

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

Затем подаёте на всё это электрический ток, который пройдёт по этой структуре от начала до конца (это означает, что в память или делается запись, или делается считывание, доступна только одна операция за раз). У каждого магнитика два состояния: или туда пришёл заряд нужной силы, или нет. Если пришёл, то магнитик будет хранить состояние «1». Если нет, то в нем хранится «0». Вот и всё, классическое

0000111000101111 0001111000001110 0010111100011100 0000111000101110 00100010

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

Принцип работы такой памяти:

• 155la3.ru/ferrite_memory.htm
• habrahabr.ru/company/ibm/blog/266425/

Эти «магнитики» часто ломались. Если во всей этой сеточке сломается один из этих магнитиков, то для того, чтобы его заменить, нужно было

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

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

Почему важно понимать как работали старые компьютеры? Дело в том, что тест-дизайн, которым мы и сегодня пользуемся — порождение тех самых времен, отблеск тех самых блестящих 50-х годов.

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

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

Раньше тестировали ДО того, как написать код (карандаш и бумага, парни), и код писали уже с учётом всех потенциальных проблем, которые были обнаружены на этапе тестирования.

Сегодня мы тестируем УЖЕ работающие приложения.

Тестирование как процесс можно представить в виде вот такой диаграммы:

1. Сперва мы что-то делаем с требованиями,
2. потом делаем какой-то тест-дизайн,
3. после этого появляются какие-то тест-кейсы,
4. и потом тестируем руками.

Причинно-следственная связь полностью соблюдена, да?! Появлению тест-кейсов предшествует тест-дизайн, следовательно, «тест-дизайн» — это деятельность по созданию тест-кейсов.

На самом деле — НЕТ, абсолютно нет.

Всё это становится очевидным, если учитывать, как и когда эта штука родилась, и где и в каких условиях она работала.

А работала она следующим образом. Вместо слова тест-дизайн подставим слово «анализ»…

А что такое анализ? Кто не знает — бегом в википедию, мазафака, там упоминается расчленёнка:

Анализ (др.-греч. Ἀνάλυσις — разложение, расчленение, разборка) — метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования

Можете соврать, что теперь-то всё стало понятно, но сперва ещё проясните слово «метод» (позже пригодится):

Метод (от др.-греч. Μέθοδος — путь исследования или познания) — систематизированная последовательность действий, которые выполняются для решение определённой задачи.

Метод (последовательность действий) — это логический контейнер для одного и более алгоритмов, по которым эти действия выполняются.

Алгоритм, а следовательно, и метод у анализа прост: смотрим на любой феномен/артефакт (и неважно, логический он или физический), и дробим его на составляющие. И каждую составляющую, если возможно, тоже дробим. И дробим всё до тех пор, пока дробить уже будет нечего.

Позже всё то, на что всё раздробилось, мы будем группировать и осмысливать. Но сперва — раздробить.

Собственно, в этом Анализ и состоит.

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

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

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

Если бы нам пришлось работать с теми самыми старыми компьютерами, то и мы начали бы делать то же самое.

И неважно, что у нас компьютеры сейчас быстрые…

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

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

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

Это тот самый момент, когда ты разобрал машинку и такой «О, я понял, почему оно так работает!» Потом отдаёшь её владельцу, говоришь, что так и было, и убегаешь домой, пока не побили.

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

Посему:

Как правило, мы стараемся сразу перейти к «осознанию», ошибочно подразумевая под этим «анализ». А надо наоборот.

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

Но анализ делается ДО осознания. Основная ошибка в том, что мы анализ не проводим, мы заменяем анализ каким-то… быстрыми домыслами.

Не надо так.

Ещё одно важное понятие, которое используется в тестировании:

Вы функциональные тестировщики. Следовательно, вы должны тестировать функциональность.

Большинство тестировщиков начинают тестировать не Функциональность (способность программы выполнить задачу), а то, из чего эта способность создана (функции).

Например, когда предлагается протестировать часы, мы начинаем с проверки «а есть ли стрелки». Ну, реально… это самое дурацкое начало тестирования: убедиться в том, что часы вообще есть. Все же с этого теста начинают?! А почему бы не начать тестирование часов с проверки того, что тестировщик проснулся и умылся? Ведь это важное предусловие для начала тестирования.

Еще пример: протестировать отсылку смс с телефона можно несколькими способами, на разных телефонах это ещё и делается по-разному. Но если не привязываться к тому, как это реализовано, то всё равно МОЖНО протестировать функциональность.

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

Думайте про тестирование функциональности, а не функций.

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

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

Мы профессиональные тестировщики, нам только дайте любую шнягу, и мы её протестируем, так?! И скажите нам точно, что именно надо делать. И мы сделаем именно то, что вы скажете, что надо сделать. А чего не скажете делать — ну, так надо было говорить!… Всё правильно?

Не надо так.

Надо понимать, зачем всё это делается. Надо спрашивать. Надо понимать сверхзадачу тестирования.

Вообще, ВСЕГДА надо начинать работу с выяснения того, что «эта штука» делает, и почему она должна это делать в принципе, и зачем этот проект вообще нужен. Да, это всё подразумевается, но подразумевается всеми по-разному, а надо, чтобы подразумевалось всеми одинаково. Взрослые тестировщики до этого медленно, но доходят.

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

Но вы не будете удивляться, бо вы не будете никого ни о чём спрашивать, бо всё ж подразумевается; а если начать спрашивать об очевидном, то — «бабки у вашего подъезда» дежурят круглосуточно.

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

Прояснение метазадачи тестирования выглядит следующим образом:

1. понять, зачем что-то надо делать,
2. потом осознать, что конкретно надо сделать,
3. и уже потом в самом конце понять, как именно это надо сделать.

Начинаем с «Зачем», затем переходим к «Что», и уже потом спрашиваем «Как».

Обычно мы ВСЕГДА начинаем с самого конца этой схемы — сразу уточняем, как устроена программа, которую надо протестировать; где у неё находится кнопка, и есть ли там кнопка, и… есть ли стрелки на чёртовых часах. Народ, часы — это объект, который может быть без стрелок, но тем не менее он выполняет свою функцию — показывает время. Соответственно, и тестировать часы надо без привязки к стрелочкам. И программное обеспечение надо тестировать точно так же, не привязываясь сразу к тому, как оно устроено. Иначе вы будете обречены тестировать только то, что видят глаза здесь и сейчас, а не то, что может случиться.

Как устроен «тест-дизайн»

Рассмотрим это поэтапно, как процесс.

Всё ВСЕГДА начинается с анализа и осознания ситуации.

Надо провести анализ Контекста (отдельно) и анализ Задач (тоже отдельно).

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

Если об этом спросить ДО начала чтения требований, то требования вам будут понятны почти так же хорошо, как и тем, кто их написал. Вот и весь секрет.

Древние программисты умели фокусироваться, но… они уже почти все поумирали, поэтому выкручивайтесь самостоятельно. Это не так уж и сложно.

После завершения анализа начинается осознание «Контекста» и «Задач» по-отдельности. Если игнорировать последовательность осознания контекста и задач, то будут сложности с анализом и осознанием того, что называется «функциональность». И будут сложности с определением метазадачи тестирования. Тут всё связано.

Тест-кейсов на этом этапе еще нет, и быть не должно, бо тест-дизайн — не для придумывания тест-кейсов.

Следующий этап, если этот прошел хорошо, — Комбинаторика.

Комбинаторика это просто объединение всего того, что вам придумалось на предыдущем шаге. И выглядит это как сборка всего в одну большую таблицу.

Тест-дизайн вообще основан на таблицах. Тест-дизайн = анализ. Анализ = контроль. Для того, чтобы контролировать все, необходимо все записать. Затем комбинировать. А это таблицы.

Для того, чтобы суметь всё контролировать, необходимо осознать две глобальные установки:

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

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

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

Ответ: вы возьмете карандаш и бумагу. Или будете рисовать мелом на асфальте, или фломастером на обоях, но вы будете записывать. Чем больше документов, тем лучше (вспомните картинку Дорофеева).

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

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

И тест-кейсов тут всё ещё нет.

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

Так же за простым предложением «сел за руль и поехал» подразумевается умение водить, а сложность и комплексность умения вождения автомобиля сложно объяснить тому, кто никогда не садился за руль.

Но это не rocket science, это дело можно и самостоятельно разрулить.

Третий этап.

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

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

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

Анализ результатов комбинаторики подразумевает следующее: берём огромную таблицу (обычно они получаются огромными) и начинаем втыкать в закономерности. Иногда они видны, просто бросаются в глаза – на диагоналях, на пересечениях.

Если вы не видите закономерностей и нелогичностей, значит, они проходят мимо вашего сознания.

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

Если анализ показывает, что нужно сделать 50 тысяч тестов, значит, нужно сделать минимум 50 тысяч тестов.

Домены. С точки зрения математики — это абстрактный образ, в котором абстрактно могут находиться какие-то сущности. Один и тот же объект может одновременно принадлежать нескольким доменам.

Например, украинец попадает в домен жители Украины. Молдаванин попадает в домен жители Украины, если он живет в Украине, не являясь при этом украинцем.

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

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

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

Тест-кейсы — это инструкции по созданию тестовой ситуации, а не «set of input values» и blah-blah-blah. Придумывать тестовые ситуации легко и просто только ПОСЛЕ этапа анализа тест-дизайна. Их можно писать буквально без того, что называется «Steps to reproduce», их можно писать одной строкой. Тест-кейс, даже если не выглядит, как трехколоночная шняга, тем не менее остаётся тест-кейсом.

Эстимация времени на тестирование — за этим марш сюда: Оценка времени на тестирование: неочевидные надводные камни

Резюме

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

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

Данные, которые собираются на этапе анализа, комбинируются (смешиваются и перемножаются). Техники тест-дизайна основаны на комбинаторике данных.

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

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

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

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

Всё, туй коныць.

Вопросы

Як це все робити, коли в тебе еджайл, і дуже коротка ітерація? Наприклад, ітерація день або тиждень. Ти просто не маєш можливості всі ці аналізи проводити.

Маешь. Не умеешь — не берись.

Так программисты поначалу воспринимают TDD, мол, у меня нет времени код писать, а вы хотите, чтобы я ещё и тесты писал 🙂

Внутри agile захардкоджен тот самый waterfall, который объявлен «плохим». Waterfall это нормально, это должно быть. Мы основаны на waterfall, то есть сначала случается свадьба, а уже потом появляемся мы. Если нарушить процесс, то, соответственно, результат будет… ну, вы сами видите, что получается.

Waterfall это хорошо, потому что это основа того, как мы делаем всё, и не надо говорить, что это плохо просто потому, что есть agile. Agile — порождение waterfall, agile это попытка сделать так, чтобы то, что мы называем «длинный процесс», делался немного быстрее и точнее. Но в agile есть место и время для анализа.

На рахунок тест-дизайну і цього всього, що було сказано, це все звучить класно, але в мене складається враження, що це така утопічна розповідь про те, як би воно мало бути. Це ідеалізовані абсолютно всі у нас умови, і от в тебе час на це, і на це. Суть в тому, що в сучасних умовах і в тому, як швидкоплинно оці з девеломпент, делівері, і т.д., це все відбувається, то реальність показує, що в тебе час дуже обмежений. І це велика розкіш, коли ти можеш дозволити собі зробити оце все, що ти описав. А далі?

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

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

Нет. Ты точно так же понимаешь, когда ты наелся. Просто понимаешь, и всё.

Если говорить про доменное тестирование — этих доменов достаточно много. До какой степени мы должны доходить?

До тех пор, пока не исчерпается воображение.

Но это очень субъективно…

О, это крайне субъективно! Поэтому тест-дизайн — это искусство личностное, как каратэ или умение играть на гитаре. Есть люди, которые умеют это делать, есть люди, которые не умеют, и чёрт его знает, почему у некоторых получается, у некоторых нет. Это личностное искусство, это раз. Поэтому очень сложно научить этому ВСЕХ, и особенно начинающих.

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

Предположим, что есть пять университетов, в которых стоят пять компьютеров одной и той же модели. Каждый из этих компьютеров в какой-то момент становится уникальным артефактом. У какого-то компьютера памяти нашили больше, у какого-то меньше. У какого-то скорость повысилась, у другого скорость ниже. Все программы в древние времена писали для отдельно взятых компьютеров (то есть невозможно было в офисе написать программу, приехать к клиенту и её установить на его компьютере, априори это было невозможно). Мы можем себе это представить? Для этого ноутбука отдельная программа, для этого отдельная, и они не синхронизируется абсолютно. В наше время это уже сложно представить, в наше время программы пишут ВООБЩЕ. В те времена это было норм, просто из-за того, как все было устроено. И тест-дизайн помогал фокусироваться. И это великое благо – умение сфокусироваться и действительно понять, что важно, и что неважно. И не разбегаться сразу во все стороны, как мы к этому стремимся иногда.

Виходить так, що тест-дизайн существовал в якомусь сенсі до нинішнього моменту в якихось вузьких кругах. Що зробити для того, щоб його відродити, зважаючи на те, наскільки популярний agile, небагато часу, все гнучко, і в принципі, немає на достатньому рівні документації. Як жити?

Agile к тест-дизайну не имеет никакого отношения. Что вы делаете ПО по agile или по waterfall, вы все равно получите ПО, что делается по определенной технологии. Эту технологию надо знать заранее, и тогда начинается разработка абстрактных артефактов, из которых состоит программирование, то, соответственно, надо их надо учитывать, как можно раньше. Поэтому неважно, в каком условии работает тест-дизайн, он работает во всем и всегда. Мытье рук – тест-дизайн, чистка зубов – тест-дизайн, не разговаривать с дураками – тоже тест-дизайн, потому что это анализ, анализ ситуации и принятие решений.

Відсутність документації, її недостатність… [не позволяют заниматься тест-дизайном]

У нас никогда не будет адекватных требований просто потому, что они пишутся физиологически не так, как мы это себе представляем. Мы воображаем, что это документ, в котором четко все написано. На самом деле любые требование это как фотография из отпуска – ты на нее смотришь и вспоминаешь, что было до неё, и что было после. Целый контекст так появляется. Другой человек на неё смотрит и видит, что на фотке просто человек стоит на фоне моря. Контекст должен быть. Тест-дизайн помогает врубиться в контекст. Тест-дизайн помогает тестировщику поднять свою глупу дупу и пойти спрашивать – вот я понял, что надо так и так, я правильно понял? Мне кажется, что надо вот так — я правильно понял? Надо ходить и спрашивать, а не просто получать документ и тестировать строго по ним, потому что это тоже очень глупо. Требования это не закон. Требования это документ, которые пишется группой людей, которые о чем-то уже договорились. Когда они о чем-то договорились, они понимают, о чем там написано. И даже когда не все четко, они все равно все хорошо понимают. Анализ, как возможность сфокусироваться на чем-то, помогает начать понимать то, что скрыто за какими-то, казалось бы, невнятными строками. А еще если читаешь о том, как требования создаются (у Вигерса), то понимаешь, что их создают вообще не глупые люди, хотя поначалу кажется иное. Но когда сам начинаешь писать требования, то очень быстро начинаешь понимать, что требования пишут нормальные, классные пацаны, им надо просто помочь, а не доказать, что они ошиблись и сделали плохую работу.

Представлення результату аналізу… скажімо, блокнот, таблиця, майнд-мап і так далі.

Абсолютно неважно. Карандаш и бумага. Notepad и курсор. И дальше как угодно.

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

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

Але тест-кейс пишеться на основі документації якої на етапі естімації ще немає.

Соберись! Когда ничего нет для анализа, то и анализировать невозможно в принципе.

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

Пяти.

Пять — это уже резвая старушка-бегун… Вот, «из ничего», но появилась информация, и я знаю, как её протестировать. Надо учесть, что возраст у неё между той и иной цифрой, и что она делает действительно движение, а не её кто-то перевозит, и что она вообще достигает определенной скорости, которую ей создают собес и внуки, которые ожидают свободную жилплощадь. Тест-дизайн это поиск информации, это анализ информации. Если нет информации, то останавливаетесь и говорите, что я не знаю, какое мне решение выдать, потому что у меня нет информации для анализа. И это естественно. Это даже нормально. Пускай заказчик себе там хоть соплями изойдет, но если нет информации, то что ему сказать?!

Получается, по условиям тест-дизайна можно ТЗ писать?

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

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

Дяка за увагу.

0

Две недели бороде, Пообтрепано пальто, Завели свой разговор тополя до начала конференции прошли в приятном, но суровом напряге — в подвалах SysIQ джуниоров-автоматизаторов тренировали…

1

Буквально за два дня до мероприятия вспомнил, что еще не сделал себе спец.футболку для конференции; пришлось бегать с утра и спешно по дебрям киева.

2

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

Редкость же, ващще…

3

Из-за великого расслабона ВНЕЗАПНО получилось спокойно воспринимать посещаемые доклады «с нуля».

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

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

Однако стремление к покою пошло на пользу — сидел спокойно, внимал ясно, словно в первый раз, никуда не спешил.

4

Порадовала инициативная Виктория Птицына с конференцийным журналом.

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

Иначе или так, ряд автографов на своем опусе пятом, фа-диез, я раздал.

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

Хоть это и первый выпуск совершенно неподготовленных в журналистике редакторов, однако получилось очень достойно, на уровне журнала выпускников журфакультета.

Изысканный эксклюзив: моя статья «Как работать в условиях: «Вот тебе приложение, тестируй, как работает — сам поймешь»» (pdf).

5

По старой дружбе дал себя слегка похантить салатово-футболочным рекрутерам из одесской Lohika 🙂

Жую лохиковский озонированный яблочный сок и хвастаюсь своей статьей в журнале

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

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

Вот поди отличи основные человеческие темпераменты…

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

6

Прогрессивному человечеству известно, что некоторые молдаване комфортно заселяют Одессу.

Мне в Одессе не очень комфортно, но это сугубо моя маничка.

Дык вот, Lohika то и дело проводит в Одессе мероприятия, аналогичные весьма качественным конференциями, только меньшего масштаба. Мне моментально подумалось о том, что ездить туда из Кишинева дело плёвое, и почему бы молдавско-подданным не набегать на конференции в Одессу, и я стал сурьезно разочаровываться в соотечественниках, которые всего этого не делают…

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

Ну, не ездят…

Не всем дано, не каждому надо, не всюду требуется.

7

Мои младшие коллеги по SysIQ (нас там была целая мини-банда) впечатлились демонстрацией техники pairwise by Никита Постолакий (Luxoft). Удивился, мол, чего там особенного, бо я постоял часть доклада, и свалил — не вштырило. А оказалось, что для них это новинка.

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

Да и вообще надо бы пересмотреть все техники тестирования в принципе.

8

Вроде бы у меня получилось растолковать Глебу Рыбалко, почему с точки зрения профессиональной ток-шоуной журналистики его с Викой Мусияченко подкасты «Тестирование, Backstage» в нынешнем формате обречены на нескорое, но безусловное загибание.

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

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

К слову, «Тестирование, Backstage» означает всего лишь «Закулисье тестирования» 🙂

9

С шефом автоматизаторов «Одноклассников» Никитой Макаровым совершили кулинарный трип в «Шницель Хаус» на Саксаганского, вследствие чего я выбил себе из этого прелестного предприятия красивую скидочную карту; также стороны в ходе прогулки по переходящему в ночь Киеву обсудили ряд насущных проблем в тестировании социальной сети «Одноклассники» в частности и тестирования всего прочего вообще в Кишиневе, Одессе, Москве, Риге и прочих местах скопления тестировщиков.

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

Пресловутое «видение художника» творит чудеса 🙂

«Мне теперь одна дорога, мне другого нет пути…

Где тут, братцы, синагога? Подскажите, как пройти…» ©

10

Николай Алименков восхищает: с температурой ходить на доклады, где неправильно рассказывают про agile, и терпеливо НЕ троллить докладчиков — это сила!

Хотя по итогам его все равно признали главным троллем конференции и выдали соответствующий приз.

11

А утром второго дня конференции я проснулся и понял — беда. Никуда не пойду. Давление изнутри давит наружу. Или наоборот. В общем, лежать, лежать, лежать.

Ну я и лёг, вследствие чего не смог дообщаться со всеми, кого видел в первый день.

12

Киев рулит, это знает каждый ребёнок, оснащенный леденцом, который у него еще никому не довелось отнимать.

Но почему-то в недрах Киева всё ещё гнездятся странные тётки образца «советская буфетчица». Обычно встречаются в небольших магазинах, но часть этих тёток основались в том самом КИМО, в котором проходила конференция.

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

Михаил Булгаков. «Богема»

В 1921 году было несколько иначе, чем в 1924 г. Именно нельзя было так ездить: снялся и поехал черт знает куда! Очевидно, те, что ведали разъездами граждан, рассуждали приблизительно таким образом:

~ Ежели каждый начнет ездить, то что же это получится?

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

~ А зачем едешь?

Написал с гордостью:

~ В Тифлис для постановки моей революционной пьесы.

Отогнанные от столов кочевали через дорогу в какое-то кофейно-кофейное заведение.

Например, перекинуться тремя парами слов с Наташей Руколь и Андреем Мясниковым получилось как раз в том заведении. И именно там же удалось спокойно поговорить с Сергеем Бережным.

В общем, КИМО в кофейно-поедальном плане — совок, а с совковыми организациями делать дела очень сложно…

Да, а тем, кто был допущен до кофейно-чайного стола к 16.00 повезло больше чем тем, кто подошёл туда к 16.10 — на столах уже было пусто.

Приносим организаторам наши сочувствия 🙂

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

13

Впечатлило наблюдение Максима Цепкова о тестировщиках:

Это конференция практиков, причем тестировщики-практики — значительно более конкретны, чем разработчики.

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

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

Waterfall, Agile, Lean для них — теория. У которой есть предельно конкретное воплощение в собственной жизни.

А вот обобщенного понимания — часто нет. Потому как не нужно. И оно домысливается по месту, иногда адекватно, иногда — не очень.

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

Мем — не имеет четкого определения.

Мемы понимаются аудиторией очень широко, а границы — нечетки.

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

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

Аналитики нам други, товарищи и поставщики юз-кейсов! А юз-кейсы являются отличной едой для грамотного тестировщика!

И ссылок чуток

Программа конференции SQA Days 11 со слайдами и местами с видео.

Сборник видео докладов от Стаса Фомина.

Всяко отзывов с фотографиями о конференции.

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

Поверьте в то, что вакансии и описание требований — просто повод для знакомства и беседы, а не пограничные столбы и фильтр. Фильтры включаются только после личной беседы.

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

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

Если были какие-то вопросы к вашему резюме — учтите их и подфиксите ваше резюме.

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

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

На собеседованиях не ведите себя как жертва, которая просит работу.

Ведите себя как хищник, которому есть что предложить, и который может отпидарасить любого мудака поставить на место любого менеджера, который вздумает усомниться в ваших способностях. Подумайте о том, что вы можете предложить. Подумайте о том, что вы сами себе менеджер, и просить вам нечего, вы пришли, чтобы узнать, есть ли возможности для СОТРУДНИЧЕСТВА.

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

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

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

Тут всё подойдет:

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

Подумайте о том, что вам нужно в этом году завести 365 новых знакомств, и подумайте о том, как вы это сделаете.

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

Подумайте о том, как вы слабы сейчас, когда у вас этих знакомств нет.

Откликайтесь на ВСЕ вакансии (мнение hr по этому поводу посылайте фтопку).

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

Общаться надо с людьми, вот и весь секрет достижений.

Знайте, что отказов всегда много, и это нормально.

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

Понимаете, почему я себя так веду?

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

Когда-то я делал всё именно так, по-тупому: просматривал кучу объявлений, затем отсекал ПОЧТИ ВСЕ по любым, даже самым идиотским поводам. «Мнэээ, тут мне не нравится, мгм, их адрес, а тут вообще не понимают, что такое тестирование, а тут вообще идиоты сидят, мнэээ…»

Оставалось два-три объявления, в которые я засылал резюме, и тупо ждал, когда оттуда ответят. Иногда даже звонил, мол, как вы там, а? Я вам засылал сто лет назад резюме, ага…

Затем делал вывод — работы нет! Я послал резюме, ответа не получил, следовательно, работы нет! А почему объявление о найме от той компании всё еще висит в сети? Да потому, что там все тупыыыыыыые, а работы нет! Я это доказал!

Это было очень глупо, увы.

Посмотрите, что творится на developers.org.ua — полно сообщений в профилях компаний вроде «Заслал им два месяца назад резюме, до сих пор не ответили, какие-то они там все дебилы, наверное…»

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

Не старайтесь одним выстрелом сразить одну крупную цель.

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

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

Послушайте интервью Артема Бойцова запишите себе на ляжках количество резюме, которые он рассылал в поисках работы в Штатах.

Сможете сделать то же самое?

Почитайте интервью Юлии Нечаевой.

Сможете сделать то же самое?

Подумайте над своим имиджем.

Вам нужно найти свое описание, емкое и краткое, которое полностью вас характеризует, какое-то простое прилагательное.

Например, «Майкл Джексон — это тот, который офигенно танцевал». Или «Брюс Ли — это тот дядя, который мог всех побить». Или «Баранцев — это тот, который тестировщик ваааау ващщщееееее!»

Про вас что можно сказать в плане краткого определения? Что вы умеете? В чем вы офигенны?

Обсуждайте, а не подразумевайте.

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

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

Всегда имейте пару вопросов про запас.

Худший случай, когда кандидат мямлит «Не, нету» на прямое обращение «У вас к нам есть вопросы?» Это не дежурный вопрос, это очень важный пункт в завершении всего собеседования. Вопросы быть должны!

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

Работодателей — выбирают. Это не совсем очевидно поначалу, особенно если вы ориентированы на поиск (это, как вы помните, слабость), но это понимание приходит со временем (а это уже сила).

Никогда не оправдывайте ситуацию, просто принимайте её ‘as is’.

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

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

И сделайте всё это сами.

И Сергей Мартыненко там же добавил:

Стажерам или тем кто только начинает.

Зубры из зубров могут искать работу очень просто. Они изменяют статус «в контакте» на «ищу работу». На этом их активная деятельность по поиску работы заканчивается и они просто выбирают куда пойти работать. Иногда они не утруждают себя и этим. Бывает и так. Иногда они выбирают фирму, приходят и говорят: «У вас прикольно, как насчет меня?» — и их берут.

Но для этого нужно много делать. Что же делать сейчас?

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

А если у вас еще нет работы.

Советы:

* делайте как сказал astenix

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

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

* Помните, не вас покупают, но вы продаетесь. По крайней мере пока.

* Учите панбагон и дописывайте его. (К Баранцевым).

Совет, который плохо работает:

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

Советы:

* Прямо сейчас начинайте фиксировать список людей, у которых вы бы хотели учиться/работать. С кем вы бы хотели работать. Я такой список веду.

Удачи.

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

«истинное знание не требует платы, ибо вы посвящаете ему жизнь.»

Но помните. Плата за это гораздо больше, чем просто оплата тренингов деньгами. Может быть вы не сможете заплатить. Или не захотите. Я захотел. 

И Наталья Руколь специально для подобных случаев разродилась аж двумя тематическими статьями:

1. 12 правил успешного собеседования тестировщиков
2. Как УСПЕШНО пройти собеседование на тестировщика

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

Да-да, давайте догадываться и угадываться 🙂

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

Кстати, смешно звучит — крупная компания микро программного обеспечения 🙂

В Киеве, в глобаллоджиевском «Gы-Club» проходит тренинг Натальи Руколь «Планирование тестирования и проектирование тестов«. Оно, конечно, более предназначено для менеджеров тестирования, однако и не будучи менеджером следует понимать, что и почему кругом происходит. В конце концов, тренинг «для менеджеров и для ведущих тестировщиков». А кому будет приятно считать себя не ведущим тестировщиком? 🙂

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

В какой-то момент выяснили, что в зале есть много QA.

Через некоторое время выяснилось, что QA в зале не очень много.

Разгадка феномена: Наташа разъяснила, что QA — это процессные менеджеры, а не все тестировщики вообще.

Кто же знал… 🙂

На слайде с представлением MS Word был замечен следующий текст:

Июль 1805 года. У Анны Шерер, фрейлины, приближенной императрицы Марии Федоровны, больший прием, несмотря на грипп (модное словечко), которым она якобы страдает. Первым появляется важный и чиновный князь Василий Курагин. Он не собирается здесь долго задерживаться — за ним заедет дочь, и они отправятся к английскому посланнику. Гость и хозяйка обмениваются пустыми замечаниями. Князь Василий вообще всегда говорит лениво, как актер говорит роль старой пьесы. Анна Павловна Шерер, напротив, несмотря на свои сорок лет, преисполнена оживления и порывов.

Откуда текстишко?

С инета, вестимо…

Но все-таки, откуда текст?

Вроде бы речь идет о персонажах из эпической саги о вампирах «В0йна и мир»… Но стиль такой уродский, что сам граф, будучи обвиненным в авторстве, отрекся бы и от авторства текста, и от своего гражданства, и от своей бороды.

Яндекс нагуглил этот текст на сайте центра помощи налогоплательщикам.

Lorem ipsum dolor sit amet…

Оправившись от удивления, поискал еще и понял, что это всего-лишь кусок школьного реферата в стиле «Ап чём гавариццо в рамане Donkey Hot за авторством Ламанческого«.

Гуд.

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

Наташа в своей стихии (управление процессом), тренинг проходит живо и адекватно.

Команда «Неформалов» обсуждают рулезы формализма в подходе к тестированию

Слайд про «школы тестирования» Наташа прокликала за две секунды. То есть, пропустила.

С точки зрения темы тренинга — да, понимание того, что там со всеми этими «школами» делается, не очень существенно.

Я это вообще заметил только потому, что все «общеознакомительные» занятия в «ПодКлассе» как раз начинаю с разъяснения про подходы к тестированию.

Это сразу объясняет, почему тестирование такое разное и неоднозначное; это сразу помогает понять «велосипед»; это сразу форматирует в правильном виде понимание бэкграунда, которое находится за всем тем, что подразумевается под словом «Тестирование».

В общем, мне это кажется очень важным делом. А то все кругом одинаково сеньорные тестировщики, а терминология — разная… Сколько можно уже 🙂

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

А еще ей давно пора поменять модель телефона, бо с такими сложностями включать блютуф — увольте…

Хинт: на большинство вопросов Наташи к участникам тренингов можно отвечать словом «Цель!»

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

ЗЫ Пицца из ресторана «Mafia» не рулит. Из «Империя пиццы» рулит, но вот сайт у «империи» тестирования не выдержал вообще.

Текст итогового сертификата собран из весьма грамотного облака тэгов, и имя тренера в этом словесном облаке читается так: «Наталья Тренер Руколь».

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

о_О

В частности:

Проходили собеседование пару тестировщиков. Спрашиваю — что учили, что знаете про тестирование.

Ответ: «Я изучал тестирование полностью по блогу А. Лупана«

Гы 🙂

— А у Руколь, Баранцева бываете ? Читали? Курсы?

— А кто это?

— Э… Как же вы тогда изучали тестирование по блогу Алексея?

— А чо я, там всякие ФИО смотреть должен? Я ж тестирование изучал )

А потом сообщил, что ты ему подарил свою футболку в которой был на тренинге Баранцева. Я вот очень сомневаюсь что ты ее подарил ему 15 июля, а потом забрал, и пришел 23-го на тренинг 😀

При этом он сказал что футболка была на него коротка. А рост у него 1,73… Ну, явно твоя майка была б ему по колено, примерно )

Тут меня окончательно пробило на «бугугугугагага!». Ведь если соврал про футболку, следовательно, соврал и про то, что учился.

В общем, должность парню не предложили.

Дима, пожалуйста, пришли мне по почте (наложенным платежом) свои глаза.

Хочется в них посмотреть 🙂

И иди — учись.

Хихикать там не над кем, бо русского языка они не знают, а надрать задницу готовы любому белокожему задроту, который в их сторону неинтеллигентно ухмыльнётся.

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

То есть, дальше будет чуть более подробное рассуждение про самокопание и профориентацию нахальных тестировщиков.

Перед прочтением надо запастить мартини (я взял коньяк, тирасполь, восемь лет, подогнали на мой прошедший «ДР!») и наушниками.

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

Сперва эту музыку включить, бо без музыки мне стрёмно такие рассказы рассказывать.

Рассказываю

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

Работая в Киеве в большой компании в качестве необычного тестировщика-технаря, я узнал о том, что:

1. иной программист может обоснованно получать ЗП больше, чем его непосредственный менеджер проекта;
2. иной тестировщик может обоснованно получать больше программиста, который получает больше чем ПМ;
3. иной менеджер тестировщиков может вообще перестать тестировать, бо от него это и не требуется;
4. стать менеджером может не каждый технарь, даже самый старательный и умный;
5. стремление стать начальником ничего не гарантирует.

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

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

Не стихийно, конечно, но очень резво.

И такой процесс в итоге привел к ожидаемому результату — «Сэр,этот корабль проще потопить, чем вывернуть на другой курс, сэр».

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

Да, есть вики.

Да есть svn, и что круто, программисты действительно используют его очень грамотно.

Но вклиниться с тестированием в их какой-никакой, но налаженный быт и процесс было сложно.

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

А еще сложнее было оценить масштабы тестирования. Практически те же траблы, что и тестировщика игр:

1. Проекту много лет.
2. В проекте уже много-много функционала, и большинство работающих над ним фокусируются только на его отдельных аспектах.
3. Тест дизайн или что-то подобное никогда не делалось, бо нафига оно надо? (ничуть не иронизирую).
4. Документация в вики есть, конечно… но…
5. Отсутствие тестового покрытия, а значит и невозможность сказать что «такая-то функциональность» работает на 100% от предполагаемого.
6. Бешенные сложности с регрессионным тестированием.

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

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

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

Теперь у нас даже задачи раздаются и отслеживаются через Mantis 🙂

Ладно, частностей много, дело еще не завершено, поэтому я вернусь к общей теме.

Я всё ещё помню, как мне работалось в Глобале.

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

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

Менеджеры уже всё продумали. Всё обеспечили. Приняли наилучшие стратегические и тактические решения, коим надо было следовать. А я солдат рядовой с небольшой головой, мне-то что…

«В двадцати шагах чужие каски с той же целью — защитить мозги«.

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

Скорее, если у тебя есть задатки и способности менеджера, тебя, вероятно, ВЫДЕРНУТ из общей толпы и посадят на определенный электростульчик ответственности, нежели тебя БУДУТ УЧИТЬ тому, что должен знать и уметь настоящий менеджер.

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

Без внутреннего «Лёха, двигай попой!» ожидать своего выдергивания наверх можно долго, тупо и глупо.

А вот в маленькой компании это перетекание вполне естественно. Народу всегда мало. Кто-то же должен быть начальником? Вот и становись…

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

Например, перевод того, кто к переводу не стремится, зачастую чреват.

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

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

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

Но двигаться надо всегда самостоятельно.

Мне жаль того, что пришлось покинуть Украину в очень сложный для меня момент — я очень хотел понять, являюсь ли я кандидатом на ВЫДЕРГИВАНИЕ. Важный вопрос, не так ли?

С одной стороны, всё было против меня. С другой стороны, всё было за меня.

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

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

После возвращения в Кишинев я снова стал управленцем тестирования (делов-то!), но тут тестировщик-управленец также и тестировщик-технарь, бо больше кликать некому.

Прошел год, а меня всё ещё свербит желание разгадать загадки «больших» тест-менеджеров, за повадками которых я наблюдал в Киеве в вольере ГлобалЛоджика.

А кого тут спросить?

Поэтому, когда я случайно* узнал про «Школу тест-менеджеров«, я всячески стал сучить ножками в поисках возможностей попадоса на этот тренинг.

* Ну, как случайно…

Это такая случайность, на которую натыкаешься только потому, что ищешь, хотя и сам точно не знаешь, что именно ищешь.

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

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

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

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

Цена за московский тренинги для молдаванского тестировщика очень суровая — почти $800 за живое выступление (отпадает сразу), и «всего» $350 за он-лайн версию.

Мне ныло и свербило попасть хотя бы на он-лайн версию, но, ёпрст, даже такая цена по нашим меркам всё равно неудобная, жабодавительная и сложно подъемная.

Варианты вроде «пусть заплатит компания» в наших шпинатах не уместны. Мне надо — я и плачу.

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

И бодро пошёл на тренинг.

Внимание интересующимся тестированием компатриотам.

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

Обращайтесь.

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

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

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

Чёрт с ним, с этим свидетельством, согласен.

Я положил его под оргстекло на своем столе, рядом с сертификатом об участии в прошедшем SQA Days и дипломом о занятии второго места в международном турнире по игре в «Морской бой» в каком-то заштатном кишиневском ресторане.

На тренинге я очень хотел узнать то, чего не знал. В итоге научился тому, чего не умел, хотя почти знал.

Разница понятна?

Неужели?!

Вообще, тренинг этот ударил по моему самолюбию, как Катерина Зеленко по немецкому Мессершмитту.

Мне казалось, что я кое-чего ЗНАЮ.

И умею.

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

Например, очень понравилось элегантное поднятие моих век в плане того, что «тест-план можно написать за 15 минут».

Это уравновесило мою психику, и я, собственно, от раздумий тупо перешел к делу, и таки написал свой грамотный тест-план — за 15 дней. Уже хорошо. Раньше в подобное не верил.

Таки удивило, что вопросы с тренером можно обсуждать и в три часа поздней ночи, и рано вечером. Осознанно или нет, но у автора получился запойный консультационный тренинг, за что я постоянно тревожился — а уместно ли спрашивать о чем-либо в три утра? Жалко тревожить, в общем…

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

Минусом я посчитал только собственную тормозливость — я не успевал вовремя делать домашние задания, и некоторые до сих пор лежат в каталоге «___СуперСрочноВсёСделатьДоЗавтра!!!!!!!».

Однако вывел для себя правило о том, что надо не только назначать конечный срок выполнения задач (так на тренинге говорилось в виде манагерской мантры), но и точное время начала работы над ней. Иначе будет постоянное «Оп-па, а что, уже пришел день сдачи?»

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

И таки сработало.

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

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

Понту мне рассуждать о тонкостях управления танком, если ни разу не нажимал на педали в танке? Надо сесть и проехаться, а потом рассуждать.

Тестирование ничуть не хуже управления танками — надо пробовать сделать, а не останавливаться на уровне «Конечно, читал я ваших Блэков и Канеров, да… Я профессионал, да…»

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

Поэтому главный вопрос о собственной подходящести на роль тест-менеджера еще открыт.

Да, я занимаюсь управлением тестирования.

Да, я всегда больше интересовался тем, как устанавливать процесс, нежели непосредственно дабл-кликингом.

Но сейчас, после тренинга, я чувствую себя тестировщиком-технарём, а не манагером.

Наверное, это нормально, и просто моя психика таким образом защищается от само-изнасилования, но всё-таки…

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

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

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

В особо неудобных условиях надо просто менять рабочее окружение вместе со всеми «странными» начальниками. Это вообще не сложно.

Выводы вынести легко.

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

Фишка в том, что надо всегда становиться начальником самого себя, а не искать себе очередного удобного дракона** и очередной электростульчик с указанием занимаемой должности.

Драконам задницы надо всегда надирать, а не подтирать.

** намек на сказку Евгения Шварца.

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

Между прочим

Вот нечто, над чем можно зависнуть на пару добрых часов рассуждений — видео с открытой лекции Алексея Баранцева “Почему тестирование занимает так много времени?”

Звук у видео глуховатый, поэтому берем наушники.