8,874,771 members and growing!

Member Pages

Technical Blog Articles

Video Articles

Recommendations

Membership FAQ

Stephan Meyn - Professional Profile

About Stephan Meyn
Groups
Reputation

Prolific 6,534 Author	Helper 60 Authority	Lurker 39 Debator	Browser 2 Enquirer	Browser 11 Organiser	Member 131 Participant	0 Editor

I am a Software Engineer/Consultant. My work is focussed on helping teams to get more out of their work. So I teach how to do requirements, analysis and design in a format that is easy to understand and apply.
I help with testing too, from starting developers on automated unit testing to running whole testing teams and how they cooperate with development.

For really big projects I provide complete methodologies that support all of the lifecycle.

For relaxation I paddle a sea kayak around Sydney and the Central Coast or write utilities on rainy days to make my life easier.

Member since Thursday, May 22, 2003 (9 years)

Link: http://www.codeproject.com/Members/Stephan-Meyn

Articles

4 (Prolific)

Tech Blogs

Videos

Messages

47 (Lurker)

Q&A Questions

Q&A Answers

Tips/Tricks

Comments

View Blog

Blog RSS

View homepage

Below is the list of groups in which the member is participating

Methods Consulting

Unknown

Administrator, Manager, Author, Member

Organisation
members

To connect Business to the IT services effectively you must define the processes where both sides interact:

Requirements
Project Governance
Testing & Acceptance
Methods Consulting offers comprehensive high value services to address issues in effective IT Service Delivery.

For more information on Reputation please see the FAQ.

You must Sign In to use this message board. (secure sign-in)

Unit Testing

Saturday, October 30, 2004 1:53 PM

I have been having a discussion with Marc Clifton in regards to unit testing.
Marc has been confirming what I have been suspecting. Writing good unit test cases is hard. It is easy to write a positive test case that verifies that the application does the right thing if it is given expected conditions. But trying to find a negative test case that is likely to break the component it is much harder.

So while we have great tools, techniques and processes at hand, we have managed to address everything but the hard bit.

Compare this with system testing. System testers have the same problem yet they do come up with reasonable negative test cases.
I am speculating that it has to do with the specifications that are available. A system tester has (hopefully) Use Cases, which are narratives. The strength of narratives are that they can contain nuances and ambiguity that leads the reader to find potential weaknesses.
On the other hand the designer of a component has non-narrative style specifications: class diagrams, interfaces, sequence diagrams, state diagrams (in order of commonality). These are clear and concise pieces of instruction to the designer. And that may be the problem. They are so deterministic that they do not invite the reader to think of what might go wrong.

More about this later

General News Suggestion Question Bug Answer Joke Rant Admin

Advertise | Privacy | Mobile
Web01 | 2.5.120528.1 | Last Updated 28 May 2012

Layout: fixed | fluid