Thursday, January 2, 2020

What is SaleForce and Hows Lending Domain Works?

Description of Salesforce:

It is an American cloud-based software company.The main purpose of this CRM tool is to sustain the relationship between an organization with its customers once the product is delivered to customers. Over the time, along with providing CRM services, Salesforce started to offer cloud storage as well. Basically its a motive to track the process of taking loan from someone and returning it back with the help of system.

What is Lending and Finance domain ?

Finance, or rather funding has been a vital part since the beginning of time. Earlier it was through indigenous lenders, funding has played a major role in each and every part of the world. This is also the reason why, lending and financing have been domains that have evolved and grown rapidly over the years and metamorphosed into more effective and creative forms and with the help of fintech, the lending sector has been growing at an exponential rate. With the likes of mobile money lenders, P2P platforms, marketplace platforms, and online lenders, consumers today have faster and better access to finance and the ability to live more comfortably.The thought of making the process of financing quick and easy for end consumers is what has increased the growth of fintech and lending giants. By continuously understanding is emerging market trends and ways in which end consumers can have easy access to finance while protecting lender’s interest in fin-tech has been able to keep satisfying the financing requirements of the world at large.




Companies which are working On SalesForce CRM:
lending companies   Lending Point, EbixCash, Capital One, American Express login, Amazon etc
commerce – Paytm, snapdeal, flipkart etc
Travel sites – Goibibo, make my trip etc
Real Estate – Lodha Group, Brigade group, KRaheja etc
Manufacturing – Ashirwad Pipes
Some Random names which I recollected are – Bajaj Finserv, Practo, Babajobs etc
Overview: Hows Lending Domain Works -
Summary: So basically what is Lending Domain: In every country the basic flow to lend a loan the process is same. The customer or group or company who requires a loan request to big companies for loan, These big companies verify the customer or the company  details with whatever resources they have. Once they get a confirmation that this guys or company is valid, then lender starts the funding process and also schedule the money returning scenarios with the interest through the system.

Third parties which help lenders to verify -
So Twilio, Phone Pay, Decision Logic, Idology, Giact, Docu-Sign and S-Docs etc based on BRMS rules.


How to test Lending application:
It depends in business flow that how lender will allow his customer or company will come/enter to its portal (Assuming its a customer), who is entering from 2 two URL's on different websites.
Scenarios
- First verify all the fields from UI prospective and also understand the values it is showing in API end. 
- You also need to understand both the url needs to have a different sources, So while verifying the application it will be easy to track, from which URL it has come to Salesforce and while testing API it needs to be clear.
- All the validation on UI fields should also be on the API end.
- Errors should be handles in API and UI end, So that it will be easy to track what error has been generated for eg: Status code 401(Unauthorized), 302 (
redirection error)
- Error logs should also get manage
- Verification through third party needs to be done from API to UI.
- Notifications through an Email/phone number should be correctly done.
- Documents should get signed properly and will get verified throughly.

- Then the request will be count as 'Lead'. A lead is a basic
information of customer who wants a loan and send all the basic details about him or his mobile number or business or account number. By these details company will verify that the customer is having all the valid information or in past he has any fraud details with him or in his/her past loan experience his Ficco/Sibel score is validated. If the basic details are correct companies allow it to be opportunity/application.
 
- So if the business is allowing, so the application gets created when all the API and UI conditions gets passed. So from QA standpoint user need to verify all the condition too for eg: whether all the API's has been executed properly or not. Whether from UI if the specific action has been clicked or not ?
- All the api shall be executed whenever the related UI action has been performed or not ?
- All the validation shall be passed from UI and API, in case of any error it should be reflect on same.
- On UI and API all fields shall gets updated whenever information gets updated and correct status shall get updated.

This application is having a account (There can be multiple accounts but simple in lending business it will be easy to manage if there will be single account but there can be possibility that there will be more then 1 account for any application which can be 'Primary' and 'Secondary') where this account will have basic detail or customer or company and then this account will also have contacts in it. So basically these contacts are the user whom we can contact if required. It can be a single user or can be more then one also.
Scenarios:
- So when application gets created, It shall have all the values which are entered either through API or through UI.
- Account and contacts shall get linked through it and in case of any update in application, if the value needs to updated to Account or contact it needs to get updated and vice a versa.

