When a tester begins his career, he usually learns testing from testing institutes and organzations. What they do is to impart technical skills and core testing techniques to the tester (Black box testing, white box testing, automation, boundary value analysis, etc.). What's forgotten is  "Lifeskills" (key skills for a tester to survive in testing). By Survival, I dont mean "mere existence in the company" as another testing resource year on year; I would define Survival as the tester's capability to constantly influence others, develop re-learning capabilities and indulge in "continous learning" throughout his career. Most of these lifeskills were originally designed by the "World Health Organization" for being used in education (which has been conveniently overlooked in our schools due to the demands of our "centum seeking generation"). These skills are expected to With these skills, the tester can work autonomously, make independant decisions, question others around him, challenge himself and help him in his quest towards excellence. Some of these lifeskills would include "Empathy", "Problem Solving", "Coping with Stress and emotion", "Critical Thinking", "Decision Making" etc. This talk is about the 1st 10 years of a tester's life and the lifeskills that he would need to start developing, sustain and drop at various stages of his 1st 10 years. The intent of this speech is to open up thoughts from everyone on this topic and get them to start thinking about the importance of having such "lifeskills" in testing education.

Mobile Apps market is growing rapidly and this has raised our expectations as a user. Study researchers have found that nearly 50% of consumers will delete a mobile app if they encounter just a single bug. More to that 35% of the consumers would report this bug publicly to friends or peers and in many cases, to the app provider itself. There is no way to hide poor mobile app quality in this era of social networking. Today's consumer demands high quality, are you ready to cater to it?

What if you could write functional tests without writing a single line of application code? What if those tests are written in plain English (so that anybody could understand) but still it's executable spec or source-code? What if you could generate the documentation from live production source code? Now you don't need to update the requirement doc all the time.

What's Specification by Example? Is it different compared to BDD? Who all participate in defining these specifications? Are functional tests and functional specifications same? These are the questions this session tries to answer.

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!

While we continuously implement new functionalities in our mobile app, automated functional tests acts as safety net and gives us confidance. Still, there is something missing. Many times we get feedbacks from clients like:
"Sign-In button has shifted a bit and user have to scroll down to see it"
"We asked to change background color of screen-X, it got changed for Screen-Y screen as well"
"Why has fonts of this link become so tiny?”
I am working on customer facing enterprise level Mobile apps of one of the biggest airline in the world. For us user experience is as important as functionality.
Our regression suit did not have capability to catch such issues. Moreover, we started building another airline app from the same codebase with only change in user interface of this new app. This means, change done for one app, affects another. Hence, it became really critical to enhance our automation with visual assertions.
There are many tools which can do this, but they charge hefty money and also does not give full flexibility. Therefore, I worte my own gem called 'nakal'.http://rubygems.org/gems/nakal

This talk brings into picture a very important person - the programmer & the programming team. Each one of us might have the experience of working with at least one tough programmer. Some programmers are very friendly and help us with finding bugs. Some of them are very strict with their deliverables and do not respond to any queries outside office hours. Some hardly talk to you unless you ask them a question. There are different types of programmers and bring in variety to our testing challenges.

With a rich experience of working with tough programmers, I present this talk to help you. I am very thankful to the programmers, especially the tough ones, as they are the ones who have taught me the most important lessons I had to learn to improve in my testing career.

There was a time when the buildings or a house had no doors, and that was because of less number of crimes or thieves or no thieves at all. As time passed, we started having doors, and then dogs to protect against any physical breach. And that was not sufficient, we thought of getting a security guard, CCTV cameras, sensors and more. Now, you see that we live in a world where are more crimes and is increasing. Its the same with the virtual world where your data is at stake. I will be speaking on why security testing is important and what happens if you don't treat it well enough in your testing profession.

Planning and Estimation faces the biggest challenge with the new technologies and need for innovation. Agile helps us to minimize this disruption through an iterative and incremental approach. Unpredictable events, Dev takes longer, business changes, retesting extends all of them live in Black Swan territory. What use is a five year test on a Radar when a Lidar replaces it? What to do with long term tests on a battery when it is replaced by one of the new lithium-ion capacitors? Instead of attempting to improve prediction we are better off developing a more robust approach to change by a rethink in testing and a testing mind-set. The emphasis of the report is on lessons of success and failure and what comes next, with lead indicators of such success. Emerging technologies such as mobile apps, tablets, 4G, cloud computing, and HTML5 are impacting software engineering and testing organizations across all industries. By enabling sensitive data to be accessed through the web and on mobile devices, there is immense pressure to ensure that apps are reliable, scalable, private and secure. With the evolving and popular market for wearable and connected devices has led to create simple, efficient and cost effective solutions. Though we are skeptical about the change, Agile minimizes these disruptions through several approaches. The internet of things devices extend its applications more than the smartphones. So how are testers prepared to test their devices in the real messy world outside the lab? What is the role of Tester?

The main objective of this talk is to highlight the key Quality contaminations and challenges that impact the Agile Scrum Teams and the remedies. It also mentions how scrum teams struggles for Quality assurance while implementing scrum and how defining Quality strategies helps.

Quality contaminations:

• No QA strategy/Plan or checklist or milestones defined for Project
• No Gates/Checkpoints defined
• No Metrics defined, measured and tracked.
• No Defect guidelines for Defect severity/priority clearly defined.
• No Defect RCA and Quality Improvement Plan (QIP) prepared.
• Not able to fit QA in same sprint as Development
• Don’t think before Test- No upfront test planning or defining/understanding of Test cases/scenarios
• QA part of Development Team- QA efforts not estimated, QA resource considered separate hanging entity in scrum team only responsible for QA
• No Technical Debt assessment and Reduction Plan

In a financial business world dominated by DATA intensive applications there is constant need to collect, manipulate, store and retrieve of large amounts of data. In addition most of the applications being process oriented require analysis and implementation of complex business rules to the data.

Few examples are taxation, customs, excise application, mutual funds, Fund Management organizations, where the underlying data typically scales over time.

Given that the tolerance for faults and errors in such applications is very small, focus has to be bought on how to effectively use data for robust functional testing.

Mostly the data challenges are possible to manage from a manual testing perspective, but that becomes very cumbersome and inefficient overtime, especially for regression testing.

In order to automate the regression of such applications, usually there are 2 options:

1. Automation tool and scripts build in the complex business rules and validation points in-line with the application. This implies that when tests are executed with multiple data sets, the values calculated by scripts should match the ones generated by the application.
2. The other approach is to use Managed Data to test the functionality of the application. This approach proves more beneficial for data intensive applications where input data is changing frequently. It allows the functionality to be tested against a predictable outcome and insulates the application from external and internal dependencies.

The focus of our discussion will be ‘Testing with Managed Data’ – framework details, prerequisites, pros and cons compared to other approaches.