terça-feira, 29 de outubro de 2013

TDC 2013- resumo da trilha de testes


Bem meu povo! O findi foi muito legal e de bastante aprendizado, já startamos na sexta-feira na trilha de testes, com bastante coisa nova e uma galera bem parceira.
A abertura do evento foi super instigante com os robôs do Vinicius Senger: uma pipoqueira e o androidzito com o arduino e o raspberry pie. O teste de bafômetro que o robozinho faz é muito legal, tudo feito com comandos de voz pelo celular do Vinicius, onde ele criou tarefas que faziam chamadas http para o robô através de comandos.
Depois entrando nas trilhas especificas, a de teste começou com um pessoal que veio de Manaus -e eles não vieram de canoa(brinks). O Andrew e o Igor vieram do instituto Nokia com a Palestra #thebugsonthetable. Eles falaram como é trabalhar com qualidade dentro do instituto, e fizeram uma dobradinha legal entre dev e teste.
Quem quiser conferir pode pegar lá no slideshare.
A próxima palestra foi a minha, que já postei anteriormente, sobre design patterns para automação com selenium.
Almoçamos (ou não, que foi meu caso), e depois tive uma grata surpresa! Uma ferramenta ultra, hiper, mega legal, e melhor: open source!
O Juraci da TW está desenvolvendo uma ferramenta que gera pageObjects automaticamente: O Swamp! Não é um sonho? Quem quiser conferir o vídeo da  apresentação clica aqui, e a apresentação clica aqui!
Depois tivemos mais duas LTs que ainda não consegui a apresentação, mas uma delas foi sobre um framework para automação de testes para mobile com o Frank, quem apresentou foi um pessoal da uMov.me, e na sequência o Marcelo Tocheto apresentou a integração do Selenium Grid com o JBehave.
Passando para a trilha standium, tivemos uma apresentação de toda a suíte da Microsoft para testes, desde a gestão de requisitos, até o bug tracking, e a automatização.
Depois tivemos mais uma sequencia de três light talks:
Automação? Mobile? Yes we Can com o Ramsés que nos apresentou uma série de ferramentas para fazer automação com mobiles.
Melhor estressar a aplicação do que ficar estressado  de um pessoal lá de SP que falaram um pouco de Jmetter, (quem quiser se aprofundar melhor tem um post meu sobre isso), e mais uma série de ferramentas que podem (e devem) ser usada para saber o quanto seu sistema suporta.
Métricas de qualidade de código com mais um pessoal da uMov.me, que mostraram um pouco sobre nosso amigo Sonar, e como ele pode auxiliar na melhoria de qualidade dos códigos que desenvolvemos. 
Lembrando que código sujo é tipo sujeira que se varre para baixo do tapete, a hora que alguém precisar mexer naquele tapete já viu né? Então fica a dica da ferramenta para que possamos ter métricas de qualidade de código.
Depois fomos de novo para a Stadium, onde um pessoal da TW falou da experiência que eles tiveram em um projeto em que usaram a pirâmide de teste invertida.
 
No mais foi isso! Um dia cheio de coisas legais, muita coisa talvez já tenha vista, mas o fato é que sempre é bom rever conceitos e sempre se aprende algo! Para mim valeu super a pena.
Assim que for conseguindo as outras apresentações vou postando aqui também.




segunda-feira, 28 de outubro de 2013

Design Patterns para Selenium

Olá pessoal!
Depois de um findi maravilhoso com o #TDC2013, venho postar aqui no Blog a minha palestra.
Na sequencia também estarei fazendo um post com as demais palestras, para quem não pode estar presente conferir o que acontecer nas trilhas de teste e também na de Agile.

terça-feira, 3 de setembro de 2013

Dicas Selenium WebDriver

Outro dia fiquei algumas horas batendo a cabeça e pesquisando no Google como resolver um problema nos meus testes: pegar um texto que estava em um elemento hidden.
Eu já havia feito isso outras vezes, só que com elementos do tipo input e um simples getText() resolvia, mas esse elemento, que era uma span, não havia jeito de pegar. Ele encontrava o elemento, porém o getText retornava vazio.
Encontrei no stackoverflow a solução para esse caso: usar o getAtribute. Com esse comando você pode ter acesso a qualquer atributo do dom do seu elemento. Então o que ficava assim:

Driver.findElement(By.xpath(//*span)).gerText();

E não retornava nada, ficará assim:

Driver.findElement(By.xpath(//*span)).getAtribute('innerHtml');

Assim você conseguira capturar o texto do elemento, e caso venha algum carácter não desejado podes usar replace na string para manipular. 
Fácil não?

sexta-feira, 30 de agosto de 2013

Noite de agilidade no IPA


Ontem à noite participei de um evento bem legal no IPA. Foram três lightning talks bem interessantes, uma delas em especial me chamou a atenção: o "Evento Dojo" que o pessoal da Ilegra organiza. Não se trata de um coding dojo como estamos acostumados a ver, é uma adaptação que tem tudo para dar certo. O pessoal se reúne bimestralmente para ter lightning talks e depois codificar algo em uma linguagem nova, depois rola games e churrasco. Gostei da idéia!!!!
A noite ainda contou com dois Dojos: um de Java e outro de Selenium conduzido pelo @diracijunior e por mim!!! Abaixo fotinhos do momento. A solução do desafio está no github e tu podes pega-lá no link abaixo. O evento foi uma parceria do GUMA e do GUTS.
EDIT: Para que quiser conferir segue o link dos fontes no GitHub: https://github.com/guts-rs/DOJO_GUTSRS_IPA

terça-feira, 21 de maio de 2013

Quem Mexeu no Meu Queijo

Quem já não leu ou ouviu  falara sobre esse livro?
Quem mexeu no meu queijo é um livro, que de forma lúdica, mostra o quanto muitas vezes é dificil se adaptar.
E quem né amigo?
Quem que nunca?
Na área de testes uma mudança começou a ocorrer a bastante tempo, mas só agora vem ganhando força: "o Agile Testing". Enquanto fábricas investem milhões em processos de testes, as empresas que adotam as metodologias ágeis buscam vias mais simples para o sucesso.
É sobre isso que irei falar no TDC em Floripa.
Veja uma prévia da apresentação abaixo.

terça-feira, 30 de abril de 2013

Prove seu sistema com o JMetter

Há alguns  posts atrás, eu havia comentado que faria um post sobre Jmetter para que a gente possa estar sobrecarregando nosso sistema.
"Muahaha"!!!!
Já que vamos estressar nosso software fique atento as seguintes situaçoes:
1) o ambiente que vamos utilizar é o mais próximo possível do real?
2) caso negativo existe a possibilidade de simularmos esse ambiente? (Quando falo em ambiente não me refiro somente a base e versão do seu software, mas sim a infraestrutura,  middleware).
3) Existe a possibilidade de executar esses testes em produção? Se sim combine com o negócio e as áreas envolvidas e teste em janelas que tem impacto.
Feito isso vamos aos testes.
O primeiro passo é fazermos download do Jmetter:
A sua instalação é muito simples, basta apenas descompactar o arquivo e usar o jar.
Ao abrir o jmetter vemos a separação de dois grupos:
- Plano de Teste
- Área de Trabalho

Basicamente essa divisão serve para uma melhor organização. A área de trabalho é como se fosse uma área de rascunho, de testes. Já o plano de teste é aquilo que você realmente vai executar quando der um play.
Um exemplo simples, é quando precisamos configurar um proxy para captura, usamos a área de trabalho. Quando temos os artefatos necessários os colocamos em um Grupo de Usuários no Plano de Teste.
Se você já sabe o que vai precisar testar, quais urls vai utilizar (com suas variáveis, seus métodos, exe: GET, POST), podemos direto utilizar a opção de plano de teste.
Caso ao contrario, você pode capturar essas informaçõee, estarei mostrando como fazer isso em um próximo Post.
Passo a passo para quem está começando:
Na opção Plano de Teste clique com o botão direito e vá em -> Adicionar-> Thread(Users)-> Grupo de Usuários.
Você pode colocar o nome desse grupo de usuários conforme a sua necessidade.
Nessa tela nós temos uma série de opções, parte delas estão relacionadas a ações se houver falha e outra parte as configurações dos usuários virtuais. Vamos nos concentrar mais na configuração dos usuários.
  • Número de Usuários Virtuais: Com quantos usuários vamos simular o teste;
  • Tempo de inicialização em segundos: Tempo total de inicialização dos usuários. Se você colocar 200 usuário e 1 segundo o jmetter vai inicializar todos ao mesmo tempo;
  • Contador de Iteração: Quantas iterações (pense como laços de repetição) irão serem necessárias a cada usuário para que o teste finalize.
Indico que para começarmos a brincadeira, que deixemos um usuário virtual e as outras opções o default.
O próximo passo é adicionarmos um gerenciador HTTP, que será o responsável pelo gerenciamento de sua conexão.
Nele é possivel configurar o User Agent que iremos simular no teste.
Para isso vá em Grupo de Trabalho clique com o botão direito e então vá em  Adicionar->Elemento de Configuração-> Gerenciador de cabeçalho http:

O user agent vai variar de acordo com o que você quer simular.
Esse geralmente é o que eu uso:

User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Para testes com mobiles é só mudar o user Agent:
 
User-Agent Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_2 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8H7 Safari/6533.18.5
Feito isso vamos aos testes.
 Vamos adicionar nossos testadores, para isso clique com o botão direito sobre o Grupo de usuários e vá em Adicionar-> Testador> Requisição HTTP

Devem ser informados os seguintes dados:

  • Nome para a requisição (qualquer nome que identique bem a etapa do teste para você)
  • Nome do Servidor: aqui você coloca somente o dominio.
  • Caminho: O resto da URL.

Nesse ponto já podemos dar um play.
No momento que deres play, verás que o contador a direita irá ficar 1/1 e logo em seguida 0/1.
E se seu site estiver ok, nenhum alerta seá contado:

Vamos adicionar alguns ouvintes para vermos o que está sendo executado. Há várias opções de ouvintes, eu gosto de usar duas: View Results Three e Simple Data Writer
Para adicioná-los vamos clicar com o botão direito sobre o Grupo de usuários e ir em Adicionar->Ouvintes->View Results Three
Se dermos play novamente, podemos ver o retorno do teste:

Podemos escolher o que queremos que seja exibido, se somente erro, sucesso ou ambos. Também é possivel exibir não somente o texto de resposta mas fazer download dos resources e exibir o html

Podemos também gerar um relatório desses testes, com um Simple Data Writer.
Adicionar->Ouvintes->View Results Three


Nesse tipo de escritor, todos os resultados dos seus testes ficarão armazenados em um arquivo. Uma dica legal é usar parametros para sempre  gerar um novo arquivo. Para isso adicione parametros como data e hora no nome do arquivo: D:\JMETTER\TesteGuriatech_${__time(YMDHMS)}.xls

O basicão é isso.
O proximo passo é começarmos a brincar com os temporizadores e alguns parametros nos testadores. Isso fará com que o nosso teste fique mais real, visto que nossos usuários não irão entrar todos ao mesmo tempo e executar todos os links no mesmo momento.
Sem o temporizador é isso que o jmetter tenta fazer, colocar todos a rodar.

Enquanto isso podemos ir adicionando mais requisições HTTP, e aumentando o número de usuários virtuais.
Divirtam-se!
No próximo post sobre Jmetter vou falar um pouco desses temporizadores e dos parametros para as requisições http.

Ficou com dúvida?
Escreva nos comentários abaixo que respoderei!





sexta-feira, 26 de abril de 2013

Compra da China

Fiz a minha primeira compra de roupas da china!
Estava acostumada a encomendar algumas coisinhas (principalmente capinhas para o Iphone) do DealeXtreme, mas roupas e coisinhas fofas, ainda não tinha tido coragem. O meu escolhido da vez foi o SammyDress.
Fiz uma boa pesquisa antes, dando uma lida em reviews, inclusive de brasileiras, e a conclusão a que eu cheguei é: Não espere muito de um produto que você está pagando um valor baixissimo.
Não espere Qualidade!
E por falar em qualidade, me surpreendi com site de deles, funciona muito bem em desktops, igualmente com mobiles, e eles ainda tem um app bem bacana para iphone.

Como SQA posso avaliar o site deles como muito bom.
Bem intuitivo, e está certo que não fiquei fuçando muito, fiz operações básicas e não encontrei bugs pelo caminho, a não ser por alguns erros no app para Iphone, onde em várias categorias foi apresentado o erro "Erro1: Data transmission error, please try again", embora eu "try again" (hahahaha) várias vezes não funcionou, e as categorias estivam funcionais no site. Como porém era m categorias que eu imagino que sejam pouco usadas, ou eles não devem ter percebido, ou deve estar no backlog deles.
Agora como mulher consumista, amei de paixão o site! Se podesse comprava de tudo um pouco! Vou esperar essa primeira compra chegar para decidir a próxima compra. Gastei 36 reias já com o frete e comprei várias coisinhas. Quando elas chegarem digo  se aprovo ou não.
O que eu comprei:


http://www.sammydress.com/product246829.html

Tá eu sei é um ralador! Mas me deu vontade de comprar tá!
http://www.sammydress.com/product71136.html

http://www.sammydress.com/product306343.html

http://www.sammydress.com/product292235.html

http://www.sammydress.com/product284777.html





quinta-feira, 11 de abril de 2013

CTFL

No mês de março fiz a prova de certificação do ISTQB para CTFL. Recebi o resultado positivo a poucos dias.
Gostaria de então dar uma mãozinha a quem pretende encarar o próximo exame com algumas dicas.
A primeira dica é: leia o silabus e o glossário, mas não concentre seus maiores esforços neles.
A segunda dica é: faca os simulados que estão na página do ISTQB. Muitas das questões que aparecem não terão suas respostas no silabus, e aconselho que caso você não saiba a resposta procure saber porque ela é a correta ( e nisso o Google te ajuda muito).
Terceira dica: procure os simulados na internet, fiz muito uso deles enquanto estudei e só parava de fazê-los quando acertava todas as questões. Abaixo vou deixar os links dos blogs que usei para estudar.
Ultra super mega dica: gaste a maior parte do seu tempo com esses simulados! Eles contém muitas perguntas que vão te ajudar a guiar o seu estudo.
Exemplo a não seguir: comecei a estudar cerca de uma semana antes da prova, pois como já trabalho há algum tempo na área pensei que ia ser tranquilo. Engano meu. Quando comecei a fazer os simulados, e os fiz após estudar o silabus, comecei a me desesperar, pois pouquíssimas questões eu consegui responder com o auxílio do que eu já havia lido. Embora o pouco tempo de estudo deu para passar com folga, mas isso vai da facilidade que cada um tem de assimilar o que esta estudando. Por isso não deixe para a última hora! Comece a estudar o quanto antes.
Links:
http://bugbox.com.br/aprender/138
Esse link contem os atalhos de outros simulados.
Muito obrigado ao pessoal do BugBox que os compartilhou! Foram muito úteis!
http://www.bstqb.org.br/
É preciso estar logado para obter acesso.
Bye!

quarta-feira, 10 de abril de 2013

Provando a estabilidade do seu software

Recentemente, passamos por um problemão aqui com as nossas aplicações. Houve uma mudança na arquitetura e falhamente não efetuamos testes de stress antes de subir a versão. É obvio que assim que o site começou a ter muitos acessos ele começou a cair. Resultado: tivemos que fazer rollback de tudo, e como foi uma mudança de arquitetura isso implicou em substituição de servidores, que embora sejam virtualizados, ainda não é rapida assim a sua substuição, deixando o site por algumas horas fora.
Isso gerou um grande stress para o negócio e sabemos claramente que houveram falhas tanto na área de dev como na área de infra. O importante é o que aprendemos com erros e o que fazemos para que eles não se repitam. Nesse caso fizemos um acerto com a infra, e ao invés de fazer várias mudanças na arquitetura fizemos apenas uma das alterações e aplicamos a versão para minimizar os locais de erro.
Após estudamos uma estratégia de testes de stress e junto com a equipe de Web Analitcs verificamos qual seria a quantidade de acessos simultâneos para testar a estabilidade. Como responsável pelos testes preparei scripts no Jmetter para testar isso, e após scripts e usuários configurados no Jmetter colocamos a rodar. Resultado: derrubamos os sites(em homologação é claro). Após vários ajustes de arquitetura, conseguimos estabilizar o ambiente e só com uma grande quantidade de acessos é que derrubamos o site, quantidade essa que não se replica em número de acessos em produção. Se você está pensando em verificar a estabilidade do seu software vamos as seguintes dicas:
1) Conheça bem a arquitetura do seu sistema, isso vai ajudar muito a você determinar o quanto seu teste é válido. Por exemplo aqui nós temos balanceamento e um stick, ou seja sempre que eu realizava testes com o Jmetter na minha máquina estava sobrecarregando somente um dos servers, pois quando eu caia no balancer ele reconhecia meu IP e me mandava sempre para o mesmo server. Para resolver isso forçamos junto com a infra que a minha máquina caisse em um servidor e a máquina de outro colega caisse em outro server, e dividimos as conexões.
2) Se você não é o gerenciador do ambiente, mantenha contato com eles para juntos avaliarem a melhor forma de stressar seu ambiente.
3) Escolha a ferramenta certa para testar seu software.
4) Estude a ferramente e como você irá conseguir tirar melhor proveito dela para seu teste.
5) Não esqueça de incluir este tempo na sua preparação do teste e que para que esse teste tenha sucesso, você deve garantir que os outros atributos de qualidade sejam garantidos:
 * Seu software precisa estar funcional!
