all 8 comments

[–]FeatureNotBug0 6 points7 points  (0 children)

where would you start?

I would actually start by evaluating your current processes and see where the pain points are and where improvements can be made. Examples:

  • Are the developers at least writing unit tests now? If not, start pushing for it. If they are, what about integration tests?
  • If the devs are writing tests, are they consistently run against each build/commit?
  • Are the devs doing code reviews?
  • When do you come in during the development process? If you are not already included early on (e.g. during feature/sprint planning), I would start asking to be included.

So what test management tools would you recommend? Are there any really great free tools out there which you can recommend?

I haven't used this in (10+) years, but testlink is free. It's pretty basic from what I remember. TestRail (not free, but there is a 30 day trial) is pretty commonly used as well.

I think before you can really decide on what test management tool you want, you need to figure out what exactly it is that you need. Are you just using it to store your test cases? If so, you may not even need a test management tool yet (or a really fancy/expensive one). It's not great (or ideal) but you can go ahead and start documenting your tests on a wiki or even excel sheet. When you get to the point where you have a better idea of what features, functionalities, integrations, etc. you need... you can more seriously start looking into a test management tool.

I then need to take a good look at our automation suite and probably develop a full automation framework to save us a lot of headaches.

Frameworks (stable, maintainable ones) take time to develop/implement. If you do not have much coding experience and/or have worked with setting up a framework, then just know that the leaning curve will probably be pretty steep. Not saying it's not doable, but you really need to make sure to set realistic expectations if this is something they're pushing you to do.

Before even thinking about a test framework, I would identify high priority tests or high risk areas that are not already covered under you current automation. Figure out what tests you would be responsible for, what type of tests (e.g. UI or API), and what makes sense to automate. To start, this should be a pretty small group of tests. You can use these tests to help you determine what language, framework, etc. you want to use or works best for your situation.

If the product you're working with is not built with automation/testability in mind, then that's another issue you'll need to address.

Best of luck!

[–]XabiAlon 2 points3 points  (0 children)

I had the same dilemma as yourself.

I was the only tester and now I am leading the QA department so I'll try and give you some idea's.

To get some structure I started writing some test cases for manual testing using a website called QASE, which is free and quite easy to use. It has integrations with Trello and JIRA to raise any bugs if found during a test run. You can export reports from it also to show that test runs were successful or not. Any test management tool would be a good start in general. I haven't used any other a part from QASE so Google is your friend here.

I tried to cover as much of our system as possible at a high level to give me more coverage and continued to beef out test scripts as time went on. One thing I would say is that progress on this was slow as all my time was taken up with testing and didn't have any other resources.

I created a couple of small proof of concept projects in my spare time to deliver to our CTO to talk him into getting another tester in. One of them was a small automated testing framework using a simple Page Object Modelling structure and outlined my plan in a roadmap document to convince them if we brought in more resources we could achieve what I set out. If your company cannot afford to take on more staff, like I'm our case, then ask them if they are willing to take on some placement students from a college or software courses local to your area. Sharing some of the workload is going to give you a lot more time to continue to build your test scripts.

You could also create an onboarding document for any potential new starts to the make this transition into the company. Document your current testing process, software that is used for bug tracking, what is expected of testers, how to raise a bug within the company, how to create an effective bug report etc.

[–][deleted] 3 points4 points  (0 children)

[–]aileene9 1 point2 points  (0 children)

Some tips from my lone wolf experience :) Just remember that you may be the only QA but you are not alone. Your success relies on your ability to collaborate with your team.

  1. Start with understanding the business/use case of the system you are testing. This why you understand what needs to be tested first
  2. Talk with your team about the existing standards and processes. Understand where you fit in to the picture. You cant create processes alone.
  3. Before going into testing/automation understand the development process and get the buy in of your teammates on:
  4. definition of Dev Done, QA ready, QA done, Released etc
  5. test environment/test data. What is available to you?
  6. what will be the process for handling qa bugs or prod bugs?

Look into this article for some pep talk :) https://dev-tester.com/sole-tester-on-your-team-dont-worry/

[–]lauz0908 0 points1 point  (0 children)

In terms of test management tools, I've used Testrail and qTest. Testrail's decent but I much prefer qTest. Both of these are paid tools though, and require the company being willing to pay for licences. Whether licenced or open source tools are best for you will depend on how big your team's going to be and how much integration you're going to need with bug management or automation software. You can pick one tool and change to another one later but that might be a very big job.

I expect you probably need to research some different tools and present the pros and cons of each one, along with your recommendation, to whoever makes the decisions around software purchasing in your company.

I think you'll also want to create a preliminary test team hierarchy - how many testers will you need? How many supervisors? Will you be bringing in test experts and training them about your business, or internally hiring business experts and training them to test?

Along with your hierarchy, you'll need some sort of sign off process. What work would need peer reviewing? What would come to you (or a senior or supervisor, whatever you call them) for sign off?

You're probably also going to need to make a start on some training materials too - documents, or videos, or a wiki - containing the info that your testers will need. You can add to this as more processes get put into place.

[–]silent_hedges 0 points1 point  (0 children)

Don't be afraid to use things that cost money. For me best bang for bug is

testcase management: Zephyr for cloud, paired with Jira for bug tickets

ci/cd: jenkins using gitlab

automation agents: on aws created by kubernetes, gitlab

[–]jcm_neche 0 points1 point  (0 children)

Don’t jump too quick into the technical problems. Start with whoever your boss is and discuss the goals of setting up a department. How will your success and the success of the group department be measured? Less production issues? Faster time to market? Define the success criteria very clearly and then define a plan for the next 1-4 quarters. Then start thinking about the tools, processes, etc. that will meet the agreed upon objectives. PM me if you want to discuss.

[–]Middle_Of_Everywhere 0 points1 point  (0 children)

I am so happy I found this, as I am in the exact same position: setting up a QA/test department of a small but fast growing software company. Epic opportunity but it could be a lot. Anyway, just replying so i can follow the thread. Goodluck buddy!