Співбесіда: Middle Manual Tester #27 — Transcript

Тренувальна співбесіда Middle Manual QA з кандидатом Владом на каналі QA Україна. Реалістичний формат, обговорення досвіду та відповідальностей.

Key Takeaways

Формат співбесід максимально наближений до реальних умов роботи QA.
Досвід кандидата охоплює різні технології та домени, що важливо для Middle Manual QA.
Підготовка до співбесіди є ключовою для успішного проходження, навіть при наявності досвіду.
Тестувальник повинен володіти навичками рев’ю специфікацій, написання тестової документації та баг-трекінгу.
Взаємодія з аудиторією під час ефіру створює додаткову цінність та підтримує живий інтерес.

Summary

Ведучий Олекса Маршиць представляє формат тренувальних онлайн співбесід на каналі QA Україна.
Це 27-ма співбесіда у серії, де беруть участь різні інтерв'юери та кандидати з різними ролями в QA.
Сьогоднішній інтерв'юер – Костянтин, кандидат – Влад, Middle Manual QA з майже трирічним досвідом.
Влад розповідає про свій досвід роботи у чотирьох компаніях, тестування різних проектів (веб, мобайл, бекенд).
Обговорюються домени проектів: healthcare, банківські додатки, криптобанкінг, соціальні мережі тощо.
Кандидат описує свої обов’язки: рев’ю специфікацій, написання тестової документації, тестування API, UI та інтеграцій.
Підкреслюється реалістичність співбесід, які проходять у форматі прямого ефіру з можливістю взаємодії глядачів.
Обговорюється складність пошуку роботи в QA та важливість підготовки до співбесід.
Відео триває близько півтори години, з акцентом на детальне обговорення та роздуми.
Ведучі заохочують глядачів брати участь у чаті та коментарях для живої взаємодії.

Full Transcript — Download SRT & Markdown

Speaker A

Раз-раз, друзі, ми маємо бути в етері насправді. І я, як зазвичай, хочу почути від вас, що все окей, що мене чутно.

Speaker A

Будь ласочку, напишіть в чаті, в коментарях, що все гаразд. Бачу, точніше себе почув, а ваші коментарі я все одно очікую, щоб якось побачити, що ви там живі, очікуєте. А мене звати Олекса Маршиць. Ви на каналі QA Україна і це наша найпопулярніша

Speaker A

аа рубрика тренувальних онлайн співбесід. Ми намагаємося їх робити максимально реалістичними. Попри те, що воно в етері, на Ютубі, такий формат. Але всіх настроюю на те, що ми не робимо тут шоу.

Speaker A

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

Speaker A

Те, що вони різні, е, це через те, що люди різні, різні підходи. У мене специфічний підхід, у Кості, який буде сьогодні вести співбесіду, свій підхід.

Speaker A

Тому ми просто різні. І це цікаво, що різні інтерв'юєри є на цьому каналі з рівними рівнями. Обов'язково подивіться списки відтворення, там список етерів.

Speaker A

Ее це вже 27-ма така співбесіда. І вони є і з автоматизаторами, і з тими лідами, і кіоменеджерами, і з ким там тільки немає. Гаразд. А-а, бачу, що ви написали. Олександре, дякую за коментар.

Speaker A

А я запрошую на цю, е, сцену. Так, хто у нас сьогодні? Я вже сказав, а ви вже бачили це, е, на обкладинці та в описі.

Speaker A

Інтерв'юер у нас Костянтин. Костя, привіт. Всім. Привіт. От. А напишіть, хто скучив за Костою і очікував наступної співбесіди. Я знаю, що таке є. А хто очікував і щоб сказати знову Костя, то також напишіть. Так, а також наш кандидат сьогодні Влад. Влад,

Speaker A

вітаю всім. Привіт. Привіт. Так, Влад, у нас Middle Manual QA. Ти зараз в пошуку роботи, правильно?

Speaker A

Вже ні, але нещодавно, нещодавно цим займався. Я не знаю, якщо в чаті є люди, які теж шукали або шукають, вони мене зрозуміють, що зараз дуже важко це робити. Ее це мій вже четверта буде моя робота. Е, і інші три рази були дуже

Speaker A

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

Speaker A

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

Speaker A

Ну, ти якраз зараз Костю зможеш довести чи не довести. Зараз побачимо, наскільки ти можеш далі бути впевненим в собі. От. Але я скажу так, що є такий невеличкий секрет, що більшість кандидатів, які приходять на такі співбесіди, е-е за моїм таким

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Ну тому тут, в принципі, супер. Так, я вас залишаю. У нас є приблизно плюс-мінус півтори години, ми так плануємо, але жорстко не фіксуємося на цю співбесіду, щоб ми могли не просто пройтися по списку, а трохи по розкачатися.

Speaker A

Покачатися, хотів сказати, покачатися, а поспілкуватися, поміркувати. Тому, друзі, можете готувати собі там, що потрібно вам для довгого перегляду.

Speaker A

Спілкуйтеся в коментарях. Я також можу до вас долучатися. Та і все. Я тоді уходжу на залаштунки, залишаю вас. А-а, все, гарного вечора.

Speaker A

Якщо що, то кличте, я тут. Бувайте. До зустрічі. Угу. Ну що ж, друзі, всім доброго вечора.

Speaker A

Давайте починати. І я би хотів задати перше питання. Воно буде пов'язано з твоїм досвідом. Розкажи коротко про свій досвід.

Speaker A

Окей. Е, я працюю загалом майже 3 роки, як в мене. Окей. Е, наразі це буде моя четверта компанія, в якій я працюю.

Speaker A

Проектів за цей час вони були маленькі і великі, і середні. Загалом їх було десь 11.

Speaker A

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

Speaker A

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

Speaker A

Також там один додаток був з трейдінгом пов'язаний, один банківський додаток був з інтеграцією крипти, такий дуже великий, е, кросплатформений. Також були додатки там схожі на Instagram, на work.ua і так далі. Тому, в принципі, якось так.

Speaker A

Вони, може, я вже сказав, не пам'ятаю, були кросплатформені майже всі. Тому я, в принципі, отримав рівний досвід тестування вебу, мобайлу іду.

Speaker A

Ну, деякі проекти там були, може, чисто Web або чисто mobile, але це була менша кількість.

Speaker A

Ну, тобто я так розумію, що у тебе в кожній компанії був релевантний досвід використання AI, використання бекенд-сервісів, бекенду взагалі. Та е да, в попередній мій мобайл, правильно?

Speaker A

Да, да. В попередній компанії це був криптобанківський додаток. Там якраз теж була кросплатформена апка і я все плюс-мінус тестив в різних, ну, в рівних пропорціях. А якщо брати останній проект, останню компанію, то це Camp чисто наве.

Speaker A

Угу. І там ще була інтеграція AI трошки для того, щоб документами працювати великими. Але там не було мобайлу і бекенд там мало тестував, але, ну, в принципі, там це було недовго.

Speaker A

Мені насправді завжди дивно від айчарів, ну, чути таке питання. Воно дуже цікаве. Я думаю, що і всі, хто зараз нас дивиться, вони теж їм його задавали. Та а скільки у вас досвіду тестування бекенду, фронтенду і мобільних застосунків? Та, як для мене,

Speaker A

ну, в моєму досвіді там відбувається майже таке аналогічне, яке в тебе, що всюди була, ну, всюди була десь апішка, десь бекенд, десь веб, та і був mobile.

Speaker A

Я, якщо мене питають так письмово, сорі, то я пишу іноді, щоб порохувати з них 33,3%.

Speaker A

Окей. Окей. Добре, давай почнемо з таких, не знаю, стандартних речей, які має вміти тестувальник. Розкажи, будь ласка, за свій релевантний досвід тестувальника на проекті. Чи які твої responsibilities були?

Speaker A

Окей. На більшості проектів, де були нормальні процеси, якщо я заходив на нульовому спринті, то починалося все з того, що я рев'ювив специфікацію до проєкту і дизайну,

Speaker A

лишав там якісь коменти, валідував там user story по певним там критеріям. Якщо щось там мені не подобалось з точки зору того, що вони там неповні або не вистачає якихось там сценаріїв і так далі, то я лишав на це коменти. Ми потім

Speaker A

там могли робити окремі сесії з БЕм або продменеджером або продакт-менеджером в залежності від проєкту, хто писав ці сторікли, ці всі коменти так само з дизайнерами.

Speaker A

Потім, коли вже де ви починали розробляти таски, піднімали ви, то там здебільшого спочатку робився бекенд, робились якісь перші там апішки на signin, signup і так далі і реєстрацію там юзера, то починав це все тестити поетапно.

Speaker A

Е, якщо, ее, ну в більшості проєктів час дозволяв це робити, то спочатку писалась документація. Тобто там зазвичай одразу після того, як прорев'ю специфікацію або перед тим, як брати таски там. Ну, на різних проєктах це було по-різному, в залежності від тайм-менеджменту,

