Performance Testing

Quisiera empezar con las definiciones básicas utilizadas en todo lo referido a las pruebas de carga y performance Testing (Performance & Load Testing).
Performance Testing
Definición según la IEEE:
“El grado en que un sistema o componente realiza sus funciones designadas dentro de las limitaciones dadas, tales como la velocidad, precisión, o el uso de la memoria.”
Enfocadas en ¿Cuanto? y ¿Que tan rápido? funciona la aplicación, no se hace juicio de la aplicación solo se mide y analiza.
Durante estas pruebas no se busca encontrar errores, pero si se busca enfocarse en procesos individuales de la aplicación  (Base de Datos, Algoritmos, Red, etc…) en busca de probables cuellos de botella (Les dejo una presentación sobre esto realizada por Scott Barber) y poder determinar una base a considerar en futuros cambios de la aplicación.
Se considera como principal objetivo, predecir anticipadamente problemas de rendimiento y degradación de recursos del sistema antes de su paso a producción y así facilitar su corrección.
Puede implicar pruebas cuantitativas realizadas en un laboratorio (tiempo de respuesta de la aplicación, rendimiento, etc ..) así como  también pruebas cualitativas como confiabilidad, escalabilidad y la interoperabilidad.
Se espera que las pruebas se realicen sobre una aplicación estable sonde sea posible la ejecución de los distintos escenarios que se consideren críticos (telemarketer que necesita información rápidamente para poder realizar la venta) o frecuentes (lo que implica mayor cantidad de usuarios concurrentes y una necesidad de disponibilidad de la aplicación) desde el lado del negocio. Además es vital tener objetivos claros para poder definir correctamente las métricas que vamos a utilizar y como las vamos a utilizar.
Performance Validation es la etapa donde se apunta a medir si se cumplen con los requerimientos establecidos por el cliente, donde se juzga los resultados medidos y analizados para poder determinar el porque y como solucionar estos. Se estima que en el 80 % de los casos los problemas de performance se deben a una incorrecta elección de la arquitectura de la aplicación. Para prevenir estos  casos existe PASA (Ver).
Performance Engineering es la etapa final donde se realizan los cambios necesarios (tunning) para alcanzar lo esperado por la aplicación, esto puede incluir cambios de codigo, hard o red entre los principales para luego ser testeado nuevamente.
Les dejo una presentación que realice sobre Performance Testing, pueden bajarla aqui
Conceptos más puntuales:
Availability:  El grado en que un sistema es funcional, estable y eficiente. Se mide por el tiempo de funcionamiento (el tiempo entre fallos).
Baseline: Referencia del rendimiento del sistema utilizada para comparar el rendimiento contra otras / pruebas de carga.
Capacity Planning: La medición, la previsión y la planificación para el crecimiento del sistema en el tiempo.
Latency: El tiempo de retraso entre el momento en que se inicia una transacción y el momento en que se completa. A veces se denomina tiempo de respuesta en forma incorrecta, ya que forma parte del tiempo de respuesta latency + Processing Time= Response time pero no es igual al tiempo de respuesta.
Load: La cantidad de demanda o de trabajo en un sistema. Para una aplicación web, esto significa transacciones de usuarios concurrentes o conexiones.
Reliability: La capacidad de un sistema para ser funcional, estable y eficiente, tanto en circunstancias de rutina como en condiciones adversas.
Scalability: La capacidad de un sistema para crecer a la par de la carga sobre este o  de incrementar su capacidad. Esta se mide por los cambios de uso de recursos como unidades de trabajo al crecer en número o tamaño. El último objetivo es que el rendimiento tenga una escalabilidad lineal, lo que significa que el rendimiento disminuye a un ritmo constante en relación con la carga.
Test Harness: Un programa informático utilizado para realizar pruebas y recoger los resultados.
Throughput: La tasa de operaciones por unidad de tiempo.
Virtual User: Un usuario creado para aplicar la carga a un sistema. Cada usuario virtual simula las acciones reales de los usuarios mediante el envío de peticiones HTTP a un servidor de la misma manera que un cliente.

Bottleneck: Punto donde la congestión y los retrasos se producen en una aplicación, ralentizando la tramitación de las solicitudes y causando que los usuarios experimenten retrasos inaceptables en el servicio.

Profiling: Recolección de datos sobre el funcionamiento de la aplicación. Ejemplos Jprofiler, JProbe, JXInsight y dynaTrace.


http://josepablosarco.wordpress.com/performance-testing/

How to Test Application Security – Web and Desktop Application Security Testing Techniques

Need of Security Testing?
Software industry has achieved a solid recognition in this age. In the recent decade, however, cyber-world seems to be even more dominating and driving force which is shaping up the new forms of almost every business. Web based ERP systems used today are the best evidence that IT has revolutionized our beloved global village.
These days, websites are not meant only for publicity or marketing but these have been evolved into the stronger tools to cater complete business needs. Web based Payroll systems, Shopping Malls, Banking, Stock Trade application are not only being used by organizations but are also being sold as products today.
This means that online applications have gained the trust of customers and users regarding their vital feature named as SECURITY. No doubt, the security factor is of primary value for desktop applications too. However, when we talk about web, importance of security increases exponentially. If an online system cannot protect the transaction data, no one will ever think of using it. Security is neither a word in search of its definition yet, nor is it a subtle concept. However, I would like to list some complements of security.

Examples of security flaws in an application:

1) A Student Management System is insecure if ‘Admission’ branch can edit the data of ‘Exam’ branch
2) An ERP system is not secure if DEO (data entry operator) can generate ‘Reports’
3) An online Shopping Mall has no security if customer’s Credit Card Detail is not encrypted
4) A custom software possess inadequate security if an SQL query retrieves actual passwords of its users
Security Testing Definition:
Now, I present you a simplest definition of Security in my own words. “Security means that authorized access is granted to protected data and unauthorized access is restricted”. So, it has two major aspects; first is protection of data and second one is access to that data. Moreover, whether the application is desktop or web based, security revolves around the two aforementioned aspects. Let us have an overview of security aspects for both desktop and web based software applications.
Desktop and Web Security Testing:
A desktop application should be secure not only regarding its access but also with respect to organization and storage of its data. Similarly, a web application demands even more security with respect to its access, along with data protection. Web developer should make the application immune to SQL Injections, Brute Force Attacks and XSS (cross site scripting). Similarly, if the web application facilitates remote access points then these must be secure too. Moreover, keep in mind that Brute Force Attack is not only related to web applications, desktop software is also vulnerable to this.
I hope this foreword is enough and now let me come to the point. Kindly accept my apology if you so far thought that you are reading about the subject of this article. Though I have briefly explained software Security and its major concerns, but my topic is ‘Security Testing’. In order to know further details of security aspects, kindly refer to – Web application security testing article.
I will now explain how the features of security are implemented in software application and how should these be tested. My focus will be on Whats and Hows of security testing, not of security.

Security Testing Techniques:

1) Access to Application:

