I'm on Twitter now; @humbugreality if you're interested. No promises whether I'll post there more frequently than I am currently doing here; so far I've twittered two jokes and am wondering what to say next. Judging from the tweets I've seen, Twitter seems to be a combination Facebook + instant messaging...

I've been super busy talking with as many testers and leads on my team as I can, gathering data on what is and is not working for them. I'm completely unsurprised to learn that, as with many other teams I've talked with, they're having problems understanding what tests mean to test, finding and using...

David Treadwell once advised me to take a job where I knew what I was doing about fifty percent of the time and would be completely clueless the rest of the time, because that would be a good balance between comfort and extreme learning. Alan Page says to find the steepest learning curve . I’ve managed...

How much of your testing do you automate? How do you know whether you have automated enough - or too much? My current team is taking the Automate Everything approach. This means we automate every last test case. "110% automation", as one of our executives liked to say. While certain tests may remain...

I tech screened a tester this morning for a position on my team. I always ask the candidate to describe the tester mentality. I loved today's interviewee's answer: More than the product working perfectly without any crash assert, if it is not intuitive and user friendly it is useless. What will the...

Recently one of my teammates was showing off a WPF application he had built. Since it's easy to do, she built a Logical Functional Model and used it to script her demo. One of the cool things her app supported was reskinning (including rearranging and relocating the various widgets), and at various...

Dr. Dobb's published my article " Achieve More Comprehensive Verification With Less Work " online - check it out!

Jerrad is writing a Logical Functional Model for a website. He is approaching the problem exactly right: figure out what the user actions are, and then organize them into a user-sane order. His example is all about searching, so the LFM could be very small, just a few different FindXxx methods. He has...

Your Logical Functional Model lets you write test cases from your user's point of view, test cases that focus on what is being done rather than how it is being done. Your Physical Object Model lets your test cases ignore the details behind interacting with your user interface. Execution Behaviors let...

My previous post hinted that the Physical Object Model takes advantage of some underlying magic that makes different types of controls look similar. This "smudging" of controls into similarity comes courtesy of the controls abstraction layer. While each different type of control is unique (else we...

With the LFM defined and hooked up to Execution Behaviors it makes sense to move on to defining the Physical Object Model . The POM is often the simplest part because it's just a straightforward API around the user interface. Given Surveyor's UI: a likely POM would be: public class UIApplicationWindow...

Once you create your Logical Functional Model the other pieces can follow in any order immediately as chunks of your feature and LFM are defined. I'll follow the most typical pattern here, which brings us to Execution Behaviors. When you first define your LFM you focus on what the user is doing not...

As soon as you have even a vague idea about what your feature is all about you can start defining your Logical Functional Model. Ideally your entire feature team will take part in this exercise, but you can certainly do it on your own as well. Ask yourself "What are the user features here?" Don't think...

All that theory is great, but without a practical application none of it matters. Thus Surveyor. Surveyor is a simple application for creating online surveys. The UI will look something like this: You have three sets of questions: those you have yet to answer, those you have skipped, and those...

Factoring these details out of the test case into intuitively organized libraries allows the test case to focus on the essence of what it is testing rather than incidental details. This helps us write more comprehensive tests faster but spend less time maintaining them. It also enables us to approach...

Most test cases that manipulate a user interface are tightly tied to the current details of that UI. What the test case is doing often gets lost in the details of how it is doing it. We abstract away these implementation details by wrapping our application UI with a Physical Object Model that lets us...

Details regarding how data is pulled out of our application’s internal data structures and other parts of the system environment are factored into an Application Internals model. This isolates knowledge about where data is found and how it is accessed in a single location. We use the same user-centric...

Verifying that a test case’s actions had the expected result is perhaps the most important part of testing. Every test case does something at least a little differently than every other test case, so the expected results are often a little different. These minute differences make it difficult to factor...

Many tests don’t care exactly what data they are executed against. Our Data Manager uses techniques similar to those used with Execution Behaviors to manage Data Providers that generate test data. This solves with a single stroke the dual problems of eliminating hard-coded test values and enabling common...

Most user actions in an application can be executed in different ways. As I mentioned earlier, creating a new document can be done via the following methods: Clicking the File menu, clicking the New submenu, then clicking the New Document menu item Clicking the New Document toolbar button ...

Even a small application such as Microsoft Notepad has a plethora of features that must be tested. While the occasional feature is simple enough that a single test case is sufficient to test it thoroughly, it is more likely that multiple test cases are required to verify a feature works as expected....

What if you had a test case that looked like this? (Assuming a shape-drawing application such as Microsoft Visio...) Logical.Projects.CreateNewProject(); Point rectangleStart = DataManager.ScenePointProvider.GetNextValue(); Point rectangleEnd = DataManager.ScenePointProvider.GetNextValue(); Logical...

The sum of these factors makes testers little more than factories churning out test case after test case, each of which is different only in some small detail (e.g., how a particular operation is invoked) than the others. Another way to say this is that testers are little more than accountants, keeping...

All of these problems combine to make Test perpetually perceived as the “long pole”, since most Test work is done very late in the milestone. Most modern product and feature teams acknowledge that involving Test early in the development process (that is, including testers in the feature specification...

These problems all combine to make test cases a maintenance nightmare. Anytime the application under test changes – regardless of whether the UI changed a tiny bit or an entire feature was dramatically revamped – every affected test case must be updated. Identifying these test cases can be quite difficult...