Speaker A

але загалом майже завжди перед тим, як там брати таску або перед на початку спринту там виділявся якийсь час ще, щоб написати чек-листи або тесткейси, е-е, або в екселі, або в Trello або в Testmo, залежало від компанії.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

повна регресія. Здебільшого там, якщо ми заливали там на інший NV stage demo або прод після цього ще там короткий смоук робив або я сам, або якщо наскільки, то ми там ділились з хлопцями, як це, ну, хто що буде

Speaker A

тестити. Тому якось так. Окей, добре. А мені цікаво, ти в більшості працював як один QA на проекті чи працював з командою?

Speaker A

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

Speaker A

Угу. Може на чотирьох, не помню точно. Добре, таке питання. Е-е, назви, будь ласка, якийсь такий челендж та або виклик, в якому ти прийняв, ну, якби саме більше відповідальності на проекті.

Speaker A

Ну, от, наприклад, в тебе були якісь задачі або ви реалізували якусь суперфечу та і ти взяв ініціативу, наприклад, випустити цю віщу або щось такого вроді.

Speaker A

Ну, якщо я був на проекті один, то це загалом майже завжди було, тому що ти по суті як кінцева точка перед тим, як віддавати замовнику build або показувати демо. І тому завжди, наприклад, ми там хочемо на стейдж завити все, то тебе

Speaker A

питають, чи готово все, чи там ти все протестив, там які ти фічі тестив там, чи все було покрито там тесткейсами і ти по всьому пройшовся. Ти там кажеш: "Так, такі є баги, вони там не критичні або критичні". Тому там, якщо ми там їх всі

Speaker A

пофіксуємо, ми заливаємось далі, там їх фіксять і так далі, і так далі. І, ну, якщо більш-менш десь були часті оновлення проду, то це завжди проходило там скрізь мене або там скрізь мене і там колегу по кілька моїх колег. І ми завжди ділили

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

це все кастомери різні. Іноді це доволі ж важко буває. Ну, демо також я показував кілька разів.

Speaker A

Вибач, в чому саме важкість? Назви якийсь важкий момент, який з яким ти стикнувся при комунікації з кастомером.

Speaker A

Як ти з цього? Іноді трошки якась агресивність. Це може бути, коли ти, наприклад, не розумієш повністю людину.

Speaker A

Ее купа тексту, дуже дуже велика активність, ну, постійне пінгування. Що ти, а що ти там, а що там? Ну, оце такі речі. Як з цього ти вийшов?

Speaker A

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

Speaker A

заспокоююсь. І типу, ну, коли я там дуже сильно стресую, я там можу на півгодини, годину, кілька годин бу, ну, погано себе почувати там, да, але потім я беру якось себе в руки. Ну, не знаю, як це пояснити, просто себе навчив. А з точки

Speaker A

зору кастомерів, ну, я просто розумів, що немає виходу, бо це кастомери. І я намагався нічого їм не доказувати, е, в плані демології там якоїсь, да. Там простіше іноді написати: "Окей, там я тебе зрозумів, я там піду".

Speaker A

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

Speaker A

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

Speaker A

Угу. Добре. Давай, давай тоді порухаємося. Я пропоную так більше такі давай специфічні питання для QA. Та і від цього будемо відштовхатись далі дон до мобільного тестування і так дальше.

Speaker A

Окей. А окей. Я бачув, що в тебе є в твому резюме вказано, що ти писав тест-стратегію.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Ну, це не зовсім так. Ну, значить, це в нас є тест-план. Та, наприклад, що таке тестплан по суті?

Speaker A

Ну, це планування перед, ну, він робиться перед тим, як почнеться тестування, коли почався проект і там описуються сіфічі, як ми будемо їх тестити, там acceptance критерія, там коли, ну, критерій того, коли ми будемо починати тестування, коли ми будемо

Speaker A

завершувати тестування. Угу. Ну, да. Там є 16, потім все підпи. Понятно, да? І я, можливо, це просто перепутав. І знаєш, типу я мав на увазі тестплан і роботу з ним. Тестплан? Ні, проворизма вказано, що strategy. Вот стратегія - це

Speaker A

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

Speaker A

стратегія тестування для, можна сказати, для різних областей тестування. Вот. І це відрізняється від тестплану набагато.

Speaker A

Окей, добре. Давайте йдемо далі. А ти переважно працював по якій моделі розробки програмного забезпечення?

Speaker A

Подрайлу і скраму. Добре. Назви мені відмінність між Agilйлом та Скрамом. Ну, скрам це він входить в айл. В айл входить скрам і канбан. В скрамі у нас є спринти, а в канбані немає. Ось тому я маю на увазі, що по agile і його

Speaker A

компоненту як скрам. Добре. А що ти маєш на увазі? Що таке? Ну, це методологія розробки програмного забезпечення додатків того, як відбуваються процеси.

Speaker A

Мені здається, як методологія, він, ну, не зовсім вірний. Чому? Бо методологія має якісь певні методи та умови.

Speaker A

Ну, можливо, це стратегія або вид менеджменту, який застосовується до того, як організувати все. Є в нас чотири рекомендації, 12 принципів. Та чотири рекомендації, кажуть, там люди і взаємодія між ними там важливіше, ніж процесо інструменти там. Ну, це якли

Speaker A

набір правил і рекомендацій тоді, да, того, як нам краще певний підхід. Тоді може краще слово підійде.

Speaker A

Підхід. Окей. Ти Ну, але сорі в усій теорії, коли де б ти не не читав про Айл, там буде написано, що це методологія, тому якось так.

Speaker A

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

Speaker A

можеш почитати, до речі. Ні, я, до речі, туди ні разу не заходив, да? О, бачиш, да? Чому тренурують цих 12 принципів, якщо вони дуже круті, насправді.

Speaker A

Е-е, вот. Окей, добре. Рухаємося тоді далі. Ну, тоді ти, значить, працював по ітераційним кримітальним моделям, да? В нас скрам, камбам і так дальше. Окей, добре. Як ти імплемен як взагалі у тебе було імплементовано іc іменно в скрам або як виживати тестувальнику в

Speaker A

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

Speaker A

З іншого боку, ну, з одного боку це плюс, а з іншого боку це певний стрес для команди, тому що ще, ну, сам SAM Agile, він, ну, все так організовано, що є часті релізу. Тобто це там один із принципів,

Speaker A

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

Speaker A

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

Speaker A

Наприклад, якщо там BA описує, да, і немає часу в нього одразу все описати, як це видалі має бути. Але, ну, насправді там в реальності він це робить поетапно. Ну, і QA так само поетапно.

Speaker A

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

Speaker A

пріоритизовану і те, що треба робити спочатку ви їх обговорюєте, чи все готово, які є блокери, які є ризики.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

так, як він хотів і так далі. Добре. Які основніта етапи STLC та ти і ну в тебе були імплементовані в роботу, які ти підтримуєш, а які ні? Чи можна STLC імплементувати в ітераційно-інкриментальній моделі? Ну, ми б зрозуміли, що, да, можна. І, в

Speaker A

принципі, ти обозначив, як воно працює. А можеш мені назвати, що саме було імплементовано у вас?

Speaker A

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

Speaker A

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

Speaker A

А от саме, ну, дивись, до нас потрапила старя наприклад тагу. От що ти робиш саме з нею? От, ну, ми дивимося на текст, та ну ми читаємо там, аналізуємо, яким самим чином, чим ти користуєшся. От я би хотів дізнатись про

Speaker A

практичний якийсь от експеримент в своїй роботі. От як ти це робиш? От ти розкажеш, я тоже розкажу, як я роблю.

Speaker A

Давай. Окей. Е, дивись, якщо заходить сторя, зазвичай це не сторя, а якийсь там, да, набір сторей. Якщо це якась там change request або щось простеньке, тоді це там одна сторя, да. Але загалом, наприклад, я починаю там з першої і

Speaker A

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

Speaker A

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

Speaker A

Є певні критерії, по яким вони мають бути якісні. І якщо якщо якісь критерії не відповідають, то ми працюємо над тим, щоб вони відповідали. І коли я, наприклад, вже все вичитав, то я починаю, ну, весь scope на спнт я

Speaker A

вичитав, там все більш-менш окей. B щось править, я починаю писати там тесткейш, якщо є час, якщо немає, там хоча б в форматі чистів якихось коротких.

Speaker A

По після того, як я це завершив, я починаю биратися до тасок в пріоритеті. Там, якщо це бекенд, то дивлюсь там беend. Якщо це frontend, дивлюсь front.

Speaker A

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

Speaker A

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

Speaker A

