Some of this is not that different from what a newly hired software developer would do:
- Learn how the company makes money. Understand what problem the product solves, how people pay for it, how it's deployed (do you ship it or do you host it?).
- Introduce yourself to everyone. You can generate a lot of goodwill by taking the initiative to introduce yourself to everyone and asking what they do. You don't have to go into great depth about it, but knowing what everyone does at a high level will help when you have questions later. And you will need that goodwill, because eventually you will ask some of those people -- particularly the developers -- to do things that they may not want to do.
- Understand the product at a high level. Ask a senior person to whiteboard the product for you. Understand the big components, how they communicate, and which ones are the most important in terms of making money for the business.
- Read the documentation. There probably isn't much documentation, but read whatever is available.
- Try out the product for yourself. Some products are easier to try out than others, but do what you can. Take notes about parts that you can't try out, because those are probably hard to test.
- Dig around in the bug-tracking system. If there isn't a bug tracking system, set one up ASAP. If there is one, look through the bugs. Find areas that tend to be buggy. Find areas with lots of backlogged bugs.
- Ask about quality problems. Ask several people, because you may get different answers. Ask developers. Ask managers. Ask a customer support person.
- Find out what kind of testing happens now. What areas get tested, and what areas don't? What's hard to test? What doesn't get tested enough? How are things tested: how much manual, how much automated, what tools, what's documented, what's just done from memory? How long does it take to test the whole thing? How long does a release tend to take to test?
As you learn more, you will start to get a sense for what should change about how software is tested. For some things, the only change will be that you will do the testing. Here are some things you might decide to do, in no particular order:
- Write tester-oriented documentation. You might write test cases, or high-level documentation, or something else. Writing things tests what you understand, and it helps the people you hire, too.
- Think about automation. You're a software developer, so you have a sense for how to write software to test software. There are testing tools available that you may not have used as a developer, e.g. Selenium for UI testing and JMeter for performance testing. You probably want to know what they do, but you don't necessarily have to use them. That will be driven by priorities.
- Start a list of things that you would like to change. Your status as a newcomer to the company (and to QA) gives you a tremendous advantage: you have a perspective that no one else does, and you don't take for granted that how things work today is how they ought to work.
There is an endless list of other things, but you will figure them out as you learn. If something doesn't seem right, make a note of it. As the list grows, you may get a sense for what other resources you need, whether it's tools, staff, or time.