* Seu software precisa ser confiavel!
 * Seu software precisa ser usável!
 * Seu software precisa ser eficaz!
* Seu software precisa ser manutenivel!
* Seu software precisa ser portável!
6) Use os principios da agilidade e sempre entregue valor ao seu cliente!
Quer saber mais sobre Jmetter? Acompanhe meu próximo post.

segunda-feira, 25 de fevereiro de 2013

Agile Testing

Olá povo!
Conforme havia prometido, estou compatilhando a apresentação que eu fiz sobre o livro Agile Testing.
É um resumão dos principais itens que me chamaram atenção.
O que eu achei do livro? É um livro bem interessante, ainda mais se você está começando a trabalhar com metodologias ageis, ou se está pensando em abandonar o método tradional.
Destaques: Achei bem interssante a abordagem de como podemos auxiliar o nosso time a ter qualidade. Muitas vezes o QA está tão focado em fazer seus testes e garantir que haja uma barreira de segurança através dele que esquece que no método ágil todos somos resposáveis pela qualidade. Se os demais integrantes do seu time não estão comprometidos, é seu papel como QA de tentar auxiliá-los a encontrar um caminho. Afinal todos ganham com isso.
O livro também fala de diversas ferramentas de automatização como: selenium, junit, FitNesse, etc., embora esse não seja o seu foco, deixa claro que sem automatização nenhum time ágil resiste(sorry!).
 Recomendo a leitura!

