These days I spend too much of my time recertifying bugs than actual value generating testing or hacking stuff up in python. Last week however I had a brief reprieve from that to produce a data generator for a new feature. This particular feature is about adding a new layer of authentication to the product; not only do you have to provide the correct credentials, but you have to be coming from a known IP Address. The ‘expected’ maximum ip list size is thought to be around 150, so I tested with 255 (a full /24 address block) which I used Excel to generate. (Note to testers, learn to love the ‘fill handle’ in Excel). There was however some concern about the implementation and data independence so in order to trigger multiple lists being inserted at the same time wanted a big list.

A really big list.

Unfortunately, the fill handle does not know the semantics of an ip address so it will merrily generate 10.10.10.256, 10.10.10.257, etc. Two and a half hours later, I whipped together this little bit of python which will generate as many lists as you want, up to the max allowable ip address (255.255.255.255).
(more…)

This year my son started playing lacrosse (I play as well, as does my daughter) and in a blatant attempt to share something I enjoy with him I signed myself up as one of the coaches. Having done a couple practices and found the need to come up with drills that at both teach them the skills and are keep them involved I’m realized there are similarities between teaching 3 and 4 year olds lacrosse and adults about testing. My guess is that this applies to other things as well.

First off, I’m more or less drank all the context kool-aid but would not go so far as to put myself down as a signatory (somewhat along the lines of recommending agile structures, but not Agile). That said, I consider the people leading the context movement to be some of the smartest people in our industry and most of their ideas are ones I recommend testers start to use once they get a bit of experience.

This is where the comparison to lacrosse comes in. One of the key skills to learn right away is how to pickup a loose ball. We teach this using the trap-and-scoop method; basically they put the pocket over the ball to kill it, then pull it back to put some reverse spin on the ball and then shovel it into the pocket when it pops up. Next year, the trap aspect will be removed and they will just scoop it. This teaches them to keep both hands on the stick and to get the stick close to the ground. If we started with just the scoop they kids end up just pushing the ball around the floor because the angle of the stick is wrong. Much later (6 or 7 years likely) the kids that stick with it will likely figure out the Indian pickup which is basically a chop with the stick in one hand which magically ends up with the ball in the pocket (I just send the ball careening off on an unknown angle when I try it…).

In testing, the boundry testing and equvilence classing (and their ilk) are the trap-and-scoop and session based exploratory testing is the indian pickup. Exploratory testing is largely about making a hypothesis, testing it then create a new one based upon what you learned. The weak point in this is the making of the initial hypothesis which is what books by people such of Rex Black help new testers. If you can look at a piece of software and have a list of the Risks that might be present, then it is time to dive into more complicated techniques.

Most new testers that I have seen in the last year or so of teaching introductory testing courses would just end up pushing the ball around if they were shown exploratory or other techniques associated with the context school but would be able to pick it up with ones associated with the factory school.

If Architects had to work like Web Designers is making it’s rounds through blogs and email forwards so who am I to stop the momentum. It’s sad how accurate this is in pointing out the silliness of ever changing requirements. We for instance are a week away from code freeze and have just been told to remove half the functionality of an already tested and bug fixed screen because the customer realized they would have to create another stored procedure to accomodate it. Naturally we said ‘we’ll be happy to’ because that is what we are paid to say, but thats a different rant entirely. In the meanwhile, enjoy the article.

This is a companion post to this one discussing dealing with frustrations / stress at work. Actually, in the grand Google context, this is the third video along these lines. The second one can be seen here but I didn’t come out with any takeaways so didn’t dedicate a post to it.

Back to the topic at hand. Today’s video by a Les Kaye, a buddhist abbot who happened to spend most of his career at IBM which I think is a pretty interesting coupling of callings. In it he talks about ‘spiritual practice’ which does not necessarily ‘zen meditation’ or even religion but about being constantly aware. Obviously it’s a little more complicated, but he does a good job explaining it.

Here are my notes

• Wrote
• On commenting on the speakers of the other two videos, they exhibit 4 outstanding qualitites
  • They are smart
  • They show dedication and sincerity to their work
  • They are wise
  • Finally, they are nice

  While there is not much one can do about ‘smart’, but 3 other factors you have choice about how your portray them

