Test Engineering Notes

100+ Computer Science Concepts Explained

#engineering #video

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

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

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

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

#testing #performance #blockchain

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

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

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

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

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

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

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

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

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

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

#tools

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

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

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

#testing #automation #grpc #python

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

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

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

#books #automation

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

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

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

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

#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

Корисне з GitHub - 1

#github #selection

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

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

#testing #engineering

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

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

День корисних шпаргалок. Цього разу - як обрати базу даних та основи роботи з SQL

Test Engineering Notes: Volume 2

#testing #engineering #digest

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

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

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

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

#testing #video

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

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

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

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

#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. Думаю, Артем та Артур можуть доповнити замітки щодо оцінок ... 😉

Які є інструменти для автоматизації в ...

#testing #python #java #tools

Доброго ранку.
Коли ми тільки знайомимось з автоматизацією, або ж переходимо з однієї мови програмування в іншу - постає багато питань.
- Яку бібліотеку для ассертів взяти в мові Х?
- Які є альтернативи бібліотеці репортів у мові У?
- Чи є BDD інструмент для мови …?
- Та інше …

Авжеж можна запитати в каналі чи в чатах тест інженерів. Але мені допомагають списки типу awesome-X. У них хтось дуже добрий вже зібрав купу інструментів та виклав у публічний доступ.

Які списки використовую я сам:
- awesome-test-automation від atinfo. Є для багатьох мов програмування - у тому числі - Java, Python, JS.
- awesome-python-testing - лист інструментів для Python.
- java-testing-toolbox - набір прикладів з книги “30 Testing Tools & Libraries Every Java Developer Must Know”. (Знайшов цього тижня, але виглядає непогано для початківців).

Для інших технологій та мов програмування, можна пошукати списки awesome списки на GitHub.

Test Engineering Notes pinned «Що це за канал та чи варто його читати? Днями на канал підписалося багато нових людей. Тому я хотів би ще раз розповісти про те, хто я та чому варто читати цій канал. Про автора Мене звати Олександр Романов. В IT я працюю з 2011 року. Декілька місяців був…»

Що це за канал та чи варто його читати?

Днями на канал підписалося багато нових людей. Тому я хотів би ще раз розповісти про те, хто я та чому варто читати цій канал.

Про автора
Мене звати Олександр Романов. В IT я працюю з 2011 року. Декілька місяців був тестувальником, а потім більшу частину своєї кар’єри займався автоматизацією тестування як у продуктових компаніях так і в аутсорсі. Був автоматизатором, СДЕТом та лідом СДЕТів. На даний момент я працюю в компанії IOHK. Ми розробляємо блокчейн Cardano та різні продукти з ним пов’язані.

Основний мій технологічний стек - це Java. Але довелося також працювати із C# та Scala. Цього року перейшов на новий проект та пишу на Python. У вільний час досліджую питання тестування та безпеки смарт-контрактів та блокчейну.

Крім каналу, я веду блог, роблю доповіді та є в Twitter. Також пишу дайджести на DOU та приймаю участь у подкасті “Не баг, а фіча”. А ще - я займаюся менторингом з автоматизації.

Про канал
У цьому каналі я збираю інформацію про технічну сторону тестування та інженерії - тобто про великі складні розподілені системи, як вони працюють та як підходити до їх перевірки.

Основний фокус саме на практичних знаннях та нових підходах. Що саме головне - я намагаюся пояснити навіть найскладніші речі простими словами.

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

І ще одне! В каналі є можливість шукати матеріали по тегам: #testing #digest #books #engineering

Ласкаво прошу у канал. До зустрічі в коментарях. Давайте разом робити тестування більш технічним та цікавим.

💡Українські телеграм канали з тестування.

Так як лінка трохи міняється - додам окремий пост.
Збірка активних українських телеграм каналів з тестування. Приєднатись - тут.

P.S. краще відкривати з мобільного

Про жаргон та зірковість

#thinking

It’s Wednesday, dudes!
Цього тижня я натрапив на цікаву статтю від Gergely Orosz - “Is Critical Thinking the Most Important Skill for Software Engineers?”.
В ній автор розповідає про дві важливі речі: жаргонізми та довіру "зіркам".

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

Довіра “зіркам”
Коли ми починаємо кар’єру (та й надалі) ми стикаємося з лідерами думок: в Твіттері, телеграм каналах, на конференціях. Ці люди, зазвичай, дуже впевнено стверджують різні речі. А через їх досвід та “медійність” - ми схильні таким людям довіряти.
Але варто пам’ятати, що ці “зірки” можуть помилятися або грунтуватись на суто власному досвіді (а потім натягувати цей досвід на будь-які ситуації).

В обох випадках, треба критично ставитися до інформації. Розбиратися та перевіряти. Навіть, якщо це говорять люди з великим досвідом.

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