Привіт, давайте те я вам коротенько розберу цей пул.


чому це на (A)
443 це дефолтний для HTTPS. Якщо він буде заблокований, то половина інтернету ляже, тобто якщо цей порт буде закритий любий рест не буде працювати)
Так що він завжди має бути відкритим, і на ньому зазвичай працює фронт.


Чому не (B) але це лідер на думку багатьох
8080 це типові девелоперські порти. На них часто бігають локальні сервіси, Dev, Staging, тестові API.
У продакшні їх майже не використовують, тому вони іноді блокуються, але не так суворо, як MySQL.

чому не (С)
тут все просто принцепі Порт 22 (SSH) . Це порт для віддаленого доступу до серверів. У багатьох компаніях він або блочиться повністю, або відкритий тільки для обраних IP. Але все ж він часто потрібен адмінам, тому може бути частково доступний.

ну і чому всеж (D) буде правильна відповідь)
3306 це дефолтний порт для бази даних MySQL. І ось якраз тут є нюанс
у нормальному продакшн-середовищі база ніколи не має світитись назовні. Вона має бути доступна тільки зсередини через бек або внутрішню мережу.

А якщо цей порт відкритий назовні, то це пряме запрошення для атак (бо багато сканерів просто брутфорсять MySQL на 3306)і, відповідно, фаєрволи, проксі, або самі провайдери його часто блочать автоматично.

як порада від мене,
Якщо бек слухає на нестандартному порту не лінуйся перевірити доступність ззовні.
Наприклад, можна банально зробити telnet yourhost 3306 або curl, або через Postman.
Бо те, що в тебе локально все літає не гарантія, що Jenkins або інший тестовий середовище дотягнеться.

пишіть коментарі якщо є що додати) а з вас класично серденько.

Привіт, друзі!
Як ваші справи? Попереду два дні вихідних час трохи видихнути, зробити щось для себе, або нарешті розібратися з тим, що давно відкладаєш. Бо ж потім знову понеділок, баги, дедлайни

А тепер трохи болі - пом'ятаєте я якось у вас питався про мишку - ну пост з верху

То ось що я маю вам сказати)
Купив собі нову мишку. Вибір упав на Hator Pulsar 3 Wireless, бо я цю фірму люблю, і крісло в мене від них, і аксесуари були. Але мишка це просто провал.

Колесо скролу як трактор у вусі.
Клік як постріл з гранатомета.
Працювати з нею фізично важко. І це за 2к

Знаєте, як воно буває один фейл, і вже не хочеться нічого більше від бренду. Хоча до цього реально довіряв.
А ще я ж Logitech теж дивився який ви всі хвалили. Там усе чітко: м'який клік, плавний скрол. Але в руку мені вона якось не зайшла.
Та мабуть, піду ще раз попробую. Бо працювати з цим не можна. Просто не можна 🤪

А поки я знову в пошуках мишки ось вам стаття на тему, яка вже стосується наших з вами професійних мізків

https://medium.com/womenintechnology/ais-impact-on-software-testing-the-evolution-of-qa-engineers-sdets-and-automation-architects-71cd91e46401

Якщо коротко, AI не замінить нас, але завжди є це АЛЕ, і варто вже зараз трохи розбиратись у нових підходах, щоб не втрачати темп.

Ну і все, гарного вам ранку, кавусі в руки, вдячності собі за все, що робите
Обняв 🤗

Привіт, друзі і доброго ранку! ☀️ Як ваші справи? Як пройшли вихідні?

Я вчора мав дуже цікаву розмову з другом, колегою-рекрутером. Зачепили одну актуальну і трохи болючу тему джуни, вакансії, конкуренція і.. резюме.

Ну шо я вам скажу
Зараз на одну вакансію прилітає в середньому
- 500 кандидатів-джунів
- 100 мідлів
- 10-20 сеньйорів

І що найцікавіше, навіть у багатьох сеньйорів резюме зроблені за якимись шаблонами зі шкіл/курсів, які взагалі не працюють.

І ось вам відповідь від людини, яка вже 10 років у рекрутингу
Резюме більше 1 сторінки, ми навіть не відкриваємо. Якщо на першій немає ключового йдемо далі.

А ключове це не сертифікати і не 10 рядків про тестрейл і джиру, а коротко про себе/ досвід/ основні скіли/ що ти реально робив

Бо часу у рекрутера 30 секунд максимум.
І якщо не зайшло то до побачення яб би це грубо не звучало. І це не про поганих людей, це про реалії ринку.

Я іноді сам беру участь у технічних інтерв’ю і навіть ще до відкриття CV по LinkedIn вже видно той самий шаблон.
А потім питаєш а що саме ти тестував, як, де, які інструменти?

Актуальність і суть важливіше, ніж лінки на курси або купа загальних фраз.

Який мій поінт до вас
Ти можешь бути крутим скіловим інженером, але твоє резюме може просто не дійти до перегляду.
Тому краще одразу писати суть, хто ти, що вмієш, де був, що зробив.

І залишайте precondition до свого резюме коротке резюме про резюме 😄

