Quality Testing

Desde inicios del año pasado estoy trabajando con un equipo remoto en India. Mi trabajo es establecer objetivos en un testplan, coordinar el trabajo y fomentar buenas prácticas (definiendo como se hacen las cosas y microprocesos). A decir verdad aprendí bastante durante este último año, es algo difícil pero una vez que uno se acostumbra se pueden lograr muchas cosas.

Para empezar voy a describir los puntos que hay que tener en cuenta:

• Diferencias de tiempo: En mi caso el equipo remoto termina su día cuando yo empiezo el mío.
• Idioma: Si bien uno puede tener un buen nivel de inglés, a veces lleva un tiempo acostumbrarse a ciertos acentos
• Cultura: Muchos paises dondese terceariza suelen tener diferente forma de encarar el trabajo y tomar decisiones
• Tamaño de empresas involucradas: Las empresas donde se terceariza suelen ser muy grandes. En mi caso mi empresa es mediana y la tercearizada es enorme, así que suelen notarse diferencias entre la forma de trabajar de sus empleados y la mia.
• Medio de comunicación: Puede ser algo que parezca simple, pero hay que acostumbrarse a usar exclusivamente mails, teléfono, gtalk o similar, etc…No es lo mismo tener la posibilidad de explicar algo en persona que remotamente.

Consejos:

• Siempre organizarse durante el día una hora para preparar el trabajo que se quiere para el otro día.
• Llevar una planificación estimativa de las tareas para realizarse durante la semana.
• Tener directamente un “buffer” de tareas para cada persona ordenadas por prioridad. De esta forma si hay algún bloqueo con alguna tarea pueden pasar a la siguiente y no se tiene el recurso inactivo durante un día u horas.
• Mandar un mail diario a los integrantes del equipo remoto estableciendo objetivos y pautas para el día siguiente.
• Siempre establecer objetivos claros, explicando paso a paso como se quiere realizar una tarea. La forma más efectiva es hacer uno y que repitan el estilo (ejemplo, automatizacion de casos. Se automatiza uno y que el resto lo automaticen de esa misma forma)
• Asignar una parte de nuestro día para revisar el trabajo realizado por el equipo remoto.
• Hablar por teléfono a diario con el equipo remoto, al comienzo o al final de su día.
• Mantener wikis con templates y guías.
• Hacer que el equipo remoto documente en wikis, de esta forma si sacan un recurso de nuestro proyecto perderemos lo menos posible el conocimiento adquirido por esa persona.
• Tratar de mantener el expertise dentro del equipo local y no el remoto.
• Tener un calendario con los feriados del país donde se terceariza y mantener un calendario con las vacaciones de los integrantes del equipo.
• Asignar tareas con ticket, de esta forma es mas fácil de hacer un seguimiento del trabajo realizado o las tareas a realizar.

REMOTE TEAMS

From the beginings of the last year I’ve been working with a remote team located in India. My work is to establish objectives in a testplan, coordinate the work and encourage the team to follow good practices (defining how to do things and setting small processes). To be honest, I learned a lot during this last year, it is something difficult, but once you get use to it you can do a lot of things.
I’m going to start describing some points:
* Time differences: In my case, when I get to the office, the remote team is leaving.
* Language: Even if you have a good english level, it takes some time to get use to some accents.
* Culture: Some cultures has different ways to work and to take decisions.
* Size of the companies involved: In general, the offshore companies are very large. In my situation, my company is a mid size company and the offshore is huge, so it is not weird to see some differences in the work metodology.
* Comunication: This may sound simple, but it is important to use only mails, phone, gtalk or similar, etc… It is not the same to have the change to explain something personally to do it remotely.

Advices:
* Assign one hour during the day to prepare the work required to the next day.
* Follow an estimated plan of tasks to follow during the week.
* Create a buffer of tasks ordered by priority for each member of the team. With this, if there is any blocking issue with one of the task, they can go to the next one and so on.
* Assign some time of our day to review the work done by the remote team.
* Mantain a daily call with the remote team.
* Create wikis with templates and tutorials.
* Make the remote team to document everything into wikis, the idea is to mantain the knoledge in case of we loose that resource from the remote team.
* Try to keep the expertise in the local team, not into the remote one.
* Keep a calendar with the holidays from the remote country and the vacations of the team members.
* Assign the work in tickets, this will make easier to follow the progress of the work or to see the pending tasks.

Estamos armando un nuevo equipo para un producto nuevo que lanzamos en la empresa donde trabajo: www.coresecurity.com

Las posiciones abiertas son:

* Tester de automatización

* Ingeniero de testing

* Lider de testing

Todas las posiciones son para trabajar en Buenos Aires, en el barrio de Palermo. Es una excelente oportunidad, si ven que su perfil matchea alguno de estos que puse arriba por favor contactarme o mandar un mail a la dir del link.

El viernes 5 de Febrero pasé el examen de la certificación ISTQB (International Software Testing Qualification Board), contestando correctamente un 83% de las preguntas.El examen es multiple choice y consta de 40 preguntas, y el tiempo para responderlas es de 60 minutos. Para aprobar hay que responder un mínimo del 65% del total de las preguntas.

Para estudiar recomiendo el libro “Software Testing Foundations – Andreas Spillner, Tilo Linz, Hanz Schaefer”. Este link lleva a la página en Amazon. Por otro lado se puede bajar un syllabus que es de gran utilidad en este link.

On Feb 5th I successfully approved the certification exam from ISTQB (International Software Testing Qualification Board), with a score of 83%.The exam is multiple choice and consists in 40 questions, witch must be answered in 60 min. To approve it is necessary to correctly answer the 65% of the questions.

To study, I recommend the book ”Software Testing Foundations – Andreas Spillner, Tilo Linz, Hanz Schaefer”. This link goes to the book page in Amazon. You can find a syllabus in this link.

Es común que suceda que muchas veces nos esforzamos en trabajar en algo que al final nos hace que nos lleve mas tiempo llegar a cumplir nuestro objetivo. El fin de testear es encontrar bugs o asegurar que el producto funcione correctamente, esto lo tenemos que hacer cubriendo la mayor parte del producto en el menor tiempo posible.Con respecto a la desición de automatizar o no se pueden cometer dos errores:

• Podemos esforzarnos en correr casos manualmente que en realidad si los automatizamos, podemos reducir notablemente el tiempo de ejecución.
• Tomar la desición de automatizar algo que en realidad no vale la pena automatizar, ya sea porque es un test demasiado simple o porque se va a ejecutar sólo una vez.

Por eso es importante discernir cuando o no automatizar. Supongamos que tenemos un test suite que su ejecución nos llevaría 5 días y que durante el testing del producto lo debemos correr 2 veces (primer ejecución + regresión hacia el final del testing). Nos quedarían 10 días de ejecución manuales. En este caso nos conviene evaluar automatizar: dedicamos 5 días a automatizar los casos y supongamos que reducimos la ejecución de 5 días a 1 día. Terminamos usando 7 días de trabajo vs los 10 días estimados manuales, y no sólo eso, la próxima vez que haya que hacer una regresión de este feature tenemos los tests automáticos listos para correr las pruebas rápidamente, pudiendo dar una respuesta de que tan estable esta el feature o no.Por otro lado si tenemos un feature que nos lleva 1 día correr manualmente y que no se volverá a testear, en este caso nos conviene directamente correrlo manualmente. Muchas veces también puede suceder que se requiere de un ambiente demasiado complejo y es realmente necesario que una persona monitoree las pruebas, ahí si: corramos el test suite manualmente.It is common that happens that many times we put a lot of effort in working in something that at the end will make us waste our time in achieving our objective. The objective of testing is to find bugs or ensure that the product works properly, and we must do this covering the most part of the product in the less time possible.In deciding when to automatize or not we can make two different mistakes:

•  We can effort in running the testcases manually but if we automatize we can reduce notably the time of execution.
•  We can make the decision write automated scripts in something that it not worth it, this can be because it is a very simple test or it will be executed only once.

That’s why it is important to decide when automatize or not. Let’s suppose that we have a test suite that it’s execution take 5 days and during the testing of the product we must run it 2 times (firts execution + regression at the end of the testing). It will take us 10 days of manual testcase execution. In this situation we must automatize: we use 5 days to automatize the testcases and let’s suppose that with this automated tests we reduce the execution time from 5 days to 1 day. We will end up using 7 days of work vs 10 days estimated if we were doing all manually, and not just that, the next time that we needed to run the tests again we will have our automated scripts to give a quick answer of the stability of the feature.On the other hand, if we have a feature that will take us 1 day to run it manually and it will not be tested again in the future we must run it manually. It can also happen that a complex environment is required and it is really necessary to put a human to check the tests, in that case we need to run the test manually too.

