The latest software test tools

As I have written before, for about two years in the late 90s I worked for Hewlett Packard/Agilent in software testing.  Granted, my group tested firmware that was getting installed into complicated test systems, rather than testing huge web apps or desktop programs.  But it was software testing.

HP was thorough.  When I started with the test group it was just getting its feet under it.  So management sent us to in-house training classes and paid for us to go to several training seminars.  I even went to three different software test conferences.

Since I left Agilent all my jobs have been testing hardware.  But I still like to pay attention now and then to software testing issues.  That's why the Jolt Awards for Testing Tools popped up on my radar.  More interestingly, there was a commentary on those awards asking why there hasn't been a big leap in what kind of testing tools developers have.  Andrew Binstock, the author, makes the point that the types of tools being awarded (code inspection, unit testing, UI testing, browser testing, load and performance testing) are the same types of tools being used a decade ago.  Indeed, those types of tools are the same things I used back in 1998 and 99.

This question reminded me of something I read last week.  I've been working my way through the book Physics of the Future by Michio Kaku.  It's an interesting read, if a little overly hyped at times.  One of the topics covered in the book is the related subject of AI and the Singularity.  Dr. Kaku makes a point in this section that, while computer processor speed and memory keep improving by leaps and bounds, the software is still being written by people.  Visionaries who predict the coming robotic revolution or the end of history as we know it miss the point that the code still requires the creativity of people to be developed.

I think that's what is happening with the software test tools.  The hardware keeps improving, but the software improvements just don't follow Moore's Law in the same way.

Prepping for the CLD-R (part 3 of 3)

Last month I wrote about refreshing my Labview skills before I passed the CLD-R exam.  This topic turned into a set of three additional posts.  The first two were about available seminar materials and online help topics.

Now I'll write about the third (and last) thing I did to prep for the test:

Study the sample tests

I found two sample tests that NI had posted on their website for the CLD-R exam.  Who knows - if you dig hard enough maybe there are more.  The first thing I did was take one of the tests as if it were real - no cheating.  Then I followed these steps:

1. Examined every write answer I got to make sure I understood why.
2. Looked at every wrong answer to figure out the correct answer.
3. Researched the specific topics that were a little fuzzy.
4. Looked online to see if anyone else had worked out answers.  A few examples are here and here.  You can try looking at LAVA as well.
5. Worked out IN DETAIL every single problem that had code attached to it.  
6. Took the second test as if it were real.
7. Repeated steps 1 through 5 for the second test.
8. Took the first test again.  A couple weeks had passed since I first tried it, which was enough time for me to gauge whether I had improved.
9. Took a couple days to digest my second pass.
10. Repeated steps 8 and 9 for the second test.

I know all that effort may seem excessive, but what can I say?  Engineers tend to be like that.  Regardless of the effort involved, following those steps definitely helped me understand the topics NI thought were important for the test.

The fifth step - working the problems out - was particularly useful.  In my opinion just memorizing answers stimulates only one part of your brain.  I created a separate VI for each problem, added as much detail as I needed, and ran the VI until I got a satisfactory (an understandable) answer.  Going through that effort helped to create a sort of "muscle memory" that I could call on during the test itself.  Besides which, I think going over those topics helped me improve my programming skills in general, even if only a little.

So that's all I'm going to write about the CLD-R exam.  Good luck to anyone taking the exam, and I hope this helped.

Prepping for the CLD-R (part 2 of 3)

In a previous post I wrote about the tasks I undertook to refresh my Labview skills before I passed the CLD-R exam.  My first post on this topic discussed NI seminar materials.  Now I want to write about something else I focused on:

Review online help info

NI publishes a list of about a dozen items the test covers.  Of those, I found the following to be worth my time reviewing:  Events, error handling, timing, recursion, reentrancy, shared variables, and file IO.  So I went into NI's online help, bookmarked the pages relevant to that topic, and then reviewed it in detail.

For example, for timing I looked at these items:

• Timed loops
• Configuring timed loops
• Timed loops are slower
• Timing structure characteristics
• Timed sequences
• Software timing vs. execution timing 

I also went through the examples I could find online as well as the example finder in LV itself.  There was quite a bit of information available.

=====================

I'll write one more post on this topic of CLD-R review, probably in another week.  Then I'll hopefully get more current with my posts again.

Prepping for the CLD-R (part 1 of 3)

In my previous post I wrote about refreshing my Labview skills before I passed the CLD-R exam.  This post will talk about one of the things I focused on:

Seminar materials

I attended the Labview Developer Education Day back in March.  This accomplished three things related to my study for the CLD-R:

1. Ni will often give out discounts for training or tests at these events, so that saved me some money.   
2. Attending an all-day seminar sparked my memories in an entirely different way than just reading up on Labview tricks or working through code examples.  I think listening to other people talk about code issues stimulates your brain in a different way.
3. I got to see presentations worked out in detail.

Number 3 on that list related to something that I had already been doing on and off since the beginning of the year: going through presentation examples.  Just go to NI.com and search for "Developer Days" or "Technical Symposium."  I did it just a few minutes ago, and one of the first items that popped up were the presentations from the 2013 Developer Days.  In fact, with some digging you can find presentations going back to at least 2009.  Even better, with some more work you can find the examples that go along with those presentations.

So I did exactly that.  I went dumpster diving into NI's archives, digging around until I found about 4 GB worth of data (including actual videos of some presentations).  And then I read through them all, skipping over the duplicates and the presentations aimed toward introductions and hardware-specific issues.  And I worked through every single example, making sure I understood it.  It helped.

So that's the first of three things I did.  I'll try to post the second one sometime this weekend.