First blog

Last night I was talking with other testers over a few beers and realized I was a non-blogging dinosaur that still read magazines. I was also convinced that I was not a testing dinosaur and that I had something to contribute. So here I am, I updated my RSS feeds to look at things other than photography and cycling and I will start writing. Really, I promise.

My areas of test automation are [I think I need better names]:

  1. Full automation – instead of manual testing helpers. This includes hooks into cruise control to start tests, cron, test lab setup, tear down and informing people of unexpected results. I have nothing against test that help manual testers it just isn’t interesting to me now. At Uplogix I have a lab management issue tracking and all the equipment that I test with.
  2. Test harnesses – This is the part of the test system that someone else can use regardless of what they are testing. Your test cases follow patterns indicating passing/failing, expected/unexpected results. When a test case gives up due to environment or failures and when it continues. It may have to activate hardware or virtual machines to connect to a server and get tests to run on that platform. Unit testers have frameworks like RSpec for Ruby, JUnit for Java or Test::More for Perl but I don’t know of an open source harness or framework for system testing. Something that would understand that the same test needs running on Windows ME/IE5 and Windows Vista Business/IE6 are different tests.
  3. Test infrastructure – how you organize your test code so the proper code is in the right place.
    • Abstraction layer giving you an API, in a ‘real language’) to write your test cases to. This might deal with the UI, WebServices, Rest an underlying RDB or a file system.
    • Test code the steps – The bulk of your testing intellectual property safe from UI changes or the technology that connects to it.
    • Test Harness – described above
  4. Automated test organization – Version tracking tests and the abstraction layer, tracking known failures, and test results.
  5. Virtualization – using technology, like VMWare, to test different OS/Browser combinations in a clean room environment. Virtualizing machines for upgrade could pay off well too.
  6. Web testing, Watir in particular. Working with the ruby test-system group, to test the reference web application.
  7. Command line testing – I am currently using Perl’s module to write an abstraction layer.
Explore posts in the same categories: General Test

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: