@hoboadam_psn said in MLBTS22 : QA is a total failure:
@suntlacrimae50_psn said in MLBTS22 : QA is a total failure:
@calikat68_xbl said in MLBTS22 : QA is a total failure:
@hoboadam_psn said in MLBTS22 : QA is a total failure:
@calikat68_xbl said in MLBTS22 : QA is a total failure:
@luvmyxbox_xbl said in MLBTS22 : QA is a total failure:
Whoever was in charge of QA for MLBTS 22 did a very bad job.
First of all, so many crashes in 22. 21 the game never crashed on me once. 22 is a plethora of crashes in all modes.
Another example : in DD, when I go into choose uniform, the uniform I chose doesn't display on the player - home or away - 21 did not have this problem. You can argue what's the big deal, it's insignificant. I can see that point of view. But the little things add up and show how sloppy this game is.
I can list countless other things but I don't understand how 21 was so tight when it came to QA and how 22 fails miserably in this department. Did they change QA teams for 22? I would be really embarrassed if I was part of that team.
Such a terrible take. QA does catch these issues, however, QA is NOT the team who fixes them. Stop blaming QA and push the issue onto the dev team, who are ultimately responsible.
Sorry, but no matter what a dev team does, QA is the last line of defense here before a patch hits production.
What SDS really needs is a UAT team in production that can test stuff for 24 hours before it hits as a patch. (UAT = User Acceptance Testing)
Devs know how stuff should work. QA should have standard things to look out for, especially for previously "fixed" items. I. Addition, QA should have baseline standards that are tested regardless of what they are testing. Examples include, menu navigation, market transactions, advancing a mini season playoff series, BR rewards etc. UAT should target specific changes. QA should make sure everything works every time.
Now some are going to start saying I don't know what I'm talking about. I've been part of doing DEV, QA, UAT and using stuff in PROD for 15+ years in finance. Nothing goes from DEV to PROD without QA and UAT.
DEV knows how to fix stuff. But you can't just expect an end user to be able to give a Dev the solution. During the QA process, you have steps to check, and you must select pass/fail in the QA reporting environment.
I've merged data and systems for Dean Witter, Discover, Morgan Stanley, Smith Barney, PFPC, DST, First data etc etc etc.
Game companies should have similar QA processes. Most do that I've played. This game, not so much.
Not only do you not understand how the software development life cycle works, you don’t understand how QA works either. I absolutely do not believe you’ve managed any data systems, work in any software development shop, or know how software especially games are shipped. Sit down, you’ll look a lot less dumb. I am an engineer and have worked on enterprise level applications.
This is hilarious. You two swinging [censored] at each other in a video game forum. “I am this” and “I am that”...lol.
Ooooooh! What are the chances you’re BOTH lying??? That would be classic.
But please, continue.
You have a point. This individual will never understand what I've done. I don't generally like painting a broad stroke, but engineers can be like that sometimes. Always up in their own silo and never required to work across organizations. Experts in their small microcosm for sure, but never part of the big picture. It's what makes them excellent engineers. That's to be commended.
You do know there's UAT for diaper absorption in addition to EVERY single system touched in financial services. There's stuff outside of coding that gets it.
QA is looking for production defects. UAT is testing done so things can be signed off on as "working as intended". These are generalizations, but are universal across everything from widgets, to software to... Diapers.
Enjoy your day. I suggest that he/she/they block me though. I actually apply my life experiences in an effort to help folks on the forum instead of telling people what I think they don't know.
You have absolutely NO understanding of how software is built, especially gaming software. You do not understand the process of QA for software.
A few things about the testing and testing methodologies - there is no standardized method for game testing. Most strategies and/or methodologies are created and developed in-house and based on a general industry approach.
Functionality Testing
It is the most common test, that does not require vast technical knowledge. Functionality testers usually look for common problems within the game itself or its user interface, such as stability issues and game mechanic issues.
Beta Testing
This test is performed during the beta stage of game development. Frequently, this is the first publicly available version of a game. Public betas are effective as the game can be tested on different platforms, languages, and timezones to find bugs that testers did not.
Load Testing
This test requires a large group of testers or software that emulate heavy activity. This test measures the capability of an app to function correctly under load. Load testing can also be performed to measure the capacity limits of a server, such as the number of players on an MMO server, the number of the mobs active on the screen, and the number of threads running in a particular program.
Multiplayer Testing
This test is commonly done for PC games. The testers ensure that all connectivity methods (modem, LAN, Internet) are working.
Soak Testing
This test refers to the context of video games. It involves omitting the game running for prolonged periods of time in various modes of operation, such as idling, pausing, and at the title screen. This testing requires no user interaction beyond the initial setup and is usually managed by lead testers.
Localization Testing
This is when the game has been translated. The translation of the languages must be accurate and indistinguishable for native speakers. The game testers must ensure that the game is localized into the languages of the countries where the game would be released.
Compliance Testing
To conduct compliance testing, exclusive documents released to developers and publishers under confidential agreements must be provided. They are not available for the general public to review although familiarity with these standards is considered a valuable skill as a tester. Testers must report objectionable content that may be inappropriate for the desired rating. Similar to licensing process, games that did not receive the desired rating must be re-edited, retested, and resubmitted at an additional cost.
Compatibility Testing
Many games can now be cross-ported to other devices such as consoles to PC and handheld devices to mobile phones. The compatibility test is a step in checking whether a game title could run on a specific device without any problem.
User Interface (UI) Testing
This test refers to the visual appearance of the game. It focuses on UI testing for both the graphical elements and contents. It also covers all localization elements that the game has.
Areas of focus during the QA (testing) phase in alpha/beta
Packaging – Ease to download, Install, and Register
Navigation – Menu, Options, Help, Action Key Configuration/gamepad
Visual appearance – Characters, Texture, Terrain, Primary objects, Background objects, Frame
Animation – Sound effect, Music/BGM
Camera and camera angle – Zoom in/out, Replay
Game flow or logic structure – Levels of difficulty, Conditions to advance to next levels
Player attributes (aspects such as avatar, player information, etc.)
Scoring – Saving the levels /scores
Scenes
Multiplayer feature
CPU utilized
Usability / User experience
User interactions and responsiveness
AI logic
Security
The senior QA engineer(s) will conduct an analysis of functional and non-functional software requirements to get an understanding of the project’s scope and software specifics to outline a path for establishing the QA process.
The engineer(s) will then do a QA process (re)design which will establish the traceability matrix, potential risks (e.g. tight timelines, changing requirements, etc.), and create a risk mitigation plan, Planning regular and systematic design reviews to spot logical errors and start creating a test plan earlier, and outlining the test strategy and test plan.
The ACTUAL QA testing process will look something like
Designing test scenarios and test cases.
Setting up a test environment and preparing test data.
Writing test scripts for automated testing.
Executing manual and automated tests.
Incorporating automated tests into CI/CD pipeline to speed up the testing process.
Reporting on the detected issues in the preferred defect tracking system and reporting results of the executed tests on the agreed schedule.
Conducting regression testing to validate that no related functionality has been broken within the new development iteration.
Conducting release testing.
This is just a high-level look at how QA is done. Bugs are always going to be an issue for software, especially games. Games being released with problems are not immediately a result because QA engineers are lazy, incompetent, or don't care.
Bugs often find their way into production, especially for games, because the games are under incredibly tight release schedules, engineering teams are understaffed, engineering teams are overworked, and both the business and consumers have just accepted it's okay to release software before it's finished.
You still don't know what UAT means when it comes to software developing, testing, and releasing.
