Performance Testing vs Load Testing vs Stress Testing

PERFORMANCE TESTING
It is performed to evaluate the performance of components of a particular system in a specific situation. It very wide term. It includes: Load Testing, Stress Testing, capacity testing, volume testing, endurance testing, spike testing, scalability testing and reliability testing etc. This type of testing generally does not give pass or fail. It is basically done to set the benchmark & standard of the application against Concurrency / Throughput, Server response time, Latency, Render response time etc. In other words, you can say it is technical & formal evaluation for responsiveness, speed, scalability and stability characteristics.

LOAD TESTING

It is subset of performance testing. It is done by constantly increasing the load on the application under test till the time it reaches the threshold limit. The main goal of load testing is to identify the upper limit of the system in terms of database, hardware and network etc. The common goal of doing the load testing is to set the SLAs for the application. Example of load testing can be:

Running multiple applications on a computer simultaneously - starting with one application, then start second application, then third and so on....Now see the performance of your computer.

Endurance test is also a part of load testing which used to calculate metrics like Mean Time between Failure and Mean Time to Failure.

Load Testing helps to determine:

• Throughput
• Peak Production Load
• Adequacy of H/W environment
• Load balancing requirements
• How many users application can handle with optimal performance results
• How many users hardware can handle with optimal performance results.

STRESS TESTING

It is done to evaluate the application's behavior beyond normal or peak load conditions. It is basically testing the functionality of the application under high loads. Normally these are related to synchronization issues, memory leaks or race conditions etc. Some testing experts also call it as fatigue testing. Sometimes, it becomes difficult to set up a controlled environment before running the test. Example of Stress testing is:

A banking application can take a maximum user load of 20000 concurrent users. Increase the load to 21000 and do some transaction like deposit or withdraw. As soon as you did the transaction, banking application server database will sync with ATM database server. Now check with the user load of 21000 does this sync happened successfully. Now repeat the same test with 22000 thousand concurrent users and so on.

Spike test is also a part of stress testing which is performed when application is loaded with heavy loads repeatedly and increase beyond production operations for short duration.
Stress Testing helps to determine:

• Errors in slowness & at peak user loads
• Any security loop holes with over loads
• How the hardware reacts with over loads
• Data corruption issues at over loads.

-Se7en Deadly Sins-

Lack of "Lust for finding Defects" – Lust could be an objectionable vice in the Bible, but in the "Bible of Software Testing", lust is a good thing; lust for finding defects that is. Have a craving, appetite, or great desire towards finding defects is something that differentiates a great tester from that of a mediocre one. Once this lust dies down inside a tester’s heart, it would be very difficult to keep going.

Having said this, I do realize that there could be times like the "tester’s block syndrome" [a condition, associated with testing as a profession, in which a tester may lose the ability to find new bugs and defects in the software that (s)he is testing]. It can happen with anybody. But don’t let it become the end of the world for you. If you are struggling to find bugs in the software and feeling burnt out, "change the way you have been testing" – adopt new test ideas, try new ways to find where the AUT (application under test) might be broken, try out pair testing, explore new unexplored areas of the AUT and even try taking a short break. And still, if nothing at all works... then change your AUT! I know how difficult it can be to change the AUT (and your project) in certain contexts. In such cases, try out new applications (there are tons out there begging to be tested; just look around) and once you start finding defects in the new AUT, it won’t be long before you would start discovering defects (again) in your old AUT.

Envy – If you are in the field of testing then I can almost certainly bet that you must have come across testing teams where only few team members perform exceptionally well and the others instead of taking it as a reason of motivation rather feel envious about them. Enviousness and jealousy leads to hatred and hatred in turn takes you further away from the path to success.

Lack of "Greed for Knowledge" – Like lust, greed also is a good thing to have for a software tester. Some call it the "burning desire to learn" and others call it "the passion to excel", but to me they all mean essentially the same thing. Once some great mind said -- "knowledge is wealth/money". And it couldn’t be agreed more for software testing. I believe that a tester should be like a "search engine king", who is a jack of all trades and the master of many! As a test manager I would want my testers to be knowledgeable in every aspects of computing -- knowledge about programming languages, operating systems, web services, technology updates, gadgets, search engines, scripting skills... everything counts as long as they help the team to be better at testing.

Sloth – Laziness is not a luxury if you are in the software business; and the onus is even greater if you are a tester working in a tight testing schedule. In my opinion, this is one of the greatest sins a tester could ever commit – laziness in testing, laziness in learning new stuffs, laziness in updating your skills, laziness in showing interest in finding defects in what you’re testing... all can doom you and your career as a tester. So beware!

Wrath – Numerous situations may arise in a tester’s life where (s)he would find her/him against the team of programmer. But anger and wrath are never the solution to such scenarios. Hate the defects, NOT the programmer. Criticize the software that we test, NOT the programmer who coded it. And don’t ever forget that to err is human and if there were no errors, there would be no need for us (testers) in the team. Being diplomatic and factual with a small dose of humility can do wonders in dealing with any such adverse situations; NOT anger/wrath.

Pride – I can imagine how an occasional self-pat can help boost self-confidence and create room for the much needed motivation. But be careful NOT to overdo it and keep it at "occasional" level. Pride is probably the easiest gateway to witness failure and the feel-good factor associated with pride makes it even more dangerous.

Gluttony – Yes, I said that greed is a good thing for you if you are in the profession of software testing. But greed is not same as gluttony (over-testing, excess testing)! Learning to know where to stop testing is a lesser known art. If you didn’t find any new defects in the past hour of testing, then perhaps you wouldn’t find any, even if you extend the testing session for another couple of hours! In such cases taking a much needed break is a wiser decision than to extend the testing session. Furthermore, every test project is associated with budget constraints and you probably wouldn't want to make your testing efforts look like a liability to the whole project instead of adding value, would you?

Courtesy : Some Blogger

Build a great brand experience

It’s really hard to build a brand. It’s hard to get the attention of others, it’s hard to get people onto your website, and it’s hard to create something that people will buy and use. We realized early on that the best visitors we get hear about us through word of mouth. Word of mouth is driven by happy people who have a great brand experience.

This is how we’ve focused on building a great brand experience:

1. Trust : A great brand experience needs to establish trust between the business and its customers. We establish trust by giving surprisingly honest feedback to customers (such as sending them to a competitor if they’re not a good fit), making it easy for anyone to get in contact with us (by putting a phone number on our website), and focusing on coaching instead of selling.
2. Do the work for the customer : We try to do as much work for the customer as possible. This means spending extra time designing a product to simplify the first time experience, asking for the least amount of information needed to solve a problem, and putting the onus on us to do the work.
3. Creating a genuinely useful product.
4. Surprise people with greatness : Give people unique and useful things that they’ll actually use. Give out the best quality t-shirt you can find instead of settling for the standard Hanes. Give people unique things they couldn’t get anywhere else. Give people something that will make them feel proud to support you.

Brand is everything. It’s every interaction with someone outside of your business. It’s your company culture. It’s your production process and the way you deal with a bug.

The secret to brand building is to start early and often. Your brand is not your logo or color scheme, it’s how people think about you. It’s the way that you represent yourself.

Bug Life Cycle