is there any start stop boundary qa s role scrum
Яка роль контролю якості в Scrum: Діяльність Scrum для тестувальників
Ця стаття - це не просто підручник з деяких процесів, методів чи інструкцій щодо роботи в якості контролю якості. Швидше, це стаття, в якій я хочу поділитися власним досвідом роботи старшим контролером якості в SCRUM.
Мій попередній технічний директор завжди говорив це «Зі свободою приходить відповідальність». Якщо ви отримали свободу робити свою роботу по-своєму, то відповідальність за свою роботу, завдання чи діяльність несете тільки ви і лише ви.
Це те, про що Scrum !! Дозвольте мені дати вам основне уявлення про Scrum, коли ми продовжуватимемо далі.
Що ви дізнаєтесь:
Огляд Scrum
Scrum - це підмножина спритна методологія і є полегшеною технологічною системою, яка широко використовується.
Scrum допомагає нам робити клієнтів щасливими, надаючи їм товар у невеликих модулях, а також інформує клієнта про те, що їх часто мінливі вимоги можуть уповільнити діяльність. Випуски короткі, і робота ведеться відповідно до можливостей задіяної команди, отже ймовірність невдач або нещасних клієнтів значною мірою зменшується.
З іншого боку, вимоги (в даному випадку Історії користувачів) доопрацьовуються перед запуском Sprint, щоб уникнути переробки, а отже спричиняє відкладений або невдалий Sprint (виключення завжди є).
Але найбільшою проблемою для забезпечення якості є те, що тривалість випуску коротка, спринт - це, в основному, 15-денний цикл. Отже, для того, щоб доставити продукт, що не містить помилок, максимум за 4-5 днів (не витрачаючи часу на розробку) потрібно докласти багато зусиль та розумного мислення.
Я QA своєї команди:
О так, я - QA своєї команди, і я є важливим гравцем своєї команди. Чому ?? Оскільки клієнти, BA, Scrum Master та всі інші нечітко ставляться до якості, зовнішнього вигляду та продуктивності програми чи продукту.
У Scrum, оскільки тривалість спринту невелика, контроль якості повинен виконувати розумно, а отже потреба з боку контролю якості брати участь із самого початку, тому що «планування» стає дуже важливим. Бувають випадки, коли система контролю якості може виконувати роль власника проксі-продукту, коли заявка на замовлення недоступна, що допомагає BA до створення сценаріїв / випадків тестування критеріїв прийняття.
Розробники також підходять до контролю якості у випадках, коли вони стикаються з проблемами з функціональністю чи правилами бізнесу. У Scrum основна увага приділяється лише плавному та успішному випуску Sprint, і мова не йде про «Моя робота» чи «Ваша робота», щоб допомогти, коли ваша команда звертається до вас за допомогою.
У поєднанні команд Scrum здорові стосунки між членами команди відіграють надзвичайно важливу роль, і, будучи контролем якості, ви повинні бути дуже обережними, повідомляючи свою думку щодо історій користувачів, які ви тестуєте. Ваше спілкування має стосуватися історії користувача чи функціоналу, а не людини, яка над цим працювала.
У Scrum QA не оцінюють і не оцінюють за кількість помилок, які він / вона виявляє, а також за те, як він / вона взаємодіє з командою, допомагає команді та мотивує команду навіть у важкі часи.
Окрім тестування спринтерських завдань, написання тестових планів / тестових кейсів / документів про випуск також намагається залучити більше, оскільки тривалість випуску Спринту коротка, а мета однакова для всіх «Успішно доставити діючий продукт без помилок, допомагаючи один одному».
Організація контролю якості бере участь у майже всіх видах діяльності, що проводяться у спринті, і технічно не існує меж для початку чи зупинки діяльності з контролю якості. На відміну від традиційної моделі Waterfall, коли QA обмежується лише тестуванням випуску, тут QA несе набагато більше відповідальності. Отже, я б запропонував спробувати та виконати більше таких дій.
Діяльність, яку слід дотримуватися
Нижче наведено декілька видів діяльності, які я б запропонував вам виконувати як QA в Scrum.
Запитання щодо інтерв’ю pl sql за 3 роки досвіду
# 1) Жити глибше:
Під цим я маю на увазі, що коли історії користувачів та критерії їх прийняття будуть готові, ретельно вивчіть їх і глибше продумайте залежності, приховані результати та чи є кращий спосіб це зробити.
Спілкуйтеся і співпрацюйте з BA та командою розробників з цього приводу, тому що може трапитися так, що вони, можливо, і не думали про це. Поділіться своїми ідеями та знахідками з командою.
Якщо ви виявите, що існують приховані перешкоди чи негативні наслідки, то підняття їх за допомогою Scrum Master і розробників дасть їм час подумати і діяти відповідно. Ця діяльність у Scrum стає дуже важливою, коли проект масштабний і коли є модулі, розподілені по командах.
Зараз під час вивчення залежностей вплив дуже важливий для контролю якості, і це навіть змушує команду розробників про це знати. Для цього обговоріть із QAs інших команд та отримайте від них інформацію.
# 2) Участь у оцінках:
Звичайною практикою є залучення контролю якості до оцінок, але багато разів, через невеликий спринт, контроль якості може не вимагати оцінки для тестування завдань і залишати їм 3/4 / 5 днів для роботи.
Ніколи не приймайте цього. Підніміть свій голос, якщо вам потрібно, але переконайтеся, що ви надаєте свою оцінку тестування, яка повинна включати час, необхідний для кожної роботи.
Він може включати час для досліджень, час для налаштувань, час для збору історичних даних тощо, але суворо і конкретно щодо часу, необхідного для проведення тестових дій, і додавання цих значень часу до історії користувача разом із часом розробки завдань .
Це дуже важливо, тому що якщо ви спробуєте виконати свою роботу у відведений час і якщо ви не зможете виконати, лише ви несете відповідальність за невдачу. Коли додається час контролю якості, керівник Scrum, замовник буде знати про заходи, що стосуються контролю якості, і необхідний час.
# 3) Сполучення контролю якості Dev:
В ідеалі, в Scrum, історії користувачів Sprint передаються на тестування після завершення розробки та після завершення тестування розробника, але проблема тут полягає в тому, що до моменту передачі в QA для тестування ледве 4-5 днів до демонстрації або огляду залишаються.
Тепер, якщо в якості контролю якості ви виявите навіть 4 блокатори або функціональні збої, вам доведеться працювати пізно ввечері або у вихідні, щоб дотримати дати випуску, оскільки для цього потрібно буде провести функціональне тестування, регресію тощо. Це здається традиційною моделлю водоспаду, що не найкращий спосіб зробити, у Scrum це найрозумніший спосіб “Запобігати дефектам, а не знаходити їх”.
Отже, рішення полягає в тому, щоб виконати сполучення QA для розробників та виконати базовий раунд тестування на налаштуваннях розробника, як тільки розробники будуть готові до публікацій ще до офіційного випуску для тестування.
Наступні критерії можна взяти до уваги, щоб зробити BVT для налаштування розробника для історій користувачів:
- Критерії прийнятності для кожної історії користувача: BVT історій користувачів відповідно до критеріїв прийняття.
- Відсутність довіри до розробників: Іноді розробники не впевнені в деяких реалізаціях, і тому вони обговорюють такі реалізації та роблять BVT для тих, хто працює на тій же програмі розробника.
- Залежності / Тестування впливу: BVT залежностей або впливу на / інших модулів нових реалізацій.
- Одиничне тестування: Зробіть BVT із розробником створених ними модульних тестів, якщо потрібно, допоможіть їм, додавши або оновивши модульні тести.
Це допоможе зменшити кількість помилок і заощадити час, заощадити час кожного, оскільки до випуску в QA більшість помилок, що аварійно завершують роботу, або функціональних помилок вже виправлені. Не забудьте зареєструвати ці дефекти у своїх інструментах перед оглядом спринту та перенести їх до стану «закритого».
# 4) Якість на білій дошці:
Я завжди особисто заохочував свою команду включати завдання з контролю якості на дошку White Scrum, включаючи помилки. Це допомагає Scrum Master визначити стан контролю якості історії користувача, просто подивившись на дошку.
Ні. помилок у списку 'Завдання', помилки у списку 'Виконується', діяльність з контролю якості в списку 'Виконання', 'Виконується' та 'Готово' говорять самі за себе. Мені дуже боляче, коли хтось приходить запитувати про стан тестування окремих історій для Спринту, тому що мені доводиться витрачати зайвий час, щоб зняти свій статус із інструментів компіляції та показати їх або скласти електронний лист.
Я просто волію вказати цю людину на Раду Scrum і дозволити їй це зробити для себе. Віддайте перевагу яскравим яскравим кольорам для липких накладок QA.
# 5) Документація:
Це один з недоліків або мінусів Scrum, оскільки через невеликий розмір Sprint часу на документацію мало, і я ніколи не бачив технічного письменника в команді Scrum. Scrum Master / BA може не завжди і не завжди оновлювати документи про інформацію про товар.
Проблема виникає в тому випадку, якщо приєднуються нові члени або в гіршому випадку, якщо змінюються правила бізнесу, функціональні можливості, і як відстежувати їх, оскільки пошук в історії “Готово” для користувачів буде подібний до пошуку голки в копиці сіна.
Рішення полягає в тому, щоб створити окреме завдання в спринті, коли це можливо (здебільшого в слабкі часи або коли навантаження значно менше) для документації, щоб ви могли переглянути документи та оновити або зробити так, щоб Scrum Master або BA оновлювали їх.
Служба контролю якості - це потрібна особа, яка допоможе в оновленні документів, оскільки саме ви перевіряєте, перевіряєте історії користувачів і знаєте, які функції входять і виходять. Зробіть це самостійно, якщо немає BA і якщо ваш Scrum Master зайнятий оновленням.
# 6) Огляд спринту / Демонстрація спринту:
Здебільшого трапляється, що QA є тим, кого обирають для демонстрації демонстрації для PO та зацікавлених сторін. але якщо не переконати свого Scrum Master зробити це. QA - це правильна людина, яка повинна демонструвати демонстрацію, оскільки вона / вона перевірила історію користувача в і поза.
QA може демонструвати з точки зору бізнесу, оскільки вони знають функціональні можливості, потоки та правила бізнесу. Добре підготуйтеся до демонстрації та спробуйте відповісти на кожне запитання, яке виникає у організацій замовлення та зацікавлених сторін. Це допоможе вам стати контактною особою для них за відсутності Scrum Master та BA.
# 7) Дійте як BA:
Це не звичайне завдання, яке навіть не очікується від контролю якості, але намагайтеся потрапити в цю роль, коли випадає шанс, тому що контроль якості - найкраща людина для того, щоб бути бакалавром. Наприклад, спробуйте подумати та уявити, чи можна змінити потоки, функціональні можливості чи ділові правила таким чином, щоб це було на користь клієнту.
Подумайте та знайдіть сучасні тенденції в інтерфейсі користувача, зовнішній вигляд програми та те, як її можна зробити беатифікованою, зробити її більш зручною тощо. Якщо команда застрягла в якійсь проблемі, залучіться та спробуйте дати простий та розумний рішення. Це дасть поштовх вашій ролі та стане фактором, що сприятиме вашому кар’єрному зростанню.
Шанси виникають під час дзвінків із організацією замовлення, коли обговорюються деякі проблеми або в процесі огляду / демонстрації, де ви можете дати пропозиції.
Висновок
Scrum - це зовсім інша методологія від звичайного методу Waterfall, а Scrum Master - фасилітатор. Тому не сподівайтесь, що він / вона визначатиме для вас вашу діяльність.
У Scrum немає початкової та кінцевої меж для ролі контролю якості. QA потребує і повинен брати участь у будь-якій діяльності з самого початку до кінця, від попереднього планування до огляду / демонстрації спринту та повинен брати участь у всіх заходах.
Це допоможе зрозуміти продукт або програму, оскільки (як я вже говорив раніше) під час роботи в Scrum немає належної документації. Від вас очікують відповідальності, мотивації та ініціативи. Тому не чекайте, коли хтось прийде і скаже вам, що і як ви повинні робити.
Вам слід брати на себе ініціативи, всіляко допомагати команді, підтримувати здорові стосунки, стежити за тим, що відбувається в команді, і найголовніше чітко розуміти свої завдання в даному спринті.
Тут немає менеджерів, які б стежили за вами або відстежували вашу діяльність. Завжди будьте готові допомогти своїй команді, і ви отримаєте найкращі можливості.
Не соромтеся висловлювати свої думки / пропозиції щодо цієї інформативної статті в розділі коментарів нижче.
Рекомендована література
- Роль бізнес-аналітиків у SCRUM та чому найкращий контроль якості для цієї ролі?
- Інтернет-вікторина Agile Scrum: Перевірте свої знання про Agile Scrum
- Встановіть свою програму на пристрій і починайте тестування з Eclipse
- Канбан проти Scrum проти Agile: Детальне порівняння, щоб знайти відмінності
- Як за короткий проміжок часу надати високоякісні функції програмного забезпечення за допомогою Agile Scrum
- Спритний маніфест: розуміння спритних цінностей та принципів
- Випробування дефектів у Scrum: як це організовано в налаштуванні Scrum
- Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)