Пример подобного слайда (элементарно нагуглено)

Да, говорят вам. Понятно, чоуж.

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

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

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

Да, говорят вам. Продолжайте, всё понятно. Восемь тысяч, вы сказали?

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

Да, говорят вам. Обязательно научите!

На слайде появляется текст «Domain testing is one of the most widely practiced software testing techniques. It is a method of selecting a small number of test cases from a nearly infinite group of candidate test cases. Domain knowledge plays a very critical role while testing domain-specific work» — ну да, на английском, бо в русской википедии про это же ничего не написано. Зачитывать это вслух вы стесняетесь, бо произношение у вас не то, поэтому вы переводите всё на лету — доменное тестирование это один из самых крутых методов техник тестирования, это метод выбора небольшого количества тест-кейсов из группы кандидатов тест-кейсов (мелькает вопрос «Ой, что я несу в массы?!» — но у вас нет времени ответить себе на этот вопрос, ведь урок продолжается), и… и, короче, это всё очень важно при тестировании доменно-специфичного ПО. Ну, вы там просто используете тестирование классов эквивалентности методом граничного значения, и когда это вместе, то получается доменное тестирование. Всё ли понятно?

Ещё бы, слышите вы. Доменная печь, доменный метод, доменный дом. Всё ясно, это всё очень важно для нас. Продолжайте.

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

Вы вспоминаете про «Ото я подумав, а що якщо замінити ІТ скажімо на музику», но на ваших слайдах написано про другое. И вы продолжаете.

Продолжаете точно так, как вас учили в школе — а там вас учили способом «Объявление». Вам просто объявляют о существовании чего-то (про domain testing, например), и предлагают запомнить определение.

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

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

Вы не идиот. Вы нормальный человек, вас наделили полномочиями инфицировать практичными, лишёнными воды знаниями (белиберда-белибердень) всех интересующихся практичными, лишёнными воды знаниями. Вы честно работаете, стараясь всех научить. Вы веселите зал и приковываете их внимание, а потом заявляете о том, что подписаться на курс Full HD со скидкой можно только сегодня, здеся и сейчаса, если подписать контракты на обучение прямо сегодня, только сегодня, сегодня-сегодня! И вы дарите всем присутствующим возможность оплачивать контракт частями — в зале начинается движуха, к вам целенаправленно идут целенаправленные девушки, которые готовы отдать вам 14 000 або 16 000 гривен здесь и сейчас, или потом, но уже частями. Вы призываете всех поверить вам, ведь вы уже столько лет работаете на работе и занимаетесь профессиональным обучением.

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

Единственным адекватным способом обучения чему-либо является способ, который можно назвать «Через объяснение», и вам даже можно объяснить, в чём разница, но вы ничего не поменяете. Это же долго, это же работает только личностно (Группа отпадает?! Но ведь я учу только группами!), это же требует понимания того, как работает когнитивный аппарат психики человеческой, это же требует терпения. Этого же у нас никто не требует! Вы искренне не понимаете, почему мне не нравится ваш обычный, стандартный, всем подходящий формат учёбы «Через объявление».

А Заратустра, как известно, не позволяет.

Мудаки, блеать.

De parabel der blinden

Бен Коллинс — Водить как Стиг

В поезде лежал, книгу читал «Водить как Стиг» Бена Коллинса (второе издание, Альпина нон-фикшн, Москва, 2018).

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

А вот на стр. 155 разверзлись хляби подземельные, и стало ыыыы:

Санитарная проверка

Вах-вах-вах, не может же быть же…

Поискал оригинал… Оказывается, может.

Sanity check

Короче, нет никакого санитарного тестирования.

Само слово Sanity переводится на русский язык проще:

• вменяемость,
• здравомыслие,
• нормальная психика.

Нет там никаких санитаров.

То, что вы называете Sanity, по-сути есть Smoke testing.

Я ещё не знаю, когда эти термины появились, но уже давно ясно, что это два разных названия одного и того же феномена. Просто тестировщики называют это Smoke, а программисты называют это Sanity. Так они привыкли, так оно укрепилось в их литературе.

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

