Basics Of Manual Testing

Test Driver

Bottom-up approach: In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.

Top-down approach: In this approach testing is conducted from main module to sub module. If the sub module is not developed a temporary program called STUB is used for simulate the sub module.

In database testing, which are the things u used?

• Database connectivity
• Domain Constraints
• Key constraints
• Using (JOINS)

What is way of writing test cases for database testing. For writing test cases in Database first one should define the project name, then module, Bug number, objective, steps/action undertaken, expected result, actual result, then status, priority and severity.

What are the types of test strategy?

A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

The test strategy describes the test level to be performed. There are primarily three levels of testing: unit testing, integration testing, and system testing. In most software development organizations, the developers are responsible for unit testing. Individual testers or test teams are responsible for integration and system testing.

What kinds of testing have you done?

Comprehensive Testing: Testing happens in various levels.

• Level 0: sanity testing/Build verification testing/Tester

Acceptance Testing

• Level 1: is comprehensive testing
• Level 2: is regression testing
• Level 3: is Acceptance testing

In level 0: all p0 testcases are executed
Level 1: All p0, p1 and p2 testcases as batches
Level 2: selected p0, p1 and p2 testcases w.r.to modification
Level 3: selected 0, p1, and p2 testcases w.r.to bug density

Comprehensive testing. After level 0 testing and selection of possible testcases for automation, test engineers concentrate on test suite and test set. Every test batch consists of a set of dependent testcases.during these test batch execution test engineers create test log document
with these types of entries like no. of pass, failed and blocked. {During comprehensive test execution, test engineers are reporting mismatches to developers as defects. After resolution of the bug, developers release modified build to testers. Testers reexecute their test to ensure bug fix work and occurrences of side effects}. Is according to mind material.

IS V Model a Process model or a Technique?

Can V process/Technique if answer for above be implemented in Waterfall Model.

V model is one of the software development model where testing is done parallely with the application development.i.e When the development of application is in process test engg will test each and every out come document

For example: Consider a bank application consisting of three modules admin, banker and the customer. The development team has completed the admin module and working with banker module. At this stage the testing team will test the admin module while the developers are in process with the banker module i.e. before completing the whole application. This is the process of v-model. There can be changes in the application with v-model.

Waterfall model is used when requirement are clear and complete and for the small projects. Here we can't incorporate new changes in the application Test Strategy: This is high level document which defines the approach for testing the overall product.

Test planning: Test plan defines the specific information about how to drive, track and record the test efforts along entrance exit criteria, resource planning, risk and contingency plans, etc. Test planning also define the milestone and schedules to effectively manage the efforts and performance.

Different testing methodologies

There are three types of testing methodologies;

• WHITE BOX TESTING-Testing structural part of an application.
• BLACK BOX TESTING-testing functionality of an application
• GREY BOX TESTING-mixture of WBT & BBT

TEST SUITE

Test suite (more formally known as a validation suite) is a collection of test cases that are intended to be used as input to a software program to show that it has some specified set of behaviors (i.e., the behaviors listed in its specification).

A test suite often also contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests.

Collections of test cases are sometimes incorrectly termed a test plan. They may also be called a test script, or even a test scenario.

An executable test suite is a test suite that is ready to be executed. This usually means that there exists a test harness that is integrated with the suite and such that the test suite and the test harness together can work on a sufficiently detailed level to correctly communicate with the system under test (SUT).

What is Bidirectional Traceability and how it is achieved?

When requirements are traced to test cases and vice versa it is called bidirectional traceability.

What is bidirectional traceability?

In the Requirements Management (REQM) process area, specific practice 1.4 states, "Maintain bidirectional traceability among the requirements and work products." Bidirectional traceability is the ability to trace both forward and backward (i.e., from requirements to end products and from end product back to requirements).

Typically, traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, bidirectional traceability is achieved from the source requirements to lower-level requirements and selected work products and verifications and then back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements and selected work products can be traced to a valid source.

Where is system testing covered in CMMI for Development?

Examples of system testing are provided in SP 1.1 of the Verification process area and SP 1.1 of the Validation process area. However, system testing is not a term used in CMMI, since the terms "system" and "testing" can be interpreted in many ways.

