Setting up a QA department for the first ime

Questions
#1

Hi everyone,

Let’s say a tester is moving to a company where they are just planning to establish a QA department.

So far testing has been done by the developers, mostly unit and integration level testing, and some UI automation, followed by a bit of manual smoke testing, performed by a developer who used to work as a tester some time ago.

They’re looking to expand on their existing QA process and improve it and also, to do a handover so the QA team is responsible for most of the testing done in the company, aside from unit tests.

What advice would you give to such a person?

1 Like
#2

Been there 3.5 years ago and it’s really tough situation (but someone has to do it eventually).

You may have knowledge and ideas, but if there was no QA at all before that, then there are numerous problems you’d have to deal with, to name a few - low awareness for QA role importance, little respect for QA authority, resistance for changes that need to happen within different parts of the process.

Best advice is to sit down with managers and top level people, then have a honest talk about state of the QA in company and upcoming changes. Without their support you won’t be able to change anything, so be sure to have them on your side and have regular meetings with them related to ongoing changes in the process.

3 Likes
#3

I think the entire team should be the owner of the tests so I first try to change their mindset that. it’s everyone’s responsibility. Find out why they want this now, what’s their actual problem and then you know better if you need to hire more people or what kind of people you should look for.

1 Like
#4
  • Move slowly, make one small change at the time;
  • Do things because they will bring value to someone - testing for the sake of testing is a waste;
  • Try to delegate and pair as much as possible - what you do today ends up becoming what you do tomorrow, and then it’s better if others are doing because they can keep doing even if you leave the company;
  • Unless you have good reasons to, do not expect others to think that you know what is good testing just because you have a “tester” role in your badge. Authority comes from what people see you doing.
3 Likes
#5

Thank, for the sound advice!

1 Like
#6

That makes a lot of sense, thanks!

1 Like
#7

I like your reasoning, cheers!

1 Like
#8

I’d push back on this one, shifting the goal to be getting the engineering teams to all adopt a quality mindset.

Go in with an open mind and assess where the company is at - how are they working now, what is working for them, and what isn’t working for them. I’ve seen too many people go in to this kind of task that think that everyone needs to do a certain JIRA workflow, that bug reports have to be done in some form or another, etc, etc, but improving quality is the same as any other problem you can use agile to solve. You communicate and you iterate, making incremental improvements to build towards big changes.

I disagree with the idea of needing management/leadership’s buy in to dictate change. Sure, that can be useful, but it’s much better if you can build the support organically - i.e. if you think the biggest issue is that bugs aren’t tracked well, spinning up a bug tracking system with lots of required fields and things is setting yourself up for failure. Focus on true MVP, i.e. just use a very base install of a bug tracker (or maybe even a spreadsheet) to start, with minimal required fields - maybe just title/description/severity, and iterate and go from there.

3 Likes
#9

  • Decide if you want to do QA or testing.
    QA: Are you going to review code, fix problems, improve code, optimize development, make code guidelines, implement tools for different code checks, monitoring, pipelines, improve general product development process - usually some of it is part of a Product Manager’s job, some companies have dedicated QA people to do this, some part of it is a Technical Lead/Architect;
    Testing: Technical empirical investigation of a product on behalf of the stakeholders, with the purpose of finding threats to its quality. Basically - information providing, useful information that none else was able to find.

  • Some testing can be and should be done by everyone.
    More others take care about what they’re developing, the higher chances of finding more problems and sooner.
    The tester should be responsible though for his own work. And for evaluating the product from a different perspective - specific to finding useful information about it’s quality.

  • All code repositories for checks(unit, api, ui, visual, etc) should stay with a development team; the tester will be one of the participants to the code built there.
    The checks should be kept and maintained as a suite of helpers for all the development team.
    Separating code repositories is recipe for possible disasters: code duplication, conflicting priorities - code checks or test, shifting too often the view point, developers would ignore support in the product for possible automated checks, lots of hacks, bad and slow coding or framework improvements, useless or powerless checks that are expensive to maintain and no chances of finding problems.

  • If they want to ‘expand’ the ‘QA process’ and ‘improve it’, can mean they are having problems with the current processes - find out which are those, be specific. It can be that they waste too much time with automated checks and not enough time on testing, maybe too much confirmation and not enough exploration/experimentation, maybe developers can’t shift their mindset well enough so they miss many problems, maybe there’s a company dysfunction and they are trying to find a scapegoat to help with dealing with the risks and problems where it might not make sense, maybe they have coded so many bugs or bad code in the product that all stuff going forward becomes unmaintainable

Take it slow, evaluate the context(from all perspectives) - talk to everyone, touch or access all tools, products and code, check history, meet stakeholders, meet the people with the heavy knowledge - they are great source of info, etc. Find the problems they have.
Evaluate how you’d deal with the risk their business has and the problems.
Review if it’s testing related or on other levels. Speak up if problems are better solved somewhere else!
Think by yourself how you’d deal with those problems/risks. Talk to the team, agree with them if it makes sense or should be adapted.

2 Likes