스크럼에서 QA가 작동하는 방식을 이해하도록 도와주세요.

스크럼에서 QA가 작동하는 방식을 이해하도록 도와주세요.

---

분명히 우리는 스크럼 개발 방법론을 사용합니다. 일반적으로 진행되는 방법은 다음과 같습니다.

개발자는 자신의 작업을 수행하기 위해 노력합니다. 일반적으로 작업을 완료하려면 대부분의 스프린트가 필요합니다. QA는 Dev에게 테스트 할 수있는 무언가를 공개하도록 요청하고, Dev는 스프린트가 끝나기 하루나 이틀 전에 마침내 QA에 버그가있는 코드를 던져 QA가 찾은 버그를 수정하는 데 나머지 시간을 보냅니다. QA는 정시에 작업을 완료 할 수 없으며, 스프린트는 제 시간에 거의 해제 할 수 없으며, 개발자와 QA는 스프린트가 끝날 무렵 비참한 며칠을 보냅니다.

릴리스 가능한 Dev 작업이 대부분의 스프린트를 차지할 때 스크럼은 어떻게 작동해야합니까?

토론에 참여 해주신 모든 분들께 감사드립니다. 매우 개방적인 질문이기 때문에 하나의 "답변"이없는 것 같습니다. 아래에 좋은 제안이 많이 있습니다. 나는 나의 "집으로 가져가는"요점 중 일부를 요약하고 몇 가지 설명을 할 것입니다.

(BTW-이것이 가장 좋은 장소입니까, 아니면 '답변'에 넣어야합니까?)

숙고 / 조치해야 할 사항 :

• 개발자 작업이 가능한 한 작게 (세분화되어) 있는지 확인해야합니다.
• 스프린트 길이는 평균 작업 길이를 기준으로 적절해야합니다 (예 : 1 주 작업이있는 스프린트는 최소 4 주 길이 여야 함).
• 팀 (QA 포함)은 더 정확한 추정을 위해 노력해야합니다.
• 별도의 QA 스프린트를 병렬로 수행하되 팀에 가장 적합한 경우 오프셋을 고려하십시오.
• 단위 테스트!

---

내 의견은 당신에게 추정 문제가 있다는 것입니다. 각 기능을 테스트 할 시간이없는 것 같고 스프린트를 계획 할 때 건물 부분 만 고려하고있는 것 같습니다.

무엇보다 흔하기 때문에 해결하기 쉬운 문제라고 말하는 것이 아닙니다. 그러나 도움이 될 수있는 것은 다음과 같습니다.

• QA를 개발 팀의 구성원으로 고려하고 스프린트 계획 및보다 면밀한 추정에 포함시킵니다.

• 'Releasable Dev tasks'는 대부분의 스프린트를 차지하지 않아야합니다. 완전한 작동 기능이 있어야합니다. 각 작업 종류에 대한 개발 시간 대 QA 시간에 대한 메트릭을 수집하고 향후 스프린트를 예측할 때 해당 메트릭을 사용하십시오.

• 매우 거친 기능이 있는지 확인하려면 백 로그를 검토해야 할 수 있습니다. 쉽게 추정하고 테스트 할 수있는 작은 작업으로 나누십시오.

요약하면, 스프린트를 예측하고 계획 할 때 고려되지 않는 작업이 있기 때문에 팀이 실제 속도를 찾지 못한 것 같습니다.

그러나 결국 예측 부정확성은 애자일 기반 또는 폭포수 기반 프로젝트에서 발견되는 어려운 프로젝트 관리 문제입니다. 행운을 빕니다.

---

여기 파티에 조금 늦었지만 여기에 당신이 쓴 것을 기반으로 한 내 의견이 있습니다.

이제 스크럼은 개발이 아닌 프로젝트 관리 방법론입니다. 하지만 제 생각에는 개발 프로세스를 갖추는 것이 중요합니다. 하나가 없으면 건축하는 대신 반응 하는 데 대부분의 시간을 보냅니다 .

나는 테스트 우선 사람입니다. 개발 프로세스에서 요구 사항과 디자인 결정을 적용하기 위해 먼저 테스트를 빌드합니다. 어떻게 당신의 팀은 그 집행? 제가 여기서 말하고자하는 요점은 단순히 "담장 너머로 물건을 던질" 수없고 실패가 발생하지 않을 것이라고 기대할 수 없다는 것입니다. 그 실패는 테스트 팀 (잘 테스트하지 않아서 문제가 사라짐) 또는 개발자 (문제를 해결하는 제품을 빌드하지 않음)에 의해 발생할 것입니다. 나는 당신이 말하는 게 아니에요 해야한다 나는 전투 또는 테스트 우선 전도자 아니에요 - - 첫 번째 테스트를 작성하지만 난 당신이 말하고 해야한다 , 테스트, 생산 품질 장소에서 프로세스를 가지고 준비를 위해 생산 코드 때를 반복의 끝에 도달합니다.

나는 내가 죽음의 나선 방법 이라고 부르는이 개발 방법론 에서 당신이 있는 곳에 옳았다 . 나는 그런 모델에서 수년간 정부 (미국)를위한 소프트웨어를 만들었다. 잘 작동하지 않고 많은 비용이 들며 늦은 코드와 불량한 코드를 생성하며 사기를 위해 아무것도하지 않습니다. 애초에 피할 수 있었던 버그를 수정하는 데 모든 시간을 할애하면 어떤 진전을 이룰 수 없습니다. 나는 그 사건에 절대적으로 구타 당했다.

QA가 문제를 찾는 것을 원하지 않습니다. 당신은 정말로 그들을 일에서 내보내고 싶어합니다. 제 목표는 모든 것이 제대로 작동하기 때문에 QA를 과시하게 만드는 것입니다. 물론 그것은 목표입니다. 실제로 그들은 물건을 찾을 것입니다. 나는 초인적이지 않다. 나는 실수를한다.

일정으로 돌아 가기 ...

제 현재 직장에서 우리는 스크럼을하고 있지만 그렇게 부르지 않습니다. 우리는 여기에 라벨을 붙이지 않지만 제 시간에 양질의 코드를 생산하고 있습니다. 모두가 탑승합니다. 테스트 할 준비가 된 내용과시기를 QA에 알려줍니다. 2 주 일찍 두드리면 손으로 이야기 할 수 있습니다. 모든 사람이 일정을 알고 있고, 모두가 릴리스에 포함될 내용을 알고 있으며, 제품이 QA에 가기 전에 광고 된대로 작동해야한다는 것을 모두가 알고 있습니다. 그게 무슨 뜻일까요? 당신은 QA에게 "XYZ를 테스트하는 것을 귀찮게하지 마라-그것은 망가졌고 릴리스 C까지 고쳐지지 않을 것입니다"라고 말하고 그들이 그것을 테스트한다면, 당신은 그들에게 그 진술을 다시 지적하고 그들에게 당신의 시간을 낭비하지 말라고 말한다. 가혹하지만 때로는 필요합니다. 나는 무례하게 굴지는 않지만 모든 사람이 "규칙"과 테스트해야 할 사항과 '

당신의 경영진이 참여해야합니다. 그렇지 않으면 문제가 생길 것입니다. QA는 쇼를 실행할 수 없으며 개발 그룹도 완전히 실행할 수 없습니다. 모든 그룹 (그룹당 한 사람이거나 여러 모자를 쓰는 사람이더라도)은 동일한 페이지에 있어야합니다. 고객, 테스트 팀, 개발자, 경영진 및 기타 모든 사람. 전투의 절반 이상은 일반적으로 커뮤니케이션입니다.

스프린트 중에 달성 할 수있는 것보다 더 많은 것을 물고있을 수 있습니다. 그럴 수도 있습니다. 왜 그것을하고 있습니까? 일정을 맞추기 위해? 그렇다면 경영진이 개입하여 문제를 해결해야합니다. QA 버그가있는 코드를 제공하는 경우 해당 코드를 다시 던질 수 있습니다. 끝나지 않은 8 가지보다 효과가있는 3 가지를주는 것이 좋습니다. 목표는 반쯤 완료 한 것들을 모으는 것이 아니라 각 반복에서 완전히 구현되는 일부 기능 세트를 생성하는 것입니다.

