Karen just posted a blog entry on Reading [Database] Schemas in which she mentions that she would like to write a class in this specific area which I interpret as ‘Databases for Testers’. I’ve been working on one in the back of my mind for awhile; I just need to convince the school I run my QA courses through to offer it. I know there is an audience for this sort of thing as most courses regarding databases are aimed at programmers or admins who have their own topics which differ from what Testers need.

As I envision such a course, it would be 2 full days (so 16 hours) and students would have access to a sqllite database to play / practice with during the course. (The benefit is that they can take it with them and it can be easily installed onto machines thus reducing setup pain.) Here is the content:

• Database objects
  • Tables
  • Views
  • Triggers
  • Stored Procedures
  • Cursors
  • Indexes
• Relational Theory
  • Primary Key
  • Foreign Key
  • Normalization
• Transactions
• SQL
  • select
  • update
  • insert
  • delete
• Data Quality
  • NULL
• Security
  • Permissions
  • SQL Injection
  • Sensitive information storage
• Performance
  • Execution Plan
• Tool Survey

Here are the slides for last night’s Testing Project class where we talked about Performance Testing. Obviously the slides do not capture the in-class tool demo where we built a JMeter Test Plan, but some content is better than none.

| View | Upload your own

It’s that time again. Here is what I found interesting in the November issue of Software Test & Performance.

• JMeter + Selenium – Gotta love being proven right. My Testing Project course uses Selenium for functional testing and JMeter. Here is a 5 page article on in a major industry rag which talks about how to use both of these. Guess this answers the ‘does anyone actually use these’ questions.
• The SOA Shell Game – A nice overview of the pitfalls one can stumble into when testing Web Services and some things too watch out for. There are certainly worse articles on this topic floating around.
• Focus on a Clearer View of Metrics goes through a number of metrics that Testers tend to use and how to question each to derive their true meaning. Context is key when dealing with metrics

There are a couple other column-ish articles which are okay too. I’d go pick up this edition.

I found a report from Forrester Research regarding the automated testing tool market. In it they have a company profile slide for each of the participating companies. In all but one of them, the Best for section includes something along the lines of ‘Shops that use other [vendor] products’. Clearly the take away from a sales lead angle is that if a company has one product, you can weasel other parts of the suite in based upon their tight coupling.

So does this mean there is a market need for an commercial open source testing tool integrator?

Hmmm.

Update: It was announced yesterday that the GST is being reduced another point to 5% effective January 1, 2008 so this post is relevant again.

On July 1, the GST (Goods and Services Tax) is being reduced from 7% to 6%. This is a much bigger issue than just being able to buy loot for less.

This has Quality and Testing ramifications in (at least) two places which could have been easily mitigated with proper up-front planning.

1. Presentation – If you have any sort of invoice displayed to a user which shows the breakdown of the tax and it only says the type of tax, but not the rate then you have dodged this bullet. However, if it shows the rate then there is a 50/50 chance that it shows the actual rate. The easy way to have this rate shown is to hard code it into the form itself. However, if this approach was taken you have to change the content, re-test to verify that it correctly displays and then re-deploy the application. All timed to be co-ordinated for 12:01AM on July 1. Not fun. If your developers are especially good/forward-thinking they would have had this value populated dynamically from somewhere else (likely a database) and when the initial testing was done the content was tested to pick up values that were changed there. For the changeover all that needs to be done is update 1 value in the database and to thank your developers for making your life easier.
2. Algorithm – Logically, the other place that this affects is the actual tax calculation. This is much like the Presentation issues above but more dangerous as it deals with actual money. If your tax calculation used a static GST rate you need to fully retest the algorithm. If it was a dynamic value using the same field as the Presentation rate then it will Just Work and be altered in lock-step with the Presentation rate.

The trick then is to keep an eye on the code your group is producing and make sure you are not setting yourself inadvertantly for pain. The only constant is change afterall. So log bugs against your presentation layer and algorithms that have anything statically included.

For last night’s ‘Testing Project’ class I covered automation (the product we are working with is web based). The tool we used was Selenium. I’ve uploaded the deck to slideshare as it is a pretty good (I hope) overview of Selenium. Thanks to Grig for putting me on the right path as far as content goes.

| View | Upload your own

One of the things I try to tell my students is that if they want to give themselves as great a shot at long term career success in testing they should pick up a scripting language. (I then suggest they nag the school to offer my Python course again ;)). This is usually met with cries of disbelief and the ever present ‘Why?’. Well, here is a quick list I came up with to answer that exact point.

You can use a scripting language to

• Create oracles
• Create test data
• Monitor log files
• Replace (overpriced) tools (like QTP)
• Check databases
• Seed databases
• Quickly check algorithms
• ‘grep’ / static analysis

I’m sure there are a tonne more, but as mentioned this was just a quick list.

Leader Machines is an article in the October 1, 2007 edition of Fortune about how some companies (most famously GE) can churn out great leaders. As someone who is in a position of responsibility in the context of training for those who work directly (or indirectly) for me, their nine practices for building leaders was most useful.

1. Invest time and money – don’t just bolt a development program onto existing HR procedures
2. Identify promising leaders early
3. Choose assignments strategically
   • About 2/3 of leadership development comes from job experience, 1/3 from mentoring and coaching and a smidgen from classroom learning
   • Organizations tend to assign people based upon what they are good at, not what they need to work on
   • “You learn 10 times as much in a crisis than in normal times” – A.G. Lafley
