O Olavo Vitor está fazendo uma pesquisa para o seu trabalho de bacharelado em Sistemas, a respeito de Teste Baseado em Risco. Quem puder ajudar ele respondendo o questionário abaixo:

http://bit.ly/q9jXKL

O questionário é bem rápido de ser respondido.

Uma das atividades que faço na nossa comunidade e que foi afetada, é a organização das Mesas Redondas que ocorrem no grupo DFTestes. Atualmente eu apenas abro as votações e inicio as discussões,  não conseguindo mais acompanhar, participar e resumir as discussões, como eu fazia antigamente.

E é exatamente esse o trabalho que estou querendo passar para outra pessoa, pois hoje a minha contribuição é muito baixa, e não consigo dedicar o tempo que seria necessário para fazer um bom trabalho.

Basicamente, as atividades do “Curador” das Mesas Redondas são:

• Abrir a votação 1/2 semanas antes do final do mês;
• Fechar a votação no primeiro dia do mês;
• Abrir a discussão no primeiro dia do mês, do tema mais votado;
• Abrir a discussão no dia 15 do mês, com o tema que ficou em segundo lugar na votação.

Eu particularmente nunca tinha ouvido falar a respeito dele, nem na época que me preparei para a CTFL.

O intuito desse post, é compartilhar esse padrão (enviado pelo Edimilson – obrigado!), e também fazer um resumo a respeito dele.

O que é o IEEE 1028?

Como todo padrão elaborado pelo IEEE (lê-se “I três E”), o 1028 é fruto do trabalho voluntário de alguns membros do IEEE. E sendo um padrão, eles nos traz algumas importantes e relevantes informações a respeito de revisão de software. Mas é sempre bom lembrar, que ele deve ser usado com bom senso, pois o contexto sempre prevalece sob o padrão (ou deveria prevalecer).

O IEEE 1028 nos traz cinco tipos de revisão de software, junto com os procedimento necessários para a execuçaõ de cada tipo. Está fora do escopo do padrão questões como: quando uma revisão se faz necessária? como escolher qual tipo de revisão deve ser usado?

Os 5 tipos de revisão abordados são:

• Revisões gerenciais;
• Revisões técnicas;
• Inspeções;
• Walk-throughs;
• Auditórias.

Os cinco tipos de revisão

Segue abaixo, a tradução do anexo B do padrão, que contém uma tabela comparativa entre os tipos de revisão (o texto original está numa linguagem meio chata de entender, e não consegui melhorar muito na tradução – se notarem algum erro ou melhoria, por favor me avisem):

Abaixo, segue o link para baixar o padrão IEEE 1028:

http://bit.ly/ieee_1028

É… já fazem três anos que o QualidadeBR nasceu, e com certeza há muita história pra contar sobre esses três anos, além do 282 posts que já foram publicados nesse período.

Mas hoje vou deixar um pouco de lado a temática do blog, e falar a respeito de 3 coisas que o QualidadeBR me proporcionou nesses 3 anos.

Conhecer pessoas

Sem dúvidas um dos pontos mais legais de ter criado o QualidadeBR foi ter a oportunidade de conhecer tantas pessoas, desde outros blogueiros até leitores. Vários deles considero verdadeiros amigos, mesmo não conhecendo alguns pessoalmente.

Acredito que esse seja uma das coisas mais bacanas ao se criar um blog, independente do assunto.

Ajudar pessoas

Como sabem o QualidadeBR não possui nenhum tipo de apoio financeiro ou veiculação de propaganda. Nunca ganhei nenhum centavo com ele, e aliás, essa nunca foi a minha intenção (não que eu ache ruim apoiadores ou veicular propagandas, muito pelo contrário).

Mas algo que ganhei e isso não tem preço, é o prazer de poder ajudar as pessoas, seja por meio do próprio conteúdo do blog, ou via e-mail.

Então se você gosta de ajudar as pessoas, criar um blog pode ser uma boa forma de fazer isso.

Aprendizado

A minha intenção inicial com o QualidadeBR era me motivar a continuar os estudos na área de Teste de Software, pois tinha acabado de obter a CBTS, e não queria me acomodar, muito pelo contrário, queria estudar sobre novos assuntos e compartilhar experiências e o pouco que conhecia da área na época.

O QualidadeBR me fez e ainda faz aprender muito, seja durante as pesquisas para um post, firmando conhecimentos durante a escrita ou até mesmo por meio dos comentários dos leitores.

Se você gosta de estar sempre aprendendo, um blog pode ser uma boa forma de motivar os seus estudos e além disso, você estará compartilhando eles com outras pessoas.

Bem é isso. Obrigado a todos leitores por acompanhar o QualidadeBR.

Baseado no Ruby Weekly e derivados (ex.: NoSQL Weekly), o Software Testing Weekly irá trazer toda segunda-feira, um resumo do que ocorreu na comunidade de Teste de Software, tanto em blogs como em grupos de discussão.

Para receber, basta se inscrever no seguinte endereço: http://eepurl.com/3Yvc. E veja um piloto aqui: http://bit.ly/exemplo_stw.

Já nesse post, iremos vê como melhorar os testes que escrevemos, utilizando um helper criado pelo Jeff Morgan.

Mas antes disso, deixa eu contar uma breve história sobre os nossos testes.

O Twitter mudou e quebrou os nossos testes

Como vocês devem ter notado, o Twitter recentemente (coisa de 1/2 meses), mudou a página de login. E a alteração também afetou os ids de alguns elementos da página, como por exemplo, o do text field do login e senha.

Os posts já foram atualizados, mas o que ocorreu é interessante pra ilustrar a fragilidade dos testes que dependem da interface.

Pode parecer estranho, mas tanto testar como desenvolver front-end são tarefas complicadas, principalmente Web (só lembrar das várias tecnologias usadas numa interface Web e os vários navegadores existentes). A sensação e de que quando falamos de sistemas front-end, pisamos num chão mais gelatinoso, e qualquer mudança faz ele tremer.

Para evitar o que ocorreu, o ideal é a equipe de desenvolvimento NÃO MUDAR o id dos elementos,  afinal de contas, para o usuário tanto faz se o text field tem o id username ou login, mas para os Testadores isso importa, e muito. Aliás, para ajudar na nomeação desses ids, estabelecer um padrão pra equipe ou boas práticas pode ajudar.

Bem era isso, agora vamos falar do helper que irá melhorar os nossos testes.

Melhorando os testes

Esse helper é uma mão na roda pra quem utiliza o Watir, com ele vamos passar a escrever menos código e será mais fácil de manter os nossos testes.

O helper mágico que estou falando é o seguinte:

module WatirHelper
  # A helper class to make accessing web elements via Watir easier.
  # All methods take an identifier parameter.  This parameter is
  # an array of hashes that are used to identify an element on the
  # page.  On elements that support multiple attributes you can
  # provide multiple identifiers.
  #
  # This module assumes there is a @browser variable available.

  def self.included(cls)
    cls.extend ClassMethods
  end

  module ClassMethods
    # adds three methods - one to put data in a text field, another
    # to fetch that data, and another to return the actual text_field.
    #
    # Example:  text_field(:first_name, {:id => "first_name})
    # will generate the 'first_name', 'first_name=', and
    # 'first_text_field' methods
    def text_field(name, identifier)
      define_method(name) do
        @browser.text_field(identifier).value
      end
      define_method("#{name}=") do |_value|
        @browser.text_field(identifier).value = _value
      end
      define_method("#{name}_text_field") do
        @browser.text_field(identifier)
      end
    end

    # adds three methods - one to put data in a hidden field, another
    # to fetch that data, and a third to return the hidden field.
    #
    # Example:  hidden(:first_name, {:id => "first_name})
    # will generate the 'first_name', 'first_name=' and
    # 'first_hidden' methods
    def hidden(name, identifier)
      define_method(name) do
        @browser.hidden(identifier).value
      end
      define_method("#{name}=") do |value|
        @browser.hidden(identifier).set(value)
      end
      define_method("#{name}_hidden") do
        @browser.hidden(identifier)
      end
    end

    # adds three methods - one to select an item in a drop-down,
    # another to fetch the currently selected item, and another
    # to return the select_list.
    #
    # Example:  select_list(:state, {:id => "state"})
    # will generate the 'state', 'state=' and 'state_select_list'
    # methods
    def select_list(name, identifier)
      define_method(name) do
        @browser.select_list(identifier).value
      end
      define_method("#{name}=") do |value|
        @browser.select_list(identifier).set(value)
      end
      define_method("#{name}_select_list") do
        @browser.select_list(identifier)
      end
    end

    # adds three methods - one to check, one to uncheck and
    # a third to return a checkbox
    #
    # Example: checkbox(:active, {:name => "is_active"})
    # will generate the 'check_active', 'uncheck_active', and
    # 'active_checkbox' methods
    def checkbox(name, identifier)
      define_method("check_#{name}") do
        @browser.checkbox(identifier).set
      end
      define_method("uncheck_#{name}") do
        @browser.checkbox(identifier).clear
      end
      define_method("#{name}_checkbox") do
        @browser.checkbox(identifier)
      end
    end

    # adds three methods - one to select, another to clear and
    # another to return a radio button
    #
    # Example:  radio_button(:north, {:id => "north"})
    # will generate 'select_north', 'clear_north', and
    # 'north_radio_button' methods
    def radio_button(name, identifier)
      define_method("select_#{name}") do
        @browser.radio(identifier).set
      end
      define_method("clear_#{name}") do
        @browser.radio(identifier).clear
      end
      define_method("#{name}_radio_button")  do
        @browser.radio(identifier)
      end
    end

    # adds three methods - one click a button, another
    # to click a button without waiting for the action to
    # complete, and a third to return the button.
    #
    # Example:  button(:save, {:value => "save"})
    # will generate the 'save', 'save_no_wait', and
    # 'save_button' methods
    def button(name, identifier)
      define_method(name) do
        @browser.button(identifier).click
      end
      define_method("#{name}_no_wait") do
        @browser.button(identifier).click_no_wait
      end
      define_method("#{name}_button") do
        @browser.button(identifier)
      end
    end

    # adds three methods - one to select a link, another
    # to select a link and not wait for the corresponding
    # action to complete, and a third to return the link.
    #
    # Example:  link(:add_to_cart, {:text => "Add to Cart"})
    # will generate the 'add_to_cart', 'add_to_cart_no_wait',
    # and 'add_to_cart_link' methods
    def link(name, identifier)
      define_method(name) do
        @browser.link(identifier).click
      end
      define_method("#{name}_no_wait") do
        @browser.link(identifier).click_no_wait
      end
      define_method("#{name}_link") do
        @browser.link(identifier)
      end
    end

    # adds a method that returns a table element
    #
    # Example:  table(:shopping_cart, {:index => 1})
    # will generate a 'shopping_cart' method
    def table(name, identifier)
      define_method(name) do
        @browser.table(identifier)
      end
    end

    # adds two methods - one to return the text within
    # a row and one to return a table row element
    #
    # Example: row(:header, {:id => :header}) will
    # generate a 'header' and 'header_row' method
    def row(name, identifier)
      define_method(name) do
        @browser.row(identifier).text
      end
      define_method("#{name}_row") do
        @browser.row(identifier)
      end
    end

    # adds a method to return the text of a table data <td> element
    # and another one to return the cell object
    #
    # Example:  cell(:total, {:id => "total"})
    # will generate a 'total' method and a 'total_cell'
    # method
    def cell(name, identifier)
      define_method(name) do
        @browser.cell(identifier).text
      end
      define_method("#{name}_cell") do
        @browser.cell(identifier)
      end
    end

    # adds a method that returns the content of a <div>
    # and another method that returns the div element
    #
    # Example: div(:header, {:id => "banner"})
    # will generate a 'header' and 'header_div' methods
    def div(name, identifier)
      define_method(name) do
        @browser.div(identifier).text
      end
      define_method("#{name}_div") do
        @browser.div(identifier)
      end
    end

    # adds a method that returns the content of a <dd>
    # and another method that returns the dd element
    def dd(name, identifier)
      define_method(name) do
        @browser.dd(identifier).text
      end
      define_method("#{name}_dd") do
        @browser.dd(identifier)
      end
    end

    # adds a method that returns the content of a <dl>
    # and another that returns the dl element
    def dl(name, identifier)
      define_method(name) do
        @browser.dl(identifier).text
      end
      define_method("#{name}_dl") do
        @browser.dl(identifier)
      end
    end

    # adds a method that returns the content of a <dt>
    # and another that returns the dt element
    def dt(name, identifier)
      define_method(name) do
        @browser.dt(identifier).text
      end
      define_method("#{name}_dt") do
        @browser.dt(identifier)
      end
    end

    # adds a method that returns the content of a
    # <form> element and another that returns the
    # form element
    def form(name, identifier)
      define_method(name) do
        @browser.form(identifier).text
      end
      define_method("#{name}_form") do
        @browser.form(identifier)
      end
    end

    # adds a method that returns a the content of a
    # <frame> element and another that returns the
    # frame element
    def frame(name, identifier)
      define_method(name) do
        @browser.frame(identifier).text
      end
      define_method("#{name}_frame")  do
        @browser.frame(identifier)
      end
    end

    # adds a method that returns an image <image> element
    def image(name, identifier)
      define_method(name) do
        @browser.image(identifier)
      end
    end
  end

  def content
    @browser.text
  end

  def visit_page(page_url)
    @browser.goto(page_url)
  end

  def page_title
    @browser.title
  end

  def wait_for_page
    @browser.wait
  end
