As per usual, this will be a crazy long post. There's no real TL;DR.

For those who don't know me and for the sake of clarifying how much I know what I'm talking about : I'm a dev in a pretty big company, I've had experience in smaller companies too. Did project managment / scrum mastering at some point, and most importantly did a fair bit of QA and automated testing, as well as the usual unit testing. I had grey hair at 25.

Now today I'll try to accomplish something rather difficult which is teach people who usually don't like to listen or be told how to do stuff, and I'm talking about a big chunk of you guys. Not you specifically, but just gamers in general. Your skillset is good, but you lack some experience and I'll try to share some insight in how you could improve how you provide feedbacks to game devs.

You all know the trend is playing unfinished games and we, as gamers, have a duty to give feedback and help the game become what it will. Not what we want. Really when you're buying a beta, you're paying to get the opportunity to work on a project you think you'll particularly enjoy. If you get to have fun in the process that's a bonus. A lot of people seem to confuse a beta with just a fancy early access, "the game is finished and I just get to play first because I can afford it". It's not, and you already knew that.

If you have never used the report button to submit an issue, or if you only used it a couple of times, then this post if for you. Let's assume you played 10 hours this week and submitted zero bugs, that would probably mean that you either tested very poorly or that the game is 99.95% finished. We also all know the answer to that one.

One thing to get out of the way : it's okay to just play the game. I personally wouldn't and find it a bit sad/annoying, but on a technical level, it's okay. You're still being part of some tests and fullfil a part of your duty, but you could be doing a lot more. Being present and playing allows to do stability testing and generate data on how the game performs, so, playing is very, very important. Submitting good bug reports will make the game better much faster. And it feels good.

What is the easiest to do ?

Well, write feedback. Just playing the game without finding any bug does not mean there is nothing to say. This is the most frequent kind of information we get on this subreddit, or in gaming in genral. It's basically sharing your opinion and experience. How can we do that efficiently ?

​

• Be a little emotional : Say if you had fun, if you were frustrated, if it was scary, thrilling. Share how you felt.
• Don't be too emotional : Anger and frustration can happen in the moment, and saying you felt that way is important.

However, writing angrily and forwarding that anger is only gonna clutter your text and influence your reader (and yourself) badly. It's very difficult to read feedback from an angry person. "This fucking shit game is so fucking broken and laggy fuck that shit im never playing it again" really doesn't translate as well as "I had a lot of issues with lag and it was unplayable during the first 10 minutes of every interchange raid. Stutters and packetloss mostly, ping looked fine, FPS was lower than the usual 65, I was at about 50 inside and 45 outside".

​

• Be factual : say what happened and what didn't, or what you would have expected. A very common one I would personally write (but seemed to be intended) is "Used an MS2000 marker for a quest, used left click to plant it and it fired my gun, I didn't expect to have to press F".

This one is good feedback because it shows the dev that his decision, while not a bug, confused you. If it's intended they'll keep it because "player has to get used to it", but if it was an arbitrary choice and there is no reason behind it, then they can change it to left click instead of F to avoid confusion. It's their decision, their knowledge/investigation, you're just sharing how you experienced it, and saying it was confusing is valid feedback.

​

• Avoid suggesting solutions : It's possible to give great suggestions on stuff you would like to see in the game, and that you should *definitely* keep doing. But when you see something you think is wrong : first, you have no idea if it's wrong or not, it might be intended. And second, you have zero vision on how the game actually works under the hood, what is planned, and why anything is made how it's made, if its just partially done for later. That means you really do not have the tools to say how things should be, because you don't know how they are now, and suggesting a change in that environment is just not gonna work, believe me.

This is a very, very common one that is unecessary and bad about 80% of the time. Unless you're in the BSG team, it's pretty much impossible to give good suggestions on how to fix a problem.

An analogy would be like you putting your car in the repair shop because it completely stopped for apparently no reason and you just go to the mechanic saying "Really the car should have 2 or 4 more wheels". Well, you know, maybe the car stopped because it lost a wheel so we could add one, you could be partially right. But maybe it could've been something else. You might think this is a dumb analogy, but from experience, believe me, I have heard stuff that is at least that stupid from smart people who thought they were giving constructive feedback. And from their perspective it makes sense, because they have zero knowledge or vision of the inside of the project. Please, assume you're dumb when giving feedback.