Whether it is a desktop application of website, access security is implemented by ‘Roles and Rights Management’. It is often done implicitly while covering functionality, e.g.in a Hospital Management System a receptionist is least concerned about the laboratory tests as his job is to just register the patients and schedule their appointments with doctors. So, all the menus, forms and screen related to lab tests will not be available to the Role of ‘Receptionist’. Hence, the proper implementation of roles and rights will guarantee the security of access.
How to Test: In order to test this, thorough testing of all roles and rights should be performed. Tester should create several user accounts with different as well multiple roles. Then he should use the application with the help of these accounts and should verify that every role has access to its own modules, screens, forms and menus only. If tester finds any conflict, he should log a security issue with complete confidence.

2. Data Protection:

There are further three aspects of data security. First one is that a user can view or utilize only the data which he is supposed to use. This is also ensured by roles and rights e.g. a TSR (telesales representative) of a company can view the data of available stock, but cannot see how much raw material was purchased for production.
So, testing of this aspect is already explained above. The second aspect of data protection is related to how that data is stored in the DB. All the sensitive data must be encrypted to make it secure. Encryption should be strong especially for sensitive data like passwords of user accounts, credit card numbers or other business critical information. Third and last aspect is extension of this second aspect. Proper security measures must be adopted when flow of sensitive or business critical data occurs. Whether this data floats between different modules of same application, or is transmitted to different applications it must be encrypted to make it safe.
How to Test Data Protection: The tester should query the database for ‘passwords’ of user account, billing information of clients, other business critical and sensitive data and should verify that all such data is saved in encrypted form in the DB. Similarly (s)he must verify that between different forms or screens, data is transmitted after proper encryption. Moreover, tester should ensure that the encrypted data is properly decrypted at the destination. Special attention should be paid on different ‘submit’ actions. The tester must verify that when the information is being transmitted between client and server, it is not displayed in the address bar of web browser in understandable format. If any of these verifications fail, the application definitely has security flaw.

3. Brute-Force Attack:

Brute Force Attack is mostly done by some software tools. The concept is that using a valid user ID, software attempts to guess the associated password by trying to login again and again. A simple example of security against such attack is account suspension for a short period of time as all the mailing applications like ‘Yahoo’ and ‘Hotmail’ do. If, a specific number of consecutive attempts (mostly 3) fail to login successfully, then that account is blocked for some time (30 minutes to 24 hrs).

How to test Brute-Force Attack: The tester must verify that some mechanism of account suspension is available and is working accurately. (S)He must attempt to login with invalid user IDs and Passwords alternatively to make sure that software application blocks the accounts that continuously attempt login with invalid information. If the application is doing so, it is secure against brute-force attack. Otherwise, this security vulnerability must be reported by the tester.
The above three security aspects should be taken into account for both web and desktop applications while, the following points are related with web based applications only.

4. SQL Injection and XSS (cross site scripting):

Conceptually speaking, the theme of both these hacking attempts is similar, so these are discussed together. In this approach, malicious script is used by the hackers in order to manipulate a website. There are several ways to immune against such attempts. For all input fields of the website, field lengths should be defined small enough to restrict input of any script e.g. Last Name should have field length 30 instead of 255. There may be some input fields where large data input is necessary, for such fields proper validation of input should be performed prior to saving that data in the application. Moreover, in such fields any html tags or script tag input must be prohibited. In order to provoke XSS attacks, the application should discard script redirects from unknown or untrusted applications.
How to test SQL Injection and XSS: Tester must ensure that maximum lengths of all input fields are defined and implemented. (S)He should also ensure that defined length of input fields does not accommodate any script input as well as tag input. Both these can be easily tested e.g. if 20 is the maximum length specified for ‘Name’ field; and input string “<p>thequickbrownfoxjumpsoverthelazydog” can verify both these constraints. It should also be verified by the tester that application does not support anonymous access methods. In case any of these vulnerabilities exists, the application is in danger.

5. Service Access Points (Sealed and Secure Open)

Today, businesses depend and collaborate with each other, same holds good for applications especially websites. In such case, both the collaborators should define and publish some access points for each other. So far the scenario seems quite simple and straightforward but, for some web based product like stock trading, things are not so simple and easy. When there is large number of target audience, the access points should be open enough to facilitate all users, accommodating enough to fulfill all users’ requests and secure enough to cope with any security-trial.
How to Test Service Access Points: Let me explain it with the example of stock trading web application; an investor (who wants to purchase the shares) should have access to current and historical data of stock prices. User should be given the facility to download this historical data. This demands that application should be open enough. By accommodating and secure, I mean that application should facilitate investors to trade freely (under the legislative regulations). They may purchase or sale 24/7 and the data of transactions must be immune to any hacking attack. Moreover, a large number of users will be interacting with application simultaneously, so the application should provide enough number access point to entertain all the users.
In some cases these access points can be sealed for unwanted applications or people. This depends upon the business domain of application and its users, e.g. a custom web based Office Management System may recognize its users on the basis of IP Addresses and denies to establish a connection with all other systems (applications) that do not lie in the range of valid IPs for that application.
Tester must ensure that all the inter-network and intra-network access to the application is from trusted applications, machines (IPs) and users. In order to verify that an open access point is secure enough, tester must try to access it from different machines having both trusted and untrusted IP addresses. Different sort of real-time transactions should be tried in a bulk to have a good confidence of application’s performance.  By doing so, the capacity of access points of the application will also be observed clearly.
Tester must ensure that the application entertains all the communication requests from trusted IPs and applications only while all the other request are rejected. Similarly, if the application has some open access point, then tester should ensure that it allows (if required) uploading of data by users in secure way. By this secure way I mean, the file size limit, file type restriction and scanning of uploaded file for viruses or other security threats. This is all how a tester can verify the security of an application with respect to its access point.

http://www.softwaretestinghelp.com/how-to-test-application-security-web-and-desktop-application-security-testing-techniques/

Desarrollo de software. El analista funcional y el analista orgánico

