Хоча я побув "спікером" цілих 99 секунд наприкінці, коли давали висловитись усім бажаючим, типу як "вільний мікрофон". Раджу усім, хто влаштовує конференції, щось таке робити (якщо це не запатентована практика). Треба піднімати рівень самосвідомості!
Багато всякого надавали
Організація
Усі матеріали обіцяли викласти тут: https://dojo.ministryoftesting.com/events/testbash-netherlands-2018Конференція була невелика як Голландія, до 200 людей. Проходила в приміщенні діючої церкви. Був один потік, все англійською, хоча половина доповідачів були голландці. Cеред відвідувачів голландців теж була, мабуть, половина.
Розклад доповідей був мені незвичниий: 2 доповіді підряд по 30хв кожна, без перерви, потім 30хв перерва, і знову 2 доповіді.
Обід був 90хв. Бо люди прийшли поспілкуватись!
Насамкінець, після 99-секундних промов усіх бажаючих було пиво у сусідньому барі, а я не пішов, бо мав родинні справи. Але може і на краще. Не все одразу.
Спікерів відрізняло вміння тиматися на сцені та робити всяки рухи. Було цікаво дивитись, часом нагадувало спектакль. Думаю, нашим треба походити на гурток театрального мистецтва.
Відео записували, але сказали не чекати наступного тижня, і навіть через один. Куди їм там до Selenium Camp 2018!
Доповіді
Maaret Pyhäjärvi: Holding Space: Making Things Better By Doing Less
Почала Маарет з того, що консультанти - поганці, а от наймані працівники - можуть все. Було доволі надихаюче. Розповіла, як вона своєю присутністю спонукала девелопера саму тестити свій код. (Навряд чи такий фокус прокотив би із джуніором, чи з тим, з ким Маарет перед тим не працювала).
Також, була доволі спірна теза, що "результатом роботи тестера є не код і не баґ-репорти, але співпраця". Звісно, я і сам часто буваю у ситуаціях, коли найкорисніше, що я міг би зробити - це принести каву, чи "своєю присутністю спонукати до розмови інших". Але я б не назвав це своїми найвище оплачуваними навичками. Тимпаче, це працює тільки як результат тісної попередньої співпраці.
(Піти, може в офісі посидіти хоч пару днів?.. Ні, не піду :-) )
Сподобалось таке:
- Будь тим, чого не вистачає. - Це дійсно корисно для команд, але некорисно для мене після 30 :-)
Sue Atkins: Why test Techniques Aren't Dead!
Сью із Шотландії розповідала про техніки попарного тестування.
Радила оцей список тулів для створення pairwise-тестів: http://pairwise.org/tools.asp
Від неї дізнався, що є вже згенеровані масиви покриття, і варто лише вибрати потрібний, знаючи кількість опцій для кожного значення, і що це називається "ортогональні масиви", і що треба читати Джеймса Баха http://www.satisfice.com/testmethod.shtml
Схоже, словом сезону стає слово "ортогональний"!
Nico Jansen and Simon de Lang: "Kill the mutants!"
Хлопці розповіли про мутаційне тестування і відкритий проект на TypeScript для нього. Я це вже чув на QA Fest від інших чуваків. А їхній фреймворк не підтримує не те що Python, а й навіть Kotlin :-)
Може комусь буде цікаво: https://stryker-mutator.io/
Mariane Duijst: Encouraging Engagement - Changing Our Work Culture
Спіч про те що ми все можемо, треба тільки взяти на себе відповідальність, і все змінити! "Маленькі люди, що роблять великі зміни". Я б назвав це "галерна ода".
Оце сподобалось:
- Не питай дозволу! За потреби попросиш пробачення. - І хоч це сказано голландцям, це актуально для українців ще у більшій мірі! Я весь час так кажу.
David Evans: Mind Your Language - Unintentional Bias, Social Identity And Teamwork
Оповів про те, що скіли класного тестувальника не унікальні тільки для тестувальників. Девід розбив навички на 4 групи:
- Редактор (!)
- Рекрутер програмістів (!!)
- Бізнес аналітик
- Лідер
Доречі, такі вправи можуть допомогти багатьом "застряглим" знайти себе. Бо "бути тестером" (і все) і "спеціалізуватись у тестуванні" (та в чомусь ще) мають зовсім різний напрямок думок.
Ще була частина про ідентичність, яка може бути різною, і людина сама в праві її обирати чи змінювати.
А загалом, Девід радив робити свою мову м’якшою і уникати оборотів, що можуть когось образити. Бо хай краще вислів буде двозначним, ніж образливим. Він правий на 100%, повірте моїй сивині :-)
Geoffrey van der Tas: Lessons From Famous Detectives for Testers
У Джефрі на початку було відео з серіалу про Шерлока Холмса, а потім він пояснював дедукційний метод. Найголовніше у цьому методі - це база знань, яку треба навмисно будувати не просто "по пам’яті", бо людська пам’ять добре зберігає лише картинки у часовій посліовності. Ця база знань побудована як база даних усіх деталей. Щоб це все тримати в голові існує метод палацу пам'яті, де ми пригадуємо шлях по знайомому місцю і прикріплюємо те, що треба запам’ятати, до тамтешніх деталей.
Пам’ять - це важливо для тестера, але вже не так, як у Даньому Римі.
Martijn Maas: Complex Problem Solving
Ця доповідь була для мене найбільш цікавою. Мартайн працює у консалтінговій фірмі, і весь час вирішує складні пролеми в ІТ, і не тільки.
Спершу він говорив про способи постановки задачі, про правило 5Y - 5-и "чому?"
Але крім того ще треба "йти до наслідків" і щоразу ставити питання "Що ще?"
А потім до кожної відповіді знову застосовувати 5Y.
Картинку що вийде, Мартайн назвав Event Map - Мапа Подій. Ммаються на увазі зв’язки подій між собою, що прииводять до проблеми. Так ми виявляємо додаткові обставини - contributing circumstances.
Проаналізувавши все, 80% проблем перестають бути складними - сідай і роби!
Але дещо лишається. І тут постає питання: Що ж таке "складні пролеми"?
І тут Мартайн та його фірма попросили Роттердамський Університет провести дослідження (круто, що їм так можна!) серед голландських компаній про те, що вони вважають "складною проблемою".
І от вони з’ясували, що самі проблеми складніше не стають. Стає складніше їх вирішувати, з різних причин. Тобто більшість проблем не складні, а неясні.
Щоб прояснити проблему, використовують правило "IS & IS NOT":
- Означте, що Є проблемою.
- Означте, що НЕ Є проблемою.
- Опишіть можливі причини.
- Перевірте їх.
З його досвіду, складно там - де є багато динамічно змінних величин, і нема змоги їх відтворити чи вплинути на них. Як погода, наприклад.
Tuhin Mitra: How do I Automate Negative Tests
Тут було не дуже цікаво. Просто пам’ятайте, що треба обговорювати і поведінку системи у разі помилок чи некоректних даних.
А також, не забувайте про негативні тести в BDD та TDD.
Angie Jones: CI and Test Management
Енжі - активна автотестерка з Twitter, має купу патентів та скрізь виступає. Особисто мені під її доповідь хотілося підспівувавти :-)Головні проблеми автоматизації (на WebDriver’і) Енжі окреслила як:
- Час виконання тестів - тривалість запуску має бути якнайменше.
- Аналіз падінь тестів - коли тест падає, важко сказати одразу, чи це проблема в апплікейшені, чи у самому тесті.
Цікавою була думка про те, що:
Failed_Test != Blocker
Більшість ортодоксальних автоматизаторів вважають навпаки. Але ті проекти, де я працював, допускали релізи навіть якщо автотест впав, і нема часу його фіксити. Тест коментять, білд зеленіє, створюють тікет на це, і спокійно релізять.
Так що я погоджуюсь із Енжі. Не треба лукавити і вдавати ніби ваша автоматизація - аж такий весь "кволіті ґейт". За необхідності його легко обійти адміністративними методами ("ПО сказав релізити так."). І ніякої трагедії в цьому нема :-)
99 Second Talks
Виступало багато людей, може 20. Хтось дякував організаторам, хтось мав якусь думку.
Мені запам’ятався професор з Університету Недерландів, що порадив: Постійно стежте за вашими користувачами!
Також хтось розшифрував QA як "Question Asker".
Мої 99 секунд були про те, що тестерам все одно треба вчитись програмувати, бо світ такий. І один цікавий хлопчина після мого виступу навіть пішов теж записався у чергу 99 секунд, і сказав там, що "Ні, тестерам не треба програмувати. Тестер може робити стільки всього, що програмування - це лише один невеличкий шматочок. І взагалі байдуже, хто пише ті тули."
Я б сказав "Ооокеей. Все залежить від контексту." Але вміння писати код ще ніколи нікому не нашкодило :-)
Але чомусь багато хто програмувати просто боїться. І навіть багато хто не наважується спробувати. Я саме їх хотів підштовкнути своєю промовою.
Особистий висновок
В Україні з конференціями все щонайменше добре :-)
Публіка у залі була така сама: колись ставили питання, колись - ні. Хіба що може на обіді й у перервах вели себе активніше. Ніхто не соромився підійти та заговорити з незнайомцем (Чи це може я не соромився...), бо для того туди й приходять.
Дякую, що дочитали :-)
Pухаймо далі наше ІТ та проактивність!
Немає коментарів:
Дописати коментар