I have some questions or complaints about the information on the process for API-Testing based on CWS.
- In the first chapter, what does 'CWS is ready' means? You have to clarify the word 'ready'. Does it means the developers finished their work or does it means the QA has also approved the CWS. Should the CWS in state 'ready for QA' or should the run of the API tests be done before the CWS state will be set to 'ready for QA'. Please be more specific here, otherwise it isn't possible to adjust the CWS approval process.
- The link for 'to get an exception' doesn't work.
- What do you mean with 'good arguments'. If you write such sentences you have to bring examples. If you want to be funny with this, than it's the wrong place here. You want to describe a process and then you have to give information, what are the arguments could be or that there aren't any arguments. Processes have be documented very clear and not funny.
- Who can approve an exception. Should this be done by the manager really? Who is the manager of a community member? In my opinion it has to be clarified in the project itself and the project lead should be responsible for that. Or shouldn't he know about an exception?
- It isn't needed to get an exception from the QA representative. Often he doesn't have enough information about the API testing and the consequences. But it is needed to put the information about an exception or about problems with the API-Testing into the CWS descriptions. This should be a must and documented here.
--cn 15:51, 20 June 2008 (CEST) Hi Thorsten, thx for you comments! I am be more specific with the "CWS is ready" and "what is an exception"
The idea to describe problems in the CWS descriptions is a very good idea. I have added this. And you are right if you say the a QA representative could not decide about the importance of UnoAPI issues. I have removed them from the exception treatment process.