Bad example : Saying stuff like "Man this 20% damage reduction buff is stupid, it should be removed". It's too emotional, it doesn't provide any actual feedback, just an opinion, and it's suggesting stuff for no reason. I call this "religious feedback". You don't like it because you don't like it, and its fine not to like it. But this doesn't help the game devs or the game itself in any way. None.

Good example : " The new 20% damage reduction buff makes it so most ammo don't one shot in the head anymore." It's factual, no emotion, and say what actually changed that might have been overlooked. With that information, the dev can make an informed decision. Should they reduce the % ? Exclude the head ? Remove the buff altogether ? Add a significant debuff ? Change duration ? Increase the prices or rarity ? No fucking idea. Not my job, don't know, don't care. I'm not skilled nor informed enough to provide that answer to you and most of us aren't either.

There are DOZENS of ways to influence the rules of the game, and we, as testers, should not tell those responsible which to choose. We should instead provide the data they can't have themselves, because we are thousands of people and we can perform an enormous amount of testing, then share our data. They, however, are the profesionnals devs and are damn good at it. Im sure you can relate whoever you are, that if someone who has no idea how to do your job would start to tell you how to do your job, it would most likely be annoying (which is emotional and irrelevant), but it would also certainly be completely wrong. Please don't assume that when the roles are reversed so are the results.

A very good way to illustrate how much we actually don't know how the game works is how the new bug appears. An obvious one is "We completely changed how scav AI works" and now you see them teleport and go through walls. Okay so this one you could assume that the new changes made that regression in scav behaviour, and it'll probably be right. But if you can make that assumption, the dev will probably be able to make it too. Don't bother making it, if it's right it means it's easy to find out and they will. If it's wrong, it's cluttering at best, and misleading at worst.

Side story here : I've personally felt in that trap of a tester saying "it's probably an authentication issue" when really the dude was using an unsupported language, which lead to an error in the login that was mistaken as a wrong password/login, which he, has a tester, thought would come from the server. But this fucker didn't say he had switched to fucking turkish language/keyboard and told me the error came from the server because he thought he knew. Well, he didn't, and neither did I. And he assumed I knew he was in turkish because he had made another report for turkish language the day before. Assumptions are the root of all evil. For every report, every feedback, don't assume anything. Write the complete story.

Now a more difficult and relevant bug would be the fact that we couldn't fold/unfold stocks if they had a recoil pad on it. This one can be really anything, and no one here would try to guess the cause, because it's probably too deep and technical. No one would write "oi thats fucked i can't fold my stock because you added that shitty grenade launcher". So why would you write "Oi thats fucked the scavs teleport why did you have to change the AI" ? Even is one is probably closer to the truth that the other, it's not your role to guess and investigate that far. Your role is to play and report. So say stuff like "Can't fold/unfold stock on AKSU", and someone else will probably say "can't fold/unfold stock on SVD", and then someone will maybe notice the recoil pad thing, and someone else will notice it happens on all weapons, and with all reports together, they'll have the information. Make yourself strong by numbers, because that's where our strength is as testers.

• Remove the fluff : Stuff like "It's bad", "It's shit", "Don't do that", "No."(notice the anger dot), "What a dumbshit idea." isn't helpful to anyone. I didn't include this in the "emotions" part that should be removed because you can disagree with something and be polite, and that's okay. But remove anything that is not useful, and it's difficult to define useful. If your wording does not help reproduce the issue, find the issue, or understand what happened, then it's probably unecessary. The guy reading it will probably have another hundred of tickets to read and it has to be brief, to the point and as clear as possible.
• Be complete: For starters, assume that the person who you're talking to has no idea what you're talking about. Because really, they haven't been in your head for the last 30 minutes. They need a TON of context.

They work on the same game that you see, but also on many, many different layers of the game that you will never see. A good analogy would be running a shop. Theres the shop, the shelves, and maybe people realize there's the register. But also there's inventory, the reserve, managing deliveries, supply/demand, holidays with more or less people, the amount of cash you'll have to give in a day vs what you'll be given, and probably much more.

