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

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.

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.

Yellow: This 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