I would like to share my working experience at VMWare, in this last 1 year we have been improving a lot in our software development process

Last year, We had much much higher regression rate and it’s all back to the battle against developers and QA. We as developer always try to make our self look right and always feel confident that we are taking the right approach and there is no flaw in our code.

Once the build is started and installed, then QA start raising bugs to us and this process of back and forth is really not efficient and causing the software released to be delayed, frustrated developers and frustrated QA and it affects the whole thing

So how do we improve the quality

1. Code Review

-We are using Review Board to do code review before we check in the code and not after. We need to get “Review Passed” by other developer before we can check in (we use post-review command line with the changeset number to post the review)

-We need to write down our “Unit Testing” (e.g login to admin, press button A then it shows ABC) in our review

*We don’t use TFS but TFS has its own code review, but if you want to use Review Board for TFS then you can read awesome article here

2. User Acceptance Criteria

-This is a simple things that we never thought before, what we are doing now is to sit to have a developer and QA to sit together and draft the test cases for a task that the developer is going to do

-Important, we don’t start the coding first. By doing this, the developer can think about their solution carefully before writing the code and look from the broader perspective

3. Unit testing

when you have your code base flexible or modular then you can start writing unit test first before start writing the code. So you write the code to pass that unit testing criteria – TDD (Test Driven Development)

-When I say the code base is flexible or modular means that it is possible for you to inject your unit testing with some fake data/implementation

4. Developer need to be pride with its own code

We as the developer need to put pride in the code, we need to be able to explain of what your code does to other developer

-Developer need to be able to explain why your coding/solution approach is better than other coding/solution approach

-Always think maintainability, make sure you are not over engineered the solution and make sure the code is easy to understand and maintained. Make sure the code can be extensible easily in the future by other developer

-Always think scalability, how scalable is your solution when the system is growing larger

-Don’t forget to put comment in your code because it will help a lot for other developers

Conclusion

This all will take longer to start doing this, but once you and the team get used to this process then you will see the better quality of software and less frustration for the developers and QA. It will be faster at the end of the day because of less bounce back from the QA team to the developer and it results on more productivity for both teams.

It’s not a simple process but one keyword that you need to keep in mind “Believe” that this process will work