тестування в нас є, да? Ну і відправляємо репорт. Якщо є баги, то їх фіксять. Ми робимо ретести. Якщо там щось посерйозне, робимо ретести там таски або цього фло, або цієї PG. І потім там все закриваємо, якщо є, ну, якщо все окей. Потім, якщо в

Speaker A

нас є там на інший LН в заливка, то потрібно там якийсь або смоук зробити, або міні-регрес.

Speaker A

Ее, ну, якщо це не прот. Якщо це на прот, то тоді потрібно виділяти там окремо час на те, щоб робити повний регрес бажано. Якщо немає часу, то якось пріоритизувати те, що ми будемо робити регрес. Ну, а потім після того, як, наприклад, ми показали

Speaker A

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

Speaker A

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

Speaker A

все правильно розвернули і це було завчасно. Якщо є діаграма, то конечно, звичайно. Вот. Лайк. Е, ну ми це прям ми це прямо в кофлюнс робили або вtion. Тобто я будь-які питання, які в мене з'являлися, я я виділяв цей текст і прямо туди це

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

І ще добре, коли вона від розробника є, тобто не тільки один к думає та в плані того, а як як це буде імплементовано.

Speaker A

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

Speaker A

Це є помилкове, ну, бачення. Це насправді є така проблема в IT, та що розробник має писати код. Вот і всь. От все, що він має робити, це писать. Це, ну, неправильне твердження. Та чомусь, ну, його підтримують більшість там якісь

Speaker A

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

Speaker A

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

Speaker A

таску і побачив, зробив все, що в ній написано, типа, і до побачення. Ні, але це брдова тема, насправді. Чому?

Speaker A

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

Speaker A

класними відлагодженими процесами, де во не надо думати за це. Йому надо писати код, да? Вот таке може бути. Та але якщо ми працюємо в ну пожайлу в скрану, якщо знайде аку, то скинь мені її.

Speaker A

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

Speaker A

сервіс під'їде, чи ні? І так дальше. Де завжди має тоже залишати якийсь слід за собою. Ну, тобто що він був залучений в цю задачу, а не тільки там бізнес анаaltлікua, там і трошки PMA. Окей, добре. Це це класно. А-а, пум-пум-пум.

Speaker A

Давай далі підемо. Давай тоді перейдемо до питань стосовно регресу. От мене цікавить, як у вас був організований, ну, взагалі регрес та що ти думаєш про нього? Вот які складності з ним бувають?

Speaker A

організований був дуже по-різному насправді. Тому от це таке суб'єктивне питання, але якщо об'єктивно відповідати, то він по ідеї має робитися перед кожним оновленням наступного ее і не тільки перед продом. Насправді в реальності в усіх компаніях майже де я

Speaker A

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

Speaker A

разом ми робили регрес. Але у нас було там в тестмо написано десь може 1500 чи 1400 тесткейсів. І ми не могли в трьох е їх всі проходити. Ну, кожен раз отак.

Speaker A

Угу. А на автоматизацію не хотів клієнт виділяти кошти, тому її не було зроблено. І так вийшло, що нам доводилося якби кожен раз пріоритети міняти регресії. Ми робили тестрани і кожен раз митрошки там щось викидували звідти, щоб встигнути. І ми ділилися. Це дуже цікаво

Speaker A

насправді. Яким чином ви вирішували, що викинути з цього, що ні? Яким самим принципом ви користувались?

Speaker A

Ну, найперший - це пріоритети, які до кожного тесткейса проставлені. І, наприклад, low і lowest відкидалися одразу.

Speaker A

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

Speaker A

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

Speaker A

в цьому скопі, в цьому спринті, а детально тестити те, що міняли в цьому спринті і що до нього дотичне. Ну, але для цього потрібно було гарне розуміння самого додатку, що з цим, ну, що з чим пов'язане, да? Це якраз та відповідь, яку я хотів

Speaker A

почути. Ну, тобто що ви дійсно вдумчиво робили регресію при великій кількісті кейсів та ви розуміли, яка частина функціоналу піддавала змінам, що могло ефектити це чи інше. Та і таким чином скорочували регрес. М. Але все одно через оцей прикол, що щось ми

Speaker A

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

Speaker A

І потім тамнка є. Та він заходи в додаток, хопбах зразу. І ти такий: "Та ну якось так". А ви туда дивіться, да? А туда ні?

Speaker A

Е, окей, добре. Е-е, давай тоді, ну, в принципі, в принципі все тут, тут по цьому блоку все. Е, давай перейдемо до бекенду. З чим ти з, ну, що, з чим ти працював в бекенді?

Speaker A

Змено в основному трошки в інсомні і в слагером. Ну, зі сwagром. Добре. Добре. Давай по архітектурі пройдемося. Це мікросервісна архітектура, це монолітна архітектура.

Speaker A

Це просто клієнт-серверна архітектура. просто клієнт серверну, е, з мікросервісною не працював, чисто там теоретично трошки знаю, що воно. А загалом це всі були додатки клієнт серверна архітектура, бекенд на сервері, а вже там клієнт це мобільна апка або веб.

Speaker A

А-а, окей, добре. А, пум-пум-пум. Розкажи мені, будь ласка, про клієнт серверної архітектури. Що ти знаєш?

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Так. Ну окей. Добре. А скільки рівнів може бути в клієнт серверній архітектурі? Ось дається п'ять, але загалом це три.

Speaker A

Це сервер, база даних і клієнт. А може бути а може бути двохрівнева архітектура? Ну, наприклад, клієнт сервер зразу.

Speaker A

Може, може, якщо батаних буде на тому ж сервері. Окей. А чому п'ять, а не більше? Може бути там біля, я не пам'ятаю, якщо чесно. І там далі оце все, що 45. Я не пам'ятаю, чого там 4,5. Якщо можеш відповісти, буде круто.

Speaker A

Або потім почитаю. Ну насправді в нас може бути дуже багато сервісів. Та може бути, ну, наприклад, в нас може бути дві різних базу, другариз, наприклад. Да.

Speaker A

Типу кожен кожен сервіс або сервак - це вже інший рівень, типу як? Да. Ну, відповідно, інший рівень. Тобто в нас може бути фронт на одному сервері, бек на іншому, бек, наприклад, ще якісь ще в нас мобіла вообще на іншому фронту,

Speaker A

да, бек іншому. Та в нас може бути монга, може бути постгрес, може бути Oracle там і так дальше. І тобто ми між всіма ними будемо комунікувати. Ну, якщо так system там 30 там десь зрозумів, да. Ну, якраз більшість останніх

Speaker A

проектів були такими якраз що було багато рівних інтеграцій, декілька БД, тому, ну, я навіть тоді не знав, що це було багато рівного, а не трьох рівного.

Speaker A

А, окей. Е-е, я Давай трошки про банкінг. Та цікаво, е-е, ти працював з фізичними, юридичними особами. Ти це вказував в своєму резюме, правильно?

Speaker A

Так, це було в передостанньому додатку. Ми там ділили юзерів на бізнес і на фізичних осіб. Угу.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

бачити, не можуть, що можуть змінювати, що не можуть. От такі речі. З перш налаштуванням, я так розумію. Та да.

Speaker A

Окей, добре. Е, назви складності, будь ласка. які були при тестуванні такого, ну, окрім приміщення, чи були якісь унікальні складності або якісь те, добре унікальні складності. Та а потім друге питання - це які інструменти ти юзав для того, щоби можливо собі конфігурювати

Speaker A

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

Speaker A

комісії і потім це все також хендлити, щоб потім це не потрапило на прот. Тобто, наприклад, щоб робити якісь транзакції і так далі, ми робили всюди мінімуми там 1 цент, якщо це там були долари, да, ее комісії також мінімальні,

Speaker A

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

Speaker A

Тобто від нас був запит на те, щоб це все зробити. А де вам потрібно було це все конфігурувати?

Speaker A

Е-е, добре. А через який 30 part system? Та а у вас проходила оплата? Це strike був чи щось інше? На одном, на більшості проектів це був страйк. Один був в мене проект Zom Railos. Це був це таке схоже

Speaker A

на страйп в Кана в Канаді. А якщо братибанський дуже Але дуже дивно це чути, тому що у самого страйпа є сбокс. Та да, да, да. А а я зараз кажу про оце що все, що я казав, це я казав про

Speaker A

попередній криптокобанківський додаток і ми там strйe не юзали. Тобто там у нас були сервіси.

Speaker A

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

Speaker A

В нього під капотом були свої фіатні кошти, а на наших получається, що в нашій системі були криптогроші на оцьому сервісі Wi-Fi юзерів, да, які заводили туди із своїх гаманців. І потім оці два сервіси між собою комунікували, щоб розуміти, що оц

Speaker A

у цього юзера, а в нашому додатку він створився потім на Wi-Fi. Цер А і він також створений в базі даних цього банківського сервісу. Це зер і вони між собою ще мають прокомунікувати, скільки в цього юзера а реально лежить

