Testing Zombie – Are you becoming one?

Slowly and steadily, with reasons or without, deliberately or out of innocence, many of us are becoming the Zombies of the testing world. Some people become part of this immediately after college when they start the job and some become as they grow up the ladder and start losing interest as they lose the aim and motivation.

Who is a Testing Zombie?
A Testing Zombie is a person that has been turned into a creature capable of testing without any rational thoughts.

How to find a Testing Zombie?
It is easy! To find a zombie around you, just look for the following symptoms/ characteristics

  • Is (s)he just coming to work as (s)he has to and does not take any ownership of actual testing?
  • Is (s)he hiding behind processes instead of testing?
  • Is (s)he pointing fingers on others instead of owning the failures?
  • Is (s)he does not understand the product functionality under test?
  • Is (s)he does not understand the technology behind the product under test?
  • Instead of owning the release and working in collaboration with product stakeholders, does (s)he wants to block the release to avoid future failures or blames?

Though, the above is not the only comprehensive symptoms list that can help you identify a Zombie in testing, you can add more negative behaviors to this list. But, if the answer to any of the above is “Yes”, you have potentially found one around you.

Types of Testing Zombies
These zombies can be found at any level in hierarchy. I have defined only the 2 broad categories below and will leave rest of them onto you to define.

  • Zombie Tester: These are the people who, land a job in testing just because they did not get anything else to work upon. There is no inbuilt motivation in them to work as a tester. They start working on the project as they are assigned one, execute the test cases that are written by others, word by word, point to the test case author for any missing step and reasons why they missed anything during testing and try to look good as a tester. They only have one mastery and that is to how to blame others for their misses.
  • Zombie Test Manager: These people, though have grown up the ladder in the organisation based on the years of experience, but do not understand the basics of the need of testing. Test Strategy and Test Plan for them means to fill up the information in  the templates. They are highly diplomatic and use their team(s) to run the show till the things mess up. They do not understand the complexities involved in the product, both at technical or non-technical front. They have the mastery to hide behind processes and create a hidden trap which is hard to break. These are mainly “Yes Boss” kind of people and do things mainly to please their bosses.

These kind of people are increasing in numbers at an epidemic rate in the corporate world and the time is not far when we all might be surrounded by them and it might lead to the end of the world for “Testing”! With time, we might also be bitten by one such Zombie and  will be pushed to become part of them.

It is a high time and imperative for each one of us to do some retrospection and see if we want to correct our paths so as to save ourselves in becoming a ZOMBIE!

Advertisements

Latency and it’s importance during Performance Tests

What is Latency?
Suppose a request is sent from the application to a server. There is a certain time lag before it reaches the server and before it starts the actual processing based on the received request. This time lag is called latency or network latency.

In other words: Response time of a request = Processing time + Latency

Why consider Latency?
The majority of performance tests that are conducted within organizations are run from a local load source using performance testing tool like Jmeter, LoadRunner etc. in the same availability zone. As the tool resides in the same network, the latency is extremely low or negligible, probably in some milliseconds. But, in the real world scenario, any application will never have this kind of latency as the networks will be different. As observed in multiple projects, such things can add event up to 750 ms depending on the mix of traffic received by the application from global hits. With such things, the application can perform awfully wrong per the user expectations resulting in the SLA non-compliance.

Normally, a Webserver spends less time waiting for a response when the latency is low say 1 ms and hence allows it to handle a much larger volume of traffic that is spread over a much lower number of threads. Now let us consider that we change the latency to 300 ms. If the application has a 1:1 ratio of thread:Transaction, this will cause ideally around 300% increase in concurrency at any given point of time. And this will definitely lead to the performance box running out of threads or memory and will never reach the actual performance levels seen during low latency.

Latency issues could also highlight probable bottlenecks in the code where the application blocks processing while waiting on other threads to complete.

How to Introduce Latency during Tests
One can mimic production latency in the performance testing environment to ensure that the application is not only tested for the ideal performance, but also stress production similar concurrency levels under low latency. To mimic the production like environment one should generate the load for the tests remotely using cloud like AWS or mimic various bandwidths inhouse.

There are tools in the market that can help mimic the various bandwidths during the performance tests. Some of the tools are

How to Monitor Latency and Impact during Tests
There are multiple tools that can help monitor the application while the performance tests are being run. Some of them are

  • Dynatrace  can be used to perform application monitoring and identify the bottlenecks arising due to latency
  • Latencies Over Time JMeter plugin – Can help in identifying latency at development level

Do share your experiences encountered with and without considering latency on your performance tests.

KISS Agile Standups

Almost all the IT organizations across the world are in some kind of a race to adopt Agile. Post decision and Agile is selected as the process, the first challenge that anyone faces is to broadcast who is doing what in the team. To meet this challenge,  the best defined solution is to have a daily standup scheduled.

These  Daily standups have become a trend in project teams. The team has an awesome feeling when Agile starts as it seems to be connected. Though some projects master how to organize these meetings, but many of such meetings become a status call and slowly as the projects progresses, team starts losing the steam. People start ignoring it as it becomes time eating meeting, as other ones, and people prefer to complete work rather than giving status.

To resolve this challenge, the only way to keep the momentum going on for this meeting is to “Keep It Short Stupid”.

kiss

Do not let it become just another status call!

Meetings – Attend/Schedule Responsibly!

meetings

Disclaimer: This post is completely based on fiction. Any resemblance to any company, living or dead, is coincidental and author does not take any responsibility for the same. The figures used to demonstrate are just for reference and to get the exact costs for your company, it is highly advisable to change the figures as per your company policies.

This post will provide an insight how to calculate a cost of any meeting. The meetings, that are intrinsic part of the corporate world, and that are key  to bring in collaboration between stakeholders and teams, needs to be arranged and attended with a sense of ownership to avoid wastage.

Let us take an example from a live scenario in any IT services company where 10 stakeholders (3 management, 4 solution consultants, 2 reviewer, 1 coordinator) are required to drive a proposal. We will use the below scenario to calculate the costs

  1. Meeting 1: Initial meeting to broadcast the information is called for 30 mins in which all 10 people are present
  2. Meeting 2: To identify and align on the team members, a 60 mins meeting is called
  3. Meeting 3: To check if we are on track, a 60 mins meeting is called
  4. Meeting 4: To check if we are on track, a 30 mins meeting is called – 4 out of 7 participants do not turn up, hence meeting gets cancelled after 15 mins
  5. Meeting 5: To check and review the proposal, a 60 mins meeting is called – all required people come as there were escalations last time, there is a lot of hue and cry and amidst discussions, meeting gets extended to 90 mins.
  6. Meeting 6: To review the solution, a 60 mins meeting is called; changes suggested in the solution and next review meeting is planned for next day
  7. Meeting 7: To review the solution, a 60 mins meeting is called; 2 solution people got stuck in another meeting and hence not able to join, meeting cancelled after 15 mins
  8. Meeting 8: Review meeting called to review the complete proposal ; a 90 mins meeting is called
  9. Meeting 9: Final review and closing; a 90 mins meeting is called

If we look at the above meetings, here is the overall cost of each meeting that company incurred

Duration (in hrs) # of Management Personnel # of Consultants # of Reviewers # of Coordinators Total Cost (in USD)
Meeting 1 0.5 3 4 2 1 420
Meeting 2 1 1 3 2 1 560
Meeting 3 1 1 3 2 1 560
Meeting 4 0.5 0 2 1 1 150
Meeting 5 1.5 1 3 2 1 840
Meeting 6 1 1 3 2 1 560
Meeting 7 0.5 1 2 1 150
Meeting 8 1.5 2 3 2 1 990
Meeting 9 1.5 3 4 2 1 1260
Total Cost 5490

Please note that the above costs only include personnel costs. If you add infrastructure costs as well into it, this will definitely double up.

This simple scenario can be related in any organization, but will leave on to you to utilize this information to calculate the cost of the meetings and see how they will be looked after that!

Book Review – “Jasmine Cookbook”

I have been involved in doing evaluation of a lot of tools and frameworks to suite the day to day project and client needs. Recently did a research on “Jasmine” to validate and check it’s implementation feasibility for BDD when I hit “Jasmine Cookbook“.

I was quite intrigued when I received this book written by Munish Sethi, as it provides practical ways how a novice can actually learn Jasmine quickly and easily. So, is it a ideal reference book for a product team to get handson on Jasmine quickly?

In short: Yes. It acts as a great reference for the teams who want to implement Jasmine for their products. More importantly it acts as a quick reference for anyone who wants to begin with Jasmine.

This book is divided into 9 logical chapters with each chapter focusing on a particular need that any team might be having at any particular phase of a SDLC i.e. from evaluation phase till actual implementation and measurement phase. Some of the key focus areas that the writer has brought out very clearly are

  1. How Jasmine can be implemented in teams following either TDD or BDD. It becomes easy for the user to understand and implement it in the projects thereafter.
  2. All examples relate to the real world scenarios a layman might get into, hence, makes them easy to understand
  3. Provides a detailed step by step approach to write your own custom “equality” and “matcher” functions in Jasmine
  4. Performing mocking using spyOn() method, Asynchronous operations and  Implementation of Fixtures and manipulation of DOM with Jasmine tests is explained in detail.
  5. Includes practical usage and designing of Jasmine based automated tests to validate complex functionality developed using AJAX, jQuery, JSON Fixtures
  6. Apart from the automated tests, it also includes methodologies to validate the code coverage achieved through the automated tests using JavaScript Code Coverage tool Karma and Istanbul that can enable product teams to keep a check on what they are testing.

Towards the end, Jasmine integration and usage with other tools like Angular JS, Node.js and CoffeeScript is touched upon. Though these could have been detailed further, but it gives a platform to quickly start in case there is a need for these technologies. But, overall the book is a great guide for a product team to take small steps to learn and implement Jasmine as per their needs.

Internet of Things: iBeacon and it’s adoption in Travel

As technology advances, organizations are feeling the need to be more and more connected with the customer to increase user experience. Apart from user experience, they also want to keep a track on the customer habits so as to utilize them for targeted marketing. With this aim in mind, there is a lot of innovation happening and “iBeacon” is one of them. There are lot more Beacons being developed by many companies for both iOS and Android, but to keep it simple, we will focus on iBeacon for now.

What is an iBeacon?

iBeaconiBeacon, as the name contains an ‘i’, definitely is developed by Apple. It is a Bluetooth low energy (BLE) device, that is specifically designed to connect iOS devices, to provide a location based information and services. It enables apps on iOS7+ based smartphones and tablets to connect and perform actions when they come in close proximity to an installed iBeacon. How does it work? iBeacon works along with a customized app on your iOS  device, specifically designed and developed to listen to the signals being broadcasted by iBeacon. An iBeacon categorizes the broadcast based on whether the user has entered, exited, or lingered in the region where iBeacon is installed. Apple has categorized the distance between iBeacon and receiving iOS device into 3 distinct ranges:

  • Immediate – Within a few centimetres
  • Near – Within a couple of meters
  • Far – Greater than 10 meters

Based on the distance between iBeacon and actual devices, apps can be instructed to perform different actions on the user devices. As per wiki, iBeacon can be configured as below

iBeacons come with predefined settings and several of them can be changed by the developer. Amongst others the rate and the transmit power can be changed as well as the Major and Minor values. The Major and Minor values are settings which can be used if you want to connect to specific iBeacons or if you want to work with more than one iBeacon at the same time. Typically, multiple iBeacon deployment at a venue will share the same UUID, and use the major and minor pairs to segment and distinguish subspaces within the venue. You can for example set the Major values of all the iBeacons in a specific store to the same value and use the Minor value to identify a specific iBeacon within the store.

How can iBeacons be useful for Organizations and individuals? There are various ways travel and transportation industry can use iBeacons to improve user experience. Some of the real world use cases can be

  • Hotels can implement iBeacons in premises to provide indoor mapping. In case of any emergency, guests can be guided to a safe place.
  • While visiting an airport, iBeacons paired with an app can keep a track of your movement within the airport. The app can guide you to the right direction based on your boarding pass.
  • You are a very frequent traveller with an airlines. As you approach to the checkin counter, the Agent receives an alert with your image, name and status level. (S)He signals you and calls you by name to invite you to help you in checkin quickly.
  • If your tagged baggage comes within iBeacon threshold configured in your app as it arrives on the airport, alert is triggered on your phone and you can take your baggage without looking at tags of other suitcases.

These are just few use cases, but industry is aggressively waking up with the plans to utilize iBeacons to get more connected to the consumers and improve customer satisfaction. As per SITA Labs iBeacon technology has a great potential to trigger better passenger experiences in airline and airport apps“. Virgin Atlantic has started trials to improve Upper Class passengers experience at Heathrow airport using this technology. It would be good to wait and watch and see how industry finds more and more uses of this technology! Not only Apple, but there are lots of other companies that want to evolve this technology further and are involved in developing BLE enabled beacons. Some of them are

  • PayPal
  • Qualcomm
  • Estimote
  • Swirl
  • GPShopper
  • Accent Systems
  • April Brother
  • BlueSense
  • Gimbal Series 10
  • Glimworm
  • Kontakt.io
  • Kstechnologies
  • Minew
  • Radius Networks
  • RECO
  • RedBear Lab
  • Roximity
  • Sensorberg
  • Sensortag
  • Todally

In this blog the focus was more to understand the iBeacon. In the next blog, I will start with the testing part of iBeacons and it’s surrounding apps and will try to uncover some of the nice to know things for the testing world :).

Stay Tuned!

7 Tips to screw any Test Automation Initiative

Companies often spend a lot on performing test automation to reduce the efforts spent by testing team. We read a lot about how to make the automation projects successful, but, have you ever thought on how you can achieve it otherwise. If you are one who want to make any of the automation initiatives unsuccessful, do proceed reading further.

Don’t involve team during planning

Planning is not important. Just tell people what areas they will work and they will deliver. This will ensure that people are spending time in delivering what they are asked to do without putting their brains behind.

Select tool based on team knowledge

Irrespective of the technology used by the application, use the tool that the team members assigned to the project knows. Don’t waste time on hiring or updating the skill sets of people.

Estimate based on your scripting speed

Don’t consider test case complexity/team skill sets/learning curve/hiring time etc while estimating the efforts. Just estimate based on how much you alone will be able to achieve.

Automate areas having high probability of changes, first

Consider that the critical areas from the point of testing are the ones that are getting changed in every build. Start automating them first. This will ensure that the team spends the time on maintenance rather than new development.

Freeze the build for the complete duration of project

Before starting the project, be strict on not changing any product build, irrespective of releases made to the testing team in between. Just make your scripts compatible with the initial version of the build provided to you. This will ensure that your scripts do not run on the latest build and hence will help in failing the UAT.

Avoid any communication with stakeholders

Stakeholders always ask for reports that often decreases the productivity. They also do not have any rights to get information on the challenges that the team is facing. If you want to fail miserably, it is seriously advised not to tell stakeholders anything about the project before the final delivery.

Keep Script integration at low priority

Do not estimate for script integration and do not even care for it. If time permits, then do it immediately before UAT so as to ensure there is enough evidence of script not working.

In case you have any other tip, request you to share it in comments and I will add it up in the upcoming post.