¿Qué podría enseñar un ejército a un probador? ¿Cuáles son los dos extremos en los enfoques de prueba? ¿Cómo explicar que la deuda técnica es roja por pago? ¿Qué tienen en común las preguntas anteriores?
Lo general es que, a pesar de su diferencia, todos están cerca de una persona.
Jim Holmes tiene detrás de él varias décadas de experiencia en TI, que comenzó en los años 80 en la Fuerza Aérea de los EE. UU., No es sorprendente que esté listo para contar mucho. El concepto de "cultura de prueba" es importante para él, y le hicimos preguntas que pueden variar mucho, pero que en última instancia están relacionadas de alguna manera con la cultura de prueba.
- Pregunta introductoria: cuéntanos sobre ti.- Mi nombre es Jim Holmes, soy consultor independiente y propietario de mi propia empresa, Guidepost Systems. Me especializo en calidad de entrega de software y he estado programando durante un total de aproximadamente 20 años, antes de eso serví en el ejército durante mucho tiempo. Hace 15 años me interesé seriamente por la calidad, mientras trabajaba en varios proyectos poco exitosos. En general, realicé muchas pruebas de automatización, pruebas unitarias, pruebas de integración y, especialmente, pruebas funcionales, pruebas de IU. En particular, trabajé para una empresa que escribió la maravillosa herramienta Telerik Test Studio. Y en los últimos 5-8 años, comencé a tratar no solo con aspectos puramente técnicos, sino también con la calidad del suministro en su conjunto, es decir, qué tan bien es la relación entre el equipo de suministro y el negocio. Pero al mismo tiempo, todavía depuro los scripts de WebDriver durante mucho tiempo y resuelvo problemas como fallas periódicas debido a acciones asincrónicas incorrectas. Vivo en la ciudad de Ashland, en Oregón. Eso sí, no en Portland (cuando en los Estados Unidos dices "Oregón", generalmente todos piensan "Portland").
- Probablemente, para el probador, la parte más inusual de su biografía es el servicio militar. ¿Qué estabas haciendo exactamente allí?- Serví en la Fuerza Aérea de los EE. UU. Porque siempre me inspiraron los aviones y mi padre era piloto. Me llevó en mi primer vuelo cuando tenía solo 4 años. En la Fuerza Aérea, tuve mucha suerte, serví en el equipo E-3: este es un avión tan grande con un gran disco en la parte superior, donde fui responsable del funcionamiento del radar y algunos sistemas de comunicación. Durante once años he estado administrando y depurando este gran sistema electrónico. Y durante el tiempo libre de vuelos, administré las computadoras de nuestro escuadrón. Alrededor de entonces, se hizo posible crear redes en el lugar de trabajo. Además, como era soldado, me pagaban por la educación, así que fui a una escuela nocturna para desarrollar software.
En cuanto a su pregunta, la experiencia del servicio militar es inusual no solo para los evaluadores, sino también para muchas otras áreas. Puedo decir que al menos me enseñaron disciplina allí.
- Sí, en el caso del ejército, lo primero que viene a la mente es la disciplina. Y con esto, muchos probadores y desarrolladores tienen problemas. ¿Crees que tienen algo que aprender de los militares?- Esta es una pregunta muy interesante. El hecho es que la disciplina que me enseñaron fue algo diferente de, por ejemplo, los paracaidistas, es decir, no hubo gritos y castigos constantes. Me enseñaron un enfoque disciplinado para las pruebas y, en general, para la resolución de problemas. La disciplina en el lugar de trabajo también era importante: comprender qué era una jerarquía; Para aprender a trabajar en él, uno debe poder comunicarse con los superiores. Este tipo de disciplina me ayudó mucho.
Dejé el ejército hace 25 años, sí, soy un anciano, y el trabajo en el sector civil contrasta muy interesante con mi experiencia previa debido a las prioridades allí. En el ejército, serví en un avión, que se suponía que debía monitorear al enemigo en un territorio grande y garantizar la seguridad de mi propio. Cualquier error significaba un riesgo para la vida de nuestros soldados. No quiero exagerar, pero realmente lo fue. Entonces, cuando alguien en TI comienza a entrar en pánico y exige que se resuelva una tarea de inmediato, gracias a mi disciplina y mi experiencia, siempre puedo tranquilizar a la gente: no estamos amenazados de que alguien muera y no perdemos cientos de miles de dólares por minuto (y he estado en tales situaciones). Muy a menudo entramos en pánico y dejamos que la empresa o los accionistas nos intimiden innecesariamente y creen una tensión irrazonable que no hace nada bueno a nadie. Quizás lo mejor que el ejército me ha enseñado es la capacidad de pedir calma, evaluar la situación de manera sólida y planificar nuestras acciones de antemano, y no precipitarse en una tarea sin pensar debido a un pánico creado artificialmente.
- Es decir, debes tomarte el tiempo para pensar en una estrategia.- Sí, y en TI este problema ha pasado mucho tiempo: requisitos constantes para entregar el proyecto en este momento. Lo principal es hacerlo rápidamente, y lo que se está haciendo exactamente es de importancia secundaria. Muy a menudo, esta presión se puede controlar si el diálogo se lleva a cabo correctamente. Pero para esto es importante poder decir que crearemos más valor si dedicamos un poco más de tiempo y abordamos racionalmente el problema.
- Pasemos a sus actividades actuales. En el trabajo, está familiarizado con la forma en que abordan las pruebas en diferentes empresas de diferentes maneras. Está claro que el enfoque puede depender, por ejemplo, del tamaño de la empresa. Pero probablemente haya muchas diferencias menos obvias. ¿Puedes hablar de ellas?- Esta es una pregunta maravillosa. Además de mi trabajo independiente, también trabajo con Pillar Technology de Columbus, Ohio. Conozco gente de esta empresa desde hace mucho tiempo. Ahora trabajan allí unas 250 personas, y casi todas trabajan según el principio de la programación extrema (XP): tienen muchas pruebas unitarias y el desarrollo está muy bien pensado. Cuando fui contratado allí hace tres años, yo era el único probador, y crearon un producto de muy alta calidad. Se acercaron a las pruebas exclusivamente desde la posición de XP, desde la posición de desarrollo basado en pruebas. Este es un gran enfoque, y lo han aplicado con éxito, y yo, junto con algunos otros empleados, logré cambiar algunos aspectos de la entrega de software.
Y puede comparar esta experiencia con otra compañía en la que he estado consultando durante los últimos tres años. Esta es una empresa industrial, se encuentra en la lista de los diez principales de Fortune y emplea a unas 200 mil personas en todo el mundo. Tienen un departamento de TI muy grande para las necesidades internas de la empresa. Hay mucha gente buena allí, pero sus pruebas se atascaron en las prácticas de los años ochenta o noventa. La compañía produce grandes lotes de exactamente los mismos productos, y muchos están acostumbrados al hecho de que en la producción de, por ejemplo, rodamientos de bolas, es muy posible estimar el número de defectos esperados. Pero el problema es que transfieren este tipo de pensamiento a TI.
Tuve una conversación con cuatro, en general, empleados muy inteligentes que estaban involucrados en la recopilación de informes de defectos de varios proyectos y tratando de predecir el número de posibles defectos en el futuro. Les dije que esto es bastante razonable en la industria, pero ¿cómo distinguirán los indicadores que se calculan para una aplicación móvil de los indicadores de, digamos, los servicios web? Ellos respondieron que no hay diferencia. Así que tuve la suerte de ver puntos completamente opuestos en el espectro de diferentes enfoques y culturas de prueba.
Además, trabajé con algunas compañías que no lograron salir de la etapa de inicio, cuando trabajan todo el tiempo sin mirar atrás, sin tratar de cubrir toda la situación. Y luego, después de varios años, en proyectos complejos, los problemas que surgieron en esta etapa comienzan a sentirse bruscamente, y tengo que convencer a la gente de que este enfoque es incorrecto y que ahora tengo que detenerme y pensar bien en mis acciones. En general, mi respuesta fue algo extensa, espero no haber perdido completamente el contacto con su pregunta.
- Y en su práctica de asesoramiento, ¿hay momentos en que, después de completar el trabajo con la empresa, le dijeron "nada mejoró"?- Te diré un secreto que es difícil para las personas, somos criaturas muy difíciles. Esta es una de las razones por las que tengo tantas canas (la segunda es mi hija). Cambiar a una persona es difícil; cambiar personas en una organización es aún más difícil. Entonces sí, tengo esta situación con bastante frecuencia.
Acerca de algunos consultores, incluso decimos que él "se quemó". Esto se debe al hecho de que estamos haciendo muchos esfuerzos para cambiar la cultura que se ha desarrollado en la organización, y tenemos que trabajar mucho con los problemas a nivel personal: las personas tienen miedo de los cambios, constantemente tienen que convencerse de que esto es necesario y busca el camino que más les convenga. No importa cuán fuerte y fuerte sea, no puedo simplemente venir y decir: haz esto y lo otro. Necesito llegar a un consenso. Este trabajo debe llevarse a cabo durante años para lograr algo, y cuando parece que ha resuelto el problema y va a consultar a otra organización, encontrará exactamente los mismos problemas que en el lugar anterior. Una vez más, pasa una gran cantidad de tiempo y esfuerzo, y luego resulta que en esa primera compañía todo ya ha regresado a su estado anterior.
La gente está muy dispuesta, es difícil con nosotros, a menudo volvemos a nuestros viejos hábitos. Pero a pesar de esto, hay ejemplos de trabajo verdaderamente exitoso. Hay organizaciones que logran consolidar el resultado logrado con usted. En general, diría que uno equilibra al otro. Continúo haciendo este trabajo porque estos casos de éxito son inmensamente satisfactorios.
- En su blog escribió sobre sus principios profesionales, y allí habló sobre la necesidad de ser abierto, siempre aprender cosas nuevas, escuchar más que hablar, adaptarse y ser amable con las personas. Me pregunto si realmente ayuda a una buena actitud hacia las personas.- Sí, ayuda. Dije que serví en el ejército, donde teníamos una disciplina estricta, pero debemos entender que la disciplina y la estructura no interfieren de ninguna manera con las buenas relaciones y la empatía con otras personas. ¿Conoces al chef escocés Gordon Ramsay? Él lidera el show de Hell's Kitchen. Lo menciono porque los chefs en restaurantes caros a menudo se comportan de manera desagradable con los empleados: gritan e insultan. Odio esta actitud hacia las personas. Para mí, una buena actitud el uno hacia el otro es importante. Si desea lograr algún cambio, debe comprender por qué la gente se resiste a ellos, es decir, necesita empatía. Y te permitirá hacer que la persona misma quiera cambiar. Tal enfoque es mucho más efectivo que gritar a las personas y exigirles que obedezcan y no hagan preguntas. Cada persona tiene su propia mente, su propia alma, su propia experiencia. No me gustaría profundizar en la filosofía, pero creo que a la larga, la buena actitud y la empatía te permitirán lograr grandes resultados. Entonces sí, ayudan.
- Realizas seminarios, y en uno de ellos enseñas a personas que no saben programar. Tengo dos preguntas Primero, ¿qué problemas impiden con mayor frecuencia que las personas se auto-programen? En segundo lugar, ¿cree que durante el próximo año las pruebas automatizadas prevalecerán sobre las pruebas manuales?- En mi experiencia, las personas a menudo se sienten perturbadas no por dificultades técnicas, sino por miedo. Puedo dar un ejemplo de mi experiencia en una empresa de Fortune 10, de la que ya hablé. Trabajé con un equipo de probadores que hicieron pruebas manuales, y necesitábamos hacer la automatización usando WebDriver. De estos, la mayoría ni siquiera podía abrir Eclipse para comenzar a escribir código. Tenían miedo de escribir un script para la automatización, porque en su opinión, esto no era muy diferente de escribir un servicio web escalable o una base de datos con subprocesos múltiples, es decir, cosas que los desarrolladores han estado aprendiendo durante años. Este miedo les impedía hacer cosas generalmente simples.
Actualmente estoy desarrollando un curso para el Ministerio de Pruebas basado en un taller en el que le explico que no necesita años de práctica para simplemente abrir un archivo Java, C # o un script Ruby, leerlo y comprender la estructura general, o escribir prueba simple en WebDriver. Además, incluso si no comprende completamente todo lo que sucede en el código, puede darle una evaluación general, porque sabe, por ejemplo, que un método no debe ocupar tres pantallas, no debe haber cuatro instrucciones anidadas si serán difíciles. para probar, no puede dar a las variables nombres de una letra, etc. En mi opinión, en la etapa inicial, la principal dificultad es superar el miedo a que tengas que resolver tareas increíblemente complejas. Y siempre me interesó ver qué tan rápido mis clientes se deshacen de este miedo: solo tiene que hacerle a la persona una prueba de unidad simple y pedirle que escriba, organice, actúe y afirme. Creo que este componente humano es muy importante.
La mayoría de las tecnologías con las que trabajamos no son tan complicadas, pocas están involucradas en cosas como vehículos no tripulados. Una vez realicé un seminario para un cliente en India, y había un gerente sin experiencia en programación. Este gerente estaba muy enojado al principio, y la razón era precisamente ese miedo del que acabo de hablar, y este miedo se superpuso a la renuencia a parecer estúpido. Pero al final de la primera lección, se sumergió tanto en las pruebas de escritura que tuve que sacarlo de la audiencia una hora después de que la lección ya había terminado: se sentó, enterrándose en el monitor, se emparejó con otro participante en el seminario y escribió pruebas simples para el algoritmo salarial. tableros. Y el punto aquí no está en absoluto en mis habilidades de enseñanza, solo muestra cuán importante juega este miedo o su ausencia. Aquí estamos hablando de cosas inherentes a la naturaleza humana.
Su segunda pregunta está relacionada con la transición de la prueba manual a la prueba automatizada. Tengo algo de experiencia aquí, trabajé durante tres años en una empresa dedicada a la automatización de pruebas. Creo que la pregunta debe plantearse de manera diferente y luchar no por la automatización de pruebas, sino por el desarrollo de probadores y su adquisición de muchas habilidades técnicas, una de las cuales debería ser la prueba automatizada. Me gustaría ver a esos evaluadores que, con una historia de usuario, especificaciones y requisitos, puedan dialogar libremente con los desarrolladores sobre cosas bastante especializadas y buscar conjuntamente soluciones que luego se incorporen en el código. Esto es algo diferente del enfoque en el que el probador enseña programación, solo para poder escribir scripts de WebDriver. Esta habilidad, por supuesto, también es importante, pero, en mi opinión, no es la más importante. La supertask, en mi opinión, es la capacidad de dialogar con el desarrollador y asegurarse de que tenga en cuenta el proceso de prueba cuando escribe el código. Incluso TDD ya será un resultado significativo: creo que todas las organizaciones deberían poder escribir así.
La conclusión es que las pruebas entregadas correctamente están lejos de reducirse a pruebas unitarias o pruebas de integración. Muy a menudo las personas están satisfechas con probar una ruta de ejecución de código típica: se pasan todas las pruebas, las casillas de verificación están en todas partes, se logra una cobertura de código del 100%. Pero nada de esto garantiza la calidad del código, ¿verdad? Aunque estos también son procedimientos necesarios, por supuesto. Entonces, en mi opinión, el probador no solo debe escribir algunas pruebas funcionales o pruebas en WebDriver, sino pensar en cómo puede establecer una cooperación más estrecha con los desarrolladores y analistas de negocios. Puede, por ejemplo, probar
la programación de la mafia . En general, creo que la automatización es una herramienta, no un objetivo.
- Las palabras "cooperación estrecha con los desarrolladores" son muy cercanas a nosotros como organizadores de Heisenbug, incluso el eslogan de la conferencia es "sobre las pruebas, pero no solo para los evaluadores". Y en relación con esta cooperación, me gustaría hacer la siguiente pregunta: ¿qué, como persona con amplia experiencia en pruebas, le gustaría decirles a nuestros lectores y programadores?"¡Que no todos somos malvados!" Los probadores se han ganado su notoriedad con sus propias acciones. Encuentran fallas en los detalles más pequeños en las reuniones, a menudo comunican informes de errores, no palabras. El desarrollador viene a trabajar por la mañana y ve 50 informes de errores que informan sobre errores gramaticales y páginas no alineadas. He estado en ambos roles, y sé cómo reaccionan los programadores ante esto. Esto es parte de la vieja escuela de pruebas, y yo también una vez me comporté de esta manera. Pero los evaluadores, que están más acostumbrados al enfoque moderno, entienden que es más fácil y mejor hablar con él que bombardear a un programador con informes de errores.
En mi opinión, es importante que los desarrolladores entiendan que un buen probador puede ser muy valioso, y si hablas con él por adelantado, puedes ahorrarte mucho tiempo y nervios. Esto es lo que dice la teoría de las restricciones. Supongamos que soy un desarrollador y veo que el probador ha detectado algún problema. Si en lugar de escribir sobre esto en TFS o en otro lugar, solo me acerco a él y hablo en persona, entonces esta conversación me ayudará a reducir la cantidad de defectos en el código que escribo. Además, en la comunicación personal, la mayoría de los evaluadores, por regla general, están lejos de dar miedo. , , , , — , , , .
, . , , , , — , . , .
, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .
— . «The leadership journey» . , : , , — . ?— , , IT: , , , , . , , , , . , , , . , , .
, . , , , . , : , , . , , , . , , , . . , , . , , - , . , , . , — .
— , . : , , , . — ?— 18 , , 13 14. . , — , , . , , . , .
, . , , . DevOps. , , . , . , Skype - , Skype for Business Google Hangouts, . . , . , , , Xbox — , .
, — . , . hangout Slack — . , , .
20 , , — . . , , , . , , , . . , — , . , , .
— «Technical debt: payment plan». « » , « » , . , , , , ?— . , , IT - , . (Trish Khoo), Twitter hogfish. — , . , , «Technical debt: payment plan». , , , , -, .
, , , , - . -, , , . , , . - X , Y , . , - . , , 30 - , . , -, . , , : - .
, 10 3 . 3 . , . . , , , , . , , , - , . , . , , IT, , . , . , . . , , - , , , .
, , . , , . , , , . , .
— , , , . , , , .— . , . , , , . , , — , . , , - . .
, . , , , , . , , , , , , . , , , .
— , — . , .— Fortune 10, , . , . , , , . , , , , , Acceptance Testing.
, , . , (, Sonar Cube), , . , , . , « », , , , . , , . , , - .
— . .— , . , : , .