Speaker A

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

Speaker A

доводити, підв'язати і ти міг реально йти вже платити кудись або в онлайн-магазині навіть замовляти. Тому ми там не був потрібний страйп і там не було сенбокса в плані оплати. Е, тобто ми ми реально криптою вели оплати і перекидували юзером крипту

Speaker A

і на інші гаманці. І завжди це були реальні кошти і комісія реальна. Тому нам потрібно було оце все зменшити.

Speaker A

Я так зрозумів, ніякого тестового рішення не було на це. Ну, тобто ні, не було. Можливо, воно теоретично існувало, але мені воно не було відомим.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

А, окей, добре. Чи окей, ти говорив за Мокі. Цікаво, ти Мокі сам створював чи, е, робили це розробники?

Speaker A

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

Speaker A

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

Speaker A

Ні, я підміняв чисто статус коди і respons або request body. Це через прокював через proxim, да.

Speaker A

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

Speaker A

Ну от давай уявимо з тобою таку ситуацію. Тобі надо протестувати 50 нотифікейшнів. Угу. На ці нотифікейшени, ну відповідно є якась певна реакція бекенда.

Speaker A

Ну я на бекенді є якісь івенти. Коли вони три горяться, то він вже там фабе це надсилає і тобі приходить пуш. Е, як це замонтувати, чесно кажучи, я не зможу відповісти, бо я так не робив. Загалом у нас, якщо були на ректах,

Speaker A

а давай подумаємо. Ну, дивись, давай. Я думаю, що в проксі по ідеї можна, да? Добре, дивись, ми не говоримо за якісь певні івенти. Та в нас не буде там якогось певно сталого з'єднання через вебсоки.

Speaker A

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

Speaker A

відправлений бекендом для нас, буде відповідний notтифіication. Та яким чином? Давай собі подумаємо, яким чином ми би це могли би, ну, імітувати та для того, щоб це перевірити.

Speaker A

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

Speaker A

іншим юзером якийсь комент і і іншому юзеру прийде, наприклад, пуш, як ти сказав, да? Я можу тим юзером створити сесію, зробити ним ее запустити там тестран, щоб ця пішка, наприклад, там 50 разів провізалася або там набір з 10

Speaker A

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

Speaker A

Ми не говоримо за push notтифіication, ми говоримо за нотів на екрані користувача. За простий нотів.

Speaker A

За нотів. Так. Ну я просто можливо Та ти неправильно зрозумів, напевно. Ти зразу думав pш notification. Та через та це ти правий. Та ми можемо якусь запустити в принципі скрипта, який нам буде присилати.

Speaker A

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

Speaker A

це зробити, наприклад, проксувати 50 запитів та, наприклад, на ту ж саму апішку, та яка буде повертати нам різні результати. Відповідно, а це тіпа в проці можна зробити, да?

Speaker A

Так. Ну, я ніколи так не користувався, тому не буду вигадувати. Ну, прикольно, да? Можна замокати. От, наприклад, е-е ми за допомогою Редекса пошукаємо реквест та і оцей реквест, наприклад, ми підкладемо отаку відповідь, а потім ще одну підкладемо, а потім ще одну. При

Speaker A

кожному звертанні будуть різні. Наприклад, це це можна зробити там або в Чарліку, або в проксімену, в залежності користуюсь.

Speaker A

Е-е, окей. Ні, ну було цікаво просто. Ну от про Firebase та пощі. Класно, дякую. Сказав.

Speaker A

Це було ще одне питання, але це вже мобіль. Я тебе я тебе не так тоді зрозумів.

Speaker A

Сорі. Ні, все окей. Е, добре. Ту-ту-ту. Опиши мені, будь ласка, найскладніше тестування бекенду, яке ти робив.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

бу бу бу бу будь-якого банку або е криптовалютного банку, ну неважливо. Для Фінтеху це реальна проблема. Та тому що нам треба унікальні конфігурації з різними користувачами та різними кейсами по флоу. Та і у вас була ця проблема та

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

криптою певний юзер. Ну, можливо, да, це було б трошки швидше, але, е, ну, ми були в такій, ну, короче, не буду там деталі влазити просто.

Speaker A

Складна ситуація насправді. Ну, я розумію твій досвід. Та то треба було робити таски, а не думати за автоматизацію. Це треба час ніхто не давав і так дальше. Надо було біжать, біжать, бежать, біжать. І, ну, у нас навіть мліт, який шарив хорошо

Speaker A

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

Speaker A

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

Speaker A

все меншити водночас якось тому Да таки не не ну зі всьєю повагою до твого ліда там просто не зміг продати цю ідею там людям які Да. Е-е окей добре.

Speaker A

А так, давай ще парочку питань по бекенду. З якими базами ти працював? Реляційними. З нереляційними. Один раз був проект перші компанії, але це був просто сервіс, який повертав нам пачку вже даних по запиту. Тобто я напряму ним не

Speaker A

не маніпулював ніяк, але ну я просто там теоретично знаю, що що вони таке, для чого вони використовуються, а працював лише з SQL.

Speaker A

Угу. Ну, з реляційним. Добре. Хто ліпше пише SQL е запити? Ти чи чат GPT?

Speaker A

Звісно, чат GPT. Я я хочу пожартувати бекндер мій. Окей. Чи користуєшся ти аїшкою для написання SQL запитів, чогось такого?

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Тобі не потрібно там, я не знаю, якісь підзапити писати і так далі. Ну, може комусь потрібно. Це я про свій досвід кажу.

Speaker A

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

Speaker A

Ні, ну в мене, наприклад, в роботі треба робити складні SQL запити. Угу. Угу. Зрозуміло. Мені треба користуватися. Та бо ти всьо просто в голові. Ну реально ні ж все одно запам'ятовуєш, як воно працює, да? З часом.

Speaker A

Ну з часом, конечно, запам'ятовуєш, та але для якихось таких певних рутинних речей це абсолютно it's окей. Так що, якщо ви навіть на співбесіді та і ви хочете, ну, показати результат, то не стидайтесь. Можете відкривати і користуватися. Це класна. Ну, от я би,

Speaker A

а, я казав, я казав, що використовую чат GPT до мене інтерв'юєр, що докопалося, що типа, а як ти валідуєш, що він тобі на фігню каже, а що ти сам не можеш, типа, а, а типу не будеш становитися ме

Speaker A

менш скіловим цього? Ні, насправді ні, насправді це проблема. Та це зловживання називається. Ну, відповідно, якщо ти не знаєш основ програмування, та тобі важко буде, наприклад, навіть запустити той скрипт, який тобі написав там ее той же самий АІ. Та якщо ти не розумієш, що основі

Speaker A

SQL, тобі складно буде навіть скласти запит до нього, та щоб тобі щось написав і так дальше. І в відповідності тут потрібна завжди чесність в експертизі.

Speaker A

Та в мене є достатньо експертизи, але мені впадло писати цей джой на там 25 строк. Типа я йду собі в АІ та і просто пишу типа напиши мені це, будь ласка.

Speaker A

Да. Він напише ідеально мені правильно без помилок. Та що я можу сам тоже там в кінці робочого дня вже тупить просто. Ну напиши мені, чого б не Ну у всьому має бути. І тут теж.

Speaker A

Ну да. Тому я не розумію таких людей. Ну- ні, насправді питання релевантне, напевно, до досвіду дівчинки, а може хлопчика, я не знаю, хто тобі таке задавав. І, е-е, напевно, хтось зловживав компанії штучним інтелектом і так дальше. Або в людини таке певне

Speaker A

мислення в тому плані є, що ні-н, це небезпечно, ви ж отопієте, ви ж не будете думати. Але є доля в цьому правди і вірогідності, та що людина перестає думати, вона пере ну довіряє а та чим собі, але це ну потім переростає все ж

Speaker A

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

Speaker A

Ні, звичайно, якщо він вирішує більшість, ну, крутих, реально рутинних задач і робить це на ура, так чому його не юзать. Е-е, от добро. Добре. Ее, давай тоді мувнимся. Боже ж, ну, щось Ні, от мені з бекенду щось недостатньо.

Speaker A

Я люблю бекенд. І я би хотів ще щось задати тобі стосовно ресту. Хотів задати тобі, що таке рест.

Speaker A

Ну, рест - це як під тип клієнт серверної архітектури, якщо можна так сказати. Це доволі таке складно тут пояснити, але загалом, ну, це архітектура в нас, е, в якій є конкретні правила. ее як взаємодіяти запі і як їх будувати. Тобто в нас є там

Speaker A

є певні типи запитів, там get post, put patch, delete options. Угу. Ее є певні статус коди і є певний формат, що в тебе є там у ур є статус код, є хедери, є respons body або request body, якщо це там пост або пут,

