User Tag List

Página 2 de 3 PrimerPrimer 123 ÚltimoÚltimo
Resultados 16 al 30 de 32

Tema: Tarifas QA de software / Testing

  1. #16

    Fecha de ingreso
    Oct 2003
    Mensajes
    17,905
    Mencionado
    42 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    214
    Agradecer Thanks Received 
    160
    Thanked in
    Agradecido 109 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Pero es que eso no es así. En parte es como dice Pakoito.....
    El manual no lo hacen los ingenieros de QA, y sinceramente, a la gente no se le paga sueldazos por saber leer un manual.
    Los test cases no los desarrollan los ingenieros rasos de QA, en todo caso un manager de testing.
    Y no, las pruebas de redundancia o de comentarios no se consideran test de QA.
    Las pruebas programaticas de QA suelen involucrar varios servicios y codigo ad-hoc para poder lanzar instancias de la aplicacion en distintos entornos controlados y no controlados y poder obtener metricas y resultados evaluables, ya sea de forma manual o en forma de preciosas estadisticas en un panel.
    Pero vamos, que en resumen, automatizar no es hacer testing.

  2. #17

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,202
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    675
    Agradecer Thanks Received 
    1,847
    Thanked in
    Agradecido 1,264 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por otto_xd Ver mensaje
    El manual no lo hacen los ingenieros de QA, y sinceramente, a la gente no se le paga sueldazos por saber leer un manual.
    No, los manuales deberían hacerlos los propios desarrolladores de la aplicación, pero eso es como los comentarios del código, las buenas prácticas y la documentación del código: nunca hay tiempo para hacerlo
    O al menos, los diseñadores del mismo, pero suelen ser documentos incompletos, de versiones alpha, y con información muy vaga.
    Así que el tester tiene que imaginarse cómo funciona el programa, y eso es tiempo, dinero, y muchas posibilidades de tener un quebradero de cabeza o un negativo crítico :P

    Cita Iniciado por otto_xd Ver mensaje
    Los test cases no los desarrollan los ingenieros rasos de QA, en todo caso un manager de testing.
    Ese es mi punto: ya tienes dos personas trabajando, y una de ellas es un especialista, por lo que los costes aumentan considerablemente frente a tener un "currito" apretando un botón del autoanálisis, o un senior creando el automatizador.

    Cita Iniciado por otto_xd Ver mensaje
    Y no, las pruebas de redundancia o de comentarios no se consideran test de QA.
    No sé si estar de acuerdo en eso, pero de todas maneras son pruebas que vienen en los programas de testing y se hacen de todas formas.
    Nosotros teníamos una serie de porcentajes para considerarlo warning, fallo leve e incluso fallo crítico.

    Cita Iniciado por otto_xd Ver mensaje
    Las pruebas programaticas de QA suelen involucrar varios servicios y codigo ad-hoc para poder lanzar instancias de la aplicacion en distintos entornos controlados y no controlados y poder obtener metricas y resultados evaluables, ya sea de forma manual o en forma de preciosas estadisticas en un panel.
    Pero vamos, que en resumen, automatizar no es hacer testing.
    Lo bueno de Java es que es tan modular que puedes acceder desde fuera a cualquier parte del código, por lo que puedes invocar servicios o lo que quieras ignorando el resto del programa y hacer tus métricas.
    Yo he usado, por ejemplo, BadBoy para hacer unas métricas de velocidad de acceso a un webservice, que me hacía 1000 peticiones por segundo. Imagina tener que hacerlo sin automatizarlo. Y el script lo escribía en 30 segundos o menos.
    Por eso digo, en casi todos los casos, especialmente en Java, automatizar las tareas sale más barato que hacer las pruebas a mano. Otra cosa es que tengas que hacer pruebas funcionales y empieces a hacer clic en botones y demás, pero las llamadas a los métodos que invocan esos botones los puedes hacer desde fuera, de forma automática, y te sobra la interfaz.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  3. #18

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    IMHO el manual no lo tiene que hacer el programador, el programador tiene que programar y no hacer miles de cosas para que después te echen la bronca de que algo no esta hecho, pues porque llevo dos días haciendo el **** manual...

    Hay gente que se dedica hacer manuales, no es fácil hacer un buen manual, yo lo veo como escribir un libro, y si quieres hacer una aplicación decente dedicate a programar y que otros hagan los iconos, diseño del interface, manual, etc.

    En Españishtan es mejor pagar 1.000€ a un tio que haga de todo y ya esta, despues te pegas un monton de horas para hacer o retocar unos iconos de mierda cuando un diseñador gráfico en la mitad de tiempo te haría un trabajo muchísimo mejor, pero claro hay que pagarle también, aunque la ventaja es que el programador podría seguir implementando otras funciones o corrigiendo errores.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  4. #19

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    aca drumpi se esta confundiendo, pensando que test automatizado es un tio que usa un script que no hizo para probar algo... no es asi, el testeo automatizado lo hace el profesional que lo automatiza (no tiene sentido que uno haga el script y otro lo corre, directamente lo corre quien lo hace, otro luego puedo reutilizar, pero el test en cuestion lo hace quien lo automatiza), haciendo scripts o usando herramientas de automatizacion de testeos, en ambos casos requiere conocimientos para llevar a cabo la tarea, y si bien puede parecer que lleva mas tiempo, por el contrario los reduce, en las iteraciones repetitivas de un testeo, o en testeos integrales o de stress.
    ser tester no es agarrar un programa y empezar a probarlo a ver que sale, los tester siguen lo que se llama "casos de prueba" o "test case", donde especifica cuales son los comportamientos que debe tener el componente a testear, por ejemplo, si es un input en un campo, validar longitud, tipo de dato, etc... pueden ser infinidad de cosas, pero deben estar incluida en el "test case"... esos test case, no son la documentacion del producto, ni tienen ni pretenden serlo... los test case, ni la documentacion, no las desarrolla el programador, por el contrario, el programador deberia recibir el mismo documento (o casi, informacion mas o menos) para hacer el desarrollo...

    desarrollador, recibe documento o pedido con detalles de comportamiento de lo que se necesita desarrollar
    QA, verifica que lo desarrollado coincida con el documento o pedido

    y despues por otro lado, tenes los betatesters que esos son los que agarran la beta de un producto y ahi lo empiezan a probar por todos lados.

    como sea, un perfil de automatizador, es mas valioso que un perfil de test manual... simplemente porque necesita tener una formacion diferente...
    ...

  5. #20

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,202
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    675
    Agradecer Thanks Received 
    1,847
    Thanked in
    Agradecido 1,264 veces en [ARG:2 UNDEFINED] posts
    Swapd0: No, el manual definitivo no lo tiene que hacer el desarrollador. Al desarrollador se le da un documento con características que se deben implementar, pero este debe devolver un documento indicando la organización del código, los bloques funcionales, etc... y entre todo eso, cómo funciona la interfaz o cómo está implementada. Pero no es un manual como los que leemos, sino un documento hecho de forma rápida, que lo entienda un ingeniero o alguien familiarizado con los ordenadores. Es más, debería ser simplemente una corrección del manual de características con los cambios que se han hecho por problemas del diseño o cosas que no se han tenido en cuenta.

    Quieras o no, el desarrollador debe hacer más que programar. Es un peñazo, pero debe DOCUMENTARLO TODO, y eso debería incluir un mínimo manual de uso, porque es el último que realiza cambios a la interfaz.

    Splinter: no te equivoques, que yo he dicho que he tenido que hacer los scripts del análisis antes de ejecutarlos, a mi no me los daba nadie.
    Los "test case" sí que me los pasaban ya hechos, pero teníamos gente que se dedicaba exclusivamente a ello, no nos venían hechos desde el cliente. Pero claro, si el test case te dice "generar un documento" ¿tú que haces? A mi no me daban un manual de uso (sólo es de despliegue). Así que iba y buscaba el típico botón de la hoja de papel blanca con la esquina doblaba, lo pulsaba y a esperar lo mejor. Generalmente funcionaba, pero luego te decías "¿y lo hará a través de archivo->nuevo...?", lo probabas y fallaba... y eso deberían considerarse dos test case diferentes.
    O peor aun: ambos métodos te funcionaban, pero luego cogías, editabas el documento y te dices "¿y si le doy ahora para generar un segundo documento?". Le dabas al botón y ¡CRASH! ¿Qué haces? ¿pones fallo al generar el documento? ¿lo pones en la edición? Al final tenía que añadir otro test case, darlo como fallo crítico y mandarlo de vuelta... Bueno, no, tenía que realizar el resto de pruebas y después mandarlo de vuelta.

    El chequeo manual es más efectivo en la localización de errores, pero mucho más lento, y por tanto, costoso. Pero todo lo que implica QA se hace en el grupo de QA, test cases incluidos, y si no hay una documentación del producto mínima, no puedes hacer nada. Yo no puedo probar un Hadooken si no me han escrito en alguna parte que se ejecuta con la combinación de botones tal, y eso es un manual de uso que viene de parte del desarrollo, pero no necesito un artwork de Ryu con flechitas de colores.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  6. #21

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    Yo por manual me referia al manual que se va a leer el usuario para aprender a usar la aplicación, y IMHO eso no lo debe hacer el programador.

    El problema de documentarlo todo es que puede que se quede obsoleto, puedes cambiar el código y no cambiar la documentación... asi que últimamente lo que hago es que si hace falta escribir un bloque de comentarios es que el código no esta claro, asi que toca refactorizar.

    Lo otro que comentas, no se donde trabajais pero lo normal es que el jefe cada día te diga haz esto, haz lo otro, etc... o sea que no hay nada escrito sobre lo que se va a hacer, simplemente vas implementando lo que de dice el jefe. Un día te llama y tienes que dejar lo que estés haciendo a medias para añadir una nueva funcionalidad de prisa y corriendo para que el cliente vea que somos serios y rápidos implementando nuevas funcionalidades.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  7. #22

    Fecha de ingreso
    Apr 2007
    Ubicación
    Rostovillar
    Mensajes
    3,783
    Mencionado
    11 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    1,016
    Agradecer Thanks Received 
    407
    Thanked in
    Agradecido 256 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    El problema de documentarlo todo es que puede que se quede obsoleto, puedes cambiar el código y no cambiar la documentación... asi que últimamente lo que hago es que si hace falta escribir un bloque de comentarios es que el código no esta claro, asi que toca refactorizar.
    Precondicion y postcondicion de las funciones, la documentacion se debería hacer sola.

    Y lo de las interfaces, supongo que os dan libertad porque os referireis a los contratos entre componentes software, porque lo que es la interfaz gráfica tiene que venir especificada en un documento de requisitos firmado con sangre por el usuario.
    Buy this car to drive to work. Drive to work to pay for this car.

  8. #23

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,202
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    675
    Agradecer Thanks Received 
    1,847
    Thanked in
    Agradecido 1,264 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    Yo por manual me referia al manual que se va a leer el usuario para aprender a usar la aplicación, y IMHO eso no lo debe hacer el programador.

    El problema de documentarlo todo es que puede que se quede obsoleto, puedes cambiar el código y no cambiar la documentación... asi que últimamente lo que hago es que si hace falta escribir un bloque de comentarios es que el código no esta claro, asi que toca refactorizar.

    Lo otro que comentas, no se donde trabajais pero lo normal es que el jefe cada día te diga haz esto, haz lo otro, etc... o sea que no hay nada escrito sobre lo que se va a hacer, simplemente vas implementando lo que de dice el jefe. Un día te llama y tienes que dejar lo que estés haciendo a medias para añadir una nueva funcionalidad de prisa y corriendo para que el cliente vea que somos serios y rápidos implementando nuevas funcionalidades.
    A eso me refiero: el manual del usuario lo hace otra persona, generalmente un artista (al menos, hace más de 20 años) que solía encargarse también del diseño del empaquetado. Pero antes de eso, hay un manual para desarrollo, y al QA llega un borrador sucio hecho en 20 minutos ¡o debería!.

    Y no son pocas las veces que me han llegado documentos desactualizados... hasta el punto de llamarme la atención el cliente por no haber implementado algo que no estaba en la documentación (así que había que poner cara de póker, decir que sí, hablar con el jefe (opcional) y ponerse a implementarlo tan rápido como sea posible).

    Lo del tercer párrafo depende. Yo estuve trabajando en QA y en desarrollo, en cada sitio se trabajaba de forma diferente. QA era todo más cuadriculado, más automático ("hazme esto" y lo hacías, y al terminar, te pasaban otro programa). En desarrollo sí que era "deja eso en cuanto puedas y resuelve este bug" o "necesito que me implementes esto para mañana", y en ocasiones eso se traducía en "modifica todo el código entero porque el cliente lo quiere por orden alfabético, no por orden de llegada" (bueno, no es un buen ejemplo, pero es que no quiero decir ninguno concreto), y tenías que recurrir a "soluciones creativas".
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  9. #24

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Swapd0: No, el manual definitivo no lo tiene que hacer el desarrollador. Al desarrollador se le da un documento con características que se deben implementar, pero este debe devolver un documento indicando la organización del código, los bloques funcionales, etc... y entre todo eso, cómo funciona la interfaz o cómo está implementada. Pero no es un manual como los que leemos, sino un documento hecho de forma rápida, que lo entienda un ingeniero o alguien familiarizado con los ordenadores. Es más, debería ser simplemente una corrección del manual de características con los cambios que se han hecho por problemas del diseño o cosas que no se han tenido en cuenta.

    Quieras o no, el desarrollador debe hacer más que programar. Es un peñazo, pero debe DOCUMENTARLO TODO, y eso debería incluir un mínimo manual de uso, porque es el último que realiza cambios a la interfaz.

    Splinter: no te equivoques, que yo he dicho que he tenido que hacer los scripts del análisis antes de ejecutarlos, a mi no me los daba nadie.
    Los "test case" sí que me los pasaban ya hechos, pero teníamos gente que se dedicaba exclusivamente a ello, no nos venían hechos desde el cliente. Pero claro, si el test case te dice "generar un documento" ¿tú que haces? A mi no me daban un manual de uso (sólo es de despliegue). Así que iba y buscaba el típico botón de la hoja de papel blanca con la esquina doblaba, lo pulsaba y a esperar lo mejor. Generalmente funcionaba, pero luego te decías "¿y lo hará a través de archivo->nuevo...?", lo probabas y fallaba... y eso deberían considerarse dos test case diferentes.
    O peor aun: ambos métodos te funcionaban, pero luego cogías, editabas el documento y te dices "¿y si le doy ahora para generar un segundo documento?". Le dabas al botón y ¡CRASH! ¿Qué haces? ¿pones fallo al generar el documento? ¿lo pones en la edición? Al final tenía que añadir otro test case, darlo como fallo crítico y mandarlo de vuelta... Bueno, no, tenía que realizar el resto de pruebas y después mandarlo de vuelta.

    El chequeo manual es más efectivo en la localización de errores, pero mucho más lento, y por tanto, costoso. Pero todo lo que implica QA se hace en el grupo de QA, test cases incluidos, y si no hay una documentación del producto mínima, no puedes hacer nada. Yo no puedo probar un Hadooken si no me han escrito en alguna parte que se ejecuta con la combinación de botones tal, y eso es un manual de uso que viene de parte del desarrollo, pero no necesito un artwork de Ryu con flechitas de colores.
    no, el desarrollador nunca hace ningun documento, "documenta el codigo" que es otra cosa muy diferente... esa documentacion nunca es para otro role que no sea el de desarrollador... o sea, que esta no tiene que ser una herramienta para QA... solo para otros programadores...

    la verdad que el que arma el diseñado deberia ser quien arme los test case en el requerimiento, el cliente no lo hace, a menos que se trate de una fabrica de software y el cliente solo contrate desarrollo... si cada uno cumple con su rol como corresponde, QA deberia limitarse a probar lo que se le especifico en los "test case"...

    para el documento de usuario (interno/externo), existe el perfil de documentador, y este se tiene que encargar de reunirse con todas las partes involucradas o necesarias y preguntar todo lo que necesite para poder realizar tal documento, pero un programador no debe hacer ningun documento salvo documentar el codigo en el mismo fuente (cosa que no siempre se aplica), o algun instructivo de instalacion o algo basico... lo mismo que las pruebas unitarias, que no es lo mismo que una prueba de QA, son pruebas basicas...

    ahora que en algunas empresas hayan recursos que sean multiroles, eso es otra cuestion diferente... pero cada role tiene su responsabilidad.

    -----Actualizado-----

    Cita Iniciado por Nathrezim Ver mensaje
    Precondicion y postcondicion de las funciones, la documentacion se debería hacer sola.

    Y lo de las interfaces, supongo que os dan libertad porque os referireis a los contratos entre componentes software, porque lo que es la interfaz gráfica tiene que venir especificada en un documento de requisitos firmado con sangre por el usuario.
    si, siempre tiene que venir firmado por el usuario/cliente en el requerimiento, y aprender a no salirse de eso en el momento de desarrollo, porque sino es un nunca acabar, al usuario nunca le gusta el tono de gris que usaste para el boton o la altura o tipo font del input X... asi que se especifica todo y eso se hace, no se sale de eso...

    totalmente...
    ...

  10. #25

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Uff qué waterfall suena eso

  11. #26

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    a que te referis con "waterfall" ?
    ...

  12. #27

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por SplinterGU Ver mensaje
    a que te referis con "waterfall" ?
    https://en.wikipedia.org/wiki/Waterfall_model
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  13. #28

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    gracias...

    y respondiendo a ^MiSaTo^, para nada, no necesariamente lo que dije tiene que ser Waterfall, por el contrario, muchas cosas se hacen en paralelo... igualmente hay cosas que no se pueden hacer sin que este la fase anterior terminada, QA no puede testear algo que esta en desarrollo, incluso testear algo que este en WIP, no se puede considerar como un test valido, ya que desarrollo puede romper algo que funcionaba y si lo testeas antes que este terminado, perdiste tiempo de QA... lo mismo desarrollar sin especificaciones... eso seria mas que nada investigacion que puede servir, pero no seria desarrollo final...
    ...

  14. #29

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,202
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    675
    Agradecer Thanks Received 
    1,847
    Thanked in
    Agradecido 1,264 veces en [ARG:2 UNDEFINED] posts
    ¿Existe la figura del "documentador"? ¿Que se encarga de leerse el código de los desarrolladores y de explicar lo que se ha hecho? ¿No es doble trabajo, teniendo al desarrollador que se conoce el código de memoria? No sé, me parece raro (y nunca oí hablar de él).
    Pero yo no hablo de un docmento tipo UML ni nada por el estilo, símplemente cosas como "para abrir un documento pulsar...", o "para crear un cuadro de texto hacer clic en tal, tal, y tal".

    Y cuando digo cambios en el código o la interfaz me refiero a que, yo que sé, que el cliente diga que quiere una ventana de "nuevo proyecto", y se le olvide incluir el campo "idioma" porque se puede cambiar en un submenú, pero es fundamental para el formato de las cadenas de texto de dicho proyecto, que no se pueden modificar tras crearlo (porque no exista una función o porque altere todo el contenido de la base de datos o lo que sea). Cosas que el cliente pide muy feliz, pero que el código no te deja o se vuelven muy rebuscadas.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  15. #30

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    ¿Existe la figura del "documentador"? ¿Que se encarga de leerse el código de los desarrolladores y de explicar lo que se ha hecho? ¿No es doble trabajo, teniendo al desarrollador que se conoce el código de memoria? No sé, me parece raro (y nunca oí hablar de él).
    Pero yo no hablo de un docmento tipo UML ni nada por el estilo, símplemente cosas como "para abrir un documento pulsar...", o "para crear un cuadro de texto hacer clic en tal, tal, y tal".

    Y cuando digo cambios en el código o la interfaz me refiero a que, yo que sé, que el cliente diga que quiere una ventana de "nuevo proyecto", y se le olvide incluir el campo "idioma" porque se puede cambiar en un submenú, pero es fundamental para el formato de las cadenas de texto de dicho proyecto, que no se pueden modificar tras crearlo (porque no exista una función o porque altere todo el contenido de la base de datos o lo que sea). Cosas que el cliente pide muy feliz, pero que el código no te deja o se vuelven muy rebuscadas.
    no el perfil documentador lo que hace es agarrar el documento de diseño/especificacion/producto (si existen), reunirse con el o los programadores, y con quien haga falta que haya estado en el proceso de produccion del producto, y preguntar, preguntar, agarrar el producto y usarlo, item por item, y va armando el documento de usuario/uso/detalles... cada reunion es corta, lo necesario para responder las preguntas y obtener algo otro dato util que salga de la charla y pueda servir como nota o detalle... redacta, formatea y demas del documento... y si es necesario volver a reunirse lo hace con las personas involucradas lo hace, pero de esta forma mantenes liberado a un recurso caro (como ser un programador) para seguir desarrollando y no perder tiempo en documentar... y te repito, una cosa distinta es documentar el codigo, en el fuente... eso no lo hace el documentador...

    claro que existe el perfil documentador... y es super util y productivo tener un perfil de esos en la estructura... agiliza, libera y le baja niveles de tension a los demas recursos, a ningun programdor le gusta hacer documentos de usuarios... las veces que toca hacer documentos a un programador, siempre es una tocada de huevos y se pierde mas tiempo del que se gana...

    -----Actualizado-----

    ah, y el documentador puede ir trabajando en paralelo con el desarrollo... no necesita que este terminado el desarrollo... luego puede ajustar una vez terminado el desarrollo.
    ...

Página 2 de 3 PrimerPrimer 123 ÚltimoÚltimo

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •