Automação de testes: Aproximando contextos

A área de Teste evoluiu muito desde quando eu iniciei nela, em 2007. Hoje mesmo não atuando nela, eu vejo o quanto é diferente a forma de se testar, de quando eu comecei na área.

Naquela época automação de testes era um assunto ainda muito pouco difundido e as ferramentas usadas pagas, de grandes suítes de teste como a Rational.

Hoje em 2013 o cenário muito bastante, práticas ágeis estão mais difundidas, a comunidade brasileira está mais madura e ferramentas open sources dão todo o “ferramentário” necessário para a automação.

Para chegarmos no estado de hoje, várias mudanças e revoluções ocorreram. E como toda revolução, ela promete algo muito melhor ao status quo e para se prevalecer, muitas vezes ela se apoia em dizer que tudo está errado.

A automação de testes surgiu como um “lobo mau” para muitos Testers e outros se agarram a ela, como se ela fosse o único caminho de se testar. Com o tempo perceberam que ela nada mais é do que uma evolução. Ela não veio pra expurgar testes manuais, ela veio pra trazer maior eficiência aos testes e evitar o “caos” das manutenções de software.

Um dos efeitos colaterais da automação de teste, foi a aproximação da área de Teste com a área de Desenvolvimento. Ela ocorreu fisicamente com os Testadores sentando mais próximos dos Desenvolvedores, pra facilitar a comunicação quando é preciso tirar dúvidas sobre programação.

Mas ela ocorreu mais ainda na formação do Tester, no próprio DNA do Tester, uma vez que programar não é mais uma arte usada apenas para construir, ela também é usada para “quebrar ” (testes de carga usando JMeter), pra verificar (testes de aceitação usando Jasmine) e pra dá segurança para mudar (testes unitários com RSpec).

Com isso dois contextos que de forma errada muitas vezes eram separados, hoje estão mais próximos. Afinal, Desenvolvimento e testes sempre existiram pelo mesmo propósito, entregar software de qualidade.

Com a dinâmica atual do mercado de TI, não há mais espaço pra guerrinhas setorias, nem para Desenvolvedores que só cospem código, e nem pra Testadores que só navegam por telinhas. Não é mais questão de ser generalista, é questão que saber analisar um problema é tão básico para um Desenvolvedor, como programar é para o Testador.

Especializações interessantes para os profissionais da área de teste de software

32ª Mesa Redonda foi sobre “Especializações interessantes para os profissionais da área de teste de software” e teve apenas 2 respostas e 3 participantes, sendo eles: eu, Elias Nogueira e Lidiane Santos.

Como a discussão foi curta, abaixo segue praticamente a íntegra das contribuições feitas pelo Elias e pela Lidiane e também alguns comentários meus.

O Elias abordou vários pontos relevantes, entre eles o insight de que uma especialização na área de Teste de Software, não precisa ser necessariamente na área. Pode parecer estranho, mas é verdade:

Acredito que a especialização em si na Área de Teste não é apenas sobre a área (ex: uma pós em Gestão de Qualidade ou Teste de Software), e sim mais sobre o negócio onde trabalhamos (SOA, Sistemas Distribuidos, Mobile, etc…)

Claro que esse meu pensamento é um pouco puxado para o lado técnico. 😛

Sempre acreditei que o profissional em teste é um dos mais completos, por causa da variedade de conhecimentos que ele precisa ter para desempenhar sua função (óbvio que dependendo do papel/nível do mesmo). Logo, penso que a carreira de um profissional de teste é cheia de conhecimento “fora-teste” (análise de requisitos, programação, etc..)

Hoje, dentro da área acadêmica (Especialização, Pós, MBA) eu vejo quase que 100% formações de líderes, analistas de qualidade ou correlatos. É muito difícil encontrar algum curso acadêmico mais técnico em teste, ou que pelo menos ensine técnicas de teste, algumas ferramentas, etc…

Vejo que o profissional, se deseja algo mais técnico, tem que recorrer a uma destas áreas acadêmicas fora de teste ou recorrer a um mestrado para desenvolver algo diferente. É um ponto que as universidades estão amadurecendo, mas muito lentamente (se pensarmos o número de matérias de programação x número de matérias sobre qualidade e teste de software)