Канер в своей книге Testing Computer Software (1988, у меня второе издание, 1999-го) не упоминает ни про smoke, ни про sanity. Самое близкое к ним есть в главе 3 ‘Test types & Software development‘ на стр. 51, и ВНЕЗАПНО оно там называется «Acceptance testing»:

Each time you receive a new version of the program, check whether it’s stable enough to be tested. If it crashes at the slightest provocation, don’t waste your time on it. This first bit of testing is called acceptance or qualification testing.

На стр. 54 та же тема с уточнениями в разделе ‘Final acceptance testing and certification‘:

If your company developed the program on contract, the customer will ran an acceptance test when you deliver it. In small projects, this test may be informal. For most projects, however, test details are agreed to in advance, in writing. Make sure the program passes the test before trying to deliver it to the customer. An acceptance test usually lasts less than a day. It is not a thorough system test. Beizer (1984) describes the preparation and execution of formal customer acceptance tests. Perry (1986) is, in effect, a customer’s guide to creating acceptance tests. Consider using Perry (1986) to structure your negotiations with the customer when you jointly design the acceptance test.

Цитата на books.google.com

Для тех, кто не может прочитать больше одного предложения в абзаце перевожу:

заранее и письменно согласуйте с заказчиком набор приёмочных тестов. Убедитесь сами в том, что релиз на них не завалится. Ранее об этом писали Бейзер (1984) и Перри (1986).

Это воспринимается странно, бо в наше время «Acceptance testing» объясняется как «Заказчик сам тестирует, как хочет». И да, вероятно, он будет основываться на наших смоук-тестах. Предполагаю, что в наше время этот термин просто истолковывается неверно, но это уже не существенно.

А вот в 2001-ом Канер уже упоминает Smoke testing в «Lessons Learned in Software Testing: A Context-Driven Approach» на страницах xxvi (это предисловие, там сходу заявлены определения ключевых терминов), 41, 121, 162, 163, 169, 141 и 144. И ни разу не упоминается sanity testing.

Рекс Блэк в «Ключевые процессы тестирования» (2004) упоминает эти два термина одновременно. В русскоязычном издании «Лори» 2006-го года они на стр. 532:

Приемочное тестирование, тестирование на исправность (Smoke Test, Sanity Test). Тестирование, проверяющее, насколько стабильная предлагаемая на тестирование версия, чтобы можно было начинать штатное тестирование. Обычно это подмножество всего комплекта тестов, как правило, автоматизированное, затрагивающее все части системы, по крайней мере, поверхностно. Качественные приемочные тесты обычно довольно долго проверяют работу системы, чтобы проявились серьезные проблемы надежности и работоспособности. Термин “smoke test” (тест на задымленность) взят из электротехники: когда инженер включает цепь, первичный тест проверяет, не дымятся ли компоненты.

Википедия

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

In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected. This is often prior to a more exhaustive round of testing.

Огромное, гигантское отличие от smoke test, да?!

ISTQB (скачать файл Glossary all terms 3.1.pdf).

Sanity test объявлен синонимом smoke test (стр. 61).

В канонах ISTQB вы не сомневаетесь, не так ли?!

Толковалка ISTQB

It is a kind of software testing which is done by the testers to ensure that the functionality is working as expected.

Огромная разница со smoke test, да?!

Кто-то сделал почти тот же обзор книг в поисках тех же терминов, что и я: almeln.github.io, и пришел к тем же выводам.

О переводах: «Да, но ведь гугл переводит это слово именно так!»

Google переводит слово Sanity

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

И напоследок. Я предполагал, что ебалайтунг с терминологией присущ нашему, русскоязычному сектору. Например, вон чего на protesting.ru пишут:

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

Но он процветает и на английской стороне. Быстро нагуглилась статья на эту тему с сайта h2kinfosys.com — оба термина представлены как нечто обособленное. Понятия не имею, что это за контора из штата Джорджия (США), но о себе они говорят «H2k Infosys provides world class IT Training, Real-time Live Project to gain hands on experience, and IT Staffing services».

Надо ли возражать людям вообще?

Упоминается Роман Савин, бо совместно листали его замечательную книгу «Тестирование дот ком» в попытке узнать, что такое тест-дизайн, и не нашли 🙁

Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системы — Действие — иное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «Действие — Результат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the Cart — Proceed to Checkout — Checkout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

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

Что надо сделать

1. определить happy path — их может быть несколько.
2. определить другие сценарии и ветвления к ним.
3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.

А загляните в череп опытного заказчика ПО — он требования прописывает сам. Всегда. Да, общепонятно, что через требования он хочет получить хотя бы именно, что было заказано, но засада не в том, что «без ТЗ результат ХЗ» (можно ваять ПО и без предварительного малевания ТЗ). Проблема в коммуникациях. Чем более опытным становится заказчик, тем сильнее он эту проблему осознает и начинает решать.

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

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

Я знал его, Горацио.

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

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

Как-то в самой крутейшей в Кишиневе студии «Сделаем сайт-визитку для вашего бизнеса, ня!» появился действительно ОПЫТНЫЙ заказчик. Как зашла она в нашу контору, так попросила не чаю, а показать ей того человека, который будет делать ей будущий сайт. ОДНОГО человека, с которым «потом будем разговаривать».

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

Кто за всё отвечает? Директор фирмы? Да, но он ничего не программирует. Программист? Да, но без дизайна он ничего не обещает. Дизайнер? Да, но без внятного ТЗ он не понимает, чего от него хотят, и сам сайт он делать не будет, он только картинку нарисует. Руководитель разработки? Кагбэ, да, но он руками в проекте ничего делать и рисовать не будет, поэтому «делать будем все сразу»… Так с кем вы хотите поговорить?

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

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

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

А программисты (оба), глянув на сроки и приблизительное ТЗ, сказали «Однозначно хз…». Бо дизайна нет, и какие ограничения по верстке? На каких мониторах, например? У нас в наличии только 1024х768. И в каких браузерах? И что за, прости господи, идея у сайта такая дебильная? Они что, потом начнут делать из него «всеобщую базу данных о недвижимости по стране»? Быгыгы… На каком движке? Быгыгы… Но отказываться нельзя.

Множество уровней принятия решений. Искажения информации — буквально на каждом уровне. Как это надо делать — у каждого своё мнение. Надо ли объяснять клиенту, что «Мы тут подумали, и считаем, что ваш проект…»?

Что в этой ситуации может делать клиент? Ничего. Ждать, когда ему «всё сделают».

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

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

И началось…

«Ну, объявление добавить в базу можно, а почему шрифт такой некрасивый? Вы что, не умеете сделать нормальный шрифт? А почему, когда мы смотрим наш сайт на мониторе в 22 дюйма, снизу выползает оранжевая полоса…» Боже, да где вы такой монитор нашли? «А у нас друг в Израиле, он посмотрел, и сказал, что дизайн вообще ни к черту…» В ТЗ было указано, что максимально разрешение экрана… «Зачем вы мне говорите про эти разрешения? Я же вас о другом спрашиваю!»

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

Наконец, в офис пришел не заказчик, а настоящий ”product owner”, серьезный и злой дядька, который встал за спинами программистов, посмотрел в их мониторы, и начал сильно тыкать им в плечи, приказывая «Давай быстро сделай сайт нормально, нах! Ну!?»

Нет, это были не девяностые. Какие могли быть сайты в девяностых?

Итого: проект с радостью передали другой студии «Сделаем сайт-визитку для вашего бизнеса, ня!», и чем оно там закончилось…

Всё, что заказчик может сделать «на входе» — самостоятельно расписать ТЗ, бо работу будут делать вообще неведомые ему люди, с которыми всё не обсудить. Да и если со всем перезнакомиться — менеджеры разработки (и особенно рекламные менеджеры, которые проекты инициируют) весьма нередко меняются прям на ходу проекта… Всякое бывает. Пусть мы будем считать их неучами. Пусть делают строго по ТЗ.

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

