Итоги года
Также, кроме срочного погашения ипотеки. Окончил курсы пикабу и уже второй месяц работаю по специальности. В свои 37 лет.
Также, кроме срочного погашения ипотеки. Окончил курсы пикабу и уже второй месяц работаю по специальности. В свои 37 лет.
Всем привет!
Впервые пишу здесь, но в одном посте на Пикабу было обсуждение на тему того, как «попасть» в тестирование через поддержку, решила поделиться своим опытом.
Меня зовут Юля, мне 29 и с 2014 года я начала свой путь в поддержке. Начиналось все с колл центра Мегафона, далее перешла в IT компанию, которая делала продукт для малого и среднего бизнеса на позицию специалиста технической поддержки. Роста в данной компании не было, да и не особо мне было интересно в тот период жизни. После 3,5 лет работы перешла в другую компанию, которая также занимается разработкой ПО.
Через примерно 1,5 года работы на позиции сопровождения 2 линии, подвернулся шанс перейти в разработку. Я начала учить язык программирования Java, освоила фрэймворки Spring, Hibernate и конечно же SQL, взаимодействие с базами данных. Сделала простенький проект, побывала на паре тестовых собеседований в этой же компании, но через какое-то время все заглохло и мне было сказано, что места нет на Джуна и не понятно когда появится.
Попробовать свои силы в других компаниях я побоялась и осталась на позиции сопровождения. Многие из нашей компании переходят из сопроводов в аналитики и тестировщики. Аналитика не мое, а вот тестирование в дальнейшем заинтересовало, так как я открыла для себя автоматизированное тестирование, в котором мои знания джавы очень кстати.
На очередной аттестации попросилась в тестировщики, мне дали матрицу компетенций, где было прописано что нужно знать. На моем проекте ( где я работала сопроводом) автотестов не было, поэтому начать решила с мануального. Снова обучение. Изучила всю теорию, протестировала всякие калькуляторы, сайты и прочее, написала тест кейсы, составила тест планы насколько умела, сделала отчеты по тестированию и запросила собеседование. На собеседовании все пошло не так, как я думала. Вопросов про техники, типы тестирования не было, по sql тоже не спросили, но к моему счастью зашел разговор о джаве. Я объяснила, что мне интересно больше автотестирование и мне бы не хотелось терять навыки джавы, которые со временем и отсутствием практики начали забываться. В итоге после провального, как мне казалось, собеседования, на котором я не смогла показать все свои знания в том числе из-за дикого волнения, мне было предложено обучиться автотестам.
Я снова начала учиться, в этот раз было легче, так как джаву нужно было только повторить. Через неделю мне дали ментора, который помогал мне в освоении материала. Я открыла для себя Селенид.
Стоит сказать, что к тому времени я уже выгорела в поддержке и работа не приносила удовольствия, как раньше. Но как только были написаны первые строчки кода, открылось второе дыхание, мне безумно нравилось запускать написанный мною код и видеть, как работает автотест. В итоге, в течении месяца я работала 2 дня в поддержке и следующие 2 дня обучалась автотестам. Было нелегко и отсутствие отдыха давало о себе знать, но я знала, что это ненадолго. Так и получилось, на следующий день, после того, как с ментором закончили обучение ( итого вышло где-то 15 дней на фронт/бэк), мне сообщили, что переводят на должность младшего тестировщика.
Однако, был нюанс, переводили на компонент, где нет автотестов, соответственно я стала мануальщиком. Немного расстроилась, но все же была рада возможности развития в данном направлении. Придя в команду, лид позволил мне на тестовом контуре проводить эксперименты с автотестами, а мой ментор все еще рад помочь, если что-то не будет получаться.
На данный момент, основное рабочее время занимают мануальные тесты и я считаю это важным навыком, а в свободное время пишу автотесты. Предстоит долгий путь обучения, проб и ошибок.
Всем, кто дочитал мою простыню до конца - спасибо!
Всем привет! Поговорим про нагрузочное тестирование.
Давай представим некую абстрактную систему в виде трубопровода, куда подается вода под давлением. Там есть турбины, развязки, какие то технические блоки и т.п. Цель проверить герметичность и то что вода подается под давлением с одного конца и спокойно выходит с другого, все турбины вращаются и блоки работают как надо. Для этого мы берем насосы высокого давления и начинаем нагнетать поток воды. Дальше смотрим есть ли у нас течь в каких то швах или компонентах нашей системы.
С информационными системами происходит примерно тоже самое, только мы подаем не воду, а поток входящих данных. Например, представим что некий интернет магазин решил провести акцию небывалой щедрости - продавать технику со скидкой в 90% и еще запустил огромную рекламную кампанию так чтобы все люди точно узнали про это. В ожидаемом результате мы планируем то что на сайт магазина ринется толпа яростных покупателей которые хотят скупить весь ассортимент.
Магазину требуется удостовериться в том что его система выдержит этот поток и удовлетворит спрос всех желающих приобрести новенький айфон. В этот момент в дело вступает нагрузочное тестирование. Задача сэмулировать миллион пользователей которые одновременно тыкают кнопочки, ищут товары, добавляют в корзину и совершают покупки.
С этим на первый взгляд все просто, с помощью какого нибудь инструмента, например jmeter, мы пишем скрипты эмулирующие все действия пользователей в системе, дальше задаем нужное количество потоков и интенсивность. Но дьявол кроется в мелочах, ведь нужно правильно рассчитать интенсивность и распределить потоки по выполняемым действиям, а это сложная аналитическая работа. Ведь подаваемая нагрузка должна максимально соответствовать тому что предстоит испытать системе в день распродажи. Может оказаться так что операция поиска товара более трудозатратная чем добавление его в корзину. Теперь давай прикинем сколько запросов поиска ты совершаешь при выборе телефона, ноута или телевизора, а добавляешь в корзину только один раз. Таким образом нужно правильно рассчитать профиль нагрузочного тестирования со всеми нюансами, что не так просто.
Так же надо понимать что вся система развернута на каких то серверах и нам нужен тестовый стенд в идеале соответствующий реальному контуру системы. Сейчас не будем в это углубляться, так как расчет ресурсов и обоснование для закупки серверов для стенда тот еще геморрой. Остановимся на том что тестовый контур может в разы отличаться от продуктивного и в этом случае придется как то натягивать полученные результаты тестирования на реальную картину мира, что из себя представляет танец с бубном.
Представим что мы рассчитали профиль тестирования, никак не ограничены в ресурсах серверов и готовы подавать нагрузку. Запускаем шарманку, наши виртуальные пользователи начали совершать все действия по покупке товаров в магазине. Что дальше? А дальше самое сложное, нужно провести анализ всей системы.
Вначале рассказывал про трубопровод, так вот теперь с эндоскопом лазим по всем щелям и проверяем на наличие протеканий. На реальных системах есть куча метриков которые нужно нужно уметь читать и анализировать. Загибаем пальцы: утилизация CPU, оперативной памяти, дисков, сети серверов, тоже самое для отдельных элементов системы которые развернуты на этих серверах, времена выполнения операций наших пользователей, интенсивность, количество активных потоков, количество ошибок, еще до кучи тонна логов, статистика с базы данных и это далеко не все метрики которые придется перерыть… В конце концов все это дело анализируем, делаем заключение и даем рекомендации по оптимизации системы. Чем глубже ты можешь капнуть тем круче ты как специалист. Естественно, я сейчас упрощаю для понимания, но далеко не каждый может установить причинно-следственную связь между утечкой памяти в одном сервисе и тем что в другом сервисе долбит fatal error.
Подводя итоги, чтобы провести нагрузочное тестирование требуется проделать большую подготовительную работу где специалист проявляет аналитические навыки. Провести запись скриптов и настройку инструмента нагрузочного тестирования - здесь необходимы технические навыки и программирование в том числе. После всего накатать портянку отчетности со своими умозаключениями и опять для этого нужны аналитические способности. Специалист по нагрузочному тестированию должен смотреть на систему целиком, видеть единую картину и обладать большим набором компетенций. Я считаю что это разительно отличает его от разработчика или функционального тестировщика. Ведь первый может писать код чисто для своего компонента системы и ему до лампочки как там оно должно работать на другом уровне, а второму не нужно заморачиваться как быстро отрабатывает та или иная функция системы.
Профессия интересная и востребованная.
Посоветуйте книгу по управлению людьми/проектами, людьми и проектами в тестировании или просто достойную книгу про управлении в этой сфере и сфере разработки ПО.
Книга нужна для уже опытного руководителя отделом тестирования.
Дмитрий , 26 лет. Краснодар
Увлекаюсь : техника , музыка (Рок , поп-рок зарубежный), кино (Ужасы , комедии зарубежные) , игры (Action / RPG / Квесты с нелинейным сюжетом)
Интересы: администрирование сайтов, web-технологии , IT безопасность.
Занимаюсь тестированием web-сайтов / приложений на уязвимости , провожу аудиты безопасности.
Ранее участвовал в bug bounty на платформах : hackerone , bugcrowd.
ищу человека по общим интересам.
Telegram: @hack2tools