Agile Teams and Communication

I was reading this interesting article about Elon Musk and his brilliant email communication rule. Here is the link —>

The point that caught my specific attention was how communication across team and hierarchy is encouraged without it being forced to go through the ‘proper channels’.

All the Agile teams (irrespective of the underlying frameworks) need to follow the Self-management and Self-Alignment approach. The team members drive the productivity through quick and frequent communication with each other, the focus is to have Autonomous Teams. But anyone who has actually worked in Agile teams will knows that it is easier said than done and specially when there are multiple teams and communication has to take place across the teams, the communication suffers on various degrees of severity. We need to catch whenever this happened and even better that we work proactively to prevent this.

But how do we track the communication efficiency? Can we have a metrics around that? It certainly sounds worthwhile to do so and I always keep in mind Goldratt’s famous quote “Tell me how you measure me, and I will tell you how I will behave” whenever it comes to metrics.

In XSCALE Business Agility (XBA) training we dedicate an entire section on Autonomous Teams and measuring the effectiveness of the communication. Here are few excerpts from the course:

1. Ideal team size by is suggested as 6, it also enable us to create 3 pairs and 2 triplets. At time it pays to have triplets, the third person can act as mediator or sounding board in certain situations.

2. Collaboration Loop Limit (CLL) is one of the key metric that can be tracked. This essentially measure the maximum number of conversations that have to happen for any two people in an organisation to collaborate.

