Smart Contracts

Updating Solidity code and Testing a Smart Contract

Books on the Blockchain

Publica Self Publishing

Goodbye Contracting

Hello brave new old world...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Tuesday, 12 March 2013

We just got the new build...

...what’s the plan for testing?

A new build of code is an exciting and nerve wracking moment for any team. But, what to do with it when it arrives should be pretty straight forward. Actually, it ‘should’ be straight forward but of course, isn't everything when it’s obvious to you!

When a new build arrives there’s a rough sequence I ask the team to follow:

Test any defect fixes that are provided in the build first

Defects == danger and so the fixes are critically important, they are also new / changed code so the next step is to…

Retest any failed test cases associated with the defect fixes and make sure they pass now

Failed or blocked test cases that moved to that state because of a defect are your regression tests, to make sure that new or changed code didn’t break anything in the immediate vicinity of the fix.

Run any test cases that haven’t been run yet, start from highest priority

In any testing project we should set a goal of ‘run every selected test case at least once’. This means coverage and potentially uncovering hosts of new defects. Make sure you’re using a test management tool such as Quality Center to track what was and wasn't run.

Re-run any high importance test cases, where time allows / needs must

Often you’re lucky to get to run your full set, if time allows or the business demands it, re-run the highest importance again. Ideally this is done on the candidate release for extra assurance.

You’re done, write the Test Completion report and ship that code!

Thoughts? Send a message!