thegoodfellas/blogset-br huggingface dataset:
que me dera o presente era, de fato, muito especial, arregacei asmangas e coloquei maos a obra. Em pouco tempo minha copa e cozinha estavamtransformadas num verdadeiro chiqueiro e, desesperado, quase chego a gritar.Por fim, transtornado, liguei para a faxineira, contrateihora extra prometendo pagar em dobro, e, assim que ela chegou, eu sai. Diretopara uma loja de importados, onde comprei uma caixa de cerveja irlandesaGuinness. Depois, com a casa limpa fiquei quieto no meu canto e, uma semanadepois, chamei a amiga para experimentar minha grande obra cervejeira. Assimque ela provou o que servi de uma bela jarra de vidro, seus olhos brilharam eveio a exclamacao: Meu Deus, voce e um genio. Isso esta melhor do que amelhor cerveja europeia.Poucos dias depois saiu uma bolsa de estudos que minha doceamiga esperava fazia dois meses, e ela viajou pra Londres. Naqueles velhostempos, pre-internet, ainda se usava remeter cartoes postais. Recebi um dela,passadas duas semanas, dizendo assim: Ontem, apos as aulas aqui, sai comamigos e tomei uma bela Guinness. Nao sei por que, mas lembrei de voce. Atehoje, como casou com um britanico e nao voltou mais pra Campinas, aindadesconfio que, de fato, ela sempre sacou o que havia na jarra que usei paraservi-la...
onde fuiatendido por uma senhora bastante idosa, na qual reconheci a dona Maria dosvelhos tempos. No que lhe disse, pegando o vidro com a compota, o que me levaraali, ela respondeu, chorando, que o marido morrera meses antes.Mas, durante o cafezinho, pude, finalmente, perguntar como eque Capella, num Estado brasileiro onde a colonia italiana era pequena, foiparar no lugarejo perdido no meio da selva. E ela me contou.Na verdade o imigrante Giancarlo Capella, nos primeiros anosdo seculo XX, buscava Sao Paulo. Por conveniencias de embarque resolveu pegar onavio em Lisboa onde um portugues, que tambem emigrava, perguntou se ele naoqueria conhecer antes a floresta amazonica, a partir de Belem do Para. Oitaliano topou, pretendendo, depois, seguir para a cidade de Santos.Desta forma acabou indo a Mocajuba, levado pelo luso quefora chamado por parentes que la trabalhavam com borracha e cacau. Rodou porali uns dias e, na vespera de regressar a Belem para tomar o rumo de Sao Paulo,conheceu linda mocinha chamada Maria, filha de prospero seringalista luso.Houve encanto mutuo.Nesta instante da narrativa a viuva de Capella me pediu paraesperar, queria me mostrar algo. Voltou com uma foto dela, meio amarelecidapelo tempo. Ao me entregar, murmurou: Quando casamos meu marido fez estafotografia, que os padres holandeses da nossa paroquia revelaram. Olhei e vi uma jovem fantasticamente bonita, deslumbrante.Torno a mirar dona Maria, ao vivo, e percebo que seus olhos mantinham brilhoprofundo. Claros, diamantes; e azuis, maravilhosamente azuis como dois pingosdaquele ceu de julho no verao amazonico, que nos cobria. Capella nao poderiamesmo, depois de conhece-la, ir para nenhum outro lugar... Tiveram doze filhos.
esperanca de passar no vestibular se ele nao estudou para isso. Nao da para voce esperar por um determinado emprego se voce nao se preparou para aquele mercado de trabalho.Se quisermos a alegria sem nos comprometermos com a esperanca, ficaremos desiludidos. Temos direito de ter esperanca quando nao paramos de lutar. Esse e o segredo dos campeoes. Nao corra atras de uma esperanca vazia, que te ilude, te paralisa, que te deixa estagnado... Para chegar ao Ceu e preciso trabalhar. Na espera nos tornamos pessoas melhores porque e tempo de crescimento. Esperar e doloroso as vezes... porem, o resultado final e belissimo, maravilhoso! Com o tempo vamos adquirindo tempera, algo tao esquecido nos nossos dias, em um mundo que vive em desequilibrios. As pessoas querem tudo de imediato, mas quando Deus nos leva a esperar somos treinados na fe e nos tornamos pessoas melhores que sabem valorizar aquilo que receberam. Esse e outro ponto importante, quando precisamos esperar algo tao desejado aprendemos a dar valor a ele e cuidar...Da nossa parte, busquemos em tudo fazer a vontade de Deus como Maria e no tempo devido poderemos cantar o nosso Magnificat em gratidao a tudo o que Deus ja esta realizando e ainda nao percebemos...Autor: Dunga (Phn - Cancao Nova)font: http://blog.cancaonova.com/dunga/?p=5079
Bom, antes de qualquer coisa, e importante lembrar que o objetivo desse exemplo e mostrar que e possivel criar um caso de teste mesmo com pouca (ou nenhuma) informacao sobre o sistema. Visto isso, e importante levar em consideracao alguns pontos:- O nivel de detalhamento do caso de teste, deve ser o mesmo nivel de detalhamento do caso de uso, quanto mais artefatos para criar um caso de teste tiver, melhor, se nao tiver, nao entre em desespero.- Essa e a hora de aplicar as tecnicas de modelagem de casos de teste (Analise das extremidades, Particao de Equivalencia, Tabelas de decisao, Grafos de transicao de estado, Grafos de causa e efeito, Tabelas de pares, Checklists, etc). Lembrando que essas tecnicas podem ser aplicadas em paralelo ou serem interdependentes, desde que sejam uteis. Nao faz sentido colocar uma tabela de pares no meio de um caso de teste que parte de um caso de uso. Por esse motivo, eu disse alguns posts anteriormente, que causou polemica, Caso de Teste e uma terminologia utilizada quando este e criado a partir do Caso de Uso (ver post aqui).- Tambem julgo importante manter um padrao de texto na criacao dos casos de teste, como no exemplo abaixo, quando e um link esta entre , etc.- Todo caso de teste deve ter "Resultados esperados", e durante a execucao, este deve ser comparado com o "Resultado real" para verificar se o sistema esta de acordo com o planejado.- E uma boa pratica a utilizacao de uma ferramenta de Gestao de Casos de Teste para facilitar o acesso e manutencao.- Utilizar outros documentos (documento de padroes do sistema, prototipo de telas, por exemplo) para auxiliar na criacao e execucao dos casos de teste.Exemplo de Caso de Uso:Fluxo normal1. Cliente coloca um ou mais itens no carrinho de compras 2. Cliente seleciona checkout3. Sistema coleta endereco, informacoes de pagamento e de envio do cliente4. Sistema apresenta todas as informacoes do usuario 5. Usuario confirma a ordem de pedido para o envio do SistemaFluxos alternativos - Cliente seleciona checkout com o carrinho de compras vazio; Sistema retorna mensagem de erro - Cliente prove endereco, informacoes de pagamento ou de envio do cliente invalidos - Sistema abandona a transacao antes ou durante o checkout; Sistema executa logout do cliente depois de 10 minutos inativo Exemplo de Caso de Teste:Passos Passo 1 Colocar 1 item no carrinho Passo 2 Clicar em Passo 3 Colocar valores validos para endereco, utilize Mastercard para pagamento e metodo de entrega valido e clicar em Passo 4 Verificar a ordem de envio Passo 5 Confirmar a ordem de envio Passo 6 Repetir os passos 1-5 mas colocar 2 itens no carrinho e escolher VISA como forma de pagamento Resultado esperado Passo 1 Item no carrinho Passo 2 Tela de checkoutPasso 3 A tela aparece corretamente e os inputs validos sao aceitos Passo 4 Aparece como digitado na tela Passo 5 A ordem de envio esta cadastrada corretamente no sistema Passo 6 Conforme feito nos passos 1-5 Font - http://testavo.blogspot.com/2010/05/exemplo-de-caso-de-teste-criado-partir.html - Luiz Gustavo S. Vieira A 30a Mesa Redonda
enquanto estamos testando a release atual ja estamos estimando e criado cenarios e casos de testes para a proxima release, se alguem fosse parar para automatizar regression a proxima release iria atrasar, e as regras mudando toda release, em outras palavras o que chamamos de regression hoje ta mais pra coisas que restaram da release passada, nao conseguimos nem manter os TCs que sao super pequenos e nada detalhados, quem dera manter atualizados scripts, aqui vale mais a pena automatizar alguns procedimentos genericos do que automatizar validacoes.Mas tem empresas tambem em que as pessoas ficam focadas em uma release so, e acompanham o projeto desde a fase de requisitos ate a homologacao, enquanto os devs nem escreveram os codigos eles tem tempo para fazer um monte de coisa, quando e assim e, se o FW e conhecido e possivel ate automatizar desde o ciclo 1 paralelamente a implementacao (aqui sim vejo ganho na automatizacao), entao assim que a primeira build e gerada deixa-se uma maquina dedicada rodando os scripts dia e noite (se possivel em integracao continua), e os testers seguem suas vidas normalmente em suas 8hs diarias executando os testes pente fino manuais. Pensando nisso, na release 2 os scripts das funcionalidades da release 1 ja estariam la, entao novamente paralelamente a criacao do codigo da release 2 iriam criar os scripts da release 2, se alguma coisa da release 2 quebrar alguma coisa da release 1 espera-se que os scripts da release 1 achem isso enquanto os testers estao focados na release 2. Nao tenho como ser generico em tirar uma conclusao geral que automacao de testes funcionais em ciclos de regressao sempre sao viaveis.Testes sustentaveis, o que raios e isso?No inicio da discussao coloquei que a automacao dos testes funcionais e muito importante para se testar de forma sustentavel, pois e muito dificil garantir a qualidade de um sistema apenas com testes manuais.O Shmuel fez consideracoes pertinentes sobre essa minha colocacao, que me fizeram explicar melhor o que seria testar de forma sustentavel.Primeiramente, testes sustentaveis sao importantes para podermos garantir a qualidade do sistema a longo prazo. Pois pode ocorrer de precisarmos de esforco X para testar o sistema, no inicio do desenvolvimento, e 2X para testar o sistema nas etapas finais de desenvolvimento, cenario esse que revela que algo pode estar errado.Testar de forma sustentavel serial algo como testar de forma eficiente, ou seja, com o minimo de esforco e o maximo de eficiencia.Ou melhor, testar de uma forma que fosse possivel garantir um bom nivel de qualidade, ao longo de todo o projeto, buscando investir um esforco sempre parecido. Ou seja, garantir a qualidade tanto quando o sistema tem apenas 2 funcionalidades, como quando ele tem 50.Para tentar explicar o conceito: imagine que estamos no ano de 2006 e voce trabalha no Google, mais precisamente na celula de desenvolvimento do Google Docs. Como todos sabem, o Google Docs e uma ferramenta que teve o seu desenvolvimento de forma incremental, e voce como incubido de testar ele. Voce precisara fazer varios testes a cada nova versao, sendo que
boa parte destes testes, ja foram feitos antes.Se voce fosse testar sempre de forma manual, acabaria entrando numa rotina, que sempre teria mais e mais testes para executar e isto com certeza iria impactar no projeto, uma vez que ou voce necessitara de mais pessoas para te ajudar ou o prazo para a entrega sera sempre maior, afinal a cada lancamento voce tera mais testes para fazer.Mas voce e o Shmuel, uma pessoa consciente e que sabe da importancia da sustentabilidade para o Teste de Software, por isso ja em 2006 percebe que boa parte dos testes podem ser automatizados, e isso iria aliviar bastante o seu trabalho e voce teria tempo para fazer outros testes mais complexos, que poderiam obter novas informacoes e que necessitariam de analises que um computador nao consegue fazer (por exemplo, testes de usabilidade).A ideia de sustentavel seria essa. Meio viajante eu sei, e muito bonita na teoria.Voce estuda a viabilidade de automacao e planeja, ou simplemente poe a mao na massa?O Juraci respondeu dizendo:Eu estudo sim a viabilidade para cada caso de teste, em um projeto eu tenho casos de teste candidatos a automacao. Sao aqueles repetitivos que serao utilizados em uma futura regressao, testes massantes tais como o mencionado anteriormente, testes que revelaram falhas no software tambem sao candidatos pois mostram o seu valor durante o teste de regressao. Vale destacar que o caso de teste e a base para a automacao, e o requisito do sotftware/aplicativo/script que sera o produto da automacao, nao adianta colocar a mao na massa sem ter os casos de teste bem definidos, pois isto equivale a ter um requisito fraco e que ira acarretar em muito mais transtorno como foi comentado.O Ferminiano tambem fazer um estudo antes:Sim, fazemos um estudo de viabilidade de automatizacao. Sempre aparece alguem querendo automatizar alguma coisa, pensando que basta apertar um uma tecla e pronto, como ja disseram aqui na lista. Um breve estudo de viabilidade mostra que apenas algumas poucas vezes isso e possivel.Bem pessoal e isso, espero que tenham gostado do resumo, que mesmo atrasado nao poderia faltar, pois essa discussao foi excelente, alias, se voce quiser saber mais, acesse o link para a pagina do DFTestes com a discussao na integra.Fonte: http://qualidadebr.wordpress.com/2010/10/09/automacao-de-testes-funcionais/
as universidades parceiras esta a necessidade da instituicao oferecer um curso de formacao profissional para o setor de TI de qualidade e atualizado. Portal TI-SmartO portal TI-Smart', alem de hospedar o curso de ingles online, tambem tera atrativos como: noticias de TI, depoimento de profissionais que atuam na area, estudos de casos de solucoes e anuncios de vagas de empregos da IBM e de parceiros de negocios. Os interessados nas ofertas de vagas poderao, inclusive, cadastrar seus curriculos no proprio portal. O site tambem disponibilizara cursos de ensino a distancia em TI, em diversas modalidades, sendo que alguns sao abertos ao publico em geral (nivel basico), e outros de acesso restrito que necessitam de senha (nivel avancado). Ambos os projetos foram idealizados para usufruir de beneficios de leis de incentivos fiscais. Tanto o portal quanto o curso de ingles foram desenvolvidos em conjunto com a Flextronics, empresa parceira da IBM para fabricacao de maquinas, sendo viabilizados pela Lei da Pesquisa e Desenvolvimento. E tambem o Funcria, fundo criado para protecao de criancas e adolescentes, cuja a intermediadora e a Prefeitura de Hortolandia, cidade na qual esta situado o Centro de Tecnologia da IBM Brasil. Visite o portal: www.ti-smart.com.brFont: www-03.ibm.com/press/br/pt/pressrelease/32424.wss
Documento, valido por um ano, foi emitido para Romualdo Panceiro nos ultimos dias de dezembroGustavo RibeiroNo apagar das luzes do governo Lula, o Itamaraty realizou uma serie de questionaveis emissoes de passaportes diplomaticos. Um dos privilegiados foi o bispo Romualdo Panceiro, da Igreja Universal. Ele recebeu o documento em carater excepcional nos ultimos dias de dezembro. A benesse, valida por um ano, foi concedida para atender um pedido formal do senador Marcelo Crivella (PRB-RJ), tambem bispo da Universal, e autorizada pelo ex-ministro das Relacoes Exteriores, Celso Amorim.bispo Romualdo PanceiroPanceiro e o numero dois na hierarquia da Universal, e apareceu em uma gravacao de abril do ano passado ensinando pastores a arrecadar dinheiro de fieis durante a crise economica mundial. Com essa crise, se nao pegar tudo que tem no banco e der para Deus, o espirito da crise vai pegar tudo, disse o bispo durante uma videoconferencia. Ele recomendava aos religiosos usarem passagens biblicas para estimular os fieis.Por lei, os passaportes diplomaticos so podem ser concedidos a autoridades de estado, como o presidente da Republica, ministros, congressistas e, naturalmente, diplomatas. As excecoes sao permitidas apenas para pessoas que representem interesses do pais. O documento diplomatico facilita a entrada de seus portadores em outros paises, pois elimina a burocracia na alfandega.Alem do bispo, dois filhos do entao presidente Lula, Marcos Claudio e Luis Claudio, receberam o documento diplomatico, validos por quatro anos. Tem direito ao passaporte diplomatico filhos de presidente de ate 21 anos (ate 24 anos se estudante) ou portadores de deficiencia. Nao e o caso de ambos.O Itamaraty fez outra gentileza a Marcos Claudio e Luis Claudio: alem do passaporte, enviou um pedido formal a embaixada americana solicitando visto para que os dois pudessem realizar uma viagem a Nova York de 5 a 15 de janeiro.Fonte: Veja Participo do Grupo chamado DFTestes e foi lancado um assunto que acho que faz muito sentido ser comentado, entao resolvi escrever esse post para mostrar o que acho de Compromisso dos desenvolvedores com a Qualidade do Produto.Bom foi colocado em questao campos que obviamente precisam de uma validacao como CPF que possui 11 numeros, nao deve aceitar letras (string) e muitas vezes nao aceita nem caracteres como (. e -), ter uma verificacao de CPF valido, etc.Muitas vezes ao fazer um documento de requisitos juntamente com o cliente, nao e especificado que campos assim devem obter tais validacoes como essas do CPF, alguns Desenvolvedores ao pegar um documento de requisitos que nao possuem a descricao de uma validacao, ira apenas fazer um campo de input e boa, envia para teste. Assim que o testador pegar esse form para testar, ele logicamente vai de cara testar se o campo aceita uma letra, ou a quantidade de caracteres que o campo deve aceitar.A questao de Qualidade de Software tem que partir de todos dentro de uma empresa de desenvolvimento e nao somente de um Analista ou Desenvolvedor ou Analista de teste, logico que tudo tem que se manter boas praticas, ex. Qual seria uma boa pratica um formulario que contenha um campo de CPF? Ter pelo
menos a validacao de CPF valido ou invalido, as vezes ao se criar documentos e tao facil passar alguma coisa como: - ha isso ja e padrao nem preciso colocar. Ta errado tem que colocar toda e qualquer validacao sim tanto no Doc. de Requisitos ou qualquer outro Doc. que o sistema possua. Mas tambem me vem o pensamento de alguns Desenvolvedores, ja escutei sair da boca de uns: - se nao tem no Doc. a descricao de validacoes para cada campo, eu vou fazer apenas o que e esta escrito.Pois acho que esta errado esta visao, desenvolvedor tem que pensar sim se nao tem ja vou fazer pois quem tera mais trabalho para consertar um erro depois e quem desenvolveu, a assim gerando mais gasto e tempo de desenvolvimento. E melhor perder tempo agora do que depois.Deixe sua opniao sobre o assunto - Comente!!!
Li esse post no blog da iMaster e achei muito interessante pois ja pude presenciar algumas falhas que pude identificar em Projetos ao ler esse texto, espero que seja util para voce tambem...Desenvolvimento para o mundo realDesenvolver software nao e simplesmente sentar na frente de um computador e comecar a escrever muitos codigos. Sao necessarias horas de conhecimento a ser adquirido sobre aquilo que sera feito no mundo computacional, que reflete o mundo real, alem de se saber ate onde do mundo real sera espelhado no computacional. Muitas visoes sao geradas no processo de conhecimento de um dominio e o resultado deste conhecimento sera o produto a ser entregue ao nosso cliente. Precisamos definir a linguagem, a arquitetura e a plataforma em que o software sera desenvolvido, entre outras questoes. E isso nao e uma tarefa facil, mas e necessaria.Falhas de comunicacao x PrazosAlem de tudo o que precisamos levantar junto ao cliente e entre nos desenvolvedores, ainda temos um grande vilao que acompanha todo o projeto de software, o prazo. Esse fator e critico, pois mensurar tempo para um software ficar pronto e bem complexo, e a grande maioria nao consegue cumprir os prazos.O que vejo muito no ramo de desenvolvimento sao clientes se apresentando como alguem que precisa de algo simples (o que na verdade nao costuma ser tao simples assim) e os desenvolvedores topando dar a solucao. Ai que mora o perigo: o cliente muitas vezes nao sabe a dimensao do problema dele e, uma vez que ele nao sabe disso, muito menos nos saberemos ate que um dia no meio do desenvolvimento comecam a aparecer surpresas e mais surpresas.O cliente precisa de uma solucao para seu negocio, muitas vezes em prazo curto e buscando o menor custo. A questao e: qual e a qualidade que o cliente deseja? E codigo? Requisitos? Ou produto? Quanto mais controles de qualidade, maior e o custo e tempo - e o cliente precisa estar disposto a pagar por isso.E ai o que fazer? Fazer tudo na correria e entregar no prazo para honrar o acordo - vulgo bancar o heroi? Desenvolver o software e ir informando o cliente do seu andamento, mais muitas das vezes nao receber por isso (Visto que valores sao discutidos antes do inicio do projeto)?Acredito que uma forma legal e ter o cliente vendo o produto nascer. Nao que ele esteja o tempo inteiro vendo o desenvolvimento, mais sim estar proximo o bastante para poder participar das decisoes de projeto - onde a qualidade em quesitos tecnologicos pode ficar abaixo do esperado.Fonte: iMasterAutor: Bruno Carlos Alves 1.1. Definicao de riscoAo avaliar os riscos de um projeto, estamos buscando aqueles fatos cujas ocorrencias poderao acarretar perdas para empresa. Nem sempre e possivel aliar um risco a uma perda um risco presente nem sempre vai gerar uma perda. Em resumo, podemos dizer que o risco e a possibilidade de ocorrencia de uma perda para empresa.Segundo o dicionario Houaiss, Risco e a probabilidade de insucesso, de malogro de determinada coisa, em funcao de acontecimento eventual, incerto, cuja ocorrencia nao depende exclusivamente
projeto; Listas de riscos publicadas; Base de informacoes de projetos anteriores.1.8.2. Analise de riscosDe acordo com o PMI os riscos devem ser analisados qualitativa e quantitativamente.A analise qualitativa dos riscos e feita com base na definicao da probabilidade de ocorrencia do risco e de sua severidade.Muitas vezes a analise quantitativa PE realizada em conjunto com analise qualitativa. O objetivo da analise qualitativa e analisar numericamente a probabilidade de cada risco, de modo que seja possivel, depois definir seu tratamento. Essa analise e feita dentro do contexto global do projeto.1.8.3. Planejamento dos riscosO planejamento dos riscos envolve a escolha dos planos para responder aos riscos. E realizado de acordo com o caminho de melhor custo-beneficio.Os seguintes planos devem ser elaborados: Plano de Mitigacao; Plano de Contingencia.1.8.4. Controle e monitoracao dos riscosControlar e monitorar riscos e acompanhar a evolucao dos riscos no desenvolvimento dos projetos, o que envolve a avaliacao permanente dos riscos e, caso algum ja tenha ocorrido, como funcionou a resposta atribuida a sua ocorrencia.