Pensamentos sobre desenvolvimento

Frequentemente entrei no meio de projetos mal conduzidos. O que nos torna cúmplices e altamente envolvidos, ou alguma vez vc já pisou numa m**** e seu amigo do lado não sentiu o cheiro, o pior é ver que tudo foi resultado de abandono de praticas que a anos são garantia de sucesso.

Na minha experiência o projeto que teve a melhor condução, foi audacioso a ponto de retomar praticas iniciais ao projeto para que pudéssemos nos firmar em requisitos que nos serviram construir fortes alicerces, mas pecamos no contato com o cliente, ultrapassamos o prazo de entrega e não cumprimos alguns pouquíssimos requisitos, o que ao meu ver foi um sucesso.

Enfim, mais conhecimento para a carreira…

Participar de um projeto de desenvolvimento de software exige doação, envolvimento, temos o luxo de não ver este belo trabalho com os olhares monetários vendo custos, lucros e prejus como nossos superiores, ficamos com a parte apaixonante. Este envolvimento deve nos levar a tomar certas atitudes ao vê-lo saindo do caminho, que tomaríamos se víssemos um parceiro indo para o lado negro da força. É fato que muitas empresas trabalham com vários projetos em paralelo e leiloam recursos entre eles, e isto deve ser evitado ou conduzido de forma que a pessoa consiga ter o este envolvimento e trabalhe sem uma identificação com o que faz. Isto nos remete às questões de planejamento de iterações (sprints ocorrem em projetos com pessoas dedicadas a somente um projeto) e cada iteração tem seu objetivo no decorrer do desenvolvimento, seja ele uma prova de conceito arquitetural, sua implementação ou a construção efetiva. A equipe deve estar comprometida com ele, ou isso não é a sua vida (querido desenvolvedor, programador, tester, analista e etc.)?

De tudo que vi até aqui acho que a combinação de requisitos bem definidos, comprometimento com o projeto, bom planejamento faz com que as coisas funcionem bem, pois sempre vejo problemas sérios sendo justificados com os tais requisitos falhos. E pra poupar essas justificativas empacantes. O jeito é fazer as coisas do jeito certo.

Um grande problema é que por mais que as empresas façam requisitos e planejem iterações, acabam tornando iterações sinonimo de fase, achando que requisitos e casos de uso são escritos em pedra com as ordens de um ser superior (chamado cliente), ou que é impossível construir casos de uso e desenvolve-los na mesma iteração.

Ao chegarmos ao ponto em que estamos levando a sério os requisitos, entendemos o que o cliente precisa, dividimos os casos de uso entre os desenvolvedores e como num passe de mágica esperamos ver um software rápido, seguro, escalável e qualquer outro nome legal que a IBM coloca em suas propagandas saindo do outro lado. Infelizmente mágica é só entretenimento e frequentemente somos iludidos por elas. Se não elencarmos um responsável que seja um ponto de referência na equipe para bolar e tomar conta da arquitetura, ninguém o fará. Logo acreditamos que ao elencarmos esta atividade isso será algo trivial que será feito rapidinho logo após que tivermos colhidos os requisitos e elaborado os casos de uso, NÃO!!! A arquitetura deve ser bolada no principio e deve ser evoluída e mantida, enfim teremos trabalho até o fim da construção com ela. Afinal é com ela que cumpriremos muitas vezes os requisitos não-funcionais.

Testes… Trabalho Eterno Sempre feito por Todos da Equipe, Sempre!!!

É realmente assim que funciona, verifique os requisitos, os casos de uso a arquitetura candidata, os diagramas, teste o código, a funcionalidade e o software.

Logicamente tudo muito bem organizado em um cronograma que também pode ser verificado, não há problemas nisso eu garanto.

Alguns podem ser rígidos quanto ao esforço exigido nesta árdua tarefa, você poderá justificar com os conceitos que tem, mas sem dinheiro no bolso o projeto não vai pra frente, então automatize tudo que puder, e infelizmente eu não vi até hoje nenhuma ferramenta que faça isso sozinha e você terá que custumizar a sua para o seu projeto, ou seja, terá que implementar as classes para os junits, nunits, runits, a, b,  c units afora. Mas isto felizmente lhe dará o impacto de uma mudança em seu projeto, fará com que esta mesma mudança não dispare um retrabalho braçal e fará com que vc consiga justificar a implementação de algo que distingue do objetivo de implementar o que o caso de uso pede, pois os ganhos são enormes.

Pois bem das atividades principais acho que vimos todas que são realmente importantes de uma forma genérica, haverão problemas de integração, de retrabalho de testes funcionais, mas lhe garanto que se sua equipe faz tudo que foi citado os problemas serão muito menores, muito mesmo…

Nada como fazer do jeito certo para simplificar as coisas…

Ferramenta de automação de testes de UI – Selenium

Uma ferramenta que efetua testes em sua aplicação web como se um usuário a estivesse usando.

Permite que vc bole um script descrevendo os passos que o teste deve seguir e descubra se o teste foi bem sucedido.
Fantástico, não precisamos mais ficar fazendo aquele trabalho de macaco adestrado, testando manualmente uma interface de cadastro… Será???
Bom, para a ferramenta funcionar vc terá que bolar um script, poutz… só mudamos a forma de trabalho de nosso bichinho. Mas e se algo pudesse gravar as minhas ações perante a interface web que estou utilizando… clique aqui, digite a usuário e senha, clique em confirmar, clique lá, clique cá, verifique se foi escrita a mensagem informando que o usuário está logado? hummm Genial!!!
Seu pedido é uma ordem… o Selenium IDE faz isso pra vc… como um gravador de macros do M$ Office. Vc instala um complemento no FireFox e pode gravar seus passos ao usar seu site…

Agora pense naquela idéia maluca que seu professor sempre dizia sobre os testes regressivos onde a qualquer mudança em seu sistema o correto seria testá-lo completamente para certificar-se que está tudo nos conformes… bom conseguiram resolver este probleminha massante…

Mas eu ainda terei que efetuar ao menos uma vez aquele trabalhinho de macaco… e se eu mudar a interface, opa… faça o teste novamente para alterar o antigo script…

Então tá… temos o Selenium Remote Control…

Pronto… agora está completo e não podemos reclamar de nada. Com o Selenium RC, podemos contruir uma aplicação que efetue os testes, ou seja, imagine que um programador muito bão (um mineirinho esperto) desenvolveu uma interface que é montada dinamicamente através de reflection, onde os ids dos campos tem o nome dos atributos das classes, utilizando reflection também é possível montar os testes dinamicamente… Vc consulta esta classe, obtém o tipo, tamanho do campo e etc. com isso podemos efetuar testes aleatórios inserindo textos e caractéres especiais em campos numéricos e ver como o site se comporta… apareceu aquela bunita telinha do tomcat… tchanammm um erro…

O Selenium Core lhe fornece toda a biblioteca para efetuar a interação com a pagina via programação…

Exemplo:

import com.thoughtworks.selenium.*;
import junit.framework.*;
public class GoogleTest extends TestCase {
    private Selenium browser;
    public void setUp() {
        browser = new DefaultSelenium("localhost", 4444, "*firefox", "http://www.google.com");
        browser.start();
    }

    public void testGoogle() {
        browser.open("http://www.google.com/webhp?hl=en");
        browser.type("q", "hello world");
        browser.click("btnG");
        browser.waitForPageToLoad("5000");
        assertEquals("hello world - Google Search", browser.getTitle());
    }

    public void tearDown() {
        browser.stop();
    }
}

O pessoal do OpenQA está de parabéns…

http://www.openqa.org/selenium/