cookie

We use cookies to improve your browsing experience. By clicking «Accept all», you agree to the use of cookies.

avatar

Тестирование ≠ QA

Тестирование, автоматизация, процессы

Show more
Advertising posts
233
Subscribers
No data24 hours
No data7 days
No data30 days

Data loading in progress...

Subscriber growth rate

Data loading in progress...

Про повышение TLDR: не получилось. Далее подробнее. Писать о неудачах в целом сложнее, но считаю, что это важно для обмена опытом. Зимой я поставил цель достичь следующего уровня по своей ветке IC (Individual Contributor). Помимо какой-то морковки в виде формальной цели, в этом был и чисто финансовый интерес — благодаря наслоению налоговых факторов, связанных с начислением акций от работы, мы полностью потеряли весьма существенную ежемесячную сумму детских денег от 🇨🇦. В Unity в целом градация для сеньоров такая: — IC 6: твердый сеньор — IC 7: супер сеньор в своей команде, способный в одиночку делать задачи проекта с высоким качеством — IC 8: staff в команде или расшаренный между командами, еще более опытный чел, способный курировать несколько проектов и стеков — IC 9: principal, архитектор И здесь мы подходим к понятию сеньорства как такового. Разные люди рассматривают эти уровни по разному, и возможно, это стоит выделить в отдельный пост, но мое понимание таково: если в вашей команде люди сильнее вас, нужно бежать в два раза быстрее, чтобы получить повышение вне зависимости от внутреннего ощущения своей сеньорности. В моем случае из 11 лет опыта я силен в собственно в качестве, тестировании, менеджменте и процессах. В рамках этого можно замахнуться и на большее. В SDET же, пожалуй, на высоком уровне могу в E2E и API автотесты. Что в совокупности достаточно для IC 6, а на 7 нужно больше и лучше. Это у меня не получилось, и вот почему. Как я уже писал, ожидания команды из-за общего уровня весьма высоки, и по факту должен стать почти таким же скилловым разработчиком, но с упором на качество и тестирование. В нашем проекте не так много ручного тестирования, так как при нескольких релизах в день это не масштабируется. В этих условиях я в свою очередь пытался развить оба направления: больше влиять на культуру и процессы, разрабатывать общую стратегию, добавлять фреймворки, писать и менторить автотесты. В свободное же ночное время проходил курсы по разработке, подтягивая слабые места. Хотя нужно было всеми силами тащить программирование и девопс. Чем я и планирую заниматься теперь.
Show all...
Тестирование ≠ QA

Мы с супругой внезапно слетали в отпуск впервые за жизнь, с трудом возвращаюсь к работе :) Я поставил себе и менеджеру цель получить формальный IC 7 level (слесарь высшего разряда) в этому году, поэтому буду активно прокачивать соответствующие скиллы, включая программирование. В большей степени потому, что я пришел в SDET из QA, и именно D является наиболее слабым в особенности на фоне моих сильных разрабов, а одним из IC 7 Leveling Descriptors является “Frequently delivers exemplar solutions”, что амбициозненько. Буду держать в курсе и делиться какими-то наработками.

🔥 11
Апдейт: у Unity новый СЕО, и у меня появилась надежда, что: а) топам пока будет не до возврата в офис б) нам коллективно можно будет попробовать давить на Best Ideas Win, чтобы найти компромисс в условиях, когда команды максимально удалены друг от друга и уйти от совкового подхода, когда у всех уравниловка. Почему надежда: новый СЕО работал в Redhat, и там он (после стандартного кровавого корпората) столкнулся с тем, что люди на местах могут предлагать лучшие решения. Об этом его TED talk, очень рекомендую посмотреть, там смешно.
Show all...
🔥 3👍 2
Тестовое задание на автоматизацию #1 Для начала пояснения: некоторые компании не хотят шарить свои тестовые, поэтому я не буду употреблять названия. Хоть и шанс кому-то из читателей податься в ту же контору с тем же заданием равен нулю, честно говоря. И сами тесты будут изменены, но суть и выбранная сложность останутся. Предлагаю желающим попрактиковать свои навыки присоединяться. Тем, кто прошел мой курс, очень рекомендую освежить знания на реальных задачках. Давайте так, кто захочет решить: - на выбор Cypress или Playwright - код кидать в комментарии в виде ссылки на GitHub Gist или лучше репозиторий, откуда можно скачать и запустить проект (если совсем стеснительно, можно в личку) С меня ревью и предложения по улучшению. Вам это поможет набить руку в оформлении тестовых и в итоге получить некое портфолио, если еще не. Ставьте лайки, зовите друзей, кому актуально. Тест 1 - Открыть https://www.cypress.io - Кликнуть на 'npm install cypress' CTA - В попапе кликнуть на 'npm install cypress' CTA Убедиться, что текст в буфере обмена равен npm install cypress --save-dev Тест 2 - Открыть https://www.cypress.io - Проскроллить до текста "Loved by OSS" и убедиться, что он отображается - Вывести в лог число загрузок за неделю без "М+" Напомню, что цель тестовых - не просто решить (обычно не супер сложную) задачку, а и продемонстрировать уровень, на который вы идете. Поэтому нет предела совершенству, можно накручивать сложность, если видите, что в этом есть смысл.
Show all...
Тестирование ≠ QA