나는 이것이 의도 한대로 받아 들여지기를 바랍니다. 내가 언급했듯이 나는 당신이있는 곳에 있었고 그것은 재미가 없습니다. 그러나 희망이 있습니다. 스프린트에서 두 개 정도의 상황을 뒤집을 수 있습니다. 아마도 다음 스프린트에서 새로운 기능을 추가하지 않고 단순히 손상된 부분을 고칠 수 있습니다. 팀으로서 결정해야합니다.

테스트 코드 작성을위한 작은 플러그 하나 더 : '테스트를 먼저 작성'접근 방식을 채택한 이후로 내 제품에 대해 훨씬 더 편안하고 자신감이 생겼습니다. 모든 테스트가 통과되면 테스트 없이는 가질 수 없었던 자신감을 갖게됩니다.

행운을 빌어 요!

---

특정 기능이 스프린트 내에서 '완료'되도록하기 위해 QA 기능 테스트가 필요한 시나리오에 리소스 할당 문제가있는 것 같습니다. 지금까지 내가 찾은 QA 관련 스크럼 토론에서 아무도이 문제를 다루지 않는 것 같으며 여기의 원래 질문은 거의 동일합니다 (적어도 관련이 있음). 그래서 부분적인 답변을 제공하고 질문을 조금 확장하고 싶었습니다.

전체 스프린트를 취하는 개발 작업에 대한 구체적인 원래 질문에 관해서는 QA에 의한 기능 테스트가 '완료'정의의 일부인 경우 이러한 작업을 완화하는 일반적인 조언이 의미가있는 것 같습니다. 4 주 스프린트로 여러 개발자의 여러 기능을 테스트하는 데 약 1 주일이 걸리면 개발 작업이 약 3 주가 걸리고 테스트 작업이 1 주일 지연되는 것이 정답입니다. QA는 물론 마지막으로 제공된 기능 세트에서 약 1 주일 지연이 있음을 인식하면 가능한 한 빨리 시작됩니다. 스프린트에서 폭포와 같은 시나리오가 발생하지 않도록 최대한 빨리 QA에 기능을 제공하고자한다는 것을 알고 있습니다.하지만 현실은 일반적으로 개발이 현실화 될 수 없다는 것입니다. 스프린트 1 ~ 3 주까지 기능을 QA에 전달했습니다. 물론 여기저기서 약간의 조각이 있지만 작업의 대부분은 2-3 주 개발이고 약 일주일 동안 남은 테스트입니다.

여기에 리소스 할당 문제와 질문에 대한 확장이 있습니다. 위의 시나리오에서 QA는 스프린트의 계획된 기능을 테스트 할 시간이 있습니다 (3 주 분량의 개발 작업, 마지막 주에 제공된 기능 테스트를 위해 마지막 주 남음). 또한 QA가 개발 1 주 후에 테스트 가능한 기능을 얻기 시작한다고 가정 해 보겠습니다.하지만 QA 1 주차, 개발 4 주차는 어떨까요?

QA 기능 테스트가 스프린트의 기능에 대한 '완료'정의의 일부인 경우 이러한 비 효율성은 피할 수없는 것 같습니다. QA는 1 주차에 대부분 유휴 상태이며 개발은 4 주차에 대부분 유휴 상태입니다. 물론 버그 수정 및 검증, 설계 / 계획 등과 같이이 시간을 자연스럽게 채우는 몇 ​​가지 사항이 있지만 기본적으로 리소스를 75 % 용량으로 줄입니다.

분명한 대답은 개발과 QA를위한 스프린트가 겹치는 것 같습니다. 현실은 QA가 항상 개발에 비해 어느 정도 뒤쳐져 있기 때문입니다. 기능이 표시되기 전에 테스트되기를 원하기 때문에 제품 소유자 및 다른 사람들에게 시연은 QA 스프린트를 따를 것입니다. 이렇게하면 낭비되는 시간이 많지 않기 때문에 개발 및 QA를보다 효율적으로 사용할 수 있습니다. 개발자 개발 및 테스터 테스트를 계속하고 싶다고 가정하면 더 나은 실용적인 솔루션을 볼 수 없습니다. 아마도 내가 뭔가를 놓쳤을 수도 있고, 누군가 나를 위해 이것에 대해 알려줄 수 있기를 바랍니다. 그렇지 않으면 스크럼에 대한이 엄격한 접근 방식에 결함이있는 것 같습니다. 감사.

