Projeto testa software para surdos que converte SMS em voz

Edital lançado nesta terça (28) busca 621 voluntários para avaliar programa. Aplicativo permite que deficiente auditivo possa se comunicar por telefone.

Um projeto está convocando 621 voluntários para testar um software que transforma mensagens de texto em voz e vice-versa, para que surdos possam se comunicar por telefone. Os interessados em participar deverão preencher os requisitos no edital, disponível neste link. O material, lançado nesta terça-feira (28), faz parte do projeto Nambiquara Audição Digital, desenvolvido pelo governo do estado.

"O programa tem um prazo de dois anos para conseguir os voluntários, para que a gente possa ajustar todos os defeitos do sistema, que já é usado experimentalmente por 50 surdos há mais de três anos, e assim o sistema poder ser lançado comercialmente", explicou o gestor de inovação da Secretaria de Ciência e Tecnologia, Alexandre Stamford.

O governo investiu R$ 320 mil para o desenvolvimento do software. Os selecionados irão receber um aparelho smartphone com o sistema implantado com tradutor de voz. Como o software permite que até 3 mil usuários participem simultaneamente, outros 2.379 deficientes auditivos que possuam aparelho compatível com o sistema operacional Android 2.2 ou superior também poderão participar do projeto, além dos 621 voluntários.

"O programa direciona ao um servidor, que recebe o texto do surdo e transforma a mensagem em voz", explicou Stamford. A pessoa do outro lado da linha responde e o sistema converte a voz dela em mensagem de texto, para que o surdo possa entender.

O gestor da Secretaria de Ciência e Tecnologia avalia acredita que, pelos teste anteriores realizados pelos deficientes auditivos, o principal desafio do sistema é a transformação fiel da voz em mensagem de texto. "O problema é calibrar o tradutor de voz para texto, pois cada um tem uma maneira de falar; há pessoas que possuem voz fina, outras têm voz grossa, e isso dificulta no reconhecimento de padrões", argumentou.

A entrega dos documentos dos interessados em participar do projeto deve ser feita até 15 dias úteis depois do lançamento do edital, à Comissão Especial de Seleção e Credenciamento, na Superintendência Estadual de Apoio à Pessoa com Deficiência, na Rua João Ivo da Silva nº 342, Madalena, Zona Oeste do Recife, das 9h às 17h. O programa é desenvolvido em parceria com a Secretaria de Desenvolvimento Social e Direitos Humanos.

Fonte: http://g1.globo.com/pernambuco/noticia/2013/05/em-pe-projeto-testa-software-para-surdos-que-converte-sms-em-voz.html

Read More

Oportunidade de Emprego - C.E.S.A.R - Recife (PE)

O C.E.S.A.R está com 11 vagas para Engenheiro de Testes em aberto. Vagas essas para trabalhar em Recife-PE.

O C.E.S.A.R é um dos principais provedores de soluções de Tecnologias de Informação e Comunicação (TICs) do mercado brasileiro; instituto de inovação ganhador dos prêmios FINEP de Mais Inovadora Instituição de Pesquisa do Brasil (2010 e 2004), Empresas Mais Inovadoras (Época Negócios, 2009) e Info200 de Melhor empresa de serviços de software (Revista Info, 2005).

O C.E.S.A.R também se capacita para gerar novos empreendimentos de TICs em associação com investidores financeiros e estratégicos, criando oportunidades concretas de criação de novos negócios para todos os seus colaboradores.

Veja abaixo detalhes sobre a vaga:

Engenheiro de Testes - 11 vagas

Requisitos Necessários:
- Superior Completo em Ciência da Computação, Engenharia ou Áreas Afins;
- Sólido conhecimento na área de testes;
- Experiência em análise de requisitos;
- Conhecimento em linguagens de programação;
- Conhecimento no uso de ferramentas de automação de testes;
- Inglês Avançado.

Requisitos Desejáveis:
- Conhecimento em testes exploratórios;
- Métricas de testes;
- Experiência em automação de testes.

Principais responsabilidades:
- Análise e interpretação de requisitos;
- Planejamento de testes;
- Escrita de casos de testes;
- Desenvolvimento de testes automáticos;
- Execução dos testes e análise de resultados;
- Uso de ferramentas de automação.

Salário:
- À combinar.

Para concorrer a essas vagas, cadastre-se no Banco de Currículos, acessando o site: http://curriculos.cesar.org.br/.