Все уроки курса "Cypress scouts: E2E automation basics from scratch" Целевая аудитория Тестировщики, которые пытались влезть в E2E автоматизацию самостоятельно и бессистемно, но не получилось. Что вы получите по итогу С минимальным необходимым знанием Javascript у вас будет репозиторий с собственными (не шаблонными) тестами на сайт с заказом товаров. Главный плюс Вы на практике будете бороться с самой главной болезнью E2E тестов - их хрупкостью. Что еще включено: - Тесты будут запускаться на CI (GitHub Actions) - Несколько способов, как находить селекторы элементов - 3 способа правильного ожидания изменений на странице - Как делать проверки - Как эффективно отлаживать тесты - Best practices, применимые в любом фреймворке Не знаю, отнести ли следующий эпитет из отзывов к плюсам - "залихватский язык"😜 Я старался живым, не канцелярско-академическим, языком описывать сложные моменты, поэтому если вам заходит стиль этого канала и/или моего канадского, должен зайти и курс. Как я писал ранее, уроки плавно усложняются…

Something new TLDR: Начинаю искать новую работу С сентября нас, как и многих в этом году, выгнали в офисы на 3 дня в неделю. Я понимаю преимущества совместной работы, когда вы можете вместе тусить, парно программировать или разбираться в сложной хренотени. Проблема в том, что за ковид глобальные компании набирали таланты, а не команды около офисов. В моей конкретной ситуации в Монреале есть только один staff engineer, с которым мы весьма редко работаем над чем-то вместе. А добираться надо в лучшем случае от 1.5 часов в одну сторону с кучей пересадок, то есть, больше 3 часов в день тратить практически без цели. Самое обидное, что это первый за карьеру проект, где мне нравится всё — матерая команда, современные технологии, идеи по развитию продукта, бесконечные возможности для развития хард скиллов в автоматизации, ну и компенсация в целом адекватна рынку. Будет непросто. В первую очередь потому, что почти все большие конторы (с бюджетами на зарплаты) перешли на гибрид, и на рынке достаточно мало вакансий и много желающих, что дает нам типичную ситуацию рынка, когда работодатели могут выбирать и снижать ожидаемые зарплаты. На днях сгоряча почти нашел работу — в одном стартапе успешно прошел интервью, но замешкался, и они взяли другого человека. Покопавшись на линкеде, стало понятно, что всё не так просто, как казалось на берегу. Возможно, что-то изменится в моем восприятии или в самой компании, и я останусь, но пока буду искать. Если кому-то интересно узнать, как будут проходить интервью, напишите в комментариях.
Show all...
Photo unavailableShow in Telegram
А напишите в комментариях, вы часто/постоянно тестируете в таком стиле? Если да, как часто находите критичное?
Show all...
Photo unavailableShow in Telegram
Всех причастных с undefined!
Show all...
😁 9
GitHub Actions: как подменить параметры в файле перед отправкой на другой сервер Думаю, может быть полезно скидывать какие-то штуки/находки из повседневной работы в формате "вопрос-решение" для расширения кругозора. Задача Ранее тесты нагрузки запускались ручками: загружались файлы на сервер, руками же копировался запрос запуска тестов на Swagger странице. Так как тесты стали запускаться чаще, нужно было это все автоматизировать из GitHub Actions (GHA), чтобы в одном месте разработчики могли задавать параметры и для самого JMeter, и для нашего внутреннего облачного сервиса. Например, хочу запустить тесты на 500 пользователей из Штатов и Европы на трех машинах на час. Файлы тестов и конфигурации облаков копируются напрямую из гита, поэтому нужно перезаписать дефолтные значения конфигов на то, что введено в формах GHA. Решение Вместо actions вида replace string, ребята посоветовали использовать
sed
редактор, который на лету подменяет нужные строчки (помимо всего прочего полезного). Например, есть yaml файл, который содержит конфигурацию вида:
modules:
  jmeter:
    properties:
      USER_COUNT: ${USER_COUNT}
      DURATION_IN_SECONDS: ${DURATION}
Тогда шаг GHA будет выглядеть как-то так:
- name: Set execution variables
   run: |
     cd <your file path>
     sed -e 's/${THREAD_COUNT}/${{inputs.number-of-threads}}/g' -e 's/${DURATION}/${{ inputs.test-duration }}/g'  filename.yaml > filename-updated.yaml
Где
${USER_COUNT}
и
${DURATION}
это строчки файла, которые надо заменить (доллар и скобки для наглядности, что это значение, это может быть любой текст), а
${{inputs.number-of-threads}}
и
${{ inputs.test-duration }}
это значения соответствующих полей, введенные в форме. После подмены можно продолжить с отправкой файлов.
Show all...
👍 5
Публичный собес джуна ручного тестировщика Достаточно стандартные вопросы и в целом адекватные ответы. Можно кинуть тем, кто входит в тестирование, чтобы им примерно понимать, как проходит процесс, какой сложности вопросы и собственно что нужно понимать (не бездумно заучить) для того, чтобы претендовать на эту позицию. От себя добавлю, отрадно видеть, что в русскоязычном пространстве принято на начальном уровне уже знать основы. Опыт многих встреченных ребят из Северной Америки меня нередко удручает. https://youtu.be/F0R8UfliZnU?si=1XcmH7gK631Bf-ZL
Show all...
Публичное собеседование / мок-интервью для QA-инженера. Тест формы и базовые принципы тестирования

🔥Бесплатный курс «Введение в тестирование веб-приложений» от Хекслета:

https://ru.hexlet.io/link/docqAU

🔥Полная программа «Инженер по тестированию на Хекслете»:

https://ru.hexlet.io/link/t467Jr

⚡Вакансии CSSSR:

https://csssr.com/ru/jobs

Сегодня вас ждет настоящая сенсация – мы проведем первое на канале Хекслета публичное собеседование в области тестирования ПО. 🚀 В роли кандидата выступает студент Хекслета, который работает инженером-экологом и прошёл программу Хекслета «Инженер по тестированию». QA-лид задала ему вопросы о работе тестировщика, базовых принципах тестирования и задала кейс, где нужно провести проверку фронтенд-части формы на сайте. – Задаёт вопросы Оля Ильчукова, QA-лидка в CSSSR (

https://t.me/csssr0)

– Отвечает на вопросы Алексей Швидунов, студент Хекслета ____ Публичное собеседование (мок-интервью) – формат учебного интервью, где мы поставим джуниор-тестировщика в условия практического собеседования. В этом видео эксперт задаёт вопросы, которые позволят кандидату продемонстрировать уровень своих технологических знаний и понимание ключевых подходов в QA manual. Это не только отличная возможность для джуниора продемонстрировать свои сильные стороны, но и для зрителей - узнать новые аспекты тестирования и понаблюдать за процессом принятия решений и ответа на вопросы в реальном времени. По завершении этого интересного эксперимента, наш джуниор-разработчик получит свой вердикт. Мы разберем его сильные и слабые стороны, обсудим, что можно улучшить, и дадим ценные советы для успешного прохождения будущих собеседований. Если видео было для вас полезным, ставьте лайк и поделитесь им с друзьями. Подписывайтесь на наш telegram-канал:

https://t.me/hexlet_ru

____ 🔗 Полезные ссылки: – Комьюнити Хекслета:

https://t.me/hexletcommunity

– Youtube-канал CSSSR:

https://www.youtube.com/channel/UCdkZ6ckHOJ3DjAYxoGeMG0w

– Подробнее про виды тестирования:

https://youtu.be/s2IwpMGtTic

– Портрет тестировщика: зачем нужны QA в команде:

https://youtube.com/live/5nHxv1nqkNM

– Гид по профессии: Инженер по ручному тестированию:

https://ru.hexlet.io/link/5myZx7

– Ещё публичные собеседования:

https://www.youtube.com/playlist?list=PLo6puixMwuSOa_0EH6X4OXzFAmyQGS3a3

____ – 00:00:00 - интро – 00:00:17 - об эксперте и кандидате – 00:01:22 - из инженера-эколога в тестировщики – 00:02:56 - всё, что вы хотели знать о роли тестировщика и его обязанностях – 00:05:26 - на каком этапе разработки подключается тестировщик – 00:07:14 - основы тестирования и базовые принципы тестирования – 00:12:06 - инструменты тестирования – 00:14:39 - тестовая документация – 00:15:45 - из чего состоит тест-кейс – 00:20:04 - что должно быть в баг-репорте – 00:22:17 - как понять, какой из багов разработчик должен взять в работу – 00:26:22 - тестирование требований – 00:28:08 - практика: тест формы и выяснение тест-кейсов – 00:31:11 - практика: тестируем форму на позитивные кейсы – 00:37:55 - практика: тестируем форму на негативные кейсы – 00:41:03 - другие техники тест-дизайна – 00:49:39 - практика: какие виды тестирования можно применить к тестированию формы – 00:54:57 - тестирование API – 00:58:54 - практика: что произойдёт с формой на бэкенде – 01:01:52 - HTTPS-запрос и ответы – 01:07:10 - зачем становиться тестировщиком и какие есть зоны роста – 01:11:40 - резюмируем #тестирование #QA #хекслет

Итоги вебинара в альпине. О чем молчат программисты На днях я проводил вебинар для программистов, лидов и тех директоров для клиентов корпоративных библиотек альпины. Было около 100 человек и мы довольно плотно пообщались полтора часа. Говорили о всяких техниках, которые позволяют уменьшить time to market способами, которые либо не очевидны, либо идут в разрез с общепринятыми концепциями. Здесь я поделюсь теми концепциями, которые вызывали наибольший интерес и дискуссию. Большая часть того, что описывалась в докладе, базируется на том как устроен инжиниринг в букинге https://apptractor.ru/develop/kak-ustroen-inzhiniring-v-booking-com.html Главная идея там, это то, что мы двигаемся быстро, но по пути можем что-то ломать. Остальное придется прочитать по ссылке выше 🙂 И так из важного. Если построить процесс разработки определенным образом, то мы можем значительно ускориться за счет частичного или полного отказа от тестировщиков, стейджинга, синхронных код ревью и деплоев по расписанию после демо дня. Да из каждого пункта есть исключения, например в мобильной разработке тестировщики нужны из-за особенностей релизов, но, в целом, их можно применить почти везде получив значительное ускорение процесса. Например мы прошли этот путь на Хекслете, когда году в 2016 мы убрали стейджинг и не случилось ничего страшного, а стало сильно проще. Быстрее цикл релиза, меньше поддержки инфраструктуры, меньше завязки на то, что кто то проверит за меня, а значит я могу забить на проверку своего кода. Если вам нужно больше доказательств, то пожалуйста https://news.ycombinator.com/item?id=30899362 в фейсбуке стейджинг не используется. https://refactoring.fm/p/do-you-need-staging большая и классная статья про это же. Вообще если погуглитть, окажется что подобных статей и примеров отказа от стейджинга очень много. В следующих постах я буду продолжать развивать эту тему, до тех пор пока мы не пройдемся по всему, что было в докладе. А у вас есть стейджинг?
Show all...
Как устроен инжиниринг в Booking.com

Мы не технологическая компания, мы бизнес-компания с сильной технологией.

Основатель Хекслета, Кирилл Мокевнин, завел канал, и в этом посте (как и всегда, впрочем) ратует за культуру, в которой тестировщики становятся ненужны
Show all...
Choose a Different Plan

Your current plan allows analytics for only 5 channels. To get more, please choose a different plan.