A mentor once told me that all of my ideas about work culture were pointless unless I had the numbers to back them up. He went on to emphasize again what most business owners and leaders trumpet -- the best definition of success is in the numbers. I agreed with him, of course. I still do. But I remember asking him: what does success look like to you?

In January of 2002 my friends, Michael Koppelman, Kurt Koppelman, Chuck Hermes, and I started a business together. It was the second go-round for me, Mike and Chuck, having tried our hand at sharing a vision and working together at our first joint adventure, Bitstream Underground.

Over a meal with Michael, we sketched out (on a napkin) our idea for a new company that included “software as a service” and a private version of what is now commonly known as “cloud services.” Our simple sketch was about technology, layered with thinking and creative. Basic, yet original. And that napkin was the beginning of our business plan.

When we talked about the kind of a company we wanted to build we all immediately agreed on two things: it would be values-based--in that we wanted to live our values of honesty, fairness, gratitude, and authenticity without pretense--and we were committed to building the kind of company where we all wanted to work. We created our own dream jobs. And we were convinced that by building that company and cultivating that particular culture we would attract the kind of talent we valued: people that pushed the boundaries of intellectual curiosity and made innovation an institutional standard.

Don't get me wrong, we knew we’d be challenged by traditional rules of business simply because things had always been done a certain way, very different from our way. We expected to make mistakes and ruffle feathers, and possibly fail. But we agreed that it was pointless to be anything other than exactly who we were.

And so we started Clockwork. We called it a “start-over” instead of a “start-up.” We poured every lesson we'd ever learned--both good and bad--into this little start-over. We endured a less-than-glamorous beginning as we waited out our non-competes and tried to make a living. The thing that helped us most during our humble beginnings is the thing that continues to serve us now--we always understood that business is the product of relationships. And the best relationships are born out of trust and respect. Our first clients were those people with whom we'd already established those things.

Over the years, we've been fortunate to serve some fantastic clients and we've triumphed over what, at the time, seemed like insurmountable challenges. We didn't do any of that alone. We've been privileged to work with some of the most amazing minds in the business. Many of those brilliant thinkers are still here, calling themselves “Clockworkers” and contributing to our truly rigorous work.

I've watched businesses like ours come and go. I've watched organizations shine lights on themselves and call attention to their mystical thinking. At the time, it made me wonder what we were doing wrong to make us seem less than mystical or not as glamorous. Still, we stayed steady and on course.

Our company--our services, software, and process--grew organically. Our solutions evolved as technology required it and users needed it. But most importantly, we stayed true to the ideals we shared from the very first day. We worked with good clients. We delivered good work. We invested in people and mutually trusting relationships, with partners, clients, and advisors.

Our band of technologists, creatives, and big thinkers got bigger and better. Like good companies do, we won awards for design and development. We won awards for being a good place to work and for being woman-owned and for being mostly healthy in terms of how we communicate and treat each other.

But you can't win an award for the thing that mattered most. Somewhere in there, in the hard work, and the good people, and the crazy days, we discovered the definition of success: the feeling of real gratitude. We had jobs we loved to do and we got to share that experience with other Clockworkers. And, what's more, the numbers backed it up.

Here we are, 10 years old and still going strong. It seems appropriate to celebrate how far we’ve come by planning for the future. And that's exactly what we're doing. We're celebrating the work we do, the people we get to do it for, and the great people that call themselves Clockworkers.

Personally, I'm celebrating being able to work every day with people I love. I'm celebrating 10 years of a really successful partnership--10 years of getting to work with my friends, my comrades, my brothers. And I'm celebrating discovering that holy grail of business: success.  

Happy Birthday, Clockwork.

Every few months, we have a Clockwork game night.   These are not formally planned events.   We play board games and eat fancy pizza.  Sometimes people play Rock Band or other cooperative video games, but it's mostly about tabletop action.

Many Clockworkers have young kids, so we show kid-friendly films to keep them hypnotized.  Or we just let them run amok in the office.

