Дві сторони тестування

#testing

В книзі "Explore It" Елізабет Хендріксон говорить про те, що тестова стратегія повинна відповідати на два питаня:

- чи веде себе софт так, як очікується в тих умовах, які прописані у вимогах?
- чи існують якісь додаткові ризики?

На перше питання ми відповідаємо, коли проектуємо та виконуємо тести згідно вимог. В тому числі - коли пишемо автотести.

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

Але повне тестування якраз і складається:

Tested = Checked + Explored

Чи згодні ви з таким підходом? Чи може одних лише тестів буде достатньо?

Вчимо та тренуємося писати SQL запити

#testing #sql

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

Виникає питання - "Де потренуватись писати SQL запити?"

Маю відповідь - підбірка Websites for Practicing SQL

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

Подкаст Testing Minutes - потрібна ваша допомога!

#podcast

Поки ми з Артемом готуємо наступний сезон подкасту, нам дуже хотілося б почути вас - наших слухачів та глядачів.
Тому ми підготували маленьку форму.

Ваші пропозиції допоможуть зробити подкаст ще цікавішим! Дякуємо за відповіді!

❓Як обрати, що вчити?

#learning

В Суворому QA комʼюніті завжди цікаві дискусії. Ось наприклад вчора було таке питання:

У кого яка поведінка в вивченні? Будете вчити те, де знаєте що кульгаєте? Або підете на ще один курс по темі, де ви норм розбираєтеся, але хочеться краще?

Тема навчання та розвитку дуже велика. Все як завжди залежить від того, чого ви хочете.

🔖Загальні відповіді

- Науково доведено, що людина скоріш буде практикуватись в тому, що вже й так знає та вміє. Бо це легко, це виходить. А якщо виходить - буде задоволення від виконаного завдання чи курсу.
- Щоб уникнути такої проблеми, треба памʼятати - ми вчимося тоді, коли нам складно. Так, у вас буде спокуса все кинути, бо складно. Але це - процес навчання. Тому краще обирати для навчання ті теми, в яких ви почуваєтесь найслабшими.
- Щоб зрозуміти, наскільки ви знаєте тему - спробуйте розповісти про неї комусь, навчити її, виступити на конференції. Або спробуйте сформулювати питання на високих рівнях таксономії Блума та відповісти на них (цікава техніка).
- Не всі знання однаково корисні. Треба розділяти концепції та процедури. Процедури - це будь-що, що ми робимо по визначеному алгоритму, наприклад налаштування серверу чи користувача або вирішення конкретної задачки на обраній мові програмування. Процедури запамʼятовуються ТІЛЬКИ ЧЕРЕЗ ПРАКТИКУ.

🤔Що роблю саме я

- Рефлексія. Відмічати, які робочі таски даються важче, ніж інші. Яких знань мені не вистачає. Це можуть бути знання програмування, технологій, продукту, домену.
- Візуалізація. Збираю усі ці замітки та формую карту того, що треба вчити взагалі для роботи.
- Пріоритети. Виділяю з усього списку найгарячіші теми та прокачую їх окремо. В мене працює фокус на 1-2 темах на виділений період часу - тиждень, два, або більше. Усю іншу інформацію - фільтрую та додаю в папку (коли-небудь потім)
- Відмічаю свій прогрес у вивченні. Записую, що тепер можу робити, коли розібрався у новому та закріпив то на практиці. "Тепер я можу налаштувати користувача", "Тепер я знаю, як подивитись логи в цьому сервісі та дослідити весь флоу"
- Роблю нотатки усього. Процедури, нова інформація чи концепції, мітинги.
- Закріплення. Досить недавно прийшов до того, що для кращого запамʼятовування та закріплення знань - треба робити собі власні тести знань. Можна для цього застосувати chatgpt, anki карти, що завгодно.

📰І ще одне!

А для тих, хто хоче навчитися чогось нового - можна піти на QA Magic Meetup 6.0, що відбудеться вже 26 жовтня, в Києві.

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

❓З чим я можу Вам допомогти?

Всім привіт.
Мене звати Олександр Романов. В ІТ я з 2011 року. За цей час писав на Java, C#, Scala, Python; автоматизував web, mobile, API, мікросервиси, блокчейн.

Крім цього каналу, блогу та подкасту, я допомагаю окремим людям та компаніям.

