TDC2014 Floripa: como foi

26 05 2014

E mais um TDC passou! O evento está crescendo a cada ano e isso mostra como as pessoas estão ansiosas por conhecimento e inovação. Vou falar um pouco mais especificamente da trilha a qual coordeno, a de Testes.

Este ano tivemos cerca de 200 inscrições, 100% a mais do que no ano passado! Já agradeci no evento e volto a agradecer novamente por aqui: MUITO OBRIGADA! Sinto que a responsabilidade é muito grande, escolher palestras interessantes para este público tão crítico e sedento de qualidade não é fácil. E por isso vou falar um pouco sobre a composição da trilha deste ano.

Eu tive a oportunidade de ler algumas críticas realizadas no formulário entregue e a maioria só avaliou as primeiras palestras. Uma pena, mas foi um erro nosso. Deveríamos ter entregue ao final do evento, dessa forma teríamos mais críticas a respeito de todas as apresentações. Mas ok, anotado para o próximo ano.

As críticas giraram em torno do mesmo assunto praticamente: palestras com o mesmo assunto. Levando em consideração que as pessoas não avaliaram todas as apresentações, apenas as 3 primeiras da manhã, elas têm razão. Mas isso foi proposital. A organização da trilha ficou separada por assuntos, um bom observador teria entendido a distribuição das palestras.

1. Automação de testes para não programadores com o método Keyword-driven – Cristiano Caetano

Esta palestra serviu como uma introdução à trilha. Foi escolhida por ser um case – proposto por um palestrante renomado –  e utilizar um método de automação para não programadores.

2. Seja um tester ágil! – Daniel Ricardo de Amorim e Raquel Liedke

3. Chaos in test – Carlos Tadeu Panato Junior e Fausto Siqueira

Essas duas palestras tinham o mesmo tema: o papel do testador, do QA em um time ágil. Mas percebam que apesar de falaram sobre o mesmo assunto, os personagens trabalham de formas distintas. Essa era a intenção: mostrar aos ouvintes que o papel de um testador ou do QA em um time ágil na maioria das vezes se difere de acordo com as características das equipes. A responsabilidade pode ser a mesma, porém o modo de agir pode diferir. Conhecer as formas de interação dentro da equipe pode auxiliar um novo testador a entender o seu papel dentro do time.

4. Quando meus testes terminam, se os ‘bugs’ não acabam? – Welington Costa Monteiro

Outro estudo de caso mas que abordou assuntos como diagramas de atividades, casos de uso, matriz de rastreabilidade, UML, gestão de defeitos e como tudo isso junto colabora com a qualidade do sistema. Este é um assunto pouco abordado nos blogs mas que é a realidade de muitos colegas por ai.

5. Melhorando sua Estratégia de Testes Automatizados – Stefan Teixeira

6. Protractor – Testando aplicações AngularJS – Daniel Ricardo de Amorim

7. Espremendo Melancia: Watir+PageObject – Carlos Tadeu Panato Junior, Alex Warmling e Fausto Siqueira

8. Como testar sua aplicação Android e iOS – uma abordagem prática – Elias Nogueira

Inevitavelmente, as últimas palestras giraram em torno do tema que é tendência e veio pra ficar: automação de testes. Embora as empresas não estejam ainda tão maduras em seus processos para que possam aplicar de uma vez a automação de seus testes, alguns QAs por iniciativa própria já praticam ou começaram a realizar “pilotos de automação” em seus projetos. A intenção aqui era apresentar a gama de ferramentas e técnicas que podem auxiliar as equipes na definição e escolha da melhor ferramenta para o desenvolvimento de automação de testes de acordo com as características do seu projeto.

Algumas imagens:

Este slideshow necessita de JavaScript.

Mais imagens na fanpage do TDC.

 

Algumas considerações:

  • O atraso na abertura não prejudicou o tempo das palestras da manhã. Respeitamos o tempo proposto para a apresentação e para as perguntas. Infelizmente por termos um tempo apertado, não foi possível realizar um maior debate entre as palestas, mas todos os palestrantes ficaram até o final do evento.
  • Nós realmente gostaríamos de ter uma gama maior de assuntos na trilha, mas somos reféns das submissões de vocês leitores! 85% das submissões são sobre utilização de ferramentas, já pensou que chato seria se todas as palestras fossem assim tão técnicas? Quem sabe ano que vem aparecem mais temas como MPS.Br, CMMI, processo de testes, ferramentas de gerenciamento de erros… #ficaadica.
  • O TDC não é um evento acadêmico, por isso não esperem profissionais com perfil de professores. O TDC é uma oportunidade para qualquer pessoa apresentar um assunto que considere relevante para a comunidade. Não importa se é um palestrante profissional ou apenas um bom profissional da área. A intenção é compartilhar experiências. Se você está esperando por um mini-curso-relâmpago, a trilha não vai lhe proporcionar isso.

Infelizmente não há como agradarmos a todos, alguns reclamaram dos palestrantes, temas repetidos, sanduíche do almoço frio, localização do evento longe, áudio ruim, sala gelada, sala quente e por ai vai! Acha que é fácil?

Sabe de nada, inocente!

Sabe de nada, inocente!

 

Sabe de nada, inocente!! Mas o resultado final foi bem positivo, e vou guardar as críticas construtivas para o ano que vem, afinal, é errando que se aprende, não é?

Obrigada a todos os que participaram!





Revizáo de testo praquê?

4 04 2014

Não, eu não estou assassinando a língua portuguesa. Sim, o título deste post está escrito erroneamente de propósito. Dói a vista não é? Você pode se perguntar, mas qual a relação disso com qualidade de software? Eu respondo: tudo a ver. A qualidade do seu software começa na escrita dos requisitos. Requisitos mal escritos podem gerar ambiguidade, dúvida e confusão na hora do desenvolvimento. Eu já peguei algumas documentações tão mal escritas que fiquei com “vergonha alheia”. Outro dia tava vendo uma apresentação no Slideshare, onde estava escrito no título de váaaaarios slides: ANDRIOD e não Android. Se você vai publicar sua apresentação na web (leia-se: TODO MUNDO VAI VER), pelamordedeus, revise!! Agora, veja esta imagem e me conte a sua opinião (clique na imagem para aumentá-la):

Muita preção!!

Muita preção!!

Achou o erro? E de quem você acha que foi o erro? Do analista de requisitos, do desenvolvedor, do testador ou do estagiário? Eu respondo: de nenhum deles! O erro está na falta de um processo de revisão. Eu já tive a oportunidade de trabalhar em projetos com a equipe era bem multidisciplinar. Tínhamos doutores e mestres em engenharia do conhecimento, administradores, especialistas em BI, desenvolvedores seniores, engenheiros de software E revisoras de texto! Sim, eram elas as responsáveis por revisar todos os documentos, desde contratos até essas mensagens de feedback para o usuário. Sentavam ao lado do desenvolvedor e faziam um trabalho de formiguinha, analisando cada mensagem de acordo com o contexto da tela. Aprendi com elas que a qualidade está nesses detalhes (saudade delas!!). E é o tipo de coisa que ninguém dá valor até encontrar um erro, como este ali de cima.

Daí você pode pensar: “ah mas eu não tenho um revisor na minha equipe e nem tenho dinheiro para investir nisso”. OK, acredito que isso possa sim acontecer, mas você tem os pares, você tem outros membros no time que podem fazer uma revisão com olhar mais crítico, o próprio QA tem a obrigação de primar pelos detalhes. Eu tive que fazer uma graduação em letras inglês pra descobrir que não sou fluente na minha própria língua mãe.

Tenho visto muitos blogs onde as pessoas apenas vomitam o que pensam, não se dão o trabalho de reler o que escrevem. Os pensamentos ficam soltos, sem coesão, sem conexão. Vão escrevendo como falam, não usam pontuação (eu já falei sobre isso em outro post), muito menos o corretor ortográfico. Gente, não custa nada você pedir pra alguém ler seu texto antes de publicar! Outro motivo que você pode pensar em me dizer é: “meu desenvolvimento é ágil, não tenho tempo pra revisão”. Helloooo, ágil não é sinônimo de desleixo!! Desleixo é deixar passar um “precione” na produção. Põe lá como tarefa da sprint: revisar mensagens de feedback; revisar escrita de histórias de usuário, revisar label dos botões. Faça da revisão uma tarefa!

