I don't know how good of an idea it is, but in my Agile GUI Testing software, one thing I'm working on (debugging my old code, actually) is some very basic image recognition software. If/when it works, it will let the tester write a line of code like this to find an image on screen:
Mac backup options FAQ: How can I backup my Mac (iMac, MacBook, MacBook Pro)? What are my options?
There are several different ways to create Mac backups. We can break all these approaches down into two main approaches:
[Note: This article was originally written in 2010.]
If you’re following along with my Automated GUI Testing (AGT) software progress, I’m showing my latest addition in another YouTube video. In short, if you supply a simple text file to describe your menus and menu items, I’ve created a new tool that does the following:
- Automatically generates menu “click” commands
- Automatically generates menu item “click” commands
- Automatically generates tests/demos for these items
In the category of best practices I have to include my thoughts today on unit tests as a form of "comments/documentation you can compile". Let me explain:
I recently had the experience of (a) working on a small but complicated software development project, (b) leaving that project for six months, and then (c) being asked to work on it again. All I can say it wow -- what a great experience it was to come back to a project that was loaded with unit and code coverage tests.
Continuous integration is a key to a quality build process for any multi-developer software development project. I can't say it much better than the way Martin Fowler describes it, so I'll just include a portion of his summary here:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day.
Summary: A quick look at "The Toyota Way", and how information technology (IT) is looked at from the framework of The Toyota Way.
Here's an interesting quote from a book called The Toyota Way:
As I mentioned in a previous blog entry (eXtreme GUI Testing, Part 1) I've been motivated to work on a project in my spare time, and I'd like to start leaking the details here.
For lack of a better name I'm currently calling this project eXtreme GUI Tester, or XGT for short. As its name implies, this is an application (actually a suite of applications) that hopes to make automated GUI testing a little more of a reality.
Here's a "generic" version of a simple test plan I just wrote for testing one wizard in a GUI software application my team is currently developing. I wrote this for one specific wizard, then realized that many of these tests are generically-applicable to all wizards.
Without any further introduction, here is my sample test plan. Feel free to use it as a template for creating your own test plans.
The grand experiment has begun. The problem: I've been on a project developing a very deep application for four years now, and lately it's become so complex and intertwined that things are starting to break. Developers have been known to say "The application is smarter than I am." I'm just a wee bit concerned about our software quality.
Throughout all of this I started to notice that many of these bugs could be found if we had ... (drumroll) ... automated GUI tests.
Unfortunately, time does not permit me the opportunity to delve deeply into my thoughts here. So, here's a short list of areas within the development process that developers think are "nonnegotiable":
- Code quality. No sloppy code, no repeated code.
- Source code control. Gotta have it.
- Repeatable build processes.
- Dedicated development, test, and production environments.
There is also a secondary list of items that are close to these ... but that will have to wait for another day.