Події які ви не можете передбачити

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

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

Вивчення продукту, це процес активного реагування, на виялення ризиків і пошуку правильних відповідей. Візьмемо наприклад Google і Microsoft. Ці компанії щоденно виконують мільйони автоматизованих тест кейсів, але й досі отримують безкінечні жалоби від користувачів на дефекти, які тестувальники ніколи не враховували. Ніякий продукт, не застрахований від помилок, коли він знаходиться у руках користувачів.

Я вже розбирав декілька методів дослідницького тестування, ви можете знайти їх використовуючи тег #exploratorytesting

про який би хотіли дізнатись більше у наступній статті?

- Exploratory Testing Tours
- Mind Mapping
- Brainstorming

Пишіть у коментарях і на днях розберемо 😉

Test Estimation на практиці🔥

Всім привіт, наступного вівторка, пропоную вам зібратися на мітап на тему оцінювання тестування.

Цього разу ми проведемо його у парі з експертом у темі QA з досвідом 10+ років Артемом Григоренко

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

І також, додатково розглянемо ряд питань:

Хто повинен цим займатися, вся команда чи QA Lead?
Як оцінювати тест активності на проекті?
Які інструменти використовувати для оцінювання?
На що потрібно звернути увагу при оцінці?
Як покращити результати оцінювання?

Збираємось 20.12 о 19:00

Вартість, добровільний донат на ЗСУ від 10 гривень😉

https://send.monobank.ua/jar/9pYvAJtaaX

Приєднуйтесь, давайте допомагати ЗСУ та навчатися разом🔥

Пишіть + у коментарях, хто бажає доєднатися

Доречі, Артем також веде свій канал в телеграм і ділиться своїми нотатками https://news.1rj.ru/str/a_grygorenko

Гайз 👋

Нещодавно ви просили, щоб із дослідницького тестування я розібрав вам Mind Mapping.

Я записав невеличкий але максимально інформативний відос у якому розібрав, як ефективно використовувати Mind Map у вашій роботі.

15 хвилин користі для вас😉

Пишіть у коментарях, як часто і де, використовуєте цей інструмент?

https://www.loom.com/share/f6b2876bca124611b5b7590391464ce8

Гайз👋

Нагадую, що вже у вівторок ми з вами збираємось, щоб розібрати Test Estimation на практиці🔥

Спікери на мітапі: Роман Якимчук та Артем Григоренко - сумарний досвід роботи у QA понад 20 років 😎

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

Починаємо о 19:00

Умови участі: donation на ЗСУ 🇺🇦

Давайте навчатися разом😉

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

Але через й##%ну рсню в мене вже другу добу немає світла. Вирішили записати вам ефір вдвох.

Як на мене вийшло дуже круто! Можете переглянути це відео тут
https://youtu.be/lM1rjaqbt0A

І не забувайте донатити, ми збираємося всі гроші передати на допомогу нашим воїнам 🙏🏻

https://send.monobank.ua/jar/9pYvAJtaaX

Друзі, хто вже подивився, накидайте коментів, як вам?

Всім привіт,
Дякую за ваші донати!

Всі виручені кошти були направлені для 46-Ї бригади десантно-штурмових військ, вони зараз під Бахмутом. Попросили докупити акумуляторів до рацій, ми долучилися до збору

Слава Українським воїнам 🇺🇦

Одного разу 👉

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

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

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

Це звичайно вимагало трохи більше часу, але в перспективі ми отримували більш якісний продукт і не приходилось заводити 100500 багів і потім перепровіряти їх після фіксів, що добряче економило нам час.

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

А які ви прийомчики використовуєте для підвищення якості своїх продуктів, діліться в коментах 👇

Друзі, вітаю вас із наступаючими новорічними святами.

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

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

Наступний рік точно буде кращим, а зараз вже час потроху закінчувати робочі справи і приділити час собі та близьким 😉

Всіх з Новим Роком! І нехай буде перемога 🇺🇦

Всім привіт👋

Потроху починає закінчуватись олів'є і більшість починає входити у активну робочу фазу 😎

Написав вам тут невеличку статтю, як ефективно застосовувати техніку Brain Storming на ваших проектах, щоб досягати більш кращих результатів у роботі в 2023-му.

https://telegra.ph/Mozkovij-shturm-01-02

Як прочитаете, діліться у коментарях як часто використовуєте дану техніку на проекті і чи застосовуєте її взагалі 😉

#QualityAssurance #brainstorming #exploratorytesting

Воркшоп по Brain Storming

Гайз, у цю суботу, пропоную вам зібратися та разом попрактикуватися у використанні техніки мозкового штурму.

Як це буде відбуватися:

▪️ Ми виберемо напрямок наших проектів;
▪️ Кожен випише ряд ідей фіч, які там будуть використовуватись;
▪️ Інші учасники нагенерують ідей по кожному з проектів;
▪️ Зробимо групування та фільтрацію ідей;
▪️ Кожен представить свій проект після брейнштормінгу.

На вас чекає півтори години цікавої практики, де ми будемо працювати у групі та ефективно використовувати мозковий штурм.

Вартість: 300 грн💰

Кому цікаво потрапити на воркшоп, пишіть + у коментарях🔥

А як вам працюється з нового року? 😂

Чому важливо розуміти сценарії користування?

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

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

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

Чому варто розглядати сценарії користування?

В традиційних вимогах до програмного забезпечення часто функціонал описується без контексту:
«Система повинна зберігати результати транзакцій оплат в системі трекінгу банківських операцій»

