RichFaces 4: Initial Quality meeting minutes and discussion
ilya_shaikovsky Oct 22, 2010 9:33 AM- QE teams suffers from basic critical issues which should be found during component development
- point risen a few times and we need to improve process of development:
- with more carefully designed development samples
- basic operations like changing skin, re-render, nesting in table should be there
- Alex S working on pluggable demo prototyping.
- with continuous checking the component on the samples and making sure things are ok before code freeze.
- All existent problems before freeze should be filled in jira by component developer.
- All such issues should be linked to component QE task.
- Who will lead that and link ones which missed to be linked from dev side?
- QE issues also should be linked from there during component testing
- All such issues should be linked to component QE task.
- Ideally developer should also write about component risks if known exsit in order to help QE to concentrate on such areas.
- Addition of attributes could be done only together with the code which handles them. We should not add unimplemented attributes using just bulk migration component properties from 3.3 and further impl.
- If some attribute works partially in base - that should be reflected in jira (or wiki page?)
- differences of usage from 3.3.x if exist should be covered at wiki page
- with more carefully designed development samples
- some issues risen could be related to miscommunication/some issues in requirements
- issues should be risen for requirements to keep them in sync
- QE engineers could also communicate with dev team directly more if questionable points appears in order not to waste time on figuring out some functionality.
- point risen a few times and we need to improve process of development:
- Need to provide components to QE as early as possible. Nowadays QE applications getting updated too late to complete QE carefully before release. Some functionality getting tested in next iteration.
- some exceptions could appears for sure - huge components like trees could be delivered close to freeze, but ideally we have to promote complete base components early and continue develop features together with base QE
- Points from dev side to improve quality
- devote some time to improving unit tests capabilities. E.g. adding of xHTML validation on the fly.
- TDD with stable requirements?
- not likely appears in current process.
- QE could waste time on design by requirements and then re-design when things changes
- Environment questions
- Sun JDK & released versions of Chrome/FF/IE as mainstream
- update our browser matrix wiki page
- Sun JDK & released versions of Chrome/FF/IE as mainstream
- Jira
- moving postponed issues to next M instead of future 4.x ? With further moving to next one if not going to be fixed?
- Not sure about community side. Some guys could follow and expect a fix then
- Also planning could be less clear then
- moving postponed issues to next M instead of future 4.x ? With further moving to next one if not going to be fixed?
-
21.10.2010.log.zip 14.4 KB