Hot answers tagged

7

The biggest problem I see with this is that you're looking at a mini-waterfall rather than a sprint. The description you're giving above forces the team to deliver all or nothing. What if they have 12 items in the sprint and deliver 9? Does that mean you won't test or release what has been done? If so then I dread your release schedule, every time any team ...


7

The ticket should be in the column it belongs in, which sounds pretty stupid to say and is exactly why I'm mentioning it. The ticket was being developed, then handed off to QA who found some defects. The ticket now goes back to an engineer to be fixed. Thus, the ticket should go back into development. Each column has a group of people or teams that are ...


6

This looks like a non-iterative version of Acceptance Test Driven Development. Like all non-iterative processes, it suffers from the fact that it assumes it can perfectly predict the future, that the client never changes their mind, that requirements, markets, environments, and circumstances never change. ATDD works in an iterative fashion: the test ...


5

There are a number of ways to ease/share the burden: Tools You don't say what languages you're using but there are many tools out there that can do basic analysis for you such as StyleCop, ReSharper, FxCop etc. Code coverage For well tested code, coverage percentage should be in high 80s at least. Peer review Even if you're still the gate keeper, you ...


5

Software verification and validation are all the activities that ensure that the software fulfils all the needs and requirements for its intended purpose. As such V&V is part of the larger set of Quality Assurance activities (the latter also include activities to improve the quality, beyond the area of quality control to which V&V belongs) The ...


4

There are two techniques that work together to avoid this type of scenario from occurring: Step 1: write a failing test before fixing the bug When the bug has been found, the first thing to do is to write a test that will pass when the bug is fixed and thus it fails whilst the bug still exists. The dev then fixes the bug and in the process makes the test ...


4

The relationship... doesn’t exist. Modern software development generally doesn’t have discrete phases where you take and validate some input, do some work, and then pass it down the assembly line. And these days even having a separate role for testers or other quality assurance work is more and more rare. At the scale necessary for most software, the ...


3

I would do QA on the dev (or master in your case) branch rather than the feature branch. Devs should test on the feature branch to ensure the features are complete, but QA should test the product as a whole after merging in the new feature. Otherwise you are testing twice, on the feature branch and after merging Just to do the sums, assuming no bugs found ...


2

Putting the dev/tester ratio issue aside, since you probably aren't in a position to fix that, the problem seems to be with your feature branches lagging behind master. As Ewan has pointed out, you want to be testing code that is representative of what will be deployed. So, testing on a feature branch that is behind master is not great. What you could do ...


2

I wholeheartedly second David Arno's suggestions about failing tests and code reviews. Also, there are often ways to write the code to make it less susceptible to that kind of error in the future. For example, if the error was created by calling a function before its prerequisites were met, you can split your classes differently so that would create a ...


1

This metric, to determine what percentage of tests pass, doesn't make much sense to me. There are two reasons why a test would fail: The test found an error. Some change in code caused the behavior under test to change and the test is alerting you to a case that needs to be considered. The change needs to be reworked to ensure that the system has the ...


1

It's very tempting to answer your question with "it depends", since that's the answer to many "should I...?" questions. In this case, however, the answer is no. You should not create a sprint test plan. At least, not a formal one. The only test plan you need for a sprint is "verify that every completed story is well tested". As a QA engineer on a scrum ...


1

I see tests at most complementing the human code review Hmm out of everything you say this stands out to me the most. Maybe there is a nuance to your meaning here, but always remember that the idea is to produce working software, not well coded software. I would suggest the first thing you do is write down the rules that you are reviewing the code against. ...


1

A few things stand out to me. First, the ratio of developers to testers stands out as being very lopsided. In my experiences, a good ratio is about 3-5 developers to 1 manual tester. This seems to work out well as long as the tester is involved from early in requirements development to begin to start identifying test strategies, approaches, and cases. The ...


1

Stop asking QA to test everything all the time. Get the developers to do it themselves. Where I work, QA don't do testing. They are there to ensure that developers are following the correct process. The only time they get involved in testing is the final formal test before software is released to a customer. Even then, they are there to ensure that the ...


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