How application is driving:
So initially when the customer has requested that he wants loan through any source/Medium - So that request will move to portal and at that time the status of that can be anything as per terminologies but we can say its in Data Entry stage where, we know a request for loan has come to our portal and we have to put all his mandatory information into our portal, In some companies they validate the phone numbers in these stages too through any API or through an medium. So if some of information is still missing but mandatory info has been entered, we can move this loan application ahead to next stage.

Sizing Calculator stage: So now we can move it to Calc status where we will calculate its salary or earnings. So what can be the offer options, So based on his earning and salaries or Sibel/FICO we will calculate Application offer options.

OfferOut: So Once offer has been selected that i want this X amount of loan and i will return the money in these years with this interest. Once that is selected then the next thing is to validate the bank account details.

Bank Verification stage: Once Bank Account has been verified based on Sibel/FICO the we move to next stage and to update how to take the money back in Installments or what will be Interest or what will be penalty amount if he missed any transactions.

Doc reviewed stage: There can be statuses where in case any document is missing, he can upload that from there. So there can be status where all the documents gets signed. whether they are correct or not.

Final Review: These can be a status where whole application is reviewed before confirming that we have your application and we are processing it.

Funding Stage: So, Once it gets Funded to customer/company there will be portal for that where he can review its application can track all the related transactions, Paid/Pending through which payment gateway. At this time application status will be Funding Customer will able to get emails regarding the whole transactions progress.

Collection stage: In case of any transaction payments gets missed, Ideal scenario says customer should receive notification in any form that his transaction has been missed please pay.
In case he is still not paying we can send him another email or notification, may be there will be some problem and because of that he will not able to pay that. So team will try to figure out that by calling or by self visit.
If still he is not responding, first the penalty on the returning transactions will happen and after that he will get notify regarding the same also.

Legal:
There is also another option whether we can mark this application as Legal that this customer is not paying the returning amount and due to rules it has to be taken to legal assistance.


Now when all the payment transactions gets return we will mark this as Close application and now if wants another loan then there will be option of Pre-approved application. So now there will not be any verification required again for this customer/company because it has been already done but there can be conditions like if there is time gap between 1st loan closing to new Loan request of 3-6 months, then we need the verification again because might be chance that FICO/SIBEL has been updated in between(Can be dependent on business model).

Note: There can be any terminologies for these stages and there can be N number of stages but the basic understanding of Lending project is this only.

Monday, May 22, 2017

Testing Tools every quality team should require ?


Dummy Emails:
http://no-spam.ws/
http://www.throwawaymail.com/

Dummy Cards for testing:
https://saijogeorge.com/dummy-credit-card-generator/

Awesome Screenshot:
https://chrome.google.com/webstore/detail/awesome-screenshot-app/mfpiaehgjbbfednooihadalhehabhcjo?hl=en

Fireshot:
https://addons.mozilla.org/en-US/firefox/addon/fireshot/?src=collection&collection_id=b94ddcb3-7bb4-44b4-b3b4-f397ea2e5481

For load testing:
Apache JMeter

Broken Link Checker:
http://www.brokenlinkcheck.com/
https://xenus-link-sleuth.en.softonic.com/

Multi Browser testing:
https://www.browserstack.com/

URL performance on PC and Devices:
https://developers.google.com/speed/pagespeed/insights/

Firebug
https://addons.mozilla.org/en-US/firefox/addon/firebug/

IMacros:
https://addons.mozilla.org/en-US/firefox/addon/imacros-for-firefox/?src=collection&collection_id=da0ecd99-2289-7ab0-7d57-e7c489c845c3

FireSizer:
https://addons.mozilla.org/en-US/firefox/addon/Firesizer/

Mantis:
http://www.mantisbt.org/download.php


Bugzilla:
http://www.bugzilla.org/download/

Live HTTP Headers:
https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/

FoxyProxy:
https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/

Temper Data:
https://addons.mozilla.org/en-US/firefox/addon/tamper-data/

Websecurify:
https://addons.mozilla.org/en-us/firefox/addon/websecurify/

XSS Me:
https://addons.mozilla.org/en-us/firefox/addon/xss-me/

SQL Inject Me:
https://addons.mozilla.org/en-us/firefox/addon/sql-inject-me/

gTranslate:
https://addons.mozilla.org/en-US/firefox/addon/gtranslate/?src=ss

YSlow:
https://addons.mozilla.org/en-US/firefox/addon/yslow/?src=ss

ShowIP:
https://addons.mozilla.org/en-US/firefox/addon/showip/

NoScript:
https://addons.mozilla.org/en-US/firefox/addon/noscript/

Edit This Cookie:
https://chrome.google.com/webstore/detail/fngmhnnpilhplaeedifhccceomclgfbg

Postman for API testing

Penetration testing: OWASP, Netsparker








Tuesday, January 6, 2015

Page Speed Insights for QA

Page Speed Insights:-
Page Speed Insights measures the performance of a page for mobile devices and desktop devices. It fetches the URL twice, once with a mobile user-agent, and once with a desktop-user agent. Basically Page Speed Insights can examine your website and make recommendations for manual improvements.

What are Google Page Speed Insights?
Google Page Speed Insights is a free open source web page analysis service which can offer guidelines on how to maximize the performance of your pages. It is part of Google Page Speed Tools which provides both analysis and optimization services. Page Speed Insights doesn't require you to host your site with or be a customer of Google. You don't have to fill out any annoying registration forms, set up an account, or provide an email address to use it. You can enter any URL you'd like to check, you do not need to be the owner or administrator. There is no need to provide any credentials for the site being analyzed, nor share any other confidential information.
Google offers a link to let you access the service directly, or you can install a browser extension for Google Chrome and Firefox which is essential for internal sites which aren't public facing as well as some other specific public sites.

How does Page Speed Insights work?
Page Speed "analyzes the content of a web page, and then generates suggestions to make that page faster. Reducing page load times can reduce bounce rates and increase conversion rates. It runs a number of diagnostic tests against a web page, and analyzes the page's performance on a number of 'rules' that are known to speed up page load time. The rules are based on general principles of web page performance, including resource caching; data upload and download size, and client-server round-trip times. They examine factors such as web server configuration, JavaScript and CSS code, image file properties, and so on. For each rule, Page Speed gives a general score, using a simple red-yellow-green grading scheme, then suggests specific techniques for correctly implementing each rule. It also provides some automatic optimization of external resources included on a page, such as minifying JavaScript code and compressing images."

For Developers - Page Speed Insights plug in for Google Chrome/Mozilla:
Page Speed Insights is available as
an open-source browser extension for Google Chrome. Webmasters and web developers can use Page Speed Insights to evaluate the performance of their web pages and to get suggestions on how to improve them.
Install by clicking this link:
http://developers.google.com/speed/pagespeed/insights_extensions
you can also add a plug in to Chrome and Mozilla browser.

To test a page with Page Speed:-
- To get started, click "Analyze your site online" (again, this does not have to be your site - keeping in mind it must be publicly accessible only).
-
Enter a URL to analyze and click "Analyze." For instance, I'll analyze www.xyz.com.
-
Note you can analyze both the "Desktop" and the "Mobile" versions of the page using the corresponding buttons in the upper right.
- The result doesn't actually reflect the loading time of a page; it indicates "how much faster a page could be." For ex 70/100 means the performance could increase by about another third of what it currently is.
- Now the suggestions are mentioned and after getting those suggestions it is easy to make website performance better.

What can the mobile site analysis function do?
- Click the "Mobile" button and you will get a similar but separate set of recommendations.

Suggestions for developers mentioned in page speed insights to enhance the speed of their website pages:-

1. Leverage browser caching
- Setting an expiry date or a maximum age in the HTTP headers for static resources instructs the browser to load previously downloaded resources from local disk rather than over the network.
2. Enable compression
- Compressing resources with gzip or deflate can reduce the number of bytes sent over the network.
3. Optimize images
- properly formatting and compressing images can save many bytes of data.
4. Eliminate render-blocking JavaScript and CSS in above-the-fold content
- None of the content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources or inline the critical portions of those resources directly in the HTML
                -Remove render-blocking JavaScript
                -Optimize CSS Delivery
Consider Fixing:
- Minify JavaScript (Compacting JavaScript code can save many bytes of data and speed up downloading, parsing, and execution time.)
- Minify CSS (Compacting CSS code can save many bytes of data and speed up download and parse times.)
- Minify HTML (Compacting HTML code, including any inline JavaScript and CSS contained in it, can save many bytes of data and speed up download and parse times.)

Sunday, December 14, 2014

Writing of Test Cases ?

Basics of Writing Test Cases:

#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.

For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password is entered. Each test case would in turn have steps to address how we can check a particular test condition is satisfied or not.

#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.

#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams, when done for their feedback.

#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.

#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.

#6. The MS word template looks something like this:

#7. The Excel template could look like the following:

#8. From the above two templates it can be observed that the fields (or the components) that make up for a test case are the same, the only difference is the way in which they are organized.
So, as long as there is a field for each of the type of information to be included in a test, the format of the template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy to expand, collapse, sort, etc. But again, choose any format that works best for you.

 Below is a list and please check out the links provided for more information on these methods.
  • Boundary value analysis
  • Equivalence partitioning
  • Error guessing - This is a very simple method and relies on a tester’s intuition. An example is: Say there is a date field on a page. The requirements are going to specify that a valid date is to be accepted by this field. Now, a tester can try “Feb 30” as a date- because as far as the numbers are concerned, it is a valid input, but February is a month that never has 30 days in it- so an invalid input.
  • State transition diagrams
  • Decision tables
Using the above techniques and following the general test case creation process, we create a set of test cases that would effective test the application on hand.

Thursday, December 11, 2014

Telling programmers to test own code?

Would you trust a programmer to test your application?  It’s like asking a Fox to guard the chicken-house, right?

Well, sometimes you don’t have a choice, or you do but that choice is to release the application untested.

As part of an Agile testing consulting engagement I am doing at a friend’s company, yesterday I started providing short training sessions for programmers who need to learn how to test better.  It’s not that this company doesn’t have testers, they have good testers!  But as many other agile teams they have much more testing tasks than available testers, and they want programmers to take part in at least some of their testing tasks.

Programmers are not good at testing or they might be but they don't want to do it properly because its their baby.

A couple of months ago I wrote a post explaining why I think programmers are poor testers, and I still think that in a sense it is like asking a dog to fly. On the other hand I also believe that with some good intentions, hard work, and perseverance you can teach a dog to skip far enough and that way to jump over large obstacles.

In the same way, you will not be able to magically transform programmers into a good testers overnight, but you can start by working with them on their weaknesses and then teaching them some simple and effective testing techniques.  With good intentions, a little practice, some hand-holding, and constant feedback you will be able to get some good testing help in your project.

Step 1 – understand the limitation and weaknesses of a programmer

I started my session yesterday by going over the points I listed in my earlier blog that make programmers “less-than-perfect-testers”:

- Parental feeling towards their own code.
– Placing the focus mainly on positive scenarios, instead of actively looking for the bugs.
– Tendency to look at a “complex problem” as a collection of “smaller, simpler, and isolated cases”.
– Less End-to-End or User-Perspective oriented.
– Less experience and knowledge of the common bugs and application pitfalls.

It made a big difference during the session to not only list the weaknesses but talk about why each of them is naturally present in programmers due to the nature of their work, their knowledge and training.

Step 2 – how to plan tests
I’ve seen that many (most?) programmers have the perception that testing requires little or no planning.

Maybe we testers are guilty of this misconception since we don’t get them involved in our test planning process as much as we should, but the truth of the matter is that when we ask them to test they they automatically grab a mouse and start pressing on the buttons without much consideration or thought.

Test Planning is a cardinal aspect of good tested, so I gave them a couple of ideas and principles planing:

1.  DON’T TEST YOUR OWN CODE!
When as a team they are asked to test, they should make sure to divide the tasks so that each of them is testing the code developed by other programmers as much as possible.

2.  Work with your testing team to create test sets.
This specific team is using PractiTest (the hosted QA and Test Management platform my company is developing), but it can be any other tool or format (even word and excel!).  They should sit with their testers and define what test cases need to be run, reusing the testing scripts already available in their repositories.

3.  Expand your scenarios by making “Testing Lists”
- Features that were created or modified (directly or indirectly)
– User profiles and scenarios to be verified.
– Different environments / configurations / datasets to be tested

The use of these lists is two-fold.
They help you get a better idea of what you want to test while you are running your manual test scripts, and they also serve as a verification list to consult towards the end of the tests when you are looking for additional ideas ow when you want to make sure you are not missing anything of importance.

4.  Testing Heuristics – SFDEPOT
The use of (good) heuristics greatly improve the quality of your testing.
I provided the programmers with the heuristic I learned fist and still helps me up to this day.  I read about SFDEPO(T) from James Bach some years ago – you can check one of the sources for it from Jame’s Site.

SFDEPOT stands for:
Structure (what the product is)
Function (what the produce does)
Data (what it processes)
Platform (what it depends upon)
Operations (how will it be used)
Time (when will it be used)
There are other heuristics and Mnemonics you can take from the Internet…

Step 3 – what to do when running tests
We talked a lot about tips to help perform good testing sessions.
1. Have a notebook handy.
In it you can take notes such as testing ideas you will want to test later, bugs you ran into and want to report later in order to “not to cut your testing thoughts”, etc.

