14
If you are following Scrum as defined in the Scrum Guide, the Product Owner cannot simply add stories to the Sprint Backlog. The Sprint Backlog, which is created as Sprint Planning as a negotiation between the Product Owner and Development Team while considering past performance and forecast capacity, is owned exclusively by the Development Team.
If work ...
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
A few suggestions:
Don't delegate & disappear until the deadline. Check in with them once or twice, just informally to ask how it's going, do they need any clarification from you, are they having any problems.
Be sure everyone is clear on what the priority of the delegated task is, especially if the people you've delegated to have other usual tasks, ...
8
Modern testing is all about how you assist to "Accelerate the Achievement of Shippable Quality".
Do your reviews help with accelerating? What metrics do you use to create proof of that? Testing helps with reducing risks, but at what cost? What is the return on investment.
Overall I think the project managers question seems a very valid one. Wonder ...
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
TL;DR
While quality can be measured objectively, defining the domain-specific elements of quality for your organization isn’t something where you can rely on a standard dictionary definition.
In fact, most of the issues you’ve identified aren’t intriniscally quality issues at all. They seem more like organizational issues. We’ll look at some of them in ...
7
This is a great question. Several years back I analysed the bugs reported in a team and found that over half of them came about as a result of misunderstanding of requirements.
Some things that can help to reduce this problem include:
Have the team (QA, devs, PM, etc.) jointly add details to a requirement, so that they share a common understanding
Using an ...
7
What do you mean by "reviews" in this context? Many development teams do peer-reviews of code and analysis because they find that reviews improve productivity and quality. Many teams also make end-user reviews part of their Definition of Done for work. This is something the whole team should have an opinion on, not something you need to discuss ...
6
Let's divide QA(Quality Assurance) from QC(Quality control), check the difference.
Short term solution for manual QC would be to create test plans, acceptance criteria's, force your QC to add test evidence(Screenshots, screencasts, logs, SQL query results), which prove that all ok, you should also plan the number of bugs based on previous development ...
6
It sounds like they are getting too deep into the technical weeds here. Definition of Done is a checklist, not a functional specification. Also, a DoD does not have to be a "All or Nothing". It is perfectly acceptable to have conditional statements (If story is UI related, then X).
Here is an example of a DoD pulled from a team I work with.
Story design ...
6
I think it is a very fair question for the PM to ask. Evaluating the proposed effort against its benefits, costs, and risks is proper leadership and management. If you have a proposal for testing, you ought to be able to articulate value. If you cannot, then do you truly understand the work?
Testing is risk mitigation, and PMs own the responsibility to ...
5
If I don't have the time to produce a Swiss precision watch, ...
If I don't have the tools to produce a Swiss precision watch, ...
If I cannot attract the people that can produce a Swiss precision watch,...
... I might end up offering sun dials.
Likewise, my customer might not have the time to actually figure out the difference between a sundial and a ...
5
Don't ask, don't tell ;)
I guess you're not giving estimates on how much time you spend thinking, and how much writing code, the same principle should apply to unit testing.
As soon as your Unit Testing activity becomes a line in the budget it becomes negotiable.
I never report unit testing as a separate activity (and in principle most of the time you ...
5
You should not consider development and testing as sequential activities within the sprint, or the thing you describe happens. Development and testing should happen together as a collaboration between devs and testers. It requires a change in the way you work. See more details here: What does a QA team do during the development phase of a sprint in Agile ...
5
If there are two stakeholders who have different understandings of the requirement, then there may be more. What about how you interpret the requirement, from the perspective of a tester? Or how about the customer? Or even the end-users of the product? If the requirement is ambiguous to the point where two people who (in theory, anyway) are working closely ...
4
Don't add them as an extra and don't allow them to be negotiated away. Make them part of your budget and schedule and make it clear that this is how you develop. If you would normally say 'task x will take 2 days plus 1 day of testing' then it gives someone the opportunity to say 'well, do it in 2 and don't worry about the testing'. If you say 'task x will ...
4
set up Continuous Integration and (as you noted) automated unit and integration tests
get the team agree on a common Definition of Done, including that no feature is completed until it is integrated back into the whole system and is proven to work there
get better Django developers by one or more of
arranging training for your existing developers,
hiring ...
4
I think that in the agile methods, you're probably going to want a different set of quality metrics to track against.
In an agile project, especially with regards to the design and code and test activities, it's highly iterative and there may not be a clear separation of these activities, so phase-based metrics (measuring effectiveness of design and code ...
4
So right now, as an Engineer, I take a single task, mull over it for 4 weeks, make sure it contains no bugs at all and I am the best worker you ever had. Despite the fact that it took me 4 weeks to deliver such a simple task.
On the other hand, you have QA, who is wildly dependent on getting a crappy Engineer assigned. The crappier the engineer, the more ...
4
I agree with @CodeGnome but not just with Agile. No matter the method, the product, or even the domain, UAT needs to belong to the users, in scope, conduct, and outcome. The client side needs to define how to conduct UAT, the scenarios it will run, procedures, training people, how to document findings, any criteria needed, etc. After all, UAT is a client ...
4
You're describing an immature organization, seemingly political, low performing team, hostile work culture.
There is no such thing as a 100% defect free product or service of any type. And a mature organization with high performing processes and capabilities know this and have a process of continual improvement while they also have contingencies to deal ...
4
Yes. A common rule of thumb for a two-week sprint is that most backlog items should take 2 - 3 days to complete including QA, deployment, etc. This is just wisdom for experienced teams though, not a hard-and-fast rule. It will also take time to get there. If the team is used to a backlog item taking a full 2 weeks to complete, they aren't going to jump to 2 ...
4
One approach you could try is to have the QA working ahead of the developers.
It would work something like this:
Back end devs write stubbed API calls that mimic the behaviour of the finished functionality
UI devs create a boiler plate front-end that calls into the API (getting results returned from the stubs)
At this stage there is no implementation code ...
3
This is largely going to depend on your work environment.
In my experience, QA can support a team of 3-5 developers, so your QA is definitely under-utilized. This can be addressed by adding more devs to your team / spread the QA across multiple teams.
Beyond resource allocation; your QA can do more than just test the functionality delivered during the ...
3
UAT Checklists Should Come From Users or Their Proxies
What checklists should I give the team?
From an agile perspective, you should not be giving the team a user acceptance testing (UAT) checklist at all. Your product's users (or at least a Product Owner or business analyst if you're not agile enough to work directly with your users) should be working ...
3
Quality Audit is basically seeing if you are following the defined process. A Process Analysis is examining what you do and identifying aspects that could be improved.
As an extreme example, in a Quality Audit you might have a process that says "Every employee should sleep for 10 minutes per hour" and the Audit would have to confirm it was being followed.
...
3
I could say something about each of your points, but will address one. If you address this one, then you will figure it all out (eventually).
“Software developers started leaving project”
Ask why? Ask them why? Ask the people that are remaining why?
Hold regular retrospectives, find out why, have the developers find and fix the problems. Give them as much ...
3
Don't use money to reward quality.
Studies show that money is an excellent motivator for routine tasks that involve no thinking, and a terrible motivator for tasks that require creativity.
Experts are motivated by autonomy, mastery, and purpose [Spam disclaimer: No relation to the book nor author].
So:
Create an environment that provides autonomy, ...
3
A lot of comments are made about the size of the team and the roles within it, so I'll skip that.
My advice (with most questions, issues or whatever): Take it to the team
The team is doing the actual work and they can tell what they think they need or should do or whatever. Then you can have a discussion about the situation and come to a solution with the ...
3
If you have teams that work on one project only, then you could keep them on Scrum iterations. If they can plan things out and do the work without depending too much on external resources (I'm thinking "you" here), then great, let them do so. From what I gather from your question, it seems that this is not the main issue, but the fact that you are ...
Only top voted, non community-wiki answers of a minimum length are eligible