Also, I would be grateful if you could give me some advice about the skills I need in order to have a career as a Quality Engineer.
I think that the most important skill a Quality Engineer (QE for short) should have is to always strive to deliver quality and never compromise on this goal. Sure, being flexible is just as important, and in order to position yourself in a place where you don't have to compromise on delivering quality, the second important skill is to always, always, do your homework and present facts (backed up with real data and numbers) about the current state of the product you're working on. Don't say things like "the product is too buggy" or "the usability is bad." Instead, focus on showing the type and number of issues you've encountered during your testing cycle or exploratory testing period. Show them numbers! Tell them instead, "our automation shows that feature X has failed Y number of tests out of a total of Z tests, which represents a percentage of P. Furthermore, since feature X is a major feature/path for our product, our customers would most likely be affected by these issues, and I'd recommend that we focus our efforts in improving this area."
By coming prepared with real data and facts, you're not telling people what you "feel" but what the real situation is. People may not respect feelings but nobody can argue with numbers :) Also, when you come prepared with a proposal, you help folks not feel insulted or upset because you're pointing out defect in their code. When you provide an alternative to how remediate a situation where quality is lacking, you help guide folks attention away from personal feelings and to what really matters: delivering quality to your customers.
Thirdly, remember that quality is something that does not start only when the product has gone through feature freeze and is delivered to QE to test it. Quality starts early, when the idea for a feature is still germinating and being discussed during a product's planning phase. When you are part of the planning process, you have the unique opportunity to listen to what the product manager wants to propose as to what the next generation/version of the product should deliver, and you can prepare yourself for the work that will eventually land on your plate. You can also, leveraging your knowledge about what type of issues are affecting your existing customers and the number of issues being filed, make recommendation as to what you believe the customer will expect from a new command line tool feature or from a new web page. Instead of waiting until the very end of the release process, where your feedback may be "too late", you can help them focus on the quality of the product from the very start.
Fourthly, spend some time learning about your issues (bug) tracking system (at Red Hat we use Bugzilla) and how to use it properly. That includes not only how to create a new issue, but also how to comment on existing issues, search, and about the features available to you. And speaking about issues, learn how to properly report them. Instead of filing an issue where your comment says "I clicked on the create button and nothing happened", try to include more information and context around what you were doing at the time you saw the issue happen. Don't be afraid to be verbose when filing your issues, and include as much relevant information as possible. For example, using the same scenario I mentioned earlier, I better report could be:
Subject: User creation through the web ui fails to create new user
Summary: When I log in into the product via the web ui (browser: firefox version x.y.z, operating system: Fedora Linux 23 x86_64) as the admin user and visit the Users page, trying to create a brand new user with valid ASCII values for all fields and clicking the Save button does not seem to complete the task. The web page continues to display the form with the values I entered (see attached screenshot) and even if I close the form and try to list all the available users, the one I tried to create is not displayed.
Further information: there were no visible javascript errors (through the firebug plugin for Firefox) when clicking the Save button but I did not notice some errors while watching HTTPD's error log (also attached).
Obviously, this is only an example for a fictitious scenario, but the bottom line is that your reports should include as much relevant information as possible, and it should be easy to read and follow. Also, it should show that you have done some leg work and that you're not just "tossing the issue over the fence" for developers to figure out a solution. By providing as much information as possible, you may already be providing all the help a developer may need to come up with a solution. Remember, delivering quality should be part of all stages of a product release, even when filing an issue.
I can think of more things to add but time is running out for me :) Let me know what you think about what I wrote and we can chat some more later on.