Speaker A

або пач. Ну і таким чином є так який певний контракт контракт між бекендом і фронтдом, як цим всм взаємодіяти.

Speaker A

Е, плюс тут є ще такі поняття, як там шкі і так далі. Ну, але це вже, мабуть, більше в клієнт сервер.

Speaker A

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

Speaker A

Ні, дивіться, дивиться. Rest - це архітектурний підхід. Вот і все. Вот це дуже просто. Це просто набір правил, як має бути організована взаємодія між клієнтом та сервером. І по цьому своду правил, та якщо ми підтримаємо convention та нашому

Speaker A

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

Speaker A

відповідні статус коди, які у нас не може бути там 603 помилка - це, ну, типа сьогодні Валера не в настрої, там 74 в нас вечарки ці дні і так дальше. Тобто конвенція ее яка визначає. І е-е так само з

Speaker A

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

Speaker A

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

Speaker A

Якщо, ну, тому що він завжди повертає, ну, майже як не буду казати завжди, він зачасту повертає респонс про сутність, е, яку ти там хотів змінити або створити. Е-е, якщо А можна так не робить, а можна А можна delete постом зробити?

Speaker A

Там можна, якщо в баді там буде передаватися щось, що стригерить бенд, видалити, можна. Це типа бенда все одно по суті. Це е ще одне питання от стосовно методів.

Speaker A

Та ее чи користувався ти хедом і опшеном? Ні, ні разу, якщо чесно. І конектор ні разу.

Speaker A

Ні. Добре, давай. Ну добре. Ще таке одне питаннячко. Воно буде пов'язано з вебсокетом. Що таке вебсокет? Та розкажи, будь ласка.

Speaker A

Websocket це по суті він потрібен для того, щоб в реальному часі робити апдейти для юзера.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

А це є протокол передачі даних. Як ти думаєш? Я думаю, що да. Він поверх по ідеї працює. Е, це по суті протокол напевно да?

Speaker A

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

Speaker A

А вебки - це теж протокол по по такій логіці чи ні? Чи це як метод?

Speaker A

Я думаю, що це більш метод. Ну, ну, зками ще працював. Ну, HTTPS - це протокол цей наш базовий, на якому зараз всі там більшість вебсайтів працюють.

Speaker A

А також є HTTP, який просто Ой, да, HTTP, який просто не захищений. Якщо брати TCP, то це передача даних протокол, який його суть в тому, що інформація передається цілісною і в правильному порядку, але повільно і вона захищена.

Speaker A

Е якщо наприклад, брати UDP, то там інформація передається хаотично, ну, з якоїсь точки зору хаотично і немає перевірки того, що, наприклад, клієнт її отримав. Тобто, наприклад, якщо в нас є стрім або там, ну, щось подібне, де потрібно швидко

Speaker A

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

Speaker A

Також є FTP протокол. Він так само, як і TCP, працює, але він там для передачі файлів якихось і так далі використовується.

Speaker A

Він теж захищений і теж там є перевірка на те, що всі файли там перейшли, що вони цілісні і так далі. Ну, IP по суті це теж протокол.

Speaker A

Та я думаю, я думаю, достатньо. Дякую. Окей, добре. Це, ну, насправді класно, що ти знаєш окрім HTTP ще інші протоколи передачі даних. М це насправді круто. Я тобі лайк від мене.

Speaker A

Да, да. Ні, ну більшість, ну я от співбесідую людей, та от і дехто каже: "Ну, я я це знаю того, що весь час на співбесідах мене чогось про це все питають. Хоча в роботі жодного разу, чесно тобі кажу, вообще не треба било

Speaker A

це". Ну, типа, я не знаю, як це сказати, щоб не показатися типа дурним, але я навіть міг не знати, що таке https, щоб це тестувати, типа. Ну, е, дивись, тут такий принцип існує. Який принцип існує? Це не то, щоби ви,

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

приміняєш. Та ну і відповідно стаєш більш ефективний в своїй сфері і маєш більше розуміння в тому, що ти робиш.

Speaker A

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

Speaker A

ми будемо по ньому по HTTP там або HTP. Вот. І, да, тут треба от різницю цього розуміти, да, типа, а, чого в мене за така фігня? Типа, от я реквест шлю, а вони відправляються де на пошті, а як в тому бекенді подивитися і

Speaker A

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

Speaker A

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

Speaker A

цьому, то просто, ну, в мене єсть сертифікат STQB, клас, але я використовуюсь тобо там десь 10%, типа і толку з цього. А, але, ну, толк може потім прийти. Ну, коли ти десь будеш стикатися, якщо в тебе різношорсні проекти, та ти будеш це використовувати.

Speaker A

Ну, хоч не хоч, там в тебе є знання для цього. Вот. Окей, добре. Поїхали дальше. Тоді, я думаю, по пекенду будемо закоруглятись.

Speaker A

Та давай по мобільному тестуванню. Добре. Пум-пум-пум. А розкажи мені, будь ласка, різницю між багами, які знаходяться на real девайсах та і багами, які знаходяться на емуляторах, симуляторах. В чому різниця?

Speaker A

Що варто тестити на емуляторі? Що можна тестити на емуляторі, симуляторі, а що варто тестити на real девайсі?

Speaker A

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

Speaker A

подивився, поклацав, повзаємодіяв. Це можна робити і там, і там, і різниці не буде. Але в чому може бути різниця? Це мабуть в продуктивності.

Speaker A

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

Speaker A

продуктивність почати просаджуватись. Якщо це в тебе там емулятор в Android Studіоіоo, то, напевно, він використовує ресурси твого компа і в принципі йому, ну, ти з цим можеш не зіткнутися.

Speaker A

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

Speaker A

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

Speaker A

Також платежі неможливо буде в реальності протестувати, наприклад, там через, ну, ти не можеш підійти з емулятором до оцієї штуки, до якої ти прикладаєш телефон. Не пам'ятаю, як посттермінал.

Speaker A

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

Speaker A

Ну, такі речі, як Face ID, Touch ID, напевно, ніяк в емуляторі ти не протестиш, бо ти туди просто нема куди палець перетискати і ти не можеш, е, симулювати типу веб-камеру, щоб вона проаналізувала там твоє обличчя, ну, фронтальну камеру.

Speaker A

Bluetooth, напевно, ще неможливо буде протестити, якщо там є щось з блютузом пов'язане. А інше, по ідеї можна.

Speaker A

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

Speaker A

Ну по-перше е, окрім того, що, ну, як, коли я пишу чеклист, наприклад, ее, то вже на цьому етапі це впливає, тому що не базово для кожної фічі і кожної userсторі, але базові якісь мають бути перевірки саме для телефону. Тобто, як

Speaker A

працює додаток, коли ти заблокуєш екран, коли ти розблокуєш екран, чи все буде окей, коли ти в back бекграунд апку закинеш, коли ти її повністю вб'єш і будеш відкривати, коли ти там перестановиш додаток або оновиш додаток.

Speaker A

Е, потім там, ну, оці всі речі, це як окремий такий в чексті там або в тесткейсах робиться папочка для цих оцих моментів, щоб оце все перетестувати. Якщо прям просто брати фічі конкретні там, да, sign up fall, там sign і потім ми робимо юзеру

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

там ти не в додатку, ти жмеш на пуш, тебе кидає в додаток, відкривається потрібна сторінка. Але всі оці моменти, про які я розказав, вони не хендляться зазвичай. І там дуже багато там різних багів. Ну, плюс А можеш мені назвати, будь ласка, от ми

Speaker A

говоримо за якісь, ну, от базові речі, та які є в мобільному пристрої, які масх перевірити з вигодом нової кожної нової фічі. Та.

Speaker A

Угу. Ну, є щось дотичне більш там, наприклад, якщо це push notтифікейшни, наприклад, це, напевно, розширяється трошки.

Speaker A

Е, якщо у нас, наприклад, відбувається якась певна оплата, то це тоже там є специфічні кейси там на це. А що саме специфічно специфічне от саме для двох платформ, наприклад, для Андроїда і для ОС? Ну, велика, я розумію, куди ти може,

Speaker A

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

Speaker A

Угу. І так далі. Можети про ці речі. Тобто, ну, коли зазвичай, якщо чесно, е, в компанії завжди тестуєш те, на чому, що тобі дала компанія, якщо це реальні девайси або на своїх видалі, як це має робитися, якщо ти хочеш респонсив

Speaker A

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

Speaker A

Е, ну, через defols просто розмір екрана там міняю, да? А я як вирішую які, то я просто йду там, короче, спитаю в чата GPT статистику найпоширеніших зараз телефонів, беру там із них там топ-п'ять і на них там дивлюсь юайку, а все інше

Speaker A

