segunda-feira, 23 de agosto de 2010

Características que compõem o perfil de um Analista de SQA

Algumas vezes já ouvi pessoas dizerem que qualquer profissional que domina o conhecimento dos processos de desenvolvimento de software ou tem alguma capacidade de compreensão técnica e o raciocínio lógico requerido por todo profissional especializado em TI, tem também a capacidade de testar um software ou sair por ai planejando projetos de testes sem nenhuma técnica especifica ou vivência no assunto em questão. Com um raciocínio, digamos indutivo, posso afirmar o mesmo que diz o slogan da Foundation for a Drug Free World: “They Lied”, ou seja, “Eles Mentiram”. Não é por acaso que utilizei o slogan desta respeitosa fundação internacional de combate as drogas, afinal, quem pensa que testar um sistema é simplesmente sair achando erros e ter uma visão fechada desta forma pode ser explicado popularmente, como “Uma Droga!”

Um profissional de qualidade de software, não diferente dos profissionais de qualidade das outras áreas, tem um perfil próprio que pode gerar a partir de seu caráter pessoal, mas nem sempre são exploradas em totalidade, quando o mesmo não se especializa ou não mantém seu conhecimento atualizado com as novas técnicas ou melhores práticas de execução de teste de software* aplicadas no mercado em sua região global.


Estava comparando personagens de filmes com nosso cotidiano de vida real e atribuindo a eles funções que possam integrar do seu caráter “imaginário” aos requisitos necessários das funções desenvolvidas no mercado atual e um personagem que no meu ponto de vista seria um grande analista de SQA, seria o Alfred o mordomo do Bruce Wayne, nos filmes da série do Batman. Alfred se destacava pela sua capacidade de precisão ao tomar decisões diante dos problemas decorrentes por mau uso dos sistemas desenvolvidos e por falta de maturidade nos processos que Bruce enfrentava, também, tinha autocontrole onde não se permitia levar por emoção ou razão, agia de forma certa e na hora certa. Com seu poder de interpretação garantia uma conduta precisa no quesito do “deve ser feito” e “como fazer”, baseando sempre em evidências precisas para tal ação. Era colaborativo, não desrespeitava as opiniões dos outros personagens, mas não deixava de expor o seu ponto de vista para garantir um trabalho seguro e critico focando no que era construtivo para uma melhor qualidade de execução de todos os módulos do software, que neste caso era o Batman e todos os apetrechos. Trazendo Alfred para a vida real, temos sim nosso perfil profissional, não como servos, empregados ou escravos do ofício, mas sim como verdadeiros amigos, especializados e diria até mesmo pais do projeto, quando o foco principal é a boa utilização e aceitação do cliente!


Bom é isso pessoal, espero que encontremos em nós os Alfreds da qualidade e não permitamos que os coringas do ofício tragam para nós charadas não resolvíveis, impulsionando-nos a assumir o papel de duas caras e assim reportarmos gatos feitos no sistema de forma fria como a de um pingüim...


*Um exemplo é o processo de melhoria de teste de software brasileiro (MPT.br). Maiores informações: MPT.br

Fale com Vitor Stelari através do e-mail para vstelari@aeiou.pt


-------------- Read this topic in english version --------------
"Now you can read my topics in english version"

Characteristics that make up the profile of a SQA Analyst

Some times I’ve heard people say that any professional who mastered the knowledge about process of software development or have some capacity technical for comprehension and logical reasoning required for all professional specialist of IT, also has the abilities for test software or it’s able to go away planning test projects without any technical or specific experience in the subject matter. With reasoning, considering inductive, I can say the same as the slogan says the Foundation for a Drug Free World: “They Lied”. It’s no coincidence that I used the slogan of this respectful international foundation to combat drugs, after all, who thinks that test system is simply finding out erros and have a closed vision in this way can be explained popularity as “A Damn!”

A software quality professional, not different the quality professional of other areas, has own profile that can generate from their personal character, but not always operated in full, when it’s not specialized or not keep their knowledge updated with new techniques or best practices in executing tests in software* applied in the global market.

I was comparing movies characters with our day-a-day and attributing to him functions that can be integrate with their character ”imaginary” as necessary requirements of functions developed in actual market and in my point of view a character that would be a great SQA analyst is Alfred, the Bruce Wayne’s employee at the series movies Batman. Alfred stand out him the capacity and precision to take a decision about problems that occurring for bad use of the systems developed and for immaturity in the processes that Bruce faced. He had self control and not allows himself to move by emotions or reasons, he acted properly and in the best time. With him power of interpretation he assured a right conduct in the question “should be do” and “how do it”, based always in right evidences for each action. He was cooperative, respected the opinion of others characters, but not letting to show him point of view for assure a security work and critical with focus in what was constructive for the best quality of execution in all modules of the software, in this case was the Batman and the paraphernalia him. Comparing Alfred as our real life, we can see our professional profile, not like a servant or slave ploy, but like a true friend specialized and can say else project’s father with the principal focus in the good using and accepting of the client.

Well that’s it people, I hope that we meet in us the Alfred of quality and not allow us that joker ploy bringing us puzzles not resolvable, pushing us to assume the paper of two faces and so, we reporting “cats” in the system, cold as a penguin.

A exemplo is the “processo de melhoria de teste de software brasileiro (MPT.br)”. More information: MPT.br

Talk with Vitor Stelari by e-mail vstelari@aeiou.pt

sexta-feira, 6 de agosto de 2010

Falta de teste Beta causa falha no Adobe Flash 10


No domingo do dia 06 de junho de 2010, a revista Info da editora Abril, divulgou uma falha causada por falta de teste na versão do Flash 10.0.4. Veja:

Adobe admite falha grave em Flash 10.0.4

SÃO PAULO - A Adobe admitiu, neste final de semana, que a versão mais recente do Flash sem a etiqueta beta enfrenta dificuldades.
Segundo a companhia, uma falha de segurança permite que crackers ofereçam códigos maliciosos aos usuários usando a aplicação em Flash. A Adobe não divulgou quando terá uma correção para o problema, embora trabalhe neste momento para superá-la.
A companhia recomendou ainda que quem deseje ter os recursos da versão 10 do Flash pode fazer upgrade para a versão beta 10.1, que não é afetada pela falha de segurança
A Adobe publicou ainda uma documentação detalhada* de como empresas e desenvolvedores podem se defender da falha.

Fonte: Portal Revista INFO


Este tipo de falha, foi admitido pela própria empresa como falta de teste no produto, uma vez que a empresa não lançou a versão Beta para que os usuários reportassem os bugs encontrados em produção antes de seu lançamento oficial no mercado. Veja a nota oficial divulgada no site:



*A documentação detalhada encontra-se no link: http://www.adobe.com/support/security/advisories/apsa10-01.html

Um dos fatores que podem ter proporcionado este tipo de plano de ação, seria a necessidade de gerar receita do produto (com a venda, licenças e etc) em menor tempo ou porque o projeto estaria em atrasado para o lançamento.
Estes tipos de problemas são comuns de ocorrer nos projetos desenvolvidos, porém são evidências concretas da importância de testar um software em sua totalidade, mesmo que isso gere atraso para o lançamento, uma vez que, o custo de correção tornasse 10 vezes maior quanto mais tarde for encontrado (veja mais informações em Regra 10 de Myers*), até que o mesmo esteja confiável e com baixo risco de re-trabalho.

* Regra 10 de Myers – É uma regra criada que define valores de custo de correção para cada fase do projeto, ou seja, quanto mais tarde for encontrado um erro, mais caro torna-se a correção em múltiplos de 10. Ex: Fase inicial o custo é 1, na fase de elaboração o custo é 10, na fase de construção o custo é 100, na fase de implantação o custo é 100.

Falta de Teste ou Falta de Atenção?

Vimos até aqui um exemplo do que pode causar a falta de teste em um projeto. Agora vamos ver um exemplo do que pode ocorrer com a falta de atenção nos testes, ao disparar um spam com promoções de produtos do e-commerce Walmart.

Ontem no dia 05 de agosto de 2010 eu recebi um e-mail do Walmart, com as promoções do setor de informática e tecnologia, conforme abaixo:



Ao ver o preço deste computador, me interessei pois estava baixo para a máquina oferecida, sendo ela um Core 2 Quad, 1 tera de HD e 4 gigas de memória. Continuando a ler o e-mail vi mais abaixo uma outra máquina, com outra configuração inferior e o mesmo preço. Veja:



Ao ler novamente o e-mail verifiquei que constava a frase: “A partir de”, então resolvi clicar para comprar o produto, lembrado que deveria conter a configuração especificada no e-mail e o mesmo valor, porém, a página exibiu o valor diferente. Veja:



Creio que ocorreu uma confusão entre os valores dos dois produtos citados no momento em que o Web Designer resolveu liberar a propaganda e disparar os e-mails. No meu ponto de vista este tipo de falha encontrada é derivado de uma falta de atenção e não uma falta de testes, como ocorreu no Adobe Flash 10.0.4. É necessário que todos os envolvidos no projeto testem suas atividades independentemente se o mesmo passará ou não pela equipe de qualidade validar o trabalho desenvolvido. A criticidade da informação errada equivale ao nível de importância do produto, porém, são inúmeros os fatores que englobam o não aceite do cliente, como por exemplo, falta de confiança, stress, perca de credibilidade, etc.

Bem pessoal, espero que este meu ponto de vista tenha sido explícito de uma forma construtiva para visionar as empresas a terem maior investimento em qualidade e teste de software, também, espero que impulsione os desenvolvedores, analistas e as equipes que cuidam da web/marketing na construção de melhores projetos e com maior satisfação entre os usuários. E nós de Qualidade de Sistemas estamos aqui prontos, para encontrar o maior número de defeitos e melhorias nos softwares desenvolvidos e garantindo um produto qualificavelmente superior e aplausivo quando comparados aos dos nosso concorrentes!

Abraço aos leitores e agradeço pelos e-mails enviados!

Envie você também, seu e-mail com matérias, posts, sugestões e criticas, para:
vstelari@aeiou.pt

segunda-feira, 2 de agosto de 2010

Links Úteis

Criei este post com alguns links interessantes que podem nos auxiliar. Pretendo atualizar sempre que encontrar algo interessante para compartilhar, por isso peço a ajuda dos amigos para que me enviem novos links nos comentários ou por e-mail vstelari@aeiou.pt e assim estarei postando no blog!! Agradeço a todos que já ajudaram...

Selenium = Site para download da Ferramenta de Automação Selenium

Opensourcetesting = Ferramentas Free de apoio para testes de sistemas

Testexpert = Comunidade de Teste e Qualidade de Software

Adrive = HD Virtual FREE com 50Gb

Macrotesting = Free Magazine about Software Testing

MPT.br = Melhoria do processo de teste de software brasileiro

sexta-feira, 30 de julho de 2010

É impossível implantar a cultura de teste nas empresas em que o segmento não é tecnologia?




A palavra impossível é talvez aquela que todo profissional especializado em testes de software abomina de sua vida. Não por ser irreal, mas por não ser aceitável em sua desenvoltura profissional. O significado de impossível é classificado em nosso vocabulário como “não pode ser”, “não se pode fazer”, ou seja, é um pré-requisito para o fim de um trabalho de sucesso. É comum que as empresas tenham sua visão focada na estrutura do negócio ao que pertencem, ou seja, quando não são filhas maternas da tecnologia, a evolução tecnológica torna-se um complemento, enquanto, nas demais empresas que produzem a mesma, têm isso como vital. Ao longo do tempo todas as empresas através de seus gerentes, diretores e presidentes, estarão vendo tecnologia, como fundo de investimento para realização de um trabalho de sucesso e com alta qualidade.
Mas o que fazer quando se trabalha em uma empresa onde seu negócio não esta focado diretamente em tecnologia? Como implantar a cultura de testes de sistemas numa área de TI que desenvolve seu próprio sistema? Como conduzir que os testes sejam executados dentro do modelo atual do mercado?
Através da minha experiência com este tipo de situação posso dizer que é uma tarefa árdua e que gera certa dor de cabeça para quem aceita este tipo de desafio. Caso algum dia você receber ou já tenha recibo uma proposta de iniciar uma área de testes na sua empresa, é importante frisar algumas recomendações, para sobreviver neste novo projeto:

- Crie um plano de implantação: Identifique o todo, ou seja, o que você pretende desenvolver dentro da empresa, faça uma análise daquilo que é necessário e possível de se implantar dentro do modelo de gestão atual e separe as partes. Produza uma estratégia de implantação para isso de acordo com a ordem de necessidade de negócio da empresa em questão.

