Depois de fazer a pesquisa sobre especializações em Teste de Software pelo Brasil, que resultou em uma planilha com uma lista de cursos, criei o blog Avançando no Teste de Software.
O objetivo é ter um ponto de consulta de cursos em todo o Brasil. Por enquanto estou colocando os cursos de pós graduação indicados pela comunidade, mas a ideia é que o blog tenha cursos técnicos e inclusive graduações que possuam disciplina de Teste de Software.
Quer indicar um curso para o blog? Comenta no post de Introdução do blog Avançando no Teste de Software e eu vou criando as páginas.
terça-feira, 24 de janeiro de 2012
quinta-feira, 12 de janeiro de 2012
Configurando visibilidade de produtos no bugzilla
A correria
anda grande e quase não tenho postado, mas esse eu achei que valeria a pena vir
compartilhar.
Precisei
configurar o bugzilla para um grupo de beta testers utilizarem. O objetivo era
que os beta testers reportassem os bugs na mesma ferramenta que já estamos
usando internamente para reportar os bugs para o time de desenvolvimento,
evitando retrabalhos como copiar descrições ou importar/exportar de outras
ferramentas.
Até ai,
tudo bem, mas como os beta testers estão testando livremente, sem nenhum
treinamento na aplicação e não tem nenhuma formação em teste, eles podem abrir
bugs que seriam apenas sugestões e não defeitos, ou ainda abrir defeitos em
funcionalidades que não foram desenvolvidas, entre outros mal entendidos que
enxeriam a caixa dos desenvolvedores de questões não pertinentes e acabariam
atrasando o trabalho deles.
Para isso então,
criamos módulos separados dentro do mesmo projeto que seriam visíveis apenas
para os beta testers enquanto os bugs já conhecidos, que os desenvolvedores já estão
trabalhando, ficariam visíveis apenas para a equipe interna. E ai começou a
trabalheira de encontrar como poderíamos omitir alguns produtos para uns e
outros produtos para outros usuários.
O caminho
natural foi procurar no manual do bugzilla, mas apesar de o manual explicar os parâmetros
do bugzilla, ao menos para minha equipe não ficou claro como fazer o passo a
passo para que funcionasse. Fuçando no google e no bugzilla, encontramos uma solução:
Menu
Administration > Parameters > Group Security
Tem um parâmetro
chamado usevisibilitygroups que deve ser ligado:
Feito isso,
será necessário criar dois grupos de usuários. Esse foi o nosso erro mais
insistente. Imaginamos a principio que como todos já estavam vendo os bugs,
seria necessário criar apenas um grupo e limitar a visualização desse grupo.
Mas na verdade não conseguimos fazer funcionar assim. Apenas quando criamos os
dois grupos conseguimos gerenciar corretamente a visualização.
Para criar
os grupos:
Menu Administration
> Groups > Add Group
Há uma explicação
no próprio bugzilla sobre como preencher os campos abaixo:
Lembre-se,
crie os 2 grupos!
Agora vamos
setar a visibilidade desses dois por produto.
Menu
Adminsitration > Products e escolha um produto
Agora para
cada produto será necessário dizer quem ve e posta bugs neles e quem não vê (e
consequentemente não posta bugs).
Acesse um
produto e vá em Edit Group Access Controls. Devem aparecer os dois grupos
criados. E essa foi a configuração que funcionou pra nós.
Configuração
para produtos acessíveis apenas pelos beta testers:
Configuração
acessível pelos outros usuários que não são beta testers:
E não
esquecer o mais importante agora: colocar cada usuário no grupo correto.
Menu
Administration > Users > Search
Espero que
você não tenha muitos usuários no sistema, agora será necessário atualizar um
por um.
Observação:
Nesse caso em que setamos a configuração de acesso para todos os produtos e
todos os usuários, usuários novos que não pertençam a nenhum grupo não poderão abrir
bugs.
Espero que
o post seja útil para economizar um tempinho para você ou, se você tiver um
jeito mais pratico, faz um post e linka aqui. :)
domingo, 14 de agosto de 2011
Certificações: O assunto de sempre compilado e comentado
E então? Você deve ou não tirar uma certificação? Qual a certificação que está mais visada? O que as pessoas que selecionam currículos mais levam em consideração? Vamos passar por essas e outras perguntas exibindo o resultado da pesquisa Certificações de Testes no Mercado Brasileiro que ficou no ar durante a semana passada aqui no blog e foi divulgada nas principais listas de discussão de teste do Brasil.
Total e seus estados
151 pessoas responderam a pesquisa. Os estados mais expressivos foram SP 23%, seguido do RS 21%. Tivemos ainda uma resposta de Israel, alguém adivinha de quem foi essa? :)
Ainda, 54% não possui nenhuma certificação e 45% possui alguma certificação de testes.
Quem não possui certificação, quer ter? Essa resposta não era obrigatória e deveria ser respondida apenas por quem não possui uma certificação.
Qual certificação tirar?
A pesquisa mostrou maior interesse na CTFL com 76%, seguida da CBTS com 44%. Essas respostas cobrem tanto as certificações que os pesquisados possuem, quanto as que eles desejam obter.
Particularmente eu tenho hoje a CTAL-TA e portanto, a CTFL. Escolhi o board do ISTQB em 2007, quando tirei a CTFL, por ser internacional e pela facilidade na época de fazer a prova. Fiz a inscrição no site da Prometric e pude realizar o exame em um centro Prometric na data mais conveniente para mim, sem ter que me agendar para fazer a prova com várias outras pessoas em uma mesma data. Os centros Prometric ainda aplicam essa prova, mas ela é em inglês. Para quem não se sente confortável com o idioma e tem interesse nessa certificação, o ideal é então procurar o BSTQB e fazer a sua inscrição para a data divulgada.
Para saber mais sobre as certificações de teste, vale a pena uma leitura do clássico post do Fábio Martinho sobre o assunto.
O tempo que os entrevistados possuem de certificação variou bastante. Tomando inclusive o meu caso como exemplo (tirada em 2007 – 4 anos), na próxima pesquisa vou melhorar esses tempos para ter uma ideia a partir de quando essa ideia de certificação virou um boom.
Outro fator que eu tinha curiosidade de saber foi se as empresas têm investido nos seus profissionais para que tirem certificações. 55% respondeu que custeou ou pretende custear a sua certificação. Fica uma reflexão: Se é realmente importante pra empresas que o funcionário seja certificado, porque elas não estão custeando essas certificações? Ou será que não é tão importante assim?
Quais as vantagens de ser certificado?
A maioria respondeu que com a certificação pretendia ganhar novos conhecimentos e um status profissional diferenciado. Aqui vale um quadro relacionando o que as pessoas esperavam quando foram atrás da sua certificação (ou esperam indo atrás de uma) e o que as pessoas que possuem uma certificação observaram de ganhos reais.
O segundo maior motivador para as certificações está listado como 5o ou 6o benefício adquirido com a certificação, empatado com a opção Nenhum.
Particularmente não vi muita diferença por causa da certificação. Cheguei a aprender alguma coisa nova de técnicas de análise de teste estudando para a certificação, mas não posso dizer que fez uma grande diferença. Não sinto meu status profissional diferenciado por ter uma certificação. Sinto que a experiência que eu tenho tido nos projetos em que participo, nas leituras de blog, listas de discussão etc., isso sim tem contribuído muito mais para meu crescimento e a visibilidade desse crescimento. A certificação pra mim tem sido um detalhe. Fiz agora a CTAL-TM. Por quê? Porque eu precisava adicionar um ponto no meu plano de performance na empresa e meu gerente achou que seria bom que fosse uma nova certificação. Nesse caso, já que ele achou, ele está custeando. A título de currículo, experiência e expectativas com a certificação, o fato de eu obtê-la ou não, não muda muita coisa. Mas espero passar para cumprir o meu plano de performance desse ano. :)
Seguem os gráficos das respostas:
E na hora da seleção? Ser certificado conta?
52% respondeu que participa do processo de seleção da sua empresa e ajudou a pontuar como são vistos pelas empresas os seguintes pontos:
Nunca senti a certificação como um diferencial para me selecionarem em uma empresa. Participei na empresa anterior e participo agora de seleção de profissionais. Atualmente as seleções que participo são esporádicas e são para consultores, portanto um nível mais sênior de profissionais. Nesse caso, não ligo a mínima para certificações. Quem eu ajudei a contratar foi por conhecer pessoalmente o trabalho daquela pessoa. Eu diria que contou mais Recomendações (meu próprio conhecimento nesse caso) e Demonstrações de habilidades na entrevista (já ter trabalhado com a pessoa).
Na empresa que trabalhei anteriormente eram muitas seleções de diversos níveis. No caso de profissionais júniors que estavam saindo da faculdade, sem experiência, etc. eu considerava sim o fato de o candidato ter uma certificação porque isso pra mim demonstrava interesse em aprender, em entrar no mercado e me dizia que provavelmente aquele candidato conhecia os conceitos mínimos de teste de software. Ou seja, Anos de Experiência contariam mais do que Certificações, mas como não havia nenhum ano de experiência, a certificação passava a valer um pouco mais. Como a certificação não prova que o candidato realmente sabe alguma coisa, um teste escrito e uma entrevista checando as respostas e outros conhecimentos do candidato valiam como ratificação ou não da minha expectativa em relação a certificação ou ao conhecimento indicado no currículo. A titularidade do candidato, bem como a instituição que proveu essa titularidade pra mim não faz muita diferença. Em parte isso se dá por eu não ter me formado em uma grande universidade e não acho que isso tenha feito diferença. Além do mais, seria muito bom que eu pudesse ter certeza que o candidato aproveitou bem suas aulas de Engenharia de Software e afins, mas isso nem a titulação, nem a instituição podem me dar, assim como a certificação por si só também não me diz que o candidato sabe alguma coisa.
Pra mim então, esses pesos seriam:
E para os que responderam a pesquisa?
Seguem os gráficos:
Conclusão
A resposta se você deve ou não tirar uma certificação deve ser obviamente uma conclusão sua. Essa pesquisa pode ajuda-lo a decidir e avaliar se isso tende ou não a ter algum impacto na carreira.
O objetivo da pesquisa foi o de entender um pouco mais sobre como o mercado está realmente vendo as certificações e dar oportunidade de pessoas expressarem mais objetivamente sua opinião sobre o assunto.
Se você ainda tiver interesse de continuar avaliando opiniões, dessa vez de maneira mais subjetiva, sugiro a leitura de alguns posts do QualidadeBR. Enquanto eu procurava o post da mesa redonda de certificações para compartilhar com vocês, achei ainda outros posts relevantes para o assunto:
Certificações de Teste de Software, por que ter uma?
Como contratar um profissional para a área de Teste?
Teste de Software: Desafios do Início
Certificações, valem a pena?
Essa discussão continua nos comentários desse post. Se você tem alguma opinião sobre os resultados ou alguma sugestão de melhoria da pesquisa, compartilhe.
Total e seus estados
151 pessoas responderam a pesquisa. Os estados mais expressivos foram SP 23%, seguido do RS 21%. Tivemos ainda uma resposta de Israel, alguém adivinha de quem foi essa? :)
Ainda, 54% não possui nenhuma certificação e 45% possui alguma certificação de testes.
Quem não possui certificação, quer ter? Essa resposta não era obrigatória e deveria ser respondida apenas por quem não possui uma certificação.
Qual certificação tirar?
A pesquisa mostrou maior interesse na CTFL com 76%, seguida da CBTS com 44%. Essas respostas cobrem tanto as certificações que os pesquisados possuem, quanto as que eles desejam obter.
Particularmente eu tenho hoje a CTAL-TA e portanto, a CTFL. Escolhi o board do ISTQB em 2007, quando tirei a CTFL, por ser internacional e pela facilidade na época de fazer a prova. Fiz a inscrição no site da Prometric e pude realizar o exame em um centro Prometric na data mais conveniente para mim, sem ter que me agendar para fazer a prova com várias outras pessoas em uma mesma data. Os centros Prometric ainda aplicam essa prova, mas ela é em inglês. Para quem não se sente confortável com o idioma e tem interesse nessa certificação, o ideal é então procurar o BSTQB e fazer a sua inscrição para a data divulgada.
Para saber mais sobre as certificações de teste, vale a pena uma leitura do clássico post do Fábio Martinho sobre o assunto.
O tempo que os entrevistados possuem de certificação variou bastante. Tomando inclusive o meu caso como exemplo (tirada em 2007 – 4 anos), na próxima pesquisa vou melhorar esses tempos para ter uma ideia a partir de quando essa ideia de certificação virou um boom.
Outro fator que eu tinha curiosidade de saber foi se as empresas têm investido nos seus profissionais para que tirem certificações. 55% respondeu que custeou ou pretende custear a sua certificação. Fica uma reflexão: Se é realmente importante pra empresas que o funcionário seja certificado, porque elas não estão custeando essas certificações? Ou será que não é tão importante assim?
Quais as vantagens de ser certificado?
A maioria respondeu que com a certificação pretendia ganhar novos conhecimentos e um status profissional diferenciado. Aqui vale um quadro relacionando o que as pessoas esperavam quando foram atrás da sua certificação (ou esperam indo atrás de uma) e o que as pessoas que possuem uma certificação observaram de ganhos reais.
|
Objetivo
|
Pretende/Pretendia obter
|
Atingiu esse objetivo
|
|
Adquirir novos conhecimentos
|
79%
|
79%
|
|
Aumento salarial ou troca de posição na sua empresa
|
53%
|
18%
|
|
Aumento salarial ou troca de posição em uma nova empresa
|
30%
|
22%
|
|
Status profissional
|
60%
|
49%
|
|
Utilizar os conhecimentos obtidos na prova para lecionar em cursos
preparatórios
|
20%
|
9%
|
|
Cumprir plano de desenvolvimento profissional da atual empresa
|
23%
|
16%
|
|
Gerar competitividade para a empresa em licitações
|
28%
|
25%
|
|
Nenhum
|
N/A
|
18%
|
O segundo maior motivador para as certificações está listado como 5o ou 6o benefício adquirido com a certificação, empatado com a opção Nenhum.
Particularmente não vi muita diferença por causa da certificação. Cheguei a aprender alguma coisa nova de técnicas de análise de teste estudando para a certificação, mas não posso dizer que fez uma grande diferença. Não sinto meu status profissional diferenciado por ter uma certificação. Sinto que a experiência que eu tenho tido nos projetos em que participo, nas leituras de blog, listas de discussão etc., isso sim tem contribuído muito mais para meu crescimento e a visibilidade desse crescimento. A certificação pra mim tem sido um detalhe. Fiz agora a CTAL-TM. Por quê? Porque eu precisava adicionar um ponto no meu plano de performance na empresa e meu gerente achou que seria bom que fosse uma nova certificação. Nesse caso, já que ele achou, ele está custeando. A título de currículo, experiência e expectativas com a certificação, o fato de eu obtê-la ou não, não muda muita coisa. Mas espero passar para cumprir o meu plano de performance desse ano. :)
Seguem os gráficos das respostas:
E na hora da seleção? Ser certificado conta?
52% respondeu que participa do processo de seleção da sua empresa e ajudou a pontuar como são vistos pelas empresas os seguintes pontos:
- Recomendações
- Anos de experiência
- Certificações
- Demonstrações de habilidades na entrevista
- Formação Acadêmica
Nunca senti a certificação como um diferencial para me selecionarem em uma empresa. Participei na empresa anterior e participo agora de seleção de profissionais. Atualmente as seleções que participo são esporádicas e são para consultores, portanto um nível mais sênior de profissionais. Nesse caso, não ligo a mínima para certificações. Quem eu ajudei a contratar foi por conhecer pessoalmente o trabalho daquela pessoa. Eu diria que contou mais Recomendações (meu próprio conhecimento nesse caso) e Demonstrações de habilidades na entrevista (já ter trabalhado com a pessoa).
Na empresa que trabalhei anteriormente eram muitas seleções de diversos níveis. No caso de profissionais júniors que estavam saindo da faculdade, sem experiência, etc. eu considerava sim o fato de o candidato ter uma certificação porque isso pra mim demonstrava interesse em aprender, em entrar no mercado e me dizia que provavelmente aquele candidato conhecia os conceitos mínimos de teste de software. Ou seja, Anos de Experiência contariam mais do que Certificações, mas como não havia nenhum ano de experiência, a certificação passava a valer um pouco mais. Como a certificação não prova que o candidato realmente sabe alguma coisa, um teste escrito e uma entrevista checando as respostas e outros conhecimentos do candidato valiam como ratificação ou não da minha expectativa em relação a certificação ou ao conhecimento indicado no currículo. A titularidade do candidato, bem como a instituição que proveu essa titularidade pra mim não faz muita diferença. Em parte isso se dá por eu não ter me formado em uma grande universidade e não acho que isso tenha feito diferença. Além do mais, seria muito bom que eu pudesse ter certeza que o candidato aproveitou bem suas aulas de Engenharia de Software e afins, mas isso nem a titulação, nem a instituição podem me dar, assim como a certificação por si só também não me diz que o candidato sabe alguma coisa.
Pra mim então, esses pesos seriam:
- Demonstrações de habilidades na entrevista -> 5
- Recomendações -> 4
- Anos de experiência -> 3
- Certificações -> 2
- Formação Acadêmica -> 1
E para os que responderam a pesquisa?
- Demonstrações de habilidades na entrevista disparou no peso 5 (32%);
- Anos de experiência ficou entre 4 (22%) e 5 (24%);
- Formação Acadêmica ficou entre os pesos 4 (19%) e 3 (21%);
- Certificações ficou com pontuação 3 (20%) como predominante;
- Recomendações foi um item que ficou bem empatado. Os valores 2, 3, 4 e 5 variam apenas de 13% a 15%;
Seguem os gráficos:
Conclusão
A resposta se você deve ou não tirar uma certificação deve ser obviamente uma conclusão sua. Essa pesquisa pode ajuda-lo a decidir e avaliar se isso tende ou não a ter algum impacto na carreira.
O objetivo da pesquisa foi o de entender um pouco mais sobre como o mercado está realmente vendo as certificações e dar oportunidade de pessoas expressarem mais objetivamente sua opinião sobre o assunto.
Se você ainda tiver interesse de continuar avaliando opiniões, dessa vez de maneira mais subjetiva, sugiro a leitura de alguns posts do QualidadeBR. Enquanto eu procurava o post da mesa redonda de certificações para compartilhar com vocês, achei ainda outros posts relevantes para o assunto:
Certificações de Teste de Software, por que ter uma?
Como contratar um profissional para a área de Teste?
Teste de Software: Desafios do Início
Certificações, valem a pena?
Essa discussão continua nos comentários desse post. Se você tem alguma opinião sobre os resultados ou alguma sugestão de melhoria da pesquisa, compartilhe.
sexta-feira, 5 de agosto de 2011
Certificações de Teste no Mercado Brasileiro
Muito se fala e se procura sobre certificações não só no Brasil, mas no mundo inteiro. É comum termos mesas redondas (ou discussoes calorosas :) ) sobre o assunto e inclusive esse blog nasceu com o intuito de me ajudar a estudar para uma certificação.
Durante o periodo que aguardei o lançamento da prova CTAL-TA no Brasil, também fui conversando com várias pessoas e lendo a respeito de certificações e formando minha opinião sobre o assunto. Essa, eu vou deixar para o próximo post.
O objetivo desse post é saber da sua experiência. Saindo do âmbito de discussões com opiniões individuais (muitas boas discussões podem ser encontradas no DFTestes, vale a pena ler), essa pesquisa tem o objetivo de coletar dados do Brasil inteiro e através da análise da experiência de uma massa de profissionais de testes indicar qual tem sido a real experiência com as certificações de teste no mercado brasileiro.
Conto com a sua participação e divulgação.
Durante o periodo que aguardei o lançamento da prova CTAL-TA no Brasil, também fui conversando com várias pessoas e lendo a respeito de certificações e formando minha opinião sobre o assunto. Essa, eu vou deixar para o próximo post.
O objetivo desse post é saber da sua experiência. Saindo do âmbito de discussões com opiniões individuais (muitas boas discussões podem ser encontradas no DFTestes, vale a pena ler), essa pesquisa tem o objetivo de coletar dados do Brasil inteiro e através da análise da experiência de uma massa de profissionais de testes indicar qual tem sido a real experiência com as certificações de teste no mercado brasileiro.
Conto com a sua participação e divulgação.
domingo, 2 de janeiro de 2011
Minha experiência CTAL
Estou de volta. Dei um tempo no blog para organizar o casamento, sair de férias e quando voltei, voltei no projeto a mil! Agora em 2011, espero retomar o pique dos posts.
Primeiro, um 2011 cheio de realizações para todos! :)
E falando em realizações e conquistas, em 2010 eu tirei a CTAL-TA. Quando criei o blog, a idéia era ir me preparando para a prova e postando aqui o material que eu ia lendo e compartilhando esse preparo, mas muitas coisas aconteceram. O trabalho não deu muita folga e mesmo o m eu planejamento inicial não foi muito seguido.
O que eu usei para me preparar? Apenas li o livro Advanced Software Testing do Rex Black que indiquei aqui no blog.
O livro é bem legal. O ponto que ele peca um pouco, em minha opinião, é no detalhamento de resoluções de questões relativas a técnicas de análise. No mais, é um excelente guia.
Não li o Syllabus. Mas não recomendo essa prática, afinal é o material oficial da CTAL.
Sobre simulados, baixei alguns no VTB (Vietnamese Testing Board), mas só resolvi um que tinha gabarito. Não vejo sentido em resolver sem ter certeza se está correto ou não.
Eu achei os simulados do Advanced Software Testing bem legais. Pra CTFL também só usei o Foundations of Software Testing.
O que eu achei do nível da prova? Tem perguntas bem fáceis, como as questões de ética e questões sobre definição de PDCA, auditoria, etc. Tem perguntas mais chatinhas de responder como quantidade de testes que devem ser feitos em determinado cenário aplicando as técnicas A e B (tem essas perguntas para treinar no Advanced Software Testing).
Quais pontos eu acho que fui pior e podia ter me dedicado mais? Tem várias normas citadas no livro. Não só as IEEE e ISO, mas também as BS e DO. Se tivesse tido mais tempo para estudar teria baixado as normas e lido.
Quanto tempo eu dediquei para estudar? Comecei o blog em maio/2009, mas não posso dizer que venho estudando desde então. Li o livro até a parte de Análise por Valor Limite, que eu postei em março/2010. Depois parei de ler o livro. Ainda não haviam marcado a CTAL no Brasil, eu estava sem perspectiva de fazer a prova fora do BSTQB e sem um prazo, fiquei desmotivada. Quando voltei de viagem de lua de mel, estava na última semana para me inscrever na prova e só depois da confirmação retomei a minha leitura. Mas como havia iniciado há muito tempo, resolvi começar do começo. Lógico que não deu tempo de ler o livro inteiro. Li até o quarto capitulo, e os seguintes eu apenas resolvi as questões do simulado que tem no final. No total eu diria que foi algo em torno de 1 mês se eu fosse por em tempo produtivo.
Qual a minha visão geral da prova? Assim como a CTFL, acredito que se você é uma pessoa que freqüenta eventos de teste, está atualizado com os conceitos, técnicas, anda visitando os blogs, participando de listas de discussão, não fica acomodado em mundos que muitas vezes são restritos no trabalho, há grandes chances de passar sem surtar estudando. Claro que vale a pena dedicar um tempo para o estudo, não é uma prova tão trivial quanto a CTFL. Se você não achou a CTFL fácil, então estude o dobro pra CTAL, senão não passa.
O que eu recomendo? Já me mandaram emails perguntando isso. Bom, primeiro eu fiz um relato de como foi PRA MIM. Não quer dizer que vai ser assim para todos. Outros que fizeram a CTAL podem ter opiniões diferentes, claro. Não recomendo fazer o meu plano de estudo (até porque não segui nenhum). Recomendo o leitura do Syllabus, do Advanced Software Testing e resolução de simulados, que como comentei tem alguns no Vietnamese Testing Board. Também acho um bom caminho se preparar como se fosse fazer o ISEB Intermediate. Eu não fiz essa prova, mas pode ser um bom passo intermediário para quem quer ter mais certeza do seu preparo antes da CTAL. O ISEB segue a mesma linha do ISTQB e a CTFL vale como certificação inicial para ambos os boards.
É isso. Boa sorte para o pessoal que vai fazer a CTAL na próxima prova.
Primeiro, um 2011 cheio de realizações para todos! :)
E falando em realizações e conquistas, em 2010 eu tirei a CTAL-TA. Quando criei o blog, a idéia era ir me preparando para a prova e postando aqui o material que eu ia lendo e compartilhando esse preparo, mas muitas coisas aconteceram. O trabalho não deu muita folga e mesmo o m eu planejamento inicial não foi muito seguido.
O que eu usei para me preparar? Apenas li o livro Advanced Software Testing do Rex Black que indiquei aqui no blog.
O livro é bem legal. O ponto que ele peca um pouco, em minha opinião, é no detalhamento de resoluções de questões relativas a técnicas de análise. No mais, é um excelente guia.
Não li o Syllabus. Mas não recomendo essa prática, afinal é o material oficial da CTAL.
Sobre simulados, baixei alguns no VTB (Vietnamese Testing Board), mas só resolvi um que tinha gabarito. Não vejo sentido em resolver sem ter certeza se está correto ou não.
Eu achei os simulados do Advanced Software Testing bem legais. Pra CTFL também só usei o Foundations of Software Testing.
O que eu achei do nível da prova? Tem perguntas bem fáceis, como as questões de ética e questões sobre definição de PDCA, auditoria, etc. Tem perguntas mais chatinhas de responder como quantidade de testes que devem ser feitos em determinado cenário aplicando as técnicas A e B (tem essas perguntas para treinar no Advanced Software Testing).
Quais pontos eu acho que fui pior e podia ter me dedicado mais? Tem várias normas citadas no livro. Não só as IEEE e ISO, mas também as BS e DO. Se tivesse tido mais tempo para estudar teria baixado as normas e lido.
Quanto tempo eu dediquei para estudar? Comecei o blog em maio/2009, mas não posso dizer que venho estudando desde então. Li o livro até a parte de Análise por Valor Limite, que eu postei em março/2010. Depois parei de ler o livro. Ainda não haviam marcado a CTAL no Brasil, eu estava sem perspectiva de fazer a prova fora do BSTQB e sem um prazo, fiquei desmotivada. Quando voltei de viagem de lua de mel, estava na última semana para me inscrever na prova e só depois da confirmação retomei a minha leitura. Mas como havia iniciado há muito tempo, resolvi começar do começo. Lógico que não deu tempo de ler o livro inteiro. Li até o quarto capitulo, e os seguintes eu apenas resolvi as questões do simulado que tem no final. No total eu diria que foi algo em torno de 1 mês se eu fosse por em tempo produtivo.
Qual a minha visão geral da prova? Assim como a CTFL, acredito que se você é uma pessoa que freqüenta eventos de teste, está atualizado com os conceitos, técnicas, anda visitando os blogs, participando de listas de discussão, não fica acomodado em mundos que muitas vezes são restritos no trabalho, há grandes chances de passar sem surtar estudando. Claro que vale a pena dedicar um tempo para o estudo, não é uma prova tão trivial quanto a CTFL. Se você não achou a CTFL fácil, então estude o dobro pra CTAL, senão não passa.
O que eu recomendo? Já me mandaram emails perguntando isso. Bom, primeiro eu fiz um relato de como foi PRA MIM. Não quer dizer que vai ser assim para todos. Outros que fizeram a CTAL podem ter opiniões diferentes, claro. Não recomendo fazer o meu plano de estudo (até porque não segui nenhum). Recomendo o leitura do Syllabus, do Advanced Software Testing e resolução de simulados, que como comentei tem alguns no Vietnamese Testing Board. Também acho um bom caminho se preparar como se fosse fazer o ISEB Intermediate. Eu não fiz essa prova, mas pode ser um bom passo intermediário para quem quer ter mais certeza do seu preparo antes da CTAL. O ISEB segue a mesma linha do ISTQB e a CTFL vale como certificação inicial para ambos os boards.
É isso. Boa sorte para o pessoal que vai fazer a CTAL na próxima prova.
segunda-feira, 16 de agosto de 2010
Testar sem documentação é possível?
Essa é a minha contribuição para o livro do DFTestes.
Falei um pouco sobre a problemática da falta de documentação para a equipe de testes.
Confiram outros capítulos na página do livro.
1. Introdução
De acordo com o RUP, caso de teste "é a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um item de Teste-alvo". Duas disciplinas da Engenharia de Software provêem informações para criação dos casos de teste. São elas: Engenharia de Requisitos e Projeto.
De acordo com o IEEE, a Engenharia de Requisitos é o processo de aquisição, refinamento e verificação das necessidades do cliente. Dentro das diversas metodologias de desenvolvimento há maneiras distintas de documentar requisitos. No RUP, o principal documento gerado, que é utilizado pela equipe de teste, são os Modelos de Caso de Uso; já nas metodologias ágeis, um documento mais comum é o conjunto de User Stories. Na prática, muitas equipes não têm nem os Casos de Uso e nem as User Stories, mas sim, descrições em alto nível dos requisitos, sejam elas por escrito ou não.
A disciplina de Projeto, por sua vez gera documentos complementares às especificações de Requisitos. Nessa etapa, a estrutura interna do software é descrita através de diagramas. A utilização da linguagem UML é bastante recomendada na geração desses diagramas. Exemplos de diagramas de projeto são Diagramas de Estados, Diagramas de Seqüência e Diagrama de Atividades, entre outros.
Essa documentação serve como apoio para a elaboração dos testes. Todas elas são de grande valia para o analista no seu projeto de casos de teste. Mas e se o analista não as tiver? É possível, mesmo assim, testar? Essa é a pergunta tema da Nona Mesa Redonda do DFTestes.
Esse tema nos fez refletir sobre a necessidade da documentação para o teste. Primeiramente não vamos confundir necessidade com importância. Denotativamente o termo necessidade significa uma obrigação imprescindível, enquanto que importância ou relevância significa valor.
As participações nessa mesa redonda são freqüentemente utilizadas no texto que segue para expressar a opinião da comunidade sobre o assunto.
2. Testes Exploratórios
É possível sim testar sem scripts e isso já não se pode chamar de novidade. O termo "testes exploratórios" foi citado pela primeira vez por Cem Kaner em seu livro Testing Computer Software (1999).
Segundo James Bach, testes exploratórios são simultaneamente um aprendizado, um projeto e uma execução de teste. Através da profunda exploração das habilidades de ouvir, ler, pensar e reportar eficazmente, os testes exploratórios podem trazer informações muito importantes de maneira tão ou mais produtiva que os testes baseados em casos de teste. A falta de um script a ser seguido tende a potencializar essas habilidades.
3. Escolas de Teste
Sobre a documentação em que iremos embasar a criação dos casos de teste, o Jorge Diz disse: "não coloquemos todas as nossas fichas na documentação do sistema. Com certeza, é possível testar sem documentação formal: pode ser mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar que o documento mais atualizado é sempre o próprio sistema sendo testado."
O contexto! Esse é o grande segredo dessa discussão. A eficácia do seu teste pode ou não ser impactada pela falta de documentação considerando diversos cenários. É papel do analista de testes sinalizar até que ponto ele consegue aferir a qualidade do sistema com as ferramentas (documentação, especialista, etc.) que lhe foram dadas.
Dentro das Escolas de Teste, veremos que de acordo com as características de cada escola (um contexto), o tema "testar sem documentação é possível?" é tratado de maneiras diferentes.
De acordo com Pettichord (2007), uma escola é definida por afinidades intelectuais, interação social e objetivos comuns. São compostas por uma hierarquia de valores, técnicas, padrões de crítica, instituições organizadas e vocabulário comum.
Existem cinco escolas de teste e suas visões são:
Escola Analítica: o teste deve ser rigoroso e técnico, com base na academia
Escola Padrão: o teste é uma maneira de medir o progresso com ênfase no custo e padrões repetíveis
Escola da Qualidade: enfatiza o processo e policia os desenvolvedores
Escola baseada em Contexto: enfatiza as pessoas, procuram bugs com os quais os clientes se importam mais
Escola Ágil: usa o teste para provar que o desenvolvimento está completo. Enfatiza o teste automatizado
Sobre os testes sem documentação, são a favor:
Escola baseada em Contexto: "Faça o que puder para ser útil. Faça perguntas se necessário. Desencave especificações escondidas."
Escola Ágil: "Conversas são mais importantes que documentação"
E são contra:
Escola Analítica: "É impossível"
Escola Padrão: "Algum tipo de documentação é necessária"
Escola da Qualidade: "Force os desenvolvedores a seguir o processo"
Como cada escola vive um contexto e analisa o teste de acordo com os seus cenários, cada uma expressa uma visão diferente da possibilidade de testar sem documentação. Na visão geral dos participantes da discussão, testar sem documentação não é impossível, mas essa abordagem também não foi defendida como a melhor prática. A comunidade do DFTestes parece ter uma tendência muito próxima a da Escola baseada em Contexto, entendendo que não devemos olhar as nossas dificuldades de documentação como muros intransponíveis, mas como empecilhos que devem ser vencidos.
4. Reflexões da Mesa Redonda
"À medida que os sistemas se tornam mais complexos, os riscos se tornam maiores, chegando ao ponto no qual ninguém conhece o que há no sistema. Isto é ruim não só para o teste, mas também para todas as fases anteriores do desenvolvimento.
Falando de casos de uso ou similares, um dos problemas comuns de quem não tem essa documentação é o de não saber o que testar. Recentemente fiz uma análise de cobertura de código em um programa de pedidos e concluí que ao incluir um pedido neste sistema com o máximo de opções que consegui informar, não cobri nem 20% do código. Se você não tem nada para consultar, como testar os outros 80% de forma eficiente? Agora imaginem se este programa estivesse 60% documentado com casos de uso e casos de teste. Já seria uma garantia bem maior.
Outro problema é o de não saber o que alterar. Recentemente em um projeto foi esquecido de alterar um programa, e só esse programa gerou mais estresse que todas as outras alterações juntas porque estava dando problema lá no cliente. Sem documentação, não há rastreabilidade." [Ismael Munchen]
Na colocação do Ismael conclui-se que:
1. Falta de documentação pode prejudicar a cobertura dos testes
2. Falta de documentação implica em falta de rastreabilidade e aumento dos riscos nas manutenções do sistema
A visão do Marcelo Andrade complementa o primeiro cenário do Ismael:
"Claro que não dá para testar tirando conclusões sobre regras de negócio da própria cabeça do testador. Neste caso, se a informação está disponível (com o cliente ou com quem quer que seja) é ela que deve ser buscada."
Então, na falta de uma documentação, caso haja alguma outra fonte de conhecimento sobre os requisitos, ela viabiliza os testes e também aumenta a sua cobertura. Essa opinião também foi expressa pela Andrea Cruz quando ela fala que "testar sem documentação é possível, porém podem existir em determinados sistemas requisitos implícitos importantes que podem não ser cobertos pelo teste."
Existe sem dúvida um risco na falta de documentação. Para ser bem sucedido, o Analista de Teste precisa contar com alguma outra fonte de informação, ou a sua cobertura poderá ser seriamente prejudicada.
Segundo Daniel Goettenauer, "o beneficio da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existem muitas mudanças.
[...] dependendo do tamanho do projeto de teste a documentação poderia ser tratada de forma mais simples (documentos básicos) ou complexa (todos os documentos). Dessa forma não teríamos projetos desenvolvidos em 16 horas e testados em 72 horas por conta do volume de documentação."
Ter algum nível de documentação é mesmo importante, entretanto o que define sua necessidade? Uma documentação necessária é aquela que é consultada e mantida, que serve de apoio para o time ou, não se encaixando em nenhum desses objetivos, ela se torna necessária apenas se for uma requisição do cliente. Jeffries, 2001 expõe em seu blog esse mesmo ponto quando fala que "você pode precisar de um UML bem formatado para o seu projeto, ou você pode precisar imprimir o Javadoc quando distribuir o seu código para outros, ou você pode precisar documentar os requisitos para o gerenciamento ou como parte de um contrato. Se e quando você realmente precisar dessas documentações, você deve realmente tê-las." Se elas não forem realmente necessárias apenas demandam tempo da equipe e nem sempre são mantidas adequadamente.
Um sem número de documentos que são criados no início do projeto e não sofrem mais atualizações é uma realidade em muitos projetos. De acordo com o Shmuel, "uma documentação desatualizada é menos útil, mas ainda pode ser usada da mesma maneira. Mas essa ajuda não é um pré-requisito necessário, e podemos testar mesmo sem tê-la. Por meio de abstrações e inferências, é possível aprender sobre o programa de várias outras maneiras, durante os testes, durante conversas, durante as discussões sobre bugs etc.”
Essa opinião está alinhada com uma pesquisa do IEEE, 2003 em que entrevistas com engenheiros de software revelaram as seguintes opiniões sobre documentação:
"- Documento de arquitetura e outras documentações abstratas são freqüentemente válidos ou ao menos provêem um guia histórico que pode ser útil para manutenção.
- Documentações de todos os tipos freqüentemente estão desatualizadas
- Uma fração considerável da documentação não é confiável. "
O Felipe da Silva trouxe um ponto diferente sobre a necessidade e assinalou outro uso dado à documentação fora o projeto de testes que é o de contrato. É comum utilizarmos uma documentação e a aprovação do cliente como um contrato ou parte dele na definição de escopo e base para cronograma. Segundo Felipe, "na maioria dos casos além de brigarmos para querer ter um sistema testável por qualquer um, em determinados processos de engenharia de software também brigamos porque queremos ter um documento como "defesa" contra a insatisfação do cliente. É aquele problema que se você não documenta, o cliente não assina, se ele não assina, não existe um registro que ele havia dito que era aquilo que ele queria, correndo o risco do cliente reclamar e ter melhorias no sistema sem pagar por elas nem ajustar cronograma e etc."
5. Conclusão
As opiniões expostas na Mesa Redonda levaram a um entendimento de que a documentação pode não ser necessária, mas é importante. O tema é bastante abrangente e a cada participação na lista foi possível idealizar novos cenários para responder a mesma pergunta. E você? A que conclusão chegou após ler o que discutimos em mais uma edição da Mesa Redonda do DFTestes?
Participantes da Nona Mesa Redonda:
Fabrício, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe da Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.
Referências:
Much Ado About Nothing: Documentation
Ron Jeffries 2001
Schools of Software Testing
Bret Pettichord, 2007
How Software Engineers Use Documentation: The State of the Practice
Timothy C. Lethbridge, Janice Singer, Andrew Forward
IEEE Computer Society
2003
Exploratory Testing Explained
James Bach, 2003
Falei um pouco sobre a problemática da falta de documentação para a equipe de testes.
Confiram outros capítulos na página do livro.
1. Introdução
De acordo com o RUP, caso de teste "é a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um item de Teste-alvo". Duas disciplinas da Engenharia de Software provêem informações para criação dos casos de teste. São elas: Engenharia de Requisitos e Projeto.
De acordo com o IEEE, a Engenharia de Requisitos é o processo de aquisição, refinamento e verificação das necessidades do cliente. Dentro das diversas metodologias de desenvolvimento há maneiras distintas de documentar requisitos. No RUP, o principal documento gerado, que é utilizado pela equipe de teste, são os Modelos de Caso de Uso; já nas metodologias ágeis, um documento mais comum é o conjunto de User Stories. Na prática, muitas equipes não têm nem os Casos de Uso e nem as User Stories, mas sim, descrições em alto nível dos requisitos, sejam elas por escrito ou não.
A disciplina de Projeto, por sua vez gera documentos complementares às especificações de Requisitos. Nessa etapa, a estrutura interna do software é descrita através de diagramas. A utilização da linguagem UML é bastante recomendada na geração desses diagramas. Exemplos de diagramas de projeto são Diagramas de Estados, Diagramas de Seqüência e Diagrama de Atividades, entre outros.
Essa documentação serve como apoio para a elaboração dos testes. Todas elas são de grande valia para o analista no seu projeto de casos de teste. Mas e se o analista não as tiver? É possível, mesmo assim, testar? Essa é a pergunta tema da Nona Mesa Redonda do DFTestes.
Esse tema nos fez refletir sobre a necessidade da documentação para o teste. Primeiramente não vamos confundir necessidade com importância. Denotativamente o termo necessidade significa uma obrigação imprescindível, enquanto que importância ou relevância significa valor.
As participações nessa mesa redonda são freqüentemente utilizadas no texto que segue para expressar a opinião da comunidade sobre o assunto.
2. Testes Exploratórios
É possível sim testar sem scripts e isso já não se pode chamar de novidade. O termo "testes exploratórios" foi citado pela primeira vez por Cem Kaner em seu livro Testing Computer Software (1999).
Segundo James Bach, testes exploratórios são simultaneamente um aprendizado, um projeto e uma execução de teste. Através da profunda exploração das habilidades de ouvir, ler, pensar e reportar eficazmente, os testes exploratórios podem trazer informações muito importantes de maneira tão ou mais produtiva que os testes baseados em casos de teste. A falta de um script a ser seguido tende a potencializar essas habilidades.
3. Escolas de Teste
Sobre a documentação em que iremos embasar a criação dos casos de teste, o Jorge Diz disse: "não coloquemos todas as nossas fichas na documentação do sistema. Com certeza, é possível testar sem documentação formal: pode ser mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar que o documento mais atualizado é sempre o próprio sistema sendo testado."
O contexto! Esse é o grande segredo dessa discussão. A eficácia do seu teste pode ou não ser impactada pela falta de documentação considerando diversos cenários. É papel do analista de testes sinalizar até que ponto ele consegue aferir a qualidade do sistema com as ferramentas (documentação, especialista, etc.) que lhe foram dadas.
Dentro das Escolas de Teste, veremos que de acordo com as características de cada escola (um contexto), o tema "testar sem documentação é possível?" é tratado de maneiras diferentes.
De acordo com Pettichord (2007), uma escola é definida por afinidades intelectuais, interação social e objetivos comuns. São compostas por uma hierarquia de valores, técnicas, padrões de crítica, instituições organizadas e vocabulário comum.
Existem cinco escolas de teste e suas visões são:
Escola Analítica: o teste deve ser rigoroso e técnico, com base na academia
Escola Padrão: o teste é uma maneira de medir o progresso com ênfase no custo e padrões repetíveis
Escola da Qualidade: enfatiza o processo e policia os desenvolvedores
Escola baseada em Contexto: enfatiza as pessoas, procuram bugs com os quais os clientes se importam mais
Escola Ágil: usa o teste para provar que o desenvolvimento está completo. Enfatiza o teste automatizado
Sobre os testes sem documentação, são a favor:
Escola baseada em Contexto: "Faça o que puder para ser útil. Faça perguntas se necessário. Desencave especificações escondidas."
Escola Ágil: "Conversas são mais importantes que documentação"
E são contra:
Escola Analítica: "É impossível"
Escola Padrão: "Algum tipo de documentação é necessária"
Escola da Qualidade: "Force os desenvolvedores a seguir o processo"
Como cada escola vive um contexto e analisa o teste de acordo com os seus cenários, cada uma expressa uma visão diferente da possibilidade de testar sem documentação. Na visão geral dos participantes da discussão, testar sem documentação não é impossível, mas essa abordagem também não foi defendida como a melhor prática. A comunidade do DFTestes parece ter uma tendência muito próxima a da Escola baseada em Contexto, entendendo que não devemos olhar as nossas dificuldades de documentação como muros intransponíveis, mas como empecilhos que devem ser vencidos.
4. Reflexões da Mesa Redonda
"À medida que os sistemas se tornam mais complexos, os riscos se tornam maiores, chegando ao ponto no qual ninguém conhece o que há no sistema. Isto é ruim não só para o teste, mas também para todas as fases anteriores do desenvolvimento.
Falando de casos de uso ou similares, um dos problemas comuns de quem não tem essa documentação é o de não saber o que testar. Recentemente fiz uma análise de cobertura de código em um programa de pedidos e concluí que ao incluir um pedido neste sistema com o máximo de opções que consegui informar, não cobri nem 20% do código. Se você não tem nada para consultar, como testar os outros 80% de forma eficiente? Agora imaginem se este programa estivesse 60% documentado com casos de uso e casos de teste. Já seria uma garantia bem maior.
Outro problema é o de não saber o que alterar. Recentemente em um projeto foi esquecido de alterar um programa, e só esse programa gerou mais estresse que todas as outras alterações juntas porque estava dando problema lá no cliente. Sem documentação, não há rastreabilidade." [Ismael Munchen]
Na colocação do Ismael conclui-se que:
1. Falta de documentação pode prejudicar a cobertura dos testes
2. Falta de documentação implica em falta de rastreabilidade e aumento dos riscos nas manutenções do sistema
A visão do Marcelo Andrade complementa o primeiro cenário do Ismael:
"Claro que não dá para testar tirando conclusões sobre regras de negócio da própria cabeça do testador. Neste caso, se a informação está disponível (com o cliente ou com quem quer que seja) é ela que deve ser buscada."
Então, na falta de uma documentação, caso haja alguma outra fonte de conhecimento sobre os requisitos, ela viabiliza os testes e também aumenta a sua cobertura. Essa opinião também foi expressa pela Andrea Cruz quando ela fala que "testar sem documentação é possível, porém podem existir em determinados sistemas requisitos implícitos importantes que podem não ser cobertos pelo teste."
Existe sem dúvida um risco na falta de documentação. Para ser bem sucedido, o Analista de Teste precisa contar com alguma outra fonte de informação, ou a sua cobertura poderá ser seriamente prejudicada.
Segundo Daniel Goettenauer, "o beneficio da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existem muitas mudanças.
[...] dependendo do tamanho do projeto de teste a documentação poderia ser tratada de forma mais simples (documentos básicos) ou complexa (todos os documentos). Dessa forma não teríamos projetos desenvolvidos em 16 horas e testados em 72 horas por conta do volume de documentação."
Ter algum nível de documentação é mesmo importante, entretanto o que define sua necessidade? Uma documentação necessária é aquela que é consultada e mantida, que serve de apoio para o time ou, não se encaixando em nenhum desses objetivos, ela se torna necessária apenas se for uma requisição do cliente. Jeffries, 2001 expõe em seu blog esse mesmo ponto quando fala que "você pode precisar de um UML bem formatado para o seu projeto, ou você pode precisar imprimir o Javadoc quando distribuir o seu código para outros, ou você pode precisar documentar os requisitos para o gerenciamento ou como parte de um contrato. Se e quando você realmente precisar dessas documentações, você deve realmente tê-las." Se elas não forem realmente necessárias apenas demandam tempo da equipe e nem sempre são mantidas adequadamente.
Um sem número de documentos que são criados no início do projeto e não sofrem mais atualizações é uma realidade em muitos projetos. De acordo com o Shmuel, "uma documentação desatualizada é menos útil, mas ainda pode ser usada da mesma maneira. Mas essa ajuda não é um pré-requisito necessário, e podemos testar mesmo sem tê-la. Por meio de abstrações e inferências, é possível aprender sobre o programa de várias outras maneiras, durante os testes, durante conversas, durante as discussões sobre bugs etc.”
Essa opinião está alinhada com uma pesquisa do IEEE, 2003 em que entrevistas com engenheiros de software revelaram as seguintes opiniões sobre documentação:
"- Documento de arquitetura e outras documentações abstratas são freqüentemente válidos ou ao menos provêem um guia histórico que pode ser útil para manutenção.
- Documentações de todos os tipos freqüentemente estão desatualizadas
- Uma fração considerável da documentação não é confiável. "
O Felipe da Silva trouxe um ponto diferente sobre a necessidade e assinalou outro uso dado à documentação fora o projeto de testes que é o de contrato. É comum utilizarmos uma documentação e a aprovação do cliente como um contrato ou parte dele na definição de escopo e base para cronograma. Segundo Felipe, "na maioria dos casos além de brigarmos para querer ter um sistema testável por qualquer um, em determinados processos de engenharia de software também brigamos porque queremos ter um documento como "defesa" contra a insatisfação do cliente. É aquele problema que se você não documenta, o cliente não assina, se ele não assina, não existe um registro que ele havia dito que era aquilo que ele queria, correndo o risco do cliente reclamar e ter melhorias no sistema sem pagar por elas nem ajustar cronograma e etc."
5. Conclusão
As opiniões expostas na Mesa Redonda levaram a um entendimento de que a documentação pode não ser necessária, mas é importante. O tema é bastante abrangente e a cada participação na lista foi possível idealizar novos cenários para responder a mesma pergunta. E você? A que conclusão chegou após ler o que discutimos em mais uma edição da Mesa Redonda do DFTestes?
Participantes da Nona Mesa Redonda:
Fabrício, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe da Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.
Referências:
Much Ado About Nothing: Documentation
Ron Jeffries 2001
Schools of Software Testing
Bret Pettichord, 2007
How Software Engineers Use Documentation: The State of the Practice
Timothy C. Lethbridge, Janice Singer, Andrew Forward
IEEE Computer Society
2003
Exploratory Testing Explained
James Bach, 2003
1o Livro DFTestes
Pessoal,
tá saindo do forno o 1o. livro do DFTestes falando sobre as mesas redondas que ocorrem no grupo. Por enquanto a publicação foi feita no formato site, mas em breve será disponibilizado em pdf.
Está bem interessante e estamos procurando feedbacks.
Dêem uma olhada por lá e deixem sua contribuição :)
Acessem aqui.
tá saindo do forno o 1o. livro do DFTestes falando sobre as mesas redondas que ocorrem no grupo. Por enquanto a publicação foi feita no formato site, mas em breve será disponibilizado em pdf.
Está bem interessante e estamos procurando feedbacks.
Dêem uma olhada por lá e deixem sua contribuição :)
Acessem aqui.
Assinar:
Postagens (Atom)