на мою думку, якщо людина дійсно зацікавлена у нашій пропозиції — вона виконає тестове, так як зацікавлена сама. Воно не складне. Ну і я не певен, що хотів би працювати з людиною, котра пошле при питанні про тестове

я мав на увазі проект з тестами. от власне, тести і не запускались

Распространяют эту практику не только на новичков, но и на тех, кому и задание уже давать-то должно быть стыдно.

неодноразово практикували у пошуках AQA. У багатьох з досвідом 3 і більше років, проект не білдився, код написаний на «відєбись». Однозначно варто

ніхто не заперечує екологічні проблеми. Більше того, останні декілька років ЕКО це великий тренд. В тій же Швеції це доволі сильно розвинено. В Україні також набуває популярності.
Ця дівчинка говорить, взагальному правильні речі,
АЛЕ її образ використовується для PR
маленька дівчинка, яка дуже емоційно говорить, через свої проблеми — чудовий маркетинговий хід задля розкручення бренду.

Дуже емоційний виступ

емоційний, можливо тому, що в неї психічні розлади ?
і вас не дивуєте піднята увага до цієї дівчинки ? доречі, її батьки відоми шведські діячі культури, які знають, що таке PR

qa auto умеющих только в c#

За останні декілька тижнів отримав більше 10 пропозицій від рекрутерів у Київ. на c# aqa . Ви рекрутерам скажіть, що криза, бо вони не вкурсі

от. дані потрібно готувати динамічно для тесту. і видаляти після

з поглибленим вивченням німецької мови. Статистика не була окремим предметом, але була в курсі алгебри

То есть, при редактировании это диалоговое окно может появится, а может и нет. Поэтому, в скрипте нужно как то это отловить.

ваш тест стає недермінованим. Напишіть тест, де це вікно ТОЧНО з’являється або не з’являється

Где ж я ещё спрошу, как не тут?!?

в гугла наприклад. Це просте питання, яке доречі покривається шкільним курсом статистики.
На банальні питання ніхто не хоче відповідати

курсы

для архитектора

JS

так собі ембеддед з ардуїно та малинкою...

моноліт — гімно
мікросервіси — гімно
serverless — гімно
soa — гімно

не хочу тягнути з registry та запускати локально всі мікросервіси. Роблю і плачу

угу. плачете, коли витрачаєте 10хв часу на тестування локально, але витрачаєте час на деплой, прогон повільних тестів і логування дефекту. Це буде точно довше ніж локальне тестування

вважаю, що тестування в готовому енвайрменті (production like) дає більш правдиві результати.

в вас ні разу не було такого, що unit, integration, api тести пройшли, а користувачы з продакшену баг заводять? Без UI тестів в складних системах ніяк

не плутайте мухи та котлети. Рівні тестування покликані вирішити різні проблеми. Те, що може виловити UI тест, може не знайти unit тест. але це не означає, що повинен бути лише один рівень тестів. Кожен рівень тестів знаходить різні проблеми. І те, що юзер знаходить дефект, після того як юніт тести пройшли, говорить не про те, що unit тести погані.

классические Unit тесты в общем понимании ломаются при рефакторинге и замедляют разработку, потому что их нужно поддерживать

зіткнулись з такою проблемою. Тому більше націлені на тести на рівні сервісу

А точно ли это нужно?

що саме : спускатись на нижні рівні чи тестувати взагалі ?
якщо спускатись на нижчі рівні — то, так треба. і не одним юніт тестінгом. треба щось між юніт та API рівнем : контракти, сервісні тести, інтеграційні
якщо про тестування взагалі — то взалежності, які цілі переслідуєте. без тестування, пізніше може бути дорожче

Мікросервіси складно тестувати атомарно

в чому проблема підняти їх та тестувати на пряму ? це одна з переваг

Мікросервіси можуть використовувати різні канали зв’язку.

а в чому проблема використовувати різні канали зв’язку ? я певен, що є готові реалізації і для tcp і для RabbitMq і для будь чого іншого

власне, мікросервіси дають змогу легко спускатись на нижчі рівні тестування, а не тестувани все через UI чи API.

Поради для девів також підійдуть. Я з будь яких порад черпаю досвід.
На рахунок дупи. Ну якщо ти вважаєш, що я в дупі це твоя думка. Я не бачу проблем у своїй кар’єрі, пропозицій та оферів достатньо.
Просто не бачу розвиток у вивченні нового фремворка чи була. Якщо це потрібно для проекту — це без проблем. А просто це приносить мало сенсу.
Тому мені цікаво як до цього підходять інші

Я не в дупі. ЗП не маленька, знайти роботу не складає проблеми. Перспективи qa це йти в менеджери, чого я не хочу на даний момент. Йти в девелопмент — для мене це не проблема, якщо говорити про .net . Хіба досвіду мало, але я не бачу це як розвиток, це швидше зміна напрямку.
От власне цікавить рух на межі компетенцій. І цікаво почути як інші це роблять

власне. саме це і було поштовхом до теми.