Why backend testing is required?

Assume that you're thinking client-server or web. If you test the application on the front end only you can see if the data was stored and retrievd correctly. You can't see if the servers are in an error state or not. many server processes are monitored by another process. If they crash, they are restarted. You can't see that without looking at it.
The data may not be stored correctly either but the front end may have cached data lying around and it will use that instead. The least you should be doing is verifying the data as stored in the database.
It is easier to test data being transferred on the boundaries and see the results of those transactions when you can set the data in a driver.
Back-End testing : Basically the requirement of this testing depends on ur project. like Say if ur project is .Ticket booking system,Front end u will provided with an Interface , where u can book the ticket by giving the appropriate details ( Like Place to go, and Time when u wanna go etc..). It will have a Data storage system (Database or XL sheet etc) which is a Back end for storing details entered by the user.
After submitting the details ,U might have provided with a correct acknowledgement.But in back end , the details might not updated correctly in Database becoz of wrong logic development. Then that will cause a major problem.
and regarding Unit level testing and System testing Unit level testing is for testing the basic checks whether the application is working fyn with the basic requirements.This will be done by developers before delivering to the QA.In System testing , In addition to the unit checks ,u will be performing all the checks ( all possible integrated checks which required) .Basically this will be carried out by tester .Ever heard about divide and conquer tactic ? It is a same method applied in backend and frontend testing.
A good back end test will help minimize the burden of frontend test.
Another point is you can test the backend while develope the frontend. A true pararelism could be achived.
Backend testing has another problem which must addressed before front end could use it. The problem is concurency. Building a scenario to test concurency is formidable task.
A complex thing is hard to test. To create such scenarios will make you unsure which test you already done and which you haven't. What we need is an effective methods to test our application. The simplest method i know is using divide and conquer.

Testing Cloud

Cloud Testing or Testing Cloud Services is like testing software. It comprises of test measures that are similar to what you are used to, like performance testing, testing functionality (such as testing APPS, web services and configurations), testing security and more. Other test measures are more explicit, like testing continuity. Also new test measures are introduced, like testing against laws and regulations. Important is that testing cloud services needs to start during the selection, since many risks are either covered or just introduced in that phase. Interesting is the necessity to keep testing even in the production phase, since there is no guarantee that what works today also works tomorrow... Many changes happen that are not under your control.

Testing Cloud is referring to USING cloud services FOR testing. For instance for renting infrastructure for test environments. Or outsource testing to the cloud (Testing as a Service).

how to make regression testing creative

a. If you have manual testcases identify an opensource or any other tool to automate those testcases
b. Identify new scenarios that will add value to test your product such as IT Standards, Usability, Security
c. Identify new envionments that your application needs to be run and prepare system testcases
d. Go through requirements and existing testcases and add new test techniques to your test conditions and improve the testcase
e. Incase of automation scripts enhance the scripts in terms of framework, areas of testing and defect capture

What is Recovery Testing

Usage	“Recovery is ability to restart the operation after integrity of application is lost. " It includes reverting to a point where integrity of system is known , then reprocessing up until the point of failure. " The time taken to recover depends upon :the number of restart points volume of application training and skill of people conducting recovery activities tools available for recovery
Objectives	“To ensure operations can be continued after a disaster . " Recovery testing verifies recovery process and effectiveness of recovery process. " Adequate back up data is preserved and kept in secure location. " Recovery procedures are documented. " Recovery personnel have been assigned and trained. " Recovery tools have been developed and are available.
How to Use	“Procedures , methods , tools and techniques are assessed to evaluate the adequacy. " After system is developed a failure can be introduced in the system and check whether the system can recover. " A simulated disaster is usually performed on one aspect of application system. " When there are no. Of failures then instead of taking care of all recovery testing should be carried out for one segment and then another i.e. structured fashion.
Who uses it	“System Analysts " Testing professionals “management personnel.
When to use	“When user says that the continuity of the system is needed inorder for system to perform or function properly. " User then should estimate the losses, time span to carry out recovery testing.
Examples	“Loss of communication , loss of database integrity. " Evaluate adequacy of back up data.

