What's the best piece of advice a tech leader can give when identifying software testing resources for their team?

Question

Answer

Look for someone that is structured, detail orientated and thorough. Good testing takes a lot of planning, attention to detail to explore every permutation, but also needs someone to think outside the box to try to do the unexpected. For example, checking what happens if someone closes the program half way through a transaction.

Answer

Experience does make a difference here, but someone who has an eye for the details, with well organization skills and has the mindset of trying different ways to see what can break things will be best suited. It is really difficult to identify these skills just with an hour's conversation. My advice would be to try with some assignments paid or free.

Answer

It's critical that testing resources understand not just all the use case scenarios but how a novice user might navigate through the software in a way that would be different from someone who is already skilled in using it.

Answer

With all the great points covered , I would also recommend that the testing resources should be able write basic code. Since testing has lot of coding in the form of automation test cases. In my experience I have observed that QA's struggle with coding(even for basic stuff).

I believe that we cant sustain QA with Automation

Answer

When we hire testers, we must look for -

1. Ability to understand the requirements (do they have taste in the mouth?).
2. Attention to details.

If they know test automation, it's a big ++.

We would send UI of amazon.com or Gmail etc, UI of well-understood services and ask the candidates to come up with possible test scenarios and cases. It is quite revealing to see how superficial most of the candidates are, and also it is pleasantly surprising to see how detailed some of them are. BTW, though it appears quite cumbersome, but it is not. One can quickly figure out who is bad and good.

Answer

Courage is high on the list for me.

My best QA people over the years by far are the ones who will speak up, ask clarifying questions, point out when people in the room aren't paying attention to the details, and who hold their peers accountable to quality standards.

We do both manual and QA automation at our company, but our QA people operate more as "consultants" than people who do the majority of the QA lift. We changed our process in Q4 of last year are seeing fantastic results from the change.

The way our QA process works now, QA, devs, and product folks confer on a ticket and agree that the change they're going to make is testable, and that a basic direction on testing the change is well understood. Developers largely test their own work, manual and automated, and are expected to keep notes on what they test and how. QA reviews those notes, suggests improvements or other tests as the work is closer to completion.

We found that in our old, more traditional QA process the learning feedback loop was broken for engineers. This was especially true during periods of rapid development and for minor bugs. It was easy to say "yep, that's a bug" without digging in and figuring out how you wrote that bug and how to guard against it in the future.

With the new process, we are seeing only slightly slowed development pace, but the bug-rate in newly released code is down by 2/3rds.

Answer

For me, it's two things: Having a process driven approach, and having strong communication skills. Being process driven ensures that any bugs or clarifying tasks have the needed descriptions and data for the rest of the team to follow, and allows us to determine whether the testing scenarios match the business processes that are being validated. Strong communication skills are key because we want to ensure that testing findings or suggestions are clear and understood. Some testers are not always able to articulate their findings or process, which results in additional work for the rest of the team.

Answer

Consider ease of use. A key criteria you want to keep in mind is that technology should at it's core make things easier/simpler. If you select a piece of technology and someone on your team that manages it quits the next day, how quickly will the rest of the team pick it up or will it stop in it's tracks? Thats the question you want to ask yourself as you evaluate all new software. Nothing worse than getting tech that is difficult to manage and having critical team dependencies that you can't easily replicate.

Answer

For me its an individual who is able to communicate effectively, who is curious, and who is an effective problem solver- hits a wall, then works smarter not harder to climb, go around or through it!

Also agree with some other points made around a person having some basic coding skills and experience!

What's the best piece of advice a tech leader can give when identifying software testing resources for their team?

Content you might like

At your organization, how much regression testing for new app features is done manually vs. how much is automated?

What are your most common challenges with CI/CD? (pick all that apply)

Any recommendations for educating employees about insider risks? What are some best practices you've found effective / what resonates most?

What would you teach to a team who knows little about Engineering and what's needed to create a product/service from scratch in Engineering? I was recently hired for an early-stage startup and want to help the founding team see the real scope of what we will be facing.

Does anyone have any sample questions to share for a Cyber Security enterprise survey? My goal is to gather data on awareness and knowledge to share with the IT Board.