Модель тестування: imagination / implementation

#testing

Минулого тижня побачив одну цікаву модель того, що таке тестування. ЇЇ автор - James Lyndsay.

Вона складається з двох кіл.

Ліве коло - то уява (imagination) - або те, що ми ХОЧЕМО мати в продукті. Сюди відносяться вимоги, бажання, дискусії та негласні домовленості.

Праве коло - то виконання (implementation) - або те, що ми МАЄМО в продукті. Тобто код, дані, інфраструктура.

Ціль тестування - взнати як можна більше про те, що входить в кожне із цих кіл.

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

Вгадайте, де на цій діаграмі можна позначити автоматизоване тестування?

🤖 Imagination / Implementation - де тут автотести?

#testing

Продовжуючи минулий пост про модель тестування.

Ось, який варіант моделі тестування пропонує Mark Winteringham в книзі "Testing Web APIs". Тут автоматизаовані тести знаходяться якраз на перетині між тим "як воно повинно працювати" та "як воно реально працює".

Я також згоден, що саме це питання закривають автоматизовані тести. Перевірити те, що є (та чи не змінилось те, що було із новою версією).

Shifting E2E Testing Left at Uber

#testing #automation

Сьогодні пропоную почитати про те, як Uber користується BITS (backend integration testing strategy). Окремо, дуже цікаво подивитись, як Uber вирішує питання підтримки тестів, їхньої стабільності та швидкості.

📹Співбесіда на Junior QA

#testing #interview

Вчора, на запрошення Олекси з каналу QA Україна, я проводив публічну тренувальну співбесіду для кандидата на рівень Junior Manual QA.

Для чого проходити такі тренувальні співбесіди?

- дізнатись свої сильні та слабкі сторони
- отримати поради куди рухатись далі, що вчити та як практикувати знання
- отримати досвід проходження інтервʼю

❗️Я проводжу подібні співбесіди (не публічні), разом із розгорнутим зворотнім звʼязком, разом із ревʼю резюме.

Якщо у вас є бажання пройти подібну співбесіду - пишіть мені в DM. ✍️

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

#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. Вразливість вже закрили, тому й виклали цей приклад у вільний доступ