Informe na a opção/cargo: “Engenheiro de Testes”

Read More

Questão de Certificação - Dia 15

Bom dia pessoal,

Hoje é a nossa penúltima terça-feira antes da prova de Certificação CTFL, aplicada pelo BSTQB, que será no próximo dia 07 de junho.

Então temos que correr e continuar no ritmo de estudo para que possamos chegar preparados no dia da prova.

Na Questão de Certificação de hoje iremos estudar alguns tipos de ferramentas de auxílio de testes, que são utilizados pela equipe de testes e também por desenvolvedores.

Lembrando que essa questão foi retirada dos simulados, disponíveis para baixar em nosso blog, na área de “Download”.

Vamos lá......

S02Q21 - Dados os seguintes tipos de ferramenta, quais delas são, normalmente, usadas pelos desenvolvedores e quais por uma equipe de teste independente:

I. Análise estática

II. Testes de desempenho

III. Gestão de testes

IV. Análise dinâmica

V. Execução de testes

VI. Preparação dos dados do teste

                a) Desenvolvedores: I, IV e VI; equipe de teste: II, III e V

                b) Desenvolvedores: I e IV; equipe de teste: II, III, V e VI

                c) Desenvolvedores: I, II, III e IV; equipe de teste: V e VI

                d) Desenvolvedores: II, IV e VI; equipe de teste: I, III e V

                e) Desenvolvedores: I, III, IV e V; equipe de teste: II e VI

Comentários: Como já debatemos em questões anteriores, os testes de software deverão iniciar o mais cedo possível, mas os testes deverão ser exclusivamente executador pelos testadores? A melhor resposta é NÃO.

A equipe de desenvolvimento também tem um papel muito importante num processo de teste bem fundamentado. Muito das técnicas de testes de Caixa Branca são de responsabilidade dos desenvolvedores, pois quem melhor para conhecer o código do sistema do que eles.

Logo todos os testes que necessitam de analisar, executar, criar, alterar... o código do sistema, a prioridade de execução são dos desenvolvedores. Como por exemplo os testes Unitários, esses são um tipo de testes muito utilizados pelos desenvolvedores.

Mas agora iremos analisar as opções da questão para saber quais são de responsabilidade dos desenvolvedores ou testadores. Temos 6 tipos de ferramentas de testes, onde alguns são de responsabilidade de testadores e outras de desenvolvedores.

Iniciaremos com a o tipo I. Análise Estática, Análise estática de código é uma análise automatizada realizada por um ferramenta sem que seja preciso executar o programa a ser analisado. A ferramenta procura no código-fonte do aplicativo os locais que contém erros ou prováveis causas de erros no programa. Esses locais devem, posteriormente, ser verificados pelo programador, que vai decidir se o código será ou não corrigido. Os analisadores estáticos de código permitem aos desenvolvedores detectar diversos erros nos estágios iniciais do processo de desenvolvimento de um software. A metodologia de análise estática funciona, também, como uma forma de disciplinar os desenvolvedores.

O tipo II. Testes de desempenho, consiste em avaliar a capacidade, robustez e disponibilidade de uma aplicação, conforme a quantidade de conexões simultâneas, avaliando seu desempenho principalmente em alta carga de trabalho e considerando seu comportamento em circunstâncias normais. Normalmente ajudar a identificar gargalos nos sistema, deficiências no software, além disso ajuda a estimar uma configuração de hardware para alcance dos desempenhos utilizados nos testes. As várias ferramentas para automatizar os testes de desempenho, onde elas são de extrema importância devido as dificuldades de se chegar aos limites dos software, executando scripts manuais. Essas ferramentas são de responsabilidade da Equipe de Teste.

O tipo III. Gestão de testes, geralmente desempenhada pelos gestores da equipe de Testes, tem como responsabilidade de gerencia todo o processo de testes (planejamento, implementação, execução, análise e gestão,...). Essas ferramentas são importantes para auxiliar na definição de requisitos de testes, desenvolvimento de Planos de Testes, Planejamento dos testes, registros de execução manuais e automáticos dos testes, registro de defeitos encontrados, associar os documentos aos testes, análise e execução dos resultados.

O tipo IV. Análise dinâmica, A utilização da análise estática durante o desenvolvimento e da análise dinâmica durante os testes permite que as equipas de desenvolvimento possam melhorar significativamente a qualidade do código e obter várias vantagens. As ferramentas de análise dinâmica deverão permitir demonstrar a inexistência de erros de memória e outros aspectos contratuais acordados com o cliente. A análise dinâmica permite reduzir significativamente a quantidade de tempo que os programadores gastam a resolver problemas de desempenho, algo que acaba por diminuir o ciclo de desenvolvimento. Tem sido demonstrado por vários estudos que um programador médio gasta cerca de cinco por cento do seu tempo na tarefa de optimizar o desempenho. A utilização destas ferramentas para identificar automaticamente os bugs permite que os especialistas em desenvolvimento gastem menos tempo no debugging de aplicações existentes e tenham mais tempo para escrever novo código.

O tipo V. Execução de testes, auxilia no momento da execução dos testes, demonstrando os documentos de requisitos sobre aquele testes, direcionando o testador nos passos a seguir para execução dos testes e também para coletar os resultados dos testes executados. Esse tipo de ferramenta reduz muito o tempo de execução manual, pois organiza e armazena todas as informações necessárias pelo testador para iniciar, executar e reportar os testes.

O tipo VI. Preparação dos dados do teste, conforme Syllabus esse tipo de ferramenta possibilita que os dados sejam selecionados dos bancos de dados existentes ou que sejam criados, gerados, manipulados e editados para uso no teste. De fundamental importância para os testadores reduzirem o tempo de execução de alguns testes, que necessitam de alguma característica inicial do testes. Exemplo um teste que necessite que a base de dados tenha 5000 registros, inserir manualmente esses registros no banco de dados é muito trabalhoso, então a utilização desse tipo de ferramenta irá inserir esses 5000 registros em segundos.

Com isso podemos finalizar nossa analise com a seguinte resposta:

As ferramentas utilizadas pelos desenvolvedores são as do tipo I e IV. As ferramentas utilizadas pela equipe de testes são as II, III, V e VI.

Logo a resposta correta é?

Resposta: “B”

Read More

Oportunidade de Emprego - TIVAPE

O nosso colaborador TIVAPE está com novos anúncios para vagas na área de Teste de Software. 

O TIVAPE é um portal de oportunidades de empregos para a área de TI, lá são divulgadas diariamente vagas para diversos cargos, mas todos voltados para a área de TI.

 Seguem requisitos para preenchimento de vaga de Analista de Testes em Recife-PE

Atividades a serem realizadas

• Analisar e desenvolver especificações para testes dos sistemas de média e alta complexidade,objetivando que o produto seja liberado dentro do prazo, visando garantir seu perfeito funcionamento, planejando e executando o processo de qualidade do produto sob sua responsabilidade.
• Realizar os testes, analisar os resultados e emitir parecer sobre o processo, conforme especificado nos cenários de testes.
• Preparar o ambiente de testes de acordo com os padrões estabelecidos.
• Elaborar e ministrar treinamentos internos de novas versões e assuntos específicos relacionados ao produto.
• Elaborar, atualizar e validar as documentações do sistema.
• Executar, analisar os resultados e emitir o parecer dos testes.

Empresa:

Confidencial

Salário:

À combinar

Interessados e deverão acessar o site http://www.tivape.com.br/anuncie_curriculo.php e cadastrar o currículo para participação da seleção.

Read More

Questão de Certificação - Dia 14

|Bom dia pessoal,

Chegamos em mais uma quinta-feira, dia de Questão de Certificação CTFL, estamos chegando perto do dia da prova, então vamos concentrar nossos esforços para chegarmos afiado para a prova.

Hoje iremos comentar uma questão a importância de se iniciar os testes de Software antecipadamente no ciclo de vida do software .

A questão abaixo foi retirado do Simulado 2, disponível para download em nosso site.

S02Q06 - Considere as seguintes afirmações sobre o teste de software iniciar, de forma antecipada no ciclo de vida do software:

           I. Iniciar o teste de software, de forma antecipada no ciclo de vida do software, pode prevenir a multiplicação de falhas

           II. Falhas encontradas, durante o planejamento antecipado de testes são mais cara para serem corrigidas

           III. Iniciar o teste de software de forma antecipada pode encontrar defeitos

           IV. Iniciar o teste de software de forma antecipada pode causar mudanças nos requisitos

            V. Iniciar o teste de software de forma antecipada requer mais esforços

                        a) I, III e IV são verdadeiras. II e V são falsas

                        b) III é verdadeira, I, II, IV e V são falsas

                        c) III e IV são verdadeiras. I, II e V são falsas

                        d) I, III, IV e V são verdadeiras, II é falsa

                        e) I e III são verdadeiras, II, IV e V são falsas

Comentários: No processo de desenvolvimento, testar o software torna-se uma atividade cara, pois necessita de investimento em mão de obra qualificada e especializada, ferramentas e ambientes apropriados para a execução de tal atividade, além do tempo do projeto que deve ser destinado a elaboração, execução e avaliação dos resultados.

Contudo, além de ser avaliar os benefícios de se testar um software, é importante ponderar também os prejuízos causados por não realizar testes. Quanto mais tarde os defeitos forem detectados, maior será o custo da sua correção. Portanto, defeitos encontrados na fase de produção de um software são muito mais caros de se corrigir do que aqueles que são identificados na fase de especificação.

Em 1979, Glenford Myers em seu livro ‘The Art of Software Testing’ (A arte de teste de software), já apresentava o conceito no qual quanto mais cedo descobrimos e corrigimos o erro, menor é o seu custo para o projeto. Esse custo em correção de BUGS cresce 10 vezes para cada estágio em que o projeto do software avança. 

 

Ao encontrar um defeito no fim do desenvolvimento, teremos que alocar mais pessoas para corrigir, se for o caso mudar a arquitetura do software, aumenta o tempo de entrega do software ao usuário, essa alteração poderá gerar efeitos colaterais em outras funcionalidades que estavam funcionando corretamente, poderá gerar insatisfação ao cliente.... Ou seja teremos prejuízo financeiro e também prejuízo na credibilidade do trabalho realizado.

Então ao se iniciar mais cedo os testes, podemos identificar defeitos no inicio do ciclo de desenvolvimento do software, facilitando manutenção do sistema, pois ele ainda se encontra em desenvolvimento. Como também testando desde do início podemos observar se os requisitos levantados e documentados realmente satisfazem a necessidade do cliente, evitando que um problema maior ocorra com o software, pois ele pode está sem nenhum defeito grave, mas não corresponde a necessidade do usuário sendo ele descartado.

Analisando agora as sentenças vamos encontrar a resposta certa da nossa questão.

A sentença I. Iniciar o teste de software, de forma antecipada no ciclo de vida do software, pode prevenir a multiplicação de falhas, é VERDADEIRA. Como sabemos um defeito pode gerar falha ou até mesmo encadear falhas múltiplas, logo se encontrarmos esse defeito no início evita que se gere falhar em lugares não planejados.

A sentença II. Falhas encontradas, durante o planejamento antecipado de testes são mais cara para serem corrigidas, é FALSA. Como vimos no gráfico de Myers, as falhas encontradas ficam mais caras para corrigir quanto mais tarde no ciclo de desenvolvimento. Dependendo de como o software foi desenvolvido, um defeito encontrado no final do ciclo poderá gerar até o cancelamento do mesmo.

A sentença III. Iniciar o teste de software de forma antecipada pode encontrar defeitos, é VERDADEIRA, pois encontrar defeitos é o principal função da execução antecipada dos testes.

A sentença IV. Iniciar o teste de software de forma antecipada pode causar mudanças nos requisitos, é VERDADEIRA. Como mencionado anteriormente, os testes antecipados poderá avaliar se os requisitos criados na fase de analise, realmente correspondem as necessidades do usuário. Assim sendo a mudança desse requisito não trará um custo muito alto para o software em desenvolvimento. Se o erro no requisito for encontrado após o desenvolvimento, pode ocorrer um custo muito mais elevado para mudança, se caso possível.

A sentença V. Iniciar o teste de software de forma antecipada requer mais esforços , é FALSA. Pois os testes irão sendo executados em paralelo ao ciclo de desenvolvimento. Seu planejamento é que seja executados os testes de acordo com a fase do desenvolvimento. Se os testes forem executados ao final do ciclo, ai sim teremos um esforço maior, pois teremos uma gama maior de testes para serem executados em um curto espaço de tempo.

Com isso temos que as sentenças I, III e IV são Verdadeiras e as II e V são Falsas.

Resposta: “A”

Espero que tenham gostado de mais uma Questão de Certificação CTFL, até a próxima semana pessoal.

Caso tenham alguma dúvida em alguma outra questão nos envie um e-mail que responderemos e publicaremos em nosso blog.

E-mail para envio: gutspb@gmail.com.br

Read More

Questão de Certificação - Dia 13

Bom dia pessoal,

Estamos na reta final para a o dia da prova de Certificação do BSTQB, então não vamos perder mais tempo e inicia a nossa Questão de Certificação CTFL de hoje.

Hoje iremos comentar uma questão sobre V-Model ou o Modelo V.

A questão abaixo foi retirado do Simulado 3, disponível para download em nosso site.

S03Q18 - Qual das alternativas é verdadeira quanto ao modelo V?

a) Ele afirma que os módulos são testados de acordo com requisitos dos usuários

b) Ele apenas abrange a fase de teste

c) Ele especifica as técnicas de teste a serem usadas

d) Ele inclui a verificação da modelagem

Comentários:

De forma resumida podemos dizer que o modelo em V  se preocupa em realizar testes  durante todo o ciclo de desenvolvimento com o objetivo de encontrar erros o mais cedo possível.

Este modelo introduz a criação de testes de dados e cenários de teste durante o ciclo de desenvolvimento do software e trabalha com diferentes níveis de testes como : Teste de unidade, Teste de integração , Teste de sistema e Teste de aceitação.

Basicamente o ciclo de desenvolvimento do modelo segue a seguinte seqüência:

No gráfico acima há dois termos que temos que ter clareza sobre sua definição:

A Verificação: "Estamos construindo certo o produto."-  É feita para garantir que as funcionalidades especificadas e definidas no DRS estão sendo implementadas no software. Esta atividade pode usar os seguintes métodos:

• Inspeções;
• Lista de verificação;
• Simulações;
• Prova de corretitude;

A validação - "Estamos construindo o produto certo" - Garante que o software que foi construído atende os requisitos do cliente. Para realizar essas atividades podemos utilizar:

• Teste de Caixa Preta ou Funcional;
• Teste de Caixa Branca ou Estrutural;
• Teste de Caixa Cinza;
• Análise baseada em erros;

Esses conhecimentos são suficientes para que possamos responder nossa questão.

Analisando as alternativas. A alternativa a) Ele afirma que os módulos são testados de acordo com requisitos dos usuários, é FALSA pelo fato de que o Modelo V afirma que os módulos são testados de acordo com a evolução do ciclo de desenvolvimento, e em cada ciclo há um artefato de saída, que serve para a entrada dos testes, nem sempre esse artefato será o documento de requisitos dos usuários. Exemplo, que para os testes de unidade, esse documento não terá tão importância.

A alternativa b) Ele apenas abrange a fase de teste, é FALSA, pois como é possível visualizar no gráfico acima, o Modelo V também abrange o ciclo de desenvolvimento do sistema.;

A alternativa c) Ele especifica as técnicas de teste a serem usadas, essa alternativa é uma pegadinha, mas ela é FALSA. O que o Modelo V especifica são os níveis de teste (Teste de unidade, Teste de integração , Teste de sistema e Teste de aceitação.), as técnicas são elaboradas de acordo com o nível do teste.

Logo a alternativa d) Ele inclui a verificação da modelagem, é VERDADEIRA. Pois como vimos a Verificação preza pelo “Se está sendo construindo certo”, então pelo modelo V a modelagem será Verificado.

Resposta: “D”

Espero que tenham gostado de mais uma Questão de Certificação CTFL, quinta-feira teremos mais.

Caso tenham alguma dúvida em alguma outra questão nos envie um e-mail que responderemos e publicaremos em nosso blog.

E-mail para envio: gutspb@gmail.com.br

Read More

Oportunidade de Emprego - Recife(PE)

Bom dia pessoal,


O projeto de parceria do CIn/UFPE com a Sansung S/A, está oferencendo uma vaga para Engenheiro de Teste de Sofware Junior, para trabalhar com tecnologia para dispositivos móveis


Veja abaixo as especificações dessa oportunidade:

ENGENHEIRO DE TESTE DE SOFTWARE JUNIOR

O que procura:

• Recém formados em Engenharia ou Ciência da Computação
• Conhecimento em técnica para criação de cenários e casos de testes de software
• Conhecimento em metogologias e ferramentas de testes
• Inglês intermediário
• Pessoas detalhitas, com habilidade investigativa e com capacidade de trabalhar sob pressão
• Conhecimento de orientação e eobjetos e desing patterns
• Desejável conhecimento em JAVA

