Artigo Científico - IDENTIFICAR ETAPAS CONVERGENTES ENTRE O MÉTODO CLEANROOM E A METODOLOGIA ÁGIL SCRUM

"I'm Back"

Finalmente após mais de um ano (especificamente 381 dias) sem uma postagem, cá estou com novidades. Neste período finalizei o MBA em Governança de TI que estava cursando e trago para vocês o meu artigo científico.

O título do artigo é "IDENTIFICAR ETAPAS CONVERGENTES ENTRE O MÉTODO CLEANROOM E A METODOLOGIA ÁGIL SCRUM", o objetivo foi identificar pontos nas etapas sugeridas pela metodologia de desenvolvimento de software SCRUM que pudessem convergir com pontos identificados nas etapas sugeridas pelo método de desenvolvimento de software CLEANROOM e que pudessem de alguma maneira agregar valor no ciclo de vida do software.

A idéia para o artigo surgiu durante uma aula do Professor Leandro Alves da Silva onde ele citou um método aplicado para testes no laboratório da universidade onde ministrava aulas, este era o método CLEANROOM. Para que os resultados do artigo fossem os mais próximos de como funciona o mercado de trabalho, após elaborar a fundamentação do artigo, preparei um questionário para os profissionais de TI responderem, o qual posteriormente foi analisado e foi à base para a conclusão.

A metodologia SCRUM já é conhecida por muitos tanto na área de testes como na área de desenvolvimento de software, hoje em dia 99,99% das consultorias apresentam processos ágeis de desenvolvimento (não vamos entrar em méritos se realmente é ágil ou não, ou se utilizam corretamente.... vamos guardar como tema para outro post). Já o método CLEANROOM é aplicado principalmente para fins acadêmicos, por isso assim não é tão conhecido pelos profissionais de TI.

Aos interessados em continuar a pesquisa e se envolver com métodos e metodologias, nas referências bibliográficas estão todos os livros, artigos e documentos que utilizei para elaboração do artigo. Uma proposta de processo utilizando o método CLEANROOM e a metodologia SCRUM com aplicação prática no mercado de desenvolvimento de software além de interessante e enriquecedor pode ser o início de uma nova metodologia.

Segue o link para o artigo: http://www.4shared.com/office/vVNfxCWW/

Agradeço a todos que comentaram e visitaram o blog mesmo na minha ausência.

Desenvolver é legal, mas testar é importante!

Lambda Lambda Lambda Pessoal,

Faz tempo que não faço nenhum post aqui, tempo corrido, muito trabalho, estudos, sempre as mesmas desculpas de todo blogueiro, rsss.

Inspiração fluindo como nunca, muitas idéias de temas para escrever. Porém tenho assumido novas responsabilidades na empresa e como dizia um tio meu "Grandes poderes trazem grandes responsabilidades.".

Antes do assunto principal, vamos aos recados da paróquia:

- Agradeço imensamente a nova amiga Catharina @catharinapin do blog TECSOLLERS, a qual nos indicou no post http://migre.me/4iZk2 . Muitissímo obrigado.

- Agradeço aos novos seguidores por acompanhar e acreditar em nosso trabalho.

- E prometo que voltaremos logo com assunto muito interessantes.

Agora chega de enrolação e vamos ao assunto que trouxe o nome ao post:

"Desenvolver é legal, mas testar é importante!"

Sim, foi exatamente isto que foi pronunciado em uma reunião de equipe, pelo responsável por TI na empresa. Analisando melhor este profissional, é bem simples entender o por que ele disse esta frase. Muito provável inicou sua carreira em TI como programador, e assim foi subindo de cargo até o atual gerencial, porém carrega até hoje os vícios, pré-conceitos e capacidade lógica apurada de um desenvolvedor.

Como profissional de testes, responsável pela equipe criticada por todas as outras que acreditam que estamos "jogando contra", sendo os "dedos-duros" de seus erros, seria muito fácil desistir, concordar que somos isto ou aquilo, ou se calar e deixar rolar. MASSSSSSSS o papel de cada líder, analista, arquiteto de testes e até mesmo dos testadores, é trazer a cultura de testes para a organização em que trabalha.

Nunca, mas NUNCAAA mesmo devemos forçar nossos companheiros de trabalho, clientes, gerentes, diretores e afins a ver como nós a área de testes, a qualidade do sistema. Ao invés disso nós devemos emprestar nossos olhos para eles, para que vejam o que vemos, mas não como vemos, não seguir nosso caminho, mas estar ao nosso lado durante este longo caminho. Isto se chama PEOPLEWARE (assunto de um próximo post), pouco utilizado, pouco conhecido, mas fundamental em todas as áreas, para todos os cargos.

A mensagem que gostaria de passar hoje é de não forçar que nos vejam como a área que junto com todas as outras da organização, mas de com o tempo e com nosso trabalho, não deixar a peteca cair, não abandonar nossos ideais e princípios, e sempre procurar trazer para o nosso lado, ver o objetivo único que deve nos guiar.

That's all folks!!

PS: Este post não teve imagem como todos os outros =/ falha minha, por não ter tido tempo suficiente de procurar uma que se encaixasse com o tema.

Neste post também abusei das frases nerds, rs, mas apenas escrevi o que pensei, espero que gostem, caso contrário pulem.

Vale lembrar que este blog não possui como principal objetivo descrever passo-a-passo como fazer as atividades de teste, seguir um processo, resolver todos os problemas, mesmo porque isto já fazemos como profissão e recebemos, rs. Nosso principal objetivo é compartilhar conhecimento, compartilhar fatos do nosso dia a dia, histórias, teorias, sempre com bom humor.

Nesse tempo sem postagens, não ficamos sem fazer nada relacionado ao blog não, rs. Nós temos vários projetos para o blog como por exemplo viabilizar um testcast quem sabe?!?! Ou uma forma melhor de interagir com todos.

Abraços.

Profissional de Testes: Profissão técnica ou não?

Salve Salve Leitores

Como passaram de carnaval? Muita festa, música? Ou como muito milhões, escolheram ficar e adiantar o projeto? RS.

Bem, o assunto de hoje é um assunto há anos eu me pergunto se estou certo, ou errado ou pelo menos, meio certo: O profissão de teste de software é uma profissão técnica ou não?

Vocês no mínimo devem estar se perguntando o por quê desta dúvida, certo? E a resposta é bem simples: Há algum tempo atrás, quando trabalhava com testes para a ferramenta SAP® R/3, tínhamos uma equipe sensacional (ok, algumas pessoas podem pensar que não era tão sensacional assim, mas era uma boa equipe). Éramos em sua maioria estagiários.

Ao final do contrato de estágio, fui informado que não seria contratado. Até aí, sem problemas. O grande problema de tudo foi o motivo: “a empresa não tem orçamento para contratar alguém técnico para o time de testes (que por sua vez utiliza ferramentas de automatização)”. Em seguida, tive conhecimento da contratação de uma pessoa da área de administração e outra do curso de engenharia agrônoma (acho que era esse curso) para o mesmo time.

Não entro no mérito profissional de cada pessoa, até porque não cabe aqui este tipo de comparação, mas de onde é que tiraram que o time de testes de software não é técnico? Vocês podem estar pensando: “Ah, mas existe a questão de regras funcionais do negócio e isso não é técnico“. Ok, mas pra esses casos existe uma pessoa que se chama ANALISTA que tem a formação técnica mas que conhece regras de negócios.

Ou seja, o que fizeram, e acredito que façam até hoje e ainda pior o mercado, é pegar alguém de qualquer área e coloca ali “rodando teste” com o pessoal da T.I..

Não diria que isso menospreza os conhecimentos, mas de certa forma vejo o seguinte: pega o estagiário de T.I. e coloca ele dois anos com um advogado, manda ler um monte de livros e beleza: ele já pode advogar, ou a mesma questão com um médico.

