Title This Speaker Proposal-And Peer Review Welcome
I'm submitting a speaker proposal for the Better Software Conference 2010 which is a biggie! It's my dream as a speaker to do CAST, and one of the STAR conferences, and this year I want to submit for both of them and do my best to work towards my goal. I've been in contact with the program chair for Better Software and got his feedback on the outline. I'd like to hone in my description and title and I'm very open to feedback. I feel this topic is really what I'm about at the core, and is the reason why I go through the work of presenting, so I know I can speak about this and love it.
Main Message: The code is one important source of data to inform abalanced test strategy, but it is not enough to focus only oncovering and improving the code. While many useful discoveries can be made with code focused testing, if we make sweeping assumptions that everything of value is in the code and limit our testing scope accordingly, many important defects may be missed. Test forwhat is missing from the code, for problems introduced by integration,and you can start finding the bugs that become apparent when you aretesting with a user focus.
Description: Testing the code alone is not a balanced or comprehensive teststrategy, and while it is important, is the user getting lost in all of the process improvements? If our goal is to raise to overall goal of the software, it is key to test for the user experience and not with only a code focused perspective. The code may be entirely covered and delivered on time, but if we fail to report the issues which impeded us deliver compelling software that humans enjoy using, our test coverage could benefit from expansion.
I. How We Test Today
II. What Have We Missed?
III. Testing for the User
IV. Big Finish
Main Message: The code is one important source of data to inform abalanced test strategy, but it is not enough to focus only oncovering and improving the code. While many useful discoveries can be made with code focused testing, if we make sweeping assumptions that everything of value is in the code and limit our testing scope accordingly, many important defects may be missed. Test forwhat is missing from the code, for problems introduced by integration,and you can start finding the bugs that become apparent when you aretesting with a user focus.
Description: Testing the code alone is not a balanced or comprehensive teststrategy, and while it is important, is the user getting lost in all of the process improvements? If our goal is to raise to overall goal of the software, it is key to test for the user experience and not with only a code focused perspective. The code may be entirely covered and delivered on time, but if we fail to report the issues which impeded us deliver compelling software that humans enjoy using, our test coverage could benefit from expansion.
I. How We Test Today
A. Unit testing
B. Code coverage
C. Reviews and inspections.
D. Functional Automated Tests
E. Automated Regression Tests
F. Internationalization/Globalization Tests
G. Performance Benchmarks
H. Compatibility Tests (systems, browsers)
I. Beta programs
II. What Have We Missed?
A. The USER
B. Anything that is missing from the code
C. Integration problems
D. Requirement problems
III. Testing for the User
A. Data Points just waiting to be used
B. What is the code missing?
C. Integration testing.
D. Collaborative Workflow Testing
E. Scenario Testing
F. Usability-More than just “is that pixel right”
IV. Big Finish
A. Real examples of bugs that would be missed even with 100% code coverage.
B. Big Picture Quality-Focus on the code early can be useful, but it aloneis not a complete balanced strategy. Starting with reviewed and testedcode will give us a strong base to test from. When the code is covered,then what? Then you are ready to test for the user experience and useyour creativity and testing expertise to report bugs on anything thatdetracts from the overall quality of the software under test, if thatis in the code or perhaps should be.
Hello,
nice idea overall.
just a question : what is the diff btw :
D. Functional Automated Tests
E. Automated Regression Tests
=> to me func test that is automated becomes automated regression test... no ?
Laurent
Reply to this
Hi Laurent. I meant to call out the difference between automating new "happy path" functionality vs maintaining a legacy automation suite (tests on existing code) as they are often handled differently. What is new functionality now WILL become legacy in the next iteration, but in many cases is treated like new until product is released.
Reply to this
Title for your presentation:
User "Taste Testing": Making sure all the code ingredients satisfy your Users appetite.
Or
Include User Testing, it's one of the most important ingredients for a successful release.
And as a comment, it is interesting how again the pendulum has swung to another extreme where code level testing is taking precedence and the User is left out. Proper balance is what is needed for a project to succeed.
Reply to this
Thanks for your fun titles! I think those sound far more interesting. I totally agree about balance. I use scripts in my testing, in fact, I'm learning lots of python, but I feel like you must DO some of the testing in order to learn about the system under test and improve your script. If you aren't learning about the system, how can your automation and testing improve to target it better? I think that is one other balance issue. No one is actually USING the stuff until so late. It makes it easy for the user to get totally lost.
Reply to this