Monday, August 31, 2015

Applying Emotional Intelligence to Testing

Did you face the following situations in you career?

 In regression(last round of) testing stage, you logged a defect and developer did not consider it for this release. Same defect raised by the customer after releasing the product/project. Higher management asks you like "Why you did not communicate with us regarding this defect before release?". How do you answer this question?

Another situation like, your manager asked you to test/automate a feature. You analysed the feature and came up with three weeks schedule. Your manager accepts it and after one day he changes time from three weeks to one week. How do you handle this situation?

In both cases what actually upsets you? How do you actually communicate back in the right way?

You need to understand where another person is coming from. So that you communicate well. If you keep talking about test cases, they don't care.

Emotional intelligence is understanding what triggers you in terms of emotions, and then how you handle those emotions


A lot of testers focus on their technical skills and they learn lot tools and techniques.But they don't concentrate on communication skills.

 “Information and communication are two words that are interchangeably used, but mean very different things—information is giving out and communication is getting through,” - a quote by Sidney Harris 

We provide information for people to make those decisions, but it's the communication aspect that actually determines how successful we are.



We're distracted. We should listen with our eyes.


There was a young boy with father at the breakfast table and he says, “Daddy, I want to read to you,” and the father is there with the newspaper and he says, “Yes, I'm listening, dear” and he says, “No, no, Daddy, Daddy. I want to read to you, please listen to me.” Father says, with the newspaper, “I'm listening.” The child gets up from the table, pulls the newspaper down and says, “Silly daddy, you need to listen with your eyes.”

We're very distracted, and we're not always actively listening because we're inside our phone or we're thinking about what we have to do next. We get so caught up in all of our things in our heads even that we aren't present all the time




More blogs @ http://qadesigngurus.blogspot.in/search/label/Srinivas%20Panyala



Sunday, August 9, 2015

Omega Tester

Are you working with a big testing team? is your test team understaffed? if not it will be soon understaffed. Your teammates work on different modules of the product.If you feel you are working alone then you may calls yourself as Omega Tester.

Omega Tester generally faces the following issues.

Anything you do means something else won't get done: You cannot be a multi-task person. If you start your work then you will put on hold other tasks are like communicating with others, preparing, learning ..etc. You are a single-threaded person.

You feel too busy to plan and prepare: You may need to read functional specifications, discuss with developers, use tools and setup testing environments. You need to understand the product and imagine the risks to prepare test strategy. On top that you need to attend a lot of meetings. Finally, the pressure will be on you. A small amount of development can create a lot of work for testers. For example, A modern web application bug fix need to be tested on all affected areas, on all supported browsers, if web application supports different themes then you have to test on all themes. Developers create new functionality and testers need to catch up with them. They also introduce performance problems, scalability problems and usability problems..etc for free. You  cannot find these problems for free.

You feel too busy to mind your infrastructure: You need to stop testing and organize your test data, update coverage, and risks list when your desktop is full of notes and files. A good infrastructure for your test project gives you efficiency, but you may feel that efficiency is a luxury you can't afford

You feel too busy for curiosity: Testing is like a search. There is no optimal way to find bugs. Excellent testing requires that you test more than the obvious things in the obvious ways. You must indulge your curiosity. You must play. You must open yourself to the unexpected. For many testers, this can be hard to justify It looks like you are goofing off, instead of doing important work. So, when the pressure is on, curiosity is easy to put on the shelf. You then become a little more like a fancy robot; a little less like a powerful human tester

No one understands what you do: Programmers and testers both do work that is intangible. The difference is that programmers have a tangible finale: the software. The end product of testing is less tangible, and efforts to make it more tangible mean spending less time actually testing. Many people think testing is easy and they wonder why it takes you so long to find those "obvious" bugs. At least if you are in a team of testers, you can commiserate and share the burden of explaining the impossibility of complete testing for the 37th time. As an omega tester, you just feel surrounded by monsters.





Wednesday, August 5, 2015

Performance testing of a modern web application - Key points

Modern web applications are built using heavy javascript files. Many applications are providing application development online. Many applications are integrated with other systems. These are all forcing us to do a Performance test.

We need to define application performance first. You may think that using the following parameters we can define. 

How fast servers are responding?

What is the response time of a request?

How the system is handling large set(1000 or 2000) of users?

Sometimes we need to consider all above parameters or any one. It depends on application

Remember the following key points before planning a Performance test.

