Иногда в телевизоре начиналась телепередача «В гостях у сказки». Было волнительно.

Анастасия Зуева

И да, это чёрно-белая картинка с телевизионными искажениями, бо вы офигели требовать цветной FullHD в советском телевизоре.

Александр Александров сказок не читает, но при запуске видео с его докладами у меня всегда возникает то самое ощущение из навсегда ушедшего времени и волнение ожидания торта.

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

И там вообще не для джунов (там над вами хохмят).

Я перегнал доклад в полноценную текстовую версию, бо оно того варто. Видео — в конце.

Александр Александров

Экономика тестирования. Версия 1.0 (2018)

О чём будем говорить

• Общеизвестные (но не до конца) истины, или почему такая тема
• На что влияет экономика тестирования
• Что такое Версия 1.0 — Подробно
• Зачем нужна Версия 2.0 — Кратко

Почему такая тема

Эту тему я обдумывал на протяжении прошедшего года, и ещё не нашёл ответы на многие важные вопросы.

Например, для меня было неожиданностью узнать, что тезис о том, что «Исчерпывающее тестирование невозможно» — не для всех очевиден. Когда меня спросили «А почему?», я сослался на книгу Гленфорда Майерса «Надёжность программного обеспечения» (1979), где был приведен пример причины. Ответ был: «Ну, там же математически не доказано, что это так!..» Я вспомнил своё математическое образование, и указал на теорему Кантора, которая говорит о том, что множество натуральных чисел — счётное (то есть, это бесконечное множество,  элементы которого можно перенумеровать натуральными числами), а раз счётное, то оно не конечное. И если сделан калькулятор, который складывает натуральные числа, то НЕВОЗМОЖНО  провести его исчерпывающее тестирование — и так далее, и так далее.

Другой источник для аргументов — силлабус ISTQB, где чёрным по белому написано о том, что исчерпывающее тестирование невозможно.

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

Наконец, есть здравый смысл: все мы тестировщики (или все, кто не тестировщики, но, очевидно, хотят ими стать, потому что другого пути развиваться у человечества, конечно, нет 🙂 ), и у нас есть опыт тестирования, который приносит понимание того, что невозможно написать ВСЕ тест-кейсы и выбрать ВСЕ тестовые данные, нельзя пройти ВСЕ пути в коде и выполнить ВСЕ действия, которые может делать пользователь и так далее и так далее.

Вроде бы абсолютная истина, но вопросы на эту тему появляются снова и снова на самых разных уровнях, и особенно на уровне топ-менеджмента:

• «Когда вы завершите тестирование?» (Когда? «Завершить» означает «Сделать всё». Когда можно сделать всё?).
• «Когда будут найдены ВСЕ дефекты?» (не то что половина, но даже 99% найденных дефектов, конечно же, никого не устроит)
• «А когда мы поставим заказчику ПО без дефектов?»
• Если дефект в продакшн — «Почему этот дефект не был найден?»
• «А почему ВСЕ дефекты, которые были обнаружены в продакшн, не были найдены до передачи в продакшн?»

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

Возникает следующая тема: критерии тестирования. Практически любые критерии завершения тестирования должны учитывать условия вроде:

• Если ущерб от незакрытого дефекта не превышает затрат на его исправление, то исправлять дефект не надо;
• Если ущерб от потенциального дефекта не превышает затрат на его поиск и исправление, то искать дефект не надо;
• Если суммарный ущерб от всех известных незакрытых дефектов не превышает выгоды от внедрения существующей версии системы, то ее надо внедрять (пусть даже и с известными незакрытыми дефектами).

Обратите внимание на слова «затраты» и «выгода» в этом списке. В конечном итоге, если для того, чтобы исправить дефект, нам надо потратить денег (универсальное мерило работы и результата) больше, чем понадобится на покрытие ущерба, который нанесёт дефект, то этот дефект исправлять — не надо. С этим фактом трудно смириться, потому что он имеет далеко идущие последствия.

Что всё это означает с точки зрения выстраивания стратегии тестирования? Тестирование нельзя завершить, его можно только прекратить, поэтому нужны какие-то критерии прекращения тестирования — они, в том числе, и экономические, а не только технологические. Я бы взял на себя наглость заявить, что они только экономические, но эта формулировка, наверное, устроит не всех. И в этом принципиальное отличие того, чем занимаемся мы, тестировщики, от того, что делают разработчики:

• Все разработать — Можно
• Все протестировать — Нельзя

Разработчики могут сделать всё. Они могут ответить на вопрос «Сколько нужно времени, чтобы всё запрограммировать?» — например, два с половиной месяца. А почему? А потому, что там 18 фич, и в среднем на одну понадобится 3 дня. А сколько времени нужно тестировщику, чтобы найти все дефекты в этих 18-ти функциональностях? А сколько времени нужно тестировщику, чтобы написать для них ВСЕ тест-кейсы? А сколько времени нужно тестировщику, чтобы проверить ВСЮ функциональность? Никакого времени не хватит. Значит, мы должны говорить о том, когда мы прекращаем тестирование и почему мы его прекращаем. И эти критерии должны быть как технологическими, так и экономическими.

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

