2 Replies Latest reply on Oct 25, 2010 9:41 AM by Nick Belaevski

    RichFaces 4: Initial Quality meeting minutes and discussion

    Ilya Shaikovsky Master
      • 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
          • 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
        • 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.
      • 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
      • 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

       

        • 1. Re: RichFaces 4: Initial Quality meeting minutes and discussion
          Jay Balunas Master

          Ilya - Thanks for the write up, very good!

            • 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?

          I believe this should start with M4.  I think it is a waste of time to retroactively set these links.

           

          • Points from dev side to improve quality
            • devote some time to improving unit tests capabilities. E.g. adding of xHTML validation on the fly.

          Agree, but I believe Alex said the jsf-test has some of this built in.  I do not want to re-invent the wheel

          • 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

          Also agree from meeting, likely not worth the change at this point, and requirements are too fluid atm.

          • 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

          This one, I feel pretty strongly about.  I think that all jira's should moved to future_4.X and then assigned, and planned for in next iteration.  There is too much blind shifting that makes jira unrealistic.

           

          We should create some jira's to update the various process wiki's with final updates from this discussion.  I don't want to spend a lot of time on this, but some will be needed.

          • 2. Re: RichFaces 4: Initial Quality meeting minutes and discussion
            Nick Belaevski Master

            Alex S working on pluggable demo prototyping.

            What's JIRA number and current status?

            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.

            This is one of the most important points - should be outlined in this thread.

            If some attribute works partially in base - that should be reflected in jira (or wiki page?)

            If this is known before testing started, wiki page is sufficient otherwise I'd insist on making additional JIRA comments so that QE is updated on the changes quickly.

            Agree, but I believe Alex said the jsf-test has some of this built in.  I do not want to re-invent the wheel

            Alex, can you please provide more information?

            This one, I feel pretty strongly about.  I think that all jira's should moved to future_4.X and then assigned, and planned for in next iteration.  There is too much blind shifting that makes jira unrealistic.

            Ok, we'll do.