Понеділкового вечора всім!
Я до Вас із вижимкою, оскільки минулого тижня у нас було дві події у спільноті! Так співпало)))

Послухала про мобільне тестування, насправді там було нереально багато інформації, моя вижимка - це лише «крапля в морі»😅 і скажу, що це було цікаво!
Тому ловіть трішки інфи🥰 *👩🏼‍💻 Катерина Абзятова, «Challenges and Techniques in Mobile Testing»
💰*Монетизація завжди дуже важлива у мобільних додатках.

📌Є такі типи монетизації:
• Freemium - додаток безкоштовний, але якийсь функціонал платний.
• Advertisement- based - купа реклами, якщо заплатити то її не побачимо.
• Transaction- based - криптогаманці і тд., які заробляють за рахунок транзакцій.
• Fee based - не можна скачати, доки не заплатимо.
• Enterprise applications - банківські додатки, де ми не платимо, але організація заробляє.

❗️Дуже важливо розуміти, де замовник заробляє гроші. Адже цей функціонал має працювати найкраще❗️

📌Mobile device type:
• Basic phone.
• Feature phone.
• Smartphone.
• Tablets.
• Companion devices including wearables and some IoT devices.

👩🏼‍💻Типи додатків:
• Нативні - скачування додатка.
• Браузерні - аплікація в браузері, адаптований варіант.
☝🏼Варіанти:
- m(dot) site.
- Responsive.
- Adaptive.
- Progressive.
• Гібридні - веб- аплікація в оболонці нативної апки.

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

💡Додатки можуть бути pre- installed - людина купує телефон і він вже має цей додаток.

Тестування кожного з цих типів додатків може вимагати різного підходу. Параметри, які слід враховувати, включають:
• Різні типи пристроїв для підтримки.
• Функції датчика та пристрою, які будуть використовуватися.
• Доступність за різних мережевих умов.
• Можливість встановлення, сумісність, ефективність роботи та зручність використання.

📎Connection methods наших аппок:
• Never connected.
• Always connected.
• Partially connected.

⚡️ При тестуванні необхідно вимірювати температуру девайсів, різне положення екрану, використання батареї, куди ведуть нотіфікейшини, локація, hard & soft кнопки звуку, різні варіанти інпута, клавіатура, один або більше дотиків до екрану, жести, камера, QR коди, орієнтації екрану і тд.

❗️Режим «Не турбувати» - у ньому можуть бути великі проблеми. Ми не маємо відправляти повідомлення коли він ввімкнений, а коли ми вимкнули цей режим - повідомлення не мають сипатись спамом.

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

🚨І памʼятаємо: тестуємо в реальних умовах, не тільки в офісі з гарним інтернетом.А тепер поділіться, хто у нас тут тестує мобільні апки?)
😍 - я;
🤯 - не я;
❤️ - дяка за допис.

Привітик гайз!
Дописи, які я Вам обіцяла (про девчелендж та курс) майже готові, залишилось оформити і скоро вони будуть у Вас😌

А поки, повертаюсь у життя і даю Вам вижимку вчорашнього вебінару, який відвідала✍🏼
*👩🏼‍💻* Аня Красильник, «Конфлікт — це можливість»

✍🏼 Конфлікт - це не завжди погано.**

☝🏼Варто ознайомитись з «Моделю Такмана» про формування команд.
Адже часто буває так, що команди застрягають у стадії формування і не можуть вийти на стадію дійсно гарного перформансу.

📖 Конфлікт - це різниця в думках або перетин інтересів, яке призводить до необхідності домовлятись.

💫 Конфлікт буває:
• Конструктивним - переговори.
• Неконструктивним - активна/пасивна агресія.

🦾 Чиї потреби задовольняються - фундамент для стратегій вирішення конфліктів.

📌 Томас Кілман, 5 стратегій вирішення конфлікту:
• Суперництво
• Співпраця
• Компроміс
• Пристосування
• Уникання

❗️Найкращої стратегії немає - є та, яка доречна.

1️⃣ правило:
Обираємо стратегію, а не стратегія нас.

