5

I am the technical co-founder of a small software startup with a complex product. Needless to say, it is hard to find a balance between adding new features which customers pay for while keeping existing features stable.

This is the reason why we have two part-time software testers who find bugs before our customers do. However, I noticed a lot of negativity in the team:

  • When the first tester joined, after several months I asked them if they felt dissatisfied with their job because I sense some negativity in the reporting. However, they answered that they are happy and its only part of their job to pinpoint what's wrong.

  • After this talk I noticed their tone to be a bit more friendlier and I actually think that they are enjoying the work.

  • After about a year, a second tester joined the team.

  • A couple months later, I got the feeling that they goad each other and they get worked up about bugs and missing functionality when working together. Stuff like "yeah, and then I did X and Y and of course, the software blew up" or "oh well, I reported the bugs months ago, they should finally start fixing it".

I think it is not the testers themselves, it is more of a team dynamic because gossiping is a powerful bonding tool. Of course they are having a point - after all there are bugs in the software - but this is somewhat "normal", especially for a newly emerging startup and it does not make sense to gossip all the time.

However, I would like to:

  • try to limit the agitation because it goes nowhere.

  • thus, prevent erosion of their standpoint when reporting (somebody might just think "Oh well, here comes negative nancy again" and dismiss the valuable feedback).

  • prevent frustration of developers who regularly become defensive.

  • prevent negativity to leak in the company culture in general.

Improve this question
6
  • This question seems to be about how to communicate software failures in a professional way. I think this is more of a topic for sqa.stackexchange.com.
    – Philipp
    Jul 3, 2019 at 8:36
  • 5
    What's the integration like with the developers? Do the QAs sit with/work closely with them? Are QAs involved throughout the entire cycle of development, or just at the end for testing? I find involving QAs at the requirements level then having QAs and devs discuss the work together (and what will be tested) before dev starts can be a big help.
    – delinear
    Jul 3, 2019 at 8:38
  • 2
    Also, the comment "oh well, I reported the bugs months ago, they should finally start fixing it" implies that your method of bugtracking is either inefficient or not transparent enough to everyone on the team. But that's also a topic for sqa.stackexchange.com
    – Philipp
    Jul 3, 2019 at 8:42
  • 1
    Well, QA's role is to see everything in black. I've always been kept far from the developpers, for this obvious reason. I shall not be enthousiastic about the product, I shall be anthousiastic about finding bugs. End be proud of each good catch.
    – gazzz0x2z
    Jul 3, 2019 at 10:25
  • I would argue that it is good that they are passionate about their reported bugs. It is also great that they can anticipate the exceptions, cf. "of course, the software blew up." You may want to have them in the team when designing the pass criteria with their ideas, that way your product is created with robustness in mind.
    – user3819867
    Jul 3, 2019 at 15:25

4 Answers 4

Reset to default
9

It sounds like your testers work in a separate "silo" to your developers, have little to no control over how features are developed, and also little to no control over whether or not a feature is considered "finished"

All of those will affect their morale, and their effectiveness at being the gatekeepers that prevent your users from seeing bugs.

Needless to say that is hard to find a balance between adding new features which customers pay for and keeping things stable

If your testers were involved earlier then this wouldn't and shouldn't be "needless to say". Ideally your testers should be working with your developers, and writing automated tests that can be repeated during every build.

They should also be involved at the start of the process, and not the end when the developers have "finished". The process should not even be considered "finished" until the testers have tested it, confirmed that it works as expected, and preferably have automated tests that can be re-run at will to confirm that everything still works.

The common counter argument to all this is "that all takes too much time". The counter argument to that counter argument is - look at all the time you're spending keeping things stable currently. If it's too much then it's time to invest in some real, early, QA.

Your testers are professionals who want to do good work, and their morale and positivity will improve when they are able to.

Improve this answer
3
  • Yes, our implementation is only considered finished after testing. However, indeed the testers are not involved in the beginning of the process - partly because as working students, they are only available around 16 hours per week each. After consultation with them in the early days, we jointly agreed that in the current situation, this would clog the dev process.
    – Ruby
    Jul 13, 2019 at 7:50
  • For me, this is the main takeaway here - QA is part of the process and not the last step in a process. However, its a tough one as they are not always available.
    – Ruby
    Jul 13, 2019 at 7:52
  • @Ruby if they're students then they quite possibly don't understand themselves how much better their job will be if they get involved and start raising questions in the planning stage. The "clog the dev process" thing is the exact sort of argument I referred to in my answer :)
    – Player One
    Jul 13, 2019 at 23:51
2

This isn't meant to be a full faceted answer - just one covering an angle that hasn't been discussed all that much:

Human beings are naturally standoffish to anyone classified as "other".

The Robber's Cave experiment is a great illustration of this. They got a bunch of 12 year olds and put them into two groups - with each group not knowing about the existence of the other. They encouraged the groups to bond amongst themselves, and then exposed the groups to each other. And that was all it took - immediately the groups were name-calling one another, viewing their fellow group-mates as kin and the opposite group's members as "other".

I bet your QA group's personnel are pretty isolated from the Dev group's personnel - they don't have a whole lot of interaction or exposure to one another. So you might actually fix this problem by restructuring things a bit. Some possibilities:

  • Have personnel do occasional stints on the other side of the fence
  • Arrange projects where 1-2 devs and 1-2 QA people are colocated for the duration of the project (get them talking/working with one another instead of their usual coworkers)
  • Arrange group activities/games/whatever, and make sure to break people into teams by something other than department.
Improve this answer
0

Lack of systematic process appears to be a root cause

From your description, it appears that what's causing the negativity is the lack of a systematic process to manage the project. This is turn may be causing the employees to lose motivation.

What may help is to try introducing some structure in the work. Have well defined specs, use a bug database, make use of collaboration tools to make team communication more streamlined and transparent.

You don't need to spend too much time on figuring out the perfect process. Start gradually, making sure that each of the above point serve their purpose.

Refereeing to the popular Joel Test could give you good pointers to get started.

A team loses motivation when their efforts don't bear fruit after an extended period of putting in work. The purpose of this exercise is to make sure the team start seeing their hard work coming to fruition. After systematizing things, this may be slow in the beginning. But once the team has gained trust, things will spiral towards positivity.

Improve this answer
0

I will not go into the full theories on how to run a business and how to run a project. I will leave that as a homework to you.

Below I will provide just-the-minimum needed for you to fix the presented issue. The other answers also have good insights into the the topic.

Have an efficient project manager. They must make decisions about what will be implemented for each release, and take responsibility for those decisions.

They will decide which bugs are critical, and which can be fixed in a later release. They will prioritize the requirements / changes / features, in order to give the development team enough time to implement them without "implementing" bugs also.

They will create the balance between the implementation team and the test team.

Install / implement a change management system (known under many names, including bug tracker etc.). All changes requested must be saved there: new feature requests, bugs, wishes, ... Based on that list, the PM will decide together with the teams (development and test) what can be and must be implemented for each release.

When everybody is on the same page from the beginning, there is no reason for conflict later, when the sh*t hits the fan.

The testers will only test what was implemented / changed / fixed. No need for frustration regarding the bugs not being fixed. If it is known that a bug was not fixed, the test-cases for it shall not be executed.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .