To know that a SQL exploit worked, you need to be sure that some code you supplied is indeed being executed server side.
One instance of SQL injection could be a query built as
SELECT * FROM users WHERE username='{user}' AND password='{pass}';
By replacing, say, user=squeamish&pass=ossifrage
with user=admin&pass=' OR ''='
, you make it so that the query executed is
... WHERE username='admin' AND password='' OR ''='';
which has good chances of getting administrator login. This is one query.
If you replace, as you did, with ' OR 1=1; WAITFOR DELAY '00:00:05';#
, (actually I believe that # ought to have been --, but maybe both character sequences are valid comment initiators? I forget), you get
... WHERE username='' OR 1=1; WAITFOR DELAY '00:00:05';# other code ignored
and these are two queries. Much more powerful syntax, yes, since you can now execute any query at all as your second one. But several engines do not, or can be configured not to, execute anything beyond the first query. You would then not get any delay, and thus mistakenly conclude that the exploit did not work.
Your second attempt also makes use of the "two query" method.
In order to get a significant delay, you need a function which will take a long time to execute. Depending on the engine, you might do well with:
' OR SLEEP(5)='
This will yield a query of
... WHERE username='admin' AND password='' OR SLEEP(5)='' ...
which, to be evaluated, requires that the engine return the result of a sleep(). The query will most likely fail, but before it does, it will wait five seconds. That's how you can automatically know that a crafted query string would yield better results.
For example in MySQL you get
mysql> select 5=SLEEP(5);
+------------+
| 5=SLEEP(5) |
+------------+
| 0 |
+------------+
1 row in set (5.00 sec) <----