El término “QA” que se usa muchas veces para referirse a un tester, significa “Quality Assurance”, o sea, aseguramiento de la calidad. ¿Se puede asegurar la calidad? ¿Es el tester el que puede asegurar la calidad? Me encantó la visión de Bolton al respecto, la cual resumo a continuación.
En este post, Michael Bolton explica el por qué no hay que llamarle Quality Assurance a un equipo de testers, y que en todo caso QA es Quality Assistance. Él afirma que el más cercano a ser Quality Assurance es el CEO de una compañía. El tester, en la mayoría de los casos, no tiene control sobre todo lo que influye en las decisiones de calidad, con lo cual, no la puede asegurarla.
Muchos quisieran poder tener un sello como el siguiente en la “tapa” de su producto:
y hacer un reclamo al seguro si aparece algún problema.
Otra cosa que comenta Bolton sobre los testers es esta:
Tell the programmers, as James suggests in the interview, that your principal goal is to help them look good—and then start believing it.
Your job is not to shame, or to blame, or to be evil.
Los testers están para que los desarrolladores luzcan bien, no para culpar o hacer sentir mal a alguien. O sea, estamos para asistir en cuestiones de calidad.
Nosotros en Abstracta hace mucho insistimos en no usar el concepto de QA, pero si alguna vez se nos escapa, el concepto está relacionado a ayudar, colaborar, asistir sobre la calidad, no la de asegurarla (por más que es lo que muchos quisieran). Por otra parte, estamos apuntando a formar más QE (quality engineers), ya que sí se puede hacer ingeniería sobre la calidad, pero no aseguramiento.
2 thoughts on “QA como Quality Assistance en lugar de Quality Assurance”