Interviewed as Java Dev but Hired as Lead QA. No QA experience. What do I do?

Question

I was recently laid off from my 5-years-long tiny telecommute-based server admin / full stack software dev job almost exactly a month ago. Exactly one week ago I interviewed for a job at a small post-startup company for the position of Java Developer, and on my first day at the job my supervisor announced to everyone that I would be starting the QA team. I have no formal experience with being the "QA Guy" but do have extensive but fragmented experience with unit testing and functional testing. At my last company I was the only employee, and the most of my QA was just telling my boss to check out new features or bug fixes. I've read a bit about creating QA software testing plans and strategies but I've never formally been "that guy."

TLDR: Any tips for someone creating a QA department from scratch with no formal QA experience at a small software company whose products still trying to learn everything about?

Answer 1

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.

Answer 2

Any tips for someone creating a QA department from scratch with no formal QA experience at a small software company whose products still trying to learn everything about?

I'll pass on some tips but first let me ask: were you announced as QA without any discussions beforehand? This may be of concern if this reflects the way the organization / your manager works. Think hard about whether you want to spend some of your career there. There are a lot of other opportunities right now if you search.

However, given that, I would recommend the following:

• Learn and become a champion of Best Practices in Quality Assurance.
• Focus on actual users and how they interact with the software
• Focus on 'sad' paths (e.g. forms with errors) as software developers will tend to have most of their focus on the happy path
• If you are using an Agile development process, study "Agile Testing - a practical guide for testers and agile teams" a modern, fantastic book on how to do QA and testing within an agile environment.
  http://lisacrispin.com/agile-testing-book-is-now-out/
• Learn about Usability. In the US refer to
  http://www.usability.gov/what-and-why/index.html
• For web pages, learn about accessibility, Section 508 (if USA) and WC3 recommendations.
  See https://www.w3.org/standards/webdesign/accessibility
• Learn the personalities of the developers and figure out how to provide positive feedback suggesting improvements rather than negative feedback that can be perceived (correctly or not) as criticism.
• Learn the business domain that you are in and what the objectives are of the company that you work for and what "quality" is perceived to mean to senior management. This can vary from higher revenue to increased customer base to increased customer satisfaction with daily use.

• Learn about the 4 quadrants of testing:

  Integrated   Performance
  
  Unit         Exploratory
  

• Learn about the triangle of testing whereby a few high level feature UI tests are supported by hundreds or thousands of individual unit tests.

       UI
   Integrated
  Unit Testing
  

• Make sure there is an easy way for QA to log bugs in the issue tracking system and that QA has the authority to do this. Issues logged should then be reviewed, for example (Agile) during a weekly sprint review.

• Be passionate and extra persistent in the following areas:

  • intermittent bugs
  • usability issues
  • best practices

  You will often need to focus on the long term for these issues and will need to continually make the case for them.

• Be involved in the whole process, including design, review and regular status meetings.

• Aim for embedded quality from the start. This means pairing with developers on test plans, using static analysis tools and pushing quality initiatives while coding. Think Quality Engineering through the process rather than Quality Assurance manual testing once it is all written and baked in and changes are much more expensive (take time, meet resistance, etc.). Explain this distinction to the team. My experience is that most organizations are still viewing Quality in the Quality Assurance sense, not Quality Engineering.

• Learn about the company the products and the industry
  see https://sqa.stackexchange.com/a/17677/8992 for great details.