One of the painful problems in Selenium automated testing is determining whether a HTML page has been loaded. This is especially the case when web application uses a JS  heavy framework such as the popular AngularJS.

During this talk we will discuss how to handle Selenium Page Object pattern better with Loadable Component.

The Loadable Component helps test case developers make sure that the page or a component of the page is loaded successfully. I will share my experience about the concept of the Loadable Component and Page Object patterns.

How can we (the testing team) help developers to cross the "app poverty line" and succeed in the market? finding: bugs, performance bottlenecks and security vulnerabilities, avoiding negative reviews and bad ratings. Straightforward and easy, right? Actually not that easy, mainly because the deep knowledge required in different technologies and tools to get this information for the hundred different kind of devices, which makes the tasks so much effort demanding.

In this talk we want to introduce Monkop, a cloud-based tool for Android testing and optimization. Once you upload the app to monkop.com, the test cloud automatically installs your app on dozens of real devices, including all Android versions, multiple screen sizes and brands. A “monkey” then plays with each device, analyzing app behavior and creating a report to be sent back in less than 24 hours. The report provides you with: app usage video, screenshots, performance metrics, power consumption data, top database times, recommendation based on best development practices and more, with just the push of a button.

Also, the aim of the talk is to share the lessons we learned developing and using these techniques (well known as “monkey testing techniques”) with the testing community. In addition to that, we are also open and looking for collaborators, testers and developers alike to get feedback and ideas from the community.

The early release of Docker (while it was in beta) was primarily used for testing. It was immediately accepted as the best tool which facilitated automation testing. Docker and its ecosystem have matured today to also support Docker in production.

Tests typically include a number of different components like DB Server, App Server, Web server. Tests also depend on external services like MySQL, Redis. Moreover, the engineers are not very conversant with the testing infrastructure: A QA engineer should ideally focus on writing and executing tests. Failed tests pollute the test environment and resetting it back to a clean test environment is an overhead. Using Docker can address all these issues.

This session aims to show how Docker can be effectively used in manual and automation testing. It will demonstrate how Docker can be used in CI + automation testing, which can form the base for your "continuous testing" approach.

This world has seen many generations. The first generation was when Software Engineering had two major stages - Analysis & Coding. The second generation expanded this to hours of exhaustive Manual Testing. The third generation of smart people took the next step towards Automated Testing. But should the smartness stop there?

Introducing the next generation of smart testing where the goodness of Exploratory Testing meets the ferociousness of Automated Testing. That's where we achieve Testing Nirvana!

Purpose: To demonstrate how productivity can improve by engaging testers from the very first day of a sprint

Questions to ask yourself:

1. Does your team receive all the features at the end of the sprint for testing?
2. Do you have the concept of code freeze in your project?
3. Does your sprint usually spill over because testing is not completed?
4. Do you demonstrate features to your stakeholders that have not been tested?
5. and many more testing paradox...

If your answer to any of the above questions is YES, then it's time to fix these problems.

In this session, not only will I demonstrate how you can engage your testing team from the very first day in order to start (that's right, start) testing your application, but also help you achieve this by means of some simple exercises.

• Business leaders know the value of adopting DevOps but Development and Operations team still struggling on how to adopt. There is gap in understanding how to transform Business Objectives to best practices & Technology Implementation. 
• Development and Operations teams have very narrow view of DevOps - they still think just CI / CD Automation is DevOps. Automated & Integrated ALM as an approach remove silos in the organization is missing. 
• Agile Coaches are trained and practicing primarily on software development side of things. Cross functional perspective ranging from Product Management to Portfolio to Release management is something they don't have exposure on.
• DevOps is big change. Industry needs coaches / architects ( change agents ) who are capable and accountable to drive this change.  
• DevOps is about operational efficiency at an enterprise level for Software Development centers; Lean / Kanban principles are the key but there seems to be Gap in industry on how to apply these to Software Development e.g. How to select an ALM, On what basis to select CI/CD tools

Augmented Reality is a breakthrough technology that could considerably ease execution of complex operations. Augmented Reality mixes virtual and actual reality, making available to the user new tools to ensure efficiency in the transfer of knowledge for several processes and in several environments. Various solutions based on Augmented Reality have been proposed by the research community: particularly in maintenance operations Augmented Reality tools have offered new perspectives and have promised dramatic improvements. On the other side Augmented Reality is an extremely demanding technology and, at the present day, it is still affected by serious flaws that undermine its implementations in the industrial context. This paper presents examples of Augmented Reality applications and shows the feasibility of Augmented Reality solutions, underlining advantages it could introduce. At the same time the principal flaws of Augmented Reality are commented and possible lines of investigation are suggested.

A reflective design approach to achieve software design agility by modelling change as a vector and tracking it to aid refactoring decisions.

Preface about the talk

Software design is a field that has always fascinated me and I have tried to be an obedient student trying to learn this art. Like any other design problem, software design is also a wicked problem. Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it .This paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.

Hence you need an architect with magical powers to get your design correct in the first go .This is the core philosophy behind emergent design in which we do not think too much about future . As Uncle Bob sarcastically points out, your customers somehow knows your design and they will come up with a requirement that will break your assumptions and thus your design. In emergent design you embrace aggressive refactoring religiously and few teams rebelliously for the good. It has also been observed that during emergent design refactoring step more focus is towards class design than higher abstract architecture elements. This creates technical debt which can go unnoticed for a long time.

In this talk I will be introducing a novel technique called change vector tracking that will address the above described problem. Change Vector Tracking is a reflective design approach to achieve software design agility by modelling change as a vector and tracking it through ceremonies like Change Vector Tracking meetings.

Change vector tracking doesn’t prevent customers from coming up with requirements that would invalidate previous design assumptions, it helps us in monitoring these changes and aids in making informed decisions of where and when to redesign. It helps us keep a check on design debt which otherwise would be overseen and not addressed at the right time .Design debt is invisible to tools initially, only when it grows beyond a scale tools can catch it. Change vector tracking is a technique to capture this design debt in a very early stage. “A stitch in time saves nine”.

Problem we faced

Our current project is a mobile app for iOS, Android and Mobile web, which is a mixture of pure native screens and webviews. Each platform has its own tools for UI automation like Calabash for iOS/Android and Watir-Webdriver for Mobile Web. But we wanted to create a generic automation framework which could support each of the  above UI automation frameworks but still reuse as much code as possible and avoid duplicating code between them.

Page Object Model

Page Object  Model was again a natural fit for this framework. Most implementations of POM recommend different POMs for each platform. But we wanted to have a single Page Object Model for all the 3 platforms to ensure maximum code reuse and reduce overall time spent in adding new automation.

Single Page Object Model across platforms

This was complicated because we had native screens as well as webview screens and so it was not possible to use the same Page Object. To solve this, we introduced abstractions for the elements on the screen and encapsulated the respective native driver implementations.

This also allowed us to implement common automation tasks in one place for e.g waiting for new pages to load, so that this code is not repeated across multiple step definitions and platforms. This helped us move to thinking in higher domain level concepts than in terms of low level UI interactions.

Today businesses are changing rapidly and they need to support rapid innovations and changes. Agility in responding to change is the key to success for every business. IT industries are adapting agile software delivery approach and one of the recent and most acknowledged such practice is DevOps. DevOps helps accelerate the TTM, reduce risks and provides continuous feedback. Continuous Testing is the most important and crucial aspect of DevOps which emphasises continuous process improvement.

Today we don't just need test automation. Times today demand a method which will help measure the risk of business failure, and not just a report which show if tests have passed or failed. This impacts not just changes (or upgrades) in technology and tools, but also a change in quality management culture is observed.

Test automation helps us test faster, and provides a mechanism to detect software defects. Though automation can be considered as a pre requisite to continuous testing, continuous testing is much more. It helps provide process improvements that can prevent future defects from occurring. It plays an important role in providing continuous feedback for your software.

Building a Test Automation Framework is easy - there are so many resources / guides / blogs / etc. available to help you get started and help solve the issues you get along the journey.

However, building a "good" Test Automation Framework is not very easy. There are a lot of principles and practices you need to use, in the right context, with a good set of skills required to make the Test Automation Framework maintainable, scalable and reusable.

Design Patterns play a big role in helping achieve this goal of building a good and robust framework. 

In this talk, we will talk about, and see examples of various types of patterns you can use for:

1. Build your Test Automation Framework
2. Test Data Management
3. Locators / IDs (for finding / interacting with elements in the browser / app)

Using these patterns you will be able to build a good framework, that will help keep your tests running fast, and reliably in your CI / CD setup!

Abstract

Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This talk focuses on answering two questions;  What are the ideal conditions when teams should adopt it? How to adopt it the right way ?

Preface about the talk 

Behaviour driven development has been a buzz word in the recent years and many teams are adopting it. The core of BDD is the collaboration angle that enables teams to build the right product. As a side effect BDD gives you a very essential output, which is an automated acceptance test suite. BDD team members work together in identifying different scenarios elaborated in the form of examples. High performing teams ensure through working agreements to only pull those features in which scenarios are well defined. These scenarios define the acceptance criteria of the feature. The scenario identification process involves full team participation and in these meeting its essential that the three amigos i.e. the entire development team, QA engineers and product owner should participate.  Along with the three amigos any other members who can constructively contribute in scenario identification are also welcomed.

During these interactions technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying and discussing scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it helps them shape their product ,  saying so few teams are yet to find value in investing time and effort towards these meetings and ceremonies . One should keep in mind that for BDD to be effective we require full team participation.

In this talk I am making an assumption that these teams who are not finding much value in adopting BDD, were practicing it in fullest of its spirits and not just documenting scenarios for creating an automated test suite. This talk discuss on how to effectively adopt it ,the right way based on problem space complexity of the feature .

A mindmap is a diagram used to visually organize information. It can be called as a visual thinking tool. A Mindmap allows complex information to be presented in a simplified visual form. A mind map is created around a single concept. The concept is represented as an image in the center to which the associated ideas are added. Major ideas are connected directly to the central concept, and other ideas branch out from those.

Mindmap is a great tool for note taking, planning, studying, brainstorming etc. The term 'mind map' was first used by Tony Buzan in 1974. I drew my first mindmap when I was in school. I preferred mind-mapping over text notes and it proved to be a great aid to revise and recall the concepts quickly. This is because the information in mindmap is structured in a way that mirrors exactly how the brain functions - in a radiant rather than linear manner. A Mind Map literally ‘maps’ out your thoughts, using associations, connections and triggers to stimulate further ideas. 

Mind maps can be used in all the test stages from test planning to test case execution.

Mindmaps can be used for:

• Test Planning
• Requirement analysis
• Impact analysis
• Task allocation
• Test case design
• Traceability
• Test reporting -Quick test reports 

Test Planning

While test planning, you can draw an initial mindmap keeping in mind the list of tasks, schedules, tools, roles, responsibilities, milestones etc. Present the mindmap and discuss it with your stakeholders. Modify the mindmap if any changes are required. One thing you will love about mind maps is its flexibility to adapt to changes. All you might have to do is to add or remove a node/branch. This flexibility might not happen when you draw on a paper, but a mind mapping software assists any changes easily.

The final mind map shows you the scope of testing in one glance. This mindmap can be used as a blueprint and later converted into a plan. This ensures that no test activity is missed.

Test case design

Mindmaps are an efficient way of creating lean test cases. It reduces the time required for creating test cases yielding better results. Mindmaps are very easy to maintain and are flexible to changing requirements.

Draw branches from every user story/epic and associate all its functionalities as sub-nodes.Start adding test ideas/test case for each functionality.

I created a mindmap covering test ideas for the major functionality. My team started to expand the mindmap by branching out more and more test ideas. We kept adding new nodes when we found unique scenarios that uncovered the bugs during our test sessions. This drastically increased our test coverage.The final mindmap can be as the basis for test case document or it's cool if it's used as it is. 

The best part of mind mapping is that you generate more ideas when drawing them. Collaborative mind mapping with the team gives you best results.

Traceability mindmap

A traceability matrix is an essential tool for every tester to analyze and improvise the test coverage. You can use a mindmap instead of a tabular traceability matrix.

To create a traceability mindmap - add nodes of all the Epics. Draw branches from every module and associate all its user stories as subsequent nodes.  Now link the test cases for every functionality.You can link the requirement number of the test management tool.

This ensures that you have not missed out writing test cases for any user story. This mindmap gives you the birds-eye view of your test coverage.You can identify the areas where you need to strengthen your coverage.

                                          The basic amenities of automotive is no longer an expectation for the safety of drivers and passengers. It is a revolution that most promising consumer electronics are cars and not the ones in the living room. Just a remote key or a smart key to lock your car is not a stop to the security breach that could happen to the latest technology equipped cars, this is a little beyond our imagination where the probable could be of hacking even a vehicle’s ECU, infotainment and hence its acceleration or braking system itself. Pairing smartphones, Infotainment components, Telematics, aftermarket ECU mapping tools are all normal routine of the racing breed, which can contribute to security threats. Without a proper security testing for the future infotainment systems, all our information from personal to vehicle details can be of a major threat. This paper will discuss about the potential security threats, Security testing setup, Vulnerability analysis, case studies and some of the counter measures to evaluate such threats in automotive components.

Key words: Security, Automotive infotainment, Threats, Counter measures

Penetration Testing is an important activity and ability to do the penetration testing effectively should not be limited to few senior security professional in an organization.

In our presentation , we will bring the systematic Engineering approach to Penetration Testing , such that it is not left for a chance.

We will touch upon the Security Principles and Threat modeling which are foundation for a secure product

Also we will present a success case of the application of this Engineering practice in our organization 

High level topics list that will be discussed are as below.

• Introduction

• Principles of Security for Secure Products

• Security in Product Development Life Cycle

• Threat Modelling

• Secure Coding

• Penetration Test Engineering analysis 

• Cyber Security- a mindset and some anti-patterns

• Conclusion

BigData with its slew of technologies and terms has been the most talked about area in last couple of years. This has evolved in Big Data Science, Analytics and now on the IoT and automation side. There is a need for testers and QA team to not only get used to this new age digital transformation area but at the same time embrace the technology to their own advantage. We have experimented and successfully used Big Data Technologies – Hadoop and MapReduce for a recent testing engagement. The actual application was implemented using classic technologies like CentOS and C++. Testing team implemented Hadoop and MapReduce to help in quick turnaround for the testing. We would like to showcase the entire case study on how the tools and technologies came in handy for a High Frequency Trading (HFT) application and had we not implemented the same what would we have missed. We would also share the entire CentOS/Hadoop/MapReduce VM with the participants. This would require the attendees to bring their own laptop with at least 4GB RAM (Available) so that they do some hands on exercises that we would like to share.

In the market today, there are a large number of devices with different resolutions and screen sizes. A tough competition exists wherein every client wants their website to run on all these devices.

Testing the same set of test cases on all the available devices in the market today is practically impossible due to the high cost factor, availability of all devices and amount of effort required to test on all these devices. Now a days, most of the websites are being developed as Responsive web design(RWD) websites. The RWD websites layout will adjust based on the screen size and PPI of the device. The main challenge for testing RWD websites is that the automation script generated for one device one platform will only cover the functionality, behavior and workflow. But the same automation script running on different devices ignores the  look and feel, Layout and UI alignment.

This Paper talks about using multiple tools available in the market currently for testing RWD website and our experiences related to them. We have focused majorly  on screenshot analysis and pixel by pixel comparison. We also have capability to execute parallel test cases for RWD website across multiple devices having multiple resolutions in one go along with continuous integration using Selenium and Jenkins.

Automation Testing has been the buzz word for ages in the testing world but never gets old. The reason - getting it right still eludes many. The quest for every testing practice has always been to identify the right Automation Testing tool for their environment. Some go for the most popular in the market, others go for an open source to save on costs. But how successful these choices prove to be? The first and the foremost question to ask is how good is the tool or framework for 'My Environment'? This presentation and demonstration will take you through one such journey where a correct focus on the environment is leading to an Automation testing revolution in the realm of Salesforce.

This workshop helps testers get an overview of what to do and what not to do under different circumstances. Then it is observed how they react/respond in those situations from where the learnings are derived. It focusses on the key testing and consulting skills. They can tie it back to real time project experiences.

Through a series of interesting phases with role plays and activities the entire workshop duration is full of energy and interactions.