---

각 스프린트에서 더 적은 개발 작업을 처리하여이 문제를 해결하기를 바랍니다. 다음 질문으로 이어지는 것은 개발자의 목표 설정은 누구입니까? Dev가 이러한 목표에 지속적으로 미치지 못하는 이유는 무엇입니까?

dev가 자신의 목표를 설정하지 않으면 항상 늦는 것입니다. 그리고 그것은 스크럼을 연습하는 이상적인 방법이 아닙니다. 이는 기한에 따라 큰 결과물을 제공하는 점진적 개발 일 뿐이며 개발자의 실제 이해 관계자 책임은 없습니다.

개발자가 충분히 알지 못해서 자신의 목표를 설정할 수 없다면 사전에 더 많이 참여해야합니다.

스크럼은 Agile Manifesto에 설명 된 네 가지 기본 원칙에 의존합니다 .

1. 상호 작용이 중요합니다. 즉, 개발자, QA, 프로젝트 관리 및 최종 사용자가 더 많이 이야기하고 서로 이야기해야합니다. 소프트웨어는 컴퓨터의 신비한 언어로 지식을 인코딩하는 과정입니다. 지식을 인코딩하려면 개발자가 지식이 있어야합니다. [왜 그것을 "코드"라고 부르는가?] 스크럼은 "쓰기 사양-트랜 섬"방법론이 아닙니다. 그것은 ANTI- "쓰기 사양-트랜 섬 던지기"입니다.

2. 작동하는 소프트웨어가 중요합니다. 즉, 개발자에게 물린 각 조각이 작동 릴리스로 이어져야합니다. QA가 씨름 할 버그 수정 세트가 아니라 작동하는 소프트웨어입니다.

3. 고객 협업-즉, 개발자는 비즈니스 분석가, 최종 사용자, 비즈니스 소유자, 자신이 구축중인 내용을 이해하는 데 도움을 줄 수있는 모든 사람과 협력해야합니다. 마감일은 고객에게 전달되는 다음 항목만큼 중요하지 않습니다. 고객이 X를 필요로하는 경우 모든 사람이해야 할 가장 우선 순위가 높습니다. 프로젝트 계획에 빌드 Y가 표시되어 있다면 그것은 끔찍한 일입니다.

4. 변화에 대한 대응-이는 고객이 다음 스프린트의 우선 순위를 재정렬 할 수 있음을 의미합니다. 그들은 진행중인 스프린트를 재정렬 할 수 없지만 (미친다), 다음의 모든 스프린트는 우선 순위 변경 후보입니다.

고객이 추진하면 마감일이 인위적인 "프로젝트 마일스톤"이되고 "X가 먼저 필요하고 Y가 필요하며 Z 섹션에서이 것은 더 이상 필요하지 않습니다. 이제 W, Z가 있습니다. 불필요한."

---

스크럼 규칙에 따르면 모든 Sprint 항목은 완전한 것으로 간주 되려면 Sprint가 끝날 때 "완전히 테스트되고 잠재적으로 구현 가능한 기능"이어야합니다. 스프린트는 항상 정시에 종료되며 팀은 점수를 얻지 못하며 Sprint 검토에서 완전하지 않은 QA를 포함하는 어떤 것도 발표 할 수 없습니다.

기술적으로는 그게 전부입니다. 팀은 일정량의 작업에 전념하고 마침내 스프린트가 끝나기 이틀 전에 QA를 받고 QA가 제 시간에 완료되지 않습니다. 따라서 Sprint의 출력은 0입니다. 고객 앞에 가서 한 달 동안 표시 할 것이 없음을 인정해야합니다.

다음 번에는 그들이 더 적은 작업량을 선택하고 제 시간에 완료 될 수 있도록 QA에 전달하는 방법을 알아낼 것입니다.

---

2.5 년 동안 애자일 프로젝트에 참여한 QA로서 말하면 이것은 정말 어려운 문제이며 여전히 모든 답을 가지고 있지 않습니다.

