ВІДЕО: Лекція в mate.academy про гнучкі методології

Моя лекція (і трошки тренінг) з agile SDLC, вперше записана завдяки Serhii Piddubchak. Назву теж він придумав, мені подобається :-)
Дякую mate.academy за можливість поговорити перед розумними людьми:-)

 

На 3й хвилині я забув, що мене щось записує, і вийшов на номінальну швидкість. 
 https://www.youtube.com/watch?v=O94gn4MLQSE&feature=youtu.be

 Якщо комусь цікаво подивитись слайди, то ось:
Software Development Life Cycle and Agile Methodologies


І якщо вам здасться, що це замало, ось ще трошки питань-відповідей опісля (обережно, пиво!):
https://www.youtube.com/watch?v=UZzGy5Oo-ZQ&feature=youtu.be

Тестер у девопсовій шкурі

Останній місяць я займаюся одразу двома проектами. Один - на завершальній фазі, як раз де "Богородице, регресію прожени!", а другий - щойно почався, і тестити там очевидно нема чого. Триває вибір архітектури взаємодії компонентів і всяке таке, коли нічого не працює, і взагалі незрозуміло, як і чи воно працюватиме. І от попросився я, щоб внести трохи ясності в проект, налаштувати їм воркфлоу в TeamCity, тобто побути девопсом чи по-архаїчному "адміном", бо у нашій команді таких не передбачено. 

Картинка з How devops can deliver business value

Що я із цього досвіду виніс. 


- Тренування на "схожому" сервері - це, скоріш за все, пусте. Там, звичайно, буде працювати більшість простих скриптів, але щось основне обов’язково піде не так. Вибирайте сервер одразу схожий на живий.
- Docker - це чудово. Проект щоразу поліпшується і стає більш стабільний. Але все одно трапляються непорозуміння, і stackoverflow іноді ліпший за офіційну документацію. Тим не менш, оця сторінка стала мені дуже в нагоді: "Dockerfile best-practices".
- Система дозволів *nix - це не тільки chmod -R 777 ., але і sudo chmod -R 755 .
А бува треба навіть sudo -s chown -R root .
- Загалом, перше, куди треба дивитися, коли щось не працює - це директорія, де виконується скрипт, і права доступу в ній.
- PuTTY й KiTTY для Windows, та й CygWin вже не потрібні, бо є GitBash, він природніший, і дійсно створює nix-досвід у Windows-середовищі :-) 
А скоро вінда взагалі буде майже убунтою. Але від того справжня Ubuntu може вмерти. Ну а що поробиш...
- SSH-ключі, агенти, демони та клієнти - це та область знань, яку я намагався не чіпати навіть семи-метровою палкою, сподіваючись, що вигадають щось нове, більш зручне та зрозуміле. Але ні, мабуть адмінів влаштовує... У мене вже третій раз виникає проблема із автоматичним чекаутом з GitHub, і я досі хз, що з ним робити... Та сподіваюсь, розберусь.

Ну і головне, що я виніс - як той співав "Карма є-е-е!" 
Те, що працює у знайомих девопсів і навіть програмістів, у мене не працює не те що з дефолтними налаштуваннями, а навіть і після втручання (неглибокого) адмінів. І це не завжди моє підсвідоме бажання все розхитати. Мені чомусь все вже розхитане попадається :-)

За нові досвіди, досліди і посліди!

Тестатон - Суддівський погляд

Пройшов тестатон TestUAStartUps#6.
А перед ним мене попросили дати настанови суддям. Ось, що я їм казав:

Скоро новий тестатон! І для мене велика честь, що мене знову запросили туди у якості судді. Цього разу я спробую хоча б кілька годин побути і учасником теж: пошукаю й позаводжу баги, "сфокусуюся на головному для користувачів", як я сам завжди раджу учасникам.

В якості судді, перевіряючи результати тестування, найбільшу увагу хочеться приділити найсуворішим багам. Адже команда за один такий баг отримує у 8 разів більше, ніж за якусь дрібничку. З іншого боку, 8 зареєстрованих дрібничок дають стільки ж, скільки Blocker, тому ними теж не варто нехтувати.

Але мало просто знайти баг, треба його добре локалізувати, гарно і зрозуміло описати, та правильно визначити важливість. Саме ці три оцінки складають повний бал за баг-репорт. 
 В оцінку опису входить "загальний екстер’єр" баг-репорту та наявність скріншоту чи відео, коли це необхідно. Але навіть добре описаний баг із неправильно виставленою важливістю вже не отримає максимальний для цієї важливості бал. Тому годі сподіватися, що поставивши скрізь Severity = Critical ви наближаєте себе до перемоги. Якщо Critical виявляється Minor'ом, то команда не отримає навіть максимальний бал за Minor. 
Те ж саме стосується локалізації багу. Гарно описаний та правильно зважений баг, що має 7 кроків відтворення замість 3 теж є кандидатом на зниження загальної оцінки.

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

Також чомусь всі команди зосереджуються на тестуванні, і всі забувають, що Test Summary Report - це теж важливо та корисно. Передусім, для стартапів - вони ж прийшли дізнатися, в яких областях у них найбільше багів. І найголовніше, Test Summary Report - це окрема номінація!

І як завжди скажу, що XSS та SQL ін’єкції - це прикольно. Тому можете вже зараз приготувати парочку шаблонів, щоб швиденько оцінити, чи думали програмісти та архітектори про безпеку своєї системи.

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

Техніки Тестування "З Досвіду"

Анлійську версію цієї статті опубліковано на EUROSTAR's Huddle as Experience-based Testing Strategies

 
На різних ресурсах з тестування програмного забезпечення часто згадують деякі загадкові “Experience-Based Test Techniques” (Засновані на досвіді техніки тестування). Для мене це завжди звучало як "от доростеш до наших літ, тоді й узнаєш". Але коли я сам став вчити тестуванню, то не міг нормально пояснити, що воно таке. Бо "досвіду" трохи важко навчити :-). Можна вигадати деякі практичні завдання, зроблені так, що студенти щось вивчають, але неможливо зробити так, щоб вони вивчили точно мій досвід.

Test Design Techniques by learnthebasicsofsoftwaretesting.blogspot.com

У тестуванні ми звикли використовувати філософські категорії, що не можуть бути явно описані за допомогою мови логіки, як то: якість, корисний, добре, досить добре, досвідчений і т.д.

Experience-based testing strategies

This article was published at EUROSTAR's Huddle as Experience-based Testing Strategies


On various software testing resources there are often mentioned some mysterious "Experience-Based Test Techniques". Teaching testing I always had a hard time trying to explain what is that. It's kind of very hard to teach "experience" :-) . One can present some practical task, designing it in a way that the students learn something, but it's impossible for them to learn exactly your experience.
In testing, we used to deal with such philosophical categories that cannot be explicitly described with a language of logic, like: Quality, Useful, Good, Good-enough, Experienced etc. (Say Hello to Plato!)

 

Test Design Techniques by learnthebasicsofsoftwaretesting.blogspot.com

Чи потрібен текст повідомлення у багрепорті?

Днями розповідав своїм студентам про те, що обов’язково треба вставляти текст повідомлень у Actual Result - наявний результат тесту у звіті про помилку. Ніби все зрозуміло і очевидно. Але потім у завданні кількох студентів побачив опис, що обурив моє почуття прекрасного:

Всі (принаймні, молоді тестери) чомусь думають, що поля Наявного (Actual Result, AR) та Очікуваного (Expected Result, ER) результату мають бути спорідненими, заповненими приблизно однаковими словами. Часто навіть бачу багрепорти, де ці поля відрізняються лише присутністю чи відсутністю частки "не". Табличка результатів тестування виходить гарна та однорідна. Я вважаю, що це "шкідлива однорідність". Бо вищенаведені поля мають принципово різну ціль, і мають бути заповнені відповідно до свого призначення, а не "для гарного візерунка".

Чому треба обов’язково додавати повідомлення в Наявний Результат?
Тому що це дозволить програмісту знайти ті місця в коді, де викликається показ саме цього повідомлення; і виправити логіку саме в тому випадку, що описаний у кроках відтворення, звісно якщо це необхідно.

Чому не варто, а часто навіть шкідливо, додавати текст повідомлення в Очікуваний Результат?
Тому, що це багрепорт - повідомлення про помилку - а значить логіка роботи системи потребує зміни. І ми дізна́ємося, які саме зміни були внесені, і яку шкоду покращення було зроблене тільки згодом. Тому зараз, коли ще навіть невідомо, чи це баг, і тим більше не відомо, як і коли його будуть фіксити, не можна диктувати програмістові з майбутнього, якими словами його логіка буде звертатися до користувачів. 
Але навіть тоді, коли логіка виправлення здається дуже ясною, як на картинці вище, багато всього залежить від контексту, який неможливо вмістити в одне речення звіту про баг.