❔Чому ми несвідомо йдемо в уникненя або пристосування?
• Страх осуду
• Страх зіпсувати стосунки
• Сила звички

❔Чому ми несвідомо йдемо в суперництво?
• Страх невдачі, зради
• Сила звички

❔Коли доречно уникання?
• Якщо не несе цінності ні проблема ні стосунки
• Коли треба охолонути
• Коли обоє погоджуються що проблема не варта зусиль

❔Коли доречно пристосування?
• Інвестиція у відносини
• Заохочення людей бути ініціативними
• Довіра думці партнера більше ніж власній
• Дотримання субординації
• Адаптація до нових умов

❔Коли доречно суперництво?
• Коли немає часу на дискусії
• Коли потрібно впроваджувати непопулярні рішення

❔Коли доречний компроміс?
• Немає часу, але стосунки важливі

❔Коли доречна співпраця?
• Інтереси дуже важливі
• Шукаємо альтернативу
• Є багато часу на дослідження та пошук

📖 Типи поведінки у конфлікті:
• Пасивна - уникання пристосування
• Пасивно - агресивна - уникання пристосування, суперництво
• Агресивна - суперництво
• Асертивна - все

❗️Знайти асертивність це мистецтво.

🏋🏼Техніки асертивної поведінки:
• Я - висловлювання
• Техніка зламаного запису
• Техніка негативного підтвердження
• Техніка позитивного ствердження

2️⃣ правило:
Ми не можемо змінити співрозмовника, ми можемо впливати на власну поведінку.

3️⃣ правило:
Якщо ми залишаємось асертивними - співрозмовнику не залишається вибору, як врахувати нашу позицію.

❔Хто керує конфліктом?
• Той хто усвідомлює мету та стратегію.
• Розуміє ситуацію на різних рівнях.
• Може створити атмосферу довіри.

🦾 Знаходження та задоволення емоційних потреб дає змогу вирішити майже будь-який конфлікт.Вебінар був дуже цікавий і подача інформації у Анни мені дуже імпонувала💫

А як Ви вважаєте, конфлікти корисні для нас?
👍🏼 - так.
👎🏼 - ні.
❤️ - дяка за допис.

⬇️ продовження вижимок з QA Day ⬇️

👩🏼‍💻 Анастасія Чудовська, «Переїзд з моноліту на мікросервіси з точки зору QA»

📌Моноліт - весь додаток єдине ціле, легко розробляти на початках, але чим більше стає додаток, тим важче підтримувати, баг фікс може поламати всю систему.

➕Плюси моноліту: легке оновлення, цілісність коду, просте тестування.
➖Мінуси моноліту: довге розгортання, пошук проблем, довга регресія.

📌Мікросервіси - додаток декомпозований на незалежні сервіси, розробляти, оновлювати та масштабувати легше.

➕Плюси мікросервісів: розпаралелювання, передбачуваність, швидкі релізи.
➖Мінуси мікросервісів: інтеграції, контроль даних, АРІ та автоматизація.

‼️Shift left не просто рекомендація, а скоріше обовʼязкова практика у світі мікросервісів.

📄Документація - наш найкращий друг.
• Документуємо все.
• Верифікуємо.
• Оновлюємо текст кейси.
• Залучення до мітингів.

💡Правила деплою:
• Жоден тікет не потрапляє на середовище без згоди QA.
• Регулярні зустрічі для обговорення очікуваних змін.
• Вчимось працювати з логами.

🦾Міграція даних - виклики:
• Зміни у зберіганні даних.
• Цілісність точність на повнота даних.
• Консистентність даних між системами.

✍🏼Міграція даних - тестування:
• Документувати структуру даних.
• Логи для відстеження помилок.
• Контроль доступу до чутливих даних.
• Синхронізація та відновлення.
• Час міграції на тестових середовищах.

👩🏼‍💻 Євген Гайдай, «Виділена команда автоматизації тестування»

❔В чому перевага структури коли AQA всередині команди?
• AQA завжди доступний для ліда, ПМ чи інших.
• AQA дуже добре знайомий з функціоналом.
• Зрозуміла ясна та керована структура команди.

