How to organize a QA Process/Department?

Question

I am in a 10 man team, and I am the only QA in the team. I am new to the team and I have already put a QA process in place.

My process is this:

1. Development (will wait till the development phase is done)
2. QA will do the testing
   • QA will create test cases off of the developer's story and what I see on the existing app(yes, the team does not have any documentation at all, including requirements)
   • QA will then execute test cases
   • QA will assign bugs to developers; developers reassign bugs for a retest to QA
   • QA will certify an app
3. QA will report the summary to the Project manager and developer, giving the 'go' sign for production deployment

Then repeat the process to the next project.

I know, for a fact, that I still lack something in the process. Since documentation is not there, which is the business documents/process documents, is it practical for me to create these documents first before creating all these test cases? We don't have a business analyst/writer. Is there anything I could improve on the process? Feel free to comment on my existing process.

Answer 1

There are some major red flags here.

You're only going to any testing after development is completely done? If this is development of a single feature, that's fine. If this is for an entire sprint worth of data, that's dangerous. You do not want to wait two weeks before sending a bug report to a developer. When I was developing I could barely remember what I worked on a day or two ago, much less weeks ago.

The process of assigning bugs to developers doesn't seem like it should be QA's responsibility. Rather, you should send bug reports to development and let them decide who is going to work on a certain bug. That's for the development manager to decide, not QA.

You don't make any mention of any formalized testing to be done by the development team. Are they going to be crafting unit tests around bugs you send back? The most common place for a bug to crop up is where one has already cropped up before, so get your developers to create unit tests. Ideally they're creating unit tests as they develop (or even before) but we know the world isn't ideal.

Answer 2

What you have described is typical of a 'waterfall' approach to software design. There are some circumstances where this is appropriate, for example, the y2k bug and I have been on such projects.

However most development today is done with a more modern, typically 'Agile' process.

I would suggest that you consider the following Agile process:

• devs and QA and product meet weekly to review new tickets, bugs and chores and score them for the degree of difficulty
• devs and QA meet (before dev starts work) to consider tests, testing and a test plan if needed
• devs write the code and the unit tests that verify it. Tests are NOT optional
• devs and/or QA write integrated and UI tests. Tests are NOT optional or 'ideally done'
• QA perform extra testing manually on a representative variety of devices and applications.
• work is demoed to product and when they are ready merged into master.

Also

• everyone can enter bugs and they are reviewed weekly
• QA acts more as a service to help than a gatekeeper to pass/fail.
• everyone gets training in Agile with a short/long term ScrumMaster on-site
• use a bug/feature/chore tracker as mentioned by Peter. Consider Trello, Pivotal Tracker and Jira
• all members sit together for 0 communication lag
• use a good IM tool. The hot new standard is slack.

This is not a comprehensive list (see resources below) but the key idea here (and I've certainly experienced it over decades of development) is that once the feature is written, with accompanying tests, it's relatively unlikely for the developer to want to start tearing it apart and trying different things based on ideas from others whether they are good or bad. So the earlier the input that the QA team can give the cheaper it is to do it, i.e. the cost of changes rises over time.

Other resources:

• https://en.wikipedia.org/wiki/Agile_testing
• http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468

Answer 3

How are you the only QA guy going to test the work of 10 developers? You will be flooded with work, teach the developers to test! :) This is important, because you will be taking shortcuts under pressure. This could lead to lower quality then before there was a QA guy, because the developers think they have to test less since they now have a dedicated tester.

Also you should try to test in parallel to development, why wait until it is finished. You could already write test-cases and or prepare testing efforts.

I suggest you read this book: Agile Testing

Answer 4

Below are some core Points which should be implemented for a successful project implementation

• Team strength of QA team should be increased to at least 3 resources if possible ( considering you have a team of 10 developers)
• Ensure that unit testing is performed by Dev before QA team proceed with testing activities
• Arrange for a bi-weekly team meeting with Dev leads/Project PM to discuss the testing timelines and project deliverables
• QA team should work closely with BAs, Product team, the dev team
• QA team should build a strong domain knowledge
• Request the business team set the priority of test requirements based on business impact
• Prepare test estimation matrix which could be re-used in every sprint/release
• Effective communication with Dev team and BAs is the key for successful project implementations
• Flag all QA related risks in the early phase of the project.

Answer 5

IMHO most obvious hole in your process is missing bug tracker.

Get one free, like TRAC. It includes wiki for technical documentation.

Every feature should start as a bug in bug tracker. Get developers write whatever thoughts they wave to bug and/or wiki pages linked, so few months later you will be able to recall what assumptions developers made when coding.

Bug tracker will force some process/workflow. Then you can start thinking and talking how you need to tweak it to fit needs of your group, and what other tools you need to involve.

Answer 6

One thing that seems to stand out is that you are considering QA as a competently separate stage from all the other work and you are not working closely enough with the other teams which can lead to various problems.

Here are some suggestions that you may want to consider.

• You need to be getting involved with the projects at an earlier stage. You will be in a great position to spot potential risks and highlight them at an early stage. You will also want to gain an insight into what work is upcoming and how complex it is.
• Attend the estimation sessions regardless of if you are working in an agile way or not. You QA estimate should be included with the development estimate.
• Don't save all the testing until the end. Chances are the developers should be breaking requirements down into smaller tickets or user stories, look to see if you can test when each story is complete. If there are issues, you want to find them sooner rather than right at the end of the project.
• Get involved with the developers and have them provide a short hand-off demonstration of the new feature, this is not only a good way to transfer knowledge across quickly but may also mean the developers find issues themselves whilst demoing the feature to you.
• If working in an agile way, attend those standup's and retrospectives, you need to be involved with the entire team and your opinion matters just as much as everyone else.

Answer 7

I have worked as a single QA in a project team so I think I understand your situation (we followed Scrum principles though). There were advises to push your team towards Agile process which is good of course; however it is often not easy to organize other people, especially if you are not their manager :) Here are several steps you could take yourself in order to optimize the QA process on the early stage:

• Try to access all formal documentation or written requirements (it is unlikely that a product is developed without any of these). Ask your PM and your Team Lead about it. At least try to collect requirements via conversations while you are waiting for features to be deployed.
• Try creating some documentation based on what you have collected. Why not develop some tech writing skills if you have time? They could serve you well in the future. You can also share this documentation with the team and discuss it. Might appear helpful for everyone.
• Analyze the requirements you have collected and try to make some assumptions about potential issues (e.g., this page contains a lot of input fields -> high probability of input validation bugs; this page might be accessible to unauthorized users by direct link etc.). Share your assumptions with PM.
• Think about optimizing the requirements. E.g., some fields or buttons may be confusing for a user; may be duplicated in another place and therefore not needed; maybe conflicting with some other elements. Share your ideas with the team and discuss.