PM-Dev-QA Interaction Process

Contents 1 PM should do: 1.1 Points to be noted: 2 Dev Team should do: 2.1 Points to be noted: 3 QA Team should do:

PM should do:

1. Write Functional Spec (FS) as a Draft.
2. Get FS Draft to be reviewed by:
   1. The Customer (for example, HIS) in case of collaborative development
   2. The GPS team as a representative of the Customer for us
   3. Dev/QA in any case, and moreover in case of Internal projects
   4. UX* in case the feature involves an important GUI change
3. Write FS Final taking into account all parties feedback
4. Get FS Final signed-off by both Customer (if applicable) and/or GPS/Dev/QA/UX* teams
5. Write user document and help on translation

Points to be noted:

• FS Signed-off means that the initial required information (basis) from the point of view of Customer/GPS to fulfill their needs and Dev/QA/UX* teams to start working on project is in there, so that everyone is on the same page and understand each other. Later on during development cycle FS can be changed (if required) under PM approval
• FS sign-off means that Customer/GPS, Dev/QA/UX* must edit FS wiki page and fill in "sign-off" cell with OK and a date.

Dev Team should do:

1. Review FS Draft
2. Sign-off FS Final
3. Write Technical Specification Draft
4. Prototype the feature to be implemented. In case of GUI-heavy features, UX needs to be consulted to design mockups of screens and flows before actual prototyping (code) starts.
5. Present a prototype and Technical Specification Draft to the Product Owner, Customer (if applicable), GPS, UX* and internal development committee: OB Functional and Technical experts (EAR, GDA, PSA, those of them who can attend) and Management.
6. Coding / Feature implementation
7. Inform QA when they estimate code is going to be ready for testing
8. Development feature testing in a wide set of environments: main-ora, main-pg, qsqss. For modules it also includes installation tests in these different environments from Stage
9. Deliver feature (published in Stage for Modules, branch access for big core changes) to QA for testing
10. Fix the bugs reported by QA
    1. After fixing the bugs Dev team has to execute all the test cases written by QA.
       1. If the project has lots of test cases (more than 10) then developers only test the critical or important ones. QA will guide Dev Team here.
    2. Dev team to send a confirmation to QA that all the tests passed before delivering feature back to QA for re-test
11. Final feature presentation to the Product Owner, Customer (if applicable), GPS, UX* and internal development committee: OB Functional and Technical experts (EAR, GDA, PSA, those of them who can attend) and Management.
12. Feature release/delivery (CR publication, PI merge)

Points to be noted:

• Prototyping is very important to get early feedback. It could be done just with windows / business processes mock-ups. Recommendation is to use 20/80 rule of the project efforts and length for the first prototype version. For big projects it makes sense to have several prototypes demos during the project progress. For initial idea generation and wireframing, always consult UX for features with a heavy GUI component. For tips & tricks on sketching, modeling and wireframing, do also consult UX.
• Internal development committee aims to get Functional and Technical feedback from most senior people in OB which we should value a lot.
• QA should maintain the result of the execution, number of test cases failed during the execution.

QA Team should do:

1. Read the functional specs.
2. Sign-off the FS
3. Design the test cases and setup environment required (Oracle and Postgre)
4. Once code is ready, execute the test cases just once and log all the issues
5. Once Dev team confirms to QA that the issues are fixed and tested QA does the final round:
   1. Second round of execution of the test plan
   2. Closing resolved issues
6. Green lights for Release

Categories: Templates | Methodologies