SIGIST conference - what did I take away?

The conference yielded a surprising array of different ideas from the tried and tested to the conceptual ideas. The items that caught my interest big style are highlighted below.

Codependency
So what do i mean? Why does testing accept the bum rap that it gets in brief as the title explains its called codependency.

Every time that we accept:-

Late handover of software to test
Software that is not unit tested
Missing requirements
Taking something not conforming to entry criteria
Signing off on something not meeting exit criteria
...to name a few

We are expected to:-

Test to crunched deadlines
Work overtime
Signoff on something with no confidence in it

Result in the long term:-

We take the rap when things go wrong that we had no time to test.
We end up expected to work overtime every release
We always get late releases
Testing is always crunched
Nothing is unit tested

This is written in my words but based directly on the talk presented today by Lee Copeland from Software Quality Engineering at the SIGIST conference

Requirements

My personal experience is with Requisite Pro so I will likely make any examples relate to this and MQC but it could also apply to any equivalent system.

If you hold your test requirements along side your business requirements within you requirements management system, then they can be synchronized so that areas of contention would be automatically identified should the business requirements change. These test requirements can then be fed through to MQC in a read only format for usage in providing the requirements linking.

For me one of the key things about doing this is that the test requirements (ie the translated business requirements) can be baselined alongside the business requirements. This would also allow the provision for metrics to be gathered on the number of requirement changes and how much those changes are directly effecting testing.

This is written in my words but based directly on the talk presented today by John Cheesman from Strat Software Ltd at the SIGIST conference


The potential issue with all this is that the requirements NEED to be maintained for this to function if the requirements are far beyond what is currently being worked on then this will be useless. But ask yourself a question “If we are testing to provide a measure of software quality back to the stakeholders, then how can we do this without requirements. The requirements are what they want”.

History of Testing

Few of us, me included know much about the history of software testing and those names that designed the core principals of software testing that we now use to base all of our methods on. Names such as Dave Gelperin, Glenford Myers, Boris Beizer, Bill Perry, Michael Fagan and Tom McCabe.

Further to this it is also startling how few testers have even picked up a book on software testing let alone read one. I think the continued learning and development of people in any profession is key to the knowledge of the work that those people are doing.

Many people don't view work and indeed life as a continued learning experience where by study is as important there as it ever was in school back when someone explained that “Two plus two equals four”.

This is written in my words but based directly on the talk presented today by Lee Copeland from Software Quality Engineering at the SIGIST conference

The people factor

Never underestimate the power of saying thankyou for all the work done to people especially staff under you when it is clear that they have done a good job.

Ensure that you reward good work with an appropriate reward this could be financial or leave or even just a thank you as above. The main thing is that this is one of the main things that makes doing these jobs worth while. It is also important to consider that things like talking to senior management to give them credit or getting it mentioned in a newsletter can be useful providing a relatively cheap but effective reward.

This is written in my words but based directly on the talk presented today by Martyn Caswell at the SIGIST conference.