Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] XP and Sorbanes-Oxley comliance

Expand Messages
  • Phlip
    ... That is so close to what I did for High Moon Studios - for a friggin videogame, not a SOX-compliant financial contraption. Each test run wrote a static
    Message 1 of 38 , Oct 24, 2006
    • 0 Attachment
      J. B. Rainsberger wrote:

      > If that's true, then I would probably write a Fit page for each defect
      > with customer-defined acceptance tests, scan in the card as a linked
      > graphic, then take a snapshot of the test run, showing it failed before
      > we fixed the defect and passed afterward. I might then note the
      > Subversion revision number with the change set for the fix.
      >
      > Of course, I've never done all that together before. It just sounds
      > reasonable to me.

      That is so close to what I did for High Moon Studios - for a friggin'
      videogame, not a SOX-compliant financial contraption.

      Each test run wrote a static web page, with a link on each tested game
      level to the same level in the last web page. The system simply
      preserved the head of each run, so I could flick back through them,
      and watch the level's test status change over time.

      To close a bug, I could use this history to perfectly characterize
      when it appeared, its duration, and which build fixed it.

      You can get perfect auditing (in your tests and in your database
      tables) by following a simple rule:

      - never delete, overwrite, or truncate data

      If you follow that rule, then you always spawn a new file with a
      date-stamped filename, so the old file is always there. And from this,
      you get a history for auditing. Same with data tables; if a customer
      terminates their account, you add a record saying it's terminated. You
      don't erase all their data.

      So Fit could run by spawning static pages describing each test run.
      (We can quietly omit all the bench runs - just preserve the Continuous
      Integration runs.)

      To make a searchable database of this sea of data, without bothering
      to add extra navigation links to each page, I simply used Google
      Desktop. ;-)

      --
      Phlip
      http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
    • Phlip
      ... That is so close to what I did for High Moon Studios - for a friggin videogame, not a SOX-compliant financial contraption. Each test run wrote a static
      Message 38 of 38 , Oct 24, 2006
      • 0 Attachment
        J. B. Rainsberger wrote:

        > If that's true, then I would probably write a Fit page for each defect
        > with customer-defined acceptance tests, scan in the card as a linked
        > graphic, then take a snapshot of the test run, showing it failed before
        > we fixed the defect and passed afterward. I might then note the
        > Subversion revision number with the change set for the fix.
        >
        > Of course, I've never done all that together before. It just sounds
        > reasonable to me.

        That is so close to what I did for High Moon Studios - for a friggin'
        videogame, not a SOX-compliant financial contraption.

        Each test run wrote a static web page, with a link on each tested game
        level to the same level in the last web page. The system simply
        preserved the head of each run, so I could flick back through them,
        and watch the level's test status change over time.

        To close a bug, I could use this history to perfectly characterize
        when it appeared, its duration, and which build fixed it.

        You can get perfect auditing (in your tests and in your database
        tables) by following a simple rule:

        - never delete, overwrite, or truncate data

        If you follow that rule, then you always spawn a new file with a
        date-stamped filename, so the old file is always there. And from this,
        you get a history for auditing. Same with data tables; if a customer
        terminates their account, you add a record saying it's terminated. You
        don't erase all their data.

        So Fit could run by spawning static pages describing each test run.
        (We can quietly omit all the bench runs - just preserve the Continuous
        Integration runs.)

        To make a searchable database of this sea of data, without bothering
        to add extra navigation links to each page, I simply used Google
        Desktop. ;-)

        --
        Phlip
        http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
      Your message has been successfully submitted and would be delivered to recipients shortly.