Category Archives: Programming

Technology Stacks (yawn)

I was assigned a Test Lead role for a project that, among other goals, is investigating SPA.  I thought I’d jargon-up my opening line because it looks all cool but it has a distinct “Emperor’s New Clothes” feel.  Single Page Application (SPA) is all the rage as of this writing (I may be a few months behind – “all the rage” is hard to maintain in software development).

Plainly said, I ain’t impressed.  In fact, I think we’re coming full circle from (former “all the rage”) desktop computing applications.  You may recall the shrink-wrapped, shiny boxes containing the coolest new application, requiring twenty minutes of disk swapping to install.  I grant you today’s installation is far simpler and faster but in the end, it’ll be a desktop application hosted in your browser.  Yup – full circle.

What really frosts me is developers talking about new frameworks and utilities they are using.  Not having familiarity with the names (which for my money are nowhere nearly as cool as Lotus 1-2-3, Wordstar, Paradox, or Sidekick), I did a bunch of research and experimenting.  I was able to install < insert popular framework>, its recommended testing tool <insert popular testing tool for popular framework>, and run a few tests.  As Biff exclaimed in “Back to the Future II”, there’s something very familiar about this.

It doesn’t stop there.  Since there are soooo many files used to create an SPA, you need a utility to bundle them.  These also have unique names but that hasn’t fool me.  Lastly, in a penultimate salute to developer vanity, there is even a utility to convert (sorry – they call it transcompile but I think that’s a pile of sh-t) source code to javascript.

If I have this straight, there is a “new” IDE for coding, a “new” utility for “compiling”, and a utility for bundling all to support SPA.  Maybe it’s just me but I’m pretty sure I can do all that in Visual Studio today.  With the Community version, I can even do it for the same price.

This journey started because we wanted to pursue SPA.  Its shiny and new.  As we experimented with it, we discovered the technology stack.  It’s as if we were walking along in the woods, and found a neat stick we could use.  When we picked it up, the other end disturbed a bee’s nest.  When you pick up a stick, you always pick up both ends.



Test Automation is an Investment

I submit that test automation can improve your project’s pace.  I realize that some believe it helps detect defects or that it can be developed independently from project execution.  I recommend you reconsider those positions.

Ever since I read Specification By Example, my understanding and attitude towards test automation has changed.  It did not change how I design or build test automation, it changed how I see its purpose.  For this post, I refer to test automation in a spectrum from evaluating newly checked in code to that used in regression testing.

I’ve been pitching what I believe is a familiar notion around test automation in testing circles.  But it was suggested to me that I provide some context.  Put simply:

The purpose of test automation is to enable frequent evaluation of application behavior in the face of change.

I did not arrive at this conclusion by myself.  Adzic’s book was a great catalyst to think about test automation more, and to discuss it with other test engineers.  A context took shape for me and its present form is my declaration above.

Defect Detection is a Narrow Focus
Test automation costs too much to make it beneficial in just detecting defects in the short term.  Indeed, test automation developers find defects many times when they are developing (not executing) the automation.  That means that by the time the test automation is completed and verified, it’s possible someone else could have located that defect AND corrected it.

I recommend you invest in your test automation today.  You will realize the real value when it detects a defect in a succeeding iteration, or a succeeding project.  When it does, it demonstrates how recent changes have introduced errors in existing behavior.  In that manner, it is acting to preserve your business intent.

Independent Development Costs More
Let’s say you wait to develop test automation.  At some point in the future (the next iteration or the next project), the testing team is discovering defects in code that was completed AND working.  The current pace begins to slow:

  • Defects in existing code must be corrected so testing can evaluate the newly deployed code.
  • There is a good chance that correcting defects will introduce more defects.
  • When the code is operating again, you may find defects in the newly deployed code.

If there was an investment in test automation, frequent execution would detect changes to existing functionality at the time they were introduced.  That is, defects would be detected when developers execute the test automation, and they would correct them.  This saves time because the project team continues building products rather than fixing products; the project maintains its pace.

Your Investment Pays You Back
Test automation pays dividends in protecting your investments in building and expanding business functionality, and detecting unintentional changes to business behavior early.

  • Time is saved because the team executes test automation often to detect behavior changes early – before the products are deployed for testing.
  • System and integrated testing is more effective because simple defects are corrected before deployment for testing.

Lastly, the project team builds confidence in their products because the testing team can spend more time exploring products broadly, deeply, and for risk.

The Most Important IT Skill

My wife and I attended Curriculum Night at the high school where our boys attend.  It had already been a busy week (and frustrating one if you count the removal of a poorly designed kitchen faucet).  But Curriculum Night is something I have enjoyed for many years and would not consider missing it!

My son is enrolled in AP Programming so I was very curious about the curriculum AND the teacher.  I was impressed with the cognitive level of assignments he had last year, and this AP course had my expectations high.  I sat through informative yet similar sounding sessions on Pre-Calc, English, and Physics before hearing about the AP Programming course.

When I arrived for the session on AP Programming, the teacher greeted me with a hardy handshake, an excited “Welcome!”, and invited me to sit where my son usually sits.  He was animated and nerdy (cool).  He had spent ten years in the industry before deciding to teach (nice).

He started talking about the curriculum, noted the students receive one new programming concept per week (they are working on arrays this week), and finished with how their work is evaluated.  My interest grew.

Students are expected to review each others’ work, note the differences between the implementations, and they are invited to speak in front of the class about their discoveries.  The teacher stated the ability to communicate was as important as learning how to write programs!

I was elated.  An experience in collaboration and empathy respectfully facilitated by the students is a great IT lesson.  In my journey through my testing career, I discovered that, as a Test Lead or Tester, testing is a very social activity.  The ability to convey and negotiate ideas, collaborate with multiple personalities, and develop a working team has been as rewarding as writing programs and tests.  Getting that experience in high school is like preventing defects early in the project!