I work as part of a "triplet" (two developers who pair program + one QA) and I am involved in tasking out stories and estimating in planning meetings at the beginning of two week iterations. As adrianh mentioned above it is essential for QAs to get their voice heard in the initial sprint planning. This can be difficult especially if you are working with Developers with very strong personalities however QAs must be assertive in the true sense of the word (i.e. not aggressive or forceful but respectfully seeking to understand the Truth/PO and Developers/technical experts whilst making themselves understood). I advocate producing QA tasks first during planning to encourage a test driven mentality - the QA may have to literally put themselves forward to get this adopted. It is opposite to how many people think software development works but pays dividends for several reasons;

1. QA is heard and not relegated to being asked "so how are you going to test that?" after Devs have said their piece (waterfall mentality).

2. It allows QA to propose ideas for testing which at the same time checks the testability of the acceptance criteria while the Truth/PO is present (I did say it is essential for them to be present in the planning meeting didn't I?!) to fill in any gaps in understanding.

3. It provides the basis for a test driven approach - after the test approach has been enunciated and tasked the Devs can think about how they will produce code to pass those tests.

4. If steps 1 - 3 are your only TDD activity for the rest of the iteration you are still doing a million times better than the scenario postulated by Steve in the first post; "Developers thrash around trying to accomplish their tasks. Generally the tasks take most of the sprint to complete. QA pesters Dev to release something they can test, Dev finally throws some buggy code out to QA a day or two before the sprint ends and spends the rest of the time fixing bugs that QA is finding"

Needless to say this comes with some caveats for the QA;

1. They must be prepared to have their ideas for testing challenged by Devs and Truth/PO and to reach a compromise; the "QA police" attitude won't wash in an Agile team.

2. QA tasks must strike a difficult balance to be neither too detailed nor too generic (tasks can be written on a card to go on a "radiator board" and discussed at daily stand up meetings - they need to be moved from "in progress" to "completed" DURING the iteration).

3. QAs need to prepare for planning/estimation meetings. Don't expect to be able to just turn up and produce a test approach off the top of your head for unseen user stories! Devs do seem to be able to do this because their tasks are often far more clear cut - e.g. "change x module to interface with z component" or "refactor y method". As a QA you need to be familiar with the functionality being introduced/changed BEFORE planning so that you know the scope of testing and what test design techniques you might apply.

4. It is almost essential to automate your tests and have these written and "failing" within the first two or three days of an iteration or at least to co-incide with when the Devs have the code ready. You can then run the test/s and see if they pass as expected (proper QA TDD). This is how you avoid a mini waterfall at the end of iterations. You should really demo the test to the Devs before or as they start coding so they know what to aim for.

5. I say 4 is "almost essential" because the same can sometimes be successfully achieved with manual checklists (dare I say scripts!) of expected behaviour - the key is to share this with Devs ahead of time; keep talking to them!

With regards to point 2 above on the subject of the tasks, I have tried creating tasks as granular as 1/2 hour to 2 hours in size each corresponding to a demonstrable piece of work e.g. "Add checks for incorrect password to auto test - 2 hrs". While this helps me organise my work it has been criticised by other team members for being too detailed and has the effect at stand ups of me either moving multiple tasks across to complete from the day before or not being able to move any tasks at all because I have not got onto them yet. People really want to see a sense of steady progress at daily stand ups so it is more helpful to create tasks in 1/2 day or 1 day blocks (but you might keep your own list of "micro-tasks" to do towards to completion of the bigger tasks that you use for COMMUNICATING overall progress at the stand-up).

With regards to points 4 and 5 above; the automated tests or manual checklists you prepare early should really cover just the happy paths or key acceptance criteria. Once these pass you can have planned an additional task for a final round of "Exploratory testing" towards the end of the iteration to check the edge cases. What the Devs do during that time is problematic because as far as they are concerned they are "code complete" unless and until you find a bug. Some Agile practitioners advocate going for the edge cases first although this can also be problematic because if you run out of time you may not have assured that the acceptance criteria have been delivered. This is one of those finely balanced decisions that depends on the context of the user story and your experience as a QA!

As I said at the beginning I still don't have all the answers but hope the above provide some pointers born out of hard experience!

---

Sounds like your development team might not be doing enough testing on their own, before the release to QA. If all your unit tests are passing, the QA cycle should be relatively smooth sailing, no? They'll find some integration errors, but there shouldn't be very many of those, right?

---

I think that there are several problems here. First, I think that perhaps the developer tasks aren't either fine grained enough, or perhaps not estimated well, or perhaps both. The whole purpose of the sprints in Scrum is to be able to demonstrate workable code at the end of the sprints. Both of the problems that I mentioned could lead to buggy code.

If developers are release buggy code towards the end of the sprint, I would also look at:

• Are the product owners really holding the dev members accountable for getting their tasks done. That's the job of the PO and if that's not happening, then the developers will slack.
• Are the devs using any kind of TDD. If not, that might help matters greatly. Get the developers in the habit of testing their code. We have this problem where I work, and my team is focused on doing the TDD in the important areas so that we don't have to have someone else do it later
• Are the task/user stories too generic? Wiggle room in the task breakdowns will cause developers to be sloppy. Again, this is somewhat of a PO problem.

One idea that I've heard batted around in the past is to use a QA person as scrummaster. They will be present for the daily standups and can get sense of where things are at with the developers. They can address issues with the PO (assuming that the PO can adequately do their job).

I can't help but feel that you need more coorporation between QA and your scrum teams. It sounds like testing only happens at the end, which is a problem. Getting QA to be a part of the team will help identify things that can be tested earlier and better.

I also feel like you have an issue with the product owner. They must be in there making sure that everyone is driving the right direction. they should be making sure that there is good cooperation, not only between QA and devs, but between the devs themselves.

---

"How is scrum supposed to work when releasable Dev tasks take up most of the sprint?"

As you've found out - it doesn't work terribly well :-) The process you're describing doesn't sound much like Scrum to me - or at least not like Scrum done well.

