TestExpert A sua comunidade de teste e qualidade de software

A Qualidade de Software não se restringe apenas à correctness das funcionalidades desenvolvidas. Correctness, termo em inglês para "corretude", significa que as funcionalidades presentes no software são fiéis aos requisitos, ou seja, comportam-se da maneira esperada, satisfazendo a especificação de requisitos. (Não entrarei no mérito se a especificação de requisitos adulterou os requisitos do usuário durante o processo de entendimento do especificador. Considero aqui que o usuário validou a especificação de requisitos :-)

A Qualidade de Software implica mais do que apenas eliminar as falhas encontradas no processo de testes funcionais. Várias outras características, ou atributos, existem e fazem parte do conjunto que determina Qualidade de Software. A maioria deles é mapeada como requisitos não-funcionais dentro de uma especificação de requisitos. Quem tiver interesse, basta acessar o link http://en.wikipedia.org/wiki/List_of_System_Quality_Attributes para visualizar uma lista imensa da família dos "-ability".

Objetivo

O objetivo desse artigo é mostrar o conceito de teste de software do ponto de vista de uma das maiores empresa de TI do mundo, a Intel Corporation.

Introdução

Procurando sempre se posicionar estrategicamente no mercado de processadores, a Intel através dos seus relatórios anuais de operação, afirma: "Entre dezembro de 1999 e agosto de 2002 a Intel liberou vinte diferentes versões do processador Intel® Pentium III e Pentium 4, o que corresponde aproximadamente a um novo processador a cada um mês e meio" (Intel 2002). Isso quer dizer que se a densidade de um circuito integrado dobra a cada doze meses, pode-se afirmar que os projetos de software também ficarão maiores e mais complexos.

Com isso, a mudança natural na indústria de software requer também que as empresas de software, assim como as de hardware, continuem competitivas e lancem produtos mais atualizados e com novas versões, adaptando-se assim ao novo hardware que foi lançado.

1ª. Conferência da Qualidade de Software

Panorama atual e perspectivas da Qualidade de Software no Brasil

A 1ª. Conferência da Qualidade de Software traz um panorama atual da Qualidade do Software do Brasil, com relatos de empresas que obtiveram excelentes resultados na implantação de programas de melhorias de processo e suas perspectivas para os próximos anos.

Venha conhecer importantes protagonistas da Qualidade de Software do Brasil e trocar experiências sobre assuntos que podem interessar diretamente à sua empresa:

- Programas de melhorias baseados em modelos e sua integração (CMMI, MPS.BR, ISO 9000, SCRUM, ITIL, PMBOK, entre outros.)
- Benefícios e riscos na implantação de programas de melhoria
- Programas cooperados de grupos de empresas para melhoria de processo de desenvolvimento de software
- O fator humano no desenvolvimento de software
- Medição de resultados na implantação de melhorias

Local:

Auditório da ABINEE
Avenida Paulista, 1439 - 6º andar (próximo à estação Trianon do metrô)
São Paulo - SP

Programação:
- Data: 04/12/08 (quinta) e 05/12/08 (sexta)
- Horário: 8:30 às 17:30 hs
- Palestras: 7COMm, Ci&T, Kaizen, Johnson & Johnson, Powerlogic, Sensedia, COPPE-UFRJ, Núcleo Softex Campinas, FUMSOFT (Sociedade Mineira de Software), APETI (Associação de Profissionais e Empresas de Tecnologia da Informação), PISO (Pólo Industrial de Software) e ASR Consultoria.

Site interessante

Análise de Riscos em Projetos de Software Assisti recentemente a uma palestra muito interessante sobre análise de riscos em projetos de software. Apesar de o assunto não ser de um todo desconhecido para mim, resolvi estudar um pouco mais o assunto. Boa idéia foi a que eu tive, pois a pesquisa foi muito proveitosa e elucidativa. Como todo o conhecimento deve ser compartilhado, repasso agora aos colegas de testes as minhas anotações: “Risco é a probabilidade de algo errado acontecer no futuro, problema é 100% de certeza que algo errado irá acontecer!” Como evitar um problema?

Segundo o site WIKIPEDIA, "Um data warehouse (ou armazém de dados, ou depósito de dados no Brasil) é um sistema de computação utilizado para armazenar informações relativas às atividades de uma organização em bancos de dados, de forma consolidada. O desenho da base de dados favorece os relatórios, a análise de grandes volumes de dados e a obtenção de informações estratégicas que podem facilitar a tomada de decisão.

O data warehouse possibilita a análise de grandes volumes de dados, coletados dos sistemas transacionais (OLTP). São as chamadas séries históricas que possibilitam uma melhor análise de eventos passados, oferecendo suporte às tomadas de decisões presentes e a previsão de eventos futuros. Por definição, os dados em um data warehouse não são voláteis, ou seja, eles não mudam, salvo quando é necessário fazer correções de dados previamente carregados. Os dados estão disponíveis somente para leitura e não podem ser alterados.

A ferramenta mais popular para exploração de um data warehouse é a Online Analytical Processing OLAP ou Processo Analítico em Tempo Real, mas muitas outras podem ser usadas.

Testes de Software – O Grande Final

Para terminar este grande evento, foi demonstrada uma visão geral dos testes, pois o tempo estava curto para o aprofundamento do assunto. Na visão das empresas os testes são considerados benéficos, pois podem prever a qualidade e a produtividade durante a fase de manutenção e também podem evitar que os erros saiam do ambiente de desenvolvimento e passem a produção. E são considerados como um problema quando os executivos querem que os testes sejam “a prova de que funciona” e quando são culpados por atrasar o projeto, pois estão sempre no caminho crítico.

Algumas situações que prejudicam a equipe de testes:

- Falta de visibilidade e envolvimento nos processos de engenharia de requisitos;
- Dificuldades em mapear os requisitos de testes aos requisitos de negócios;
- Dificuldades em manter os testes alinhados e sincronizados com os requisitos;
- Raramente são notificados ou envolvidos no processo de gestão de mudanças;
- Mudanças são executadas sem levar em consideração o impacto causado nos testes.

Continuando nossa "saga" no Evento da Borland, entramos em Gestão de Projetos, o que iniciou muitas trocas de informações e conhecimento entre todos que estavam lá e o Renato Quédas. 

E quando falamos em gerenciamento de projetos podemos verificar muitas situações bem parecidas com as utilizadas pelo MPS-Br. O desenho do projeto é o mesmo, pois segue praticamente as regras criadas pelo PMI. Isto é:

Iniciação -> Planejamento <-> Controle <-> Execução -> Encerramento

Assim comecei a verificar muitas situações que ocorriam nos processos do MPS-
Br e efetuei uma discussão para saber como o mercado estava tratando estas situações.

Continuando a falar sobre o evento realizado pela Borland,  entramos em um assunto que muitos conhecem, mas tem dificuldades na utilização no seu dia a dia. Muitos já sabem da importância da Gerência de Requisitos e cada dia que passa esse processo está se tornando cada vez mais necessário nas organizações de desenvolvimento de software.

O Renato começou informando que a prioridade dos requisitos normalmente é o cliente que deve definir, assim fica muito mais fácil saber qual a prioridade das solicitações.

Uma situação interessante levantada foi que sempre quando houver uma mudança de algum requisito todos os envolvidos devem ser avisados (analista que desenvolveu o requisito, analista programador e analista de testes).

Neste primeiro post, gostaria de passar uma visão geral do Mantis, que é uma ferramenta de gestão de defeitos muito utilizada pelas empresas que adotam uma política de controle de testes e qualidade.

É uma ferramenta FREE pelos termos do GNU General Public License (GPL). Escrita em PHP, tem seu código aberto, o que permite ao usuário a possibilidade de uma grande variedade de customizações que, inclusive, são incentivadas no arquivo principal do sistema. Um grande diferencial de seus concorrentes é a possibilidade de utilização do sistema em diversos idiomas, inclusive o Português - Brasil.

São 6 níveis de usuários, (Visualizador, Relator, Atualizador, Desenvolvedor, Gerente e Administrador) cada qual possui diferentes níveis de atribuições e permições dentro do sistema, um Visualizador por exemplo pode apenas ver os registros de erros efetuados, e o Administrador tem poderes completos.

Os casos reportados (issues) são separados por projetos e sub-projetos, dessa forma ficam bem organizados dentro do sistema. Assim que são salvos, os casos são designados a um usuário, que receberá um email notificando-o como responsável pela resolução do bug. Após solucionar o erro, o responsável terá que responder ao remetente que avaliará se o caso pode ser encerrado ou não. Todas as ações são gravadas em logs que irão gerar relatórios consistentes sobre o andamento dos casos dentro de um projeto.

Segundo a NBR ISO 9000:2005, "qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos". Ou seja, pode-se afirmar que se algum produto ou serviço atende aos requisitos especificados, este mesmo produto ou serviço possui a qualidade desejada.

A qualidade pode ser medida através do grau de satisfação em que as pessoas avaliam determinado produto ou serviço. No entanto, esse produto ou serviço pode ter qualidade para algumas pessoas e para outras nem tanto, ou seja, a qualidade é algo subjetivo.

Conceituar desta forma então o termo qualidade se torna uma tarefa muito difícil, pois elementos intrínsecos estão enraizados no intelecto de cada ser.

O termo TQM (Total Quality Management), amplamente usado nas organizações, também descreve uma abordagem para a melhoria da qualidade. De acordo com Kan (2002), "O termo tem tomado vários significados, dependendo de quem interpreta e como se aplica." (KAN, 2002, p. 30). Independente dos seus vários tipos de implementação, os elementos chave do TQM podem ser resumidos conforme Figura 1, abaixo:

Figura 1 - Elementos chave do TQM.

Na semana passada fui a um treinamento na Borland em SP. O treinamento foi muito válido e gostaria de estar passando um pouco do conhecimento adquirido no mesmo. Quem puder participar destes eventos na Borland em SP vão, pois vale a pena e o que eu vou escrever é apenas uma pequena parte do que vimos lá.

Treinamento: Qualidade do Planejamento à Entrega do Software
Data: 05 de Março de 2008.
Local: Borland / SP
Ministrado por Renato Quédas

Antes de falar sobre o que foi passado, queria falar um pouco sobre o palestrante, Renato Quédas é um profissional brasileiro que foi transferido para Chicago, para atuar como responsável pelas soluções de LQM (Lifecycle Quality Management) da Borland. Ele responde para a região das Américas como Domain Specialist, uma função que atende as demandas das equipes de vendas e desenvolvimento. A atuação de Quedas tem um foco especial nos produtos Borland Gauntlet e Borland SilkCentral Test Manager.

Foram focados três grandes assuntos neste treinamento, Gerenciamento de Projetos, Gestão de Requisitos e Testes de Software.

Início

Iniciou-se falando um pouco de algumas estatísticas de mercado, onde foram verificados que:

Olá pessoal, depois de tanto tempo estamos aqui com a segunda parte do artigo sobre Watir. Desculpem-me a demora, quem estava aguardando, mas estou
com muitos projetos profissionais que me impediram de conseguir um tempo para me dedicar ao artigo.

Sem mais desculpas, vamos ao que interessa.