Звіт з QAFest 2017 про менеджмент

Відгудів QA Fest, відгудів на ньому я, і навіть моя голова після нього вже теж відгула :-) .
Хоч я і не доповідав, але класно потовкся серед розумних людей, а з деякими з них навіть хильнув після першого дня конфи.

Друга частина звіту: Про саме тестування

Організаторам QAFest - величезний респект! Атмосфера була чудова, вдень - QA, ввечері - фест. Відповідно назві!
Для учасників на буклетах були досить забавні тестувальницькі завдання і навіть кросворд! (100 років не розгадував кросвордів) 
За правильні відповіді, а також за фотки зі спікерами давали якісь призи. Тому молоді тестувальниці/ки скажено полювали за доповідачами. Така увага мене остаточно переконала таки піти кудись виступити :-) 

 Їжі було багато.

Щодо доповідей

Найбільше відрізнялася від усіх доповідь, чи радше, "шоу" Сергія Пирогова та Ярослава Пернеровського. Хлопці влаштували гру "Як стати мільйонером" із питаннями про те, як працює Selenium Webdriver. Вперше в житті мені Java була така смішна як JavaScript із цього відосика (розважтеся джаваскриптом, поки відео доповіді ще нема) https://www.destroyallsoftware.com/talks/wat
Підбір прикладів був цікавим і навіть знайомим, але я вгадав лише відсотків 30 :-). Співбесіду на Java-автоматизатора не пройду.
Цитата з їхнього виступу:

"Ти спирався на здоровий глузд, а я спиратимусь на досвід!"

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

• Потік менеджерських думок

Ірина Жилінська, Епам, розповідала про реальність у risk-based тестуванні. Зі слайдів я підтвердив свою думку про те, що працювати в Епамі можна лише із крайнього відчаю і кров’ю сльозами на очах. Тим не менш, цікаві думки:

• Якщо вплив фактору ризику (risk impact) можна взяти і перевірити, то це Product Risk, якщо не можна перевірити - це Project Risk.Тобто ми можемо перевірити, чи гарна вийшла нова фіча, але не можемо перевірити, чи Славко вийде завтра на роботу.
• Треба планувати перед ключовими етапами проекту, я б назвав, "засадничу раду", тобто коло людей не більше 10, які збиратимуться для раптових брейн-стормів, якщо виникатиме потреба. Ідея цікава, але як тестувальник, я бачу тут небезпеку потрапляння у цю раду "номінальних керівників" замість людей, що знають реальну ситуацію, і могли б бути корисними.
• Кожен ризик на стадії планування позначається до всього іншого ще й оцінкою "глибини тестування" від 1 до 5. Де 1 - "Extensive Test Run", 5 - "Report Obvious Bugs". Цікавий розріз оцінки. Так можна багато що міряти, не тільки ризики.

Віктор Тимощук, Cocur, Чехія, у своїй доповіді "Rocket science - challenges of mobile quality", насправді теж багато говорив про ризики. Головною ідеєю, як я її почув, було доповнення піраміди тестування ще одним виміром - часом, відведеним на тестування; або обернено-пропорційною величиною - пріоритетом виконання кожного з тестів, за яким вони запускаються на різних рівнях. Дуже крута ідея для уявлення про пріоритети та ризики, але я не побачив достойної візуалізації. Було б круто!

Герлоф Хукстра(Gerlof Hoekstra), Atos, Нідерланди, мав замість презентації величезну майнд-мапу і вправно та швидко тягав її, замість сумного перемикання слайдів. У нього майже все вийшло. Доповідь була "Планування - чекай неочікуваного" на прикладі детального плану його батька автомобільної подорожі з Голландії до Італії, що перетворився просто на папірець одразу після того, як вони пропустили перший з’їзд з автобану. 

• Майте приблизний план, що ґрунтуватиметься на "Щасливому ході", Sunny Scenario
• Навчіться, і навчіть Вашу команду, працювати з деталями у випадку ("коли") все піде не так. Домовтеся про SLA на випадок виправлення дефектів.
• Декомпозиція функціоналу, чи slice&dice, можлива ЗАВЖДИ! Прибирайте зайві залежності.
• Не документ - результат роботи команди під час зборів, а спільне розуміння!
• Односторінковий Тест План - це дуже добра річ. Ось кілька прикладів з поясненнями. 

Володимир Примаков, Ciklum, розповідав про величезну кількість різних метрик, що ними можна міряти не тільки тестерів, а й усі продукти їх діяльності. Чекайте на його слайди, там дійсно є що запозичити.


Хотів усе написати в одному пості, але поки й так фате. Завтра напишу про більш технічні речі, автоматизацію, чи про що там ще у мене нотатки :-)