E olha o que eu achei no jornal de hoje!

Precione!!

Precione!!

Outro exemplo de mensagem ambígua: Sim ou não O contexto da mensagem é o seguinte: um spam típico onde eu cliquei em descadastrar o e-mail. O meu desejo inicial era o de remover meu e-mail da lista, ou seja, cancelar o recebimento deles. Em momento algum eu cliquei em alterar configurações. Na mensagem de feedback eles misturaram as duas ações que eu poderia fazer e me deram duas opções: SIM ou NÃO. Daí eu fiquei pensando onde clicar: SIM, eu quero cancelar. NÃO, eu não quero alterar as configurações. Apesar da dúvida, cliquei no SIM, e para a minha surpresa, nova página com outras informações apareceram, para que eu então confirmasse o cancelamento. Gente, não tenho que dar satisfação do motivo pelo qual eu não quero receber algum e-mail, ainda mais quando é publicitário! Mas acreditem, eu tive que informar!! Mas penso que aqui essa enrolação é estratégica, pra fazer o usuário desistir do descadastramento. Mas eu fui até o fim!!

É aquele negócio, seja o exemplo, comece por você! Quem trabalha com qualidade deve ser exigente em todos os sentidos. Errar é humano, claro, mas seja humilde o suficiente para pedir ajuda, não há nada de errado nisso. Pra finalizar, um exemplo de mensagem de feedback para o usuário muito bem bolada. Era isso que as meninas da revisão faziam com as mensagens dos nossos produtos, tornando-as amigáveis e significativas!

Cool!!

Cool!!

Pense antes de escrever e revise o que escreveu! Isso serve pra qualquer área da sua vida: um e-mail, um recado, um post no blog ou até mesmo nas redes sociais, um caso de teste, um caso de uso, uma história de usuário. Lembre-se que o objetivo da comunicação é passar uma mensagem. Cabe a você garantir que o seu significado seja recebido pelo outro sem ruídos e interferências.

Agora, vou “precionar” vocês pra me darem uma opinião!





2011 chegou, passou e 2012 na mesma pressa!

16 08 2012

Gente, isso aqui tá cheio de teia de aranha, hahaha, sério! Prometi no último post que encontraria tempo pro blog, mas não deu. 2011 voou! Trabalhei muito, estudei demais (meeeesmo) e agora 2012 tá no mesmo ritmo. Tô terminando a pós em Qualidade e Engenharia de software, mas ainda tenho 2 semestres do curso de letras inglês na UFSC. Mas já tenho em vista duas oportunidades de mestrado, ai ai. Os sonhos não param, e neste meio tempo ainda quero me dedicar pra minha futura eterna profissão: ser mãe!

Mas o post de hoje é só pra tirar a poeira e falar que estou viva sim, com alguns projetos em vista e o mais recente é a palestra no TDC de Floripa, que acontecerá nos dias 24 a 26 de agosto de 2012, na Faculdade Estácio de Sá, em São José.

O tema da palestra é o mesmo do meu artigo da pós: Melhoria de processo: Ver e Var segundo os modelos CMMI, MPS e ISO/IEC 15504. Mais informações sobre o evento você pode obter no site do mesmo: TDC FLORIPA.

Passa lá, nem que seja só pra me dar um OI!!!!





O valor de uma vírgula

5 08 2010

Este não será um post de minha autoria, mas poderia ter sido, rsrs. Explico: sabe quando você lê alguma coisa e pensa: “Poxa, por que não pensei nisso antes???” O texto do Edwagney, fala sobre a qualidade dos textos na descrição dos requisitos de um software. E isso tem tudo a ver comigo por dois motivos: trabalho com qualidade e sou estudante do curso de  letras (inglês), e por isso também me preocupo muito com o modo de como os requisitos e casos de uso são escritos, se estão transmitindo corretamente a informação. Gostei muito do texto e gostaria de compartilhar com meus leitores. Espero que gostem!

===================================================

Caros amigos.

Ao contrário do que muitos pensam, Qualidade de Software vai além da investigação e busca por defeitos em umsoftware. Ela começa na fase de levantamento de requisitos.

De forma análoga, imagine quando você vai comprar um carro. Quais requisitos você pede? o que o carro precisa ter para que você se sinta bem ao comprá-lo? Em software é a mesma coisa… Requisito é aquilo que o cliente deseja receber quando o software ficar pronto. E a qualidade desse software será avaliada pelo cliente, ou seja, estou feliz com o que recebi?

Tá, mas o que isso tem a ver com o título desse post?

Tudo que fazemos surge de um desejo. Depois materializamos esse desejo. Em um projeto de software essa materialização começa na transposição do desejo para o papel e é nesse ponto que os defeitos começam a ser introduzidos nele. Portanto, qualidade de software está intimamente ligado à qualidade do texto que escrevemos para tornar nosso desejo em realidade.

Hoje recebi um e-mail de uma amiga sobre o uso da vírgula. E isso me deu a idéia de levantar uma questão importantíssima e que, sob meu ponto de vista, vejo cada vez mais sendo colocado de lado por muitos profissionais. O Português!

Não existe mais, ou não pode mais existir aquele pensamento de que pessoas ligadas às áreas de exatas não ligarem muito para o Português. Aquele pensamento de que, “isso pra mim não é importante, preciso apenas escrever códigos e fazer o software funcionar.” Esse é um pensamento retrógrado e arcaico. Ou você acha que para escrever um e-mail não precisa conhecer regras de português? Acha que todos os e-mails que escreve pode usar “vc” ao invés de “você”. Pode usar “naum” ao invés de “não”? Pior ainda e é aí que quero chegar, uso davírgulaconcordância.

Não é raro pegar documentos de requisitos onde o uso incorreto da vírgula muda completamente o sentido do texto. E isso para a materialização do desejo, é um tremendo erro que certamente se tornará um defeito grave no futuro, caso não seja identificado nas fases iniciais de um projeto de software.

Portanto, profissionais de qualidade, antes de estudarem técnicas e mais técnicas, irem atrás de certificações, etc, pensem em como está o nível do Português. Pensem na forma como estão escrevendo. Ao contrário do que muitos pensam, muita gente escreve textos gigantescos sem nenhuma, isso mesmo, nenhuma pontuação. Não precisa muito esforço. E-mails é o meio mais comum de disseminação dessa prática. Será preguiça de quem escreve? Talvez seja, mas que é ruim e doído de ler, isso é.

Certa vez, em um dos fóruns que participo, tivemos uma discussão acerca desse assunto. Para minha surpresa, um dos integrantes justificou que grande parte dos participantes eram estagiários e que erros desse nível era normal ocorrer, pois estavam aprendendo. Achei engraçado e ao mesmo tempo entrei em pânico, pois se eram estagiários, obviamente estavam em alguma faculdade. Ora, pelo que eu sei, a disciplina que mais pesa em um vestibular é o? PORTUGUÊS!!! Aeee!!! (mas pelo visto não era o caso deles).

Outro ponto levantado foi a justificativa de que existe muita literatura em Inglês e isso faz com que o Portuguêsfique de lado. Mais um motivo para entrar em total desespero. Quer dizer que se eu aprender o Inglês, devo esquecer meu idioma nativo? E se eu aprender outro idioma, devo esquecer o Inglês? Uma lógica um tanto quanto estranha…

Para aprendermos um outro idioma, necessariamente espera-se que pelo menos o SEU idioma seja dominado. Você fala e estuda ele desde que nasceu e TEMOBRIGAÇÃO de saber lerfalarescrever muito bem.

Peço por gentileza em nome de todos os profissionais, que como eu, gostam de ler bons textos. NÃO DETURPEM A LÍNGUA PORTUGUESA. Mesmo conhecendo “n” outros idiomas, moramos no Brasil, trabalhamos no Brasil, fazemos projetos no Brasil, isso por si só nos dá subsídio mais do que o suficiente para saber que, PRECISAMOSDEVEMOS saber falar e escrever BEM o nosso rico e belo Português Brasileiro.

