Consider creating Mind Maps/Modeling your app as you test. One of the most powerful techniques I've used is Mind Mapping. (I know not everyone gets Mind Mapping, but don't write me off yet.) Essentially what I would do is start trying to identify the larger components of the system, and the key sub components/modules, all the way down to even feature calls. For example if I had a system for registration, there might be a ReserveSlot, CancelReservation as possible operations. (When in doubt fall back on CRUD: Create, Remove, Update, and Display alternatively: Create, Read, Update, Delete)
Once you start getting maps of the system, you can then look at what component you are testing, and start creating charters to cover the functionality you know of beneath it, and also to explore for other parts that have not yet been mapped or documented in the model. Eventually you may reach a point where you don't do much adding to the mind map. One thing to look for are pieces of functionality that are reused in multiple places. These are places where redundant testing might be taking place, or it may be that the components are instantiated differently, and thus look different. Those are key things to model as well. Then from there along with the other advice in this thread, build your charters around the areas you know you want to test, the parts it may interact with directly, or be part of a longer process, and anywhere else where they may rub up against each other.