As a Clockworker, I'm consistently looking for ways to become a better tester, improve my programming skill set and find ways to do my job more efficiently. While life as a software tester at Clockwork is full of challenges and surprises, I found a particular part of my responsibilities tedious: Test Plan Entry.

Prior to launching the testing phase of a project, we enter test plans into TestLink, an open-source project. TestLink allows us to track test plan execution, and for the most part, it works well. However, entering test cases manually into TestLink can be time consuming.

A self-challenge was established: Find a way to speed up test plan entry, and level up my novice programming skills.

What is a Test Plan?

A Test Plan is a combination of scenarios (test cases) and the anticipated behavior (expected results) for features and functionality on a product; the amount of detail each plan contains can vary, depending on the complexity of a product, its schedule, and the test engineer assigned to the project. 

Here's a sample Test Case:

Test Plan Entry

To get the above test case into TestLink, every line must be entered into a separate text box, and each new test step requires a page reload; updating a test case, because our processes are dynamic and fluid, requires similar effort.

To get around this, our test team creates test plans in plain text. This works great; changes to the plain text test plan can easily be tracked using version control software, and any Clockworker can easily edit, add, or change the test plan.

When a test plan is ready to execute, the process of entering test plans into TestLink begins. We migrate the plain text test plan into TestLink, using the tried-and-true cut-and-paste method, test case by test case, step by step, result by result. If a plan had a particularly detailed test case, migrating that individual case into TestLink could easily take 3-4 minutes to enter in this method. A standard-sized project might have 100 unique test cases; cutting and pasting these into TestLink impacts a project's budget, and getting the most out of our time is important.

Improving the Test Plan into TestLink workflow

As a Clockworker, part of my responsibility is improving processes. Was there a way this process could be improved? Can I import a test plan into TestLink?

Unfortunately, importing from a plain text file (our preferred format) isn't supported by TestLink. At one point, TestLink supported importing from Excel spreadsheet files, but this functionality is no longer supported, and tracking TestPlan changes in an Excel file isn't as slick as our plain text solution. However, TestLink supports importing from an XML file format.

For a novice programmer (but experienced tester), it couldn't be that hard to convert plain text to XML, could it? As proof of concept, a simple shell script was drafted that converted a plain text test plan into the very basic elements of a TestLink-compatible XML file.

Adventures in PHP

This initial script was bare bones. After a review by the test team, a distillation of TestLink's XML specification, a series of feature requests, and encouragement from senior staff, I took it upon myself to get familiar with PHP.

Over a couple of nights with PHP and a Clockwork Lab Day, a refined little application was born. Support for complex test cases was added and a simple syntax implemented for our plain text test plans. The Summary section was updated to support HTML for cleaner presentation in Testlink. Finally, the project was christened "TestOutlineConverter" and put into production. Now, our test plans are written faster and easier.

Now, with more TestOutlineConverter

Here's how that test case looks with TestOutlineConverter's simple syntax. This also has a little HTML thrown in for prettier formatting.

TestOutlineConverter Output

And the test case, after being imported into TestLink

Leveling Up

The gains of my efforts were immediately tangible to Clockwork and our clients; budget for Test Plan Entry dropped from over an hour to less than five minutes, the Clockwork Test Team can work faster, and I now have a +1 to PHP on my personal stat sheet.

Where to see, get, and/or contribute to TestOutlineConverter?

TestOutlineConverter is hosted at github. Updates to the program will be committed there and contributions are welcome.

Future plans for TestOutlineConverter include an expanded markup language, TestLink keyword and preconditions support, and the ability to process exported files from TestLink.

About Andrew
Leaf is a Quality Assurance Specialist at Clockwork. At an early age, he discovered a love for the command line and a passion for installing operating systems from floppy disks.
More About Andrew | Follow Leaf on Twitter

Recently, I found an XSS vulnerability in a rather large proprietary CMS. The vulnerability wasn't hugely prominent, but it did allow me to take over any page that I could get the script to be displayed on. And it would appear on all visitors’ screens. Although it was a mostly hidden vulnerability involving cookie values, once found, it wasn't very difficult to execute.