2.  Work with extreme data.
Big files vs. Small files
Equivalent input classes [ -10 ; 0 ; 1 ; 10,000,000 ; 0.5 ; not-a-number ]
Dates: Yesterday, now, 10 years from now
etc

3.  Think about negative scenarios.
– How would Mr. Bean use your software?
– How would a hacker try to exploit the system? or you can say a mouse name Jerry enter your house and you are a Tom.
– What would happen if…? (blackout, run out of space, exceptions, etc)
– What if your  2 year old would hijack the keyboard in the middle of an operation?
– etc

4.  Focus & Defocus:
I used this technique to explain to them that during their testing process they need to make a conscious effort to always look at the bigger picture (application, system, process) and not only focus on the specific function they were testing.

5.  Fight Intentional Blindness:
I used the following film of the kids passing the balls to explain the concept of Inattentional Blindness and it worked great!
We were 8 people in the room, and only I had seen the video before.  Out of the 7 participants one is currently a tester, another one is a former tester turned programmer, the rest are “regular programmers”.
The cool thing is that only the 2 testers saw the Gorilla the first time…  talk about making a point!

Step 4 – what to do when (you think) you are done testing ?
We talked about how even when you think you are done testing you should always make sure there is nothing else that should be tested, and what techniques they can use in order to find these additional places:

1.  Walking the dog
Taking a break from your tests, doing another tasks for 30 – 60 minutes, and then returning to review the tests you did and what you found.  This break usually helps to refresh the mind and to come up with more ideas.

2.  Doing a walk-through session to review the tests you did.
Most of the time you will be able to get more ideas as you explain to your peers about tests you just did.
The funny part is that many of these ideas will come from yourself and the things you think about when you are explaining your tests to others out loud.

3.  Ask for ideas from other developers or testers.
Simple as it sounds, come to others in your team and ask them to pitch you ideas of stuff they think you could test.  90% of the stuff you will already have tested, but the other 10% might prove useful too!

In the end is a questions of mindset and motivation
One of the things I like most of agile teams (and many non-agile but yes smart development teams) is that they define Quality to be the responsibility of the whole team and not only of the testing guys running the tests tasks at the end of the process.



My final piece of advice to the group was that everything starts from them, and their understanding that testing is not a trivial task and definitely not a sequence of doing a bad job or for finishing their tasks ahead of time.  What’s more, I am sure that once these guys start testing better and gaining a testing perspective of their application they will also start developing better software too.

Why can’t developers be good testers?

I’ve been trying to explain to a couple of Agile Teams why developers are usually not good testers; so after working hard to remember all the reasons I could think of (based on my experience so far) I decided to put together a short list and post it.

Don’t get me wrong I think developers should take part in the testing tasks, specially on Agile Teams, but I am also aware of their limitations and the cognitive blind-spots that tend to harm their testing; and as it has been said before, the first step to improve your weaknesses is to understand you have them.

Why developers (usually) suck at testing?

1. “Parental feelings” towards their code
Developers are emotionally linked to the stuff they write.  It may sound silly but it is hard to be objective towards the stuff you create.
For example, I know my kids are not perfect and still I am sure I would have a hard time if someone would come to me and starts criticizing them in any way (after all they are perfect, right? :) ) .

2. Focus on the “Positive Paths”
Development work is based on taking positive scenarios and enabling them on the product.  Most of their efforts are concentrated on how to make things work right, effectively, efficiently, etc.  The mental switch required to move them from a positive/building mind-set to a negative/what-can-go-wrong mind-set is not trivial and very hard to achieve in a short time.

3. Work based on the principle of simplifying of complex scenarios
One of the basic things a tester does as part of his work is to look for complex scenarios (e.g. do multiple actions simultaneously, or make an operation over and over again, etc) in order to break the system and find the bugs.  So we basically take a simple thing and look for ways in which we can complicate it.

On the other hand our developer counterparts are trained into taking a complex process or project and breaking it down into the smallest possible components that will allow them to create a solution (I still remember my shock in college the first time I understood that all a computer could do was work with AND, OR, NOT, NAND, NOR, XOR and XNOR operations on Zeros & Ones).

