Ecommerce and Entrepreneurship Blog | About | Contact | Store

The Never Ending Saga of Testing

Posted on April 20, 2010 by Zach

I have to imagine by now that our development team enjoys a healthy love and hate relationship with me. Being in the marketing department we have a lot of development projects which include testing before they go live and I often get tasked with helping to test other projects. I have become what I might call a “Testing Pirate”, I come to bang on the doors, break in through a window, make a bunch of noise, break some stuff and steal what I can. In essence it’s my job to pillage projects or code and let me tell you, business is good. To add insult to injury I also have an opinionated eye for design and organization, especially when it comes to websites. In light of all this I decided to put together my steps for testing development projects especially when you are not a developer.

Pre Qualifications - It's nice if you are technically inclined and or have dabbled in a little coding. I am fairly technically inclined and I have taken a few programming classes back in the day so that gives me a decent understanding of what’s going on, how things can be handled and what may or may not be possible or can cause an issue. That sets me up to have a basic understanding so that I am better able to effectively test the project or code. It’s also a good idea to spend a little time with your developers, ask questions about the platform they are using, coding practices, their experience and even have them take you through a little code so that you understand what they are doing.

Understand what you are testing - There should always be a clear understanding of what is being tested. One of the time suckers of testing can be poor expectations of what to test and the testers end up testing areas, code, pages or the like which are not ready to be tested. I can't count how many times I have fully tested something but realized that half of what I found was fixed at a later time or incomplete because I did not realize I should have only been testing a specific area.

Complete it straight forward - Once you are ready to roll and understand what to test, complete the testing in a straight forward manner knowing what you know about the project or code making sure core features and functionality are working as designed. If the basics of what is being tested is not working you probably don't want to spend any more time identifying other issues.

Complete it with objectivity - Next test the project or code again with objectivity pretending you have never seen this before and have no prior knowledge about it. Remember the Parents or Grandparents test, complete the test as though you where someone who is not technically inclined, what does not work well, what is unclear, is something too technical, are their clear instructions?

Complete it with an angle - Next test the project or code again with an angle, what can be broken into as well, is there sensitive data being stored, are there any potential breaking points, can you pass any bad data or get to anything you should not be able to?

Have more than one person testing - It's always a good idea to have more than one person testing, especially someone who is not as close to the project or code if possible. They might be able to catch things you miss or take a more objective look.

Validation - Validation can be the bane of a project's existence, if something is passing or accepting bad data it can ruin a project, promote insecurity and create a bad user experience. It's important to make sure that when testing you are trying different types of data and making sure that proper validation is implemented.

Documentation - While testing, your developers will really appreciate good documentation. Make sure it's organized, has identifying information like page or project name or URL. Screen shots can be nice and make sure that any issues are fully explained, especially what lead up to how you found them. Sometimes dev teams have testing protocols, forms requiring signature and the likes. It's a good idea to review the testing protocols with your DEV team before hand so that you understand the ways in which they need issues documented and you are following their recommended documentation process.

Nothing is 100% or secure - Regardless of the amount of testing, nothing is going to be 100% secure or bullet proof so make sure that you are putting in the appropriate amount of testing for the project. Something customer facing probably needs a little more polish and vetting while an internal tool may not.

Happy Testing!

Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

SQL Server 2005 XML Quick Reference

Posted on April 1, 2010 by Trevor

If you've paid attention at all to the technologies behind web platforms recently, you'll know that XML has had a lot of both fanfare and debate surrounding it. XML is a data language, a way to wrap data in order to preserve its structure. It's quite simple and similar to HTML, which led to easy and wide adoption by web developers. However, although XML itself is simple, working with it is not. There are several competing languages intended to translate XML data into documents that can be either viewed by people or parsed by programs. Furthermore, while these secondary languages are standardized, their implementations may not be.

SQL Server is one example of a non-standard implementation. SQL Server 2005 implements XQuery, perhaps the most widely-used XML handling language in the database realm. However, it leaves out many features of XQuery and adds a few of its own. For a SQL Server admin or developer learning about XQuery, this can get very confusing as most resources are targeted at the standard rather than SQL Server's implementation, which means large parts of them don't work or apply. There are a few good resources like MSDN's Introduction, but one of the resources I couldn't find was a quick reference sheet.

