Pages

Sunday, January 10, 2010

How to Succeed or Fail at Connectathon

In addition to the application software you are testing, you should have the following things in your bag or on your laptop:
  • Network Sniffer (WireShark is what I like to use)
  • A wired hub, cables and power strip.
  • Copies of all the IHE, HL7, DICOM, IETF or other specifications you implemented.
  • Application Development Tools (debugger, compiler, et cetera)
If you just want to fail, leave some of it at home.  For the rest, see the table below:

Succeed
Fail
Planning
  1. Make a spreadsheet of all of the tests you need to complete by copying the data from Kudu. Use one tab each for No Peer Tests, Peer to Peer Tests and Group Tests.
  2. Review your actors. If you have not completed MESA testing for some of your actors, DROP them.
  3. Hide rows for ANY OPTIONAL tests, if you have time at the end, you can do these, but not before you've completed REQUIRED tests.
  4. Delete rows for tests required for Options that you don't implement.
  5. Plan for weather delays.  Chicago in January often has snow.  Plan to arrive the day before you are needed.
You can skip the planning step.  You don't need any planning to fail.  You won't need to look at Kudu until Monday around 10:00pm (which is when your plane lands anyway, right?).
Load in and Setup
  1. Drop your box on the table, plug it in, cable it, check network connections.
  2. Configure it to use your assigned IP address.
  3. Activate the /etc/hosts or /windows/system32/drivers/etc/hosts file that you created last week.
  4. Update it with any changes that you find out about.
  1. Search for your equipment that was shipped late and hasn't arrived yet.
  2. Find a place that will recover your data from your un-backed up hard drive.
  3. Ask a monitor what your IP address should be.
  4. Add to your hosts table every time you need a new address.
No Peer Testing
  1. Do your Time Client Test.
  2. Upload the filled out ATNA Questionairre to the WIKI
  3. Upload all of the objects you expect others to be able to render
  4. Render all objects that others have provided for you (check back frequently for subsequent posts)
  5. Provide testing hooks to enable no peer testing of your applications.
  1. Search the internet for how to configure windows to get it's time from an NTP client
  2. Ask someone what ATNA is and whether your product needs it.
  3. Start building the objects you need others to render on day 2.
  4. Don't worry about rendering objects until Friday.
  5. Require applications to use all workflow steps to perform no peer tests.
Peer to Peer Testing
  1. Design your system to be easily reconfigured without a reboot.
  2. Store configurations that you need to use for the connectathon.
  3. Find test partners for each transaction and make a plan for when you are going to test with them.
  4. Save optional tests for last.

  1. Design your system so that a reconfiguration requires a reboot of your server.
  2. Enter configuration parameters manually each time you have to reconfigure.
  3. Test with partners before telling them you are going to run a test.
  4. Spend a lot of time on an optional test that isn't working while you still have required tests to perform.
Group Tests
Make sure that by Wednesday evening you've completed at least one of every test you need for the group tests.
Start testing critical path features Thursday morning.


2 comments:

  1. You forgot that they need to do the tests in/out of order. It's essential to do the most complex tests before finding out if the supporting test work.

    ReplyDelete
  2. Great pointers Keith. Also need support at the company both for the testing and any issues with the software while you are there.

    ReplyDelete