$LL(k)$ and $LR(k)$ grammars are nice not just because they can be parsed efficiently, but also because we can check if a grammar is $LL(k)$ or $LR(k)$, and because we can generate tables for them (parse tables are used to parse input strings). Note that for these two classes, having the parse table immediately allows you to check whether the grammars are in the classes, because this is so if and only if the tables contain no errors. Also, yes, there are classes of grammars which we can parse efficiently if we have a parse table, but for which we cannot generate the table if it exists.
Any textbook on parsing methods will teach you how to generate the tables for $LL(1)$ methods and possibly also for $LR(1)$ (though $SLR(1)$ is more common). Textbooks such as Parsing Theory by Sippu and Soisalon-Soininen also treat the parse table generation for $LL(k)$ and $LR(k)$ grammars.
Unfortunately, for really weird grammars, the parse tables for $LL(k)$ and $LR(k)$ (though not for $LL(1)$) can blow up and become huge; they will do this even for normal grammars if $k$ is high enough. There are tests available that can check whether a grammar is $LL(k)$ or $LR(k)$ or not that run in polynomial time (table generation is exponential). For details, read the textbook above. Note that in a lot of cases, the table is reasonably sized, so the test is not needed.
If you don't want to try values of $k$ to see if your program works, but instead want to have your computer figure out whether there exists a value of $k$ such that your grammar is $LL(k)$ or $LR(k)$, you are unfortunately out of luck, as this is undecidable. If your grammar is $LR(k)$ for some $k$ though, you can decide whether your grammar is $LL(c)$ for some $c$, possibly different from $k$ (see here for details).