Eu fiz uma Pós em Teste de Software (onde vi toda a área de validação) na Unieuro, e recomendo. Apesar de eu já ter o conhecimento do que eu tive na pós, eu a procurei alguns motivos: ter outras visões do mesmo assunto e ter uma certa comprovação acadêmica. Hoje já recorro a cursos dentro da minha área de especialização que mais me interessam.

A minha dica é que na hora da escolha de uma especialização na área, em termos acadêmicos, que o profissional saiba qual linha ele quer/vai seguir, pois para a linha técnica não existe muita coisa.

Aproveito pra listar aqui algumas instituções acadêmicas ao redor do Brasil que possuem cursos voltados para a área de Teste e Qualidade de Software (sugestão de ficar como um thread separada depois)

– Unieuro (Brasília/DF) – MBA em Teste de Software (Pós Graduação) [não existe mais]

– Feevale (Novo Hamburgo/RS) – Teste e Garantia da Qualidade de Software (Pós Graduação)

– Unisinos (São Leopoldo/RS) – Qualidade de Processos de Software (Tecnológico)

– FIAP (São Paulo/SP) – MBA em Gestão da Qualidade em Software com ênfase em CMMi e MPS.BR (Pós Graduação) [não existe mais]

– SENAC (São Paulo/SP) – Gestão da Qualidade de Software (Pós Graduação)

 

 

 

UNICAMP – Especialização em Engenharia de Software

A Lidiane contou um pouco da sua experiência e lembrou que participar de eventos é uma forma de buscar se especializar e também de compreender melhor a área e a sua amplitude:

Realmente esse tema é muito importante e legal. Vejo muitas pessoas que estão na área de teste que não sabem que os profissionais dessa área podem ter uma carreira.

Em relação a especializações, existem muitos cursos legais de ferramentas, automação de testes, implementador MPT.BR, TMM. Vejo que há bastante cursos online e/ou semi-presencias, mas não são muito divulgados

Pós-Graduação, eu vejo que é muito interessante na area de Engenharia de Software, Qualidade de Software, é muito importante analisar a grade, pois tem algumas pós que não abordam muito o tema Teste SW.

Na Poli tem alguns cursos bem legais de especialização e extensão vejam no site www.pecepoli.com.br , temos a Iterasys com os cursos preparatórios para certificações, mesmo que vc não faça a prova, o curso acaba sendo muito legal e você consegue praticar algumas coisas no dia-a-dia.

Eu atualmente tento frequentar os eventos de teste como o Brateste, Conferencias – inclusive fui no TDC 2010 realizado em Agosto, WorkShops, estou sempre antenada nas novidades e visitando blogs relacioandos a Qualidade e Teste SW.

Por fim, termino agora em novembro o MBA em Teste de Software pela Unieuro, o curso é bom tirando algumas falhas da instuição em relação ao atendimento ADM e Financeiro… *rs

Eu achei super válidas as contribuições do Elias e da Lidiane, e retratam bem as formas que podemos nos especializar na área de Teste de Software.

Na minha opinião, a especialização hoje é encarada pelos profissionais, basicamente de duas formas:

  • O profissional gosta da área e quer se aprofundar melhor nela, ou está buscando cobrir lacunas da graduação e conhecer outras áreas (ex.: ao fazer uma pós em Engenharia de Software);
  • A outra forma, são os profissionais que estão buscando status e aumento. Afinal, é bunitinho falar que é pós-graduado e para algumas empresas, o título mostra que o profissional é mais qualificado que outro que não possui uma pós. Essa abordagem é perigosa, porque você pode acabar fazendo um curso que não gosta ou que o seu perfil não encaixea Além do que, essa visão de que ser pós-graduado é igual ser melhor do que os que não são, é uma visão alienada.

Eu particularmente, prefiro uma pós-graduação fora da área de Teste de Software, para quem está na área de Teste de Software. Caso o seu perfil seja mais gerencial, busque uma pós de gestão ou um MBA, agora caso o seu perfil seja mais técnico, busque então uma pós em Engenharia de Software.

