Never Stop Learning

What's the one thing that consistently sets a successful person apart from the rest? Knowledge. The most successful people I know are always reading, watching industry trends, and keeping their ears to the ground for what's new & exciting.

I subscribe to about 30 different RSS feeds on coding, qa, and sales engineering. A lot of the people I follow on Twitter work in those fields. I read up on what's hot in their fields, and then I can speak more intelligently when I'm asked a question about Visual Studio 2010, agile test automation, or how to give a better presentation. That information helps me do a better job, which keeps me employed, which is a happy thing :)

No matter what your role, whether it's sales, testing, development, or something else, there's always something new for you to learn. Keep learning, and you'll never be bored, you'll keep your skillset current, and you'll be able to do your job more effectively.

Helpful Tool: Reflector

Everyone who works with .NET applications should know about Reflector. This is a handy little tool that lets you inspect the code that makes up your application. Need to know what the heck one particular assembly does, and you don't have access to the source code or the developer who wrote the code? Reflector will show you all the methods and classes that live inside the app, what parameters they take, and so on. There are a bunch of plugins available too, that let you view more info about Silverlight apps, get quality metrics, and so on.

Check it out at http://www.red-gate.com/products/reflector/

Even Robots Need Maintenance

When people are first exposed to test automation, one of the questions I often hear is: "If the application changes, like if they totally reorder & redesign the screens in a given workflow, will my automated test break?"

Well, yes. Your manual test cases will need to be changed as well. Your manual testers may also need to be retrained on your app if it changes that dramatically. The point is that your automated tests are going to need to change and evolve as your application changes and evolves. Anyone who tells you that an automated test is bullet-proof and can't be broken is selling something.

So yes, you will need to refactor, repair and update automated tests as you progress. You can make your tests change resilient, but they'll never be change proof. You'll need to plan for those changes in your release cycles, just as you would any other test activity. Be aware of that, keep it in mind, and your automated test efforts will go much smoother.

What do you do to plan for change in your automated tests? Sound off in the comments.