• Google has a meditation program; not that that is all that surprising in light of the other perks they get
• Often we believe that we are paying attention; but we’re easily distracted and let our attentions stray
• What we should be paying attention to
  • the day-to-day; nothing is permenant (once we realize this then we will not desire it, and remove a lot of our suffering according to buddhist teachings
  • – each other (how the same, different, etc) – how we should be with each other
  • our self – especially when we make a mistake; identify why
• Have we as individuals or as a society (or profession) really examined our own values?
• Learn how to avoid traps in life
• Are you defined by your image of yourself? Is that image your true image? Is it based upon something nonpermenant? (remember, nothing is pemenant
• Meditations allows the mind to come back into balance. A busy mind is an unbalanced one.
• Apparently the white queen is the most powerful piece in chess. link (but doesn’t explain why white in particular)

Direct link here.

My review of is now online over at DDJ.

I also just realized that my review of was published back in September also over at DDJ.

After buying a new computer yesterday (hurray!), the email reciept I was sent had a banner in it for free magazine subscriptions. One thing you figure out after awhile in technology is that there is no reason to pay for a magazine subscription if you are willing to do a bit of work for it (where work is defined as fill out a survey and/or tell some white lies saying you are a ceo). The site they sent is here. The catch is of course that even though this banner is from a Canadian company, all the cool magazines are available to US residents. Would I like to get Better Software on a monthly basis? Sure. I’m just not willing to pay for it.

To Canadian readers, here is the list available to us. On a purely testing note, one could argue that it is a bug that I did not get taken to this link from the banner as both my billing and shipping address are Canadian.

In the last year I have worked in 3 distinctly different product environments. Each has their good and bad parts. It is useful to consider the attributes of each when considering joining (or leaving) a company.

Consumer Deliverable
In this environment you are dealing with a physical consumer deliverable; typically a cd, dvd or downloadable installer. As such, deadlines are pretty hard and fast as you likely have a contract with the duplicating company. The initial quality out the door also has to be pretty high as having to recall and recut cds is expensive. The quality strategy and implementation is also in completely in your realm of influence. I happened to be working on enterprise software so did not actually see it in use in the real world, but I suspect there is a certain pride to be had walking into a store and seeing something you were involved in for sale. Time spent on a project here typically is done based on percentage of project done.

Web Property
This is the umbrella name I’m giving companies that deliver their product to consumers through web (such as Points or host other businesses’ services in an ASP model (such as 80/20 Solutions). Here, deadlines, while still very much real are not dependent on booking time with an external entity and so are not as costly monetarily if they slip (unless of course there is contractual penalties) –of course there is a cost to your reputation. This type of environment benefits most from a “release early, release often” strategy (or agile, or continuous integration, or whatever buzzword you like). Think of all the sites that are in perpetually in ‘beta’ around the internet. Thats a secret code for ‘there are bugs, we admit it, and when we find them we will fix them’. Sometimes you can get away with it, sometimes you cannot. The quality strategy is also largely under your control in this situation though in the ASP side of things you might have a UAT cycle before the client starts paying you your monthly fee. Here too you can take pride in showcasing what you do by pointing them to your company’s url. Project tracking is also based upon % complete of the project too though hours spent might be kept track of for billing purposes if you are doing customizations for customers.

Consulting / Outsourcing
This environment is one of rapid product change. For a month you could be involved in a month of testing a financial application followed by a week of analyzing documentation for a social networking product. You however are just the hired help. If the company who is currently paying the bills says to follow a certain methodology or process, you don’t really get a say. I read an email thread today talking about what to do if are told to do something unethical when testing; if its “wrong” morally the answer is pretty simple, if its “wrong” in a braindead sort of why things get a bit fuzzier. Consulting companies also have lots of things on the burners too usually to keep the income stream even which can cause a fracturing of the corporate culture alot more so than if the company is focused on a single product or property. This fractureness(?) makes implementing change organization wide difficult (okay, more difficult because change is never easy) and causes little project-based fiefdoms to arise. “We should do X, but the customer isn’t willing to pay for it so we won’t” can also be heard in some organizations of this nature. Project tracking here is strictly hours worked; if the customer has said they are willing to pay for 40 hours of x, at 40 hours, x stops regardless.

I’m sure there are other large baskets out there (and likely smaller ones that these can be further broken down to), but these are the ones I have seen first hand. When considering a prospective company ask yourself if you are the type of person that is suited not only for the role, but the environment. You might not actually be both.

I found out today (the “fun” way) that there is a size limit surrounding compiled JSPs. That limit is 64k. Of course, the limit does not happen during compilation. No, that would be too simple. Instead the server will compile the page happily to something > 64k, but will then blow up when trying to execute the page.

If you recall, java (and so jsp) is a compiled language, unlike Python which is interpreted. So web app servers (like Tomcat, WebSphere, WebLogic, JBoss, Jetty, etc) take the .jsp file and compile it to a .class file. It is this .class file that actually gives you content in the browser.

It would certainly be well worth the time check your app server’s work directory (or whatever it is in your context; work is a Tomcat term) and see if there are any class files hovering around the 50k mark or so. If indeed there are, they would be worthwhile candidates for some refactoring before they grow any larger and kill the test teams productivity for a day whilst investigating the problem.

Not that the last sentance is an indicator of how my day is going. 🙂