I'm unsure from what you've described whether the QA folk are part of the team - or a separate group.

If they're a separate group then this is probably a big part of the problem. They won't be involved in the team's commitment to completion of tasks - and the associated scope negotiation with the product owner. I've never seen an agile group succeed well without their being QA skills in the team. Either by having developers with a lot of testing/QA skills - or by having an embedded QA person or three on the team.

If they are on the team then they need to get their voice heard more in the initial sprint planning. By now it should be clear to the product owner and team that you're overcommitting.

I'd try a few things if it were me:

• Get QA/testing folk on the team if they're not there already
• Have a good long chat with the product owner & the team over what counts as "done". It sounds like some of the developers are still in the pre-scrum mindset of "handed over to QA"" == done.
• Break down the stories into smaller chunks - makes it easier to spot estimation mistakes
• Consider running shorter sprints - because little and more often is easier to track and learn from.

You might also find these tips about smoothing down a scrum burndown useful.

---

We solved this problem as follows: - Every item in the product backlog must have fit criteria or acceptance criteria, without those, we don't start a sprint - A tester is part of our team, for every product backlog item, he creates test tasks (1 or more, based on the acceptance criteria) together with an estimation, and a link to the item to test - During the daily scrum, all tasks that are finished are placed in a 'To Test' column - We never do tasks that take longer than 16 hours; tasks that are estimated longer, are split up

---

Split the tasks into smaller tasks.

Also, QA can create test cases for Dev to test against.

---

One idea to consider is to have QA work one iteration behind the main development. That works well in our environment.

---

Here I would say that, One size does not fit all. Every team deals QA differently. It so much depends on the project you are working on, either it's a small one or big one. Does it need extensive regression, User acceptance and exploratory testing or you have quite few scenarios to test. Let me restate that in Agile, generalist are preferred on specialist. What is that? Because there is time during the project when you don't have anything to Test, so at that time you might be doing something else. Also you might be doing testing even though you are a hard-core programmer.

How do we handle it? We have regular 2 week sprint. Testing start after a week on the task completed by developers during the week. Now tester keep adding issues to our Issue tracker and developers who are done with their sprint tasks start picking those bugs. By the end of the sprint we mostly get done with our sprint task and all critical and major bugs.

So what does tester two in the first week of the sprint?

Well, There are always things to test. We have testing tasks in the backlog, that may include some exploratory testing. Many people don't value Exploratory testing but that is extremely important to build quality products. Good testers create task for themselves and find the possibilities where things go wrong and test them.

Hope that helps!

참고URL : https://stackoverflow.com/questions/155250/help-me-understand-how-qa-works-in-scrum