Arquivo mensal: setembro 2008

Fuzz Testing

Um dos testes de Caixa Preta (Black Box) é o Fuzz testing, cuja tradução seria algo como teste aleatório. É uma técnica que consiste basicamente na inserção de dados aleatórios na aplicação, com o objetivo de descobrir falhas no programa, relacionadas com a inserção/leitura de dados, e, assim, melhorar a confiabilidade do software.

O procedimento de implantação do Fuzz testing é composto por três passos:

  1. Preparar uma massa de dados de entrada para o seu programa;
  2. Inserir a massa de dados no programa;
  3. Verificar se ocorreu algum problema.
Para a preparação da massa de dados, geralmente é utilizado algum script/programa capaz de gerar dados aleatórios, sendo esses dados compostos muitas vezes por “dados ruins”, ou seja, dados que muitas vezes não são esperados pela aplicação como, por exemplo, caracteres especiais (@,$,%,¢,►,º,etc). A inserção dessa massa de dados também é feita pelo script/programa, ou até pela própria aplicação, por exemplo, abrindo o arquivo da massa de dados.
O Fuzz testing também pode ser usado com o propósito de segurança, pois a sua execução pode encontrar negligências e erros humanos, que colocariam a segurança da aplicação em xeque. Podendo, simular problemas que causariam a quebra, como por exemplo: buffer overflow, cross-site scripting (XSS para não confudir com CSS – Cascaded Style Sheet), ataques de negação de serviço e injeção SQL.
Vantagens
As falhas que a técnica de Fuzz testing pode encontrar são freqüentemente de ordem severa, podendo representar brechas de segurança que um hacker poderia explorar com o intuito de invasão. Outra vantagem é a contribuição para a robustez da aplicação que dará maior confiabilidade a mesma, evitando assim futuros problemas em produção.
Desvantagens
A principal desvantagem é que o Fuzz testing, geralmente só encontra falhas muito simples. E sua eficácia varia bastante de acordo com a pessoa que está implementando o teste, pois além da criação do script/programa, é ela que vai criar a massa de dados, ou seja, a massa de dados será o grande diferencial de um bom Fuzz testing para um mal.
Conclusão
Fuzz testing é uma técnica que permite descobrir falhas que provavelmente não seriam possíveis de serem encontradas de forma manual. Por isso a necessidade da automatização do teste, por meio da criação de um script/programa. A sua execução aumenta a confiança e solidez da aplicação.
Essa técnica ainda ajudará o programador a tomar futuramente as medidas preventivas de acordo com as falhas encontradas. Algumas dessas medidas são descritas no artigo do Elliotte Harold (vide fonte), para quem tiver interesse em conhecê-las, o artigo é muito bom.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Harold E. Fuzz testing – Attack your programs before someone else does. IBM – Developer Works, 2006.

Fuzz testing – Wikipedia

Testes de sobrevivência

Pessoal, há um tempo atrás publiquei um artigo sobre os tipos de testes, Teste Estrutural (White Box) X Teste Funcional (Black Box), no qual disse que iria detalhar cada técnica de teste em futuros artigos. Pois bem, como dizem “promessa é divida” e aqui inicio falando sobre testes de sobrevivência.

Segundo o livro Base de conhecimento em teste de software, os testes de sobrevivência avaliam a capacidade do software de continuar operando mesmo quando algum elemento (software ou hardware) fica inoperante ou pára de funcionar. Ou seja, seria uma versão do programa “No Limite” para o software, no qual iriamos verificar o comportamento  do mesmo, em situações atípicas. Por exemplo: queda de um dos servidores utilizados, queda do banco de dados, etc.

Logicamente, não é cobrado que a aplicação continue funcionando normalmente em tais situações, o que é verificado é o comportamento dela nessas situações. A aplicação deverá está preparada para enfrentar esses “desastres”, por exemplo: uma aplicação bancária ao perder conexão com o banco de dados, deverá parar as suas execuções atuais e informar ao(s) usuário(s) do ocorrido e quando a conexão com a base de dados for restabelecida ela deverá dá um rollback nas execuções que foram paradas.

Outro objetivo dos testes de sobrevivência é conhecer os limites do software, para que em produção evite-se submeter-lo a tais situações. Podendo até esse limite tornar-se uma restrição do software. Uma analogia pode ser feita com o elevador, no qual há uma restrição quanto a quantidade de passageiros máximos ou peso máximo que o mesmo pode transportar, pois foi realizado testes previamente, que revelaram que caso essa restrição não seja respeitada o elevador corre risco de quebra.

Por fim, podemos concluir que os testes de sobrevivências são essenciais para aplicações críticas, pois irão revelar os seus limites e ajudará a equipe a tomar decisões para prevenir tais situações.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de software. São Paulo, Martins Fontes, 2007.

Qualidade Sem Nome

Muitas vezes estamos buscando saber o que determinada coisa é e não buscamos saber o que ela deveria ser. Pela complexidade humana, encontramos uma distinção nos sistemas pela qual há sistemas que estão imersos na natureza e outros que não estão.

Pode parecer meio confuso, pois quando falamos em natureza, cada indivíduo faz uma associação diferente com a palavra natureza. Um sistema que está imerso na natureza, seria um que possui poucas barreiras com o usuário, e com o qual o usuário tem uma interface colaborativa, ou seja, que o comportamento do sistema possa reproduzir ou emitir, em certo sentido, o comportamento normalmente esperado de um humano em cooperação com o usuário.

Qualidade Sem Nome, ou Quality Without a Name (QWAN), foi definida pelo arquiteto, matemático e urbanista, Christopher Alexander, no seu livro The Timeless Way of Building, como sendo:

Uma qualidade central que é a raiz da vida e espírito de um homem, uma cidade, uma construção, da natureza. Tal qualidade é precisa e objetiva, mas não possui um nome.

Fugindo dessa definição filosófica, a qualidade central seria como o chassi de um carro: é ele que definirá a qualidade do produto final (carro), não adianta ter um motor potente, ou um bom piloto, se o chassi do carro foi mal projetado.

Alexander, ainda diz que a Qualidade não pode ser fabricada, mas sim gerada, indiretamente, pelas ações das pessoas. Embora muitos ainda pensem que a Qualidade esteja intrinsecamente ligada aos processos, metodologias ou ferramentas, quando na verdade ela está diretamente ligada as pessoas e suas ações.

Aplicando a QWAN em TI, podemos associar ela ao real objetivo de algum programa, ou seja, aos requisitos do projeto. E esses podem está errados, fazendo com que o “chassi” da nossa aplicação fique totalmente prejudicado. Afinal, na maioria das vezes, a falha está no planejamento do projeto e não no desenvolvimento.

E qual o motivo para esse fato?

A verdade é que a Qualidade é traduzida muitas vezes até a entrega final do produto, e durante estas traduções podem ocorrer algumas das seguintes situações:

  • O cliente não conseguiu traduzir corretamente o que ele realmente queria;
  • O gerente teve uma perspectiva diferente da vontade do cliente;
  • Ao elaborar o escopo do projeto o gerente acabou incluindo alguns aspectos que ele achou melhor colocar, pois pela sua experiência eles são essências;
  • O design planejou toda a interface, seguindo o padrão da empresa, não se preocupando com as vontades do cliente.

O conceito de QWAN nos leva a uma revolução, Alexander não apenas tentava achar padrões que explicassem a existência da QWAN, mas também achar padrões que gerem objetos com essa qualidade.

QWAN proporciona uma conexão quase emocional com a estrutura projetada. Proporciona àqueles que interagem com ele um sentimento de completude, de conforto, de sentirem-se vivos. Os artefatos que a possuem são flexíveis, extensíveis, adaptáveis, reutilizáveis, enfim, possuem qualidades que de um certo ponto de vista emulam vida.

Esta definição é demasiada subjetiva para se adequar aos paradigmas atuais de Engenharia de Software. O QWAN opera no nível visceral de inteligência humana e as disciplinas da engenharia almejam o nível comportamental.

Por fim, podemos entender que a QWAN nos fazem evidenciar que o produto deverá fornecer uma sensação imediata de compreensão e afetividade com o usuário. Por isso, devemos colocar o usuário no centro do projeto e sempre estarmos nos perguntando e comprovando se o sistema correto está sendo construído. Buscando a criação de estruturas que são boas para as pessoas e influem positivamente nelas, melhorando seu conforto e qualidade de vida.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Christopher, A. The Timeless Way of Building, Oxford University Press, New York, 1979.

Valente, E. Padrões de Interação e Usabilidade, UNICAMP, Campinas, 2004. (obtido no site da Biblioteca Digital da UNICAMP)

Lehti, L.; Ruokonen, A. Foundation of the patterns. (obtido no link: http://www.cs.tut.fi/~kk/webstuff/Foundationofpatterns.pdf)

Carreira – Teste de Software

A área de Testes é uma das que mais tem crescido, nos últimos anos, para se ter idéia em média há umas 50 a 70 vagas da área de Testes no Apinfo, site dedicado a vagas de TI, tendo como base o estado de São Paulo.

Esse resultado dá-se, devido a importância da execução dos testes, durante o ciclo de desenvolvimento. Principalmente, com o “boom” das práticas de outsourcing e de offshoring, que exigiu das empresas uma maior garantia da qualidade de seus produtos.

Recentemente saiu uma lista dos empregos de TI à prova de recessão, feita pela empresa de recrutamento online JobFox, na qual se encontra na 12º posição os profissionais especialistas em testes e controle de qualidade.

A carreira nesta área geralmente respeita a seguinte hierarquia:

  • Tester (Testador) – é a posição de entrada na área. O Tester é responsável pela execução dos testes, que em muitas vezes incluem as seguintes atividades: testar configurações de hardware e software, executar scripts simples de teste, reproduzir e reportar bugs. Alguns trabalhos podem se tornar chatos e repetitivos, mas com certeza o aprendizado obtido será muito recompensador e dará condições de galgar novas posições. É nesta fase que o profissional poderá ir para o “lado negro da força” (Desenvolvimento), caso seja notada habilidade e vocação para a programação. No Desenvolvimento o Tester será responsável por realizar os testes de Caixa Branca, principalmente os de nível unitário. E poderá preencher um gap existente na área de programação, que é a habilidade e conhecimento em testes, podendo assim ser tornar um excelente e requisitado programador.
  • Analista de Teste – é o profissional responsável pela modelagem e elaboração dos casos de teste e pelos scripts de teste. Em algumas vezes, ele também é o responsável pela execução de testes mais específicos, por exemplo testes de desempenho, estresse e homologação, nos quais exige um maior conhecimento e maior responsabilidade. Este profissional tem bons conhecimentos em Análise de Sistemas, UML, modelos, normas, processos, banco de dados, ferramentas de teste e principalmente tem pleno conhecimento do software que está sendo testado.
  • Analista de Automação de Teste – é o cargo mais recente da área de Testes. O Analista de Automação de Teste é um profissional que tem como objetivo principal, buscar a automatização de testes, sempre que ela for possível e viável. Utilizando para isso ferramentas, como por exemplo: JMeter, Marathon, Selenium, SoapUI, WebLOAD, entre outras. O profissional deverá estar atento ao aparecimento de novas ferramentas, ter bons conhecimentos de programação e buscar novas soluções para a melhoria dos testes. Ele necessita conhecer bem o processo de Teste e a realidade da empresa para que possa automatizar os testes de acordo com a necessidade da empresa, afinal a automatização de testes não é uma tarefa tão simples e se feita de forma equivocada poderá trazer prejuízos ao invés de benefícios.
  • Arquiteto de Teste – é o responsável pela montagem da infra-estrutura de teste, monta o ambiente de teste, escolhe as ferramentas de teste e capacita a equipe para executar seu trabalho nesse ambiente de teste. É uma função que exige um bom conhecimento em redes, sistemas operacionais (Linux, Windows Server, etc), servidores Web, banco de dados e principalmente conhecimento da infra-estrutura do ambiente de produção, na qual o software que vai ser testado será futuramente instalado, para que o ambiente de teste seja o mais próximo do de produção.
  • Líder de Teste –  é o profissional responsável pela condução dos testes e pela equipe de Testes. Geralmente é um profissional com alto grau de conhecimento em ciclos de vida de testes, automação de testes, ambientes de testes e documentação de testes. Ele ajuda o Gerente de Teste a elaborar os três relatórios básicos para o acompanhamento do projeto: Relatório de Status, Relatório de Progresso e Relatório de Desempenho.
  • Gerente de Teste – o Gerente de Teste tem como função primordial a iniciação do projeto de teste a ser realizado no produto a ser testado. Suas qualificações e competências se assemelham a um gerente de projetos típico: elaborar o plano do projeto de teste, aquisição de novos recursos, orçamento, riscos, prazos, elaboração de relatórios, limitações do escopo do projeto de teste e outras atividades gerenciais como constante comunicação com sua equipe, controle e monitoração das atividades, geração de métricas para alimentar indicadores, etc.
Hierarquia da área de Testes

Hierarquia - área de Testes

Os cargos e as tarefas dos cargos podem variar de empresa para empresa, principalmente devido ao porte da empresa. E é muito comum o acúmulo de papéis, por exemplo: o Analista de Teste também ser responsável pelas ferramentas de automação de teste e da montagem do ambiente de teste.
A área de Testes está a pleno vapor e os seus profissionais cada vez mais valorizados, exemplo disso é o surgimento de vários cursos, certificações e até MBA na área. Que mostram que o mercado está à caça de profissionais qualificados.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:
Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de software. São Paulo, Martins Fontes, 2007.