Speaker A
Друзі, ми маємо бути в етері. Я зараз це гляну, а ви напишіть традиційно, що я є.
Публічна співбесіда на посаду middle manual QA з кандидатом Маркусом, обговорення досвіду, навичок та процесів тестування.
Key Takeaways
- Публічні співбесіди допомагають демонструвати реальний процес оцінки кандидатів.
- Middle manual QA повинен мати як технічні, так і комунікативні навички.
- Важливо вміти налагоджувати тестові процеси та документацію з нуля.
- Знання методологій Agile, зокрема Kanban та Scrum, є перевагою.
- Досвід роботи на різних доменах (гемблінг, AI, Web3) розширює професійний кругозір.
Summary
- Відео демонструє публічну співбесіду на посаду middle manual QA.
- Ведучий Олег Самашець та кандидати Костянтин і Маркус беруть участь у розмові.
- Обговорюється досвід кандидата Маркуса, який має понад 3 роки в QA.
- Маркус розповідає про роботу на різних проектах, включно з гемблінгом, AI, Web3 та healthcare.
- Кандидат описує свої обов’язки, зокрема створення тестової документації та налагодження процесів.
- Згадується використання методологій Kanban та Scrum у роботі.
- Обговорюються як хард, так і софт скіли кандидата.
- Ведучий підкреслює серйозність, але водночас дружню атмосферу співбесіди.
- Відео містить живий діалог з питаннями та уточненнями щодо досвіду та процесів.
- Згадується важливість правильного написання імен та увага до деталей.
Full Transcript — Download SRT & Markdown
Speaker A
Так, бачу я, що я є. Я вас вітаю. Мене звуть Олег Самашець. Ви на каналі QA Україна. І у нас сьогодні публічна співбесіда на рівень, на посаду, так, middle manual QA.
Speaker A
А вона в режимі у нас hard відбувається. М ви побачите самі, як це буде. Це не означає, що прямо я хтось буде когось валити. Ні.
Speaker A
Але має бути серйозна розмова, скажімо так. Хоча не без жартів, я так підозрюю. Тож сьогодні я також буду з вами дивитися на це дійство.
Speaker A
Е-е, та мабуть досить всього казати. Давайте ближче до справи.
Speaker A
Е-е, я вітаю повернення Костянтина. І також я вітаю кандидата Маркуса. Привіт, хлопці. Всім привіт.
Speaker A
Привіт. Привіт.
Speaker A
Е-е, та напевно, що напевне я можу більше не цей тут не світитися.
Speaker A
Е-е, приємного вам вечора.
Speaker A
Так, у тебе є питання?
Speaker A
Так, Олександр, в мене є не питання. Я спеціально цей підготував момент до початку, бо ми вже готувалися,
Speaker A
але я спеціально підготував його. А для активних глядачів, в принципі, QA 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
Ви мені просто скажіть, я прийду. Можете лампу дещоще ще потерти, я красиво з'явлюсь серед вас.
Speaker A
Все, гарного вечора, хлопці, гарного перегляду всім.
Speaker A
Ну що ж, давайте розпочнемо. Маркус, привіт.
Speaker A
Е, я думаю, що перший із питань буде: як ти оцінюєш свій рівень взагалі?
Speaker A
От як ти відчуваєш себе?
Speaker A
Наразі себе позиціоную на рівні middle, враховуючи ті обов'язки, котрі я виконував на різних проектах.
Speaker A
Е, враховуючи те, що я був як і на маленьких проектах чи не то, що на маленьких проек, я був єдиним тестувальником на проекту, так і працював на доволі великих масштабних проектах.
Speaker A
І враховуючи ці всі знання, я би сказав би на middle, але я би сказав би такий middle плюс, так як більш а-а організаційні моменти так само я міг оформлювати на проекти і або створювати тестові процеси з самого нуля.
Speaker A
Угу. А як ти оцінюєш, от в тебе сильна сторона хардскілова чи софтскілова?
Speaker A
Я би сказав би, більш софтскілова, але одне без одного не може існувати.
Speaker A
Угу. Добре. Хотілось би чути від тебе взагалі інтродакшн тебе, твого досвіду. Можеш розказати?
Speaker A
А так, звичайно, е працюю інженером більше 3 по по років. Працював на дуже різних проектах в різних компаніях.
Speaker A
Outsource, outstaff продуктових останніх два місяці роботи це були гемблінг проекти в домені гемблінг бізнес домені це були продукти і працював в великих командах над створенням якщо ми кажемо про останній проект це був сервіс, котрий допомагав все посередині великого,
Speaker A
як би сказати, один з сервісів, котрий допомагав іншим сервісам навколо позиціонувати.
Speaker A
І так само був, е, як би так сказати, працював проксі для, ее, іншого сервісу, за рахунок котрого проганяв певну інформацію через нас і ми її віддавали вже від себе.
Speaker A
Е, якщо так ближ більш детально, е, це можна сказати така CRM-система велика, котра враховувала, е, в себе багато інформації юзерів, е, їхніх.
Speaker A
Е, вибачай, вибача, я тебе приб'ю. Я просто не розумію зв'язку. От давай з самого початку.
Speaker A
Та, наприклад, в тебе є скільки років досвіду? 3,5 років.
Speaker A
3,5 років досвіду. Давай про перший досвід.
Speaker A
Про перший досвід це працював в компанії, котра позиціонує на створенні mobile аплікейшн.
Speaker A
Це було таке, якби сказати, не те, що Blackbox, це було, якби сказати, е-е поверхневе тестування на перевірку дизайна і те оте, що певні функції працюють.
Speaker A
Тобто там було дуже багато дрібних апок різноманітних, починаючи там від калькулятора до якогось емулятора е-е євротраку.
Speaker A
Е ось і в загалом ми так от працювали.
Speaker A
Угу. Далі.
Speaker A
А потім працював в аутсорса outstaff компанії, котра більше всього мала проектів в бізнес-домені. Це AI і ну взагалі Web3 крипто були AI проекти, але так само були і ETE, і Healthcare.
Speaker A
Угу. Які обов'язки ти там виконував?
Speaker A
Це якраз той, та компанія, в котру я прийшов абсолютно єдиним, ну, єдиним заанбордився на ту компанію і почав будувати процеси, враховуючи те, що в мене було не настільки багато досвіду, наприклад, як в мене зараз є.
Speaker A
Але я, враховуючи свою ініціативність і по життю якби проактивність, я почав зрозумів, що це великий челендж і велика мотивація для того, щоб крутий експірієнс для того, щоб пережити і проявити себе як професіонал.
Speaker A
Ну, тобто твої обов'язки були проявити себе як професіонала?
Speaker A
А мої обов'язки ні, не зовсім так. Мої обов'язки були про більш про те, щоб в загалому налагодити в загалому процес тестування, зрозуміти, які у нас є можливі потенційні проекти, тобто імплементи той самий Shift Left Approach, котрий,
Speaker A
наприклад, я зараз розумію, що як що це таке. Раніше я думав таки, ну, нам же потрібно раніше тестувати для того, щоб, ну, от раніше тестувати, щоб у нас було, щоб ми могли знаходити баги якомога раніше.
Speaker A
Е, поставити тестову документацію, за рахунок котрої так само клієнти могли орієнтуватися і структурувати наші реквайрменти, котрі у нас є, на певну документацію, певні поінти для того, щоб ми так само клієнтам, коли, наприклад, обговорюємо певний функціонал або певні модулі, котрі ми хочемо імплементувати,
Speaker A
щоб ми їх могли структурувати і потім коли юзер або, наприклад, е-е кастомер приходить, каже, що, наприклад, воно працює, ну, не зовсім так.
Speaker A
Ми йому могли спокійно показати, що от, ну, ми ж домовлялися, от у нас ми зробили по порівно по тим критеріям, які ви і я далі, вибач, не розумію, чим ти там займався.
Speaker A
А-а, знову ж таки, це не всі обов'язки, котрі там були. Е-е створення тестової документації, створення налагодження процесу, а самого планінгу, як можна сказати, котрий у нас є разом працюючи з а-а project-менеджером, зве з девелопменті мою комунікацію, планінг який саме?
Speaker A
А, ну, загалом це, я би сказав би, це спринт планінг, але би я б сказав би, це а це активності QA.
Speaker A
Е, це не активності QA, але вони, але активності QA по як член команди в них входять в цю активність.
Speaker A
Ну, звичайно. А що таке планінг? Та взагалі, що це таке? Ну, план активність чого?
Speaker A
А ти маєш на увазі?
Speaker A
Ну, планінг - це взагалі процес планування того, що ми будемо робити в певний проміжок часу або в певний мілстоун.
Speaker A
А яка в вас методологія там використовувалась?
Speaker A
Е, от я оце і не хотів заякатися, бо там використовувалась, я би сказав би така, ну, я би, скажемо так, чисто, можна сказати, канбан з певними церемоніями скраму по типу daily стендапів, і рефайментів, і тих же самих планінгом скрам-бам, да, ну я би сказав би та.
Speaker A
Та це окей. А я тобі говорю за процес, побудований процес. Ти ж працюєш quality assurance інженером, ти ж інженер забезпечення якості. Які практики ти впровадив для того, щоби побудувати процес якості?
Speaker A
М. Да. Дивись. Ну, тобто теж саме, що я казав спочатку, тобто те ж самі е-е Shift Left Approach, котрий, ну, я не знаю тоді, що це так називається, типу зараз я розумію, тобто це це ранішнє тестування, а чим той ж самий принцип
Speaker A
тестування раніший testing, sales money and time. Яким, яким чином ти це реалізував? е, тими ж самими, е, бізнес-ременти, котрі у нас були, котрі ми збирали, котрі ми в на грумінгу, е, рефарменті, е, він обговорювався з клієнтом, з нашим
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
тестовим активностям. Я маю набір питань для тебе для того, щоб чекнути твій рівень. Розкажи мені, будь ласка, про рівні тестування, які ти знаєш. Рівне тестування component, component integraation, system, system integration і acceptance. На яких рівнях ти працював?
Speaker A
Напевно на всіх, окрім компонента, але в принципі зазвичай ритуальники на них не працюють. Скажи мені, будь ласка, як ти на component integraation працював?
Speaker A
А Compent Integration дуже просто, тобто перевіряв я, в мене був досвід навіть просто працювання е в інтеграційній команді.
Speaker A
Тобто ми підключали паі сервіси, котрі працювали з нашою системою, тобто, ну, грубо кажучи, payймент провайдери. Е, і на інтеграційному рівні ми дивилися того, то що ці мало того, то що вони працюють напряму від нас, наприклад, і як вони працюють через наші сервіси,
Speaker A
мікросервіси. А це не system integraation? Е, да, це system integraation. Але перед цим ми дивилися взагалі е в інтеграційному рівні, як вони працюють от напряму, як ми їх тим.
Speaker A
Що ти маєш на увазі? Інтеграційний рівень на Ну, як як ти це практично робив? Будь ласка, розкажи.
Speaker A
А практично робив. Дивись, тобто у нас є якийсь один от, ну, провайдер, наприклад, котрий ми є, у нього є якісь свої а-а м методи. Є певні солюшени, котрі вони на різні системи. Це е все по-різному є.
Speaker A
І ми перевіряємо того, ото, що ви, як він взагалі працює. Ми дивимося, ну, локально, грубо кажучи, направляємо його типа і е-е локально направляємо. Це як? Я от не розумію.
Speaker A
Локально, тобто ми переправляємо напря напряму, наприклад, через ее пост, ну, через саме той поман беремо, направляємо API request і як він себе поведе. З інтеграційному рівні ми можемо подивитися, як він поведе. Якщо ми запустимо, як дивись API request. Та
Speaker A
дивись, тут дуже ключове. API request - це що? Це запит ти. А, запит. А, вже готовий. А запит передбачає собою, що? Що система десь вже вилита, розвернута, та в неї вже є якийсь inпот, який з зовнішньою освіту до неї може постукати.
Speaker A
А це що в нас? Це component integration чи в нас system integration? Ти маєш на увазі, що ми відправляємо комусь на нарпаті?
Speaker A
Ну, напаті в них може бути це ж інтеграція не цього конкретного, а до нашої системи, як він себе. Я тобі скажу так, це не є component integration. Добре, давай пору component integration чи component. Це не є компонентно-інтеграційне тестування.
Speaker A
Воно воно виконується на рівні коду. Крапка. Всьо. Ти на рівні коду це використовував. ти мокав щось стаби використовував. Ти маєш на увазі? Ти дивись, в нас в мене розумінні є компонентне юніт тестування інтеграційне, system і system integration. Це ми правильно це про це
Speaker A
кажемо? Звичайно, звичайно. Ти кажеш зараз про перший рівень. Це про компонентне тестування чи протеation?
Speaker A
Competent integraation. Дивись, я просто от пройшов нещодавно STQB, типу, і в мене просто от дуже сильне питання, типа, бо компонентне тестування, типа, я ще як тобі перед цим сказав, тобто компонентне - це тей рівень, котрий ми тестувальники зазвичай
Speaker A
не робимо. Це ті самі юніт-тести, котрі пишуть розробники на свій же код. Compentation - це інтеграція між компонентами.
Speaker A
Ось. Ну, я ж тобі кажу, тебе просто якому рівні? На рівні коду. Так, да, загули хочеш. Ні, так ні, дивись, ми ж просто ми вже зрозумівляємо просто, бо ти мені спочатку сказав про компонентне, а потім compent. Ні, я
Speaker A
чітко сказав, що component integration. Мені цікаво було, як ти його використовував. По суті, ти мав готову систему, з якої ти відправляв IP запит - це system integration.
Speaker A
А не компонент. Ну, дивись, ми ж просто маємо, ми ж про правильно говоримо прогрент.
Speaker A
Компонент? Так, що таке компонент? Ну, компонент - це конкретний компонент якийсь в системі якась якісь може бути функціонал якийсь певний кластер. Клас.
Speaker A
А клас. Ну, чи ні? Мож можливо бути і клас, типа. Я просто хотів довести просто цю е нашу не дискусію просто і чи правильно ми взагалі одне одного зрозуміли, бо я я спочатку спитав типу про компоненти, ти сказав так, компонентне, потім про коне
Speaker A
integration, типу я просто розумію, чи правильно ми зрозуміли одне од component integration, да? Тобто це от компонен, коли ми беремо, перевіряємо конкретний компонент тестування, юніт тестування, це перевіряється самим девелопером код на код. Добре, це я хотів почути. Е-е, окей, добре.
Speaker A
Системний рівень. Що таке системний рівень? Е-е, системне тестування, правильно? На системне системне тестування на системно. Ну, що таке системний рівень взагалі?
Speaker A
Системний рівень - це тоді, коли ми дивимося, як от наші сервіси, якщо більш докладно, тобто це якісь у нас є от клавіатура і от на системному рівні того ото що вона працює, то ото щоб у нас всі сервіси і всі а саме головне
Speaker A
конфігурації, котрі у нас можуть бути на певному енвайменті, вони як вони Взагалі оці всі, е, компоненти у нас є разом, як вони працюють і, е, коexist, ее, з один одним і про проявлять. Чому? Чому воно називається системне? Бо ми перевіряємо,
Speaker A
грубо кажучи, систему на нашу систему повністю і от наш продукт. А чому? Дивись інтеграційну ми тоже перевіряємо там систему покомпонентно там, наприклад, ну ми перевіряємо конкретно якись от або шматок функціоналу, або конкретно якийсь шматок е сервісу конкретно якись ізольовано для того, щоб
Speaker A
подивитися, що він загалом працює нормально. А на системному рівні ми дивимося, як вони поведуть себе в в загалому в оточ в оточенні системи. О, оце, да. Окей. Да, тобто, якщо переводити більше приклад, тобто, наприклад, ти от такий класний, думаєш
Speaker A
моцний, типа ти вдома, але вийдеш, наприклад, ти там, не знаю, секцію з вільної боротьби, якби ти вже будеш трошки на системному рівні і може трошки не не то бути. Ключове, в тому, що воно розвертається на рівні системи, тобто на
Speaker A
певному енвайменті та і система цілосно тестується в середовищі. Я просто послухав перший речення. Ключове ключове, тому що чому системний рівень? Та тому що воно тестується в розвернутому середовищі. Да, да, да, ти все правильно кажеш. Типу, тобто це симуляція того, то що як буде поводитись
Speaker A
бажано на схожому на продакшн середовище. Окей. Види тестування які ти знаєш? А-а функціональне нефункціональне.
Speaker A
White, black box, change related. Чим відрізняється White Box від Blackbox? А тим те, що Blackbox ми перевіряємо, а в загалому вхідні і вихідні дані. Тобто той самий той чорний ящик, типу ми не ми не бачимо, як вони відпрацьовує. ми даємо якісь інпут ее
Speaker A
дати і от повинні щось отримувати на виході. Вйтбоксі ми же дивимося більш на структуру саму і дивимося, як вони певні а-а шматки коду, наприклад, вони як вони імплементовані. Тобто біл білий ящик. Ми дивимося ще хтось би сказав би про
Speaker A
GreatБОX, але чесно, е, ее я би сказав би що це ми щось таке схоже є, але я не вважаю, що це вид тестування чи взагалі він такий існує. Типа чому?
Speaker A
А чому GreatБОx не існує? Багато багато людей зараз навпроти, да, які дивляться тебе зараз дуже палають.
Speaker A
Ну дуже чому так? Дивись, ну, якщо ми просто зайдемо в, наприклад, ITQB, нам каже, що у нас є тільки white box, blackbox, типу, тобто White Box тільки, коли ми дивимося от прямо в код дивимося Blackbox, коли ми дивимося от чорний ящик, ми дивимося
Speaker A
то-то. Зрозуміло, да? Я жму зробив ремарку, типа то, що він офіційно його немає, але, ну, по факту ми розуміємо, що, е, сірий ящик - це от приблизно щось таке. Ми там десь подивилися, де ми подивилися там, то якби в постмені воно
Speaker A
приходить, ми подивилися логі, е, подивилися там, наприклад, ДБшку, що відправляється, типу от такий сірий ящик. Хоча по факту, е, це або Blackbox, або WhiteБx. Тобто це офіцій офіційно такої термінології немає, скажемо так. Тобто те ж те ж саме, що, наприклад, смок тестування.
Speaker A
Типа всі думають, що це тип тестування. От, наприклад, смок-тестування чи зайняті тестування. Хоча насправді це не тип тестування, це ширина або глибина тест Світа.
Speaker A
Тобто якось так. Я погоджуюсь. А-а, окей. Добре. Давай перейдемо до чогось глибше. Давай перейдемо до а клієнт серверної архітектури. Що ти знаєш взагалі про бекенд? Що таке клієнт серверна архітектура?
Speaker A
А клієнт серверна інтерфектура - це [музика] підхід зв'язку між клієнтом і сервером, котрий зв'язується через срабет API, тобто так, вони комунікують е-е так клієнт, тобто це ми, тобто це може бути будь-який інтерфейс, там калькулятор, котрий під'єднаний до інтернету або наші лептопи. І сервер -
Speaker A
це машина, котра оброблює е-е дані і запити. М по якому протоколу спілкується? М пошті TP.
Speaker A
А ще які є протоколи передачі даних? А-а HTTP HTPS протоколи передачі даних зараз. Ну чому? Ну чому тільки по HTTP? Ну от я не згоден.
Speaker A
А папапам так щось я пам'ятаю готувався, але щось в мене повилетало з голови про ці протоколи.
Speaker A
Ну, в загалому це самі популярні типи, але це якщо казати про Ростові, але про передачу даних так само є протоколи. От якщо б я в контексті би задавав питання ресту, це да, це правильна відповідь. Я не задавав в контексті цього. То той
Speaker A
самий вебсокет, наприклад. Окей. Але Websocket - це більше навіть Ну ладно, добре. Webсокетки має свій протокол. Вебsке - це більше як підхід до реалізації клієнт серверних додатків.
Speaker A
Добре. О, давай, давай. Цікава тема насправді. Ее які підходи до реалізації клієнт серверних додатків ти знаєш?
Speaker A
М Restful, той самий Websocket, Graph QL. О, бачиш, Webсокеet - це в вас що?
Speaker A
Це не протокол. Ну, протокол передачі, да? Ну, точно, точно так само і підхід. От так само є REST і restful типу. Тобто - це філософія іфл просто використовує як підхід до створення цієї а-а стилю пере а-а я думаю, що це більше як
Speaker A
філософія. Це перше уніфікований іменно якийсь певний набір правил, та яких притримується. Добре. От давай про Restful. Та як ти будеш підходити до тестування Restful АІ? Ну, а сервісів на рівні архітектури. Як ти будеш підходити до них? На рівні
Speaker A
архітектури. А в плані, як би я його тестував би взагалому? Ну, дивись, якщо ми говоримо зафл, та це концептуальна модель. Та це певний, ну, підхід. Та от як на основі цього підходу протестувати то, що є в наш, ну, сер, ну, в нас наш
Speaker A
сервіс та є Rest Full, які основні моменти потрібно чекнути? то, що він використовує протокол HTTP. А так само е зазвичай по використовується якби в ресті той самий JON для передачі даних, але він, якщо я правильно пам'ятаю, він не обов'язковий. Він може
Speaker A
використову використовуватись, до прикладу XML то той самий, але зазвичай в останній час тіпа всі використовують е-е Jon. А чому так?
Speaker A
А чого Jon XML? Та от поясни, будь ласка, мені, де використовує, де ліпше використовувати Jon, де ліпше використовувати XML? Ну, в Jon краще використовував взагалі, в принципі, мені легше використовувати було завжди JSON, бо він, перше, більш інтуїтивно зрозумілий, його легше
Speaker A
писати, е, менше займає, ну, місця, якщо ти, грубо кажучи, про баді, наприклад, якесь кажеш. В XML краще б зазвичай він використовується тільки в Суапі, але SUAP - це як я не скажу, я так не скажу. А ну XML типа Ну а по
Speaker A
Суапу як А як ти по-іншому в Суапі окрім Ні, я не скажу, що він там от переважно використовується там. Він може ще десь використовуватись. А переважно типа XML, ну типа його ну якби відносити до SUA, да. Є є такий чинник один, та який ти
Speaker A
проговорив вже. Та це що обсяг даних та і скільки вони важать. Е, тобто просто в Суапі, ну просто SUAP використовує тільки XCML, типу Redfull, наприклад, може використовувати і Jon, і XML, але в, наприклад, в XМлі, наприклад, є оці от е-е теги, котрі,
Speaker A
наприклад, ну, їх просто інтуїтивно важко типу розуміти. Ну, їх можна зрозуміти, але щоб їх писати, типу це потрібно постійно це писати, писати, писати, писати. Наприклад, в а в джесоні, наприклад, ти можеш отак от зробити. Але, до речі, так само про
Speaker A
передачу даних. Е-е, в, наприклад, в, е-е рестфулі наприклад є е-е об'єкти і масиви, а в Суапі, наприклад, ти не передаш ніяк, ее, масиви.
Speaker A
А, продовж далі про Restf. Ти сказав тільки що е, що у нас має бути в Restfall апі сервісах обов'язкове?
Speaker A
сервіса. Ну, повертаючись до питання, та в них Jon та або XML, неважливо. Ти сказав про це. Що дальше?
Speaker A
А раз по запитах метод повинен бути урла. Ну, урла то, ну, вона зрозуміла, типа сам домен, типу, котрий повинен бути, типа пас, котрий повинен бути хедери.
Speaker A
Обов'язково content type application Jon. Ти вже говориш, він може бути application XML. Е, він може бути application XML спокійно. Типа як це відноситься до Rful.
Speaker A
Аа, ну я кажу просто зі свого досвіду, що ми зазвичай використовували тільки говориш. Ти говориш про реквест, про структуру реквеста. Я тобі говорю зараз фул. А чи ще щось ти можеш додати до цього?
Speaker A
А до того ще якби я перевіряв бифл типу на рівні архітектури. Є метод є по методу. Окей. Добре. Які методи в нас чому саме методи є? Ну от в ре, да, і вони визначені строго. Чому так?
Speaker A
М ну вони визначені для того, щоб зрозуміти, який екшн ти хочеш зробити з цим запитом, бо від цього методу залежить е то, як сервер себе поведе. От один можна постом зробити delete?
Speaker A
постом робити delт. Да, да, можеш спокійно, типу, якщо це сервер так обробить, типу, він може спокійно зробити. Е, але тобто по, наприклад, один один сервер, в мене були кейси, коли ти міг, е, постом все абсолютно робиш, типа, або путом, наприклад, ти
Speaker A
створюєш, а оновлюєш постом, типа, чи, ну, делітом мене в мене менше було набагато кейсів, типа, але от, е, він імплементований так, те, що це залежить від того, як працює сам, е, сервер, типа і ну зазвичай ми розуміємо, що якщо постти
Speaker A
створюєш щось гетом, типу отримуєш, потом щось оновлюєш Або так само створюєш, якщо це перший типа айтем, типа delм деліш. Окей, окей, окей. Е, добре. Ще що? На рівні архітектури е-е чесно таке е, не складне питання, бо типу я прям
Speaker A
так не не думав, а над таким, але над рівнем архітектури. Ах. Що ще може бути? Да, давай собі подумаємо, да, це не складно. Ну, наприклад, уніфікація методів, ми сказали, що має мати визначений URI.
Speaker A
URL, та добре, да, URL і пас, котрий повинен бути, типу так само. Це не менш важливо.
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
Куда приходи куди приходи меседж? В чергу. Чергу, наприклад, той самий ребіт MQ чи Кавку, наприклад, так само. І вони приходять, типу, і там ти вони обмінюються одне з одним інформацією, котра на котру ко котру їм потрібно, чи котру вони запитують чи передають.
Speaker A
А яким чином вони це роблять? Ну, є в мене от дивись, в мене є вісім мікросервісів. Я я запуляв івент, наприклад, да. Як мікросервіс розуміє, що це івент його?
Speaker A
певні, по-перших, ну, якщо ми роз розумієте його, по-перших, це атрибути, котрі в нього є, наприклад, ті ж самі теги або певна, а, скажемо так, мета метаданна або, ну, теги або атрибути, котрі підв'язані під певний а-а мікросервіс, типу, щоб він розумів під
Speaker A
ее що він. По-других, це якщо він робиться в чергу якусь певну, якщо того, то що я розумію, а-а, в чергу, то воно воно не може бути чиєсь інше. Типу, якщо він за запуляв типу в чергу мікро другий, запуляв пшого, типу, він не може
Speaker A
бути відноситись до сьомого. Він не пуляє в один одному, він має загальний м це називається баз.
Speaker A
Ну, він має, по суті, свій бас та і кожен мікросервіс вислухує з того басу ті івенти, які до нього дотичні. Добре, рухаємося далі.
Speaker A
А, добре, давай, давай трошки про Посман. Це моя улюблена тема насправді. А-а, розкажи про свій досвід коротко, будь ласка, і тезисно з Посманом, щоб я розумів.
Speaker A
з Постманом, напевно, багато працював. Тобто як створював колекції типа з самого нуля був такий досвід а-а створення ко колекції execute колекції, створення для third party е ресурсів, створення тих самих варіайблів, а-а, і якісь мінімальні автотести, тобто по три по прикладу там
Speaker A
створення, да, створення ключа, створення юзера. е-е там логін іліт, наприклад, чогось чи створення там тогото грубо чи такого, але це не було е-е в рамках е флоу кома саморозвиток.
Speaker A
Мені цікаво, скільки переміник є у Посмані? А-а перемінних є у Посмані. Так, скільки є видів перемінних у Посмані? М змін. Хм, Цікаве питання. Е, що ти маєш на увазі? Типа, ну, як, як ти перемінні створював? Змінні. А, ну, змінні в
Speaker A
моєму, е, розумінні це типа вузначаєш якусь перемінну, правильно? Вона є певного виду. Добре, давай відповідь на це питання я відповім. У постма є чотири види перемінних. Перше є variables, друге collection variables, третє є environment variables, а третє, а
Speaker A
четверте global variables. Я я зрозумів, дати Угу. Добре. Ти створював колекції в постмані та чи ти використовував скрипти правильно? Да. По постскрипти, прескрипти, але там було такий мі мінімальний досвід не сильно з ними прямо. А а чи ти розберевся трошки
Speaker A
дальше, да? яким чином ці скрипти взагалі реалізуються і так дальше. Можеш відповісти на це питання чи складно?
Speaker A
Загалому то, що я зрозумів, тобто по постревести пререквести і постревести, вони потрібні для того, щоб якусь, ну, пререквести, щоб або забрати дату, наприклад, з якогось варіайбла, наприклад, там зенвайромента, або зробити якусь певну дію для того, щоб створити е це запита, наприклад, я
Speaker A
використовував для того, щоб забирати от, наприклад, ключі аутентифікації, наприклад, і для того, щоб одразу їх сетати не руцями кодувати, типу, а для того, щоб сетати в а-а в змінну а variaable наш в в колекцію, щоб можна було одразу
Speaker A
екзекютити наступний або, наприклад, щоб вони автоматично зали яким чином відбувається вичитка респонсу за допомогою скриптів?
Speaker A
А в за допомогою? Ну, дивись, давай уявимо ситуацію. В тебе є от, наприклад, якийсь запит з авторизації, так? Ти хочеш вичитити з нього що? Токен, правильно? Для того, щоб переписати в якусь певну варіable. Яким чином ти робиш так, щоби в те отримати з респонсу
Speaker A
цей токен і записати його? Ну, ти робиш скрипт для того, щоб він читав цей е-е А я розумію, що скрипт робиш. А яким чином? Що в цьому скрипті буде включено?
Speaker A
Давай мені два аспекти. Це саме головне. Перше, що повинно бути, це тип даних, котрі повинні приходити, типу ж ні формат, котрому вони повинні приходити, тип даних, котрий ти так атрибут, котрий ти хочеш отримувати, щоб він отримався і ее значення з нього. Яким чином ти це
Speaker A
робиш? Ну, типа, це зрозуміло. Тобто я хочу, наприклад, токен. Та мені треба токен. Вот, наприклад, ну, що ти робиш?
Speaker A
Що ти в скрипті вказуєш? От скрипт робить якусь певну функцію. Та перша, друга. Та перша - це яка? Перша - це от прочитання то нашого нашої відповіді, котра нам пішла від сервісу. Так, добре. А яким це робиться?
Speaker A
А яким чином? Що ти робиш? От з відповіддю таке одне слово є. Ну ладно, ти парсиш, ти парсиш дані. Ну, парсинг. Ну, да, да. Ти парсиш дані з відповідним ключем, та які тобі потрібно. А друге, що ти робиш? Считуєш
Speaker A
дані, котри ти туда, туда ти з того атрибуту, котрий ти хочеш. Е, добре. А куди ти її записуєш? І ти її записуєш уже тоді туди, куди ти хочеш. Ти хочеш який хочеш вариаable? Типа свій в collection, вvirймен або в glг. М.
Speaker A
Угу. Чи використовував ти щось більше, чим Postman? Наприклад, Newman. Newman я не використовував. Свагер юзав.
Speaker A
Swager. Окей. А чи ви, ну, от чи використовував ти, наприклад, колекцію десь на CCD?
Speaker A
М? Ніт, таке таке не було. Якщо Окей, добре. Який в тебе досвід зйками? Мені цікаво. В Argo CD працював і білдрадари працював. Як?
Speaker A
працював. Ну, в плані дивився от про останній досвід типу, тобто ми дивилися першими деплоїли самі ж типа пайплайни, котрі у нас були на певний от шматочок функціоналу, котрий ми імплементували для того, щоб перевірити на певному енвайронменті.
Speaker A
Дивилися, як воно взагалі теплоється на них. Ти виконував ти виконував pйплаine на якийсь певний enваймент для того, щоби що? Для того, щоб його потестити.
Speaker A
Добре, давай свічнемся тоді на проксі. Розкажи мені свій досвід з проксі тулами. Нащо ти їх використовував і нащо ти використовував код, бо в тебе це вказано в резюме? А, да, з проксі тулами використовував. Ну, тобто, грубо кажучи, читання тих самих а логів, того
Speaker A
трафіку, я би сказав би, котрий в нас проходить через певні девайси. Той самийкод дуже сильно допомагає, знову ж таки, в залежності від самого продукту, десь воно дозволено, десь не дозволено, типу, але сама ця тула допомагає нам подивитися, е, як def tools, наприклад,
Speaker A
ми використовуємо для в Network, наприклад, для того, щоб дивитися, як які запити дивитися. А дивитися, що саме в проксілі, що ти дивишся?
Speaker A
Прок тоді ти дивишся просто, ну, ті запити і той трафік, котрий в тебе переходить через апку. Ми дивимося, то що ми бачимо?
Speaker A
Вкді. Ну так, ну ти ж говориш, що ти юзавко перепитав цей, ну, в ексді вкладку чи що ти маєш на увазі? Добре, а при яких умовах ми можемо вкладку подивитися? А при умовах того, то що в нас, наприклад, якщо ми кажемо про Xкод,
Speaker A
слідчим ми кажемо про iOS типу, то повинен бути дозволено від акаунта, котрий нам дав от апку, щоб це був дебаєрський білд, правильно? І маємо ми збілди його. Що?
Speaker A
А збілдити? Ну, ну є дуже важливий чинник. Та ти не побачиш підкапотних логів, якщо не збілдаєш це на свому на своїй машині та на девайс. Ну це знову ж таки це все залежить від того нас в я якому виді
Speaker A
тобі підключаються. Бо я, наприклад, тут дивився в останній мій досвід був з ее це був через тестflight, тобто там не було е-е цих е білдів, котрі тобі віддавали файлом.
Speaker A
Типу ти дивився вже в теслайті конкретну версію. Я тобі не за тест. От, наприклад, ми можемо там подебажити, наприклад, якісь критичні, ну, штуки, які пов'язані саме з девайсом та нашим аплікейшеном та якісь кращі і так дальше. Ти тільки це
Speaker A
можеш зробити, якщо ти збілдаєш це на машині. Ну, типа, або через кокод збілдаєшся на апку і так дальше. При інакшим при інакшій при інакшому в тебе нема можливості подивитися на стільки детальні логи.
Speaker A
А, окей. Добре. Що стосовно white тестінгу, що ти використовував? Ти вказав це в резюме? Мені дуже стало цікаво. Поділись.
Speaker A
Да, я пам'ятаю, як на цього увагу. Да. Мо, ти знаєш якусь мову із програмування? Ну, взагалі ну JS на базіксу, типа. Та так. Не, не, не програму. Ну, тобто саме ті самі API реквести, тобто постмоні там Jon типа
Speaker A
JS, тобто майже одне і те ж саме типу, тобто Ну окей. Ее що стосовно White Boxing White Box, я просто не знаю, чого так здивувався. Типу по факту багато хто, ну, я казав би не всі, ладно, типа, скажемо так, багато тестувальників
Speaker A
просто самі не розуміють того, то що, наприклад, вони використовували BB. От мені цікава твоя думка. White Bкting.
Speaker A
Сор, я просто ее запинай вже. Е-е, коли, наприклад, приходить реквеквест, наприклад, від девелопера якись, не знаю, чи нова фіча, чи якийсь фікс, ти можеш в, от в мене було, наприклад, в бітбакеті подивитися цей requквест і подивитися взагалі, що він зробив. Тобто
Speaker A
атрибути, які у, наприклад, видались, там червоне написано і зелене, наприклад, що що додалося? Це от, наприклад, той самий статік тестування, котре нам допоможе подивитися взагалі, що він зробив. Тобто це оце називається WhiteБ. Ти подивишся взагалі. А мені мені дуже цікаво, а що ти можеш
Speaker A
зрозуміти з комітою, якщо ти не розумієш ну коду? М ну, наприклад, там додалось там вісім класів, е, імплементовані багато якихось певних змін в коді. Як ти це зможеш зрозуміти? Та і нащо? Чи тобі, ну, доцільно це розуміти? Та от яке велью ти
Speaker A
даєш тим, що ти дивишся коміт? Е, дивись, стосовно того вісім класів, коли ти сказав, типу, це зрозуміло, якщо у тебе немає таких компетенцій, це, ну, немає сенсу це передивлятися і рев'ювати взагалі. Я кажу про те, то що йбок
Speaker A
тестування передивитися взагалі, що девелопер додав, типа, і чи взагалі зробив він то, що ти очікував. Тобто, наприклад, ти можеш подивитися, якщо ти хотів, щоб він додав там от е просто текст, там текст один замість там нала, наприклад, все додав і ти
Speaker A
подивишся оцим от ее статік тестування в цьому реквесті, ти подивишся, що він дав взагалі якусь там біліберду взагалі ти кажеш йому, ти навіть не екзекютиш сам код, ти і не за екзекючивши, ти подивився, що він взагалі не зробив не то, як до прикладу.
Speaker A
Зрозуміло, якщо в тебе немає певних це розумі це тві це твій досвід з white боктенгу. Та це ще ще щось є чи це все е зйтбок тестінгу? Ну по факту, да. Це от окей. Е ти вказав, що працював з
Speaker A
тестрейлом. Мені цікаво, який ти підхід, ну от використовував для написання для не то, що написання, для організації там тесткейсів. Що ти використовував? Ну там тестрей, то якби все разом. Там є кокод і зефір типа там то ой-код, боже мій. Е, x-ray. Е-е, ну,
Speaker A
там все однаково, типа, неважливо. Ну, ти використовував ТМС. Так, добре. Який підхід до організації тестових випадків ти використовував? Е, тестових випадків чи в загалом про структуризацію откруї документації можна. А тестові документації. По-перших, по потрібно зробити декомпозицію самих фічей, типу
Speaker A
декомпозицію самої системи, на яку буде розподілені певні а-а модулі, типу, то котрими будети певний функціонал для того, щоб як мінімум можна було зайти спокійно подивитися, як е е-е як воно структуровано, типа, і не плутатись там, де що знаходиться, а по-других
Speaker A
створювати а-а підхід м створення. Ти маєш на увазі самого е-е створення з для наявного функціоналу чи вже котрими буде в процесі девелопменту.
Speaker A
Ну, дивись і яка між цим різниця тоді давай так. Ну, в тему то, що, наприклад, наразі функціонал, якщо він якийсь є, в нього повинна бути якась документація або його може не бути. Якщо ми робимо якийсь функціонал, котрий повинен бути,
Speaker A
на нього 100 100% повинна бути якась документація або бажано її завести. Нащо ти пишеш тестові випадки? Для чого в переважній більшості? Ее для того, щоб перевірити і чи працює той функціонал е по по тим критеріям, котрі були задідані. Добре. А друге, а друге - це
Speaker A
не менш важливо підтримка в майбутньому цих тестових випадків, щоб вони е-е давали зрозуміти, чи вони взагалі е актуальні і чи нічого не зламалося в майбутньому. На що е нащо їх для якої активності ти це використовуєш? Е для регрешен, ти маєш
Speaker A
на увазі? Ну та та я це хотів почути. Добре. Для регресивного тестування. А-а, добре. Як ти думаєш, який з золотий стандарти з кейсу?
Speaker A
Е-е, золотого стандарту немає. Це все залежить від капасті продукту. При Давай так. При регресивному тестуванні який золотий стандарти скіс? А при регресивному тестуванні, ну, те ж саме, що я сказав, тобто ві від цього залишиться. Але якщо е-е для
Speaker A
регресивного тестування чи коли для регресивного тестування е-е для того саме для того, то що я зрозумів, саме головне, щоб він був уніфікований цей тесткейс, тобто він не був прив'язаний до якоїсь а певної а-а з залежної, тобто а константи, наприклад, що число тільки
Speaker A
100 повинно бути е для того, щоб в майбутньому, коли ми ту ж саму регресію робили, наприклад, о не один там, а п'ять 10 тестувальників її проходить водили один той самий тесткейс, один банальний тесткейс, там вводення числа, щоб він вони вводили не одне число, а
Speaker A
вводили різні варіанти для того, щоб ці в майбутньому якісь можливі інконсивності, котрі виникають чи можливо були, щоб вони всі по можливості їх перевіряли.
Speaker A
Я думаю, що це більш навіть правило золоте, а а не стандарт та по написання тестової документації взагалі, що не має в тебе бути ніякого, в принципі, значення та яке потім буде пестицидним.
Speaker A
Та кожен тестувальник по свому досвіду або по своїй по своєму розумінню цього тесткейса має приймати своє значення і свій вибір. Та де це допустимо? М. Окей.
Speaker A
Добре. А, Пурум-Пум, ти вказав, що в тебе є досвід інтеграції 50 пс платіжних методів. Так.
Speaker A
Розкажи про процес тестування от просто нового платіжного провайдера від початку до кінця. Ох, я можу на цю тему розмовляти довго.
Speaker A
Е-е, все починається в загалом з планування, тобто з того, з мінімальних реквійментів, котрі нам приходить від того ж бізнесу, ну, як в мене це було, того, то що ми хочемо зробити, це deposit draw, в який ее, наприклад, payймент методи ми хочемо від певного
Speaker A
провайдера, типу, чи як вони повинні оброблятися. починається це все з самого інвестигейту, його документацію, розуміння, як вони працюють, по якій системі, які у них є підходи і чи саме головне - це взагалі побачити наскільки їхня документація взагалі актуальна до того, як вона
Speaker A
працює. Тобто ти, наприклад, воно написано, що повинно бути 200, якщо ти от все це ввів, ти береш, екзекюш, а там, наприклад, пятисота чисота, типа. І от мож можна більш конкретики стосовно цьго, ее, да, тобто ее коли ти е
Speaker A
перевіряєш оці от е методи, саме головне - це е-е перевірити по-перших е-е позитивний флоow, котрий написано в цій е документації. Наприклад, там написано, що по постом ми створюємо, наприклад, там а-а header ау, ой, боже мій, beре, е токен аутентифікації,
Speaker A
наприклад, одним. І цим токетоном ми, наприклад, можемо зробити там депозит, наприклад, реквест на депозит. В мене питання: а чи схожі були ці 50 інтеграцій між собою? Е, деякі, да. Е-е, але якщо ми кажемо всередині самих а-а провайдерів, всередині провайдерів вони
Speaker A
багато на чим схожі, але посередині різ різних провайдерів типу ці payment методі можуть абсо абсолютно кардинально. Та ж сама віза може на провайдері одному бути нормально зроблена, а на другому взагалі по-іншому. Тому це все залежить від підходу до створення цього.
Speaker A
Окей. Добре. А розкажи, будь ласка, мені за якийсь певний свій такий досвід, що, наприклад, в тебе був якийсь рутинний процес, та от в тебе є рутина така ужасна, да, і ти це оптимізував, автоматизував, можливо. Розкажи про такий досвід, якщо є.
Speaker A
А автоматизувати, я би сказав би так, що цікаве питання, цікаве, цікаве, цікаве. А-а, ну, наприклад, створення того ж самого чекліста, наприклад, е-е, котрий нам потрібен мі мінімальний.
Speaker A
Тобто це хай хайлевельний чекліст, котрим ми, наприклад, можемо перевіряти певний функціал, поки навіть навіче немає або немає реквайментів, або їх нема не буде взагалі, типу, або е-е це дуже про просто можна зробити, наприклад, на через AIку, наприклад, собі зробити або якийсь певний чекліст,
Speaker A
наприклад, от тій самій інтеграції, про котрі ми говорили. А-а, не покривати тест кейсами цієї інтеграції, це просто немає сенсу.
Speaker A
Набагато простіше і зрозуміліше, якщо ми зробимо якийсь уні уніфікований чекліст, котрий буде перевіряти певні атрибути, котрі нам потрібні, наприклад, в першу чергу, типа, що провайдер може працювати по-своєму, ми їх навіть можемо не знати, типа, як вони там працюють на своєму,
Speaker A
але вони щось нам віддають. І саме головне, щоб у нас вони, наприклад, е працювало.
Speaker A
Стосовно такого автоматизації, чесно, зараз складно згадати. Окей, добре. А як дивіться, шановні глядачі, Маркус, Олекса, можна тебе викликать? Олекса сказав включити. Включити. Чекайте, дайте потру лампу.
Speaker A
А в мене є цей reactions. Так, я от тільки відійшов руки помити і ви одразу одразу одразу покликали. Скажіть, будь ласка, ми можемо зробити буквально дво-трихвилинну перерву? Звісно, антракт. Антракт. От я пішов руки мити, чай робити. Бачиш, я
Speaker A
передбачив, я от і хотів це робити. Звісно. Е, друзі, хто дивляться, також давайте собі чайку трошки вечір холодає.
Speaker A
Або що ви там піти? You welcome. Так, робимо паузу. Угу. Так. Друзі, пишіть, як вам. Є дві хвилинки поспілкуватися, е, поки хлопці повертаються.
Speaker A
От так. Ну, питання в співбесіду у нас зазвичай, це я коментарі читаю, зазвичай ми це не практикуємо, тому що ми намагаємося, наскільки це вдається, зробити співбесіду максимально, ну, реалістичною. Так от, тому, щоб не перетворювати це на щось неочікувано
Speaker A
хаотичне, зазвичай питання не ставимо. Але, звісно, якщо, е, Костя подивиться в чатик, хоч я всім раджу не дивитись, щоб просто не відволікалися люди від один від одного і сам намагаюся не дивитися, коли проводжу сам. От. Але якщо подивиться і поставить питання, то
Speaker A
звісно його welликом. От. А якщо питання до мене, то звісно я не не відповім.
Speaker A
Може ви хочете в мене запитати, як як Маркус цей перевіряв колбек. Я не знаю.
Speaker A
От. А про курс не розповім. Е, тільки скажу, що в посиланні є в описі є посилання на ukuна і ви там побачите новий курс. Він навіть іншим кольором на цьому. Але я не хочу вкрасти час і увагу від хлопців, тому що цікаво, мені цікаво
Speaker A
слухати. Вподобайки поставили, якщо вам цікаво. От. Е-е. Угу. А я пішов. Все, я тут.
Speaker A
Давайте. Добре. В мене, якщо продовжуючи цю тему, та в мене є питання стосовно, як ти думаєш, які основні ризики існують в тестуванні платіжних систем?
Speaker A
А-а, основний ризик того, то що вона взагалі може не запрацювати на продукт enвайронменті, як сама така став, з котрою я зіштовхувався. Тобто, що, наприклад, ми тестуємо її локально, типу ми тестуємо на de маті, воно робиться окей, окей, окей, окей. Але були
Speaker A
випадки, коли, наприклад, ми запускали його на продакш, типу і, наприклад, або самі перевіряли, або, наприклад, бетатестри перевіряли, воно, ну, взагалі не не працює, типа, чи за допомогою чого, які інструменти ти використовуєш для того, щоб передбачити якісь певні критичні кейси?
Speaker A
А якщо ми кажемо конкретно про цей кейс, наприклад, його дуже важко передбачити, бо, ну, немає у це залежить не від нас, а від провайдера самого, як він запрацює. Типу, давай так візьмемо. В нас платіжна система strike, наприклад.
Speaker A
Угу. Ми її інтегруємо там з нашим сервісом або вона інтегрується з якимось сервісом. Е, наприклад, якісь ставки, я не знаю, пофіг вообще, да.
Speaker A
Яким чином ми можемо перевірити роботоздатність тральпу на нашій системі? Наприклад, роботозадатність страйпу. Ну, со страйпом дуже мав мало досвіду, типу, я би сказав. Неважно, бо будь будь-яка платіжна система, та яка є, ну, там Big Enterprise, там, можна так сказати, ну,
Speaker A
популярна, не знаю. Ну, наприклад, сама віза може бути American цей American американські карти. Ну, скріл, наприклад, самий популярний от в Європі, котрий є. Ну, давай, давай, давай. Яким чими зараз кажемо про с ризики, правильно? Чи про те, як протестувати його? Ні, зараз про
Speaker A
те, як протестувати. А дивись, по-перше, треба проінвестийтити їхню взагалі, ну, я би продивився би перше їхню документацію, як вони взагалі працюють, типу які у них є запити, як вони взагалі працюють, типу чи авторизація, аутентифікація, типу, як вони працюють,
Speaker A
типу чи є у них якісь можливо нюанси, котрі нам потрібно перед девелопментом. Наприклад, там, щоб вони завайтлейбли наш наші айпішки, якщо у них, наприклад, така авторизація, наприклад, нам їм потрібно, щоб ми взрали, чи дати нам певних тестові акаунти для того, щоб ми
Speaker A
дивилися е як вони як ти перевіриш там недостатність коштів, наприклад, або як ти перевіриш будь-які чинники, які будуть впливати, наприклад, там з неплатоспроможністю клієнта, заблокованістю його, простроченим CVV і так дальше. Да. Е-е, да, це якраз хотів дойти, типу, тобто ми, по-перших
Speaker A
подивимося, взагалі дізнаємося і про нього, як воно працює, типу робимо е про те, як перевірити оці всі методи.
Speaker A
По-перше, треба зрозуміти е позитивний метод для того, щоб він працює взагалі взагалі взагалі працює по то по тій документації або якщо не працює нормально зрозуміти у а самого провайдера, як воно працює. Але зазвичай я зміг якось там туди-сюди зміну типа
Speaker A
перекидути або якось там змінити якийсь тип даних чи якісь там перекинути, то воно плюс-мінус зго. Але краще це все перепитати у провайдера для того, щоб поверчатись до другого питання того, щоб перевірити а-а оці ечкейси, котрі у нас можуть бути типа чи
Speaker A
ві від ві варіанти відповіді серверу, котрий у нас буде використовується так само тестова документація. Ну, якщо ми кажемо про тестове середовище, ее, з певними атрибутами, наприклад, там тест тестові карти, наприклад, провайдер там, е, надає, ну, в нормальних провайдерах
Speaker A
дають тестові карти, наприклад, або тестові акаунти, на які, наприклад, роблять певну, е, тобі відповідь і вони, е, будуть тільки там недостатньо коштів, типа, чи там заблокована карта, інвалід, CVV і так далі, і так далі, і так далі.
Speaker A
Як це називається? А це ти маєш на увазі сам erorрх hand хенлінг? Снбокси на деть пісочниці тестове середовище типу. Да.
Speaker A
Це маю на увазі про це я казав. Не зовсім тестове середовище, але типа воно це пісоч Ну да. Стбокси, тобто там із теestru чи фолс, типа так само може цим переключатися. Окей. Які тести ти вважаєш обов'язковими?
Speaker A
для перевірки платіжних систем. А, ну як для як для бізнесу виходить, це в деяких бізнесах це саме основний бізнеслю, у котрі в принципі воно є. Тобто і саме головне, наприклад, що вони взагалі е дуже важливі каж системи, типа перевірка типа і головне,
Speaker A
щоб вони працювали стандартний флоу, котрий у нас є. Тобто в нас по факту то, щоб юзер зайшов, зареєструвався, у нас прийшли кошти, я би сказав би, це один з самих головних а критеріїв. Вже якщо ми дивимося по негативним кейсам, якщо юзер
Speaker A
там то чи то чи то чи то, це вже це не менш важливо, типа, але не так важливо, як позитивний флок, котрий у нас повинен бути стандартно з юзера. Угу.
Speaker A
Добре, давай перейдемо до до логів взагалі. Що ти використовував? Я бачу, що це Open Search та Kibana.
Speaker A
Ну да, Open Search воно в принципі просто одне і те ж саме по факту, але на різних проектах в мене називався, але так само використовував в Локі. Угу.
Speaker A
Е ти використовував це для чого? для того, щоб дивитися, як працюють наші мікросервіси, які вони меседжі відправляють і дивитися, чи немає якихось еров. Да. Добре. Як як ти організовував? Ти організовував, наприклад, якийсь збір метрик на продакшені або збір метрик на тестовому
Speaker A
середовищі при викатці якихось певних функцій. Як ти визначав стабільність свого продукту по Кебані? Ну або по openрчу, неважно які по Кибані особисто я, ну, про метрики в загалому так я збирав, типу, але якщо ми кажемо конкретно про а логі, то у нас, я цим не
Speaker A
займався. Це у нас була графана, котрий ми дивилися, oncle інженери використовували для того, щоб дивитися наскільки у нас є, наприклад, тих ерорів, котрі у нас падають на продакшені бо наприклад девелопенті це не сильно має ее релевантно воно мати
Speaker A
такі ее алерти, наприклад, коли там один пви метод бере просто і тупо от все валиться типу роррори. Тобто те ж саме от метрики, котрі нам допомагали, наприклад. А конкретика ти викори ти збирав метрики чи ні? А особисто я ні не
Speaker A
збирав метрики. Все, дякую. Все, цього достатньо. Е так само е root кейс аналіз, наприклад, чи ти, ну, наприклад, щось прилітає з проду.
Speaker A
Рудкос аналіз можеш, рудкос, да? Рудко аналіз, да, звичайно, це дуже крута тема. Типу, от то саме HTQB дуже сильно його от я пройшов ще в курсі, я зрозумів, що таке взагалі родкос аналіз, що таке взагалі бах, типа, і звідки воно
Speaker A
робиться типу, то це не просто типу там, ну, в нас зробив бах, це бах. У нас якби є рудко рудкос, котрий робить якийсь свій erрор містй, котрий робить в свою чергу бах дефект.
Speaker A
Бахдефект переходить в failor, але так само ніхто не застрахований, то що цей баг може бути зроблений так само не з цьої з root cзу, а, наприклад, environment configuration, наприклад.
Speaker A
Так само може бути за ефект зробитися цей баг. Окей, добре. ти вказував, що ти е-е тестував сумісність з 20 плюс Іо пристроями. Яким чином ти це робив? Е, да, це було от на першій моїй роботі.
Speaker A
Типу це такий був дуже, е, екзотичний для мене досвід, бо, ну, це реально була компанія, котра от з було поста Маркус, яким чином ти це робив? Да, да, да. Тобто це компанія просто поставила е нам для нас ее для
Speaker A
тестування е задачу перевіряти всі от наші тутсунки, котрі казав маленькі оці дрібнішки на оцих девайсах. То ти, тобто береш от реальний девайс, просто береш, включаєш їх, завантажуєш собі на iPad, iPhone, е-е Mac, е, ну, на Apple Watchі, конечно, ми не використовували, але на
Speaker A
оці всі девайси, тобто і ти береш отак от е береш, перевіряєш як сумісність. Тобто по факту це портабіліті, типу а-а можна було б сказати, типу, але я я думаю, що це більше було до доречно до адаптивності самої верстки, типу як я
Speaker A
зрозумів. Ти не ти не приймав учені участі з визначення, наприклад, девайсів актуальних ее операційних систем на яких версій їхніх і так дальше. Ти просто виконував тестування, правильно? Ні, якщо якщо ти кажеш сугубо всіх 20 девайсах, то тоді ні, бо це мій був
Speaker A
перший досвід. Я взагалі Але подалі, да, ми я приймав типу в в участь в тому, то щоб ми просто е-е зменшували чи якийсь певний брали вид а я би сказати так характеристик. Ну, наприклад, там iPhone Pro Max Pro і звичайний. Нам не треба
Speaker A
там всі айфони лінійки типу до кінця там достатньо там основних характеристик, котрі здебільшого використовують ті самі юзери, наприклад, на Я зрозумію. Е, давай далі. В тебе є вказано, що в ти покращив процеси фавбеbet. Що ти саме зробив?
Speaker A
А-а, в принципі, коли прийшовши на проект, трошки була, а, запущена документація, я би так сказав би. Тобто там е-е проект дуж дуже дуже великий, гігантський і дуже старий. Як мені Тімлі сказав, там були е єсть шматки функціоналу живих людей, котрі знають,
Speaker A
як він працює і вже немає. Типу добре тоді проблеми в тому, що було велике legy, правильно? Да, велике leg, тобто і наприклад регресії там як такової взагалі не було. використовувались смоки. І той самий, наприклад, смок сю, котрий ми використовували перед піс
Speaker A
перед деплоєм і після деплоя вже перевірки на наварентах, котрі ми заливалися. Е-е, от цей, е, так само, е, якщо ви кажете так, по-перших, е, це документацію і процеси самі, це Shift, left, а, approach, тобто, ну, той самий рефайменти, котрі були, типу це
Speaker A
перевірка а-а самих ізольовано пайплайнів. Е, ну, це не те, що звичайно моя ініціатива, але оцей шифто А це як ізольованих пейплайв. Що ти маєш на увазі? Пітизольова ізольовані шматки коду. Сер, може не так визначиться.
Speaker A
Ізольовані шматки коду котрі ми в паплані заливаємо, типу. І той самий Shift Left. Е, мене мене цікавить іменно твоя ініціатива. От я встав, наприклад, і сказав: "Короче, ребята, сьогодні я от поняв, що отак нема не має бути, да?
Speaker A
Давайте з цим щось робити. Конкретно надав аргументи свої, чому і як. Будь ласка, оцей досвід мені цікавий. А, да, окей. Тоді той самий Сумоксютко сказав, тобто я їх цей і наш і інший сервер сусідній, котрий у нас був, так само їх
Speaker A
е я заініціював типа, ну і мені просто, бо я такий ініціативний, мені якби Тімліт на назначив, щоб я його зробив, тобто ее з актуалізував, я би сказав би так, бо там було дуже багато перевірок, котрі, наприклад, ну там не сильно він
Speaker A
був великий, типа, але е я зміг так його зменшити його перевірки, котри в нас, наприклад, ми перевіря віряємо additional чи, наприклад, котрі не сильно вони потрібні, не актуальні і дода і додав ті, котрі нам потрібні. І друге - це з створення самого баг
Speaker A
репорту, бо був дуже такий осередкований багрепорт, котрий я читав. Типу, знову ж таки е там своя якби кухня, типа, але прийшовши туди, я ввів якісь такі, а-а, сказати і за ініціював того ото, що можна багрепорти описувати зовсім по-іншому,
Speaker A
що є нормальний summer з якимось, е, з розумінням того, який модуль, наприклад, чи яка частина функціоналу робиться. Е, summary по нормально описано expected, actual result, цей стеби і так далі, і так далі. покращив ее саме створення Бахрепорту. Правильно? Дада. Да. Ще
Speaker A
щось? А-а що е смаки а-а оновив і [музика] а-а не напевно напевно це все. Угу.
Speaker A
Окей. А добре. Ти мав досвід в керуванні командою, правильно я розумію? Ну да, по певній мірі.
Speaker A
А скільки людей було в твоєму підпорядкуванні? А якщо ми кажемо, ну, в залежності від, якщо ми кажемо про CGS, типу, де я працював, типа, був єдиним першим тестувальником, приходив, там були якби Junніор, а, ну, я сам тоді, конечно, був
Speaker A
типа і ще з дженом, типа, було приблизно три три тестувальника, котрих не те щоби сказати були в підпорядкуванні, я би сказав би так, був сніор локально в компанії старшим тестувальником, на котрий онбордив, розповідав взагалі про флоу дивив, показував ментори в певних
Speaker A
моментах, типу розказував якісь нюанси, котрі у нас є. І, ну, вгалом був таким трохи проводником, якісь мінімальні там вантування проводив і так далі. Якщо а-а казати м далі, тобто в тебе не було людей в підпорядкуванні, ти був просто
Speaker A
якимось старшим членом команди, правильно я розумію? Е-е, да, да, да, да, да, можна так сказати. Це міняє картину. А-а, добре. Таке для тебе питання цікаве на подумати.
Speaker A
Давай. Опиши, будь ласка, як би ти організував тестування при переході з терфол на скрам, наприклад.
Speaker A
А як я змінив би тестування би? Організував би його. Так. Угу. Ну, дивись, просто треба розуміти, як би його реалізував би. Ну, ми рухались по якомусь скрамбалу, якомусь скрамватербалу, можна так сказати, непонятному существу. та яке собі жило до того. Але ми
Speaker A
от готові до змін, да, вся ціла тема хоче помінятися, да, і звичайно з змінною методології там міняється підхід до тестування.
Speaker A
Угу. Да. Е, що саме та ти би організував тестуванні при цьому переході? Дивись, просто по-перше, треба зрозуміти, що приклад в моєму розумінні, коли це було до тестування ти доходиш тільки вже в самому кінці. Тобто в тебе є оці всі
Speaker A
степи принципі всі стейджі проектування, планування і ти доходиш по ватерфол. Зрозуміло, це ти доходиш до тестування в самому майже в самому кінці, коли це все зроблено. Доходи в самому кінці. Яка роль доходи в самому кінці до тестування?
Speaker A
чи quality control. А в самому кінці ти маєш на увазі потерфолу? Ну, по фактум, да, вона тестує. Хто в нас тестує? Ну, тестувати, якщо в твоєму різрі твого твого питання, це вже переходить, виходить тестувальники. Це quality assurance інженери. там не можуть бути,
Speaker A
бо ти, якщо ти не можеш ніяк, а-а, наприклад, ну, терфолі тото то, що ми от зробили, у нас є кожне stage і кожен stage кожен його вхід є е вихід з цьо вхід і вихід entry і exit критерія і
Speaker A
кожне екзит критерія попередньої буде е entry для наступної. В загалому в моєму розумінні терфолу, ну, це правильно, але, ну, це більше Stec.
Speaker A
А-а, не в тому питанні було. Окей, добре. Давай сконцентруємося на цій відповіді. От маємо класичний терфол. Та і от ми переходимо, наприклад, на agile якесь майндсета хочемо скрам. І які би твої були би організаційні моменти в тестуванні?
Speaker A
Да, дивись, так як в ватерлі, якби, ну, на моє на моєму досвіді то те, що я то, що я чув, типу Waterfall - це коли приходить до тебе вже тестування, без тебе абсолютно нічого не було. Ти приходиш і тестуєш ці штуки. В аджайлі,
Speaker A
коли ти будеш до цього підходити, тобі потрібно зрозуміти, довести до команди і до стейкхолдерів, котрі у нас є, що в нас тестува процес тестування тестувальники, самі quality assurance інженери повинні бути залучені з самого початку, з того етапу, коли у нас
Speaker A
створюється сама ідея створення якоїсь фічі. Тобто для того, щоб ми той самий Shift Leхоч змогли за допомогою цього Shift Leochмогли ее небажані типу і можливі ризики. Перших ми як змогли їх зааналізувати, продивитися, як воно буде імплементовано. Ее взагалі, чи має це
Speaker A
якийсь, наприклад, сенс. Наприклад, ми хочемо там зробити там підключити провайдера, щоб в нас було більше е-е pay е пейментів було. Але, наприклад, ти поаналізувавши, подивився цього провайдера, наприклад, ти підготувився до якогось піару, ти дивився, ну, в нього не так багато, в нього там і
Speaker A
складно, і так далі. Ну, тобто підводити все під питання і проводити це про себе, як воно буде йти далі. А-а, потім, а-а, [сміх] з е-е самого етапу планування воно повинно переходити тобто оці, він повинен залучатися на кожному етапі, котрий у нас є, починаючи з того
Speaker A
самого планування, execution або completion для того, щоб оцю рамку і ми ми могли тримати і ми на кожному етапі ми могли якось а-а а не те що під сапорти я би сказав би так ее зрозуміти що у нас якісь помилка бо
Speaker A
як е сама е дешеві помилки - це котрі знаходяться раніше плюс треба ще ураховувати тото що в на відміну від ава для мене Для мене це достатньо. А ти сертифікований спеціаліст по HQбі?
Speaker A
Да. Добре. Ти колись писав тест-план? Ой, не писав, але проходив. Приходилося. Ну не не приходилося, я би сказав би чи на жаль, чи не Да.
Speaker A
Але розуміння того, то то якщо ти маєш на увазі оційсь план типа 20ти листовий, то ні, такого я не писав і не був на проектах, котрі такі писали. На жаль, 16 пунктів, ало всього-навсього. І але якщо ми кажемо про однолистковий тест-план,
Speaker A
то в загалому таку концепцію як би сказати я якісь якісь мірі робив. Тобто це не зовсім неся тестплан, якби це більше як добре. Що ти з тест-плану би взяв в свою роботу? Для що для тебе от useful для з нього було би?
Speaker A
З тест-плану [музика] наприт у нас є. А-а для чого? Для чого? для, ну, для того, щоб зрозуміти взагалі, е, яка в нас ціль тестування, для чого ми робимо, для того, то щоб, наприклад, дивись, давай ти один, ти працюєш на проекті, да? Ти
Speaker A
розумієш для чого в тебе ціль тестування? Ну, зрозуміло, що в мене є ціль тестування, але в тестплані описується сама нюанси, котрі нам потрібні більше всього, на котрі ми акцентуємо увагу, бо наприклад як payймент провайдер ми більше чи, наприклад ні е система ее апка
Speaker A
котра спеціалізована, так, головне бізнес value, котре у нас є, це, наприклад, пейменти, котрі ми отримуємо, буде е основним, головним, тому що в нас ці пейменти приходили типа і вони, е-е, А, ну ти, ну ти розумієш от в своїй роботі,
Speaker A
от ти сидиш, наприклад, я єдиний тестувальник на проекті, да? Я ж розумію, яка там бізнес-велю і так дальше. Ну добре, ну це це твоя відповідь, не моя, але просто я хочу зрозуміти на хіба.
Speaker A
Та дуже просто для того, щоб зрозуміти взагалі на що нам акцентувати увагу. Тобто це ж робиться ж не просто так. І ми зрозуміли, що ми приходимо находити всі можливі баги, котрі у нас є. Хоча такого неможливо. Типу exкosive testting
Speaker A
із зовсім не це. Але все одно, тобто у нас є якась стіль тестування. Для чого ми це робимо? Якісь певні тест-левели, котрі ми робимо.
Speaker A
Тест аа Боже мій. Окей, давай підемо далі. Давай ще якісь пунктів візьмемо. А папапапам слевели, да, взяв. А згу exit і entry критерія. От це ду дуже юсво для того, щоб взагалі розуміти, коли ми взагалі можемо починати і коли
Speaker A
ми можемо коли ми можемо розуміти от definition of town, коли ми можемо закінчувати критерія, то есть призупинення та продовження тестування.
Speaker A
Ти маєш на увазі? Припинення продовження тестування. Resumмtion критерія. Є в нас таке в тестплані. А про те, що ти говориш, enter критерія в нас такого нема.
Speaker A
Entry exit критерія в на Ну, якщо ми кажемо про той тестплан, котрий ми кажемо, критерія, це де використовується в ну в тестплані CLC більше, да, в тестплані такого немає. Є паффе fail критерія.
Speaker A
Ні, стоп. В SDLC давай розберемося, бо в SDLC, ну, зрозуміло, що є, типа, на кожен процес, типу, є entry критерія, типа, і воно буде, типа, але в тестплані так само повинні бути нтри критерія, коли у нас повинні бути певний
Speaker A
енвайронмент, певні певні люди, певний відбувається. Там є пункт такий environment needs. Та да, envirймен. Ну, enвайменти, зрозуміло, на котрих ми будемо тестувати. Люди, котрі були задіяні, котрі у нас є дедлайни, це все так зрозуміло, але от критерія, тобто
Speaker A
definition of ready, коли ми можемо починати тестування, ми ж не можемо починати тестування, коли в нас немає енвар, немає людей, ти один на проекті, в тебе там, не знаю, купа всіх нових речей, типа, ти ж не можеш почати просто
Speaker A
тестування, в тебе буде якийсь definition of ready для того, щоб починати це тестування. І так само definition of.
Speaker A
Саме питаюсь тебе, от для тебе, для твоєї роботи, що би ти юзанув, а от що тобі поможе для декомпозиції, для будь-чого, що пов'язано буде з тестуванням, з плануванням своїх активностей. От я хочу тебе спитати про це. От що би ти з тестплану взяв ба?
Speaker A
М самі об'єкти тестування, ти маєш на увазі, котрим Ну я не маю на увазі. Я от просто от концепцію тобі виклав. Я хочу почути твою відповідь.
Speaker A
М чесно, мені мені складно орієнтуватися, бо якби я тут не не використовував тестплан з того, то те, що, ну, я проходив типа і то того то, що мені більш-менш зрозуміло. Тобто це мені достатньо, мені достатньо цього. Дякую.
Speaker A
А що ти конкретно використовуєш на практиці зQB, з тих знань, які ти отримав? Насправді дуже багато. Типа не скажу, що відкрило якусь еврику. Воно би ска більше структурувало дані ко знання, котрі в мене були і розклали на полочку. Ну, на
Speaker A
наприклад, е, от той ж саме про рудкос аналіз, тобто і створення оцей процес, як воно оця лі л лінієчка оцього добагу.
Speaker A
Це ж не просто баг, типа є якийсь ерор містей, котрий ми робимо, єкос, котрий у нас робиться. Це е-е тому що е inadquate е тренінг недостатньо, наприклад, ко компеція девелопера, він там джуніор чи, наприклад сеньорний, але він там не
Speaker A
проспав. Е-е потім естимація, а е да, естимація, декомпозиція. е, воно проходилось, ну, загалом, це було і так, але воно плюс-мінус мені з вдалось зрозуміти, е, рівні тест левелу того, то що які взагалі, як вони взагалі по поділя ні сорі.
Speaker A
Е, типи тестування тести рівні, то зрозуміло воно, але от про system кост integration, наприклад, от я про такого не знав, про п'ятий пункт типа і було дуже цікаво дізнатися про це так само прореelated типи або, наприклад, ото, щоби от є е те техніки тест-дизайну, є
Speaker A
от Blackbox WBX, не будемо там уточнюватись, але от саме от цікаве було от в experience Experience того то, що в от ми називаємо там манките, adhogг. Це все насправді більш ніж така е-е сво своєрідна е як сказати жаргон.
Speaker A
Тобто насправді, да, ми використовуємо, тобто нормально це error gessing explorти тестування, тобто наприклад самий adhook, котрий я думав і багато хто може мене є питання. Які техніки ти юзаєш от найбільш? в яких ти техніках прям не то що я скажу експерта але що тобі
Speaker A
помагає ой ну напевно то що я почав казати да експлорирується тестування це от дуже сильно допомагає занбордитись на продукт якщо ти приходиш ну чи на проект взагалі подивитися чи по ну мені три причини робити експлореторі три причини та три е перша економія часу
Speaker A
друга набагато ефектив тивніша процес, як би сказати онбордингу на проект, я би так сказати. І третє - це м не прив'язка до якихось е я би сказав би так, не не прив'язка до до якихось певних речей, а ти робиш ее в залежності від того, як ти
Speaker A
хочеш, типа, і як е ти бачиш. Тобто це вільне тестування. Хоча, наприклад, той самий тестчаптер ее може використовуватись для того, щоб експлорити тестування, щоб ми, наприклад, ми не просто перевіряємо вапку, а, наприклад, по цість чаптеру, наприклад, ціль тестування там знайти
Speaker A
яка якомога більше багів там, коли юзер там логіниться, наприклад, чи Ну, це це тестування сесії більше, да, ми Ну, да, те по факту це ще є, можна сказати, таке, як спорити тестування. Ну, це є воно назначається, наприклад, якщо я
Speaker A
хочу перевірити, чи, наприклад, в тому чи іншому функціоналі є бага. Дайте мені, будь ласка, дві години на експлортері. Я хочу визначити це. Та але, але це трошки інакший вектор та exploatting. Ну, в переважності, якщо в тебе нема документації, в тебе все
Speaker A
погано на проекті, да, ти хочеш дослідити, як що працює для того, щоби хоч сформувати привичний смоук, а далі це в регрешн якийсь привичний набір текесів, да, ти це будеш використовувати. Класно. Якщо ти хочеш більш оптимізувати свої тест-кейси та
Speaker A
подивитись, як в тебе функціонал працює з тим, з тим, що можна об'єднати, да, це будеш використовувати це. Ну і так дальше. Тобто і навіть на своєму вільному часі е-е знов проінвестийти те, як працює твоя апка, типа нічого поганого від того не буде. Ну але, да,
Speaker A
ліпше, конечно, балансувати між життям і роботи і на своїх перервах цього не робити. Лег. Так, да, да, як є. Е, добре, дивись, я почув достатньо. І в мене є ще питання від е моєї тіми на роботі, якщо ти не проти, я хочу їх озвучити. Можна?
Speaker A
От по цим питанням би ребята мої орієнтували збирати тебе до себе чи ні. Ее, давай так. Хто краще тестує, дівчата чи хлопці?
Speaker A
однаково, я би сказав би, це про провокативне питання, типу на моєму досвіді, це аб це абсолютно немає ніякого сенсу. Я бачив і геніальних тестувальників дівчат, і геніальних тестувальників хлопців. Типа це взагалі не залежить від, ну, гендеру. Камон, ми
Speaker A
в 21-му віці, типу, тому це абсолютно якісь біси старого покоління. Якщо добре, тоді наступне питання. Якщо хлопець трансгендер, він може тестувати як дівчина?
Speaker A
Якщо ти трансгендер, тестувати як жінчина, ну, в залежності від того, ким він себе позиціонує. Якщо він позиціонує себе як професіонал, він може бути навіть як я, лесбіяном, типа, і спокійно собі тестувати.
Speaker A
Е-е, як протестувати чашку, якщо ти ложка? М мати дві руки, я би сказав би.
Speaker A
Добре. І останнє питання. Хто переможе? 100 лицарів в латних обладунках чи 1000 карликів з гадюками?
Speaker A
Хм. А-а 100 лицарів з обладунками чи 1000 карликів з гадюками? Ой, мені здається, що тися карликів з гадюками. А мені тоже насправді все.
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
резюме вказував таке, що ти там на якісь певні лідував там і так дальше. Як виявилось, це не зовсім так. Та ти просто займав якусь певну там старшу роль та і так дальше. Але це не літ, це більше, ну, типа до когось підійти,
Speaker A
запитатися там, бо в мене були ряди питань, да, які стосовно команди, як ти якісь певні проблеми і так дальше вирішував. Я зрозумів, що мені їх задавати, ну, не треба, бо по суті ти не відповідаєш сі роль. Е-е, з
Speaker A
whitebстін. Ну, привично, ну, відповів на питання, але, ну, мені б хотілось більше, да. От якщо я вказую white boxing, да, я хотів би бачити там більше, чим просто подивитись, як влаштований коміт, але то, що ти дивишся, як коміт влаштований - це
Speaker A
плюс. Я не хочу знецінити цей досвід, та це він хороший, продовжив в тому ж русі.
Speaker A
Я надіюсь, що через рік ми зустрінемося, можливо, з тобою в такій ж самій атмосфері, да, і ти розкажеш більше. Е, більше треба підтягнути технічних певних аспектів стосовно постману. використовую автоматизацію, розбирайся і, ну, як на мене, е, рекомендую тобі взяти підів
Speaker A
вчити хоч одну якусь мову з програмування, розібратися. Це буде прикольним, класним плюсом для того, щоби ї розуміти девів, розуміти свою роботу, автоматизувати процеси, ну, і бути більш ефективним та в тому, що ти робиш. Але з плюсів, давай виводжу з
Speaker A
плюсів, да, давайте вишинку на цей тортик покладемо все ж таки ложку дьоктя. Ініціативність твоя - це дуже прикольний, класний софтскі skill, та який дійсно дуже цінується. Мною дуже цінується. Я розумію, що в перспективі ти можеш знаєш, якщо ти вже прийшов
Speaker A
через STQB, та ну воно тобі ж нахібась надо було, да, то значить більш технічний експреєнс ти можеш наробити собі. А це от з основних плюсів. То що ти можеш вклинитись в дискусією, розібратись там з девами, піти, зробити навіть не свою
Speaker A
роботу, це тоже один із плюсів, із мінусів, да, можна так сказати, бо треба чітко диференціонувати то, що я можу зробити, то, що мені не надо, і це, будь ласка, робіть ви. Ось. А туру гарно розбираюся з тим, там в видах
Speaker A
тестування. Е, так, е, ще що я для себе відмітив. Угугу. Та по процесу поговорив. Так, в принципі, це в принципі мій фідбек. Це все ее Олекса, хочу, можливо, щоби ти додав, якщо ти хочеш. Звичайно, зараз все зіпсую, розумієш? Я сиджу і я
Speaker A
стримуюсь, тому що ти Я от пишу людям в чатик, я кайфую, тому що можу писати людям в чатик. А і такий я що це харт.
Speaker A
Ну типу я зараз в сесію, розумієш, я там зараз фідбеки і я зараз одразу пом'якшу цей харт, тому що звісно, що мені звісно, що мені є що сказати там із позитивного. Це я ж на цьому спеціалізуюся. Мій більше акцент
Speaker A
витягування з людини типу типу гарного, перспективного, це моя, ну типу спеціалізація. Я це роблю на природньому рівні. Ну, типу це типу легко. Інше мені треба типу типу налаштуватися.
Speaker A
Костянтина трошки типу навпаки. В нього на природньому рівні закладено хард і критичне типу ставлення. Тому от отак от тому отак от і є. Тому я поки помовчу, от якщо я придумаю щось. Але звісно, що у мене є. Нехай люди подумають, що б це
Speaker A
могло бути. Ще одне, що мені дуже от якось запам'яталось от після якесь от враження, так, що я не розумі, ну, от дійсно я не розумію, чи от дійсно твої знання, та вони відповідають практичним.
Speaker A
І от я недарма задав питання про HQB. От що ти висунув зQB в своїй практиці, да?
Speaker A
Ти почав щось розказувати стосовно цього, що оце це оце я дізнався, це прикольно. А іменно практично, що ти от застосовуєш? Я недарма спитався за тестплан. Та бо з тест-плану дійсно можна багато для себе от вичленити прямо, да, це там fecha to be тести,
Speaker A
тестми та environment needs, education needs, та те, що потрібно дійсно для того, щоби підготуватися до цього.
Speaker A
Suspension resumption, критерія, в якій ми призупиняємо або поновлюємо тестування та тобто вже домовленості якісь є з розробкою та в якихось певних складних моментах, да, це має сенс. Ну і best fail критерія, да, в якому ми вказуємо типа наші acceptance критерії
Speaker A
по суті, да, коли дійсно тестування наше завершується, да, оце що ти говорив, definition не ореі, а офіition of done більше. Я побачив багато організаційних моментів, та які, в принципі, ну, відносяться більш до, ну, я розумію, що можливо така робота була, в мене тоже
Speaker A
такі роботи були, що треба було, ну, брати на себе ініціативу, організовувати да процеси так таким чином, бо хотілось ліпше поліпшувати, да, але я мало побачив та тут тестува от іменно тестування от іменно Qя та більше якогось організатора. Мені би хотілось
Speaker A
більше побачити Qяю от направленостю туда. Та тому я тобі багато питань задавав: "А конкретно: "А що? А як? А і чому?" Та і отримував розплив чисті відповіді, що мені не дуже подобалось.
Speaker A
Вот тому, будь ласка, зверни увагу на це та при своїх наступних. Так сиджу я і думаю, пройшов би я співбесіду на медластоючи і пройшов. Я би сам не знаю, чи я сам без тебе прийшов.
Speaker A
Так, це це до речі також також так це правда, що навіть сам ти можеш не пройти власну співбесіду, я як би це не звучало. Причому тут тут можна на дві частини розділити. Типу сам не пройшов, тому що ее ну як сказати, тобто ти
Speaker A
можливо можеш провести гарну співбесіду, на яку сам не пройдеш. Це, ну, типу необов'язково, що ти прямо, ну, це необов'язково. Так, я спілкувався з гіршим, чим я навіть в багато разів. От в цьому є певна перевага інтерв'юєра, що може таке бути,
Speaker A
але це буває інший варіант, коли людина ставить формально типу гарні запитання, але не може їх сама оцінити, тому що типу некваліфіковано. Тому тут дуже багато є варіантів. От. А я щось хотів сказати. Я щось хотів сказати. Я ж люблю
Speaker A
щось е таке сказати, чого від мене не очікують. Так от, я думаю, що мені прийшло на спало на думку, а от що так, щоб і похвалити, і не йти в розріз сильно з Костою, е-е знаєте, чого мені часто не вистачає?
Speaker A
е-е бажання людей працювати, їх реально зацікавленість. Зараз такий є тренд. От я його розумію, з повагою, да, ставлюся, але мені не подобається. Ніби навмисно ми маємо не любити роботу. Прямо робота 100% - це погане щось. Це не має тобі
Speaker A
подобатись. От якщо подобається, зроби так, щоб не подобалось. Тому що всі, значить, ці капіталісти, вони всі жатіни. Це все робота. Вони всі, значить, рабовласники. Все оце в цю в копілку я типу я із віком, е, сильно відходжу від лівих типу поглядів в
Speaker A
правий 100%. Я по класиці тут. От. А, але правда, типу я бачу, як як люди начебто принципово бояться гарно ставитись до роботи і бути зацікавленим. Ніби це погано, ніби треба кайфувати тільки від життя, яке обов'язково не робота. Але в
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
так, а-а, перейти потихеньку в автоматизацію, тобто той самий джест, котрий я вивчав на, е, початко на початкових та ее на бе на бейксу, тобто е вивчав, тобто це використовував тих самих в реквестах APIних.
Speaker A
А приклад я навів, тобто того, то що, наприклад, мені це не було в моїх обов'язках те ж саме колекцію а автоматизовувати. Тобто це абсолютно не моє, але для себе чисто як для дослідження я це робив. Не знаю, можливо, просто ти забув
Speaker A
або я просто помітив це, що е ти сказав, що не було цього досвіду, що цього е мало. І стосовно тестплану, е, що хотів сказати про тестплан. В мене тут просто записано. Ее, а стосовно того, то що типу ее це така штука доволі
Speaker A
така тонка, бо типу я не якби з ним не працював, типу я його проходив плані вчив QB, типу плюс-мінус розумію, як він потрібно його робити, але я думаю, що тут ми трошки уйшли, трошки уйшли, але в загалому а класний підхід Тобто класне питання.
Speaker A
Тобто мені от я пам'ятаю, а Алекса казав то от ще і Костя ти казав то, що на деяких от класно, коли кандидат каже, що я не знаю, от мені от особисто мені подобається, коли інтерв'юєр каже: "Все, мені достатньо, типа ми не продовжуємо
Speaker A
тему для того, щоб просто ти не почав там тречет, п'яте, семей, все достатньо, типу". Оце те, що я можу підмітити. Е, да. Ее, ще раз повторюсь, класний досвід сподобалось.
Speaker A
[музика] Тобто клас. Дякую. Ми стараємося для вас, глядачі, для кандидатів, для всіх, просто зробити круті співбесіди. Будь ласка, приходьте, приходьте сюда на місці Марку. Да, ви можете ви Я на останочок е пригадав, в мене є питання і і що ще? І коментар, який я ще можу
Speaker A
сказати, тому що ви торкнулися його. Це буде якраз доречно. Мені здалося, що Маркос, ти просто спочатку не зрозумів стиль Кості. І спочатку це от я згоден з Костою, що конкретики було типу малувато. А-а, але мені здається, що ти
Speaker A
просто не зрозумів, як він спілкується. От у мене просто от було таке враження. А потім в процесі, коли ти зрозумів, то у вас все пішло набагато рівніше. А спочатку так начебто ти кажеш і знаєш, наче ти сприйняв питання по-своєму і
Speaker A
почав розповідати, як тобі здається, треба ві відповідати. Костя в своїй манері починає казати: "Це не так, ти не ти не розумієш, а як?" А Костя їй не дуже розповідає, а просто такий: "Ну, конкретніше, конкретніше". І от ви типу
Speaker A
типу один одного не зрозуміли, а після вже пішло набагато. Тобто тут я з тобою згоден, як ти відмітив сам, як типу рівень температури там або типу узгодженості, або типу харду і тиску, начебто зменшився. От я це відношу до
Speaker A
того, що ти що ти просто зрозумів, як Костя проводить співбесіду, звик за заспокоївся з цим і воно типу пішло дуже гарно. От от в мене отаке враження. А в мене є питання до вас.
Speaker A
Тепер я будую останній шматок 5 хвилин про проводити з вами співбесіду і скажу: "А чому?" Ви мені розкажіть, чому? Я б, можливо, також обрав би карликів, але чому карлики зі зміями переможуть лицарів в обладунках? Ну, тому що в них
Speaker A
є змії, розумієш? От вони карлики і в них є змії. І вони питання в стилі відповідь в стилі питання. Я розумію, але кость а тепер увага. Я хочу конкретніше.
Speaker A
Добре, конкретніше. Якщо ми порівнюємо там 100 лицарів та в обладунках, у нас є у нас є карликів та відповідності це в 10 раз більше, чим лицарів в обладунках.
Speaker A
Якщо середньо сказати, що при розмасі та лицарю в обладунках треба ще нагнути, щоби, ну, короче, херячнути карлика, да, то за цей період часу карлики бувають шустріші, та і можуть підкинути мій в обладунки. Та і 1000 кар вона переважає
Speaker A
чим 100 лицарів. Та тому з більшою верогідності, що тися карликів швидше запулюють змій в облатунки сталицарем і переможуть.
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
реальних таких умовах 100% і гарне. Людям в коментах декілька разів писали, що от сподобався Маркус, як він відповідає твій рівень.
Speaker A
І я хочу тут підкреслити, що це ви сприймаєте як з двох боків. Тобто це і Маркос молодець, але це і питання, на які Маркус відповідав. Тобто, значить, все вдалося, навіть якщо вам не сподобався, типу емоційно можливо інтерв'юєр, але це його частина, щоб
Speaker A
саме на такі питання відповідав кандидат, який вам сподобався. Тому зверніть на це увагу. От тому, якщо лаконічно інтерв'ю, співбесіда гарна, а тидл, ну, типу питань у мене немає. Все, якщо ти хочеш мою оцінку, можливо, я б не казав, але тут спокійно. Я не є і не
Speaker A
претендую на експертність, щоб казати от як я тільки думаю. Ні, тут окей мати декілька думовок. Я, можливо, не був би таким суворим, щоб сказати, що ти початковий midл, наприклад. От я б сказав, що ти нормальний, як мінімум.
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 України і там мій новий курс програмування та веб для те для QA, де ми будемо вчити саме
Speaker A
програмування як таке і базові веб-технології, а як такий вступний перший квиток. Та куди хочете, до General, до Automation, до SD, як хочете. Хвилиночка рекламий. Ось заходьте. Вже скоро будемо починати такий нестандартний, але як на мене має бути саме цей курс в наші часи базовим.
Speaker A
Все. А-а, ще раз всім дякую. Приходьте, слідкуйте за нашими подіями. Подписуйтесь на наш Telegram. Також в описі є посилання, щоб бути в курсі того, що у нас далі відбувається. А і слідкуйте далі. Скоріше за все, давно не було в мене два формати тут. Це розгляд
Speaker A
CV. В нас було декілька співбесід, і я їх ставлю пріоритетними, але хочу ще подивитися на ваші CV трошечки. А також давно не було стріму для своїх, я вже сам скучив. Тому ці два формати скоріше за все будуть найближчими. А там
Speaker A
подивимося, якщо з'явиться дуже класний кандидат, цікавий, то пишіть, будемо посувати вперед. І бетельй ще скоро, хто знає, той знає, а я пізніше розкажу.
Speaker A
Все бувайте. Yeah.
Topics:співбесідаmiddle manual QAтестуванняQA Українатестова документаціяKanbanScrumгемблінгAIWeb3
