воскресенье, 25 марта 2018 г.

Топ 5 проблем у роботі команди від Катерини Несмелової — Full Advanced Level ISTQB certified professional




Катерина протягом тривалого часу працювала в Україні та Новій Зеландії. Вона – QA з понад десятьма роками досвіду в ІТ та сертифікована Full Advanced ISTQB. Одним із напрямів її роботи є покращення процесів тестування в командах. Тож ми запитали в неї, які ключові проблеми трапляються в роботі команди та як їх можна уникнути чи мінімізувати.

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

Непорозуміння, невміння домовлятися з девелоперами, із замовниками, між собою спричинюють серйозні проблеми в командах. На жаль, у нас це відбувається скрізь. Це специфіка не тільки ІТ-сфери, а загальна проблема будь-якої спільноти, будь-якої команди. Це пов’язано з дуже багатьма речами. Одна з найважливіших – це відсутність довіри між членами команди. Тобто найбільші проблеми в спілкуванні трапляються, коли люди одне одному не довіряють і їм потрібно якось себе захищати. Тоді затягується процес, збільшуються об’єми документації та бюрократія. Численні ж дослідження та курси для менеджерів доводять: коли в колективі високий ступінь довіри, працювати набагато краще. Процеси забирають менше часу.

Друга дуже серйозна проблема (і вона не технічна, знову-таки) – люди бояться робити помилки. Їх жахає те, які наслідки для них можуть мати ці помилки. Деякі люди бояться розповідати про свої проблеми команді або керівникові та намагаються все вирішити самотужки. Це призводить до того, що проблеми лишаються прихованими майже до точки дедлайна. А коли вони таки виринають на поверхню, то щось вдіяти вже важко.

Саме тому, коли в команді високий ступінь довіри, люди не бояться помилятися та відповідати за свої помилки. Відтак гарному менеджеру в цій команді лишається тільки мінімізувати наслідки цих помилок. У мене є дуже гарний приклад, як саме це працює в нашій компанії. Коли я тільки перейшла в PricewaterhouseCoopers (PwC), у нас був дуже специфічний керівник відділу: для нього завжди було дві точки зору – його та неправильна. І хоч загалом людина була непогана, але дуже вперта. Ступінь довіри в команді був не надто високий, а от people turn over якраз навпаки – люди йшли з команди часто. Після зміни начальства нас зібрали і сказали: «Ми трансформуємося, наше завдання – трансформувати бізнес. Але ми не можемо трансформувати бізнес, не трансформувавши водночас себе. А щоби трансформувати себе, ми маємо вчитися, ми повинні помилятися. Інакше нічого не вийде».

Третя проблема – невміння давати фідбек. Коли ти даєш фідбек, то найперше, що ти повинен розуміти, – яка мета цього фідбеку. Мета фідбеку – це підтримати «правильну» поведінку чи змінити «неправильну».

На жаль, люди дуже рідко надають фідбек на «правильну» поведінку та на «хороші вчинки». Якщо хтось щось зробив добре, то його треба похвалити, треба сказати «ти дуже добре це зробив, дякую, це мені допомогло», можливо, навіть написати листа вдячності. Однак (незрозуміло чому) у нас так не заведено. Якщо ти робиш щось добре, то це просто сприймається як належне. Але коли ти десь схибиш, тобі скажуть все, що про тебе думають. Тоді в людини виникає думка: «Ага, я, виходить, нічого гарного не роблю, я тільки помиляюся, я поганий». Тому, по-перше, фідбек мусить мати коригувальний вплив. Коли ти даєш коригувальний фідбек, треба розуміти, що людина не є поганою. Можливо, щось було зроблено не так, але людина не погана сама по собі. Це як із дітьми: коли дитина вчинить погано, то треба пояснити, що погана не вона, а лише її вчинок. Усі хороші люди можуть помилитися і зробити щось не дуже правильне. Але разом можна виправити це.

Про фідбеки дуже гарно розповідається на manager-tolls.com. Там є хороші безплатні подкасти про стосунки, про те, як їх налагоджувати. Я дуже раджу всім послухати про фідбеки. Там йдеться про те, як їх правильно структурувати та давати. Дуже гарна штука, яка дійсно працює.

З усього вищезгаданого випливає четверта проблема – невміння людей пояснити свою точку зору. Один із прикладів – це різниця контекстів: якщо ти зараз у певному контексті, то це не означає, що всі автоматично мають розуміти цей контекст. Саме тому, коли ти починаєш щось пояснювати (особливо коли ти захоплюєшся), треба обов’язково перевіряти, чи співрозмовники тебе зрозуміли. Треба не забувати наводити приклади.

Ще один дуже важливий аспект цієї проблеми – це неефективні мітинги, неефективні зустрічі. Знову нетехнічна проблема. Я впевнена, що будь-яку технічну проблему можна розв’язати, коли ти працюєш разом із командою: чи то написання автотестів, чи розробка якоїсь дуже хитрої стратегії тестування… – немає жодної різниці. Коли проблему вирішує команда, це вже не проблема, а лише невеличкий технічний челендж.

Що ж до неефективних мітингів – це дуже важка річ, яка з’їдає надто багато часу. Люди, коли там сидять, не завжди розуміють, що вони там роблять. Але чомусь вважається, якщо вони були на тому мітингу, з усім були згодні та не ставили жодних питань, то вони все зрозуміли і все буде добре. Ні.

На тому ж manager-tolls.com є гарна добірка подкастів про ефективні мітинги. Я у своїй компанії нещодавно робила невеличкий тренінг про ефективність мітингів. Там я проводила експеримент про те, що на мітингах треба слухати й аналізувати. Найперше я розбила групу на 4 підгрупи:

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

Але далі експеримент був ще цікавішим. Це інші дві групи. Третій групі дозволили записувати чи не записувати – за бажанням інтервʼюера. У четвертій групі цій людині дозволено було гортати FB чи телефон під час питань. Запитання були дуже прості. Типу «Що позавчора ви їли на вечерю?», «Де ви провели вихідні?» тощо. У тих, хто не відволікався на телефон, середній відгук був 5-10 секунд. Але в тих, хто відволікався, відгук був майже 30-40 секунд. Лише порівняйте – 5 секунд і 30 секунд!

Це пов’язано з тим, як працює наш мозок. Це називається behavior economics. У нашого мозку дуже мало ресурсу й коли ти його витрачаєш на різні дрібниці (… як пам’ять процесора чи ЦПУ), то в тебе залишається менше ресурсу на обробку важливих задач. Тож коли ти відволікаєшся, аби відповісти на мейл, почитати FB і т. ін, то уваги й ресурсів твого «процесора» не вистачає на важливу задачу. Відтак дуже важливо, щоби на мітингах не було телефонів, а лептопи були тільки для нотаток. І тут важливо зазначити: краще мати на лептопі програмку скетчінгу, щоби писати прямо на екрані як на папері. Якщо ж у лептопі немає такої крутої опції, то звичайний аркуш паперу завжди згодиться. Адже цікаве свідчення: коли ми записуємо інформацію, ми її запам’ятовуємо краще, бо в нас працює інший відділ мозку.

П’ята проблема так само належить до так званих софт скілс. Вона теж пов’язана з контекстом, але трохи в іншому сенсі. Часто люди намагаються робити все так, як раніше, і не беруть до уваги певний локальний контекст: навички конкретної команди, як побудовано спілкування з девелоперами, бізнес-аналітиками, замовником, з ким завгодно… які є доступні технології, і найголовніше – якою є мета.

Порівняймо: сьогодні ви розробляєте веб-сайт для того, щоби випустити якийсь новий вид супер-ламп і їх треба швидко продати. А назавтра ви, наприклад, розробляєте медичне програмне забезпечення, яке буде відповідати за операцію на серці… Мета та підходи будуть різними. Це головне. Коли ти починаєш працювати, треба розуміти, яка в тебе мета, та її постійно перевіряти: чи вона не змінилася, чи ви працюєте так, аби її досягти. Це, знов-таки, стосується не лише програмістів чи тестувальників. Це застосовно взагалі до всього. Треба чітко обговорювати й розуміти цілі: важливо, аби вони були спільними. Бо в команді дуже часто буває таке, що в усіх вони різні. Хтось із девелоперів прийшов вивчити нові підходи до програмування, хтось прийшов відсидіти свої 8 годин та щось за це отримати… А мета має бути одна – зробити класний продукт, який буде допомагати людям.

Коли в тебе є мета, ти і працюєш краще, бо розумієш, чого тобі треба досягти. Ти ліпше розумієш, як тобі співпрацювати з іншими. Ти можеш чітко пояснити, що тобі потрібно від цих інших. Як бачимо, усе переплітається: якщо у вас усіх одна мета, вам простіше працювати в команді, ви довіряєте одне одному, ваші мітинги стають ефективними, ви в одному контексті. Тож виходить, що все починається з визначення спільної мети. А від неї вже залежить, як працювати над рештою складників. Мету я невипадково лишила наостанок, адже треба було до цього дійти. Як говорила моя вчителька англійської: the last but not the least. Тобто остання лише в списку, але не на останньому місці.


Редактор: Пірогова Юлія
Інтерв' ювер: Марина Шевченко


понедельник, 19 февраля 2018 г.

17 - 18 березня 2018 у Львові відбудеться BAQ Conference



17 - 18 березня 2018 у Львові відбудеться BAQ Conference – 6-та двохденна конференція для системних та бізнес аналітиків, для професіоналів в області тестування ПЗ, Product Owners та Product Managers.

