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 www.model-based-testing.org.
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!
Thursday, October 19, 2006
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
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
Subscribe to:
Posts (Atom)