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

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

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

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

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

Всем, кто дочитал мою простыню до конца - спасибо!

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

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

Представим что мы рассчитали профиль тестирования, никак не ограничены в ресурсах серверов и готовы подавать нагрузку. Запускаем шарманку, наши виртуальные пользователи начали совершать все действия по покупке товаров в магазине. Что дальше? А дальше самое сложное, нужно провести анализ всей системы.

Вначале рассказывал про трубопровод, так вот теперь с эндоскопом лазим по всем щелям и проверяем на наличие протеканий. На реальных системах есть куча метриков которые нужно нужно уметь читать и анализировать. Загибаем пальцы: утилизация CPU, оперативной памяти, дисков, сети серверов, тоже самое для отдельных элементов системы которые развернуты на этих серверах, времена выполнения операций наших пользователей, интенсивность, количество активных потоков, количество ошибок, еще до кучи тонна логов, статистика с базы данных и это далеко не все метрики которые придется перерыть… В конце концов все это дело анализируем, делаем заключение и даем рекомендации по оптимизации системы. Чем глубже ты можешь капнуть тем круче ты как специалист. Естественно, я сейчас упрощаю для понимания, но далеко не каждый может установить причинно-следственную связь между утечкой памяти в одном сервисе и тем что в другом сервисе долбит fatal error.

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

Профессия интересная и востребованная.

UI/UX

Вполне интересное направление. Что-то типо Frontend, только без з*луп с языками) Друг работает. Не знаю, норм, но он даже на позиции ныне Lead в крупной российской компании говорит, что "я них*я не знаю на самом деле, хотя думал что знал многое".

1С

Тут даже не надо изучать английский. Но сообщество 1Сников какое-то конечно очень токсичное. Х*есосят всех, даже своих. PlayStation элита из мира программирования, сидят в болоте из говна и палок и не понимают сами чо к чему. Ну, это я по чатам в телеграм определил. Единственное реально токсичное сообщество. Гайд долбоёба ток советуют, а сами не могут от себя ничего рассказать. Но направление весьма интересное, но как это изучать - непонятно. Много слов про стажировки с нуля во франчайзах, но что-то такого вообще нету, какие-то невыдуманные истории о которых невозможно молчать.

Мысли

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