дивлюсь на своїх реальних, які в мене є тести. А в тебе в тебе немає в ком, ну, наприклад, в твого замовника або в компанії якихось специфічних реквуєрментів, вони знають своїх користувачів?

Speaker A

Ну, на яких на яких це телефонах буде? Чи ти просто так робиш це тестування на всякий?

Speaker A

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

Speaker A

одному якомусь Самсунгу, якщо є в когось із колег або в мене, тому що Самсун має специфічні баги, часто які на інших девайсах не репродуються. Це, тобто, ну, тобто завжди задача протестити iPhone якийсь, завжди задача протестити якийсь Android і,

Speaker A

е, протестити Samsung. Бажано, щоб вони всі були різного розміру. Тоді ти більшість девайсів по суті покриєш. Ти покриєш великі девайси, маленькі, Android, iOS і Samsung.

Speaker A

Нуце, ну UI, ну розмірам там, да. Ну ні, ну да. Ну і все інше теж, коли як буває так, що на Андроїді додаток дуже е там продуктивність дуже просідає, а на Айосі нормально вообще все ідеально.

Speaker A

Отакі ще тоже приколи. А в залежності, ну від чого це? відбувається в залежності від кількості анімації на PG з, ну, зачасту так, кількость кількість контенту, який який не PG, це, напевно, якось ускладнює рендеринг. Ну, я я там це може бути таке, а ще й від

Speaker A

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

Speaker A

написана кимось. Ну, я я не маю претензій до рекнейтів, а до кривого написання маю.

Speaker A

Ну, в ме в мене досвід з фатером абонейтів розробкою. Оце, ну, кілька проектів абонейтів. iOS Android було окремий деве, а все іншого ще на фатері було. Ну то загалом все добре, але бувають моменти, що да на Android не справляється, а iOS окей.

Speaker A

Тому як мінімум оцей, ну оцей мінімум завжди є, що мають бути оці там три девайси.

Speaker A

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

Speaker A

Якщо мені потрібно було прям дуже на якомусь девайсі, то я Android Studio чи XC чи в XC запускав емулятор. І там, ну, була було невелика кількість разів, коли мені потрібно було логі чекнути, бо не могли зрозуміти, в чому проблема

Speaker A

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

Speaker A

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

Speaker A

Якщо такого не було, то якраз девайс, якщо це Android, запускаєш Android Studio, конектишвайс і бачиш влоги. А якщо це iOS, то треба Mac Xкод запускаєш, конектиш iPhone і бачиш. І там можна вже фільтрувати е-е або через Search, якщо там ти знаєш, як Ну,

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

наприклад. Ну вообще нема от як саме подивитися логи через студію? Можеш мені сказати, да? Ну, ти коли підключаєш, ти відкриваєш Android Studio на компі, ти через кабель USB під'єднуєш девайс і в тебе в Android Studio він з'являється. Я

Speaker A

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

Speaker A

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

Speaker A

Android, там ситуація простіша насправді. Вот якщо ми говоримо за iOS, то потрібно іменно білдати до додаток на app, ну, на девайс та або на емулятор, або на девайс. Тоді ти можеш подивитись логи та по цій операції.

Speaker A

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

Speaker A

Угу. Потім я під'єднував чи ну до, ну, до Мака, по-моєму, там на ні, по-моєму, кабель потрібен був. І він з'являється там одразу в, ну, ти вкді там бачишний телефон, ти там клацаєш і одразу бачиш воги і так само

Speaker A

фільтруєш. Якщо ще, ну, я не буду тобі вигадувати, що я там ще щось робив. Я не пам'ятаю, чому він одразу в мене працював.

Speaker A

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

Speaker A

Добре. А що, що саме в Android? Ну, ну от через Android, що ти саме використовував для того, щоб дивитись логио чи ти використовував якусь е сторонню толзу та для цього?

Speaker A

Ні, ну це насправді, насправді дуже мало разів це було потрібно. І я робив це саме через Android Studio.

Speaker A

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

Speaker A

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

Speaker A

Ну, я я підключав прокмен або череліз. Спочатку я працював з Черлізом, а потім з проксіменом. І майже всі майже всі е баги, щоб дебажити, цього було достатньо. Просто подивитися респонс чи реквест. А коли вже бах був специфічний краш якийсь,

Speaker A

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

Speaker A

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

Speaker A

прикол. Вони мене просили тоді продивитися логи, і я находив ерорку і просто там скидав їм, ну, все, що з нею зв'язане, там повністю весь текст, і вони тоді розуміли, що не так.

Speaker A

Окей. Але це було на кілька разів там може. Добре. А-е, тоді давай підемо дальше. Одну хвилинку.

Speaker A

Ні, що я була тільки одинака в нас, ну, от чи можеш сказати, будь ласка, різницю між багами на Іосі і багами на Андроїді, яку бачив ти, яка між ними може бути різниця?

Speaker A

Е, ну, те, що я вже згадував, це продуктивність, а інше - це з пермішенами. Е-е, це було давненько, що прям такі баги специфічні для айos. Але, е-е, я пам'ятаю, що е-е коли там де ви намагалися пофіксити якийсь баг, вони

Speaker A

казали, що це специфіка айos, бойо не дає perмішн, наприклад, зберегти ці дані там в ба, ну, в по базі даних якось девайсу чи щось таке. І потім ще були проблеми, що в коли в тебе апка ну не відкрита, а згорнута в background,

Speaker A

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

Speaker A

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

Speaker A

А, ну, отакі всякі речі, то ні, більш-менш вони все було однаково. Ну, так, від самої архітектури, ну, самого Іосу і Android, вони є різні.

Speaker A

Та і в відповідності ти сказав про пермішени, про методи зберігання якихось певних даних. Це насправді є гепи на тій і на іншій платформі, про які сказати. Так.

Speaker A

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

Speaker A

взяти якісь, ну, це ти точно маєш зробити на iOS, на Android і на Samsungх. Це чисто моя думка. А якщо ти там вже не Ну і плюс це ще має бути остання, е, ос бажано точно. Е-е і було б ще непогано якусь стару взяти на

Speaker A

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

Speaker A

Всьо чи ще щось? Там наче всьо. Може я щось там ти мене до чогось ведеш, я не розумію.

Speaker A

Добре, в нас є девай девайс кастомера треба протестити ще точно. Ну, девайси, на яких кастомери дивляться, що точно треба зробити протестити.

Speaker A

Е-е, в нас є різні версії продукту, правда? А, ну да, да. В нас є версія один, версія 1.1.

Speaker A

Update. Update ще коли, ну да, наприклад, це якщо на проді, то що на деві на демо. І ми цього ніколи не тестували, але на проді, да, е, на продіти потрібно там видалення, встановлення з нуля і також ее оновлення.

Speaker A

Я тобі не за це. А не за це, наприклад. Да, я не за це. Маю на увазі, в тебе є версія один, версія оди і оди.

Speaker A

Та угу. Який який? Добре, давай з такого почнемо. Який метод є оновлення? Які є два методи оновлення?

Speaker A

Ну, з середини додатку, коли ти відкриваєш його або із Apple Store, або Google Play Маркету.

Speaker A

Добре. Ти заходиш нову. Прифую я тобі питання. Не, не методи та а м обов'язковість, яка є оновлень.

Speaker A

Є обов'язкова та є необов'язкова. Та що тут варто врахувати? Пригре. Сечас трошки подумаю. Давай подумай.

Speaker A

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

Speaker A

і юзер не оновиться. Але, ну, по ідеї, якщо він обов'язковий, то нам в додатку треба додати щось таке, що юзер не може ним користуватися, поки не оновується, тобто якийсь блокер.

Speaker A

Та відповідно, напе треба перевірити зворотню сумісність, чи в нас все, що працювало в оди в першій версії, воно працює. Та і в 1.1 воно тоже працює.

Speaker A

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

Speaker A

не паше, а тоді надо оновитися там і так дальше. От. Ну да, да, це такий один з важливих аспектів.

Speaker A

А окей добре. Я так розумію, любій проксі. Добре, давай так питання тобі так чисто. Воно ж ні на що не повпливає. Чому проксімен, а не Чарлік?

Speaker A

Ну того, що його інтерфейс мені набагато більше подобається. В ньому на його набагато простіше навіть налаштувати.

Speaker A

Е-е там набагато простіше фу налаштування і так далі. І інтерфейс userfriendly і приємніший чисто через це. І в нього нема оцього приколу, як у Чарліза. Якщо він не офіцій, ну, якщо в тебе він неофіційний, то кожні 30 хвилин

Speaker A

він тебе закривається. А в проксімена, здається, такого немає. Ні, ну просто провена є фрішна версія, типа, яка доступна всі.

Speaker A

Ну, вона адекватна, да, вона нормально працює. Єдине, що там брекпоінтів типу лише один, по-моєму. А так, ну, просто мені приємніше. Але якщо треба, то можу і черлізом, але я ним вже давно не користувався. на правах реклами. В общем, проксимен дякуюрили.

