Agile Testing

por elessandraestevao

No modelo Tradicional de desenvolvimento de software, composto por fases bem definidas, o tester atuava apenas em sua fase específica, recebia como entrada em sua fase os artefatos da fase anterior, trabalhava “no seu quadrado” e gerava seu artefato que seria direcionado àlguma outra fase. No caso de bugs encontrados, as evidências obtidas retornariam para o time de desenvolvimento através de ferramentas específicas para essa comunicação.

O tester tradicional tinha em seu mindset:

  1. Procurar bugs
  2. Garantir o atendimento dos requisitos
  3. Resistência a mudanças
  4. Qualidade é responsabilidade do tester
  5. Trabalhar separado do time de desenvolvimento
  6. Teste é uma fase
  7. Teste é no final do desenvolvimento

O desenvolvimento ágil de software mudou completamente o mindset do tester e a forma como esse profissional trabalha. Ao contrário de como o tester via o processo de desenvolvimento de um produto, de forma apartada, isolada, no contexto ágil o tester passa a ser parte do time de desenvolvimento e seu mindset se transforma. Agora o tester trabalha na prevenção de bugs, garante que as expectativas do cliente sejam claras, aceita novas ideias, a qualidade é responsabilidade do time e o tester é parte dele e o teste é uma atividade do processo de desenvolvimento de software.

Toda essa mudança de postura e do trabalho desempenhado pelo profissional de testes está baseada na mudança de paradigma quanto ao desenvolvimento de software, que passou de um modelo em cascata ou Waterfall para o modelo Ágil. O modelo Ágil é composto por princípios, os quais são condensados no Manifesto Ágil e descritos por meio de quatro valores:

  1. Indivíduos e a interação entre eles mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

Para o agile tester, seu trabalho e sua postura dentro de um time de desenvolvimento também são guiados por princípios ágeis. Veremos cada um desses princípios.

1. Comunicação face-a-face

O Método mais eficiente e eficaz de transmitir informações para o time e dentro de um time de desenvolvimento. Diferentemente do modelo tradicional onde o tester não tinha acesso ao time de desenvolvimento, no Ágil, o tester é parte desse time, o coder está sentado ao seu lado e a comunicação basta ser face-a-face, eliminando a burocracia.

2. Feedback contínuo

Diz respeito à prática de testes automatizados, desde os testes unitários até os testes de interface, dentro da pirâmide de testes. Os testes automatizados proporcionam o feedback rápido (unitários e de serviço) e contínuo, sendo executados num ambiente de Integração Contínua. Incluindo a garantia de testes regressivos, que dá segurança na hora de fazer mudanças no software e passa confiança para o time de desenvolvimento em relação ao trabalho que está sendo desenvolvido.

3. Melhoria contínua

Buscar sempre trabalhar da melhor forma e entregar o melhor, em valor, para o cliente e para o usuário final. A melhoria contínua é tanto de processos quanto de pessoas. Times ágeis são focados em fazer sempre o melhor e para isso, utilizam, como no Scrum, os valores da transparência, inspeção e adaptação para melhorarem continuamente seu processo de desenvolvimento e a si mesmos como pessoas e profissionais.

4. Ter coragem

A coragem é fundamental para times ágeis. É preciso coragem para fazer alterações no software ou refatorar. Para mudar de paradigma, sair do mindset tradicional e migrar para o ágil, é preciso ter coragem. Compartilhar a responsabilidade, pedir ajuda, propor mudanças ou soluções, apontar problemas, permitir-se errar ou os outros errarem são exemplos para os quais é preciso ter esse princípio como base.

5. Entregar valor para o cliente

Para entregar valor para o cliente, o tester precisa estar próximo dele, entender suas necessidades e ajudá-lo a transformar suas necessidades em cenários de testes voltados ao negócio que servirão para a validação de uma entrega ao final de uma iteração. No desenvolvimento ágil, o tester atua tanto no time de desenvolvimento quanto no time de negócio, sendo o ponto de ligação entre os dois mundos. O tester consegue conversar com as pessoas de negócio, entender o negócio, levantar questões técnicas durante as explanações de negócio, fazer perguntas que levem ao melhor entendimento sobre cada regra de negócio ou feature debatida. Assim, o tester pode ajudar o time de desenvolvimento a desenvolver aquilo que atende à necessidade de negócio e a entregar o valor esperado pelo cliente, além de utilizar suas habilidades técnicas para suporte e construção de uma suíte de testes automatizados durante o desenvolvimento.

