Desenvolver Software é só entender requisitos e escrever código?

Durante os últimos cinco anos de trabalho no desenvolvimento de software fui responsável por entender os requisitos e necessidades dos usuários/clientes e transformá-las em um sistema de qualidade que atenda às expectativas de todos envolvidos no projeto e principalmente pelos que o usarão.

O nicho de mercado em que atuo lida diretamente com técnicos, muitas vezes renomados, que possuem seus próprios conceitos de como as aplicações/ferramentas devem funcionar, desta forma é difícil criar ferramentas reusáveis, ou seja, criamos ferramentas com a mesma função, mas com roupagens diferentes, tal roupagem mina as práticas de reuso, outro problema recorrente é criarmos ferramentas com base no conhecimento técnico do cliente e ao vê-las prontas elas não atendem ao que usuário final precisa ou são de extrema dificuldade de uso, atrapalhando o usuário ao alcançar seu objetivo, muito embora satisfaça um desejo do técnico responsável.

Me questiono sobre qual seria meu papel no projeto, que não o de tradutor de desejos e organizador de ideias. Neste ponto nada mais faço do que traduzir estes desejos e ideias em ferramentas que muitas vezes não se encaixam com a realidade, ora por inviabilidade técnica ou financeira. Um trabalho nada gratificante.

Mas como então deveríamos agir para que estas ideias fossem mais próximas do mundo real, ou que essas elas tivessem um relacionamento com outras e pudessem contribuir para o desenvolvimento de algo mais bem fundado e que pudesse ser compartilhado com outros técnicos de outras áreas.

Não vejo outra forma que não a de influenciar estas mentes. Em meu entendimento uma Empresa com este problema deve atuar menos como desenvolvedora de sistema e mais como agência de publicidade, criando campanhas, divulgando quais são as práticas e ferramentas para construir um projeto de sucesso, atuando em eventos e disseminando o conhecimento que muitas vezes só circula dentro dos escritórios de projetos de software. Nestes meios de comunicação apresentamos as formas de atender aos desejos utilizando ferramentas possíveis, apresentando a estes clientes visões realistas sobre como trabalhar com o conjunto de ferramentas que a empresa oferece. Além de eventos devemos ter meios de comunicação fixos que disseminem essas informações através de revistas, blogs e propagandas em papel, mostrando quais são os caminhos e finalmente direcionando o cliente para que ele resolva seus problemas com um conjunto de ferramentas viáveis, sustentáveis e bem arquitetadas, para que no final das contas todos gastem energia e intelecto com algo comprovadamente útil.

Qto vale seu aprendizado

Aprendizado, bom, algo que poucos seres humanos tem a capacidade e algo que poucos homens utilizam. Nestes 10 anos trabalhando na área de tecnologia já embarquei em várias ondas de balas de prata, onde os maravilhosos eventos faziam com que o desenvolvimento de sistemas se tornasse acessível às massas, era só pegar o “cdzinho” do amigo com o VB6(pois é, na época não dava pra baixar todo o imenso conteúdo de um cd em minutos no seu navegador) e sair criando telas cheias de eventos acessando um banco e persistindo informações. Logo após veio o maravilhoso mundo da multi-plataforma “write once run anywere” em que fez o olho brilhar, programar agora tinha filosofia de vida, eu estudava um conceito e não uma mera linguagem de programação. E então como seres evoluídos que somos “descobrimos” que é melhor organizar tudo do que por a mão na massa, afinal isso era para os nerds que são anti-sociais e não possuem tato com outras pessoas normais da sociedade, teriamos então que planejar tudo, organizar, priorizar, pensar no QA, nos Testes e a Engenharia de software era o que tornaria vc um profissional que entenderia o que o cliente precisa. Novamente tentando seguir as ondas e confuso com as marola que ainda rolava das outras tecnologias e praticas, vê-se ao longe um grupo de pessoas que quer simplificar tudo aproveitar o que há de melhor, estar de mãos dadas com o cliente num caminho maravilhoso em busca da quebra de contratos, foco em valor ao negócio, comunicação e parceria e assim atender às necessidades de nosso insaciável e mal-entendido CLIENTE.
Enfim, durante muita evolução há que ser parar e perceber que não há o que trará uma formula magica ao seu trabalho cotidiano a não ser trabalho trabalho trabalho, e além disso aprenda com seu erros, e seja fiel aos seus preceitos, à sua ideologia e missão. Nossa área não é uma parte da sociedade que viveu durante os ultimos anos desenvolvendo sistemas totalmente bugados que ñ serviam de nada e somente com as práticas atuais sim, eles podem ser realmente bem desenvolvidos, livre de erros, livre de mal-entendidos.Durante esses anos de experiência aprendi com um querido amigo que é muito melhor colocar algum avanço em prática do que defendê-lo com unhas e dentes como a master blaster pratica ou tecnologia que resolverá todos problemas do mundo.
Eu defendo realmente o auto-conhecimento, algo como disse @rodrigoy ação e inspeção em um de seus tweets, O que resolve seus problemas pode criar problemas para outros, e desta forma com seu auto-conhecimento vc saberá distinguir entre balelas e coisas de valor.
Entendam que não estou dizendo para ñ pesquisar e entender as novas ondas, com certeza elas trazem beneficios, só acredito ser a pior coisa do planeta, lançar mão de todos conhecimentos e experiências adquiridas para pega-la.

Desta forma eu continuo defendendo que um grupo se encontre durante um momento para discutir como tem sido resolver os problemas do dia-a-dia e que olhem para os problemas atuais e decidam com o auto-conhecimento qual a melhor maneira para resolve-los e acredito que assim a empresa se torna flexivel para adotar um novo framework ou novas praticas.

Separando melhor na forma que nossos gerentes gostam de ler: Treinamento 70% Trabalho 30%.

Pois acredito que um time em treinamento pode produzir e em trabalho pode responder numa velocidade extremamente alta.
Desta forma acredito que todos terão um grande auto-conhecimento e agirão com rapidez sobre as situações adversas do cotidiano.

Fontes:

- Transformando suor em ouro;

- Experiência;

Levantamento de requisitos

Técnicas:

JAD
Técnica aprimorada pela IBM, digo isso pois qualquer pessoa organizada terá uma organização parecida, já vi isso não vida real.
Consiste em dividir responsabilidades: Temos vários papeis que em resumo são: Facilitador, moderador, corpo técnico, digitador, cliente e usuários.
No caso o Facilitador toma posse da reunião e orienta as conversas num caminho produtivo rumo ao objetivo da reunião, sem deixar que o cliente e os usuários guiem a reunião ao nada;
O corpo técnico composto por analista de negócio e técnicos, discutem uma solução com o intuito de bolar algo aderente ao negócio e tecnologicamente viável de modo a não tomar nenhuma decisão e sim analisar as possibilidades;
Digitador faz algo muito sugestivo, digita tudo que está sendo conversado;
Cliente e Usuários: se degladiam para que o sistema não tenha só a visão estratégica dos gerentes(cliente) muito menos seja cheio de macetes e manhãs para poupar o trabalho dos usuários e gerar algo com pouco foco em coisas produtivas;
Moderador: cuida para que as coisas ocorram no tempo planejado;

RUP
Consiste em criar o As Is e depois o To Be. O analista primeiro entende como é o estado atual do negócio, em seguida bola fluxos to be, que demonstram como será o sistema.
Altamente indicado, pois nos momentos em que o to be está sendo discutido é necessário voltar ao roots para se manter aderente ao que é pratica atualmente e de que maneira o software trará melhorias, evita também que pontos da especificação sejam perdidos.

Processos
Neste ponto temos duas vertentes:
Processo baseado na organização industrial;
Tem base no processo industrial onde há entrada, processo e saída, sendo que a analogia pode ser utilizada perfeitamente para um fluxo de informações onde o dado é consumido, um processo é executado com base neles então uma informação é gerada, os processos ficam encadeados porque uma informação de saída alimenta outro processo e assim por diante;
Processo baseado em BPMN;
Neste processo sinto a falta do fluxo da informação, tudo é baseado em processo e não é fácil enxergar como o dado se transforma em informação ao longo do processo. Trás um mecanismo para registrar as regras referentes aos processos;
Seguindo BPM, esta é uma técnica que analisa gargalos, integrações e propõem uma organização melhor do processo de negócio;

Persona
Em resumo, pois sem pouca coisa deste assunto. É uma técnica que se encaixa muito bem em projetos que desenvolve produtos, ex: Iphone, Pacote Office e etc. Não existe um grupo de usuários que tem o domínio de todas os requisitos do software, desta forma o que há a se fazer é definir persona e interpretá-los, vestir o papel e orientar-se seguindo a necessidade de determinadas personas alvo de venda.

Entrevistas
Já vi esta estratégia sendo usada no mundo ERP, onde a empresa domina o negócio, em alguns casos de maneira melhor que o cliente. Neste escopo há duas estratégias onde pode-se combinar a entrevista com perguntas objetivas e abertas. Vejo que é algo muito de experiência, pois o método não te fala que perguntas fazer.
Mesmo assim este é uma ferramenta que com certeza será combinada com as demais técnicas.

Na pratica a teoria é diferente?

Pois é, na minha tentativa de fazer com que os usuários compreendessem um fluxo de informações por processo para que eles falassem na nossa língua, notei que muita gente além de dificuldade de entender o que nos parece óbvio, há a vontade de cada um de passar este conhecimento da forma que o usuário acha melhor, pois também é o objetivo dele que entendamos e porque não entender como ele se organiza afinal pra ele é mais fácil. Neste conflito vejo cada vez mais que várias maneiras de resgatar o conhecimento esbarram na forma de lidar com pessoas e fica claro que o analista de requisitos, analista de negócio ou seja lá como você queira chamar, deve saber lidar com esses conflitos e não adianta, não há processo nem metodologia que explique detalhadamente como fazer isso.
Bom, do que eu vi a principal qualidade é paciência e compreensão, deixar o usuário falar e estar muito atento às palavras-chaves, pois através delas que você conduzirá a conversa. Você está lidando com o que a pessoa faz na vida, é algo importante, você acha que ela vai contar sem enfeitar, sem te mostrar que é a coisa mais importante do mundo, portanto tenha paciência, ouça e não deixe o usuário se perder, seu principal objetivo é guardar as coisas principais. Quais são as coisas principais?

Bom, vai do feeling do Analista, se o molde será materializado em processo, fluxo de informações ou requisitos o correto é direcionar o que a pessoa está falando neste sentido, deixe claro que você precisa estruturar o que o usuário está dizendo de uma maneira que você e que outras pessoas possam entender, peçam para que ela valide sua forma de entendimento e que compartilhe o mesmo entendimento ao olhar para seu fluxo ou para seu requisito.
Eu prefiro de longe um fluxo de atividades e um diagrama de estado para entidades mais importantes. Além disso algo que surtiu um efeito muito bom foi ter em mente um fluxo macro(Diagrama de Contexto da Análise Essencial) para que você saiba de onde partir e onde chegar em uma conversa de detalhamento de processos, o que lhe ajuda a guiar a conversa com seu usuário , ou seja, até onde parar ou até onde continuar.

Objetivo Final
Bom, o objetivo final é construir um software que esteja de acordo com as necessidades do cliente. Nunca podemos deixar isso de lado, pois inserir um milhão de artefatos e criar outros trabalhos distantes do foco principal é inutil, é inutil discutir ideologias e quem está do lado negro ou do lado da luz, são tantos casos e formas de contratação que não há certo e errado, afinal tanta gente abomina o cascatão e o usam tentando usar a pratica da moda e há casos de sucesso, afinal como é que seria que nossa área se manteria, vejo tantos falando mal do cmmi, me digam como a Índia se tornou uma grande potencia.
Acho que ainda falta muita comunicação entre a área de venda e nós desenvolvedores, enquanto ninguém entender que ambas devem estar sob a mesma asa e que os objetivos devem ser compartilhados, desgastes serão fato.

Usabilidade ao meu ver

Ao trabalhar num projeto onde os usuários eram extremamente exigentes quanto aos detalhes de como a interface gráfica funcionaria, passei a pensar sobre como aquelas exigencias poderiam ser documentadas. Após um tempo vi que seria impossível coletar cada exigência que o usuário faz sobre aquelas dezenas de interfaces, principalmente porque o usuário pedia a alteração, a mesma era implementada e a partir daquela mudança o usuário notava que havia um outro detalhe que poderia ser alterado e como tinhamos 3 usuários chaves cada um fazia suas exigências ao sabor de seu humor.

Vendo aquele grande número de requisitos de interface e usabilidade, um processo iterativo poderia sim ajudar, mas ainda sim esse vai e vem de alterações tinha grandes chances de ocorrer. Abstraindo essas exigências e olhando de outra perspectiva notamos certas similaridades que podem nos ajudar a definir um padrão, como por exemplo processo para cadastro de informações:

• Usuário informa os dados;
• Sistema valida informações;
• Usuário desenha geometria no mapa;
• Sistema valida as regras topológicas;
• Sistema apresenta mensagens de resultado;

Ou como proceder numa alteração por exemplo. Esses procedimentos sempre nos conduzem a um padrão que é replicado às demais telas. Lembrando que me atenho ao aspecto funcional, como a mensagem é trocada entre usuário e sistema. Com relação à aparência de um site, deixo isso na mão de um designer que tem o conhecimento para definir estrutura de exibição das informações, cores, logos e etc.

Unindo-se a esta idéia acredito que a maior parte da responsabilidade em definir como os aspectos funcionais devem ser elaborados é nosso(desenvolvedores), afinal somos nós que trabalhamos o ano todo com centenas de usuários, diversos de projetos e mais do que ninguém temos o conhecimento necessário para definir como a tela se comportará e qual é a melhor forma para definir uma interface que torne a experiência do usuário algo prático, rápido e que controle bem as exceções, evitando que cadastros sejam perdidos, que informações erradas sejam inseridas, retrabalhos e etc.

Os operadores do sistemas convivem com um conjunto de informações em seu dia-a-dia. Estas informações mais relevantes deve sem apresentadas em um plano principal, pois são elas que fornecerão insumo para que seu trabalho seja exercido da melhor forma.

Todo o restante das informações deve aparecer com menor importancia na tela sem que esta importancia reduza este nova informação a um pequeno painel flutuante sobre o restante das informações, afinal por mais que existam outras informações de maior importancia em segundo plano a informação atual deve ser mostrada de forma que a atenção atual fique somente nela e assim que ela perder esta importancia ela é recolhida e não mais está sobre o mapa ou uma tabela dinamica com um resumo das informações.

As vezes imagino pq mostrar mais que 5 paginas… eu não teria tempo no meu trabalho para olhar cada uma delas, acho que as interfaces podiam ser mais dinamicas e um padrão sobre validações, formatos, e coisas que facilitem a vida do usuário seriam melhores tanto para a agilidade da execução do trabalho qto para redução de erros.

Afinal desenvolvemos sistemas para facilitar a vida do usuário, ele não sabe sozinho como isto pode ser feito da melhor forma, fico indignado quando fazemos coisas inferiores pq o usuário não sabe o que quer isto vai de encontro com a ética de um desenvolvedor.

Aí que fico indignado com essa definição extremamente unilateral de papeis, ou seja, definimos que um programador só faz codificar, um analista de requistos os coleta, prioriza e mantém os requisitos e se o usuário não definir o que ele quer podemos usar este documento contra ele, mas veja bem… ele nos contratou para que fizessemos o melhor e é claro que ele vai pagar com felicidade por ele, basta que ele esteja feliz com o software.

Enfim, concluindo sobre os padrões, acredito que definir uma a uma cada tela seja um trabalho muito árduo que exije grande esforço, mas se soubermos que informação exibir e os padrões que definam em que ordem devemos mostrar os dados se devemos priorizar campos requeridos, se devemos ocultar alguns dados não requeridos em grupos, como vamos formata-los. Como exibir as informações mais relevantes ao usuário e como mostrar novas janelas que contribuam para estas informações mais relevantes.

Vejamos um ciclo completo:

Um usuário que é responsável por coordenar a recepção de produtos deve ter um painel que mostre os produtos que necessitam de reposição nas próximas semanas e destes produtos o que já foi solicitado e se há algo chegando dentre os próximos dias. para ele selecionar algo que estava prestes a acabar avisando que é necessário solicitar estoque de reposição. para o vendedor apareceria outro painel com as informações relevantes ao trabalho dele. Contendo uma pesquisa sobre preços dos produtos frequentemente comprados, quais são os produtos que estão a ponto de chegar a reserva de estoque.

Talvez estes painéis representem grande tráfego na rede e alto consumo de processamento, mas tornar o sistema algo que traga valor aos usuários é o melhor caminho.

Talvez as telas que forneçam informações, tornem desnecessários preencher tantas informações para um cadastro.

Outro grande problema são as telas de cadastro, por exemplo… se eu for cadastrar uma rua, certamente eu já estarei no local em que desejo desenha-la neste ponto algumas informações não precisarão ser preenchidas pois o desenho já estará posicionado sobre algum pais, estado, cidade e bairro então pra que digitar tudo isso novamente? bom pra poupar processamento? se seu sistema não puder fazer uma busca em tabelas com no maximo 500 registros seu problema é mais grave, resolva sua infra antes de implementar o software.

Tenho quase certeza que o usuário não pedirá isso, pois isso vai onerar um custo e o pobre do usuário não vai pedir, mas se vc fizer um sistema meia boca, sinto lhe informar mas fará só um.

Enfim, para definir essas caracteristicas não acredito que seja necessário criar um protótipo de tela, uma prova conceitual com certeza, mas criar um protótipo para cada tela em algumas hora eu não vejo necessidade, talvez para determinar os padrões e facilitar a visualização pelo usuário, mas para cada tela eu não acho necessário.

Com tantas linguagens de programação qual escolher?

Tenho visto tantas ondas de mercado e tantos xiitas que auto-explodem quando você diz algo contra a linguagem que ele acredita, que me questiono sobre o que é correto. Pra explicar o que penso, imaginemos um cenário que corriqueiramente encontramos:

– O cliente contrata uma solução em que ele necessita ter em mãos um resumo de suas finanças;

– Noutro momento ele quer planejar com mais tempo seus pagamentos e recebimentos;

– Devido a tanta informação ele precisa que um processo noturno seja executado para conciliar todos pagamentos recebidos com a contabilidade e o estoque;

Ufa… Agora gostaria de convocar um xiita para mostrar uma solução completa com o framework de sua religião… alguns em java usariam tudo, mas já vi resultados de testes que dizem que ruby e python são bem mais rápidas que java, então, esta seria a melhor solução realmente? Da mesma forma o pessoal de .net descreverá toda gama de soluções que .net dispõem, mas e se os dispositivos móveis não tiverem windows como sistema operacional? Ou se então o cliente deseja utilizar ferramentas livres.

Acho que muitas vezes esquecemos que o sucesso só virá se as necessidades do cliente forem completamente solucionadas, ficar nesta guerra nos bastidores ao meu ver nada contribuí, pois muitas vezes encaramos o cliente como um ignorante que não sabe o que quer.

É simples: O sucesso virá se o cliente estiver satisfeito, pouco me importa se isto será feito com fortran, com c, delphi ou ruby and rails. A pergunta é? Você solucionou os problemas do cliente?

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/

Vamos descomplicar essa avalanche de inovações que nos bombardeiam?

Navegando pela net a procura de ferramentas que facilitem meu dia-a-dia como programador me deparei com uma série de blogs, sites de fabricantes e geniais inventores focados cada um em vender seu belo peixe ou demosntrar que em sua lista existem as mais novas bugigangas lançadas no mercado… ooohhh isso é muito divertido… descobrir este monte de inovações as quais exigiram boa parte de seu tempo. Mas qual o verdadeiro ganho? demonstrar para os seus que é um profissional atualizado e está na crista da onda? Resolver velhos problemas com uma nova perspectiva de uma solução?

Bom, acabei descobrindo que saber do ultimo modelo do pen drive que vem pintadinho com um personagem engraçadinho ou ver que exite uma ferramenta que tira de vc aquele suspiro de “poutz… pq não pensei nisso antes” mas na hora H deixa a desejar… não evoluem meu ambiente de trabalho, não melhoram minha produtividade, não aumentam o tempo que dedico a minha família e as tantas coisas saudáveis que por desperdício deste deixamos de lado…

Então inicio este projeto com o intuito de refletir sobre uso destas inovações relacionando aos ganhos que realmente contribuem para o enrigecimento dos pilares que dão significado as nossas vidas.

Bom…… boa viagem a todos nós…