Code Journey

Não pode ler agora? Ouça esse conteúdo durante suas atividades:

Na primeira parte do artigo sobre as pragas do teste de software, abordamos sobre as pragas da repetitividade, da amnésia e do tédio. Caso não tenha lido, pode acompanhar a leitura aqui.

Já nessa segunda parte, iremos falar sobre mais algumas pragas: 

• A praga da casa nova (The Plague of Homelessness) 

• A praga da cegueira (The Plague of Blindness)
  

A praga da casa nova (The Plague of Homelessness)

Essa praga se inicia com uma pequena definição, são dois grupos distintos que encontram bugs com frequência: os testadores e os usuários, que acabam se deparando com os erros quase que na maioria das vezes sem querer. Isso acontece com a combinação da interação da aplicação com usuários reais, utilizando dados reais e em um ambiente real. 

Não pode ler agora? Ouça esse conteúdo durante suas atividades:

Segundo James A. Whittaker, existem as chamadas “Pragas do Teste de Software”, que resumem problemas vividos no cotidiano de testers. Algumas delas são: 

• A praga da repetitividade (The plague of Repetitiveness) 
• A praga do tédio (The Plague of Boredom) 
• A praga da amnésia (The Plague of Amnesia) 
• A praga da casa nova (The Plague of Homelessness) 
• A praga da cegueira (The Plague of Blindness)
  

Hoje, falaremos um pouco sobre as 5 pragas acima. Em breve, teremos aqui uma parte 2 com as outras duas Pragas do Teste de Software. Vamos lá?

Não pode ler agora? Ouça esse conteúdo durante suas atividades:

Quem nunca recebeu uma tarefa e disse para si mesmo “É IMPOSSÍVEL!”? Atire a primeira pedra (uma de cada vez…rsrs)!

Sabe aquela tarefa que você disse “sim”, mas para si mesmo você disse “não”? Que para não receber o olhar de rejeição de seu patrão, chefe, gerente, supervisor, colega, amigo e etc., você acaba aceitando aquela solicitação, mas pensando consigo mesmo: “não vai dar pé, não tem como essa tarefa ser realizada”.

Essa situação pode acontecer quando uma tarefa é muito difícil, ou quando existe um prazo apertadíssimo. O pior é que a qualidade do serviço acaba comprometida nessas missões impossíveis.

Não existe uma forma infalível, uma fórmula mágica (caso exista, infelizmente não temos acesso ao livro de feitiços e não recebemos a mente da Hermione), mas tudo bem. Hoje vou compartilhar com vocês algumas dicas para resolver essas situações difíceis com base na minha experiência.

Sabe aquelas telas de boas-vindas que vemos quando abrimos um app pela primeira vez? Este processo é feito para familiarizar o usuário com o app e suas funções. É uma oportunidade para apresentar as principais funcionalidades ou diferenciais do app, novidades de uma versão, ou tentar convencer usuários a se registrarem no serviço.

Neste tutorial irei ensinar como criar um onboarding no iOS usando UICollectionView e Storyboard. Os controllers das views serão escritos em Swift 4. Se quiser baixar o projeto completo, siga este link para o GitHub.

Storyboard

Acho legal usar o storyboard pra desenhar as views porque economiza muito tempo e linhas de código, fora a vantagem de poder ver todo o fluxo de telas da aplicação de uma vez!

Por isso, vamos criar um novo projeto, abrir o storyboard, remover a View Controller padrão e colocar em seu lugar uma Collection View Controller. Com a ajuda do Document Outline, selecione a Collection View que está dentro da Collection View Controller. Queremos alterar algumas propriedades para que ela se comporte como um onboarding com scroll horizontal:

Atualmente a transcrição de textos é algo comum para os usuários de smartphones. A SIRI,  o Google Now e a Cortana popularizaram essa prática. Mas na Web isso não é tão comum assim. As grandes empresas de tecnologia hoje nos oferecem API’s para esse serviço, mas não é algo muito barato e nem tão trivial assim integrar com as gigantes.

Mas e se os browsers nos fornecessem essa API de forma nativa, para que pudéssemos transcrever tudo o que o usuário fala em texto apenas com uma permissão simples e HTTPS? Muito mais fácil, certo?

Essa é a ideia da especificação da W3C para a Web Speech API, para que o browser nos forneça esse serviço de forma nativa e muito simples. Então, veremos logo abaixo como podemos implementar essa API em nosso dia a dia para facilitar a vida do usuário e aumentar muito a acessibilidade das nossas aplicações.

Há alguns anos atrás a análise de requisitos era um tanto renegada no mercado de desenvolvimento de software, onde alguns profissionais diziam que encareciam muito um projeto e não geravam valor. Mas nos últimos anos essa realidade tem mudado. Os números demonstram que projetos com análise e especificação de requisitos agregam valor para o desenvolvimento e para o negócio e o seu valor é justificado.  

Mas é claro, é melhor não ter nenhuma documentação escrita do que ter uma especificação que não faça sentido para o projeto. Então, para lhe ajudar a entregar valor com sua documentação eu reuni cinco dicas para lhe auxiliar nessa tarefa. Mas como não existe “Bala de Prata” na engenharia de requisitos, você deve seguir aquelas que fazem sentido para a sua realidade e negócio.  

Não pode ler agora? Ouça esse conteúdo durante suas atividades:

É muito comum ouvirmos falar sobre metodologia ágil em TI nos dias de hoje. Realmente é bem raro encontrar alguém envolvido com desenvolvimento de software que nunca tenha ao menos ouvido falar em termos como XP, Scrum, Histórias de Usuário, Pair programmig e etc.

O conceito de agilidade surgiu por volta dos anos 2000 com a criação do Manifesto Ágil, que possui entre seus doze princípios os objetivos de satisfazer o cliente através da entrega contínua e adiantada de valor agregado ao cliente, além de aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.

Este artigo visa comparar de maneira geral o papel dos requisitos no Modelo Cascata, utilizado antigamente, com os Modelos Ágeis tão amplamente difundido nos dias atuais. Vamos lá?

Há poucos dias, publiquei um artigo sobre o conceito de testes de performance em uma aplicação. Caso você não tenha lido, recomendo acessá-lo, pois esse artigo é uma continuação. 

Quando iniciei os meus estudos sobre Testes de Performance, logo conheci o JMeter. Essa ferramenta, desenvolvida pela Apache, traz um conjunto de soluções para avaliar fatores como desempenho, disponibilidade e escalabilidade das aplicações. Era o que precisávamos em um dos projetos da DB1. 

Para que este artigo não fique tão extenso, decidi agrupar as principais características do JMeter de acordo com a experiência que tive com a ferramenta. 

Neste post, vamos demonstrar um exemplo de utilização de métodos simples de inteligência artificial para aplicações práticas utilizando R direto da ferramenta Power BI. 

Para seguir com o tutorial é necessário que seja instalado o Power BI e do R for Windows.

Uma dificuldade comum para os desenvolvedores é fazer estimativas assertivas. Imagine a vantagem de ter de forma automática para obter macro estimativas de desenvolvimento com base no histórico? Isso pode facilitar o gerenciamento de projetos em geral, pois daria uma ideia do tamanho da demanda antes dos desenvolvedores desempenharem tempo nas estimativas. Bom, vamos tentar algo semelhante utilizando regressão linear.