DIT...data input table. My definition for this is simply a column of data in an Excel spreadsheet we feed into functions and user paths.
Also helps when automating since with a bit of scripting automated tests can simply read the Excel file and feed all defined input into the function being tested.
This sounds very code-intensive but our test planning exercises start under the premise the UI is a DOS prompt. In general I don't need to test a checkout/checkin operation for every single client. I can test from a thick or thin client and have reasonable assurance that if a call to checkout a file comes from a web client causes an error more than likely the same error will occur when using the fat client. Yes, I know there may be some additional code executed based on the client that makes the request but in such a situation I simply put clients on a rotation. One week web client....next week the fat client. If we go an entire week before a defect is found in the thin client which hasn't been tested in a week I'd be quite proud of my team if defects can be found within 1 week of a defect being introduced into the code.
Use templates as a guideline unless the particular industry you deliver software to requires specific templates to be used. Do not assume the people who came up with such templates have a better understanding of you dev methodology, customers, historical issues, etc. to the point their template is automatically better than a template you could define for your projects.
They are people like you and I....challenge the norm when appropriate and don't back down.
Reserve a few months every so often and preview retirement throughout your career. You won't regret that a 35 year career was reduced to 34 years to take vacations measured in months in order to remember what a stress and care-free life is all about.
Books and hard work will get you anywhere you want to go.