Tuesday, September 18, 2007

Keeping Testers Busy

There are two problems with testers that appear competing, but instinct tells me their not. One is keeping testers busy. Anyone who's spent any time testing knows the dreary periods of down time that lead (in my case, at least) to productivity hits when you need to be busy. The other is making sure testers have enough time.

The old maxim "If you fail to prepare, you plan to--" something or other is partly true, but the real problem is the busy work in testing. Testers waste a lot of time looking for bugs. They waste a lot of time in preparation, setup, and executing manual steps to get to the point where they can look for bugs. This is not a "let's automate everything" screed. The waste a lot of time planning how and where they're going to find bugs.

Wouldn't it be more efficient if they could just find the bugs and not waste all that time? Those puzzle games which you try to solve in the least number of steps comes to mind. I never really liked those games. Part of it is intuition, practice, understanding the architecture, limitations, functional ambiguity, the developers weaknesses, etc. -- that's what makes a good tester. As anything, experience is a good teacher. And part of it is planning. But most of it is just that it takes a lot of work, and if we knew the solution to the puzzle in advance, we wouldn't need to solve the puzzle (find the bugs.)

Automation can help, especially with setup and repetitive tasks. Taking away the repetitive or unvaluable tasks is great for morale, and keeps you alert so that you find more bugs. But the real problem I want to tackle is the downtime. Part of the answer to keeping testers busy is doing things like working on automation, preparing test data, gaining a further understanding of the requirements and the architecture, etc. All worthy goals.

I'm still reaching for what I want. It's more of the psychological problem. That you need to balance down time with stimulus and relaxation, as well as up time. How do I keep them -- not busy -- but productive when they're bored. Whether it's in downtime when they're surfing the web twiddling their thumbs, or crunch time when they're too busy to be productive, and too strained to be creative and find the bugs.

I had a glimmer of a thought earlier, but have lost it in the analysis. Anyway, I've made a few steps towards identifying the problem, so it's not time lost.

Tuesday, September 11, 2007

Framework Diagram







I was reading another PHP vs. RoR discussion on Slashdot and started thinking about web frameworks again. A short list of frameworks, based arbitrarily on perceived mindshare:

  • Ruby on Rails
  • Django - Python
  • TurboGears - Python
  • CakePHP
  • Symfony - PHP
  • Catalyst - Perl
  • Struts - Java
My apologies if I've left your favorite out. I'd probably like to learn more about it. In practice, I've only used two frameworks in production: Ambivalence (PHP version of Maverick) and Ruby on Rails. I liked Ambivalence for its simple MVC mapping but it is really scant on features and Rails was great for quick database entry forms.

In truth, by far the largest app I built was in VBScript on ASP. I developed on Chilisoft (then recently acquired by Sun) and deployed to IIS, and it wasn't fun, and the other developer on the project firmly followed the Model 1 architecture. From that experience, I came away with the understanding that frameworks are for those of us with smaller brains who *need* the abstraction to make sense of it. She couldn't grok my OO approach to sessions, but loved my hand written logging framework that I needed to sort through her spaghetti.

[That reminds me of the time I wrote a logger in bash...]

Actually, database handling doesn't bother me, even if I end up writing (or generating) tons of DAOs, and maybe it's time to use an ORM tool, though I don't like any of them out there, and am tempted to write my own every time I use one.

Form handling is another thing I don't really mind doing, though I admit to being pessimistic about user input and take a restrictive 90% rule on web facing apps that sucks for usability, or come-what-may attitude for intranet apps.

What I really need are business objects, and if I ever write something serious about security I need an authenication service. Probably 90% of those out there in the wild are actually worthless, even those written for "enterprise" frameworks. But in truth, 99% of the time, no one cares about your data except spammers, and to avoid them, you've got to outrun the bear and/or shark and just be a pain yourself.

[I'm not sure if that metaphor works, but most people probably won't get the reference so I won't have to defend it.]

Anyway, here's a pretty doodle, though it looks like it's not going to post well on this site. I'll try wordpress too.

First Post

So I registered the domain, one-shore.com, in 2005. On August 12, 2007 I filed with the Washington Secretary of State for a corporation named One Shore Inc. I started using aaron at one-shore.com for email shortly thereafter. Today I created a blog on Wordpress and Blogger, to see which I prefer. I've used both for personal purposes, but haven't really been happy with either. So I'll try both alternately and decide eventually. There's not much danger to posterity, but I'll probably post business ideas here and maybe someday someone will want to find out about my company.

So this is the first post. I already composed a big rambling post on wordpress and decided the textarea isn't big enough. Neither is it here. I may end up looking for an offline tool (or just use vi and then cut and paste when I visit a cybercafe.) An email based blog posting tool might be interesting too.

Anyway, I'll duplicate a bit about myself and the company here, in the possibility that it might come out better.

The company is still in the incubator, although the step of creating a corporation with a tax id and all is an important one. I had to pay real money for the business license and incorporation, and now I have to file real quarterly taxes. The first expense was registering the domain and purchasing hosting, but other than that, it has been in fallow.

The main impetus for incorporating is to be able to do corp-to-corp billing should I find consulting work that requires (or prefers) it. Of course, if I end up getting partners and giving them shares or employees with options, I'll be that much closer. Being a registered business may also help with gaining customers if I do go the route of selling products or services.

In just over 1 month I will be moving with my wife to Cuenca, Ecuador. She went down there in 2004 to volunteer with OSSO, the Ophanage Support Servives Organization. She fell in love with the country, the people, and the work, and so now we are returning.

She would like to start her own foundation and work in tandem with OSSO, but also on her own in areas that they don't specialize, particularly in providing help to teenage girls. She will teach English and do job skills training as well as developmental programs for children similar to what she does here.

I will try to make a living, or at least improve my skills while I'm down there. Of course, I'll work with her and the orphans as well, but I will concentrate on starting a business. I don't know how far I will get in the next 6 months. I may end up finding telecommute work, or start selling products, or merely find out that that's not what I want to do. But for 6 months I'll dedicate myself to it, and at the end, evaluate. Which may mean seeking investment, hiring employees, giving up, or maybe just spending some of the profits.

What I'll do first is identify 3 products or services and attempt to develop them. I'll create a web site for the business presence and other infrastructure as needed (network, email, etc.) I'll also look at 3 products or services (probably open-source tools) and look at supporting them. I'll begin with a home office but may end up renting office space. In conjunction with Kelsey teaching English, I will offer computer skills classes. I'll also try to learn Spanish. I will look for web development and testing consulting work as well as part or full time telecommute positions.
After 3 months evaluation, I will decide whether I want to pursue developing or supporting specific applications or markets, or target consulting. Optionally I will continue to pursue both.

My skills are in web application development and software quality assurance. I could pursue hosting solutions or a QA lab, but those are capital intensive. Product development or client hosted solutions are an alternative, but then support services become the liability. Employees, partners, and investors all bring their own baggage. Telecommute and consulting are time intensive and do not allow geometric growth. However, they provide steady income.

These are the decisions I will have to make. I have a pretty good idea what I want, and the answer looks like "all of them" but I will refine it after 3 months, and again after 6 months when we return from Ecuador.

I hope the toughest question will be whether we buy the house in Ecuador or the boat first.