З чим я можу допомогти Вам

🔶 Тренувальні mock інтервʼю. Можливо, ви тільки закінчили курси, але ще не відчуваєте впевненості в собі для першої роботи. Можливо, ви не відчуваєте себе сіньйором в достатній мірі. А може ви задовго були на одному місці роботи та хочете бути морально готовим до нових співбесід. Якого б рівня ви не були, тренувальна співбесіда зі зворотнім звʼязком додає впевненості та допомагає зрозуміти пробіли у знаннях. Приклад інтервʼю можна подивитись тут.

🔷 Окремо хочу виділити також оцінку й покращення Вашого CV. Бо хороше резюме повинно розповідати історію про Вас та ваші сильні сторони.

🔶 Консультації з автоматизації тестування. Як краще писати тести? Чи правильний Ви обрали підхід? Які можуть бути "підводні" камені в автоматизації? Іноді проста розмова та погляд зі сторони допоможе прийняти необхідне рішення.

🔷 Індивідуальний менторинг. Разом із вами ми можемо створити план вашого карʼєрного розвитку. Я можу допомогти із тим, що краще вчити, як практикувати вивчене, а найголовніше - як це робити найбільш ефективно. (Щоб знання стали навичками, а не забулися через місяць-два).

З чим я допомагаю компаніям:

🔶 Технічні інтервʼю. Якщо у вас молода команда, але треба її швидко розширити, я можу допомогти зі співбесідами та оцінкою навичок кандидатів.

🔷 Консультації з автоматизації тестування. Від оцінки проєкту до побудови стратегії тестування й автоматизації. Або ж вирішення конкретних запитів.

Якщо маєте питання чи хочете домовитись про дзвінок - пишіть в дірект. Завжди радий допомогти.

“ISTQB Test Manager 3.0: управління тестуванням в умовах невизначеності”

🤓 Цьогоріч перше за 12 років вийшла оновлена версія силабусу до сертифікації ISTQB Advanced Test Manager.
Його вже дослідила і готова ділитися своїми враженнями Олександра Ковальова, ISTQB-тренерка з 8+ річним досвідом.

👉 що покриває нова версія Advanced Test Manager 3.0 і де вона стане у нагоді, а де ні;
👉 чи став іспит легшим в новій версії;
👉 скільки в новій версії agile і до чого тут Foundation Level 4.0;
👉 як впливає модель розробки на проєкті на планування тестування, і де тут невизначеність;
👉 навіщо тестувальникам рівня Middle та Senior розуміти роботу Test Lead;
👉 чи вплинули ці зміни на тестувальників, які складали попередні версії іспиту;
👉 яка різниця в ролях Тест Лід та Тест Менеджер в компаніях, і що про це каже ISTQB.

Коли?

⏰ Початок о 19:00, 8 жовтня
📋 Обов'язкова реєстрація для участі у трансляції та отримання запису.
🎯 Деталі та реєстрація: https://bit.ly/3XVdujo

Що таке Peel Testing?

#testing

Блукаючи мережею в пошуках цікавого контенту, я натрапив на коротеньке відео "What is peel testing".
Моє перше враження було - "Прикольно, новий вид тестування!".
А потім я подивився й зрозумів, що тестування - то не тільки програми, біти й байти ...

А ви знаєте, що таке peel testing?

📣 Embedded QA skill set: Are you all set? 📣

Це must-visit подія для QA-спеціалістів, які цікавляться напрямом Embedded, де команда SQUAD поділиться дослідженнями та аналізом актуальних навичок для Embedded QA.

Приєднуйтесь, щоб оцінити себе або команду відносно потреб ринку 🧐

У ПРОГРАМІ:

▪️Актуальні скіли для Embedded QA
▪️Статистика по топ навичкам для Embedded QA в Україні та США
▪️Опис скілів та їхнє оцінювання
▪️Визначення пріоритетних скілів кандидатів при наймі в команду
▪️Обґрунтоване формування цілей та трекінг прогресу розвитку колег
▪️Чому skill set матриця є одним з найзручніших інструментів візуалізації вмінь команди?

ДЕ і КОЛИ:

🗓️ 23 жовтня | 19:00-21:00
📍 Київ, облаштований та безпечний простір SQUAD
💻 Онлайн-трансляція для тих, хто не може долучитися фізично
🙌 Участь безкоштовна

