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
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
No comments:
Post a Comment