Speaker A

Клас. Ні, насправді, та я погоджуюсь, мені тоже там подобається і моїм колегам, наприклад, ну, з якими я працюю, тоже прокмен якось більше до Я я випадково абсолютно спробував його, а мені дев підсказав. Він каже: "Нафіг ти оцей юзаєш, типа скачай нормальний".

Speaker A

Я скачав такий: "Вау! Давай, давай з тобою поспілкуємося ще про автоматизацію і якісь поінти, які ти зробив для того, щоби автоматизувати якісь певні процеси. Та мені би хотілось зараз тут почути від тебе, що саме, які в тебе були про, ну, от назвик там

Speaker A

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

Speaker A

Ну, по твоїй ініціативі це було. Ти маєш на увазі прям автотести чи про що ти?

Speaker A

Ну, дивись, от, наприклад, от є в мене така ситуація, там, наприклад, на якійсь роботі, да, скажемо так. Вот, е, мені для того, щоби наконфігурити собі тестові дані, потрібно викликати там 16 реквестів, та наприклад.

Speaker A

І я кожен раз це мучаюсь і так дальше. Я собі взяв там відкрив, ну, ту мову програмування, на які я вмію писати, наприклад, на Пітоні та відкрив, заавтоматизував собі ці 15 реквестів, або зробив це через Посман, та або через

Speaker A

Postman Flow зробив це. Та і тепер маю щастя, ще й випхом до Ослаку підв'язав, наприклад. І тепер мої колеги тоже можуть собі конфігурити там, наприклад, якісь певні тестові дани на певні якісь кейси та за допомогою чату в слаку. Та

Speaker A

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

Speaker A

це рішити. Там я рішив це на рівні там, не знаю, своїх тімлідів, команди, компанії, можливо, там і так дальше.

Speaker A

Добре. Та мені хоче почати, якщо прям в цьому контексті, то не робив так. Е, якщо в іншому, то у нас ось на моєму останньому проекті велика дуже була проблема із стабільністю сервісів і серверу. Вони весь час падали через

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Але це реалізували і більш-менш стабілізувало цю ситуацію. Ми почали бачити в Teams е там нотифікації про те, що в нас там якийсь сервіслі або якесь оточення. і могли це пофіксити.

Speaker A

Ну, це була чисто як ініціатива, але я сам там по суті нічого не робив, просто таски там постворив.

Speaker A

Ее, щоб я прям автоматизовував собі якісь рутинні процеси. Я цього не робив ее з точки зору коду. Я це робив з точки зору часті GPT. якісь мінорні баги або якщо пачки баги летять з регресу, наприклад, в мене є шаблон в GPT, я йому

Speaker A

кидаю відос або скріншот і summer, і він мені, в принципі, в гарному форматі багу, е, все це заповнює.

Speaker A

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

Speaker A

користувався я цим. Окей, добре. Мені ще цікаво взагалі за аїшку. Ну, от оцей кейс класний, що ти розказав. Насправді я тоже так роблю. От є якась, ну, типа от просто ти знаєш, що це бага вона, ну, от ро рутина, вона

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Захейтили. Тоді я офіційно хейчу тих людей, які захейтили. То, ну, типа, вони кажуть: "А чого це ти так робиш? Ти що, з типа сам не можеш? Ти ж, ти ж, типу не розучишся, а вдруг він там фігню робить." Я кажу:

Speaker A

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

Speaker A

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

Speaker A

штука, як аїшка, яка генерує багу тобі. Ну, на конечно воно працює тільки на англійській мові. Вот. Але є така штука.

Speaker A

Ну, якщо вони навіть це імплементують, типа, ну, ну, в людини шок, напевно. Вона не може стереотипи і скоріше стереотипи. І коли це чують, думають, що ти або лінивий, або типа сам не знаєш, як тому питають. Хитрий, а, да, але тут питання з іншого. Коли в

Speaker A

тебе велика навантаження на роботі, або ти робиш РГС і ти там потім будеш ще 15 багів заводить там дві години, або ти їх заведеш за півгодини, типа.

Speaker A

Ну, вони, конечно, будуть не ідеальні. Сам ти напишеш краще. Ну, і чита читабельніше для Дева. Але тут питання, чи це цінно буде типу для команди?

Speaker A

Да, відповідно, якщо Ну, це дуже просто робиться насправді. А от дивіться, я створюю баги за допомогою їшки чи ок вам? Та мені навпаки, де ви казали класно, класні багрепорти того, що після цього до цього вони з індусами працювали.

Speaker A

А, а, а, я їм роблю через ще GPT. Вони кажуть: "Все класно, типа, все понятно там." Да. Ну, це тобто для кожної компанії це все унікально насправді. Хтось має якісь певні конвеншени, які забороняють це робити, або хтось з, ну, з керівництва

Speaker A

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

Speaker A

просто до цього. І це окей. Це насправді окей. Але, ну, від мене лайк за це, тому що це прикольно.

Speaker A

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

Speaker A

часу, поширити цей інструмент між всіма і, ну, принести вельо. А це ж насправді вельо. Ну, але якщо ти розлінишся, ми ж це помітимо 100%.

Speaker A

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

Speaker A

непонятно. Окей. Добре. Окрім того, ще в чому ти аїшку використовуєш? Е, ну, от як я сказав, для тексткейсів.

Speaker A

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

Speaker A

передавав йому, е, дези, передавав йому описчей, е, суть. І потім, коли він це проаналізував, я робив йому сам типа як опис, що я від нього хочу. Там позитивні, негативні кейси, на Uані кейси. Потім я його просив: "Все одно

Speaker A

нічого не роби". Е, аллоалло, щось за нетом. Ти тут? Так, я тут. А ти?

Speaker A

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

Speaker A

можу щось змінити, наприклад, і потім він вже робить детально пачками, типу я їх вже протім потім просто вставляю там або в Excel, або в test.

Speaker A

Так, а мене чути нормально? Чути так, але походу якась затримка або зам щось. Сподіваюсь, це не в мене.

Speaker A

Це походу в мене. Зараз можливо пофікшудко. Так що ми поки чекаємо на Костю. Ага. Значить це не в мене хотя б.

Speaker A

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

Speaker A

швиденько і свій перевірив, хоча він не має вплинути. Це все Webbased, але все-таки акаунта й так. Ну що, ми трошки, звісно, що почекаємо. Буває форс-мажор всі їх відключення світла пишуть люди ее в коментарях от кажуть, щоб я продовжував.

Speaker A

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

Speaker A

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

Speaker A

А взагалі я тоді цей, я тоді краще щось скажу, як висновок насправді. Ну, типу, що я почув. Ага. А, а ось і Костя.

Speaker A

Не дає мені. І це правильно. Так, Костя, бачу, що ти доєднався, але поки що камери не бачу. Увімкни, будь ласка, камеру, перевір, що в тебе все гаразд, і я тебе одразу доєдную. Ага, бачу, є.

Speaker A

Так. Ага, перейшов, мабуть. Окей, я додаю Костю. Кост ще. Ага. Мобільний інтернет. Я не знаю, чи це мобільний чомусь. Ну, просто реально лагає. Я не розумію за чого.

Speaker A

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

Speaker A

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

Speaker A

Так, а у Кості здається і аудіо також. Ану, ану скажи. Ти тут? Да, мені Алло. Раз, два,три.

Speaker A

Супер. Я тут. Та мене чути взагалі? Давайте. Так, так. Давайте я тоді уходжу зі сцени.

Speaker A

Спробуйте закінчити, фіналізувати. Окей. Угу. Дякую. Що підстрахо? Якщо що, я повернуся. Давайте. Так, чути мене добре, правда?

Speaker A

Так, чути добре, да? Окей. Ну, в принципі, ці питання були вже фіналізовані. Та і я для себе а можу висунути висновок. Та а про тебе як про кандидата.

Speaker A

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

Speaker A

А, Лекса, ти можеш під'єднувати? Окей, давайте. Та ні, я просто я собі подумав, що я би хотів, можливо, ще щось задати і так дальше, але мені насправді цього досвіду здається, що достатньо для того, щоби зробити певні висновки. М

Speaker A

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

Speaker A

не так зрозумів. Ти дуже легко, класно виходив з цих ситуацій. Ну, от просто от якось так просто легко. Та мені це сподобалось, да.

Speaker A

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

Speaker A

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

Speaker A

такі ситуації: "Нам треба швидко на завтра наприклад або нам треба на сьогодні" і тому подібне, та є певні там інструменти, якими можна користуватися для того, щоби, в принципі, надати вели, ну, нормальну там прозору кількість аргументів, чому це неможливо, типу і

Speaker A