3. As number of teams grow and we create a structure for communication, we have to be aware of Dunbar’s Limit ( Dunbar’s number is a theoratical limit to the number of people with whom any individual is able to sustain a stable or meaningful social relationship (usually considered to be roughly 150).

picture credit:

XBA training also suggests the ways in which teams can be formed for effective communication, about the leadership in the teams, prioritisation, conflict resolution and there is a very insightful and entertaining cards game around The Tragedy of the PMO. The team structure and communication has lasting impact on learning and self-propagating transformation. More on this later.

Java on my mind!!!

Java on my mind!!

As the FREE Online Java Boot Camp from Agile Testing Alliance garners lot of interest from testing enthusiasts, the question to debate is why only Java? Why Testing Heads are recommending their manual testing professionals to learn Java? Would they like their testing team to start developing Java applications? The answer is simple – Selenium being the most popular open source automation tool in the industry and Java being most preferred programming language for scripting its a no brainer that Java + Selenium is one of the popular combinations used by Automation professionals!!!

When we do CP-SAT (Certified Professional Selenium Automation Testing) Training we often get lot of manual testing professionals who get overwhelmed by seeing Eclipse, Java code and frameworks. So the idea to have free Java Boot Camp came from there so that Selenium learning becomes easier

So what we teach in FREE Java Boot Camp which is conducted online in weekends?

We divide into 2 modules – Basic and Advanced

Basic involves Datatypes and Strings, Loops in Java (if, if else and nested if else, for loop, while, do while loops), One and two dimensional array, Methods In Java, Return Type Of Method, Access Modifiers In Java, Static, Non Static Methods, Variables and Variable Types In Java

Advanced involves Objects In Java, Constructor In Java, Inheritance in Java, Interface In Java, ArrayList In Java, Hashtable In Java, Read-Write Text File, Exception handling in Java, Encapsulation, Polymorphism, Abstract Class, Difference between Abstract Class and Interface, Method Overloading, Final and Super Keywords in Java

The entire online sessions which are conducted on weekends are hands-on i.e. participants write the code in their own Eclipse IDE. Whats more, all session are recorded and participants get lifetime access for the recordings so that they can practice anytime they want!!!

This is enough for a manual tester to get acquainted with Java and proceed with Selenium scripting – be it a simple Selenium WebDriver object creation, or a Page Object Model or a Data Driven Framework.

Is this really FREE or there are any hidden charges? – There are no hidden charges and 1000 INR is charged which is refunded as soon as you attend the training program. This is to ensure serious participation. So its absolutely free with only one condition – you must attend the training program. Period.

What are you waiting for? Enrol into this FREE Java Boot Camp now and get trained from the comfort of your home and start your Automation journey!!!

PS: FREE Online Java Boot Camp will be conducted with Java Basic on 23-Sep and 24-Sep and Java Advanced on 7-Oct and 8-Oct

Why we loved Selenium IDE

Yeah, “loved”, you guessed it right!! Selenium IDE is going to be discontinued from Firefox 55 onwards. Well we wont go to the reasons behind that. You can read that here.  As we gear up for our next upcoming batch for CP-SAT Training we take back and look into some interesting things about this cool plugin.

As a CP-SAT Certified Trainer and as part of CP-SAT Curriculum we  always start our training with Selenium IDE. The reasons are many but boils down to these –

  • Manual Testers found it motivating to see they can automate their test and generate script using a simple record and playback facility. This boosts their confidence and gets them to the groove.
  • QTP enthusiasts could relate to it easily !!

Half the battle is won and your participants are now raring to go ahead. Selenium IDE gives lot of confidence and enthusiasm to the manual testers who are exploring to start their career in Automation. Since its vast and thsi post isn’t going to be a tutorial on Selenium IDE, we will look into some interesting things about this awesome tool –

Readymade Locators:

When you start recording the script you will see that it gives you all type of locators as much it can in the form of Selenese commands. Be it id, xpath, css or link. This way it makes it easier to copy paste the locators to further another editor like Eclipse.

Another plugin which similarly gives all locators of an element is Qbot.

As you progress in the training and start exploring simple Java commands to achieve your task you will see a slight dip in the learning curve of students. You will see participants struggling with Java syntax and more. Thats where the Clipboard format comes into your rescue!!

Clipboard Format

The Clipboard Format helps in converting your Selenese commands to a programming language syntax like C#, Java, Python or Ruby!! Thats it. Participants are now happy that they can atleast not worry about the syntax. Please note that not all Selenese commands will get converted into your programming language syntax. For e.g. mouseover command doesnt get converted into Actions Class in Java.



Similarly with Clipboard Format as you go further the Format option gives you the code with entire Junit/TestNG annotations. You don’t need to bother whether you have included the all the pre, test and post annotations. I have seen many participants who practice the code/exercises during the CP-SAT training or after the training use Selenium IDE for recording their scripts so that they hit less keystrokes. Infact i use it always a starting point whenever i want to do Automation pilot for our consulting projects, unless ofcourse the application is not supported by Firefox.

Regular Expressions

Often in the 1st day of the CP-SAT training itself you will find QTP enthusiasts asking this question – Does Selenium supports Regular Expressions? Ofcourse it does. Just use regexp with the text in the command window and it will give you the output. For e.g. regexp:Web[Dd]river command will work exactly same as for “D”phere and “d”river. That means it will return the values having text WebDriver as well as Webdriver.

Running tests on Chrome

Another question often asked is can we run the script on Chrome since its only a Firefox plugin and Chrome being a popular browser. Often participants may feel this question little silly but actually it does!

Just go to

  • Options–>Options–>WebDriver tab.
  • Check the option to ‘Enable WebDriver Playback’ from opened tab
  • Provide ‘chrome’ value in text box and click OK button.

As you can see from the image not only chrome it also supports other browsers too.

JavaScript Support

With Javascript support i can store values and put an if condition to verify

For e.g.

var A=Number(“${20}”.substr(3).replace(/,/g,”)); var B=Number(“${30}”.substr(3).replace(/,/g,”)); var C=Number(“${40}”.substr(3).replace(/,/g,”)); var D=false; if (A>=B && B>=C) D=true; D

I can put the entire above command in the command window and execute and it will give the result  in the log. Often i can use the above script to verify the price sorting in e-commerce sites like Flipkart, Amazon, Crossword etc.

Nevertheless these are some features and there is ofcourse a lot more which we cover in Selenium IDE.

But stopping Selenium IDE from Firefox 55 version wont stop us in using Selenium IDE, isnt it? We still can install older versions of Firefox from and run Selenium IDE from there. But yes we will never see any new development on this for some time.

So for now Adieu Selenium IDE!!!


Free Java Boot Camps on weekends starting from 23-Oct. For more details please click here

Online Selenium Weekday batches and Weekend batches starting from 9th Oct. For more details please click here for Weekdays and Weekend batches

DevOps – Developers.. check, Ops.. check, Testers.. err

DevOps is neat, I like it, I find it natural extension to Agile movement and timely progression of it. Of late while consulting and coaching for the clients it seems to have entrenched me, to a point where it made me see every aspect of software development from the vantage point of (through?) DevOps. It’s all good but it’s also good to introspect your thoughts and observations, I did that. And I realised that for every team I worked with, the common recommendation was to bring the testing team upto speed or it was me saying DevOps is not working for you guys because Testing is lacking the edge or something to that effect, each and every time. Did I focus too much on Developers and Ops team to make them work in synch, collaborate and left testing to focus on automation and making continuous testing work? And hoping that this would make the testing team develop the necessary chops to deliver in DevOps projects. I was wrong, cutting it short, here is my conclusion – You can make testing effectively in DevOps only when the team has mastered the art of Agile testing. Just doing test automation, integrate testing tools with DevOps tools, doing continuous testing will not help much if the Agile fundamentals are lacking in testing.

So I take a step back and putting together my thoughts (without being too prescriptive) on actions to take to become agile in testing. Mind you I have kept it grounded to remain within the domain of Agile QA only and not ventured into Continuous Testing or Testing in DevOps space… back to the basics team (documenting my thoughts at random so you may find the sequencing not in ideal order). Here it goes:

Agile is iterative so is the testing: In any Agile model the requirement gathering and documentation, and design activities, and development activities, are iterative in nature. So must testing activities. If Testing team is not adapting to this then it will lead to failure.

Testing activities start with requirement phase: Requirements are ever evolving and there will not be a time where comprehensive requirements specification will be made available, therefore testing strategies can not rely on complete specifications. In fact work with rest of the team during the requirements gathering and grooming activities and create test strategies on the go.

Team formation and “T” shaped testers skills – This expectation has been around for long however the practical problem faced is that team may not even know what additional skills are needed and to what extent. This needs to worked upon and gradually skills need to be introduced to the testers.

Embedding Testers into Development teams for story testing including the unit tests.

For releases and niche testing it is good idea to have independent testing teams (and even have test hardening sprints)

Test environment and test data setup – This needs to be handled upfront as requirement and technical task while requirements gathering.

Test Automation and regression testing: Test automation strategy needs to be planned in sprint zero itself and have automation done in every sprint. Planning to do big band test automation after several sprints does not work and leads to high risk of having ineffective regression pack.

Perform static analysis: Static analysis to be used to check the quality where an automated tool checks for defects in the code, often looking for types of problems such as security defects or coding style issues.

Lead finalising the Acceptance Criteria for Business User Stories: Combining Business Requirement driven approach to testing by using Behavior Driven Development (BDD) using Cucumber. The greatest challenge with adopting BDD could be the lack of skills amongst existing requirements practitioners and testers. This is yet another reason to promote T-Shaped skills within the organization versus narrowly focused specialists.

Utilize the code coverage tools to ensure that the automation tests are offering sufficient coverage on code. Not doing this will lead to pesticide paradox and “false-pass” tests.

Plan and stay with the Development cycle: Do all that can be done but do not get one (or more sprint) behind the development cycle. Always plan for n-1, n and n+1 and it becomes essential that the testing team participants in sprint and release planning sessions.

Defect Management: In Agile the defects are just another type of requirement. A defect can be documented into the requirement to fix th defect against the Story X. In such situations the customer typically needs to pay for new requirements that weren’t agreed to at the beginning of the project but should not pay for fixing defects. This leads to commitment for zero-defect goals and merging the requirements and defect management processes into a single, simple task board gives a wonderful opportunity for process improvement and defect prioritisation.

Another practice that works wonders for quality is All-hands demo: Although there might be several project stakeholders working directly with the team we could have several hundred (or thousand) of actual users that don’t know what’s going on. Thats why I advocate an “all-hands” demo/review early in the delivery life cycle, typically two to three sprints into the construction phase, to a much wider audience than just the stakeholder(s) versus the few with whom we are working.

Going by Agile-Lean principles, testers should look for defect prevention and not just focus on finding defects. By this the definition of defect from lean perspective is:

– Building something with low quality (having bugs, traditional testing perspective)

– Building something the customer did not ask for because a requirement was misunderstood (BDD can help via executable requirements)

– Building something the customer did ask for, but later realized it was not what they meant and they do not want it now (BDD can help, also frequent all-hands demo)


Go beyond the typical Agile metrics such as Burn-Up and Bund-down charts, velocity and story points tracking. Some metrics that can lead to high quality:

  • Running Tested Features
  • Business Value burn-up
  • Technical Debt
  • Code Metrics – Cyclomatic complexity, Coding standards violations, Code duplication, Code coverage, Dead code, Code dependencies, Abstractness

Metrics are merely indicators and trends, they should not lead to blaming individuals in the team. They helps us get the desired Agile “inspect and adapt” feedback loop and we don’t collect data just for the sake of collecting data.

Hope the above helps and when in doubt check the Agile Manifesto and the guiding Agile Principles .

Fail fast to get it right the first time…

There is a myth around Fail-Fast agile concept that it is license to fail as long as you are learning. Yes, it does seem like a fair trade-off that when your agile teams are failing they are also learning and getting better. However, it should not be taken as an excuse to fail or take the failure itself lightly. We need to consider HOW we are failing. Fail fast cannot be attributed to fact that the team just cannot code or test properly, that’s bad team formation and we need to hit the planning board.

There is always COST attached to a failure if not blame or stigma, stigmatizing failure is a mistake and wouldn’t lead to any innovation. But whenever a sprint goes bad while you were trying something unique or experimental and it failed, it will help you in learning and evolution of a possible solution but make no mistake the sprint has costed the client and no real product increment actual happened. You need to also take the cost perspective in account so, let’s make it Fail-Fast Fail-Cheap.

It would also matter WHEN you are failing, failure as part of initial sprints could be manageable especially when you were anticipating it considering the extent of experimentation you were going for. We need to experiment in controlled environment keeping cost in mind. Having said that there are end-game sprints, for example in the sprint which is going live, there we cannot afford to fail. So, this makes it Fail-Fast Fail-First Fail-Cheap.

In the current market scenario, customer experience is the key. Businesses need to ensure the quality is in synch with what the customer is expecting or even superior to that. Hence, it is crucial to achieve First-Time-Right as the customer forms an opinion on a particular application as soon as he or she opens it. Customer loyalty resulting out of his or her first impression, once lost, is difficult if not impossible to regain. Hence, businesses cannot afford to ship something that is incomplete; they have to get it first-time right.

So that’s a pretty good reason why assuring first-time right is so important for businesses and Fail-Fast Fail-First Fail-Cheap can be utilised to ensure quality and innovation. It would be a big problem if we are not able to capture the failures and leak this to releases. This is also why shift-left is helping to put better quality at the forefront as a part of the everyday activities, as a part of how everybody should look at quality as everybody’s job. That’s the reason why this and other aspects of shift-left are helping the businesses deliver first-time right, every time.

Fail-Fast Fail-First Fail-Cheap using Shift-Left to get First-Time-Right

Prioritising the Product Backlog using Kano Analysis

In an Agile project the Product Owner’s most critical job is to prioritise the backlog considering there is high risk associated with building the wrong product. Regardless of how good and fast your technical team is, or DevOps, CICD is in place and testing is immaculate, you still need to ensure that you are building the right product.

The product backlog prioritisation is dependent upon several factors and taking into account the cost of building the feature (and also cost of not building the feature called as CD3). I shall be writing about these financial factors in some other blog. Here I wanted to share the innovative and logical way to analyse the features, the Kano Analysis.

Professor Noriaki Kano from Japan created the Kano Model in 1984 while studying the contributing factors to customer satisfaction and customer loyalty. The professor classified 5 unique categories of customer requirements which can be used to analyse the features and get the priority.

The features can be classified according to their quality:

  1. Attractive quality
  2. One-Dimensional quality
  3. Indifferent quality
  4. Must-be quality
  5. Reverse quality


  • Attractive quality – Surprise and delighters

– Valuable to users but maybe not to purchasers if they are different

– Today’s Attractor is tomorrow’s Must-be

  • One-dimensional quality – more is better

– Needs to be quantified – ‘minimum’ and ‘maximum’ are too vague

– What about diminishing returns?

  • Indifferent quality – customer doesn’t care

– So why bother?

  • Must-be quality – expected by the customer

– Minimum usable subset, minimum marketable feature set

  • Reverse quality – Some customers prefer the reverse

– Not all users are the same e.g. too many features confuse some people


In order to explain above I can use an analogy to mobile phones.

Mobile phone features

Attractive quality – Curved screens, fancy apps etc

One-Dimensional quality – more internet bandwidth

Indifferent quality – what processsor chip is used

Must-be quality – must be able to make call

Reverse quality – some customers want a simple phone which just does calls


The Kano Model suggests the customer satisfaction for the given quality attributes as below:

The important points that the PO needs to keep in mind are 1) what delighted customers in the past is now expected and 2) what is expected today will not meet minimum customer expectations in the future.

Dawn v/s Don: Context and importance of BDD

Dawn v/s Don: Context and importance of BDD

Let me give the story behind this title.  Myself and two of my friends and colleagues,  Harsh and Valerian were travelling from Mumbai to Pune on 15th of July for ATA’s 15th meetup which was being hosted by FiServ. The meetup was supposed to start at 9:30 am. We had targeted to reach Pune before 9:00 am. July being a monsoon month in Mumbai we decided to leave Mumbai quite early around 5:30 in the morning. The cab picked me up from Airoli first and then Harsh from Ghansoli and last Valerian at the Jui Nagar bus stop. On our way we were discussing about different things. In one of the discussions I mentioned about a movie I saw previous night and how much I liked that. Immediately after that Valerian told that we liked Don (that is what me and Harsh heard). I immediately told that Don is a great movie too with Amitabh Bachan (Bollywood’s) as the lead in the same. Harsh agreed with it. Valerian then said what don he is talking about DAWN – that morning Dawn he witnessed while waiting for us on the Jui Nagar bus stop. While living in Mumbai high rises we seldom get a chance to witness DAWN. It then dawned (J) on us that the context changed and the phonetically sounding words DON and DAWN have created this confusion.

During the meetup we had an excellent presentation on “Whole TEAM approach to Agile Testing  – BDD can help better” by By Shraddha Gupta and Saket Deshpande.

