GR Testers - August 12, 2013

Greg's Notes:
•  Pain points:
o      Paradigm shift:
•    Waterfall to Scrum
•    Scripted to ET
•    Manual to Automated
o      Requirements
•    Change / Shift / Unclear
•    Changed by mandate
•    Difficulty understanding well enough to design test
    "Works as designed"
    Nebulous
o      Resources
•    People, Human Capital
•    Hardware
o      Platforms (OS, etc.)
o      Complexity of the System
•    Adding features to an existing software system
•    Slow to change
•    Error prone when changing
o      No unit test (specific example the project leads don't even have the concept of it)
o      Competing / conflicting priorities
o      Backlog is too big (too many "pending" features", excessive Work in Progress)
o      Release management and timeframes
o      Release Management timeframe
•    Missed deadlines
o      Builds fail
o      Process "weenies" 
•    Things have to be done for the sake of fulfilling a process
o      Difficulty in getting a good test plan
o      How to determine you have adequate test coverage
•    Functionality
•    Function points
•    Usability
o      Dealing with people who don't want to do their jobs (i.e. "lazy weenies")
o      Finger pointing

•Narrow the list down to 1 or 2 topics to work on
o    Selected Topic: No Unit Tests

•Describe the problem:
o    "Harder"
o    Lack of support for them
o    Unit may work
•    Unit Integration may not (units might not integrate for the build)
o     Culture doesn't support Unit Test (EE doing the work)
o     Look at how to embed tests so the build fails without the unit tests passing
o     No baseline costs to point out how expensive no unit test is; all projects before were done this way, so there doesn't appear to be any added cost.
o    No metrics to point what time or costs are lost by not doing UT up-front.
o     "You can't test your own code." 

•What do you do about it?
o    Bring in outside (therefore impartial) people to explain the process / problems

•How do you make it happen?
o    Boss is an EE, so he doesn't grasp the concept of unit testing
•    Point out that individual electrical components are tested before they build their circuit boards.
o    Point out cost / benefit analysis.
o    Point out that skipping UT is violating their development process
•    Verify it's actually in the process document.
    Then point out where things are not getting done.
o    Present tests to the developers, "If these [3, 4, 5…] basic 'happy path' tests don't pass, then I'll…"
o    "3 Amigos" meeting (emphasis on friends), Biz / Dev / Tester to review testing and development
•    Very hard to build from the bottom up
•    Easier if you can get some management buy-in
•    Experiment.. ("What if….")
o    Try bringing in a couple developers in to "help with testing" and show them the value of unit tests
o    Informal pairing:
•    Ask a friendly developer to come over and help you test something, for 15 - 30 minutes (minimal time invested)
    Let them be the expert, so it doesn’t appear like you're trying to teach them.
o    Bring them to a meeting with food
•    Makes it a bit more fun / less antagonistic
•    Recognize that the testers are scary; they judge the devs
o    Involve / Invite the devs to participate in what you do.
•    What constitutes success for this problem?
o    Build / repair relationships
o    "Get a few managers interested in this."
•    Shift focus from "Make the date" to "Make it right" (which are not mutually exclusive goals)
•    Now, how do we do that?
o    What steps do we have to take?
o    How do we get it considered?

o    Who might get in the way?

•    Aside: SWOT Analysis
o    Strengths
o    Weaknesses
o    Opportunities
o    Threats
o    Put into a 2x2 grid and lay out thoughts in each quadrant as a way to explicitly call out issues

=== 

Pete's note  - Using a SWOT style analysis you can break out the steps described above, then look for ways to implement them.  THis also will help you consider possible blocks/constraints in the process (Weaknesses - lack of ability in the team, stuff in the team that may get in the way;  Threats - Things/people external to the team that may prevent or block progress.)