Previous Entry Share Next Entry
Learning the hard way - How to be a Software Engineer.
robotsunny
sunnywiz

In hindsight, i'd suggest the following for myself:

- When an employee leaves, and his code/projects get transferred to you, immediately assume a 1 week hit per project.  2 weeks or more if the project is still in development.
- During this one week,  go through the UI of the project.  Try to figure out what each and every button does.
- Write a smoke test, a path through the entire feature, which uses every aspect of the feature's functionality.    This becomes especially interesting if there are multiple actors involved, like in routing slips or phase gate.  I used a simple table:
    USER          ACTION              {RESULT}
       A,B,C ..     {use indentation}   {only fill this out if its not obvious}
- Run through the smoke test, logging and verifying any bugs as you go.  A lot of security questions will probably come up (was this user able to do that?).  
- In a complicated test, keep track of test runs as columns.  If GHOST or VPC's are used to do savepoints, mark the savepoints in the test run columns.    Derived data (like saved templates) can be saved into a test run directory somewhere.
- Use the "A", "AA", "AAA" system for naming subsequent savepoints, to allow for maximum describability. 

Congratulations.  The part of the feature that would correspond to the Product Definition Review and/or HLDR is now done. 

Now, its time to go fix bugs and figure out how the code is put together.  If there are no bugs, then follow things through the debugger.    Use CLOC to find tight spots.    Add Unit Tests if at all possible.

I hope the tag i'm putting in works.


?

Log in

No account? Create an account