Kanika Pandey, Regional Director – Asia Pacific, Applitools

As the industry faces more digital transformation, each business will expect that feature requests entering the development pipeline will pop out smoothly on the other side in the form of great apps and web properties, with 5-star user experiences. This development happens in stages, and roughly they include plan, development, testing, and then into production. There are sub-stages, but these are generally the categories. And rather than passing through these stages without incident, we know that all software contains defects. Typically, these defects are found over the test phase, and sometimes over production. And this is really the root of a problem that starts to define the space we concentrate on. i.e Quality Assurance. Defects cause all kinds of problems. We pay attention to three of those problems. To start with, they are expensive. We do studies with our customers all the time and routinely determine that a defect found here in ‘Test’ will cost 8x more than one found here in ‘Build’. And one found in Production, that can range from 100x to ‘complete disaster’. The second way they hurt you is in developer productivity. As they come back in to the beginning of the pipe in the form of backlog, they start to compete for time with new functionality development. This then causes a choking of the innovation flow through this pipeline. The third way these defects hurt you is in user experience, either because the app doesn’t work very well, or because relative to competitors, there is missing functionality. The third critically impacts your brand in today’s digital world. However, there are a few leaders who are getting this right. Having worked with some industry leaders in Asia Pacific, Kanika would like to share her learnings of the four pillars of success towards enhancing user experience. The four pillars are
1. Focussing on Coverage
2. Lots of automation
3.Making feedback flow faster to the developer and
4. Quality operations should be integrated in the DevOps toolchain

Mirco Hering, APAC Agile & DevOps Lead, Accenture

As they say, nothing is more dangerous than using yesterday’s logic for today’s problems, yet we are still working in our organisations with mental models that were inspired by manufacturing. You can see artefacts of it even in the language we use: people are resources and they work in development factories. If we are surprised why our transformations are not progressing as fast as we hoped when Agile took the stage, then looking to these old mental models provides part of the answer. In this talk I will explain from practical experience in my work, how the old models still influence us every day and how we can break away from them and learn new models. I will give positive and negative examples from real projects to show that it is normal to experience failures and how to course correct from the lessons such failures teach us. I will also provide pragmatic steps that everyone can take in their own organisations that don’t rely on buying new tools or following specific methods. Charting your own course starts with understanding where the problem is and understanding where our mental models let us down is part of that journey.

Thomas Hadorn, Managing Director APAC, Tricentis

Automation is a must, manual testing is unjustifiable, exploratory testing is a necessity. The testing community certainly is caught between the devil and the deep blue sea when it comes to exploratory testing. Although that term has been already around for ages, it still leads to more confusion than clarity for most of us. The real cause of this dilemma might be attributed to the fact that exploratory testing is not so much a thing that you do, but far more a way you think. As a result, it is little surprise that numerous questions still remain unanswered: is exploratory testing an activity or a technique – something that you do? Or is it an approach – a way or a style of doing something? Isn’t all testing exploratory? When do you do it? How to do it properly? How does it relate to the entire software life-cycle at all? In this talk, the speaker outlines the most common confusions and controversies on that topic to tackle these questions. He explains what exploratory testing is, why to go for it and when to practice it. Specific heuristics and techniques of exploratory testing, especially in regulated and fast-paced environments are discussed to get the most out of it in your daily testing business.

Brett Maytom, CEO and Lead Trainer, Scrum On

Agile has been around in Software development for quite awhile, but are testers actually using it correctly? Brett Maytom, Australian expert on Agile and Scrum will talk about the common pitfalls of using Agile and how to follow a few simple principles to make it work well. Brett is a seasoned business consultant with 28+ years of corporate leadership through IT, Business Systems and Professional Scrum Training experience across myriad sectors. As a Professional Scrum Trainer and Professional Scrum Master III , Brett is recognized for demonstrating a natural aptitude for optimizing systems, spearheading organizational management initiatives, and implementing agile practices. Join the session to learn more on the how software testing can be enhanced in Agile.

Kunal Gupta, Quality Assurance Consultant, Testingmind

