You don't say anything about the industry you're working in or the development methodology that's used. Those two factors plus the company culture will have a huge impact on the nature of the documentation you need to create and maintain.
If you are in a heavily regulated industry - the documentation you need will be largely mandated by the industry regulations, since it's required for audit purposes. For example, software for the healthcare industry in the USA requires maintaining proof of what testing was performed and when. For test automation, that means keeping logs with screenshots as well as clear indications of what tests were performed, and making those logs generally accessible. It also means maintaining a record of what parts of the application are tested through automation vs parts that are manually tested.
If you are working with a waterfall type methodology - a simple web search will give you a listing of the types of documentation that are expected. The key documentation for waterfall-type methodologies is some kind of test plan that indicates what will be tested (and, equally importantly, what will not be tested) plus some form of test case documentation. These can be Word or Excel documents, or they can be built via a tool. The critical aspect for waterfall or CMMI type documentation is that your test cases are mapped to the requirements document and the functional specification.
If you are working in an agile environment - the required documentation for any of the agile methodologies is rather light by comparison - for test automation you could probably work with the auto-documentation functionality of whichever language you are using (Javadoc for Java, Sandcastle for VB or C#, etc.). For other tests it can be as little as notes attached to user stories of what is tested. Again, a web search will give you some examples to work with.
Honestly, the documentation you use is up to you. The Ministry of Testing has some nice examples of lightweight but effective test documentation in different formats (disclaimer: I have written several articles for the site, but I did not write the one I've linked to). Choose something that works for you and adapt it to your needs. Ask your lead/manager what documentation they expect from you, and provide them with what they need.