4. Develop leaders within their current jobs – short term work assignments; managers don’t leave their jobs but take on an additional assignment outside of their field of expertise or interest
5. Be passionate about feedback and support – combine frequent, honest assessment with plenty of mentoring and support
6. Develop teams, not just individuals – GE puts entire teams through their leadership training where they make real decisions about their actual business
7. Exert leadership through inspiration
8. Encourage leaders to become active in their community
9. Make leadership development part of the culture

All great points to bring to the fore as companies start to think about end-of-year assessments and bonuses.

As my shed continues to be built (walls, gables and roof cross members finished), I continue to come up with testing parallels.

• Automation is not always best tactic. For example, a drill is great for wall pieces, but sucks in the corners due to it’s length. An old fashioned, manual screwdriver excels at this task.
• Different activities require different tools
• Experiment on the most efficient way to do something early in the process. I discovered, quite by accident, the trick to making wall panels align properly. Were I do it again, I would consciously seek to figure out the technique before moving forward.
• Look at completed activities from multiple angles to ensure the results are as you expect. I installed one of the back panels upside down. In the early morning shade it ‘looked’ right from the inside, but it was only after I went around back to pick up a dropped screw I noticed the problem.
• Certain activities can be run in parallel. If I had a second drill the wall panels would have gone up twice as fast as my wife could have been using it on one side while I did the other.
• Don’t rush, you will make dumb mistakes. Some things take exactly as long as they take and not a second sooner
• Just because something is ‘free’ doesn’t mean you actually need it. We bought this particular shed partly because it came with a ‘free’ base kit. Had I thought it through I would have realized I didn’t need it because of the platform I built for it. So not I have a soggy (it was in the rain) box filled with a shed base I have no use for.

In market where layoffs are a rite of passage and employment-for-life is one of those quaint things that happened to our parents, you realistically have to start finding your next job as soon as you have started at the current one. In a tech community as small as Toronto’s the adage of it’s not what you know, it’s who you know is especially true.

I’ve had this post bouncing around for a bit, but it wasn’t until Anne-Marie Charrett wrote I recently re-discovered that the best way to promote myself is to meet people…..in the flesh, face to face… you know, where you shake hands and make eye contact. that I convinced to finish it.

As QA/Testers, there are a couple of events that it makes sense to attend (with resumes / business cards)

• TASSQ is the Toronto Association for System and Software Quality. TASSQ meets once a month for a (decent) meal and after the meal there is a featured presentation. The organizers are pretty well connected in the greater testing world so can lure excellent speakers.
• The Toronto SPIN (Software Process Improvement Network) has been dormant for awhile, but appears to be starting up again. The demographic is more BA type persons, but if you believe that Quality is largely a process issue, then this might be worth going to. If you get a rash from CMMi or similar though you might want to avoid it.
• The ASQ also has a Toronto Chapter but looking at their schedule they seem to be more manufacturing oriented than software. There are worse things to do than get involved in the ASQ though as they have a large software community there too.

Another avenue to get yourself injected into the larger Toronto community is to participate in the numerous un-conference events that happen through the city. The largest one of these is DemoCamp where lots of the movers and shakers get together to keep a pulse on the scene with people demoing the cool things they are working on. The most important networking opportunity is afterwards at the pub though where you can just jump in and out of conversations. I’ve made a tonne of connections through DemoCamp. You can find announcements regarding DemoCamp on David Crow’s site.

There are also a number of related and spin-off events that happen through the month. Some of which are WikiWednesday, VizThink, Enterprise2.0Camp, StartupCamp, FacebookCamp, etc. If you are trying to get yourself known and cannot find something 3 times a week, you are not really trying.

Something with more history than anything so far are user groups. These tend to be pretty light on the tester representation, but as testers are becoming more and more technical and knowing a programming language is becoming a near-requirement (for long term success) we can fit in better. I was a regular attended of the Toronto Linux User Group (at one point adam@linux.ca was my email) 10 years ago and still ping people every so often to keep my name in their contact list. There are groups for every niche / system and language. Pick where you want to be known at and start attending. I know there are active meetings for Unix, Java, .NET, Python, Perl and Ruby. At one point there was even a Mercury Toolset one, but I’m not sure how active they are now.

Finally, this last tip is not really as generic as the ones above, but from a career standpoint is invaluable. Instead of sending your resume to every headhunter in the city, get to know 2 or 3 of them well. Ask to be assigned an associate and request a meeting. Tell them who you are, what you do, what you are looking for etc. I guarantee that they will remember the person who floored them in their office for an hour over someone who they just know as an entry in their contact list. This strategy isn’t without risk of course, but not that much. Most companies who retain a headhunter, retain 2 or 3 firms for the same job. Pick your firm well and you a lot of your bases covered. At one point I was in frequent contact with someone from Procom, CNC Global and still have someone from GuruLink programmed into my phone.

I’ve used all these methods to a fair degree of success over the last 6 or 7 years that I have been actively managing my career. They do require a bit of extrovertedness though as you do have to walk up and introduce yourself, but the connections made are well worth the effort as the people who attend these sorts of thing are generally passionate people which are exactly the sort of people you want to surround yourself with.