Fanfare Blog

Is Testing Green?

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

So our PR team asked me a great question: Is testing green?

 

Yes, er, No, um ... Depends? OK, not as easy as I wanted. So, I have been thinking about the answer for a few weeks and I might be missing the obvious, but here is what has been fermenting in my brain:

 

At a very high level yes, testing is green. If you test products before they are released, the overall effect is green. While I spend and consume resources to test, if I do a good job, the product will be of high quality. Hopefully high quality means a successful product, and that means the materials used to produce the product were not wasted and the product does not wind up in the landfill three months after production due to all the support issues. So yes, I think testing can reduce waste and that is green.

 

This naturally led me to the question "Is automation greener?" At first I thought "No brainer," but then I thought that automation actually means more equipment consuming more power.  So, in the witness stand ("Sir, just answer the question") I might say "Automation is not green." I think that neglects a key point, however: Automation should mean more testing, more testing should equate to better quality, and I asserted earlier that better quality is green.

 

In addition, I could claim or assume that I was going to do a certain volume of testing and automation just does it more efficiently than manual testing. A test lab with lots of test equipment that is heavily used 12 hours a day, but is idle at night, seems an inefficient use of resources; either I can run a lab 24x7 with automation or I have to have a bigger lab or more labs around the world to get the same manual testing done in the same time. Bigger or more labs is defiantly less green.

 

So yes, automation is greener than not using automation.

 

Lastly, (granted this is more of a feature than testing) some companies have started using virtualization to do testing. This means that instead of running real devices, I virtualize several devices on one machine. That saves power and that is green.

 

So, outside of the choice to just not do testing, I make the claim that high quality is more green than poor quality. While this is not really planting trees and taking cars off the road, it is a way to improve our planet from where we are. So yes, testing and automation are green.

 

Disagree? Did I miss a point?

 


    Related Entries
TrackBacks | Comments | Tag with del.icio.us | System and Device Testing Home | Permalink: Is Testing Green?

Tags: , ,
Copyright System and Device Testing

Standards - they are worth your time

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

Whenever I hear the word "standards", I think of Blu-Ray versus HD DVD and then I think of deeply technical standards bodies that debate the smallest detail.  Necessary of course, but not my cup of tea. 

I know most of us are aware of standards, and at least some of us have to test to standards.  But what about standards for use in testing?  I am not talking about the 'gold' standard of testing, say zero defects found by customers. I am talking about standards that define how scripts and equipment we use interoperate.  For example, a standard on how my test authoring software should interoperate with test equipment, say a traffic generator or probe. 

For many, because our labs are growing in complexity as what we test becomes more complex, standards have become a really hot issue (well, at least as hot as standards can get).  The complexity has increased primarily because so many vendors engage in a little tactic called customer lock in;  "Hey, if my customer builds a 1000 test scripts and they have to be hard-coded to my equipment, they will never get my stuff out." As a result, you have to spend a lot of time modifying existing scripts to work again each time there's an upgrade to their test equipment. "My script doesn't work because they changed their API!!!  Now I have to fix 100 test cases, spending more time fixing than actually testing." So for testers, this is what standards should be really about: making a consistent and easy way to build test cases that are robust and easy to work with on several flavors of equipment, without a PhD or six months of maintenance.   

There is a new standards body being formed called NTAF (www.ntaforum.org).  What is interesting about this one is that it is a bit of a Phoenix rising from the ashes of other failed attempts and it is being led by customers -- customers who are demanding that testing vendors create standards to make their job easier.  This is likely going to have a better outcome for the industry than the war waged to get a company's proprietary standard in and force conformance.

Of course, standards can take a long time and usually lag the market. At some point, testers need to get involved -- get someone from your company involved at least to peruse the proposed standards, or to communicate problems that need to be addressed.  That small effort may mean you get home on time and watch the World Cup instead of doing a find-and-replace in 100 test scripts.


Tags: , ,

    Related Entries
TrackBacks | Comments | Tag with del.icio.us | System and Device Testing Home | Permalink: Standards - they are worth your time

Tags: , ,
Copyright System and Device Testing

Whats in your resume?

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

The market is heating up, people are looking for better jobs -- in fact our company has hired a few experienced testers to lead service and consulting work for us. 

Looking at the resumes I found a huge diversity in the experiences people have and what they highlight.  Such as;

"Led a team of x people"

"Created an automation strategy"

"Built a test infrastructure"

"Established a quality test process "

"Worked with engineering to remove bugs earlier"

"Certified with X testing software tool"

"Authored X test scripts"

"Proficient in X, Y, Z scripting language"

I rarely saw how candidate participated or led to 15% reduction in defects, or how a new approach resulted in a faster time to market.  Is this because we just don't think to put this on our resume?  Is it because we don't know how measure these things?  Or is it because we don't think anyone cares?

What do you think?  What are the top three items on your resume?

Tags: , ,

TrackBacks | Comments | Tag with del.icio.us | System and Device Testing Home | Permalink: Whats in your resume?

Tags: , ,
Copyright System and Device Testing

A new UI on iTest 4.0?

Shop Talk Blog - May 10, 2010
If you’ve been looking at some of the sneak previews of iTest 4.0, or you’ve been involved in the beta program, then you may be aware of the new default look-and-feel in this release. What’s this all about? Is it going to be useful to you? Do you have a lot of relearning to do?

Quick Calls in iTest 4.0

Shop Talk Blog - April 30, 2010
There’s a new capability baked into iTest 4.0 that many of you might not notice at first. But once you discover it, I predict you’re going to find it pretty interesting. We call these “Quick Calls”. The concept is fairly simple to explain. Any session profile can now have a set of iTest procedures associated with it. When you have one of these sessions open, you can search through available procedures and execute them. When you do this, a single action is captured – corresponding to the procedure you selected.

Centralized Reports: Little Feature, Big Impact

Shop Talk Blog - April 19, 2010
In iTest 4.0 we added quite a modest feature which allows you to configure iTest to use a centralized database rather the embedded database for storing the test reports. From our standpoint, this was a relatively modest feature. We don’t really care what kind of database we use, or where it is located. So, in some sense, we’ve just exposed the database connection properties to the user. However, this rather modest change has potentially far-reaching consequences to how iTest can be used by teams.

December 31, 1969
Syndicate content