As we all know, Siebel configuration work is quite different than other software development because we only do the customization based on vanilla Siebel by using Siebel Tools. If we want to conduct Siebel automating testing, we have to use some commercial tools such as QTP and LoadRunner.
I have been working on a large and complex Siebel project for more than two years as an offshore configuration lead. The challenge is how to produce high-quality code during Siebel implementation without automated testing. Here I want to share some ways on building high quality in my team:
1. Defining the code standard document
After the project kicking off, the architect should define the code standard during the sprint planning phase. The code standard document should be used by developers for their daily development work. It will help us produce more readable and easily understood programs.
2. Building a code review checklist and improving it
First, we can use the checklist if we already had in previous project, but this checklist might not be suite for your current project, we need to keep improving this checklist. We can add more checklist items if we find the same defect happen several time but not addressed in the checklist. Or we can prune the useless checklist items if that are not finding problems. For example, if we all know we need to use Symbolic String for applet control caption, and then we can eliminate this check
3. Peer review with checklist
After the developer implements the user story, he/she should take initiative to ask other developer to do the peer review. Here is the normal peer review process in order:
-
Perform the testing based on the test cases at Local
-
Review the code based on the code standard and cod review checklist
-
Check in the changes into the code base
-
Bounce the sever with the compilation with the changes
-
Perform the testing based on the test cases at Server
4. Implementing the feature based on the user story and test cases
We are trying to apply Test-Driven Development to our project, the test team will develop the test cases based on the user stories provided by BA, and then BA will review the test cases and put the user story with test cases in the next sprint, developer will customize Siebel application based on the user story and test cases.
5. Having the specialist for each module
Because we are developing a large CRM system which will cover different modules (e.g. Assignment,Notification,Entitlement Checking,eService,etc). Each module will use different techniques and has different business focus. No one can master all of the modules, so we need to have the specialist who will mostly be focus on one module. So when developing these modules, in our team, some senior developers will be in charge of these modules as a specialist on both business and technical areas. All the changes made by other developers should be reviewed by these specialists accordingly. For example, Charlie is regarded as a expert in eService developing, he will be the best person to review your code if you want to do some changes in eService.
6. Defect Analysis
Unless developers find and correct the defects they inject, these defects will end up in the finished product. To produce fewer defects, we must learn from the defects we made. We will have a defect analysis session at each sprint to divide them into categories. By categorizing defects into several types, we can quickly see which category cause the most problem. Besides, we will also share some methods to reduce defects.
7. Pair programming when new developers join the team
When new developers joined the team, we could do knowledge transfer to them to share requirement, software architecture, developing tools, develop process and so on and so forth. But we did find that would not help them much to deliver a high quality code, then we used pair programming for speeding up the new developers from both requirement understanding and being familiar with process and coding quality.
8. Knowledge sharing
Knowledge sharing might have not direct relationship to Quality, but while conducting the knowledge sharing within the team, the team will get improvement in sharing requirements and technology and hence the knowledge sharing will be also a key to quality in implementation.