¿Qué tareas realiza un analista funcional?, ¿cuáles un analista orgánico?. Depende de la entidad en la que trabajen y del proyecto en sí, la limitación de las funciones de cada uno.
Por regla general, se considera analista funcional a quien se encarga de la recopilación del catálogo de requisitos y de la definición de los casos de uso (o historias de usuario). Su objetivo es describir las funcionalidades del sistema y su comportamiento mediante el estudio de las necesidades del usuario. Su trabajo es muy importante y sin embargo no se le da el valor que se merece, ya he comentado en más de una ocasión que lo técnico suele resultar más glamuroso.
Los sistemas se desarrollan para el usuario y para que sean de utilidad hay que saber captar qué es lo que quiere el usuario y cómo desea interactuar con el sistema.
La técnica es muy importante, pero no lo es menos que la vertiente funcional, todos suman y todos restan si no hacen adecuadamente su trabajo.
El analista orgánico se encarga del diseño que no es otra cosa que la particularización de las necesidades del usuario a una implementación concreta. Para un proyecto concreto vendría a ser el arquitecto de la solución, ya que entraría incluso a definir el framework con el que se va a trabajar.
Lo habitual en los proyectos de desarrollo de software es encontrarnos con analistas que realizan las dos funciones, aunando en un solo perfil lo funcional y lo técnico. Tiene como principal ventaja que no es necesario transferir el conocimiento entre diferentes fases o procesos del desarrollo y que cada tarea es realizada por un experto en la misma. El principal inconveniente es que no existe una especialización, no obstante, hay que ser bastante bueno en uno de los dos perfiles para marcar de manera clara la diferencia respecto a analistas que realicen ambos trabajos (ahora, quien las marca es que es muy bueno y por tanto, vale mucho dinero).
En desarrollos iterativos e incrementales con una orientación ágil lo deseable es que la evolución del desarrollo sea rápida (realizándose los incrementos con cierta frecuencia) y resulta fundamental la participación del usuario, a ser posible como una pieza más del equipo de proyecto, lo normal es que no exista distinción entre analista funcional y orgánico, si bien, tendrá una vertiente más técnica, por las características particulares de este tipo de desarrollos. Existirán excepciones, en proyectos que por su naturaleza requiera de desarrolladores que den apoyo funcional, por la experiencia que tengan en un tipo de negocio concreto.

http://jummp.wordpress.com/2011/05/04/desarrollo-de-software-el-analista-funcional-y-el-analista-organico/

Difference between Desktop, Client server and Web testing

In this post I am gonna give answer to reader’s question.
There was one question asked by Srividya:
Q.What is difference between client server and Web Testing?
Vijay: Well Srividya I would like to add one more testing type i.e Desktop Testing in this discussion. So now we have three testing types Desktop application testing, Client server application testing and Web application testing.
Each one differs in the environment in which they are tested and you will lose control over the environment in which application you are testing, while you move from desktop to web applications.
Desktop application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e DB.
In client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.
Web application is a bit different and complex to test as tester don’t have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.
I think this will have an idea of all three testing environment. Keep in mind that even the difference exist in these three environment, the basic quality assurance and testing principles remains same and applies to all.

http://www.softwaretestinghelp.com/difference-between-desktop-client-server-and-web-testing/

SDN. Software-defined Networking

Hablamos de Internet, de la nube, de redes privadas virtuales, de redes de área local y los entendemos y asimilamos, generalmente, sin mucho problema, pudiendo incluso explicar a otras personas qué nos ofrecen y cómo funcionan, siempre y cuando no entremos en mucho detalle, porque es ahí donde las cosas empiezan a complicarse, y de qué manera, porque no es nada sencillo explicar cómo un grupo de personas pueden jugar en red, como tus correos electrónicos llegan sus destinatarios o cómo se sincronizan tus carpetas con tu gestor de almacenamiento en la nube favorito, sobre todo si empiezas a adentrarte en el proceloso mundo del TCP/IP, sus diferentes capas y las infraestructuras software y hardware que la soportan o lo que es lo mismo, a cómo viaja esa información entre un origen y un destino.
Los expertos y profesionales en redes de comunicaciones son los que podrán explicarte con mayor profundidad eso que no vemos, si bien, para ellos la complejidad también se incrementa conforme seguimos descendiendo en el nivel de detalle ya que no para de aumentar el número de tecnologías y soluciones que aparecen, así como el número de servicios a todos los niveles que se pretenden ofrecer en una red de comunicaciones.
Para ellos existen “piezas” que utilizan, que saben como interconectar, configurar y administrar pero que son como cajas negras limitadas a las especificaciones del fabricante, que si bien cubren determinados estándares, generalmente cada una de ellas requiere unos conocimientos específicos no solo para extraerle el mayor provecho posible, sino para hacerlas funcionar de la manera que necesitamos y nos interesa.
A medida que es mayor la red con la que se trabaja, intervienen un mayor número de elementos software y hardware heterogéneos, que se van a ir actualizando con el tiempo de manera no homogénea (y probablemente no organizada), lo cual sumado a que el tráfico no tiene por qué ser plano (pudiéndose establecer determinados niveles de calidad del servicio) hace que las tareas de administración se compliquen sobre manera.
Uno de esos elementos son los conmutadores que son dispositivos o elementos de infraestructura de red cuya función es interconectar diferentes segmentos de red o múltiples subredes para que funcionen de manera integrada como una sola.
Su función principal es la recepción y envío de paquetes, haciendo uso de su capacidad de almacenamiento y aprendizaje de direcciones, de manera que todo paquete dirigido a un mismo destino seguirá una misma trayectoria y será tratado de la misma manera. Cuanto mayor sea el nivel de funciones que se requieran del conmutador mayor será su coste teniendo en cuenta que en este caso, los upgrades no se solucionan generalmente con “parches” sino con la adquisición de nueva infraestructura.
Por tanto, podemos considerar que existe una gestión/administración distribuida dependiente de cada uno de esos conmutadores y de sus limitaciones o lo que es lo mismo, dependiente de un conjunto de cajas negras que tienen que ser reemplazadas en el caso de que se requiera un nivel de “inteligencia” que vaya más allá de las que tiene definidas, con el coste que eso supone (si alguna de las cajas negras es un componente software, además de estar limitada a la propia funcionalidad que ofrece, salvo que sea un desarrollo a medida o sea una solución de software libre, será necesario montar un mecanismo para tratar de automatizar en lo posible la configuración de las reglas definidas).
Las redes definidas por software tienen como objetivo simplificar la gestión/administración de las redes, centralizándola e independizándola de las soluciones específicas para el direccionamiento, es decir, se pretende establecer dos planos diferenciando lo que es el plano de control que es donde se toman decisiones sobre el destino del tráfico y lo que es el plano de datos que es la infraestructura que hace el “trabajo sucio” de enviar el tráfico al destino seleccionado.
Es decir, seguimos teniendo cajas negras pero se extrae de ellas la mayor parte de su “inteligencia” y se integran en un único punto, que se denomina controlador.
Además de las posibilidades que este paradigma presenta en cuanto a la flexibilidad en la implementación y mejora de servicios, que se gestionará en de manera centralizada, tenemos su independencia respecto al proveedor de cada uno de los conmutadores de la red, lo que ofrece un marco de trabajo apropiado para un entorno de red que debe ser escalable y adaptarse a la demanda existente en cada momento.
Tenemos dos planos: inteligencia y músculo, se necesita, por tanto, un mecanismo de comunicación entre ambos y que sea un estándar. Con este fin surge OpenFlow promovido por la ONF (Open Networking Foundation)

http://jummp.wordpress.com/2013/11/16/sdn-software-defined-networking/

Debate – Salarios testing y QA

Sumario

Debate iniciado en el grupo de discusión TESTING & QA, comunidad de testers dentro de la red LinkedIn, para discutir si hay relación entre la experiencia de un tester y su productividad. Título del Debate: Salarios testing y QA

Salarios

El siguiente contenido es parte de un debate que se ha generado desde el grupo de discusión en LinkedIn : TESTING & QA, te invito a que participes de él y si aún no eres miembro, solo tienes que unirte.

Me gustaria sabe cual es la opinion acerca de su sueldo, pero no a modo de encuesta para saber cuanto gana cada uno. Lo que me interesa es saber si consideran justo su sueldo en base a las tareas que realizan y a los compromisos que tienen. Por ejemplo, yo gano como tester con la cantidad de años de experiencia que tengo, lo mismo que gana el promedio ( según encuestas ), de todas maneras creo que el trabajo podria estar desvalorizado en el sentido de que cuando algo falle a los primeros que van a apuntar es a nosotros ( teniendo en cuenta como ya se debatio que un sistema nunca esta excento de errores ). Sin embargo otros puestos tienen salarios mas altos. ¿ En base a que podemos darle valor a nuestras tareas ?

Comentario 1
Qué buen debate que iniciaste Diego, y espero que otros miembros participen dejando sus comentarios, tal como ha impactado el debate referido al “Bug en Producción y la respuesta a darle al QA Manager”.

Bien, al punto entonces. Hace un tiempo elaboré una encuesta referida al tema pero sobre la base de un rango de montos de acuerdo con el perfil técnico, en este caso lo estas planteando desde otro punto de vista, no menos interesante.

Si veo para atrás un poco, desde que abrí este grupo y me puse a ‘trabajar’ en él, difundiendo los debates y lanzando distintas acciones, nuestra actividad ha crecido mucho.

Me cabe a veces una pregunta, o creció realmente la actividad del software testing (y cada vez es mayor la demanda, aunque en algunas partes dicen que nó) y/o no existía un canal de comunicación en español para permitir esta participación que aquí se ha dado.

El valor de nuestras tareas diarias, esta en relación directa con cuán profesionales somos en el desempeño de nuestra función, y atado a ésto, se encuentra el salario, aunque muchas veces no se pague como debiera.

No por nada hay períodos en donde hay muchas rotaciones entre empresas, porque es lógico que así sea, de hecho a mi me pasa en lo personal.

Hasta donde puedo ver, y consultándolo con otros pares, todos (quien más quien menos) actualmente estamos manejando muchas tareas a la vez y por ende, el compromiso aumenta.

No siempre, ésto se recompensa monetariamente (porque no se vé, no se muestra, no se puede) y así como surgen variantes de ‘pago’ intentando satisfacernos lo más posible: homeworking, flexibilidad horaria, sala de relax, sala de juegos, tickets de descuentos, % pagos para algún curso, descuentos en universidades, capacitaciones internas, regalos empresariales, otros etc etc etc.

Hasta hace un tiempo atrás, estábamos ganando muchísimo menos que un desarrollador, en cambio de un tiempo a esta parte y para ciertas actividades, esta cuestión se está comenzando a equiparar.

También mucho depende del lugar que le dé la empresa al QA/QC dentro de su negocio, dentro de su portfolio de servicios, dentro de sus estrategias y presupuesto anual.

Comentario 2
Yo pienso que habria que analizar el salario en relacion al valor agregado que se le da a los sistemas. Si un sistema tiene trabajando a 10 programadores durante un año, el precio final tendra en cuenta ese trabajo acumulado. Con los programadores es mas facil sacar cuentas porque ellos trabajan y producen algo tangible ( por decirlo de alguna manera ). Tal vez nuestro salario pueda hacerse valer en cuanto a los costos de produccion que reducimos.
Me interesaria averiguar dentro de otros tipos de trabajo que requieren un proceso de produccion, cual es la relacion de salario entre los trabajadores que se encargan de la produccion en si misma y la de los que se encargan de hacer un test de calidad. Por otro lado aca puede ser el debate mas amplio porque la calidad como concepto general incluye otras cosas mas que el testeo de un producto

Comentario 3
Diego, es un tema mas que interesante. Pero que esta muy lejos de estar resuelto en cualquiera de los sectores del industria del Software. Antiguamente el testing era una area de iniciacion en la industria ( de aprendizaje y conocimiento del sistema en particular). Con el paso del tiempo se transformo en una area de conocimientos especifico ( que necesita de personal calificado y certificado para que se desempeñe en el). Esto hace que esta tarea se valorice. Tambien la automatizacion hace que esta tarea sea “menos bruta”, menor cantidad de horas hombre…..
Respecto de que se apunte siempre al tester y que por esa responsabilidad esta desvalorizado, es relativo. Cuando se analiza un BUG, lo menos jugoso es entender por que el testing no lo detecto, ya que salvo que en el testeo se hayan omitidos pruebas o el tester haya evaluado mal el resultado. Lo mismo viene arrastrado de etapas previas de proyecto. Lo importante es llegar al origen del verdadero problema ( el BUG -Problema del proyecto) y no del falso problema ( por que el testing no lo detecto – Problema del responsable de testing/QA).-
En mi experiencia muchos de los BUG tiene su origen en las etapas primeras de los proyectos.

Comentario 4
Diego, me quedó dando vueltas una frase que pusiste:
“…Con los programadores es mas facil sacar cuentas porque ellos trabajan y producen algo tangible ( por decirlo de alguna manera )…”

En realidad, nosotros los Testers también generamos/producimos entregables durante el proceso de pruebas, y una muy buena cantidad dependiendo de la metodología que se haya elegido y de las herramientas con las cuales uno trabaje.

Esta producción también da cuentas de nuestra valor dentro del ciclo de vida de desarollo de software y por ende, puede y debe cuantificarse para luego llevarlo a números concretos que demuestren la utilidad y los beneficios de nuestra actividad.

Todos estos datos más alguna recopilación de resultados anteriores, tendencias, estadísticas, mejores prácticas, casos de éxito, permiten que los comerciales junto con el asesoramiento de algún técnico como nosotros, puede vender el servicio de software testing fuera y/o dentro de la empresa.

De ahí en más, cómo se reparten las ganancias obtenidas, es ‘harina de otro costal’, ya que aquí intervienen políticas internas, políticas de distribución, recursos humanos, gerencia del área, comparativos en el mercado, objetivos conseguidos y bonus asociados.

En fin, lo cierto es que hoy por hoy, nosotros podemos demostrar de muchas formas las ‘huellas’ que vamos dejando por el camino y cuánto es que valemos.

Después dependerá de cada uno hacerse valer más o menos, dependiendo de las circunstancias del momento.

Otro gran punto a tratar para otro debate, es que no tenemos un GREMIO que nos respalde, distinto es el caso para otras actividades que sí lo tienen.

………………………………………………………………………………………………….

Si quieres participar del debate y aún no eres miembros, te invito a que te unas a nuestra comunidad de software testers de habla hispana. Muchas gracias ! Te esperamos.

http://testingbaires.com/debate-salarios-testing-y-qa/

