Дякую за цікавий подкаст. Поділюся думкою щодо "Чи варто тестувальнику знати алгоритми?" Коротка відповідь. Якщо хочете в ФААНГ та великі компанії - варто. Якщо хочете змагатися на змаганнях та мати це як хоббі - варто. Якщо ви хочете працювати в типовому аутсорсі - зазвичай не варто. Якщо є інші прогалини в знаннях - не варто (краще вчити інше). Розгорнута відповідь. Питання алгоритмів можна розглядати на різних рівнях: на мікро рівні (саме по собі) та на макро рівні (як один шматочок знань в арсеналі зрілого спеціаліста). (Я говорю тут не про тупе завчення напам'ять, а про обізнаність в алгоритмах та вміння вирішувати задачі на сайтах типу HackerRank або LeetCode). Вивчення алгоритмів та розв'язання задач на вище зазначених платформах допоможуть Вам краще розв'язувати будь-які складні технічні завдання, допоможуть проходити співбесіді в Україні. Для компаній рівня ФААНГ - це must have. Але я стикався із базовими алгоритмічні завданнями навіть на позиції QA інженерів у компанії в Європі. Але вивчення алгоритмів (особливо коли Ви не вчили їх в університеті) - займає час. Щоб здобути необхідні навички для проходження співбесід у топові компанії потрібно витратити десь від 3-6 місяців до року. Тому вирішуйте самі, чи потрібно Вам витрачати стільки часу. До того ж, вміння розв'язувати типові задачі без належної практики має здатність погіршуватися. Тому є сенс вчити це тільки перед реаундами інтерв'ю. Єдиний виняток - якщо вам подобається розв'язувати задачі - як хоббі. Тоді можна навіть змагатися на різних платформах з іншими людьми, здобувати призові місця. Рекрутери вас там знайдуть). На мікро рівні. Для звичайної роботи на рівні джуніор-мідл (навіть автоматизатор) на 95% аутсорс проєктів в Україні це знання ви використовувати скоріш за все не будете. Краще вкладати Ваш час у вивчення конкретних інструментів та інших речей навколо вебу чи мобайлу. Для тих 5%, що залишилися - вони або наймають випускників технічних ВУЗів із знаннями алгоритмів або (в разі необхідності) допоможуть швидко опанувати ці специфічні знання. На макро рівні. Знання алгоритмів та структур даних - це лише один з багатьох елементів знань. Сам по собі він багато користі не принесе. Разом із цими знаннями, для тестувальника краще буде здобути навички у System Design - с позиції того, з яких елементів будуються сучасні великі системи та як вони можуть ламатися. Це в свою чергу приведе Вас до заповнення деяких прогалин у технічних знаннях - хешування, ті самі розподілені системи, мережі та ін. Усі ці знання допоможуть краще розуміти причини великих багів у Вас та у інших продуктах. Допоможе розуміти більше з пост-мортемів. А саме - розуміти де і що ПОТЕНЦІАЛЬНО може зламатися на тому чи іншому етапі масштабування чи додавання функціональності у систему.

Дякую за подкаст

Дякую) такий цікавий випуск і дуже круто, що наводите конкретні приклади ) згадала, що треба передивитися теорію ISTQB))

Дуже цікавий підкаст! Дякую!

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

дякую, дуже цікаво. шкода що без відео

59:00 та до того "навіщо SM". Наприклад SM зможе показати й навчити використовувати Cynefin framework:) Скрам не "срібна куля", тому у SM, принаймні у мене й мого кола спілкування, зазвичай є "портфель" PM(наприклад PMI)+SM+Kanban trainer+багаж досвіду, за який вже заплатили і відрефлексували в минулих кейсах.

44:30 ооо, за декомпозицію задач лайк! Став лайк під відео, якщо тебе бісить робити естімейти задач))

Ми використовуємо естімейшн покер, але тільки всередині куа відділу. Це іноді допомагає нашому ліду переконати СТО, що пару задач зі спринту таки треба викинути, бо не встигнемо :)

дякую за подкаст) 46:20 Я на теперішньому і декількох минулих проектах використовував Пленнінг Покер. Зі свого досвіду скажу - має сенс лише коли всі процеси круто налаштовані і команда добре знає проект та код. В інших випадках просто waste of time :(

У нас всі функціональні команди роблять єстімейти в сторі поінтах. Відаллено юзаємо скрам покер. Робимо це під час грумінга нової сторі і оцінка включає в себе всю роботу(BE+FE+QA) набагато простіше ніж вираховувати часи на кожну окрему задачу

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

Всім привіт ))) в першу чергу дуже Вам дякую за годний випуск Я працюю на оншорів з США (Фін Тех) і в нашій команді є скрам мастер. Завжди на спрінт пленінгу ми юзаємо спец простеньку тулзу для Покер Естіменту (це все обслуговує наш Скрам Мастер ми лише клікаємо циферки ахах) і в нас це дуже швидко і якісно , команда моїх девів дуже злагоджена тому ек має вакханалії і тим паче що ми юзаємо числа фібаначі а не години ))))

Дякую за обговорення питання "Чи потрібно тестувальникам знати алгоритми". Чіткої відповіді якось не почув, але я б сказав, що алгоритми і цикломатична складність - це nice to have, але точно не mandatory. Ех, десь в ідеальному світі тестувальники знають базовий Сomputer Science і не свічнулись в девелопмент :)

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

Чудовий подкаст, не зупиняйтесь 🙂

О, я за те, щоб розглянути pairwise і чому ви його не використовуєте!

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

Сумно було почути про ретро. Як нам відомо, Quality Assurance - це про процеси [розробки], і відповідальність на кожному в команді. Ретро - логічне місце, щоб ці процеси обговорювати. Якщо команда не бачить сенсу в ретро, всім все ок, то ймовірно люди закрилися в бульбашці власної таски і власне з QA працювати бажання нема. Або ж очікують на готові рішення, делеговані кимось з-за меж дев команди. Відповідні висновки про зрілість такої команди

планінг покер постійно використотвую на протязі 7ми років))) вже навіть не знаю як по іншому, ше естімацію T-shirt використотвуемо на раніх єтапах планування але потім все в сторі поінтах

Відповідь на питання чи тре вчити та знати алгоритми: Вам це не потрбіно поки в вас не буде досвіду років з шість в автоматизації тестування та ви не працюєте з тетсуванням нейронок Або якщо ви не хочете за 6+ років досвіду так само писати лише ікспаси та пейджобжекти архітектурити - то вам потрібні вже знання в алгоритмах, менеджементі, розробці, архітектурі, наймі, фінансах. Чим більше в вас досвіду, тим скучніше вам буде займатись одним й тим самим, тому інсує світчінг досвідчених в середині ІТ ібо є жага до нових знань та складніших задач. І тому алгоритмів буде вже мало для подальшого розвітку вас як спеціаліста Ну але звісно, шо не всім хочеться розвиватись, комусь і ОК 3к заробляти все життя, а хтось за 6 років вже заробляє +8к

Давайте гуртом придумаємо ім'я цьому жуку, який буде вас розважати під час прослуховування подкасту :)

А чого нікого зі скводу не запросили?

як робити естімейт, якщо не знаєш як робити таску 😄

Свідок перезаливу тут, видно дійсно була помилка

Вчився, вчився я на тестера так і не спромігся десь піти бо слабка англійська.

1 ейкйнкй не!!!!!!!!!!!!

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