Difference between QA, QC and Testing

Most of the people and organizations are confused about the difference between quality assurance (Q.A.), quality control (Q.C.) and Testing. They are closely related, but they are different concepts. Since all three are necessary to effectively manage the risks of developing and maintaining software.They are defined below:

* Quality Assurance: A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.
* QA is Prevent the issue and correct it.
* QA is the responsibility of entire team.

* Quality Control: A set of activities designed to evaluate a developed work product.
* QC is detect the issue and resolve it.
* QC is the responsibility of team member.
* Testing: The process of executing a system with the intent of finding defects. (Note that the "process of executing a system" includes test planning prior to the execution of the test cases.)

QA activities ensure that the process is defined and appropriate. Methodology and standards development are examples of QA activities. A QA review would focus on the process elements of a project - e.g., are requirements being defined at the proper level of detail. In contrast,

QC activities focus on finding defects in specific deliverables - e.g., are the defined requirements the right requirements. Testing is one example of a QC activity, but there are others such as inspections.

Controversy can arise around who should be responsible for QA and QC activities -- i.e., whether a group external to the project management structure should have responsibility for either QA or QC. The correct answer will vary depending on the situation,
Both QA and QC activities are generally required for successful software development.

* While line management should have the primary responsibility for implementing the appropriate QA, QC and testing activities on a project, an external QA function can provide valuable expertise and perspective.

Error Guessing

Error Guessing is not in itself a testing technique but rather a skill that can be applied to all of the other testing techniques to produce more effective tests (i.e, tests that find defects).

Error Guessing is the ability to find errors or defects in the AUT by what appears to be intuition. In fact, testers who are effective at error guessing actually use a range of techniques, including:

* Knowledge about the AUT, such as the design method or implementation technology
* Knowledge of the results of any earlier testing phases (particularly important in Regression Testing)
* Experience of testing similar or related systems (and knowing where defects have arisen previously in those systems)
* Knowledge of typical implementation errors (such as division by zero errors)
* General testing rules of thumb of heuristics.

Error guessing is a skill that is well worth cultivating since it can make testing much more effective and efficient - two extremely important goals in the testing process. Typically, the skill of Error Guessing comes with experience with the technology and the project. Error Guessing is the art of guessing where errors can be hidden. There are no specific tools and techniques for this, but you can write test cases depending on the situation: Either when reading the functional documents or when you are testing and find an error that you have not documented.

How to access different systems using Web Service?

Lots of approaches to distributed computing have been tried over the years, and many of these are still in use. But none has achieved the same degree of explosive growth and re-use as we have seen with HTML for web UI. The term "web services" encompasses applications that employ a specific combination of technologies to make themselves accessible to other systems running on remote machines. The most significant web services technologies address three questions:

* How do I find web services that I want to use?
* Once I find a service, how do I learn how it works?
* How do I format messages to a web service?

Finding a Web Service:

In the simplest case, you could learn about a web service in the normal course of communicating with your friends, co-workers and business partners. Universal Description, Discovery and Integration (UDDI) offers a more structured approach. UDDI is a standard for establishing and using registries of web services. A company could establish its own private registry of web services available internally, or to its partners and customers. There also are several public UDDI registries that anyone can search, and to which anyone can publish the availability of their own web services.

Understanding a Web Service:

Once you identify a web service that you'd like to use, you need to know how it works: What kinds of messages does it respond to? What does it expect each message to look like? What messages does it return, and how do you interpret the responses? The Web Services Description Language (WSDL) provides a way to declare what messages are expected and produced by a web service, with enough information about their contents to enable using the service successfully with little or no additional information. When you create a web service, you can create a description of the service using WSDL and distribute the description file (often called a WSDL file) to prospective users of the web service, either directly or by including a link to the WSDL file in a UDDI registry entry.

Communicating With a Web Service:

Now that you've obtained the WSDL description of a Web Service, you're ready to invoke it. Web Services communicate with one another via messages in a format known as XML. XML (Extensible Markup Language), like HTML, is a descendent of Standard Generalized Markup Language (SGML). HTML focuses on the way information is to be presented. XML, on the other hand, focuses on the structure of the information, without regard to presentation issues. That's one reason XML is well suited to exchanging information between automated systems. Web services exchange XML messages with one another, typically using either HTTP or SMTP (e-mail) to transport the messages. The Simple Object Access Protocol (SOAP) is a further specification of how to use XML to enable web services to communicate with one another. A SOAP message is just an XML message that follows a few additional rules, most of which deal with how the elements of the message are encoded, and how the message as a whole is addressed.

Web Service

What is a Web Service?

The W3C defines a Web Service as a software system designed to support inter-operable machine to machine interaction over a network. Web services are frequently just API's that can be accessed over a network, and executed on a remote system hosting the requested services.

Among the many ways devised to enable humans to use software running on distant computers, HTML transported over HTTP and presented via a web browser is surely the most successful yet. By using this relatively simple, accessible message format, applications can be used by people all over the world without installing custom client software on their computers.

