Но есть беда. Чтобы тесты генерировать, нужна основа — требования. Без набора требований бедняге ПИ в qase.io не от чего отталкиваться. Мдэ.

Если кто не знает, в qase.io подразумевается, что требования надо создавать и хранить в самом qase.io, там для этого есть отдельный раздел. И если им пользуются аналитики и их ручные тестировщики, то, вероятно, всё норм — требования живут вместе с тестами, видно их покрытие, видно, что откуда начинается и чем заканчивается, и сколько всего надо переписывать, если затеяли обновляться. Но если в проекте нет аналитиков? Требования же надо не просто записать, а ещё постоянно обновлять, добавлять, редактировать, комментировать. И когда весь движняк разработки полностью находится в Jira/Слак, то кто будет вообще возиться с требованиями на отдельном ресурсе? Всегда проще требования (если есть) запихнуть, кагбэ, в Jira…

Вообще, у qase.io есть интеграция в Jira, но с ней, кхм, сложно, постоянно чувствуется, что это два отдельных ресурса. Чем-то это всё напоминает древний Zephyr на дьявольском flash — есть взаимное линкование между тестами отсюда с задачами в Jira, но и только, в глаза это всё не бросается. Решение у древнего Zephyr в конце-концов нашлось естественное адекватное — древний Zephyr был взят и убит, вместо него появился плагин, встроенный в Jira, который и наследует у Jira интерфейс, и сущности типа тест-кейсы подтягивает под рабочую задачу (как и полагается), где они явно заметны… testomat.io тоже по этому пути пошел, Xray пошел… Кто вообще отныне пойдёт НЕ через встроенную интеграцию с Jira? Только смелый qase.io, что гордо реет между молний над ревущим гневно морем и кричит в рожок победы: «Генерируйте тест-кейсы, тестировщиков — поменьше, вам же лучше будет сразу!»

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

А вот что в глаза бросилось — предупреждение о том, что

using Qase’s AI Test Case Generator will not result in your data being used to train the language model. This Beta version uses the ChatGPT API Platform for test case generation. OpenAI explicitly states that «We do not train on your business data».

Да, да, разумеется, да! ChatGPT именно так и работает — всё читает, всё генерирует и сразу всё забывает, он же учится с вами взаимодействовать НЕ на взаимодействии с вами! Быгыгы.

С другой стороны, а какие есть варианты? В тест-кейсах всегда есть sensitive data, и если ты уже выбрал сторонний сервис для управления ими, то нехай уже это всё читает ChatGPT, крестик уже снят. Вот только ему нужны требования…

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

Обложка книги «Тестирование черного ящика»

В начале декабря 2015-го я неосторожно пообещал Никите Макарову (папа автоматизации тестирования в «Одноклассниках») объяснить, почему книга Бориса Бейзера — это про тестирование, но не для тестировщиков, а для программистов, поэтому и читать ее надо не так, как Канера.

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

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

Мои там тоже остались 🙁

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

Перевод там гнилой, что ли?

Ну…

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

Будете перечитывать?

И да, оригинал «бейзера» читается намного проще и внятнее. Но где ж его взять?

Однако проблема не в качестве перевода. Почти те же глюки посещают тестировщиков и после чтения Пауля Йоргенсена (тоже очень крут, но у нас незаслуженно непопулярен) или Гленфорда Майерса (у нас на слуху, но кто ж дочитал все те листинги, которые он там понаписывал?).

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

Вкратце:

они учат тестированию программистов,

а не тестировщиков.

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

Бейзер читал лекции для будущих инженеров, которые получали наивысочайшее образование по университетской программе в области компьютерных наук или программной инженерии (Дональд Кнут и вся его серия книг «Искусство программирования» вам примером). А упомянутое высочайшее образование нет смысла покупать ранее, нежели успешно освоены минимум два года среднего специального образования в области компьютерных наук, или же полный курс обучения по направлению «Программное обеспечение» в системе военного образования США.

Домашнее упражнение:

1. Оценить этот минимальный уровень врубания в тему.
2. Посмотреться в зеркало.
3. …

И Бейзер

на протяжении десяти лет провел свыше 200 технических семинаров для тысяч тестировщиков,

и Майерс

…served as a lecturer in computer science at the Polytechnic Institute of New York University, where he taught graduate-level courses in computer science,

и Йоргенсен

…since 1986, he has been teaching graduate courses in software engineering, actually in Grand Valley State University, Michigan

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

То есть, не для меня Дон разольется.

Все аналогичные авторы рассматривают тестирование как некую логическую дисциплину, которая направлена на ПРЕДУПРЕЖДЕНИЕ появления багов в ПО. То есть, ДО ТОГО, как пишется код.

Собственно, классическая Analytic school всего нашего тестирования ПО.

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

1. Открыть браузер,
2. открыть сайт,
3. кликнуть по полю Login,
4. на серьезных щщах ввести в поле ‘Login’ всякую туфту
5. и убедиться в том, что залогиниться невозможно…

Это «предупреждение» всегда делается задолго до того, как программа написана;

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

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

это делается посредством разбиения всех входных данных на классы эквивалентности для каждого модуля по-отдельности, а затем и по-цепочке (получается очень смутная и объемная шняга);

это делается посредством расписывания причинно-следственных диаграмм («Мне трудно объяснить логические модели без привлечения булевой алгебры, а ее нет смысла учить, если вы не владеете диаграммами Карно-Вейча» © Борис Бейзер);