when reopen bug be cancel bug

We can 'Reopen' a closed bug based on the following:

- If the bug is same as old
- If the environment to test/the URL is same
- If the steps to reproduce are exactly the same
- If the old bug does not have more threads and more screenshots
- If the bug is somewhat recent one(May be less than two or three months old)
- If the bug tracking tool is same

Disadvantage of opening the closed bugs:
- Person may forget to change the assignee name to the currently active person, as there are chances for a dev team member may not be in the current project/he may have left the organization
- If the version id/affects version is not marked for the current id, then that bug may be left unnoticed for the current sprint cycle

Note: If we are going to open a new bug, its better if we reference the old bug id in the new one.

ETL Testing?

ETL testing (Extract, Transform, and Load). This article will present you with a complete idea about ETL testing and what we do to test ETL process.

  It has been observed that Independent Verification and Validation is gaining huge market potential and many companies are now seeing this as prospective business gain. Customers have been offered different range of products in terms of service offerings, distributed in many areas based on technology, process and solutions. ETL or data warehouse is one of the offerings which are developing rapidly and successfully.

Test Strategy Guidelines

In order to make the most of our test strategy, we need to make it reusable and manageable. To that end, there are some essential guiding principles we should follow when developing our overall test strategy:

• Test automation is a fulltime effort, not a sideline.
• The test design and the test framework are totally separate entities.
• The test framework should be application-independent.
• The test framework must be easy to expand, maintain, and perpetuate.
• The test strategy/design vocabulary should be framework independent.
• The test strategy/design should remove most testers from the complexities of the test framework.

These ideals are not earth shattering. They are not relatively new. Yet, it is seldom these principles are fully understood and instrumented.

Problems with Test Automation

Historically, test automation has not met with the level of success that it could. Time and again test automation efforts are born, stumble, and die. Most often this is the result of misconceived perceptions of the effort and resources necessary to implement a successful, long-lasting automation framework. Why is this, we might ask? Well, there are several reasons.

Foremost among this list is that automation tool vendors do not provide completely forthright demonstrations when showcasing the "simplicity" of their tools. We have seen the vendor’s sample applications. We have seen the tools play nice with those applications. And we try to get the tools to play nice with our applications just as fluently. Inherently, project after project, we do not achieve the same level of success.

This usually boils down to the fact that our applications most often contain elements that are not compatible with the tools we use to test them. Consequently, we must often mastermind technically creative solutions to make these automation tools work with our applications. Yet, this is rarely ever mentioned in the literature or the sales pitch.

The commercial automation tools have been chiefly marketed for use as solutions for testing an application. They should instead be sought as the cornerstone for an enterprise-wide test automation framework. And, while virtually all of the automation tools contain some scripting language allowing us to get past each tool’s failings, testers have typically neither held the development experience nor received the training necessary to exploit these programming environments.

Most unfortunate of all, otherwise fully capable testers are seldom given the time required to gain the appropriate software development skills. For the most part, testers have been testers, not programmers. Consequently, the "simple" commercial solutions have been far too complex to implement and maintain; and they become shelfware.

Test automation must be approached as a full-blown software development effort in its own right. Without this, it is most likely destined to failure in the long term.

Criteria of a Good Requirement

Criteria of a Good Requirement

Each Individual Requirement Should Be
Necessary: If the system can meet prioritized real needs without the requirement, it isn’t necessary.
Feasible: The requirement is doable and can be accomplished within budget and schedule.
Correct: The facts related to the requirement are accurate, and it is technically and legally possible.
Concise: The requirement is stated simply.
Unambiguous: The requirement can be interpreted in only one way.
Complete: All conditions under which the requirement applies are stated, and it expresses a whole idea or statement.
Consistent: It is not in conflict with other requirements.
Verifiable: Implementation of the requirement in the system can be proved.
Traceable: The source of the requirement can be traced, and it can be tracked throughout the system
(e.g., to the design, code, test, and documentation).
Allocated: The requirement is assigned to a component of the designed system.
Design independent: It does not pose a specific implementation solution.
Nonredundant: It is not a duplicate requirement.
Written using the standard construct: The requirement is stated as an imperative using “shall.”
Assigned a unique identifier: Each requirement shall have a unique identifying number.
Devoid of escape clauses: Language should not include such phrases as “if,” “when,” “but,” “except,” “unless,” and “although.” Language should not be speculative or general (i.e., avoid wording such as “usually,” “generally,” “often,” “normally,” and “typically”).

