• 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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)