quinta-feira, 7 de fevereiro de 2013

Continuação Dojo

Em continuação ao último post, hoje pretendo explicar o código de teste funcional que criei e se adequava ao desafio.
Em primeiro lugar se você pensa em escrever um código de teste legal aprenda o conceito de page objects. Isso ajudará você a economizar muitas linhas de código e facilitará a manutenção dos mesmos.

Iniciei a codificação mapeando os elementos da minha página em um objeto e criando métodos para que a minha classe de teste pudesse acessa-los. Os primeiros objetos mapeados, foram todos os campos do formulário como combos, inputs, buttons, etc. Feito isso já tinha o básico para iniciar a classe de testes.

public class PaginaFormularioCadastro {
    private WebDriver driver;

    public PaginaFormularioCadastro(WebDriver driver) {
        super();
        this.driver = driver;
    }
   
    public void selecionaPessoaFisica(){
        driver.findElement(By.id("legalEntity.F")).click();
       
    }
    public void selecionaPessoaJuridica(){
        driver.findElement(By.id("legalEntity.J")).click();
    }
    public void escreveNome(String nome){
        driver.findElement(By.id("firstName")).sendKeys(nome);
    }
    public void escreveUsuario(String usuario){
        driver.findElement(By.id("userName")).sendKeys(usuario);
    }
    public void escreveSenha(String senha){
        driver.findElement(By.id("password")).sendKeys(senha);
    }
    public void reEscreveSenha(String senha){
        driver.findElement(By.id("password2")).sendKeys(senha);
    }
    public void escreveEmail(String email){
        driver.findElement(By.id("email")).sendKeys(email);
    }
    public void queroInfoGrupo(){
        driver.findElement(By.id("complement.rbsEmail")).click();
    }
    public void queroInfoParceirosGrupo(){
        driver.findElement(By.id("complement.otherEmail")).click();
    }
    public void aceitaTermo(){
        driver.findElement(By.id("acceptTerms")).click();
    }
    public void cadastrar(){
        driver.findElement(By.cssSelector("input[type=\"submit\"]")).click();
    }
}