Quick reference (or "cheat") sheets condense as much relevant information as possible about a subject onto a limited number of printable pages (usually two: the front and back of a single sheet). They're especially useful when you have the general ideas down but need to look up specific points (say, when you're trying something out that you just learned). There are plenty of good XML and XQuery quick reference sheets (those put out by Mulberry Technologies are especially good), but surprisingly I couldn't find one that specifically addressed the peculiarities of SQL Server's XML handling. So, because it would help me learn it myself, I decided to create one.

The following quick reference sheet is for SQL Server 2005's XML data type. It assumes a working knowledge of SQL Server and XML at least, so if you're not versed in the particulars you may want to pass it off to your developer or database administrator. However, I'm by no means an expert in this field, so if you notice any errors or omissions, please let me know and I'll do my best to update it. Of course, as always, neither I nor Gordian Project can make any guarantees as to support or liability regarding this quick reference sheet.




Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

Integrating Open Source Software Into a Work Environment

Posted on October 29, 2009 by Archives

I am a fan of open source software.  The main characteristic of open source software is that the source code is freely published.  This contributes to the success of the programs in many ways: the code is available for modification making it flexible, users are able to collaborate to correct defects, authors are more likely to stand behind their claims (because the code can be read), oh and it’s typically free.  Linux (Ubuntu) is my main desktop operating system at home and on my personal laptop.

However, as do many open source enthusiasts, I use Windows at work.  But, of course, I would prefer to use an open source solution.The question is, how does one “infiltrate” open source into their primarily Windows based work environment?
First I thought about letting everyone know that we should be running Linux (*BSD, OpenSolaris) on everything regardless, no matter what it is or who is running it. What stopped me is that I am still unable to grow a proper Unix/Linux Beard:


unix beard and linux beard

Little bit of nerd humor, but joking aside, for the everyday office circumstance this is probably not the best approach for integrating open source software into a work environment that has been based on a Windows operating system. What does make sense is starting small and simple.  Instead of replacing the current platform, build on top of it.  That is, find open source software that runs on Windows.

If you don't know where to start there is the OpenDisc which is a CD you can download that has open source software to try out.

Also, here is a list of programs that I use at work:

    • Open Office: Office productivity suite that is able to open the new docx and xlsx out of the box unlike office 2003.


    • FireFox: Even you don't know about open source you've most likely heard of this web browser that offers many custom features, add ons and plug-ins.


    • FreeMind: A java based mind mapping program.


    • GIMP: For image retouching, editing and authoring.


    • SharpDevelop: A free IDE for C#, VB.NET and Boo projects on Microsoft's .NET platform.


Of course check with your IT Manager to make sure that the use of these programs is allowed.  Also, check out this presentation by Chad Wollenberg titled “The Free and Open Advantage”.



Data and Content: The Offensive Line of eCommerce

Posted on September 18, 2009 by Archives

In the spirit of football season I have written a blog contrasting some positions in football to those of an eCommerce team. In the game of football there are different positions, the positions vary in skill and brain power, but when combined on a team, and in order for that team to succeed, they all need to work together. Without the skilled positions, you would not be able to play the game of football.  For example that would mean playing without a quarterback. There are also the lineman, not categorized as a skilled position, and by some considered to be the grunts of the team.

Now, lineman are not as “necessary” to playing football as the more skilled positions. To play a pickup game at the park no one is going to hold off kickoff to fill the lineman positions. Even competitive passing leagues don’t need lineman, but those aren’t as competitive as the major league. To play any serious, competitive football, the type that gets exposure, you need lineman, good lineman. Good lineman are absolutely needed for any serious team to win games and be successful.

There is a balance though, the better your skilled positions are the worse your lineman can be, because your stars will make plays and really stand out because of their skills. Conversely, the better the lineman, the better your skilled positions will look because they give the quarterback time to make that pass, they make the holes for your running back to run through, etc. Again, your skilled positions will stand out, because they are able to perform well. Being a lineman is a thankless job, they almost never get any glory, no adulation, and no recognition in comparison to other positions. Rarely does an offensive lineman make the highlight real unless he misses a block. To be part of the offensive line is also a tougher job than people realize, lineman have to know the playbook just as well as the running backs and be able to recognize and read the defense.