❔В чому недоліки структури коли AQA всередині команди?
• Важко уніфікувати підхід до автоматизації та стек технологій в рамках компанії.
• Проблема перерозподілу ресурсів.
• 1 AQA - 1 команда.

❔В чому переваги структури відділеної AQA команди?
• Відсутність прямої привʼязки AQA до команди.
• Можливість залучити ресурси на критичні напрями.
• Уніфікація підходів та стеку технологій.

❔В чому недоліки структури відділеної AQA команди?
• Важко одночасно бути в контексті всього.
• Велика кількість швидких перемикань уваги.
• Можливість недостатку ресурсу у потрібний момент.

❔Як витримувати навантаження декількох команд?
• CI/CD рішення має бути простим, зручним та надійним.
• AQA не тестують, а надають інструмент для тестування.
• Скоуп автоматизації формують продуктові QA.

❌Можливі помилки:
• Бажання, щоб AQA були додатковими тестерами в командах.
• Відсутність залучення мануального QA в роботу з автоматизацією.
• Відсутність контролю за процесом автоматизації та тестування.

Отакий виходить нотатник Аміни😂 вибачте! Я зупинюсь)))

❔Як Вам інфа? Знайшли щось собі корисне?
⚡️ - так;
🥱 - ні;
❤️ - сердечко за старання.

Привітульки!
Тиждень ще не встиг початись, а вже майже його кінець… то ж завершуємо справи і готуємось до вихідних!
Поки Ви завершуєте, я вже повністю додивилась доповіді з QA Day і несу Вам останні вижимки🥳
Насолоджуйтесь!

👩🏼‍💻 Ганна Каплун, «Тестування на основі персон: ідея, інструменти, приклади»

💡Техніка прийшла до нас від UX дизайнерів.
📖 Ідея цієї техніки полягає у тому, щоб спробувати поставити себе на місце користувача.

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

👤 Персона - це конкретний користувач якого ми вигадали, але для кого ми маємо певну інформацію.
Цей користувач є частиною нашої цільової аудиторії.
✍🏼 Наприклад: імʼя, позиція, скільки років, з якими проблемами стикається і тд.

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

⬛️ Чорний ящик побудований на даних, а технік на основі поведінки мало.

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

❔Які питання собі задавати?
• Хто це користувач нашого продукту?
• Яка у нього проблема?
• Як вони його використовують?

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

📜 Характеристики:
• Вік
• Робота , роль
• Доступність
• Геолокація
• Патерни поведінки
• Цілі
• Болючі поінти
• Все що завгодно, що може повпливати на використання продукту

✅Хороші практики:
• Фокусуємось на тому, що важливо.
• Дізнаємось нашого юзера.

❌Погані практика:
• Забути про техніки тест дизайну.
• Фокусуватись тільки на едж кейсах.

👩🏼‍💻 Юрій Малий, «QA метрики в процесі SDLC»

✔️ QA бере участь у всіх етапах SDLC.

«• Що у нас там із проектом?
• Як виміряти?
• Що означають ці цифирки?
• Як було раніше? І т.д. І т.п....»
Можна привентивно задати ці питання собі, вчасно їх задавши у нас буде більше часу на аналіз, підготовку і гарний результат.

❔Менеджмент задає ці питання бо вони не розуміють, що там відбувається - їм недостатньо прозорості.

💫 Забезпечити прозорість - ми можемо вибором правильних метрик.

📜 Приклад метрик:
• Defect quantity
• Fault density
• Test cases
• Pass rate
• Quality coverage rate
• Logged time metrics
• Scrum metrics

⬇️ внизу будуть дві останні ⬇️

Як і обіцяла - одразу даю Вам частину другу! Аби не затримувати…

👩🏼‍💻 Євген Толчинський, «QA метрики і як їх хакнути»

📌Метрики потрібні щоб оцінити якісь тестування.
Потрібні вони менеджерам, лідам, та команді.

💫Для менеджерів:
• Репортінг.
• КРІ.
• Оцінка ситуації.

💫Для лідів:
• Репортінг.
• Оцінка ситуації.
• Менеджмент команди.

💫Для команди:
• Репортінг.
• Розуміння, що я роблю.
• Оцінка ситуації.

Далі ми розглядали метрики, які збирають для того, щоб відстежувати якість продукту! Там були скріни, тому їх «вижати» не можу😅

👩🏼‍💻 Артем Овчаренко, «Promises від А до Я: Асинхронність, колбеки та пастки масивів»

🙏🏼Більше знаєш, легше працюєш, отримуєш більше грошей.

📌Promises - виникли для того, шоб працювати з асинхронністю.

📖Асинхронність - це архітектурне рішення, яке не блокує виконання коду.
Паралельно може виконуватись декілька дій.

📌 Це взаємодія з іншими елементами на сторінці при тому, що всі інші доступні.

💡Неблокуюча комунікація.

📌Await і async - це проміси.

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

💡Call back - функція, яка передана як аргумент в іншу функцію.
Наприклад:
Йдемо в магазин, в магазині дзвонимо і питаємо що купити.

👩🏼‍💻 Юрій Малий, «Впровадження системного процесу QA в великій компанії для забезпечення якості IT-продуктів на кожному етапі»

📌 Переваги тестування для бізнесу та цінність для компанії:
• Зменшення витрат на підтримку та оновлення.
• QA допомагає виявити дефекти на ранніх етапах розробки.
• Підвищення продуктивності.
• Покращення якості обслуговування клієнтів.

💫 Основний бізнес будь-якої компанії - створювати додаткову цінність.

📌Для нас - це гроші
📌Для клієнта - якісний продукт

❔З якими питаннями звертаються до IT:
• Інструмент не працює.
• ІТ-рішення працює погано.
• Клієнти/користувачі чимось не задоволені.
• Інструмента взагалі немає.

📌Основні причини:
• Неправильно зробили вимоги.
• Неправильно зафіксували вимоги.
• Перед впровадженням продукту не перевірили чи все працює.

💡***Згідно з дослідженнями, приблизно 60% усіх помилок у проектах розробки системи виникають на етапі розробки вимог.
Чим пізніше проекті розробки виправляється недолік у вимогах, тим вищі витрати, повʼязані з його вправленням.

❔Як Вам інформація? Яка з вижимок сподобалась найбільше?
Діліться!❤️***

Гарної суботи гайз!
Памʼятаєте ми говорили про стрес?
Помітила, що це дуже гаряча тема, зокрема серед мого оточення.
Тож подумала, що варто винести її на ширшу аудиторію!

Запрошую Вас у топік DOU до обговорення❤️

Хелоууу!
Вчора як і завжди відвідала вебінар, тож біжу давати Вам вижимку?

*??‍?*Анна Куркотова: Проблемні питання комунікацій у сучасному ІТ-світі

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

?️Види комунікацій:
1️⃣Вербальна комунікація:
Усна: Живе спілкування, телефонні розмови, мітінги, тощо.
Письмова: Чати, імейли, листи, звіти, тощо.
2️⃣Невербальна комунікація:
Жести, мімка, пози, рухи тіла, інтонація, тон, вираження.
3️⃣Електронна комунікація:
Соціальні мережі, месенджери, конференції, діаграми, борди, тощо.

‼️Важливість комунікації:
• Забезпечує чітке розуміння ролей і обовʼязків кожного члена команди.
• Правильна комунікація допомагає уникнути дублювання зусиль.
• Допомагає зменшувати або уникати конфліктів.
• Допомагає розуміти потреби та вимоги клієнтів.
• Регулярна комунікація дозволяє швидко реагувати на зміни в проєкті.
• Хороша та постійна комунікація допомагає відслідковувати прогрес і вчасно виявляти проблеми.
• Результатом хорошої комунікації є якісна робота/продукт.
• Правильна комунікація допомагає створювати якісну, легку та прозору документацію проєкту.
• Звіти дозволяють відслідковувати прогрес і вчасно виявляти проблеми.

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

Ми говорили про внутрішню комунікацію.

❌Типові помилки при спілкуванні:
• Нечітке формулювання думок
• Недостатнє слухання
• Перебивання
• Паразити в мовленні
• Надмірно технічна мова
• Неврахувування невербальних сигналів
• Емоційні реакції
• Монологізація розмови
• Відсутність контексту

