Leadership (part 1)

I am on a quest to become a leader. I have given it more thought this year than all years before. Even though I have spent years as a software test manager, I believe that I have only scratched the surface. I appreciate your comments.

Imagine yourself working at a company that is facing a challenge. The market is not growing while the competitors are taking market share and reducing their costs. People are worried about their jobs. Your friends are worried. You are worried. If you get laid off, what is going to happen?

There is a key project that is important for the company’s survival. The project manager suddenly takes a job somewhere else leaving a void in leadership. Then the head of R&D comes to you and says “We need your leadership. Please guide this project so that it is successful.”

Of course you are flattered by the request. You wonder if you really are the best person for the job. Can you get it done and keep balance in your life? Can you bring up the morale of people so they can do their best? Can you keep management from interfering with the project and resources? Or will you fail?

Then your mind goes back to the things that you did to prepare for this role. You remember the time spent listening to others to understand the problems from their point of view. You recall the times you shared your vision of how things could be on another team, allowing everybody to see what could be. And you feel some pride when you think about how everybody worked together to get it done. You realize that whether intentional or not, you have become a leader. You accept the offer and build on your experiences from the past.

We are all on some path of leadership. Some of us want to be leaders. Others are tired of being led by dictators or phonies. Some of us want to have an impact. And some just want to keep following. There is nothing wrong with any of those desires. In fact, we have a little of each in our hearts. However, if you want a little or lot of success, which I think you are by the fact that you are reading this blog, you can prepare yourself to be a good leader.

Note: I would like to get feedback on what you think a leader is and is not. I welcome your comments.

Exploratory Testing with Interactive Ruby

I want to premise this post with two things. First, I didn’t think of this. I heard Jim Knowlton interviewed on the Watir Podcast. I also attended a web cast with Michael Bolton on using automated testing in a manual form. Both inspired me to try this myself. As some of my software friends are aware, I dig testing with Ruby and Watir (Web Application Testing In Ruby). I didn’t know anything about Ruby or Interactive Ruby (IRB) before working with it, starting in about 2007-2008. But since starting to use it, I found I am more productive by “trying” my code out in the IRB interface before adding it to my functions. Very handy!

My eyes were opened even more when I heard Jim talking about using IRB to facilitate his testing (and his co-workers) by creating libraries that assisted him. I started to envision things I could use it for: pumping data into a system for create conditions for testing business logic; grabbing near-real time information from log files; quickly getting to the ‘state’ in which I want to explore; and grabbing unseen information about the interface that I am looking at such as the state of objects and making them ‘seen’. I remember being so excited that I asked other people to listen to the podcast.

The webcast with Michael was revealing too. I could see with a simple command line IO, inputing numbering and getting numbers back helped me quickly learn about a system that I knew nothing about. He talked strategies to use exploration, as well as tactics that supported the strategy.

Those lessons came to fruition at my new job. I started with needing to test a web service. I have tested SOA web services before. But I had not tested the with Ruby before. I saw the team I was joining using a RestClient. They were modifying the ‘get’ and ‘delete’ calls based on the data set from the ‘create’ call. I asked myself how many times I wanted to copy that data, the answer was three times. So I pulled out the restful web services book that I had opened one or two times in the past, and found a snippet of net/http to call web services. Once I figured out how to add the pieces I needed, in less than a day, I had a class that could perform all three calls and retain the data, allowing me to test the web services api until I was satisfied that it was working according to the design. Running these from IRB allowed me to run manual tests. I kept changing the tests. Even though they were written in QC with instructions on parameters, I kept asking myself “what if I did it this way?” which allowed me to learn and satisfy myself that the API was strong.

I also saw  the other team members copying and pasting data from the create api call to use in a lynx (text-based command line browser) for testing business logic. I found all the typing and copying unnecessary and mistake-prone so I ‘printed’ the lynx command out allowing me to copy and paste the entire thing. This allowed me to more quickly get to the business of testing. I used that gained time to add a direct command from Ruby, reducing a step to run quicker, and finally incorporating the Mechanize library with that saved time.

The fruit of that labor was to allow me to test more quickly from the web service call to the browser call. That in itself did not find any defects, but it enabled me to see the need for faster (virtual) browser calls which did find three major defects and a minor defect. In spite of these gains, my manager was concerned about the cost of maintenance of early automation – a lesson I learned from James Bach’s Test Automation Snake Oil that says “Manual testing, on the other hand, is a process that adapts easily to change and can cope with complexity. Humans are able to detect hundreds of problem patterns, in a glance, an instantly distinguish them from harmless anomalies.”  I gave her a demonstration to show that my mind was in control of these tests. She felt at ease and asked me to continue.

The final culmination was today when I discovered a problem in a caching algorithm that would not be detected with smaller slower data-flows. I had no intention to test for load. I wanted to test functionality in a system environment and more realistic volumes. At this point, I did create a Ruby “script” but even then it took command line arguments to allow me to modify the test cases as I saw fit. There were no magical red or green colors that filled a test management system with results. Just tests that I ran as I felt were needed to learn if this system was ready to release or not.

– Dave McNulla

10 Things I Love About my New Job

I am starting a new job after such a long, wonderful tenure at Hewlett-Packard. After 10 years, if you include my tenure at Peregrine Systems which was purchases by HP, HP gave me walking papers in the nicest way 11 weeks of severance plus vacation pay. And my boss actually got me the lead for this job!

But it’s a break, a change. What’s going to happen? Will I do OK? Will I like the new job? I am a guy that likes small changes on a steady base. So I was not so much of freaking out but ‘concerned’. Let me tell you that those concerns were laid to rest.

1. Challenge – I am not going to say this place is perfect because it’s not. That is part of the attraction. I have never been satisfied at turning bolts all day. I have to find a way to make it better. If it was heavenly already, the I couldn’t help raise it up. They seem to be caught in a scrumbutt world and I know their issues from experience. Hopefully I can develop enough credibility to have an audience.
2. Automation! – Yes that’s an exclam. I am NOT a programmer but I like to solve problems and I can solve some test efficiency & capability problems with automation. I was able to build a proof of concept in the first few days using ruby as the language, net/http as the library, and irb as the interface tool. I was running manual tests more efficiently in a hurry, and the developers started using those tools too.
3. Nice People – I felt that everybody give me criticism in constructive ways, tries to listen to me even when they don’t want to, and answers tons to good and bad questions. They take the time to explain the business logic and why the system works the way it does. The first 20 minutes of the weekly QA meeting is to discuss what happened on the weekend.
4. Good Coffee & Free Snacks – I would never take a job because of coffee, free cokes, free juice, healthy snacks, and some not so healthy snacks. I still appreciate them being there. The company wants us to be comfortable. I stay away from the sodas.
5. Treat Contractors like people – I have been a contractor before so I know about the ways they can be treated differently. I am one again (3 month contract before conversion to employee). Despite the difference, I have not been treated any differently. I have been invited to lunch-n-learns, holiday parties, etc. – many things forbidden at other places I have worked at.
6. Lunch and Learn – the company actively participates in teaching everybody in the company about the products the company makes. Perhaps there are other topics, but that’s what I’ve seen so far. Next week, I will try introducing the QA team to Ruby as a test tool next week in a similar type of event.
7. Protects People – the product that I work on protects people from their online privacy being invaded. That’s usually a good thing.
8. Apple – I have not used Apple products (outside my iPhone) since 1989. I now use a Mac and I will seriously consider that for my next home purchase because of the time savings I get (start-up, fewer questions about security, etc.).
9. HP – As if I couldn’t get away from my beloved former employer, I am using QC, SiteScope, and my baby Service Manager. I am hoping to get a LoadRunner license to help in testing performance in the future.
10. Supportive – people are giving me some room to run around and try new things… even before I have developed a lot of credibility with them. That kind of support is so valuable to my happiness because I can focus for a while on investigations without worrying about what people will think.

I have no idea how the future will turn out. I just want to be a technical (and spiritual) leader in my new job. I think it’s going to be mutually beneficial to say the least!

– Dave McNulla