Antes disso preparei uma classe que conteria as assinaturas @before e @after, que poderão serem usadas por outras classes de teste. Iniciei a classe de teste estendendo a classe que cotei acima.

 public class Teste {
    protected WebDriver driver;
    protected String baseUrl;
    private StringBuffer verificationErrors = new StringBuffer();
    @Before
    public void setUp() throws Exception {
        driver = new FirefoxDriver();
        baseUrl = "http://zerohora.clicrbs.com.br/wrs/action/update/newUser;jsessionid=ac19071f30d825732ff18c3a4149b3cfc47cf2a125ef.e34RbNaLchqQay0NbhmTc40.22?site=4446";
        driver.manage().timeouts().implicitlyWait(15, TimeUnit.SECONDS);
        driver.get(baseUrl);
    }
    @After
    public void tearDown() throws Exception {
        driver.quit();
        String verificationErrorString = verificationErrors.toString();
        if (!"".equals(verificationErrorString)) {
            fail(verificationErrorString);
        }
    }
}
Comecei a chamar os métodos criados no objeto para fazer as simulações. Assim que essa etapa estava concluída e funcionando, precisava das assertivas para garantir que o teste passou, então implementei no objeto, métodos que faziam essas verificações.
Acabei os cenários de teste na minha classe e parti para verificar o funcionamentos. De cara eu sabia que teria problemas para atender aos critérios de aceite do teste devido a estar usando sempre o mesmo nome de usuário para cadastrar, mesmo assim executei o teste apenas modificando esse parâmetro e vi que o teste estava funcionando. Para resolver esse problema criei um objeto chamado usuário com o atributo username.

 public class Usuario {
    protected String username;
  
  
    public Usuario(String username) {
        super();
        this.username = username.replaceAll("[ :]", "");
    }
    protected String getUsername() {
        return username;
    }
    protected void setUsername(String username) {
        this.username = username.replaceAll("[ :]", "");
    }

}


 O construtor desse atributo pegava a hora e data do sistema, retirava espaços em branco e barras e convertia para string. Cada vez que eu executava o teste ele pegava um timestamp diferente. Resolvido isso meu teste ficou pronto para ser executado várias vezes sem precisar de ajuste a cada execução.
Done? Done!

sexta-feira, 25 de janeiro de 2013

Dojo de testes funcionais com Selenium

Olá pessoal! Essa semana foi bem movimentada e tenho bastante coisas para compartilhar com vocês, mas vou compartilhar aos poucos se não fico sem fôlego!
Bem a primeira experiência legal e que é o motivo desse post, trata-se de um primeiro dojo de testes funcionais usando Selenium que fizemos aqui na RBS.
No dojo reunimos testadores e desenvolvedores para que podessemos fazer uma troca legal.
O desafio era automatizar três cenários bem simples em uma ferramenta que é de uso de todo o time.
Infelizmente não foi possível acabar o desafio pois acabou o nosso tempo e a sala já estava reservada. O pessoal quase conseguiu finalizar o primeiro cenário, e foi uma experiência de bastante aprendizado a todos.
Basicamente os cenários eram:
Cadastrar usuário com sucesso
Cadastrar usuário com falha de duplicidade
Cadastrar usuário com falha de itens obrigatórios
As premissas eram: escrever o código de forma que ele ficasse reutilizável e sempre pensar que o teste não era feito para ser executado uma vez só mais sim infinitas vezes.
Os códigos estão no meu github: https://github.com/cintiaarmesto/dojo-RBS-testes .



terça-feira, 15 de janeiro de 2013

Testes Automatizados com Selenium - 1ª Etapa

Olá!
Essa semana tive um tempinho enquanto as coisas ainda estão meio paradas devido as férias e montei uma pequena apresentação de Selenium para iniciantes.
É um guia mega básico só para quem está iniciando mesmo.
O exemplo que usei é de uma busca simples no site Pense Imóveis (www.penseimoveis.com.br).

Quem tiver alguma dúvida posta ai!

Abçs

quinta-feira, 10 de janeiro de 2013

Mais importante que Perfil é Atitude!

Durante as minhas férias estive lendo o livro "Agile Testing" da Lisa Crispin e Janet Gregory, pretendo postar no blog um resumão das pricipais ideiais que tirei e uma apresentação que estou fazendo para um hot spot aqui na "firma". Até o momento uma das melhores frases que tirei do livro é o titulo do post de hoje : Mais importante que perfil é a atitude!
O livro fala mais especificamente para a área de testes mais a frase é usual para muitas outras situações. Atitude é tudo, não adiante tu ser super, ultra, mega inteligente e não ter aquele "tchan". Esse "tchan" é a nossa querida ATITUDE. Ter atitude implica muitas vezes em sair da zona de conforto,  mas não quer dizer que você vai sair por ai entrando em confronto com as pessoas.
Em um time, é necessário pensar como o todo e para o todo e colocar isso em ação. Não adianta pensar individualmente e agir de acordo com somente o que você acha melhor. É preciso analisar o que o rodeia e ai sim ter atitude.
Há uma música que a muito tempo me guia em qualquer projeto novo, meta nova é ela que me impulsiona. Aprendi essa música em um momento muito especial da minha vida, momento esse que ajudou a formar muito do que eu sou hoje.
Durante seis anos particpei de um movimento da Igreja Católica chamado CLJ, que muito além de me ensinar espiritualidade, me ensinou a viver em grupo, a desenvolver a minha liderança, a agir. É disso que fala esse música,  já usei ela em uma palestra, junto com minha amigas de comunidade, para jovens lideres de uma escola. Quer quiser ouvir, achei o link no youtube logo abaixo.
 
Concluindo, então não adianta de nada eu ter um perfil super bom para testes, mas não saber trabalhar em equipe, não me posicionar junto com os meus colegas, não estar disposto ajudar. De que adianta ter perfil? O perfil por si só é vazio. Perfil é importante? É claro que é, mas o perfil por si só não basta.O perfil não faz o diferencial.
Atitude, ação, liderança fazem a diferença. Coloque o que você faz de melhor a propósito do seu time e você fará a diferença.


terça-feira, 8 de janeiro de 2013

Pangéia Digital

Você lembra do conceito de "Pangéia" visto  nos conteúdos de Geografia? Se não lembra dá uma rápida olhadinha pois logo saberá o que ela tem a ver com o post de hoje.
Trocar idéias, conceitos, conhecimentos na área da computação é essencial. Obviamente em outras áreas também, mas o que acontece na nossa area é que as coisas acontecem rápidas demais, e mudam com muita facilidade. Parecido com o que acontece com a moda, aquilo que ontem era tendência hoje não é mais e aquilo que era mega estranho, como as roupas que as modelos usam nos desfiles, passa a ser o usual.
É preciso estar antenado ao que está a acontecendo e em constante contato com pessoas do meio para não ficar descompassados ao que se passa ao redor. Hoje é muito mais fácil encontrar pessoas que estão dispostas a colaborar e isso vem sendo facilitado com o networking criado inclusive pelas redes sociais.
Recente havíamos feito um ciclo de conversas sobre testes aqui na RBS  onde falamos como se estava trabalhando a qualidade nos nossos times, dessa movimentação surgiu a oportunidade de ir até a DBServer e trocarmos idéias com eles. Vimos como eles desenvolvem a qualidade no Test Center deles e tiramos várias idéias interessantes que podem ser aplicadas nas mais diversas áreas.
Ganhamos muito com isso! Conhecemos pessoas podemos compartilhar problemas e encontrar juntos   a solução para eles. Não há porque ter medo de compartilhar idéias, ferramentas, métodos que estão dando certo. Só tem medo de partilhar quem tem medo de perder prestígio. 
E nesse mundo colobarativo que vivemos, como estamos preparando a próxima geração para trabalhar nele? Em um dos muitos HotSpots que temos aqui, um engenheiro do Google, que não me recordo o nome, falou exatamente disso. Fomos educados pelas instuições de ensino a sermos individualistas, a não compartilhar soluções, a não fazer cópias. Ao chegar no ambiente de trabalho temos que passar por esse paradigma e temos que partilhar ideias, copiar códigos e melhorá-los, conviver e encontrar soluções juntos para problemas.
Deixamos de ser ilhas, passamos a compor arquipelagos, que logo se tornarão continentes. É o fenômeno inverso do que aconteceu a Pangéia, e quanto mais você se agitar, mais sua placa tecnotônica vai se mover, e o movimento deve ser de atração, para que você se junte a pessoas e troque ideias!
E ai você vai movimentar suas placas ou vai esperar que o movimento das outras torne você cada vez mais ilha e menos continente?