Escolha bem o curso e não vá na “hype”, afinal uma pós-graduação, geralmente exige um investimento financeiro grande. Faça a sua escolha com bastante parcimônia. 😉

E lembrem-se: nem sempre se especializar, significa se matrícular num curso de pós-graduação, hoje em dia há outras opções.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Bug no Gmail

Estava desenvolvendo a funcionalidade de aplicação de tags para as menções no Vizir, e durante o desenvolvimento tomei como base do comportamento dessa funcionalidade,  a aplicação de labels do Gmail.

Durante o estudo do funcionamento da criação dos labels no Gmail, acabei encontrando um bug interessante, que mostra bem como nem sempre podemos cobrir todas as situações de erro, uma vez que elas são muitas.

Para quem não conhece essa funcionalidade do Gmail ou não usa o Gmail, segue uma breve explicação sobre ela:

Você quer aplicar um label (marcação) para um e-mail, por exemplo: todos os e-mails de promoções com o label “promoções”. O que essa funcionalidade faz, é exatamente prover uma maneira de aplicar labels aos seus e-mails.

Vamos direto em como reproduzir o bug:

  1. Clique no checkbox ao lado do e-mail que você quer aplicar o label;
  2. Clique no combo-box Labels;
  3. Clique na opção Create new (um pop-up irá aparecer);
  4. Digite o nome do seu label e clique no botão OK (“OK” para um botão de criação é estranho hein, poderíamos sugerir uma melhoria).

Pronto, viu o bug? Não?

Sem um screenshot fica difícil, neh. Segue abaixo uma imagem com cada passo feito, clique nela para visualizar numa resolução maior .

E agora viu o “danado”?

Se você nunca usou essa funcionalidade dessa maneira (tem como usar ela criando filtros pré-definidos), está descontado. Mas se você já usou deve/deveria ter reparado que faltou algo.

Quando você aplica um label na mensagem duas coisas acontecem:

  • Uma mensagem aparece em cima da box dos e-mails, avisando que a “conversação” foi adicionada no label (The conversation has been added to “qualidadebr”.)
  • O e-mail/conversação é marcado com o label.

O que faltou foi a segunda forma de notificação, o label não foi adicionado no e-mail (visualmente, se você atualizar a página irá visualizar o e-mail com o novo label). O interessante que esse bug só ocorre quando você aplica um novo label ao e-mail, se você for aplicar um label já existente, o bug não irá ocorrer.

Abaixo, o resultado esperado:

Pelas entranhas do bug

Com a explicação acima um bom desenvolvedor já iria descobrir o porquê do bug existir.

O que ocorre por de trás das câmeras quando você aplica um label ao e-mail, é que uma atualização via AJAX é feita em duas partes da página: no div da mensagem e no div dos labels.

O problema não é que a atualização não é feita no div dos labels, e sim que o elemento não é adicionado, provavelmente porque o novo label não foi adicionado na varíavel que contém os labels.

E como saber tudo isso?

Te contar que nem precisa entender muito de Javascript e HTML. Utilizando o formidável Firebug você já consegue observar esse comportamento. Difícil é entender o HTML gerado pelo javascript do Gmail (se estiver curioso em entender um pouco como o Gmail funciona esse artigo pode ser útil).

Como solucionar esse bug?

Eu passei pelo mesmo problema na implementação da funcionalidade de aplicação de tags nas menções no Vizir. A solução que encontrei foi dá um refresh na página, quando uma nova tag é inserida. Desta forma, o objeto que armazena os labels já é atualizado com o novo label.

Não deve ser a solução mais linda e elegante, talvez seja possível atualizar a lista de labels do combo-box, via Javascript. Mas como eu não sei fazer isso (preciso dá uma pesquisada se é possível e como fazer [canelada pra mim]),  e essa solução se comportou bem e foi eficiente para o problema que enfrentei. 🙂

Como esse bug escapou dos jardins do Google?

Sou usuário do Gmail desde 2007, e desde lá, só uso ele como cliente de e-mail, tanto para uso pessoal como profissional. E só no começo desse mês que encontrei esse bug.

