Практичний кейс про те, як ми відмовились від QA, для того щоб покращувати метрику «швидкості реакції команди» на критичний баг на проді. При цьому кількість owner’ів якості начебто збільшилась в рази. Висновки і практики, до яких ви прийшли в результаті реалізації підходу, вам зміг би сказати будь-який більш-менш досвідчений QA lead, а може навіть і senior QA з відповідним досвідом, також вони описані у багатьох підручниках з тестування.
Як на мене був сильний missfit по першому QA, якого ви найняли, і цю проблему ви спробували вирішити створенням власного велосипеду, який начебто поки що їде.
Навіть у висновках не обгрунтували чи вдалося вам

забезпечити якість продукту в стартапі без виділеного QA

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

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

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

б. Ще в назві ви надали думку, що рутинність = зниження ефективності в роботі, яка не є аксіомою сама по собі, оскільки можуть буть варіанти/передумови:

• передбачається, що людина вже була ефективним тестувальником, що не очевидно.
  
• передбачається, що рутинність знижує ефективність через «втому» і як наслідок зниження концентрації на роботі, але як на мене цей факт може компенсуватись набуттям досвіду, коли людина просто відчуває де шукати дефекти і робить це без всього того складного тест дизайну. 10 тестів, 7 з яких знайдуть дефекти.
  
• а як щодо тих людей які дуже полюбляють рутину і хотіли би поменше думати і побільше проганяти тести і репортити баги. Чи їм теж треба зменшувати рутину? Особливо під час війни, коли безкінечне регресійне тестування є чт не єдиним острівцем стабільності в їх житті?
  

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

Тепер йдемо по тексту:

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

2.

Створення зрозумілих тест-кейсів

... хм, а що заважає рутинно створювати зрозумілі тест-кейси, теоретично це навіть збільшує монотонність роботи, тому що ви починаєте в моменті більше писати нудних, очевидних тестів. І це як раз приклад, коли рутинність може конфліктувати з ефективністю підтримки тестів для складного проекту.
У прикладі ви вказали, що precondition треба розписати прямо в тест-кейсі (принаймні я так зрозумів з тексту). Дуже спірно, я б навіть сказав шкідливо, оскільки ви тільки обтяжуєте тест-кейси цим, а от посилання на інший тест-кейс, який переводить систему в це стан (і вони наприклад обєднані в єдиний test suite), або ці preconditions розписані в якомусь документі, наприклад у тому ж тест плані, це вже більше до справи.

3.

Систематизація тест-кейсів

— знову ж таки процес систематизації досить рутинний, але підвищує ефективність команди (хоча якщо команда — це тільки ви, а проект короткостроковий, то це знижує ефективність команди ? ;)

Вибачте, не знаю деталей, але чому тест-кейси з ID C1, C3, C5 у вас мають однакову назву — Instagram: Create account? То це однаковий тест чи є між ними різниця? Якщо є, то її треба відобразити у назві, якщо ні — то це повинен бути тест C1, що повторно використовується для тестування в різних test suites

4.

Використовуйте інструменти для управління тестовими сценаріями

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

5.

Воскресіть у собі креативну частину

Зробили припущення, що вона вмерла. Якщо була живою та вмерла, то тут треба розібратись чому і чи була взагалі необхідна? Може там якісь інші є проблеми ніж рутина? А чи потрібна на цьому місці була б креативність. Комусь знаєте і просто баги репортити треба, чи тести проганяти.
Чим пункт «розуміння користувача» відрізнається від «емпатія до користувача»?

6.

Обмін досвідом та знаннями з командою

Тут трохи не зрозумілий приклад, оскільки якщо 3 тестувальники працюють в одному проекті, то вони начебто всі повинні знати про ці фічі, або принаймні приймати участь в їх обговоренні, бо з вашого прикладу навіть виникають кейси коли з розсилки ми можемо перейти по посиланню і авторизуватись (тільки не кажіть що рестрацію та логін теж відповідають різні тестувальники :) ) або незавершена покупка в корзині может потрапити до теми розсилки. І якщо ж кейс такої прям «ізоляції» людей в команді, то це питання до менеджерів.
Якщо обмін знаннями іде просто «щоб не було нудно» і ці люди навряд чи будуть робити тести одне одного, то тут ще питання для чого це?
З точки зору тім ліда, то тут треба уникати ситуацій наявності «унікальних знань» які втрачаються разом з людиною. В розвязанні проблеми тут допоможе такий інструмент як star map або skill map. Але також як рішення проблеми — створення документації і діставання знань з будь-якої голови. Тобто взагалі не згоден з цим пунктом якщо говоримо про ефективність і дуже умовно згоден, якщо це про рутину, хоча навіть в цьому контексті, саме рутина виглядає не такою великою з інших можливих наявних.

7.

Відстежування та аналіз результатів

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

Застосування відстежування та аналізу результатів може значно покращити ефективність і виявити рутинні завдання.

Я б це написав як:
— Застосування відстежування та аналізу результатів може виявити рутинні завдання і внаслідок їх оптимізації значно покращити ефективність.

І тут як висновок моє бачення ситуації. Поділений на дві частини:

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

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

Всім гарного дня і цікавого тестування!