Деталі та реєстрація — https://bit.ly/47X6o2A

Встигніть зареєструватися, кількість місць офлайн обмежена 😎

😱Покращуємо якість без тестувальників

#testing

Цими вихідними натрапив на цікаву статтю. В ній розробник розповідає, як вони покращили якість на проєкті.

🦶Покроковий алгоритм дій:

1. Звільніть усіх тестувальників!
2. Розкажіть розробникам, що вони тепер відповідальні за якість
3. Розробник, що робить код ревʼю - тестує фічу
4. Розробник, що зробив задачу - додає до пулл реквесту докази того, що фіча працює (скріншоти, відео, запити)
5. Проводьте нерегулярні bug bash активності - де тестувати будуть усі, включно з дизайнерами, менеджерами та аналітиками (бо знайти хорошого тестувальника складно)

Більше про результати можна почитати в статті.

❓Як думаєте, чи успішний був такий підхід?

Швидко малюємо діаграми в Excalidraw

#visual

Іноді простого опису текстом недостатньо, щоб зрозуміти якийсь процес чи структуру. Тоді на допомогу можуть прийти діаграми.

Краще, звичайно, малювати їх вручну самостійно. Але можна користуватись й інструментами - наприклад Obsidian Canvas, Miro, Excalidraw.

Якщо треба швидко зробити візуалізацію, то в Excalidraw є функція "Text to diagram".

Наприклад ось, що він зробив на такий текст:

  
Digital Signature Scheme

Two phases: sign and verify. 

At sign phase, Alice calculates hash (256 bit) from the document she wants to send Bob. Then Alice encrypts the hash with her secret key. 

At verify phase, Bob decrypts hash with Alice's public key, calculates hash from the document and then compare his hash and Alice's hash. If same - document is verified.

📝Кількість багів - як метрика якості 🐞

#testing #metrics

Коли стає питання, як виміряти ефективність тестувальників, перша думка, що виникає в голові менеджера - це кількість багів!

Але сама по собі, кількість багів це, скоріш, шкідлива метрика.

Чому шкідлива?

✍ Оцінювати ефективність роботи по кількості багів - це як оцінювати розробника по кількості строк коду чи книжку по кількості сторінок

✍ Кількість багів може бути різною, бо все залежить від специфіки продукту, процесів, людей

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

Що робити замість трекінгу кількості?

Збирайте та аналізуйте defect leakage - кількість багів, що "просочилася" на продакшн та була знайдена користувачами. На кожен з таких багів треба зрозуміти його причини та як команді не пропускати подібні баги у майбутньому.

89 сторінок типових софтверних помилок від Cem Kaner

#testing

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

Дефекти можуть бути різними:
- помилки в коді (ліміти значень, обробка помилок, розрахунки)
- помилки в логіці та роботі з даними
- помилки "хардової" частини, що впливають на софт
- помилки в UI/UX
- багато інших.

Для тих, хто хоче подивитись на види помилок трохи глибше - я знайшов величезну (майже на 90 сторінок) добірку від Cem Kaner.

Навіть просте читання цього матеріалу може підкинути вам багато ідей про те, де ще можна тестувати та шукати ці дефекти у вас в софті

Як це працює: Shazam

#howitworks

Колись давно, дізнатись назву пісні чи виконавця, які ви десь почули було вкрай складно. Можна було записати фрагмент на диктофон, запитати в друзів чи чекати, коли той кліп покажуть десь на М1 чи Enter Music 👨‍🦳 А потім - зʼявився Shazam та дав нам можливість взнати мелодію за якісь лічені секунди.

Але що то за магія? Як працює? Сьогодні я поділюся статтею, яка пояснює алгоритми та технології під капотом Shazam. (Без хешування не обійшлося!)

TL;DR - Коли додаємо нову пісню в бібліотеку

1. Калькулюємо спектрограму пісні
2. Дістаємо граничні значення зі спектрограми
3. Обчислюємо хеші з цих значень
4. Зберігаємо колекцію хешів як унікальний "відбиток" пісні

TL;DR - Коли шукаємо пісню

1. Обчислюємо "відбиток" аудіо фрагменту
2. Знаходимо хеш значення, що відповідають цьому відбитку
3. Для кожного потенційного збігу в пісні треба обчислити час відстеження, потім згрупувати це у формі гістограми
4. Повернути пісню, що найбільше подібна до фрагменту

Більш докладно можна почитати в статті. (Описаний алгоритм був на початку розвитку продукту. Який там він зараз, поки не знайшов. Напевне щось там з AI)

Але найбільш цікавими залишаються питання - як це все тестувати? Яким би був Ваш підхід?

🧪Курс Automation Testing: від ручного тестування до автоматизації з Олексієм Вовком – можливість підняти свою кар’єру тестувальника на новий рівень та опанувати навички створення надійних автоматизованих тестів.

🔸Старт: 24 жовтня
🔸Тривалість: 16 занять
🔸Програма та реєстрація

Старт вже через 2 дні і залишилось ще декілька місць на курсі, тому це твій останній шанс приєднатись до курсу зі знижкою -40% (від вартості Standard).


Чому варто взяти участь:

🔸Тренер – Олексій Вовк, Senior Test Automation Engineer, автор статей у медіа, практикуючий спеціаліст Sigma Software з понад 7-річним досвідом в автоматизації тестування
🔸Практичне застосування знань на реальних проєктах
🔸Опанування новітніх технологій та практик
🔸Робота з ШІ – дізнайся, як ШІ може покращити роботу тестувальника-автоматизатора, та створи модуль для тестового фреймворку за допомогою ChatGPT

🔗Дивись вступну лекцію, дізнавайся більше та реєструйся – ТУТ

I am tired of AI

#testing #ai

Bas Dijkstra у своєму блозі вирішив поділитись думками щодо AI.

TL;DR

- зараз неймовірне засилля AI де треба й де не треба
- AI інструменти з тестування можуть допомогти отримати результати швидше. Але чи кращі такі результати - то вже інше, велике питання
- Люди користуються AI навіть для написання текстів (наприклад для CFP на конференціях) про AI. Ці тексти зазвичай просто однакові! Вони не показують справжню людину.

Що я думаю про AI

Від себе можу додати, що частково я згоден з автором.

Цими вихідними був на черговій конференції тестувальників - та бачив там 60-70% однакових доповідей з AI в темі. До того - на інших конференціях ситуація не краще.

- Хтось продає "чарівні срібні кулі", які допоможуть тестувати за наносекунди.
- Хтось в мільйонний раз намагається розповісти базу з AI за 30 хвилин для непідготовленої аудиторії, якій це абсолютно не цікаво.
- Хтось годину показує як користуватись chat GPT (хоча там запити також дуже прості)

Але разом із тим - майже немає доповідей як реально тестувати ML алгоритми. Чи чатботи. Чи LLM системи.
Те, що я бачив - на дуже примітивному рівні (підготуй ексельку з питаннями й відповідями та потім закинь її в чатбот).

Нові технології та їх розвиток - це дуже круто. Але нам, як інженерам, треба не ганятись за хайпом, а розбиратись як воно працює та як це може потенційно вийти з ладу (як то все тестувати).

Як це працює: злам віддаленого доступу до Kia

#howitworks #security

Тестування непотрібне! Тим паче якесь там тестування безпеки!
А в результаті маємо можливість за лічені хвилини віддалено відкрити будь-який новий автомобіль Kia.

TL;DR - Як зламали?

Для того, шоб відкрити авто, на сервер надсилається POST запит з sessionId та VIN кодом машини. VIN отримати нескладно. А от як отримати sessionId?

1. Реєструємося як дилер та отримуємо sessionId
2. Шукаємо авто в базі по VIN коду
3. Модифікуємо доступ до авто для дилера
4. Додаємо мейл зловмисника для авто по VIN коду
5. Можемо відправляти запит на відкриття авто

Більше про вразливість у статті.

P.S. Вразливість вже закрили, тому й виклали цей приклад у вільний доступ

Automation Challenge

#automation

Ви хочете повноцінний проєкт з автоматизації у своєму портфоліо? Але не знаєте з чого почати?

Я знайшов цікавезний БЕЗПЛАТНИЙ варіант від Bas Dijkstra, як здобути ті важливі практичні навички з автоматизації тестування.

Йдемо на https://github.com/basdijkstra/a-test-automation-project, обираємо ту мову програмування, яка вам цікава - та виконуємо проєкт крок за кроком.

🤔Пародокс Тога (Або парадокс складності)

#theory

