January 23, 2010 by mensming.

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.

Posted in professional development, process improvement, test tools | No Comments »

January 2, 2010 by mensming.

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.

Posted in professional development | No Comments »

September 7, 2009 by mensming.

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.

Posted in software engineering, professional development, process improvement, project management, requirements, conferences | No Comments »

April 22, 2008 by mensming.

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.

Posted in professional development, conferences | No Comments »

April 6, 2008 by mensming.

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.

Posted in professional development, web testing | No Comments »

December 10, 2007 by mensming.

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.

Posted in professional development, training, software engineering | No Comments »

October 7, 2007 by mensming.

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.

Posted in professional development | No Comments »

August 28, 2007 by mensming.

I just finished reading Better: A Surgeon’s Notes on Performance by Atul Gawande. This is a very interesting book about the medical system. However, there are a couple of items which apply to software development professionals.

The first section of the book deals with diligence. Many of the examples in the book deal with the need to be vigilant in some of the most mundane aspects - washing hands, inoculations and wearing body armor in Iraq. Often, in software development, we fall down when we are not diligent. We take shortcuts, we don’t create unit tests, we don’t review requirements, design or code. All things we know we should do but often skip. In short - we are not diligent.

In another section, Gawande shows how measurements impacts the quality of care. The Apgar score (the simple measurement used to judge the health of newborns) spurred doctors to improve care of newborns who originally were not considered viable. While the medical profession keeps many different statistics, it is often difficult to compare one doctor’s performance to another. The introduction of the Apgar store allowed for a simple measurement to be applied universally. Doctor’s, patient’s and hospital’s had a way to compare performance and improvement in this aspect of care. Unfortunately for software, there is no simple measurement that can be applied to a software product and there is definitely no universal measurement that can be used to judge our performance compared to our peers.

I think these two items are worth each of us considering. How can we be more diligent in our daily activities? And while a universal measurement is not achievable, can we develop a measurement to compare our (or our team’s) performance from project to project?

Posted in professional development | No Comments »