¿Cómo se realizan las pruebas de software en las startups tecnológicas?

10

He visto muchos artículos de investigación y blogs de tecnología que cuentan con los beneficios de las pruebas de software. Estoy convencido de eso. Pero dado que toda la investigación de pruebas de software es realizada por grandes compañías de software, no creo que realmente se apliquen a las startups. Dado que las startups tienen diferentes necesidades y limitaciones en comparación con las grandes empresas de software.

Entonces esto planteó las preguntas. ¿Deben las startups tecnológicas escribir pruebas automatizadas? Si es así, ¿se hacen de la misma manera que las grandes compañías de software? (prueba de humo, prueba de regresión, etc.) Es mejor si puede consultar algunos artículos de investigación sobre este tema ... ya que no pude encontrar ninguno por mi cuenta.

(Debo admitir que a pesar de que todavía estoy en una etapa temprana de mi carrera, pero aún no he visto una startup que esté seriamente comprometida a escribir pruebas automatizadas)

testing startup

— ming_codes
fuente

55

Me uní a una pequeña empresa de 10 años, y fui el primero en agregar pruebas que se ejecutan de noche. No porque fuera un genio, sino que era la primera vez que el gerente (también codificador) reconocía que era hora de agregarlos y que finalmente tenían la mano de obra. Las estratagemas a menudo tienen que sobrevivir primero y luego perfeccionarse. De acuerdo, esta puesta en marcha fue iniciada por personas que no son expertos en tecnología, por lo que esta característica tuvo que "introducirse".

— Trabajo

55

¿Una startup de 10 años ...?

— Pap

Dilbert dijo : "Si la mejor práctica es adoptada por todos en la industria, la mejor práctica se convierte en mediocridad". Supongo que es cierto, je.

— ming_codes

Inicio de 10 años ... deben estar usando Java: 3 años de diseño + 7 de desarrollo :) solo bromeando (soy un desarrollador de Java por cierto)

— nuvio

11

Siempre hay un conflicto entre lo que se debe hacer y lo que realmente tenemos tiempo para. Sí, muchas startups renuncian al desarrollo impulsado por pruebas y pruebas automatizadas para ahorrar tiempo para poner en marcha un proyecto.

Los sitios de redes sociales y las compañías de aplicaciones móviles son las grandes burbujas ahora, y son ferozmente competitivos. A veces, la diferencia entre vivir en 4 meses versus 5 meses significa que pierde.

El tiempo de comercialización es clave, y luego, si el éxito ocurre, es hora de escalar, entonces habrá tiempo de sobra para refactorizar su software no probado en algo que valga la pena.

— árbol de arce
fuente

Sin embargo, el tiempo de comercialización es un mito. Los participantes tardíos en un mercado pueden sorprender a los jugadores existentes: friendster> myspace> facebook.

— Joeri Sebrechts

@JoeriSebrechts Leí un artículo interesante sobre la progresión del software y cómo se relaciona con el éxito de los participantes tardíos. Hay variables en juego, el período seguro para un participante tardío con una solución similar es igual a la cantidad de tiempo para que la base de usuarios de un software se transforme de Adoptadores Tempranos a Usuarios Generales. Una solución similar, por supuesto, significa características que son similares y no innovadoras en comparación con el primer participante en el mercado (por ejemplo, Facebook fue innovador en comparación con MySpace). Una vez que se alcanza una masa crítica de Early Adopters, los usuarios generales comienzan a migrar.

— maple_shaft

12

Las pruebas de software no son una religión. Es solo una muy buena idea.

¿Dices que no tienes la mano de obra para escribir exámenes en este momento? Está bien. Dentro de 6 semanas, ¿tendrá la mano de obra para encontrar el error que está bloqueando su aplicación, que se habría encontrado de inmediato si hubiera realizado las pruebas adecuadas?

Demasiadas pruebas pueden retrasar el desarrollo. Muy pocas pruebas también pueden ralentizarlo. Tienes que encontrar el equilibrio correcto, y generalmente es difícil saber dónde está. Y nada de esto es específico para empresas grandes o pequeñas.

— Mike Baranczak
fuente

4

Durante muchos años, mientras trabajaba en pequeñas empresas y nuevas empresas, tuve la idea errónea de que "no tenía tiempo suficiente para escribir pruebas unitarias para mi código" .

Cuando escribí las pruebas, estaban hinchadas, cosas pesadas que solo me animaron a pensar que solo debería escribir pruebas unitarias cuando sabía que eran necesarias.

Recientemente me animaron a usar Test Driven Development y descubrí que es una revelación completa .

Ahora estoy firmemente convencido de que "no tengo tiempo para no escribir pruebas unitarias" .

