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.
Great answer!
Anyone that has ever been part of a decent software development team would agree with you.
I guess the product owner somehow went over the QA team/process due to time/budget constraint.
I know, I know, ambitious ProductOwner rushing things to production against Dev & QA recommendations is something totally new and unheard of in Software development.
Let's hope they'll be able to fix everything as soon as possible!!
-
The game works just fine for me. I haven’t encountered any issues other than the network error once in awhile.
-
@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.
-
@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.
My pension and port authority ID says otherwise. I spent 3 weeks building systems from scratch at harbor side after 9/11 that integrated with Morgan Stanley and Van Kampen mainframe systems. Also sat on the BDAC for Mutual Funds and 529 Plans.
Walked from the WTC to Varick Street on 9/11 and was one of 2 people with credentials to manually cancel trades that day since our systems remained open, and slimy brokers tried to exchange out of ILAF when the market never opened. Also helped build the data center in West Consohoken.
Broker needs to cut a check out of a brokerage account? Yeah, I helped build that. Customers want to cut their own check using online account access? Yeah, helped build, QA and UAT that too. When a statement goes out each month showing securities you own, you realize there's a team that has to get sign off that their products are displaying and are priced right. Yeah, that was my team too.
Just one example of 15 years of front and back end integration I've touched with my own hands on a keyboard.
QA failed this year. UAT doesn't exist.
I'm NOT an engineer. Never claimed to be. I do know data though and the code with how it's stored, and then translated and sent to and from end user screens to data centers. Left MSSB over 9 years ago. I'm an old timer as far as this stuff goes.
Enjoy your overnight.
-
QA didn’t fail. You don’t understand how software is built and shipped, especially games. You also don’t know what user acceptance testing (UAT) is either.
-
@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.
-
@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.
-
@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.
As for you, last thing I have, is time to lie on the internet. My generation doesn't do that. There's enough people here that know me outside of TSN that know I don't shovel it.
-
@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
SecurityThe 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.
-
@calikat68_xbl said in MLBTS22 : QA is a total failure:
@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
SecurityThe 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.
Nice copy and paste from your job. I appreciate your passion. I'm 9 years removed from the work I did, so unfortunately I can't reciprocate.
What you list above is very similar to what's done in financial services. Biggest difference being that SME's from product divisions are responsible for UAT and sign off.
You do realize that you are agreeing with me. 99% of the people here, really don't care. You know what you know, and I know what I know. Neither one of us are wrong. Maybe you'll see that one day. Maybe you won't.
Difference is once again, I try to help people understand the process. Of course stuff gets lost in translation. I'm not telling you that YOU don't know what you are talking about. YOU are telling ME though that I don't. That's pompous, arrogant and unfortunate.
I apply what I know, to what SDS does or doesn't do. I also try to describe it in layman's terms for the general audience here. QA and UAT isn't a one size fits all, but it's glaringly apparent when it's missing or done poorly.
Enjoy your weekend. Hope you feel better soon cause you are definitely triggered.
There's a lot of value to what you pasted above. Hopefully SDS takes note.
-
@hoboadam_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:
@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
SecurityThe 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.
Nice copy and paste from your job. I appreciate your passion. I'm 9 years removed from the work I did, so unfortunately I can't reciprocate.
What you list above is very similar to what's done in financial services. Biggest difference being that SME's from product divisions are responsible for UAT and sign off.
You do realize that you are agreeing with me. 99% of the people here, really don't care. You know what you know, and I know what I know. Neither one of us are wrong. Maybe you'll see that one day. Maybe you won't.
Difference is once again, I try to help people understand the process. Of course stuff gets lost in translation. I'm not telling you that YOU don't know what you are talking about. YOU are telling ME though that I don't. That's pompous, arrogant and unfortunate.
I apply what I know, to what SDS does or doesn't do. I also try to describe it in layman's terms for the general audience here. QA and UAT isn't a one size fits all, but it's glaringly apparent when it's missing or done poorly.
Enjoy your weekend. Hope you feel better soon cause you are definitely triggered.
There's a lot of value to what you pasted above. Hopefully SDS takes note.
You don't know how software development works. Stop arguing with people who actually do know how software development works. The original take blaming QA for how the product shipped is a bad take. Your babbling about being tech support is just as bad.
At the end of the day, most bugs are the result of limited time to fix or limited resources in getting them fixed. They are NOT the result of QA engineers just being bad at their job.
Your comment about my being triggered just shows what type of person you are. I'm not triggered at all. I've simply pointed out that you're wrong. I've showed you how the process works. SDS doesn't need to take note of what I stated, these are competent engineers, you on the other hand, not so much.
-
@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:
@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
SecurityThe 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.
Nice copy and paste from your job. I appreciate your passion. I'm 9 years removed from the work I did, so unfortunately I can't reciprocate.
What you list above is very similar to what's done in financial services. Biggest difference being that SME's from product divisions are responsible for UAT and sign off.
You do realize that you are agreeing with me. 99% of the people here, really don't care. You know what you know, and I know what I know. Neither one of us are wrong. Maybe you'll see that one day. Maybe you won't.
Difference is once again, I try to help people understand the process. Of course stuff gets lost in translation. I'm not telling you that YOU don't know what you are talking about. YOU are telling ME though that I don't. That's pompous, arrogant and unfortunate.
I apply what I know, to what SDS does or doesn't do. I also try to describe it in layman's terms for the general audience here. QA and UAT isn't a one size fits all, but it's glaringly apparent when it's missing or done poorly.
Enjoy your weekend. Hope you feel better soon cause you are definitely triggered.
There's a lot of value to what you pasted above. Hopefully SDS takes note.
You don't know how software development works. Stop arguing with people who actually do know how software development works. The original take blaming QA for how the product shipped is a bad take. Your babbling about being tech support is just as bad.
At the end of the day, most bugs are the result of limited time to fix or limited resources in getting them fixed. They are NOT the result of QA engineers just being bad at their job.
Your comment about my being triggered just shows what type of person you are. I'm not triggered at all. I've simply pointed out that you're wrong. I've showed you how the process works. SDS doesn't need to take note of what I stated, these are competent engineers, you on the other hand, not so much.
Now THAT'S a bad take.
Once again sparky, you fail to even attempt to be open minded. You're speaking in terms of absolution that you're right, I'm wrong, no middle ground. How miserable. You haven't showed me anything I haven't seen before. You can't even take a compliment without digging in your heels.
You're like a criminal lawyer that's trying to tell a real estate attorney they don't know law. You're response would be that I must think I'm a lawyer because I watch SVU.
There's such a larger world out there. Hopefully you get to experience it one day both professionally and socially.
-
The idea that a bug doesn't get addressed or fixed b/c of QA is laughable on its face. Complete nonsense. Because an issue doesn't get addressed does not mean quality couldn't uncover the problem or even know how to fix it. It implies that development does a cost/benefit analysis and decides the issue isn't pressing enough to spend resources to fix it. QA doesn't allocate development resources; they test and report while the developers take their feedback and make decisions about what is to be addressed.
This has never been esoteric knowledge and game developers have repeatedly affirmed this for decades.
-
@hoboadam_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:
@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
SecurityThe 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.
Nice copy and paste from your job. I appreciate your passion. I'm 9 years removed from the work I did, so unfortunately I can't reciprocate.
What you list above is very similar to what's done in financial services. Biggest difference being that SME's from product divisions are responsible for UAT and sign off.
You do realize that you are agreeing with me. 99% of the people here, really don't care. You know what you know, and I know what I know. Neither one of us are wrong. Maybe you'll see that one day. Maybe you won't.
Difference is once again, I try to help people understand the process. Of course stuff gets lost in translation. I'm not telling you that YOU don't know what you are talking about. YOU are telling ME though that I don't. That's pompous, arrogant and unfortunate.
I apply what I know, to what SDS does or doesn't do. I also try to describe it in layman's terms for the general audience here. QA and UAT isn't a one size fits all, but it's glaringly apparent when it's missing or done poorly.
Enjoy your weekend. Hope you feel better soon cause you are definitely triggered.
There's a lot of value to what you pasted above. Hopefully SDS takes note.
You don't know how software development works. Stop arguing with people who actually do know how software development works. The original take blaming QA for how the product shipped is a bad take. Your babbling about being tech support is just as bad.
At the end of the day, most bugs are the result of limited time to fix or limited resources in getting them fixed. They are NOT the result of QA engineers just being bad at their job.
Your comment about my being triggered just shows what type of person you are. I'm not triggered at all. I've simply pointed out that you're wrong. I've showed you how the process works. SDS doesn't need to take note of what I stated, these are competent engineers, you on the other hand, not so much.
Now THAT'S a bad take.
Once again sparky, you fail to even attempt to be open minded. You're speaking in terms of absolution that you're right, I'm wrong, no middle ground. How miserable. You haven't showed me anything I haven't seen before. You can't even take a compliment without digging in your heels.
You're like a criminal lawyer that's trying to tell a real estate attorney they don't know law. You're response would be that I must think I'm a lawyer because I watch SVU.
There's such a larger world out there. Hopefully you get to experience it one day both professionally and socially.
There's nothing to be open minded about here. Your take is bad, you blaming QA is bad, and then trying to gaslight me just shows what a terrible person you are. I actually do this kind of stuff for a living, unlike you.
"There's such a larger world out there. Hopefully you get to experience it one day both professionally and socially." What is this supposed to mean? Is this some sort of insult? Anyway, you're dumb, you're an [censored], and I'm glad I will never know you, I'd be less for the experience.
-
@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:
@hoboadam_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:
@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
SecurityThe 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.
Nice copy and paste from your job. I appreciate your passion. I'm 9 years removed from the work I did, so unfortunately I can't reciprocate.
What you list above is very similar to what's done in financial services. Biggest difference being that SME's from product divisions are responsible for UAT and sign off.
You do realize that you are agreeing with me. 99% of the people here, really don't care. You know what you know, and I know what I know. Neither one of us are wrong. Maybe you'll see that one day. Maybe you won't.
Difference is once again, I try to help people understand the process. Of course stuff gets lost in translation. I'm not telling you that YOU don't know what you are talking about. YOU are telling ME though that I don't. That's pompous, arrogant and unfortunate.
I apply what I know, to what SDS does or doesn't do. I also try to describe it in layman's terms for the general audience here. QA and UAT isn't a one size fits all, but it's glaringly apparent when it's missing or done poorly.
Enjoy your weekend. Hope you feel better soon cause you are definitely triggered.
There's a lot of value to what you pasted above. Hopefully SDS takes note.
You don't know how software development works. Stop arguing with people who actually do know how software development works. The original take blaming QA for how the product shipped is a bad take. Your babbling about being tech support is just as bad.
At the end of the day, most bugs are the result of limited time to fix or limited resources in getting them fixed. They are NOT the result of QA engineers just being bad at their job.
Your comment about my being triggered just shows what type of person you are. I'm not triggered at all. I've simply pointed out that you're wrong. I've showed you how the process works. SDS doesn't need to take note of what I stated, these are competent engineers, you on the other hand, not so much.
Now THAT'S a bad take.
Once again sparky, you fail to even attempt to be open minded. You're speaking in terms of absolution that you're right, I'm wrong, no middle ground. How miserable. You haven't showed me anything I haven't seen before. You can't even take a compliment without digging in your heels.
You're like a criminal lawyer that's trying to tell a real estate attorney they don't know law. You're response would be that I must think I'm a lawyer because I watch SVU.
There's such a larger world out there. Hopefully you get to experience it one day both professionally and socially.
There's nothing to be open minded about here. Your take is bad, you blaming QA is bad, and then trying to gaslight me just shows what a terrible person you are. I actually do this kind of stuff for a living, unlike you.
"There's such a larger world out there. Hopefully you get to experience it one day both professionally and socially." What is this supposed to mean? Is this some sort of insult? Anyway, you're dumb, you're an [censored], and I'm glad I will never know you, I'd be less for the experience.
Go hit another 256+ HR in RTTS in a single season.
Welcome to the Show and welcome to TSN. Enjoy the ride.
If you think I'm a terrible person, can't wait for you to meet the rest of the folks here. LOL
Funny thing is, your account is 14 days old. In a month or two, we might actually be friends here.
-
A admin locked this topic on
