Wolfgang becoming a testing professional

My time as a test manager is over again. As the Munich development site of my company is shut down, I also decided to go on and not to become a remote worker without a home base.

For me it is pretty important to have some engineers around and to embed test activities into the overall development lifecycle. As there would be no one ele then me around in Munich, I would have been either traveling around all the time or on video conferences every day. THat is not my preferred way of working.

Let’s see, how much I will be involved in testing in my future engagement.

Today I got notice that a talk proposed by Alexander Buchmann and me for Seacon 2011 is accepted. It is a German conference held in Hamburg my former home town. I am really excited as this is my first talk in the testing arena.

The title of our talk is “High performance software architectures – planning, coincidence or experience? See our secret recipe!”

Based on our experience we will deduce, why creating the correct load model is an iterative approach and can’t be done right in the first shot. We also point out reasons for a changing load once the system is used by the end customers. Based on our experience, we show a use case based approach for performance modeling and performance measurement which is quite different from traditional models which are reasoning about excessive usage of single system resources like CPU, disk I/O and network traffic.

Looking forward to meet you in Hamburg.

When I started my tester career two month ago, my department was called SI. I missed to ask what this acronym stands for, because becoming acquainted with my daily tasks as well as reacting to the daily escalations really consumed all of my time. Today by the way I know that SI stands for solution integration . After some days I updated my profile in the social networks I am registered to. Choosing the right job title gave me some trouble and because I didn’t find anything better, I typed in QA Engineer. That was the title some friends and former colleagues working in the testing arena use in their profiles.

But: I did not feel comfortable bearing that title.  I kept on reading books, different blogs and watching recordings from Google Test Conferences. Then it finally sunk in: QA as well as SI lack something I always felt is an important part of my work – engineering. In addition the testing part seems to be minor to QA and SI. To my understanding, QA is more concerned about the processes: QA takes care for process definition and improvement, repeatability of all steps in developing a product and that the product will meet the requirements.  Testing on the other hand is an activity to execute a system with the intent of finding defects. It becomes an engineering task if tests are planned prior to the execution of the test cases.

In one of the videos Patrick Copeland explained his conception of test engineering and it pretty much matched what I think I would like to work on.  Patrick explains the principles they introduced in Google to change their test culture:

• Embedding testing at the grass roots level
• Solving problems of scale with technology
• Automating at the right level of abstraction

Google test teams used these principles to shift from a “service group” composed predominantly of exploratory testers to an “engineering group” with technical skills. More details of Googles approach are given in one of the posts at googletesting entitled “The difference between QA, QC, and Test Engineering” .

I think this is exactly the shift of mind that my organization started when moving from a waterfall process to an agile approach. Unfortunately we stopped half way and ensuring testability of our products will obviously be my major task. I will have to

• ensure that the products are adequately unit tested
• review design documents and ask for more test hooks in a project
• ensure that testing can be automated further

I feel challenged to work as a test engineer.