робота з запереченням і так дальше, і продавати ці ідеї і тому подібне. Ну, в принципі, це має займатись APM, та але якщо може типа за тестові процеси там і якісь певні речі та вже відповідати сам QA там рівня сніори, якщо він є на

Speaker A

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

Speaker A

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

Speaker A

виражусь, та але я виражусь по-свому. Типа це робоча машина, та яка має робити роботу.

Speaker A

Вот. І насправді, ну, мені здалось, та що ти якраз відповідаєш цій позиції, та що ти можеш робити роботу. Ну, звичайно, я би, напевно, би розширив то більш там до якихось певних практичних питань, типа: "А як ти користуєшся з тим або

Speaker A

іншим?" І так дальше, але ми би зараз розширили нашу співбесіду би там 4, по години, тому нікому не надо би було би.

Speaker A

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

Speaker A

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

Speaker A

цим питанням. В тебе були такі ситуації, ти міг з них виходити. Це плюс. Та ну і дальше там завершення тестування. Про те, що ти сказав про репортінг, бахрепорти і так дальше, то в принципі і використання штучного інтелегу - це плюс

Speaker A

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

Speaker A

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

Speaker A

Олексій зі мною погодиться, може ні, звичайно, це все ж таки взяти для себе на навчання якусь людину та хоча би дове, ну, вивчити її та і насправді покращити свої майр Це класика. Чому б ні? Так, це це класичний підхід. Його часто запитують,

Speaker A

якщо такого взагалі не не було, то взяти таке можна. До слова, в коментарях хтось написав про те саме, що типу можна стати.

Speaker A

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

Speaker A

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

Speaker A

сказати, бо це так дуже важкий такий момент і специфіка. Угу. Тобто майже всюди це робили поеми. Сорі, да сорі.

Speaker A

Або тім Костя продовж. Ну, це та це нормально. Та якщо цим займається PM, значить хороший PM насправді, якщо він бере на себе ризики і так дальше.

Speaker A

вміє відстоїти команду і взяти на себе оці дурні питання до Qва. Чому так довго тестувати? Е, да, насправді. Ну, але якщо, ну, буває таке, що, наприклад, немає, е-е, ну, такої людини, та і тобі потрібно процеси тестування відстоювати самостійно, та або брати на себе цю

Speaker A

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

Speaker A

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

Speaker A

рішити там на рівні когось чогось. Та і як би нам там пропушити цю ідею та і показати е дійсно велью цього, тобто як ми можемо продати це там, наприклад, оце скоротить час тестування настількито та якщо ми витратимо там 2-3 дня там на

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

конечно, да, а вміло, ну, от просто якісь свої сильні сторони. От е в кожного QA є сильна сторона якась. Вона в когось там бекенте тесті. Хтось вообще любить, ну, вторчить від цього, да, в когось іменно набір солянки, там, я вмію

Speaker A

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

Speaker A

Та і якщо я тебе отакі сильні свої сторони ще би добавляв би в резюме, було би дуже класно, да, і непогано. Ось. Ну, по комунікації точно плюс, по скілам плюс. Та, ну, по всьому іншому. Єдине, що до, ну, от досвід до сіньйорства, він

Speaker A

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

Speaker A

І звичайно мене чи Олексій, є тобі дякую. Я багато не хочу того давати. Мені сподобалось, як пройшло все. І я хотів би залишити це в рамках ваших двох компетенцій. така таких змагань. А-а можу сказати, що вийшло так і так. Я

Speaker A

люблю е питання на розуміння, на широке рерозуміння, як працюють механізми. У вас багато було про практику. Це такий специфічний є портрет. Влада, як людини, яка багато чого насправді спробувала і користувалася на гарному професійному рівні. І здається і склало

Speaker A

емоцію цієї співбесіди. От. Ее то чому ні? Це гарно, мені зда здається. Ну і при цьому не було в цілому якогось, знаєте, ефекту, що це щось дуже вузьке було тільки на практиці, а насправді людина не зробила висновків про якісь

Speaker A

системні речі. Ні, все виглядало так, що є і достатнє системне розуміння, і багато практичного розуміння. Тому, як там в мене, все справді гарно тут виглядало. Так, Костя ЗНО нас залишив.

Speaker A

Так от, а якось так. Почитаєш потім коментарі. Вони гарні в цілому. Да, слава Богу. Це я чат не дивився, бо я боявся, що це будуть хейтити, то я цей посиплюсь.

Speaker A

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

Speaker A

Відповідно сприймати будеш на свій рахунок. А може воно взагалі не типу не те. Тому я раджу всім не читати чат. От.

Speaker A

Але дякую всім глядачам за те, що ви коментували. Е-е раджу всім приходити на етери саме в момент проведення, тому що цікаві можуть бути комунікації в чаті. Потім ніхто вже той чат не читає у записі, хоча він записується. І ви можете подивитися, як

Speaker A

люди спілкувалися. Але закликаю всіх ходити. Так, Костя знову доєднався і, здається, у нього навіть відео з'явилося нормально. Костя, я тебе повертаю.

Speaker A

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

Speaker A

Ох, ті компи. У тебе у тебе цей штучний інтелект в телефоні є чи в цьому? Чи в компі? Зараз ми з'ясуємо, хто. А може в тебе роутер з штучним інтелектом? Е, знаєте, я думаю, що в іосі самий, ну,

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

А я думаю, що Костя, можемо передати слово Владу, щоб він міг також сказати свій фідбек і все, що за захоче, тому що це традиційно для такого жанру співбесід.

Speaker A

Так. Та звичайно. Влад, тобі тоді слово можеш сказати все, що хочеш. Е, можеш багато, можеш небагато, це не обов'язково. You are welcome.

Speaker A

Добре. Я хочу вам подякувати. Це було круто. Я не можу сказати, що щось було негативне. Всі питання, вони мали в собі сенс і практичний, і теоретичний.

Speaker A

Е, тому мені було дуже цікаво. Це такий дуже важкий челендж. Е-е, і хочу подякувати всім, хто дивився, мене підтримував, а може там чи не підтримував. Ее, я, на жаль, не дивився, що ви там писали. Того, що мені було

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Всім дякую. Дякую, Влад. Також я традиційно і не втомлююсь це повторювати. Вже на кінець скажу, що ми дякуємо і тобі. І це не просто, знаєте, така вдячність, всі один одному дякують. Це, я кажу, те, в що я вірю. Тобто, здавалося б, що кандидат

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

бачення, це 100%. От. Але це, ну, люди оцінюють вже з пони підкреслювали, зайдете трошки пізніше, завантажиться, почитаєте по користі, технічних аспектах і так далі. Саме як інтерв'ю. А це круто. Тому всім дякую, друзі. Дякую. Будемо з вами прощатися,

Speaker A

хлопці, залиште. ще на пару слів. А я, а я, а я, а я, а я вам кажу, е, до побачення. Е, думаю, що скоро зустрінемося. Дивіться відео на цьому каналі. Не забувайтеся підписатися, поставити вподобайку. Ідеально. Трошки пізніше, коли відео завантажиться,

Speaker A

залиште коментар. Допомагайте розповсюдженню українського контенту. Нам це потрібно. Сам по собі він не розходиться. Потрібні ви. Тому дивіться, що вам тут цікаво. Є багато різних інтерв'ю. Дивіться інші інтерв'ю. Manual automation, Juniніор midle senior lead QR-менеджер. Все це є на цьому каналі. І

Speaker A

інтерв'юєрів в нас там з вісім, можливо різних є. Тож долучайтеся. А в описі є посилання на хлопців, якщо потрібно. Підписуйтесь на них. в Лінкдині, так, професійна мережа, тому саме такі лінки і на Telegramканал QA Україна, щоб не пропускати все це і

Speaker A

взагалі десь побачити QA Україна конференція Battle Gazйз. Підписуйтесь і цікавтеся. А все, я закінчую тоді цей стрім. До нових зустрічей. Бувайте.

Speaker A

Yeah.

Topics:співбесідаMiddle Manual QAтестуванняQA Українатестування мобільних додатківтестування бекендутестова документаціяонлайн співбесідатренувальна співбесідатестування API

Frequently Asked Questions

Який досвід має кандидат Влад у тестуванні?

Влад має майже 3 роки досвіду, працював у чотирьох компаніях, тестував веб, мобайл та бекенд проекти у різних доменах, включно з healthcare та криптобанкінгом.

Як проходить формат співбесід на каналі QA Україна?

Співбесіди проходять у форматі прямого ефіру на YouTube, максимально наближеному до реальних умов, з живою взаємодією аудиторії через чат і коментарі.

Які основні обов’язки тестувальника, згадані у відео?

Тестувальник повинен рев’ювати специфікації, писати тестову документацію (чек-листи, тест-кейси), тестувати API, UI, інтеграції, а також заводити і пріоритизувати баги.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →