Journey Automação no mundo da L10n!!

Journey Automação no mundo da L10n!!

Feb'14, Reetika Ghai

Automate

As conversas blog sobre a importância da automação no mundo da localização e sua maior necessidade no mundo de Agile

Mudança de Paradigma de Cachoeira para o Agile no Mundo de Localização

Você sabe qual é o animal terrestre mais rápido do mundo, alcançando velocidades de até 113 kmh?

Ao longo dos últimos dois anos, tem havido uma mudança gradual no Software Development Life Cycle (SDLC) metodologia para a maioria dos produtos de proa Adobe. Gestão de produtos passou de um ano do ciclo de vida de desenvolvimento de produtos à base de cachoeira para correr metodologia Agile (baseado em desenvolvimento iterativo e incremental, onde os requisitos e soluções evoluem através da colaboração entre a auto-organização, equipes multifuncionais).

Como resultado da evolução das tendências do mercado, precisamos reinventar a nossa abordagem ao teste de localização para atender as novas exigências de metodologia Agile. No Agile, ciclos de desenvolvimento e de teste são mais curtos, com rápido tempo de resposta. Na localização, volumes de teste têm picos considerando a duração do ciclo de Sprint 2-3 semana. Características requerem validação frequente em vários locais e plataformas antes de certificar para um lançamento em um modelo de lançamento simultâneo (sim-GM). No âmbito Agile, é importante estar ciente dos objetivos de negócio do ponto de vista de localização. Eu classificaria estes em três grandes áreas:

  1. Tempo em caixa lançamentos freqüentes ao mercado: Com ágil a maioria dos produtos da Adobe ter pelo menos um lançamento a cada trimestre para uma freqüência tão elevada como lançamentos semanais / mensais
  2. Âmbito teste Aumento levando ao aumento de esforços de localização: Com cada sprint o escopo legado para certificar LOC construção aumenta
  3. Maior foco no desenvolvimento rápido característica nova com lançamento simultâneo ao mercado: Certificação recursos em plataformas N Local e M em um sprint de 3-4 semana

Esses objetivos criar os seguintes desafios para uma Internacional de Engenharia de Qualidade (IQE) equipe ao decidir o escopo na localizada constrói para testes de localização:

    • Garantir uma maior cobertura de teste sobre os novos recursos, equilibrando a cobertura para áreas de recursos legados
    • Garantir a possibilidade de reutilização de testes em várias variantes da plataforma
    • Garantir a precisão do teste através de cenários repetitivos em vários idiomas
    • Garantir a execução mais rápida de descobrir defeitos no início
    • Certifique-se de todos os recursos funcionam como esperado em todas as plataformas suportadas e localidades
    • Certifique-se de co-existência de diferentes versões dos produtos / patches lançados
    • Certifique-se de enviar o produto ao mesmo tempo em todas as localidades com suporte em todo geografias (sim-GM)
    • Assegurar a cobertura do teste otimizado em todas as localidades com suporte e variantes da plataforma

 

Automação em Agile & Localização

Por que o teste de automação em Localização?

- Vários lançamentos em um ano

- Alto volume de testes

- Complexidade da Plataforma: Combinação local

- Cobertura de teste melhorada levando a uma melhor qualidade

- Escalabilidade

- Mais rápido tempo de mercado

- Eficácia de Custos

Com estes pensamentos iniciais, propusemos para expandir a cobertura de automação de recursos de produto do Dreamweaver de língua Inglês para idiomas localizados em setembro 2012. Nosso objetivo inicial era atingir 45% cobertura automação característica em versões localizadas no que diz respeito à cobertura em Inglês construir na plataforma Mac.

Aos poucos, nós construímos as capacidades de automação de recursos nos próximos seis meses, a partir permitindo a estrutura de automação para a localização (ou seja, adicionou suporte à estrutura de automação para executar scripts do sistema operacional localizada) para a execução de testes de fumaça diárias em todo o 15 idiomas suportados, e, eventualmente, ter uma boa cobertura de automação ao nível de recursos.

Automação é uma ótima maneira de superar os desafios acima e, efetivamente, atingir a cobertura do teste optimizados em localização constrói. Com a automação, seria possível certificar incrementais versões criativas de nuvem para todos os sistemas operacionais suportados e combinações linguísticas apoiar os lançamentos com prazos.

Com vários lançamentos para o mercado em um ano, execução manual do escopo de teste reproduzível pelos fornecedores de localização leva ao aumento dos esforços de teste. A maior parte do aumento do esforço de teste pode ser atribuído ao aumento incremental âmbito teste legado, ou seja, âmbito legado é cumulativo a soma de todas as entregas no passado de um produto e aumentaria com cada sprint. Por outro lado, testes automatizados pode ser executado repetidamente garantindo cobertura definida através de plataformas e combinações linguísticas, contribuindo assim para a qualidade geral do produto para o tempo de liberação em caixa. Isto não só elimina a redundância de teste, mas também ajuda a produzir resultados de teste mais rápidos.

Tendo a área do legado automatizada ajudaria o testador localização focar manualmente o atual Sprint entrega, portanto, descobrir defeitos no início do teste cycle.The IQE preciso ser cauteloso ao decidir o escopo da automação em versões localizadas. Priorizando a cobertura de automação é muito importante.

A cada lançamento trimestral de mercado, o escopo de certificação dos recursos herdados definidos para um produto está aumentando, levando a amplificado esforço de teste reproduzível em vários sprints em comparação com um tempo de validação no modelo de lançamentos anual

Legacy Automation Coverage

Journey into Dreamweaver Automação

Equipe DW Localização tem 88% Cobertura Funcional & 86.5% de cobertura condicional núcleo cobertura w.r.t de 50% cobertura condicional e funcional na versão CC para MAC!

Para a adopção de automação produto em idiomas localizados, nossa jornada olhou, respondendo a algumas de nossas perguntas iniciais:

  • Quais são as características que precisamos para automatizar?
  • Qual será a seqüência de automação característica?
  • O localidades que devemos considerar para começar, com base em dados da história de pré-lançamento e bug?
  • Qual seria a melhor abordagem para a cobertura do teste otimizado nas diferentes localidades?
  • Na estrutura de automação, Onde deve ser as cordas específicas localidade (usado em scripts de teste) ser colocado? Ou devemos puxar as cordas diretamente para comparação do Adobe Localização Quadro (ALF) em tempo de execução?
  • Como é necessário muito esforço para a adoção de automação em localidades?
  • Qual seria a configuração inicial necessário para iniciar a automação nas diferentes localidades?
  • Quanto é necessário um esforço adicional para a execução de scripts de automação em versões localizadas regularmente?
  • Quais serão as necessidades de hardware e o desafio de encontrá-los?
  • Qual deve ser a frequência de automação é executado (fumaça diariamente, plano característica básica, e novo plano de recurso)?
  • Como ter o melhor tempo de resposta de execução em todas as localidades? Qual deve ser a matriz de otimização considerando tempo de resposta rápido em ágil?

Inicial 6 meses jornada para adoção da estrutura de automação para localização Dreamweaver

Time chart

Automation Framework Dreamweaver

Automação Dreamweaver é baseado na estrutura de automação caseiros Adobe chamado de 'Jerry '. O quadro foi desenvolvido pela equipe de Dreamweaver Inglês QE. Ele foi escrito em Java Núcleo, suportado por scripts de maçã e scripts java no backend, fazendo uso da API do Dreamweaver exposto pelos desenvolvedores.

DW framework


O diagrama mostra o fluxo de trabalho de automação:

Passo 1: Um tíquete de trabalho (contém detalhes de configuração como TC #, Plataforma, Detalhes da máquina, informações sobre o idioma, etc) é alimentado ao servidor PULPO.

Passo 2: Servidor Pulpo objetivo principal é o gerenciamento de máquina e registro de resultado. Servidor Pulpo invoca a máquina de teste com base e executa a automação de teste com base no plano mencionado no tíquete de trabalho.

Passo 3: Uma vez que a execução é concluída os log / resultados são copiados para o servidor Pulpo, para posterior análise.

Passo 4: Os resultados são registrados no painel de automação "AutoDash"

O quadro Jerry contém casos de teste automatizados agrupados sob vários planos de teste:

Fuma diariamente - Teste básico para a validação da compilação diária

Plano de recursos básicos - Contém casos de teste do legado e novas áreas de cobertura de fumaça recurso no Studio Test

Plano de Aceitação - Contém aceitação e cobertura de passagem de teste completo para os recursos desenvolvidos no legado e presente ciclo de lançamento no Studio Test

Começamos com uma máquina iMAC dedicada à automação Dw. Contudo, logo após a prova de conceito foi bem sucedida, nós adicionamos uma máquina mais dedicado para automação em versões localizadas. Os planos de teste acima foi executado em uma base pré-programado em todos os 15 localidades no plano de execução predefinido. Bilhetes de trabalho distribuídos em 15 localidades foram alimentados com o servidor Pulpo manualmente ou automaticamente e foram acionados na chegada de novas construções no Codex. Tipicamente, no momento em que chegou ao escritório, construir sanidade foi concluída em todas as localidades e estávamos bom compartilhar as compilações com os nossos parceiros fornecedores.

Para o monitoramento e otimização de cobertura de teste através 15 línguas, um calendário de execução específica foi seguido. Com base no calendário, diferentes planos de teste automação foram executados em várias combinações locales / plataforma em uma base diária. Teste de fumo diário para validação de construção foram executados, seguido de passagem de teste dedicado full característica nos fins de semana. A execução foi pré-agendada ea cobertura do teste foi distribuído entre as localidades para melhores resultados, dado o tempo e as limitações da máquina.

Realizações & Aprendizagens

Realizações

Na Nuvem Criativa (CC) lançamento, que se beneficiou de ter teste automatizado passa localizada constrói através 15 línguas:

  • Eficiência global de cobertura de teste melhorou quatro dobras em comparação com a execução de teste manual
  • Teste de sanidade rápida para a aceitação de construção de localização antes de passar a compilação parceiros fornecedores aumento da eficiência
  • Alcançados rápido tempo de resposta para o teste característica básica de scripts de automação
  • Certificação paralelo em várias compilações (Patch e linha principal constrói)
  • Mais foco na parte nova desenvolvimento características do sprint atual pelos testadores funcionais de localização
  • Certificação de pré-lançamento de construção completamente através da automação
  • Construído projeto e código de verificação Sign através da automação em todas as localidades em 2 horas em comparação com 32 horas de verificação manual

Aprendizagens

  • O apoio da equipe principal: É essencial ter a automação abençoado da equipe de Inglês para suporte ideal. Em caso de Dreamweaver, temos imenso apoio da equipe, especialmente de Kiran Patil (Gerente da Qualidade) e Arun Acidente (Sr. Chumbo Qualidade) para dirigir os esforços de automação em versões localizadas
  • Piloto em estrutura de automação para uma locales 1/double-byte/Cyrillic camada para garantir o quadro era robusto e iria apoiar automação na maioria das localidades
  • Sempre documentar as questões / desafios que enfrentamos durante a criação de automação, eles sempre agir como um ponto de referência mais tarde
  • Garantir os scripts básicos são independentes das cordas Inglês. No Dreamweaver, atualizar os scripts de automação legado para fazer esses scripts são executados na localização foi um grande desafio, como scripts de automação estavam falhando em comparações de strings. Aishvarya Suhane (Localização Automação QE) foi uma grande ajuda para escrever funções na estrutura de automação e criando alguns novos scripts para resolver questões específicas de localização.

Chitas no mundo da localização …

Um agradecimento especial a Guta Ribeiro para inspirar & tutoria me a escrever o meu primeiro Blog & Rakesh Lal por seu apoio.

Adobe Tooling Tradução Automática Para Moisés Apresentado no MT Summit 13

Este artigo foi escrito originalmente em Inglês. Textos em outros idiomas foram fornecidos via tradução automática.

Membros da equipe de MT Adobe estavam na mão na Cúpula MT 13 em Xiamen na China para apresentar as realizações da Adobe MT e demonstrar a próxima geração de ferramentas para a plataforma de código aberto Moisés MT. Membros da equipe da Adobe Ray Flournoy, Yu Gong, Christine Duran, e Jeff Rueppel fizeram a viagem para participar do 4 dia conferência bianual. A conferência se desloca da Europa para a América do Norte e este ano foi hospedado na China pela primeira vez. (Adobe Verão 2011 Estagiário Yifan Hi fez uma pausa de seu cargo tarefas de doutorado e apresentou sua pesquisa também.)

Yu Gong e Jeff Rueppel deu uma demonstração de 3 novas ferramentas Adobe para agilizar o desenvolvimento de motores de tradução automática utilizando o Moisés sistema de código aberto.

(Ferramenta da Adobe Aproveite Scoring)

Funcionários da Adobe demonstrou Scoring Harness Ferramenta da Adobe. (visto acima) O arnês de pontuação é um vários blocos de construção Adobe está colocando em prática para facilitar a automação de MT desenvolvimento de motores e implantação. O chicote de fios de pontuação automatiza o teste de motores de MT, usando padrões da indústria reconhecida pela qualidade motor de qualidade, (Azul, Nist, Meteoro, e TER) e vai permitir o ensaio dinâmico de novos motores contra motores já utilizados para a produção.

Muro de localização

Este artigo foi escrito originalmente em Inglês. Textos em outros idiomas foram fornecidos via tradução automática.


Des Oates
Localization Solutions Architect

A primeira vez que se envolveu na indústria de localização quando entrei Aldus Corporation, na Escócia, no início de 1994 pouco antes de se tornar parte da Adobe. Kurt Cobain ainda era rockin 'n Rollin. Bill Clinton tinha acabado de completar seu primeiro ano de seu mandato e 1 D:Ream foram top das paradas musicais do Reino Unido com 'As coisas só podem melhorar'. Um hino profético para o artigo de hoje.

Naquela época Aldus’ Equipe de localização Europeia composto de um grupo de cerca 40-50 equipe interna composta de Engenheiros de localização, QUE, Os lingüistas, Gráficos / DTP Profissionais, Planejadores e pesquisadores. Uma grande assembléia com certeza. Mas se bem me lembro as nossas capacidades de entrega não foram tão grandes: Para uma versão de software típico, um projeto de localização seria:

  • Alvo não mais do que 10 línguas-alvo, no total
  • Ter mais de 2 ou 3 línguas trabalharam ativamente a qualquer momento
  • Seja o lançamento do software só trabalhou em grandes naquela época
  • Empregam pouca ou nenhuma parceiros externos
  • Levar até 9 meses para concluir grandes projetos.

Nove meses para localizar um produto em 10 línguas. A sério? NASA pode obter um robôs a Marte mais rápido!

Compare-se isto até hoje. Na Primavera 2010 lançamos Adobe Creative Suite 5.0 :

  • 5 Versões Suite.
  • 15 produtos individuais
  • 24 línguas

Mais de 600 aplicações localizadas simshipped * com o Inglês, com 50% redução de erros sobre a versão anterior. Eu acho que você vai concordar que é um passo incrível para cima dos velhos tempos.

Hoje em dia grupo Globalização Adobe é ligeiramente maior do que era naquela época. Nós nos concentramos principalmente na Gestão do Programa, Globalização / Engenharia Liderança e Internacional QE. Quase tudo o resto é tratado por parceiros confiáveis. Estamos sempre à procura de melhorar a nossa produtividade, qualidade, e alcance global. Como tal, fiz uma série de mudanças ao longo dos anos para os nossos processos de nossa equipe e nossa tecnologia. É difícil capturar todas as mudanças que fizemos de forma sucinta em um artigo como este, mas com base nessa experiência, Eu pensei que eu iria partilhar algumas lições que aprendemos ao longo do caminho.

As maiores mudanças que fizemos são nessas áreas interdependentes: Arquitetônico, técnico, e cultural. Aqui estão alguns pontos-chave:

  • Internacionalização. Se bem feito, inicialmente, os benefícios de localização (financeiros e de tempo de colocação no mercado) superam os custos na frente por uma ordem de magnitude. Evangelizar as melhores práticas para o seu I18n tecnologia também é um esforço meritório. Apoio à internacionalização deve ser um critério fundamental no momento de decidir sua plataforma de desenvolvimento para o seu projeto.

 

  • Automação. Estamos sempre nos esforçando para melhorar a automação de localização em nosso negócio. Não pense em localização como um processo humano. Não tem que ser. Poderia ser uma série de passos automáticos, um ou mais dos que podem exigir alguma entrada tradução humana. Como uma regra de ouro, os passos mais manual que você tem em seu processo de localização, o mais caro ele será. Se você usa um GMS, um sistema sob medida, ou apenas um monte de scripts- não importa. Você vai colher recompensas produtividade e reduzir os custos de se empregar confiável, manutenção e automação repetíveis.

 

  • Lançamento / Build Integração. Nos velhos tempos, Engenheiros nossa localização construída a cada componente do software que foi localizada no CD manualmente em sua própria estação de trabalho. Foi sujeito a erros, e trabalhoso e exigiu uma série de QE. Agora todas as versões linguísticas aplicação são construídos como parte de um processo unificado. Localização tornou-se simplesmente de engenharia uma liberação sub-processo, permitindo-nos aumentar os nossos esforços de forma dramática. Se você primeiro otimizar sua automação, faz sentido para integrar o processo em uma configuração versão multilingue único.

 

  • Trusted Partners / Confiando: A área final da mudança foi a maneira que interagimos com outros grupos. Identificamos as barreiras culturais e de comunicação entre nós e os grupos que trabalham com. Em última análise, é necessário estabelecer parcerias eficazes de confiança com as partes interessadas nos processos de sua localização. Pode ser equipes internas, tais como as equipes de desenvolvimento ou unidades de negócios que você precisa para chegar a, ou parceiros externos, tais como LSPs ou de prestadores de tradução.

 

Aqui no Adobe começamos o 'Readiness Mundo’ programação: Uma vantagem de iniciativa da minha colega Leandro Reis que fornece um quadro de avaliação para avaliar a prontidão global de nossos produtos. Junto com destacando os problemas que oferece conselhos e conhecimentos sobre como corrigi-los. Nossos clientes internos "’ foram compelidos por esta abordagem, e os nossos muros de localização interna começou a cair.

Da mesma forma, se você usar os parceiros externos, eles devem estar dispostos e capazes de integrar com o seu negócio – não vice-versa. Que pode exigir alguma formação inicial e mentoring em curso. É fácil decidir não fazer isso, para manter a parede de localização de alta entre você e seus parceiros, throw localização de trabalho e para trás sobre ele, mas esse modelo é mais caro, em última análise. A falta de transparência pode levar a atrasos nos projetos, aumentou as taxas de defeito, e, ocasionalmente, o caos. No entanto, se a agilizar os seus processos de localização própria, inferior de suas paredes de localização e selecionar parceiros competentes dispostos a abraçar seus processos de negócios, então você vai ganhar um parceiro de confiança capaz, e seus parceiros vão ganhar um valor alto, repita-business cliente. A situação ganha-ganha.

Apenas por diversão Eu olhei para cima o número 1 canção nas paradas britânicas, quando a Adobe clientes em todo o mundo começaram a receber suas cópias localizadas do Creative Suite 5 maio 2010…

…”Tempo boms” por Roll Deep.

 

* simship: Não mais do que 5 dias após Inglês