The job of data entry is much like being an offensive lineman. Data managers are expected to do their job correctly 100% of the time, there is no room for mistakes. There is an important reason for this though, data entry/lineman are the foundation. If something goes wrong with them, something goes wrong with everyone. Without the correct data/block you can't move the ball forward, you make it harder on the rest of the team. Data entry is a supporting position, the quality of their work has an effect on everyone else. So don't forget how important they are to the success of the company as a whole, and data entry people don't forget how important the quality of your work is and how important it is to everyone else.



Meeting Consumer Expectations: Getting it Right Prior to Order Placement

Posted on July 28, 2009 by Arianna

Keeping customers happy is one of the key elements to company growth. Providing the customer with a user friendly website, easy and quick returns policy, and an understanding of how our processes work will ensure that our customers stay happy. One of the most common reasons for returns, chargeback’s, and negative feedback stems from not meeting customer expectations. If a customer misunderstands the description of a product, believes that an email response time was beyond their allotted wait time, or didn’t thoroughly read the shipping process, then, depending on their order, we may not have met their expectation.

Setting product expectations will help customers understand what they are ordering. Clear and concise product descriptions are a must. They should always include specific product information such as dimensions, weights, colors and finish and should also include clear succinct images.

When it comes to shipping, one difficult lesson, learned only through experience is that customers don’t understand shipping processes.  Yep I said it.  Unless a consumer has been in the industry, has had experience with different types of shipments: expedited, LTL, etc. it is really difficult to communicate shipping processes.  Clients often believe that if they order an item on a weekend that the order will arrive to them in three days.  Unfortunately for our consumers most of our warehouses aren’t shipping on weekends, which we are grateful for.  That’s just one example, freight shipments can be difficult as well, we have specific emails that go out to consumers that have freight orders to try to combat this issue alone.  Educating customers by providing an upfront shipping section that explains rates and policies on the website will help customers fully understand what it takes to ship their order.

Having a user friendly website, communicating and setting expectations with your customers will allow for fewer returns, less chargeback’s, and an improved user experience.


Five Spreadsheet Formulas You Should Know and Use

Posted on July 2, 2009 by Archives

I stare at a spreadsheets most every hour at work, so there are a lot of spread sheet manipulations that take place on a daily basis. Here are five formulas that I find useful and I think you will too.

Microsoft Office: VLOOKUP(lookup_value,table_array,col_index_num,range_lookup)
Open Office: VLOOKUP(lookupvalue; datatable; columnindex; mode)
VLOOKUP() is used to find the “lookup value” in a given table of values and returns the column identified by the “column index.” This formula I find invaluable, it is used any time there is multiple data sources and I need to match up data.

Microsoft Office: CONCATENATE (text1,text2,...)
Open Office: CONCATENATE(text1; text2; ... text30)
CONCATENATE() combines the values of the given cells. I use this often to combine data to create product names according to our format. As a hint, to concatenate a space, put the space in quotes (“ “).

Microsoft Office: LEFT(text,num_chars)
Open Office: RIGHT(text; number)
RIGHT() and LEFT() work similar to a sub string function in programming. The formulas start at the right or left side of a cell and then grab the number of characters specified in the formula, which can adjust the data to your specifications.

Microsoft Office: SEARCH(find_text,within_text,start_num)
Open Office: SEARCH(findtext; texttosearch; startposition)
SEARCH() locate one text string within a second text string, and return the number of the starting position of the first text string from the first character of the second text string. SEARCH() can be very helpful when used in conjunction with LEFT() or RIGHT() when you want to get the contents of a cell to a certain character.

Text to Columns
Ok this one is not really a formula but it is a very useful tool. It allows you to break one column in to multiple columns by a common delimiter that you choose. Also you can choose “Fixed Width” and break up the column by width.

Differences between Open Office and Microsoft Office

For the most part the way that formulas work in Open Office and Microsoft Office work the same. There is a syntax difference in Open Office, instead of using commas (,) Open Office uses semi-colons (;) to separate the parts of the formula.

For additional information see the Open Office Formula Reference, and the Microsoft Office Formula Reference.


The Importance of Documentation in the Workplace

Posted on April 7, 2009 by Trevor

