We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

22

TL; DR Your question embeds some false assumptions about the linear nature of testing within an agile process. A mature agile team with cross-functional skill sets treats development and testing as intertwined activities rather than as sequential ones. You should strive to integrate development and testing so that they are not fundamentally separate work ...


13

QA Must Not Be Separate Clayton's answer was close. However, I'd go further and say that any team that excludes QA from the team, or treats the QA specialists as second-class citizens within the Scrum team, has entirely missed the point of the Scrum methodology and how agile practices like XP work. The core concepts behind any agile methodology boil down ...


13

“It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. Sherlock Holmes A logical corollary is that it is a capital mistake to devise risk mitigation strategies before stating a risk. There is no risk in your question. Your client wants to compress UAT. Before ...


12

In my experiences, the quality assurance staff typically handles system and acceptance testing, so I think that this would be a good place to start. This includes both manual and automated tests of the system against the requirements (functional and non-functional). Given how you describe the background of the individual, it sounds like this is an ...


12

I would hope that by now you would have frozen scope as you have cited new requirements entering at the testing stage as a problem. That has to stop otherwise you are in an endless cycle. Once you have stopped the scope creep there are a number of areas you need to look at. But the one that leaps out at me is System Testing. If the users are finding issues ...


12

If you are building a product for a client, your internal testing / QC work is not subject to negotiations. It is part of the work, part of the price, and there is no reduction in that area. If the client does not want to conduct UAT, that's their choice and risk to accept; however, there's secondary risk on the seller in this scenario. To mitigate the ...


12

The answer depends on whether this slows down or speeds up the process. How many of the bugs she found were discovered during the Code Review phase? If they were all discovered during the Code Review then maybe she's wasting her (and everybody's time). Though we can still ask: How many of the bugs she found were fixed before the Code Review stage? If ...


11

The estimate for an item should cover how long it'll take to be done. Assuming what you define as done covers testing as well as development, then it should be in the original estimate. The best way to ensure everything that needs to be covered to reach done goes into the estimate is to ensure everyone involved (eg the testers) are invited to the sprint ...


10

TL;DR Neither of your stated options are truly agile. You are misusing points in an attempt to represent progress or to "hold people accountable." Neither is appropriate within the Scrum framework. Points are an estimating tool. They are only meaningful in the aggregate, and are primarily needed for estimating team capacity during Sprint Planning. Using ...


10

An Agile team should have automation testing knowledge from the start, the team should be cross-functional. Personally I think a test in each layer of the test pyramid should be defined in the definition of done for each story (feature) that is done. Creating UI tests as an after thought will result in harder testable software. During development it is easy ...


9

Testing is Everyone's Job Agile teams should strive to be cross-functional. Even when some members of the team specialize, everyone should be involved in some aspect of test execution or test development. For example, on a software project limited to the roles you've defined: Designers should be involved in Acceptance Test-Driven Development (ATDD), ...


9

When you have dedicated testers it can appear to make sense to have a seperate testing task for them. But when you think about it, testing is really a team activity. For example, a tester may need to speak to a BA or Product Owner to understand more about what they are testing. They may also need to speak with the developers to understand the new ...


9

Try to quantify (read: put a hard $ amount to) the increased time/expenses that build up over the lifecycle of the project - regression testing, bug-fixing, new feature risk and increased time to integrate, etc. Edit: and of course share this with the clients. :)


9

The traditional Test Manager role is not compatible with the Scrum framework. Testers are members of the Scrum Team and they may well do some development and other activities in addition to testing. Note that they will choose to do these other activities as they see that it is of benefit to the team. It is not something they are obliged to do. Testing is a ...


8

I am not deep into code testing but, from a QC perspective, having the same person check his/her own work is like having a prisoner keeping the key to his cell. The QC objective is to find defects. The more defects found, the better the QC capability. That objective is inconsistent with the objective of the developer/builder, who is being measured by ...


8

Scrum teams are made up of cross-functional members. It's dangerous to categorize one individual as the QA person (or DBA, or security expert etc.) You should strive to integrate this individual into the team so that they can share their expertise with others as a member of the team, not a specialized resource. The entire team is responsible for determining ...


