COSMIC Sizing Forums COSMIC Size measurement How to measure testing complexity

Tagged: 

Viewing 1 reply thread
  • Author
    Posts
    • #24175
      Avi Kessner
      Participant

      I recently tried to size a project of upgrading the version of a framework. Basically, we will use a tool to upgrade the code base, which will result in some known breaking changes, and new warnings we want to fix. I ended up with the following calculation:

      1 Entry – Old code for service 1
      1 Exit – New code for service 1
      1 Entry – Old code for service 2
      1 Exit – New code for service 2
      1 read – Automatic code upgrade tool.
      1 write – Expected breaking changes.
      1 read – New deprecation warnings.
      7 CFP

      An objection was raised with this calculation, based on the fact that we would have to do a bunch of e2e testing, since upgrading the framework in the past has created issues with scrollbars, or UI issues. Does it make sense to include a Read / Write/ Exit/ Entry for tests both manual or automated?
      On one hand, I can see these being counted because a test has an output and we record the test results in the long term so there are writes.
      On the other hand, I can see these not being counted because testing is just part of the process, not the size of the software.
      Additionally, if we do count the tests, do we count 1 write for all tests, or 1 write for each category of testing?

    • #24201
      Arlan Lesterhuis
      Participant

      Dear Avi,

      I suggest you to first read the sizing of changes of software, in the Measurement Manual, Part 1 Rule 24, in Part 2 section 3.7 Measurement of the size of changes to software.

      Arlan

Viewing 1 reply thread
  • You must be logged in to reply to this topic.