Quarta, 19 Dez 2018

Palestras

Quinta-feira, 13 de outubro de 2011

Lee Copeland Keynote: Today’s Testing Innovations
Lee Copeland, Software Quality Engineering

As a consultant, Lee Copeland has spoken with thousands of software testers in hundreds of different organizations. Generally, he comes away from these discussions depressed with the state of testing. Many organizations neither know about nor have adopted recent important innovations in our field. Lee will discuss nine of the important innovations in testing—the context-driven school, test-first development, really good books, open source tools, session-based test management, testing workshops, freedom of the press, virtualization, and testing in the cloud. Join Lee for his list, and propose others if you’d like. Discuss the keys to innovation and take a test evaluating your organization’s innovation quota.

Janet Gregory Keynote: Seven Key Factors for Agile Testing Success
Janet Gregory, DragonFire, Inc.

What do testers need to do differently to be successful on an agile project? How can agile development teams employ testers’ skills and experience for maximum value to the project? Janet Gregory describes the seven key factors she has identified for testers to succeed on agile teams. She explains the whole-team approach of agile development that enables testers to do their job more effectively. Then, Janet explores the “agile testing mindset” that contributes to a tester’s success. She describes the different kind of information that testers on an agile team need to obtain, create, and provide for the team and product owner. Learn the role that test automation plays in the fast-paced development within agile projects, including regression and acceptance tests. By adhering to core agile practices while keeping the bigger picture in mind, testers add significant value to and help ensure the success of agile projects.

Lee Copeland Choosing the Best of the Plan-Driven and Agile Development Methods
Lee Copeland, Software Quality Engineering

We seem to be under a curse in our profession. Although not cast by a witch or a wizard, the curse affects us just the same. It is the curse of “either/or”—the curse that we must choose either “this” or “that” but we cannot choose parts of both. Nowhere is this more evident than in today’s struggle between the adherents of the traditional “plan-driven” and newer “Agile” approaches to software development. What most overlook is that both groups want to achieve exactly the same goal: quality software that meets customer needs within the constraints of time, budget, staff, and technology. They differ only on the strategies to achieve this goal. For example, both groups agree that system requirements must be understood; their differences lie in questions of “how much of what to do and when to do it.” Lee Copeland offers insights and suggestions on the methods and approaches that will be most valued on your project—control vs. flexibility, individual contribution vs. process guidance, and contractual specification vs. adaptable delivery. Find out which of the plan-driven and Agile processes will work best in your organization and in your project’s context.

Martin Tornquist Planejando uma carreira profissional promissora, desafiante e gratificante em Testes de Software
Martin Tornquist, T&M Testes de Software

É sabido que o profissional se mantém atualizado e empregável inventando tendências e não apenas seguindo-as. Como se posicionar como profissional de testes em um mercado de TI concentrado, comoditizado e, paradoxalmente, ainda sem um bom nível de confiabilidade? Investir e focar em quê como profissional de Testes?

Gerard Numan The destiny of testing: End-to-End Integration
Gerar Numan, Polteq Test Services B.V.

Service Oriented Architectures, Virtualization and Internet Technology enable the (IT-)world to move into the Cloud. This phenomenon combined with the increasing usage of package software and outsourcing requires adequate means for the most extreme form of integration testing: End-to-End testing.

We have business processes but we let the processes be done where ever, by whomever. Organizations have more and more shared processes, for example amongst telecom companies, having each their own releases and projects possibly effecting each other's chains of systems. How can we still validate the quality of those processes, where they become increasingly depended on diverse particles on the electronic highway and this whole system landscape changes more and more rapidly?

Learn how effective and repeatable E2E testing will become the main and most challenging task for the testing community for now and the future. For testers to step up to this task, they will need to take things in their own hands: this means finding and defining the E2E requirements and specifications themselves by starting long term partnerships with business users and operators. Planning, preparing and executing a suitable End-to-End test, and evolving towards a more or less continuous End-to-End testing process.

Martin Pol Service-Driven Test Management: Enabling instead of complaining and blaming
Martin Pol, Polteq Test Services B.V.

Over the years test management has evaluated from "struggling to get involved" via "managing the fire brigade" to nowadays "an indispensable partner in the project". It was always very easy, and it became an attitude, to complain why testing could not be carried out as planned. Insufficient specs, not enough people, too late and incomplete delivery, no appropriate environments, no tools, tremendous time pressure, etc. All reasons to blame the rest of the world that testing was blocked by somebody else. The ”us” and ”them” thinking became common, claiming a lot of negative energy.

Since IT and testing have evaluated, testing and in particular test management has changed dramatically. Thinking in terms of solutions instead of problems, enabling instead of complaining and blaming, “we” in stead of ”us” and “them”.

Nowadays test management is fully focussing on the project objectives: “the service” to implement a workable solution for the business. Not as a kind of referee but organizing whatever is required to enable the project team to add quality. As a professional member of the project team test management finds solutions for any testing related problem that could influence the project’s success. This presentation will address how to act in the modern testing scene, by anticipating from the beginning, by organizing alternatives and shortcuts, by enabling the project team to deliver quality, in fact by taking ownership, as a partner in the project team, based on craftsmanship in testing.

Felipe Freire Piores práticas em testes (e como evitá-las)
Felipe Freire, Engenheiro de Software e Especialista em Ferramentas IBM Rational

Em muitas empresas os testes de software estão desacreditados, ou não recebem a devida importância. Essa desilusão em relação aos testes muitas vezes é resultado de tentativas frustradas ou da aplicação de más práticas. Nessa palestra serão apresentados cenários comuns de mau uso dos testes e dicas de como evitá-los, com base em experiências práticas. Ao longo da palestra serão abordados os seguintes assuntos: gerenciamento dos testes, testes ágeis, ferramentas de automação, testes funcionais e de desempenho, entre outros.

Rodrigo de Carvalho O que esperar de uma plataforma moderna de testes e qualidade de software?
Rodrigo de Carvalho, Gerente de Produtos das Ferramentas de Desenvolvimento da Microsoft no Brasil

Numa sessão dinâmica, interativa e que contará com a participação dos congressistas a Microsoft responderá o questionamento feito para os participantes do BRATESTE 2011 para seguinte pergunta: “O que esperar de uma plataforma moderna de testes e qualidade de software?”, mostrando ao vivo e na prática como equipes de qualidade podem trabalhar de forma mais colaborativa, produtiva e inovadora, aprimorando o fluxo de valor, redução de desperdício e aumentando a transparência ao longo de todo o ciclo de desenvolvimento.



Ir para o topo

 

Sexta-feira, 14 de outubro de 2011

Martin Pol Keynote: Chasing Quality in Cloud Computing: Testing different levels of quality requirements for cloud computing
Martin Pol, Polteq Test Services B.V.

The IT world is changing quickly, in fact it’s accelerating for a complete new era. During the next couple of years the IT and testing scene will migrate towards servicing and sourcing, partly provided in the private, public, hybrid and community clouds.

There is no time to lose. In the tradition of the testing world we are already late. Architects, designers, developers and suppliers such as Microsoft, Apple, Google, Amazon and IBM are working day and night to provide the technology and infrastructure for the near future. The cloudy future of IaaS, PaaS, SaaS, web services, mobile Apps, virtualisation and social media and networks, in fact the real Internet age.

More and more applications consist of ‘cloudy’ solutions. Every piece of software that moves into the cloud increases the dependency on the ‘evil’ internet. The end-to-end test complexity increases rapidly. Since all testing in de cloud IS end-to-end, the testing challenges are huge! Quality can be bought from the cloud: it brings you flexible performance and storage. Pay as you go. But what about the continuity, availability, elasticity and controllability of your cloud services that are delivered through the insecure minefield called internet?

Cloud Computing introduces a new set of quality requirements, at different levels e.g. at the level of the software supplier, at the level of the internet and at the end-to-end level.

So in short: how to test the cloud?

Gerard Numan Keynote: Risk based testing: a practice based story
Gerard Numan, Polteq Test Services B.V.

Risks are a popular subject for project and test management. “No risk, no test” and “many risks, smart testing” are great sounding slogans. But how to make the jump from stakeholder worries to risks and to testing activities?

There are some models and methodologies around, giving guidance on how to translate information about risks to testing activities covering the risks. But, as with music, the most important things are not in the score.

This presentation is based on experiences from the work floor, shedding light on the common ideas behind risk based testing, avoiding the abstract calculative methodologies but showing how to drive out the information you need to identify the risks and the do’s and don’ts of processing risks into a test strategy.

What types of people to involve for getting all the necessary information on? How to organise and manage a risk assessment workshop? What to do if a workshop is not possible? What kind of risks can you expect and which questions to ask? How to make risks quantifiable? What other benefits can come out of risk assessments and what role can testers play in this? Which testing activities can cover which risks best?

  1. Interviewing guidelines related to risk assessments
  2. Risk assessment workshop guidelines
  3. Create a risk based test strategy
  4. Getting full benefits out of risk assessments
  5. Practice based examples

Lee Copeland Proving Our Worth: Quantifying the Value of Testing
Lee Copeland, Software Quality Engineering

Over the years writers have defined testing as a process of finding, a process of evaluating, a process of measuring, a process of improving. For a quarter of a century we as testers have been focused on the internal process of testing, while generally disregarding its real purpose. The real purpose of testing is to create information. James Bach nailed it when he wrote, “The ultimate reason testers exist is to provide information that others on the project use to create things of value.” That is why testing exists — to provide information of value. So, when managers complain that testing “costs too much” perhaps they are really trying to say, “I’m not getting enough valuable information to justify the cost of testing.” When testers say “my management doesn’t see the value in our work” perhaps they are really trying to say, “My management doesn’t value the information I’m providing to them.” To prove our worth, to increase the value of testing, we must first focus on testing’s purpose — providing valuable information — not its process. Join Lee as he discusses why quantifying the value of testing is difficult work — perhaps that’s why we concentrate so much on testing process—that’s much easier. But until we do this difficult work, until we prove our worth through quantifying our contribution, we should expect the bombardments to continue.

Janet Gregory Agile Testing Practices
Janet Gregory, DragonFire, Inc.

On agile teams, testing is an activity not a phase or a role, and many teams struggle with this concept. So, what do testers really do on an agile team? Janet Gregory will explain how testing fits into the agile process, and what value a tester can add to your agile team. She will talk about the importance of collaboration and simplicity in activities such as automation, ATDD (Acceptance Test Driven Development), and exploratory testing. This session is an overview of agile testing practices.

Lee Copeland Quality Metrics for Testers: Evaluating Our Products, Evaluating Ourselves
Lee Copeland, Software Quality Engineering

As testers, we focus our efforts on measuring the quality of our organization’s products. We count defects and organize them by severity, we compute defect density, we examine the changes in those metrics over time for trends, and we chart customer satisfaction. While these are important, Lee suggests that to reach the next level of testing maturity we must apply measurements to ourselves. He suggests we count the number of defects in our own test cases and the length of time needed to find and fix them; compute test coverage; the measure of how much of the software we have actually exercised under test conditions; and determine Defect Removal Effectiveness, the ratio of the number of defects we found divided by the total number we should have found. These and other metrics help us evaluate and then improve the effectiveness and efficiency of our testing process.

Gerard Numan How to test Datawarehouse systems
Gerard Numan, Polteq Test Services B.V.

Datawarehouse systems differs substantially from traditional systems: risks, infrastructure, process and use are very typical. Testing therefore needs to take into account the specifics of a Datawarehouse.

This presentation explains what needs to be in place to achieve successful testing of a Datawarehouse. A short introduction to Datawarehousing will be given and the differences with the traditional information systems will be pointed out. Based on that, the consequences for the test strategy, activities to be performed and required test techniques and knowledge will be explained. A real example will be shown, including pitfalls and tips.

Target audience

  • Introductory
  • Intermediate

3 Key Points

  1. Datawarehouse, the phenomenon, what is different
  2. Create a risk based test strategy
  3. Test strategy and required techniques
  4. Doing it in practice, pitfalls and tips

A paper on the subject is available and will be handed out.

Martin Pol TMap (NEXT) in a nutshell
Martin Pol, Polteq Test Services B.V.

Since the first introduction of TMap version 1.0 , 15 years ago, the approach has been implemented by numerous organizations worldwide. For the testing scene TMap offers a solid foundation for processes, techniques and organizational aspects. In fact TMap answers the classic questions when, what, how, with what and who to test.

TMap is a practice based approach, suitable for any application, branch or environment.

Martin Pol is the initiator and first author of the TMap approach.

TMap NEXT represents the third version of TMap, more focusing on business drivers, better suitable for iterative/agile and non-functionals. This presentation gives a general overview of TMap NEXT, including the famous TMap Live Cycle Model and among others, Product Risk Analysis, Quality attributes, Test-types and Estimation. Main objective is to enable testing staff to quickly find their way in the vast theory of the approach or to bridge the theory to their own test organization.

José Papo Testando em projetos Ágeis com práticas modernas como Especificação por Exemplos e Testes Exploratórios: Demonstração Prática de solução
José Papo, PUC-SP

Testes Ágeis geram uma mudança de paradigma em testers acostumados com processos Waterfall. Abordaremos o perfil do testador Ágil e como seu papel se transforma em uma equipe Ágil multifuncional e auto-organizada. Falaremos sobre técnicas modernas de testes e faremos uma demonstração prática delas.

As demonstrações práticas abordarão as seguintes técnicas: Specification by Example (também conhecida como Acceptance Test Driven Development), Testes Exploratórios com diagnósticos automáticos e Testes Funcionais automatizados gerados automaticamente a partir de testes manuais (exploratórios ou não).



Ir para o topo