Showing posts with label types of bugs. Show all posts
Showing posts with label types of bugs. Show all posts

Thursday, March 13, 2008

FAQ - Manual ( 31 to 40 )

31. How many test cases can you write an average for a day?


There is no measurement for writing the test cases avg for a day. That depends on functionality. If the functionality is critical we can write just 5 to 10 test cases otherwise

We can write 60 to 70. In this way the average for day is 30-35.


32. What does buddy testing mean?


Due to lack of time for testing, test engineer grouped with programmer to conduct testing as early as possible. Buddy means a group with programmer and tester. It is a type of ad-hoc testing


33. What are the difference bug, error, and defect?


Bug : Discrepancy in the application functionality


Error : Mistakes in coding


Defect : Deviations from the requirements


34. When the relationship occurs between tester and developer?


Developer is the one who sends the application to the tester by doing all the necessary code in the application and sends the marshal id to the tester. The tester is the one who gives all the input/output and checks whether he is getting required output or not. A developer is the one who works on inside interfacing where as the tester is the one who works on outside interfacing


35. Write 5 negative test cases for pen?


1. Throw the pen at a Wall and try Write in again.

2. Hold the Pen in the upward direction for 5 mins and try writing in.

3. Do not use the pen for 10 days and then try writing up.

4. Throw the pen in the water and then write up again.

5. Expose the pen to the heavy weather conditions and try writing up with the same.


36. What are the contents of FRS?


Function Behaviors Requirements (Outputs) of the System that is defined.

Specification (How, What, When, Where, and Way it Behaviors.

Function Requirement Specification.

This is a Document, which contains the Functional behavior of the system or a feature. This document is also known as EBS External Behaviors Specification-Document or EFS External Function Specification


37. Give me some example for high severity and low priority defect?


High severity:

Eg: Calculation bugs

Low priority:

Returning float with single decimal point with rounding the value instead of two decimal points can be treated as low severity.

Eg: Expected: 77.77

Actual: 77.8



38. What is the Difference between Web Application testing and Client Server testing ?


In both Tests we perform Load and Performance Testing. Testing the application in intranet (without browser) is an example for client-server. (The company firewalls for the Server is not open to outside world. Outside people cannot access the application.) So there will be if limited number of people using that application.

Testing an application in Internet using browser is called web testing. The application which is accessible by numerous numbers around the world (World wide web). So testing web application, apart from the above said two testing there are many other testing to be done depending on the type of web application we are testing. If it is a secured application (like banking site-we go for security testing etc.) If it is a commerce testing application we go for Usability Testing


39. Explain about Bug life cycle?


1) Tester->2) open defect->3) send to developer 4)->if accepted moves to step5 else send the bug to tester gain 5) Fixed by developer->6) regression testing->7) no problem in Built and signoff 8)->if problem in built reopen the issue Send to step3


40. What are the common defects revealed in Functionality Testing?


Page not found (Error 404)

Server not found

Page Errors

FAQ - Manual ( 21 to 30 )

21. What is the purpose of “check-in”,” check-out”?


CHECK IN:

If we want to modify our documents then that is check-in process


CHECK OUT:

We go for check out so that no other user can modify our documents. The document is set as read mode option.


22. Testing methodology means


The process of testing of s/w application in different situations, phases and on different types of applications some Methodologies are

* Adhoc Testing

* System Testing

* Functional Testing

* Security Testing

* Performance Testing

* Usability Testing

* User interface Testing

* Portability testing

*Multibrowser compatibility testing

* Installation testing

*Integration testing

*Sanity Testing

*Retesting

*Regression Testing

*End to end Testing., etc


23. What is the need of testing? Give three reasons.


The need of testing is to find out errors in the application.

The good reasons of testing are

1) Quality Assurance
2) Verification and validating the product/application before it goes live in the market.
3) Defect free and user friendly.
4) Meets the requirements.

24. Explain the Different types of Bugs ?


* Missing functionality

* User interface bugs

* Boundary related bugs

* Calculation bugs

* Race conditions (hanging of system because of dead lock)

* Version control bugs, etc


25. How do you know the test cases writing completed?


By using TRM (means Traceability requirement matrix) we can know the how many of the test cases are covered and how many of test cases are not covered.


26. What is test summary report and it content?


Overall testing status

Number of module tested

Number of bugs identified


27. What are the different test deliverables?


There are different test deliverables at every phase of the SDLC. These deliverables are provided based on the requirement once before the start of the test phase and there are other deliverables that are produced towards the end/after completion of each test phase. Also there are several test metrics that are collected at each phase of testing. Below are the details of the various test deliverables corresponding to each test phase along with their test metrics

The standard deliverables provided as part of testing are:

* Test Trace-ability Matrix

* Testing Strategy

* Test Plan

* Test Cases (for functional testing)

* Test Scenarios (for non-functional testing)

* Test Scripts

* Test Data

* Test results

* Test Summary Report

* Release Notes

* Tested Build


28. What is a non functional requirement used in Ur project


Non functional requirements are color, text box alignment etc


29. What is the difference between sanity testing and smoke testing?


Sanity testing: Sanity testing is testing the application to ensure, if it is stable enough to continue further testing. If the test fails, we cannot continue testing further. Sanity testing is the initial test after the build release. The QA team does it.


Smoke testing: is done by the developers, to ensure that the build is ready for release to the testing team, does this.

Explaining in detail ….

Smoke testing is done to verify that the build (to be tested) is done properly. (The build is a new / updated version of software). The motive is to check that the application build is working fine and does not crash.

For example – say an application has following features – (say each feature has a page, so in this case there are 10 features; so its 10 pages)
Login, Logout, Enter info, delete info, update info, Change address, search records, retire records, print form, generate reports etc…

Here's how you will Smoke Test it -
Check that each of the pages is displayed properly and there are no broken links between pages.
Check that the buttons on the pages are clickable (not disabled or hidden).
Check that you can traverse back and forth between pages.
Check that you can see the help section pages, legal and disclaimer section on the pages (outgoing links on the pages)
Check the look and feel of the pages (fonts and user text boxes displayed properly and no broken images or cluttered text or font scramble) – this is optional check unless you see something that is unreadable
Check that you are able to enter info into input boxes (no need to do any transactions; just check whether you are able to input text on the pages or not).

Note that you are not required to do any transactions in Smoke test. In other words you are not testing the functionality of the application but the application build itself.

Sanity Testing – is done to verify whether the new / updated build is functioning properly. (Note the difference – smoke checks the application build; sanity checks the build functionality at higher level.)

Take the above example again – say an application has following features –
Login, Logout, Enter info, delete info, update info, Change address, search records, retire records, print form, generate reports etc…

Here's how you will Sanity Test it -
Check that the customer critical functionality is working by performing at least one transaction for each of the major features.

Your depth of sanity testing depends on the functionality of the application. Say there are 5 major features of that application. So you need to perform only one transaction for each of the feature (to verify that all the major features are working properly).

(Sanity test concentrates on testing major features. A feature is said to be major if it is accessed by customer frequently or daily and its working is important to the business. )

Now say the login, logout, enter info, delete info and generate records are the 5 main features on the application.

Sanity test -
Check that you are able to login
Check that you are able to logout
Check that you are able to enter the info and save record for new user.
Check that you are able to delete data of existing user.
Check that you can generate report for current date.

You don't need to test rest of the features. Nor do you require to run other exhaustive test cases for each of these major features.

Note that you just have to check that the basic functioning of the major features is working. Don't run end to end and multiple operation test cases in sanity.


30. Can you explain about defect life cycle?

Defect Life Cycle:


Initially, when the tester identifies/reports a defect the status is NEW by default. The tester Forwards the defect to team lead .The team lead reviews the defect to determine whether or not to consider it for repair. If the defect is not accepted then the status is REJECTED, if the defect is accepted for repair the status is OPEN. The team leader forwards the defect for repair to the development team with priority (very, high, high, medium, etc). The concerned developer repairs the defect and changes its status to FIXED. The tester retest the defect to make sure it does not recur. If the defect doesn't recur the status is CLOSED or if the defect recurs the status is RE-OPENED and the cycle repeats.

1. NEW

2. OPEN

3. FIXED

4. CLOSED