qa - soriano - que es quality assurance
¿Cuándo es hora de tener un departamento de control de calidad? (12)
El departamento de Garantía de Calidad (QA) es aproximadamente un grupo de probadores que desacreditan su (s) aplicación (s) todo el día, dando luz verde a las versiones, manejando programas Alpha / Beta. Y mucho más.
Pero sin un departamento de control de calidad en una compañía de software, los problemas surgen con demasiada frecuencia en el campo y los problemas cuestan más para solucionarlos. Sin embargo, la mayoría de las compañías comienzan en un garaje, con 1 empleado siendo usted mismo, y luego se convierte en una empresa de software.
¿Cuándo dices que es para crear ese departamento? ¿Tiene algo que ver con el tamaño de la empresa, los problemas que encuentra?
Actualmente estoy dirigiendo una empresa de software de inicio de garaje, en este momento sustituyo un departamento de Q & A con familiares y amigos, los llamo o les pido que vengan a tomar unas cervezas y probar mi producto para mí.
Esta prueba de "pasillo" ha funcionado bastante bien hasta ahora, de nuevo mi producto no está dirigido a usuarios técnicamente capacitados, si fuera así podría tener más dificultades para encontrar probadores.
Si no tiene familiares y amigos disponibles, le recomendaría lanzar un anuncio en sus anuncios clasificados o craigslist, debería ser difícil encontrar algunos estudiantes o alguien que pruebe el salario mínimo.
En cuanto a cuándo contratar personal de control de calidad a tiempo completo, diría que depende únicamente del estado financiero de la empresa.
Bueno, quieres a alguien que no sea el programador que escribió el código de prueba. Eso no significa que necesites un departamento de control de calidad. En muchas tiendas, los analistas de negocios también realizarán pruebas, lo que es mucho más económico porque solo se puede probar durante la parte posterior de la construcción, no durante el análisis y el diseño de los requisitos. En una tienda muy pequeña probablemente ni siquiera utilices la palabra analista de negocios, pero ya sabes a qué me refiero: gente de productos o diseño que no codifica. Incluso en una empresa muy grande, este modelo tiene sus ventajas; los grupos de prueba pueden tomar vida propia.
Como ex gerente de control de calidad de una empresa de software exitosa, yo diría crecer tan pronto como publique su primer programa. (Antes, si es posible). Realmente, tan pronto como puedas pagarlo. Pero, como desarrollador, debería estar haciendo muchas pruebas usted mismo durante todo el ciclo de desarrollo, no solo al final. El trabajo de QA (según el libro que leas) es manejar una gran cantidad de pruebas heredadas, pruebas SMOKE, pruebas de regresión, pruebas en el mundo real y procedimientos de prueba automatizados, procesos y planes, etc.
Las pruebas ad hoc son solo una pequeña parte de lo que debería hacer QA. Hay dos áreas principales de enfoque para QA. 1) ¿El software HACE lo que se supone que debe hacer y cumple los requisitos de una manera que el cliente pueda utilizar, y 2) el software NO hace lo que se supone que NO debe hacer?
Las pruebas planas, de procedimiento y Ad hoc son la base de la garantía de calidad. Descubrí que si solo realiza un tipo de prueba u otro, no tendrá un ciclo de QA exitoso.
He lanzado software sin control de calidad cuando trabajo por mi cuenta, pero puedo decir que SIEMPRE es más propenso a errores, no importa cuánto lo pruebe. Un segundo conjunto de ojos es lo mejor para el software.
Solo asegúrate de formar a tu equipo con ADD retentivo anal, geeks de la computadora. Obtendrás tus mejores resultados de esa manera. :) Las personas que están ORGULLOSAS cuando pueden hacer que el software de alguien vaya BOOM ... heh .. (Es una broma ... Sé un montón de QA Testers que no tienen ADD) ...
Depende. Si es una empresa pequeña con un equipo pequeño y eficiente y su tasa de error es baja, probablemente no sea el mayor problema que deba resolver.
Si el mercado lo está presionando para que produzca más rápido, la cantidad de desarrolladores está creciendo y la tasa de error está empezando a dañar sus relaciones con los clientes, entonces puede considerar arreglar el proceso haciéndolo más formal.
El truco para sobrevivir en una empresa pequeña es implementar solo el proceso, cuando el valor se paga por sí mismo. Si está contratando personas para mejorar su calidad, tiene que ser bastante grande para pagarse a sí mismo, lo que significa que antes, la calidad tiene que ser bastante mala (y perjudicial para las empresas).
A menudo, un mejor proceso de soporte es mucho más importante, porque incluso el mejor grupo de control de calidad dejará ocasionalmente que salgan errores. Los clientes quedarán mucho más impresionados si manejas bien las correcciones / parches (no notarán una reducción significativa en los errores, a menos que las versiones anteriores fueran realmente muy malas).
Pablo.
Para jugar al abogado del diablo: "departamento de control de calidad" es una pista falsa, y en muchos casos una salida de emergencia.
Tratemos con el arenque rojo primero. "Departamento" es una declaración de la estructura organizacional, quién informa a quién; eso es secundario "QA" es un término general, sin ningún significado particular. (¿No me creen? Aquí hay una prueba: ¿no querrían "asegurar la calidad"? Por supuesto que no. Todos quieren eso).
Entonces, ¿qué es lo que realmente quieres aquí? Desea conocer los modos de falla de su software antes de que lo hagan sus usuarios.
Si su software tiene "problemas" en el campo, bueno, eso significa que el trabajo de descifrar los modos de falla no se está logrando, y es posible que desee contratar a alguien con las habilidades para hacerlo.
Creo que la descripción del trabajo de un desarrollador debe incluir al menos algo de eso. Si contrato testers, preferiría que tuvieran que trabajar duro para encontrar modos de falla. Si la aplicación falla en cuestión de segundos después de que un examinador la haya puesto, los desarrolladores van a escucharla en términos directos. La frase "defecto atroz" viene a la mente.
En el cofre. La verdad es que no se puede poner calidad en el producto después del hecho. Pero "deberíamos contratar a algunos probadores" es el grito de muchos desarrolladores atrapados con las manos en la masa convirtiendo el código muy por debajo de los niveles aceptables de calidad. (Lo sé, he sido uno de ellos)
Por lo tanto, si contratas a alguien con experiencia en pruebas, lo correcto es hacer que funcione en mi humilde opinión junto con los desarrolladores. Reportando al mismo gerente. Con la misma misión: corregirlo en primer lugar.
Somos una nueva y pequeña startup con un solo desarrollador. Cada vez que hablamos de agregar recursos adicionales, ¡mi primera respuesta es contratarme una persona de QA!
Supongo que creces un departamento de control de calidad de forma orgánica: incluso cuando eres un programador en solitario, deberías estar haciendo parte del trabajo que hace una persona de control de calidad.
Si, por ejemplo, una persona dedica el 10% de su tiempo a actividades de control de calidad, tan pronto como llegue a diez personas, puede tener una persona dedicada a la garantía de calidad.
Tan pronto como pueda pagarlo. Nunca tendrá un producto que sea tan confiable sin un departamento de qa que con uno. Los programadores no son buenas personas de QA, y siempre es mejor tener una segunda persona (o más) que revise cómo funciona la aplicación.
Todas las buenas compañías de software y las organizaciones con buenos departamentos de TI que crean programas tienen un equipo qa. Es vital para el desarrollo de software.
debería funcionar sin QA pero con
- Software CI
- programación de la compañía (y analizar y diseñar y ...) y algunas herramientas para "forzar" al programador a ir con ellos
- algunos comentarios de vez en cuando
- etapas de prueba ej. entorno de prueba de equipo, integración (todas las aplicaciones juntas) y consolidación (igual que la integración pero con copias de los datos de producción)
- si es necesario un grupo de planificación de liberación
- y ... bueno ... buenos programadores de artesanos
Tan pronto como la base de código crece tan grande que una sola persona no puede conocer todos los detalles.
El razonamiento detrás de esto es que el 90% de las regresiones se realizan porque los programadores desconocen la imagen completa y el posible efecto secundario de su código en el resto del sistema. En tales casos, ni siquiera sabe que nunca debe proporcionar -1 como parámetro de edad o algo así. En la mayoría de los casos, las interfaces deben ser claras y tener una comprobación de errores, pero en las bases de códigos grandes se desliza, también cuando se apresuran a cumplir con la fecha límite, o las largas horas de trabajo son reducciones de concentración.
Por lo tanto, aunque debe realizar pruebas básicas incluso cuando se trata de una exposición individual , se deben usar elementos como pruebas unitarias e instalaciones de prueba automatizadas similares tan pronto como el código crezca lo suficiente como para que usted (o cualquier otra persona que pueda estar trabajando con usted) no puede comprender todo el sistema en mente.
Cuando tiene una empresa de dos personas que contrata un probador puede ser excesivo. Trata de pasar un tiempo probando solo. O solicite a un desarrollador amigo (que no está en el equipo) que juegue con la aplicación durante un tiempo. O pregúntele a un amigo (no desarrollador), casi como Pruebas de aceptación del usuario.
Contrata cuando comiences a vender software, cuando tengas 3 o más desarrolladores, cuando tengas dos cosas en mente para hacer pruebas (y me refiero realmente a las pruebas, no "comienza en mi máquina", sino "He estado tratando de aplastarlo por varias horas pero todavía funciona. ¿Tal vez debería ser realmente creativo? '').
El departamento de Garantía de Calidad (QA) es aproximadamente un grupo de probadores que desacreditan su (s) aplicación (s) todo el día
Me preocupa que vea el control de calidad como "un grupo de evaluadores que desacreditan su aplicación", como QA es un obstáculo para el producto final. Me hace pensar que has tenido una mala experiencia con QA en el pasado. En su lugar, intente ver el valor que QA aporta a su empresa. Desea que el usuario final pueda confiar en su producto desde el principio. Si el usuario final encuentra problemas o defectos, y se siente frustrado con su aplicación o sitio web, cada vez confían menos en su aplicación. La garantía de calidad debe mitigar el riesgo de que los usuarios pierdan la confianza en su aplicación. Si el QA no está haciendo eso, entonces no aportan el valor que es imprescindible para cualquier aplicación. En ese punto, necesitas un nuevo control de calidad. No solo botones pulsadores. QA que conoce la aplicación tan bien como el desarrollador. QA colabora con el desarrollador y el propietario del producto para asegurarse de que todos estén en sintonía con respecto a los requisitos y las expectativas del producto final.
Una nota final es que los desarrolladores no son QA. Los desarrolladores solo deben poner sus gorras QA cuando sea absolutamente necesario. Esto es difícil en una pequeña compañía de 1 o 2 desarrolladores. Así que estoy de acuerdo con los demás cuando dicen que obtengan QA tan pronto como puedan. En mi ubicación en el sitio para una gran empresa de desarrollo de software, los desarrolladores solo se ponen el sombrero de control de calidad cuando tenemos plazos difíciles que deben cumplirse y el tiempo de control de calidad es escaso. Incluso cuando ponen sus sombreros QA, el proceso de prueba es revisado por uno de los principales QA de ese equipo de desarrollo para asegurar que el desarrollador esté probando la aplicación completa y efectivamente. Solo hasta que el líder de control de calidad esté satisfecho con el nivel de prueba que ha ingresado en la porción que el desarrollador ha probado, el control de calidad se cerrará en esa parte.