Звіт з QAFest 2017 про тестування та автоматизацію

Із вдячності згадаю, що Svitla Systems повністю заплатила за мій квиточок на QA Fest. Це добре. Всі фірми мають спонукати своїх співробітників до професійного спілкування.


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

Ну і продовжу про інші доповіді, де я встиг побувати.

Jeremias Rößler, ReTest, "Applying AI to Testing"

Іларій Хенрік Егертер (Ilari Henrik Aegerter), House of Test, Швейцарія, проповідував контекстно-кероване тестування, вправляв клепки тестерам із важкими формами пост-ISTQB-шного синдрому, і загалом поводив себе як намісник Джеймса Баха і Сема Канера на землі. Мене дуже потішило, що його презентація на 80% співпадала за змістом із моїм ввідним уроком для початківців у тестуванні. 

• Тестер має бути "compulsive empericist", тобто намагатися про все дізнатися тільки із практики. 
• Повторив мою думку, що тестер не має нікому вірити, "Trust no one!" (дивіться отут із коментарями Майкла Ларсена).
• Тестування має ділитися не на "ручне" та "автоматизоване", а за кількістю часу, що тестер витрачає, спілкуючись із іншими людьми. Тут Іларій сам запнувся і не зміг продовжити думку до кінця. Думаю, він мав на увазі, що зараз усі тестери в тій чи іншій мірі використовують певні елементи автоматизації: скриптик підлаштувати, дані згенерувати. І виходить, що всі є авто-. Зі свого боку, я б розділив тестерів на тих, що пишуть тули для підтримки своєї дослідницької роботи, яку вважають головною; і тих, що пишуть тули, які потім виконують окремі функції і живуть своїм життям.
• В кінці презентації був вартий уваги список літератури з філософії тестування.

Єреміас Рьослер (Jeremias Rößler), ReTest, Німеччина, презентував свій стартап ReTest, де вони широко застосовують штучний інтелект для налаштування регресійного тестування. Цікава ідея, що давно літає в повітрі. Бажаю йому та його стартапу успіхів!

• Регресійне тестування - це, насправді, ніяке не тестування, а контроль змін. Нові фічі  - це бажані зміни. Увесь інший функціонал не має змінюватись, там зміни - не бажані.
• 2 підходи до опису змін: Чорний Список - описуємо області, що треба ігнорувати; та Білий Список - описуємо області, що треба перевірити, інші ігноруємо.
• Пригадайте мнемоніку HICCUPPS (F) від Майкла Болтона, що достатньо повно опитує систему на узгодженість (consistency). Єреміасу треба формалізувати таку оцінку системи за допомогою штучного інтелекту. Цікава і сучасна задача.

Пер Торсхейм (Per Thorsheim), з Норвегії, будучи просвітником в області кібербезпеки, мав 2 доповіді. Перша стосувалася останніх змін Європейського законодавства щодо персональних даних. Лише одна нотатка звідти:

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

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

• Використовуйте Signal / Watsap / Wire. Вони мають відкритий код, достатній рівень захисту особистої інформації та їхні повідомлення не зберігаються на сервері.
• Використовуйте Viber тільки якщо ви довіряєте ізраїльським спецслужбам. 
• Емейл досі є найбільшим каналом передачі інформації. І водночас - найбільш вразливим каналом, з огляду на старий протокол і недбальство адміністраторів з переходу на нові інструменти захисту власних серверів, як то STARTTLS
• DNS теж дуже вразливий. Перевірте, чи увімкнений DNSec у вашого провайдера (треба дивитись презентацію, не зміг зараз знайти ту сторінку).
• Рушієм усіх змін можете бути Ви! Завдяки Пе́ру, наприклад, Норвегія стала більш захищеною, бо він ходив, дзвонив, писав і всіх задовбував.

Діана Пінчук, GetSocial, дуже цікаво розповіла, як працюється тестером, коли кінцевим продуктом вашої команди є не повноцінний додаток, а бібліотечка SDK, що вбудовується в інші програми.

• Один сучасний мобільний додаток містить 12-16 інших SDK
• Користувачі - хай це і програмісти - помиляються, роблять дурню, хочуть неможливого. На це треба зважати, і перевіряти зручність стек-трейсів, вставляти туди лінки до описів популярних помилок.
• Мнемоніка для тестування мобільних систем: TAP IT UP (вона описана в минулій презентації Діани https://www.slideshare.net/Dakiry/how-to-test-mobile-sdk-and-do-not-loose-faith-in-yourself )

Також було згадано про нові для мене інструменти: 

• Stetho - для аналізу апок;  
• Vysor - контроль за телефоном та запис відео з екрану;  
• RunScope - як Postman, але із можливістю запуску тестів API за розкладом.

Раджу подивитися презентацію повністю, коли вона з’явиться, бо було цікаво.

Іван Циганов (Иван Цыганов), Positive Technologies, росія, у доповіді "Не смішіть мій coverage" ділився прикладами вимірювання code coverage (statement, decision, (доречі, не було condition coverage)) у Python за допомогою coverage.py.

Від Івана вперше почув про практичну спробу використання (не дуже вдалу, як я зрозумів) мутаційного тестування за допомогою mutpy.

  Олег Лимарчук, Glombex, показав, як швидко підняти Jenkins, і за допомогою Pipeline плагіну змусити його піднімати Docker-контейнери із Selenium-тестами на py.test. І навіть зберігати відео запуску тесту у якості білд-артефакту. Було досить круто, треба і собі спробувати якось.

От і все від мене. дякую ще раз усім, хто долучився!
Сподіваюсь, слайди та відео викладуть раніше, ніж цей пост поросте мохом забуття :-)