Cada tanto veo que hay testers que no tienen lo necesario para este trabajo. Muchas veces son personas que no les interesa demasiado pero quieren ganar dinero, entonces no se esfuerzan en adquirir conocimientos o en innovar. Esto luego lleva a que las cosas no se hagan como correspondan o que al hacer cambios en el proceso de testing, les lleve mas tiempo o no se adapten.

Bien, yo pienso que un tester debe tener por un lado ciertos conocimientos y por otro ciertos skills “soft” que le permitan desarrollarse correctamente en el puesto. Obviamente los conocimientos pueden variar de acuerdo a lo que esté testeando o la empresa para la que trabaje. Pero en general sería útil que sepa:

• Técnicas de testing (obviamente)
• Conocimientos de networking
• Conocimientos de programación (preferentemente en el lenguaje en el que está hecha la aplicación que se está probando)
• Conocimientos de sistemas operativos
• Conocimientos de bases de datos (SQL)
• Debe tener la capacidad de apoyarse en lenguajes de scripting para facilitar o automatizar tareas
• Inglés (esto es importante, hoy muchas empresas tienen su casa central en EEUU u otros países de habla inglesa

También se necesitan ciertos skills generales como:

• Debe poder comunicarse correctamente, escribiendo y hablando. Es importante que pueda describir problemas de una forma precisa y reducida.
• Es importante tener una personalidad analítica.
• Debe ser metódico y ordenado.
• Debe poder lograr un buen trato con los desarrolladores, debe ser diplomático. Si alienta peleas con éstos se puede complicar el trabajo o peor, la relación entre el area de calidad y desarrollo.
• Debe tener una alta capacidad de aprendizaje. Tanto para conocimientos técnicos nuevos que pueden ser requeridos para el testing de un producto en particular, como de la lógica de negocios que tiene el producto que se esta probando.
• Debe tener una mente técnica, interesarse en los cambios en la tecnología informática y seguirlos. De esta forma cuando la tecnología de las aplicaciones cambie, el tester va a estar al tanto, pudiendo entender como funciona la aplicación y no siendo un mono que presiona controles.

En cuando a la carrera universitaria, opino que debe ser una carrera de informática. Siempre vamos a estar testeando software y siendo informáticos podemos entender como se hace y como funciona. Si ponemos a cualquier otra persona que entienda sólo la lógica del negocio de la aplicación solamente va a testear ciertos aspectos funcionales y no globalemente el producto.

Se que es probablemente difícil conseguir a un tester con tantos skills, pero si se logra, se tendrá un equipo de testing sumamente profesional y entre ellos se sentirán a gusto, porque su equipo estaría compuesto por gente que realmente sabe lo que hace. El hecho de pertenecer a un equipo profesional motiva a sus integrantes.

Sometimes I meet testers that they don’t have what it takes to do this job. Most of the times, they are people that they are not much interested in this field, but they want to make money, so they don’t make any efforts in order to aquire knoledges or to innovate. This leads to mediocre perfomances or if we make some changes in the testing process, they will probably cost the doble of time to adapt or not adapt at all.
Well, I think that a tester must have some particular knowledges and in some soft skills to be a good tester. Obviously the knowledges can be diverse, depending on the application under test or the company. But in general this is what a tester should know:

• Testing techniques (obviously)
• Networking
• Programming (Preferably the languaje of the application under test)
• Operating systems
• Databases (SQL)
• He must have the ability of use scripting languages to make easier some tasks or for automation propourses.
• English (most of the companies are based in english speaking countries). For english speakers, it could be usefull to learn another language.

Some soft skills are also needed:

• He has to be able to communicate himself correctly, writing and speaking. This is importanto so he can describe the problems in a reduced and precise way.
• Analytic personality.
• Methodical and organized.
• He must be able to have a good relationship with the developers, to be diplomat. If the tester encourage fights with them the work can become complicated or worst: the relation between the quality area an development can be affected.
• It is important to have high learning ability. This goes for new technologic knoledges that could be required for the testing of a particular product, or the bussiness logic of the product under test.
• A technical mind is important. If the tester is interested in the changes of the computer technology, he will be able to understand how the product under test works and not simply be a monkey pressing controls.

Regarding the university career, I think that it is very important that the tester must study some computer science career. We are always going to test software so if we study that we will be able to understand how the software is made and how it works internally. If we put any other person that only understands the bussiness logic of the app, this person will only test the functional aspects of the application and not the app globally.

I know that it is complicated to find a tester with all this skills, but it is find, the testing team will be highly professional and they will feel comfortabl, because their team will be composed by people that really knows what they do. The fact of belong to a professional team motivates the members of the team.

Los testers realizamos un trabajo en el que es importante estar descansados y atentos. Sino se nos empiezan a escapar cosas y muchos defectos que podrían ser encontrados a tiempo y tener ser reparados a un bajo costo se encontrarán en producción, aumentando así el costo de su reparación y hasta perjudicando la imagen del producto/empresa.

Algo muy interesante es el síndrome del burnout o quemado. Esto sucede cuando la persona trabaja durante largos períodos de tiempo sin descansar. No me refiero a que duerma pocas horas al día, sino trabajar durante todo un año sin un corte, sin vacaciones.

Esto puede afectar negativamente al tester. Un tester responsable tal vez puede tratar de evitar que esto afecte su desempeño, pero lidiar con este problema y además mantener el mismo nivel de eficiencia es muy difícil.

El sindrome del burnout puede causar en una persona:

- Sensación de que el trabajo nunca se termina, que se vive para el trabajo

- Cansancio, incluso luego de haber dormido la cantidad correcta de horas

- Depresión y desgano

- Stress

- A nivel corporal: insomnio, dolor de cabeza, mareos, dolores musculares, trastornos digestivos, infecciones, manchas en la piel, trastornos respiratorios y circulatorios o variaciones en el peso.

La solución para esto es simple: VACACIONES. Todos los años hay que tomarse vacaciones y descansar debidamente durante al menos dos semanas. También asegurarse de hacer cosas durante el tiempo libre que se tiene para despejar la mente.

El software no tiene materia prima. De un conjunto de personas se saca un producto que se vende. Así que la principal máquina de esta industria es el ser humano. Si un manager no cuida sus recursos, su área no va a producir lo esperado, por lo que es importante asegurarse de que la gente que dirige se tome las vacaciones cuando es debido. También es responsabilidad de cada persona saber cuando cortar y no sobreexigirse innecesariamente.

The kind of tasks that a tester perform, requires to rest and be alert.  If we don’t rest some defects should not be found at time and the cost of their repair will be too much in production and it will even affect the image of the product or the company.

There is a disease called burnout sindrome. This ocurrs when a person works for long periods of time without a rest in between. I’m not talking about not resting enough at night, it’s about working a whole year without a cut in the activities, without a vacation.

This can affect the tester in a very negative way. A responsible tester maybe will try to avoid this to affect their performance, but dealing with this problem and keep up with the same working level could be very difficult.

The burnout sindrome may cause:

- The feeling that the work never ends, that the life consist in only working

- Tiredness, even when sleeping the correct amount of hours every day.

- Depression.
- Stress.

- From the body perspective: insommnia, migranies, muscular pain, digestive failures, infections, spots in the skin, breeding problems and changes of weight.

The solution for this is simple: VACATIONS. Every year it is important to take vacations and rest properly for at least two weeks. It is also important to do some thinks during the free time to clear the mind (e.g. some hobby)

The software doesn’t need any raw material to be created. From a bunch of people a product is created and it is sold. So the raw material of the machine of this industry is a person. If a manager doen’t take care of his resources, his area will not produce what it is expected to produce, so he should make sure that his people take vacations regularly. It is also important that each tester make a cut in his work when it is convenient and not to work excessively.

Algo que no puedo evitar mirar ofertas de trabajo en internet. Es un buen ejercicio para ver que es lo que se pide en el mercado y que tan activo está. Lo que últimamente noto es que muchas veces se piden cosas como “experiencia de manejo de rational robot” o “experiencia automatizando con quicktest”, estas son creo que las dos herramientas de automatización más caras y más populares. Supongamos que aparece un analista que trabajó con otras herramientas de automatización menos populares (por ejemplo testcomplete de automated QA) o directamente se tomaron el trabajo de usar lenguajes de scripting como python o ruby para crear su propio framework de automatización. Probablemente la gente de RRHH a cargo de esa búsqueda lo descartará inmediatamente, pero se está perdiendo de un recurso valiosísimo con experiencia en automatización o más aún si se dedico a crear su framework. Para mi esto no es culpa de la gente de RRHH sino de quien pide la búsqueda. Tal vez la empresa se maneje con esa herramienta de automatización, pero no deberían excluír a quienes no la manejen.

El punto de esto es que si uno requiere algún tester para automatizar, debería mirar más allá y no buscar solo a  quienes manejen una herramienta en particular. Considero más valioso a quien se hizo su framework a quien uso durante un tiempo el rational robot para automatizar. O también una persona con experiencia en TestComplete podría manejar el rational robot sin problemas. Hace poco tuve la oportunidad de probar varias herramientas de automatización (ranorex, rational robot, testcomplete, silktest y quicktest) y la verdad que testcomplete me gustó mucho mas que las otras y no tiene nada que envidiarles.

Por eso es importante valorar más la experiencia de automatización de la persona que la experiencia con un software en particular.

The use of certain automation tool is required…

I always look the job opportunities in internet as an exercise. This is good to see what’s going on in the market. Lately I’ve noticed job posts looking for people with “experience with rational robot” or “experience with quicktest”, theese are probalby the most popular and expensive automation tools. What if an analyst apply for this with experience in another automation tools not that popular (for example TestComplete of automated QA) or he just developed his own automation framework using a scripting languaje like python or ruby. Probably the people from RRHH will discard this guy inmediatly, but they’re loosing a very valuable resource with experience in automation or in testing framework development. However, this is not the fault of RRHH, it is fault of who requested the search. The company surely use that automation tool but it shouldn’t exclude the people with experience in automation but who don’t use that tool.

The thing is,  if an automation tester is required, it is important not to look only for people who had experience using a particular tool. It is most valuable the guy who made his framework than the guy who only used rational robot for a while. Or also the guy who used TestComplete could use rational robot without any problem. Recently, I had the oportunity of try many automation tools (ranorex, rational robot, testcomplete, silktest and quicktest) and truly I thing that testcomplete is good as the others (or maybe better).

That’s why it is more important the experience in automation than the experience with a particular tool.

Me confirmaron en la empresa en la que trabajo que me van a enviar a STAREAST. Voy a estar toda la semana (del 5 al 9) asistiendo a las diferentes charlas. Afortunadamente voy a asistir a los dos tutorials days, tengo planeado ir a:

Lunes:

Test Automation Patterns: Best Practices and Common Pitfalls

Managing Keyword-Driven Test Automation

Martes:

Requirements-Based Testing

El resto de los días voy a asistir a diferentes charlas más cortas. El primer día son dos tutoriales de medio día y el segundo es un tutorial que dura todo el día.

Si alguien va y quiere contactarme pueden mandarme un mail a jmoschino@gmail.com

I’M GOING TO STAREAST!

My company will send me to STAREAST. I’ll be there the whole week (from May 5th 9) in the different conference events. I’m also going to two tutorial days:

Monday:

Test Automation Patterns: Best Practices and Common Pitfalls

Managing Keyword-Driven Test Automation

Tuesday:

Requirements-Based Testing

The rest of the days I will assist to many other small lectures. The first day will be two half-day tutorials and the second a full day tutorial.

If someone is going to STAREAST and want to contact me, send me an email to jmoschino@gmail.com

I’ve started this blog in spanish, but now I will write my articles also in english.

The old articles will be translated in the future so be patient!. It will take me some time to do that.

En el libro Lessons Learned in Software Testing hay un capítulo en el cual exclusivamente se dedican a dar consejos para quienes deciden seguir carrera en testing. A continuación muestro un resumen de dicho capítulo con las partes más interesantes.

1. Elije un camino y síguelo: Los dos típicos caminos en testing son los técnicos y los mas referidos al management. Muchas veces se puede escalar de las posiciones técnicas a posiciones de management. Por ejemplo, un Black box tester puede ser algún día un test manager o un test lead y a su vez este puede escalar a posiciones fuera de testing como un project manager (por supuesto todas las escaladas de posición se dan no sólo con experiencia sino con la capacitación adecuada).

2. Los ingresos percibidos por los testers pueden ser mayores a los programadores: Tradicionalmente, los testers siempre cobraron menos dinero que los programadores que poseen la misma cantidad de años de experiencia. Esto cambió últimamente. Por lo general los testers con más habilidades técnicas hoy son más cotizados (y por lo tanto mas difíciles de conseguir) entonces en algunos casos suelen cobrar más que algunos programadores.

3. Sientete libre de cambiar de camino y perseguir algo distinto: No estás encerrado en testing. No estas encerrado en un rol de management ni en una compañia ni en un trabajo. Si quieres moverte a un área diferente simplemente toma cursos y aprende lo necesario.

4. Cualquiera sea el camino que elijas, síguelo activamente: Esta es tu carrera. Tu compañia o tu manager pueden que esten dispuestos a ayudarte a planear tu carrera, y puede que sean buenos en ello. O no. Si tienes una dirección, las habilidades y la determinación, tu compañía pagará por cursos y te dejará intentar nuevas cosas.
Algunas compañías pagan cursos y otras no. Debes pensar que tu eres quien construye tu propia carrera. Obtén lo que necesites y lo que te interese. Si debes gastar dinero, piénsalo como una inversión. En cuanto ganas nuevas habilidades te tornas más valioso para la compañia o para una futura compañia que elijas.

5. Extiende tu carrera más allá de software testing: Pasar el tiempo buscando y criticando los errores de las otras personas nos envejece. Probar nuevas áreas del desarrollo de software da nuevas perspectivas.
Los managers que fueron multifuncionales son muy valiosos en muchas compañías.

6. Extiende tu carrera más allá de tu compañía: Es TU carrera. Si tu compañia desaparece mañana tú sigues ahí, y tu carrera sigue ahí. Afuera de la compañia hay una enorme comunidad de software testers y aún más grande comunidad de developers.
Puedes involucrarte en la comunidad de diversas maneras. Una forma es ir a las conferencias.

7. Las conferencias son para intercambiar ideas: Cuando se asiste a una conferencia no solo se va a oir las sesiones sino que también se va a discutir con las otras personas que asisten las diferentes presentaciones.

8. Muchas otras compañias tienen tantos problemas como la tuya: Muchos testers quedan horrorizados con los bugs en sus productos y la confusión en sus compañias. Esta no es una situación inusual, incluso en las mejores compañías. Los testers ven que está sucediendo algo malo y esto no es siempre gracioso.
Por lo general las compañías que realmente andan mal no tienen testers siquiera. Para tener una perspectiva de que tan mal andan las cosas lo mejor es tener un contacto con otros testers de otras compañías.

9. Si no te gusta tu compañia, busca un nuevo empleo: Si sientes que tu trabajo actual no te permite crecer, no estás ganando lo que necesitas o que el ambiente no es propicio, es hora de que evalúes un cambio.

10. Estate preparado en caso que debas apostar tu trabajo (y perderlo): Siempre es bueno tener el CV listo y mantenerlo actualizado en caso de que pase algo. Si es posible tener buenas relaciones con recluiters que estén al tanto de los openings de testing y de cuanto se está ofreciendo en el mercado.

11. Construye y mantiene una lista de compañías donde te gustaría trabajar

12. Construye un portfolio: Es muy útil tener una colección de código, documentos y otros trabajos de ejemplo que demuestren tu experiencia.

13. Usa tu CV como una herramienta de ventas: Tu CV te excluye de algunos trabajos y te incluye en otros.
- Si estás interesado en diferentes tipos de trabajos escribe distintos CVs.
- Prepara un CV histórico. Este describe tu experiencia en orden, de trabajo en trabajo mostrando tus logros en cada uno.

14. Consigue un referido interno: Muchas empresas dan a sus empleados bonos por referir candidatos que son contratados. Si conoces a un empleado de la compañía a la que quieres entrar tienes más información de la compañía y más feedback durante el proceso de entrevista.

15. Investiga sobre salarios

16. Toma ventaja de oportunidades de entrevistas: Por más que te llamen para una entrevista de un trabajo que mucho no te convenga, tal vez no sea mala idea asistir de todas maneras. Tómalo como una forma de practicar para una entrevista más seria.

17. Aprende sobre las compañías cuando te postulas a algun empleo en ellas: Además de toda la búsqueda en los respectivos sites y en buscadores que se puede encontrar en internet sobre las compañías, si te llaman para una entrevista pide información del producto, demos del producto u otra información extra de la compañía.

18. Haz preguntas durante las entrevistas

19. Negocia tu posición.

20. Ten cuidado con Recursos Humanos: No son quienes deciden quienes son contratados, así que no pierdas demasiado tiempo negociando con ellos.

21. Aprende Perl, Java, C++ (Python o Ruby pueden ser extremadamente útiles también y fáciles de aprender)

22. Baja copias de prueba de herramientas de testing y pruébalas.

23. Mejora tus habilidades de escritura.

24. Mejora tus habilidades de oratoria.

25. Piensa en certificarte.