Scrum quality and scaling

We have merged this meeting with the previous days meeting around testing and Scrum.

Overall the discussion was broken into the following area’s;

Testing within the sprint – Definition of Done

Integration testing – On a larger scale this was a separate team and done ongoing and sometimes separately

System/stability testing – This was not part of the sprint for most teams and was done by a specific team.

Specs,

• Helps with the timing…writing down “here is what I am going to build and here is what I am going to test. Try not to have process for process sake.

System testing

• Time boxed regression testing, Things found during regression gets pushed into sprints.

• Full time Systems testing, integration teams travels to different teams finding gaps and work with teams, senior QE people.

• How do we stop handoffs? Teams continue to feed into systems testing

• Each sprint is delivered into system team for further testing

Infrastructure

• Build system is very important, some one did a value stream to find the bottle neck and make it more efficient.

• Problems with not feeling the immediacy of fixing the builds. Various suggestions as to how people have dealt with it. Singing fish Monitor with picture of the person who broke the build. Emails seem to be ineffective

• Each module owned by a named developer and they would be sent email and would immediately resolve, build sheriff appointed at certain critical times.

• System where the last check in gets an email. If build breaks.

• Triaging can sometimes be tricky, idea of building up a build posse in order to identify the problem

• Is it the build masters job? Configuration manager…needs to be someone technical- pitfalls is attitude and denial from development …”not my boss”

• Maybe need a program manager to ping integration

• Friday top 20 bugs….fixed in a day if not they are rolled into the sprint planning. Fixit Friday

• Cruise control is great, get red icon on desktop

• an integration stability team might make teams lazy, not testing leaving it to integration team to sort it out…maybe just QE.

Measuring Quality

http://www.amazon.com/Measuring-Software-Design-Quality-David/dp/0135685931]… reference book by Robert glass.

• Bugs

• Code coverage

• Performance

• Stability

• Functional testing… manual testing…automation is key

• Test case to lines of code is another measure.

Test driven development

• http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ref=pd_sim_b_title_3 Mike feathers reference

• Need good programmers for tdd, expect the velocity to go up.

• Training is needed but feedback is very positive, should rename to intention testing , lookout for refactoring….tdd is a safety net, better and more efficient code http://www.martinfowler.com/ and Robert martin referenced…tdd is a cushion for organic design…bowling example discussed.

Unit tests vs component tests.

• Test first? PO ultimately should write reqs as a test. Executable reqs.

• http://fitnesse.org/ tool is helpgul dev need to write hooks for it to work but works well.

• Specify inputs and outputs powerful tool write something with http://selenium.openqa.org/

• Have to do setup and tear down good for unit tests once features are in the bus analyst could use it…similar to wiki. Good for acceptance testing as well.

• Developers should execute the component tests as part of competion.

• QE take customer view need to promote finding and fixing within sprint without logging bug.