Пример: «Если потратить столько-то человеко-часов, получится приемлемое качество (не очень много дефектов останется). А если потратить меньше, то качество будет хуже (больше дефектов останется)». Это значит, что если мы потратим 5 000 ч/часов, то мы найдём 97% дефектов, а если мы потратим меньше, то мы найдём меньше дефектов. В такой формулировке мы можем говорить, как нам организовать тестирование — конечно, при определённой зрелости процессов разработки.

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

• Рецензирование требований
• Разработку тест-кейсов
• Ручной прогон тест-кейсов
• Автоматизацию тест-кейсов
• Анализ результатов и подготовку отчетности

Инвестиции в трудозатраты должны возвращаться (ROI) качеством объекта тестирования. Мы знаем, на что мы должны потратить время и деньги — мы должны привлечь в проект людей определённой квалификации, платить за инструменты автоматизации  и так далее. Мы должны инвестировать в тестирование, в том числе и в трудозатраты. Но любой инвестор спросит, что он получит взамен. А что мы можем предоставить взамен? Качество.

На что это влияет

Давайте рассмотрим анатомию процесса планирования.

Надо планировать так, чтобы затраты были реалистичными (укладывались в бюджет проекта) и эффективными (давали бы ожидаемый результат). Если мы пообещаем, что нам нужно 5 000 ч/часов, а за эти 5 000 ч/часов мы что-то протестируем, то нам головы открутят, и, естественно, извинения после этого приносить не будут. Если мы пообещаем, что мы гениальные тестировщики и что за три дня найдём все дефекты, то нам тоже головы открутят, но позже, когда необнаруженные дефекты выскочат на продакшне. И тогда зачем обещать? Ведь за свои слова надо отвечать.

Значит, необходимо пользоваться методами и моделями оценки трудозатрат на тестирование (я рассказывал об этом в 2011 году на SQA Days в Москве в докладе «Оценка трудозатрат на тестирование в проектах сопровождения» https://sqadays.com/ru/talk/12185). На основании полученных оценок планируются активности по тестированию. Необходимо также  отслеживать процесс тестирования, чтобы вовремя обнаружить отставание от плана и скорректировать его.

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

Мы можем недооценить трудозатраты на тестирование. Да, мы можем их недооценить с самого начала. Например, мы запросили 5 000 ч/часов, а их в проекте нет, и нам предлагают —  возьмите 3 500 ч/часов и как-то выкручивайтесь. Что ж, давайте крутиться.  

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

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

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

Подробно о Версии 1.0

Недооценка трудозатрат на тестирование часто приводит не к изменению  стратегии тестирования, а лишь к увеличению трудозатрат (дополнительному времени, персоналу и др.) и, как следствие, к увеличению сроков и/или стоимости проекта. Или мы недооценили трудозатраты, или нам их недооценили — что делать? «Дайте нам то, чего нам не хватает! Да, мы получили оценку в 3 500 ч/часов, но поскольку всё пошло не так, нам надо ещё. Нам надо больше людей и времени». Чем это плохо? Мы выходим за обещанные рамки, за сроки и за стоимость, а для заказчика ничего хуже этого не бывает, потому что ложка дорога к обеду. Конечно, если вы сделаете работу в срок, но плохо — это неприемлемо, но если вы сделаете хорошо, но на полгода позже — подумайте, что хуже. 

Рассмотрим решения реальных кейсов. Первый: «Главное — получить проект, а там посмотрим». Мы участвуем в тендере. Мы оценили трудозатраты на тестирование  в 500 ч/часов. Получилось дорого, поступает указание урезать трудозатраты, но разработчиков урезать нельзя! При таких трудозатратах проект продать нельзя, поэтому уменьшили тестирование до 300 ч/часов. Дальше — больше. «Непонятно, что в проекте делают тестировщики. Если они поставляют ПО с дефектами — от этого проекту только хуже. Если они тест-кейсы пишут — да кому эти тест-кейсы нужны?!» Мне приходилось эту фразу слышать от топ-менеджмента неоднократно.

Хорошо, мы согласились на 300 ч/часов. Как мы это сделаем за 300 ч/часов — мы не знаем. Но мы согласились с этой оценкой, пообещав тем самым  сделать все в полном объеме, со всеми артефактами. И вот эти часы исчерпались. Дальше что? Чудес не бывает: либо тестирование останавливается, что для проекта губительно с технической точки зрения, либо тестирование продолжается себе в убыток, и приходят грозные дяди из финансового подразделения и спрашивают, почему компания несёт убыток. А если к тому же компания торгуется на бирже, нам говорят «вы показываете низкую маржу, от нас побегут инвесторы». Результат: качество проекта непредсказуемо.

Второй кейс: «Любой каприз за ваши деньги». Сколько раз мы говорим это заказчику? Заказчик воспринимает это буквально, и начинает требовать любой каприз за свои деньги. Проект выполняется по модели Fixed Price, потому что все стремятся минимизировать затраты, начинаются изменения, повторное тестирование, мы получили свои 500 ч/часов, мы их честно израсходовали, потому что мы подписались под «ваши капризы» и всё, результат печальный. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.

Третий кейс: «Тестирование от забора до обеда». Мы оценили трудозатраты  на тестирование в 500 ч/часов и получили согласие на эти трудозатраты. У нас есть команда, и мы начинаем тестировать, не заботясь о  приоритетах и целях, мы тестируем всё, что под руку попадается, потому что всё это заказчику нужно — он же сам нам об этом сказал. Мы заказчика очень любим и хотим сделать работу хорошо, но вот 500 ч/часов исчерпались. А что происходит с приложением, когда эти 500 ч/часов исчерпались? А бог его знает. Что-то протестировано, что-то нет, где-то написаны скрипты автоматизации, которые, правда, ничего не находят, но они же написаны. Регрессионное тестирование с помощью автоматизации — это такая фишка, которая с одной стороны, может ничего не дать, а с другой стороны, деньги жрёт так, что никакая расточительная длинноногая молодая так не сможет. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.

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

Кратко о Версии 2.0

Поговорим о том, в чём разница между экономиками тестирования версии 1.0 и 2.0.

Версия 1.0 — это парадигма, в которой, к сожалению, мы с вами сегодня работаем. Нам дали сколько-то ресурсов, а теперь мы должны дать результат. Почему всё так устроено? А потому, что мы знаем, как эти ресурсы использовать. К примеру, мы знаем, что из 500 ч/часов 200 мы потратим на написание тест-кейсов, 100 на автоматическое тестирование и 200 на ручное — но это все в идеальном мире, если не будут радикальных изменений, все тестировщики будут прекрасно работать, и так далее. А если мы обосновываем оценку, показываем ее реалистичность и  эффективность, и будем оценивать все риски, то за эту оценку, уж извините, любой нормальный менеджер проектов открутит вам голову, ибо ему непонятно, почему тестировщики должны ошибаться — они же тестировщики! Это разработчики могут ошибаться, но чтобы тестировщики — никогда 🙂

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

А что такое Версия 2.0? Вот мы получили оценки. Эти оценки играют роль запасного парашюта. Это то, как мы будем работать, если у нас ничего более эффективного не получится. Но Версия 2.0 говорит нам о том, что надо использовать обоснованные трудозатраты эффективно, анализируя проектную ситуацию. Мы будем писать тест-кейсы? Если будем, то какие? Какие тестовые данные мы будем использовать и где мы будем их брать? От заказчика? Свои? Какие нам нужны тестировщики — мало сильных (но дорогих) или много слабых (зато недорогих)? Нам нужна стабильная команда для данного проекта или нет? Нужна нам автоматизация вообще, и если да, то какой инструмент, какое покрытие должно быть обеспечено?

Если для Версии 1.0 критерии — это возврат инвестиций в трудозатраты (ROI), то для Версии 2.0 критерий — это максимизация выгоды. И это разные вещи.

Заключение

Перечислим кратко основные тезисы.

• Исчерпывающее тестирование невозможно.
• Тестирование — это в том числе и экономическая деятельность.
• Версия 1.0, или Что надо сделать. Работаем в рамках плана и оценки, при нехватке ресурсов просим их добавить (экстенсивный подход)
• Версия 2.0, или Как надо сделать. Работаем в рамках плана и оценки максимально эффективно (интенсивный подход)

Благодарности

Наконец, позвольте поблагодарить:

• Организаторов конференции SQA Days # 24 за приглашение и возможность выступить.
• Моих коллег Андрея Ладутько, Александра Лукашева, Андрея Павлова, Алексея Федорова и Александра Куцана за детальное обсуждение тематики доклада и поддержку.
• Программный комитет конференции SQA Days # 23, благодаря усилиям которого на SQA Days # 24 появился этот доклад и, надеюсь, на SQA Days # 25 появится доклад «Экономика тестирования. Версия 2.0» и его широкое обсуждение.

Вопросы и ответы

Стоит ли вообще тестировщику отстаивать свои 500 ч/часов, которые он рассчитал, долго и упорно, или согласиться с оценкой менеджеров, перекладывая на них, таким образом, ответственность за результат?

Не стройте иллюзий о том, что вы перекладываете ответственность. Если вы согласились на 300 ч/часов вместо 500, то вы взяли на себя ответственность, что протестируете всё за 300 ч/часов. Придут и спросят: ну как же, вы же обещали? Вы же сказали, что за 300 ч/часов ВСЁ протестируете, и дефектов не будет. Но дефекты есть. Тогда за что вы зарплату получаете?

Если вы знаете, как протестировать за 300 ч/часов, и 200 ч/часов для вас было «большой подушкой» — ради бога. Иначе — вот вам горящий фитиль в бочке с порохом, на которой вы сидите, и радуйтесь тому, что вы не знаете длины фитиля и не знаете, когда оно жахнет.

Сколько времени у вас занимает разработка оценки для проекта и кто это делает?

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

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

Если говорить про ресурс, то этим занимается тот ресурс, у которого хватает квалификации для этой работы (наука, поверьте, не дворянская).

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

Стоит ли закладывать оценку трудозатрат на оценку трудозатрат в тестировании?

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

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

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

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

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

Этот расчёт может быть очень полезным с точки зрения обоснования трудозатрат на тестирование. Когда вам заказчик говорит «А на что вам 500 ч/часов на тестирование?» можно ответить «ОК, давайте снизим до 300. В этой функциональности раз в месяц у вас будут возникать отказы, и центральная система банка будет простаивать шесть часов. Можно посчитать, сколько вам будет стоить этот простой?» Вот это и будет объём убытков. Вы нам не даёте деньги на 500 ч/часов — значит, у вас будут убытки, и вот столько они будут стоить (обычно, больше пресловутых 500 часов на тестирование).

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

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

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

Пример — штрафные санкции из  контракта Сбертеха: шесть серьезных дефектов в продакшн за полгода — штраф в размере стоимости контракта на разработку ПО. Шесть дефектов в огромной системе — это абсолютно реальная вещь. Есть резон брать на себя такие риски?

Если всё протестировать нельзя, то следует ли из этого, что у нас всегда непредсказуемое качество? И как можно его предсказать?

 Позволю себе сослаться на свой доклад на SQA Days в 2009-ом в Питере, где это обсуждалось https://www.slideshare.net/SQADays_2009_Piter/ss-1703956 (сохранились только слайды).

Предсказать можно. Да, есть методы количественного управления — «шесть сигм», статистическое управление и так далее. С вероятностью 99,97% можно оценить количество дефектов, которые у нас будут на выходе. Если есть более тридцати измерений, то статистика весьма достоверная, и можно предсказывать количество дефектов. Это требует определённой процессной культуры и определённой профессиональной инженерной культуры в тестировании, но до конкретного уровня и с конкретной точностью это оценивать можно. Тогда вы скажете, что если тестирование будет проводиться с такими-то параметрами, то у нас будут в продакшн (упростим для простоты) два серьезных дефекта на 10 000 строк кода. Мы можем соотнести затраты и выгоду, и защитить эту оценку.

А в ситуации «Дайте нам 500 или 5 000 ч/часов, только мы не знаем, что получится в результате», демонстрируется профессиональная  беспомощность, что не есть хорошо.

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

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

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

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

Оценивали ли вы затраты на обучение и на тестирование? Есть ли техники нахождения баланса, когда дешевле привлекать специалиста извне, или дешевле обучить своих сотрудников?

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

Сотрудника вводят в проект, когда проект уже есть. Если брать заранее, то есть риск, что проект не состоится, и затраты не будут возвращены.

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

Видео после текста.

— Будем рассуждать о том, во что превратилось обучение тестировщиков в наше время, и что с ним будет в ближайшем будущем.

В 2014 году в Киеве было под тридцать курсов по тестированию. И ещё плюс в Одессе и во Львове. Для Украины это было не так, чтобы мало, и большое количество курсов обещало то, что (наконец-то) на рынке появится много обученных тестировщиков. Их можно будет брать на работу и кидать на проекты — бизнес пошёл! Ожидалось, что количество будет переходить в качество.

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

Что будет дальше? Как нам себя вести, и вообще — что нас ожидает?

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

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

Люди, у которых опыт работы больше 3-х лет, осваивали профессию тестировщика самостоятельно (я из их числа), и они пришли в тестирование в 2010-2012 годах. То есть шесть лет назад. То есть тестировщики, которые приходили на работы, которые появлялись, казалось бы, из ниоткуда, по качеству своему, и по техническому оснащению, и по своему состоянию намного превосходят тех тестировщиков, которые появляются сейчас.

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

Есть очень много людей, которые видят всё происходящее в жизни в виде цепочек, которые одна за другой цепляются. То есть для того, чтобы быть социально защищённым, нужна хорошая работа. Хорошая работа = хорошее образование. Следовательно, для того, чтобы получить хорошую работу, мне надо сначала закончить школу, университет — по цепочке. Эта цепочка на самом деле не так уж и валидна. Она в очень многих случаях представлена у успешных людей в виде разрывов. Нам хочется видеть всё упрощённо. Понимание того, что происходит, всегда представлено во взаимосвязке. Иногда есть вещи логичные, но совершенно глупые, и поскольку они логичные, люди ими руководствуются. Соответственно, нынешние люди, которые учатся тестированию, руководствуются ошибочным выводом о том, что для того, чтобы стать тестировщиком, нужно сначала куда-то пойти и у кого-то научиться.

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

Она присутствует на рынке в виде ужасающей ямы, в которую скатываются все. Яма-воронка, скажем так, которая затягивает, даже тех, кто понимает, что можно сделать что-то по-другому, так или иначе. В большинстве резюме, которые были ещё лет 5 назад тестировщики писали, что владеют Microsoft, Excel, PowerPoint, Word и прочие интересные вещи. В современных резюме тестировщиков (практически у всех) указано, что «закончил такие-то курсы». Такой вот тренд времени. Это не хорошо и не плохо, просто фиксируем то, что есть.

Далее забавная и странная вещь. Половина опрошенных на qatrends указали, что «курсы оказали огромное влияние на получение работы в сфере тестирования». Еще раз — половина всех тех, кто ходит на обучение, считает, что это оказывает большое влияние на получение работы.

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

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

Среди преимуществ курсов было заявлено, что преподаватели — реально работающие практики с огромным опытом. Это хорошо для привлечения аудитории, которой ещё можно сказать, что, например, учим английскому языку с носителями языка. Кто-нибудь научился английскому языку, изучая его именно с носителями, находясь здесь, в русско-украиноязычной среде?! Логика говорит, что это — призрачный путь. Опыт показывает, что для того, чтобы выучить английский язык, нужно сначала понять, как он устроен. Для этого не нужно сразу начинать говорить только на английском, да еще и с носителем. То есть, идея о том, что если на курсах преподаватели с реально работающей практики, с огромным опытом, следовательно, там можно научиться чему-то хорошему — ошибочна.

У практика можно научиться тому, что он уже может делать, и зачастую делает неосознанно. Если вы наблюдали когда-нибудь за людьми, которые работают на уровне неосознанности, они делают все очень быстро. Все, чему можно научиться в работе у практика, это просто перенять какие-то навыки или же шаблоны поведения. Практик не объясняет, почему он что-то делает, он не объясняет, почему этот феномен существует, как этот феномен появился, как он связан с другими феноменами — именно всё то, что нужно объяснять другим начинающим.

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

Однозначно вследствие этого опроса (по-меньшей мере, я это увидел) выяснилось то, что цепочка, которая привлекает людей на обучение, чуть менее, чем полностью характеризуется словом «однозначность»:

1. пойду на курсы —
2. значит, подготовлюсь к работе —
3. значит, возьмут на работу.

Это логично. А опыт показывает, что это тупиковый путь.

Следующий тренд, который тоже ведет к однозначности, но он представляет собой видение работодателей. У них ожидание следующее:

1. пришел с курсов =
2. подготовлен к работе —
3. значит, возьмем на работу.

То есть, и учащиеся, готовящиеся к работе, и работодатели, которые смотрят на толпу учащихся, ожидают, что если курсы прошел — следовательно, подготовлен к работе. И вот здесь самое неприятное и самое очевидное из того, что надо признать: курсы не готовят к работе. Если бы готовили, то 50% опрошенных не жаловались бы на нехватку практики. Второе — если бы курсы готовили к работе, то просто будучи выпускником с какого-то курса, можно было бы сказать, что работа гарантирована. Но этого не происходит. Большинство компаний (всё ещё) проводят собеседования и отсеивают большую часть кандидатов, несмотря на то, что они проходят даже не один курс, а сразу несколько.

Чем отличаются краткосрочные курсы от долгосрочного вузовского образования? Ничем. Просто вуз — это курсы длинной в несколько лет. Современные курсы это обучение длинной в несколько месяцев. Какая может быть практика за несколько месяцев?! Да и даже за несколько лет её бывает сложновато получить.

Сложность обучения современных тестировщиков (это то, что я заметил) в том, что тестировщики старой школы проходили тестирование уже понимая, что такое программирование, или, по-меньшей мере, могли на HTML могли сделать что-нибудь. Хотя бы. Это представители того поколения, которое ещё живо, они ковырялись в компьютерах из интереса, а не будучи принужденными это делать, потому что нужно работу найти. Я когда ковырялся в компьютерах — я ещё и журналистом был! У меня не было дома компьютера — это приветствие тем, кто говорит, что невозможно научиться программировать, потому что у меня дома нет ноутбука. Можно научиться.

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

Ну, и вузы. В вузах тестировщиков не учат. Там и программистов не учат, на самом деле.

Делаем выводы.

Курсы высшего образования, то есть вуз — ничего не стоят, потому что все знают, что это потерянное время. Все согласны, да?

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

Итак, курсы высшего образования ничего не стоят. Краткосрочные курсы, оно же ПТУ древнее, оно же нынешние курсы — не вуз, следовательно, они чего-то стоят.

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

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

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

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

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

Например, есть такое понятие — регрессионное тестирование. Всем знакомо? А еще есть понятие регрессивное тестирование. Знакомо? В чем разница между регрессионным и регрессивным тестированием?

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

— Нет! Нет разницы между этими терминами. Regression Testing — это однозначный феномен. Просто он переводится по-разному. Люди, которые учились тестированию, читая только Савина, привыкают к слову «регрессивный», потому что Савин именно так его использует — все регрессионное называет регрессивное.

На многих собеседованиях именно так все происходит. Очень легко запутать начинающего, предложив найти разницу между этими двумя терминами. И её таки начинают искать и таки находят… хотя её нет.

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

До тех пор, пока этот разрыв будет сохраняться, как это сейчас происходит, мы будем получать все больше тестировщиков, которые, на первый взгляд, знают о тестировании всё. По меньшей мере, они оперируют терминами, или реагируют на них определенным образом. Но когда начинаются уточняющие вопросы — понятно, что термин то известен, но что за ним стоит — туман и дым. Работать такие тестировщики не могут. Как некое исключение, компании берут несколько тестировщиков «на вырост», надеясь, что адекватный пацан вырулит, когда его кинут в работу.

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

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

Ещё неприятное еще. Все однотематические курсы, общенаправленные, со временем неизбежно усредняются. Чем отличается выпускник SkillUP от выпускника GoIT? Цветом футболки они отличаются…

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

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

Из-за того, что всё усредняется, студенты становятся абстрактно знающими тестирование. Абстрактное знание тестирования — идиотизм совершенный! Представьте себе, что нам надо сейчас кого-нибудь обучить тестированию, и мы не знаем, где он будет работать. Чему его учить?! Тестированию десктоп, веб, основам чего? Как? Что он будет делать?

Тестирование — неоднозначный феномен. Хоть и слово одно и то же, но когда тестируешь алгоритмы, это вообще другие подходы и другое мышление, нежели когда тестируешь функциональные вещи. Поэтому: чему должны учить курсы? Тому, что сейчас на рынке востребовано? А что сейчас востребовано на рынке? Веб и мобайл, очень неоднозначные шняги. Веб разный бывает. Мобайл постоянно меняется. Чему именно надо учить? Конкретным технологиям, или общим принципам?

Ок, не надо учить тестированию ВООБЩЕ, это логично. Учить нужно по-другому. Учить нужно частностно и личностно. Нужно не учить, а тренировать. Это очень сродни со школами, которые учат боксу, шахматам, плаванью. Школ много. Стилей обучения очень много. Но это все не командное обучение. Каждое обучение происходит личностно. Каждый пловец учится личностно, каждый борец учится сам, а не наблюдая за тем, как другие плавают, делая выводы о том, что когда мне нужно будет нырнуть, я скачаю учебник, и… значит, шаг один, шаг два… что делать?

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

Те, кто по психике своей не способны дальше продвигаться, на этом ломаются. И это очень хороший показатель. Сломался — не надо дальше заниматься. Если же не сломался и попытался хотя бы что-то сделать, объяснение того, почему получилось или не получилось, ляжет на уже подготовленную почву. Обучающийся начнет понимать намного лучше то, что он уже сделал, хотя бы чуть-чуть, или не получилось. Даже если ему сначала абстрактно, как в школе, рассказать о том, что существуют различные алгоритмы, и эти алгоритмы разруливаются вот 150-ью способами. До большинства из этих до способов можно додуматься. Когда учишься самостоятельно, это, на самом деле, тренировка и есть. Не обязательно в зале тренироваться боксу. Можно в Grand Theft Auto потренироваться. Как бы там ни было, личностно надо все делать. Научиться тестировать в группе, на курсах логично и разумно, но нецелесообразно вообще.

Нужно делать все под наблюдением тренера. Сколько обычно людей в группе у обычного тренера? Можно уследить за успеваемостью десятерых человек одномоментно? За тремя уже сложно уследить и сложно объяснить, что получается, что нет и почему. Но тренинг нужен, и тренироваться надо, потому что это дичайше отличается от школьного постулата, который во всех нас вбит — давать нужно только правильные ответы. Если ответишь неправильно, или сделаешь неправильное решение, будешь наказан — двойка, родители в школу…

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

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

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

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

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

Зачем проходить собеседование, если потом будешь тупить?! Жизнь заставляет, безусловно. Сначала нужно работу получить, потом я буду учиться тому, что нужно на работе. Логично? Глупость ужасающая! Но логично. Есть очень много людей, которые учат только то, что нужно будет на работе. Бить их нельзя, но идею эту надо из людей всячески выбивать.

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

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

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

Преподаватели тоже друг от друга чем отличаются — непонятно. Как отличить сильного от слабого преподавателя? Количеством выпущенных студентов? Цветом футболки? Восторженностью студентов? Залысиной? Непонятно.

Что такое хорошие курсы? Чем их отличать? Хорошие курсы от плохих отличаются качеством выпускников. Следовательно, если будет хороший преподаватель на курсах, то и курсы будут хорошие. То есть, все ищут хороших преподавателей, но искать их среди практиков разумно, но тяжело, потому что, повторюсь, практики не обязательно умеют объяснить. Быть тренером — это отдельная профессия, ей где-то тоже надо научиться. А где? А как? А сколько времени для этого нужно?

Слабости современных тренеров я обобщу. Современные тренера не могут объяснить суть феноменов, которыми они оперируют. Я умею ездить на автомобиле, но не знаю, где находится мотор, и почему он работает — водить-то это не мешает?! Есть же множество водителей, которые вообще не понимают, как и почему работает мотор. Точно так же и практики зачастую используют какие-то вещи, не понимая, почему они работают или почему они так называются. Самый простой тест на выявления слабостей и знаний практика это спросить, почему регрессионное тестирование называется регрессионным. Подумайте об этом как-нибудь.

Так вот что такое «Регрессионное Тестирование»!

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

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

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

Реальными курсами будут признаваться те, которые обеспечивают нужды владельцев проектов. Представьте себе, что вы заказываете не тестировщика, а сантехника домой. Сантехника вы будете брать того, который только что закончил курсы ВООБЩЕ, или того, который закончил курсы по подготовке конкретно к выполнению тех задач, которые именно вам нужны? Логично же…

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

Я «внутренний» тренер, я готовлю тестировщиков для работы в тестировании вообще, но в компании Astound Commerce в частности. И у меня это получается именно потому, что я знаю, каким должен быть хороший тестировщик, который будет работать в компании Astound Commerce. Это не brand book, в котором всё написано, это не какой-то общий план, который можно расписать и положить на стол, это больше интуитивное ощущение относительно того, каким должен быть тестировщик, что такое для него хорошо, и что такое плохо. И это понимание, оно ложится на ожидания компании, которые я сейчас обслуживаю, и это означает, что эффективность моего обучения неизбежна, она накапливается.

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

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

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

Точно так же надо тренировать тестировщиков.

1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам.

Удивительно абстрактно, не так ли?

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

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

Почему не установлен уровень меры в третьем законе?

Каким образом формулировка третьего закона разрешает роботу действовать даже в том случае, если он будет уничтожен?

Что должен делать робот, если Человек выглядит не как человек, или речь вообще идет не о человеке?

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

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

И программировали их не на Java.

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

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

Есть ли у кого-нибудь на примете фантастика из области роботехники, написанная программистом?

Читал ли кто-нибудь что-нибудь из фантастики про то, как роботов тестировали?

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

— Ты знаешь, что такое гамма-лучи? — резко спросил Богерт.

— Какое-то излучение, сэр?

Следующий вопрос был задан дружеским тоном, как будто между прочим:

— Ты когда-нибудь имел дело с гамма-лучами?

— Нет, сэр, — уверенно ответил робот.

— Гм… Ну так вот, гамма лучи мгновенно убьют тебя. Они уничтожат твой мозг. Ты должен это знать и помнить. Конечно, ты не хочешь быть уничтоженным.

— Естественно. — Робот, казалось, был потрясен. Потом он медленно произнес: — Но, сэр, если между мной и хозяином, которому будет грозить опасность, окажутся гамма-лучи, то как я могу спасти его? Я просто бесполезно погибну.

— Да, это верно. — Казалось, Богерт был озабочен этим. — Я могу посоветовать тебе только одно. Если ты заметишь между собой и человеком гамма-излучение, ты можешь остаться на месте.

Робот явно почувствовал облегчение.

— Спасибо, сэр. Ведь тогда нет никакого смысла…

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

— Ну, ясно, сэр. Без всякого сомнения.

— Теперь можешь идти. Человек там, за дверью, отведет тебя в кабину. Жди там.

Когда робот вышел, Богерт повернулся к Сьюзен Кэлвин:

— Ну как, Сьюзен?

— Очень хорошо, — ответила она вяло.

— А может быть, мы могли бы поймать Нестора-10, быстро задавая вопросы по физике поля?

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

Отсюда все связи со временем, опытом, интуицией, даром, инструментами и прочими атрибутами, которыми снабжены все те люди, которых можно оценить как «Отличный тестировщик!»

Меня об этом никто не спрашивает, но если спросят, то я скажу, чо…

Только что ощутил себя очень хорошим тестировщиком и очень, очень, очень плохим тест-менеджером.

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

А рабочее время уже вышло за дверь в направлении юга.

Ах, Бартоломео!

Неужели горячий (а равно и холодный) ужин мне сегодня не светит?

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

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

Например, бесперспективность своевременного ужина.

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

Более цифровых метрик для оценки крутости тестировщика тоже навалом.

Простейшая: берем небольшой документ от Джеймса Баха «Heuristic test strategy model» (http://www.satisfice.com/tools/satisfice-tsm-4p.pdf), и на второй странице всматриваемся в список техник тестирования. И оцениваем каждый из тамошних пунктиков по трехбальной шкале:

• «0», если не владеем,
• «1» если владеем в принципе,
• «2» если нас в этом считают экспертами.

Суммируем, делим на 9 (по количеству пунктов в исходном документе) и получаем собственную оценку себя как тестировщика.

Максимальная оценка — «2.0», но это вранье…

Затем можно попросить окружение оценить себя (уж они оценят более трезво и адекватно, да?!), и сравнить со своим результатом.

Ой…

Вообще, матрицы компетенций рулят, если составлены не про тебя самого тобою же самим 🙂

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

Рассуждать хочу долго и о ситах.

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

Сперва послушаем историков:

Человеческие жертвоприношения из ряда тестировщиков до и после релиза были распространённым явлением у менеджеров проектов, живших на полуострове Юкатан до нашествия конкистадоров. Тестировщиков приносили в жертву через повешение, утопление, отравление, избивание, а также посредством захоронения заживо в груде документации по проекту.

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

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

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

Итак, утопление.

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

Как все это добро достать?

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

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

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

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

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

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

Сделаем музыкальную паузу.

Прочти, раскрась, запомни:

Тестирование в Agile-way особенно сильно тем, что всё, что можно автоматизировать, автоматизируется до и во время разработки, а не отдельно от неё.

Продолжим сосать мартини и рассуждать.

Каждое «сито» в девелопменте имеет свое имя.

1. Test Driven Development — сито мелкоячеистое.
2. Acceptance Test Driven Development — сито среднеячеистое.
3. Functional Testing — сито крупноячеистое.

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

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

Рассуждать о трех ситах следует абстрактно, с точки зрения процесса, не вдаваясь в детальки.

Например, понятие сита — уже абстракция.

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

Unit testing

Внятный пример — LoveUT.

Цитата из статьи:

Тихо мурлыкая под нос, Анна продолжает кодировать свой класс.

Суть «разработки через тестирование» проста:

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

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

Особенности юнит-тестов:

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

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

Acceptance testing

Внятное описание на английском языке: wikipedia.org.

Акксептанс-тесты — второй шаг после юнит-тестов. Это уже существенный уровень абстрактности от кода.

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

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

Особенности акксептанс-тестов:

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

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

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

Для сочувствующих agile development уточняем: акксептанс-тесты проверяют юзер-сториз. А юзер-сториз — вне кода, вне технологий. Получается, что у нас есть high level tests, которые запускаются нажатиями кнопок.

Пример, пример!

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

В примере проверялась такая юзер-стори:

«User want to perform money operation from my account to another one to pay/receive money to/from another User»

посредством следующего приемочного критерия:

«After money operation one of the accounts is increased and another is decreased by the same amount of money».

Критерии акксептанс-тестов задают (а в идеальном мире — пишут) заказчики софта, а не разработчики. Например, пресловутый заказчик просит* следующего:

• в базе должны существовать аккаунты разных юзеров.
• у каждого юзера на счету есть какие-то деньги.
• после нажатия кнопки «Сделать офигенно», со счета юзера №1 на счет юзера №2 должны передаваться какие-то суммы.

* имхо, неимоверно удачно выбранный глагол.

Как выглядит такой тест, написанный в wiki-разметке в фреймворке «FitNesse»

Тесты в FitNesse читаемы и понятны

Как эта таблица выглядит в формате wiki:

Make sure that there are no accounts in the bank.

!|ensure|clean accounts|

Create two different accounts.

!|create account for user|Bob|with amount|5|

!|create account for user|John|with amount|7|

и тд

Как это выглядит после прогона теста:

FitNesse рапортует о выполнении задач партии

Как и почему это работает — не уточним, чтобы не переходить в детали и не разрушать сказки и абстракции. Но стоит сказать, что написание подобных тестов требует интеллекта и какого-то времени. Все равно, что стихи писать…

Предварительное резюме

Тестирование на уровне юнит-тестов показывает, что кусочки кода по-отдельности работают, как ожидалось.

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

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

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

Functional testing

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

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

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

Тут мы узнаем, что бывает, если муравьев в системе слишком много или слишком мало.

Это можно делать как всеми органами осязания, воззрения и осмысления, так и заранее документируя свои действия (тест-кейсы).

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

Окончательное прозрение

Если

1. проект только начинается
2. разработка ведется в стиле on-going (неизвестны ни конечный результат, ни дата полного финала)
3. код пишется «с нуля»
4. заказчик умеет работать в agile-стиле
5. разработчики умеют работать в agile-стиле
6. инженеры «болеют» тестированием
7. все три сита постоянно применяются в процессе разработки

тогда

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

Из-за денег и тщеславия.

Есть два типа тестировщиков — Хирург и Медседстра.

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

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

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

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

Проверяльщик — медсестра.

Оба они сидят в отделе с названием QA, который переводится не как «Тестирование», а как «Гарантия качества» — quality assurance.

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

Понятно, что хирургов всегда будет меньше, чем медсестер?

Понятно.

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

Все эти люди бывают профессионалами. Да, бывает хирурги-профессионалы, и бывают медсестры-профессионалы.

Аксиома: профессионал — это круто.

Откровение: медсестра-профессионал всегда будет получать меньше денег, нежели хирург-профессионал…

Удовлетворение от бытия определяется (в том числе и) количеством денег. А кто считает иначе, у того уже слишком много денег и самомнения. Или уже застарелая простата.

Не только деньги «двигают» людьми. Социальный статус тоже постоянно сует шило сами знаете куда. Круче быть хирургом, нежели медсестрой, пусть даже очень-очень профессиональной. Да и медсестра, которая очень опытная, и даже может самостоятельно резать и зашивать, непременно захочет получать больше денег. Если хирург получает 1000, то медсестра — всегда 400.

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

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

Итак, «медсестра» хочет «деньги хирурга». Как это сделать?

1. Убить хирурга
2. Стать хирургом.

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

Да, медсестра может захотеть стать хирургом. В мире IT подобные трансформации вполне допустимы, и даже закономерны.

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

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

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

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

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

Быть «обезъянкой» — не так уж и плохо, особенно если хватает бананов, и все кругом говорят, что ты — профессиональная обезъянка. Но в принципе приятного мало. Хочется много приятного.

Эволюция тестировщика

Вернемся к Дарвину и проследим эволюцию тестировщика:

1. проверяльщик-обезъянка, который не особо понимает, что и как устроено, но вполне может «проверять».
2. опытный проверяльщик-обезъянка, который уже понимает, что и как устроено, может «проверять», но не может «сотворять» проверяемые предметы.
3. опытный проверяльщик-обезъянка, который уже понимает, что и как устроено, может «проверять», может «частично сотворять» проверяемые предметы. Например, скрипты пишет. Компонует чужие скрипты. Суется к программистам с дурацкими вопросами и советами, за что бывает сильно битым и гонимым.
4. опытный проверяльщик-обезъянка, который уже понимает, что и как устроено, может «проверять», может «частично сотворять» проверяемые предметы, и может влиять на их «сотворение» другими людьми — дает советы программистам, а они его не бьют и по-всякому не обзывают. Потому что советует дельные вещи.
5. опытный проверяльщик-обезъянка, который уже понимает, что и как устроено, может «проверять», может «частично сотворять» проверяемые предметы, и может влиять на их «сотворение» другими людьми — дает советы программистам, и руководит другими проверяльщиками-обезъянками. Опа, «проверяльщик» уже становится «гарантировщиком». Потом он будет становиться все более сильным менеджером, старшей медсестрой, которая может советовать хирургу, и даже бить его по рукам…

Большинству этого хватает, потому что доходы менеджера вполне могут быть сопоставимы с доходами программистов (хотя есть и менеджеры программистов…). А некоторые тестировщики становятся программистами. Dixi.

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

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

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

Добавка

Является ли тестировщик-автоматизатор «ступенью» к программированию?

Нет. Задачи, которые решает тестировщик-программист, не сопоставимы с задачами, которые решает обычный программист ни по сути своей, ни по внешним признакам.