Contenido
Cuando comienza una tarea, debe justificarse. Debes convencer al desarrollador de que:
- esto es realmente un error;
- necesita ser reparado;
- necesita ser reparado exactamente como dijimos.
Y a veces lees errores (especialmente errores de principiantes) y te preguntas:
- ¿Por qué es esto un error?
Por ejemplo, dice: "Descargue el informe, obtenemos 57.6. Y debería ser - 57.9 ".
Escribir el razonamiento resolverá los problemas:
- Los colegas distraen con las preguntas "¿Por qué es esto un error?", Sacándolo fuera de contexto.
- Un mes después, usted mismo olvidó, pero, de hecho, por qué era un error ...
Ver también:
Por qué es necesaria la justificación en un error , más detalladamente sobre por qué, en general, la justificación.Cientos de probadores principiantes (estudiantes) pasaron por mí. Fue precisamente en sus tareas que comencé a hacer la pregunta "¿Por qué es esto un error?" ... Le preguntas a los chicos y a cambio obtienes "¡Sí, es obvio!". Bueno, de alguna manera no muy =))
A través de un montón de tareas y preguntas, "¿Por qué?" patrones de respuestas comenzaron a surgir. Destaqué los patrones buenos y malos. Quiero hablar sobre ellos
Este artículo es para:
- Probadores principiantes : aprenda a explicar correctamente su punto de vista;
- gerentes de prueba : para dar un enlace a sus Padawans y luego referirse a los antipatrones sin más explicaciones.
1. Antipatrones: mala justificación
1.1. Obviamente
¿Por qué los evaluadores no escriben una justificación en un error? Sí, porque les parece obvio. Y proyectan sus pensamientos sobre todos. Es obvio para mí = es obvio para todos ¿por qué escribir algo?
Pero en realidad esto no es así, porque cada persona está en algún tipo de contexto. Y lo que es obvio para usted no es en absoluto un hecho que sea obvio para otra persona.
Veamos ejemplos simples. Lee la palabra que escribiré a continuación: ¿qué pensaste cuando la leíste? ¿Qué asociaciones me vinieron a la mente?
BLOQUEO
¿Una cerradura de puerta o una gran fortaleza de piedra?
MATRIMONIO
¿Una boda o un iPhone roto?
...
Sí, estos son homónimos. Pero muestran muy claramente el problema "es obvio". Es obvio para usted que el castillo es un castillo, y para mí es un castillo.
Y si escribes en un error:
Resultado
57,6
Resultado esperado
Obviamente, debería haber 57.9
Eso no responde a mi pregunta "¿POR QUÉ?" ¿Qué significa "obvio"? Explícame por favor. No es obvio para mí, de lo contrario no volvería a preguntar. Pero el autor es obvio y piensa que todos también.
Si hablamos de la experiencia de los principiantes, uno de mis alumnos formuló esta idea lo mejor de todo:
"No entendí por qué justificar los errores en absoluto, hasta que leí los errores de otros estudiantes"
Puedes decir durante mucho tiempo que es "obvio" para todos los que son diferentes y no estoy en tu contexto, y mucho más ... Pero el autor de la tarea considerará que simplemente le encuentran fallas, el resto no lo entienden, ¡pero lo está haciendo bien!
Y solo leyendo los errores de otras personas, comienzas a pensar: “Hmmm, ¿por qué piensa eso? Pensé diferente ". Es entonces cuando llega el entendimiento de que su "obvio" no es obvio para todos.
Una vez que entré en el rastreador de errores y vi un error de un estudiante: “Ingresamos el nombre Sharipat, se define como masculino. ¡Y debería ser como una mujer! ¿Por qué debería ser como una mujer? Miro este nombre, bueno, Sharipat y Sharipat, parece un hombre. Yo pregunto:
"¿Por qué decidiste eso?" ¿Por qué mujer?
- Sí, porque mi esposa se llama así!
Y esto al menos ya me explica por qué comenzó la tarea. Cuando probamos aplicaciones, primero probamos datos simples, cosas que sabemos. Probamos nuestro nombre, el nombre de nuestra esposa, hermano, hermana ...
Intentó ingresar el nombre de su esposa y descubrió un error. Y si incluso escribió en el resultado esperado: “El género es femenino, este es un nombre femenino, mi nombre es ese”, entonces al menos la pregunta “¿Por qué comenzaste esta tarea?” Desaparecería.
Por supuesto, tal justificación no es suficiente. Google "nombres inusuales", porque no está prohibido incluso nombrar la mesita de noche de nuestro hijo, pero ¿vale la pena considerar esta palabra como el nombre masculino correcto?
Entonces, aquí es necesario buscar en Google, ¿cuáles son los nombres en general, para localizar el problema, el problema con los nombres rusos? Kazajo? Ucraniano? Pero, ¿debería el sistema poder procesarlos? Y así sucesivamente. Tal vez no sea un error en absoluto ...
Y, sin embargo, "el nombre de mi esposa es así" al menos permite que el autor nos presente en su contexto y explica por qué decidió comenzar la tarea.
Y recuerde, la evidencia puede ser dictada por el contexto. Has estudiado cuidadosamente el gran módulo del sistema, lo sabes todo a fondo. Por lo tanto, es completamente obvio para usted que "este chip debería funcionar AQUÍ ASÍ". Pero si regresa a la tarea en un mes o dos, ya estará trabajando en otro módulo, y recordar por qué será así será más difícil.
Incluso el lápiz más tonto es más afilado que la memoria de Internet más nítida
Cuando comience un error, y el resultado esperado le parezca obvio, deténgase y piense: "¿Por qué lo creo?". Y escriba la respuesta a esta pregunta.
1.2. Lo juro por mamá!
Cuando un estudiante se da cuenta de que escribir nada, "porque es obvio", no falla, pasa a la siguiente etapa de enojo, negación y justificación de errores, que se llama "¡Lo juro por mamá!" Esto es cuando decimos que es correcto, sin explicar por qué.
Es decir, la lógica se parece a esto:
Resultado
57,6
Resultado esperado
57.9 porque es muy correcto
Pero tal razón nuevamente no responde a mi pregunta "¿Pero por qué?". ¿Por qué decidiste que es tan correcto? Todavía no soy un wang o un telépata, y no sé por qué piensas que esto es correcto.
De hecho, esto no es muy diferente de la situación "no escribió nada en absoluto, porque es obvio". Por lo tanto, llamo a esto la segunda etapa: es precisamente en este escenario que los eventos generalmente se desarrollan, primero "obviamente", luego "sí, muy exactamente". Veamos un ejemplo de la vida de los estudiantes:
Pedro y los indios
Nuestro sistema puede desviar nombres por casos. Un estudiante verifica el nombre de Peter. ¿Sabes cómo se inclina? En el caso nominativo, está escrito a través de la letra E, y en todos los demás, a través de E. "Peter, pero Peter".
Y entonces entro en el rastreador de errores y leo dicho error: "Peter se inclina sobre los casos a través de la letra e, pero debería hacerlo a través de e".
Yo pregunto:
"¿Por qué piensas eso?"
- Bueno, es obvio que a través de E es necesario (primera etapa)
"¿Por qué crees que esto es obvio?"
- ¡Pero esto es así de acuerdo con las reglas del idioma ruso!
- ¿Por qué reglas?
- Bueno, ¿debería correr y googlear las reglas del idioma ruso? (segunda etapa, muy bien, créeme)
- SI! Sí, eso es exactamente lo que debes hacer. Porque esta será la razón del error. Porque tal vez tu desarrollador es indio y tú también eres indio. ¡Y no conoces las reglas del idioma ruso! Así que deles un enlace y todas las preguntas desaparecerán de inmediato.
Por supuesto, no hay necesidad de ir al extremo y dar enlaces a los diccionarios cuando se pone un error en un error tipográfico o una coma omitida. Sin embargo, Peter es un ejemplo no trivial, esta es una excepción a la regla. Siempre funciona así, pero para Peter es diferente.
Por lo tanto, aquí el enlace será útil. Especialmente si el desarrollador preguntó: "¿Es realmente así?" Puedes acusarlo de estupidez y analfabetismo y arruinar la relación. Y puede dar un enlace, confirmando suavemente su punto de vista.
Pero bueno, tomemos otro ejemplo, no sobre las reglas del idioma ruso, que son "tan obvias".
Email.rf
A mis alumnos les gusta mucho esta tarea (casi todas las transmisiones la elaboran):
- Estoy intentando registrarme con email.ru y no puedo. Esto es un error!
- por qué?
- ¿Cómo es eso? Vivimos en Rusia, ¡todos tienen tales correos electrónicos!
Le conté este caso en la conferencia DUMP y tenía una sala de audiencia completa. Pedí levantar la mano de aquellos que tienen ese correo electrónico. De 200 personas, tres personas levantaron la mano.
El hecho de que vivamos en Rusia no significa que todos tengan esos correos electrónicos. Bueno, sí, sí ... Y domesticar osos y muñecas de anidación ...
Aquí no hay una relación causal, simplemente es difícil renunciar a su idea. Después de todo, aquí, ¡encontré un error! ¿Cómo puede esto no ser un error? Tan genial Rusia, obviamente! No, no es obvio? Bueno, de todos modos, Rusia, seguramente hay muchos.
Este razonamiento es más como "Soy demasiado vago para buscar en Google, buscar hechos". Cree la palabra ". Cuando no tenemos hechos y pruebas, existe el deseo de ocultar su justificación y escribir "Probablemente, probablemente, seguro ...".
¡Pero estas son palabras de PARADA! Si desea escribirlos, entonces no tiene hechos reales. Así que solo piénsalo bien. ¿Y por qué necesitamos hacer una tarea basada en la imaginación de un probador? ¡Demuestra tu teoría!
¿Y si no hay hechos? Entonces la tarea ni siquiera vale la pena comenzar. Sí, es difícil rechazar el error "tu propio nativo". Pero esto también debe ser capaz de hacerlo.
Email.ru - hechos
¿Cuáles podrían ser los hechos?
En primer lugar, podemos crear nuestro sitio para algunos clientes gubernamentales que deben registrarse en el dominio .rf. Estándar corporativo, no tienen otra opción.
O realmente tenemos muchos de estos clientes, esto se muestra mediante estadísticas. Por ejemplo, hay muchos errores en los registros "intento de registrarse a través de dicho dominio". Y quizás entonces valga la pena hacer esta función. Para no perder clientes potenciales.
Con base en tales hechos, PM (Gerente de Proyecto) toma una decisión si haremos la tarea o no. Y si lo haremos, entonces cuándo. O puede decir: "Bueno, hay errores, y bueno, hay menos del 1% del total de registros, no los haremos"
En lugar del resumen "sí, ¡esas personas definitivamente existen!" dar los HECHOS.
Y cuando establezca la tarea, use el principio 5 por qué. Mientras escribe el resultado esperado, pregúntese: "¿Por qué estoy esperando esto?" La primera respuesta será "Esto es obvio", pero nuevamente haga la pregunta "¿Por qué?". Y si nota que no hay datos, le parece que sí: busque los hechos o discuta la situación con sus colegas.
1.3. Los conejos se ofenden
Si no hay hechos, pero no desea rechazar el error, los estudiantes pasan a la siguiente etapa de ira, negación y justificación de errores ... Presión sobre las emociones:
Intento registrarme con el nombre Cthulhu, pero el sistema no. Debería dar, de lo contrario ... Me ofendió y me fui, ¡y USTED! Perdí un cliente!
Y seguramente todos son iguales a mí, así que has perdido TODOS los clientes, ¡y también han presentado una demanda por insulto y se llevaron todo el dinero!
Y otros autos ...
Por supuesto, cuando personalmente no me gusta algo, me enoja mucho ignorar mi problema. ¿Qué significa "La gente normal no se registra con ese nombre?" ¿Estoy loco? Como quiero, se llama, ¿cómo puedes prohibirme algo?
Y luego se activa la proyección: si no me gusta, ¡a otros usuarios no les gustará! Si no todos, entonces al menos muchos. Por lo tanto, esto definitivamente es un error y debe corregirse. Bueno, o al menos partimos en el marco de la capacitación, si estamos hablando de estudiantes.
Sin embargo, el usuario ofendido es la peor justificación que puede existir. Porque pueden justificar cualquier tontería:
- ¿No hay gato en el principal? Bueno, eso es todo! Me ofendió y se fue! Y tu! Perdí un cliente !!
- ¿Me registré y no me pagaron por ello? Me ofendí y me fui ... ¡Y USTED! Bueno, lo entiendes!
Cualquier cosa puede pasar y ofenderme. El botón es verde, pero quería uno rojo, el sistema no me ofreció pizza como regalo ... Como usuario, puedo ofenderme por cualquier cosa. ¿Pero a quién le importa? De todos modos, no te complacerá, el resentimiento es inevitable. Y amenazar es generalmente lo último.
Todo comenzó con uno de los estudiantes, que acaba de decir esta frase secreta:
- Ah, ¿no quieres registrarte a través del dominio de la Federación Rusa? Y como usuario traté de registrarme, vi esta situación flagrante y ¡IDO! Y tu! Perdí un cliente!
Entonces mi amigo dijo que tales discursos son muy similares a "Los conejos se ofendieron". No sé de dónde sacó esta analogía, pero a todos les gustó.
El estudiante se dio cuenta de que estaba emocionado. Fui a buscar una justificación sin emoción. Y tenemos el nombre antipatrón.
Recuerde una regla simple: ¡
no debe haber emociones en el error!Las emociones son un fenómeno pasajero. Es ahora que estás ardiendo con ira justa y quieres expresarlo en comentarios maliciosos como "solo un idiota podría escribir código como este". Pero recuerde cualquier situación en la que un niño a su lado fuera caprichoso, organizando un berrinche para mamá debido a un juguete o helado no comprado. ¿Usted, como observador externo, disfruta viendo esta escena? ¡Pero su histeria en el rastreador de errores se ve exactamente igual!
Por lo tanto, si realmente quieres, di todo verbalmente. Discuta con el desarrollador la tarea en la sala de fumadores, defendiendo con vehemencia su posición. Pero tan pronto como llegamos a la computadora, eliminamos las emociones, escribimos solo los hechos. Sin "si sí si" y sin "¡y USTED! ¡Perdí al cliente!
Recuerde que regresan a las tareas después de un año o dos o tres. Y luego incluso mirarás con aprensión tu propio berrinche. Después de todo, no hay más emociones pasadas, esto parece ridículo. Así que las máximas emociones verbalmente - ¡en la sala de fumadores! Y en un error de alguna manera sin ellos.
Y en la justificación no escribas sobre conejitos mega-ofendidos. A veces, tal defensa de la tarea llega a ser ridícula:
El estudiante encontró un error tipográfico en la oferta del usuario. Poner un error con prioridad crítica. Cuando se le pidió que aclarara la prioridad, se indignó mucho:
- ¡El sistema me engañó, no puedo confiar en ella!
Probablemente le preocupaba que la pregunta se convirtiera en "esto no es un error en absoluto", por lo que comenzó a defender su error. Pero a nadie le importa que esto sea un error. ¿Pero por qué es crítico? ¿Quién lee la oferta?
- Yo leo! Por lo tanto, veo que el sistema es malo, si hay un error tipográfico allí, ¿qué puede hacer? ¿Y cómo creerlo ahora?
Pero "leo" ≠ "todos leen". Y luego, el propio estudiante admitió que no lee cuidadosamente CADA acuerdo de licencia que se nos ha introducido al instalar los programas. Entonces con la oferta la misma historia. Si bien todo está bien, no lo leen. Si algo no es agradable, ya diríjase a las reglas.
Sin embargo, "el sistema me engañó y no puedo creerlo ahora" debido a un error tipográfico en la décima página del texto que pocas personas leen ... Bueno ... No escriba esto en un error, no se lo diga a su RM.
Entonces, eliminamos las emociones del error. ¿Y qué podemos dejar allí? Por supuesto, los hechos!
En lugar de escribir sobre las emociones, "los conejos seguramente se ofenderán, se irán y perderás clientes":
- recopilar estadísticas;
- estimar los costos laborales;
- contar el ROI;
- Entrevista a los usuarios;
- Comparar el producto con la competencia;
¡Y en lugar de una ardilla histérica, te convertirás en un probador genial que hace errores reflexivos!
2. Buenos patrones de justificación
¿Cómo justificar los errores correctamente? ¿Qué debe escribirse en el resultado esperado para que su error se repare como lo escribió? Y no preguntaron 10 veces "¿por qué es tan correcto"?
Tres antipatrones se discutieron anteriormente, discutamos tres buenos patrones para justificar errores.
2.1. Pruflink
Podría ser:
- Enlace a requisitos
- Los requisitos mismos (archivo de palabras, presente ...)
- Enlace de internet
- ROI estimado
- Carta del cliente
- Estadísticas
Enlace a requisitosEl error más simple es cuando hay un TK y el sistema no funciona como se describe allí.
Entonces escribimos en el resultado esperado: "57.9, porque es así en la declaración de trabajo". Hmm, hmm ... Espera un minuto. Suena como "Lo juro por mamá" ...
Sí, en esa redacción suena así. Por lo tanto, confirme sus palabras con un enlace. De lo contrario, el desarrollador lee el error y necesita:
- darse cuenta de qué tipo de conocimientos tradicionales está involucrado;
- encontrar TK en sí mismo;
- encuentra el lugar específico en cuestión;
- para entender ...
¿No es más fácil dejar solo el último elemento? Después de todo, el desarrollador puede trabajar en 10 proyectos diferentes, cuya documentación se distribuye en 10 lugares diferentes. Le llevará de 5 a 10 minutos buscar TK, y agregar un enlace para usted es cuestión de un segundo. Después de todo, ahora está probando TK, lo que significa que está abierto y frente a sus ojos. Copia el enlace y pégalo!
Respeta el tiempo de los colegas y ellos te lo agradecerán.
Requisitos propiosSi los requisitos NO se almacenan en una confluencia u otro sistema en la nube, sino en un Word normal, adjunte el documento que está probando.
Es posible que esté probando requisitos obsoletos. Y si adjunta un archivo de palabra directo con el que está comprobando, el analista puede verlo y decir: "Oh, espera, ya hemos cambiado todo 10 veces, olvidé cargarlo. ¡Espera!
Si no lo haces, pasa tres horas en un enfrentamiento con el desarrollador, que dirá "¡pero tengo uno diferente!". Correrás, verás sus requisitos, luego los tuyos, luego buscarás un analista para aclarar quién tiene razón ...
Y entonces, inmediatamente puso los requisitos, el desarrollador miró y dijo "algo es algún tipo de basura", redirigió el análisis. El analista las escribió, y cuando abra su palabra, comprenderá de inmediato si está desactualizado o no. Eso es ahorrar tiempo!
Enlace de internetComo recordamos, los requisitos están lejos de ser siempre. Y en lugar de ellos tal vez ... ¡Enlace a Internet! Si, porque no?
Si recordamos nuestro ejemplo "Peter, Peter", incluso si tenemos requisitos en el sistema, es poco probable que diga "El sistema funciona de acuerdo con las reglas del idioma ruso" y se enumeran todas las reglas del idioma ruso. Por supuesto, nadie escribe así. Y aún así, si quieres referirte a las reglas del idioma ruso, debes ir y buscarlas en Google.
O si tomas un ejemplo de Sharipat. De nuevo, ¿de dónde sacaste que este es un nombre femenino normal? Buscamos en Google todo tipo de kazajo y otros nombres, encontramos Sharipat, buscamos otros nombres similares y le damos un enlace a esta página.
Y aquí ya, incluso si el desarrollador no está de acuerdo con usted, puede venir y decirle: "Mira, le diste un enlace al sitio, pero esta es una especie de prensa amarilla, siempre escriben basura". Pero si no proporcionó el enlace, el desarrollador tendrá que buscar en Google, buscar él mismo todo tipo de sitios y solo entonces comprenderá que puede haber atacado alguna información falsa. , .
, , , , , . « », !
. , «-», , . , , :
— , - . , , .
:
— , 1 2015
, , , (, , ). , 5 . , 10 — ?
, , , . :
— , 1 -, / . , , , . , , . …
, . , , . , .
ROIROI — . ? ?
— , . — - , .
ROI , — . , . — ! , .
— «, , !», … , , , …
, , - , :
-! , , , … ! ? , !
? « , , .» Para . -. , [2]. . , , !
… , ? . , , . ? !
, . . . ? ? , , .
— , !
:
— ;
— ;
— ;
— , ( );
— …
, - «» — . ? , 10 ? ?
, «» . , … 100 , . , .
— , , . , 5-7 , . — - !
., — « »? , , , - .
? , -, — . , , . Y viceversa.
, . : «, , , , !». , . , , … , , .
, , , , , .
, , . - , . ? , .
. , , . , ...
. , . . , — , — . !
2.2.
, . , — .
, ( , , ). «», «Jkmuf», .
. . . — , . , !
Jkmuf →
, , «»? , , :
> →
!
, , , 2 : , , , .
, ! , , . — >, , , . ? , Jkmuf, , .
, , . « , », .
2.3. , #
- .
– . — , « » , , . - , , .
, « !». . , ?
usability. , , , . ! , « ...» — , , . , , , , . .
, - .
, . , ! , 5 , .
Al probar una nueva función, la cubro con autotest. El marco de prueba ha existido durante mucho tiempo, estamos acostumbrados. Las pruebas son similares entre sí, así que copie y pegue; después de todo, generalmente cambiamos un parámetro, dejando el resto sin cambios. Este es el principio de "1 prueba = 1 prueba", de modo que una caída en la prueba indica inmediatamente la causa.
Y ahora necesito copiar parámetros de autotest a autotest. Y tengo que desenterrarlos de la primera prueba a la segunda, tercera, cuarta, quinta, décima ... Y en este copiar y pegar solo necesito cambiar 1 valor en una línea, y si no lo hago, todo se vendrá abajo con un terrible un error
Por supuesto, cuando copie y pegue, cometeré un error en alguna parte ... Como resultado, escribí 30 pruebas, las ejecuté de una vez y todo se cayó con NPE. Me siento, me rasco la cabeza y pienso "maldición, ¿dónde me equivoco?"
He estado resolviendo todo el día, buscando un error, ejecutando pruebas automáticas ... Estoy tratando de encontrar un error o un lugar donde me equivoqué. Como resultado, encuentro y luego en el próximo rally me quejo:
"Escribí estas pruebas automáticas todo el día de ayer, porque cometí un error en la quinta prueba y luego traté de entender durante mucho tiempo cuál fue la razón de la caída". Oh, este copiar y pegar!
Y luego el desarrollador dice:
"Sí, ella vendría a mí; yo refactorizaría todo para ti en media hora y solucionaría este problema".
¿Y entonces fue posible?
Por favor no tengas miedo! Tal vez estás sufriendo, y el desarrollador ni siquiera lo sabe. Y tal vez él pueda solucionar rápidamente su problema, aquí y ahora. Y tal vez no lo arregle, pero sugiera una solución alternativa.
Por supuesto, si el problema es de una sola vez, o si tarda demasiado en solucionarlo, la tarea de optimización irá a la próxima versión o más. Pero al menos vale la pena discutir "cómo se puede mejorar esto" y establecer una tarea. Después de todo, si no hay tarea, nadie hará nada.
Hay varios casos de problemas:
- problema del cliente;
- el problema del usuario real;
- problema del probador;
- un problema dentro del equipo;
Algunos son más prioritarios, otros menos. Y, sin embargo, si describimos el caso real y el problema real, dicha tarea tiene más posibilidades de corrección que "obviamente, para que todos sean mejores".
Sí, debe comprender que incluso si describimos lo malo que es para los usuarios reales, todavía no garantiza que solucionaremos el error, pero esta es la vida. En cualquier caso, si al menos describimos el problema, al menos quedará claro por qué hemos establecido esta tarea. Incluso si volvemos a él en un mes, dos o tres. Siempre veremos por qué pensamos que los usuarios eran malos e incómodos al trabajar con él.
3. Cuando no se necesita la justificación
De repente, ¿verdad? =)
Sin embargo, el antipatrón "obviamente" tiene excepciones. Realmente NO necesitamos escribir una justificación si el sistema:
- colgado
- cayó con un error no manejado;
Especialmente si esto sucedió en la producción. Si nuestro sitio lo es, no hay razón para justificarlo, debe golpear el gong y correr al desarrollador "¡corríjalo urgentemente!" Es posible sin un error en absoluto. Y puede hacerlo con un breve "Error 500 en el principal", esto es suficiente.
No chupe la razón del dedo, porque "siempre es necesario". Escribir "el sistema no debería caer" es texto por el bien del texto.
Pero! Definitivamente necesitas escribir el resultado esperado. Incluso si te parece obvio, escríbelo, no te borrará.
Pasos
Abra el sitio web example.com
Resultado
Error 500
Resultado esperado
La página principal se ha abierto.
Aquí todo parece ser simple: el principal no se abre, pero debería. Pero hay ejemplos más complicados.
Por ejemplo, el desarrollador hizo una fórmula de TK y en algún lugar se produce la división por cero. Si solo escribe "No debería haber errores, el informe se carga", entonces el desarrollador seguirá respondiendo con la pregunta "¿Cómo debería abrirse entonces? ¡Hay división por cero!
Debe pensarlo y escribir: “Espero que se abra un informe con tales valores según la fórmula ”. Si bien piensa qué debería estar allí, usted mismo puede encontrar una articulación en los TOR. Y luego verifique con el analista cómo hacerlo correctamente.
Entonces, incluso si no hay justificación, existe al menos el resultado esperado. Y recuerda que esta es una excepción a la regla. El sistema no debe caerse ni congelarse. Sin embargo, tales errores son raros, y en otros casos debería haber justificación.
4. Resumen
Discutimos 3 antipatterns. Tres etapas de ira, negación y justificación de errores:
- Obviamente : para nosotros es obvio que no lo justificamos. Y luego tenemos "oh, olvidé por qué quería" ... Esto es obvio solo para ti, solo aquí y solo ahora. Después de seis meses, usted mismo olvidará por qué. Explica cuán estúpido, qué tipo de evidencia hay.
- ¡Lo juro por mi madre, es cierto! - ¿Por qué jurar? Por alguna razón, piensas que es tan correcto, así que dime por qué. Dé un enlace a los requisitos, por ejemplo.
- Los conejos se ofendieron : "Oh, ¿no agregaste un gato a la página principal? Bueno, eso es todo! Me ofendió ... ¡Y SE HA IDO! Y tu! ¡Perdí al cliente! Pero lo que es inconveniente para usted puede ser conveniente para otros. Así que elimina las emociones y da hechos.
En cambio, deberían usar la lógica correcta:
- Pruflink - TK, Internet, carta del cliente en la que solicitó esta funcionalidad ...
- Uniformidad : si el sistema siempre funciona de esta manera, y en un lugar diferente, ¡vale la pena arreglarlo!
- Problema : describa el problema que surge para usted o el usuario (si se está comunicando con los clientes). El verdadero problema siempre es mejor que una simple prueba negativa.
Asegúrese de escribir por qué decidimos que esto es realmente un error y por qué queremos que se solucione exactamente como lo escribimos aquí. Nos hacemos preguntas de la serie "5 por qué"
- ¿Por qué creo que esto es obvio?
- ¿Por qué creo que es tan correcto?
- ¿Por qué creo que los usuarios están molestos?
Proporcionamos enlaces a requisitos en Internet, indicamos uniformidad o hablamos sobre el problema real del usuario.
Y cuando después de un año vuelva a leer las tareas ejecutadas de manera competente, aún me dirá "¡Gracias!" ツ