Know your users:

You should know who is using your application, what type of users using your application, and finally how they use your application. You can get this information from production system logs, monitoring tools, sales and support team.

Test Data:

Test data should be close to production data. We should provide realistic data. We should not use non representative data, as it may not be easy to validate. We should not start with very large data, it should be equivalent to the production system. Test data should be increased depending on the understanding of the growth of data in the application.

Compare Test Environment & Production Environment:

We should replicate the test environment with the production environment. We should not execute performance test on a small machine and calculate the requirements. This never works.
We should use same machines, same database, same load balancers.. etc

Rubber Duck Sessions - Tester can add value earlier in the Lifecycle

Before the agile process, testers used to start testing the software once the development cycle is completed. In the agile process, testers started involving early in the cycle. 

When we have multiple developers in the team they do code reviews. In this code review, they mainly concentrate on coding standards, code quality, never ending loops and deadlocks. Sometimes the software may not full fill the requirements.In this case, we require acceptance testing. If it passes the acceptance testing the will do the full round of testing.

This kind of situations we can handle by introducing "Rubber Duck Sessions". 
The name “rubber ducking” is a reference to a story in the book The Pragmatic Programmer , in which a programmer would carry around a rubber duck and debug his code by forcing himself to explain it, line by line, to the duck.

In these sessions, the tester will understand the software whether we had built the right thing or not before we start testing. These sessions some people call "Rubber Duck Sessions".

Tester can add value earlier in the Lifecycle

A tester will have a different view if we compare with the developer. This will help to build the right software. If we involve tester in earlier life cycle he can work with the developer and understand the software well, so that he can prepare the checklist or test scripts.  It is good to deliver the software to testers in workable pieces.  In "Rubber Duck Sessions" tester can detect anomalies if they exist.

With checklist or test scripts tester can write unit tests and as he knows the business requirements he can prepare some end to end scenarios and before delivery we can make sure that expected things work fine.

In the waterfall model, testers were not interacting with developers much. In Agile process speaking with developers and knowing them will not add direct business value, but it does open up space for conversation about what the developers are doing.
 

Thinking caps for testers

Innovative thinking may decrease day by day if you are working on the same project/product for long time. Testers commonly face challenges like one-dimensional thinking, limited ideas, time bound thinking.. etc

Testers need to come out of the comfort zone and think differently. Thinking caps process can help us in this situation. This thinking cap idea is based on a popular book by Edward de Bono, Six Thinking Hats

Blue: This hat tester should know the overview of the product/project. He should understand every situation or problem. People should contact him for any change. He should control the other caps and execute the project.

White: This hat tester should collect the information and analyse it. He should know all about requirements, user stories, defects logged and defects status, tools..etc. This analysed information will help us to take further decisions.

Red: This hat tester should have end user emotional angle. He is allowed to think positive and negative and whatever end user thinks. Anytime his thoughts may break the software. Should control him or his thoughts doing anything.



YellowThis hat tester is a positive thinker. He thinks of only product quality. Where ever bugs are found he thinks in a positive way and makes sure that all promised things work fine.

Black: This hat tester should always be active and careful. Whenever he sees risk he is expected to escalate it to the higher management. This hat tester helps us to find the problem at the earliest so that we can take decisions.

Green: This hat tester is a creativity tester. He will come up with new ideas and reduce the efforts. He provides alternative solutions for any problem. He will brainstorm the team put the team in a comfort zone.



Putting a hat is not a simple job. Should understand the ability of each team member and assign. There is no magic in this process just think on specific lines.

Fiddler for Security Testing

In today's cloud world every application is a web application, and each application has many components. Every component communicates with other components. 

Inter-component communication requires authentication. This authentication mechanism generally happens with a secure token. Some people use current date and time to generate this secure token and this token may valid for some amount of time(E.g., 20 mins). 

If secure token is generated based on current date and time then using this security token anybody can do any action on the application without authentication. Most of the time while logging people may not bother much about security and they use this kind of tokens to log the information without any authentication.

Most of the cloud vendors are providing public cloud and private cloud applications. If they use this kind of security token then hackers may use private cloud application generated token to access public cloud application and they can perform any action until that token expires.

To verify/test  this kind of security defects we need a tool to find security tokens. Fiddler is http(s) traffic recorder tool. Using this we can record all http(s) requests and responses.


Automate SSL decryption