Ou seja, acredito que este bug não se apresenta com tanta frequência, pois nem todos usuários utilizam esse recurso (diria até, que uma minoria utiliza). Além disso, o uso mais frequente dos labels, pelo menos o uso que mais faço e vejo as pessoas fazerem, é na criação dos filtros.

E a equipe de Teste de Software do Gmail, por que será que eles não encontraram esse bug?

Tenho duas especulações quanto a isso:

  • Encontraram o bug, porém como a sua ocorrência não é tão frequente e sua presença não atrapalha muito o usuário, o bug ainda não foi corrigido (tá na fila no bugtracking deles, com prioridade baixa);
  • Não encontraram, pois não tinham um caso de teste que cobria esse cenário.

A grande lição que podemos tirar com esse bug, é que um sistema pode muito bem ir para produção, ser super bem elogiado pelos usuários e mesmo assim conter dezenas de bugs (eu conheço uns 3 ou 4 só do Gmail rs). Se você for querer ser perfeccionista ao extremo, você nunca irá colocar um sistema em produção. Um sistema sem bugs não é algo comum, e esse fato é até justificável, é só olhar para as pessoas que desenvolvem e usam os sistemas, elas são perfeitas?

Fique por dentro das novidades, assine o feed do QualidadeBR.

Meus pensamentos sobre pós-graduação

A escrita deste post tem duas motivações:

  1. Li semana passada o sample do livro The Personal MBA: Master the Art of Business do Josh Kaufman;
  2. A notícia de que a Unieuro foi reprovada na avaliação do MEC.

Já adianto, que não tenho nada contra o curso de pós-graduação da Unieuro em Teste de Software. E pelo feedback que tive de alguns amigos, me parece ser um curso, onde é possível extrair conhecimentos e experiências para o seu crescimento profissional.

Colocada as motivações do post e um breve aviso, é hora de explicar o porquê deste post:

O objetivo é simples, compartilhar a minha visão e posição atual sobre a possibilidade de fazer uma pós-graduação e também minha visão geral sobre uma pós. Lembrando que essa é uma visão bem particular e que acredito ser adequada para o meu perfil e para os meus objetivos a curto e médio prazo, portanto ela pode ser bem diferente da sua visão.

Contextualizando

Estive sentado numa carteira desde os meus 3 anos de idade até os meus 20 anos (hoje tenho 22). Portanto foram 17 anos navegando pela direção convencional dos estudos e aperfeiçoamento pessoal e profissional. E após tanto tempo, tantas escolas, colegas, professores, amigos e notas, me sinto muito à vontade em falar sobre educação, afinal passei das 10.000 mil horas e portanto, me considero um expert, como aluno.

Porém o título de expert como aluno, não é algo que se deva ficar se orgulhando tanto, para mim ele é muito mais próximo do “título” expert em saber andar, do que de um título de expert na arte de ensinar, por exemplo.

Após 2 anos sem frequentar regularmente uma carteira (terminei a faculdade em dezembro de 2008), deveria estar me pressionando para fazer uma pós-graduação. Até já pensei sobre o assunto, principalmente no primeiro semestre de 2009 e estava até planejando começar algo no início de 2010. No entanto, já estamos em 2011 e nem sequer me inscrevi em alguma pós-graduação.

Os motivos para a minha escolha

Essa escolha não foi feita de um dia para o outro, ou após um longo período de reflexão, ela foi feita dia-a-dia.

Ano passado, foi quando tive certeza que não é o momento de fazer uma pós-graduação. Os principais motivos para essa decisão foram:

  • Tempo: fazer uma pós-graduação consume muito tempo, e tenho que confessar que mesmo após ter terminada a faculdade não senti, um grande alívio na minha agenda, parece que naturalmente o tempo que era investido na faculdade, foi sendo consumido por outras coisas;
  • Dinheiro: uma das minhas opções de pós é o MBA na FGV e minha condição financeira iria ficar seriamente comprometida;
  • Maturidade: tanto para um MBA na FGV, como um mestrado na USP, não sinto que estou no momento de fazer, ou melhor, não sinto que irei contribuir o meu máximo para o curso, e que ele irá agregar tanto para a minha formação.

Acho que devo uma explicação para a minha última frase, afinal que louco falaria que um MBA na FGV ou um mestrado na USP não iria agregar tanto para a formação dele.

Então senhores(as), ambos iriam agregar muito, tanto para a minha formação, como para o meu networking (lembrando que o networking é um dos pontos mais importantes de qualquer instituição educacional, desde do primário). No entanto, para o meu contexto atual, há outras alternativas que se encaixam melhor, além do mais, o título e “status” que uma pós na FGV ou USP me daria, não é algo tão relevante para mim (mesmo sabendo que pode ser para uma empresa que for me contratar), eu me importo muito mais com a grade dos cursos e professores e a relevância dos assuntos para o meu contexto.

A minha escolha foi baseada na minha expertise como aluno e meu gosto por vários assuntos/áreas. Essa expertise me permite navegar sozinho pelos mares da informação, e com ela eu mesmo faço a minha grade, escolho os meus mestres e o mais importante, consigo corrigir a tempo a minha direção.

Para ilustrar um pouco disso, vamos considerar a área de Teste de Software. Por ela ainda ser recente no Brasil, não há nenhum curso que esteja maduro e atualizado o suficiente para o meu gosto. Além do mais, para quem está nessa área e está focando em obter conhecimento, acredito ser mais válido acompanhar blogs, listas de discussão, ler livros e participar de eventos (como até disse nesse outro post).

Agora sobre o meu interesse em vários assuntos/áreas, acredito ser um “mal” desde cedo, pois na escola mesmo eu gostava de várias matérias, ao nível de gostar tanto de Matemática como de Português (rs). Lógico que há o risco de se tornar um pato, mas eu não estudo todas as áreas de meu interesse ao mesmo tempo, muito pelo contrário, geralmente eu foco em uma por um bom tempo e em paralelo vou dando uma olhada em outras. Simplesmente, é impossível abraçar o mundo.

Minha escolha

Lendo o sample do livro The Personal MBA: Master the Art of Business (vou até comprar o livro em breve), percebi que a minha escolha não é tão incomum assim, o próprio autor também fez essa escolha e há anos atrás, e ele cita pessoas que fizeram essa escolha há décadas atrás!

Eu costumo até brincar, que esse tipo de livro/autor são má influências para mim, porém, vejo que eles foram pessoas iguais a mim, que tiveram as suas dúvidas sobre qual caminho escolher, e acabaram encontrando outras pessoas com visões parecidades e que ajudaram a trilhar o seu próprio caminho.

Ainda estou bem no início desse caminho, portanto não há nenhum resultado expressante para te conta e tentar te convencer que esse é O caminho. Aliás, acredito que o caminho do autodidata pode se encaixar para determinadas pessoas e para outras não, e não há nada de errado com isso. O importante é você escolher o seu caminho, e não deixar essa escolha para o seu chefe, pais, marido/esposa, etc.

O interessante de ser um autodidata é que a impressão que eu tinha, é que esse é um caminho solitário, afinal, muitas vezes você não tem com quem discutir sobre o assunto que você está aprendendo ou tirar uma dúvida. Porém, não é bem assim não, acabei conhecendo várias pessoas (boa parte conhecidos/amigos virtuais) e até o problema da falta de relacionamento com outras pessoas (networking), pode ser muito bem surprido, indo em eventos relacionados com as áreas de estudo.

Outro ponto bem interessante, é que como você está no comando do seu próprio barco, e desta maneira, o seu limite é até onde os seus olhos podem ver.

Além do mais, o acesso a informação está muito mais fácil e simplificado hoje em dia, eu por exemplo, consigo ter em um minuto o livro que achei interessante em minhas mãos, ou melhor, no Kindle. E sites como a Amazon, são verdadeiros oasis da informação e do bom consumismo.

Saindo um pouco do mundo dos livros, temos os blogs, que ainda são uma fonte muito rica e atualizada de informação. Na área de Teste de Software por exemplo, há excelentes profissionais escrevendo em seus blogs, tanto aqui no Brasil, como lá fora. Palestras também estão cada vez mais sendo compartilhadas em canais como o YouTube e Vimeo, e o investimento financeiro necessário é zero!

Por enquanto é isso, quando eu ler o livro, provavelmente terei mais opiniões e pensamentos para compartilhar, e este assunto voltará ao foco.

E você o que pensa sobre pós-graduações, você já fez alguma, está pensando em fazer ou está seguindo por outros caminhos?

Fique por dentro das novidades, assine o feed do QualidadeBR.

Qual o objetivo do Teste de Software?

Minha resposta para essa pergunta é bem simples e direta: obter informações.

Na lighting talk dada pelo Shmuel Gershon na EuroStar desse ano, ele fala sobre isso de uma maneira bem didática (vale a pena assistir!).

Não que as outras respostas estejam erradas, muito pelo contrário. Mas percebo que algumas são muito extensas e particularmente, gosto de simplificar as coisas.

Mas dentre as possíveis respostas para a pergunta do título desse post, há uma perigosa: encontrar bugs.

Seria como se eu perguntasse para um policial, qual o objetivo do trabalho dele e ele me respondesse que é prender os bandidos. Na verdade, esse é só um dos objetivos do policial, e encontrar bugs é só um dos objetivos do Teste de Software.

E o perigo para nós profissionais de Teste de Software, é quando os outros pensam que a nossa tarefa é só essa, ou pior ainda, quando nós mesmos nos limitamos a fazer apenas isso.

Durante a exploração do software, não podemos ficar esperando encontrar apenas bugs, precisamos focar em encontrar informações. Como o próprio Shmuel disse: ao obter uma informação, ao invés, de se perguntar se ela é algo ruim, podemos nos perguntar “o que podemos concluir a partir dessa informação?”. Parece ser a mesma pergunta, mas não é.

Além do mais, se você focar apenas em encontrar bugs, poderá perder facilmente a motivação, pois haverá dias em que você não encontrará nada, porém se você focar em obter informações, dificilmente passará um dia sem ter obtido uma informação interessante.

Notícias ruins é o que faz vender o jornal (rs) ou prender a atenção a TV, mas não se restrinja apenas as tragédias, há vários outros tipos de informações que podem ser até mais relevantes para a equipe, e que ajudarão eles a melhorar o sistema. E você não será mais visto, como o portador de notícias ruins (rs).

Fique por dentro das novidades, assine o feed do QualidadeBR.

Teste de Software: resultado da imperfeição

Ontem comecei a ler o livro “O Ócio Criativo” do Domenico de Masi. E logo no começo, em uma das perguntas feitas pela entrevistadora Maria Serena Palieri ao de Masi, ele traz um insight muito interessante, no qual valoriza as imperfeições do ser humano.

Para entender melhor, reproduzo abaixo o trecho do livro em questão:

Quais foram, então, os momentos da História nos quais nós, seres humanos, atravessamos encruzilhadas, vimos que o mundo virava de cabeça para baixo, se torna “um outro” mundo?

Um primeiro longo período da história humana vai de setenta milhões a setecentos mil anos atrás. Durante esse período, quem vivia não percebia nenhuma mudança, se sentia sempre igual. Trata-se da longuíssima fase na qual o homem criou a si mesmo: aprendeu a andar ereto, a falar, a educar a prole.

Se refletirmos bem, estas são mudanças extraodinárias, todas elas decorrentes da compensação dos nossos defeitos. Rita Levi Montalcini explicou isso muito bem no seu livro L’elogio dell’imperfezione (O elogio da imperfeição). Tínhamos um olfato fraco, portanto não podíamos perseguir a caça farejando a terra, como fazem os animais, mas tínhamos que avistá-la: para isto devíamos caminhar de pé, já que a caça frequentemente fugia, desaparecendo na vegetação. Isto fez com que se tenham salvado somente aqueles indivíduos da nossa espécie que se tornaram mais aptos para caminhar eretos.

Tal fato nos faz entender melhor o surgimento de várias áreas e tecnologias. E uma das áreas decorrentes da imperfeição humana, é a de Teste de Software.

