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.

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..


‘Mastering Agile Testing’ – Join the CP-MAT certification batches by ATA

CP-MAT training and certification batch held at Bangalore was a huge success. With wonderful participation by the delegates, intriguing questions and enthusiastic response, it was a pleasure training and interacting with them!

CP-MAT is a wonderfully interactive course designed specifically for agile test practitioners.

CP-MAT stands for “Certified Professional – Master Agile Testing” certification prepared and honored by “Agile Testing Alliance” & “Universiti Teknologi Malaysia”.

The course is applicable for all roles and not just “testers”. Knowledge, experience & certification is consciously designed to focus on “agile testing” and not on “agile testers”.

CP-MAT helps the participants get into the testing mindset in an agile project. It helps you utilise your testing experience in learning hands on Agile testing. It instils the “Quality is everyone’s responsibility” concept in the minds of the participants.

For complete course agenda , please visit —

It is useful for even to an experienced tester to apply the “regular” testing techniques to an Agile project. The concepts of Agile process with context to testing are covered during the course along with the associated best practices for Testing in an Agile Project. The course takes a hands-on approach while covering Release Planning, User Stories Review, Estimation, Sprint Planning, Agile Test Strategy, Testing debt, Testing DoD, Test Reporting and Metrics. This also introduces the participants to the concepts of TDD, ATDD, BDD and Continuous Integration (which are covered in detailed in the next level course CP-AAT).

Here is sneak peek into the training room–

Enrol now to master the art of agile testing!

Happy Learning!


Queries from Agile Testing perspective?

Agile has been a buzz word for some time now. Everyone feels they know agile and they are already doing agile. Still, some times while working in our agile testing world we get into a situation where we get a breather to have a peaceful morning coffee or an afternoon break. While having that cup of coffee or just relaxing on our own..  the thoughts sometime linger on back to work and we tend to have too many questions than answers..  Worrying indeed


  1. My client is asking me to increase the testing speed and also reduce the testing resources at the same time – has he gone nuts ?
  2. If I think differently, I start getting a feel that may be my client is right. Me and my testing team can do things much better, specially with so much time pressure and cost pressures. Is there a way out ?
  3. I always feel that there is an urgent need for the team to learn and innovate new things in testing? Should I give them more time to learn and participate in the community events and some training programs even though the time lines don’t allow me such liberty
  4. We have improved much from last year, our testing now is not one sprint behind: what can be done next.. In sprint Automation ?
  5. How can we scale up to the next level of testing ?
  6. Given the increased workload, Is there really a way to maintain the velocity and still increase testing coverage and overall quality ?
  7. Is DevOps the way for me and my team?
  8. Should I make my entire testing team learn coding ?
  9. …..

I am trying to bring some of the queries out here and want your help in commenting with your queries. Please bring out your worries and queries.

Let us see what is bothering todays teams (Testing and Agile Testing teams).