Found this great presentation on How to be a UX Team Of One from the IA Summit 2008.

I liked this presentation for a couple of reasons. First, it's got great slides! As a sometimes presenter, and someone who sits through a lot of conference presentations, I loved the slide layouts. Engaging and original. If you present, watch this presentation with just the presentation style in mind.

Second, and more important, I think the content of this presentation also on target:

• Early in the conversation, as Leah describes her story of how she came to adaptive path, she illustrates the same techniques we use as testers. For more on generative design, check out the following paper . There's a lot in there that transfers to test design.


• The techniques she outlines for identifying the strongest ideas (along with her evite example) are fantastic. You'll see generate, refine, and roughing and overproduction, abandonment and recovery in practice. It also shows a great use of modeling the problem space. (Love the inspiration library as a recovery mechanism.)


• Finally, this is just great information on design. As a tester, I suspect you have an opportunity to do some basic usability testing. This is great background information on user experience heuristics and design principles.

A while ago I answered the following question on SearchSoftwareQuality.com’s Ask The Software Quality Expert: Questions & Answers.

I'm working as an IT engineer and I have a software integration testing question. I have very low-level requirements which match directly to a function or some statements of function -- that is, a group of requirements matches to one function. I want to do software integration testing for the above requirements. Can you please suggest to me how integration testing is possible? I want to know the testing approach.

Here is a clip from my answer:

When talking about your question with Dale Emery, Dale pointed out that for him, one of the fundamental ideas for integration testing is the idea of disagreement between various parts of the system. That is, if we believe part X does its specific function well (hopefully based on some level of unit testing) and part Y does its specific function well, then when we put them together and test we're looking for ways in which there is conflict or unintended consequences between the two. The less certain we are about the different parts we'll be testing, or the lower our confidence in how those two parts will interact, the more integration testing we might want to do.

You can find the full posting here .