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

2.4k views2 Upvotes15 Comments

CIO / Managing Partner in Manufacturing, 2 - 10 employees
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.
3 1 Reply
Chief Executive Officer in Software, 51 - 200 employees

Great point!

Director of Engineering in Software, 11 - 50 employees
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. 
2 1 Reply
Chief Executive Officer in Software, 51 - 200 employees

Thank you Rahul

Director of IT in Software, 1,001 - 5,000 employees
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.  
4 2 Replies
CIO / Managing Partner in Manufacturing, 2 - 10 employees

Excellent point Jill.

Chief Executive Officer in Software, 51 - 200 employees


Director & Head of Engineering in Software, 51 - 200 employees
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  
2 1 Reply
Chief Executive Officer in Software, 51 - 200 employees

Automation is next key part for QA career skill development

CTO in Education, 11 - 50 employees
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.
Vice President of Engineering, Self-employed
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. 
Chief Information Officer in Healthcare and Biotech, 201 - 500 employees
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.  
2 1 Reply
Chief Executive Officer in Software, 51 - 200 employees

Thank you

Director of Information Security in Energy and Utilities, 5,001 - 10,000 employees
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. 
VP of Global IT and Cybersecurity in Manufacturing, 501 - 1,000 employees
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!

Content you might like

We are not doing regression testing10%

25% manual, 75% automated50%

50% manual, 50% automated28%

100% manual, 0% automated8%

Don't know2%


1.8k views3 Upvotes2 Comments

Limited environment/Infrastructure resources31%

Inability to quickly identify the root cause of CI/CD pipeline failures45%

Lack of standardized CI/CD pipeline templates across the organization53%

Integrating security tools - inefficient security implementation leading to false positives37%

Poor communication across business and product teams/coordination challenges26%

Cost/resource management26%

Implementation of CI/CD into on-going projects and workflows22%

Internal resistance: training issues, culture, etc.14%

Inefficient implementation of CI/CD due to lack of expertise, poor training, etc.18%

Poorly written unit and acceptance testing9%



CIO in Energy and Utilities, 11 - 50 employees
How vertical / integrated your different cybersecurity infrastructure components are? - are they manually mantained/monitored? - how much effort did you dedicate to make them work together?

326 views1 Comment