Місце проведення: м. Львів, готельТаурус

17 березня - день, присвячений системним та бізнес аналітикам, Product Owners та Product Managers

18 березня - день, присвячений тестувальникам

Вас чекають доповіді на актуальні теми: автоматизація тестування, ручне тестування, тест менеджмент, тестування безпеки та інш.

Серед спікерів: Юрій Гайдучок (Head of Business Analysis @ Ciklum), Ірина Крючкова (Менеджер компетенцій Бізнес Аналітичного Офісу, SoftServe), Антон Серпутько (Performance QA Engineer – Ciklum), Олександра Ковальова (Managing Director у Softengi Training Center ) та інш.

Реєстрація учасників

Більше на сайті – baq.dakiry.com.ua і FB

А для наших читачів додаткова знижка 10% за промокодом " AN_B "

вторник, 13 февраля 2018 г.

Тренинг по тест-дизайну: Black & White Box, Risk based testing от Андрея Ладутько из Минска



Тренер Андрей Ладутько (Минск) - ISTQB Certified Tester, Full Advanced Level (Test Analyst, Technical Test Analyst, Test Manager).

* 6 лет работал тестировщиком, а потом тест-лидом в аутсорсе (Intetics Inc, Дисплей Нетворкс)
* 1,5 года обучал начинающих тестировщиков в IT-Академии “БелХард”
* 2,5 года работал тест-лидом и экспертом в Центре Компетенций тестирования в ЕРАМ
* Сейчас тест-менеджер и тренер в PandaDoc
* Автор и тренер учебных программ для начинающих тестировщиков, тест-лидов, тренингов по тест дизайну, тестовой стратегии и др.
* Член программного комитета конференции SQA Days
* Регулярный докладчик конференции SQA Days и др.


Программа тренинга:
70% практика, 30% теория

Тест-дизайн с умом - Black Box:
2 марта, Старт 10:00 - 15 участников

Введение. Зачем нужен тест-дизайн.
Black Box Technics:
- Equivalence Partitioning & Boundary Value Analysis
- Decision Table Testing
- State Transition Testing
- Orthogonal Arrays and Allpairs algorithm
- Pairwise Testing
- Domain Testing
- Use Case Testing

Тест-дизайн для взрослых - White Box Testing + Risk Based Testing:
3 марта, Старт 10:00 - 15 участников

White Box Technics :
- Statement coverage
- Branch / decision coverage
- Condition coverage
- Multiple condition coverage
- Condition determination coverage
- Path coverage

+ Loop coverage
Исследовательское тестирование
+Risk-based testing


Когда: 2,3 марта
Где: Softengi Training Center - Новоконстантиновская, 15-15, Киев

Подробности и регистрация:
http://softengitraining.com/test-design-training?utm_source=pr&utm_medium=post&utm_campaign=qaclub 

Промокод на скидку 10% - #QAClub

понедельник, 22 января 2018 г.

Конференція TestingStage' 18 у Києві 13-14 квітня




Конференція TestingStage’18, відбудеться у Києві 13-14 квітня цього року у Mercure Kyiv Congress Hotel.

Це буде масштабна подія, на яку запрошені ТОП спікери  з 10 країн з напрямків:
  • Security,
  • Embedded
  • Performance,
  • Automation,
  • Test management and process,
  • Out of the box.
Крім професійних обговорень, на вас чекає нетворкін та afterparty та розіграші подарунків від партнерів.

пятница, 19 января 2018 г.

Звіт з зустрічі QA Club Kiev та KyivTesters Meetup #20. Tooling with Docker & Mobile Testing

Перший мітап тестувальників цього року!
17.01.2018 відбулася 20 зустріч QA Club Kiev та KyivTesters Meetup.

Як і було обіцяно, ми говорили про Docker та Мобільне тестування.


четверг, 18 января 2018 г.

Приглашаем на Selenium Camp 2018!




Мы рады сообщить о начале официальной подготовки конференции Selenium Camp 2018, которая назначена на 2-3 марта и традиционно пройдет в Киеве. Это событие полностью посвящено автоматизации тестирования и будет интересно как начинающим тестировщикам и разработчикам, так и опытным автоматизаторам.

понедельник, 15 января 2018 г.

QA Club Kiev #20 event: Tooling with Docker. Mobile Tips&Tricks

Новогодние праздники уже позади, и самое время нам собраться для очередного QA Club Kiev Meetup #20. 

В этот раз мы поговорим о Докерах и Мобильном тестировании. 

Эта встреча будет особенно полезна как тем, кто только слышал слово “Докер” так и тем, кто пробовал его использовать. А также тем, кто хочет поближе познакомиться с тестированием мобильных апликейшенов.