Todos conhecem aquela frase que diz que “errar é humano”. E a probabilidade da ocorrência do erro ainda pode ser maior dependendo do ambiente em que estamos inserido. Sendo que quando falamos de um ambiente de desenvolvimento de software, logo lembramos de palavras como: prazo, complexidade, pressão, dentre outras.

Portanto, os profissionais de TI acabaram ao longo do tempo, percebendo a importância de se testar o software, sendo ela uma ação derivada da imperfeição humana. Afinal, seria um desperdício de tempo e esforço testar algo produzido pelo ser humano, se ele fosse perfeito.

É interessante notar, que graças as nossas imperfeições, fomos forçados a nos adaptar melhor ao ambiente em que vivemos e ao longo da história da humanidade, grandes inventos foram feitos, justamente para tentar contrapor tais imperfeições.

Voltando ao texto do livro, podemos interpretar que ao aprender a andar ereto, diminuímos os riscos de não conseguir comida. E pensando no mundo do desenvolvimento de software, o Teste de Software acaba também diminuindo riscos, no caso, os riscos associados a qualidade do produto/serviço que iremos entregar ao cliente.

E a lição que podemos tirar de tudo isso, é que é importante reconhecer as nossas limitações e erros, e mais importante ainda, é buscar agir para contrapô-los. Sendo assim, testar um software acaba sendo uma das ações que podemos executar, para contrapor o fato de que não produzimos software perfeito.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Tire a gente da Área 51

O Felipe Knorr Kuhn teve a iniciativa de criar um repositório para perguntas sobre Teste de Software no StackExchange (mesma plataforma do StackOverflow e que foi criado pelo grande Joel Spolsky e o Jeff Atwood) .

Abaixo, falo mais sobre esse repositório, baseado no e-mail do Felipe, que foi enviado para algumas listas de discussões.

O que é o StackExchange?

Assim como o StackOverflow, ele é voltado para armazenar perguntas e respostas, tendo funcionalidades como por exemplo: “tagear” perguntas e avaliar respostas e perguntas,. O legal do StackExchange, é que ele te permite criar o seu próprio repositório de perguntas e respostas, onde uma comunidade fica responsável por ele.

Se quiser ver um exemplo prático de uso do StackExchange, você pode clicar no link abaixo, para o repositório de Teste de Software internacional, onde pessoas como o Matthew Heusser, Justin Hunter e o Shmuel Gershon participam:

http://testing.stackexchange.com/

Que área 51 é essa?

Para pode ter um repositório no StackExchange é preciso passar por três etapas:

  • Definição: Precisamos de 60 pessoas “seguindo” a proposta e algumas perguntas que sirvam de bom ou mal exemplo para o assunto;
  • Comprometimento: Uma vez que a etapa de definição tenha sido atingida, precisamos de pessoas que decidam dar suporte à comunidade, fazendo ou respondendo perguntas;
  • Beta: É o site finalmente no ar, sendo utilizado pela comunidade.

Enquanto o nosso repositório não passar por essas três etapas ele fica numa área “secreta”, chamada área 51, uma boa analogia do pessoal do StackExchange com a Área 51 (rs).

Qual a diferença desse repositório para as listas de discussão?

O foco do StackExchange é armazenar perguntas e respostas, sendo assim a primeira diferença é que o repositório será voltado para responder perguntas relacionadas com Teste de Software. Já numa lista de discussão os assuntos podem ser mais variados, desde discussões até divulgação de eventos.

Particularmente, acho bem legal o StackOverflow (onde sempre caiu quando pesquiso por alguma exceção ou problema que estou buscando resolver), e por isso, acho que o nosso repositório no StackExchange pode ser bem legal, afinal ele é focado em perguntas e respostas, e isso pode facilitar tanto a vida de quem quer ajudar, quanto de quem está querendo ajuda.

Agora se vai dá certo ou não, só o tempo poderá dizer. 🙂

Se você achou interessante a ideia e quer participar, acesse o link abaixo para seguir o repositório e por favor, divulgue na sua empresa, grupo de amigos, etc. 😀

http://area51.stackexchange.com/proposals/10120/teste-de-software

Fique por dentro das novidades, assine o feed do QualidadeBR.