The document details best practices for creating high-performance engineering teams in software development, emphasizing the importance of automation, continuous integration, and collaboration between engineering and QA. Key strategies include reducing non-productive activities, enhancing testing frequency and quality, and prioritizing bug fixes. It also highlights the significance of using frameworks for automated unit and acceptance testing, as well as encouraging a culture of continuous improvement and transparency.

1. High Performance Engineering Teams
The Technical Practices
Lars Thorup
ZeaLake Software Consulting
October 18, 2011

2. Who is Lars Thorup?
● Managing software
development
● 10 years of agile practices
● 15 years of automated testing
● Introducing agile and
automated testing with clients
● Assessing software projects
and companies
● Founder of 2 agile consulting
companies
● 12+ senior consultants
● 10+ years

3. What is a High Performing Team?
● Short time from getting idea
to going live
● weeks instead of months or
more
● Faster development
● Higher quality
● Lots of experience from
industry how to accomplish
this

4. How to become faster?
● Stop doing non-productive things!
● Manual regression testing
● Bug hunting and debugging
● Implementing more than required
● Out-of-date documentation
● Piling up bug reports
● Rediscovering of knowledge
● Working on stuff not in the value stream

5. How to increase quality?
● Test more thoroughly
● Test more often
● Test cheaper

6. Automate!
● Software companies tell
their clients to automate to
increase productivity and
quality
● This advice also applies to
the software development
itself!

7. Shorten the feedback cycle
● Automate testing
● from weeks to minutes
● Close collaboration between Engineering and QA
● from weeks to hours

8. Don't track bugs - fix them!
● Real bugs are always top priority
● Fix before working on anything on the backlog
● Decide if an issue is a real bug or an (unwanted) feature
● Prioritize (unwanted) features into the backlog
● Purge your backlog

9. Automate the build
● Compile code and installers ● Have a visible dashboard to
show status
● Run tests
● on every commit ● Notify about broken builds
● Top-top priority
● Deploy to internal servers ● "Stop the line"
and production ● How can we prevent this type
● at the push of a button of break in the future?

10. Automate the testing
● Unit tests
● Is the code doing things right?
● Test one piece of code in isolation
● Acceptance tests
● Is the code doing the right things?
● Test the integration of all layers of
code

11. Automated unit testing
● Use a unit testing ● Track coverage for new
framework for each code
programming platform you ● Aim for 75%
use ● ... and more for important code
● Java: JUnit ● Include on the dashboard
● C++: UnitTest++, Google Test
● JavaScript: Jasmine, QUnit
● SQL: Probably JUnit

12. Automated acceptance testing
● Test through the UI if you must
● ...as little as reasonably possible
● Test just below the UI if you can
● Use your existing unit testing framework
● Consider an acceptance testing framework
● like Cucumber

13. Test Driven Development
● Write tests before writing the code to make them pass
● Not a testing technique!
● but a design technique
● Makes it easy to write tests
● keeping coverage high
● Makes the design flexible
● Improves communication between Engineering and QA
● Speeds up development

14. Continuous integration - Continuous delivery
● Each commit to the version control system
● triggers an automated build
● triggers an automated deployment
● Expect developers to commit several times a day

15. Collaboration between Engineering and QA
● QA can test the code as soon as possible
● Before it is written
● TDD collaboration
● Write automated acceptance tests
● Just after it is written (same day)
● Continuous Delivery makes it available
● Exploratory testing
● Scenarios the developer didn't think about
● Make this step part of "done" for stories
● Don't keep a large backlog of untested stories
● Engineering can help QA on testing if required

16. But: what about legacy code?
● Add pinning tests
● special kinds of unit tests for legacy
code
● verifies existing behaviour
● acts as a safety net
● Can be driven by change requests
● Refactor the code to be able to write
unit tests
● Add unit test for the change request
● Track coverage trend for existing
code
● and make sure it grows

17. But: "we can't change the company this much"
● Yes you can! ● It requires
● Enthusiasm
● Others have done it before ● Support
you ● Willingness to invest
● Transparency

18. But: <your question here>

19. References
● "Continuous Delivery: Reliable Software Releases through
Build, Test, and Deployment Automation" by Jez Humble
and David Farley
● Local software companies following these practices with
success
● Wealthfront, Palo Alto
● IMVU, Mountain View
● Salesforce, San Francisco
● Pivotal Labs, San Francisco
● ...