end

Os comentários feitos pelo Jeff já explicam muito bem o que esse helper faz. Mas mesmo assim deixa eu dá uma explicação rápida, sobre a magia por de trás dele: Basicamente ele facilita a definição dos elementos da página. Provendo tanto o setter quanto getter dos elementos que iremos interagir durante o teste, além de prover o objeto do próprio elemento.

Pra utilizar esse helper, basta fazer o include, o que irá fazer com que a classe HomePage “ganhe” todos os métodos dele, como por exemplo o método page_title, que irá retornar o título da página que está aberta.

Abaixo está como ficou o código dos nossos testes com a utilização desse helper.

require 'rubygems'
#require 'watir'
require 'firewatir'
require 'lib/watir_helper.rb'

module Twitter

  class HomePage
    include WatirHelper

    HOME_PAGE = 'twitter.com'

    link(:tweet_button, :class => 'tweet-button button')
    link(:tweet_button_disable, :class => 'tweet-button button disabled')
    text_field(:username, :name => 'session[username_or_email]')
    text_field(:password, :name => 'session[password]')
    text_field(:editor, :class => 'twitter-anywhere-tweet-box-editor')
    button(:sign_in_submit, :class => 'submit button')
    div(:message, :class => 'tweet-text')

    def initialize
      @browser = Watir::Browser.new
    end

    def visit
      @browser.goto(HOME_PAGE)
    end

    def login(username, password)
      self.username = username
      self.password = password
      self.sign_in_submit
    end

    def type_message(message)
      self.editor = message
      self.editor_text_field.fire_event('onMouseDown')
    end

    def tweet
      self.tweet_button
    end

    def message_exists?(message)
      @browser.wait_until {self.message_div.text == message}
    end

    def alert_message_exists?(message)
      @browser.wait_until {@browser.text.include? message}
    end

    def tweet_button_is_disabled?
      @browser.link(self.tweet_button_disable_link.exists?)
    end

  end
end

O que ganhamos utilizando esse helper, você pode estar se perguntando. Basicamente duas vantagens.

Definição mais simples dos elementos web

Ganhamos três métodos  pra cada elemento:

• um pra setar o valor do elemento (setter): self.username =
• outro pra retornar o valor do elemento (getter): self.username
• e por fim um que retorna o próprio objeto do elemento: username_text_field (podemos utilizar qualquer método do objeto TextField)

• o NOME_DO_SEU_ELEMENTO_text_field é para o caso do elemento ser da classe TextField. Se for um div, seria _div, se fosse um button seria _button e assim vai.

Para quem não sabe, “o melhor da semana” era uma compilação do que lia durante a semana e achava interessante, a respeito da área de Teste de Software e relacionados.

Pois então, “o melhor da semana” não irá mais existir, porém ele não irá morrer. O que ocorrerá, aliás já ocorre, é que estou compartilhando os posts que acho interessante no Twitter do QualidadeBR.

Portanto “o melhor da semana” não chegou ao fim, apenas mudou de plataforma.

Então agora é só seguir o Twitter do QualidadeBR para se manter informado. Tento “tweetar” ao menos uma vez ao dia, e diferente do meu Twitter pessoal, o @QualidadeBR tem apenas conteúdo de Teste de Software.

E dê uma olhada nas duas listas (1 e 2) do QualidadeBR para conhecer o pessoal de Teste de Software que está no Twitter, vários costumam postar um conteúdo bem relevante sobre a área.

Abraços!

P.S: Caso você não tenha um Twitter e não queira ter, você pode assinar o feed do @QualidadeBR: http://bit.ly/feed_qualidadebr

Embora tenha tido poucas respostas, a mesa redonda gerou um bom conteúdo. Confira ele nos próximos parágrafos.

Devemos gerenciar os riscos de teste separados do desenvolvimento?

A Ana Paula respondeu a pergunta, contando um pouco da sua experiência:

O gerenciamento de riscos deve ser feito em conjunto com o planejamento estratégico da empresa, e principalmente com o desenvolvimento. A depender da demanda dos setores relacionados ao setor de Qualidade, todo o planejamento interno pode mudar.

Um exemplo desta situação, onde trabalho, é a obrigatoriedade do PAF-ECF na Bahia. Nós, do setor de Qualidade, cuidamos da homologação. Porém o desenvolvimento precisa estar atento aos prazos e aos novos requisitos inseridos pela secretaria da fazenda. Sem um planejamento conjunto, os riscos serão maiores.

