,

Sejam bem-vindos ao GUTS-PB, o Grupo de Usuários de Teste de Software da Paraíba

Esse grupo foi criado voltado para todas as pessoas da área de TI que tenham interesse em obter informações em Testes de Softwares, com o intuito de divulgar, expandir, disseminar, promover e tornar prático as atividades de testes de software para esses profissionais paraibanos. Sentindo um grande deficit de especialistas nessa área, em nosso estado, criei esse grupo para que possamos trocar conhecimentos e tornar as práticas de Teste de Software cada vez mais comum. Seja bem-vindo e sinta-se à vontade em comentar, assim como sugerir posts para que o nosso Blog seja utilizado cada vez mais.

Oportunidades de Emprego

Veja aqui quais as oportunidades de emprego que estão sendo oferecidas para as áreas de teste de software.

Cursos e Treinamentos

Está a fim de se especializar ainda mais em Teste de Software, então acesso esse link e veja quais os cursos de testes mais próximo de você

O GUTS-PB irá realizar em João Pessoa o 1º Testing Dojo Paraíba. Ficou curioso em saber? Acesse e participe.

segunda-feira, 19 de agosto de 2013

Proporção de testadores em relação ao número de desenvolvedores de um projeto: Melhores práticas e a realidade Brasileira

Estimar a quantidade de testadores de um projeto é uma tarefa árdua e imprecisa. Frequentemente esta estimativa é realizada com base no número de desenvolvedores. No entanto, diversos especialistas na área de testes de software alertam que nem sempre é possível estimar a proporção de testadores em relação aos desenvolvedores em virtude de que existem muitos fatores externos que podem afetar e influenciar o resultado final.
Para Michael Eason [1], a relação entre os testadores e os desenvolvedores de um projeto pode ser estimada com base na seguinte generalização (testador:desenvolvedor):
  • 1:3: Quando o processo é bastante maduro e os requisitos são detalhados e consistentes;
  • 1:1: Quando o processo é imaturo, ou não existe processo e os requisitos são ambíguos, inconsistentes e desatualizados.
Kathy Iberle [2] defende que a proporção entre testadores e desenvolvedores não pode ser definida linearmente. Para ela, a quantidade de testadores em relação aos desenvolvedores de um projeto deve ser estimada com base no histórico dos projetos anteriores da organização e num modelo (proposto por ela) onde essa relação é calibrada em função de fatores ambientais (complexidade do projeto, nível de experiência dos desenvolvedores ou testadores, entre outros). Dentre os principais fatores descritos por Iberle, podemos destacar:
  • A experiência dos testadores e desenvolvedores;
  • A freqüência em que o desenvolvedor insere defeitos na aplicação (e a severidade desses defeitos);
  • A eficiência do desenvolvedor em detectar e resolver defeitos antes de liberar a aplicação para a execução dos testes;
  • A eficiência do testador em detectar defeitos;
  • Entre outros.
Johanna Rothman [3], no seu artigo “It Depends: Deciding on the Correct Ratio of Developers to Testers”, corrobora a visão de Iberle. Para ela, não existe uma melhor prática que possa ser aplicada em todas as organizações. Ou seja, não existe resposta certa para a proporção entre testadores e desenvolvedores de um projeto. Cada organização deve analisar a sua realidade e definir os seus próprios patamares. Adicionalmente, Rothman afirma que durante essa análise, devem ser considerados os seguintes pontos:
  • Produto: a qualidade dos requisitos, o tamanho e a complexidade do produto;
  • Projeto: o processo de desenvolvimento, a tolerância do cliente em relação à quantidade defeitos ou atrasos nas entregas;
  • Pessoal: a experiência dos testadores e desenvolvedores e as suas responsabilidades.
Randall Rice [4], realizou uma pesquisa informal em 2000 durante a conferência “QAI's 20th Annual Software Testing Conference” e chegou à seguinte conclusão:
  • Proporção mais comum: 1 testador para cada 3 desenvolvedores;
  • Proporção média: 1 testador para cada 7 desenvolvedores.
Para Rice, não existe um número mágico que possa ser adotado para qualquer organização. Além disso, as pesquisas sobre a relação testador:desenvolvedor normalmente não adotam metodologias formais e não representam a realidade do mercado em virtude de que o número de participantes não é suficiente para determinar uma média precisa.

Realidade Brasileira

Para delinear a proporção mais comum de testadores em relação aos desenvolvedores no cenário Brasileiro, foi realizada uma enquete no portal gratuito de testes e qualidade de software TestExpert (www.testexpert.com.br). Esta enquete foi realizada no período de 11 de outubro de 2007 a 22 de novembro de 2007 e contou com a participação de 231 respondentes. O resultado da enquete pode ser observado na Figura 1. Curiosamente, o resultado mais comum é compatível ao resultado da pesquisa realizada por Randall Rice. A proporção mais comum foi de 1 testador para cada 3 desenvolvedores.

Figura 1: Resultado da Enquete (Testador:Desenvolvedor)
Trocando em miúdos: não existe uma solução que sirva para todas as organizações. O orçamento do projeto e o risco que um defeito na aplicação pode trazer ao negócio são fatores que influenciam diretamente a quantidade de testadores de um projeto. Ou seja, uma aplicação simples de baixo risco, pode estimar uma proporção de “1:>10”. No entanto, se a aplicação for utilizada em equipamentos médicos, sem dúvida, a proporção deverá ser muito próxima de “1:1”. De qualquer forma, uma grande quantidade de testadores por si só não garante que a aplicação tenha mais qualidade e seja livre de defeitos críticos. Grandes empresas como por exemplo, a Microsoft, que podem dar-se ao luxo de ter a proporção de “1:1” em praticamente todos os projetos , frequentemente liberam produtos no mercado repletos de defeitos críticos. Ou seja: Tudo depende!


Referências

[1] EASON, Michael. Sizing a Software Quality Assurance Group: Theory and Application
[2] IBERLE, Kathy. Estimating Tester to Developer Ratios (or Not)
[3] ROTHMAN, Johanna. It Depends: Deciding on the Correct Ratio of Developers to Testers.
[4] RICE, Randall. The Elusive Tester to Developer Ratio.
[5] Microsoft Test center aims to help corporate programmers avoid buggy code. Disponível em: http://www.networkworld.com/community/node/20877
[6] Qual é a proporção de testadores em relação aos desenvolvedores nos seus projetos (Testador:Desenvolvedor)?. Disponível em: http://www.testexpert.com.br/?q=node/263

 
Post criado por: Cristiano Caetano - É certificado CBTS pela ALATS. Consultor de teste de software sênior com mais de 10 anos de experiência, já trabalhou na área de qualidade e teste de software para grandes empresas como Zero G, DELL e HP Invent.

terça-feira, 13 de agosto de 2013

Epidemia dos bugs: corrigir agora ou postergar?

Elizabeth Hendrickson , consultora norte-americana focada em automação de testes e desenvolvimento ágil, publicou recentemente em seu blog uma análise a respeito do tempo desperdiçado em reuniões para a análise de bugs. Em seu post, a autora cita empresas que gastam muito tempo e dinheiro realizando testes, sem aproveitar bem as informações reveladas por eles.
Hendrickson relata que há uma concepção comum, mas equivocada, na comunidade de engenharia de software, de que os bugs são inevitáveis e que nem todos podem ser corrigidos. Isso justificaria a tomada de decisões de se fazer a correção ou postergá-la, com base em ROI (retorno do investimento) do projeto.
A autora trabalhou em duas companhias em que essa linha de pensamento tornou-se uma armadilha. Segundo Hendrickson, as empresas não faliram diretamente por causa dos bugs, mas esses bugs se tornaram uma "infecção generalizada" que derrubou a produtividade e paralisou times de testes e de engenheiros.
Foram os custos ocultos que nos esgotaram: horas perdidas argumentando sobre bugs em reuniões de análise; horas perdidas debatendo sobre assuntos já discutidos várias outras vezes; lutando contra um código frágil e propenso a gerar erros mesmo com alterações simples; registrando e categorizando o backlog. Isso era desmoralizante e extremamente caro.
A autora elabora algumas conclusões, de acordo com as suas experiências:
Cancele todas as reuniões para avaliação de bugs; gaste seu tempo prevenindo e corrigindo defeitos. Teste cedo e frequentemente para encontrar os bugs o quanto antes. Corrija os bugs assim que forem identificados; cuide cedo de suas janelas quebradas.
Leitores do blog registraram seus comentários a respeito do artigo. Jim Gay, por exemplo, disse:
Vi bugs que indicavam que o processo de desenvolvimento estava errado. Por exemplo, um analista diz que você deve fazer X e você implementa X, e depois os usuários perguntam porque o programa não está fazendo Y. Um erro no código ou um erro no processo significam que alguma coisa deve ser corrigida.
Gabe Newcomb não concorda com todas as considerações de Hendrickson:
O texto deixa a entender que todos os bugs devem ser corridos e o esforço para fazer isso é mais importante que o desenvolvimento de novas funcionalidades. Mas isso não bate com a minha experiência. O processo de triagem de bugs responde a questões importantes como: quando (e se) o bug deverá ser corrigido e onde se encaixa em relação a outras atividades.
Steve Fenton é um desenvolvedor que acredita que todos os bugs devem ser corrigidos:
O tempo gasto para corrigir um bug é quase sempre menor que o tempo necessário para discutir se deve ou não ser corrigido. Além do impacto no cliente, um defeito já existente pode ser lançado novamente pelo time de testes e ser fechado como duplicado diversas vezes pelos desenvolvedores. Quanto mais tempo se postergar uma correção, maiores são as chances de que custe mais do que se o defeito tivesse sido corrigido rapidamente.
O assunto relatado por Hendrickson é polêmico e sempre rende boas discussões. Você acredita que os bugs são inevitáveis? Considera que essa mentalidade pode ser classificada como uma armadilha?