Mantenimiento adaptativo

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.
Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos:
- Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”
- Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.
Con las definiciones por delante resulta bastante sencillo discernir un tipo de mantenimiento de otro, ya que el primero está centrado en un cambio en las necesidades del usuario o lo que es lo mismo, en una modificación de los requisitos funcionales de la aplicación (por muy pequeños o grandes que sean) y el segundo se basa en los cambios en cualquiera de los elementos que conforman el entorno sobre el que funciona el programa, a los ejemplos que indica Métrica V.3, yo añadiría los servidores de aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si una aplicación se comunica con otra por servicios web y ésta modifica la interfaz el cambio a realizar en la aplicación es de carácter adaptativo ya que el requisito funcional (que es comunicarse con ese tercer sistema) no ha variado.

http://jummp.wordpress.com/2010/09/25/mantenimiento-adaptativo/

An approach for Security Testing of Web Applications

This is guest article by “Inder P Singh”
Introduction
As more and more vital data is stored in web applications and the number of transactions on the web increases, proper security testing of web applications is becoming very important. Security testing is the process that determines that confidential data stays confidential (i.e. it is not exposed to individuals/ entities for which it is not meant) and users can perform only those tasks that they are authorized to perform (e.g. a user should not be able to deny the functionality of the web site to other users, a user should not be able to change the functionality of the web application in an unintended way etc.).
Some key terms used in security testing
Before we go further, it will be useful to be aware of a few terms that are frequently used in web application security testing:
What is “Vulnerability”?
This is a weakness in the web application. The cause of such a “weakness” can be bugs in the application, an injection (SQL/ script code) or the presence of viruses.

What is “URL manipulation”?
Some web applications communicate additional information between the client (browser) and the server in the URL. Changing some information in the URL may sometimes lead to unintended behavior by the server.
What is “SQL injection”?
This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server.
What is “XSS (Cross Site Scripting)”?
When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS.
What is “Spoofing”?
The creation of hoax look-alike websites or emails is called spoofing.
Security testing approach:
In order to perform a useful security test of a web application, the security tester should have good knowledge of the HTTP protocol. It is important to have an understanding of how the client (browser) and the server communicate using HTTP. Additionally, the tester should at least know the basics of SQL injection and XSS. Hopefully, the number of security defects present in the web application will not be high. However, being able to accurately describe the security defects with all the required details to all concerned will definitely help.
1. Password cracking:
The security testing on a web application can be kicked off by “password cracking”. In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. If the web application does not enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters), it may not take very long to crack the username and password.
If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password.
For more details see article on “Website cookie testing”.
2. URL manipulation through HTTP GET methods:
The tester should check if the application passes important information in the querystring. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the querystring. The tester can modify a parameter value in the querystring to check if the server accepts it.
Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.
3. SQL Injection:
The next thing that should be checked is SQL injection. Entering a single quote (‘) in any textbox should be rejected by the application. Instead, if the tester encounters a database error, it means that the user input is inserted in some query which is then executed by the application. In such a case, the application is vulnerable to SQL injection.
SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct MySQL queries are executed on database by accepting some user inputs.
If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled/escaped properly in such cases.
4. Cross Site Scripting (XSS):
The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.
Attacker can use this method to execute malicious script or URL on victim’s browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.
Many web applications get some user information and pass this information in some variables from different pages.
E.g.: http://www.examplesite.com/index.php?userid=123&query=xyz
Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which can explore important user/server data on browser.
Important: During security testing, the tester should be very careful not to modify any of the following:

•  Configuration of the application or the server
•  Services running on the server
•  Existing user or customer data hosted by the application

Additionally, a security test should be avoided on a production system.
The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.

http://www.softwaretestinghelp.com/security-testing-of-web-applications/

Desarrollo de software. Ciclo de vida iterativo incremental

Este modelo de ciclo de vida es el que más de moda se encuentra de un tiempo a esta parte ya que es utilizado en diferentes metodologías relacionadas con la programación extrema y con estrategias ágiles de desarrollo de software.
El concepto es simple, el producto software se desarrolla por incrementos en el que cada iteración (incluida la primera) obtiene una versión funcional del producto, de esta forma el sistema se desarrolla poco a poco y obtiene un feedback continuo por parte del usuario.
En este modelo, en cada incremento se realizan las diferentes etapas de desarrollo de software, empezando por el análisis y terminando con la implantación y aceptación del sistema.
Tiene cierta similitud con el espiral, con la diferencia de que en este caso no se hace hincapié en el análisis de riesgos y si tomamos como referencia la variante Win & Win de Boehm, no tiene explícito el proceso de negociación bajo un prisma Ganar – Ganar entre las diferentes partes implicadas en el proyecto.
Las iteraciones no tienen por qué realizarse de manera secuencial, pudiendo haber varias ejecutándose simultáneamente siempre y cuando no existan incompatibilidades entre ellas (básicamente que se encuentren en fases distintas del proceso de desarrollo).
Este modelo de ciclo de vida es mi favorito, creo en él ya que estoy convencido que es el que más se aproxima a la realidad de un proyecto de desarrollo de software y sus contingencias. Tiene sus inconvenientes, como el hecho de que tal vez obtener una primera versión que se pueda considerar completa del producto puede tardar más en obtenerse y costar más que por ejemplo con un ciclo de vida en cascada, ya que en cada iteración se tiene en cuenta el feedback del usuario por lo que además de nuevas funcionalidades habrá modificaciones sobre lo de desarrollado en iteraciones anteriores.
No quiero decir con esto que el software necesariamente vaya a costar más de esta manera, ya que lo que hace es repercutir en el proceso de desarrollo parte del coste del mantenimiento, que recordemos que un autor como Robert Glass lo estima entre el 40 y el 80% del coste total del software.
Lo que sí se necesita son usuarios involucrados en el proyecto durante bastante tiempo y de manera constante, algo que no siempre es sencillo encontrar.
Pese a que es mi modelo favorito, sí que considero que es interesante tener una visión inicial del producto software más allá de las primeras iteraciones, ya que independientemente de que se definan una serie de metas intermedias creo que es interesante desde el inicio saber más o menos a dónde se quiere llegar.

http://jummp.wordpress.com/2011/03/31/desarrollo-de-software-ciclo-de-vida-iterativo-incremental/

Informe sobre sueldos de los testers en España

Link de encuesta 2013

El sector del Testing de Software está en constante evolución. Sin embargo, algunos aspectos profesionales como la situación salarial son poco conocidos. A menudo, en las escalas profesionales se olvida el puesto de tester o QA mientras es más popular el de programador, por citar un ejemplo.

El objetivo de esta segunda encuesta es situar en el mapa la figura del Tester o del QA y cómo está valorado en la escala salarial respecto a otras profesiones. Por ello, agradecemos a todas las personas que han participado en ella.

Esta encuesta se ha realizado en línea entre el 1º de febrero de 2013 y el 15 de marzo de 2013. La encuesta se difundió dentro de los medios afines al Software Testing, en las redes sociales, y en las redes de los organizadores de la encuesta.

Los resultados presentados a continuación se limitan a las respuestas de personas trabajando en España, por las cuales se han obtenido un número de datos estadísticamente relevantes. Se han eliminado las respuestas incompletas o dudosas en cuanto a la validez de los datos.

Este trabajo es el resultado de la encuesta promovida nexo QA, ATI (Asociación de Técnicos Informáticos) y SoftQANetwork.

Se recibieron numerosas respuestas de muchos países, pero no en un número suficientemente representativo como para poder sacar conclusiones en terceros países.

No obstante este último comentario publicado en el site de SoftQANetwork,  administrado por Javier Fernández-Pello Alvargonzález, es muy válida esta iniciativa ya que marca un punto de inflexión entre lo desconocido y ahora, lo conocido, por así decirlo en cuanto a salarios de nuestra actividad.

Enlace a la Encuesta:
https://docs.google.com/file/d/0B7lIfBS4SE-KYkxpZHNTbkY0MXc/edit?usp=sharing

Ahora bien, ¿Qué les parece si hacemos una encuesta similar para Argentina? ¿Me ayudarían?

Comenzaré a prepararlas sobre esta base y las difundiré dentro de la red LinkedIn, donde se encuentra además nuestro Grupo de Discusión TESTING & QA, para permitir mayor recepción y colaboración de sus miembros, ya que la comunidad desde el 2009 ha crecido lo suficiente como para que tenga recepción este tipo de noticia.

http://testingbaires.com/informe-sobre-sueldos-de-los-testers-en-espana/

Teoría y práctica en el desarrollo de software

Las metodologías y prácticas son modelos teóricos que si bien han podido ser probados con éxito en situaciones particulares, difícilmente resultan exportables, tal cual, a todo el conjunto de proyectos. Por ese motivo, la adaptación al contexto y la adaptación al cambio resulta fundamental a la hora de seleccionar el método de trabajo.
Por este motivo, cuando se trata de imponer ciertas dinámicas de trabajo suelen no conseguir resultados porque muchos proyectos o situaciones dentro de los mismos no terminan por encajar y al final no se consigue ni respetar esa dinámica, pero tampoco esquivarlas completamente afectando directamente al proyecto y con ello, muy probablemente, a sus resultados.
¿Quién está libre de no haber caído en ese error? Yo he sido el primero que ha caído en ello, empezando en la aplicación de metodologías de enfoque clásico e incluso con las metodologías aǵiles (algo que va contra natura de lo que el agilismo pretende y en lo que se cae con demasiada frecuencia).
Como decía Séneca: “Largo es el camino de la enseñanza por medio de teorías; breve y eficaz por medio de ejemplos”.
Por este motivo es difícil acertar a la primera porque al principio te basas en fundamentos teóricos: lo que leiste en un libro o lo que escuchaste en aquella conferencia, etc… Al final, la experiencia te pondrá en tu sitio, siempre y cuando decidas aprender algo de la misma.

http://jummp.wordpress.com/2013/08/05/teoria-y-practica-en-el-desarrollo-de-software/

Website Cookie Testing, Test cases for testing web application cookies?

We will first focus on what exactly cookies are and how they work. It would be easy for you to understand the test cases for testing cookies when you have clear understanding of how cookies work? How cookies stored on hard drive? And how can we edit cookie settings?
What is Cookie?
Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.
Why Cookies are used?
Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.
For example if you are accessing domain http://www.example.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.example.com/2.html then new request is send to example.com web server for sending 2.html page and web server don’t know anything about to whom the previous page 1.html served.
What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server.
How cookies work?
The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.
Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine called cookie.
Here is one example of the code that is used to write cookie and can be placed inside any HTML page:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;
When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.
Generally two types of cookies are written on user machine.
1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expire the cookie.
2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.
Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path “C:\Documents and Settings\Default User\Cookies”
Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user name like “Vijay” etc.
The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then “Show cookies” button.
How cookies are stored?
Lets take example of cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.
Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM
Applications where cookies can be used:
1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user don’t want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.
2) Personalized sites:
When user visits certain pages they are asked which pages they don’t want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him.
3) User tracking:
To track number of unique visitors online at particular time.
4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.
5) User sessions:
Cookies can track user sessions to particular domain using user ID and password.
Drawbacks of cookies:
1) Even writing Cookie is a great way to maintain user interaction, if user has set browser options to warn before writing any cookie or disabled the cookies completely then site containing cookie will be completely disabled and can not perform any operation resulting in loss of site traffic.
2) Too many Cookies:
If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.
3) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.

4) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.
This should be enough to know what cookies are. If you want more cookie info see Cookie Central page.
Some Major Test cases for web application cookie testing:
The first obvious test case is to test if your application is writing cookies properly on disk. You can use the Cookie Tester application also if you don’t have any web application to test but you want to understand the cookie concept for testing.
Test cases: 
1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.
2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.
3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.
4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)
5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.
6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.
7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.
8 ) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.
9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.
10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.
These are some Major test cases to be considered while testing website cookies. You can write multiple test cases from these test cases by performing various combinations. If you have some different application scenario, you can mention your test cases in comments below.

http://www.softwaretestinghelp.com/website-cookie-testing-test-cases/

Desarrollo de software. El término aseguramiento de la calidad se utiliza de manera muy gratuita

“Vamos a implantar un servicio para el aseguramiento de calidad de los productos software”.
Interesante slogan comercial que normalmente se traduce en un mayor coste en los productos software que se desarrollan y en la implantación de la infraestructura necesaria (personas y equipamiento) que estará por encima de los beneficios reales sobre el conjunto de productos software y sobre la organización.
Los lectores habituales del blog sabrán que soy un defensor a ultranza de los testers y de las tareas de testing en general y cada día que pasa lo soy más.
¿Qué no defiendo? Los slóganes vacíos como el que pone el punto de inicio de este artículo. Quienes hablan de asegurar o certificar la calidad del software no lo están haciendo desde una base real porque entre otras cosas lo hacen si conocer a priori cuáles son los umbrales de calidad definidos en la organización ni tampoco los que existen para cada proyecto concreto, lo que vendrá a significar, muy probablemente que el aseguramiento de la calidad lo pretenden conseguir a través de la implantación de procesos en todo lo que rodea al desarrollo del software porque entienden que lo importante realmente es el proceso y que eso puede con todo.
Me parece mucho más real hablar de servicios que pretenden mejorar la calidad de los productos software y del control que la organización tienen sobre el código fuente, librerías dependientes, etc…, así como de determinados entregables documentales que de asegurar la calidad.

http://jummp.wordpress.com/2013/03/23/desarrollo-de-software-el-termino-aseguramiento-de-la-calidad-se-utiliza-de-manera-muy-gratuita/

El sindicato del software está a un paso de obtener la inscripción gremial

Sumario -> Si bien es un artículo de tono político, nuestro foco debería ser entender el objeto de todas estas acciones que un grupo de personas están realizando, el alcance de las mismas, su impacto en nuestra actividad y relación con entidades como la CESSI. Si bien, todo es política como alguna vez me dijo un profesor de facultad, sería un buen ejercicio abstraerse del tono político que pudiera tener y entender qué esta pasando por la cabeza de algunas personas con un cierto poder de decisión en nuestra Argentina y reconocer si ésto puede o nó beneficiarnos.

Detalle -> Los trabajadores del software desde hace algunos años luchan por tener un gremio propio, que atienda las necesidades específicas del sector. Unión Informática (UI), apoyado por el diputado Facundo Moyano, fue el que tuvo mayor resonancia y antes del 30 de abril obtendría finalmente la personería gremial, según lo dictaminó la Sala 6 del Juzgado Nacional del Trabajo Nº 11.

“En noviembre, el Juez de primera instancia obligaba en noviembre al Ministerio de Trabajo a terminar la inscripción gremial. Ahora, la Cámara dictaminó que ni siquiera va a tener en cuenta la apelación del Ministerio. Esto significa que la sentencia está corriendo y si el Ministerio no tiene la inscripción para la semana que viene, estaría incumpliendo con un fallo judicial“, explicó a RedUSERS Pablo Dorín, secretario general de UI.

“Si (el ministro de Trabajo Carlos) Tomada no firma la inscripción, accionaríamos penalmente contra él porque consideraríamos que tiene algún interés y también accionaríamos penalmente para ejecutar el fallo”, indicó Dorín, quien agregó que les “hace mucho ruido” que el Ministerio tenga conversaciones con las empresas, algo que consideran “normal”, a la vez que critican que no se haya acercado a hablar con UI.

El secretario general indicó que la legitimidad del gremio está dada por sus trabajadores. “El día que presentamos los papeles, nos pidieron 50 adherentes para comenzar el trámite. Presentamos más de 250“, relató el funcionario, quien aseguró que ya tienen unos 200 afiliados que aportan cuota sindical y habría un total de más de 80 mil trabajadores en el sector.

La inscripción gremial que todos los trabajadores del software puedan afiliarse, más allá del sector al que se dedica la empresa. “Estamos con una medida de fuerza en la planta de YPF en Comodoro Rivadavia, donde hay muchos empleados del software que no entran en ningún convenio: no son petroleros, ni administrativos, ni del Estado. Recurrieron a nosotros para darle un amparo legal a sus actividades sindicales”, se explayó Dorín.

Por otro lado, el gremio quiere establecer un diálogo más fluido con la Cámara Argentina del Software y Servicios Informáticos (CESSI). “Es la única cámara patronal que reconocemos como representativa del sector. Queremos ver qué cosas tenemos en común y en qué nos podemos ayudar mutuamente. Lo mejor para todos es evitar el conflicto, ver qué necesitan ambas partes y que discutamos una agenda común”, expresó Dorín.

Además, aseguró que la regulación del gremio le conviene a todos, pues “debe haber un escalafón con categorías para que quede claro qué tipos de carreras hay dentro de la industria“. Con respecto a los despidos, remarcó que se han frenado los despidos ‘directos’, pero siguen luchando contra los ‘indirectos’, es decir, el alejamiento de los empleados debido a un salario que no se actualiza por inflación.

Los objetivos que persigue Unión Informática

• Salario básico de 7.000 pesos bruto
• Seguridad laboral: no puede haber empresas que abren y cierran en menos de dos años
• Una industria informática que no sólo se base en los servicios: queremos producir desde el diseño hasta la última pieza de software, aunque ya nada se produce en un sólo país
• Lograr un convenio en el que patronal y trabajadores diseñemos las categorías de trabajo: no puede ser que un programador en JAVA valga lo mismo que alguien que hace un servicio pequeño dentro de la industra
• Evitar el estrés laboral, que antes parecía sólo cosa de los gerentes, pero ahora también afecta a los empleados por las presiones a las que son sometidos
• Diálogo con la patronal para no llegar a las medidas de fuerza

http://testingbaires.com/inscripcion-gremial/

Mantenimiento adaptativo

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.
Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos:
- Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”
- Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.
Con las definiciones por delante resulta bastante sencillo discernir un tipo de mantenimiento de otro, ya que el primero está centrado en un cambio en las necesidades del usuario o lo que es lo mismo, en una modificación de los requisitos funcionales de la aplicación (por muy pequeños o grandes que sean) y el segundo se basa en los cambios en cualquiera de los elementos que conforman el entorno sobre el que funciona el programa, a los ejemplos que indica Métrica V.3, yo añadiría los servidores de aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si una aplicación se comunica con otra por servicios web y ésta modifica la interfaz el cambio a realizar en la aplicación es de carácter adaptativo ya que el requisito funcional (que es comunicarse con ese tercer sistema) no ha variado.

http://jummp.wordpress.com/2010/09/25/mantenimiento-adaptativo/

How can a Web site be tested?

Points to be considered while testing a Web site:
Web sites are essentially client/server applications -
with web servers and ‘browser’ clients.
Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.).
Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort.
Other considerations might include:
What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
Will down time for server and content maintenance/upgrades be allowed? how much?
What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
How reliable are the site’s Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?
What processes will be required to manage updates to the web site’s content, and
what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
How will internal and external links be validated and updated? how often?
Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet ‘traffic congestion’ problems to be accounted for in testing?

How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page.
The page layouts and design elements should be consistent throughout a site, so that it’s clear to the user that they’re still within a site.
Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type.
All pages should have links external to the page; there should be no dead-end pages.
The page owner, revision date, and a link to a contact person or organization should be included on each page.

http://www.softwaretestinghelp.com/how-can-a-web-site-be-tested/

Hiring Great Testers - How Important Is Testing Affinity?

When it comes to the increasingly important role of test developer, hiring managers have a choice to make.  They must decide what is the controlling criteria for hiring.  Which is more important, testing skills or development skills?  Sure, you want both to be strong but often times, you don't get a perfect candidate and are forced to compromise.  If you have to choose one skill as the more important, which should it be?  There is no universal answer.  Each situation will vary.  However, it is my assessment that you are often better off hiring a good developer and teaching testing skills rather than hiring a good tester and trying to teach development skills.  The reason for this is largely this one belief:  it is easier for the average developer to learn to test than for the average tester to learn to develop.
When I say developer, I don't just mean someone who knows the syntax of a programming language but rather someone who really understands programming.  That is, someone with computer science competencies.  This is not necessarily someone who has a CS degree.  The person can be self-taught, but they need to understand the sorts of things computer science students learn.  They need to have familiarity with data structures and algorithms.  They must understand complexity issues.  They should be familiar with operating system concepts including concurrency.  For a modern programmer, experience with object-oriented design principles is also necessary.
Two critical traits all testers must have to pay attention to details and being curious.  A tester needs to be thorough.  They cannot afford to leave any stones unturned in their quest to explore the product.  Good testers also need to be curious.  They need to have an instinct where to look to find the issues.  They have to want to experiment.
Let us think about most developers.  Are they detail-oriented people?  The good ones are.  Code is unforgiving.  If you don't pay attention to details, your program will misbehave or even crash.  Are they curious?  More often than not, curiosity is what brings someone into programming.  Is it the sense of exploration and later mastery that drives most of us forward.  It would seem then that good developers have the basic traits to be good testers.
What about the average tester?  Here I'm not talking test developer but rather someone who is less skilled in programming.  Do they have what it takes to make a good developer?  There is no way of knowing.  While curiosity and thoroughness are traits most developers have, those are not sufficient traits to be a good programmer.  To be the best programmer one must be a good problem solver.  One must also be able to think in very abstract ways.  Most good testers are also good problem solvers.  However, I'm not convinced that there is a correlation between abstract thinking and testing.  Testing can be done in a very concrete manner.  Many who make good testers do not have the ability to become great programmers.  It is often this trait that is missing.
Now let us consider the specific skillsets required for testing and programming.  It is argued that testing is just as difficult as programming.  That the skillset required is equally deep and varied in manner rather than scope.  I reject this notion. 
It's not that I think testing is easy.  It isn't.  I've interviewed many people who don't have what it takes to be a good tester.  They have the wrong mindset.  They aren't curious or thorough enough.  Sometimes they just don't really grok computers.  Often times the higher level skills in testing are enumerated to prove the difficulty.  These include things like understanding equivalency classes or pairwise testing.  The thing is, I've never found these to be too difficult to understand.  Equivalency analysis--despite its fancy name--is something any competent tester should just intuitively understand.  Pairwise testing is more complex but is something any CS student should be able to understand quickly.  There is a lot of art in successful testing too.  This can take a long time to develop well.  The average developer isn't going to be a great tester overnight.
How about programming?  How easy is it for the average tester to pick it up?  As I argued above, good programming is not just knowing the syntax.  I like to use the concept of writing to prove my point.  Knowing the syntax of a programming language is like knowing grammar.  You can correctly form sentences and can most likely convey your point to the audience.  However, knowing grammar does not make you a good writer.  What sets Mark Twain apart from your typical math student is not just a superior knowledge of grammar and vocabulary.  It is understanding the larger process at work.  Likewise, knowing the syntax of C++ or Java doesn't make for a good programmer.  One merely needs to watch The Daily WTF for a short while to understand why such thinking can cause enormous trouble over time.  It takes a long time and a lot of hard work to go from being someone who understands syntax to someone who can truly weave code.
Thus I think the gap between a tester and a developer is harder to cross from the tester side than from the developer side.  A developer can become an adequate tester well before a tester can become an adequate developer.  Given the choice between someone who is a good developer and someone who is a good tester and each lacking much skill in the other discipline, I'll take the developer nearly every time.
As always, your mileage may vary.  There are some testers who go on to make amazing developers.  There are developers who cannot grok testing.  There are some jobs where you don't really need good development skills.  Sometimes a person who understand syntax is enough.
That's my take anyway.  Release the arrows.

http://blogs.msdn.com/b/steverowe/archive/2007/02/13/hiring-great-testers-how-important-is-testing-affinity.aspx

what makes a good tester?

I was asked to give a short presentation to a Testing Training Class about the attributes required from a Professional Tester in today’s environment.
After carefully reviewing the issue and talking with a couple of colleagues I reached the (un-surprising) conclusion that today we look for 2 separate types of attributes in a tester: Soft-Skills and Technical-Skills.
Personally I think that Technical Skills can be learned by 80% of the population, but Soft Skills are something that takes more time to cultivate and mold. This is the reason that when I interview a candidate for a position I start by evaluating his personal skills based on my following list:
1. Communication skills – both verbally and written.
This is my first impression of the person and it starts with the way the she will introduce herself and even how she wrote her resume.
Every person in the team, and specially a tester, needs to be able to communicate clearly and accurately, without going around in circles and knowing how to differentiate between the noise and the important stuff in his message.
Most importantly, she needs to know how to reach her audience regardless if this is his manager, a fellow tester or a developer in the firm.
2. “Business Oriented”
(Confused…? Are we still talking about a testing job…? – I was tempted to make this my first attribute, but I decided that the first impression comes from the verbal skills, but so that you know you… it was close call!)
I think that each member of the team needs to understand the purpose, requirements and constraints of the business; after all we are part of a larger team with one sole purpose or mission. I don’t believe in hiring short-sighted engineers who’s sole purpose is to find bugs and go home.
What I look for is a person who knows how to shift priorities as they shift within the company, and to always find the most beneficial way to contribute to the efforts of the Organization.
3. Ability to Self-Learn
I am not looking for a self-thought rocket-scientist, but I need to understand that the candidate will be able to take a new subject (it may be a methodology, a feature or a tool) and learn it by herself, looking for materials available on the web, books, or whatever other place she may find them.
4. Flexibility Much in line with the point about Business Orientation, I look for persons who will be able to do more than one job and who won’t find ANY JOB bellow their taste or abilities.
My favorite example is from Test Engineers who are hired to do Automation and REFUSE to do ANY manual tests whatsoever (these guys have approximately 5 minutes to pack their stuff and go home in my teams). You can choose not to move to do a Job permanently if you don’t want to, but if the team needs something done you should be able to fill any position that will help push forward the objective and goal of your Organization.
5. Persistence
If you’ve been in testing for more than a couple of months you know that our job requires us to move mountains once in a while.
A tester should poses that delicate balance between understanding when they are wrong (and letting go) and when they need to be persistent with their peers, managers and other stakeholders.
To compliment my soft-skills list, in addition to all the above every tester should also be curious, careful and consistent.
Technical Skills
I already expressed that I believe these skills can be learned quickly enough so I don’t pay too much attention to them on a Starting Tester. On the other hand, if I talk to someone who has been in the field for a number of years I try understanding about his knowledge and experience in the following areas:
1. Technical Skills in the product areas he worked previously.
2. His ability to analyze a product and deduce from it the best approach to test it (based on the requirements and constraints of the business!)
3. His ability to write clear and complete testing scenarios
4. Bug reporting skills
5. Tools – any tools regardless if they are testing-tools, db-tools, sniffers, etc
–
Again, at the end of the day you can always train someone on the technical aspects of the work, but you cannot change the way he is.
It is better to have a great person who can become a good tester, than a “great” tester who will never be a good part of your team.

http://qablog.practitest.com/2008/12/what-makes-a-good-tester/

RUP

RUP - Rational Unified Process

El Proceso Unificado Racional (RUP) es un proceso de desarrollo de software que junto con el Lenguaje Unificado de Modelado (UML), constituyen la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema que sigue pasos establecidos para el desarrollo de un proyecto, sino que sigue un conjunto de metodologías que se adaptan a las necesidades de cada uno.

RUP se basa en 6 principios:

•       Adaptar el proceso
•       Balancear prioridades
•       Demostrar valor iterativamente
•       Elevar el nivel de abstracción
•       Enfocarse en la calidad
•       Ciclo de vida

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en un número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.

1. Concepción
2. Elaboración
3. Construcción
4. Transición

En  la siguiente figura podemos apreciar mejor estas fases:

 
http://xherrera334.blogspot.es/1194229380/rup-i-/