І щоб не бути голослівним ось вам крута стаття про те, як правильно скласти резюме і шо про шо

https://medium.com/analysts-corner/an-opinionated-guide-to-writing-your-first-business-analyst-resume-4e3b27682aa0

Якщо у вас схожий досвід діліться в коментарях.
Може, є HR серед підписників, теж цікаво почути їхню точку зору.

Всім гарної неділі і натхнення
Обняв ❤️

Доброго вечора друзі) як ваш день?

Давайте розберемо цей пул коротенько - статистика цікава і зрозуміло чому така

Ну що я маю вам сказать


Чому це не (A)
Ping по домену справді може допомогти, якщо DNS уже оновився. Але якщо ні, тут отримаєте просто помилку, і не дізнаєшся нічого нового.
Пінг може бути заблокований на сервері, і це не означає, що сервіс не працює.


І чому не (С)
Перевірка у браузері надто загальний спосіб. Побачите не відкривається і що далі робити? Це може бути DNS, TLS, backend, що завгодно.(


І так чому не (D) але він в топі по відповідям
Очистити DNS-кеш так це має сенс, але лише після того, як переконався, що DNS уже оновився. Або якщо бачиш, що твій ПК кешує стару адресу

Ну і чому же все таки правильна відповідь (B)
Виконати nslookup або dig це найкращий перший крок, чого спитаєте? ці команди покажуть, куди саме резолвиться домен, чи оновився запис, і з якого DNS-сервера йде відповідь.

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

Всім гарного вечора, головне спокійного)

Обняв 🤗🤗🤗

Я не міг це не закинути)
Підняти вам настрій на вечір - хтось себе взнав??? 🫣🫣🫣

Всім доброго вечора друзі)

Щось давно не було!
Вечірня історія QA. Як перевірити, чи проект світиться назовні і заробити плюсик в репутацію.

ну що я маю вам сказати.

Повертаємось до теми безпеки. І якщо ви QA, який не просто клікає кнопки, а хоче розуміти, що реально з проектом ця історія для вас.

Сьогодні поділюсь одним лайфхаком з реальної практики.

І якось прочитав я статтю, що іноді деви залишають службові файли десь у публічному доступі, просто не подумавши.

Задача яка перевірити, чи проект відкриває щось зайве через nginx. якщо якась службова інфа світиться зовні, це реальна дірка.
І я вирішив це перевірити

і так був файл який реально світиться зовні в якому інфа про версіі, номера сертифікатів і т.д до той чи іншой інфи) в нашому випадку той файлик не велику інфу несе і його прикрили) але це могло чи у вас може буди важливим)

Суть яка
Береш якийсь умовний, непримітний файл. Називаєш його скажімо,

internal-status/health.txt або zxc123/debug.log.

Далі, пробуєш просто постукати по порту напряму.
Наприклад, у вас девсервер був на

10.10.123.123

, і пробуйте

curl -I http://10.10.123.123:443/zxc123/debug.log

І Якщо
200 OK. І пішов контент.
то цей лог доступний зовні. Просто валяється під руками, без авторизації, прямо через NGINX.
Це не баг у коді. Це неправильна конфігурація nginx. просто забули закрити або прибрати шлях у location.

І от тут ви вже не просто QA, а той, хто потенційно врятував реліз від зливу інфи.


А тепер ще цікавіше: .git/

я часто читаю шо деви особливо не опетні забувають прятати .git, і ви можете це перевірити не відкрита службова папка .git/ (а вона часом випадково заливається разом із кодом).

просто зробіть

curl -I http://{{IP}}/.git/config

І якщо знову 200 OK і у відповідь прийшов вміст git-конфігу з remote URL, ім'ям розробника, і навіть ssh-ключем (true story 🫣). то це просто провал)

Це реальна загроза, бо

 .git/HEAD, .git/config, .git/index

- відкривають структуру репозиторію, через них можна відновити весь код і навіть знайти секрети, які колись хтось пушнув

як перевірити, що шось лишнє світиться,

Найпростіше через curl
Умовно

curl -I http://<IP>:<port>/.git/config

Можете перевірити ще кілька

curl -I http://<IP>/.env
curl -I http://<IP>/debug.log
curl -I http://<IP>/logs/latest.log

Якщо щось дає 200 OK бігом в чат з девами


Чому це важливо для QA?
Бо іноді найкращий тест це просто подивитись трохи глибше. Ти можеш реально знайти вразливість, яка обійде всі UI-тести, не вилізе в CI. і яку ніхто навіть не шукав

А ти взяв і знайшов і тебе вже хвалять)

Поінт від мене простий
Навіть не будучи сек'юріті інженером, ви можете знаходити великі речі. Просто треба розуміти, що і навіщо перевіряти.

Такі штуки це реальний плюс до твоєї репутації як QA.

якщо хочете окрему шпаргалку по типових шляхах, які треба перевірити чекаю від вас ❤️

а вообще спробуйте шо у вас і напешіть в коментарях шо вийшло або ви про це взнали і перевіряєте це вже давно)

Бажаю вам гарного вечора!
Обняв 🤗