Na minha opinião, depende do contexto. Se a equipe de teste é separada da de desenvolvimento, é bem provável que sim. Mas mesmo assim, haverá riscos inerentes as duas áreas, e que portanto deverão ser tratados por ambas as áreas.

Agora riscos relacionados exclusivamente com a área de Teste, podem muito bem se tratados separadamente, pelo responsável/gerente pela equipe.

Quais são os riscos mais frequentes em teste de software?

A Ana Paula citou três riscos mais frequentes:

- Implementações que geram outros erros (muito frequente quando não tem-se uma documentação bem estruturada ou uma matriz de rastreabilidade de requisitos);

- Pouco investimento em testes e qualidade e, consequentemente, falta de profissionais qualificados (falo isso pela situação na Bahia! Aqui poucas empresas investem.)

- Prazos apertados.

A Ana Paula tocou em três riscos que acredito que são os mais comuns:

1. Qualidade dos builds/versões;
2. Falta de profissionais qualificados;
3. Atrasos.

O primeiro é um risco bem enjoado pra se gerenciar, pois ele é externo a equipe de Teste de Software, principalmente, quando essa se encontra separada da equipe de Desenvolvimento. Portanto, o que devemos fazer é propor ações para mitigar esse risco, como por exemplo:

• Realização de testes unitários e integrados pelos desenvolvedores;
• Implementar integração contínua;
• Estabelecer uma métrica para que a versão/build seja considerado testável pela equipe de Testes, por exemplo, passar em 90% dos testes unitários e integrados;
• Promover treinamentos aos desenvolvedores, tanto em relação a linguagem e boas práticas, quanto sobre o domínio de negócio do software.

Já o segundo podemos ter as seguintes ações:

• Desenvolver talentos internamente;
• Ter uma certificação/treinamento interna para balizar os conhecimentos dos profissionais;
• Terceirizar os testes.

E o último, que é um dos riscos que mais tira o sono do pessoal (literalmente rs). Podemos:

• Entregar/apresentar o software em intervalos mais curtos;
• Revisar as estimativas a cada ciclo de desenvolvimento;
• Monitorar o tempo gasto com as atividades;
• Identificar possíveis gargalos e impedimentos que possam ocorrer (por exemplo, a máquina de integração contínua está muito lenta – trocar para uma máquina melhor);
• Priorizar as atividades e buscar entregar o que agrega mais valor ao cliente primeiro.

A Sarah levantou uma ideia bem interessante, e que faz todo sentido para ser armazenado numa “base de conhecimento”, além de explicar alguns riscos, baseada em duas últimas experiências:

Cada projeto é um projeto, mas não sei se vocês têm a mesma impressão que eu, mas parece que tem riscos que podiam vir junto com o template do documento que registra/acompanha os riscos :)

Algumas das ultimas experiências que eu tive:

- Projeto de consultoria: Quality Assessment

Equipe de testes 90% terceirizada no modelo fábrica.

Por que é um risco: Porque a empresa se envolvia muito pouco no ‘modus operandis’ do terceiro e problemas que encontrássemos que tivesse raiz na fábrica tinha pouca probabilidade de ser resolvido. Além disso, tínhamos acesso restrito às informações sobre esse ‘modus operandis’ e o terceiro tinha todo direito de não nos atender.
Impacto: Altíssimo
Probabilidade: Alta
Ações previstas: Reuniões entre os lideres da empresa e do terceiro para explicar a nossa forma de trabalho, explicando que não se trata de uma auditoria de contrato e que as respostas seriam confidenciais e a própria empresa contratante não teria acesso a essas respostas diretamente.

Equipe de testes interna com auto estima muito elevada

Por que é um risco: Estranho não? Mas é que é complicado tu dizeres pra uma pessoa que o que ela acha que ela faz melhor que a grande maioria não é bem assim.

Impacto: Altíssimo. Se não quiserem nos ouvir, o projeto não gera nenhum resultado.
Probabilidade: Média. Não era possível aferir mais que isso porque ainda não conhecíamos a maturidade da equipe.
Ações previstas: Reuniões intermediárias de apresentações de findings para ”preparar o espírito” para o relatório final.

Bom, esses eram os tops em minha opinião. Mas claro, sempre existem vários outros como confiança e conseqüente cooperação das áreas correlatas no trabalho realizado (um trabalho de quality assessment não pode contar somente com a equipe de testes como entrevistado e colaborador, precisa ser um trabalho holístico); previsão de orçamento interno para implantar as melhorias sugeridas; entre outros.

Esses trabalhos de consultoria são bem legais (eu gosto pelo menos rs), tem que ter conhecimentos diversos na área de TI pra meter o bedelho na área de todo mundo, mas principalmente tem que desenvolver bem um trabalho psicológico para não ferir os brios de ninguém, inspirar confiança e influenciar pessoas de modo a convencê-las dos ganhos que as mudanças podem trazer.

Já num outro projeto de delivery, eu entro em todos os pontos que o Fabrício e a Ana falaram, e ainda acrescento alguns complicadores como:

- A equipe de desenvolvimento já havia comunicado que não iria fazer testes unitários
- A data do projeto é uma daquelas datas previstas por astrólogos e negociadas com os deuses do Olímpio e se tu não cumprires vai ter toda uma vida de má sorte
- Um dos momentos mais emocionantes foi descobrir que não tinha tempo de re-trabalho previsto no cronograma.

Enfim. A gente tá sempre fazendo malabarismos na nossa área. Impressionante. Um bom gerenciamento de riscos permite NO MÍNIMO manter os olhos de todos abertos para todos os “problemas inevitáveis que estão por vir”, e com um pouco de sorte, conseguir impedir que alguns deles cheguem a afetar o projeto.

A propósito, outra experiência interessante desse ano foi ouvir: “Estou cansado de ouvir as pessoas falando nas reuniões de projeto sobre risco de não entrega de infra-estrutura. Está marcada para o dia 30/10. Atrasou? Não. Então não é um risco!”. É muito importante que antes de entrar numa reunião sobre riscos, os participantes tenham idéia de O QUE É um risco. Ajuda a acalmar os ânimos rs.

Além dos já citados, eu acrescento:

• Não ter um ambiente de teste próximo do de produção;
• Falta de expertise em determinada ferramenta;
• Ausência de ferramentas para determinado teste;
• Dificuldades em manter os testes automatizados;
• etc.

Esse foi o resumo da 33ª Mesa Redonda DFTestes, se você quiser saber como foram as outras mesas redondas, confira os outros resumos.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Como a discussão foi curta, abaixo segue praticamente a íntegra das contribuições feitas pelo Elias e pela Lidiane e também alguns comentários meus.

O Elias abordou vários pontos relevantes, entre eles o insight de que uma especialização na área de Teste de Software, não precisa ser necessariamente na área. Pode parecer estranho, mas é verdade:

Acredito que a especialização em si na Área de Teste não é apenas sobre a área (ex: uma pós em Gestão de Qualidade ou Teste de Software), e sim mais sobre o negócio onde trabalhamos (SOA, Sistemas Distribuidos, Mobile, etc…)

Claro que esse meu pensamento é um pouco puxado para o lado técnico.

Sempre acreditei que o profissional em teste é um dos mais completos, por causa da variedade de conhecimentos que ele precisa ter para desempenhar sua função (óbvio que dependendo do papel/nível do mesmo). Logo, penso que a carreira de um profissional de teste é cheia de conhecimento “fora-teste” (análise de requisitos, programação, etc..)

Hoje, dentro da área acadêmica (Especialização, Pós, MBA) eu vejo quase que 100% formações de líderes, analistas de qualidade ou correlatos. É muito difícil encontrar algum curso acadêmico mais técnico em teste, ou que pelo menos ensine técnicas de teste, algumas ferramentas, etc…

Vejo que o profissional, se deseja algo mais técnico, tem que recorrer a uma destas áreas acadêmicas fora de teste ou recorrer a um mestrado para desenvolver algo diferente. É um ponto que as universidades estão amadurecendo, mas muito lentamente (se pensarmos o número de matérias de programação x número de matérias sobre qualidade e teste de software)

Eu fiz uma Pós em Teste de Software (onde vi toda a área de validação) na Unieuro, e recomendo. Apesar de eu já ter o conhecimento do que eu tive na pós, eu a procurei alguns motivos: ter outras visões do mesmo assunto e ter uma certa comprovação acadêmica. Hoje já recorro a cursos dentro da minha área de especialização que mais me interessam.

A minha dica é que na hora da escolha de uma especialização na área, em termos acadêmicos, que o profissional saiba qual linha ele quer/vai seguir, pois para a linha técnica não existe muita coisa.

Aproveito pra listar aqui algumas instituções acadêmicas ao redor do Brasil que possuem cursos voltados para a área de Teste e Qualidade de Software (sugestão de ficar como um thread separada depois)

- Unieuro (Brasília/DF) – MBA em Teste de Software (Pós Graduação) [não existe mais]

- Feevale (Novo Hamburgo/RS) – Teste e Garantia da Qualidade de Software (Pós Graduação)

- Unisinos (São Leopoldo/RS) – Qualidade de Processos de Software (Tecnológico)

- FIAP (São Paulo/SP) – MBA em Gestão da Qualidade em Software com ênfase em CMMi e MPS.BR (Pós Graduação) [não existe mais]

- SENAC (São Paulo/SP) – Gestão da Qualidade de Software (Pós Graduação)

 

 

 

- UNICAMP – Especialização em Engenharia de Software

A Lidiane contou um pouco da sua experiência e lembrou que participar de eventos é uma forma de buscar se especializar e também de compreender melhor a área e a sua amplitude:

Realmente esse tema é muito importante e legal. Vejo muitas pessoas que estão na área de teste que não sabem que os profissionais dessa área podem ter uma carreira.

Em relação a especializações, existem muitos cursos legais de ferramentas, automação de testes, implementador MPT.BR, TMM. Vejo que há bastante cursos online e/ou semi-presencias, mas não são muito divulgados

Pós-Graduação, eu vejo que é muito interessante na area de Engenharia de Software, Qualidade de Software, é muito importante analisar a grade, pois tem algumas pós que não abordam muito o tema Teste SW.

Na Poli tem alguns cursos bem legais de especialização e extensão vejam no site www.pecepoli.com.br , temos a Iterasys com os cursos preparatórios para certificações, mesmo que vc não faça a prova, o curso acaba sendo muito legal e você consegue praticar algumas coisas no dia-a-dia.

Eu atualmente tento frequentar os eventos de teste como o Brateste, Conferencias – inclusive fui no TDC 2010 realizado em Agosto, WorkShops, estou sempre antenada nas novidades e visitando blogs relacioandos a Qualidade e Teste SW.

Por fim, termino agora em novembro o MBA em Teste de Software pela Unieuro, o curso é bom tirando algumas falhas da instuição em relação ao atendimento ADM e Financeiro… *rs

Eu achei super válidas as contribuições do Elias e da Lidiane, e retratam bem as formas que podemos nos especializar na área de Teste de Software.

Na minha opinião, a especialização hoje é encarada pelos profissionais, basicamente de duas formas:

• O profissional gosta da área e quer se aprofundar melhor nela, ou está buscando cobrir lacunas da graduação e conhecer outras áreas (ex.: ao fazer uma pós em Engenharia de Software);
• A outra forma, são os profissionais que estão buscando status e aumento. Afinal, é bunitinho falar que é pós-graduado e para algumas empresas, o título mostra que o profissional é mais qualificado que outro que não possui uma pós. Essa abordagem é perigosa, porque você pode acabar fazendo um curso que não gosta ou que o seu perfil não encaixea Além do que, essa visão de que ser pós-graduado é igual ser melhor do que os que não são, é uma visão alienada.

Eu particularmente, prefiro uma pós-graduação fora da área de Teste de Software, para quem está na área de Teste de Software. Caso o seu perfil seja mais gerencial, busque uma pós de gestão ou um MBA, agora caso o seu perfil seja mais técnico, busque então uma pós em Engenharia de Software.

Escolha bem o curso e não vá na “hype”, afinal uma pós-graduação, geralmente exige um investimento financeiro grande. Faça a sua escolha com bastante parcimônia.

E lembrem-se: nem sempre se especializar, significa se matrícular num curso de pós-graduação, hoje em dia há outras opções.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Essa mesa redonda teve 7 respostas e 7 participantes, sendo eles: eu, Lidiane Santos, Shmuel Gershon, Felipe Silva, Fermiano de Queiroz, Sarah Pimentel e Ueslei Silva.

É possível realizar documentação de testes quando trabalhamos com metodologias ágeis? Digo, desde o plano de teste até o caso de teste, isso é possível?

A Lidiane deu a sua contribuição dizendo:

É possível sim, fazer documentação em um proceso ágil, mesmo porque você começa desenvolvendo em cima dos cenarios de testes que foram levantados.

E eu já trabalhei muito em empresas que não utilizam o processo agil, mas já testei muito software sem documentação, indo apenas pela intuição e conforme vou testando vou documentando os testes.

Acho que essa associação de Teste de Software = Documentação e Burocrácia é coisa do passado.

Para o Shmuel, você pode tanto documentar, como não documentar, quando está trabalhando com metodologias ágeis:

É possivel realizar documentacao de testes quando trabalhamos com metodologias ágeis.

E também, é possível não realizar documentação de testes quando trabalhamos sem metodologias ágeis. Surpresa!

