Nything called GUI standards

The simplest way is an anonymous method passed into Label.Invoke:

// Running on the worker thread
string newText = "abc";
form.Label.Invoke((MethodInvoker)delegate {
    // Running on the UI thread
    form.Label.Text = newText;
});
// Back on the worker thread

Notice that Invoke blocks execution until it completes--this is synchronous code. The question doesn't ask about asynchronous code, but there is lots of content on Stack Overflow about writing asynchronous code when you want to learn about it.

Basic guiding principle: if they want you to test something, testers need a way to get the application into that state, and once in that state, a way to validate that the state is correct.

So the first thing is to ensure they understand that automation is programming and the UI is your API.

• Agreement to not arbitrarily change the UI -- if tester Bob see that the component changed from a button to a link, and it matches the spec, clicks and goes on. While a relatively easy code change in automation, it is a change that may have to be made in multiple locations. (your job as a tester is to understand that change happens and minimize the cost of maintenance; their job is to only make important changes and to understand the impact)

• A way to determine which page you are on.... Bob can tell the difference between login and order entry, but how will automation know? If an enter field with the 'Username' label, the login page. If an entry field with Order number, the order field.

Not good -- better practice is a consistent UI element to identify the page -- page title, hidden component, etc.

• A way to uniquely identify every element that you need to interact with (click, type in, verify, etc.) And not INPUT_42....

• Ask the developers what information that testers can provide them to speed their debugging, and ask them to put it into a log file

• Ability to dump state of the program

• Consistent error handling & reporting (also just good UI design)