4. Inability to catch small things in big pictures
I can’t really explain the reason behind this one, but I have seen it many times in my testing lifetime.
One of the side-effects from becoming a good tester is to develop a sense to (almost unconsciously) detect what “doesn’t fit” in the picture.  The best way to describe it is by the feeling one gets when something “doesn’t fit” in the picture but we just can’t put our hand on it; then by applying some systematic processes we are able to find the specific problem.

I had a developer once tell me that good testers can “smell bugs”, and maybe he was not very far from the truth.

5. Lack of end-to-end & real-user perspective
Do the nature of their tasks most developers concentrate on a single component or feature in their product, while they still maintain a vague idea of how their users work with their end-to-end system.
Testers need to have a much broader perspective of our products, we are required to understand and test them as a whole while using techniques that allow us to simulate the way users will eventually work in the real world.

6. Less experience with common bugs & application pitfalls

Again something that comes with time and experience is our knowledge of the common bugs and application pitfalls.  Obviously as a developer accumulates KLOCs on his keyboard he will also get to meet many bugs and pitfalls, but as a tester we are going to gain this experience faster and in a more deeper sense.

An experienced tester sees a form and automatically starts thinking about the common bugs and failures he may find in it and starts testing for them.

My bottom line
It’s not they don’t want to do it, developers simply are not able to test in the same way we tester do.  This doesn’t mean they cannot help in testing, and in some specific areas they will be able to do it even better than we do, but before they start it may help if they are able to map their testing-blind-spots in a way that will allow them to compensate for them.

Developer testing adds a lot of value to the general testing process…  I am even thinking as I write this about a future post on the subject of the added value gained from pairing developers and testers.

Don’t write a single test, Until you know how to do it !!

We've all heard about the “Infinite Monkey Theorem” whereby a monkey hitting keys on a keyboard (typewriter) at random will eventually come up even with the complete works of Shakespeare.

But the problem is that it would take it an infinite number of years, and maybe more importantly the work would be buried under so much junk and gibberish that it would be impossible to find it.

What’s the status of your test cases?

Now take a look at your test repository.  What do you see?
Is there anything in common with the work of the monkey above?

I am not implying your team is made up of chimps typing at random – even though if it is, please take a picture of them and send it back to me, I promise to publish it!!!

But something I see a lot in the context of my work with PractiTest’s customers is that people tend to concentrate on the quantity of their test cases, and fail to put enough efforts on the quality of their resources.

The result is repository with a lot more test cases than it should actually have, many of them covering the same feature too many times, others describing functionality that was modified a number of releases back, and some that have not been run in a number of years because they are not really important anymore.

I don’t think this comes from incompetence, but I do believe that a big factor for this is the fact that it is easier to create a new test than to find an existing case (or cases) and modifying it accordingly.

Another cause is the fact that it is a lot easier to measure the number of tests than the measure the quality of your testing coverage (and the quality of the individual tests cases themselves).

Process and rules of thumb for writing test cases

A good way of stopping problems of this type is to have some process and rules of thumb in place to help testers write better cases.

Some examples for rules of thumb you can define with the team can be the following:
Setting upper and lower limits for the number of steps per test case.
Setting maximum number of test cases per feature or functional area.
Working with modular test cases that you can use as building blocks for your complex test scenarios.
Have separate test cases for positive and negative scenarios.
Use attachments and spreadsheets to decouple testing data from testing processes.
Regarding process, this is a little harder but it is also a lot more effective in the long run.  Some examples might be:

Before starting to write test cases have a small team create the test list and their scope, only then fill out the steps.
Break your test repository into areas, assign each area to a tester in your team and make him/her responsible for all aspects of its maintenance.
Have peer test creating or review sessions.
Visit and validate “old” test cases & tests that have not run in the last 6 months.
Review tests that do not find any issues in the last year.
Create visibility and accountability into your test management system

A big factor that will help or hamper the way you maintain your test cases is how you manage and organize them.  You can obviously do this in your file system repository or using something like Dropbox to share these resources with your team.

But  after your tests grow in size or your team expands above a certain level it makes more sense to find a professional test management system that will help you to organize your test cases and generate good visibility and control over them.

I don’t want to make this a marketing post, but I do recommend you take a look at PractiTest and the way we provide excellent visibility into your test cases with the use of our exclusive Hierarchical Filtering system.

Other than creating visibility, make sure there is accountability for each area of your testing repository.  As I wrote above, it is important to assign testing areas and their cases to specific players in your team.

Give them tasks (and the time) to update and maintain their tests, both during the preparation stages but also during the regular testing process.  You should not expect people to maintain their test cases during the frenzy and craziness of your regular testing cycle.