Dru
En respuesta a una pregunta en el foro, Blizzard explica cómo planifica las pruebas de jefes de banda en el PTR.
Blizzard explica cómo planifica las pruebas de jefes de banda en el PTR
Este es un comentario muy acertado y algo de lo que ya hemos hablado anteriormente.
Para entender el problema, tenemos que dar un paso atrás y hablar de cómo hacemos las pruebas PTR:
- La semana anterior a una prueba de RPP, confirmamos qué jefes están listos para la prueba y pedimos a sus diseñadores que los tengan en un estado estable y comprobable para el final de la semana.
- El fin de semana anterior a una prueba de RPP, generamos una nueva versión para utilizarla en las pruebas.
- Aunque es de esperar que se produzcan errores en la RPP, queremos garantizar un nivel básico de estabilidad para no hacer perder el tiempo a los jugadores. Aquí es donde entra en juego el departamento de control de calidad, que hace un gran trabajo para encontrar cualquier error que pueda interferir con las pruebas.
- Una vez que hayamos solucionado los problemas más importantes y tengamos el visto bueno del departamento de control de calidad, pondremos la nueva versión en el RPP y publicaremos nuestro anuncio para las pruebas de incursión.
El reto está en esta última parte: a veces los problemas que encontramos son tan graves que pueden tardar varios días en solucionarse o pueden impedir las pruebas de raid esa semana por completo. Un ejemplo podría ser algo como: «hay agujeros invisibles en el suelo por todo el raid». Por eso esperamos hasta estar seguros de que se va a realizar una prueba antes de anunciarla.
Dicho esto, sabemos lo que «queremos» probar al comienzo de la semana, y podríamos anunciarlo antes, pero esto conllevaría un riesgo significativo de que los planes se cambien o se cancelen más adelante en la semana. La pregunta es entonces: «¿Estaría bien anunciar una prueba antes, hacer que los jugadores planifiquen su asistencia y cancelarla más tarde si descubrimos un problema que impida la prueba?».
Me gustaría discutirlo con el equipo antes de prometer cualquier cambio en la forma de hacer las cosas, pero tengo curiosidad por conocer vuestra opinión al respecto basándome en la información anterior.
This is super fair feedback and something we’ve talked about previously.
To understand the problem, we need to take a step back and talk about how we do PTR testing:
- The week prior to a PTR test, we confirm which bosses are ready for testing and ask their designers to have them in a stable & testable state by the end of the week.
- The weekend before a PTR test, we generate a new build to use for testing.
- While bugs are to be expected on PTR, we want to ensure a baseline level of stability so that we’re not wasting players’ time. This is where QA comes in and they do a great job finding any bugs that could interfere with testing.
- Once we’ve fixed any major issues & have QA’s blessing, we put the new build on the PTR and post our announcement for raid testing.
The challenge comes in with that last part – sometimes the problems we find are serious enough that they can take multiple days to fix or might prevent raid testing that week entirely. An example might be something like: “there are invisible holes in the floor all over the raid”. This is why we wait until we’re pretty certain a test will happen before announcing it.
That being said we do know what we “want to” test by the start of the week, and we could announce that sooner, but it’d come with a significant risk of plans being changed or canceled later in the week. The question then becomes: “would it be OK to announce a test earlier, have players plan to attend, and then cancel it later if we discover a problem that would prevent testing?”
I’d want to discuss with the team before promising any changes to how we do things, but I’m curious to hear your thoughts on this based on the information above.