6. Manter simples

Este princípio para os testers é especialmente delicado, pois por meio de sua visão crítica e analítica, o tester consegue pensar em diversos cenários que podem ocorrer quando do uso do usuário e, consequentemente, o tester quer testar todos esses cenários. No entanto, dentro de uma iteração curta de desenvolvimento, nem sempre dá para se testar todos os cenários levantados. Com isso, é necessário simplificar, utilizando as ferramentas mais leves para realizar o trabalho e priorizar juntamente com o cliente e com o time de desenvolvimento qual a área de maior risco no desenvolvimento, onde se encontra o maior retorno para o cliente dentro das funcionalidades em desenvolvimento, onde se encontra a maior dor do cliente. São essas questões que guiarão o trabalho do tester para testar “apenas o suficiente” com as ferramentas e técnicas mais leves.

De acordo com a priorização será realizado o trabalho de testes. Manter simples ajuda o time de desenvolvimento a manter o foco no risco, maior retorno e dor para o cliente.

7. Responder a mudanças

Diferentemente do modelo tradicional de desenvolvimento onde o planejado no início era levado à cabo, muitas vezes deixando de considerar as mudanças ocorridas durante o período de desenvolvimento, no contexto de desenvolvimento ágil, o time precisa responder às mudanças que naturalmente ocorrem durante esse período. Assim, o tester precisa se adaptar e ter uma postura flexível para entender o contexto e ver como pode ajudar o time de desenvolvimento a entregar valor e software com qualidade durante as iterações. Aprender novas habilidades, manter-se atualizado com novas tecnologias, fazer pareamento, cuidar da saúde do time, são algumas das atitudes que um tester pode ter para responder às mudanças ocorridas durante o desenvolvimento do produto.

8. Auto-organização

Times ágeis são auto-organizáveis. O time se auto organiza para resolver um problema ou enfrentar um desafio da melhor forma, utilizando as habilidades de cada membro do time com a maior eficiência. E essa auto-organização emerge do próprio time. Essa característica é importante para o tester ágil, pois, como membro desse time, ele precisa ter essa visão e autonomia para se auto-organizar e também colaborar com o time no mesmo propósito.

9. Foco em pessoas

Agilidade tem muito mais a ver com humanidade do que com burocracia de processos, documentos e ferramentas. Ser ágil é muito mais ser humano do que ser metódico e procedural. Focar em pessoas é aplicar todos os outros princípios já mencionados e manter a proximidade com as pessoas envolvidas no desenvolvimento de um produto. É saber que todos têm o mesmo objetivo de sucesso e podem se ajudar para o alcançarem. Focar em pessoas é cuidar da saúde do time.

É muito bom trabalhar num ambiente colaborativo e com pessoas motivadas e felizes com seu papel. Parece utópico, mas é um ideal que podemos buscar e ver resultados concretos no dia a dia, desde que assim acreditemos e trabalhemos por alcançá-lo.

10. Divertir-se

Um tester ágil não pode ser o “chato” do time, aquele que só reclama e aponta os “bugs” e “acusa” os outros. Isso não tem nada a ver com Agile Testing. O tester ágil é alguém que consegue viver a partir desses princípios e colocando-os em prática, torna sua profissão atraente para o time, agrega valor ao time de desenvolvimento e ao produto. É alguém que passa confiança, que está preocupado com o bem-estar da equipe, com o valor entregue, com o desenvolvimento, com o produto e principalmente, com as pessoas envolvidas (clientes, time de desenvolvimento, usuário final). Quando o tester ágil e o time atingem essa maturidade, é divertido ser um tester. =)

Conclusão:

O tester deixa de ter uma atuação em uma fase de desenvolvimento apenas, como no modelo tradicional de desenvolvimento de software e passa a ter um papel atuante e fundamental para o desenvolvimento de um produto, desde o entendimento do negócio até a entrega do produto final. O tester passa a ter habilidades diferentes, tanto técnicas quanto de negócio e de desenvolvimento de produto. Ou seja, ser tester, no contexto ágil, vai muito além de “achar bugs”. Para isso, não é preciso, necessariamente, de um tester, temos várias ferramentas de monkey testing e outras que podem encontrar bugs em menos tempo, menor custo e maior velocidade do que uma pessoa. No entanto, para agregar valor ao desenvolvimento de um produto, agregar valor ao time de desenvolvimento e ser uma referência em qualidade, para isso o Agile Tester é fundamental dentro de um time ágil.

Ser um tester ágil é ser alguém que serve ao time, ao cliente, à empresa com suas habilidades e capacidade crítica e analítica, não fica apontando falhas ou erros de outros, mas busca soluções para os problemas.

Qual é sua visão ou experiência com Agile Testing? Trabalha em um time ágil? Fique à vontade para compatilhar nos campos abaixo. Até a próxima!

Publicidade

“App did not start” com Calabash-android

por elessandraestevao

Ao iniciar um projeto com Calabash-android para criar testes automatizados com utilização do Cucumber, me deparei com o erro “App did not start” quando tentava executar o Calabash-android.

Como havia atualizado algumas Gems, pensei que fosse algo decorrente dessas atualizações e comecei a buscar a causa desse erro. Depois de constatar que não estava relacionado às minhas atualizações, descobri que o erro decorria do uso de permissões no app que estava testando. Faltava a permissão de acesso à Internet no app (:-) Após adicionar a permissão no arquivo AndroidManifest.xml, problema resolvido!

Mas por que isso aconteceu?

Porque o Calabash-android, para interagir com a aplicação que está sendo testada, utiliza o protocolo HTTP entre o seu servidor (que é instalado no device ou simulador onde serão executados os testes) e a aplicação em teste. Assim, sem essa permissão habilitada, não era possível estabelecer uma conexão entre o servidor do Calabash e a aplicação. O seguinte erro foi mostrado no log da aplicação quando da tentativa do Calabash de estabelecer comunicação com a mesma:

Este log diz que não foi possível abrir um socket para conexão entre a aplicação e o servidor de testes requisitada pelo Calabash devido à permissão negada.

Após adicionar a permissão, gerei um novo apk e foi possível estabelecer a conexão com a aplicação e dar start nela. No log da aplicação no Android Studio vi o seguinte:

Ou seja \o/

Como foi a Trilha Testes no TDC 2016

por elessandraestevao

No TDC SP, a Trilha de Teste é destinada aos profissionais ligados à qualidade e testes de software nas empresas, estudantes e entusiastas da área. A coordenação da trilha foi feita pelo Elias Nogueira, que é QA Engineer, Agile Coach & Trainer na Adaptworks e Professor de Pós Graduação na Unisinos/RS, e pela Tatiane Fukuda, QA Lead na TFG Co, com experiência de mais de dez anos em Qualidade e Testes de Software.

Considerando que comecei a trabalhar nessa área há cerca de seis meses, essa foi a primeira vez que participei da Trilha Testes. Então, a intenção deste post é deixar as minhas impressões como iniciante. Vamos lá?

No total, foram 14 palestras ao longo do dia. A primeira foi “Eu não garanto a qualidade” ministrada por Diego Blond, Analista de qualidade na Vizir Software Studio. Diego mostrou seu ponto de vista sobre o que pode contribuir para a garantia da qualidade num projeto e o que não contribui para tal. Segundo ele, abrir bug, relatórios, discussões, planos de teste, hora extra, equipe maior ou menor, focar na qualidade, entrega com ou sem pressa e teste automatizado, de forma isolada, não garantem a qualidade. Diego acredita que o que realmente garante é A EQUIPE! Como?

  • Sendo uma equipe informada sobre as regras de negócio, fazendo questionamentos, conhecendo bem o cliente, o usuário final e o projeto;
  • sabendo se comunicar com o cliente, propondo melhorias, apresentando argumentos;
  • saindo da zona de conforto, sempre estudar, se aprimorar, não regredir em suas habilidades e conhecimento;
  • sendo uma equipe unida, todos buscarem a qualidade;
  • utilizando o bom senso para todos os itens que, isoladamente, não garantem a qualidade (citados acima), mas que, utilizados em conjunto, pela equipe, funcionam.

Se você quiser ver os slides que ele apresentou, eles estão aqui.

