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
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 ...
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 ...
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
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
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
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 ...
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
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
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 ...
4
People are prone to cognitive bias, and developers are not exempt. A person who tests their own work will tend to miss problems that other people have a high probability of finding, because their thinking has been constrained by their understanding of how things are supposed to work. Put another way, a person can't think of using something in a different way ...
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
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
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
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
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
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
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 think what you are experiencing is the harsh reality of the Triple Constraint or Project Management Triangle:
The principle is that all projects involve a tension between three factors: scope, cost and schedule. Some people use scope and quality interchangeably, while in other cases (including the diagram above) quality is seen as the factor affected by ...
3
Props to @Zsolt for a very good answer. However this is a plan for the future, not a response to the situation in which you find yourself.
I believe that the relationship between coder and tester should not be adversarial - they're both partners in trying to produce finished code of a known quality. I want accurate measurements of code quality, and I want ...
3
If the same person does the development and test, the feedback loop of doing things right is short (verification). The test driven development method builds on this idea. On the other hand, it is good to have another view on the problem just to know if the right thing is built (validation), and that's the case when somebody else tests the developers' 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
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 ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
