Ще раз про оцінювання задач

#testing #process

Минулого тижня я прочитав дві вкрай практичні статті про те, як робити естімейти.
- Rules of Thumb for Software Development Estimations
- My Software Estimation Technique

Далі я наводжу мої короткі нотатки (авжеж краще ознайомитись із оригіналом!)

Про оцінки
- Не існує двох повністю ідентичних проєктів
- Невизначеність буде завжди
- Комунікації між командою та бізнесом впливають на оцінки

Як НЕ треба робити естімейти
- Намагатись “вгадати” чи взяти оцінку з довідника “стеля”
- Користуватись одним та тим самим підходом для будь-яких задач
- “Забивати” на зовнішні фактори
- Відмовлятись переглядати оцінки з часом

Яку техніку естімації пропонує Jacob Kaplan-Moss:
1. Розбийте роботу на невеликі менш складні підзадачі. В залежності від складності це можуть бути small, medium, large та extra-large задачі.
2. Оцініть невизначеність. Розробіть свою виміру: чим більше невизначеність, тим більший множник. Для низького рівня множник може бути 1.1, для найбільшого - 5.0.
3. Виконайте розрахунки. Для кожної задачі розрахуйте очікуваний час виконання, а також час з урахуванням невизначеності.
4. Уточніть дані, якщо є потреба. Якщо у вас багато extra-large задач, спробуйте або розбити їх, або додати окремі задачі на research - щоб зменшити ризики та невизначеність.
5. Відстежуйте точність, щоб покращуватись із часом. Порівнюйте, наскільки ваші оцінки відрізняються від реального часу виконання задачі - та робіть відповідні зміни у своїх підходах.

Які ще техніки оцінки задач існують
- Program Evaluation and Review Technique
- Evidence-based scheduling
- Fruit-salad scrum

Як допомогти менеджеру та команді робити оцінки краще
- Більше комунікуйте
- Користуйтеся своїм досвідом
- Не забувайте про ризики
- Заохочуйте культуру, де задавати питання та уточнення - це нормально

P.S. Наче нічого кардинально нового, але ...
P.P.S. Думаю, Артем та Артур можуть доповнити замітки щодо оцінок ... 😉

Секрети тестування від Matt Heusser

#testing #video

Matt Heusser щотижня викладає короткі відео, в яких розповідає про тестування та ділиться секретами із власного досвіду.

Вже вийшло три випуски: 1, 2, 3

Про що там?
- Який найбільший секрет тестування
- Чому ми прокрастинуємо, коли потрібно тестувати та як зробити тестування веселим
- Скільки часу ми дійсно витрачаємо на тестування

Test Engineering Notes: Volume 2

#testing #engineering #digest

Всім привіт. Черговий дайджест цікавих статей вже тут.

З найкращого, у цій підбірці ви знайдете:
- чи можна копіпастити код у тестах та чи працює дослідницьке тестування в Agile
- тренди автоматизації в 2023 та підходи до тестування навантаження розподілених систем
- чи потрібно переписувати усе за "папєрєдніками"?
- як працюють Slack, ChatGPT, алгоритми рекомендацій та пошуку аномалій
- чи моноліт краще за мікросервіси та чи можна вже зараз створювати додатки та тести зі специфікації з ChatGPT

а також купу інструментів, включно з новою тулою для тестування мобілок.

Хороша візуалізація того, що таке двох-факторна аутентифікація

Чи варто витрачатися на якість?

#testing #engineering

Мої нотатки статті Мартіна Фаулера. В ній він розповідає про те, чому краща внутрішня якість дозволяє додавати фічі легше, швидше та навіть дешевше.

Корисне з GitHub - 1

#github #selection

- Для тих, хто вивчає тестування безпеки маю план навчання із добірками статей. Постійно поповнюється.
- Для стильних та молодіжних, хто користується JS в автоматизації - webdriverjs рецепти
- Для тих, хто як і я, час від часу помиляється в командах в консолі - thefuck

Про стандарти та якість даних

#testing

Всім доброго ранку понеділка.

Час від часу на співбесіді можна почути питання - "А що таке якість? Які різні аспекти якості ви знаєте? Що ви знаєте про якість даних?"

Ця тема доволі обширна, але починати пропоную зі стандартів.

Знайшов отакі стандарти:
- ISO/IEC 25010 Software Product Quality
- ISO/IEC 25012 Data Quality Model

Окремо для тих, хто хоче почитати про застосування моделі якості даних:
- Data Quality Certification using ISO/IEC 25012: Industrial Experiences
- Assessing data cybersecurity using ISO/IEC 25012

Поради з автоматизації на кожен день

#books #automation

У Joe Colantonio, того що веде подкаст Test Guild, вийшла книжка - "Automation Awesomeness". В ній Joe зібрав поради з автоматизації та тестування від кожного із запрошених на подкаст гостей.

Якийсь час ця книжка буде безкоштовною через Amazon Kindle.

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

Цікаво: як працювати з gRPC через unix socket

#testing #automation #grpc #python

Коротка нотатка про деякі особливості роботи gRPC через сокети.

P.S. Дайте знайти в коментах, якщо потрібно трохи більше розкрити тему gRPC.

Tools. Генерація даних в Java, питання по DevOps та Python завдає удару у відповідь

#tools

Цікаві інструменти та репозиторії для розробки та навчання новому

1. Бібліотеки генерації даних в Java: datafaker та instancio
2. Шикарна підбірка питань та відповідей для тих, хто вивчає DevOps
3. Pynoscript - пишемо Python код прямо у HTML

Hardcore у п'ятницю: Перша ремарка про перфоманс блокчейн систем

#testing #performance #blockchain

Цього тижня я тільки-но почав досліджувати питання перфомансу блокчейн систем. А саме - як та що вимірювати.
Ось що я встиг зрозуміти.

Блокчейн систему (як дуже спеціалізований вид розподілених систем) не можна тестувати та вимірювати звичайними метриками та засобами до яких ми звикли. Тобто не буде дуже правильно ставити питання “скільки TPS (transaction per second) може витримати система?” (а люди все ще запитують)

Чому? Бо блокчейн веде себе зовсім по-іншому. В звичайній системі (наприклад у веб додатку) більшість запитів повинні отримати відповідь через деякий час. Чим більше запитів від користувачів, тим більше ресурсів бекенду задіяні в обробці цих засобів.
Для того, щоб обробляти більше запитів - ми просто додаємо більше “машин” для обробки. (Наприклад автоматично через auto-scaling).

В блокчейні такий підхід не працює.
Кожен вузол в блокчейні може обробляти деяку кількість запитів. Причому запити в блокчейні - це звичайні транзакції. Коли транзакцій стає більше, ніж влазить у mempool вузла, нові транзакції не будуть оброблятись.

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

В окремому випадку потрібно зачекати, поки транзакція стане “стабільною”. Це може бути N блоків поверх того, в якому ця транзакція опинилась або інший варіант алгоритму. Тільки після цього можна відправити дійсно правдивий респонс користувачеві про те, що його транзакція успішна.

То ж підвищити швидкість обробки транзакцій (тобто “перфоманс” блокчейну) не можливо простим додаванням більшої кількості вузлів. Бо вузлам потрібен час, щоб комунікувати між собою та досягти консенсусу.

Один з варіантів оцінки швидкості - це наскільки швидко буде транзакція оброблена, включена в блок та стане стабільною. Тобто block propagation time.

Попереду в мене ще багато відкриттів. Продовжую дослідження.

Збір 10 млн грн на борти Shark

DOU та KOLO організовують збір на 5 БПЛА Shark для найкращої туристичної компанії - 15-тої окремої бригади артилерійської розвідки. Пропоную долучитись до збору та допомогти нашій розвідці.

100+ Computer Science Concepts Explained

#engineering #video

Для тих, хто досі відчуває "синдром самозванця" - маю коротеньке відео, яке допоможе закрити деякі прогалини в знаннях computer science.
Це не замінник університету та навіть хорошим курсам.
Але ... допоможе не переживати щодо базових технічних знань на співбесіді.

Книжкове: Demystifying Public Speaking

#books #review

Минулого тижня я прочитав книгу "Demystifying Public Speaking" за авторством Lara Hogan.
Далі коротко розкажу чому та кому цю книжку варто читати.

Для кого ця книга? Для людей, що жодного разу не виступали публічно з доповідями. Навіть на роботі. Але якщо ви вже десь щось розказували декілька разів - деякі поради з книги також можуть стати у пригоді.

Ця книга з категорії - "як би я хотів її прочитати років десять тому". В книзі дуже мало води та дуже багато практичних порад. До того ж - книга невелика, тому її можна швидко прочитати.

Що ви дізнаєтесь з книги:
- усі хвилюються перед виступом - це нормально
- як знайти тему для доповіді навіть якщо "нема про що розповідати"
- як підготуватися до доповіді та як збирати корисний зворотній зв'язок
- алгоритм "тренувань" доповіді перед великою конференцією
- як правильно писати Call For Papers
- як оформлювати слайди та інші матеріали
- як правильно відповідати на питання з залу
- багато іншого та купу посилань на різні статті та відео

Чого в книзі ви не знайдете?
- прикладів крутих доповідей (є декілька, але мало)
- постановки голосу, роботи з аудиторією, storytelling, різні підходи к презентаціям
- як вести воркшопи та інші типи доповідей на більше 45 хвилин

Про що робити доповідь?

#speaking

Нотатки з книги Demystifying Public Speaking.

Так, де взяти тему для доповіді (особливо першої)?
Можна розповісти базову доповідь про підхід або інструмент (intro to ...)
Або ...

Задумайтесь, на що ви витрачаєте більшість часу на роботі? Це також може бути вашою темою.

Коли ви знайшли цікаву проблему, що варта уваги:
- знайдіть її першопричину
- проаналізуйте та запишіть весь процес вирішення проблеми
- проаналізуйте також результати - що можна було зробити краще
- сфокусуйтеся на результатах (для стороннього слухача)

Кожна з тем може містити в собі історію, натхнення, демонстрацію або новий підхід для вирішення старої та відомої проблеми.

На останок шарю з вами цікавий worksheet-cхему для генерації ідей для доповіді.

П'ятничне: Про унікальний підхід до розробки у Valve

#testing #video

Коротке відео про те, як у ігровій компанії Valve підходять до тестування та як це тестування впливає на подальшу розробку.
Це наче Shift-right тестування практично з першого дня роботи.