Já na Udemy o Curso "Selenium WebDriver Superando os Problemas."
Acesse o link abaixo com desconto.
domingo, 9 de outubro de 2016
terça-feira, 20 de setembro de 2016
Multiplataform Hyper-V Manager using Python and FreeRDP
HYPY - HYper-v in PYthon
Multiplataform Hyper-V Manager using Python and FreeRDPHow HYPY works?
Hypy uses winrm to comunicate with hyper-v server shell and sends powershell commands to interact with the virtual machines. Using Powershell, HYPY can get Name, ID and state of virtual machines. Therefore, HYPY call freeRDP with vm-id and credentials, using settings in.conf file to connect the vm.Pre-requisites
WinRM
Hypy uses winrm to communicate with the hyper-v host, so it must be enabled and accepting connections. https://github.com/diyan/pywinrm has a session explaining how to Enable WinRM on the remote host.
FreeRDP
FreeRDP binary must be in path (windows, linux and mac). Make sure FreeRDP is working before using hypy or it will not open the session to the virtual machine. If you are using Linux, you package manager should have freerdp avaiable or look into https://github.com/FreeRDP/FreeRDP for install instructions.
Configuration
To configure Hypy, change the file 'hypy.conf'[credentials]
host = <server name in domain>
domain = <domain name>
user = <user name in server>
pass = <password>
[options]
cache_file = <name of cache file>
sync_interval = <interval in hours to make new cache file>
usage
If you don't know how to use hypy, you can usehypy.py --helphypy.py --help
Usage: hypy.py [OPTIONS] COMMAND [ARGS]...
Multiplataform Hyper-V Manager using Python and FreeRDP
Options:
--help Show this message and exit.
Commands:
connect Connect to virtual machine identified by...
create Create a new snapshot with vm's current state
delete Delete a machine's snapshot by name
list List virtual machines and its indexes
pause Pause virtual machine identified by index
restore Restore virtual machine snapshot
resume Resume (paused) virtual machine identified by...
snaps List virtual machine snapshots
start Start virtual machine identified by index
stop Stop virtual machine identified by index hypy.py COMMAND --helpAutor: Gabriel Avanzi. https://github.com/avanzzzi/hypy
domingo, 21 de agosto de 2016
Criando uma Mini-Interface para Execução de Scripts em Python
Neste Post vamos criar uma Mini-Interface para executar nossos testes, a mesma tem que fazer 3 coisas básicas.
1. A primeira coisa é ler um arquivo .json que vai conter dados sobre os testes, e pegar qual .json vai ser lido pelo mesmo.
2. O segundo passo é executar o teste de forma isolada.
3. O Terceira passo após a execução capturar os logs e matar os Processos.
No entanto tem um grande problema que pode acontecer nesse processo, não matar os processos filhos daquele determinado processo, assim você deixa acumular processo em memória ou seja acumulando lixo no sistema, deixando sua Interface lenta. Outro problema que já evidenciei é a tentativa de o próprio teste tentar fazer algo atribuído a Interface, isso é uma coisa que não vai funcionar de maneira adequada.
Abaixo vemos com mais detalhes sobre o determinado problema de muitas Interface não funcionando bem, é porque precisa matar os processos de forma recursiva, neste caso vamos utilizar o Psutil:
Abaixo vemos com mais detalhes sobre o determinado problema de muitas Interface não funcionando bem, é porque precisa matar os processos de forma recursiva, neste caso vamos utilizar o Psutil:
children(recursive=False)
Return the children of this process as a list of
Process objects, preemptively checking whether PID has been reused. If recursive is True return all the parent descendants. Example assuming A == this process:
Note that in the example above if process X disappears process Y won’t be returned either as the reference to process A is lost.
# Funcao do PsUtil pra matar os processos filhos de forma recursiva, # caso der erro ao matar o processo, no .json tem alguns selecionados. def kill_recursive(self, proc_pid, json_file): print ( "Matando o Processo de Forma Recursiva: " +str(proc_pid)) try: process = Process(proc_pid) for proc in process.children(recursive=True): proc.kill() process.kill() except NoSuchProcess: print ("o processo nao existe mais.") self.list_kill(json_file)
Outro problema que resolvemos no código abaixo é abrir o script em um sub-console, o que pode ocorrer que muitas das vezes a Interface poder atrapalhar na execução dos testes, caso a execução aconteça no mesmo processo da Interface.
self.process = Popen([sys.executable, self.command], creationflags =CREATE_NEW_CONSOLE,stdin=PIPE, stdout=PIPE, stderr=PIPE, )
Com as dicas acima, vamos conseguir resolver muitos problemas na hora da execução dos testes. Vou criar um vídeo explicativo e colocar nosso projeto no bitbucket.org depois. Outra Solução é executar os testes através de uma ferramenta de Integração Continua como Jenkins, no entanto na Interface você pode expandir e fazer coisas mais além, como controlar as máquinas virtuais, armazenar os dados dentro de banco de dados para ter dados estatísticos para analisar futuramente.
Segue o código do Post realizado, como fiz bem rápido, precisa de alguns melhorias: https://bitbucket.org/masters_test/interface
git clone git@bitbucket.org:masters_test/interface.git
Problema:
Como o mundo não é mil maravilhas temos um problema grave, dependendo do projeto, alguns programas após inicializados não tem como matar ele, neste caso use o os.startfile, não use o popen, quando colocar na integração continua ele vai falhar, e você não vai saber porque.
Referências:
[1] http://pythonhosted.org/psutil/
[2] https://pypi.python.org/pypi/psutil
[3] https://docs.python.org/2/library/subprocess.html#subprocess.CREATE_NEW_CONSOLE
[4] https://docs.python.org/3.6/library/os.html
sábado, 21 de maio de 2016
Criando Testes com Psutil matando processos (Automação em Python para Desktop)
O Psutil (Processos e Utilitários do Sistema) é uma biblioteca multi-plataforma para recuperação de informações sobre a execução de processos e utilização do sistema (CPU, memória, discos, rede) em Python. É útil principalmente para a monitorização do sistema, criação de perfis e limitando recursos e gestão de processos em execução do processo.
O mesmo implementa muitas funcionalidades oferecidas pelas ferramentas de linha de comando, tais como: ps, top, lsof, netstat, ifconfig, who, df, kill, free, nice, ionice, iostat, iotop, uptime, pidof, tty, taskset, pmap. Atualmente ele suporta Linux, Windows, OSX, Sun Solaris, FreeBSD, OpenBSD e NetBSD, ambas as arquiteturas de 32 bits e de 64 bits, com versões de Python de 2,6 para 3,5 (usuários do Python 2.4 e 2.5 podem usar 2.1.3 versão).
Resumindo é um Canivete Suíço para auxiliar nos testes automatizados. Como assim? Você pode monitorar o consumo de memoria/processamento do seu aplicativo em um determinado teste, ou verifica o antes e o depois de um determinado teste, tendo o total de consumo de memoria no sistema operacional, você pode criar um testes de instalação do seu produto e verificar se o aplicativo após a instalação esta em memoria, assim como desinstalação do seu produto verificando se foram removidos da memoria do sistema operacional.
Em sistema embarcado já fiz inúmeros testes tendo que pegar a memoria de um determinado teste, por um período de tempo, por exemplo em um teste o Middleware estava travando em uma funcionalidade quando você voltava do Standby. Com o Psutil podemos monitorar esse teste de forma melhor. O Middleware era em linux eu usava o top e o free, em sistemas desktop o Psutil é maravilhoso, podemos verificar monitorar o uso de memoria, processamento, rede e disco.
Vamos aos exemplos práticos, abaixo funções para pegar o pid de um processo passando o nome, matar uma lista de processos via Psutil e via console e também de forma remota, é super prático e rápido.
import subprocess
import psutil
class TaskKill:
def __init__(self):
pass
# funcao que me passa o nome do app e me retorna o pid.
def list_pid(self, app):
pid = ''
if app:
for proc in psutil.process_iter():
try:
pinfo = proc.as_dict(attrs=['pid', 'name'])
if pinfo['name'] == app:
pid = pinfo['pid']
except psutil.NoSuchProcess:
print "o processo nao existe mais."
return pid
else:
print(pinfo)
else:
print "Voce precisa enviar o nome do processo!"
return pid
# funcao que me passa uma lista de processo por nome e me retorna uma lista de processos.
def lista_processos(self, app):
proc_kill = []
for proc in psutil.process_iter():
try:
pinfo = proc.as_dict(attrs=['pid', 'name'])
if pinfo['name'] == app:
proc_kill.append(proc)
except psutil.NoSuchProcess:
print "O processo nao existe mais."
pass
else:
print(pinfo)
return proc_kill
# Funcao que forca matar o processo via force no console.
def kill_force(self, pid):
if pid:
p = psutil.Process(pid)
app = p.name()
for proc in psutil.process_iter():
try:
pinfo = proc.as_dict(attrs=['pid', 'name'])
if pinfo['name'] == app:
print "notepad found!"
subprocess.check_output('taskkill /PID ' + str(pid) + ' /F', shell=True)
return True
except Exception, e:
print "Erro Desconhecido: ", e
pass
else:
print "Pid nao enviado!"
return False
def on_terminate(self, proc):
print("process {} terminated with exit code {}".format(proc, proc.returncode))
# funcao de envia uma lista de processos e mata o processo via psutil.
def psutil_kill(self, procs_kill):
status = False
procs = procs_kill # a list of Process instances
for p in procs:
try:
p.terminate()
print "Terminate processo!"
status = True
except psutil.NoSuchProcess:
print "O processo nao existe mais."
pass
gone, alive = psutil.wait_procs(procs, timeout=10, callback=on_terminate)
for p in alive:
print ("couldn't terminate process %s" % p)
try:
p.kill()
print "Kill processo!"
status = True
except psutil.NoSuchProcess:
print "O processo nao existe mais."
return status
# funcao que matar um processo de forma remota na rede, usando o pskill.
def kill_force_remote(self, computer, pid, user, password):
print "notepad found!"
try:
subprocess.check_output(
'C:\SysinternalsSuite\pskill.exe -t \\' + '\\' + str(computer) + ' -u ' + str(user) + ' -p ' + \
str(password) + ' ' + str(pid), shell=True)
return True
except Exception, e:
print "Erro generico: ", e
return False
if __name__ == '__main__':
obj = TaskKill()
pid_num = obj.list_pid('notepad++.exe')
test = obj.kill_force(pid_num)
print "Kill App: " + str(test)
Resultado:
C:\Python27\python.exe C:/Users/reiload/Dropbox/python_functions/kill_app.py
{'pid': 0, 'name': 'System Idle Process'}
{'pid': 4, 'name': 'System'}
{'pid': 7120, 'name': 'chrome.exe'}
{'pid': 7444, 'name': 'chrome.exe'}
{'pid': 7548, 'name': 'WUDFHost.exe'}
{'pid': 7964, 'name': 'zatray.exe'}
{'pid': 8064, 'name': 'chrome.exe'}
{'pid': 8088, 'name': 'taskhostex.exe'}
{'pid': 8128, 'name': 'GWX.exe'}
{'pid': 9028, 'name': 'python.exe'}
{'pid': 9124, 'name': 'dasHost.exe'}
{'pid': 9272, 'name': 'chrome.exe'}
{'pid': 9368, 'name': 'chrome.exe'}
{'pid': 9396, 'name': 'chrome.exe'}
{'pid': 9556, 'name': 'cmd.exe'}
{'pid': 9820, 'name': 'chrome.exe'}
{'pid': 10084, 'name': 'jucheck.exe'}
{'pid': 10164, 'name': 'cmd.exe'}
{'pid': 10324, 'name': 'audiodg.exe'}
{'pid': 10836, 'name': 'chrome.exe'}
{'pid': 10848, 'name': 'conhost.exe'}
{'pid': 11832, 'name': 'python.exe'}
{'pid': 12316, 'name': 'fsnotifier.exe'}
{'pid': 12320, 'name': 'pycharm.exe'}
{'pid': 12620, 'name': 'conhost.exe'}
{'pid': 12812, 'name': 'python.exe'}
{'pid': 12864, 'name': 'taskeng.exe'}
{'pid': 12932, 'name': 'chrome.exe'}
{'pid': 13080, 'name': 'chrome.exe'}
{'pid': 13188, 'name': 'conhost.exe'}
{'pid': 13544, 'name': 'conhost.exe'}
{'pid': 14564, 'name': 'chrome.exe'}
{'pid': 15032, 'name': 'notepad++.exe'}
notepad found!
Kill App: True
Process finished with exit code 0
Quem já não precisou matar um processo no braço? Aqui temos um exemplo de forma automatizada e super prático em Python. Na função kill_force_remote, se você não sabe qual é o PID, passa o nome do processo que vai funcionar mesmo assim. O que pode ocorrer de o script não funcionar é porque você não tem permissão necessária para o mesmo, podemos adicionar o except psutil.AccessDenied, que vai informar que houve acesso negado. Podemos ir um pouco além com o DDT (data driven test), para fazer ele ler vários processos através de um arquivo de json.
Se você tem um servidor e todo dia tem que matar uma lista de processos na mão, aqui você tem a solução de seus problemas, fazendo isso de forma automatizada, bom espero que gostem e até o próximo Post.
Referências:
[1] http://pythonhosted.org/psutil/
[2] https://pypi.python.org/pypi/psutil
[3] https://technet.microsoft.com/en-us/sysinternals/pskill.aspx
[4] https://pypi.python.org/pypi/ddt
segunda-feira, 4 de abril de 2016
14 Boas Práticas para Sucesso na Automação - Parte 1
Vamos falar sobre Boas Práticas sobre Testes Automatizados, esse tópico vai ser dedicado ao pessoal que trabalha com testes de forma ágil, em resposta ao desafio #desafioAgileTesters2016, é sempre bom trabalhar de forma ágil, sem muita Burocracia.
Eu sempre procuro olhar para o testador como um Étical Hacker (White hat), que sempre esta procurando falhas no Sistema. Um simples testador geralmente só faz Monkey Test ou seja testes manuais, não limite seus conhecimentos simplesmente a testes manuais, uma vez que o sistema está em manutenção e você tem que testar ele novamente, isso já é o indicador que ele precisa ser automatizado, como muita gente sempre procura um motivo pra não fazer, a desculpa é "Eu não tenho tempo pra isso!".
O meu conselho é já que você não tem tempo muito tempo tire uma a duas horas do seu dia pra trabalhar com testes automatizados, geralmente é o tempo que você gasta no celular, no facebook, ou conversando com as pessoas, que você pode redirecionar esse tempo gasto sem propósito para justificar um aumento.
Geralmente o pensamento da gerência é "Pra que vou pagar bem um testador, se ele somente faz Monkey Test?", aí é a hora de mostrar que seu time manja das coisas com testes automatizados, testes de performance/stress, testes de segurança, testes exploratórios inteligentes, com certeza o time vai ser valorizado.
Procurar gerenciar melhor suas atividades vai ajudar muito na automação, o bom é dedicar no mínimo 50% do seu tempo pra Automação. Não confunda Automação de Testes com 100% de bugs encontrados.
O meu conselho é já que você não tem tempo muito tempo tire uma a duas horas do seu dia pra trabalhar com testes automatizados, geralmente é o tempo que você gasta no celular, no facebook, ou conversando com as pessoas, que você pode redirecionar esse tempo gasto sem propósito para justificar um aumento.
Geralmente o pensamento da gerência é "Pra que vou pagar bem um testador, se ele somente faz Monkey Test?", aí é a hora de mostrar que seu time manja das coisas com testes automatizados, testes de performance/stress, testes de segurança, testes exploratórios inteligentes, com certeza o time vai ser valorizado.
Procurar gerenciar melhor suas atividades vai ajudar muito na automação, o bom é dedicar no mínimo 50% do seu tempo pra Automação. Não confunda Automação de Testes com 100% de bugs encontrados.
Agora vamos ir direto ao assunto, primeiramente você tem que criar o processo de testes para automação, todos os livros de testes falam que você tem que começar pelo processo, definindo o processo, não sejamos leigos ao dizer que não precisamos de um processo, é claro que ele não precisa ser um processo lento, nem demorado. Você tem que definir um processo ágil, rápido, sem muita burocracia. Eu recomendo o uso do SCRUM, devido a filosofia de entregar as coisas que tem a maior prioridade e de maior valor para o negócio do cliente, que encaixa perfeitamente com a automação. Automatizar tudo pode gerar bastante manutenção/retrabalho, automatizar aquilo que tem o maior valor para o cliente é sempre o ideal.
O processo você pode criar um apresentação mostrando o processo de automação, como ele é feito. As pessoas ao seu redor precisam saber o que você esta fazendo e como você esta fazendo as coisas, se possível mostre pro seu gestor mais acima.
Faça Marketing do time de testes, eu mesmo tenho que melhorar meu Marketing Pessoal, conheço pessoas que são profissionais nisso e sempre se dão bem.
Acima vemos um processo bem definido de automação, antes de definir um processo, tenha em mente a quantidade de pessoas que você tem para trabalhar no projeto. Eu não entendo a mente de certas pessoas, que define um mundo para fazer, sendo que tem 3 ou 2 pessoas no máximo.
Em uma empresa grande que trabalha com automação geralmente eles criam seu próprio Framework, se não for o seu caso tire isso, você vai gastar muito tempo tentando criar um Framework, que não pode ser a melhor solução pra você, essa é um dica importante, avalie bem a criação de um Framework, o Framework que estou falando é uma estrutura complexa pra automação seguindo um conjunto de metodologias e ferramentas, faça as coisas simples e bem feito que terão resultado.
Considerando o cenário que temos poucas pessoas pra trabalhar na automação, o processo abaixo é a melhor escolha.
Em uma empresa grande que trabalha com automação geralmente eles criam seu próprio Framework, se não for o seu caso tire isso, você vai gastar muito tempo tentando criar um Framework, que não pode ser a melhor solução pra você, essa é um dica importante, avalie bem a criação de um Framework, o Framework que estou falando é uma estrutura complexa pra automação seguindo um conjunto de metodologias e ferramentas, faça as coisas simples e bem feito que terão resultado.
Considerando o cenário que temos poucas pessoas pra trabalhar na automação, o processo abaixo é a melhor escolha.
Você pode criar uma ferramenta que cria vários gráficos de comparação entre versões, ou seja que auxilie a gerência na tomada de decisão, é claro que isso não é necessário, somente faça se tiver tempo livre, no Jenkins temos o plugin cucumber-reports-plugin ele já dá conta do recado.Trabalhe com a automação usando o framework BDD, todos conseguem entender o que você esta fazendo e o que você está testando, muita das vezes a falta de valorização do seu trabalho está acontencendo pela falta de visibilidade, o BDD vai ajudar muito a mostrar isso pra empresa em si.
No Python temos o Pytest-html, muito bom!
A minha segunda boa prática de automação é definir os testes Positivos e Negativos na sua Estratégia para Automação.
A terceira boa prática é apresentar metas a curto prazo e a longo prazo. Na imagem acima definimos os casos de testes a serem entregues a duas ou três semanas, sem nenhum problema, demorar muito para entregar algo, isso gerar desconfiança das pessoas na automação. Sempre queremos entregar algo grande, isso pode ser seu fracasso, apesar de serem poucos testes, 8 no total, temos 5 browsers padrões, os teus testes tem que rodar nesses cinco browsers com sucesso, multiplicando foram feitos 50 testes, agora temos 3 sistemas operacionais mais usados Linux, Windows, MAC OS, agora temos 8x5x3, ou seja 120 testes executados em questão de minutos.
Na próxima Sprint adicione mais testes, mas vá devagar se você esta começando agora, não esqueça que a Sprint termina em 3 semanas, com a prática você vai conseguir entregar muito em pouco tempo.
Minha dica é faça o caminho feliz do sistema na primeira entrega, coloque seu esforço nas features mais importantes do sistema. Não gaste muito tempo em features que o cliente dificilmente vai usar. Não faça os testes na sua máquina, monte maquinas virtuais com o ambiente adequado e configurado com os browser e suas versões, você pode dar snapshot no VMware, ou seja você pode voltar ao inicio dos testes sem alteração do ambiente.
Nossa quarta boa prática na automação, esta na escolha da ferramenta ou Framework certo para automação, sem falar na linguagem de programação que a sua equipe de testes quer trabalhar. Nem todo mundo gosta ou quer trabalhar com Java na Automação, consulte a sua equipe antes de escolher a linguagem para se trabalhar.Temos as seguintes linguagem mais usadas Java, Python, Ruby, C#, JavaScript, PHP, você esta montando uma equipe de automação e ninguém da sua equipe conhece Java/C#, isso pode ser seu fracasso, Java/C# exige um certo tempo para seu aprendizado, lembrando que você tem que aprender a linguagem de programação primeiro (OOP). Caso você quer trabalhar com Java contrate alguém experiente em Java, para passar o conhecimento para o resto da equipe, ou escolha uma linguagem de rápido aprendizado como Python, Ruby, JavaScript.
Meu conselho sobre as ferramentas ou Frameworks para automação, faça uma pesquisa no mercado, consulte especialistas, veja os pontos negativos de cada ferramenta, sempre procure as ferramentas mais usadas no mercado, siga as tendências do mercado para não ficar para trás.
No meu ponto de vista as ferramentas livres são as melhores (Selenium WebDriver/Grid, Appium), você encontra bastante material sobre o assunto, em forum o pessoal responde rápido a sua dúvida, você pode modificar ou acrescentar melhorias as ferramentas, ou seja contribuir para comunidade open source.
As ferramentas pagas são uma caixinha fechada, sempre vai precisar do suporte técnico da ferramenta para resolver eventuais problemas. A escolha errada do equipamento ou ferramentas para os testes automatizados pode trazer o fracasso ou lentidão ao seu projeto.
Fonte: https://saucelabs.com/resources/webinars/test-automation-trends-for-2016-and-beyond
Minha dica é procure sempre dominar as ferramentas que você trabalha isso é essencial para seu crescimento de carreira fora da empresa. Reforce seus conhecimentos com Cursos, Webnar, Palestras, Certificações na área.
Nossa Quinta boa prática é com relação ao ambiente, pense sempre em integração continua nos seus testes automatizados (Jenkins, Hudson), sempre procure trabalhar com o pessoal de desenvolvimento, todo mundo é um time só, se falhar todo mundo falhou, não somente você falhou, mas o projeto como todo, sempre tenha isso em mente. Em várias vezes o time de desenvolvimento me ajudou bastante a resolver problemas na aplicação para melhorar a performance dos testes.
Outra dica é sempre procure ter uma ferramenta para controle de versão, ou seja um repositório para seu código, eu sempre uso o GIT e o Bitbucket, para armazenar, organizar e gerenciar meu código fonte, legal do Bitbucket que tem integração com o Jira. Não caia no erro de deixar o código no seu computador, como você vai justificar um mês de trabalho perdido?
Outra dica é sempre procure ter uma ferramenta para controle de versão, ou seja um repositório para seu código, eu sempre uso o GIT e o Bitbucket, para armazenar, organizar e gerenciar meu código fonte, legal do Bitbucket que tem integração com o Jira. Não caia no erro de deixar o código no seu computador, como você vai justificar um mês de trabalho perdido?
Baixe e Leia o Continuous Testing Whitepaper no link acima, ótimo material para ler.Tente montar teu ambiente mais parecido com o do usuário final. No Jenkins você pode montar um Matrix de Browser ou trabalhar com Selenium Axis Plugin. Podemos usar o Docker no ambiente para testes, leia a apresentação abaixo:
Using-docker-for-testing
Nossa Sexta boa prática, não somente é aplicada a testes, mas a equipe de desenvolvimento, a programação em par, também aplicada a testes como uma ótima prática. Na automação em par, duas pessoas trabalham juntas, ou seja uma elaborando e a outra no mesmo momento revisando.Você também pode trabalhar com um revisor, ou seja somente dar o teste como concluído, após feito a revisão por outra pessoa do time, você pode definir as regras para o revisor, ele tem que baixar o código, executar no ambiente dele, revisar, ou ele pode colocar um TO DO uma melhoria que pode ser feita mais a frente.
Aconselho a sempre trabalhar com um revisor, sempre deu muito certo essa boa prática, quando você estar automatizando algo difícil, tente trabalhar em par, vai acrescentar mais qualidade ao projeto. Algo legal de se fazer é usar uma ferramenta de inspeção de código, no Python eu uso o Pylint, isso eu considero como uma boa prática, já vi muitos códigos totalmente fora do padrão da linguagem, difíceis de entender.
Nossa sétima boa prática, procure participar de fórum, grupos, sites, Webnar que falam de automação, geralmente o pessoal tem ideias novas, procure fazer cursos com professores que tenha anos de experiência, para tentar melhorar seus projetos de automação.
Sempre faça os Testes Exploratórios na Aplicação é uma boa prática após a Automação, nos testes exploratórios sempre procurando cenários não mapeados pelos testes automatizados, focando as regras de negócio da Aplicação.
Sempre faça os Testes Exploratórios na Aplicação é uma boa prática após a Automação, nos testes exploratórios sempre procurando cenários não mapeados pelos testes automatizados, focando as regras de negócio da Aplicação.
Siga a Qualister (Elias Nogueira), Agiletesters (stefanteixeira), obeythetestinggoat pra quem trabalha com python, Dave Haeffner que é autor do selenium guide book. Siga o site da Sauce Labs eles constantemente fazem diversos Webnar sobre melhores práticas de testes.
No site do PacktPub você pode baixar um sample do livro e o código fonte, no site do Selenium Guide Book faça o registro, eles sempre me mandam alguma solução de alguns problemas típicos.
Vamos finalizar por aqui a primeira parte, na segunda parte vamos falar somente sobre boas práticas de codificação em Selenium WebDriver e outro POST falando do Page Objects um exemplo prático. O desafio do automatizador sempre é escrever testes de fácil manutenção e reutilizáveis, compatíveis com diversas plataformas, e tendo uma excelente performance, para isso você tem que ganhar tempo montando estratégias, escolhendo a ferramenta/framework certo, com pessoas especializadas na área.
Geralmente as coisas ficam difíceis quando tem diversas plataformas diferentes, no meu caso na GVT para TV Digital eu tinha 6 tipos de caixas diferentes e dois portais diferentes, meus scripts tem que rodar em todas essas caixas, e em dois portais diferentes, aí a coisa começa a ficar complexa, neste caso usei classes genéricas para atender várias coisas, as funções estão organizadas por classe, e cada função faz uma coisa única, a configuração dos testes estão bem separados e fácil de mudar, em termos de comparação semelhante ao Page Objects Pattern.
Um problema comum no meu caso, o equipamento que o pessoal comprou pegava a imagem com uma qualidade baixa, que dificultava a automação, assim deixando a elaboração mais lenta, com o tempo montei um solução para ele dar zoom no portal, mas para isso tive que pedir ajuda do pessoal de portal para ajudar na resolução do problema.
Trabalhando em um ambiente ágil aonde as pessoas procuram ajudar umas as outras, os problemas que iram surgir, mas você consegui resolver o problema com o time, implementando novas soluções. Automação hoje em dia você não precisa justificar o custo no meu ponto de vista, já se tornou uma questão de estratégia da empresa para sobrevivência no mercado competitivo, se você não faz a concorrência vai fazer por você, entregando um produto de qualidade mais rápido do que o seu.
Um ponto de atenção com relação aos testes manuais, ele é sempre um gráfico com uma linha crescente, a cada release você tem que testar mais coisas, novos testes com a mesma quantidade de pessoas, e a mesma quantidade de tempo, que sempre chega uma hora de estresse. Gastar tempo com automação é um investimento e não uma despesa. O maior fracasso dos projetos de automação é a falta de conhecimento nas metodologias e de programação.
Faça certo desde o inicio com a metodologia certa e da forma correta, que dar 100% certo.
Um problema comum no meu caso, o equipamento que o pessoal comprou pegava a imagem com uma qualidade baixa, que dificultava a automação, assim deixando a elaboração mais lenta, com o tempo montei um solução para ele dar zoom no portal, mas para isso tive que pedir ajuda do pessoal de portal para ajudar na resolução do problema.
Trabalhando em um ambiente ágil aonde as pessoas procuram ajudar umas as outras, os problemas que iram surgir, mas você consegui resolver o problema com o time, implementando novas soluções. Automação hoje em dia você não precisa justificar o custo no meu ponto de vista, já se tornou uma questão de estratégia da empresa para sobrevivência no mercado competitivo, se você não faz a concorrência vai fazer por você, entregando um produto de qualidade mais rápido do que o seu.
Um ponto de atenção com relação aos testes manuais, ele é sempre um gráfico com uma linha crescente, a cada release você tem que testar mais coisas, novos testes com a mesma quantidade de pessoas, e a mesma quantidade de tempo, que sempre chega uma hora de estresse. Gastar tempo com automação é um investimento e não uma despesa. O maior fracasso dos projetos de automação é a falta de conhecimento nas metodologias e de programação.
Faça certo desde o inicio com a metodologia certa e da forma correta, que dar 100% certo.
[0] http://www.slideshare.net/AgileDenver/discover-the-power-of-pair-testing
[1] https://cucumber.io/
[2] http://pythonhosted.org/behave/
[3] https://pt.wikipedia.org/wiki/JUnit
[4] http://appium.io/
[5] http://www.qualister.com.br/
[6] https://seleniumguidebook.com/
[7] http://www.obeythetestinggoat.com/
[8] https://jenkins.io/
[9] http://hudson-ci.org/
[10] http://www.slisenko.net/2014/06/22/best-practices-in-test-automation-using-selenium-webdriver/
[11] http://www.softwaretestpro.com/
[12] http://www.qualister.com.br/blog/testes-exploratorios-parte-1-introducao
quarta-feira, 27 de janeiro de 2016
Testador Cargo, Sálarios e Desejados Skills
O objetivo deste tópico é mostrar os cargos e salários, assim como, o perfil dos profissionais da área de teste e qualidade de software. Os pontos chave aqui considerados foram: cargos e salários, plataforma/tecnologia das aplicações onde os testes são realizados, linguagens de programação utilizadas para auxiliar as atividades de testes, formação, certificações dos profissionais, dependendo do Porte da Empresa e Nível de Criticidade dos Sistemas em Desenvolvimento ou em Manutenção, o salário varia muito de 2000 a 5000 mil Reais, ainda falta profissionais qualificados nesta área, com os conhecimentos necessários para atender a vaga, como sou um Arquiteto Junior, ainda necessito de muito investimento em certificações para atender o Mercado Nacional ou galgar um degrau maior na empresa aonde eu trabalho.
Ano 2010.
Escrevi esse Post em 2010, resolvi atualizar o mesmo, para falar mais sobre o assunto e as mudanças de mercado. Com a crise no Brasil tivemos uma baixa nos salários dos analistas de testes, vejo pouca vaga para muita concorrência e quase nada de vagas para Sênior, a maioria é para Junior e Pleno. Essas vagas variam de 1500 a 3500, é a triste realidade do momento, poucas vagas estão pagando acima de 4000 mil, apesar disso não vamos desanimar conheço muita gente que ganha entre 5000 a 7000 reais trabalhando com testes, geralmente quem ganha mais que isso trabalha com consultoria e treinamento.
Acima vemos a pesquisa pelo maior site de empregos de TI, o CEVIU, temos o máximo de 7000, realmente muitas empresas multinacionais pagam esse valor, mas pra quem tem mais de 5 anos de experiência e domina o English Fluente, com as mudanças do mercado é necessário entender de várias ferramentas de testes e pelo menos uma linguagem de programação para automação, não é do dia pra noite que você vai se tornar um expert em testes, requer bastante treinamento e foco no aprendizado das ferramentas, é importante estudar um pouco ou tirar uma certificação em metodologia ágil.
Ser Proativo e Investigativo é um das principais qualidades de um testador, um ponto de atenção que muitos testadores erram é na comunicação e no trabalho em equipe. Muitas empresas que abrem a vaga de analista de testes e não conhecem nada sobre testes, e não tem um setor de testes definido no desenvolvimento de Software, pode ser uma boa oportunidade de crescer na empresa, mas vai ter muito trabalho pela frente. Tire da sua cabeça que o testador não precisa entender de desenvolvimento, o mercado mudou e agora é um diferencial na seleção.
Pesquisa sobre salários da Qualister:
Sites para Pesquisa de Emprego e Curriculum Online:
Minha Dica de Cursos baratos é na Udemy, faça a inscrição e selecione os cursos na wishlist e espere as promoções dos finais de semana, tem promoções boas por 12$ ou seja 56 reais dependendo do valor do dollar:
Pra começar recomendo um bom curso de Selenium com BDD e Python 3:
Bons cursos no Brasil:
Minha Dica de Pós-Graduação:
Desenvolvimento em Android (Mercado em Alta):
Análise de Dados com foco em Cloudy (Mercado em Alta):
Inglês Online o melhor é o englishtown:
Em automação segue as linguagens mais usadas, em Primeiro vem Java, vejo um crescimento por JavaScript, Ruby, Python e C# nas vagas abertas.
O Selenium é o Framework mais usado, geralmente se usa o Selenium com Cucumber ou JUnit. A ferramenta mais usada pra automação é o UFT ou chamado QTP da HP e o segundo mais usado é o TestComplete.
Ferramentas de Testes automatizados tem as suas limitações, é bom conhecer todas elas, antes de adquirir uma ferramenta cara.
fonte: http://blog.testproject.io/2015/12/03/worlds-most-desirable-automation-skills/
Desired Skills and Experience
>> A primeira parte desde anúncio sobre uma vaga de analista de testes, são os requisitos básicos de qualquer vaga de testador, o diferencial está na Automação com conhecimento de uma linguagem de programação, e uso do framework Selenium com BDD (Behaviour-Driven Development).
Nos testes não-funcionais com testes de stress/performance, ele poderia ter adicionado também os testes de segurança, pelo menos os básicos relacionados as aplicações Web, Top 10 OWASP, outra coisa bem comum o conhecimento em SQL, pelo menos o básico (Insert, Alter table, Update, Delete, Select with multiple tables). Se a vaga fosse para Sênior iria exigir conhecimentos em testes para Mobile.
Bom esse é o Perfil desejado atualmente de um testador, é sempre bom ter o nosso curriculum atualizado com as exigências do mercado de trabalho.
Ferramentas que os Analistas de Testes tem que conhecer:
TestLink - Open Source Test Management;
Jira + Kanoah Tests - Project management, Bug tracking, Test Process, Test Management;
Bugzilla - Bug tracking;
MantisBT - Bug tracking;
HP UFT, HP LoadRunner - Bug tracking, Test Process, Test Management, Automation Testing, Performance/Stress Test;
TestComplete - Automation Testing Tool;
Ready! API - RestFul Testing Tool (Security, Load and Automation Testing)
Apache JMeter - Performance/Stress Test;
RedMine - Project Management;
Acunetix, IBM AppScan - Blackbox Security Testing (Web).
Entidades Certificadoras de Teste e Qualidade de Software, recomendo a BSTQB.
- ALATS (Certificação Brasileira de Teste de Software).
- CSTE (Certified Software Tester).
- CSQA (Certified Software Quality Analyst).
- CTFL (Certified Tester Foudation Level).
- ISTQB (International Software Testing Qualification Board).
- BSTQB (Brazilian Software Testing Qualification Board).
http://www.qaibrasil.com.br/
http://csqa.info/
http://www.bstqb.org.br/
http://istqb.org/display/ISTQB/Home
http://www.pmi.org/
quarta-feira, 20 de janeiro de 2016
Testes Unitários com Jasmine+Karma Test Runner
Nessa Postagem vamos falar sobre
Testes Unitários em JavaScript, hoje em dia é um diferencial o testador
conhecer sobre o mesmo, testes unitários não é nenhum bicho papão para o
testador temer. Muitas empresas como a google fala da evolução do Quality Assurance para Test Engineering então é bom
você aprender porque será o futuro, para saber mais sobre essa palestra leia as
referências.
Em programação
procedural, o teste unitário é feito para testar uma unidade isolada ou função
individual ou um procedimento separado. Idealmente, cada teste de unidade é
independente dos demais, o que possibilita ao programador testar cada módulo
isoladamente.
1. Escopo dos Testes Realizados
Vamos realizar testes unitários em um Jogo da Velha/ Tic
Tac Toe, este foi desenvolvido em JavaScript. Será usando o framework
Jasmine/karma Test Runner para desenvolvimento dos testes unitários em JavaScript.
Com relação a criação dos scripts de testes, serão exatamente 17 testes para cada browser, totalizando 85
testes feitos no todo.
O projeto se limita aos
browser Firefox, IE , Chrome , Safari, Opera, o teste foi será rodado nos
sistemas Operacionais Windows e Linux, no Linux com limitação de browser (Firefox,
Chrome, PhantomJS).
Além de fazer os testes Unitários vamos corrigir os bugs do Jogo.
2. Testes Manuais:
Para
realização dos testes manuais foram feitos a cobertura dos testes utilizando o plugin firebug no browser Firefox, e no Chrome o seu próprio editor interno.
Bug
01 - Ao abrir o Jogo no Firefox o mesmo não estar funcionado corretamente, esta
dizendo que eu já selecionei o campo, mas o campo está vazio.
Bug
02 - Quando inicio um novo jogo ele diz
nada, por padrão deveria mostrar uma mensagem que o jogo foi iniciado.
Bug 03 - Ao testar o jogo no browser Google Chrome e Safari esta informando o
ganhador errado.
Bug
04 - Quando eu desativo o javascript, ele para de
funcionar, deve estar claro para o usuário que o mesmo deve estar ativado para funcionamento
do jogo.
Bug 05 UX/UI - Pra melhorar a usabilidade do jogo deve ser colocada cores diferentes para cada jogador, assim melhorando a usabilidade do mesmo.
Bug 06 UX/UI - Para ficar mais interessante o jogo foi colocado um Score/Placar e um reset de Score/Placar.
Bug 05 UX/UI - Pra melhorar a usabilidade do jogo deve ser colocada cores diferentes para cada jogador, assim melhorando a usabilidade do mesmo.
Bug 06 UX/UI - Para ficar mais interessante o jogo foi colocado um Score/Placar e um reset de Score/Placar.
Figura 01 - Quando os valores dos campos estão como undefined, ele exibe a mensagem que o usuário já ganhou “The winner is” e o nome do jogador.
3. Lógica e cobertura dos testes:
Foram realizados 17 jogadas, essas 17 jogadas cobre todos os loops do código fonte implementado, em casa desenhei um quadro com o jogo da velha, e cada campo uma numeração ce11, tanto que mudei isso no código para ficar como variável global:
ce11 = '', ce12 = '', ce13 = '',ce21 = '', ce22 = '', ce23 = '', ce31 = '', ce32 = '', ce33 = '';
A figura abaixo mostra muito bem o que fiz, são oito linhas, são necessárias somente uma jogada certa para cobrir um loop de código, como assim [ "X","X","X","O","O","","","","","X" ] é uma jogada na figura seria 3,2,3, isso quer dizer que X ganhou o jogo, a jogada de O , O não vai ser analisada pelo código, não importa a ordem da jogada, mesmo que a jogada seja de O ou X, a análise do código vai ser a mesma, ele vai entrar no primeiro loop do código:
if (((ce11 !== '') && (ce12 !== '') && (ce13 !== '') && (ce11 == ce12) && (ce12 == ce13)) ||
Primeiro ele verifica se os três primeiros campos estão vazios, e segundo se os três campo são iguais, e mostra a mensagem pro usuário X, por isso tem aquele X no final dos testes, representa o usuário que fez a jogada, concluindo basta um teste para cada loop feito no código. Beleza e quando o usuário não entra em nenhum loop?
Bom isso é simples a jogada representa assim:
[ "X","X","O","O","","","","","","X" ]
X fez duas jogadas e O fez duas jogadas, e quem esta jogando é X.
Coloquei no código a mensagem "Continue game!", ele não faz nada continua a jogada no jogo, não importa a quantidade de vezes diferentes sempre vai entrar em Continue game, então você precisa somente de um único teste para representar isso!
E por último seria a jogada que não houve ganhador:
("X","O","X","O","X","X","O","X","O","X")).toEqual("There wasn't winner");
Representado pelo testes acima, basta um único teste para cobrir esse laço de código, são totalmente desnecessário realizar diversos testes, sendo que um único já basta.
Para pessoas críticas quem me garante que você falou esta certo?
Para isso usei o karma-coverage é um plugin que analisa a cobertura do código realizado.
Como o código implementado seria exibido na página HTML, sem precisa criar um arquivo separado?
Respondendo essa questão, a melhor forma seria criar uma classe pra fazer a chamada das funções e referenciar o html para a classe, não foi implementado isso, mas fica a dica aqui, para melhorar o código feito.
Figura 02 - karma-coverage
Figura 03- Foi baseado nesta figura a quantidade de possibilidades de ganhar o jogo, que é a mesma do código.
4.
Testes Unitários/Unit Test:
As figuras abaixo mostra o resultado dos testes realizados, em dois ambientes diferentes Linux e Windows.
Rodando os testes via Jasmine sem o Karma Test Runner, temos o seguinte relatório:
Para concluir o Jasmine é uma ferramenta muito poderosa, além de fazer os testes unitário podemos executar os Testes na camada de UI com o Protractor, assim podemos ter uma solução completa. Nas referências contém tudo que vai precisar sobre os testes unitários em JavaScript, compartilhei o projeto para a comunidade de testadores saber mais sobre o assunto. Bom espero que tenham gostado, ser um bom testador é sempre ir mais além.
Referências:
Para Aprendizado sobre JavaScript, segue um curso online no YouTube:
Curso JavaScript - Introdução #01
Download da documentação e do jogo da velha com os testes unitários:
https://www.dropbox.com/sh/jfhxudslfpasvhu/AAAn2mLvnNN4GdLov19moGPUa?dl=0
Palestra sobre Test Engineering da google:
GTAC 2013 Keynote: Evolution from Quality Assurance to Test Engineering
Jasmine:
http://jasmine.github.io/2.4/introduction.html
Karma Test Runner:
https://karma-runner.github.io/0.13/index.html
Assinar:
Comentários (Atom)