Titan Two Beta Testing Goals & Expectations

[UK_Wildcats]

Jefferson - I think that it would be great if you outlined the goals of the beta test and set expectations. Here are some examples.

PURPOSE: Beta testing is to provide a more rigorous and larger user base of testing in order to identify issues, problems and improvements prior to the full product launch. A good beta test WILL find many problems.

GOALS:

HARDWARE:
1. Validate the standard/normal functions (i.e. basic scripts, gamepacks, etc.)
2. Validate the dual controller authentication support works with various consoles and controllers (PS4 with DS4 and Xbox Elite)
3. Validate the headset audio support is working across multiple consoles and controllers
4. Identify any problems, issues and possible improvements for full launch

SOFTWARE (Gtuner):
1. Validate the basic core functions (i.e. script development, compile, programming)
2. Validate plug-in functions
3. Identify any problems, issues and possible improvements for full launch

SOFTWARE (Scripts):
1. As part of the beta, users will be developing scripts for various games and testing them

EXPECTATIONS:
1. With every beta, there will be problems and issues which is the reason for a beta
2. DETAILED descriptions of issues, problems, settings, circumstances, etc. ARE REQUIRED (no "it doesn't work)
3. It may often take several updates and tries in order to resolve issues
4. Beta testing can and will be frustrating at times
5. It may often take time to resolve each issue

Beta testers must have patience and understand that there will be issues. If you do not have patience or do not like dealing with problems, you should avoid being a beta tester.

[bonefisher]

Totally agree!

[The_Rabid_Taco]

Also agree! Too many times I've seen the "it doesn't work" with no more detail than that. Quite possibly it may be good to have a form that people could fill out and attach for bugs. I'm not sure what would be the best way to do that, but I'm sure we could come up with something.

[antithesis]

I'm here for the Xim4 support, so you might want to add that to the list. There are plenty of folks interested in the Titan Two over at Xim4 and I'm the middle-man between here and there.

I've got all consoles and a duck's nuts setup with multiple USB hubs and switches and a gazillion peripherals (arcade sticks, wheels, flight controllers, foot pedals, motion controls, mice, keyboards, headphones, mics etc), so I can test the piss and pickhandles out of the Titan Two. If there's one setup that's gonna test this thing, it's mine.

That and the fancy new scripting engine. Can't wait to sink my teeth into it. But mostly interested in making sure Titan Two and Xim 4 play friendly.

[Valant]

I'll can test XB1 and XB360's capability with everything that I possibly can.

Don't need to type a paragraph about what I can do, I can save that for my beta experiences.

I agree with Rabid, a form would be a good organized way to report bugs, then we can also discuss everything in the forum as well.

[pablosscripts]

The main "happy path" scenarios are likely going to be 99.99% ok.

Where the testing needs to be concentrated is on the fringe scenarios - crazy setups with all sorts of peripherals that aren't used by 90% of people.

Your Stinkyboards. Your XIM's. Your random-brand-mice. This is the sort of ground that J2Kbr won't be able to cover by himself.

[pablosscripts]

2. DETAILED descriptions of issues, problems, settings, circumstances, etc. ARE REQUIRED (no "it doesn't work)

Having run a software testing team for many years, this is the basic template that I would expect all my testers to use. Every company I have worked for has used a variation of this format for logging bugs:

Priority: 1-5*

Environment: XB1, custom Scuf controller (x model), Gtuner installed on Windows 1995 CE

Steps to replicate:
1. I did x and y
2. Then z
3. and so on...

Expected outcome:
The X button should have done...

Actual outcome:
Except the LED did...



*******************

Priority definitions:

1) Critical and will prevent further beta testing (this should be very rare and is often abused - realistically very few things are true P1's)
2) Very important - you can continue beta testing but this still needs to be addressed before release
3) Important to fix, but there are work arounds, OR very important but affects a very, very small number of people
4) Nice to have, will fix when time permits
5) Cosmetic issues


J2Kbr - do you have a plan on how bugs should be logged? Do you have a bug tracking system or are you just going to use this forum? If it's the former you should probably establish a triaging process. This is what we generally do - everyone logs bugs into a single repository, then a small triage team (e.g. Bonefisher and/or other experienced people) would review it and weed out the duplicates, the user errors, the crap, and funnel you the genuine issues. Otherwise you may be overwhelmed.

There are a bunch of open source options:

https://opensource.com/business/16/2/to ... king-tools

Let me know if you'd like assistance with setting this up. Even if I'm not part of the beta I would be happy to help as I've spent years working in software dev / testing and running these sorts of things.

[J2Kbr]

This is the most important message.

Beta testers must have patience and understand that there will be issues. If you do not have patience or do not like dealing with problems, you should avoid being a beta tester.

Thank you UK_Wildcats_Fans and pablogroup for the initiative in explain the expectations and how bug reports should be detailed.

@pablogroup. Initially I was thinking in just use the forums for bug reports. But I can see the advantages of having a bug tracking system. I will be looking to the available options. Do you know any system that does not require be hosted on our server? This would be more appropriated at this moment, as every time I install a new system on the server I get very paranoid if the new system is secure and will not expose the server to attacks such arbitrary file upload/download. So, every time I went checking many php files, bug and security reports on internet, etc to have peace of mind. lol

-- to everybody --

What can you expect on the beta period:

1) An usable device, firmware and software;
2) Initially only hard wired connections for consoles and controllers (the BT module will be available yet during the beat period);
3) Working and tested on PS4, XB1, PS3, XB360 consoles;
4) Working and tested with all official controllers;
5) I have not performed any test with third-party controllers, so you can expect many of them to not work until I add the correspondent vid:pid on the firmware.

What we expect from who is participating on the beta period:

1) Be willing to give feedback on the functionalities of the device and software;
2) Improvement suggestions;
3) Bug reporting;
4) Long period testing of the implemented capabilities. (eg. the headset support was only tested for short periods of time, so we need confirmation if this feature is working as expected in long periods of usage)

Understand what is the Titan Two, in order of importance:

1st) Core functionality: A device that enables control/change the controller data stream via scripts;
2nd) Crossover gameplay: use any compatible controller on any supported console;
3rd) Input translator device: to enable keyboard, mouse, steering wheels, rock band gear, etc to be used on consoles.

[titanone_fan]

Curious as to how beta testers are going to be determined. I'd love to be able to test Xbox one/chatpad/headset but I respect seniority in the process.

[J2Kbr]

The most important aspect is be engaged. this will be a determining fact to select the beta tested users.