- Não tente mudar todos os processos de uma vez: Mesmo que o gigante seja bem maior do que você imaginou, você pode ir devagar o atingindo aos poucos, começando pelo ponto mais baixo, até chegar ao topo e dar o bote final! Não adianta querer trazer todo modelo de mercado de uma vez para dentro da empresa, mas sua tarefa é adaptar a empresa de acordo com ele.

- Tenha paciência com sua liderança: Provavelmente sua liderança não é especializada em testes de software, afinal não teria o porquê de te contratarem, então quando você for expor suas idéias tente demonstrar a necessidade e os porquês da realização de tais tarefas. Demonstre de forma clara os tipos de testes que você estará realizando, porque a verificação de tal artefato é importante para o trabalho que você pretende desenvolver e qual sua importância para os negócios da empresa. Utilize gráficos, mostre lucro e aumento de receita, os lideres sempre interpretam melhor este tipo de demonstração.

- Crie uma metodologia de teste: Geralmente as empresas que fabricam seu próprio ERP não têm uma metodologia de desenvolvimento ou até possuem, porém é focada no desenvolvimento e análise de sistema, mas a idéia inicial é que você utilize desta metodologia para criar uma independente focada apenas nas atividades pertinentes aos testes e qualidade do sistema. Como a área de qualidade esta presente do inicio ao fim de um projeto, não existe problema de termos esta metodologia independente, porém integrada, que utilizará de base o desenvolvimento e controle das suas atividades, somente relacionadas ao teste de software. Lembrando, que não se pode descartar a metodologia de desenvolvimento já implantada, esta será a base que definirá o tempo em que andará os processos desta sua nova metodologia de testes.

- Utilize as ferramentas mais apropriadas:
Busque as ferramentas que melhor se adéqua à área. Hoje temos o privilégio de existirem muitas ferramentas interessantes no mercado, sendo grande parte Open Source, então cabe a você analisar qual ou quais são as melhores para seu plano de implantação*.

- Prepare sua equipe de testadores: Deixe sua equipe consciente do trabalho que você deseja desenvolver, caso exista alguém que também traz experiência do mercado, em qualidade de software, troque este tipo de experiência e produza mais em equipe. Este tipo de tarefa auxilia na evolução e amadurecimento dos profissionais envolvidos. Não permita que novos testadores que provavelmente você estará formando, tenha vícios antigos, da forma de trabalho antes executado e que estes vícios influenciem na metodologia de testes que você estará implantando. Estes velhos hábitos geram improdutividade do profissional ou até mesmo da equipe.

- Seja compreensivo com os desenvolvedores e analistas de sistema: Eles não estão acostumados a ter alguém toda hora olhando o trabalho deles e apontando seus erros, então é importante que, você conscientize-os de que o trabalho que você esta desenvolvendo é na verdade uma ajuda para que futuramente eles mesmos não tenham re-trabalho naquilo que eles desenvolveram. Adquira a confiança deles, concentre-se no problema resolvido e não nas pessoas envolvidas nele, não entre em conflito com elas.

- Apresente um feedback: A cada fase do projeto, ou etapa de teste concluída é importante apresentar aos interessados, o feedback do que você executado, quais Bugs foram resolvidos, a quantidade de cenários de testes realizados, a evolução adquirida neste ou nestes projetos, entre outros... Lembre-se que “a gestão e liderança entendem melhor gráficos do que texto” então crie sempre gráfico para demonstrar de forma clara a sua produção até este momento.
Estas são apenas algumas dicas que eu creio que vão auxiliar bastante, os profissionais que enfrentam este desafio de implantar a cultura de testes nas empresas e tem como objetivo criar uma área de qualidade dentro do setor de TI da empresa, mesmo esta ainda necessitar de uma ajudar externa para identificar a real necessidade de um equipe disposta para qualificar um melhor trabalho desenvolvido.
Boa sorte para vocês que estão passando por isso, assim como eu passei e ficarei feliz se publicarem suas idéias. Espero ter ajudado de alguma forma, creio que nós podemos nos ajudar com dicas e possíveis macetes para driblarmos tarefas que possam causar divergências de opniões ao longo deste desafio.
Abraço,

*Referencias
Site de ferramentas de testes OpenSource: http://www.opensourcetesting.org/