Start from the basic . When learning a new language, start from the beginning. Understand the elementary notions of it. Make sure you know what the language represents, what it is used for, how to write it properly. Read the tutorials, try out the examples.
Be lazy. Don't reinvent the wheel. If you need some code that someone has already developed, use it. Use existing libraries where possible.
Modularize, don't copy paste. When you know you have bits of code that will repeat themselves, extract them in a separate method and call that method wherever the code is needed.
Think and plan before you write your tests. Take time to analyze the requirements, to discuss the implementation with the developers, in order to identify the broadest and most relevant set of test cases. Take notes. Visualize how regular users will interact with the site. Make sketches. Jumping into testing just to finish it will make you skip some obvious scenarios.
Name things properly. Whenever you pick a name for a method, attribute or test scenario, make it relevant to what it is supposed to do. Describe it as much as possible. Use a decent amount of letters (not 2-3 and not 100).
Ask questions. Whenever something is not clear, or when you just need a confirmation of how well you understand the requirements, ask the people around you for information. No matter how basic or stupid the question might sound, it's the start of a conversation which benefits all the people included in it.
Separate concerns. Don't put all the code in one class. Analyze what you must write. What part is the setup, what part is the verification? Usually tests should largely focus on the actual testing, not the setup, so maybe extract that part into a separate class/unit, so that you minimize how large a test it. Also, you can put in all validations in a separate place. In this case, when you read the test, you should have - a line of code which calls the setup; the test logic; one line of code that performs the validation (if possible). Also i find the following to be some very good principles:
Communicate with your developers. A lot. Help them help you, by having them propose easier or cleaner ways of writing your tests. Their coding knowledge will help reduce the lines of code you might initially think of writing (as per 2 above). Also, a different opinion can always spark ideas for improvement.
Don't trust your developers. Ok, i'm not saying don't go to lunch with them or be their friend, but don't get charmed by the famous "this is only a small change, i promise it works". Don't believe this phrase, prove it. If they were right, even better.