Atividades:

• Efetuar testes funcionais e de qualidde de software de aplicações móveis, através de avaliação de requisitos, desenvolvimento e execução de cenários e casos de testes com report falhas/defeitos.

Oferecido:

• Contratação CLT (8h) com benefícios adicionais, como poliítica de investimento à pós-graduação e de capacitação técnica.

Interessados enviar o currículo com a pretensão salarial para rhsamsung@cin.ufpe.br

Prazo para envio até 21/05/2013

Read More

Problema de registro de DNS deixa sites da Globo.com instáveis

As grandes também falham.....

Uma falha no processo de gestāo de um dos domínios de propriedade das Organizações Globo fez com que páginas da Globo.com acessadas na manhã deste domingo, 19,  fossem redirecionadas incorretamente para outro endereço.

O problema  relacionado ao endereço propagado foi resolvido às 10h40. A Globo.com está em contato com todas as operadoras brasileiras de telecomunicação para agilizar o processo de atualização das páginas o mais rápido possível.

Read More

Questão de Certificação - Dia 12

Bom dia pessoal,

Infelizmente o dia de ontem foi muito corrido e não tive como publicar a Questão de Certificação CTFL da quinta-feira.

Mas excepcionalmente hoje daremos continuidade aos nossos estudos.

Hoje iremos comentar uma questão sobre write-box ou nossa famosa Caixa Branca.

A questão abaixo foi retirado do Simulado 6, disponível para download em nosso site.

S06Q15 - Quais das medidas abaixo poderiam ser usadas para avaliar a cobertura alcançada pelas técnicas de teste baseadas em estrutura (white-box)?

      V Resultados das decisões testadas

      W Partições testadas

      X Limites testados

      Y Condições ou multiplicas condições executadas

      Z Comandos executados

            a) V, W ou Y

            b) W, X ou Y

            c) V, Y ou Z

            d) W, X ou Z

Comentários: Vamos relembrar um pouco os conceitos e as Técnicas baseadas em estrutura ou caixa branca.

De acordo com o Syllabus, Teste de estrutura ou caixa-branca é baseado na estrutura do software ou sistema, como veremos nos exemplos que seguem abaixo:

• Nível de Componente: a estrutura é o próprio código, ex.: comandos, decisões e desvios.
• Nível de Integração: a estrutura pode ser uma árvore de chamadas (um diagrama em que um módulo chama outros módulos).
• Nível de Sistema: A estrutura pode ser uma estrutura de menu, processos de negócios ou estruturas das páginas Web.

Dentre as técnicas podemos destacas:

Testes e Cobertura de Sentença: avaliada pela porcentagem de sentenças executáveis que foram exercitadas por um conjunto de casos de testes.

Testes e Cobertura de Decisão: avaliada pela porcentagem dos resultados da decisão (por exemplo, as opções de “Verdadeiro” ou “Falso” de uma expressão condicional - IF) que foram exercitados em um conjunto de casos de teste.

Existem formas mais detalhadas de cobertura estrutural além da cobertura de decisão, por exemplo, cobertura de condições e cobertura de múltiplas condições.

O conceito de cobertura também pode ser aplicado a outros níveis de teste (teste de integração) no qual, as porcentagens de módulos, componentes ou classes são exercitadas por um conjunto de casos de teste.

Analisando a questão, ele quer saber quais das sentenças são fatores de avaliação para cobertura de testes baseados em estruturas.

Então vamos analisar as sentenças. V Resultados das decisões testadas, como vimos nas definições acima, uma das técnicas de Testes e cobertura baseado em estruturas é a Cobertura de Decisões, onde avalia os resultados dos testes que passaram pelas decisões (Verdadeiro ou Falso, de uma condicional, por exemplo). Logo podemos afirmar que avaliar os resultados dessas decisões é uma medida de avaliação.

W Partições testadas, em outras questões nós estudados uma técnica chamada Partição de Equivalência, onde utilizamos testes com valores válidos e inválidos para testar os valores de saída do sistema. Porém essa técnica é utilizada em Cobertura baseada em especificação, ou Caixa-Preta. Logo é falso afirmar que é uma medida de avaliação de cobertura de Estruturas.

X Limites testados, similar a sentença anterior os testar os limites de um sistema faz parte da técnica de Análise do Valor do Limite, técnica também utilizada em Cobertura baseada em Especificação (Caixa-Preta). Logo também é falso afirmar que é uma medida de avaliação de cobertura de Estruturas.