O Fermiano contou um pouco da sua experiência atual:

Sei que existem testadores que usam deste argumento, mas também vejo testadores fazendo o contrário. Felizmente, aqui a maioria encara os desafios da função e assume os riscos, sedentos por um teste exploratório. Documentação também depende do processo utilizado, precisamos seguir os planos de testes para garantir o sucesso obtido em projetos anteriores. Em nosso processo temos uma variedade de testes, com base em planos de teste e, também, exploratórios, em várias etapas. Toda a documentação “necessária” para os testes é gerada durante essas etapas, de acordo com cada etapa do processo.

A Sarah tocou num ponto bem importante, o de que as metodologias ágeis muitas vezes não são utilizadas corretamente, e passam a ser apenas para mascarar que não está sendo utilizado nenhuma metodologia:

Pois é.. Uma questão é que muitas vezes quando alguém me diz “nesse projeto vamos usar metodologias ágeis” me dá um frio na espinha e eu já saio correndo pra mesa do SQA dizendo pra ele fazer alguma coisa, porque em muitos casos eu sei que ‘usar metodologia ágil’ é uma desculpa pra não usar metodologia alguma. A metodologia passa a ser: precisamos entregar para o cliente um monte de pedaços de sistemas e fazer várias entregas e rápidas.

Completamente deturpado. Não existe envolvimento próximo do cliente, não tem ninguém capacitado na equipe para conduzir o time nas práticas da metodologia escolhida, a equipe é formada por um grande numero de profissionais juniors, ou seja: tem tudo pra ser um desastre.

Não tô dizendo que NINGUÉM sabe fazer projeto ágil, por favor. Tô dizendo que HÁ CASOS, em que ‘metodologia ágil’ é desculpa para não usar metodologia alguma. Se não tiver um responsável fazendo às vezes de SQA (no sentido de orientar a equipe e até mesmo intervir na escolha da metodologia) o negócio desanda feio.

Então metodologia ágil pode ou não ter o teste documentado, dependendo da necessidade do projeto.

Se para testar é necessário ter uma vasta documentação, já discutimos isso antes. A minha opinião é: não.

O Ueslei compartilhou um pouco da sua experiência:

Depende!

Atualmente estou alocado em uma empresa que usa desenvolvimento ágil. Junto com o Desensolvimento, estão 3 pessoas encarregadas pelos testes.

As histórias de usuário criadas pelo desenvolvedor, são levantadas com base nas especificações que são realizadas por uma área específica.

A equipe de teste, utilizam tais especificações para realização da primeira bateria de testes.

Mas, isso não é tudo. Temos também uma outra equipe de testes, com perfil de homologação/aceitação, mas que explora os sistemas com maior granularidade do que os conhecidos testes de aceitação.

Esta equipe, é formada por 10 colaboradores. Esta equipe, também com base nas especificações, geram documentos de casos de teste e automação de teste.

Bom! no nosso ambiente, além de ágil, temos outros processos que suportam as necessidades e geram artefatos. Mas, mesmo que uma organização use ágil puro, ainda sim, seria interessante usar documentos, mesmo que simples. Por exemplo, mapas do que é interessante ser testado. Assim, o conhecimento não fica tácito nem corre-se o risco de algo importante cair no esquecimento.

Eu acredito que sim. Porém, pensando em uma equipe que é realmente ágil ou pelo menos busca respeitar os princípios ágeis, talvez não seja necessário realizar um plano de teste. Copiando e colando um exemplo que dei num comentário no blog As Especialistas, relacionado ao assunto:

Segundo o Shmuel:

Um dos motivos da ligação Teste de Software –> Documentação é esse mesmo, os testadores passarem o tempo tentando provar que da pra documentar, e tentando gerar documentação suficiente pra se proteger atrás dela. Quem nunca ouviu um testador falando: “Testei o que está nos requerimentos”, “esse bug eu perdi, porque não esta no plano de testes”, “Já terminamos os testes: 100% do plano de testes”… ? Acho que essa associação é culpa nossa, mais do que culpa deles.

O Felipe Silva comentou a resposta do Shmuel dizendo:

Que jogue a primeira pedra aquele que nunca se protegeu atrás de documentação.

Na minha opinião, a documentação acaba sendo uma forma da gente se defender. E além disso, muitos profissionais foram influenciados por processos que tem em sua saída a produção de artefatos. Então, acabamos utilizando a documentação até mesmo em ocasiões onde ela não é necessário (ex.: comunicação).

Fique por dentro das novidades, assine o feed do QualidadeBR.