|
Have you ever noticed, as a software project comes to an end, you will see all the developers in the same state. You will see long beards, long faces and long groans... All the developers would be in the same state for one reason. They would be doing the thing that they hate the most. Testing. The QA team would be breathing down upon their necks, the client would bebreathing down upon the necks of the delivery guys / engagement manager, there would be a lot of fatigue because all the developers have been working on the same project for a year or so depending upon the complexity of the project. Defects keep appearing on modules that were developed over a year ago… Some of the developers are even new who are providing maintenance to code that has been written by someone else… And they complain that the guy who wrote the code was an imbecile… And eventually everyone just keeps praying as to how you can get over this project, get released and start off something new…
What do you do about it? I have been wondering… how do you make the last couple of months’ experience interesting? Well most of the last few months of any project are dependant on QA. Now that’s what the developers hate the most. And that’s what they are expected to do towards the end. Wouldn’t it be great if all the dirty testing would just go away…? Well it wouldn’t go away, but we could surely automate it… when I say automate, I do not mean the automated testing tools that are available… that’s the QA’s work to use automated testing tools to test the build. I am talking about automating the testing that the developer has to go through before releasing it to QA… One thing that developers do not mind doing is code. So why not do something in a good way so that the entire QA Experience in the end becomes pleasant.
Build an NUnit framework right from the beginning. Doing this from the beginning is a very good idea. Reasons? The energy level is high, the deadlines are not very tight and everyone has enough bandwidth to just do it. Once we have completed 1/3rd of the project, things start getting a little tight… this is the time when the team lead should kick in some discipline. A module shouldn’t be considered complete until the test cases are written. The leads should also consider the time to write test cases in their estimates.
By the time 2/3rd of the project is done, most of the unit test framework is ready. Now where this helps is that once you have changed some code or added some component, you can run the tests and make sure that nothing that has already been written and was previously working has not broken. That way we don’t have to test every little piece of code that has been written since God created the heaven’s and the earth… well 10 months into the same code and it does feel like that…
Last 1/3rd of the project, three things happen… one people will realize the merits of writing tests. Second people will get habituated to writing tests and third the frequency of new tests would decrease.
There is more automation that can be brought into development. But this would involve writing utilities and using over the team… utilities which are custom… like to test a particular scenario you require a specific set of data in the database. And there are so many such “scenarios” that you need to test. We could broadly classify these scenarios, and write SQL Scripts to generate a set of data that would enable the testing. Write a simple crude utility that could give you a choice to choose a classification and create the required environment.
In fact I was thinking could I create a generic framework that would enable me to automate such mundane tasks across projects and make software development exciting… If work is exciting, quality would most definitely follow… |
|