Other factors for Automation

Deciding factors for Automation

1. What you automate depends on the tools you use. If the tools have any limitations, those tests are manual.
2. Is the return on investment worth automating? Is what you get out of automation worth the cost of setting up and supporting the test cases, the automation framework, and the system that runs the test cases?

Criteria for automating

There are two sets of questions to determine whether automation is right for your test case:

Is this test scenario automate-able?

1. Yes, and it will cost a little.
2. Yes, but it will cost a lot.
3. No, it is no possible to automate.

How important is this test scenario?

1. I must absolutely test this scenario whenever possible.
2. I need to test this scenario regularly.
3. I only need to test this scenario once in a while.

If you answered #1 to both questions – definitely automate that test
If you answered #1 or #2 to both questions – you should automate that test
If you answered #2 to both questions – you need to consider if it is really worth the investment to automate

What happens if you can’t automate?
Let’s say that you have a test that you absolutely need to run whenever possible, but it isn’t possible to automate. Your options are

1. Re-evaluate – Do I really need to run this test this often?
2. What’s the cost of doing this test manually?
3. Look for new testing tools.
4. Consider test hooks.

Automation Testing (Pros and Cons)

Pros of Automation

1. If you have to run a set of tests repeatedly, automation is a huge win for you.
2. It gives you the ability to run automation against code that frequently changes to catch regressions in a timely manner.
3. It gives you the ability to run automation in mainstream scenarios to catch regressions in a timely manner.
4. Aids in testing a large test matrix (different languages on different OS platforms). Automated tests can be run at the same time on different machines, whereas the manual tests would have to be run sequentially.

Cons of Automation

1. It costs more to automate. Writing the test cases and writing or configuring the automate framework you’re using costs more initially than running the test manually.
2. Can’t automate visual references, for example, if you can’t tell the font color via code or the automation tool, it is a manual test.

Manual Testing (Pros and Cons)

Pros of Manual

1. If the test case only runs twice a coding milestone, it most likely should be a manual test. Less cost than automating it.
2. It allows the tester to perform more ad-hoc (random testing). Since, more bugs are found via ad-hoc than via automation. And, the more time a tester spends playing with the feature, the greater the odds of finding real user bugs.

Cons of Manual

1. Running tests manually can be very time consuming.
2. Each time there is a new build, the tester must rerun all required tests - which after a while would become very mundane and tiresome.

Difference between Re-Test and Regression Testing

Re-Test
You have tested an application or a product by executing a test case. The end result deviates from the expected result and is notified as a defect. Developer fixes the defect. The tester executes the same test case that had originally identified the defect to ensure that the defect is rectified.

Regression Test
Developer fixes the defect. Tester re-test the application to ensure that the defect is rectified. He also identifies a set of test cases whose test scenario surrounds the defect to ensure that the functionality of the application remains stable even after addressing the defect.

On the other hand, if a particular functionality had undergone a minor / major modifications, the tester tests the application to identify defects in the changed functionality followed by the execution of certain set of test cases surrounding the same functionality to ensure that the application is stable.

Test Efficiency Vs Test Effectiveness

Test Efficiency:
a. Test efficiency = Internal in the organization how much resources were consumed, how much of these resources were utilized.
b. Number of test cases executed divided by unit of time (generally per hour).
c. Test efficiency = (Total number of defects found in unit + integration + system) / (Total number of defects found in unit + integration + system + User acceptance testing)
d. Test Efficiency: Test the amount of code and testing resources required by a program to perform a function.
e. Testing Efficiency = (No. of defects Resolved / Total No. of Defects Submitted) * 100.
f. Test Efficiency is the rate of bugs found by the tester to the total bugs found.

When the build is sent to the customer side people for the testing (Alpha and Beta Testing), the customer side people also find some bugs.

Test Efficiency = A/(A+B)
Here A= Number of bugs found by the tester
B= Number of bugs found by the customer side people
This test efficiency should always be greater than 90%

Test Effectiveness:
a. Test effectiveness = How much the customer's requirements are satisfied by the system, how well the customer specifications are achieved by the system, how much effort is put in developing the system.
b. Number of defects found divided by number of test cases executed.
c. Test effectiveness = (Total number of defects injected + Total number of defect found) / (Total number of defect escaped)* 100.
d. Test Effectiveness: It judge the Effect of the test environment on the application.
e. Test Effectiveness = Loss due to problems / Total resources processed by the system.

Use of Drivers and Stubs

A driver module is used to simulate a calling module and call the program unit being tested by passing input arguments. The driver can be written in various ways, (e.g., prompt interactively for the input arguments or accept input arguments from a file).

To test the ability of the unit being tested to call another module, it may be necessary to use a different temporary module, called a stub module. More than one stub may be needed, depending on the number of programs the unit calls. The stub can be written in various ways, (e.g., return control immediately or return a message that indicates it was called and report the input parameters received).