E para discontrair um pouco e refletirmos um pouco mais sobre o poder que tem uma vírgula. Dêem uma olhada abaixo:

1. Vírgula pode ser uma pausa… ou não.
– Não, espere.
– Não espere.

2. Ela pode sumir com seu dinheiro.
– 23,4.
– 2,34.

3. Pode criar heróis..
– Isso só, ele resolve.
– Isso só ele resolve.

4. Ela pode ser a solução.
– Vamos perder, nada foi resolvido.
– Vamos perder nada, foi resolvido.

5. A vírgula muda uma opinião.
– Não queremos saber.
– Não, queremos saber.

6. A vírgula pode condenar ou salvar.
– Não tenha clemência!
– Não, tenha clemência!

E por fim, como prêmio aos que conseguiram chegar ao final desse texto… Onde você colocaria a vírgula no texto abaixo?

SE O HOMEM SOUBESSE O VALOR QUE TEM A MULHER ANDARIA DE QUATRO À SUA PROCURA.

Aguardo o resultado nos comentários.

Abraços e até a próxima!!!





Portal do Software Público e a qualidade de software

12 02 2010

Hoje estava dando uma re-lida em um fórum sobre teste de software que assino, e encontrei um post da Érika Hmeljevski, diretora reginal da ALATS em SC, falando sobre o Portal do Software Público. Até tuitei os links, mas resolvi colar o texto de apresentação do portal aqui no blog, até como um registro e acesso mais fácil do que as centenas de emails do fórum.

Chamo a atenção para o módulo específico sobre Teste de Software. É como se fosse um “guia dos primeiros passos” sobre a importância dos testes na qualidade do desenvolvimento de um software. Algumas páginas ainda estão em construção, mas tudo está aberto a colaboração da comunidade! Vamos começar a ajudar também???

Abaixo segue o texto descritivo sobre o Portal.

Todos os participantes do Portal do Software Público ganharam um ambiente dedicado ao tema de qualidade de Software. O espaço é composto inicialmente por 6 vetores: Ecossistema, Qualidade do Produto, Desenvolvimento de Software, Interoperabilidade, Prestadores de Serviço e Teste de Software. Os participantes do Portal SPB podem se cadastrar direto no ambiente com seu usuário e senha, pelo endereço http://www.softwarepublico.gov.br/5cqualibr/register/user-join

O ambiente foi apresentado durante a reunião de Coordenação do Portal do Software Público na cidade de Brasília no início de dezembro. O segundo grupo de Interesse do Portal SPB foi batizado de 5CQualiBr: conhecimento, comunidade, colaboração, compartilhamento e confiança para qualidade do software público brasileiro. O 5CQualiBr será coordenado pelo Centro de Tecnologia da Informação Renato Archer-CTI, com sede na cidade de Campinas. O principal objetivo do grupo de interesse será disponibilizar conteúdos para melhorar a qualidade do software brasileiro.

A intenção da coordenação do 5CQualiBr será de garantir a interação dos usuários em torno do tema, acrescentar novos conteúdos periodicamente e estimular o debate sobre qualidade de software no país. Os conteúdos serão disponibilizados em modelos de licenças livres e grande parte do material poderá ser acessado abertamente.

O Portal 5CQualiBr é um dos produtos do Modelo de Qualidade do Software Público Brasileiro, projeto em vigência desde o final de 2008, que conta com recursos da FINEP-Financiadora de Estudos e Projetos e com apoio da Secretaria de Política de Informática-SEPIN, do Ministério da Ciência e Tecnologia.

Trata-se do segundo grupo de interesse criado no ecossistema do software público. O primeiro foi dedicado aos municípios brasileiros: o 4CMBr. Que pode ser acessado pelo endereço http://www.softwarepublico.gov.br/4cmbr/register/user-join





Fundamentos do Teste de Software

28 09 2009

Há algum tempo venho pensando em escrever algo mais fundamentado aqui no blog. Hoje parei pra pensar, arrumei um tempo e resolvi falar sobre o capítulo 1 do Foundation Level Syllabus, material base pra certificação do ISTQB e BSTQB. É quase um resumão, às vezes com algumas considerações minhas imbutidas conforme minha experiência na área.