The term "system" was not used in CMMI because of its multiple interpretations across disciplines. Instead of "system," the term "product" and "product component" were used for consistency and clarity. The terms "verification" or "validation" were used instead of "testing" since (1) testing can be either part of verification or validation, and (2) testing is only one method used for verification or validation.

What is Automation Test Framework?

A test automation framework is a set of assumptions, concepts, and practices that provide support for automated software testing. This article describes and demonstrates five basic frameworks.

1. The Test Script Modularity Framework
   The test script modularity framework requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.
2. The Test Library Architecture Framework
   The test library architecture framework is very similar to the test script modularity framework and offers the same advantages, but it divides the application-under-test into procedures and functions instead of scripts. This framework requires the creation of library files (SQABasic libraries, APIs, DLLs, and such) that represent modules, sections, and functions of the application-under-test. These library files are then called directly from the test case script.
3. The Keyword-Driven or Table-Driven Testing Framework
   Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.
   
   If we were to map out the actions we perform with the mouse when we test our Windows Calculator functions by hand, we could create the following table. The "Window" column contains the name of the application window where we're performing the mouse action (in this case, they all happen to be in the Calculator window). The "Control" column names the type of control the mouse is clicking. The "Action" column lists the action taken with the mouse (or by the tester) and the "Arguments" column names a specific control (1, 2, 3, 5, +, -, and so on).
   

   Window	Control	Action	Arguments
   Calculator	Menu		View, Standard
   Calculator	Pushbutton	Click	1
   Calculator	Pushbutton	Click	+
   Calculator	Pushbutton	Click	3
   Calculator	Pushbutton	Click	=
   Calculator		Verify Result	4
   Calculator		Clear
   Calculator	Pushbutton	Click	6
   Calculator	Pushbutton	Click	-
   Calculator	Pushbutton	Click	3
   Calculator	Pushbutton	Click	=
   Calculator		Verify Result	3

   This table represents one complete test; more can be made as needed in order to represent a series of tests. Once you've created your data table(s), you simply write a program or a set of scripts that reads in each step, executes the step based on the keyword contained the Action field, performs error checking, and logs any relevant information.

4. The Data-Driven Testing Framework
   Data-driven testing is a framework where test input and output values are read from data files (datapools, ODBC sources, cvs files, Excel files, DAO objects, ADO objects, and such) and are loaded into variables in captured or manually coded scripts. In this framework, variables are used for both input values and output verification values. Navigation through the program, reading of the data files, and logging of test status and information are all coded in the test script.
   
   This is similar to table-driven testing in that the test case is contained in the data file and not in the script; the script is just a "driver," or delivery mechanism, for the data. Unlike in table-driven testing, though, the navigation data isn't contained in the table structure. In data-driven testing, only test data is contained in the data files.
5. The Hybrid Test Automation Framework
   
   

What Is a Test Strategy?

Why do a test strategy? The test strategy is the plan on how to approach testing. The purpose of a test strategy includes:

• To obtain consensus of goals and objectives from stakeholders (e.g., management, developers, testers, customers, users)
• To manage expectations from the beginning
• To be sure we're "headed in the right direction"
• To identify the types of tests to be conducted at all test levels
• A test strategy provides an overall perspective of testing, and identifies or references:
• Project plans, risks, and requirements
• Relevant regulations, policies, or directives
• Required processes, standards, and templates
• Supporting guidelines
• Stakeholders and their test objectives
• Test resources and estimates
• Test levels and phases
• Test environment
• Completion criteria for each phase
• Required test documentation and review methods

What is a test strategy?

Answer:

A test strategy must address the risks and present a process that can reduce those risks.

The two components of Test strategy are:

1. Test Factor: The risk of issue that needs to be addressed as a part of the test strategy. Factors that are to be addressed in testing a specific application system will form the test factor.
2. Test phase: The phase of the systems development life cycle in which testing will occur.

WHAT IF THERE ISN'T ENOUGH TIME FOR THOROUGH TESTING

Here are some points to be considered when you are in such a situation:

1. Find out Important functionality is your project?
2. Find out High-risk module of the project?
3. Which functionality is most visible to the user?
4. Which functionality has the largest safety impact?
5. Which functionality has the largest financial impact on users?
6. Which aspects of the application are most important to the customer?
7. Which parts of the code are most complex, and thus most subject to errors?
8. Which parts of the application were developed in rush or panic mode?
9. What do the developers think are the highest-risk aspects of the application?
10. What kinds of problems would cause the worst publicity?
11. What kinds of problems would cause the most customer service complaints?
12. What kinds of tests could easily cover multiple functionalities?

