The advantage of working at many start ups is the occasional exposure to new business processes, especially those that are considered and decided upon at the high level. While there may be the need for education, and some additional hires, the process (whatever it is) will help the company streamline itself, or even make the company more competitive. Or at least that is the thinking.
This is how Six Sigma was presented to us at one company, whose name will remain anonymous at this point since it is still around. This company was a service provider using ASP and MSSQL along with apps written in both Java and C++ that utilized COM and COM+, depending on the various item. So in the middle of the yearly managers meeting we learned that Six Sigma was the way to go. A business process person was hired, books were bought and sent to all the managers, and we were encouraged to help bring this process into the company and help expand our productivity and effectiveness. Were we really ready for any of this?
In a word - no.
The company (especially the Development Heads) was more concerned with getting new software and features out to customers, even with a huge backlog of issues that needed to be fixed in our production code the push was on to get the newest and sexiest feature out. While the issues kept rising, and the bug reports noted the increase, the Development Managers ended up ignoring the Six Sigma and kept moving on the way they were. We could have improved our code some, we actually did two bug fests when we had some massive system hemorrhages, and then moved on to improving our process; or done it in parallel. But we didn't.
Instead we ended up reading the books, doing what we normally do then sit in the kitchen and look at each other saying things like "Did you make that coffee by Six Sigma? It doesn't look very efficient to me." Which was when we knew the process was gone...oh that and the fact the Business Process Person got promoted to the Operations group, and spent her time getting new offices and sites up and running.
Monday, May 22, 2006
Friday, May 19, 2006
Myopia or Familiarity
The other day while changing my son's diaper I noticed that I am following a process, every time I go to change the diaper I get my materials together and set them up in a certain way to make the process go quick. He hates being placed still for too long, this also eliminates the time it takes when he is still asleep and I need to change the diaper without waking him up; I have this down to 5 minutes. But then it happened, part of my process had changed to where I no longer was using the cloth to cover him in case of a liquid projection, and when it happened I was unprepared. Luckily none on me, though I have been close, but the area around him and his clothes required changing. Yet another bullet dodged.
When it comes to testing something on a consistent basis eventually I discover a sort of too familiar attitude crops up to the point where I am going over some areas quickly, and others not so quick. In the same way as my process just becomes second nature, to where I don't think about it at all. It's then I consider that I am either too familiar with the product, which does allow me to test it faster as I know the Test Cases by heart, or its that I have become myopic in my evolution of the Test Cases and pretty much just do the ones I know and maybe do a tinge of Exploratory Testing. I could say that familiary breeds contempt, though I don't exactly hate the application or feel any sort of disdain for the testing I am doing, its just that I have spent so much time with it that I have come too close. I no longer see the whole picture. Being so focused that I see only the design, and the paths that the Test Cases have generated over time.
In a growing group this sort of work can be shared, fresh eyes can come in and look at the Test Plan and find a new way to do things, or enhance the Test Cases. Perhaps adding more for that new piece of functionality that I considered covered by another Test Case; duplicate coverage is another thing best described in the future. Or I can find myself in front of the monitor again, looking to test the application for the umpteenth time and try to pull myself back, in order to get back that freshness and see the whole picture once again. Sometimes I find that I circle around and get back to the same close up view, and its hard to pull myself back to review all the Test Cases again and see if perhaps something needs to be added.
Reading the Cases backwards is one way I've found to add in some novelty to get myself thinking again about how I should go about testing once more; almost like starting over. That's really what I try to do, even if its the thousandth time I have looked at the same Test Plan, I at least try to fool myself into thinking its the first time.
When it comes to testing something on a consistent basis eventually I discover a sort of too familiar attitude crops up to the point where I am going over some areas quickly, and others not so quick. In the same way as my process just becomes second nature, to where I don't think about it at all. It's then I consider that I am either too familiar with the product, which does allow me to test it faster as I know the Test Cases by heart, or its that I have become myopic in my evolution of the Test Cases and pretty much just do the ones I know and maybe do a tinge of Exploratory Testing. I could say that familiary breeds contempt, though I don't exactly hate the application or feel any sort of disdain for the testing I am doing, its just that I have spent so much time with it that I have come too close. I no longer see the whole picture. Being so focused that I see only the design, and the paths that the Test Cases have generated over time.
In a growing group this sort of work can be shared, fresh eyes can come in and look at the Test Plan and find a new way to do things, or enhance the Test Cases. Perhaps adding more for that new piece of functionality that I considered covered by another Test Case; duplicate coverage is another thing best described in the future. Or I can find myself in front of the monitor again, looking to test the application for the umpteenth time and try to pull myself back, in order to get back that freshness and see the whole picture once again. Sometimes I find that I circle around and get back to the same close up view, and its hard to pull myself back to review all the Test Cases again and see if perhaps something needs to be added.
Reading the Cases backwards is one way I've found to add in some novelty to get myself thinking again about how I should go about testing once more; almost like starting over. That's really what I try to do, even if its the thousandth time I have looked at the same Test Plan, I at least try to fool myself into thinking its the first time.
Wednesday, May 17, 2006
Just a review of where I started
Originally published in May 2006, I am moving this to my new home. Enjoy it again or for the first time!
Well as a way to start things here, let me sort of recap my employment, and my foray's into Quality of all kinds over the years.
I pretty much ended up into this after Managing a couple of Support groups, Customer and Technical, and as the person who was the liason to the Engineering department I got exposed to Quality techniques in opening up ways to troubleshoot and report issues. The more I got involved with the QA department the more I realized how interesting it was, the deconstruction of problems, and the generalized knowledge you gain by having to be familiar with all aspects of the software. So I buckled down and started studying some programming and process techniques.
Landing a job as the first QA employee at a startup I worked close with the Engineering Team, who were mostly an offshoot of the group I worked with when I was in Support, ah yes the heady days of working with the evil Empire of NewsCorp. This was the mid-90's when they were in their first move into the internet, and then realized (well the first time anyway) that they didn't get it and laid us all off. By this time the QA group was 3 people including myself this only took 2 years.
So I took my experience of a few years as a tester, and as management experience pretty much translates across jobs, started at another place as a one man team who grew the team as I began formulating what I knew a group needed at a new place. Again, as the lovely days of the DotBomb went on, we had fun and lots of beer lunches, then all got laid off. So I went on to another place, this time we grew the QA group to about 6 people in a year, thinking it was not me I took some time to find a new place and worked as a contributor. That work was more like a summer job, it lasted from June to September, but at least by the end of it I had been introduced to my future wife. Moving on took another year as a Contributor and when that didn't work out went back to the start up phase again. That job lasted 3 years, we built up a solid organization where QA was also the Release Team, as I had done some release work in some of the previous jobs I was given the task, and we at the highest had 8 people total in the group.
Now I am back to being a Contributor, tired of Management, but still enjoying the deconstruction and the learning as I am moving into more Automation and Unit Testing Frameworks. Never went to school for programming, I am all self taught, but I've been lucky to work with talented people to bounce ideas off of, and its good to have some online communities to share experiences with as well.
Since I am caught up, with just a little background, I'll go over many of the lessons I have learned and am learning...if its of any use to you then good. If not, I will at least try to make it an interesting read. Judge for yourself if its worth it.
Well as a way to start things here, let me sort of recap my employment, and my foray's into Quality of all kinds over the years.
I pretty much ended up into this after Managing a couple of Support groups, Customer and Technical, and as the person who was the liason to the Engineering department I got exposed to Quality techniques in opening up ways to troubleshoot and report issues. The more I got involved with the QA department the more I realized how interesting it was, the deconstruction of problems, and the generalized knowledge you gain by having to be familiar with all aspects of the software. So I buckled down and started studying some programming and process techniques.
Landing a job as the first QA employee at a startup I worked close with the Engineering Team, who were mostly an offshoot of the group I worked with when I was in Support, ah yes the heady days of working with the evil Empire of NewsCorp. This was the mid-90's when they were in their first move into the internet, and then realized (well the first time anyway) that they didn't get it and laid us all off. By this time the QA group was 3 people including myself this only took 2 years.
So I took my experience of a few years as a tester, and as management experience pretty much translates across jobs, started at another place as a one man team who grew the team as I began formulating what I knew a group needed at a new place. Again, as the lovely days of the DotBomb went on, we had fun and lots of beer lunches, then all got laid off. So I went on to another place, this time we grew the QA group to about 6 people in a year, thinking it was not me I took some time to find a new place and worked as a contributor. That work was more like a summer job, it lasted from June to September, but at least by the end of it I had been introduced to my future wife. Moving on took another year as a Contributor and when that didn't work out went back to the start up phase again. That job lasted 3 years, we built up a solid organization where QA was also the Release Team, as I had done some release work in some of the previous jobs I was given the task, and we at the highest had 8 people total in the group.
Now I am back to being a Contributor, tired of Management, but still enjoying the deconstruction and the learning as I am moving into more Automation and Unit Testing Frameworks. Never went to school for programming, I am all self taught, but I've been lucky to work with talented people to bounce ideas off of, and its good to have some online communities to share experiences with as well.
Since I am caught up, with just a little background, I'll go over many of the lessons I have learned and am learning...if its of any use to you then good. If not, I will at least try to make it an interesting read. Judge for yourself if its worth it.
Subscribe to:
Posts (Atom)