is there any start stop boundary qa s role scrum
Каква е ролята на QA’s в Scrum: Scrum дейности за тестерите
Тази статия не е само урок за някои процеси или методи или инструкции за това как да работите като QA. По-скоро това е статия, в която искам да споделя собствения си опит от работата като старши QA в SCRUM.
Предишният ми технически директор винаги го казваше ‘Със свободата идва и отговорността’. Ако ви е дадена свободата да вършите работата си по вашия начин, тогава вие и само вие сте отговорни за вашата работа или задачи или дейности.
Ето за какво е Scrum !! Позволете ми да ви дам основна идея за Scrum, докато продължаваме по-нататък.
Какво ще научите:
Преглед на Scrum
Scrum е подмножество на пъргава методология и е лека технологична рамка, която се използва широко.
Scrum ни помага да поддържаме клиентите доволни, като им предоставя продукта в малки модули, а също така държи клиента в течение, че техните често променящи се изисквания могат да забавят дейностите. Изданията са кратки и се работи според капацитета на участващия екип, поради което шансовете за неуспехи или нещастни клиенти намаляват до голяма степен.
От друга страна, изискванията (в този случай Потребителски истории) са финализирани преди старта на Sprint, за да се избегне преработката и по този начин води до забавен или неуспешен Sprint (изключения винаги има).
Но най-голямото предизвикателство за QA е, че периодът на освобождаване е кратък, а Sprint е предимно 15-дневен цикъл. Следователно, доставянето на „безплатен“ продукт за грешки за максимум 4-5 дни (като се извади времето за разработка) се нуждае от много усилия и интелигентно мислене.
Аз съм QA на моя екип:
О, да, аз съм QA на моя отбор и съм важен играч на моя отбор. Защо?? Тъй като клиентите, BA, Scrum Master и всички останали са размити по отношение на качеството, външния вид и усещането и работата на приложението или продукта.
В Scrum, тъй като продължителността на спринта е кратка, QA трябва да се представи по интелигентен начин и следователно необходимостта от QA да бъде включена още в началото ‘Планирането’ става много важна. Има моменти, когато QA може да играе ролята на собственик на прокси продукт, когато поръчката за поръчка не е налична, като по този начин помага на BA да създава сценарии / случаи за тестване на критерии за приемане.
Разработчиците също се обръщат към QA в моменти, когато се сблъскват с проблеми с функционалността или бизнес правилата. В Scrum акцентът е само върху гладкото и успешно издание на Sprint и не става дума за „Моята работа“ или „Вашата работа“, за да подадете ръка за помощ, когато екипът ви се обърне за помощ.
При свързването на екипа на Scrum здравите отношения между членовете на екипа играят много важна роля и като QA трябва да бъдете много внимателни, докато съобщавате мнението си за потребителските истории, които тествате. Вашата комуникация трябва да се отнася за историята или функционалността на потребителя, а не за човека, който е работил по нея.
В Scrum QA не се оценява или оценява за броя на грешките, които той / тя открива, но също и за това как той / тя взаимодейства с екипа, помага на екипа и мотивира екипа дори в трудни моменти.
Освен тестване на спринтовите задачи, писането на тестови планове / тестови казуси / документи за издание също се опитва да включва повече, тъй като продължителността на издаване на спринта е кратка и целта е еднаква за всички „Да доставим успешно работещ продукт без грешки, като си помагаме взаимно“.
QA участва в почти всички дейности, извършвани в Sprint и технически няма граница за започване или спиране на QA дейности. За разлика от традиционния модел Waterfall, при който QA се ограничава само до тестване на изданието, тук QA има много повече отговорности. Така че, бих ви предложил да опитате и да направите повече от следните дейности.
Дейности, които трябва да се следват
По-долу са дадени няколко дейности, които бих ви предложил да следвате като QA в Scrum.
въпроси за интервю за .net разработчик
# 1) По-дълбоко обитаване:
С това имам предвид, че когато потребителските истории и техните критерии за приемане са готови, проучете ги задълбочено и помислете по-задълбочено за зависимостите, скритите резултати и дали има по-добър начин да го направите.
Комуникирайте и си сътрудничете с BA и екипа за разработки за това, защото може да се случи, че те също не са мислили за това. Споделете вашите идеи и открития с екипа.
Ако установите, че има скрити пречки или негативни въздействия, тогава вдигането им със Scrum Master и разработчиците ще им дадат време да мислят и да действат по съответния начин. Тази дейност в Scrum става много критична, когато проектът е мащабен и когато има модули, разпределени в екипите.
Сега, докато изучаваме зависимостите, въздействието е много важно за QA и дори кара екипа за разработка да осъзнае същото. За да направите това, обсъдете с QA на другите екипи и вземете информация от тях.
# 2) Включете се в оценки:
Обичайната практика е да се включи QA в оценките, но много пъти поради малкия спринт QA може да не бъде поискан за оценка за тестване на задачите и оставяне на 3/4/5 дни за тестовата работа.
Никога не приемайте това. Повишете гласа си, ако трябва, но се уверете, че предоставяте оценката си за тестване, която трябва да включва времето, необходимо за всяка работа.
То може да включва време за проучване, време за настройка, време за събиране на исторически данни и т.н., но трябва да бъде строго и конкретно относно времето, необходимо за извършване на тестовите дейности, и тези стойности на времето да се добавят към историята на потребителя, заедно с времето на задачите за разработка .
Това е много важно, защото ако се опитате да свършите работата си в определеното време и ако не можете да завършите, само вие ще носите отговорност за неуспеха. Когато се добави QA време, Scrum Master, PO ще бъде наясно с включените QA дейности и необходимия период от време.
# 3) Dev QA сдвояване:
В идеалния случай в Scrum потребителските истории на Sprint се предават за тестване след приключване на разработката и след като тестването на разработчика е направено, но проблемът тук е, че по времето, когато е предадено на QA за тестване, едва 4-5 дни към демо или преглед остават.
Сега, ако като QA откриете дори 4 блокерни или функционални откази, ще трябва да работите късно вечер или през уикенда, за да спазите датата си на пускане, тъй като ще бъдат извършени функционални тестове, регресии и т.н. Това изглежда като традиционния модел на водопад, който не е най-добрият начин да се направи, в Scrum най-умният начин е „Предотвратявайте дефекти, вместо да откривате дефекти“.
Следователно решението е да се направи сдвояване на QA на dev и да се извърши основен кръг от тестване на настройката на dev веднага щом разработчиците са готови с историите дори преди официално пускане за тестване.
Следните критерии могат да бъдат взети под внимание, за да се направи BVT за настройката на разработчика за потребителски истории:
- Критерии за приемане за всяка потребителска история: BVT на потребителските истории в съответствие с критериите за приемане.
- Липса на доверие в разработчиците: Понякога разработчиците не са уверени в някои внедрения и следователно те обсъждат такива внедрения и правят BVT за тези на същата настройка на разработчика.
- Зависимости / Тестване на въздействието: BVT на зависимостите или въздействието върху / на другите модули на новите реализации.
- Единично тестване: Направете BVT с разработчика на модулните тестове, които те са създали, ако е необходимо, помогнете им, като добавите или актуализирате модулните тестове.
Това ще помогне за намаляване на грешките напред и назад, спестяване на времето на всички, тъй като преди пускането в QA по-голямата част от сривните или функционални грешки вече са поправени. Не забравяйте да регистрирате тези дефекти в инструментите си преди прегледа на спринта и да ги преместите до състояние „затворено“.
# 4) QA на бялата дъска:
Винаги съм насърчавал лично екипа си да включва задачи за осигуряване на качеството на дъската White Scrum, включително и грешките. Това помага на Scrum Master да разбере QA състоянието на потребителска история, като просто погледне дъската.
Не. на грешки в списъка със задачи, грешките в списъка в процес, QA дейностите в списъка със задачи, в процес и в списъка Готово говорят сами за себе си. Намирам за наистина болезнено, когато някой дойде да пита за състоянието на тестване на отделни истории за Спринт, защото трябва да отделя допълнително време, за да извадя състоянието си от инструментите за компилиране и да ги покажа или да изготвя имейл.
Просто предпочитам да насоча човека към Scrum Board и да го оставя сам да си го направи. Предпочитайте ярък изключителен цвят за QA Sticky фишовете.
# 5) Документация:
Това е един от недостатъците или минусите на Scrum, че поради малкия размер на Sprint няма много време за документация и никога не съм виждал технически писател в екип на Scrum. Scrum Master / BA може и не винаги да актуализира документите относно информацията за продукта.
Проблемът възниква, ако се присъединят нови членове или в най-лошия случай, ако бизнес правилата, функционалностите се променят и как да се следи за тях, тъй като търсенето в потребителски истории за „Готово“ за информация ще бъде като търсене на игла в купа сено.
Решението е да създадете отделна задача, създадена в спринт, когато е възможно (най-вече в слаби времена или когато натоварването е много по-малко) за документация, така че да можете да прегледате документите и да актуализирате или да накарате Scrum Master или BA да ги актуализират.
QA е правилният човек, който може да помогне при актуализирането на документите, защото вие сте този, който тества, проверява потребителските истории и знае функционалността вътре и извън. Направете го сами, ако няма BA и ако вашият Scrum Master е зает да актуализира.
# 6) Преглед на спринта / Демонстрация на спринта:
Най-често се случва QA да е този, който е избран да даде демото на PO и заинтересованите страни. но ако не убедите вашия Scrum Master да го направи. QA е подходящият човек да даде демото, тъй като той / тя е тествал историята на потребителя в и извън.
QA може да демонстрира от бизнес гледна точка, защото те познават функционалностите, потоците и бизнес правилата. Подгответе се добре за демонстрацията и се опитайте да отговорите на всеки въпрос, който има ПО и заинтересованите страни. Това ще ви помогне да станете контактна точка за тях в отсъствието на Scrum Master и BA.
# 7) Действайте като BA:
Това не е редовна задача и дори не се очаква от QA, но се опитайте да влезете в тази роля, когато се даде шанс, защото QA е най-добрият човек да бъде BA. Например, опитайте се да помислите и да визуализирате дали потоците, функционалностите или бизнес правилата могат да бъдат модифицирани по начин, който да е от полза за клиента.
Помислете и потърсете актуалните тенденции в потребителския интерфейс, външния вид и усещането на приложението и как то може да бъде беатифицирано, направено по-удобно за ползване и т.н. Ако екипът е заседнал по някакъв проблем, включете се и се опитайте да дадете прост и умен решение. Това ще даде тласък на вашата роля и ще бъде фактор, който ще допринесе за израстването ви в кариерата.
Шансовете идват по време на разговори с организацията на поръчките, когато се обсъждат някои проблеми или при преглед / демонстрация, където можете да дадете предложения.
Заключение
Scrum е съвсем различна методология от нормалния метод Waterfall, а Scrum Master е фасилитатор. Следователно не очаквайте той / тя да определя вашите дейности вместо вас.
В Scrum няма начална и крайна граница за ролята на QA. QA се нуждае и трябва да участва във всяка дейност от самото начало до края, точно от предварително планиране до прегледа / демонстрацията на спринта и трябва да участва във всички дейности.
Това ще ви помогне да разберете продукта или приложението, тъй като (както вече казах) няма налична подходяща документация при работа в Scrum. От вас се очаква да сте отговорни, мотивирани и инициативни. Следователно не чакайте някой да дойде и да ви каже какво или как трябва да правите.
Трябва да предприемате инициативи сами, да помагате на екипа по всякакъв възможен начин, да поддържате здравословна връзка, да следите текущите неща в екипа и най-важното да сте наясно със задачите си в даден спринт.
Тук няма мениджъри, които ще ви наблюдават или ще следят вашите дейности. Винаги бъдете готови с помощна ръка за вашия екип и ще получите най-добрите възможности.
Чувствайте се свободни да изразявате вашите мисли / предложения относно тази информативна статия в раздела за коментари по-долу.
Препоръчително четене
- Роля на бизнес анализаторите в SCRUM и защо QA е най-добър за тази роля?
- Онлайн тест за Agile Scrum: Проверете знанията си за Agile Scrum
- Инсталирайте приложението си на устройство и започнете да тествате от Eclipse
- Kanban срещу Scrum срещу Agile: Подробно сравнение за намиране на разлики
- Как да предоставим софтуерни функции с висока стойност за кратък период от време, използвайки Agile Scrum процес
- Agile Manifesto: Разбиране на пъргавите ценности и принципи
- Дефект триаж в Scrum: Как е организиран в Scrum настройка
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)