Предисловие
Всем привет. Мне немного за 30 и я предпрениматель. С большим опытом, но не в нужной сфере. Долго ли коротко ли, решил войти в IT. Хотел с embedded зайти, но раствору не подвезли, так что, крепко обдумав, что есть, чего нет и прочие pro и contra... "чому бы нет", пойду в QA. На хабре частенько дальше первой статьи ничего не заходит. Как и в жизни. Так что любые реакции и комменты мотивируют меня писать дальше. Добро пожаловать.
Пролог. Как я познакомился с Отусом.
Когда-то, ещё робко вползая в embedded, и пытаясь оживить связку ESP32+EspressifIDF+C, я что-то там пытался найти. И наткнулся на Сергея Кольцова. А, вспомнил! C-Make это был.
И я даже что-то понял. Понял мало (ибо неуч), но подача материала понравилась. И это было бесплатное занятие с, собственно, Отуса. Я тогда пытался меню на ESP32 состряпать. Ох как наивны были мои мечты. Потом я открыл STM32 и весь их environment. Ну и плавно пришел к таким вещам как С++ и FreeRTOS. Ну и, конечно же, застрял.
- Как понять когда нужно писать класс, стихи и статьи на хабре, а когда - нет.
- Если можете не писать, не пишите.
Я долго облизывался на базовый курс отуса по С++. Потому что в преподах был, так понравившийся мне, Сергей Кольцов. Но курст стоил 7000. Не сумасшедние деньги, но просто так не валяются.И тут о чудо. Распродажа базовых курсов по 10р. Прям десять рублей. Чё я тогда не скупил все что можно было скупить я не знаю. Купил, начал смотреть... Короче разочаровался я в Отусе. Если первая часть, про функции, которую я и так уже освоил, и которую, читал как раз Сергей, это интересно и прикольно, с примерами из жизни, то вторая (собссно классы полиморфизм и прочее) - это выразительное чтение на камеру.
Давайте напишем класс Class. Отстой. Прям даже бесплатно не хочется время терять тык тык и тык.
Всё это к чему.
В айти я вхожу не с нуля, а с некоторым багажом знаний и умений.
У меня есть немалый опыт предпренимательства
И огромный опыт работы с техникой.
На отусе попадаются как весьма интересные преподы, так и не преподы вовсе.
"Быть спецом и быть преподавателем по специальности - разные вещи."
Цзао Лы
Короче, нужно всегда помнить, что тупой человек может сидеть по обе стороны учебной парты. И всякие эти ваши объективные суждения... ну такое.
Долго присматривался, смотрел отзывы, читал статьи тут на хабре, не буду тыкать пальцем...
Отус победил и я купил курс “в рассрочку” с отсрочкой первого платежа. Ну в смысле, это оказало на влияние на мой выбор. Курс стоит чуть больше 40т.р. и идет 4 месяца. То есть, условно, можно расписать его по 10к в месяц. Напоминаю, на дворе май 2022.
Ключевое слово - торопиться
Ну и вот я, такой воодушевленный, начал врываться в IT. А вот стоило бы сначала осмотреться. С другой стороны, излишняя осмотрительность может привести к долгому ящику. Так что имеем что имеем и делимся опытом, дабы следующий за мной на мои грабли не наступал.
Чего я ожидал (да и ожидаю) от курса. Что по окончании, я могу смело идти на вакансию джуна. Как сварщик 3-го разряда после ПТУ. Много не заработаешь да и далеко не везде возьмут. Но где-от там нужны джуны. Если у тебя есть четкий минимум, милости просим, добро пожаловать.
Вот тут надо остановиться и трезво оценить что нам предлагают.
За 40 тысяч. За 4 месяца. Нам предлагают. QA engineer Basic.
40 тысяч - это очень дешево. 4 месяца - очень мало. Для engineer. Вот для QA basic - в самый раз. А для инженера маловато.
А ещё есть проблема советского маркетинга. Бессмысленного и беспощадного: ОБЪЁЁЁЁМ. Нам надо сдать отчеты, надо больше обученных людей, чтобы больше людей купили курс!Мы пихаем в курс всех и вся. С любым опытом. И без опыта тоже пихаем.
Вместо того, чтобы разделить аудиторию на целевые группы. И дать каждой группе то, чего она хочет.
Вот школа чтобы не объяснять что такое сайт и как шарить гуглдоки. Школа - бесплатно. Вот базовый курс, он дешевый но даст тебе всё что нужно для дальнейшего движения. Вот тест, чтобы ты мог понять свой уровень. Хочешь помощь - плати. Вот QA engineer. А в итоге в потоке все. И нулёвые и продвинутые, и половина из них уйдет забрав остатки денег, или бросит. Самое интересное, что и базовый курс и тест у Отуса есть.
Знаете чем крута западная система образования? Тем что колледж - это круто. У нас, если у тебя не высшее, ты - не человек. А раз есть такой спрос на высшее, то давайте им торговать. В итоге высшее образование у нас скомпрометировано до состояния: "умеет писать без ошибок, читать инструкции, можно оставить без присмотра примерно на пол дня".
Так вот. Инженер - это круто. Я, проработал с железом больше 10 лет, починил тысячи узлов и конструкций, разработал и создал не один десяткок приблуд и устройств, что-то даже пошло в серию. Я умею пользоваться Inventor и Fusion360. И я - не инженер. Я - хороший специалист. Да, я гораздо лучший специалист, чем многие. Но я не смогу даже "балку на прогиб посчитать". Воспользоваться инструментом по расчету смогу. А с ручкой листком да в чистом поле - нет. Так вот специалист - это тоже круто. И на специалистах держится любая отрасль. И помочь человеку определиться, какой уровень и в какой сфере уму нужен. Помочь понять, что ему не нужно гнаться за недосягаемым - это тоже часть маркетинга. В итоге те, кто мог бы остановиться и совершенствоваться фрустрируют, а те кто хочет двинуться глубже и быстрее, стоят и буксуют.
Ну чё ты докопался до этого инженера. курс и курс. Какая разница как называется. Вот теперь поехали разбирать.
Программа 1-го месяца.
0 Заполнить раздел "О себе"
1 Качество ПО
2 Методологии разработки программного обеспечения
3 Карта функциональности продукта
4 Что такое требования и какие они бывают
5 Тесткейсы и чеклисты
Занятие 1-е. Качество ПО. Преподаватель - Лиана Кузнецова.
Преподавателям давать оценку не буду, пробные занятия есть на ютубе каждый смотрит и оценивает сам.
Как сформулированы цели и содержание.
Цели занятия:
Определить основные цели тестирования
Обьяснить семь принципов тестирования
Рассказать об основных видах тестирования
Краткое содержание
Исследуем что такое качество. Рассмотрим семь принципов тестирования. Познакомимся с видами тестирования.
Классический академический подход. Все просто доходчиво понятно. Обзорное занятие, что с него взять.
Что бы я хотел услышать и увидеть. Что Quality Assurance - это не тестирование. Это "деланье продукта офигенным". Make your product awesome. Это концепция которая напрочь отсутствует в постсоветском мозгу. Исправляй косяки до их появления, улучшай продукт на стадии планирования, продумывай удобство до воплощения.
Эргономика, принудительная безопасность, удовольствие от использования, всё это как мотиватор покупки. Поле улучшений, на самом деле, безгранично.
Домашка
Создать документ в google docs.
Открыть доступ к файлу, используя функциональность "Опубликовать в интернете".
Отправить ссылку на документ в чат с преподавателем.
Seriously? Это уровень QA engineer?
На том же занятии дают список литературы, в котором есть “Тестирование программного обеспечения” Святослава Куликова. Книги Куликова часто мелькают в рунете. Что кагбэ намекает. Книга в открытом доступе, качаем читаем. Читаем ПЕРЕД покупкой курсов по QA. Почему? Ниже поясню.
Переходим ко второму занятию. Методологии разработки программного обеспечения. Преподаватель Валерий Львов
Цели занятия
Студенты будут знать про две самых распространенных методологии разработки ПО, понимать их принципы, фазы и этапы. Понимать, в каких условиях какая из двух методологий предпочтительна. Понимать, где и какая работа требуется от QA-инженера, знать основные артефакты работы тестировщика.
Краткое содержание
Два наиболее распространенных подхода: "водопад" и Agile (на примере Scrum).
Роль тестирования в процессе разработки.
Перед Валерием стояла крайне сложная задача. Объяснить людям, которые if-ов не нюхали и функций не писали следующие концепты.
принципы, фазы и этапы разработки ПО
в каких условиях какая из методологий предпочтительна
где и какая работа требуется от QA-инженера
основные артефакты работы тестировщика.
Это четыре отдельных занятия, на пару академических часов каждое.
А тут за 90 минут надо ещё и на вопросы ответить.
По отзывам в учебном чате “информации было очень много”. А по мне - мало. Вот как тут всем угодишь.
Опять у нас классическая лекция с большим количеством определений и объяснений к ним.
Собственно, эта лекция должна идти в паре с первой. Понимание того как разрабатывается продукт дает вам понимание почему QA должен(но/ны) быть с начала и до конца на всех этапах продукта.
Для тех кто не в курсе. Есть два подхода. 20-го века и Agile.
В 20-ом веке заказчик шел к мэнэджэру, тот шел к директору, директор к инженеру, инженер к начальнику цеха, потом к бригадиру и в конце концов проект во всей красе попадал к токарю Василию. После чего выточенный болт отправлялся в ОТК (отдел технического контроля). ОТК проверяли соответствие болта требованиям и условиям договора (и ГоСТ), и всё это выдавалось заказчику. Это waterflow. Работает там где всё стандартизировано, где есть четкие требования и где цена ошибки высока. Например всё что связано с деньгами, безопасностью и личными данными (привет Россия 22). А ещё госзаказы.
Но ещё в далеком 1986-ом люди придумали SCRUM. (рекомендую посмотреть как это выглядит с тегом rugby, и вам станет проще понять принцип). А в 2001-ом вертевшаяся у всех на языке концепция обрела формулировку: “кто не шарит - тот %$#рит”. Если цель заказчика выдать лучший продукт по лучшей цене, то все вместе садимся и работаем на результат. Дальше досаливаем всё это нюансами и получаем DevOps.
Так вот. Agile - это не гибкость. Это - ловкость. Есть классические виды спорта: бег, штанга, гимнастика. А есть какой-нибудь страйкбол в котором нужно задействовать ВСЕ ресурсы и умения организма чтобы победить. И с одной стороны у тебя каждый год появляются новые инструменты, мощности, фреймворки, способы коллаборации и типы продукции. А с другой - стоимость одного часа (!) работы твоей команды может исчисляться тысячами долларов. Тут надо работать быстро. Вы ещё обсуждаете формулировки контракта, а Angry Birds уже не в моде.
Не хватило реальных жизненных историй и примеров. Что Лиана, что Андрей, от них прям веет профессионализмом. Если сравнивать с ремонтом авто. Спроси у такого спеца, почему именно такой тип резины используется в прокладке головки блока цилиндров - ответят. Но этот же профессионализм заставляет их быть осторожными с формулировками, что придает лекции "размытости". Палка о двух концах.
Едем дальше.
Дальше должна была быть лекция №4. Что такое требования и какие они бывают. Преподаватель Валерий Львов
Цели занятия
Студенты будут знать про роль требований в процессе разработки ПО, понимать необходимость работы с требованиями для тестировщиков, понимать жизненный цикл требований. Получат практический навык документирования требований в нотации Use Case и его связь со сценариями тестирования.
Краткое содержание
Что такое требования;
Жизненный цикл требований и роль тестировщика;
Структура use case и связь их с тест-кейсами;
Практика составления use case.
Почему я так переставил, потому что на этом условная академическая часть курса заканчивается.
И что, на мой взгляд, должен вынести отсюда ученик.
“Как задача ставится, так она и выполняется”. И когда всё пойдет прахом, заказчик придет и скажет “ну ты же специалист”.
Прежде чем писать дальше, я бы хотел рассказать анекдот. бородатый.
Наводнение. Город затапливает. Народ бежит. Посредине на лавке сидит дед.
-Дед, спасайся сейчас все затопит.
-Меня бог спасет.
Вода уже деду по грудь, народ выгребает на лодках.
-Дед, залезай мы тебя вывезем.
-Меня бог спасет.
Вода уже под горло, вертолет собирает последних опоздавших.
-Дед, хватайся, мы тебя спасем.
-Меня бог спасет.
Ессно, дед тонет, предстает перед богом.
-Вот, я тебе молился, все посты соблюдал, а ты меня не спас.
-А лодка кому была послана? Вертолет?!
Так вот. Специалист Quality Assurance это те самые лодки и вертолеты. А вот если их(QA) не послушали, то - спасательные экспедиции и водолазы. На этом месте обычно рисуют диаграмму стоимости исправления багов.
Requirement - это то что вам придется раскаленными щипцами и обманным путем вытягивать из заказчика. Это хотелки. Зачастую заказчик сам не знает чего хочет.
И вот после того как вы эти хотелки узнали, их нужно зафиксировать и донести до релиза через разрабов, дизайнеров и ограничения бюджета. А вот как вы их будете фиксировать, через use case or user story or something else, это вопрос техники.
Домашка
Написать 3 юзкейса.
Если быть точнее на 3-ем занятии нам рассказывают про декомпозицию продукта. Потом мы должны выбрать себе application, и далее с ним работать.
Сами пишем декомпозицию, сами пишем юз-кейсы, сами пишем тест-кейсы на втором месяце мы будем писать угадайте что? багрепорты… ну ты понел.
Собссно третье занятие, а за ним и пятое. 3. Карта функциональности продукта. 5. Тесткейсы и чеклисты. Преподаватель Екатерина Шляпкина
3 Цели занятия
декомпозировать продукт и выделить основные бизнес-сценарии.
Краткое содержание
Определим основную функциональность продукта. Разберем инструменты для построения карты функциональности продукта в форме диаграммы связей (ментальной карты, mindmap).
Цели занятия
объяснить какие виды тестовой документации существуют;
составить чек-лист;
составить тестовый сценарий.
Краткое содержание
тестовый сценарий (test case);
чек-лист;
план тестирования.
Я, конечно, могу представить как меня берут старым джуном, засылают одного на проект со словами: “декомпозируй продукт и выдели нам бизнес сценарии”. Но скорее всего уж если мне доверят столь крутую задаю я подойду к тимлиду или к заказчику и спрошу: “а каким образом эта глюковина должна приносить деньги?”.
Вообще декомпозиция - это из серии “развивайте аналитический склад ума” и “научитесь мыслить нестандартно”, вжуууух.
Основная мысль с этого занятия, на мой взгляд, должна была выглядеть примерно так. Декомпозиция продукта (и фиксация этой декомпозиции) будет основой вашей стратегии по тестированию. Поможет не метаться от кнопки к кнопке, а спокойно организовать вашу работу.
Чего мне не хватило на этих двух занятиях.
Практики. Нормального человеческого, смотрите как выглядит моя работа.
Где лучше использовать чеклист, а где тест кейс. Ну и конечно же. ВЕЛОСИПЕДОВ.
Я понял, почему я не могу вторую неделю сесть и сделать домашку.
Ребята, изобретите велосипед. Вот вам мелок и асфальт
Тут статеечка была…
Начинающие программисты боятся темноты
и ещё одна
Весь код уже написан. Все тесткейсы придуманы…
Веб тестирование, документация. Валидация емейлов.
А вот тут ещё в комментах накидано…
180+ Web Application Testing Example Test Cases
Напишите юзкейс, напишите тесткейс... Это если чё, уровень мидла. И с точки зрения QA engineer, вы должны учиться всё это писать. Но подачу "вот так выглядит тесткейс иди пиши свои" я могу абсолютно бесплано посмотреть в интернете. Ещё и с подробными разборами. Первое правило инженера - посмотри, а нет ли готового решения твоей проблемы.
Подведем итог.
Хотя нет. Перед подведением итога заглянем на сайт отуса и найдем курс
“Ручное тестирование” за 7тышш рублей
Модуль 1
Введение в тестирование
Тема 1. Введение в тестирование
Тема 2. Основы тестирования
Тема 3. Принципы тестирования
Тема 4. Методы и типы тестирования
Тема 5. Подходы и уровни тестирования
Тема 6. Виды тестирования
Тема 7. Итоги
Модуль 2
Жизненный цикл разработки ПО
Тема 1. Понятие жизненного цикла
Тема 2. Модель Waterfall. Аналитика
Тема 3. Модель Waterfall. Разработка
Тема 4. Модель Waterfall. Тестирование
Тема 5. Гибкие методологии
Тема 6. Итоги
Модуль 3
Тест-кейсы и дефекты
Тема 1. Введение
Тема 2. Источники ожидаемого результата
Тема 3. Пишем тест-кейс
Тема 4. Заводим дефект
Тема 5. Итоги
Модуль 4
Техники тест-дизайна
Модуль 5
Тестирование Web-приложений
Модуль 6
Тестирование мобильных приложений
И вот теперь подведем итог.
За 10к (примерно столько стоит месяц обучения), я получаю выразительный пересказ книги “Тестирование программного обеспечения Базовый курс (3-е издание)” главы 2.1, 2.2 и 2.3 частично. С картинками из этих ваших интырнетов. Или прям из книги. Ну в книге они скорее всего из интырнетов, но книга бесплатная, так к что кней претензий нет, а вот к Отусу вопросы есть.
Без песочницы, без практики, без реальных примеров. Но с ментором. Менторы - классные. Ну, по крайней мере, мне повезло. Ну и можно задать вопрос если чо-то непонятно.
За условные 3.500р., на курсе от того же отуса, я получаю все тот же объем информации.
Не говоря уже о том, что всё это можно нагуглить в любом порядке. Чем я и занимался две недели.
Очень не хватило обзора профессии в целом. Что есть, например, веб дизайн и тогда вас ждет джаваскрипт, есть мобилки, игры, десктоп всё это тестится вот так так и вот так. А вот здесь высокая доля мануала, а вот тут вам не отвертеться от автоматического и SQL... Короче вот это всё.
Вместо этого мне рассказывают, что главное декомпозицию выполнять по часовой стрелке размещая приоритетные направления вот тут. И что глаголы в инфинитиве надо использовать. Я открою вам секрет. Есть минимум три типа психики, каждый из которых организует рабочее пространство по-своему. Это если вы сами себе всё организуете. А вообще вы, скорее всего в команде будете работать. Так что пофиг что удобно ВАМ. Важно то, что продуктивно. А ещё приоритеты могут поменяться. Кардинально. А у вас там целая ветка со спринтами материалами и юзерсторями.
А знаете, чего вам ещё не расскажут в первый месяц обучения?
Подбор заработков на тестировании
А потом вы заходите на UTest, и в их академии учите всё что рассказывают на отусе - бесплатно. С тренажерами, пошагово с видосами, с описаниями. Правда на английском. Ну и с определенной заточкой под UTest. Я не говорю, что нет других ресурсов кроме ютеста, просто это то, что я сам успел поюзать. Тут ещё работа пошла, надо денежки зарабатывать. Времени реально в обрез, так что начинаешь очень ценить каждый час, потраченный на просмотр не самой качественной информации.
1st month resume
С академической точки зрения инфы слишком мало. С практической - воды слишком много. И общих фраз. Вместо того чтобы забивать резиновым мототком нейлоновые гвозди в пластилин, дайте нагрузку. В домашке должно быть "к следующему занятию вы должны знать вот это...". На вебинаре примеры ответы на вопросы и практика. Сам себе придумать всё я и бесплатно могу.
Пока что оценка курса "верните мои деньги".
To be continued
Впереди второй месяц обучения. Нас ждут новые преподаватели и, надеюсь, челленджи.
Бесплатное занятие Как правильно составлять баг репорт.
И ещё одно Исследовательское тестирование.
и ещё семь занятий между ними.
Post Scriptum Какой язык учить в 2022?
Английский.
UPD 05.06.22
Признаться, я не ожидал, что мою статью, вообще, опубликуют. Более того. Случилось так, что я списался с автором тех самых статей, которые сподвигли меня на поступление на курс. За что ему большое спасибо. И за статьи и за ответ). Далее у нас случился такой вот разговор. 
И я сел писать причесанную версию. И тут я открываю свою ленту и вижу там свою статью! О небеса о боги! Её даже не заминусили. И срач в комментах! Дайте обмазаться!
Я постарался пофиксить баги, сохранив дух, посыл и начальные чувства. Заранее спасибо модераторам за терпение. Глядя на комменты я вижу, что вопросы, которые я хотел бы ещё раскрыть, имеют место быть. Так что, если позволит время, то закину часть 1.5, не дожидаясь конца этого месяца.