Гарна стаття. Єдине, що «безпосередньо проведення тестування» я би розділив на аналіз, дизайн, імплементацію. Ви описали безпосередньо дизайн. Можна було б ще долучити ChatGPT до аналізу і тестування безпосередньо вимог.

Смартфони дарували людям надприродні здібності. Наприклад, ви стали в курсі подій, які відбуваються навкруги майже у реальному часі. А як їм треба було поводитись в перші дні? Прикладати вуха до землі, щоб почути танки? Взявши смартфони люди сіли в свої машини, і поїхали у місця, в яких вони ніколи до того не були, за сотні і тисячі кілометрів і точно знали, куди їдуть. Їм не треба було орієнтуватись по зорях і сонцю.
Тільки за, щоб мої діти використовували смартфон (і всі нові гаджети) ще більше і ефективніше ніж я.
ChatGPT — це просто новий інструмент в нашому арсеналі, який дозволяє нам приймати рішення швидше або з урахуванням такого об’єму інформації, який ми фізично не змогли б обробити (у відведений час). Здебільшого компанії забороняють використовувати LLM, оскільки побоюються за NDA, і не хочуть тренувати чужі моделі за рахунок власних даних. І ті ж самі компанії вкладають кошти в розробку власних LLM.

Це вже прям цілий світогляд виходить :)

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

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

Досить цікава статейка у вас вийшла.

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

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

2. Дуже спеціальна людина

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

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

Ніт. Це ще вилами по воді писано, що якщо щось на проді пішло не так у якійсь фічі, то винен саме розробник цієї фічі (або взагалі якийсь розробник). Це каже лише про відсутність поваги до своїх інженерів і їх приватного життя. Не залежить нічиє життя від того, що на edtech платформі щось там не працює о 2 годині ночі. Принаймні я це якось так бачу. Можливо приклад був невдалий. І за декілька років роботи таких кейсів можна було б перерахувати по пальцях, але все одно не є гуд.

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

Викладаєш у КПІ, круто! Прям ведеш лекції, приймаєш екзамени, от це от усе?

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

А owner — це ж кожен інженер, так? Я сподіваюсь, що у вас в компанії щонайменше 70 feature owners?

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

А ще їх не треба підіймати о 2 годині ночі, щоб щось фіксити на проді

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

А чому фаундеричи продакт-менеджери не можуть побачити фічі, які необхідні. Вони що, не працюють в команді?

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

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

Хрещення онбордингом — переводячи на людську — онбордингу у нас нема і ми цим пишаємось. З першого дня комітиш в прод. Знайшли чим пишатись...

Про self-nominated performance. Так таки ревю робите по фічах чи по проектах? Трохи ж між цими словами різниця, чи не так? Чи все ж таки стандартні 6-12 місяців рев’ю як в усіх компаніях? І здається у вас менеджери ініціюють рев’ю, а не інженери? І про акції компанії забули написати.

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

Не думаю, що це шлях, описаний в ідіократії. Це просто наступний інструмент, який полегшує роботу / звільняє час / забирає на себе рутину. Так само як писемність, книжковий прес, конвейєр, калькулятор, інтернет, вікіпедія. Він звільняє нас від певних навичок, зберігає час, спрощує доступ до інформації. Суспільство відреагує належним чином, вийде на новий рівень асбтракції, створить запит на нові навички, вміння і знання. Як сьогодні нікому з роботодавців не цікаво наскільки у вас красивий почерк, так завтра нікому не буде цікаво, що ви вмієте складати красиві, логічні, стройні тексти без допомоги якихось тулів та ML-моделей.
Я впневнений, що успіх буде в критичному оцінюванні відповідей від ChatGPT, а не сліпому слідуванню їм.
І як раз таки процес навчання можна поліпшити саме з ChatGPT, тому що це лектор/ментор, на яокго не впливає його настрій, який готовий відповісти на ваше запитання будь-коли. Щодо побоювань, що він заведе нас кудись не туди, то наведу приклад Вікіпедії. Там теж на початку була критика, що статті будуть з помилками, неповні, неточні, протирічити одна одній і т.д., і що енциклопедії повинні створюватись суто професіоналами чи академіками. Але на виході маємо те що маємо. Зараз знайомство з будь-яким фактом у вас почнеться скоріш за все з вікіпедії, а потім вже — по профільних ресурсах.
Так буде і з ChatGPT. Спитали, отримали відповідь, якщо подобається — в роботу, ні — уточнюєте запити, пропробляєте власноруч.

Дизайнити тест-кейси ChatGPT поки що не вміє, від слова «зовсім». На виході якісь «взагалі по загалям», навіть якщо уточнювати. Про добрий coverage годі і мріяти. Зате ідеально працює, щоб позбавитись «остраху чистого листа». Швиденько накидати якийсь чек-ліст, в який вже будеш закидувати необхідні кейси — от це саме воно.
А от все що стосується навчання — пояснення, то це прям стає в нагоді.
Також він дуже класно пруфрідить тексти під будь-яку тематику. Просто видаєш йому потік свідомості, а потім «оформи це у вигляді гайдлайну», «напиши ввічливий імейл для замовника», «зроби з цього перформанс рев’ю на колегу», «виділи окремі буллет-поїнти». Такий собі калькулятор, але для написання різних видів документів (якщо ви розумієте про що я). Але калькулятор сам за вас роботу не зробить.

+