Сьогодні вівторок, а значить саме час ... поговорити про парадокси. (Жартую, немає ніякої привʼязки до дня тижня)

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

👉 Приклади

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

2. Спрощення задач також призводить до виникнення нових обовʼязків (та потреб). Ось, наприклад, додали нову HR систему, яка зробила перфоманс менеджмент та різні базові штуки майже автоматичними. Але тепер у HR зʼявилось багато вільного часу та нових обовʼязків - розвиток співробітників чи їх залучення. А це призведе до збільшених потреб до софту.

3. Соціальні мережі принесли нам можливості швидкої комунікації та обміну фото. Але чим далі, тим вони стають все складнішими та багатофункціональними. Тут тобі стрімінг, AR / VR, вбудовані маркетплейси (згадується нещодавний приклад Monobank).

4. Те ж саме з автоматизацією. Як тільки ви автоматизуєте базові тести, зʼявляться ще більше запитів на автоматизацію: а ось тут репорт, а ось тут CI, а тут ще 3-party перевірки треба, а потім мобілки, десктоп та якийсь IoT з блокчейном...

🤷‍♂️Ну то й що?

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

🔮The Future of Jobs Report 2023

#career #testing

Поки курси QA все ще росказують, що тестування це "швидко, легко та для будь-кого!", ситуація у світі вкрай протилежна.

Згідно з репортом Світового Економічного Форуму, робочі місця для тестувальників скоротяться на 15% до 2027 року. Разом із тим, інші інженерні направлення (software engineering, big data, AI, devops, blockchain) очікують ріст в 20 - 30 %.

Додатково, DORA report говорить про те, що високо-продуктивні команди мають метрику change lead time (час від коміту до деплою) на рівні менше одного дня. Маючи деплойменти кожного дня - їх просто нереально кожного разу тестувати руками.

🤷‍♂️То що це означає? Тестувальник перетвориться в девелопера?

Якщо коротко, то так, частково.

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

В деяких командах тестувальники вже мають тайтл - software engineer in test. Тобто по факту - це розробник, що спеціалізується на тестуванні. Наступний крок - коли таких людей просто зроблять software engineer. Просто задачі будуть різними. Хтось займається продуктовою розробкою, хтось - platform engineering, а хтось - інструментами та процесами якості.

‼️Що робити?

☑️поглиблювати технічні навички
☑️дивитись на якість та процеси більш цілісно
☑️вивчати інструменти розробки
☑️вчитись ефективно комунікувати результати та плани
☑️шукати ніші, суміжні із тестуванням (або ж той інжинірінг, який вам більше подобається)

Світ змінюється. То ж треба адаптуватись.

📝Про зберігання статей "на потім"

#reading

Я багато читаю. Як для щомісячного дайджесту статей, так і загалом по роботі.

Все й одразу прочитати не вийде. Особливо, коли статті чималенькі за розміром.
Тому треба тримати фокус. Єдине, що працює в такому випадку - це користуватись "Read It Later" функціями чи додатками. Про їх приховану силу писав якось Tiago Forte у своєму блозі.

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

Потім якийсь час я користувався вбудованою функцією Reading List від Google Chrome. Для початку вона досить непогана (Подібна функція є й в Safari). Але не вистачає папок, тегів та організації посилань.

Згодом я знайшов непоганий варіант - Omnivore. Він навіть міг сінхронізуватись із Obsidian. Але в цьому місяці цей додаток нажаль закривається. Тож треба шукати щось інше.

Які є варіанти?

👉 Instapaper
👉 Readwise
👉 Raindrop

Поки що я зупинився на Raindrop. Безкоштовної версії мені поки вистачає.

🤓З цікавих функцій Raindrop:

- Raindrop працює напряму з вашими закладками в браузері (По факту це "прокачаний" менеджер закладок)
- папки та теги для посилань
- можливість зберегти декілька відкритих вкладок одночасно
- читання статті прямо в мобільному застосунку
- пошук по закладкам прямо з пошукової стрічки
- якась сінхронізація із Obsidian (але самопальна)

Сподіваюся, що Raindrop допоможе мені навести лад із закладками у Chrome та нарешті їх читати.

Можливо, вам підійде більше Readwise - якщо ви хочете не тільки зберігати статті, але ще й читати та робити нотатки (highlights). Я роблю нотатки одразу в Obsidian.

А чим користуєтесь ви?