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