Что вы делаете такого что выдает в вас ITшника?
Расскажите что вы из IT не говоря что вы из IT.
Расскажите что вы из IT не говоря что вы из IT.
Часто по окончанию курсов по тестированию, выясняется, что о многих инструментах, необходимых для тестов выпускники просто не знают или не слышали.
Давайте перечислим несколько программ, которыми мы пользовались с самого начала:
1️⃣Jira - популярная система управления проектами, их разработкой и отслеживания ошибок. Можно создавать задачи, двигать по статусам, декомпозировать задачи, просчитывать загруженность команды, проставлять приоритеты задач и многое другое.
2️⃣TestIT - система управления и хранения тестовой документации. Тест-планы, тест-кейсы, чек-листы - все это можно создавать создавать, хранить можно там.
3️⃣Postman (куда без него) - один из самых популярных инструментов тестирования API. Он облегчает процесс создания, проверки и описания API. При помощи данного инструмента тестировщик может выполнять различные виды HTTP-запросов, такие как GET, POST, PUT, PATCH, а также автоматически генерировать код для языков программирования, таких как JavaScript и Python.
4️⃣Kibana - это удобный инструмент, позволяющий просмотреть логи системы (чаще всего сервера), например по той или иной ошибке, понять по какой причине она могла произойти, проанализировать их и передать разработчику.
5️⃣Jmeter - инструмент для нагрузочного тестирования, довольно простой и понятный. Как симулировать большой приход пользователей на сайт? как нагрузить один запрос? Как выгрузить отчеты по нагрузке? - ответы в Jmeter
У каждого тестера есть свои раздражители, поэтому этот пост будет сугубо субъективным, основанном на наших реальных событиях
🔴Бесит, когда забывают учесть время на тестирования в планировании задач
🔴Бесит, когда говорят «быстренько протестируй, пожалуйста»
🔴Бесит, когда после тестирования задачи меняются требования к ней
🔴Бесит, когда разработчик не прописывает, что именно он сделал в задаче, а что нет и по какой причине
🔴Бесит, когда задают вопрос, не пользуяюсь правилом 15 минут
🔴Бесит, когда важные решения происходят в личных чатах, о которых ты узнаешь случайно 🔴Бесит, когда тебе нужен напарник, но «поиск нового тестера сейчас не в приоритете»
🔴Бесит, когда уходишь на обед и ты сразу становишься всем нужен
🔴Бесит, когда ты закончил свой рабочий день, а коллега с другим часовым поясом начинает активничать в вашем чате
🔴Бесит, когда предлагаешь классное решение проблемы, но все отказываются от него, потому что все привыкли делать как привыкли и не важно, что их метод давно устарел
Один из самых критичных багов, который привел к непоправимым последствиям для компании, произошел с марсоходом NASA — Mars Climate Orbiter. В 1999 году он был потерян из-за ошибки в расчетах, вызванной использованием английских единиц измерения вместо метрической системы одним из подрядчиков NASA. Это привело к неправильному маневрированию аппарата, который в результате был утерян при входе в марсианскую атмосферу.
Заметный пример критической ошибки, которая привела к значительному ущербу для компании в сфере электронной коммерции, — это знаменитый сбой, который повлиял на онлайн-рынок eBay в 2014 году. Этот баг привел к крупному отключению, в течение нескольких часов пользователи не могли покупать и продавать товары. Точная природа ошибки не была обнародована, но последствия были значительными: сообщалось о потерянных продажах и падении цены акций компании после инцидента. Не было обнародовано конкретной информации о финансовых потерях eBay из-за сбоя в 2014 году. Однако, сбои в работе IT-систем могут стоить компаниям в среднем до $300,000 за час простоя веб-приложений.
Еще один известный случай связан с веб-основанным хранилищем Amazon S3 в 2017 году, которое вышло из строя из-за опечатки сотрудника Amazon во время выполнения команды, что привело к нескольким часам простоя для многих веб-сайтов и сервисов, зависящих от S3 для хостинга. Во время сбоя сервисов Amazon Web Services (AWS) в 2017 году, который длился около четырех часов, компании, входящие в индекс S&P 500, потеряли примерно 150 миллионов долларов. Кроме того, финансовые службы США потеряли около 160 миллионов долларов.
Эти инциденты подчеркивают важность тестировщика в команде разработки. Так что, мы, гильдия тестировщиков - не последние люди в разработке.
Боишься первых собесов?
1️⃣ Что такое тестирование?
Да, да. Как банально подумаете вы, однако все мои собседования начинались с этого вопроса. И обычно ты начинаешь теряться в нем, так как не думал, что будет такой легкий вопрос.
Самое простое определение: тестирование ПО - это процесс проверки программного обеспечения на соответствие ожидаемому результату.
2️⃣ Какие виды тестирования вы знаете? Что такое функциональное, регресиионное тестирование?
Также спрашивают чем отличаются некоторые виды друг от друга. Например, функциональное от нефункционального, дымное от регрессионного. Просят назвать виды нефункционального тестирования.
3️⃣ API-методы. POST, GET, DELETE, PUT.
Также часто спрашивают корневое различие методов GET и POST. А также какие методы являются самыми популярными.
4️⃣ Что такое баг, а что такое дефект. Их различия.
В разных компаниях принимается по-разному. Кто-то использует в процессах только баги, а кто-то имеет четкое разделение багов и дфектов и это для них важно.
5️⃣ Как бы вы поступили, если в задаче, которая пришла к вам на тест, не совсем вам понятно ТЗ?
Обязательно задают вопрос по процессам, даже если у вас нет опыта. Размышление над такими вопросами дает понять работодателю как вы будете себя вести в новой для вас ситуации. Поэтому заранее подготовьтесь к нему.
Комьюнити для начинающих тестировщиков QA_nobug
Ты нашел для себя новое дело, загорелся, у тебя огромный запас энергии, ты кайфуешь от того, что наконец нашел то, что тебе действительно интересно! Все мы так думаем до поры до времени, когда приходит усталость, выгорание и ты бросаешь уже сотое дело в начале пути. У кого такое было хотя бы пару раз? Скорее всего вы допускали несколько ошибок:
❌Ставили завышенные ожидания, которые редко совпадают с реальностью. Начиная какое-то дело, мы сразу представляем во что оно может вырасти через какое-то время. И вот это время проходит, но мечта не сбылась. Это не только расстраивает, но и размотивирует делает что-либо дальше. Тут важно понимать, что это абсолютно нормально, что все идет не по плану. Вы выиграете, если примете эти условия - и не остановитесь. 2 шага назад ради 1 шага вперед!
❌Не давали себе отдыхать. Да, новое дело, по началу может увлечь так - что все вечера, выходные мы заменяем на него. Это может приносить удовольствие, но опять же не надолго. Нужно останавливать себя, чтобы каждый раз возвращаясь к этому делу, вы чувствовали, что соскучились по нему, и готовы сделать еще больше.
❌Не дисциплинировали себя. Вы тоже могли сталкиваться с тем, что в момент выгорания, вы идете у себя на поводу, придумываете отмазки, отговорки, чтобы не возвращаться к делу, которое не так давно вас загорело. Но если когда-то оно вас загорело, то может загореть снова, главное не останавливаться. Даже в момент выгорания договориться с собой хотя бы на 10-20-30 минут посвятить делу, а дальше - прислушайтесь к себе. Главное, дать шанс снова себя зажечь.
Признавайтесь, допускали ли вы хотя бы одну из ошибок и как с ними боролись? #БольТестировщика
Назовем его «собеседование через шутку»
Никогда не знаешь, на какую тему тебе зададут больше всего вопросов. А мы попробуем заставить задать нам вопросы на тему, в которой мы больше всего разбираемся.
Как?
Рассказываем супер поверхностно, вскользь про то, что мы хорошо знаем. Чуть подробнее - про то, что мы знаем, но не совсем хорошо. И шутим про то, что совсем ничего не знаем.
Собеседование обычно ограничено часом-полтора. И те, кто собеседуют, посмеявшись над вашей шуткой, думают:
«Ага, вот над этим он шутит, тут все понятно - разбирается. Выкенем из собеса эту тему - не хватит времени. Про вот это он рассказал впринципе более менее подробно. А вот по этому прошелся вскользь - погоняем на эту тему»
И начинают спрашивать именно по той единственной теме, в которой мы шарим)
Можете воспринимать это как шутку, но это рабочий лайфхак, который помог не одному моему знакомому. Только никому 🤫
Всем привет! Поговорим про нагрузочное тестирование.
Давай представим некую абстрактную систему в виде трубопровода, куда подается вода под давлением. Там есть турбины, развязки, какие то технические блоки и т.п. Цель проверить герметичность и то что вода подается под давлением с одного конца и спокойно выходит с другого, все турбины вращаются и блоки работают как надо. Для этого мы берем насосы высокого давления и начинаем нагнетать поток воды. Дальше смотрим есть ли у нас течь в каких то швах или компонентах нашей системы.
С информационными системами происходит примерно тоже самое, только мы подаем не воду, а поток входящих данных. Например, представим что некий интернет магазин решил провести акцию небывалой щедрости - продавать технику со скидкой в 90% и еще запустил огромную рекламную кампанию так чтобы все люди точно узнали про это. В ожидаемом результате мы планируем то что на сайт магазина ринется толпа яростных покупателей которые хотят скупить весь ассортимент.
Магазину требуется удостовериться в том что его система выдержит этот поток и удовлетворит спрос всех желающих приобрести новенький айфон. В этот момент в дело вступает нагрузочное тестирование. Задача сэмулировать миллион пользователей которые одновременно тыкают кнопочки, ищут товары, добавляют в корзину и совершают покупки.
С этим на первый взгляд все просто, с помощью какого нибудь инструмента, например jmeter, мы пишем скрипты эмулирующие все действия пользователей в системе, дальше задаем нужное количество потоков и интенсивность. Но дьявол кроется в мелочах, ведь нужно правильно рассчитать интенсивность и распределить потоки по выполняемым действиям, а это сложная аналитическая работа. Ведь подаваемая нагрузка должна максимально соответствовать тому что предстоит испытать системе в день распродажи. Может оказаться так что операция поиска товара более трудозатратная чем добавление его в корзину. Теперь давай прикинем сколько запросов поиска ты совершаешь при выборе телефона, ноута или телевизора, а добавляешь в корзину только один раз. Таким образом нужно правильно рассчитать профиль нагрузочного тестирования со всеми нюансами, что не так просто.
Так же надо понимать что вся система развернута на каких то серверах и нам нужен тестовый стенд в идеале соответствующий реальному контуру системы. Сейчас не будем в это углубляться, так как расчет ресурсов и обоснование для закупки серверов для стенда тот еще геморрой. Остановимся на том что тестовый контур может в разы отличаться от продуктивного и в этом случае придется как то натягивать полученные результаты тестирования на реальную картину мира, что из себя представляет танец с бубном.
Представим что мы рассчитали профиль тестирования, никак не ограничены в ресурсах серверов и готовы подавать нагрузку. Запускаем шарманку, наши виртуальные пользователи начали совершать все действия по покупке товаров в магазине. Что дальше? А дальше самое сложное, нужно провести анализ всей системы.
Вначале рассказывал про трубопровод, так вот теперь с эндоскопом лазим по всем щелям и проверяем на наличие протеканий. На реальных системах есть куча метриков которые нужно нужно уметь читать и анализировать. Загибаем пальцы: утилизация CPU, оперативной памяти, дисков, сети серверов, тоже самое для отдельных элементов системы которые развернуты на этих серверах, времена выполнения операций наших пользователей, интенсивность, количество активных потоков, количество ошибок, еще до кучи тонна логов, статистика с базы данных и это далеко не все метрики которые придется перерыть… В конце концов все это дело анализируем, делаем заключение и даем рекомендации по оптимизации системы. Чем глубже ты можешь капнуть тем круче ты как специалист. Естественно, я сейчас упрощаю для понимания, но далеко не каждый может установить причинно-следственную связь между утечкой памяти в одном сервисе и тем что в другом сервисе долбит fatal error.
Подводя итоги, чтобы провести нагрузочное тестирование требуется проделать большую подготовительную работу где специалист проявляет аналитические навыки. Провести запись скриптов и настройку инструмента нагрузочного тестирования - здесь необходимы технические навыки и программирование в том числе. После всего накатать портянку отчетности со своими умозаключениями и опять для этого нужны аналитические способности. Специалист по нагрузочному тестированию должен смотреть на систему целиком, видеть единую картину и обладать большим набором компетенций. Я считаю что это разительно отличает его от разработчика или функционального тестировщика. Ведь первый может писать код чисто для своего компонента системы и ему до лампочки как там оно должно работать на другом уровне, а второму не нужно заморачиваться как быстро отрабатывает та или иная функция системы.
Профессия интересная и востребованная.