I've read a lot of "hey man your update doesn't work." Well, shit, that's bad isn't it? Would you care to give a little fucking context on what isn't actually working? 😀 Now, where do I start? Is it the flux capacitor or the quantum drive that's giving you an issue? How do I know? I don't. When you write feedback, provide context, say what you were doing, what you were trying to achieve, how you did it, what happened, and what you expected would happen. That's really top tier reporting there.

Bad report example : The game crashed. or "The game crashed when I left the game." That's short, without emotion, factual, but it's vastly incomplete.

Great report example : "I was leaving the game using ALT-F4 from the flea market window, with the 'Add Offer' menu still open, and windows said the process EFT.exe terminated", that way the dev can try and reproduce it the way you did it, he can see what machine you were running in the logs, and can also understand that it's a windows error that was shown and not a BSG error message which is very different (means it's probably unhandled).

• Provide footage when possible/relevant. Saying "I swear I saw a scav teleport right onto me!" is bad enough, because you're not saying what actually happened in a way that devs can investigate. The best way is to provide a video. Video has no emotions and is 100% factual. It can be analyzed very thouroughly. "Oh, I see it only happens in doorways and when the scav is sprinting". "Oh no, this video shows it happens when there's a big elevation, but the scav was also sprinting" That's the kind of things you would not have thought to say, but the guy who wrote the AI will notice it straight away because he knows how the pathing knows in his game. You job is to describe facts in situations that you think might be wrong. They decide if it was actually wrong, and if so, how/why it happened and how to fix it.

But what else can we do ?

Well, try stuff. That's mostly annoying QA stuff but anything that you can try, you should. What happens if I throw a grenade there. What happens if I put two scopes in a row. What happens if I jump on someone who's sprinting. What happens if I jump on that ledge just at the edge of the map. What happens if I put smoke in front of a light source, do I get to see silhouettes behind the smoke? What if I use thermals/FLIR ? What if I fall from that slope or try to get stuck in that corner then jump like a retard for a full minute (commonly called monkey testing) ? What if I overweight past 100000kg ? What if I press lean left & lean right at the same time? What if I run the game in russian but don't have the language installed on my computer? What if I use accessibility keyboards/tools during the game, can I zoom more? What if I unplug my ethernet cable during loading ? What if I do that, then run straight and kill someone while I'm timed out, then plug the cable back in ? The server seems to always make me move super fast to catch up remotely of what happened locally. Did I get an insta kill that way?

Just try and break the game in general.

Anything you can think of, do it. If it's stupid and nobody thought about it, it'll certainly reveal a bug or an interesting issue. At worst you'll understand a bit more about how the game acts/reacts, at best you'll have a ticket to write. Really our job is to break the game as much as possible, and it's fucking fun to do it. The more it's bugged now, the better it is. Because it is bugged a fuck, everything always is. The key is to find most of it, which happens in most cases, and that way when shipping day arrives, only the very edge-cases bug are left. Hopefully.

Okay, what else can we do ?

Stay informed on various channels. Read the subreddit, read dev posts, read changelogs, read other's people feedback, feel how the community feels and stay in touch with everybody.

If you see a new grenade has been added, you know you'll have to test it. Shoot it through glass, through wooden doors, through metal, in the sky, at your feet, in water, through a scav, with ricochet, with a scope, without scope, at day, at night, during the rain, through smoke… Fuck, I don't know, try to drink it if you can. Do it all, it's new and I guarantee you if it's new, its bugged.

​

Alright, if you've read all that I hoped you learned a thing or two, if not, well, now is your time to put your skills to use and write it factually and without emotions 😀

I'll leave on a really nice old tweet that sums up the life pretty well. You can test as much as you want, as smart as you want, you'll always forget that one thing. For me, it was the turkish keyboard.

​

https://preview.redd.it/aiwx4tm2icf51.png?width=747&format=png&auto=webp&s=6af29b777c943f4e0ce1ee796f45a4b6b76244f4