это делается тогда, когда от вероятных ошибок в ПО мир рухнет в Тартарары и еще дальше, буквально в лапы Скараоцки.

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

Про молдавские болота: долго объяснять, справок на всех вас не хватит…

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

И звучит всё это круто…

Однако, Петька,

есть

один

нюанс… ©

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

Увы.

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

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

Кстати… Буквально недавно на собеседовании спросил «Про пестицид эффекта», и получил обстоятельный, классический ответ.

Ну, кагбэ… Одно из главнейших качеств тестировщика — внимательность к деталям, не так ли?

Я и уточняю у бро, мол, «А ничего, что я спросил про ‘пестицид эффекта’, а не про ‘эффект пестицида’?«

Засмущалси бро, покраснел слегка /от ненависти ко мне/, а мне чо, я ж тестировщик, я привычный.

С другой стороны — ну, позитивный джун… Ну, будет писать позитивные баг-репорты…

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

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

Усредненный выпускник подобной системы образования, для которой работают Бейзер, Майерс и Йоргенсен, страдает всеми теми качествами, которые отличают владельцев высшего образования от простых парней «от сохи». Подобный студент умеет правильно оттарабанить определения терминов и умеет выполнять именно те алгоритмические расчеты, которым его обучили, не более. Феномен известный, Ричард Фейнман об этом уже смачно распространялся:

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

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

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

После лекции я спросил одного студента:

— А какой будет экзамен?

— Очень простой. Я могу Вам прямо сейчас назвать один из вопросов, — он заглянул в тетрадь и сказал: «В каком случае два тела считаются эквивалентными?». А ответ: «Два тела считаются эквивалентными, если равные вращательные моменты производят равные ускорения».

Так что, как видите, они могли сдавать экзамены, и «учить» все это, и не знать абсолютно ничего, кроме того, что они вызубрили.

Императивы учебной программы ISTQB весьма близки к этому способу мышления, но скомпоновано всё чуууууточку проще, поэтому и подходит для многих, а не только для выпускников курса «Программное обеспечение» в системе военного образования США 🙂 Но результативность…

У меня сейчас на учебной сковородке прожаривается очередной обладатель сертификата ISTQB, который с нуля учится тому, что такое тест-кейсы и как их надо придумывать. Ну не поубивав бы?!

И опять же репрезентативное для большинства осертификаченных: «У нас на проекте все это применять не приходится«. Ещё бы… Для занятия тест-дизайном знания и умения нужны, а не сертификаты.

Почему все так неоднозначно и криво?

Ну… потому, что ТАК МОЖНО.

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

Но миру не нужно, чтобы всё ПО было высокого качества. Миру нужно, чтобы ПО просто работало.

Поэтому можно выпускать некачественный софт — и он работает.

Просто иногда его надо постоянно обновлять. Блеать!

И поэтому МОЖНО знать, как надо тестировать, но нифига не уметь тестировать.

И также поэтому МОЖНО тестировать, не особо понимая, что именно перед тобой открыто: «браузер» или «фаерфокс»; и откуда открывается интернет-магазин, с «сайта» или с «сервера»; и технику разбиения чего-либо на классы эквивалентности объясняют/воспринимают на примере дурацких карандашей, и тем не менее, компьютеры работают, сайты открываются, цивилизация продолжается. То есть, не всё так страшно.

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

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

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

Или более приземленное: https://www.google.com.ua/advanced_search протестируйте, используя только классы эквивалентности карандашиков и вписывание лютой туфты в поля ввода…

Или, раз уж речь зашла, подумайте, как иначе, если не «по-академически основательно», можно спроектировать и протестировать инфраструктуру, на которой когда-то зижделись «Одноклассники» (она однажды ПОЛНОСТЬЮ «сыпанулась» из-за одного бага, который в принципе присутствует у всех и никому не мешает уже сто лет в обед):

…нужно было оживить около 5 000 машин. Перезагрузить их удалённо и загрузить по сети было нельзя, поскольку многие просто не были для этого сконфигурированы. Это было следствием выбранного когда-то подхода к созданию инфраструктуры. Ведь Одноклассники не развёртывали на пустом месте единовременно несколько тысяч серверов — парк постепенно разрастался в течение нескольких лет. Поэтому пришлось вручную перезагружать тысячи серверов и разрешать в BIOS управление по сети для автоматизации восстановления.

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

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

Читать Бейзера можно/надо будет когда-нибудь потом, когда/если тестировщик дорастёт до понимания сути тест-дизайна. Все те вещи, о которых говорит великий старик, можно изложить и более простым языком, более простыми образами, и когда начинаешь их понимать — о, Бейзер очень крут для постижения тест-дизайна!

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

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

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

\ToDo{Прекратить руководствоваться логичным, но до невозможного дурацким соображением о том, что «Но ведь если тестировщик научится программировать, то он станет программистом!!!«. Не станет. Знание английского языка не делает вас англичанином, но помогает более тонко и всеобъемлюще понимать мир и других людей}.

Next step: «Они учат тестировщиков программировать«

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

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

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

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

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

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

Эпик фэйл.

Аустерлиц.

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

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

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

Но!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ:

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

Агррррх!

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

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

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

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

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

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

Впустую.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Luxoft?

GlobalLogic?

Epam?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О как просто!

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

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

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

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

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

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

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

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

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

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