Define a definition of done that includes testing. Define which testing effort is minimal needed to get the work done.
Time boxed exploratory testing session for each story, just after coding is done or even during the coding sessions, pair with developers to test their work
Good balance of UI-, Service- and unit-tests, read about the test pyramid
Get the whole team to work on the problem.
Given the arrangement you've discussed clearly the team needs to look at options to resolve this. The problem itself seems fairly endemic in all of the organizations I have worked with. It seems inevitable given the setup unless proactive steps are taken to address it.
A frequent issue is that there is no 'one ...
This is very common.
There are basically 3 parts to the problem:
Track stats to know when the backlog is getting worse or improving, week to week
Figure out what things you need to change to stop making it worse week to week
Clean up the backlog you created, bit by bit
I'll focus on part 3 - the cleanup - but ...
"there is nothing to test"
That is a strong statement.
I like to use James Bach's definition of testing:
Testing is the process of evaluating a product by learning about it
through exploration and experimentation, which includes to some
degree: questioning, study, modeling, observation, inference, etc.
So, unless there is nothing new to learn about ...
In addition to Michael Durrant's excellent answer and the equally good comments, I'd suggest you consider a few things:
If you have not already done so, devote some time to analysis of your bug backlog. You will probably find some combination of the following things:
The bugs cluster in certain areas of the application. These will typically be the areas ...
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest ...
In addition to some of the other suggestions, you could consider a few other options:
Build/run load tests for new/recent work (given the maturity of your test automation you may already have this under control)
Review existing test automation for obsolete or ineffective tests (You have no idea how much I wish I could reach this point)
Review and refactor ...
My ex-client went through a very similar thing. When I started, QA weren't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.
The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of ...
I've tested in the sprint + 1 system under the SAFe framework. The framework does not specific this but lends itself to doing it for organizations coming from waterfall.
Mu suggestion is:
Your questions of
Does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to ...
It depends, and there are no industry standards.
Seriously. Any metric can be gamed (and will be, if you use it for assessment). I'm not aware of any standard approaches, not least because the teams are - or should be - evaluating themselves regularly and looking for ways to improve their own processes (if they aren't then they're probably using SCRUM-but......
Classic testing is Quality Assurance
Agile Testing is Quality Engineering
Traditionally most testing as done at the end of the development. It asks if the product that has been developed meets the requirements, both explicit and implicit.
This field is primarily concerned about automation and automated tests.
It breaks ...
Great Communication Brings Great Results
Being last in line, QAs keep facing this repetitively. QA should proactively communicate delays and respective risks to stakeholders.
I’ve never seen any agile project where every sprint came in on time. Start with finding the reason what is causing the delay.
There can be multiple reasons for the delay:
With respect to testing they are the same.
Kanban and Scrum are both iterative Agile development models, the goal is to get the most important tasks fully done (including testing) as soon as possible. The product should be potentially shippable at the end of the iteration. The difference is with Scrum the end is a set date, with Kanban it could be anytime ...
I've been there. This is my experience:
Start with - Review all the documentation you're given. Chances are good something critical has been overlooked because Project Managers tend to focus only on their projects and developers tend to focus on the work they're developing. Testers are usually the ones with a broad perspective. The key thing here is that ...
One of the foundation principles of the Agile Manifesto is self-organizing teams:
The best architectures, requirements, and designs emerge from
PS: It includes processes
And the Scrum Guide (which came before the Manifesto) talks about it too:
Self-organizing teams choose how best to accomplish their work, rather
than being ...
I'd suggest you start by taking a look at some of the related questions and their answers, particularly this one and this one.
Also, if you don't have Crispin and Gregory's Agile Testing, get it.
Some things that I've found helpful include:
Test plans will still happen - but they tend to be much more lightweight and built as you test. Some tools support ...
My team struggles with a similar issue having multiple input streams, that are running on different iteration/sprint cycles into a common product.
We tried testing in the dev int area for each team for a while and then marking items done at that point, but we quickly discovered that was too early in the process. We could verify that new functionality was ...
Seems you have a mini water-fall. Everyone in the team should help finish the Sprint. Let the developers help with the Stability testing and re-running failed test cases.
Developers and QA do not exist in Scrum, to quote the Scrum guide:
Scrum recognizes no titles for Development Team members other than
Developer, regardless of the work being performed by ...
Anybody can be the Scrum Master, just make sure the Scrum Master has no other conflict of interest roles as Product Owner, Manager or Stakeholder.
Personally I think testers have the potential to be great Scrum Masters, because:
Testers discover problems/defects, but often do not demand a certain solution. Its up-to-the owners of the issue to find the best ...
Use tests to drive code design.
This is the difference between using tests as quality checks, post development instead of using tests to uncover and drive the design up-front.
"Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Managing the Unmanageable. Steve ...
In the spirit of working in a multi-disciplinary team, I think developers should participate in the QA process if there's a backlog of work, (or even if there isn't).
I think it's bad practise for the development and QA teams not to be closely integrated - As far as possible, they should be the same team, and that makes it easier for developers to switch ...
I'm going to answer the first two points because I think the other two should be put as separate questions instead.
What are the types of testing that can be conducted on first build which was released in first sprint in agile development model?
There is no specific check-list. It depends solely on the architecture and complexity of the project. Team ...
You don't wait for a sprint to start before doing test work. You should have been present during the planning of the ticket and given feedback on the feature. Were all possible scenarios spec'd out? Could something be added to improve the testability of the feature? Do you need to create additional work items for yourself to set up an environment or generate ...
As your question is tagged Scrum I will try to answer it within that context.
It starts with the Scrum's Definition of Done:
When a Product Backlog item or an Increment is described as “Done”,
everyone must understand what “Done” means. Although this varies
significantly per Scrum Team, members must have a shared understanding
of what it means for ...
Of-course, understanding the goal of an user-story before coding review gives a lot of context. In an Scrum team I would expect all team-members to already understand the acceptance criteria as everyone was part of the Sprint planning session.
Still actively verifying the (user/customer level) acceptance criteria of an user-story does not seem something I ...
Now QA is not the only person responsible for the quality of the product, instead, QA's are taking up the role of a person who drives the quality process inside the team. Some things which you can do/introduce to improve your and your teams efficiency are :
Educate the whole team about the importance of quality and also that QA's are not the sole person ...
If you have a set of Regression Tests, testers can start automating them starting with which are easiest to automate. This will save you a lot of time in the long run during Regression Testing. Of course, this requires some programming skills and if the testers do not have those at the moment then this is the great time for them to learn it and apply to ...
We have an issue
Issue for who? Sprints are a completely artificial unit of time usually set up by managers who do not do your work anyway. If you're breaking this artificial deadline but the clients and customers are happy with the product, perhaps it's time to change the way you as a team work.
One problem with the way you seem to work now is that the ...
There are a few different ways to approach this problem.
From a Scrum perspective, your Development Team does not have sub-teams. You may have specialists, such as people who specialize in testing, but the whole team should be involved. Rather than putting the QA specialists in a position where they must test everything at the end of the Sprint, the whole ...
Tell your devs and management that a Backlog Item isn't "done" until it is tested. So PBI don't get "done" at the end of the sprint, they remain unfinished because the team "forgot" to schedule the necessary QA.
The whole Scrum team should have a Definition of Done and QA belongs into it.
If you can handle irony or sarcasm, ask ...