At this point, I had two choices: try to let the site know about the problem, or post the vulnerability in social media networks so other people could exploit it, too.

I'm a nice guy, so I chose the first option. But it wasn't easy, and that's a real problem. Most sites, and the platforms on which they run, don't have the right mechanisms in place for users to report security and technical issues (aside from possible public humiliation on Twitter).

In other words, web sites need to think about how to make it easier for nice guys like me to do the right thing.

Here's what happened to me:

Reporting

First, I tried to get ahold of someone that ran the site on which I found the problem. Not easy. It was a newspaper so the channels of communication were varied and mostly vague. I tried their general help line and hoped to be redirected successfully. Eventually, I ended up at the help desk, “Yes! I did need help in order to help them!” And they seemed to take me seriously: they took down my information and said that someone would be contacting me soon to get the full details. Two weeks later, I hadn't heard back.

In the meantime, I looked up the platform the site was running on. I found the platform vendor's site, looked at their client list, and found the same vulnerability on another site. I went through the same reporting process (“Hello, help desk?”) for the second site as well. Then I contacted the platform provider. 

I wasn’t having a lot of luck at this point. With any of them.

When a door closes, find a window.

Since it was close to the Thanksgiving holiday, I waited patiently. Then I started digging into my contact list. (As in, I knew someone who might know someone at the original site where I discovered the vulnerability.) That got me places. I was put in touch with higher-ups at both sites who treated me professionally and seriously. Furthermore, both sites fixed the issue in a timely manner. They were thankful for my reporting, and a little embarrassed that my previous contact attempts went unanswered and ignored:

Vulnerable Site 1 (Director of Technology):

“Thanks so much for passing that along. We’ve patched up that for both display to the public as well as the private welcome message area (just to be safe). I really appreciate your reaching out to us and I’m investigating why your initial report wasn’t forwarded to our area when submitted through the normal feedback channel. Thanks for your persistence in contacting us on this!”

Vulnerable Site 2 (Vice President, Editor):

“Please accept my heartfelt (and somewhat belated) thanks for identifying these security issues.

We investigated, based on your work, and found several concerns. We developed and deployed a patch for these holes last week. Now, if you see code in the comments, it will display as plain text only - but we also went a little further and fixed similar issues in other places.

I don't know that we would have identified this without your help. I thank you for calling this to our attention, and for the discretion you showed in how you let us know, as well. Please let me know if you see ANYTHING else that we need to address.”