Всё, что заказчик может сделать «по-итогу» — тестировать, тестировать, тестировать. Самостоятельно.

Задача тестировщика в начале проекта — понимать, что случится с психикой заказчика, когда упадет занавес. И начинать готовить финальное тестирование.

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

Без доступа к телу заказчика, конечно, натестируешь всякого… Например, программисты намутили возможность оплаты через очередной пэй-пал, и много всяких сложностей в процессе сего порешали, а тестировщики об этом вообще хз, и тестируют оформление «страницы товара», находя там баг на баге в верстке, и совсем чуть-чуть в функционале «Send to a friend»… Ну как тут не пожелать бить морды на комплексе?

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

Третья задача тестировщика — взрослеть и перестать тупить над тест-кейсами. Бо успешность ПО не в строгом соответствии ТЗ.

PS Не будем ковырять разницу между «требованиями» и «ТЗ». Не в терминах собака зарыта.

Научим всякой туфте, вроде Smoke Testing, Regression Testing, Decision Table Testing, Pairwise Testing, даже State-Transition Testing, или даже, святая святых, не каждому дано — Domain Analysis Testing… Это интересно? Это поможет найти работу?

Начинающему достаточно только рассказать про Equivalence Class Testing + Boundary Value Testing, показать форму заполнения тест-кейсов и отчетах о дефектах, и пнуть под зад, бо всё, «You’re in da Army now, stand up and fight», дальше — сам.

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

Почему недостаточно только рассказывать про Equivalence Class Testing + Boundary Value Testing?

Ну, поначалу всё ок, пока дело не дойдёт до какой-нибудь сложной формы наподобие google.com/advanced_search, и тогда «Баста, карапузики, кончилися танцы!»…

И ладно, если на наших глазах облажается джуниор (мы же тут любому джуниору ногу отгрызём, буде таковой рыпнется, ага?!). У джуниора есть время на то, чтобы осознать ошибки молодости и переучиться, и доучиться, или жениться и перестать отличать тестирование от программирования, равно как и утро от вечера.

А если это взрослый человек?

А если взрослый, то надо формулировать задачу правильно. И грамотно оценивать возможности реализации.

Как вы яхту назовете, так она и поплывёт

Ведь можно было бы сформулировать тот же запрос более откровенно: «Чему нужно научиться, чтобы найти работу в тестировании и зарабатывать там много денег?» Ну, что мешает?

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

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

Джуниор в любой отрасли == «На старте будет мало денег в принципе, но, вероятно, ПОТОМ денег будет много».

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

Снимать жилье на зарплату джуниора в Киеве априори невозможно.

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

Капля никотина ковбоя не убивает. Не лошадь же…

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

Или наоборот, я уже курю «Мальборо», следовательно, я уже — почти ковбой. Где моя лошадка, где мои коровки, где моё лассо, где моя Горбатая гора?! Сплошные иллюзии.

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

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

Особенно если семья не поддерживает.

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

Бо важнее понимать окружение (environment), нежели запоминать вид и расположение иконок в приложениях, и только догадываться о том, как и почему оно работает.

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

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

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

У меня этот переход был очень болезненным, но я к нему был готов. У кого-то это вообще не получается. И это нормально.

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

Вот и вся ситуация, если говорить грубо и без вежливых экивоков.

И вот что… Сегодня тестирование/программирование рулит, бо в кризисе айтишные конторы оказались на коне, всё такое.

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

Вы в курсе, что в семидесятых годах ХХ века в том же СССР было полно программистов? Кто тогда хотел ходить в очках, с бородой, в белом халате, в НИИ чего-то там?

Завтра тестирование перестанет рулить, завтра и кризис закончится. Все к этому готовы?

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

Некоторые — от голода и упрямства.

И когда тестировщиков наконец-то станет МНОГО, и даже больше необходимого, их стоимость начнет падать просто потому, что их будет много, и уже будет не до жиру.

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

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

Это прекрасная тема для обсуждений и трепа на ДОУ в любом приличном обществе. Каждому понятны плюсы и профиты подобного ревью.

Ведь правда же?

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

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

Например, небывалые сложности вызывает вопрос «Какие свои навыки в тестировании ты именно планируешь развивать на протяжении следующих шести месяцев?»

Сложно, да?

Попробуем по-другому: «Чего ты вообще хочешь? Кем ты хочешь стать?»

Ыыыыыы… 😉

Нередкий ответ: «Ну, я хочу прочитать книгу про нагрузочное тестирование…»

— А нафига оно тебе?

«Нуууу, я хочу стать более профессиональным тестировщиком, чем сейчас…»

— А в функциональном тестировании ты уже все Джомолунгмы покорил? И как часто ты будешь заниматься нагрузочным тестированием на своем проекте? Оно у вас вообще применяется?

«Нет, не применяется, но…»

Ладно.

Есть отличный рецепт.

Ложись на кушетку, один час стоит $300, приступаем.

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

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

300 гривен?

Гуд.

Отложи 10% (от щедрот наших оставим тебе немного на такси).

Что ты хотел написать в своем плане? «Прочитать книгу про нагрузочное тестирование».

Гуд.

За твои 270 гривен я выполню любую задачу из твоего перформанс плана.

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

Было написано «прочитать книгу про нагрузочное тестирование…» Отлично — вот, я ее прочитал. Условие выполнено. Давай 270 гривен из твоего личного правого кармана.

Прозреваем?

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

Следует же записать явную задачу: «хочу сделать нагрузочное тестирование нашего проекта; для этого мне надо научиться делать нагрузочное тестирование; для этого я прочитаю такую-то книгу (к такому-то сроку)».

А для этого надо понять, чего ты в действительности хочешь…

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

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

Профит понятен?

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

«А почему тогда некоторые компании развивают?»

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

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

Понятно?

Гуд.

Очистить кушетку, пригласить следующего.

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

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

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

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

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

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

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

Рассказываю

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Неужели?!

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

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

И умею.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Между прочим

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

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

Эта статья NOT депрессивная, кхе-кхе!

Анадысь случилась со мной странность.

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

Чаще интересуются, как стать тестировщиком. Чему учиться, где учиться, как учиться… Где лежит легкий путь к тому, чтобы стать программистом, например 🙂

Мне очень интересно общаться в таком стиле. Ментор я, гыгы.

Но одно из обращений недавно закончилось моим провалом в роли ментора.

Эпик фэйл.

Аустерлиц.

Линия Мажино.

Один парень (дефолтный сити) решил оценить свои способности к тестированию посредством тестирования программы «ListBoxer». Меня он попросил проверить его результаты по найденным ошибкам в том приложении.

Правильный настрой. Правильное стремление.

Но!

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

Это очень, очень плохой старт.

Да, в этой аппликухе есть много багов.

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

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

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

А самостоятельная работа с листбоксером молодому тестировщику только навредит.

Никто не начинает играть на гитаре с попытки выдать коронное арпеджио Ингви Мальмстина. Начинать надо с «Маааалааалетние шалавы», или с «Я сижу в одиночке, мама», или с «Из-за леса выезжает конная милиция», или с «Рэйп мииииии, энд нафынг элс мэттерс», или с «Группа крови на рукаве» — по вкусу и по интересам.

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

Игра должна доставлять удовольствие.

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

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

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

Проблемы следующие:

1. Понту мне знать, сколько багов ты в нем найдешь? Одно только количество багов не говорит о крутости, внимательности или предрасположенности к тестированию.
2. Сообщение о том, что «я тестировал программу ListBoxer» окружающим тестировщикам и работодателям не говорит ни о чем существенном. Да, тестировал. И что?
3. Сообщение о том, что «я тестировал программу ListBoxer и нашел 40 ошибок» не говорит ни о чем существенном. Да, тестировал. Нашел 40 ошибок. И что? Сколько их там всего? Насколько важными были найденные ошибки? А требования откуда взял?

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

Ответ:

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

Агррррх!

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

А тестирование не начинать с «у меня есть только 60 минут, аааааа, я тупой и не успеваю!», а с анализа…

У программистов (программеров, если угодно) совсем не тот подход к тестированию, на который следует ориентироваться.

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

А это плохой старт.

Агррррх! Агррррх! Агррррх! Агррррх! Агррррх! Агррррх! Агррррх!

Впустую.

Брат-программист всегда круче молдаванского тестировщика:

Ошибок за 1 час нашел мало 🙁 Стыдно показывать.

Агррблиаррх!

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

Теперь вопрос — а как научиться тестировать?

Ходить на курсы

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

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

И курсы про введение в тестирование Натальи Руколь (тоже плохому не научит) требуют какой-никакой подготовки в теме.

Разве что люксофтовский тренинг «Тестирование — как и с чего начать» кажется интересным в нашем случае, но у Люксофта такие цены, тааакие цены…

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

К слову, от разъяснений того, «что такое тестирование», Александров очень грамотно и дальновидно не отнекивается:

Напрашиваться на работу куда угодно и учиться «на ходу»

Это почти что мой вариант, но то, как учили меня — это слишком по-джедайски.

В частности, мне предложили тестировать систему, которая еще не существует.

Я думал, что попал в логово неадеквата.

Я думал, что надо бежать.

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

Я думал, что буду бить по мордасам.

Я был совершенно не готов к подобным предложениям.

Но от злости и/или страха, в общем, сосредоточился и справился. Не сразу, но справился.

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

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

В общем, учиться на работе можно только при наличии мощной мотивации.

Бо на самой работе учиться не придется. На работе надо будет работать.

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

Выучиться в учебном центре любой крупной компании

Ну, кто там у нас крупный?

Luxoft?

GlobalLogic?

Epam?

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

И на курсах компании GlobalLogic будут учить (прививать) внутренней политике компании. А она может отличаться от внутренней политики Epam или любой другой. В частности, там учат работать в БОЛЬШИХ компаниях. Понимаете же, что в мире существуют не только БОЛЬШИЕ компании? В маленьких компаниях тестирование тоже есть, но оно слегка другое 🙂

И иногда эти курсы очень платные.

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

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

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

Типа, тестировать ВООБЩЕ ученик будет учиться сам…

И поскольку тестирование все ещё находится в состоянии развития, почти все УЦ учат по собственным учебникам. И акценты в учебниках расставляются по-разному, в зависимости от их авторов и их направленности.

Учиться по блогам

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

Подробно я разорялся об этом в записи «Трудности исследовательского тестирования»

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

Пообщаться с уже взрослыми тестировщиками

Способ самый грамотный.

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

О как просто!

Не читать книги и статьи о вождении танков, а пообщаться. Это и быстрее и проще.

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

И самое простое и эффективное — водитель танков быстро поймет, предрасположен ли ты к такой работе. Как он это сделает — неважно, но он это сделает обязательно. Из интереса.

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

Или наоборот — презреть рекомендации и стать самым крутым водителем танков в мире, и пусть эти уроды утрутся слезами 🙂

А где их взять, тестировщиков-то?

• В своем ближайшем окружении.
  • Покрутить головой. Кто там у нас самый симпатичный и адекватный тестировщик? Пригласить его в обеденный перерыв на три вопроса.
• В рунете.
  • Крутить яндексы и писать письма.
• В интернете.
  • Крутить гуглы с переводчиками, и писать письма всем сразу. Тот же Джеймс Бах часто и легко общается по скайпу с тестировщиками со всего мира.

Да, и если кто-нибудь из матерых посоветует для начала протестировать за час листбоксер… ну, вас мягко послали нафиг. Это бывает. В ответ надо не тестировать листбоксер, а искать новых тестировщиков.

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

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