8

Agile teams are cross-functional teams. They estimate the work from design to delivery often on a story based level. This includes the testing work, since testing should be part of the definition of done. I as a tester part of an Agile team always sit in with the planning poker sessions and estimate just with the team, keeping in mind the complexity and ...


8

As a general rule I would say that the earlier the Product Owner starts testing the better. The reason for this is that a lot of bugs happen as a result of misunderstanding of requirements. The Product Owner is uniquely well placed to review and give feedback to a team. Ask PO to wait until the item is in the testing phase and keep to sprint timebox and ...


8

The direct answer for almost all teams is that QA must be complete to call a user story done. I would take that further and say that I have never worked with a team where this was not true. The More Thorough Answer In Scrum, a product increment (the product as it stands at the end of the sprint) must be "potentially shippable". This is a confusing term, ...


7

A quick counter question can probably answer this. "Would you deliver to the client after 4 hours of Dev?" Since you can't deliver after just the dev work, QA's estimate has to be included to the original estimates. As @David suggested, you should go for the Definition of Done which includes every activity needed to complete the job from initiation to ...


7

Make an effort to write independent smaller stories ...additional stories that she has no interest in nor does she understand. Don't write stories that the PO doesn't understand. If it is for developers' convenience, it is not a story. It is just a technical task. Put in more effort in writing smaller stories that the PO does understand. See previous ...


7

TL;DR Make unit testing part of your core development methodology, and ensure that test coverage is part of your "Definition of Done." Also, ensure your estimates include the overhead to develop and refactor your unit tests. How to "Bake In" Unit Testing How can I make unit testing a priority? Unit tests can function as both design tools and quality ...


7

Stop the Line; Fix the Process Obviously this will continue going forward because there will be a backlog of stories to be tested, whereas development will continue (we can't halt development because of this). In other words: "Help, we have a broken process! How can we keep doing what we're doing, and fix it without fixing it?" You're trying to put ...


7

My in-Sprint testplans always try to cover the area's defined in Brian Maricks described Agile testing quadrants. We look at each area at the beginning of the story and defined what effort we are going to put into it, but also if it is relavant for this story. Afterwards we create sub-tasks if needed. Agile: Focus is on test automation: https://less.works/...


7

In favor of eliminating waste I'd suggest waiting, too. Assuming a PO's time is more expensive/valuable than a tester's or dev's, simply because of supply and demand as there is only one PO, but multiple devs/testers, the following would be a waste of good PO time: Reporting errors that would have been found by a developer anyway Reporting errors that ...


6

The Project Management Perspective Should the same person to do the testing that did the development, or should another team member to do the testing? There is no canonical answer for this from a project management perspective because it's a false dichotomy. Quality assurance (QA) or user acceptance testing (UAT) often have different objectives and ...


6

TL;DR You are likely having this problem because testing isn't being included in your "definition of done" for each story. You should include testing for each story in your Sprint Backlog, and as a column on your kanban if you use one. Testing as a Story Requirement Generally, Scrum teams will include unit testing in the development work, and Quality ...


6

They could be doing a number of things. What they should be doing depends on your organization's Scrum/XP maturity but here are some common items: QA work - yes devs can QA, whether thats writing new automated tests, upping existing test coverage or reducing test complexity, doing manual testing, or performance/load testing, devs can and should QA. The ...


6

We face this situation in our AOL Advertising platform today. Like @MrHinsh suggests, the very first thing to do is move all QA into the scrum teams. We are actually in the process of moving all our QA into development roles where they are doing some development and all our developers towards full stack automation. You need to stop doing big bang releases. ...


6

We've struggled with the same issue on my team, while there's no replacement for a quality QA on the team, we've managed to get along by wearing multiple hats. This is our workflow: TDD the story until it's ready to integrate. Developer integrates and manually tests. Developer requests code review. 2nd dev reviews the code. 2nd dev pulls the changes ...


Only top voted, non community-wiki answers of a minimum length are eligible