LONG TEXT BELOW
Фан почався уже після реєстрації - у пакетику з програмками був приємний сюрприз у вигляді візитниці з фірмовим логотипом конференції, сайт конференції лежав, а у залі А починав свою доповідь гість з Ізраїлю - Ярон Цубери. Він розповів про стратегію тестування у своїй компанії та defects driven approach. Хоча нічого нового у їхньому підході я не помітила, та жартував спікер дотепно, тому увагу тримав справно. Одне питання, яке він підняв, досі мене хвилює: як уникнути такого явища, як over-testing? Мені здається, що одним поділом функціональностей по пріоритетах цього не досягти. Завжди має місце помилка, ми схильні одне переоцінити, а іншому приділити менше уваги. Загалом, є над чим подумати.
Влаштувавшись у зручному кріслі-пуфіку я оцінила переваги сучасних технологій, прослухавши пару доповідей на стендовій секції. На минулій конференції SQA days, що пройшла в Москві, була одна проблема, яку цього разу організатори успішно усунули, - доповідачів було майже не чути. Сьогодні ж, отримавши мікрофон, що кріпився за вухом, спікери могли говорити і бути почутими. А слухати таки було що. Максим Кузьмич поділився своїм баченням можливостей використання баг-трекерів. За його словами, ці веб-сервіси прекрасно виконують роль системи тікетів для команди підтримки, воркфлоу можна налаштувати якзавгодно і відстежувати стани замовлень, запитів, чи просто ту-ду тасків.
Потужною була доповідь Алли Копилової, яка розповідала про Feature Injection як метод роботи з вимогами. Вона наголосила, що першим етапом цього процесу завжди повинне бути визначення цілі. І головне, щоб це бачення було одинаковим як у замовника, так і в команди розробки. А далі робота моделюється шляхом визначення відповідей на дуже прості запитання: "who? what? why? how?". Чітко усвідомлюючи цілі та потреби як замовника, так і кінцевих користувачів, можна легко знайти рішення поставлених задач, при тому визначати як саме технічно реалізувати це рішення (як?) - потрібно в останню чергу, і це питання на етапі аналізу повинно бути "чорним ящиком".
Далі було декілька доповідей, які торкалися теми дослідницького тестування (exploratory testing), які моментами викликали відверте нерозуміння. Як от: у своїй стендовій доповіді "Регресивне тестування методом вільного пошуку" Сергій Вербенко обмовився, що в регресивний набір тестів вони включають тестування нового функціоналу, що, мяко кажучи, викликало нерозуміння та неприйняття з боку аудиторії.
Мені взагалі здалося, що люди, котрі торкаються таких тем, повинні бути дуже обережними з визначеннями та крихтами теоретичної інформації, яку вони дають, адже у слухачів, малознайомих з темою, може скластися неправильне враження. Так пояснюючи, що таке exploratory testing, Сергій навів цитату Джеймса Баха, де сказано, що це тестування без попередньо написаної документації та плану. Хоча насправді якраз навпаки - навіть для тестування методом вільного пошуку потірбно попередньо готувати план, і під час тест-сесії записувати ідеї наступних кейсів. Нещодавно Майкл Болтон написав цілий цикл розвінчувальних статей на тему "Чим дослідницьке тестування не є". Дуже раджу почитати та звільнитися від міфів про exploratory testing.
Потім Тетяна Зінченко воювала за увагу слухачів, які не пішли на обід у першу зміну. Вона коротко та доволі поверхнево дала визначення Скраму та Канбану і розповіла про гібрид цих двох agile-методологій, який функціонує у їхній "Команді без правил, команді-мрії".
Після обіду я вирішила приділити увагу стендовій секції, і таким чином пропустила суперовий (судячи з відгуків щасливих слухачів) майстер клас Нікіти Постолакія про методику розробки тест-кейсів Pairwise. Проте стала свідком наочної демонстрації порад Марини Гончарової щодо мистецтва бути почутим: її команда змоделювала "управлінські поєдинки", де можна було приміряти на себе роль будь-якого учасника процесу розробки програмного забезпечення і відчути на власній шкірі як воно:)
І на закуску, вже добряче втомлена від такого насиченого потоку інформації, та приємно втомлена від кулуарних теревень, я вирішила послухати доповідь Марини Дідковської про тестування специфікацій. І ні разу про це не пошкодувала! Було дуже цікаво, пані Дідковська зуміла переконати усіх у винятковій важливості тестування специфікацій, адже за її словами більше 50% усіх багів відловлюються саме на цьому етапі, і оскільки фікс цих багів найдешевший, то щоб не завести проект у >...<, варто попрацювати над текстами спек, що потрапляють до вас у руки. Вона продемонструвала "живі" приклади вимог, які надсилав їм замовник, їхні коментарі до них та еволюцію текстів після того, як замовник припиняв сипати двозначностями та починав давати реальні визначення того, що їм було потрібне. Так, як виявилося, щоб вияснити, що справді було потрабно замовнику, довелося двічі правити спеку та пересилати стек "what didi you mean" запитань.
...Ух... На сьогодні все. Було круто знову відчути ту атмосферу з великою концентрацією спеціалістів з якості ("ми з вами одної крові" і все таке))) на одній території.
Звіт про день 2 is coming:)
No comments:
Post a Comment