Info

You are currently browsing the archives for the professional development category.

February 2012
M T W T F S S
« Jan    
 12345
6789101112
13141516171819
20212223242526
272829  
Links

Archive for the professional development Category

Great Resource for Testing Podcasts

I listen to a lot of podcasts. Between my bus commute, errands and going to the gym, I have lots of time I can spend listening. I recently came across the site TestingPodcast.com. The site is an aggregation of various podcasts that deal with software testing. Sometimes they are podcasts I already subscribe to. Others are podcasts I would not want to listen to every episode but a particular episode might be interesting. They are all here.

I was a little puzzled finding the RSS link - it actually was in a logical place, I was just missing it. The RSS feed link is http://feeds.feedburner.com/SoftwareTestingPodcast?format=rss.

 

The Lean Startup - Eric Ries

I have worked most of my career at startups. Some have been successful, others failures. This may explain my interest whenever I see something about startups. I am very interested in how others experience line up with mine. I recently came across a slideshow by Eric Ries entitled The Lean Startup.

There are a couple of items I particularly liked:

  • The comment that a startup "has nothing to do with the size of the company"
  • Speed wins - decrease time between major iterations
  • Minimize total time through the following loop: Ideas -> Build (Code) -> Measure (Data) -> Learn -> More Ideas
  • Five Whys Root Cause Analysis

 

Michael Gerber’s 10 Pillars of Small Business Success

I am reading Michael Gerber’s Awakening the Entrepreneur Within: How Ordinary People Can Create Extraordinary Companies. I don’t buy his whole premise. However, I did think the “10 Pillars of Small Business Success” in chapter 13 are worth thinking about:

  1. All businesses require vision.
  2. All visions are both personal and impersonal.
  3. Every company is an organization of people, relationships, functions, a flow that can be charted.
  4. An organization is an organization of systems. All systems merge into one system.
  5. There is no such thing as customer service, only commitment.
  6. Master money, and everyone in your business must master money.
  7. Your people are not your business. Your business is its own reality.
  8. Your business is an idea.
  9. You know more about your business than anyone else.
  10. A business must mean something.

 

Testing and December 2009 MSDN Magazine

Even if you are not working on the Microsoft platform, the December 2009 MSDN Magazine has some articles which can be of use to all testers.

In particular, Pairwise Testing with QICT by James McCaffrey provides enough insight into the QICT tool that it can be easily ported to any platform. While Automated Unit Tests for Legacy Code with Pex by Nikhil Sachdeva is specific to Microsoft technologies, Pex is a tool that all testers should become familiar. Finally, Using Agile Techniques to Pay Back Technical Debt by David Laribee has tips that are useful to most test organizations.

 

Demise of Paper Based Test (Technical) Literature

I commute by bus. I have been doing this for over 9 years. Every work day, I have time set aside where I can read, listen to podcasts, unwind, etc. However, over the last few years, the amount of test (and more generally - technical) literature I can read on the bus has declined. Some have simply gone away (Software Development). Others have converted to an online only presence (InfoWorld). Some no longer provide paper editions to those subscribers who receive copies based on professional qualifications (Better Software). In addition, more and more of the test related content is only available in blogs or other online forums.

Overall, I like online content. It is easier to find items at a later time. Unfortunately, I find that I do not read as carefully/thoroughly when I read something online. I am now purposely trying to read professional development material online with more focus — but it is an effort. Who knows what other changes are ahead of us.

 

Jason Fried of 37Signals - Business of Software 2008

One of the things I love is being able to see presentations from conferences I was unable to attend. A coworker passed on a link to this video (55 minutes) from the Business of Software conference. In the talk, Jason Fried of 37Signals, makes of Ruby on Rails and Basecamp, speaks on many aspects of running a software company and keeping teams working effectively.

Here are some of the slide titles, topics and items Jason discussed:

  • Planning is vastly overrated - no roadmaps, specifications, projections. Get rid of distractions. Functional specification does not reflect reality and leads to an illusion of agreement.
  • Decisions are temporary - optimize for now
  • Red flag words - need, can’t, easy, everybody, nobody. These are the words that cause projects to be late
  • Interruption is the enemy of productivity - the closer the team is physically, the less you get done. Interruption is not collaboration. A fragmented day is not a productive day.
  • Underdoing - target non-consumption
  • Find the right size - imagine the software as a physical item
  • Follow the chefs - what is your cookbook?
  • Always be questioning - Why are we doing this? What problem are we solving? Is this actually useful? Are we adding value? Will this change behavior? Is there an easier way?
  • Give up on hard problems - there is an abundance of easy problems
  • You’re an editor - Curate your product. Say no to more things than you say yes.
  • Work Less
  • Q&A - Starts 28 minutes into the video

An enjoyable video, especially the first half before the Q&A session.

 

PNSQC CFP Deadline Extended - May 1, 2008

In a prior post, I mentioned the call for papers (CFP) for the Pacific Northwest Software Quality Conference (PNSQC). I received a notice last week that the deadline has been extended to May 1. More details can be found here.

 

Job Candidates and HTML Validation

I review a lot of resumes. In the majority of the cases there is a web site mentioned on the resume. I don’t look at the website unless I am going to interview the person (phone or in person). In most cases, the website has not been updated for quite some time and I wonder why the person included it on their resume. In some cases, the web site is of a strictly personal nature and once again I wonder why they want a propspective employer to look at it. Then there are the cases where the website is relevant to the person’s professional interests and is current.

One of these resume/websites came across my desk recently. It was a rather plain looking site but had good, relevant content. The person stated clearly his belief in web standards. He even included the W3C button that allows the pages HTML to be validated against whatever HTML version is specified in the DOCTYPE tag. I click on the button - the page fails validation. Not a good impression to set with a prospective employer.

Hint to job seekers - If you have a HTML validation link on a page, make sure the page passes validation.

 

MSDN Tester Center

I came across a reference to a new online testing resource - MSDN Tester Center located at http://www.msdn.com/testercenter. The site is fairly new but I think it shows promise, especially for people new to the software testing field.

In his introduction to the site, James Whittaker says that one of the purposes of the site is to spread the testing knowledge used internally at Microsoft - especially from those people who do not necessarily speak at conferences or write papers. Having met many talented testers from Microsoft, I think this is a great idea.

As far as content, it is still pretty light - about 4 papers, a dozen videos (each about 5 minutes long) and links to a couple of blogs. But it is new and I like the intent. I will definitely be keeping an eye on it.

 

Write Your Own Job Description

In January, I let my boss know that after more than six years, I would be leaving the company (after a long transition period). Having spent six years in my role, there was quite a bit of knowledge that only existed in my head. He asked that I put together a list of what I did along with a job description for my replacement.

The job description felt like a monumental task, so I started with just a list of what I did day in and day out. Luckily, I keep a bulleted list of what I do each day. I archive these off on a weekly basis. After retrieving these task logs for the last twelve months, I went through the tasks and categorized them into recurring items.

Once I had this comprehensive list of tasks I performed over the last twelve months, I then classified them as:

  • Should be done by the person in my role
  • Should be delegated to someone on my team
  • Should be done by someone on a different team
  • Should not be done

With the list of items that should be done by my replacement (and a couple of web searches), it was easy to generate the job description. However, the real value of this exercise was identifying those items I should be doing and those I should delegate. If only I had been doing this before and on a more regular basis.