Break-points and watch-points are the ways to involve the debugger. A break-point can be set in the Abap code of interest, in several ways. In the Abap editor, look up the coding you want to see and select the "Break-point" icon (Stop!) which will show a stop sign left of the line. Only Abap coding which is in fact executable can hold such break-point (don't place your break-point on a comment line or a data definition). Note that this type of break-point is "personal" and client-dependant. It will remain until you remove it (from the debugger or Abap editor) or you log off. You will also note that debugging is a multi session matter. Place the break-point in the editor in a session, run the report in another session to invoke the debugger. You will need to restart the report you are debugging.
Using the Abap editor is only one of many ways breakpoints can be set. It is a very common way as it lets the developer decide where (thus when) the debugger should be invoked. So it is quite common that a bit of preliminary investigating is done to set break-points. The object builder (transaction SE80) can be a very helpful tool to do this, e.g. by finding the screen which is shown before the problem first presents itself. Then check the PAI (processing after input) for the screen and set break-points.
Another way to look at a program is a script that juggles with variables. The program effectively alters variables as it's main task. With this in mind, you could use the watch-point. Watch-points are declared in the debugger on a variabele of the program. They will invoke the debugger when the value of a watch-point is about to change. So the debugger will be invoked whenever the value of a variable of your choice is changed during the program run.