Difference between Bugzilla & Mantis

Bugzilla

ü  It provides better customization of report queries, and has much more powerful reporting code.

ü  Some excellent statistics might take a minute to generate in Bugzilla.

ü   Setting up scheduled, automated emails with saved searches is an excellent way of reminding someone about bugs that need some action taken. There is also a default available to remind yourself about bugs that have sat around too long.

ü  Bugzilla-Flags. The ability to flag (or “label”) a bug and run searches off of those flags is a feature that I have come to rely on. I can set a bug as “follow-up” or “possible-fix-needs-testing” or “blocking-some-release”. The ability to set labels like that makes bug management and reporting a lot easier.

ü   Advanced search interface, providing more dynamic options. JavaScript is effectively used to update the advanced search panel fields when you make certain selections. It’s a bit easier to create new searches as well as edit existing items, and it’s easier to access searches you’ve saved.

ü  Bugzilla displays a page that confirms the change, but also shows either the bug you just edited or the next bug on the list, reducing the number of pages I need to click though.

ü  Bugzilla has a single view page that allows you edit any field you have without clicking extra buttons.

Advantages:

·         Stores large data’s.

·         Reports are easily designed.

Disadvantages:

·         Lazy processing.

·         Installation is difficult.

·         Usability.

Mantis

ü  Mantis can show some excellent statistics by default

ü   Mantis sends update emails when actions are taken on bugs, which is a great feature to have.

ü  I don’t see any type of automated email reminder system in Mantis.  The lack of this feature is the one thing that really makes using Mantis difficult.

ü  Mantis allows for saving of “filters” but that’s about it. While useful, it requires a bit more work when saving and using multiple filters. Also, I don’t believe that mantis allows you to bookmark your search.

ü  Mantis seems to have several steps in a process that don’t need to be there. I don’t want an entire page to tell me “Operation Successful” after I do something.

ü  When I view a bug in Mantis, I need to click an edit button before I can edit it, but by default, not all of the fields are available to edit. I need to click edit advanced in order to edit every field available.

ü  Mantis doesn’t have the ability to connect with CVS.

ü  In mantis you need to edit a php file in order to change some of the field options, as well as the more advanced options.

Advantages:

·         Interface is very User friendly.

·         Deals with Multi-project & Additional Language - Romanian.

·         Notifications through Email.

·         Upload files as screenshots.

Disadvantages:

·         Reports are complicated.

Who Coined the term "BUG"

Every software tester is familiar with the word bug.They Used this word very often.
Who disocovered it?In what application they foound this?
It was very difficult to answer......:)

The term bug was coind by "Grace Hopper" for the first time in 1945.
In 1945, Grace Murray Hopper was working on the Harvard University Mark II Aiken Relay Calculator (a primitive computer).
On the 9th of September, 1945, when the machine was experiencing problems, an investigation showed that there was a moth trapped between the points of Relay #70, in Panel F

Steps for Manual Testing

Steps for Manual Testing

A manual tester would typically perform the following steps for manual testing:
1.    Understand the functionality of program

2.    Prepare a test environment

3.    Execute test case(s) manually

4.    Verify the actual result

1.    Record the result as Pass or Fail

2.    Make a summary report of the Pass and Fail test cases

3.    Publish the report

4.    Record any new defects uncovered during the test case execution

There is no complete substitute for manual testing. Manual testing is crucial for testing software applications more thoroughly. Test automation has become a necessity mainly due to shorter deadlines for performing test activities, such as regression testing, performance testing, and load testing.