When to stop testing?

Answer:

1. When all the requirements are adequately executed successfully through test cases
2. Bug reporting rate reaches a particular limit
3. The test environment no more exists for conducting testing
4. The scheduled time for testing is over
5. The budget allocation for testing is over

Your company is about to roll out an E-Commerce application. It is not possible to test the application on all types of browsers on all platforms and operating systems. What steps would you take in the testing environment to reduce the business risks and commercial risks?

Answer:

Compatibility testing should be done on all browsers (IE, Netscape, Mozilla etc.) across all the operating systems (win 98/2K/NT/XP/ME/Unix etc.)

What's the difference between priority and severity?

Answer:

"Priority" is associated with scheduling, and "severity" is associated with standards.

"Priority" means something is afforded or deserves prior attention; precedence established by order of importance (or urgency). "Severity" is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior. The words priority and severity do come up in bug tracking. A variety of commercial, problem tracking management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its 'severity', reproduce it and fix it. The fixes are based on project 'priorities' and 'severity' of bugs. The 'severity' of a problem is defined in accordance to the customer's risk assessment and recorded in their
selected tracking tool. Buggy software can 'severely' affect schedules, which, in turn can lead to a reassessment and renegotiation of 'priorities'.

Your manager has taken you onboard as a test lead for testing a web-based application. He wants to know what risks you would include in the Test plan. Explain each risk factor that would be a part of your test plan.

Answer:

Web-Based Application primary risk factors:-

1. Security :- anything related to the security of the application.
2. Performance :- The amount of computing resources and code required by the system to perform its stated functions.
3. Correctness :- Data entered, processed, and outputted in the system is accurate and complete
4. Access Control :- Assurance that the application system resources will be protected
5. Continuity of processing :- The ability to sustain processing in the event problem occurs
6. Audit Trail :- The capability to substantiate the processing that has occurred.
7. Authorization :- Assurance that the data is processed in accordance with the intents of the management.

General risk or secondary risk's:-

1. Complex :- anything disproportionately large, intricate or convoluted.
2. New :- anything that has no history in the product.
3. Changed :- anything that has been tampered with or "improved".
4. Upstream Dependency :- anything whose failure will cause cascading failure in the rest of the system.
5. Downstream Dependency :- anything that is especially sensitive to failures in the rest of the system.
6. Critical :- anything whose failure could cause substantial damage.
7. Precise :- anything that must meet its requirements exactly.
8. Popular :- anything that will be used a lot.
9. Strategic :- anything that has special importance to your business, such as a feature that sets you apart from the competition.
10. Third-party :- anything used in the product, but developed outside the project.
11. Distributed :- anything spread out in time or space, yet whose elements must work together.
12. Buggy :- anything known to have a lot of problems.
13. Recent Failure :- anything with a recent history of failure.

What is parallel testing and when do we use parallel testing? Explain with example?

Answer:

Testing a new or an altered data processing system with the same source data that is used in another system. The other system is considered as the standard of comparison. OR we can say that parallel testing requires the same input data be run through two versions of the same application.

Parallel testing should be used when there is uncertainty regarding the correctness of processing of the new application. And old and new versions of the applications are same.

E.g.-

1. Operate the old and new version of the payroll system to determine that the paychecks from both systems are reconcilable.
2. Run the old version of the application system to ensure that the operational status of the old system has been maintained in the event that problems are encountered in the new application.

What is the difference between testing Techniques and tools? Give examples.

Answer:

• Testing technique :- Is a process for ensuring that some aspects of the application system or unit functions properly there may be few techniques but many tools.
• Tools :- Is a vehicle for performing a test process. The tool is a resource to the tester, but itself is insufficient to conduct testing.
• E.g. :- The swinging of hammer to drive the nail. The hammer is a tool, and swinging the hammer is a technique. The concept of tools and technique is important in the testing process. It is a combination of the two that enables the test process to be performed. The tester should first understand the testing techniques and then understand the tools that can be used with each of the technique.

Differentiate between Transaction flow modeling, Finite state modeling, Data flow modeling and Timing modeling?

Answer:

