View
2.088
Download
1
Category
Preview:
DESCRIPTION
Based on my experiences building high performance engineering teams, this presentation focuses on the technical practices required. These practices centers around automation (build, test and deployment) and increased collaboration between Engineering and QA (TDD, exploratory testing, prioritization, feedback cycles).
Citation preview
High Performance Engineering TeamsThe Technical PracticesLars ThorupZeaLake Software Consulting
October 18, 2011
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
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
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
How to increase quality?● Test more thoroughly
● Test more often
● Test cheaper
Automate!● Software companies tell
their clients to automate to increase productivity and quality
● This advice also applies to the software development itself!
Shorten the feedback cycle● Automate testing
● from weeks to minutes
● Close collaboration between Engineering and QA● from weeks to hours
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
Automate the build● Compile code and installers
● Run tests● on every commit
● Deploy to internal servers and production● at the push of a button
● Have a visible dashboard to show status
● Notify about broken builds● Top-top priority● "Stop the line"● How can we prevent this type
of break in the future?
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
Automated unit testing● Use a unit testing
framework for each programming platform you use● Java: JUnit● C++: UnitTest++, Google Test● JavaScript: Jasmine, QUnit● SQL: Probably JUnit
● Track coverage for new code● Aim for 75%● ... and more for important code● Include on the dashboard
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
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
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
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
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
But: "we can't change the company this much"● Yes you can!
● Others have done it before you
● It requires● Enthusiasm● Support● Willingness to invest● Transparency
But: <your question here>
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● ...
Recommended