Their entire presentation is available on ATA Slideshare (


Saket and Shraddha talked about Context and how BDD plays an important role in getting the context related issues resolved. In one of their slides they talked about perception v/s perspective. Please see the picture below


This is where the context comes into play. How elephant parts can be perceived to be different from different folks depending on the context they are looking from. Similarly agile development team, Ops team, Testing and QA Team and the Product Owner (Business) might have their own perspective as per the context they are speaking from. Exactly like DAWN and DON confusion that happened on 15th morning among us.

If the context and perspectives are not matching it may result into key issues. Saket and Shraddha talked about the whole team approach which is really important to get this confusion out. But the confusion will not come out unless there is a formal way to get things discussed. BDD (Behavior driven development) is one such technique which come in very handy to resolve this.

There are some great benefits of BDD, other than the contextual problems that it automatically resolves. An excellent post – 10 reasons by BDD changes everything has this elucidated very nicely by Lary  Apke. Here are the 10 reasons from the post.

  1. Communication between business and development is extremely focused as a result of common language.
  2. Business needs to tie directly to the code that is written.
  3. Developers know what test cases they should write to accommodate TDD.
  4. All the underlying benefits of TDD become more easily realized.
  5. Code is easier to maintain.
  6. Code is self documenting.
  7. Stories are easier to “groom” – breakdown, task and plan.
  8. Teams can be more agile.
  9. Developers can be trained / on-boarded easier.
  10. There is more visibility into team progress and status.

The top most in this list again is communication between the business and Dev team. The Dev team should now include a wider perspective and have QA and Operations too part of it. Let them all use the full power of BDD from day 1 to get things going confusion free.

In another interesting post from Rachel Davis (, the definition of BDD is explained as shared understanding. Quote from the same blog and picture below. “The B in BDD stands for Behaviour, the desired behaviour of the software to be developed. The DD part stands for Driven-Development. BDD is an approach for building a shared understanding on what software to build by working through examples. “

These differences in understanding, the contexts and confusions are some of the important reasons projects gets delayed, defects are not found until late and the overall costs gets escalated. BDD is resolving this problem and is getting popular in most of the agile and DevOps setup. Choice of tools are Cucumber with Selenium or Appium.

Here is picture from our meetup – thanks again to FiServ, Mayuresh, Rajiv, Amit and the whole ATA Community which makes learnings a fun during these meetups.

We are also running hands on BDD/Cucumber/Selenium/TDD/ATDD programs – part of CP-AAT certification programs. If you want to learn practical BDD along with implementation using Cucumber, Selenium or Appium do let us know.

How to crack the CP-SAT certification code?

Certified Professional – Selenium Automation Testing (CP-SAT) is the only globally recognized Selenium certification which is actively pursued in countries like India, USA, UK, Argentina, Chile and Ecuador.  I am proud to say that I am one of the certified trainers for the program and have trained across the world for CP-SAT (including the train the trainer program).  One of the major concerns that participants have is that they find the certification exam very difficult to pass.  I don’t have the full statistics but there are not more than 50% who clear the exam in first attempt.  Here I am going to the sharing my views on this and also share some tips to prepare and clear the CP-SAT exam.

As per my role in ATA Steering Committee it has been one the responsibilities to review the course curriculums and exam questions patterns time to time to keep it relevant and fair.  We keep reviewing the curriculum to ensure we cover the topics in terms of coverage and depth, please mind the fact that the CP-SAT training run for 2.5 days with certification exam in the remaining half day.  Considering the limited time, we pick the topics carefully to ensure that there is enough learning for participant to spend time in class and later they can practice and get expertise.  We also include the peripheral topics to ensure that we don’t cover the tool in isolation and cover the ecosystem to enable participants to use Selenium effectively.

CP-SAT is an open exam and we are seeing more and more participants taking the exams directly (without training). For someone who has attended the training it becomes relatively easier as they have exactly covered the curriculum and also got trained from a certified ATA trainer (the selection criteria for that is very stringent). Anyways for anyone who is taking the CP-SAT exam there are certain guidelines which when followed can help crack the exam, let me share them.

  • Study the Learning Objectives presented on the ATA CP-SAT webpage and use this as basis for your preparation.
  • Read the questions carefully to see which combination for test script is being asked, for e.g. the question can be to write script in TestNG framework, WebDriver architecture and for Firefox browser. If participant submits a script in JUnit, WebDriver and for Firefox, even though it is fully functional still you will not get full marks.
  • Create the test environment with relevant Jar files (or POM file for maven) and project structure in IDE before the exam starts.
  • Use the last 5 minutes only to prepare the archive file of your project that needs to be emailed to Before you export the archive file please ensure that all the Jar and exe files has been removed and list them in a txt file.
  • Double check your archive file for small size (it should be in KBs) and ensure all your script for given questions is there.
  • Name the classes and html (for Selenium IDE) as per the question you are answering, for e.g. or question5.html
  • Even if you find a certain question difficult and you are not sure how to solve it (may be due to lack of time), you should still attempt some steps of the question as there are points given on steps. It will all add up!
  • Read the entire exam paper carefully before you start and allocate time for questions and keep track of time. Even if you spend an hour to answer a 10 marks question and do a great job at it, you will still get no more than 10 marks and then you will find difficult to complete remaining questions. Be Agile, inspect and adapt.

Ultimately there is no alternative to hard work, you need to work hard to learn the tool and the CP-SAT certification exam is designed to judge the depth of your knowledge.  You will need to practice coding and get into problem solving mode to make good use of your knowledge. If you are to get ATA Certified for CP-SAT then you gonna have to earn it. All the best!!

Testing the system behavior which is not there

Yesterday, we were giving a demo of our mobile test automation POC to a client for their android app in the financial domain.  It was a simple scenario with login to the android app and then testing the market watch feed to the logged in user.

The screen as below:

The POC was based on the existing manual test scenario with the suggested data from client. Using the correct login id and password takes the user to the welcome screen.  If the user id or the password is not correct then the application would throw an error message and request you to try again with valid credentials.

After the demo of the successful login and further steps in the POC, the client representative asked us to update the test to use invalid password which was very long.  The data suggested was “anand long name in the password 8hj”, this string was 35 character long.  When we reran the test the login was unsuccessful as the password was invalid, however the password field didn’t accept the full string and truncated it to 12 characters “anand long n”.  So the conclusion was that the test passed as it didn’t allow to login with invalid password with an observation that the test didn’t do enough to catch the fact that the entire password string was not used to run the test and the test data for the password was actually truncated.

Now should the above test trap this condition and not allow any further characters post 12 characters to be typed into the password field?  Should it throw an error?

What do you think?

Here is my $0.02…

I would look at the behavior of the system in the requirements in the same scenario. What happens when we manually run the test?  Is it conforming to the requirement?  The manual test and thus the test automation script needs to validate this behavior of the system.

It would be wrong for a test case to validate something which is not part of behavior of the system and even worse trap and override the system to give warning and errors.

In the above test case when I manually enter the password, after 12 characters the system does not let me type any more characters, but please note that it does not stops me from entering any further characters into the field.  If I was not looking at the screen then I would simply type away all the characters and process with the next steps.  A test automation tool is like a person who does not look at the screen only interacts with the system under test.

This seems innocuous at first but consider this, if the valid password is “123456789012” (12 character string) and I used test data as “123456789012345” (15 character string), the system would allow me to login with invalid test data as it would truncate the long string into a valid password.

Type away!!

Now it is up to the users to decide what should system do if I am happily typing away even though the password field allows max 12 characters?

  1. The system should let user type more than 12 characters and not truncate (as it may pose a security risk to reveal the max length of the password)
  2. The system should pop-up an error message that user has reached max characters allowed in the password
  3. Or the existing way where the users can type as many characters but system will truncate it to max allowed characters without knowledge of the user.

Once we close on this expected system behavior from the varied perspectives of functional as well as UX testing then we need to accordingly validate this behavior using manual and automation test cases.

I would also like to bring your notice that above scenario is also an example of how testing can lead to functional as well as the user experience requirements when it is either done along with or prior to system requirement gathering. This will help us study requirements from a behavior perspective which can then evolve and lead to better test cases and eventually high quality.

Happy testing!!

Should #TestersBhiCoders ? Which programming language they should begin with?

With the ongoing shift in the trends and the needs of IT industry, lot more is being expected from the testers. Tester is obviously expected to have the prime skills of finding defects (which is and should remain a passion always), but apart from that most of the recent job requirements have started to expect a lateral testing recruit to know two or more from the below list and the list keeps on growing.

  1. Automation tools like Selenium, Appium etc
  2. Programming in Java or Python, Ruby or CodedUI , Junit,
  3. RDBMS, SQL skills
  4. Cloud – AWS / Azure
  5. Performance testing tools – Jmeter or like

Please find below sample latest JD’s from one of the leading job portals in India

🙂 One thing is sure, 2017 or beyond – today’s tester need to be a Super man/woman nothing less than that.

Another thing which is also in vogue is that many organizations are spending lot of money in getting their testing teams up-skilled on automation side.

Going by the current trends it is quite evident that even though we testers cannot be super humans and know everything on this earth, but knowing some automation tool is a must. It will not only come in handy but also help get us into a lucrative job or better still, help keep our job.

Our first take is that Testers should definitely move into coding sooner or later. #TesterBhiCoder is a trend that is more of a necessity in today’s changing world than anything else.

Recent post on Linkedin about the most popular tools hint a massive shift from legacy tools like QTP/UFT to new age open source tools like Selenium and Cucumber. Reference

And recent updates on the most in demand programming languages is as below. Reference :

Although Python is having the No. 1 slot, the top four—Python, CJava, and C++—all remain very close in popularity.

Let us correlate  the popular languages and the most popular automation tools

With 30% preference towards Selenium, 7% for Appium and 5% for Cucumber and 8% on Jenkins – that makes it close to 50% of tool set which are actually working together in some form or other in today’s agile and DevOps environment. All of these work well with Java.

I would like to thus recommend Java as the starting point for the testers and then pick up their choice of most popular testing tool

Agile Testing Alliance is also trying to get more and more testers learn Java under their #testerbhicoder initiative (

Please check the following out  – Free Java Boot camp for testers from ATA. Instructor led online training program..