DISCLAIMER: This is a really bad idea. The ASA platform is designed to be one system, with hardware redundancy. Therefore, you should ensure that the config always stays in sync, which ensures that the state tables always stay in sync, which ensures that everything works the way it is intended to.

But for the sake of education, you could do something foolish. This would likely not be supported by TAC. Technically, you can modify the config on the standby unit, then do a failover to it. When a failover occurs, the newly-active unit does not bulk sync its config or its state to the formerly-active unit. (Meaning, it does not suddenly bring the formerly-active unit up to date.) It does, however, sync updates if you modify something while running on the newly-active unit. The changes you made while standby are not synced, but the changes you make while primary are synced.

Moving on, if you like the result of the failover, then you can do a no failover and failover on the formerly-active unit (or do a write standby on the newly-active), which will then trigger a bulk sync and bring its config completely up to date. Alternatively, if you were not happy with the result of the failover, then you could fail back to the formerly-active unit, where the previous config was still running. Then, of course, you should do a no failover and failover on the unit that you messed up to bring its config back into line with the way it used to be.

Having said all this, I'm betting there are good many situations where you could cause some bad things to happen. Modifying interfaces, I bet is one scenario--if the two have different interfaces and are sending state updates to one another, something could cause some corruption, or a crash.

So, this is meant to teach you how failover works, not to teach you how to rig something up with bubble gum and duct tape. You should always make changes on the active unit. If you aren't comfortable because you can't fail back, then find someone who can help you create a backout plan, or find someone who has the skill to get you successfully through the changes you need to make.

The active/active cluster allows you to split traffic into groups so the A node handles traffic for some networks while the B node handles traffic for the others, in the event of a failover the stable unit will handle traffic for both A&B traffic groups (assigned on a per context basis). Active/Standby cluster handle all traffic on a single node while the other is brought into use only in the event of a failure.

This is generally used when you're going to have more traffic than a single node can handle, if one of the units fails, instead of stopping all traffic destined to the failed ASA it will run in a degraded state until it is replaced. So essentially you're stretching you're hardware and actually utilizing it taking the risk of degradation if there's a failure instead of paying for a standby unit that essentially never sees any traffic pass through.

Edit: Forgot to clarify active/active is only available for multi-context mode since it would serve no purpose otherwise since you couldn't create the groups