❗️Комунікаційні проблеми у керівництва:
• Невизначенність та неясність
• Неефективне слухання
• Невідповідний стиль спілкування
• Недостатнє делегування
• Відсутність регулярного спілкування
• Непрозорість у прийнятті рішень
• Недостатній зворотній звʼязок
• Одностороння комунікація
• Неефективне управління конфліктами
• Недостатнє визнання та мотивація
• Перевантаження інформацією
• Недовіра та страх перед керівником

✅Загальні рекомендації по покращенню комунікації у команді:
Регулярні зустрічі
Канали комунікації
Навчання комунікації
Прозорість і відкритість
Система винагород

?Рекомендована література:
• Сім звичок надзвичайно ефективних людей, Стівен Кові.
• Радикальна відкритість, Кім Скотт.
• Ніколи не їжте наодинці, Кейт Ферацці, Тал Рез.
• Як здобувати друзів і виливати на людей, Дейл Карнегі
• Емоційний інтелект, Деніел Гоулман.
• Я чую вас наскрізь, Майкл Соренсен.
• Спілкування без насильства, Маршалл Розенберг.

Також ми пограли у дуже цікаву гру! Це було прям круто, олівці і митці (хто знає той знає)?

Всім гарного вечора і комунікуйте правильно??

❔Чому тестування важливе? Або як і хто впливає на якість?Сьогодні хотіла б навести Вам приклади, коли несправності системи призвели до летальних випадків.

?Ці історії я розповідаю на своєму курсі, адже кожен хто входить в професію тестування повинен розуміти, що це не просто «кнопочки тикати» як хтось там сказав, це дійсно важлива діяльність від якої часто залежать й життя.
І тільки в кооперації з усіма членами команди, ми можемо уникнути таких ситуацій.

?Трагедія з медичним обладнанням Therac-25.

Лікувальні апарати Therac-25, які використовувалися для променевої терапії, мали програмні дефекти, які призводили до передозування радіації.
З червня 1985 року до січня 1987 року цей апарат став причиною шести передозувань радіації (деякі пацієнти отримали дози в десятки тисяч рад). Щонайменше двоє померли безпосередньо від передозувань.

?Трагедія з літаком Boeing 737 MAX.

Внаслідок дефектів у програмному забезпеченні системи автоматичного управління польотом (MCAS), два літаки Boeing 737 MAX зазнали катастрофи, сумарно загинуло 346 осіб.
Літак Boeing 737 MAX розбився у жовтні 2018 року в Індонезії. Тоді загинуло 189 людей. Лайнер цієї ж моделі впав в Ефіопії у березні 2019 року. Унаслідок авіатрощі загинуло 157 людей, які були на борту.
У березні 2019 року експлуатацію Boeing 737 MAX заборонили у всьому світі. За даними слідства, причина обох авіатрощ – помилка у програмному забезпеченні.

?Аварія медичного обладнання в 2017 році.

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

?Аварія в новому терміналі британського аеропорту Хітроу.

У 2008 році в новому терміналі британського аеропорту Хітроу встановили суперсучасну систему контролю багажу, призначену для перевезення безлічі вантажів.
У підсумку, в день відкриття терміналу 42000 валіз загубилися, бо не полетіли разом зі своїми господарями. Було скасовано понад 500 авіарейсів.
А все тому, що нова система не впоралася з реальними сценаріями, які не були перевірені під час тестування (наприклад, зняття багажу зі стрічки вручну ламало програму, і вона вимикалася).

?Таких історій, на жаль, безліч. Проте це життя, і як ми памʼятаємо - вичерпне тестування неможливе.
І цей допис не про те, щоб повісити відповідальність за тестування лише на тестувальника, ні.

?Цей допис про те, що відповідати за якісь продукту мають ВСІ.
Від розробника який пише код - до дизайнера, який малює макети.

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

?Чим швидше у Вас в команді зʼявиться ця думка - тим якіснішим ставатиме Ваш продукт.Сьогодні такі думки…всім цьом?