Documentation, the recording of organizational structures, policies, actions, and goals, is vital to any business, and doubly so for those of us in development. When I came on board I inherited roughly 200,000 lines of code that I had to learn well enough to find and pinpoint individual errors, within the span of about a week. While experience and clues from within the code help somewhat, the job would be nearly impossible without documentation of some kind. And documentation will continue to be important going forward: with so much to manage, it's unlikely I'll remember exactly what a particular piece of code does even a few months down the line unless I leave some easily understandable record. Even outside of the development world, documentation plays a fundamental role in business. It codifies procedures, ensuring everyone in the company does things the same way (hopefully the right way!). It streamlines processes, allowing people to look up answers instead of asking coworkers or reinventing the wheel. And it acts as protection during audits, helping to pinpoint any actions taken against policy. So, how should documentation be developed and integrated into your business practices?

First, it's important to develop your documentation alongside the actual process. Too often developers take the attitude, "Code first, document later." That would be fine if we could stick to it. But in practice it tends to become, "Code first, then code something else, and put off documentation for another time." Instead, you have to consider documentation a priority, updating it while the work you've done is fresh in your mind. Will that make you work slower? At first, yes, but over the long run it should save you time. Instead of thinking of documentation as something that hampers your real work, consider it as part of that work. You can't set aside part of your job because it's slowing down another part.

Second, streamline your documentation process to require the least amount of extra work. It's especially important not to duplicate information. When I'm documenting code, for example, it's often possible to intersperse the code and the documenting comments so that half of the documentation is the code itself. That way I'm not duplicating information by writing it once in code and once in the documentation. Another possibility is to set up automatic documentation procedures, so that you only need to manually fill in specific information. I have a Google document to record changes I make: it automatically fills in several fields for me, and other fields are set up to ease entering that information. This took a bit of extra effort to set up at first, but it reduces the ongoing work.

Third, be sure to structure your documentation. If you're documenting your work as you do it, it's likely that the documentation will be close to the actual work, both in detail and in location. That is wonderfully helpful when you're already looking at a specific piece of work, but what if you're trying to find that piece among all the rest? For that, you need higher-level documentation that gives the general structure of your work, explaining each piece and where to find it. It might also be helpful to give pointers to this general documentation from the specific pieces so you will be able to follow it back. However you choose to do it, make sure that your documentation gives a clear starting point to someone who doesn't already know what they're doing. Hunting for the right documentation is often just as frustrating as trying to understand the work itself.

As I come to grips with the code I have to work with and the duties I'm expected to perform, I'll be reading, updating, and creating the documentation to go with them. I'm hoping that with these principles I can efficiently create documentation enabling me and anyone else who reads it to get up to speed quickly and get the work done.

Monetizing Interpersonal Obligation in the Online Buying Experience

Posted on February 19, 2009 by Brian

During the last several months one of my brothers and I both purchased our first house.  Inevitably we end up in discussions about various renovation and repair projects we have in work, or on the horizon.  One such discussion included my brother’s tale of a pair of pruning shears he paid some ridiculous price for, like two to three times the price than what was listed as the price at the big box up the street.  Why?  Well, he was standing across the counter from the guy that just spent time explaining what shears he needed and how to use them to properly prune his trees.  He visited the nursery because he knew he could get the information he needed and now the interpersonal obligation pushed him to buy the overpriced shears.  In all fairness, maybe the shears were fairly priced when the value of the information and advice was rolled in.  Unfortunately he didn’t get to see the information price tag up front.  Interestingly, I found myself in a similar situation, at the exact same nursery.  For me, it was information plus a jug of some chemical needed to solve a citrus tree fungus problem.  I too couldn’t muster the shrewdness to thank the attendant for the information while passing on the grossly overpriced chemicals. 

The lesson … interpersonal obligation can be a huge component of monetizing information.  If my brother or I had found the appropriate information online from a given source we would happily have made the subsequent purchase from another source based on whatever price, trust, etc. considerations we use when actually buying a product we’ve settled on.  There would be no interpersonal switching cost associated with buying from a seller who hadn’t provided the necessary information during the shopping process.

So, the obvious question for internet retailers is how to add a sense of interpersonal obligation to the process of providing information in the hopes of converting a sale.  This wouldn’t serve as an excuse to ignore the portion of the buying cycle that falls after information gathering, learning, and item selection, but it could help mitigate the impact of low switching costs that occur at that point.  Mitigating that impact may help to pay for creating all that informative content.

If you have any neat ideas for adding “interpersonal switching cost” to the ecommerce experience please add them to the comments; we’ll do the same.


Vanessa’s Variety for the Week of January 2nd, 2009

Posted on December 31, 2008 by Vanessa

Happy New Year all!  I am out for the rest of the week so the variety is early.  There are some new posts that I wanted to share, but in addition to that let’s take a look at some of our favorite posts, top stories, and some of the biggest developments in the industry from 2008.

  • Google Product Search up 786% in the category of shopping search.
  • The Silicon Alley Insider reports on Digg’s revenue losses and why ad targeting, or the lack there of, could be a major factor in these losses.
  • Have your 2009 wish list ready for Google?  I know Zach does and Matt Cutts’ parents do, but submissions are coming in fast so add yours soon.
  • Jennifer Laycock released her second installment of “Six Lessons from a Wooden Boy”, but I recommend starting from her first post on the subject.
  • A legend about the inventor of chess may provide insight into internet retail growth.


2008 In Review

Internet Retailer released their top 10 stories from 2008, here they are in ascending order:


I know this couldn't possibly be everything, which events in 2008 were most memorable to you?


Department of Redundancy Department: Internet Connections Need Apply

Posted on October 22, 2008 by Archives

I’d just like to take a minute out of my day to thank our Manager of Customer Service, Josh, for his management of our internet connection. You see, when we were small and starting out, Josh was there from the beginning and it fell on him to set up our internet connection. Then as we grew, moved, expanded, and moved again, Josh has maintained his maniacal death grip management of our internet connectivity.  In fact, Josh single handedly maintains all of our connection issues, including designing and implementing our VOIP phone system. And a job well done, I might add.

However, up until very recently, we at were the red-headed step children from the wrong side of the tracks, literally. Well, not the red-headed part, but some of us are step children, and we were definitely on the wrong side of the tracks. Due to the archaic monopoly structure that limits cable service options, our area was serviced by Charter cable, who in turn refused to service our particular building. And although we are a mere stones throw from the regional headquarters of Charter, we have been unable to get Charter high speed internet access due to the fact that we are located 50 feet on the wrong side of the railroad tracks.

So here we are, a fast-growing, expanding company, complete with VOIP (did I mention that the “IP” in “VOIP” refers to internet protocol), sharing a slow T1 connection at several times the price we could pay for high speed cable internet. Download a large file and be ready to become the office pariah and heaven forbid you have a webinar to call into. But thanks to Josh’s relentless pursuit and a little luck, a couple of months ago we finally got Charter to service our area, and now we cruise the internet at true broadband speeds. Ah, life is good. We have become spoiled by our high speed connection, streaming episodes of The Office and playing Sudoku at will.

That is, until the day the sun stopped shining; the day Charter disconnected us. Due to some clerical error on their end, one recent morning Charter disconnected us. The internet was no more. We panicked. We didn’t know what to do. We quickly reverted to our early days before Al Gore invented the internet; selling bathtubs on the street corner, filing invoices in a drawer, and using those calculators with the rolls of paper that keep a record of your every keystroke.

Josh alone remained calm, level-headed, and undaunted. Since we still had our T1 line (dedicated solely to our VOIP system), Josh set about restoring our internet connection via the T1 line. As we set out to restore connectivity to the masses of employees huddled around a stapler, I was concerned. How long would it take? How complicated would the switch over be, and then the subsequent switch back once Charter reconnected us? Fortunately, it took longer to vocalize my fears than it did to enact the redundancy plan.

For Josh had designed the system, spanning two buildings across the street, with redundancy in mind. He simply patched a couple of connections and we were up and running, splitting the T1 connection between our VOIP and networking systems. A couple of hours later when Charter got it all figured out, we simply reversed the process.

The best part is that when Charter made the same mistake the next day, I didn’t even need Josh to restore the connection. As the office descended into panic, I simply walked across the street, made the appropriate connections, and waltzed back into the office full of adoring fans, all thinking I was a networking genius. All thanks to Josh!