Lembro que nessa questão ainda tinha ouvido algo do tipo: “Ah, o difícil é aprender regra funcional. Parte técnica é mais tranquilo”. Claro né, super fácil, tanto que os Analista de sistemas todos aprendem na faculdade todos os processos de negócios ao invés de linguagem de programação, metodologias de desenvolvimento e tudo mais técnico.

Bem, minha opinião acredito que vocês devem ter idéia. O profissional ele é técnico. Sim ele também deve conhecer a regra funcional pra testar o processo corretamente, mas isso não impede que ele seja técnico, afinal, acredito eu que seja mais difícil ensinar o porque de um IF apenas decidir entre sim e não ( e acreditem, já perguntaram porque dele só decidir entre sim e não) do que uma regra funcional pra quem supostamente estudou pra este tipo de coisa.

Um grande abraço, e ótimo fim de carnaval pra todos.

Fonte da Imagem:

http://4.bp.blogspot.com/_yUZDgh1fvo4/TOWy2BqIJMI/AAAAAAAAAKU/g9UJJTJj9TM/s1600/index_10.jpg

20/fev - Dia do Teste de Software

Olá pessoal,

 Apesar de estar atrasado no post, não poderia deixar de escrever sobre este assunto. Algo que era novidade para mim quando me deparei com a primeira pessoa falando sobre o "Dia do Teste de Software". Realmente não tinha me passado pela cabeça que existiria uma data para comemorar/homenagear os profissionais que trabalham com teste de software.

 Agora chega de enrolação e vamos para um pouco de cultura.

>>> História <<< 

 Em 20 de fevereiro de 1979, foi publicado o livro "The Art of Software Testing" por ninguém menos que .... Glenford J. Myers. Com pensamentos/técnicas/opiniões inovadoras para época (me arrisco a dizer que para algumas empresas, estas opiniões são inovadoras até hoje =P) e referência obrigatória em todas as publicações seguintes, o livro introduz pela primeira vez a expressão Teste de Software, que viria a nomear a nossa área.

 Devido a este fato histórico, o dia 20 de fevereiro passou a ser considerado por muitos o "Dia do Teste de Software", a comemoração do aniversário de uma profissão que está crescendo exponencialmente por todo o mundo.

 O livro apresentou e estabeleceu os principais conceitos utilizados até hoje para teste, entre eles as classes de equivalência e os valores limites. Outro destaque fica por conta do capítulo dedicado a Econômia do Teste de Software, onde fomos apresentados a "Regra 10 de Myers", com a visão de que teste reduz custos de construção e manutenção do software na forma de diagrama.

 Atualmente, sabe-se que os custos de identificação e correção de erros não são multiplicados exatamente por 10 a cada fase do projeto, mas o princípio de que quanto mais cedo testarmos, mais barato será identificar e corrigir o defeito continua válido e serviu de base para a outros estudos como:

> Análise do ROI - Retorno de Investimento por Rex Black;
> Gráfico aperfeiçoado por Boehm, onde foram introduzidas margens de variação no custo.

 Por fim, parabenizo a todos que fazem parte da área de Teste de Software, e direta ou indiretamente fazem esta crescer e evoluir com sua dedicação e empenho.

 Não deixe que esta data passe em branco, divulguem, publiquem, comemorem!!!!

Abraços.

Fonte imagem: http://farm1.static.flickr.com/5/6688756_6c6cc85924_z.jpg

Livro - Base de Conhecimento em Teste de Software

Prazer Pessoal,

Sou a Marcella e a partir de hoje contribuirei sempre que possível com as minhas experiências e conhecimentos sobre analise de testes, processo e automação de teste.

Para iniciar, gostaria de recomendar o livro "Base de Conhecimento em Teste de Software" dos autores "Emerson Rios / Aderson Bastos de Souza / Ricardo de Souza Cristalli / Trayahú Rodrigues Moreira Filho".

Quando iniciei na área de qualidade de software, um amigo me indicou este livro para adquirir conhecimentos na área, posso dizer que gostei muito da indicação, e até hoje procuro utilizar os conhecimentos compartilhados no livro de forma simples em apresentações para iniciantes na área de qualidade ou até mesmo em vendas, onde o seu cliente não conhece a disciplina de testes.

Alguns dos temas tratados pelo livro são:

- Introdução ao Processo de Teste
- Custo da Qualidade
- Processo de Teste (Ciclo de Vida, Técnicas, Atributos, entre outros)
- Preparação do Ambiente de Testes
- Análise de Risco (Definição e Controle)
- Estimativas
- Planejamento, Elaboração e Execução
- Gestão de Defeitos
- Relatórios

Estes que listei são os que considero interessantes para iniciantes, lembrando que não se deve seguir o livro ao pé da letra, pois "cada caso é um caso" e nem sempre a solução (documentação, processo, tratamento) apresentando pelo livro é o ideal para a situação/projeto em que você pode estar alocado.

Com base nestes tópicos também é possível preparar uma apresentação bem legal, tanto para um treinamento básico, como para a venda de uma equipe de qualidade interna ou externa (terceirizada), ao explorar a necessidade, os problemas (principalmente o custo) causados pela falta de um processo de qualidade, como preparar uma área de qualidade, quais as reais necessidades e quais os retornos previstos, como medir a qualidade da área de qualidade (se o time de qualidade cuida da qualidade, quem cuida do time de qualidade? .... Acreditem o cliente realmente precisa de uma métrica que apresente quanto a equipe de qualidade está auxiliando, mas isto já é tópico para outro post =] ).

Por hoje é isso.
Comentários, sugestões. opniões e suas experiências serão sempre bem-vindas.

Abraços.


Fonte imagem: http://compare.buscape.com.br/base-de-conhecimento-em-teste-de-software-aderson-bastos-ricardo-cristalli-trayahu-moreira-emerson-rios-8599102893.html

O início de tudo - 1ª Evidência de Teste e Origem do Termo "Bug"

Olá Pessoal,

 Post bem rápido e simples hoje, simplesmente uma curiosidade, algo que acrescente conhecimento sobre a área de teste para nós.

 Não sei se realmente as informações abaixo são 100% exatas, porém gosto das mesmas e acredito que mesmo que não seja a primeira evidência de teste conhecida, ou que a origem do termo bug não seja a qual falarei, ambas me parecem bem plausíveis e não sou o primeiro a utilizá-las em apresentações.

 Vamos lá!!!

 A foto abaixo apresenta a primeira evidência de testes conhecida. A história que sempre ouvi e que passo a frente é que esta evidência foi tirada quando em um grupo de analistas estavam tendo problemas com as execuções das tarefas da máquina "Harvard Mark I" em 1945.

 Como é possível notar na imagem, eles descrevaram passo a passo o que estavam fazendo, com horários e resultados, até o momento da falha onde por incrível que pareça, identificaram que era por conta de um inseto (aparentemente uma barata queimada pelos circuitos) e colaram o mesmo na evidência descrito como "BUG".

 Poxa legal, mas então foi daí que surgiu o termo "bug" quando fazemos referência a um erro/defeito/falha em um sistema?

 Nãããããoooooo!

 O termo "bug" surge por volta de 1878, quando Thomas Edison (foto abaixo) ao enfrentar dificuldades com o funcionamento de seu fonógrafo, abriu o aparelho e voilá, ele encontrou um inseto, assim batizando o defeito/falha/erro como nosso tão conhecido "Bug".

 Hummm.... interessante mas o que isso não tem nada a ver com o que faço no dia-a-dia Rafael. Nunca escrevi um caso de teste pensando se teria barata (ou seja lá o que for que seja o inseto, rs) dentro da máquina.

 Pessoal, a função deste post é trazer cultura e conhecimento sobre a área em que trabalhamos, a qual dedicamos parte do nosso dia. Acho interessante conhecermos a origem dos termos que usamos, a origem dos documentos com os quais trabalhamos, nunca se sabe quando será necessário explicar para alguém com o que é que você trabalha!! =D

Abraços à todos.


Fonte imagens:
http://smeira.blog.terra.com.br/files/2008/08/bug-hopper-bigger-500px.jpg
http://www.biografiasyvidas.com/monografia/edison/fotos/edison_fonografo.jpg