Who What Where When Why How?
| 2011/03/29 | Posted by CCAdmin under Uncategorized |
Who Am I?
My name is Chris Chartier. I graduated with a Bachelor’s degree in Computer Engineering in 1997 from the University of South Florida and then got a Master’s degree in Computer Engineering in 2003. I’ve been developing software since 1998, in and out of Software Testing that entire time.
What Is My Purpose (For This Blog)?
Over my career, I have been in and out of Software Testing, but it is not until recently that I’ve decided to take that direction seriously. Now that I have, I’m jumping into Software Testing head first. *Germonimo*
My purpose is to entertain you, educate you and take you with me on my journey. Sit back and relax. I’ll do the work; all you need to do is enjoy the ride. If I succeed in my task, you will learn a few things as we go and have a laugh or two too.
Where Am I (Professionally Speaking)?
As I stated earlier, I’ve been in and out of Software Testing for most of my career. However, it was seldom my “focus”. I had always considered myself a “software developer”, but I just so happened to be developing software for testing purposes most of the time. For a long time, like many, I saw “software testing” as a lesser role – something that you gave to rookies fresh out of school. It is only recently that I’ve finally overcome that mental hurdle to realize how absolutely FALSE that is (more on that later…probably a separate post just on that topic).
My first role was testing operational flight software for aircraft Embedded GPS/INS (EGI) Navigation Units at “an Aerospace company”. The team I was on wrote scripts in a proprietary language (kind of a mix of DOS batch files and assembly language) to exercise various functions of the box. In the end we were testing to the unit’s functional requirements.
Later, I moved over to the Space side of the company. The Space division worked on things like satellites, the space shuttle, etc…. One of my early projects was writing test vectors that probed and tested various circuit boards that went into the Space Shuttle Main Engine Controller (SSMEC). It was nice to say I worked on the Shuttle program, but not very challenging as a software developer. It was more tedious than anything else.
The next major job shift was the best one ever. I got into a program that was really cutting edge compared to my previous work and I got to work with a lead who was a fantastic guy who I’ll call Dave (because his name was Dave). Dave mentored me well and really took me to the next level as a developer. Working with Dave, on the software reuse team, our main mission was to canvass the various programs under the entire Software department and determine what reusable software modules we could develop that would help multiple programs with the obvious goal of software cost avoidance.
We really went about this in a sophisticated way compared to most software that was being developed on programs in our department. First, Dave was a UML guy, so he taught me to design in UML for our various software projects. I didn’t realize, until recently, how new UML was at the time…it had probably only been ratified as a standard for a year or two. He also taught me about design patterns, and we used many patterns in our software projects. The Abstract Factory and Singleton patterns came up quite frequently and were heavily used.
The short version of the story is we created some great products and saved hundreds of thousands of dollars (possibly more) for the company. We developed software with reuse in mind. It’s all about interfaces. When done correctly, you can develop software that becomes easily cross-platform. For example, I wrote some serial device drivers with a standard interface that was carried on to about four or five different embedded platforms. When adding a new platform, one need only change the platform specific “concrete” functions underneath that implemented the interface. The interface and apps written to the interface do not need to change. So, for example, a file transfer routine is written to the interface on one platform and can easily be used on another platform without changing the file transfer routine one bit.
After a few years of doing the software reuse, we took on our biggest project yet. We were going to develop a test suite application that all programs could use as their testing harness application. We took requirements from all the programs and developed it from the ground up, using java to be naturally platform independent. It was a large and well used application and was big enough to need frequent maintenance for added functionality.
At this same time Dave hurt his back and was out of work for many months. Sadly, the software reuse effort kind of fizzled, and I became the maintenance guy for this test framework for the next few years. It wasn’t bad…I added a standardized driver framework for our GPIB devices based on a similar effort another engineer had started, but after a few years it started to become tedious. Through many slower periods, where maintenance wasn’t required, I worked on many test software projects and developed many test cases and wrote lots and lots of test scripts. I even led a few of the programs – particularly some that were done offshore.
Then I transferred to the company’s Redmond, WA office (from Clearwater, FL). I was chosen to essentially do maintenance on their home brewed test framework application. It was an obvious fit since I was the maintenance person on our test framework app in FL. Let’s just say that position was not as exciting as I’d have liked it to be. At the time my purpose was to get the transfer to the Redmond office (really love Seattle), so for that goal it was a success.
Luckily, after doing that for a few years, I found a job opening in the company for a V&V (verification and validation) position. It looked to be more geared toward process, but I went for it was a level higher and it couldn’t possibly be more tedious. I got that position and started working strictly in the testing (V&V) arena from that point on. The position was more than just process…I got to work with many, many pilot programs to help lead their testing efforts. It was quite technical as it often required me to play the “mentor” role.
I’ve been in this role now for over a year. About a year into this position something finally “clicked” in me. I realized that testing was a great direction for me. I really felt connected as if this was an area I really excelled at. Then I started looking into testing more, and I realized there was a whole world of information out there I was unaware of.
So I started reading. I thought I knew a lot about test, but the more I read the more I realized that my company was really in the dark ages. While I “knew” that our waterfall software process was outdated, I had no idea just HOW outdated it was. My company makes “systems”, not “software”, so although software provides 80% of the functionality in those systems, the culture has not caught up and software gets lower priority. It seems software is not given the attention (e.g. resources and budget) it deserves.
So, as a “software guy” I’ve started really focusing and researching software testing. I’ve read books and blogs. I registered as a member of the Association For Software Testing (AST) and signed up for one of their classes. Lastly, I’ve started this website and blog to chronicle my journey, espouse what I already know, teach things I learn along the way and hopefully entertain a few of you too.
Why Do I Want To Write About Software Testing?
As mentioned above, I made this “realization” that Software Testing was the field I belonged in. I’m excited about that because I feel like I really finally found what I was meant to do. Not everybody finds that in life.
I’m excited about things I’m learning in this process and want to share those. I’m excited about organizing my thoughts on things I’ve already worked out and think are worth sharing. Even if nobody reads this blog, it would be a repository for me of gathered information and ideas.
How Do I Plan To Move Forward?
I already know a lot about testing. I don’t mean that in a conceited way…in fact, quite the opposite. I’ve started reading on the topic and realize that although I know a lot, there is a LOT I don’t know. I’ve been very sheltered with my current employer of 13 years. Things are done a certain way, all the time, so there are lots of topics that I’ve not been exposed to – some are probably even fundamental topics in testing.
So to move forward, I’m diving head first into software testing in a big way. I’m reading books, yes, whole books on the topic. I’ve already read one cover to cover and have 4 or 5 more books at least I plan to go through. I’ve signed up for a Black Box Software Testing course to learn some fundamental topics there. I’m now reading many blogs from others in the area and plan to attend more webinars and testing events (like Weekend Testers). I’m also hoping to attend the AST conference this August as it’s in Seattle (local for me). If I can’t convince my employer to send me, I may just pay for it myself.
Hopefully I can take the things I learn back to my employer and be able to effect some positive change. If done well, I can hopefully influence process change and save the company money. However things shake out in the end, I now know where I need to be and will work toward putting myself there.
Thank you for reading. If you made it this far, you are either a glutton for punishment or love to laugh at nerds like me.
Recent Comments