During this session learn about the various QA assessment models and understand How to measure the maturity of a Software Testing process ? and Why it is important to benchmark and revisit maturity quantitatively ? The session will also make the audience aware of the methodology and measuring techniques used in the well known frameworks used for assessing the maturity. The quantified data helps the management to take right decisions and remove impediments for a smooth QA practice setup within the module / project / enterprise. Know about the TMMi , TPi and other well known assessment models and their usage in traditional and Agile testing practices. The usage of frameworks will help to strategies the People, Process, Tools and Technology aspect in Software QA.

Jayaraman Thatchanamurthy, Senior Manager, Capgemini

Agile programs run with 1 philosophy, application delivery is carried out with the intention of preventing the bugs first and not finding them late. Developing a strategy to bring performance testing to the fore is virtually guaranteed to save time and money in the long run. The aim is to bring performance testing forward which is currently the last phase of application development and make it a part of a continuous delivery pipeline that ultimately maximises efficiency while improving the quality of the finished product. This will help in achieving the speed that current digital economy demands. An application that is being developed with 10 functionalities need not be waited to be tested till all 10 functionalities are made available. With agile performance testing every single feature can be performance tested as soon as 1 of that 10 features is available thereby resulting in early identification of bugs and also helpful to highlight issues in the end product as already we would be aware of the individual feature’s performance capabilities. Saying all these, it is not easy to shift left right away and without right processes to start performing P&V testing. I will be presenting on few proven practices that will help you to make your agile performance testing as smooth as possible including techniques to derive non-functional requirements, identification of performance risks, automation of few performance processes to enable continuous testing ,monitoring and reporting. When to go for agile Performance and when to avoid the same.

Kenny Lee, QA & Release Manager, Civica Pty Ltd

Test early, test often. But what if the development cycle is long, complex and hard to integrate?

Interactive/reply-response software testing is usually dependent on all the services being available before meaningful testing can start. Service virtualisation can help overcome this testing limitation.It’s not a silver bullet to solve all testing issues. It’s also not just a testing tool. To create a virtualised service, it needs to go through requirements gathering, designing, coding and unit testing within its own solution.

It needs resource with the correct skillsets – ideally a technical tester or a developer.

It should not be a once off development or implementation. To use it effectively and with meaningful return on investment, it must be used continuously throughout the development and testing lifecycles. Join this session to know more about how effectively Service virtualization can be used to assure the quality of product/software being developed

Sougata Das, Senior Technology Architect , Infosys

Digital world is rapidly moving towards UX/CX with zero downtime driven by costs and efforts trending south with automation tests triggered by deployment. Reduced manual intervention and no wastage of efforts is driving for devops with continuous delivery and integration. The tools hence needs to highly agile, collaborate and integrate-able to each other. As heavy weight testing tools are moving towards lesser acceptance the light weight open source market is picking up. From Perfecto for mobile automation, Selenium with cucumber framework for functional automation easily integrated with Github/Protractor for CD/CI; the tool chain involves Gatling or Jmeter for Performance test execution with deployment triggered via Jenkins. Service Virtualization is driven by Stubby or CA LISA.

It should not be a once off development or implementation. To use it effectively and with meaningful return on investment, it must be used continuously throughout the development and testing lifecycles. Join this session to know more about how effectively Service virtualization can be used to assure the quality of product/software being developed.

Ujjwal Gulati, Test Manager, Red Energy

What might be an effective list of test metrics for technology stakeholders might not serve the need of the business stakeholders. When we look at the list of test metrics available in various books or internet, we find heaps of them right from requirements until the production. Some of the common questions that we are being asked regularly during testing are:
i. Are we getting the coverage right?
ii. How’s the quality of the deliverable?
iii. Are we tracking to the plan?
iv. How soon can we have the code in production?
v. Is the deliverable Red/Amber/Green from a go live perspective?
vi. What is the quality of the deliverable per business function? And many more…

What set of metrics answers the most common questions like the ones above? We often invest a lot of time in creating flashy test reports but what are those key test metrics that matter to most all stakeholders on the project? Which are the ones that demonstrate the real value of testing? Join this session to more about few of the effective test metrics that demonstrate the value of testing.