A segunda palestra “Testes exploratórios não são sinônimo de bagunça” foi ministrada pelo Igor Abade V. Leite, um dos sócios da Lambda3 e Microsoft MVP (Most Valuable Professional) de Visual Studio ALM. Igor mostrou na prática como utilizar o plugin XTInstall para o Chrome, que permite fazer a abertura de bugs, criar uma nota a respeito de um bug encontrado, prints da tela durante a navegação na página web, criação de um caso de teste, geração de relatórios HTML, dentre outras características. O plugin é desenvolvido pela Microsoft e pode ser encontrado aqui. . Tem a versão Stand alone (gratuita) e a versão de modo conectado ligado ao TFS. Se você quiser saber mais sobre esse tema, os slides do Igor estão aqui.
A terceira palestra, “10 coisas que não me contaram sobre testes”, foi ministrada pela Katiana Maia, Analista de Testes e Qualidade na Alcis — Softwares para Logística. Segundo ela, o que ela não sabia sobre testes é que o detalhismo é bom; que o profissional de testes precisa atuar muitas vezes como psicólogo e saber “se virar” com programação; que nem todos fazem teste, e por isso é importante falar sobre a importância da prática; que a automatização dos testes é imprescindível e possível para um testador, basta ter paciência e persistência; que no processo tradicional de desenvolvimento de software ou no ágil, o essencial para o sucesso é a comunicação; que tempo é definitivo (infelizmente, uma versão pode ser entregue com ou sem testes, e quando os prazos são apertados a primeira opção de corte é o teste); e, por fim, o mundo dos testes é maior do que pensamos: tudo deveria ter testes! Se você quiser saber mais, pode ver os slides da palestrante aqui.

Depois foi a vez de Jônatas Davi Paganini — full stack engineer na Resultados Digitais, que falou sobre como sua equipe conseguiu diminuir o tempo do build de 12 mil testes de 25 min para 13 min na palestra “Otimizando tempo de build: performance da suíte de testes”. Ele enfatizou o uso da factory Girl, uma biblioteca para a criação de objetos Ruby como dados de teste. Veja os slides dele aqui.

Em seguida, Luiz Augusto dos Santos Lohn, Mobile QA Engineer na Socialbase, falou sobre “Automação de Testes Mobile com Appium“, por meio deste exemplo prático.

Appium é uma ferramenta para a automação de testes no contexto mobile que suporta diferentes tipos de linguagens de programação, atende as plataformas Android e iOS nativas e aplicações híbridas. Os slides da palestra estão aqui.

A palestra “4 dicas valiosas para uma pirâmide de testes saudável” foi ministrada por Taíse Dias da Silva e Ricardo Cavalcanti, ambos da ThoughtWorks. Eles falaram sobre o que é a pirâmide de testes de acordo com as visões de Mike Cohn (livro Succeding with Agile), Sam Newman (livro: Building Microservices) e Lisa Crispin e Janet Gregory (Livro: Agile Testing).

De acordo com o que foi explicado por eles, a maior quantidade de testes em um projeto deve ser na base da pirâmide, os testes unitários, os quais são executados em pouco tempo e podem ter uma bateria ampla sem comprometer o tempo de build do projeto. No meio da pirâmide estão os testes de serviço (API, aceitação) e no topo da pirâmide estão os testes de interface, os quais devem ser em menor quantidade, abrangendo o fluxo funcional da aplicação como um todo, porque são testes mais demorados. Entretanto, eles ressaltaram que os diferentes tipos de testes são complementares, não excludentes entre si.

Por fim, eles sugeriram separar testes unitários dos testes de aceitação para ter feedbacks mais rápidos e não adiar a implementação da jornada do usuário, ou seja, o teste de fluxo da aplicação a partir da UI (evitando o acúmulo de dívidas técnicas).

Claudenir Freitas, desenvolvedor de sistemas na Sensedia, falou sobre “Testes em APIs REST”. O objetivo da utilização de APIs é prover um mecanismo simples, seguro e escalável para que desenvolvedores construam suas aplicações de forma desacoplada e no menor tempo possível. Claudenir mostrou a utilização do Swagger para a documentação de API, a extensão do Chrome ‘Postman’ para fazer requests em APIs, o Newman, um pacote Node utilizado para executar coleções do Postman via linha de comando e falou sobre o Jenkins para a integração contínua. A apresentação dele está aqui.

Danilo Feijó, tester na CI&T e entusiasta Ágil, falou sobre “BrowserSync: Acelerando seus testes manuais na web”. BrowserSync é uma ferramenta assistente para execução de testes manuais na Web, baseada em Node.js. Com esse assistente é possível replicar os testes feitos em um browser em outros de forma simultânea, ou seja, podemos testar um site no Firefox, Chrome e Internet Explorer ao mesmo tempo, interagindo apenas com um desses browsers. Aqui estão os slides dele.

Danilo Torres Porcelani, desenvolvedor na DB1 Global Software, falou sobre “Automação de testes com Docker“. Porcelani pontuou a necessidade de estratégia na hora de refatorar um código ou projeto e, segundo ele, não ter medo de encarar essa necessidade (desafio) e “conteinizar” aos poucos faz parte desta estratégia.

Segundo Porcelani, a “conteinerização” simplifica o desenvolvimento e a execução de testes, elimina inconsistências de ambientes e a necessidade de servidores destinados ao uso de QA exclusivamente, dentre outras características. Veja os slides que ele usou aqui.

Lucas Martins Ramos, desenvolvedor na Geofusion, falou sobre “Programando Testes: uma quebra de paradigmas entre DEV e QA”. Ramos enfatizou a necessidade do “pareamento” entre desenvolvedores e testers na hora de pensar e escrever os testes. Em sua experiência em equipe trabalhando junto com um profissional de qualidade sem experiência em programação, Ramos compartilhou que aprendeu a enxergar diversos cenários de teste e ensinou como programar esses cenários para o tester. Com essa troca de conhecimento, o time se beneficiou com o aumento de qualidade no desenvolvimento do projeto e com o aumento de conhecimento da equipe. Para Ramos, a expressão “Dev x QA” deve ser para a multiplicação, para o aumento de qualidade e conhecimento das esquipes multidisciplinares. Os slides dele estão aqui.

Edlaine Zamora, desenvolvedora Web na DB1 Global Software, falou sobre “Tomada de decisão baseada em testes de carga“. Segundo ela, os testes de carga detectam falhas de segurança e são importantes para a tomada de decisão pois expõem as capacidades e fraquezas de um sistema e coletam dados para fins de escalabilidade, sendo que uma decisão assertiva deve se basear em dados. Veja aqui os slides.

Priscila Formaggio e Jessica Mollo, analistas de Qualidade no UOL Pagseguro, falaram sobre “A transição de um QA tradicional para um Agile Tester”. Elas definem os testers que atuam apenas no final do processo de desenvolvimento como os “tradicionais” ou “Jurassic testers”. No contexto ágil, o tester é parte do processo eatua do início ao fim.

As palestrantes definiram três perfis de profissionais de qualidade:

  1. QA de negócio: aquele que tem uma visão analítica, macro do negócio e suas regras, atua mais próximo do P.O. e do cliente, além de testes funcionais e não funcionais.
  2. QA técnico: aquele com habilidades voltadas para a programação, atuando mais próximo dos desenvolvedores, TDD, Pair Programming, frameworks, etc.
  3. DevQA: aquele com conhecimento no pipeline de implantação e configuração de scripts, que motiva o time nas práticas de entrega e integração contínua.

Para elas, é importante o profissional de qualidade identificar suas habilidades, sair da resistência e adquirir novos conhecimentos, desenvolver novas habilidades e consolidar seu papel no time. Sempre aprender, melhorar e trabalhar em equipe foram as orientações finais. Veja os slides aqui.

Robson Correa, especialista em Qualidade na UOL e na BOLD International, falou sobre como um desempregado pode se recolocar como QA. Correa baseou sua palestra na sua história pessoal. Ele saiu de uma empresa na qual trabalhava há anos e foi para Liverpool, na Inglaterra, onde aprendeu inglês e se aprimorou, estudando diariamente.

Nessa jornada de aperfeiçoamento profissional e recolocação no mercado de trabalho, Correa fez uma análise e compartilhou em sua palestra dados como as cidades com mais vagas disponíveis na área de Qualidade, faixa salarial, processos seletivos, etc. As informações estão disponíveis nesses slides.

Para encerrar, Alan José Nascimento, líder de testes na Raia Drogasil, falou sobre “O que a IOT vai mudar no mundo dos Testes”. Alan acredita que em breve teremos uma nova grande mudança em como trabalhamos com qualidade e testes, assim como foi com a mudança do modelo tradicional de testes de software para testes automatizados. Para ele, em um futuro próximo, os termos como Eletrônica embarcada, sensores, relés, etc, serão familiares para os testadores de software, que também testarão hardware. Veja a apresentação aqui.

Para mim, foi uma trilha ótima que abrangeu diversos assuntos e deu dicas de ferramentas a serem estudadas e que estão sendo utilizadas na comunidade de Testes e Qualidade de software, tratou de assuntos técnicos e não-técnicos como a postura de um profissional de qualidade dentro de times multidisciplinares.

Além de ter tido uma visão sobre o mundo de Qualidade de software por meio de outros profissionais, vi que nosso trabalho vai além de automatizar testes, tem a ver com a postura ativa e focada no bem-estar da equipe e da entrega de resultados com qualidade para o cliente, além de atingir o usuário final de forma a encantá-lo. Em resumo, me identifiquei com essas pessoas e com a área e quero continuar a estudar e me tornar cada vez mais uma profissional de Qualidade com excelência. =)

O que é documentação viva?

por elessandraestevao

Por definição, documentação é o ato ou processo de documentar, ou seja, reunir informações para provar algo. No contexto de desenvolvimento de software, especificamente em ágil, precisamos documentar o sistema de uma forma que seja também ágil. Para isso, usamos o processo de documentação viva. Vamos entender um pouco mais esse conceito?

Uma documentação é viva porque é dinâmica e acompanha o processo de desenvolvimento desde o levantamento de requisitos e de cenários funcionais até a implementação, gerando documentos e sendo utilizada e conhecida por toda a equipe de desenvolvimento, além dos stakeholders. A “vida” da documentação está relacionada a algo que tem suas “funções vitais” ativas, como por exemplo nortear a implementação de features, revelar o status do sistema ou esclarecer interessados sobre como o sistema funciona. Quem dá vida a essa documentação é a equipe de desenvolvimento, testers e demais stakeholders. Não é um monte de papel engavetado, consultado em casos emergenciais e apenas isso. Pelo contrário, é algo que cresce, muda e evolui junto com o desenvolvimento do sistema, com o envolvimento de toda a equipe e interessados.

Parte da documentação viva engloba a especificação das funcionalidades a partir de exemplos, o que chamamos de especificação por exemplo. Com ela, os interessados não-técnicos podem interagir e entender sem dificuldades, uma vez que a especificação é feita em linguagem natural e é voltada para as regras de negócio. Essas especificações descrevem por meio de exemplos os cenários funcionais do sistema, os quais são “traduzidos” em uma validação que verificará periodicamente (isso é configurável) se o sistema faz o que deveria, ou seja, o que está especificado. Além disso, a validação também avalia se essa especificação continua representando com fidelidade o que o sistema faz, ou seja, se está atualizada. Uma especificação traduzida em validação é uma especificação executável, e isso faz parte do que a constitui “viva”, pois o que é vivo tem reações e interações. A especificação reage contra o sistema que está sendo validado. Reagir às especificações contra o sistema é testar, e os testes também são parte de uma documentação viva.

Um dos artefatos da documentação viva é um documento ou relatório resultante da validação do sistema a partir da especificação executável. Este artefato às vezes pode ser confundido como sendo a própria documentação viva, porém uma documentação viva diz mais sobre o processo que gera esse artefato. O documento ou o relatório final é onde culmina todo o processo de documentação realizado.

O que deveríamos ter em processos ágeis se não uma documentação ágil? Um projeto sem documentação fica refém do entendimento técnico principalmente dos desenvolvedores de software e do que está na cabeça dos que estão trabalhando nele de perto. Uma documentação que não reflete o sistema e que não evolui com ele também não atende às necessidades de processos ágeis, afinal nesses processos nada está escrito em pedra. Uma documentação viva pode ser uma aposta e uma prática de equipes ágeis que se preocupam em garantir a qualidade do que fazem ao invés de apenas “entregar” o que o cliente solicitou no prazo estipulado. A documentação viva pode estar incluída nas estimativas de tempo e esforço de desenvolvimento como uma prática de garantia de qualidade do time.

Um sistema de documentação viva é essencial e deveria ser de alta importância para todos os envolvidos no projeto, principalmente pela equipe de desenvolvimento. É algo que deveria ser comprado por todos do time, que por sua vez deveria se comprometer a dar muita importância a essa documentação quanto se dá ao código fonte do sistema. Por quê? Porque quem vai dizer daqui a alguns meses o que o sistema faz ou não faz para um stakeholder? Quem vai poder orientar as decisões sobre as mudanças funcionais, seus impactos e estrutura funcional do sistema quando este for de grande complexidade? Quem pode mostrar o esqueleto funcional do sistema sem ter que rodar a aplicação em uma reunião não-técnica? Quem pode mostrar ao time como está o sistema, se funciona como deveria ou tem algo quebrado? Esta função é da documentação do projeto. Mas uma documentação convencional é difícil de manter e de atualizar, demanda muito esforço e não acompanha a evolução do sistema ou suas mudanças. É uma documentação morta, que não cumpre sua finalidade. Por isso a documentação deve ser viva. Viva porque é atual e acompanha o sistema, sendo seu reflexo traduzido em formato não-técnico, ao qual não apenas desenvolvedores ou testers têm acesso e podem entender, mas qualquer interessado no projeto.

Ficou alguma dúvida ou tem algo a dizer sobre o tema? Aproveite os campos abaixo! Até a próxima.

Welcome aboard no Rails 4+

por elessandraestevao

No Rails 4+, a página inicial da aplicação “Welcome aboard” não fica mais em public/index.html (como até no Rails 3), e sim está localizada em uma gem. Ao acessar a aplicação no browser, no log do server dá para saber onde está o arquivo index.html. No meu caso está em:



/home/user/.rvm/gems/ruby-2.2.1/gems/railties-4.1.8/lib/rails/templates/rails/welcome/index.html.erb

 

Atributo acessível por meio de Form no Rails 4+

por elessandraestevao

Para que um atributo de um modelo fosse acessível através de um formulário no Rails, bastava adicioná-lo à lista de atributos acessíveis da classe de modelo, em app/models/class.rb

class Class < ActiveRecord::Base
  attr_accessible :atribute1, :atribute2  
end

A partir de Rails 4, o attr_accessible foi substituído pelo conceito de Strong Parameters.
Para dizer à classe modelo que um atributo é acessível por meio de um formulário, basta adicioná-lo como atributo permitido no método class.params do controller respectivo da classe modelo, em app/controllers/”name_table_db”_controller.rb:


 private    
    def class_params
      params.require(:class).permit(:atribute1, :atribute2)
    end
end

Sobre Padrões de Projeto

por elessandraestevao

Terminando o curso “Design Patterns para bons programadores em C#”,  da Caelum, onde vi alguns padrões de projeto, fui desafiada a escrever a respeito, concluindo o que aprendi no curso.

Sobre Padrões de Projeto, vejo que são soluções elegantes para resolvermos os problemas do dia a dia de desenvolvimento como vários ifs, repetição de código, trechos de código parecidos, alto acoplamento entre as classes e classes e métodos que tem variadas funções (baixa coesão). Os padrões de projeto resolvem esses e outros problemas, visando um código com qualidade.

Os padrões de projeto fazem uso de abstrações como interfaces e classes abstratas. Implementam classes coesas, pequenas, com responsabilidade única, o que facilita o entendimento e manutenção dessas classes, e, também, a expansão do sistema mantendo a qualidade do código. Antes da implementação desses padrões, o mais importante é o entendimento do conceito por detrás de cada um deles, ou seja, por que surgiu e em quais situações deve ser aplicado. Se eu entender o conceito atrás de um padrão, poderei identificar as situações no meu dia a dia de desenvolvimento onde aplicar determinado padrão ou outro, sempre visando um código de qualidade, utilizando os conceitos de Orientação a Objetos.

Em resumo, os padrões de projeto aplicam os conceitos de Orientação a Objetos, como interfaces, classes abstratas, baixo acoplamento, alta coesão, independência funcional, ocultamento de informação. Aplicando padrões de projeto na minha maneira de programar estarei utilizando a OO.