Post escrito por: Michael Stal, traduzido por Leandro Guimarães. Fonte:  http://www.infoq.com/br/news/2012/09/epidemia-bugs

quarta-feira, 7 de agosto de 2013

O que é e o que faz o testador de software?

Bom dia pessoal, 

Abaixo coloquei um post muito legal sobre o que faz um testador, leiam e comentem sobre o texto.

Um testador de software, como o nome já sugere, testa softwares das empresas desenvolvedoras. Apesar de pouco conhecida, a profissão está em alta no mercado e os profissionais estão escassos.  
O profissional que testa softwares possui a função principal de avaliar a qualidade das aplicações dentro das normas internacionais estabelecidas. Se necessário, o profissional deve corrigir as possíveis falhas que forem encontradas.

O testador de software é responsável por todas as atividades dentro do processo de desenvolvimento que garantem a qualidade e eficiência do sistema que está sendo desenvolvido.

Vista como uma atividade nova no mercado, os testadores de software estão ganhando cada vez mais espaço no mercado brasileiro. Já existem muitos órgãos que só contratam empresas que produzem software somente após a avaliação do produto por testadores de software. Com o tempo, a estimativa é que as fábricas de software sejam obrigadas a ter um profissional específico do ramo.

Vale notar que apenas há pouco tempo os profissionais que queriam se especializar nesta área conseguiram obter a certificação no Brasil. Até 2006 era necessário buscar o certificado fora do país. Agora o BSTQB (Braszillian Software Testing Qualifications Board), braço oficial do ISTQB (International Software Testing Qualificationn Board) está no país para qualificar esta mão-de-obra.

Quais são as tarefas?

O testador possui uma função específica, ou seja, precisa analisar as aplicações para que possíveis bugs sejam corrigidos enquanto estão sendo desenvolvidos. Por isso é importante que o trabalho seja iniciado antes de os códigos serem escritos.

Com isso, o objetivo geral é corrigir as falhas antes que o produto final fique pronto. Qualquer falha não detectada no desenvolvimento de um determinado software pode causar grandes transtornos. Além disso, o teste feito nos softwares evita que o trabalho precise ser feito novamente, causando atrasos. Também dá mais credibilidade ao serviço.

O testador não pode poupar o software. Bem ao contrário, ele precisa ser exercitado de forma constante, assim, terá mais chances de encontrar uma falha. Deste modo, se for encontrado qualquer tipo de problema, é melhor que seja detectado na sua fase de elaboração, pois quando ele já estiver na prática, além de trabalho redobrado, poderá causar sérios danos onde ele está sendo usado.

O testador de software costuma seguir um roteiro de testes e, após o sistema estar rodando, os testes são realizados. Tais testes são feitos de forma manual ou mesmo automática. Todos os resultados costumam ser relatos em um relatório, apresentando todas a as impressões. O relatório costuma ser repassado ao desenvolvedor do sistema, para que, se necessário, realize a correção dos erros.

Logo após todo o processo, o software volta ao testador, e novos testes são feitos. Após todos os testes serem realizados e não encontrado mais qualquer erro, o software passa a ser enviado para a produção.

 

Média salarial

A média salarial de um profissional testador de software não costuma ser muito alta, apesar da crescente ascensão no mercado. Cada empresa acaba determinando um valor para o profissional contratado, bem como cada estado costuma ter alguma variação salarial. Tendo em vista tais fatores, a média que um testador de software recebe no Brasil varia entre R$ 1.500 e R$ 5.000.



Fonte: Oficina da Net:
http://www.oficinadanet.com.br/post/11183-o-que-e-e-o-que-faz-o-testador-de-software?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+oficinadanet_rss+%28Oficina+da+Net+-+Feed%29