[textile]
Today was the second day of the WHET #4 (Workshop on Heuristic and Exploratory Testing). At the workshop, the question of "What is a boundary?" came up. Here's my answer...

Continue talking how a testing concept that are simple in text-books are so complicated in real life within a context. Integration testing is typically described as testing either two components or two systems interacting with each other by channels designed for this purpose. Both types of tests are aimed to check if intended interaction works as designed/specified. But how about unintended interactions? My vision of testing to be done by testers are to test unintended misbehavior of the software. Developer unit tests are typically enough to test the intended behavior. Reveal such type of integration defects are quite complicated task. I found how to solve it in my project, but have no idea how it could be solved in general case.

This is the second issue in series of mini-experiences – learning opportunities I’ve recently described .
Equivalent partitioning is a simple concept isn’t it? I’m going to show that even as simple example as search form with two fields could appear quite complex. A person without testing experience has a good chance to design excess tests still failing to design the test case to detect the defect I’m going to describe. The defect from a real life I've reported few weeks ago. Do you want to check yourself?

There are bugs that sit still waiting for you to catch them. There are flies that could only be killed with proper skills/techniques/tools.
This is the first issue in series of mini-experiences – learning opportunities I’ve recently described . It is typically mentioned that tests should be designed repeatable, so that if any defect is found it could be easily repeated. Nevertheless I’ve seen recently numerous blogs mentioning not repeatable bugs and casualties caused. However it seems the only message is to fix them, not how to make them repeatable.

Often, when a customer ask me to provide a quote for automating performance tests, I tend to do a proof of concept before I give any numbers...

Why ? Because there's no "do-it-all" tools and depending on protocols, complexity and many other aspects, the tool I have may not be suited for the job..

On other cases, it may be a lot faster, and cheaper, to use GUI automation instead, if the load is reasonnable and the GUI, responsive enough.

I have just finally landed after spending a month running around to various conferences and workshops. I will discuss each of them in a bit of detail below, but first I want to talk about the entire experience.

Conferences, tradeshows, and workshops have many purposes. For vendors, it is an opportunity to try and get your wares in front of an interested audience. For practitioners, it is an opportunity to see the latest in tools and technology, and attend tutorials and sessions, sometimes from prominent industry leaders. And for everyone, it is an opportunity to meet new colleagues, reconnect with old friends, and engage in that most basic and valuable activity of any true conference…conversation.

I really enjoyed the STP conference. I am not afraid to say that it was the best conference that I've ever attended. Almost all the presentations that I attended were very good. I was especially impressed by Hung Nguyen (I've never been to one of his presentations before). His straight to the point presentation was about test automation outsourcing.