Time to Market

I have a software development business on the side of my day job. Recently I have focused my business on writing small programs that would be of interest to hackers. The programs I develop are posted on my Black of Hat blog. Currently I am giving my programs away for free to try to increase readership of my new blog.

The interesting thing about these programs is that I have not been subjecting them to rigorous testing. Often times the goal is to get some software posted out on my blog quickly. So I run a couple quick unit tests, fix the obvious bugs, and warn my readers that the software may be in an early state.

My goal is to write many useful programs quickly. Of course I plan to improve and fix any bugs that pop up. But there is a definite lack of V&V being done. The question is whether formal test methods would be of any value in this fast paced environment. I don't get any direct penalty for releasing a program that crashes and burns. There may be some unhappy readers which turn away from my blog. However I am considering the faster time to market to be the prime objective.

Perhaps I could take my next program developed by my side business, apply more thorough testing to it, and try to measure the outcome subjectively. I am not against going through a formal test cycle for these programs. The objective is to gain the most amount of readers so that I can monetize my blog. Any way I can do that more effectively is worthwhile. Besides I feel as if I may be developing bad habits in my side business software development. It would be easier if I use the same methods in both my day and night jobs.

Test to Dev to Test

Over my career, I have met a number of software developers that have become testers. These testers often tell me that they got tired of working the long hours in development. They say that testing, while challenging, is less stressful and easier that writing code. And these are usually the testers that are creating scripts or writing code to test data.

I have also met developers who said they got trapped in the test environment. First it starts out with the need to write a high profile master test plan. Then who better to oversee the test execution than the author. Pretty soon you get known as somebody proficient who can run tests, and then you are pigeon holed into being a tester.

There is one other scenario which is not encouraging. Sometimes developers who just do not cut it as programmers get reassigned to the test team. It is almost as if this is a demotion. This seems strange as the top talent in the test world seem to make good money. Maybe it is just a psychological effect.

The reverse path appears to be difficult if not impossible. I have not met many developers who said they started out as a tester. There was one guy I knew who was pretty good with code. He wrote a lot of scripts to generate test data. But he was still officially assigned to the test team. Maybe there are such developers, but they don't want to talk about their test background. Still it seems a very rare move. It looks like a one way street between development and testing roles.

Top Notch Testers

Recently we had some late new requirements that needed to get into the system. We rolled them out after our latest major release of the software. There was a hasty test cycle before shipping the software out the door. And guess what? There are a lot of problems with the code in the Production environment.

The good news is now that we are fixing the problem, our internal test team is better equipped and has more time to verify our changes. A recent set of changes has failed internal test a couple times. Seems I have made a number of invalid assumptions about the data in the system.

A lot of the good testing comes from the fact that the tester assigned to my code is actually an old developer. He used to sit next to me in my cubicle on a past project. Somehow he got moved to the test organization. And now he is taking test to a whole new level.

This reminds me of another tester from a couple years ago. Let's call her "SJ". She astounded me and my team when she first started verifying out fixes. SJ has a deep technical understanding about the changes we were making. Sometimes she even dug down and showed me where I had made mistakes in the code. When I asked SJ how she was able to figure this out, she said that she too was a developer in a past life. She wanted something different and was doing testing now.

Not all testers have to be developers at heart. But I have found that it certainly helps.