Відсутність контексту створює місце для двозначності і виникає багато додаткових запитань:

⁃ Коли відбувається ця подія?
⁃ Чи важливий порядок запису відносно інших транзакцій?
⁃ Хто ініціює подію?
⁃ Що відбувається, коли система трекінгу банківських операцій недоступна?

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

Переваги моделювання користувацьких сценаріїв

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

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

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

#QualityAssurance #usecases

Привіт, натрапив на такий чекліст
The Test Automation Implementation Check List

59 Questions to Ask before you Implement your
Software Test Automation solution

Implementing software test automation solutions is not easy. There are many pitfalls and lots of issues that need to be anticipated. This guide presents 59 questions that you should consider before you go any further with your Software Test Automation project.
https://www.testmanagement.com/resources-pdf/The-Check-List.pdf

Нехай буде, може кому пригодиться 😉

З чого все починалось, сьогодні хочу розповісти історію того як я попав в ІТ

В далекому 2011 році я закінчував 5й курс університету і вирішив знайти якусь роботу. Вчився я на інженера механіка і спеціалізація була пов’язана з інструментальним виробництвом. Так як я добре працював з 3D програмами і міг змоделювати інструменти, мій дипломний керівник підкинув мені халтуру. Його другу потрібно було спроектувати якусь деталь в 3D та зробити креслення. Я приїхав в офіс до того чєліка, отримав завдання і через кілька днів знов приїхав з готовим рішенням завдання.

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

Я погодився, думаю чому б не спробувати, це хоч якось було пов’язано з спеціальністю. Там я швидко навчився продавати та відгружати товар по заводам. Також цікавим моментом роботи були відрядження, так я побував в Маріуполі на Азовсталі, Металургічному комбінаті Ілліча, в Краматорську, Горлівці, Дружківці, Лисичанську та багатьох інших заводах України.

Я вмів чудово домовлятися і через 4 місяці роботи став кращим продавцем у компанії, після чого мені запропонували позицію керівника відділу продажів. Але якраз ця робота мені не дуже подобалась, багато бюрократії: табличок, звітів, контролю, планів і т. д. За цим всім я все менше перестав займатись тим що мені подобалось, а саме продавати.

Через деякий час я вигорів і мені нічого не хотілося робити на тій роботі і мій старший брат запропонував мені повчитися на тестувальника і перейти на нову роботу. Так за 3 місяці навчання і практики, яку підкидав мені брат, я пішов на свою першу роботу Junior QA.

Цікаво, а що підштовхнуло вас піти в IT?

На днях я писав пост про важливість розуміння сценаріїв користування

Вирішив також записати для вас коротеньке відео з прикладами Use Cases. Тому ласкаво прошу до перегляду
https://youtu.be/BUmK2A8xCkU

Що робити коли часу мало, а тестування забагато?

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

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

◼️ В першу чергу, приоритезувати тести згідно бізнес та юзер функціональності. Визначте найдорожчі фічі в продукті та починайте з них і далі по приоритету. Щодо юзер кейсів, необхідно старатися розписувати end to end сценарії та покривати ті кейси, які б на вашу думку використовувались найчастіше

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

Замість покрокового заповнення форми покупки товару і опису кожного поля та даних картки можна написати так: «Заповнюємо клієнтські дані та вводимо валідні дані карти і купуємо товар» і не забуваєм додати очікуваний результат. Це хоча б трохи зекономить ваш час!

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

◽️ Майнд мапа
Дозволяє тримати весь функціонал в фокусі і по ній можна рухатись та перевіряти кожну фічу поступово! І візуальна інформація швидше обробляється нашим мозком

◼️ Мозковий штурм
Ну і для того, щоб вистачало часу на тестування важливо добре продумувати всі ситуації разом з усією командою, ще перед початком імплементації функціональних вимог. Для цього найкраще підійде техніка брейнштормінгу за допомогою якої ваша команда продумає всі кейси та відповідно реалізує функціонал запревентивши виникнення багів!

А що ви робите, якщо бачите що дедлайни підгорають?

Всім привіт 😎

У цю неділю хочу провести для вас корисний вебінар, на тему

Що потрібно робити перед стартом будь якого нового проекту?

Без зайвої води, розберемо із вами, що саме треба вміти використовувати тестувальнику, перед початком роботи.

Поговоримо про:

▪️Аналіз вимог;
▪️Декомпозицію;
▪️Дослідження подібних продуктів;
▪️Тест менеджмент;
▪️Тест репорти.

Після вебінару ви зможете:

▫️самостійно стартувати тестування на проекті;
▫️налаштовувати систему тест менеджменту;
▫️ будете знати коли яку тестову документацію краще використовувати;
▫️ досліджувати та аналізувати продукт;
▫️ робити звіти по виконаній роботі.

Вартість: free або donation на ЗСУ за вашим бажанням
Банка https://send.monobank.ua/jar/9tUU9eQi2x

Коли: у Неділю 22 січня об 11:30. (Раптом що, запис буде)

Пишіть "➕" під дописом, хто бажає доєднатися, буде точно корисно всім 😉

Всім привіт, бажаю вам гарних вихідних!

Нагадую що вже завтра об 11:30 ми зустрічаємось. Трошки поспілкуємось про те, що потрібно знати та розуміти при старті тестування на новому проекті.

Зверху в каналі буде закріплена трансляція, тому приєднуйтесь!

І не забувайте донатити, якщо є така можливість, хочеться все ж таки наблизити нашу перемогу разом! 🇺🇦