• Transaction Flow modeling :-The nodes represent the steps in transactions. The links represent the logical connection between steps.
• Finite state modeling :-The nodes represent the different user observable states of the software. The links represent the transitions that occur to move from state to state.
• Data flow modeling :-The nodes represent the data objects. The links represent the transformations that occur to translate one data object to another.
• Timing Modeling :-The nodes are Program Objects. The links are sequential connections between the program objects. The link weights are used to specify the required execution times as program executes.

What is SEI? CMM? ISO? IEEE? ANSI?

SEI = 'Software Engineering Institute' at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.

CMM = 'Capability Maturity Model', developed by the SEI. It's a model of 5 levels of organizational 'maturity' that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMM ratings by undergoing assessments by qualified auditors.

Level 1 - characterized by chaos, periodic panics, and heroic efforts required by individuals to successfully complete projects. Few if any processes in place; successes may not be repeatable.

Level 2 - software project tracking, requirements management, realistic planning, and configuration management processes are in place; successful practices can be repeated.

Level 3 - standard software development and maintenance processes are integrated throughout an organization; a Software Engineering Process Group is in place to oversee software processes, and training programs are used to ensure understanding and compliance.

Level 4 - metrics are used to track productivity, processes, and products. Project performance is predictable, and quality is consistently high.

Level 5 - the focus is on continuous process improvement. The impact of new processes and technologies can be predicted and effectively implemented when required.

ISO = 'International Organization for Standards' - The ISO 9001, 9002, and 9003 standards concern quality systems that are assessed by outside auditors, and they apply to many kinds of production and manufacturing organizations, not just software. The most comprehensive is 9001, and this is the one most often used by software development organizations. It covers documentation, design, development, production, testing, installation, servicing, and other processes. ISO 9000-3 (not the same as 9003) is a guideline for applying ISO 9001 to software development organizations. The U.S. version of the ISO 9000 series standards is exactly the same as the international version, and is called the ANSI/ASQ Q9000 series. The U.S. version can be purchased directly from the ASQ (American Society for Quality) or the ANSI organizations. To be ISO 9001 certified, a third-party auditor assesses an organization, and certification is typically good for about 3 years, after which a complete reassessment is required. Note that ISO 9000 certification does not necessarily indicate quality products - it indicates only that documented processes are followed.

IEEE = 'Institute of Electrical and Electronics Engineers' - among other things, creates standards such as 'IEEE Standard for Software Test Documentation' (IEEE/ANSI Standard 829), 'IEEE Standard of Software Unit Testing (IEEE/ANSI Standard 1008), 'IEEE Standard for Software Quality Assurance Plans' (IEEE/ANSI Standard 730), and others.

ANSI = 'American National Standards Institute', the primary industrial standards body in the U.S.; publishes some software-related standards in conjunction with the IEEE and ASQ (American Society for Quality).

SOME MAJOR NEGATIVE TEST CASES TO BREAK THE SIGN UP PAGE:

1. See the limit of username field. I mean the data type of this field in DB and the field size. Try adding more characters to this field than the field size limit. See how application responds to this.
2. Repeat above case for number fields. Insert number beyond the field storage capacity. This is typically a boundary test.
3. For username field try adding numbers and special characters in various combinations. (Characters like!@#$ %^&*()_+}{":?><,./;'[]). If not allowed specific message should be displayed to the user.
4. Try above special character combination for all the input fields on your sign up page having some validations. Like Email address field, URL field validations etc.
5. Many applications crash for the input field containing ' (single quote) and " (double quote) examples field like: "Vijay's web". Try it in all the input fields one by one.
6. Try adding only numbers to input fields having validation to enter only characters and vice versa.
7. If URL validation is there then see different rules for url validation and add urls not fitting to the rules to observe the system behavior.
   
   Example urls like: vijay.com/?q=vijay's!@#$ %^&*()_+}{":?><,./;'[]web_page. Also add urls containing http:// and https:// while inserting into url input box.
   
8. If your sign up page is of some steps like step 1 step 2 etc. then try changing parameter values directly into browser address bar. Many times urls are formatted with some parameters to maintain proper user steps. Try altering all those parameters directly without doing anything actually on the sign up page.
9. Do some monkey testing manually or automating (i.e. Insert whatever comes in mind or random typing over keyboard) you will come up with some observations.
10. See if any page is showing JavaScript error either at the browser left bottom corner or enable the browser settings to display popup message to any JavaScript error.

White Box Testing is coverage of the specification in the code.

Code coverage:

An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

Code Coverage Analysis

1.1 Basis Path Testing

A testing mechanism proposed by McCabe whose aim is to derive a logical complexity measure of a procedural design and use this as a guide for defining a basic set of execution paths. These are test cases that exercise basic set will execute every statement at least once.

1.1.1 Flow Graph Notation

A notation for representing control flow similar to flow charts and UML activity diagrams.

1.1.2 Cyclomatic Complexity

The cyclomatic complexity gives a quantitative measure of 4the logical complexity. This value gives the number of independent paths in the basis set, and an upper bound for the number of tests to ensure that each statement is executed at least once. An independent path is any path through a program that introduces at least one new set of processing statements or a new condition (i.e., a new edge). Cyclomatic complexity provides upper bound for number of tests required to guarantee coverage of all program statements.

1.2 Control Structure testing

1.2.1 Conditions Testing

Condition testing aims to exercise all logical conditions in a program module. They may define:

• Relational expression: (E1 op E2), where E1 and E2 are arithmetic expressions.
• Simple condition: Boolean variable or relational expression, possibly proceeded by a NOT operator.
• Compound condition: composed of two or more simple conditions, Boolean operators and parentheses.
• Boolean expression : Condition without Relational expressions.

1.2.2 Data Flow Testing

Selects test paths according to the location of definitions and use of variables.

1.2.3 Loop Testing

Loops fundamental to many algorithms. Can define loops as simple, concatenated, nested, and unstructured.

Examples:

Note that unstructured loops are not to be tested . rather, they are redesigned.

• Segment coverage: Ensure that each code statement is executed once.
• Branch Coverage or Node Testing: Coverage of each code branch in from all possible was.
• Compound Condition Coverage: For multiple condition test each condition with multiple paths and combination of different path to reach that condition.
• Basis Path Testing: Each independent path in the code is taken for testing.
• Data Flow Testing (DFT): In this approach you track the specific variables through each possible calculation, thus defining the set of intermediate paths through the code.DFT tends to reflect dependencies but it is mainly through sequences of data manipulation. In short each data variable is tracked and its use is verified.

This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.

• Path Testing: Path testing is where all possible paths through the code are defined and covered. It's a time consuming task.
• Loop Testing: These strategies relate to testing single loops, concatenated loops, and nested loops. Independent and dependent code loops and values are tested by this approach.

Why we do White Box Testing?

To ensure:

• That all independent paths within a module have been exercised at least once.
• All logical decisions verified on their true and false values.
• All loops executed at their boundaries and within their operational bounds internal data structures validity.
  
  Need of White Box Testing? To discover the following types of bugs:
  
• Logical error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program
• The design errors due to difference between logical flow of the program and the actual implementation
• Typographical errors and syntax checking skills Required:

We need to write test cases that ensure the complete coverage of the program logic.

For this we need to know the program well i.e. we should know the specification and the code to be tested. Knowledge of programming languages and logic.

Limitations of WBT:

Not possible for testing each and every path of the loops in program. This means exhaustive testing is impossible for large systems.

This does not mean that WBT is not effective. By selecting important logical paths and data structure for testing is practically possible and effective.

BLACK BOX TESTING

Black box testing treats the system as a "black-box", so it doesn't explicitly use Knowledge of the internal structure or code. Or in other words the Test engineer need not know the internal working of the "Black box" or application.

Main focus in black box testing is on functionality of the system as a whole. The term 'behavioral testing' is also used for black box testing and white box testing is also sometimes called 'structural testing'. Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn't strictly forbidden, but it's still discouraged.

Each testing method has its own advantages and disadvantages. There are some bugs that cannot be found using only black box or only white box. Majority of the application are tested by black box testing method. We need to cover majority of test cases so that most of the bugs will get discovered by black box testing.

Black box testing occurs throughout the software development and Testing life cycle i.e. in Unit, Integration, System, Acceptance and regression testing stages.

Tools used for Black Box testing:

Black box testing tools are mainly record and playback tools. These tools are used for regression testing that to check whether new build has created any bug in previous working application functionality. These record and playback tools records test cases in the form of some scripts like TSL, VB script, Java script, Perl.

Advantages of Black Box Testing

• Tester can be non-technical.
• Used to verify contradictions in actual system and the specifications.
• Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing

• The test inputs needs to be from large sample space.
• It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
• Chances of having unidentified paths during this testing

Methods of Black box Testing:

Graph Based Testing Methods:

Each and every application is build up of some objects. All such objects are identified and graph is prepared. From this object graph each object relationship is identified and test cases written accordingly to discover the errors.

Error Guessing:

This is purely based on previous experience and judgment of tester. Error Guessing is the art of guessing where errors can be hidden. For this technique there are no specific tools, writing the test cases that cover all the application paths.

Boundary Value Analysis:

Many systems have tendency to fail on boundary. So testing boundary values of application is important. Boundary Value Analysis (BVA) is a test Functional Testing technique where the extreme boundary values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values.

• Extends equivalence partitioning
• Test both sides of each boundary
• Look at output boundaries for test cases too
• Test min, min-1, max, max+1, typical values

BVA techniques:

1. Number of variables
   For n variables: BVA yields 4n + 1 test case.
2. Kinds of ranges

Generalizing ranges depends on the nature or type of variables.

Advantages of Boundary Value Analysis

• Robustness Testing - Boundary Value Analysis plus values that go beyond the limits
• Min - 1, Min, Min +1, Nom, Max -1, Max, Max +1
• Forces attention to exception handling

Limitations of Boundary Value Analysis

Boundary value testing is efficient only for variables of fixed values i.e. boundary.

Equivalence Partitioning:

Equivalence partitioning is a black box testing method that divides the input domain of a program into classes of data from which test cases can be derived.

How this partitioning is performed while testing:

1. If an input condition specifies a range, one valid and one two invalid classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined.
4. If an input condition is Boolean, one valid and one invalid class is defined.

Comparison Testing:

Different independent versions of same software are used to compare to each other for testing in this method.

What is Impact analysis? How to do impact analysis in your project?

Impact analysis means when we r doing regressing testing at that time we are checking that the bug fixes r working properly, and by fixing these bug other components are working as per their requirements are they got disturbed.

Which comes first test strategy or test plan?

Test strategy comes first and this is the high level document. And approach for the testing starts from test strategy and then based on this the test lead prepares the test plan.

What is the difference between web based application and client server application as a tester's point of view?

According to Tester's Point of view

1. Web Base Application (WBA) is a 3 tier application; Browser, Back end and Server. Client server Application (CSA) is a 2 tier Application; Front End, Back end.
2. In the WBA tester test for the Script error like java script error VB script error etc, that shown at the page. In the CSA tester does not test for any script error.
3. Because in the WBA once changes perform reflect at every machine so tester has less work for test. Whereas in the CSA every time application need to be install hence ,it maybe possible that some machine has some problem for that Hardware testing as well as software testing is needed.

What is the significance of doing Regression testing?

To check for the bug fixes. And this fix should not disturb other functionality. To ensure the newly added functionality or existing modified functionality or developer fixed bug arises any new bug or affecting any other side effect. This is called regression test and ensure already PASSED TEST CASES would not arise any new bug.

What are the diff ways to check a date field in a website?

There are different ways like:–

1. you can check the field width for minimum and maximum.
2. If that field only take the Numeric Value then check it'll only take Numeric no other type.
3. If it takes the date or time then check for other.
4. Same way like Numeric you can check it for the Character, Alpha Numeric and all.
5. And the most Important if you click and hit the enter key then some time page may give the error of JavaScript, that is the big fault on the page.
6. Check the field for the Null value.

The date field we can check in different ways Positive testing: first we enter the date in given format.

What is Positive Testing ?

Testing aimed at showing software works. Also known as "test to pass".

What is Negative Testing?

Testing aimed at showing software does not work. Also known as "test to fail".

In negative testing, we check whether the application or system handles the exception properly or not. It is nothing but "Test to Break" testing.

What is the difference between QC and QA?

Quality assurance is the process where the documents for the product to be tested are verified with actual requirements of the customers. It includes inspection, auditing, code review, meeting etc. Quality control is the process where the product is actually executed and the expected behavior is verified by comparing with the actual behavior of the software under test. All the testing types like black box testing, white box testing comes under quality control. Quality assurance is done before quality control.

What is Gray Box Testing?

A combination of Black Box and White Box testing methodologies, testing a piece of software against its specification but using some knowledge of its internal workings.

Difference between smoke testing and sanity testing

Smoke Testing is non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details. Sanity Testing is a cursory testing, it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

The difference between smoke and sanity testing is in smoke testing tester concentrate on the core functionality of the application whether it is working or not for further functionality.eg.build crash, environmental effect, networking etc.

Sanity testing basic functionalities are tested, eg.check boxes, radio buttons, text boxes, list boxes.

What is Ramp Testing?

Continuously raising an input signal until the system breaks down.

What is beta testing

testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.

What is alpha testing

testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

What is Test Bed?

An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerate the test beds(s) to be used.
What is a scenario?

A scenario defines the events that occur during each testing session. For example, a scenario defines and controls the number of users to emulate, the actions to be performed, and the machines on which the virtual users run their emulations.

What is Gorilla Testing?

Testing one particular module, functionality heavily.

what is the difference between system testing and end to end testing. System testing is done with respect to the Application functionality by considering that system as a individual(internal functionality flow).

Where as in End to end testing we will verify the application end to end functional flow by considering all other integrated applications functionality (includes upstream and downstream systems connected to that particular application for which System Testing is completed as mentioned above).

What is Code Coverage?

An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

GLOBALIZATION TESTING

The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.

Select a test platform

So, which operating system (OS) should you use for your international testing platform? The first choice should be your local build of Windows 2000 with a language group installed. For example, if you use the U.S. build of Windows 2000, install the East Asian language group.

• MUI (Multilanguage User Interface) Windows 2000 - especially useful if your code implements multilingual UI and it must adjust to the UI settings of the OS. This approach is an easier implemented alternative to installing multiple localized versions of the OS. To further enhance multilingual support, Microsoft offers a separate Windows 2000 Multilanguage Version, which provides up to 24 localized language versions of the Windows user interface.
• Localized build of the target OS - German or Japanese are good choices. Remember it might be harder to work with them if you do not know the operating system's UI language. This approach does not have significant advantages over the solutions above.
• Execute tests
  After the environment has been set for globalization testing, you must pay special attention to potential globalization problems when you run your regular test cases:
• Put greater importance on test cases that deal with the input/output of strings, directly or indirectly.
• Test data must contain mixed characters from East Asian languages, German, Complex Script characters (Arabic, Hebrew, Thai), and optionally, English. In some cases, there are limitations, such as the acceptance of characters that only match the culture/locale. It might be difficult to manually enter all of these test inputs if you do not know the languages in which you are preparing your test data. A simple Unicode text generator may be very helpful at this step.

Recognize the problems

The most serious globalization problem is functionality loss, either immediately (when a culture/locale is changed) or later when accessing input data (non-U.S. character input).

Some functionality problems are detectable as display problems:

• Question marks (?) appearing instead of displayed text indicate problems in Unicode-to-ANSI conversion.
• Random High ANSI characters (e.g., ¼, †, ‰, ‡, ¶) appearing instead of readable text indicate problems in ANSI code using the wrong code page.
• The appearance of boxes, vertical bars, or tildes (default glyphs) [□, |, ~] indicates that the selected font cannot display some of the characters.

It might be difficult to find problems in display or print results that require shaping, layout, or script knowledge. This test is language-specific and often cannot be executed without language expertise. On the other hand, your test may be limited to code inspection. If standard text-handling mechanisms are used to form and display output text, you may consider this area safe.

Another area of potential problems is code that fails to follow local conventions as defined by the current culture/locale. Make sure your application displays culture/locale-sensitive data (e.g., numbers, dates, time, currency, and calendars) according to the current regional settings of your computer.

LOCALIZATION TESTING

Localization translates the product UI and occasionally changes some initial settings to make it suitable for another region. Localization testing checks the quality of a product's localization for a particular target culture/locale. This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be executed only on the localized version of a product. Localizability testing does not test for localization quality.

The test effort during localization testing focuses on:

• Areas affected by localization, such as UI and content
• Culture/locale-specific, language-specific, and region-specific areas

In addition, localization testing should include:

• Basic functionality tests
• Setup and upgrade tests run in the localized environment
• Plan application and hardware compatibility tests according to the product's target region.

You can select any language version of Windows 2000 as a platform for the test. However, you must install the target language support.

The localization testing of the user interface and linguistics should cover items such as:

• Validation of all application resources
• Verification of linguistic accuracy and resource attributes
• Typographical errors
• Consistency checking of printed documentation, online help, messages, interface resources, command-key sequences, etc.
• Confirmation of adherence to system, input, and display environment standards
• User interface usability
• Assessment of cultural appropriateness
• Checking for politically sensitive content

DATABASE TESTING

In DB testing we need to check for:

1. The field size validation
2. Check constraints.
3. Indexes are done or not (for performance related issues).
4. Stored procedures.
5. The field size defined in the application is matching with that in the db.
6. We can check whether all the data from the application is being inserted into the database properly, or not imposes constraints on the data i.e. database integrity.
7. Database testing is the test various things of data like its functioning, performance, loading. It also checks and removes the data redundancy.
8. Database testing can be done in two ways that is testing the backend end database by inserting the values in the frontend application and seeing whether these had been inserted correctly r not and at the same time inserting the values in the backend database directly and seeing them in the frontend application.
9. we can retrieve the data by giving some select statements and at the same time insert them by insert statements in the database and check. Whether they are been effected or not.
10. In manual database testing we will type the query and see that the table is giving the same result or not.

HOW DO YOU DIFFERENTIATE BETWEEN TRUNCATE AND DELETE?

Truncate removes all the rows from the table and cannot be rollbacked, while delete removes all/specific rows from table and can be rollbacked.
Also truncate resets the high water mark.

A common misconception is that they do the same thing. Not so. In fact, there are many differences between the two. DELETE is a logged operation on a per row basis. This means that the deletion of each row gets logged and physically deleted. You can DELETE any row that will not violate a constraint, while leaving the foreign key or any other constraints in place. TRUNCATE is also a logged operation, but in a different way. TRUNCATE logs the deallocation of the data pages in which the data exists. The deallocation of data pages means that your data rows still actually exist in the data pages, but the extents have been marked as empty for reuse. This is what makes TRUNCATE a faster operation to perform over DELETE. You cannot TRUNCATE a table that has any foreign key constraints. You will have to remove the constraints, TRUNCATE the table, and reapply the constraints.

The difference between the two is that the truncate command is a DDL operation and just moves the high water mark and produces a now rollback. The delete command, on the other hand, is a DML operation, which will produce a rollback and thus take longer to complete.

DESKTOP TESTING, CLIENT/SERVER TESTING, WEB TESTING

Desktop application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e. DB.

In client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.

Web application is a bit different and complex to test as tester don't have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.

Standards for Software Test Plans

Several standards suggest what a test plan should contain, including the IEEE.

The standards are:

IEEE standards:

• 829-1983 IEEE Standard for Software Test Documentation
• 1008-1987 IEEE Standard for Software Unit Testing
• 1012-1986 IEEE Standard for Software Verification & Validation Plans
• 1059-1993 IEEE Guide for Software Verification & Validation Plans

What is good code?

A code which is:

1. bug free
2. reusable
3. independent
4. less complexity
5. well documented
6. easy to chage is called good code

What type of metrics would you use?

1. QAM: Quality AssuranceMatrix
2. TMM: Test ManagementMatrix
3. PCM: Process Compatibility Matrix

How involved where you with your Team Lead in writing the Test Plan?

As per my knowledge Test Member are always out of scope while preparing the Test Plan, Test Plan is a higher level document for Testing Team. Test Plan includes Purpose, scope, Customer/Client scope, schedule, Hardware, Deliverables and Test Cases etc.

Test plan derived from PMP (Project Management Plan). Team member scope is just go through TEST PLAN then they come to know what all are their responsibilities, Deliverable of modules.

Test Plan is just for input documents for every testing Team as well as Test Lead.

What processes/methodologies are you familiar with?

Methodology

1. Spiral methodology
2. Waterfall methodology. these two are old methods.
3. Rational unified processing. this is from I B M and
4. Rapid application development. this is from Microsoft office.

What is globalization testing?

The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems.

What is migration testing?

Changing of an application or changing of their versions and conducting testing is migration testing.

Testing of programs or procedures used to convert data from existing systems for use in replacement systems.

What is UAT testing. When it is to be done?

UAT stands for 'User acceptance Testing' This testing is carried out with the user perspective and it is usually done before a release UAT stands for User Acceptance Testing. It is done by the end users along with testers to validate the functionality of the application. It is also called as Pre-Production testing.