Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Testing is Your Best Investment Expand / Collapse
Author
Message
Posted Sunday, August 24, 2014 8:04 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Wednesday, October 22, 2014 12:34 PM
Points: 31,181, Visits: 15,626
Comments posted to this topic are about the item Testing is Your Best Investment






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1606943
Posted Monday, August 25, 2014 3:43 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 7:45 AM
Points: 1,253, Visits: 919
Definitely agree.
Writing tests (and documentation) is also a "simplicity test". If a feature can't be tested in a simple way, it's probably a good moment to rethink and redesign the feature.
Post #1606995
Posted Monday, August 25, 2014 5:31 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 1:28 PM
Points: 2,908, Visits: 1,834
Amen to that.

I am making the switch from TDD to BDD (behaviour driven development) simply because the readability of the tests and output is vitally important in demonstrating software quality to non-technical stakeholders.

As someone with "Big Data" in their job title a large part of the battle is convincing people used to shrink wrapped software and big vendor SLAs that cutting edge stuff can be developed in a reliable manner. Using Behaviour Driven Development as a communication device as well as a quality metric is extremely important.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1607018
Posted Monday, August 25, 2014 7:01 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: 2 days ago @ 11:46 AM
Points: 685, Visits: 1,723
After two agonizing weeks of semi-productivity in SSIS on a huge project, I realized my actual job is testing vendors software. (I love the core SQL Server engine, but there's no way that much of the surrounding software (SSIS, SSRS) goes through the same functional testing and usability testing rigor.)

In my code, (mostly custom ETL and utilities), the functionality and users are limited, so tests exist, but they are not as numerous had they gone in end user applications. However my colleagues can use, read and maintain the code and tests. (If they can, then I can, even years later...)

As for using SSIS, the important test is can it be used by my coworkers for this project? Right now it is failing the usability and the functionality tests, so I guess we will be testing the alternatives...
Post #1607051
Posted Monday, August 25, 2014 7:39 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:38 PM
Points: 35,371, Visits: 31,912
I love this article. Too often, testing takes a back door and a lot of managers just don't understand how expensive troubleshooting and rework actually is... especially if the fault makes it out to the customer when they can least afford for a fault to appear.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1607071
Posted Monday, August 25, 2014 8:25 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:09 AM
Points: 7,802, Visits: 9,554
If you want code working and out of the door quickly, there's only one way to do it: first spend enough effort understanding requirements and usability issues, if possible discussing user interfaces with people who will be users, and then make your development and deployment programme inculde thorough testing at every stage: unit testing (including stress testingn of units, checking handling of invalid input data and/or environmental data as well as function testing, throughput testing, and performance testing) is important; system testing must include both black-box testing (tests based on how the software is supposed to work) and white-box testing (tests based on what the software is supposed to do), it must include stress testing, it must include error injection to see if errors can be contained (and ideally recovered without too much impact on the user) and don't cause unlimited damage, it must include testing with workloads and data volumes that exceed requirements to be certain that there is smooth degradation rather than sudden total collapse, it must include testing with bizarre data, and tests must include response times (both for interactive operations and for batch operations); quality assurance testing must be white box testing thoroughly independent of testing that has gone before, it must include stress testing of all types and performance testing of all types as well as error management testing and functional testing, and any failure discovered in QA tests but not earlier should lead to a review of testing plans to try to ensure that that can never happen again. Both System tests and QA tests should have regard to usability and to views expressed by potential end users, so that acceptance trials won't throw up too many unexpected enhancement requests.

If all that is done, there won't be too many big expensive errors on customer sites. There will perhaps be some, as getting it right is difficult, so the software should always be designed to be easily mended as well as being thoroughly tested.

Unforunately it is usually impossible to convince management that doing the job properly form the start will deliver the goods sooner than attempting to do it the cheap way; many managers don't even learn from their failures, but find someone else to blame for the consequences of their decisions to ignore good development and testing practice.


Tom
Post #1607095
Posted Monday, August 25, 2014 2:09 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 4:50 PM
Points: 169, Visits: 404
Unit testing is new to me. Where I worked it was the culture not to do it at all. However, since having left there I've been teaching myself new skills, and one of them is unit testing. I have come to really see it's benefits and will use it wherever and whenever I can.



Rod
Post #1607234
Posted Monday, August 25, 2014 5:27 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:38 PM
Points: 35,371, Visits: 31,912
TomThomson (8/25/2014)
If you want code working and out of the door quickly, there's only one way to do it: first spend enough effort understanding requirements and usability issues, if possible discussing user interfaces with people who will be users, and then make your development and deployment programme inculde thorough testing at every stage: unit testing (including stress testingn of units, checking handling of invalid input data and/or environmental data as well as function testing, throughput testing, and performance testing) is important; system testing must include both black-box testing (tests based on how the software is supposed to work) and white-box testing (tests based on what the software is supposed to do), it must include stress testing, it must include error injection to see if errors can be contained (and ideally recovered without too much impact on the user) and don't cause unlimited damage, it must include testing with workloads and data volumes that exceed requirements to be certain that there is smooth degradation rather than sudden total collapse, it must include testing with bizarre data, and tests must include response times (both for interactive operations and for batch operations); quality assurance testing must be white box testing thoroughly independent of testing that has gone before, it must include stress testing of all types and performance testing of all types as well as error management testing and functional testing, and any failure discovered in QA tests but not earlier should lead to a review of testing plans to try to ensure that that can never happen again. Both System tests and QA tests should have regard to usability and to views expressed by potential end users, so that acceptance trials won't throw up too many unexpected enhancement requests.

If all that is done, there won't be too many big expensive errors on customer sites. There will perhaps be some, as getting it right is difficult, so the software should always be designed to be easily mended as well as being thoroughly tested.

Unforunately it is usually impossible to convince management that doing the job properly form the start will deliver the goods sooner than attempting to do it the cheap way; many managers don't even learn from their failures, but find someone else to blame for the consequences of their decisions to ignore good development and testing practice.


+1000!

Heh... I remember the conversation we had in a similar vein... If you have to pick amongst doing it Right, Fast, or Cheap, make sure that you choose "Right" because, as you pointed out in that other conversation, there's a very good chance that "Fast" and "Cheap" will come along for the ride.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1607300
Posted Tuesday, August 26, 2014 2:14 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 6:50 PM
Points: 5,604, Visits: 3,457
Jeff Moden (8/25/2014)
TomThomson (8/25/2014)
If you want code working and out of the door quickly, there's only one way to do it: first spend enough effort understanding requirements and usability issues, if possible discussing user interfaces with people who will be users, and then make your development and deployment programme inculde thorough testing at every stage: unit testing (including stress testingn of units, checking handling of invalid input data and/or environmental data as well as function testing, throughput testing, and performance testing) is important; system testing must include both black-box testing (tests based on how the software is supposed to work) and white-box testing (tests based on what the software is supposed to do), it must include stress testing, it must include error injection to see if errors can be contained (and ideally recovered without too much impact on the user) and don't cause unlimited damage, it must include testing with workloads and data volumes that exceed requirements to be certain that there is smooth degradation rather than sudden total collapse, it must include testing with bizarre data, and tests must include response times (both for interactive operations and for batch operations); quality assurance testing must be white box testing thoroughly independent of testing that has gone before, it must include stress testing of all types and performance testing of all types as well as error management testing and functional testing, and any failure discovered in QA tests but not earlier should lead to a review of testing plans to try to ensure that that can never happen again. Both System tests and QA tests should have regard to usability and to views expressed by potential end users, so that acceptance trials won't throw up too many unexpected enhancement requests.

If all that is done, there won't be too many big expensive errors on customer sites. There will perhaps be some, as getting it right is difficult, so the software should always be designed to be easily mended as well as being thoroughly tested.

Unforunately it is usually impossible to convince management that doing the job properly form the start will deliver the goods sooner than attempting to do it the cheap way; many managers don't even learn from their failures, but find someone else to blame for the consequences of their decisions to ignore good development and testing practice.


+1000!

Heh... I remember the conversation we had in a similar vein... If you have to pick amongst doing it Right, Fast, or Cheap, make sure that you choose "Right" because, as you pointed out in that other conversation, there's a very good chance that "Fast" and "Cheap" will come along for the ride.


So, so true.

On top of that, by choosing "Fast" and "Cheap" one often has just selected "Delayed" and "Costly". Delayed because someone, somewhere decides that the early shipped software is unworkable, unreliable and/or unmaintainable and costly in terms or maintenance, reputation and/or loss of income.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1607371
Posted Tuesday, August 26, 2014 8:55 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:47 PM
Points: 7,105, Visits: 15,455
Gary Varga (8/26/2014)
Jeff Moden (8/25/2014)
TomThomson (8/25/2014)
If you want code working and out of the door quickly, there's only one way to do it: first spend enough effort understanding requirements and usability issues, if possible discussing user interfaces with people who will be users, and then make your development and deployment programme inculde thorough testing at every stage: unit testing (including stress testingn of units, checking handling of invalid input data and/or environmental data as well as function testing, throughput testing, and performance testing) is important; system testing must include both black-box testing (tests based on how the software is supposed to work) and white-box testing (tests based on what the software is supposed to do), it must include stress testing, it must include error injection to see if errors can be contained (and ideally recovered without too much impact on the user) and don't cause unlimited damage, it must include testing with workloads and data volumes that exceed requirements to be certain that there is smooth degradation rather than sudden total collapse, it must include testing with bizarre data, and tests must include response times (both for interactive operations and for batch operations); quality assurance testing must be white box testing thoroughly independent of testing that has gone before, it must include stress testing of all types and performance testing of all types as well as error management testing and functional testing, and any failure discovered in QA tests but not earlier should lead to a review of testing plans to try to ensure that that can never happen again. Both System tests and QA tests should have regard to usability and to views expressed by potential end users, so that acceptance trials won't throw up too many unexpected enhancement requests.

If all that is done, there won't be too many big expensive errors on customer sites. There will perhaps be some, as getting it right is difficult, so the software should always be designed to be easily mended as well as being thoroughly tested.

Unforunately it is usually impossible to convince management that doing the job properly form the start will deliver the goods sooner than attempting to do it the cheap way; many managers don't even learn from their failures, but find someone else to blame for the consequences of their decisions to ignore good development and testing practice.


+1000!

Heh... I remember the conversation we had in a similar vein... If you have to pick amongst doing it Right, Fast, or Cheap, make sure that you choose "Right" because, as you pointed out in that other conversation, there's a very good chance that "Fast" and "Cheap" will come along for the ride.


So, so true.

On top of that, by choosing "Fast" and "Cheap" one often has just selected "Delayed" and "Costly". Delayed because someone, somewhere decides that the early shipped software is unworkable, unreliable and/or unmaintainable and costly in terms or maintenance, reputation and/or loss of income.


A previous AppDev manager I worked with used a reasonably colorful metaphor from his military background for this scenario. His quote was something to the effect of:

Either FMECA or BOHICA - your call either way.


In short - either plan for the failures you will encounter, or expect some unpleasantness in the delivery.


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #1607487
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse