The Bug Bang Theory

(No Ratings Yet)

 Loading ...

Acabamos de ganhar mais uma ótima referência sobre Segurança de Dados.Uma nova revista para o público de qualidade de software e serviços de Tecnologia da Informação, a Security Acts http://www.securityacts.com/.

A revista é online e totalmente gratuita, é uma nova revista do José Días que já publica a revista muito conceituada na área de Teste de Software, a Revista Testing Experience http://www.testingexperience.com/.

A nova revista trata de assuntos relacionados a todos os aspectos de segurança em TI e não somente na produção de software. Os assuntos variam de segurança dos equipamentos e recursos até segurança em linhas de código, mas observei que a maior partes dos artigos fazem parte diretamente a atividades de desenvolvimento e teste de software.

Gostaria de ressaltar um artigo publicado na revista pelo nosso grande pesquisador Rex Black. O artigo que ele escreveu para a primeira edição da revista Security Acts, “A Risk-Based Approach to Improving Software Security” (Uma abordagem baseada em risco para melhorar a segurança do software) onde ele descreve sete passos para ajudar a manter, monitorar e controlar os riscos de segurança enquanto o software está em tempo de desenvolvimento.

Fica minha dica para uma boa leitura sobre segurança, para manter-se atualizado e para conhecer o mercado internacional no que diz respeito a uma das principais (se não a principal) preocupação das maiores empresas de todas as áreas e seguimentos no mundo “A Segurança da Informação”.

Na primeira edição temos os seguintes artigos:
AJAX makes applications more difficult to secure
by Manu Cohen

An Overview of Software Supply Chain Integrity
by Paul Kurtz

The Science of Secure Software
by Prof. Dr. Sachar Paulus

Practical Application Security
by Manu Cohen

International Secure Software Engineering Council (ISSECO)
by Petra Barzin

The Liability of Software Producers and Testers
by Julia Hilterscheid

The Human Face of Security – #1
by Mike Murray

Software Supply Chain Integrity in SAP Applications
by Sebastian Schinzel, Gunter Bitz, Andreas Wiegenstein, Markus Schumacher & Frederik Weidemann

Business Logic Security Testing and Fraud
by James Christie

A Risk-Based Approach to Improving Software Security
by Rex Black

Demystifying Web Application Security Landscape
by Mandeep Khera

Security Testing by Methodology: the OSSTMM
by Simon Wepfer & Pete Herzog

Application Security Fundamentals
by Joel Scambray

How to conduct basic information security audits?
by Nadica Hrgarek

Boa leitura

(No Ratings Yet)

 Loading ...

Publicação original em: http://www.bstqb.org.br/?q=node/57

Em março de 2010 o Brasil sediará o encontro do Conselho do ISTQB (International Software Qualifications Board). Esse encontro contará com a presença dos Conselhos nacionais de cada país, onde o ISTQB é representado. Estarão presentes diversos nomes de destaque da área de testes de software, colocando o Brasil em foco. Será na cidade do Rio de Janeiro, no dia 19 de março. Essa é a primeira oportunidade do Brasil em sediar esse evento internacional, tendo disputado essa oportunidade com outros países.

Em conjunto com a reunião do ISTQB, teremos um evento aberto em São Paulo, com duração de dois dias e será voltado a área testes, contando com a participação ativa do Conselho brasileiro BSTQB. Esse evento terá a junção do público nacional e internacional, trazendo discussões atuais e relevantes sobre o tema ao nosso mercado. Diversos participantes do encontro do ISTQB estarão presentes nesse congresso, trazendo uma oportunidade única para o mercado brasileiro. Dados sobre esse evento serão divulgados pelo BSTQB.

O ISTQB é um Conselho internacional formado em 2002 e composto por representantes de mais de 40 países, os denominados conselhos membros. O número de Conselhos membros tem crescido a cada ano, demonstrando a importância e a abrangência do Conselho internacional. Esse Conselho é dedicado à disciplina de testes de software, e promove o profissionalismo na área através de um programa de certificações profissionais. O BSTQB é o Conselho membro brasileiro, formado em 2006 e com crescente aderência dos profissionais à suas atividades. Atualmente são mais de 120.000 certificados ISTQB no mundo, e mais de 500 certificados no Brasil, sendo a maior certificadora em testes de software no Brasil e no mundo. O ISTQB e seus Conselhos membros são entidades sem fins lucrativos. Essa estrutura traz transparência para suas ações, justificando seu sucesso e reconhecimento no mercado.

Três vezes ao ano, o ISTQB reúne seus membros dos Conselhos em uma reunião, o General Assembly Meeting, com diversas metas:

- Divulgação do status do programa de certificação;
- Tomada de decisões em relação a atividades do Conselho;
- Realização de votações relativas ao Conselho diretor; corpo de conhecimento, grupos de trabalhos, entre outros,
- Discussão e votação em relação à entrada de novos Conselhos membros.

Essa reunião tem uma grande importância para o encaminhamento das atividades do Conselho internacional. Também é de grande importância para o país que a sedia, visto que muitos nomes de destaque da área comparecem, contribuem com a comunidade, além de ser uma oportunidade de negócios e contatos.

(No Ratings Yet)

 Loading ...

Por Mário Pereira

O Banco Nacional de Desenvolvimento Econômico e Social (BNDES) elevou de R$ 1 bilhão para R$ 5 bilhões o orçamento do seu Programa para o Desenvolvimento da Indústria Nacional de Software e Serviços de Tecnologia da Informação (Prosoft), que desde sua criação conta com a parceria da SOFTEX. O programa é voltado ao financiamento de empresas de tecnologia da informação e operações de capital de risco.

O aumento é resultado do crescimento da demanda por projetos de investimento na área de informática e tecnologia da informação. Somente no período janeiro a julho deste ano, a carteira de projetos em análise no BNDES Prosoft já totaliza R$ 1,4 bilhão. Esse volume de recursos corresponde à metade da carteira de projetos do Prosoft no acumulado dos três últimos anos, até julho de 2009, que é da ordem de R$ 2,8 bilhões.

Maurício Neves, chefe do Departamento de Indústria Eletrônica do BNDES, destaca que o Prosoft, além de impulsionar o desenvolvimento de pequenas e médias empresas brasileiras de TI, também contribui decisivamente para a melhoria do processo de gestão.

Para Carlos Alberto Leitão, gerente de funding da SOFTEX, “esse aumento de recursos reflete diretamente uma maior visibilidade do programa, que também passou a interessar o universo das grandes empresas”. De acordo com Carlos Alberto, a SOFTEX, como parceira desta iniciativa, tem tido extremo cuidado em apoiar as empresas para a elaboração do seu pedido de crédito. “Queremos que o programa continue contribuindo de forma decisiva não só para uma maior produtividade e competitividade do setor brasileiro de TI, como amplie a sua atuação como um importante fator para a geração de empregos e para o aumento de nossas exportações”.

Ao longo de todo o ano passado, a SOFTEX atendeu a mais de 100 empresas interessadas em acessar o Prosoft e encaminhou para avaliação final do banco um total de 35 planos de negócios que, juntos, pleitearam um total de R$ 1,2 bilhão em recursos.

“Com a reformulação ocorrida em 2007, a natureza do apoio prestado pela SOFTEX às companhias nacionais, antes centrado somente no  Prosoft-Empresa foi ampliado, pois começamos a trabalhar também com o Prosoft-Exportação e o Prosoft-Comercialização”, destaca Arnaldo Bacha, vice-presidente executivo da SOFTEX. Dessa forma, acrescenta Bacha, a SOFTEX passou a orientar também o encaminhamento de planos de negócios de grandes empresas e a trabalhar com operações mais complexas, muitas delas envolvendo processos de fusões e aquisições. Um exemplo foi o caso da fusão Totvus e Datasul.

O BNDES Prosoft foi criado em 1999, tem prazo de vigência até 31 de julho de 2012 e é importante ferramenta da Política de Desenvolvimento Produtivo do Governo Federal.

(No Ratings Yet)

 Loading ...

A 2ª edição da Conferência trará um panorama atual da Qualidade de Software no Brasil, com relatos de empresas que obtiveram excelentes resultados na implantação de programas de melhorias de processos e suas perspectivas para os próximos anos.

Data:  11 e 12 de Novembro de 2009
Horário:  das 8:30 às 18:00h
Local: Universidade São Judas Tadeu (Unidade Mooca)
Rua Taquari, 546 – Auditório do Térreo
São Paulo – SP.

Venha participar das palestras e debater com especialistas da Engenharia e Qualidade de Software assuntos que podem  interessar diretamente à sua empresa.

Agenda Provisória:

11 de novembro (quarta-feira)
- Cerimônia de Abertura
- Ações e atividades do MCT, Resultados e Planos para o futuro do mercado de TI
- MPS.BR – Resultados e Perspectivas
- Programas de melhorias de processo em empresas de TIC
- Implementação integrada CMMI nível 3 e MPS.BR nível C
- Utilizando metodologias ágeis em uma empresa CMMI nível 5
- A importância do fator humano na definição e manutenção de processos

12 de novembro (quinta-feira)
- Estimativas de Software
- TMMI – Test Maturity Model Integration
- Qualidade Arquitetural em aplicações em Java
- Implementação de melhores práticas de ITIL em grupos de empresas
- CMMI v1.3 e CMMI for Services
- Compatibilidade entre metodologias ágeis e CMMI/MPS.BR
- Controle Estatístico de Processos de desenvolvimento de software

Investimento*:
- Participação nos 2 dias: R$ 180,00 por pessoa
- Participação somente em 1 dia: R$ 110,00 por pessoa

Descontos para 2 ou mais inscrições da mesma empresa
- Participação nos 2 dias: R$ 160,00 por pessoa
- Participação somente em 1 dia: R$ 90,00 por pessoa
*valores válidos somente para inscrições realizadas até 23/10/2009.

Inscrições e Informações:
comunicados@asrconsultoria.com.br
(11) 2629-0610
www.asrconsultoria.com.br

(No Ratings Yet)

 Loading ...

Um dia. Uma causa. Milhares de vozes.
Hoje é dia 15 de Outubro de 2009, o Blog Action Day.

Tema de 2009 – Climate Changes (Mudanças Climáticas)

A definição do Blog Action Day está disponível no site Oficial: http://www.blogactionday.org/

Blog Action Day is an annual event held every October 15 that unites the world’s bloggers in posting about the same issue on the same day with the aim of sparking discussion around an issue of global importance. Blog Action Day 2009 will be one of the largest-ever social change events on the web.

Pesquisei um pouco sobre mudanças climaticas e computação e tentei achar alguma relação entre os dois. Encontrei alguns artigos interessantes e até um pouco assustadores, mas poucos que pudessem fazer uma relação interessante a publicação de um post para o Blog Action Day sem quebrar o clima “nerd” de computação do meu blog.

Então dois artigos foram mais interessantes: 

1 – Novo supercomputador simulará mudanças climáticas globais no Brasil
http://idgnow.uol.com.br/computacao_corporativa/2008/07/15/fapesp-e-finep-investem-em-supercomputador-para-simulacoes-climaticas/
Achei super interessante o Brasil investir dinheiro em computação para realizar as previsões do clima. Isso mostra que o Brasil “já” enxerga que a computação pode ajudar a resolver, ou pelo menos a orientar as tomadas de decisão no meio ambiente.
Essa publicação é de 2008, e pesquisei um pouco mas não encontrei nada novo. Será que saiu do papel?

2 – Computing Climate Change: Just the Tip of the Iceberg
http://www.scientificcomputing.com/article-hpc-Computing-Climate-Change-Just-the-Tip-of-the-Iceberg-063009.aspx
Desenvolvimento de uma plataforma publica (hardware e software) disponível em um portal na WEB para quem quiser “saber” o terrível futuro que nos aguarda.
O primeiro para a mudança na minha opnião, é saber que precisa mudar. Um sistema com esse potencial com certeza ajuda  a população a pensar mais sobre como nossos dias de amanhã serão,  ajuda os pesquisadores de países com menos recursos como alguns dos países da África a realizar as suas pesquisas e é claro, mais uma área em que a computação avança e mostra sua colaboração para os “dias de amanhã”.

Espero que essa pequena contribuição ajude no nosso Blog Action Day’09, com o espírito do “Um dia. Uma causa. Milhares de Vozes”. #BAD09

(2 votes, average: 10,00 out of 10)

 Loading ...

Meio estranho o título para um blog de tecnologia não?

Mas o ET que estou falando não é o nosso popular amigo de dedo brilhante, nem os assustadores (pelo menos eram para ser) monstros de Hollywood.

Estou falando de um papel que muitas vezes não é explícito nos nossos processos e que se fosse mais explícito e mais valorizado, nossos processos de produção de software seria muito beneficiado.

O papel de Engenheiro de Testes ou Arquiteto de Teste é um papel no mínimo recomendado para que um projeto de produção de software seja entregue com padrões satisfatórios de qualidade.

A necessidade desse papel está diretamente vinculada a complexidade dos requisitos, especialmente dos requisitos não funcionais e do ambiente do sistema.

Se pesquisarmos no glossário do ISTQB, não temos uma declaração explicita para esse papel, nem mesmo nos Syllabus, mas o RUP descreve um pouco desse papel com o nome de Designer de Teste com a seguinte definição:
Designer de Teste: Essa função é responsável por definir a abordagem de teste e assegurar sua correta implementação. Isso inclui identificar as técnicas, ferramentas e diretrizes apropriadas para implementar os testes necessários e fornecer orientação sobre os correspondentes requisitos de recursos para o esforço de teste.Em algumas culturas em desenvolvimento, essa função é referida como Arquiteto de Teste, Arquiteto de Automatização de Teste ou Especialista em Automatização de Teste.

Mas para o RUP, esse profissional ainda está muito vinculado a automação de teste, o que de certa forma é verdade se levarmos em consideração que a maioria dos testes de requisitos não funcionais estão ligados a automação.

Mas e se pensarmos no papel de Engenheiro/Arquiteto de Testes como uma versão do ponto de vista de Controle de Qualidade do arquiteto de Software?

A definição do Arquiteto de Software segundo o RUP é:
->Essa função orienta o desenvolvimento da arquitetura de software do sistema, que inclui promoção e criação de suporte para as principais decisões técnicas que limitam o design e a implementação gerais para o projeto.

Logo o nosso Arquiteto de Testes seria um profissional responsável por boa parte das decisões técnicas do como os testes devem ser realizados. O profissional responsável por escolher as ferramentas mais adequadas, treinar a equipe que irá executar e desenvolver os casos de teste, ajudar na definição de uma massa de teste, selecionar o formato das suítes de teste, definir o nível de detalhamento dos casos de teste, ajudar a definir a complexidade e prioridade de cada caso de teste, entre outras atribuições.

Quem se habilita a ser um Engenheiro de Testes? Ou melhor, o que é preciso para ser um BOM engenheiro de testes?

•O Engenheiro de Teste assim como o Arquiteto de Software é um profissional que está acima de qualquer Tecnologia, Metodologia ou Suíte de Ferramentas. não tem “religião”. Deve ser neutro, calculista e possuir vasta experiência em todas essas verticais. Um profissional que domine bem a poderosa suíte de ferramentas de engenharia de software da IBM Rational não é simplesmente por esse fator um profissional habilitado em testes de performance, modelagem de dados, engenharia de requisitos e etc. O mesmo se aplica a um profissional que acredita que uma metodologia, seja ela RUP, SCRUM ou qualquer outra, é a melhor em todos as ocasiões. Para um Engenheiro de Testes não existe o melhor universal, existem opções que podem ser combinadas para cada modelo de projeto. Ele acredita na idéia de um projeto ser uma entidade viva, com características próprias, as vezes únicas, que devem ser estudadas, entendidas e suas soluções arquiteturadas e aprovadas por provas de conceitos.

•O Engenheiro de Testes tem vivencia em muitos projetos, dos mais diferentes tipos, de “simples” sistemas de padaria, catraca e controle de acesso a portais eletrônicos de compra, sistemas de bilhetagem e controladores de vôo por exemplo.

•O Engenheiro de Teste é um estudante assíduo das novas tecnologias, de TODAS as disciplinas de engenharia de software, do mercado de fornecedores de ferramentas de teste dos mais diversos e sua pedra angular é a Engenharia de Software.

•O Arquiteto de Testes programa tão bem quanto um desenvolvedor e tem uma excelente capacidade de compreensão de requisitos, assim como possui uma ótima capacidade de identificar requisitos não-funcionais, compreende-los e examinar as soluções propostas de forma crítica e analítica.

•O Engenheiro de Testes é um profissional proativo, crítico por natureza, visionário e ousado. A missão dele deve ser a integridade da qualidade para o SISTEMA e não somente para o SOFTWARE.

•O Engenheiro de Testes é um profissional criativo e oportunista, vislumbra soluções inteligentes em teste para cada tipo diferente de produto de software.

•Deve ter espírito de liderança e ter uma excelente desenvoltura ao lidar com pessoas, ser organizado, metódico e sistemático.

Um artigo que achei muito interessante tratando da relação entre Arquiteto e Líder técnico é o artigo The Seven Leg Sheep do Gerrit Muller, que descreve as macro e micro categorias de características técnicas que um profissional nesses papeis possui. Uma versão crítica em português muito boa está disponível em http://blog.arkhi.com.br/2008/11/03/a-ovelha-de-sete-pernas/.

Acredito que a mesma relação feita nesse artigo também é valida para Engenheiro de Teste e Coordenador de Teste, como na figura abaixo que representa uma relação Arquiteto de Software X Líder Técnico.

Quanto mais uma empresa investe em teste, mais ela investe em qualidade, não só do produto, mas também das suas pessoas, dos seus processos, consequentemente na qualidade da sua imagem e dos seus clientes. Uma equipe de teste de software pode trazer ganhos fantásticos, conhecimento partilhado, melhoria continua de processos, novas formas de fazer atividades, novas ferramentas etc. Após uma quantidade X de investimento em testes Funcionais, uma empresa de médio porte já começa a ter projetos que exigem novos padrões de qualidade e cada vez mais os requisitos não funcionais tem sido fator de falha em excelentes projetos de software com poucos “bugs”.

Engenharia de Teste de Software já existe, implicitamente em todos os projetos. A questão é que quando tornamos isso explicito ganhamos uma nova forma de garantir que os requisitos como um todo sejam atendidos, temos um processo de teste sob medida (ou pelo menos mais realista) para o projeto e consequentemente temos um produto com uma qualidade mais próxima do esperado.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(No Ratings Yet)

 Loading ...

Comçando uma série de artigos onde vou publicar periodicamente os defeitos que viraram notícia nos principais meios de comunuicação.

Pretendo publicar um link, titulo e um comentário pessoal sobre cada defeito e quem sabe arristar um palpite sobre como poderia ser evitado.

•Bug no Mac OS X 10.6 Snow Leopard pode apagar contas de usuários (macmagazine)

http://macmagazine.uol.com.br/2009/10/09/bug-no-mac-os-x-10-6-snow-leopard-pode-apagar-contas-de-usuarios/

-Esse defeito, como citado no próprio blog da Apple, é um defeito crítico, e fiquei realmente espantado com ele. Achei um erro muito “Iniciante”, tanto para ser cometido e ainda mais para não ser pego.
Será que não existia um “casinho de teste” com o titulo “Guest User Login”?
Ou será que teste de regressão não é uma prática comum nos laboratórios/fábricas de teste da Apple? Na minha opinião, acho que ouve uma falha de processo e alguem que devia ter executado algun dos casos de teste que cobria essa regra acabou por não executar.

De qualquer forma todas as empresas estão sucetiveis a falhas, mesmo que grosseiras como essa, mas a Apple é pelo menos para mim um exemplo de perfeccionismo, qualidade e inovação, por isso acho que todos vamos convir que uma falha como essa não afeta em nada a imagem da Apple (Pelo menos pra nós que não tivemos nossos dados deletados).

•Falha da MS elimina dados de handsets (INFO)

http://info.abril.com.br/noticias/tecnologia-pessoal/falha-da-ms-elimina-dados-de-handsets-12102009-13.shl

-Acho que o primeiro teste negativo que eu faria seria exatamente esse.

Ao testar aparelhos móveis, dispositivos de bilhetagem, GPSs entre outros aparelhos que tem vida dependente de carga e recarga devem ter atenção especial para casos de pane, perda de energia ou desligamentos forçados.

Motivos que me levam a crer que esse sistema não passou por um teste realmente eficaz:

1 – Como disse, primeiro teste negatívo que eu faria;
2 – Testar mudança de chip;
3 – Testar mudança de bateria;
4 – Testar esgotamento de bateria;
5 – Testar interrupção de carga;
6 – Testar ligar com pouca carga;
7 – So on. . .
Mais uma infinidade de casos que tem um passo em comum – Interrupção da força.

O outro motivo é que não é um caso especifico, mas TODAS as interrúpções de carga, sejam elas naturais ou anomalias tem o mesmo resultado.

Esse realmente é um defeito lamentável, ainda mais vindo de uma das maiores empresas de TI.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(1 votes, average: 10,00 out of 10)

 Loading ...

Apesar de trabalhar muito com a “mega suíte” de ferramentas de engenharia de software da IBM Rational, acredito que o open-source TestLink é uma ferramenta sob medida para nós analistas de teste coordenarmos os nossos projetos.

O TestLink tem recursos muito interessantes e pouquíssimos problemas e inconformidades com os padrões e nomenclatura do ISTQB .

Bom, como toda ferramenta, o TestLink não é perfeito, e possui alguns problemas pontuais que podem ser corrigidos com menos ou mais esforço, um pouco de dedicação e conhecimento básico sobre PHP e MySQL.

Na empresa onde eu trabalho, estou ajudando a implantar e customizar o TestLink e durante essa customização um dos problemas foi identificado.

Não existe uma maneira de exibir os requisitos, escopo, nos documentos “Plano de teste” e “Relatório de teste”, apenas o seu título e identificação. Um dos nossos clientes tem uma exigência contratual que obriga a presença desse conteúdo nos casos de teste, o que tornaria o TestLink uma ferramenta incompleta para os projetos desse cliente.

Como podemos ver abaixo, as opções de impressão e o relatório exibido:

Figura1-Painel de opções para impressão do Plano de teste

Alem disse problema , outra coisa que eu sempre me questionei porque não funcionava muito bem no TestLink era a formatação do conteúdo da precondição, passos e resultados esperados. Mesmo cadastrando com cuidado, colocando uma quebra de linha entre um e outro, o sistema sempre exibi tudo na mesma linha.

Com esses dois problemas para resolver, estudei um pouco do código do TestLink e da documentação presente no próprio manual e realizei as duas correções:

A primeira coisa a fazer foi pensar em como isso seria implementado. Substituir a opção atual? Criar novos relatóriospara preservar a opção anterior?

Eram inúmeras opções, porem dentre as várias opções, decidi por manter configuração original do sistema, e adicionar um checkbox novo, com a funcionalidade adicional.

Dessa forma podemos ver:

Figura2-Opção Corpo dos requisitos do caso de teste

Com a opção acima, o sistema exibe o corpo do requisito abaixo de cada título, caso não seja marcada o sistema apenas exibe o ID e o Titulo como nas versões que estamos acostumados.

Exemplo:

Antes:

Depois:

No meu caso, a opção de quebra de linha é permanente, dessa forma apliquei a todos os projetos e a opção de exibir o corpo da regra está como opção na página de seleção das informações.

Implementando

Para implementar tive que modificar alguns arquivos do próprio TestLink, esses são:
…\testlink\locale\pt_BR\strings.txt
…\testlink\lib\results\printDocOptions.php
…\testlink\lib\results\printDocument.php
…\testlink\lib\results\resultsReqs.php
…\testlink\lib\function\requirement_mgr.class.php
…\testlink\lib\function\print.inc.php

Arquivo requirement_mgr.class.php:
Modificamos a Query selecionar o fild scope.

Arquivo printDocOptions.php:
Nesse arquivo incluímos a opção que aparecerá no menu:

Arquivo printDocument.php:
Nesse arquivos incluímos a opção no array de definição da impressão.

Arquivo resultsReqs.php:
Incluído para receber o valor do conteúdo do requisito.

Arquivo print.inc.php:
Aqui exibimos os valores em quebra de linha:

Aqui exibimos o conteúdo do requisito (scope):

Arquivo strings.txt:
Incluímos duas nova String chamadas: $TLS_opt_show_tc_body e $TLS_opt_show_tc_reqs_body

As modificações acima funcionam para todos os browsers (Crhome, FireFox, IE, safari etc) e para todas as formas de saída dos relatórios (Word, Writer, HTML etc).

Para facilitar a implementação segue abaixo o link de um arquivo .zip com todos os arquivos usados para essas implementação e já no formato da estrutura de pastas, basta extrair na raiz do seu Testlink e mandar sobescrever tudo.
Download: requirementBody

ATENÇÃO: Cuidado, se existir alguma customozação em algum desses documentos ela será perdida, e é altamente recomendável fazer backup de tudo antes de qualquer modificação. Caso não use o testlink em português terá que criar as strings no arquivo strings.txt do idioma utilizado.

Assim termina a implementação e a explicação sobre como implementar desse arteigo.

mas se quiser experimentar sem mudar nada no seu ambiente acesse:

HTTP://testlink.camiloribeiro.com

usuário: visitante
senha: visitante*2009

Obrigado por experimentar com responsabilidade!

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.