Este capítulo fala sobre os Fundamentos do Teste de Software.

Erro ao tentar finalizar uma transação importante!

Erro ao tentar finalizar uma transação importante!

Muitas pessoas devem se perguntar por que se faz necessário testes em software. Ora, devemos levar em consideração o contexto de cada software em desenvolvimento. Atualmente todos temos acesso a diferentes softwares diariamente. Em menor ou maior grau de dificuldade de uso, como por exemplo, aplicações bancárias, sejam elas acessadas pela web, celular ou caixa eletrônico. Você poderia imaginar o desastre se essas aplicações não fossem muito bem testadas? Você se sentiria seguro em realizar uma transação pela web? Bom, eu com certeza não. Outra aplicação que nos serve como exemplo, é o nosso querido Gmail. Bom, eu não vivo mais sem ele, e diferentemente do sistema bancário, eu não me preocupo muito em perder informações ali contidas (minha opinião tá, tem gente que tem muita coisa armazenada ali!!). Uma outra aplicação que considero importante de ser testada, são os sistemas de lojas e supermercados. Até hoje eu tenho o hábito de verificar os valores dos itens que estou comprando, porque não me sinto segura no sistema de barramento x valor do produto. Enfim, ema ema ema, cada um com seus problemas!! Esses exemplos servem pra mostrar que softwares que não funcionam corretamente podem trazer diversos prejuízos e grandes impactos para as pessoas e empresas que os utilizam.

Algumas causas dos problemas de software podem ser causadas por erros (enganos) humanos. O erro gera um defeito (bug) no software. E esse bug, gera uma falha no sistema. É atrás dessa falha que os testadores correm atrás (imaginei uma corrida de cachorros, onde eles correm em busca de um coelho, ou A recompensa).

Testadores atrás de um bug

Testadores atrás de um bug

Falhas podem ocorrer também, por eventos externos ao software, como quedas de luz, radiação, calor, poluição, campos magnéticos ou eletrônicos. Conheço um caso onde os servidores ficavam na mesma sala com 8 desenvolvedores, onde o ar condicionado no verão mal dava pra refrescar as pessoas. A temperatura da sala girava em torno dos 24 graus diariamente. Resultado disso: queda frequente do sistema, devido ao aquecimento das máquinas no ambiente.

Os testes têm funções específicas em cada fase do desenvolvimento e manutenção do software, e servem para reduzir os riscos de ocorrências de problemas no ambiente operacional, quando os defeitos encontrados são corrigidos em fase anterior a implantação na produção.

Qualidade em software implica em testes em todas as fases do desenvolvimento, desde o planejamento, através de testes na documentação, até a fase final do aceite do cliente. O teste ajuda a medir a qualidade em termos de defeitos encontrados por características e requisitos funcionais ou não funcionais do sistema. Os resultados da execução dos testes bem projetados pode representar a confiabilidade do software, quando poucos são os erros encontrados ou quando os mesmos são encontrados e corrigidos de forma efetiva.

Testes finalizados!

Testes finalizados!

E a pergunta que não quer calar é: quando devemos parar com os testes?

Bom, não se tem uma resposta padrão pra essa pergunta, porque tudo depende de cada projeto. Diversos são os fatores que podem definir quando parar-se de testar, como por exemplo: prazo, orçamento e riscos. É nesse sentido que os testes devem trazer informações suficientes para a tomada de decisão pelos stakeholders. Seus interesses são fundamentados nas limitações do projeto e, acredito eu, no grau de maturidade e qualidade do software desenvolvido. Para isso é que temos as versões beta, não é mesmo?





SCRUM ou CMMI? Temos mesmo que escolher?

8 09 2009

Recebi este link para uma ótima palestra sobre Scrum e CMMI, ministrada pelo professor Dr. Marcello Thirry, para os alunos da Unisul Virtual.

Vale a pena ver e rever várias vezes!

http://unisul.streambrasil.com/ONDEMAND-UV/unisul_sv_030909.html

Abraços

Fernanda