Apenas com essas analises já teriamos a resposta correta... Mas para critério de estudo vamos continuar as analises das sentenças.

Y Condições ou multiplicas condições executadas, como vimos acima uma outra forma de testar a cobertura de estrutura são as técnicas de condições e multiplicas condições. Logo podemos afirmar que avaliar os resultados dessas decisões é uma medida de avaliaçãoe cobertura baseada em estrutura..

Z Comandos executados, como sabermos, testes de caixa-branca (estrutura) são testes voltados para avaliar a parte de código do nosso sistema, utilizando as técnicas acima citadas, mas não podemos de deixar de falar na cobertura dos comando, onde iremos testar o sistema em nível de componentes. Logo podemos também afirmar que avaliar os resultados dessas decisões é uma medida de avaliação de cobertura baseada em estrutura.

Então temos: V(verdadeiro) – W(falso) - X(falso) - Y(verdadeiro) – Z(verdadeiro)

Resposta: “C”

Read More

Loja online Windows Phone Store falha em teste de melhores aplicativos

A Windows Phone Store falhou em um teste apresentado engenheiro, ex-gerente da Microsoft, que determina a relevância de um ecossistema. Hal Berenson, agora presidente do True Mountain Group, mostrou uma forma de avaliar o conteúdo de uma loja de aplicativos e a sua maturidade - método que difere das habituais métricas de quantidade.

"Eu vou tomar uma porção de categorias que são importantes para mim, e creio que para muitos outros, e verificar o quanto os aplicativos são bem representados no  Windows Phone Store", escreveu Berenson em seu blog pessoal.

Simplificando, Berenson selecionou três categorias - bancários, fundos mútuos e companhias aéreas - determinou os top 10 dos EUA em cada categoria e, em seguida, foi à procura de aplicações desses setores na Store.

Na semana passada, a Microsoft anunciou que a loja online passou a marca de 145 mil apps.

Enquanto Berenson usou sua própria metodologia para medir a app store, o mesmo processo pode ser usado com qualquer ecossistema de aplicativos, incluindo a Windows Store - canal de distribuição de aplicativos para Windows 8 e Windows RT.

"Escolha uma categoria de aplicativos que são importantes e encontre uma lista dos 10 melhores para cada uma", disse Berenson, argumentando que essa é a melhor maneira de avaliar um ecossistema, em vez de se fixar na falta de "must-have" apps, ou confiar em contagens de aplicativos.

"Se é uma categoria do mundo real, então escolha as 10 melhores empresas do mundo real (ao contrário de listas sobre o que é baixado em outras plataformas), e veja quantas delas possuem apps oficiais em cada uma das lojas de aplicativos", acrescentou.

Outros têm avaliado a loja virtual usando apenas os métodos descartados por Berenson. Em março, por exemplo, Sameer Singh, da Tech-Thoughts, destacou o crescimento lento da contagem aplicativos.

Anteriormente, outros analistas criticaram a Microsoft por não convencer os desenvolvedores a fornecer aplicativos importantes, com vários citando o Facebook como um excelente exemplo. 

Para a Windows Phone, Berenson encontrou três aplicações bancárias top-10, nenhum app na categoria de fundos mútuos e três melhores aplicações aéreas.

O Windows 8 e o Windows RT saíram-se ainda pior, de acordo com pesquisas na Windows Store realizada pela Computerworld.

Dos top-10 bancos, a Windows Store pode se gabar de apenas um: Bank of America. Nenhum das melhores empresas de fundos mútuos tinha um aplicativo para Windows 8 disponível na loja, enquanto que apenas uma companhia aérea (a Alaska Airlines) oferecia seu próprio aplicativo.

 Fonte:  http://idgnow.uol.com.br/internet/2013/05/15/loja-online-windows-phone-store-falha-em-teste-de-melhores-aplicativos/

Read More

Prorrogação do Concurso Cultural para Escolha do nome do nosso mascote

Bom dia pessoal,

Devido a pedidos estamos prorrogando o prazo para envio das sugestões para o nome do nosso mascote.

O novo prazo é o próximo dia 31 de maio.

Então pessoal não percam mais tempo e mande logo as suas sugestões, preenchendo o formulário abaixo.

FORMULÁRIO DE INSCRIÇÃO

Read More