#learnit #istqb
Чому починаємо із Foundation Level Certified Tester? Усе дуже просто - ви не матимете змогу здати будь-який інший екзамен без наявності FLCT.
📋 Формат:
40 питань на 60хв + 15хв (25%) для не носіїв рідної мови. Прохідний рівень - 26 правильних відповідей (65%).
Екзамен містить питання теоретичного складу характеру із невеличкими задачками з технік тест дизайну.
🔍 Основні джерела інформації:
Syllabus 2018 - посібник, на якому базуються питання екзамену;
Glossary - глосарій термінів та визначень.
⚠️ Наші рекомендації для успішної підготовки:
- читаємо вдумливо Syllabus, мінімум 2 рази,
- шукаємо терміни у Glossary,
- проходимо тестові екзамени з мережі (пам'ятаємо, що у них можуть міститись помилки).
📚 Недостатньо? Тоді необхідно прочитати одну з книг:
- Foundations of Software Testing ISTQB Certification
- A Study Guide to the ISTQB® Foundation Level 2018 Syllabus
- Software Testing Foundations
Попередні версії книг можна знайти у вільному доступі, вони також підійдуть.
🧐 А ви сертифіковані?
Чому починаємо із Foundation Level Certified Tester? Усе дуже просто - ви не матимете змогу здати будь-який інший екзамен без наявності FLCT.
📋 Формат:
40 питань на 60хв + 15хв (25%) для не носіїв рідної мови. Прохідний рівень - 26 правильних відповідей (65%).
Екзамен містить питання теоретичного складу характеру із невеличкими задачками з технік тест дизайну.
🔍 Основні джерела інформації:
Syllabus 2018 - посібник, на якому базуються питання екзамену;
Glossary - глосарій термінів та визначень.
⚠️ Наші рекомендації для успішної підготовки:
- читаємо вдумливо Syllabus, мінімум 2 рази,
- шукаємо терміни у Glossary,
- проходимо тестові екзамени з мережі (пам'ятаємо, що у них можуть міститись помилки).
📚 Недостатньо? Тоді необхідно прочитати одну з книг:
- Foundations of Software Testing ISTQB Certification
- A Study Guide to the ISTQB® Foundation Level 2018 Syllabus
- Software Testing Foundations
Попередні версії книг можна знайти у вільному доступі, вони також підійдуть.
🧐 А ви сертифіковані?
ISTQB та азартні ігри 😱
#learnit #istqb
Вітаю друзі! Нещодавно вирішив перечитати деякі визначення в словнику ISTQB і передивитись Syllabus'и (не покидаю надію дочитати цього року книжку та здати екзамен на ISTQB Expert 🤓. Напишіть, чи вам цікаво дізнатись, що ж має знати експерт, може це мене замотивує!). Так от, я вражений, наскільки активно розвивається організація та скільки спеціальностей вони додали. Раніше все було просто:
➡️ Foundation (базовий) ➡️ 3 Advanced (менеджер / аналітик / технічний аналітик) ➡️ Expert.
Зараз ціле дерево, очі розбігаються! На Foundation рівні 8 спеціалізацій, окрім базової!
🏃♂️ Agile tester
✅ Acceptance testing
🗜 Performance testing
📱 Mobile application testing
🎲 Gambling industry tester (азартні ігри, Карл!)
🚗 Automotive software tester
🎀 Usability testing
🔬 Model-based tester
Хочу продивитись усі, напишіть, чи вам таке цікаво, поділюсь деталями. Особливо про азартні ігри (в мене не бомбить 😄)
#learnit #istqb
Вітаю друзі! Нещодавно вирішив перечитати деякі визначення в словнику ISTQB і передивитись Syllabus'и (не покидаю надію дочитати цього року книжку та здати екзамен на ISTQB Expert 🤓. Напишіть, чи вам цікаво дізнатись, що ж має знати експерт, може це мене замотивує!). Так от, я вражений, наскільки активно розвивається організація та скільки спеціальностей вони додали. Раніше все було просто:
➡️ Foundation (базовий) ➡️ 3 Advanced (менеджер / аналітик / технічний аналітик) ➡️ Expert.
Зараз ціле дерево, очі розбігаються! На Foundation рівні 8 спеціалізацій, окрім базової!
🏃♂️ Agile tester
✅ Acceptance testing
🗜 Performance testing
📱 Mobile application testing
🎲 Gambling industry tester (азартні ігри, Карл!)
🚗 Automotive software tester
🎀 Usability testing
🔬 Model-based tester
Хочу продивитись усі, напишіть, чи вам таке цікаво, поділюсь деталями. Особливо про азартні ігри (в мене не бомбить 😄)
🎓 ISTQB CTFL
#istqb
Почався черговий курс із підготовки наших колег до здачі сертифікації ISTQB CTFL. Якщо вам цікаво пройти даний курс в форматі коротких телеграм-постів присвячених кожній із 6 глав Syllabus'a з корисними посиланнями - голосуйте та пишіть.
#istqb
Почався черговий курс із підготовки наших колег до здачі сертифікації ISTQB CTFL. Якщо вам цікаво пройти даний курс в форматі коротких телеграм-постів присвячених кожній із 6 глав Syllabus'a з корисними посиланнями - голосуйте та пишіть.
CTFL 0. Intro
#istqb
Доброго ранку! Оскільки попередній мессидж пробудив неабияку зацікавленість, сьогодні публікуємо перелік рекомендованих матеріалів в рамках підготовки.
1️⃣ ISTQB CTFL Syllabus 2018 V3.1 - теоретична база, обов'язкова для прочитання. Скачати можна з офіційного сайту організації.
Там же знайдете корисні матеріали про структуру та правила здачі екзамену, а також мок-тести, що максимально наближені до бойових.
2️⃣ ISTQB Glossary - усі keywords, що винесені на початок кожної глави Syllabus'а потрібно знати та розуміти, фактично половина питань (20/40) із екзамену на визначення та порівняння. У словнику також шукайте усі незрозумілі вам терміни, що зустрінете по тексту Syllabus'а.
3️⃣ Як щодо книг? Rex Black Foundations of Software Testing - чудова книга для підготовки, враховуючи, що в Syllabus'і не усе детально висвітлено. На жаль, 4-го видання книги у вільному доступі немає, а коштує вона чимало, тому рекомендую 3-тє видання (по версії Syllabus 2011) - pdf вільно гуляє на просторах інтернету.
4️⃣ Чудова стаття (варто написати свою 🤔), присвячена підготовці, містить низку безкоштовних тестів.
5️⃣ Сайт із тестовими завданнями для практики.
6️⃣ На жаль, дійсно хороших мобільних додатків не виявлено, зверніть увагу на - Android & iOS.
Загальний підхід до підготовки:
✅ читаєте главу Syllabus'а, вивчаєте термінологію,
✅ вирішуєте тести (із книги, сайту, додатку) з фіксованим часом,
✅ переходите до наступної глави і тд,
✅ вкінці проходите мок-екзамени,
✅ перед здачею ще раз прочитуєте Syllabus.
Якщо у вас є хороші матеріали для підготовки - діліться у коментарях або через feedback.
#istqb
Доброго ранку! Оскільки попередній мессидж пробудив неабияку зацікавленість, сьогодні публікуємо перелік рекомендованих матеріалів в рамках підготовки.
1️⃣ ISTQB CTFL Syllabus 2018 V3.1 - теоретична база, обов'язкова для прочитання. Скачати можна з офіційного сайту організації.
Там же знайдете корисні матеріали про структуру та правила здачі екзамену, а також мок-тести, що максимально наближені до бойових.
2️⃣ ISTQB Glossary - усі keywords, що винесені на початок кожної глави Syllabus'а потрібно знати та розуміти, фактично половина питань (20/40) із екзамену на визначення та порівняння. У словнику також шукайте усі незрозумілі вам терміни, що зустрінете по тексту Syllabus'а.
3️⃣ Як щодо книг? Rex Black Foundations of Software Testing - чудова книга для підготовки, враховуючи, що в Syllabus'і не усе детально висвітлено. На жаль, 4-го видання книги у вільному доступі немає, а коштує вона чимало, тому рекомендую 3-тє видання (по версії Syllabus 2011) - pdf вільно гуляє на просторах інтернету.
4️⃣ Чудова стаття (варто написати свою 🤔), присвячена підготовці, містить низку безкоштовних тестів.
5️⃣ Сайт із тестовими завданнями для практики.
6️⃣ На жаль, дійсно хороших мобільних додатків не виявлено, зверніть увагу на - Android & iOS.
Загальний підхід до підготовки:
✅ читаєте главу Syllabus'а, вивчаєте термінологію,
✅ вирішуєте тести (із книги, сайту, додатку) з фіксованим часом,
✅ переходите до наступної глави і тд,
✅ вкінці проходите мок-екзамени,
✅ перед здачею ще раз прочитуєте Syllabus.
Якщо у вас є хороші матеріали для підготовки - діліться у коментарях або через feedback.
CTFL 1. Fundamentals of Testing
#istqb
Доброго дня!
Курс триває, а отже пора і ділитись інформацією 📚
Перша глава Syllabus'у присвячена основам тестування - що це є, навіщо та яка користь від нього.
Ключові моменти, які слід знати:
✅ 20% питань екзамену (8/40) присвячені цій главі.
✅ Testing vs debugging - чітко розумійте різницю між цими процесами.
✅ Test objectives - вмійте сформулювати та виокремити цілі тестування.
✅ QA != QC - якщо тестування є частиною QC, то QA - це дещо інший звір.
✅ ISO25010 - ознайомтесь із цим стандартом (раніше ми писали про нього).
✅ Чітко орієнтуйтесь та розумійте різницю між error, mistake, fault, bug, defect, failure.
✅ 7 testing principles - обов'язково буде питання присвячене якійсь із парадигм.
✅ Test process - потрібно знати фундаментальні етапи процесу тестування, їх характеристики та активності, а також які work products виникають на кожному з етапів і як вони між собою пов'язані.
✅ Розумійте людські та психологічні фактори тестування в розрізі процесу розробки ПЗ.
Надіємось, що дана інформація буде корисною та бажаємо успіху у підготовці до сертифікації 😊
Діліться своїм досвідом та враженнями у коментарях ⬇️
#istqb
Доброго дня!
Курс триває, а отже пора і ділитись інформацією 📚
Перша глава Syllabus'у присвячена основам тестування - що це є, навіщо та яка користь від нього.
Ключові моменти, які слід знати:
✅ 20% питань екзамену (8/40) присвячені цій главі.
✅ Testing vs debugging - чітко розумійте різницю між цими процесами.
✅ Test objectives - вмійте сформулювати та виокремити цілі тестування.
✅ QA != QC - якщо тестування є частиною QC, то QA - це дещо інший звір.
✅ ISO25010 - ознайомтесь із цим стандартом (раніше ми писали про нього).
✅ Чітко орієнтуйтесь та розумійте різницю між error, mistake, fault, bug, defect, failure.
✅ 7 testing principles - обов'язково буде питання присвячене якійсь із парадигм.
✅ Test process - потрібно знати фундаментальні етапи процесу тестування, їх характеристики та активності, а також які work products виникають на кожному з етапів і як вони між собою пов'язані.
✅ Розумійте людські та психологічні фактори тестування в розрізі процесу розробки ПЗ.
Надіємось, що дана інформація буде корисною та бажаємо успіху у підготовці до сертифікації 😊
Діліться своїм досвідом та враженнями у коментарях ⬇️
CTFL 2. Testing Throughout the Software Development Lifecycle
#istqb
Доброго ранку! Рухаємось далі по курсу 📆
2га глава Syllabus'у розповідає про місце тестування у життєвих циклах розробки ПЗ.
🔍 Ключові моменти:
✅ 5 питань на екзамені присвячені цій главі.
✅ Syllabus класифікує життєві цикли розробки ПЗ на: послідовні (Waterfall, V-model); інкрементальні та ітеративні (RUP, SCRUM, Kanban, Spiral) - чітко розумійте їхні особливості.
✅ Яку б модель ви не вибрали - завжди дотримуйтесь принципу early testing.
✅ На практиці життєві цикли залежать від: цілей проекту, типу продукту, бізнес пріоритетів та ризиків. Для COTS (commercial off-the-shelf) чи IoT проектів життєві цикли розробки, тестові активності та тестові рівні можуть комбінуватись, змінюватись чи застосовуватись в симбіозі.
✅ Test levels - Component -> Integration -> System -> System integration -> Acceptance - кожен тестовий рівень має свої характерні тестові цілі, базиси, об'єкти та типові дефекти.
✅ В рамках Acceptance Testing виділяють User acceptance, Operational acceptance, Contractual and regulatory acceptance, Alpha and beta testing.
✅ Test types - Functional, Non-functional, White-box, Change-related - типи тестування ставлять перед собою різні цілі. Якщо функціональне тестування відповідає на питання "що" робить продукт, то нефункціональне на "як добре" продукт поводиться. Тестування білого ящика бере за основу внутрішню будову системи (code, architecture, work flows, data flows etc.), а тестування, що залежить від змін включає у себе confirmation та regression testing.
✅ Важливо відмітити, що кожен тип тестування може проводитись на кожному тестовому рівні. Це уже залежить від самого продукту, цілей та обставин.
✅ Maintenance Testing - окремий звір, з яким доводиться мати справу. Ознайомтесь із основними тригерами (system modification, migration etc.) для проведення такого роду тестування та що таке Impact Analysis.
Як завжди, будемо раді вашому зворотному зв'язку ⬇️
#istqb
Доброго ранку! Рухаємось далі по курсу 📆
2га глава Syllabus'у розповідає про місце тестування у життєвих циклах розробки ПЗ.
🔍 Ключові моменти:
✅ 5 питань на екзамені присвячені цій главі.
✅ Syllabus класифікує життєві цикли розробки ПЗ на: послідовні (Waterfall, V-model); інкрементальні та ітеративні (RUP, SCRUM, Kanban, Spiral) - чітко розумійте їхні особливості.
✅ Яку б модель ви не вибрали - завжди дотримуйтесь принципу early testing.
✅ На практиці життєві цикли залежать від: цілей проекту, типу продукту, бізнес пріоритетів та ризиків. Для COTS (commercial off-the-shelf) чи IoT проектів життєві цикли розробки, тестові активності та тестові рівні можуть комбінуватись, змінюватись чи застосовуватись в симбіозі.
✅ Test levels - Component -> Integration -> System -> System integration -> Acceptance - кожен тестовий рівень має свої характерні тестові цілі, базиси, об'єкти та типові дефекти.
✅ В рамках Acceptance Testing виділяють User acceptance, Operational acceptance, Contractual and regulatory acceptance, Alpha and beta testing.
✅ Test types - Functional, Non-functional, White-box, Change-related - типи тестування ставлять перед собою різні цілі. Якщо функціональне тестування відповідає на питання "що" робить продукт, то нефункціональне на "як добре" продукт поводиться. Тестування білого ящика бере за основу внутрішню будову системи (code, architecture, work flows, data flows etc.), а тестування, що залежить від змін включає у себе confirmation та regression testing.
✅ Важливо відмітити, що кожен тип тестування може проводитись на кожному тестовому рівні. Це уже залежить від самого продукту, цілей та обставин.
✅ Maintenance Testing - окремий звір, з яким доводиться мати справу. Ознайомтесь із основними тригерами (system modification, migration etc.) для проведення такого роду тестування та що таке Impact Analysis.
Як завжди, будемо раді вашому зворотному зв'язку ⬇️
Принципи тестування
#istqb #learnit
Привіт. Нещодавно ми писали про перший розділ ISTQB Syllabus і сьогодні вирішили написати трохи детальніше про принципи тестування. Їм вже більше 50❗️ років і вони все ще актуальні! Про них варто пам'ятати як новачкам, так і експертам:
1️⃣ Тестування демонструє присутність дефектів, але не їх відсутність. Не можна довести, що в програмі немає багів, але тестуючи, можна зменшити імовірність знаходження багу користувачами
2️⃣ Вичерпне тестування неможливо. Протестувати програму з усіма можливими комбінаціями вхідних значень неможливо за скінченний проміжок часу. Навіть для простих програм типу калькулятор це означало б перевірку операцій з усіма дійсними числами від -∞ до +∞. Саме тому тестери використовують техніки тест дизайну та аналізують ризики
3️⃣ Раннє тестування економить час і гроші. Чим швидше в життєвому циклі ми знаходимо баг, ти простіше і дешевше його пофіксити. Статичне тестування вимог набагато дешевше, ніж повне регресійне тестування системи після баг фіксу перед релізом. Раннє тестування зараз ще відносять до shift left
4️⃣ Дефекти часто скупчуються разом. Зазвичай, знайшовши 1 помилку в певному модулі програми, імовірність знайти там ще баги - зростає. Тут знову нам допомагає аналіз ризиків 🤓
5️⃣ Остерігайтеся парадоксу пестицидів. Якщо одні й ті самі тести проводити багато разів - імовірність знайти дефект зменшується. І це є одним з аргументів на користь переваги ручного тестування перед автоматизованим, оскільки мануальний тестер завжди робить варіації початкового плану
6️⃣ Тестування контекстно залежне. різні програми ми тестуємо по різному. Тестування автопілоту літака вимагає серйознішого підходу та зусиль ніж черговий, навіть дуже класний, інтернет магазин. Саме тому, чим більше досвіду ми маємо, тим більше ми цінуємось, оскільки знаємо різні контексти (доменні знання)
7️⃣ Відсутність помилок - це помилка. Дехто може думати, що тестери можуть знайти багато багів, їх пофіксять і багів більше не буде. Але принципи 1️⃣ та 2️⃣ кажуть нам, що це не можливо. Більш того, знаходження і фікс великої кількості багів може привести до хибної впевненості, що програма якісна. Насправді ж, навіть система, яку протестували і не знайшли багів може виявитись нецікавою користувачам і нікому не потрібною 🤷♀️
Як вам? Не застаріли принципи? Може не згодні з якимись? Може треба додати нові? Напишіть нам в коментах!
А ще знайшов картинку про баги, стару, як ті принципи 😎
#istqb #learnit
Привіт. Нещодавно ми писали про перший розділ ISTQB Syllabus і сьогодні вирішили написати трохи детальніше про принципи тестування. Їм вже більше 50❗️ років і вони все ще актуальні! Про них варто пам'ятати як новачкам, так і експертам:
1️⃣ Тестування демонструє присутність дефектів, але не їх відсутність. Не можна довести, що в програмі немає багів, але тестуючи, можна зменшити імовірність знаходження багу користувачами
2️⃣ Вичерпне тестування неможливо. Протестувати програму з усіма можливими комбінаціями вхідних значень неможливо за скінченний проміжок часу. Навіть для простих програм типу калькулятор це означало б перевірку операцій з усіма дійсними числами від -∞ до +∞. Саме тому тестери використовують техніки тест дизайну та аналізують ризики
3️⃣ Раннє тестування економить час і гроші. Чим швидше в життєвому циклі ми знаходимо баг, ти простіше і дешевше його пофіксити. Статичне тестування вимог набагато дешевше, ніж повне регресійне тестування системи після баг фіксу перед релізом. Раннє тестування зараз ще відносять до shift left
4️⃣ Дефекти часто скупчуються разом. Зазвичай, знайшовши 1 помилку в певному модулі програми, імовірність знайти там ще баги - зростає. Тут знову нам допомагає аналіз ризиків 🤓
5️⃣ Остерігайтеся парадоксу пестицидів. Якщо одні й ті самі тести проводити багато разів - імовірність знайти дефект зменшується. І це є одним з аргументів на користь переваги ручного тестування перед автоматизованим, оскільки мануальний тестер завжди робить варіації початкового плану
6️⃣ Тестування контекстно залежне. різні програми ми тестуємо по різному. Тестування автопілоту літака вимагає серйознішого підходу та зусиль ніж черговий, навіть дуже класний, інтернет магазин. Саме тому, чим більше досвіду ми маємо, тим більше ми цінуємось, оскільки знаємо різні контексти (доменні знання)
7️⃣ Відсутність помилок - це помилка. Дехто може думати, що тестери можуть знайти багато багів, їх пофіксять і багів більше не буде. Але принципи 1️⃣ та 2️⃣ кажуть нам, що це не можливо. Більш того, знаходження і фікс великої кількості багів може привести до хибної впевненості, що програма якісна. Насправді ж, навіть система, яку протестували і не знайшли багів може виявитись нецікавою користувачам і нікому не потрібною 🤷♀️
Як вам? Не застаріли принципи? Може не згодні з якимись? Може треба додати нові? Напишіть нам в коментах!
А ще знайшов картинку про баги, стару, як ті принципи 😎
CTFL 3. Static testing
#istqb
Ранок добрий 😊
Сьогодні мова піде про часто нехтуваний але дуже важливий вид тестування - static.
🔍 Пам'ятайте:
✅ Якщо динамічне тестування вимагає запуску ПЗ, то під час статичного ми мануально (review) або інструментально (static analysis) оцінюємо код та інші робочі продукти.
✅ Які робочі продукти можна статично протестувати? Фактично будь-які: специфікацію, юзер сторі, архітектуру й дизайн, моделі, код, тестову документацію, контракти, плани і тд.
✅ Статичне тестування реалізовує принцип early testing, що майже завжди економічно вигідно для проекту. Окрім цього є низка інших переваг: знаходження специфічних дефектів, запобігання дефектів у вимогах, дизайні та коді, збільшення продуктивності команди, покращення комунікації в команді.
✅ Динамічне тестування не є менш чи більш важливим за статичне - ці два типи є компліментарними й чудово доповнюють один одного, знаходячи різного роду дефекти.
✅ Reviews варіюється від неформального до дуже формального (informal -> walkthrough -> technical -> inspection). Загалом, це процес (планування, зустріч, фікс дефектів та звітування) оцінювання робочого продукту групою осіб з призначеними ролями (Author, Reviewer, Leader, Manager, Moderator, Scribe, Reader). Процес та ролі варіюються в залежності від рівня формальності review. Якщо informal review може взагалі не документуватись, то inspection містить навіть формальні правила, чеклісти, а також entry & exit criteria.
✅ Існує низка технік, якими користуються при проведенні review. Найпопулярніші з них:
ad hoc - проводиться без попередньої підготовки з мінімумом інформації й залежить від навичок тестувальників;
checklist-based - систематична техніка пошуку дефектів на основі переліку потенційних вразливих місць;
scenarios and dry runs - структуровані керівні вказівки як правильно розглядати робочий продукт;
perspective-based - емпірично найбільш ефективна техніка, що дозволяє рецензувати продукт з різних перспектив (кінцевого користувача, маркетингу, тестування, дизайну, підтримки і т.п.);
role-based - розгляд продукту з точки зору ролі користувача (досвідчений, недосвідчений, старша людина, дитина і т.п.) чи працівника компанії (адміністратор, менеджер і т.п.).
✅ Завжди слідуйте рекомендаціям:
- встановлюйте чіткі цілі;
- вибирайте ті типи review та техніки, які відповідають вашим цілям;
- великі робочі продукти розділяйте на менші частини для review;
- виділяйте достатньо часу на підготовку, тренінги, особливо до technical review, inspection;
- залучайте правильних людей, тестувальники є цінними оглядачами;
- добивайтесь підтримки збоку компанії та менеджменту;
- працюйте в атмосфері конструктиву та довіри.
🧐 Пишіть нам, чи ви практикуєте статичне тестування та в якому вигляді воно проходить? ⬇️
#istqb
Ранок добрий 😊
Сьогодні мова піде про часто нехтуваний але дуже важливий вид тестування - static.
🔍 Пам'ятайте:
✅ Якщо динамічне тестування вимагає запуску ПЗ, то під час статичного ми мануально (review) або інструментально (static analysis) оцінюємо код та інші робочі продукти.
✅ Які робочі продукти можна статично протестувати? Фактично будь-які: специфікацію, юзер сторі, архітектуру й дизайн, моделі, код, тестову документацію, контракти, плани і тд.
✅ Статичне тестування реалізовує принцип early testing, що майже завжди економічно вигідно для проекту. Окрім цього є низка інших переваг: знаходження специфічних дефектів, запобігання дефектів у вимогах, дизайні та коді, збільшення продуктивності команди, покращення комунікації в команді.
✅ Динамічне тестування не є менш чи більш важливим за статичне - ці два типи є компліментарними й чудово доповнюють один одного, знаходячи різного роду дефекти.
✅ Reviews варіюється від неформального до дуже формального (informal -> walkthrough -> technical -> inspection). Загалом, це процес (планування, зустріч, фікс дефектів та звітування) оцінювання робочого продукту групою осіб з призначеними ролями (Author, Reviewer, Leader, Manager, Moderator, Scribe, Reader). Процес та ролі варіюються в залежності від рівня формальності review. Якщо informal review може взагалі не документуватись, то inspection містить навіть формальні правила, чеклісти, а також entry & exit criteria.
✅ Існує низка технік, якими користуються при проведенні review. Найпопулярніші з них:
ad hoc - проводиться без попередньої підготовки з мінімумом інформації й залежить від навичок тестувальників;
checklist-based - систематична техніка пошуку дефектів на основі переліку потенційних вразливих місць;
scenarios and dry runs - структуровані керівні вказівки як правильно розглядати робочий продукт;
perspective-based - емпірично найбільш ефективна техніка, що дозволяє рецензувати продукт з різних перспектив (кінцевого користувача, маркетингу, тестування, дизайну, підтримки і т.п.);
role-based - розгляд продукту з точки зору ролі користувача (досвідчений, недосвідчений, старша людина, дитина і т.п.) чи працівника компанії (адміністратор, менеджер і т.п.).
✅ Завжди слідуйте рекомендаціям:
- встановлюйте чіткі цілі;
- вибирайте ті типи review та техніки, які відповідають вашим цілям;
- великі робочі продукти розділяйте на менші частини для review;
- виділяйте достатньо часу на підготовку, тренінги, особливо до technical review, inspection;
- залучайте правильних людей, тестувальники є цінними оглядачами;
- добивайтесь підтримки збоку компанії та менеджменту;
- працюйте в атмосфері конструктиву та довіри.
🧐 Пишіть нам, чи ви практикуєте статичне тестування та в якому вигляді воно проходить? ⬇️
Книжечка доїхала
#istqb
Вітаємо переможця нашої супер-пупер кріпто-вікторини!
#istqb
Вітаємо переможця нашої супер-пупер кріпто-вікторини!
Xfmm epof Wjdups!Гурт вболівальників за якість, QAMania
CTFL 5. Test management
#istqb
Доброго ранку! 😊
Сьогодні мова піде про тест менеджмент, оскільки ми уже детально розглянули 4ту главу Test Techniques у попередніх постах (#testdesign).
👇 ISTQB звертає увагу на:
✅ Незалежна команда тестування має як свої плюси (більша об'єктивність, знаходження різного роду дефектів) так і мінуси (ізольованість, нестача інформації, втрата відповідальності збоку команди розробки та інші).
✅ Задачі та відповідальності Test Manager і Tester можуть варіюватись в залежності від проекту й компанії. Тест менеджер відповідає за загальний процес тестування й успішне керівництво усіма тестовими активностями в той час, коли тестувальник безпосередньо виконує ці активності слідуючи тестовому процесу.
✅ Виділяють наступні Test Strategy and Approach:
> Analytical - базується на аналізі певного фактору (наприклад, вимог або ризику).
> Model-Based - тестування проводиться на основі побудованої моделі (бізнес/математичної/надійності тощо).
> Methodical - заздалегідь визначений набір тестів або тестових умов (наприклад, типові помилки, характеристики якості тощо).
> Process-compliant (or standard-compliant) - аналіз, дизайн та імплементація тестів базується на галузевих стандартах, процесній документації, політиках компаній.
> Directed (or consultative) - зацікавлені сторони, галузеві чи технічні експерти керують процесом або надають поради, вказівки.
> Regression-averse - ставка робиться на автоматизацію та повторне використання існуючих тестів з метою зменшення регресії.
> Reactive - тести дизайняться та застосовуються безпосередньо під час динамічного тестування (e.g. exploratory testing).
На практиці рідко зустрінеш якусь окрему стратегію, усі ми використовуємо поєднання тих чи інших підходів.
✅ Найбільш поширеними Test Estimation Techniques є:
> metrics-based technique - оцінка базується на екстрапольованому значенні із попередніх подібних проектів або вираховується із заданих величин.
> expert-based technique - досвідчені спеціалісти можуть оцінити затрати без спеціальних формул, але така техніка застосовується як правило для швидкої оцінки проекту на успішність.
✅ Configuration Management - слід пам'ятати, що усі робочі артефакти на проекті повинні бути унікально ідентифіковані, версійно контрольовані та трасовані один з одним.
✅ Питанню Risks and Testing ми присвятили кілька постів (#risks).
✅ Defect Management - приклад хорошого bug report (incident report) можна знайти у стандарті ISO/IEC/IEEE 29119-3.
А як ви ставитесь до питання менеджменту?
#istqb
Доброго ранку! 😊
Сьогодні мова піде про тест менеджмент, оскільки ми уже детально розглянули 4ту главу Test Techniques у попередніх постах (#testdesign).
👇 ISTQB звертає увагу на:
✅ Незалежна команда тестування має як свої плюси (більша об'єктивність, знаходження різного роду дефектів) так і мінуси (ізольованість, нестача інформації, втрата відповідальності збоку команди розробки та інші).
✅ Задачі та відповідальності Test Manager і Tester можуть варіюватись в залежності від проекту й компанії. Тест менеджер відповідає за загальний процес тестування й успішне керівництво усіма тестовими активностями в той час, коли тестувальник безпосередньо виконує ці активності слідуючи тестовому процесу.
✅ Виділяють наступні Test Strategy and Approach:
> Analytical - базується на аналізі певного фактору (наприклад, вимог або ризику).
> Model-Based - тестування проводиться на основі побудованої моделі (бізнес/математичної/надійності тощо).
> Methodical - заздалегідь визначений набір тестів або тестових умов (наприклад, типові помилки, характеристики якості тощо).
> Process-compliant (or standard-compliant) - аналіз, дизайн та імплементація тестів базується на галузевих стандартах, процесній документації, політиках компаній.
> Directed (or consultative) - зацікавлені сторони, галузеві чи технічні експерти керують процесом або надають поради, вказівки.
> Regression-averse - ставка робиться на автоматизацію та повторне використання існуючих тестів з метою зменшення регресії.
> Reactive - тести дизайняться та застосовуються безпосередньо під час динамічного тестування (e.g. exploratory testing).
На практиці рідко зустрінеш якусь окрему стратегію, усі ми використовуємо поєднання тих чи інших підходів.
✅ Найбільш поширеними Test Estimation Techniques є:
> metrics-based technique - оцінка базується на екстрапольованому значенні із попередніх подібних проектів або вираховується із заданих величин.
> expert-based technique - досвідчені спеціалісти можуть оцінити затрати без спеціальних формул, але така техніка застосовується як правило для швидкої оцінки проекту на успішність.
✅ Configuration Management - слід пам'ятати, що усі робочі артефакти на проекті повинні бути унікально ідентифіковані, версійно контрольовані та трасовані один з одним.
✅ Питанню Risks and Testing ми присвятили кілька постів (#risks).
✅ Defect Management - приклад хорошого bug report (incident report) можна знайти у стандарті ISO/IEC/IEEE 29119-3.
А як ви ставитесь до питання менеджменту?
Один рік
#qamania
Вітаємо всіх! Рівно рік тому, 29 липня 2019, ми створили цей канал з метою цікаво писати про тестування.
Вбачаємо нашу місію та внесок у QA спільноту - в збільшенні кількості та якості україномовних матеріалів.
За цей рік Вас приєдналось майже 600 👥, й ми опублікували 203 📝 дописи на різні теми. Встигли розробити стікери для телеграму, та провести "кріпто-квест" з підручником з ISTQB в якості призу. Деякі з думок, статей, посилань, опитувань набагато більше сподобались читачам, аніж авторам, деякі навпаки - авторам, і не дуже читачам :) Але щодо більшості дописів наші смаки збігались!
Найбільш популярними постами стали наступні:
За переглядами: 👀
🥇 t.me/qamania/142 - "перше квітня awesomeness"
🥈 t.me/qamania/185 - "ISTQB CTFL0"
🥉 t.me/qamania/207 - "Python humble bundle"
За "реакціями": 👍
🥇 Найжвавіший відгук завжди мали опитування :) (1, 2, 3, 4, 5)
🥈 t.me/qamania/184 - "ISTQB CTFL"
🥉 t.me/qamania/182 - "ISO 29119"
Найвживаніші рубрики в постах:
🏷 #learnit 53 поста
🏷 #tools 36 постів
🏷 #truestory 17 постів
🏷 #friday 14 постів
🏷 #istqb 11 постів
Окрім цих, ще декілька "для душі" :)
🏷 #bugseverywhere (9)
🏷 #fun (8)
🏷 #longread (6)
Якщо ви хотіли б побачити в каналі якісь теми або ініціативи, яких тут поки що не було, або просто хочете привітати - пишіть нам в коменти та через feedback bot!
Залишаємось на зв'язку :)
Дякуємо, що з нами!
QAMania
#qamania
Вітаємо всіх! Рівно рік тому, 29 липня 2019, ми створили цей канал з метою цікаво писати про тестування.
Вбачаємо нашу місію та внесок у QA спільноту - в збільшенні кількості та якості україномовних матеріалів.
За цей рік Вас приєдналось майже 600 👥, й ми опублікували 203 📝 дописи на різні теми. Встигли розробити стікери для телеграму, та провести "кріпто-квест" з підручником з ISTQB в якості призу. Деякі з думок, статей, посилань, опитувань набагато більше сподобались читачам, аніж авторам, деякі навпаки - авторам, і не дуже читачам :) Але щодо більшості дописів наші смаки збігались!
Найбільш популярними постами стали наступні:
За переглядами: 👀
🥇 t.me/qamania/142 - "перше квітня awesomeness"
🥈 t.me/qamania/185 - "ISTQB CTFL0"
🥉 t.me/qamania/207 - "Python humble bundle"
За "реакціями": 👍
🥇 Найжвавіший відгук завжди мали опитування :) (1, 2, 3, 4, 5)
🥈 t.me/qamania/184 - "ISTQB CTFL"
🥉 t.me/qamania/182 - "ISO 29119"
Найвживаніші рубрики в постах:
🏷 #learnit 53 поста
🏷 #tools 36 постів
🏷 #truestory 17 постів
🏷 #friday 14 постів
🏷 #istqb 11 постів
Окрім цих, ще декілька "для душі" :)
🏷 #bugseverywhere (9)
🏷 #fun (8)
🏷 #longread (6)
Якщо ви хотіли б побачити в каналі якісь теми або ініціативи, яких тут поки що не було, або просто хочете привітати - пишіть нам в коменти та через feedback bot!
Залишаємось на зв'язку :)
Дякуємо, що з нами!
QAMania
Improving test process
#test_improvement #istqb
Привіт друзі! Вже з місяць маю в чернетках кілька дописів про покращення процесу тестування - настав їх зоряний час ⭐️
Озираючись на весь свій досвід, я розумію, що будь-який інженер проходить 3 стадії дорослішання, як в анекдоті:
👶 ти віриш у Святого Миколая
🙅♂️ ти не віриш у Святого Миколая
🎅 ти - Святий Миколай
На моєму прикладі: коли почав працювати - мене ВСЕ влаштовувало. Кажуть що і коли робити, кого питати, кому доповідати. Бути старанним і робити вчасно. Головне - робота є! Цікава! І за неї ще й гроші платять.
Через деякий час, набувши досвіду, вже розумієш, що не все подобається - деякі процеси занадто складні а задачі, що ставлять - безглузді (типу експортувати звіт з джири зі статистикою замість того, щоб просто дати посилання на дашбоард). Але все ще бракує впевненості і розуміння, як же зробити правильно. Як висока кухня - однозначно можна сказати, що їжа несмачна, але як зробити її краще?
І ось нарешті, набивши купу шишок, прочитавши купу літератури, ти розумієш, як робити правильно і намагаєшся впровадити зручні процеси на благо себе та своєї команди.
От саме про процес покращення тестування в ISTQB є окрема сертифікація: expert level improving test process. Десь пів року тому ми писали, що купили книги і намагатимемось підготуватись до екзамену. І все ще намагаємось 🤷♂️
І поки наш коллега продовжує публікувати дописи про ISTQB CTFL (шукайте за тегом #istqb), я все ж таки взяв себе в руки і вирішив, що ось і настав момент почати щось робити для сертифікації рівня експерт. Скажу чесно - книгу читати важко, тому вирішив прочитати syllabus, зробити нотатки і потім повернутись до книги та поглибити свої знання.
Інше питання - навіщо отримувати сертифікат? Більшість спеціалістів, чим більше досвіду мають, тим менше цінують різні сертифікати, оскільки вони майже не впливають на кар'єру (окрім випадків, коли це є обов'язковою умовою для певних видів робіт, як сертифікати CISCO дають змогу працювати з їх обладнанням) та реальні знання та навички важливіші. Відповідь - зараз маю трохи часу і цікавлюсь, наскільки експертна теорія може стати мені в нагоді.
Тому намагатимусь раз на тиждень розбирати разом з вами по одній главі, без води та з прикладами з досвіду, якщо такі будуть.
Вам цікаво? Чи може відкопати свої конспекти з підготовки до ISTQB Advanced Test Management?
#test_improvement #istqb
Привіт друзі! Вже з місяць маю в чернетках кілька дописів про покращення процесу тестування - настав їх зоряний час ⭐️
Озираючись на весь свій досвід, я розумію, що будь-який інженер проходить 3 стадії дорослішання, як в анекдоті:
👶 ти віриш у Святого Миколая
🙅♂️ ти не віриш у Святого Миколая
🎅 ти - Святий Миколай
На моєму прикладі: коли почав працювати - мене ВСЕ влаштовувало. Кажуть що і коли робити, кого питати, кому доповідати. Бути старанним і робити вчасно. Головне - робота є! Цікава! І за неї ще й гроші платять.
Через деякий час, набувши досвіду, вже розумієш, що не все подобається - деякі процеси занадто складні а задачі, що ставлять - безглузді (типу експортувати звіт з джири зі статистикою замість того, щоб просто дати посилання на дашбоард). Але все ще бракує впевненості і розуміння, як же зробити правильно. Як висока кухня - однозначно можна сказати, що їжа несмачна, але як зробити її краще?
І ось нарешті, набивши купу шишок, прочитавши купу літератури, ти розумієш, як робити правильно і намагаєшся впровадити зручні процеси на благо себе та своєї команди.
От саме про процес покращення тестування в ISTQB є окрема сертифікація: expert level improving test process. Десь пів року тому ми писали, що купили книги і намагатимемось підготуватись до екзамену. І все ще намагаємось 🤷♂️
І поки наш коллега продовжує публікувати дописи про ISTQB CTFL (шукайте за тегом #istqb), я все ж таки взяв себе в руки і вирішив, що ось і настав момент почати щось робити для сертифікації рівня експерт. Скажу чесно - книгу читати важко, тому вирішив прочитати syllabus, зробити нотатки і потім повернутись до книги та поглибити свої знання.
Інше питання - навіщо отримувати сертифікат? Більшість спеціалістів, чим більше досвіду мають, тим менше цінують різні сертифікати, оскільки вони майже не впливають на кар'єру (окрім випадків, коли це є обов'язковою умовою для певних видів робіт, як сертифікати CISCO дають змогу працювати з їх обладнанням) та реальні знання та навички важливіші. Відповідь - зараз маю трохи часу і цікавлюсь, наскільки експертна теорія може стати мені в нагоді.
Тому намагатимусь раз на тиждень розбирати разом з вами по одній главі, без води та з прикладами з досвіду, якщо такі будуть.
Вам цікаво? Чи може відкопати свої конспекти з підготовки до ISTQB Advanced Test Management?
CTFL 6. Tools Support for Testing
#istqb
Доброго дня! 😊
Закінчуємо рубрику CTFL публікацією про тестові інструменти 🛠
✅ Будь-який інструмент, що використовується під час тестування можна віднести до тестових інструментів - починаючи із блокноту, ґуґл таблиць та закінчуючи повноцінною комерційною платформою а-ля HP ALM.
✅ ISTQB класифікує тестові інструменти на такі, що підтримують:
- тест менеджмент;
- статичне тестування;
- тест дизайн та імплементацію;
- тест виконання та логування;
- вимірювання продуктивності та динамічний аналіз;
- спеціальні тестові потреби. (оцінка нефункціональних х-к якості - usability, security тощо)
✅ Потрібно розуміти, що використання будь-якого інструменту має як переваги, так і недоліки. До переваг відносять:
- зменшення повторювальної ручної роботи;
- надійність та консистентність;
- більш об'єктивна оцінка;
- агрегована та доступна інформація про тестування (графіки, статистика).
Щодо потенційних недоліків:
- нереальні очікування від інструменту;
- недооцінка затрат на вивчення, використання інструменту;
- ризики пов'язані з вендором;
- нехтування залежностями та взаємодією інструменту з іншим софтом та середовищем.
✅ Для того, щоб ефективно використовувати інструмент у вашій компанії чи організації слідуйте наступних рекомендацій:
- надавайте інструмент у використання поступово, а не усім відразу (починайте з пілотного проекту в одній команді, де визначите сильні й слабкі сторони, ефективність, рентабельність, метрики);
- моніторте та адаптуйте й покращуйте процес використання інструментів;
- виділяйте час на тренінги, навчання, менторство;
- визначте інструкції з використання інструменту;
- надавайте підтримку та вивчайте отримані уроки.
🔍 А чи бував у вас досвід із вибору спеціальних інструментів для впровадження їх у вашій організації/проекту?
#istqb
Доброго дня! 😊
Закінчуємо рубрику CTFL публікацією про тестові інструменти 🛠
✅ Будь-який інструмент, що використовується під час тестування можна віднести до тестових інструментів - починаючи із блокноту, ґуґл таблиць та закінчуючи повноцінною комерційною платформою а-ля HP ALM.
✅ ISTQB класифікує тестові інструменти на такі, що підтримують:
- тест менеджмент;
- статичне тестування;
- тест дизайн та імплементацію;
- тест виконання та логування;
- вимірювання продуктивності та динамічний аналіз;
- спеціальні тестові потреби. (оцінка нефункціональних х-к якості - usability, security тощо)
✅ Потрібно розуміти, що використання будь-якого інструменту має як переваги, так і недоліки. До переваг відносять:
- зменшення повторювальної ручної роботи;
- надійність та консистентність;
- більш об'єктивна оцінка;
- агрегована та доступна інформація про тестування (графіки, статистика).
Щодо потенційних недоліків:
- нереальні очікування від інструменту;
- недооцінка затрат на вивчення, використання інструменту;
- ризики пов'язані з вендором;
- нехтування залежностями та взаємодією інструменту з іншим софтом та середовищем.
✅ Для того, щоб ефективно використовувати інструмент у вашій компанії чи організації слідуйте наступних рекомендацій:
- надавайте інструмент у використання поступово, а не усім відразу (починайте з пілотного проекту в одній команді, де визначите сильні й слабкі сторони, ефективність, рентабельність, метрики);
- моніторте та адаптуйте й покращуйте процес використання інструментів;
- виділяйте час на тренінги, навчання, менторство;
- визначте інструкції з використання інструменту;
- надавайте підтримку та вивчайте отримані уроки.
🔍 А чи бував у вас досвід із вибору спеціальних інструментів для впровадження їх у вашій організації/проекту?
ISTQB CTEL. Improving the testing process
#istqb #expert #test_improvement #longread
Привіт друзі! Як і анонсував у понеділок, починаємо розбирати syllabus експертного рівня. Щодо advanced - його теж планую розібрати, але трохи пізніше.
======
Глава 1. The Context of Improvement
1️⃣ Нащо покращувати тестування?
Є 3 основні причини:
✅ потреби бізнесу чи вашої організації
✅ потреби підтримки ПЗ, що вже в продакшені
✅ потреби поточного процесу забезпечення якості
⚠️ Моя примітка: ніколи не треба чекати особливої причини, щоб почати покращувати процеси, якщо ви бачите, що щось не так. Варто ініціювати дискусію з командою
Типові причини покращувати тестування для бізнесу:
🔰 Зменшення часу виходу на ринок (time to market). Щоб не страждала якість, можна сфокусуватись на підвищенні ефективності поточного тестування та впровадження/збільшення раннього тестування з метою економії часу на пізніх етапах (зараз це називають shift-left testing) - менше багів допустили - менше часу на фікс та регресію
🔰 Покращення якості продукту
🔰 Бажання мати більше інформації про продукт - кращий тест репортінг та передбачуваність (тобто, заплановані активності мають виконуватись за планом. Без розбіжностей)
🔰 Забезпечення якості вимог (наскільки я зрозумів - документації) на прийнятному рівні для користувачів та third party організацій
🔰 Економія грошей за рахунок тестування
🔰 Зменшення часу розробки продукту за рахунок інтеграції тестування з процесом розробки
🔰 Бажання зменшити ціну помилки для продукту в проді
🔰 Необхідність відповідати стандартам
Покращення процесу тестування може відбуватись в рамках покращення всіх процесів компанії/бізнесу, таких як, наприклад:
🔰 Total Quality Management (TQM)
🔰 ISO 9000:2000
🔰 European Foundation for Quality Management (EFQM) Excellence Model™ чи подібний
🔰 Six Sigma
Покращення процесу тестування може відбуватись в рамках покращення процесу розробки, таких як, наприклад:
🔰 Capability Maturity Model Integration (CMMI)
🔰 ISO/IEC 15504
🔰 ITIL, ITIL2
🔰 Team Software Process (TSP) та Personal Software Process (PSP)S
⚠️ Моя примітка: деякі з перелічених процесів розглянемо пізніше
2️⃣ Що можна покращити?
Незалежно від того, чи відбувається покращення процесу тестування в рамках покращення процесу розробки чи процесів роботи компанії, можна покращувати інфраструктуру, організацію, навички тестерів. А ще іноді прокращення процессу тестування може служити індикатором незрілості інших процесів та бути для них точкою відліку.
Але варто завжди пам'ятати, що цілі тестування мають збігатись з цілями бізнесу і не завжди оптимальною стратегією є досягнення максимального рівню зрілості тестових процесів.
Як вам для початку?
#istqb #expert #test_improvement #longread
Привіт друзі! Як і анонсував у понеділок, починаємо розбирати syllabus експертного рівня. Щодо advanced - його теж планую розібрати, але трохи пізніше.
======
Глава 1. The Context of Improvement
1️⃣ Нащо покращувати тестування?
Є 3 основні причини:
✅ потреби бізнесу чи вашої організації
✅ потреби підтримки ПЗ, що вже в продакшені
✅ потреби поточного процесу забезпечення якості
⚠️ Моя примітка: ніколи не треба чекати особливої причини, щоб почати покращувати процеси, якщо ви бачите, що щось не так. Варто ініціювати дискусію з командою
Типові причини покращувати тестування для бізнесу:
🔰 Зменшення часу виходу на ринок (time to market). Щоб не страждала якість, можна сфокусуватись на підвищенні ефективності поточного тестування та впровадження/збільшення раннього тестування з метою економії часу на пізніх етапах (зараз це називають shift-left testing) - менше багів допустили - менше часу на фікс та регресію
🔰 Покращення якості продукту
🔰 Бажання мати більше інформації про продукт - кращий тест репортінг та передбачуваність (тобто, заплановані активності мають виконуватись за планом. Без розбіжностей)
🔰 Забезпечення якості вимог (наскільки я зрозумів - документації) на прийнятному рівні для користувачів та third party організацій
🔰 Економія грошей за рахунок тестування
🔰 Зменшення часу розробки продукту за рахунок інтеграції тестування з процесом розробки
🔰 Бажання зменшити ціну помилки для продукту в проді
🔰 Необхідність відповідати стандартам
Покращення процесу тестування може відбуватись в рамках покращення всіх процесів компанії/бізнесу, таких як, наприклад:
🔰 Total Quality Management (TQM)
🔰 ISO 9000:2000
🔰 European Foundation for Quality Management (EFQM) Excellence Model™ чи подібний
🔰 Six Sigma
Покращення процесу тестування може відбуватись в рамках покращення процесу розробки, таких як, наприклад:
🔰 Capability Maturity Model Integration (CMMI)
🔰 ISO/IEC 15504
🔰 ITIL, ITIL2
🔰 Team Software Process (TSP) та Personal Software Process (PSP)S
⚠️ Моя примітка: деякі з перелічених процесів розглянемо пізніше
2️⃣ Що можна покращити?
Незалежно від того, чи відбувається покращення процесу тестування в рамках покращення процесу розробки чи процесів роботи компанії, можна покращувати інфраструктуру, організацію, навички тестерів. А ще іноді прокращення процессу тестування може служити індикатором незрілості інших процесів та бути для них точкою відліку.
Але варто завжди пам'ятати, що цілі тестування мають збігатись з цілями бізнесу і не завжди оптимальною стратегією є досягнення максимального рівню зрілості тестових процесів.
Як вам для початку?
ISTQB CTEL - Шо Quality?
#istqb #expert #longread
Уявімо, що ми з вами, для чогось або когось, починаємо процес покращення чогось, щоб щось стало краще 🤔 Звісно мова все ще про тестування 😄. При всій своїй невинно прекрасній простоті, саме з цим рівнем чіткості досить часто доводиться мати справу у практиці професійного "покращувача-процесів-тестування".
І якщо ми хочемо корисних змін у процес то задаємось запитаннями: "навіщо ці зміни?", "що ми власне збираємось змінювати на краще?". Причому саме у такій послідовності: спочатку ціль, потім предмет, і вже потім засоби та все інше.
З першим питанням "навіщо" - вже трохи розібрались в попередньому пості, давайте спробуємо глибше розібратись з другим: "ШО?"
В питаннях покращення, як і у всьому, що стосується тестування, наріжним каменем виступає якість.
На ранніх етапах знайомства із тестуванням (ISTQB Foundation) ми вчимось описувати незрозумілу та аморфну якість програмного забезпечення за допомогою детермінованих атрибутів. Разом із професійним дорослішанням (ISTQB Advanced) в нас все краще й краще виходить цю якість вимірювати. І, нарешті, досягаючи рівня експерта (ISTQB Expert), ми дізнаємось, що наше стале розуміння якості не є таким вже однозначним, бо навіть зберігаючи всі свої атрибути, якість може виглядати дуже по різному для різних компаній та проектів.
Метафорою в даному випадку є роздоріжжя. Ми визначили мету подорожі (навіщо нам покращувати тестування) та вже точно вирішили вирушати в дорогу (покращувати), але ось за 100 метрів від початку шляху зустріли вказівник: шляхів декілька й всі вони різні.
Кожен з таких шляхів - це різний фокус та пріоритети у сприйнятті якості тією організацією, для якої ви збираєтесь покращувати процеси тестування.
ISTQB Expert Level виділяє п'ять кутів зору на якість, в контексті покращення процесів тестування:
📦 Продуктовий. Здебільшого фокусується на нефункціональних характеристиках якості, таких як наприклад ефективність, супроводженість, мобільність продукту.
⚙️ Виробничий. Фокус на повторюваних ефективних процесах, які забезпечують відповідність продукту вимогам.
👤 Користувацький. В голові кута - рівень задоволення користувачів від продукту.
💰 Ціннісний. Про баланс між якістю та вартістю.
🧘 Трансцендентний. Або "інтегральний" - про поширення контексту якості продукту на непряму користь від нього всьому суспільству.
Нам на практиці поки що, нажаль, не доводилось консультувати з приводу покращення тестування організації, які орієнтувались би на "трансцендентну" якість :) але зо всіма іншими кутами зору на якість, так чи інакше маємо справу.
Ось що каже з цього приводу ISTQB: "Кожен раз ми повинні питати себе: яку найбільшу кількість атрибутів якості (📦) ми можемо впровадити для вирішення задач наших користувачів (👤) підтримуючи при цьому найкраще співвідношення вартості та вигоди (💰) та слідуючи ефективному та повторюваному процесу виробництва (⚙️)"
І хоч дійсно, здебільшого ми так і маємо справу з балансом між різними аспектами якості, все ж таки коректне визначення того чим є якість для цільової організації - може суттєво вплинути на стратегію впровадження покращень: методи й інструменти, ресурси, KPI для вимірювання успішності впроваджених змін.
А який присмак має якість на вашому проекті?
#istqb #expert #longread
Уявімо, що ми з вами, для чогось або когось, починаємо процес покращення чогось, щоб щось стало краще 🤔 Звісно мова все ще про тестування 😄. При всій своїй невинно прекрасній простоті, саме з цим рівнем чіткості досить часто доводиться мати справу у практиці професійного "покращувача-процесів-тестування".
І якщо ми хочемо корисних змін у процес то задаємось запитаннями: "навіщо ці зміни?", "що ми власне збираємось змінювати на краще?". Причому саме у такій послідовності: спочатку ціль, потім предмет, і вже потім засоби та все інше.
З першим питанням "навіщо" - вже трохи розібрались в попередньому пості, давайте спробуємо глибше розібратись з другим: "ШО?"
В питаннях покращення, як і у всьому, що стосується тестування, наріжним каменем виступає якість.
На ранніх етапах знайомства із тестуванням (ISTQB Foundation) ми вчимось описувати незрозумілу та аморфну якість програмного забезпечення за допомогою детермінованих атрибутів. Разом із професійним дорослішанням (ISTQB Advanced) в нас все краще й краще виходить цю якість вимірювати. І, нарешті, досягаючи рівня експерта (ISTQB Expert), ми дізнаємось, що наше стале розуміння якості не є таким вже однозначним, бо навіть зберігаючи всі свої атрибути, якість може виглядати дуже по різному для різних компаній та проектів.
Метафорою в даному випадку є роздоріжжя. Ми визначили мету подорожі (навіщо нам покращувати тестування) та вже точно вирішили вирушати в дорогу (покращувати), але ось за 100 метрів від початку шляху зустріли вказівник: шляхів декілька й всі вони різні.
Кожен з таких шляхів - це різний фокус та пріоритети у сприйнятті якості тією організацією, для якої ви збираєтесь покращувати процеси тестування.
ISTQB Expert Level виділяє п'ять кутів зору на якість, в контексті покращення процесів тестування:
📦 Продуктовий. Здебільшого фокусується на нефункціональних характеристиках якості, таких як наприклад ефективність, супроводженість, мобільність продукту.
⚙️ Виробничий. Фокус на повторюваних ефективних процесах, які забезпечують відповідність продукту вимогам.
👤 Користувацький. В голові кута - рівень задоволення користувачів від продукту.
💰 Ціннісний. Про баланс між якістю та вартістю.
🧘 Трансцендентний. Або "інтегральний" - про поширення контексту якості продукту на непряму користь від нього всьому суспільству.
Нам на практиці поки що, нажаль, не доводилось консультувати з приводу покращення тестування організації, які орієнтувались би на "трансцендентну" якість :) але зо всіма іншими кутами зору на якість, так чи інакше маємо справу.
Ось що каже з цього приводу ISTQB: "Кожен раз ми повинні питати себе: яку найбільшу кількість атрибутів якості (📦) ми можемо впровадити для вирішення задач наших користувачів (👤) підтримуючи при цьому найкраще співвідношення вартості та вигоди (💰) та слідуючи ефективному та повторюваному процесу виробництва (⚙️)"
І хоч дійсно, здебільшого ми так і маємо справу з балансом між різними аспектами якості, все ж таки коректне визначення того чим є якість для цільової організації - може суттєво вплинути на стратегію впровадження покращень: методи й інструменти, ресурси, KPI для вимірювання успішності впроваджених змін.
А який присмак має якість на вашому проекті?
ISTQB Foundation level
#istqb
Привіт! Минулого тижня наш авторський склад відверто упоровся по ISTQB. Тому треба все це зафіксувати й зібрати в одному місці/пості всі дописи CTFL.
🤓 Intro - Посилання та загальний підхід
🧱 Fundamentals of Testing - основи та ключові моменти тестування
🔄 Testing Throughout the Software Development Lifecycle - життєві цикли розробки ПЗ, типи та рівні тестування
📖 Static testing - види статичного тестування і нащо воно треба
📊 Test Techniques - окремого посту ми не робили, оскільки мали до цього низку статей про тест дизайн, можна знайти за тегом #testdesign
👨💼 Test management - робота в команді, стратегії тестування, оцінка роботи, ризики #risks
🛠 Tools Support for Testing - види інструментів для тестування, критерії їх оцінки для роботи та кроки для впровадження
Як вам збірка? Корисно? Чи не зробити ще кілька? За рік ми написали багато дописів, що гарно було б систематизувати
#istqb
Привіт! Минулого тижня наш авторський склад відверто упоровся по ISTQB. Тому треба все це зафіксувати й зібрати в одному місці/пості всі дописи CTFL.
🤓 Intro - Посилання та загальний підхід
🧱 Fundamentals of Testing - основи та ключові моменти тестування
🔄 Testing Throughout the Software Development Lifecycle - життєві цикли розробки ПЗ, типи та рівні тестування
📖 Static testing - види статичного тестування і нащо воно треба
📊 Test Techniques - окремого посту ми не робили, оскільки мали до цього низку статей про тест дизайн, можна знайти за тегом #testdesign
👨💼 Test management - робота в команді, стратегії тестування, оцінка роботи, ризики #risks
🛠 Tools Support for Testing - види інструментів для тестування, критерії їх оцінки для роботи та кроки для впровадження
Як вам збірка? Корисно? Чи не зробити ще кілька? За рік ми написали багато дописів, що гарно було б систематизувати
The Generic Improvement Process
#istqb #expert #longread #test_improvement
🔰 Цикл Демінга
Постійне покращення процесів вимагає встановлення цілей, вимірювання ступіні їх виконання та, коли цілі досягнені, вибір нових цілей. Цикл Демінга - корисний загальний фреймворк для постійного покращення і він складається з наступних кроків:
❇️ Plan - цілі визначаються поточними характеристиками якості, бюджетом та рівнем зрілості QA послуг. Формулюються менеджментом для покращення бізнесу і розбиваються на індивідуальні "контрольні пункти" для того, щоб було зрозуміло, які активності вже виконано. Цілі мають бути вимірювані (як - інше питання, розглянемо пізніше)
❇️ Do - після розробки плану - він виконується
❇️ Check - перевіряються "контрольні пункти", визначені раніше, для оцінки прогресу, відхилень від плану та передбачення часу виконання
❇️ Act - (іноді зустрічається "Analyze/Act") - аналіз інформації, отриманої в процесі покращення для планування подальших дій
🔰 фреймворк покращення IDEAL
Походить від описаного вище циклу Демінга та розширює його. Назва - абревіатура з перших літер назв фаз:
✳️ Initiating
- визначення причини щось покращувати
- встановлення контексту та спонсорства (хто за це заплатить)
- Створення інфраструктури для покращення
✳️ Diagnosing
- оцінка поточних практик
- розробка рекомендацій та документація результатів фази
✳️ Establishing
- вибір стратегії та пріоритезація
- Створення групи тестових процесів
- планування дій
✳️ Acting
- Визначення процесів та їх оцінки
- планування та розробка пілотів (демо)
- планування, розробка та контроль впровадження
✳️ Learning
- Документування та аналіз результатів
- Рев'ю організаційних підходів
🔰 Основні Принципи Досконалості (Fundamental Concepts of Excellence)
Цей фреймворк використовується глобально в моделях досконалості цілих організацій для оцінки за 8 критеріями. Європейський Фонд Управління Якістю (EFQM) надає приклад EFQM-Web, на який і посилається ISTQB Syllabus:
1️⃣ Results Orientation - досконалість залежить від рівноваги і задоволення потреб всіх учасників (і команди, і замовника) та від фінансових інтересів організації
2️⃣ Customer Focus - замовник - наше все! Він дає фінальну оцінку продукту чи сервісу, тому наша задача - задовільнити його в першу чергу
3️⃣ Leadership & Constancy of Purpose - від поведінки менеджмента залежить якість і прозорість процесів організації (натякають, що треба прокачувати менеджмент скіли і не бути мудаком)
4️⃣ Management by Processes & Facts - організація працює добре, коли всі процеси в ній всім зрозумілі та керовані (всі знають, що мають робити) та всі дії робляться за планом
5️⃣ People Development & Involvement - показати весь потенціал організація може, якщо всі співробітники мають спільні цінності та культуру довіри, мотивації всіх
6️⃣ Continuous Learning, Innovation & Improvement - продуктивність організації буде більша, якщо є knowledge sharing, культура постійного навчання та інновацій
7️⃣ Partnership Development - організація працює ефективно, якщо робота побудована на довірі між всіма співробітниками та замовниками
8️⃣ Corporate Social Responsibility - організація має бути зацікавлена в своїх співробітниках, піклуватись про них та мати довготривалі інтереси на благо суспільства
За моїм досвідом, найбільш універсальним процесом був і залишається цикл Демінга - простий і всім відомий. IDEAL - можна спробувати, оскільки він розширює цикл. Принципи досконалості - повна шляпа. Звучить як мотиваційна хрінь без будь-якої конкретики.
А чи покращували тестування у вашій компанії? За яким процесом?
#istqb #expert #longread #test_improvement
🔰 Цикл Демінга
Постійне покращення процесів вимагає встановлення цілей, вимірювання ступіні їх виконання та, коли цілі досягнені, вибір нових цілей. Цикл Демінга - корисний загальний фреймворк для постійного покращення і він складається з наступних кроків:
❇️ Plan - цілі визначаються поточними характеристиками якості, бюджетом та рівнем зрілості QA послуг. Формулюються менеджментом для покращення бізнесу і розбиваються на індивідуальні "контрольні пункти" для того, щоб було зрозуміло, які активності вже виконано. Цілі мають бути вимірювані (як - інше питання, розглянемо пізніше)
❇️ Do - після розробки плану - він виконується
❇️ Check - перевіряються "контрольні пункти", визначені раніше, для оцінки прогресу, відхилень від плану та передбачення часу виконання
❇️ Act - (іноді зустрічається "Analyze/Act") - аналіз інформації, отриманої в процесі покращення для планування подальших дій
🔰 фреймворк покращення IDEAL
Походить від описаного вище циклу Демінга та розширює його. Назва - абревіатура з перших літер назв фаз:
✳️ Initiating
- визначення причини щось покращувати
- встановлення контексту та спонсорства (хто за це заплатить)
- Створення інфраструктури для покращення
✳️ Diagnosing
- оцінка поточних практик
- розробка рекомендацій та документація результатів фази
✳️ Establishing
- вибір стратегії та пріоритезація
- Створення групи тестових процесів
- планування дій
✳️ Acting
- Визначення процесів та їх оцінки
- планування та розробка пілотів (демо)
- планування, розробка та контроль впровадження
✳️ Learning
- Документування та аналіз результатів
- Рев'ю організаційних підходів
🔰 Основні Принципи Досконалості (Fundamental Concepts of Excellence)
Цей фреймворк використовується глобально в моделях досконалості цілих організацій для оцінки за 8 критеріями. Європейський Фонд Управління Якістю (EFQM) надає приклад EFQM-Web, на який і посилається ISTQB Syllabus:
1️⃣ Results Orientation - досконалість залежить від рівноваги і задоволення потреб всіх учасників (і команди, і замовника) та від фінансових інтересів організації
2️⃣ Customer Focus - замовник - наше все! Він дає фінальну оцінку продукту чи сервісу, тому наша задача - задовільнити його в першу чергу
3️⃣ Leadership & Constancy of Purpose - від поведінки менеджмента залежить якість і прозорість процесів організації (натякають, що треба прокачувати менеджмент скіли і не бути мудаком)
4️⃣ Management by Processes & Facts - організація працює добре, коли всі процеси в ній всім зрозумілі та керовані (всі знають, що мають робити) та всі дії робляться за планом
5️⃣ People Development & Involvement - показати весь потенціал організація може, якщо всі співробітники мають спільні цінності та культуру довіри, мотивації всіх
6️⃣ Continuous Learning, Innovation & Improvement - продуктивність організації буде більша, якщо є knowledge sharing, культура постійного навчання та інновацій
7️⃣ Partnership Development - організація працює ефективно, якщо робота побудована на довірі між всіма співробітниками та замовниками
8️⃣ Corporate Social Responsibility - організація має бути зацікавлена в своїх співробітниках, піклуватись про них та мати довготривалі інтереси на благо суспільства
За моїм досвідом, найбільш універсальним процесом був і залишається цикл Демінга - простий і всім відомий. IDEAL - можна спробувати, оскільки він розширює цикл. Принципи досконалості - повна шляпа. Звучить як мотиваційна хрінь без будь-якої конкретики.
А чи покращували тестування у вашій компанії? За яким процесом?
Що робити, коли нічого робити?
Привіт друзі! Минулого тижня мало писали - роботи побільшало. Цього тижня спробуємо надолужити темп і поділитись чимось цікавим.
Іноді так буває, що ви зробили всю роботу раніше, ніж заплановано. Чи тільки почали проєкт і задач на цілий робочий день ще немає. Чи видали продукт в реліз, чекаєте на фідбек користувачів. Що робити, коли нічого роботи? (до речі, я люблю питати таке на співбесідах, щоб зрозуміти, що буде робити потенційний колега, якщо перестати його менеджити)
Так от, зі свого досвіду, я маю наступний список дій, сортованих по пріоритету:
✅ знайти роботу 1 - так, це банально, але часто буває, що твій менеджер завантажений і не має часу знайти тобі задачу. Можна проявити ініціативу і попросити щось для себе. Наступний рівень - знайти кілька задач з беклогу, почитати чи привести в порядок документацію, і запропонувати менеджеру, що можу ось цими задачами зараз зайнятись, поки не з'явиться чогось більш пріоритетного
✅ знайти роботу 2 - Все трохи складніше, коли ти сам менеджер. І маєш зайняти себе і команду. Власне, активності для команди можна поставити ті самі, з першого пункту. Можна делегувати прийняття рішення, яку роботу робити команді і потім перевірити результати. А ще можна влаштовувати сесії KT (knowledge sharing) - вони дають всій команді більше уявлення про різні функції та зменшують ризики простою у випадку втрати спеціаліста
✅ саморозвиток - зробити щось корисне для себе, щоб покращити свою подальшу роботу. Вивчити автоматизацію, наприклад, і випробувати її в своєму проєкті
✅ прочитати книгу - не обов'язково дізнаватись щось нове, можна систематизувати вже існуючи знання і, наприклад, підготуватись до екзамену #istqb
Думав, пунктів буде більше :)
А що ви робите, якщо незавантажені роботою?
Привіт друзі! Минулого тижня мало писали - роботи побільшало. Цього тижня спробуємо надолужити темп і поділитись чимось цікавим.
Іноді так буває, що ви зробили всю роботу раніше, ніж заплановано. Чи тільки почали проєкт і задач на цілий робочий день ще немає. Чи видали продукт в реліз, чекаєте на фідбек користувачів. Що робити, коли нічого роботи? (до речі, я люблю питати таке на співбесідах, щоб зрозуміти, що буде робити потенційний колега, якщо перестати його менеджити)
Так от, зі свого досвіду, я маю наступний список дій, сортованих по пріоритету:
✅ знайти роботу 1 - так, це банально, але часто буває, що твій менеджер завантажений і не має часу знайти тобі задачу. Можна проявити ініціативу і попросити щось для себе. Наступний рівень - знайти кілька задач з беклогу, почитати чи привести в порядок документацію, і запропонувати менеджеру, що можу ось цими задачами зараз зайнятись, поки не з'явиться чогось більш пріоритетного
✅ знайти роботу 2 - Все трохи складніше, коли ти сам менеджер. І маєш зайняти себе і команду. Власне, активності для команди можна поставити ті самі, з першого пункту. Можна делегувати прийняття рішення, яку роботу робити команді і потім перевірити результати. А ще можна влаштовувати сесії KT (knowledge sharing) - вони дають всій команді більше уявлення про різні функції та зменшують ризики простою у випадку втрати спеціаліста
✅ саморозвиток - зробити щось корисне для себе, щоб покращити свою подальшу роботу. Вивчити автоматизацію, наприклад, і випробувати її в своєму проєкті
✅ прочитати книгу - не обов'язково дізнаватись щось нове, можна систематизувати вже існуючи знання і, наприклад, підготуватись до екзамену #istqb
Думав, пунктів буде більше :)
А що ви робите, якщо незавантажені роботою?
Підсумки року 2020
#qamania
Вітаємо всіх! Вже наступного дня ми замість того щоб гортати сторінки календаря - замінимо його на новий, дістанемо подарунки з під ялинки, дзвінко зустрінемось келихом ігристого з кимось нам близьким, сподіваємось особисто, але накрайняк можна й по зуму ;)
Та, пригадавши події двадцятого, зітхнемо з полегшенням, або ж посміхнемось з вдячністю - це вже хто що пригадає :)
Ми в QAMania з вдячністю за дуже різноманітний досвід проводжатимемо 20-й та з оптимізмом дивитимемось та будуватимемо плани на 21-й.
Дещо з того, що пригадується за 20-й:
👥 Канал росте. В 20-му ми отримали можливість ділитись досвідом та думками з більшою кількістю людей. +1000. Починали рік з 214, закінчуємо з майже 1,300 підписників. В планах подальше зростання. Дякуємо, що з нами.
⭐️ Якість та кількість матеріалів. За 20-й зробили 188 дописів. Загальна ж кількість постів в каналі на даний момент: 278. Так само намагаємось писати кожен день, але в цьому році досить часто перемагав внутрішній перфекціоніст, тому з однієї сторони - не завжди вдавалось кожен день, з іншої - стало більше власних статей, лонгрідів та особистих думок.
📣 Нові формати. В цьому році ми започаткували наш youtube канал, спочатку суто для студентів в рамках курсу з тестування в КПІ, але потім й для класних технічних воркшопів. Завдяки одній добрій людині почали партнеритись з організаторами різних подій, конференцій, привели трохи до ладу facebook сторінку. Зареєструвались в google maps - тепер qamania можна знайти й там :)
Пробували навіть Pinterest для нашої рубрики #linkz, та й взагалі багато чого іншого пробували, але не все пішло 🤷♂️
💡 Рубрики. Очікувано позитивні враження отримали від нової рубрики #quiz з питаннями по теорії тестування за мотивами istqb - судячи з кількості відповідей, вам також сподобалось :) Багато писали власне про #istqb - також популярна тема, судячи з кількості вподобайок та відгуків. Плануємо продовжувати як з istqb, так і з опитувальниками. Взагалі ось наші топ рубрики, які мають від 10 постів:
#learnit 58
#tools 43
#truestory 26
#friday 20
#istqb 20
#bugseverywhere 15
#longread 15
#automation 14
#linkz 11
#fun 11
#testdesign 10
А які рубрики були до вподоби вам? Чи може якихось не вистачало? Напишіть в коментах.
🎬 Події. Стікерпаки з багами, "кріпто-квест" з призами, конференції, мітапи, статті на ДОУ. Є що пригадати :) Та й на наступний рік деякі ідеї вже є.
Якщо й ви маєте такі ідеї - напишіть нам в коменти, може вдасться їх реалізувати :)
Рік відбувся. Збагатив всіх нас новим досвідом, когось позитивним, когось нажаль й негативним, а когось просто неочікуваним.
Залишаємось на зв'язку :)
Дякуємо, що з нами!
QAMania
#qamania
Вітаємо всіх! Вже наступного дня ми замість того щоб гортати сторінки календаря - замінимо його на новий, дістанемо подарунки з під ялинки, дзвінко зустрінемось келихом ігристого з кимось нам близьким, сподіваємось особисто, але накрайняк можна й по зуму ;)
Та, пригадавши події двадцятого, зітхнемо з полегшенням, або ж посміхнемось з вдячністю - це вже хто що пригадає :)
Ми в QAMania з вдячністю за дуже різноманітний досвід проводжатимемо 20-й та з оптимізмом дивитимемось та будуватимемо плани на 21-й.
Дещо з того, що пригадується за 20-й:
👥 Канал росте. В 20-му ми отримали можливість ділитись досвідом та думками з більшою кількістю людей. +1000. Починали рік з 214, закінчуємо з майже 1,300 підписників. В планах подальше зростання. Дякуємо, що з нами.
⭐️ Якість та кількість матеріалів. За 20-й зробили 188 дописів. Загальна ж кількість постів в каналі на даний момент: 278. Так само намагаємось писати кожен день, але в цьому році досить часто перемагав внутрішній перфекціоніст, тому з однієї сторони - не завжди вдавалось кожен день, з іншої - стало більше власних статей, лонгрідів та особистих думок.
📣 Нові формати. В цьому році ми започаткували наш youtube канал, спочатку суто для студентів в рамках курсу з тестування в КПІ, але потім й для класних технічних воркшопів. Завдяки одній добрій людині почали партнеритись з організаторами різних подій, конференцій, привели трохи до ладу facebook сторінку. Зареєструвались в google maps - тепер qamania можна знайти й там :)
Пробували навіть Pinterest для нашої рубрики #linkz, та й взагалі багато чого іншого пробували, але не все пішло 🤷♂️
💡 Рубрики. Очікувано позитивні враження отримали від нової рубрики #quiz з питаннями по теорії тестування за мотивами istqb - судячи з кількості відповідей, вам також сподобалось :) Багато писали власне про #istqb - також популярна тема, судячи з кількості вподобайок та відгуків. Плануємо продовжувати як з istqb, так і з опитувальниками. Взагалі ось наші топ рубрики, які мають від 10 постів:
#learnit 58
#tools 43
#truestory 26
#friday 20
#istqb 20
#bugseverywhere 15
#longread 15
#automation 14
#linkz 11
#fun 11
#testdesign 10
А які рубрики були до вподоби вам? Чи може якихось не вистачало? Напишіть в коментах.
🎬 Події. Стікерпаки з багами, "кріпто-квест" з призами, конференції, мітапи, статті на ДОУ. Є що пригадати :) Та й на наступний рік деякі ідеї вже є.
Якщо й ви маєте такі ідеї - напишіть нам в коменти, може вдасться їх реалізувати :)
Рік відбувся. Збагатив всіх нас новим досвідом, когось позитивним, когось нажаль й негативним, а когось просто неочікуваним.
Залишаємось на зв'язку :)
Дякуємо, що з нами!
QAMania