The platform provider was a different story. My phone calls to their tech support line were blown off, so I tried to join their platform developer community. Because it’s restricted to developers for companies that have paid for the software, I requested admittance. I was sent a brush-off email. Arg. I replied to the email address (hoping that it wasn't a black hole address) and actually received a response along with contact info from the Security Architect for the company. FINALLY!

 CMS Provider (Security Architect):

“I sat down with our engineering team and we do see the points where input could be brought into the platform without sanitization if the customer fails to do so.

I'm also getting the ball rolling on getting a method of contact available for people to report issues outside of the normal support channels.

Thanks for your help.”

What do we do with this?

There are a lot of questions to ask ourselves: what are the rules? How far should you go to report an issue to the content owner? Is there a point at which you say "Screw it" and throw up a public post detailing the vulnerability and start sending the link to the post to anyone that will listen? (I nearly reached this point myself.) Which is the better way to solve the problem: going public or going directly to the source?

The sites that I found issue with were grateful for my reporting, but it took a lot of effort. A. Lot. Why’s this a problem? Because while there are groups like Anonymous and Lulzsec hacking into and posting data from unprotected sites, there are also people — nice guys like me — that have no interest broadcasting this information to the world. Don't make it hard for us to do the right thing. Other people may have given up and just posted something like, "Hey look at that! Their shit's broke, yo. Break into it and get some lulz.”

As a company, no matter how someone tries to reach out to you regarding security issues you need to take it seriously and actually pass along the information. There needs to be a plan in place that all employees with email accounts, phones and social media accounts are aware of. And when a user takes the time to contact your company about issues like this, send a follow up. It’s polite, gracious and just good business.

My Answer

Software Testing is my profession and passion. I enjoy finding bugs, reporting them, and verifying that the developer has, in fact, fixed them. Unless I've exhausted all possible communication methods for reporting a vulnerability, I'm not going public with it. 

If after several attempts, I can’t get the attention the issue deserves, I'll go public with the problem as well as publish my trail of communication and what I did to attempt the contact.

As much as I would love to think that making the info public would have been a huge win for my reputation as a tester, the real reward is a secure online environment. We all want it, and therefore we should all contribute to it in a productive way.

About Dez
Dez is a Quality Assurance tester at Clockwork. He started testing web applications for a local e-commerce company and — with the exception of a 2.5 year stint as a guard and computer repair teacher at a Minnesota prison — has been testing ever since.
More About Dez | Follow Dez on Twitter

Hai-ya! A code ninja has produced a snow ninja for December’s wallpaper installation. If you are running OSX, download the Desktop Sequence Pack, set your desktop to change the picture at your desired interval and let it snow!

Happy holidays from your friends at Clockwork.

Download "Snow Ninja"

Desktop Version

• 16:9
• 16:9 (without calendar)
• Widescreen 
• Widescreen (without calendar)
• Standard
• Standard (without calendar)

Desktop Sequence Pack (OSX)

Zip file containing 6 images to cycle through.

1. Download Zip folder (16:9 without calendar)
2. Select downloaded folder under "Desktop and Screen Saver" in System Preferences 
3. Check "Change Picture:" and select desired interval

Tablet Version

• iPad (portrait and landscape in one!)
• iPad (without calendar)

Mobile Version

• Home/Lock Screen

About John
John is a Front End Developer at Clockwork. He delivers a unique blend of creative insight, technical skill and organizational ability with several years of industry experience.
More About John | Follow John on Twitter

Clockwork represented in designer-ly fashion at AdFed's "The Show" on Friday.  I was joined by Micah and Ben from our illustrious and talented design team.  It was an inspiring event and showcased some really, really impressive work.  As I strolled through the award winners, I was struck by the quality of work from top to bottom.  It made me proud to be a part of the Twin Cities design community.

Bringing Home Some Hardware

We were happy to accept an award for our Clockwork Notebook iPad app, which you can download for free from the iTunes store.  It is great to see digital categories starting to get more visibility in competitions like this, and we were in really good company.  In the coming years, I'm excited to see how digital initiatives continue to influence and shape events like this.  For instance, wouldn't it be great if party goers could actually try out the iPad app or browse one of the sites that won?  It would be a great way to really understand the full "experience", which sometimes can far exceed the simple design aesthetic printed on a piece of paper.

Thanks to AdFed for a great party and for recognizing our Notebook app!

About Eric
Eric is the Design Director at Clockwork. His bachelor's degree in marketing, combined with his design savvy and decade of experience, result in effective user-centered designs that help clients achieve business objectives.
More About Eric | Follow Eric on Twitter

This month's wallpaper was inspired by the release of the new Twilight Saga film, Breaking Dawn: Part I, coming out on November 18th. (OMG, you guys! Edward and Bella are TOTALLY GETTING MARRIED!)

Along with the film's release, we'll also soon unveil EdwardMe -- a Lab Day project that started in November 2010 -- where you can add some sparkly vampire hotness to your favorite guy.

Keep an eye on EdwardMe.com and @edward_me for more details!

Download "Edward"

Desktop Version

• 16 x 9
• Standard
• 2300 x 1440
  
  

Tablet Version

• Home/Lock Screen

Mobile Version

• Home/Lock Screen

About John
John is a Front End Developer at Clockwork. He spent a long time trying to figure what to do with his love for art, then the web came. Now he enjoys his time making things beautiful on the web with his trusty friend CSS.
More About John | Follow John on Twitter

Last year for Halloween we dressed up as Foursquare badges. This year we created a spreadsheet and Clockworkers signed up to be their favorite internet memes. Check out the results: