The first question is "Do you need either of those buttons?"
"Back" is a universally-available browser control. There is no need to replicate existing browser functionality inside your interface -- at best it'll be redundant, at worst it's a source of confusion (is it going to act exactly like the browser 'back' button, or do something different? does it overwrite the browser history or append to it? There's no way for the user to know without experimenting.) Unless there are particular navigational needs you haven't described here, you probably should remove this button.
The one case where a bespoke "back" button is reasonable is when the user is in the middle of a multi-step process which occurs within the context of a single page -- a stepwise inline popup or modal "wizard" or the like -- and the user needs to be able to move back and forth between the steps of that process without leaving the context of the full-browser page. In this situation, the modal or popup signifies to the user that the "back" button it contains is limited to that context, rather than the full page.
As for "Cancel": based on your description, there are several things that button could be doing. Some are defensible and useful; some are not.
- If "Cancel" means "navigate to the previous page", then it is redundant with both back buttons (the browser's and yours) and is misleadingly labeled. Remove it.
- If "Cancel" means "reset this one-step form to its default state", then it should be labeled "Reset", not "Cancel". It should be retained only if the form is long and complex enough that resetting it might be useful functionality.
- If "Cancel" means "this is step n of a multi-step process, at least one part of which has already been completed, and we're allowing the user to bail out of the entire process and discard any already-submitted data" -- then it's useful and should be kept. In this case, the difference between "back" and "cancel" is clear: "back" will take you to the previous step, "cancel" will abort the entire process.
Should we clear out the form on pressing the back button?
For most interpretations of the word "Back", the form will no longer be visible to the user after the user presses that button -- so there's nothing to clear.
If it is a "step back to a previous step of this multi-step process" back button, then you should not discard the user input: users will expect to be able to move from step to step without loss of data.
Do we need to add any checks (for eg A user might have filled half of the form) on CANCEL/BACK buttons?
Most of the time, you should err on the side of not pestering the user with alerts and messages. But two scenarios in which an alert is appropriate are:
- It's a long, complex form that would take a significant amount of time for the user to fill in again, if they inadvertently navigate away from it.
- The site / app interface is such that it's easy for users to accidentally lose track and navigate away from the form. (Facebook is a good example of this: it's easy for a user to start typing out a comment or post, scroll around on the page to look for something else, then click a link to some other page, forgetting they were mid-comment.) This is generally more applicable to plain navigation, less so to explicit "back" / "cancel" / "reset" buttons, because it's harder for users to not realize what they're doing when they're actively clicking a button that tells them what they're doing.