Synergy Conference, July 2008
http://www.synergy2008.org

The National Science Foundation has a section called ATE, for Advanced Technological Education, which funds research in community colleges. I have been involved for two years with such a grant called “Scenario-Based Learning in Technical Education.” All of these ATE grants require dissemination, the promotion of our work across the country. The Synergy conference is a working conference where we learn how to disseminate our work successfully.

We met for four days in Phoenix, where we heard some great keynote speakers and worked in our group to devise a plan for disseminating our work next year, which is the final year of our three-year grant. The following list contains the powerful ideas I picked up that will facilitate the adoption of scenario-based learning:

• Enable instructors to take ownership for the methodology in their classroom. Practically speaking, we need to allow them to easily modify the materials we give them.

• Identify problems that instructors are having, and tell them how our methodology can help them solve them. Look at the project from the outside and say “Here’s how we can help you.”

• Have instructors, especially those from Foothill and De Anza, sit in on my classes to see how the students are learning.

• Videotape my class and put the video on the web.

• Research shows that the reasons people adopt change, in order, are: cost, simplicity and compatibility.

• Inform top administrators at Foothill about this work. They talk to many other colleges and can help spread the word.

14 July 2008
Interview with John Thomas, Software Test Engineer at Google.
This meeting included Shuly Cooper, who is preparing a new course in software quality engineering for Foothill College.

Q: What skills do you look for in a new hire?
A: Software test engineers must have all the same skills as software engineers, including:
- knowledge of algorithms
- ability to design well
- ability to handle structured chaos
- coding
- teamwork
- comfortable with loosely defined product requirements

On top of those typical software engineering skills, test engineers must also be able to:
- hack software, break it
- understand the boundaries of software
- handle internationalization and security issues
- communicate bugs to developers in a non-threatening way

Q: What tools do you use to test software?
A: We make use of tools we developed at Google, but we also use:
- GWT test case
- JUNIT
- Selenium
- Eggplant
- JwebTester
- Perforce for internal software and scripts on top of Perforce
- Subversion when a project goes open source

Q: What programming languages are used at Google?
A: Java, C++, and Python

Q: What is the software development process like at Google?
A:
- Requirements are written and reviewed extensively
- Design is written (in English) and reviewed continuously. The design is sent to peers for review before it is halfway finished.
- Pairs programming is practiced
- Code is reviewed regularly, with all feedback from reviewers incorporated. All software engineers spend a lot of their time reviewing others' code.
- New code is released often, between once a week and once a month.

Q: How do you know when you are finished with a product?
A: Tests have covered sufficiently:
- code
- features
- internationalization
- security
- stress
- load
- performance

Q: What are some best practices that you follow at Google?
A:
- In object oriented design, composition is better then inheritance.
- Customer support shows test engineers how to prioritize features.
- We try to do the testing with the same tools and at the same time as development.
- Engineers are encouraged to contribute "across the board", meaning improving common processes in order to help large numbers of Googlers be more productive.

Q: Can you give us references on software test engineering?
A:
- "Effective Java" book
- "Design Patterns" book
- "Introduction to Software Testing" book by Copeland
- GTAC conference
- The Google Testing Blog at
http://googletesting.blogspot.com/