Thursday, October 19, 2006

StarWest Post #2

Today (Wednesday, Oct. 18, 2006) we had three great keynote sessions.

First, Harry Robinson of Google spoke about "How to Build Your Own Robot Army". I thought this was one of the best presentations I have heard at a conference. The main thing I took away from Harry's talk was that test automation can move beyond just repeating carefully constructed scripts to test a variety of functions repeatedly and somewhat randomly.

I think this could find many more defects than the way we currently test and perform test automation. Also, the cost of testing using robots can be many orders of magnitude less than anything we are currently doing.

Do you know anyone who would test for $1.25/hour USD? Plus, you can share the robots with developers to advance testing in the development process, which reduces defects found in testing, and makes life better for everyone.

You can learn more about Harry's work at

Gary McGraw of Cigital spoke on security testing. It was a great presentation as well. The main things I took away from the talk was that 1) the more code, the more bugs there are, 2) bad guys exploit bugs to gain access to systems, 3) to find these bugs, you must think like an attacker.

Finally, Lloyd Roden of Grove Consultants (UK) spoke on the Top Ten Myths and Illusions of Testing. Lloyd is a good friend and I greatly enjoyed his address. His talk was thought-provoking and entertaining. Just a few of the myths and illusions he covered were: anyone can test, senior managers are interested in bug counts, and quality can't be measured.

It was a good day with lots of great ideas and information!

Wednesday, October 18, 2006

StarWest Post #1

I'm at StarWest in Anaheim, CA this week. Thanks to those of you who attended my tutorial session on Monday on "Becoming an Influential Test Team Leader." We had a great time.

Some of you have asked for the list of testing challenges we made during the session, so here it is (not in any particular order):

1. Getting the right technology match (i.e., test tools) for the type of testing at hand

2. Not having enough time for testing

3. Lack of testing skills/training

4. Inability to reproduce defects

5. Insufficient documentation

6. Changing requirements

7. Knowing when to stop testing

8. Cultural resistance to testing

9. Lack of time for training

10. Holding back defect information to look good later in the project

11. Testers being seen as an obstacle to progress

12. No time reserves

13. Over-reliance on testing to find all the defects

14. Lack of human resources

15. Testing only along a narrow path (lack of rigor in testing)

16. Schedule-driven projects

17. The wrong people performing testing

18. Communication gaps

19. Resource planning

20. Non-tangible nature of QA/test

21. Transitioning to automation

22. Understanding how customers use a product

23. Managing offshoring of testing

Whew! What a list!

We determined that 18 are human in nature, 1 (#1) was purely technical and 4 were both. So, this validates the thesis of my book, Surviving the Top Ten Challenges of Software Testing, that most testing problems are people problems.

I'll check in later this week and give my thoughts on what I am hearing and seeing at the conference.

Randy Rice's Software Testing & Quality Blog