En mi experiencia, al desarrollar teniendo en cuenta las pruebas, termina con interfaces más limpias, clases y módulos más enfocados y, en general , un código más SÓLIDO y comprobable.

Cada vez que trabajo con código heredado que no tiene pruebas unitarias, y tengo que probar algo manualmente, sigo pensando "esto sería mucho más rápido si este código ya tuviera pruebas unitarias" . Cada vez que tengo que intentar agregar funcionalidad de prueba unitaria al código con alto acoplamiento, sigo pensando "esto sería mucho más fácil si se hubiera escrito de forma desacoplada" .

Si hay algo que he descubierto a lo largo de los años, si está trabajando en una empresa nueva, debe ser ágil , y no solo en el sentido de la metodología de desarrollo de software . Para mí, TDD es una herramienta importante que permite comenzar y mantenerse ágil .

— Mark Booth
fuente

1

No se trata de quién debería hacer las pruebas de software, las pruebas de software son una especie de filosofía de desarrollo de software. Las pruebas de software establecen la base de una buena calidad de software, y en una startup, la calidad del software es una ventaja cuando la adquisición por parte de una gran empresa está a la vuelta de la esquina;)

— Francisco Valdez
fuente

1

Las mejores prácticas abarcan toda la industria, ya sea que esté convirtiendo a la abuela en un sitio web o creando el sistema de guía para un satélite. Siempre deben ser seguidos por aquellos que quieran considerarse profesionales, por eso se les llama MEJORES prácticas.

— Ryathal
fuente

Puede que se sorprenda al saber que las mejores prácticas no abarcan toda la industria. thedailywtf.com

— Gary Willoughby

@Gary es más una industria amplia en teoría, o parte de ese mundo utópico donde los proyectos tienen plazos realistas y html tiene un significado semántico y los gerentes admiten que carecen de conocimiento técnico que los ayudaría a tomar mejores decisiones ...

— Ryathal

"Mejores prácticas" generalmente significa hacer cosas como todos los demás, produciendo un resultado promedio. La empresa promedio establecida funciona razonablemente bien, pero la startup tecnológica promedio no llega lo suficientemente lejos como para colapsar espectacularmente.

— David Thornley

1

@DavidThornley - No, creo que la "Mejor práctica" es lo que la mayoría de las personas creen que deberían estar haciendo, tengan o no el tiempo, la energía o la aprobación de la gerencia para hacerlo. * 8 ')

— Mark Booth

@ Mark Booth: Normalmente, cuando escucho la frase, significa lo que dije. YMMV, por supuesto. Sin embargo, Ryathal se refiere a un mundo donde los proyectos tienen plazos realistas, y eso no es necesariamente posible en los negocios. Hacer que un producto salga dos meses tarde puede ser intrascendente o fatal (particularmente para una startup que puede estar en peligro de quedarse sin dinero), y de manera molesta a menudo hay un fuerte argumento comercial para obtener algo que generalmente funciona por la puerta lo antes posible. Me resulta difícil creer en las "mejores prácticas" que pueden condenar a una empresa.

— David Thornley

1

Sí, las startups a veces cortan esquinas y no implican pruebas adecuadas. A veces esto es apropiado (para proyectos lo suficientemente pequeños o cuando el tiempo / dinero son críticos)

Sin embargo, esto no es exclusivo de las startups. Uno de nuestros proveedores contratistas de TI no tiene un entorno de prueba. Todo se hace directamente para vivir y esta es una gran compañía de software multinacional (¡da miedo!)

— Tom Squires
fuente

1

¿Deberían ellos? Si. ¿Lo hacen en la práctica, no tan a menudo como deberían?

La razón más típica dada es la falta de recursos, que incluye el tiempo del desarrollador, el costo de contratar a un probador dedicado o de medio tiempo, el costo de configurar un entorno de prueba, etc. Incluso puede encontrar estas excusas en grandes entornos corporativos, así como en pequeñas empresas de nueva creación.

Mirando de otra manera, las pruebas son una de las cosas más fáciles de eliminar de un cronograma de desarrollo, especialmente una con presión de tiempo muy apretada y / o presión de costos para producir resultados visibles. Junto con el trabajo de diseño detallado, muchos gerentes lo consideran `` esponjoso '' y en primer lugar dirán "córtalo para que podamos hacer que nuestro horario y presupuesto funcionen", seguido de "¿Por qué no estás codificando?".

En algunas compañías, habrá alguien que haga pruebas de empuje. Por lo general, este será el desarrollador contratado y, por lo general, serán alguien con experiencia y probablemente alguien que tenga una participación financiera de algún tipo en la empresa. Una compañía que comienza con este "ADN" probablemente hará las pruebas desde el principio.

— jfrankcarr
fuente