With Fiddler it’s up to you to decide which HTTP(s) requests and responses to decrypt and which not. If you have the decryption feature enabled, you can choose the processes which will be automatically decrypted for you. You can select between:
  • All processes
  • Browsers only
  • Non-Browsers
  • Remote clients
Use the decryption process filter to avoid decrypting traffic that you do not care about—you can exclude such traffic easily using this option.

Fiddler security add-ons

Fiddler can help you achieve many security testing goals: Eric Lawrence, the creator of Fiddler, as well as some web security experts have built several robust add-ons that empower even newbies to discover and resolve security issues. Here’s a quick list of these:
  • Watcher – Developed by the Casaba Security team, Watcher observes a browser’s interactions with your site. The tool scans requests and responses, flagging potential security vulnerabilities.
  • x5s – Another add-on from Casaba Security, x5s evaluates your website’s vulnerability to cross-site scripting bugs caused by character-set related issues.
  • intruder21 – This add-on enables fuzz-testing of your web applications. Once your target requests are identified in Fiddler, this extension generates fuzzed payloads and launches them against your site.
  • Ammonite – Detects common website vulnerabilities including SQL injection, OS command injection, cross-site scripting, file inclusion, and buffer overflows.

Load Testing with Telerik Test Studio

Now a days most of the web applications are invoking external web services or RESTful services to get the dynamic data. If external services takes more response time then web application performance will be decreased. This can lead to unsatisfied application users.

Load testing is becoming must for web application. Load testing using Telerik Test studio is a simple tool to develop a load test and run

Load Testing with Telerik Test Studio involves below simple steps

1) Record the test
2) Modify the dynamic parameters
3) Set the number of users & time
4) Run




Key Features

  • Multiple Channels to Create Load Tests
  • Crafting Complex Load Testing Scenarios Is a Snap
  • Load Testing of Web Services
  • Load Testing Traffic from Mobile Devices
  • Easy to Setup, Easy to Run
  • Test Lists Scheduling and Distributed Execution
  • Smart Diagnosis of Issues

You can also create test from regular Test Studio functional test and Fidler trace

Want to do Load test of a simple Web UI test? JWebUnit is sufficient

Concurrent user scenarios very common when  you work for a  web application if it is used by multiple users across the globe.There are some challenges when you test these kind of scenarios.

If you want to do a load test for you web site then you can go for any commercial tool like Telerik Test Studio,Neo load,Load runner..etc

There are some scenarios  like we need to validate a  defect(small web ui steps) which required some concurrent  users login or need to do load test of just login ui. In these cases you can use JWebUnit.

JWebUnit is a Java-based testing framework for web applications. It wraps existing testing frameworks such as HtmlUnit and Selenium with a unified, simple testing interface to allow you to quickly test the correctness of your web applications.

Setup:

1) Download latest version of JWebUnit jars here . One lib folder will be available.
2) Write a java program
3) All above lib folder jars to classpath.

Sample program:

import static net.sourceforge.jwebunit.junit.JWebUnit.beginAt;
import static net.sourceforge.jwebunit.junit.JWebUnit.clickElementByXPath;
import static net.sourceforge.jwebunit.junit.JWebUnit.setBaseUrl;
import static net.sourceforge.jwebunit.junit.JWebUnit.setTextField;
import static net.sourceforge.jwebunit.junit.JWebUnit.submit;
import static org.junit.Assert.*;

import org.junit.Test;


public class ExecuteWebUI {

@Test
public void test() {
     setBaseUrl("http://xxxxx/router/login");
             beginAt("/login.jsp");
             setTextField("loginName", "xxxxx");
             setTextField("password", "xxxx");
             submit();
}

}

Using eclipse:

1) Create a Java Project
2) Copy above downloaded lib folder to this project
3) Add all lib folder jar to project classpath
4) Create a JUnit test case

Are you storing test results in Database or in flat files? Try Rollbase. You can get better reports and you can save lot of time


After executing each test case/suite we need to store test results some where. Generally we  store test results in database,flat files or sending mails.

Generally higher management need test results statistics like Daily,weekly,monthly..etc test reports.To provide these reports we need another application (may be a web application) which can read test results from Database,flat files, mails and display in nice format. Some times we need to send test results statics in email to higher management.

To develop this application QA need to spend lot of time and team required some development skills

In this case you can try Rollbase 

Rollbase is a platform as a service (PaaS) software solution. You can get rapid application development in the cloud, with minimal coding. Build, deploy and manage cloud-based applications with a single tool designed to get you up and productive fast.

Rollbase is a cloud application. Rollbase provides REST API to create records.



Rollbase has many features like Charts, Gauges..etc. Using these features you can display test results in better format.

Rollbase has other features like batch jobs and triggers. Using these features you can automate the process of getting test results analytics.

Rollbase also supports sending emails,sms, mobile app so that you can get the report anytime and anywhere

You can also build a dashboard to see the Live results in a single page

Want real product installed in test environment instead of simulated product installation?


We test different kind of applications like Console Application,Windows Application & Web application.

To test any type of application we need system run time environment. To run unit tests or system tests we setup a run time environment which is mostly a simulated one not the real customer product run time environment.

There are some advantages with this simulated environment. Setup can be done easily,Debugging may easy, Continuous integration may be done easily.. etc

We can modify this simulated environment to real product environment with Install Automation.

Generally we use InstallShield or InstallAnywhere software to provide installer to customers to install our product. Both supports silent installation.

Silent installation is a installation type. We can install software without UI.

Using following command we can install software without UI

C:\xxxx_vxx.exe -i silent -f installer.properties


How to get install.properties?

First install the product using UI. Normally it asks for installation directory and other required options. After installation done successfully. Move to installed directory and search for install logs.

In one you can find the all user interactions recorded.

Sample installer.properties looks like below


#Destination and Working Directories
#-----------------------------------
USER_INSTALL_DIR=C:\\xxx\\xxx

#Database Type
#-------------
USE_EXISTING_DB=1
INSTALL_NEW_DB=0

#Database
#--------
DB_HOST_NAME=localhost
DB_PORT_NUMBER=9999
DB_USER_NAME=xxxx
DB_PASSWORD=xxxx
DB_NAME=xxx
DB_LOCATION=C:\\xxx\\xxx\\xxx


#Application Server
#------------------
USE_NEW_TOMCAT=1
USE_EXISTNG_TOMCAT=0
TOMCAT_DIR=C:\\xxx\\xxx\\xxx


You can use same installer.properties file to install on all OS platforms like Windows,Linux,Sun Solaris,IBM AIX, HPUX.. etc

Installer UI may not support in platforms like HPUX and IBM AIX. Using this silent install you can install the product easily.

You can use this to install on cloud machines by connecting using Putty.




Need to do large scale email analytics? Don't worry Rollbase can help you



Now a days people are busy. We don't want to use multiple applications.We want every thing on emails. 

For example: Forum Questions.

Employees can log into Forum application and they can reply but employees are happy if they get forum questions via email and they are happy to give reply via email.

Higher management  want every thing in email like weekly status, monthly status, daily discussions...etc

Of course we use rules/filters to move emails to separate folders 


After some years will have lot of emails. If we want generate some analytics based on a component or a word. Rollbase can help you.

Rollbase is a platform as a service (PaaS) software solution. You can get rapid application development in the cloud, with minimal coding. Build, deploy and manage cloud-based applications with a single tool designed to get you up and productive fast.

Rollbase provides API to read emails. You can write your own logic in JavaScript

http://documentation.progress.com/output/Rollbase/index.html#page/rb/email-api.html

Example
rbv_api.openPOP3("mail.mydomain.com", 995, "address@mydomain.com", password, null);
var arr = rbv_api.getMailMessages(100, 110);
for (var k=0; k<arr.length; k++) {
var m = arr[k];
rbv_api.println(m.get('subject'));
}
rbv_api.closeMailSession();

After writing logic to filter out emails using Rollbase other APIs you can create records in Rollbase system. Once you get data in Rollbase then you can utilize Rollbase features like Charts, Reports.

You can use batch jobs to run your logic daily and get live email analytics

Finally you can get analyzed report as a email 

How we tested a critical feature of cloud platform with zero customer defects



We got a critical(architecture level change ) feature for testing. We followed a different approach to test this feature and we achieved zero customer defects.

Why different approach?

Our Cloud platform is integrated with many other cloud products.We use a integrated environment for regular testing. If we directly test on regular integrated environment then all other product teams may get disturbed if we have any critical bugs. Instead of wasting other team members time we followed a different approach.

Steps followed:


1) Dev Testing

QA provided automation tests to Developer. Developer ran all automation tests on dev environment

and fixed the defects. Provided a good stable build to QA.

2) Regular QA build testing

QA did a full round of testing on regular QA build. Ran all automation suites like Manual tests, API tests,UI tests.. etc

Verified all existing defects.

3) Testing on Cluster setup

QA did a full round of testing on Cluster setup. Ran all test suites on cluster setup.

4) Testing on Customer environment 

We simulated a customer environment. The customer who is going to get benefited more with this feature. We executed customer specific tests.

5) Testing on Integrated environment

QA did full round of testing. Executed all automation tests. Did not find any integration defects

6) Testing on Stage-prod

QA did sanity test of all features.




Finally we released the feature and no defects reported by customers.


How to invoke RESTful webservice from ANT script


We got a requirement like we need to send automation results to Cloud Platform www.rollbase.com.

We used HTTP Post ANT task to send automation results to www.rollbase.com.

We can invoke REST service from ANT script using POST ANT task.

Example:

    <property name="test.val" value="here's my test value"/>
    <property name="test.val2" value="second test value"/>
    <post to="http://wwwj.cs.unc.edu:8888/tang/servlet/tangGetPostServlet"
        verbose="true">
        <prop name="prop1" value="val1 ${test.val}"/>
        <prop name="prop2" value="val1 value 2"/>
        <prop name="prop3" value="val got some spaces %funky ^$* chars"/>
        <prop name="prop4" value="&amp; do an ampersand like this &amp;amp; or
        Ant will whine"/>
        <prop name="thanks" value="dude, thanks for the echo server!"/>
        <prop name="test.val"/>
        ${test.val2}
    </post>


Prerequisites:
  1. Copy ant-contrib-0.3.jar to the lib directory of your Ant installation. If you want to use one of the tasks in your own project, add the lines
    <taskdef resource="net/sf/antcontrib/antcontrib.properties"/>
    
    to your build file.
  2. Keep ant-contrib-0.3.jar in a separate location. You now have to tell Ant explicitly where to find it (say in /usr/share/java/lib):
    <taskdef resource="net/sf/antcontrib/antcontrib.properties">
      <classpath>
        <pathelement location="/usr/share/java/lib/ant-contrib-0.3.jar"/>
      </classpath>
    </taskdef>



Page Object Pattern may solve your UI Automation Tests maintenance problem

UI Automation Testing Gone Wrong?

Consider the following example: 

To automate a website, we will download a automation tool. Using screen recorder will navigate to your website and go click, click, type, click, type, tab, type, tab, type, click and assert. Then you replay the recording and it works. Sweet!! So you export the actions as a test script, put it into your code, wrap it in a test and execute the test and see the browser come alive before your eyes and your tests run very smoothly. You get very excited, share your findings with your colleagues and show it off to your boss and they get very excited and go: "Automate ALL THE THINGS"

A week later and you have 10 automated UI tests and everything seems great. Then the business asks you to replace the username with email address as it has caused some confusion amongst users, and so you do. Then like any other great programmer you run your UI test suite, only to find 90% of your tests are broken because for each test you are logging the user in with username and the field name has changed and it takes you two hours to replace all the references to username in your tests with email and to get the tests green again. The same thing happens over and over again and at some point you find yourself spending hours a day fixing broken tests: tests that didn't break because something went wrong with your code; but because you changed a field name in your database/model or you restructured your page slightly. A few weeks later you stop running your tests because of this huge maintenance cost, and you conclude that UI testing gone wrong.

You should NOT use any screen recorder to develop your test cases. That said, it's not the screen recorder itself that leads to a brittle test suite; it's the code they generate that has inherent maintainability issues. Many developers still end up with a brittle UI test suite even without using screen recorders just because their tests exhibit the same attributes.

What is wrong with this test?


Who is a good QA Architect?


The Quality Assurance Architect provides highly specialized and advanced technical expertise and mentoring in the design/development of product testing/quality processes and in developing testing architecture

Responsibilities

  • Provides advanced technical expertise and mentoring to the quality assurance team and the broader organization. Champions quality assurance process improvements across the organization.
  • Analyzes new and emerging trends in quality assurance architecture, evaluates alternatives, and completes feasibility studies.
  •  Provides advice to senior management on quality assurance advancements, and makes strategic methodology and development recommendations
  • Designs and develops product testing/quality processes, ensures a team review of defects in assessing product quality, and facilitates the review of applications for testing needs and requirements/design quality.
  •   Maintains up-to-date knowledge of current information technology techniques and tools.