Retesting Vs Regression Testing

Retesting: If any change is made into the application, testing only those changes and not the entire application is known as Retesting.

Regression Testing: If any change is made into the application, testing the entire application to ensure that changes made has not broken any existing functionality is known as Regression testing.

Test Case

1. What is a test case?

“A set of test data and their expected results.

2. Why we write test cases?

To validate the testing coverage of the application.

3. How to write test cases (Example of test case or Sample of Test Case)?

There is no particular formula for  writing the test case. Basic elements used in the test case are:

a. Test case number: 1 OR 1.1

b. Test Case Name: Login Verification

c. Test case Inputs or Steps or Action: Enter Login credentials, Click on “login” button.

d. Test Case Expected result: Verify that user is successfully login to “Home” page.

e. Test Case Status: Pass or Fail.

f. Comments: If test case is fail the you can write why it is failed. Also you can write bug number here which you are going to be reporting.

You should ask your self a question before writing the test case "What should be the steps followed by different users to use this functionality". Surely you will get the answer and just you have to write that answer in the form of points in excel sheet. Those points will automatically become test cases :)

Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written.

4. What is the suitable time to create Test case?
There are levels in which test cases should be analized/designed to avoid duplication efforts.

Level 1: In this level tester should write the basic test cases from the available specification documentation.
Level 2: This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
Level 3: This is the stage in which tester should group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases.

5. Automation vs Manual Test Cases
The following types of test cases can be preferred for automation:
a. Test cases that need to run on every build.
b. Test cases that use multiple data values for same action.
c. Identical test cases that need to be executed using different browsers.

The following types of test cases should not consider for automation testing:
a. Test Cases that will only be executed once.
b. Test Cases used for Ad-hoc/random Testing.
c. Test Cases that are infrequently selected for execution.
d. Test Cases that will require manual intervention i.e. a task not possible to automate.
e. Based on the intuition and knowledge of application. Eg. if you find that you cannot escape from manual intervention.


6. Examples

1. Basic Test Cases for Fan 1. It should have a hook for hanging in the roof.
2. It should have minimum three blades.
3. It should be moving once the electricity pass into it.
4. Speed of the fan should be controlled by the regulator.
5. It should be stop once the electric switch off.
6. The fan should run with minimum noise.
7. The blades should have proper distance from the ceiling.
8. The fan while in motion, should not vibrate.
9. The color of the fan should be dark.
10. Fan should work in clock-wise direction

2. Basic Test Cases for Credit Card Case 1: Check for invalid Characters in Credit Card.
Description: Enter invalid characters @@@@34534"asd".
Expected Result: Error message should appear informing that invalid value is entered.

Case 2: Check for wrong Credit Card type.
Description: Enter invalid Credit Card type e.g. Enter Am Ex in place of VISA.
Expected Result: Error message should appear informing that invalid Credit Card is entered.

Case 3: Check for wrong Expiry Date.
Description: Select wrong month & year of expiry date.
Expected Result: Error message should appear informing that invalid Expiry date has been entered.

Case 4: Check for CVV number with the invalid characters as well as with the alphabetic & alpha numeric values.
Description: Enter invalid CVV number. Like: ABC or a3c. or @@" or "1".
Expected Result: Error message should appear information. Invalid characters are entered.

Case 5: Check for validation messages while enter wrong billing information.
Description: Check for Maximum & Minimum value acceptance. Check for invalid Characters. Check for Numeric value acceptance where numeric values are required & vice-versa.
Expected Result: Error message should appear while enter invalid values.

3. Basic Test Cases for Printer 1) Open page setup by selecting File>Page Setup
Expected Result: Page Setup dialog appears

What to Print
2) In Page Setup, select Orientation = Portrait, Margins = 10 for Top, Bottom, Right, Left. Click OK.Expected Result: Error: “The margins overlap or they are off the paper. Enter a different margin size.” Click OK

3) Now select Orientation =Landscape
Expected Result: Notice that all margins are automatically reset to default values.

4) In Page Setup, click on Printer. In Printer, select a printer from the Name list., then click on Properties. Expected Result: Verify that the selected printer's name is displayed as part of the title of Document Properties popup.

5) In Document Properties, leave defaults as is (Portrait, None, Front to Back). On the Layout tab, click OK to close all popups belonging to Page Setup. File>Print. In Print, click on Properties. In Document Properties, select Landscape, Flip on Long Edge, and Pages Per Sheet = 2.. Click OK
Expected Result: Notice that printout is based on the settings in File>Print, i.e. This setup override the one in Page Setup.

Miscellaneous Cases:
6) Make changes to the setting and click the Default button
Expected Result: Settings should revert to defaults

7) Switch to a different printer
Expected Result: When printed, the diagram should be sent to alternate printer

8) Switch to the plotterExpected Result: When printed, the diagram should be sent to the plotter

9) Switch to a color printer
Expected Result: When printed, the diagram should be sent to the color printer

10) Change the paper size
Expected Result: When printed, the diagram should appear on the correct paper size

11) Switch to portrait orientationExpected Result: When printed, the diagram should appear in portrait orientation

12) Switch to landscape orientation
Expected Result: When printed, the diagram should appear in landscape orientation

Other Printer Test Cases:
Case 1: Ensure correct behavior of application with Print functionality.

Steps:

1. Verify that printer is connected with machine.

2. Open the application and click on Print. Verify printouts in all the views.

Case 2: Ensure that application behaves correctly if printer is not available. Steps:1. Verify that no printer is connected with machine. 2. Open the application and click on Print. 3. Verify that proper message appears for printer unavailability.

Case 3: Ensure that application queues prints in printer if papers are not available in printer.

Steps:

1. Verify that printer is connected with machine. 

2. Verify that no papers are available. 

3. Open the application and click on Print. Verify that all the prints which were in queue.

Case 4: Ensure correct behavior of application if printer is uninstalled. 

Steps:

1. Verify that printer is uninstalled from machine.

2. Open the application and click on Print.

3. Verify that proper message appears for printer unavailability.

Case 5: Ensure correct behavior of Print functionality with new installed printer. Steps:

1. Verify that printer is uninstalled from machine. 

2. Now, install printer on machine. 

3. Open the application and click on Print. 

4. Verify printouts in all the views.

4. Basic Test Cases for Paging Functionality Condition: Qty available is given and we have to fill Qty we want (Reffer iReuse.com paging)

Test Case 1:
1. Try to enter Qty we want more than Qty available (this should not happend).
2. Try to enter alphabets (this should not happend).
3. Submit without entering anything.

 
Test Case 2:
1. Select page 1 enter items.
2. select page 2 enter items.
3. Click again on page 1 and see if this remembers same entered items.
4. Click again on page 2 and see if this remembers same entered items.
5. Submit, check the email and match result.

 
Test Case 3:
1. Select page 1 do not enter items.
2. select page 2 enter items.
3. Click again on page 1 and now enter items.
4. Click again on page 2 and see if this remembers same entered items. Then change some items.
5. Submit, check the email and match result.

 
Expected critical errors: Sometime items exchanged the values from different pages.

5. Test Cases for Upload Images 1. Upload files with extensions like .jpg, .jpeg, .gif, .png, .bmp).
2. Upload files with extensions like .jPg, .JpeG, .GIf, .pNg, .bmP).
3. Upload files with extensions like .JPG, .JPEG, .GIF, .PNG, .BMP).
4. One thing we have to keep in mind while testing files uploading that we also should have to test files with long names.

Note: I had received the server error when uploading with long file name while functionality was working file with small filename. Also I received the server error when used .JPG, but application was working fine with extension .jpg.

Spiral Model

The spiral model gives more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase.

Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Advantages

a. High amount of risk analysis.

b. Good for large and mission-critical projects.

c. Software is produced early in the software life cycle.

Disadvantages

a. Can be a costly model to use.

b. Risk analysis requires highly specific expertise.

c. Project’s success is highly dependent on the risk analysis phase.

           d. Doesn’t work well for smaller projects.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Advantages

a. Simple and easy to use.

b. Each phase has specific deliverables.

c. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.

d. Works well for small projects where requirements are easily understood.

Disadvantages

a. Very rigid, like the waterfall model.

b. Software is developed during the implementation phase, so no early prototypes of the software are produced.

c. Model doesn’t provide a clear path for problems found during testing phases.

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.

 

Requirement (Diagram)

a. Design

b. Implementation & Unit Testing

c. Integration & System Testing

d. Operation

 

Advantages

a. Simple and easy to use.

b. Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.

c. Phases are processed and completed one at a time.

d. Works well for smaller projects where requirements are very well understood.

 

Disadvantages

a. Adjusting scope during the life cycle can kill a project

b. Poor model for complex and object-oriented projects.

c. Poor model for long and ongoing projects.

d. Poor model where requirements are at a moderate to high risk of changing.

Black Box testing

Black Box testing refers to the technique of testing a system with no knowledge of the internals of the system. Black Box testers do not have access to the source code and are oblivious of the system architecture. A Black Box tester typically interacts with a system through a user interface by providing inputs and examining outputs without knowing where and how the inputs were operated upon. In Black Box testing, target software is exercised over a range of inputs and the outputs are observed for correctness.

Advantages

a. Efficient Testing — Well suited and efficient for large code segments or units.
b. Unbiased Testing — clearly separates user's perspective from developer's perspective through separation of QA and Development responsibilities.
c. Non intrusive — code access not required.
d. Easy to execute — can be scaled to large number of moderately skilled testers with no knowledge of implementation, programming language, operating systems or networks.

Disadvantages

a. Localized Testing — Limited code path coverage since only a limited number of test inputs are actually tested.
b. Inefficient Test Authoring — without implementation information, exhaustive input coverage would take forever and would require tremendous resources.
c. Blind Coverage — cannot control targeting code segments or paths which may be more error prone than others.

White Box Testing

White Box Testing refers to the technique of testing a system with knowledge of the internals of the system. White Box testers have access to the source code and are aware of the system architecture. A White Box tester typically analyzes source code, derives test cases from knowledge about the source code, and finally targets specific code paths to achieve a certain level of code coverage. A White Box tester with access to details about both operations can readily craft efficient test cases that exercise boundary conditions.

Advantages

a. Increased Effectiveness — Crosschecking design decisions and assumptions against source code may outline a robust design, but the implementation may not align with the design intent.
b. Full Code Pathway Capable — all the possible code pathways can be tested including error handling, resource dependencies, and additional internal code logic/flow.
c. Early Defect Identification — Analyzing source code and developing tests based on the implementation details enables testers to find programming errors quickly.
d. Reveal Hidden Code Flaws — access to source code improves understanding and uncovering unintended hidden behavior of program modules.

Disadvantages

a. Difficult To Scale — requires intimate knowledge of target system, testing tools and coding languages, and modeling. It suffers for scalability of skilled and expert testers.
b. Difficult to Maintain — requires specialized tools such as source code analyzers, debuggers, and fault injectors.
c. Cultural Stress — the demarcation between developer and testers starts to blur which may become a cultural stress.
d. Highly Intrusive — requires code modification has been done using interactive debuggers, or by actually changing the source code. This may be adequate for small programs; however, it does not scale well to larger applications. Not useful for networked or distributed systems.

Difference B/w Error, Bugs, Defect, Fault & Failure

Error: Errors are basically the deviation from the requirement, caught by testers and caused by misunderstanding of the Developers.

Bug: If the Error found by testers are accepted as error by Developers. Then the error will called Bug.

Defect: Suppose any product/software is currently running as a beta version in the market/client side. Any issue currently caught in that application that are deviating the actual result from the requirement, will taken as Defect.

Fault: When the product/software successfully launched in the market and running properly but due to any reason if it works unexpectedly is called Fault.

Failure: If the product fails to full fill the requirement, then it is called Failure.