Wednesday, May 23, 2012

Testing Interview Questions


1. Differentiate between QA and QC?
QA:
      It is process oriented
      It involve in entire process of software development.
      Prevention oriented.
QC:
     It is product oriented.
     Work to examine the quality of product.
     Deduction oriented.

2. What is a bug?
A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result.

3. What is a test case?
Test case is set of input values, execution preconditions, expected results and execution
Post conditions, developed for a particular objective or test conditions, such as to exercise a particular program path or to verify compliance with a specific requirement.



Test Plan Template Doc


The below list is not intended to limit the extent of the test plan and can be modified to become suitable for the particular project.
The purpose of the Test Plan is to achieve the following:
·        Define testing strategies for each area and sub-area to include all the functional and quality (non-functional) requirements.
·        Divide Design Specifics into testable areas and sub-areas (do not confuse with more detailed test spec).  Be sure to also identify and include areas that are to be omitted (not tested) also.
·        Define bug-tracking procedures.
·        Identify testing risks.
·        Identify required resources and related information.
·        Provide testing Schedule.

The purpose of usability testing is to ensure that the new components and features will function in a manner that is acceptable to the customer. 
Development will typically create a non-functioning prototype of the UI components to evaluate the proposed design.  Usability testing can be coordinated by testing, but actual testing must be performed by non-testers (as close to end-users as possible).  Testing will review the findings and provide the project team with its evaluation of the impact these changes will have on the testing process and to the project as a whole.


Friday, May 4, 2012

FREQUENTLY ASKED QUESTIONS

1.   What are the entry and exit points in test plan?
A: Entry point of test plan is - that functional description to be tested and required procedure is the exit point.
2.   What is the use of “swing time” in Load runner?
A: Elapsed time indicates swing time (to determine the performance of the application under load)
3.   What is internationalization?
A: It means that following standards. Ex: ISO/CMM/Six Sigma.
4.   What are the different functions in win runner?
A: Analog functions, Context Sensitive functions, Customization functions, Miscellaneous and Standard functions.
5.   What are the testing’s involved in black-box testing?
A: Acceptance testing, stress testing, user-interface, regression, performance, Potential bugs, Bea test, release test, utilities.

MANUAL TESTING DEFINATIONS

1.Quality: - It is defined as the conformance to the customer specification.

2.Testing: - A Tester should suppose to identify the defects.

3.White box testing: -Based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths, conditions.

4.Test case: - Test case is a description of what to be tested, what data to be given and what actions to be done to check the actual result against the expected result.

5.Black box testing: - Not based on any knowledge of internal design or code. Tests are based on requirements and functionality.

6.Functionality testing: - Testing whether the functionality of the application is working or not and whether all the requirements have covered are not.

7.System testing: - The entire application tested according to the requirements.

8.Sanity testing: - Initial testing conducted on the application to check the proper behavior on the application.
9.Smoke testing: - Initial testing is conducted on over all application to check whether all the functionalities available to conduct detail testing on them.

10.Regression testing: - Retesting the bug after fixing or any modifications or enhancement done to the application and testing whether the existing functionalities are effecting to the privies functionalities or not.

11.Integration testing: - All the modules are integrated together and testing how modules are couple together and communication between the modules.

12.Usability testing: - Checking whether it is user friendliness or not.
i.      To check for the look and feel of application.
ii.  Where the end user can understand and can easily use the application.
13.User acceptance testing: - After all the bugs are fixed we have to test once again to make shore that the application meets the user requirements.

14.Severity: - how much the bug is effecting the application.

15.Priority: - When the bug is to be fixed.

16.Unit testing: - After completion of their reviews, programmer concentration on coding, to physically construct a soft ware. In this level, their will test every program through white box testing.

17.Recovery testing: - It is also known as reliability testing during this test, testing engineers validates that whether our application build change from abnormal state to normal state or not.

18.Compatibility testing: - It is also known as portability testing. During this test, testing engineer validates that whether our application build run on customer expectation platform or not.

19.Configuration testing: -It is also known as hardware compatibility testing. During this test testing engineer validates that whether our application support different technology hardware devises or not.

Monday, April 23, 2012

Top 10 Tips For Testing iPhone Applications

1 Accurately report available memory. 
Many of the non-reproducible bugs you run into when testing iPhone apps are related to memory problems. 
It's critical that you know and report available free memory before launching an application. 
In all likelihood, the reproducibility of a crashing iPhone app bug is related to low memory conditions. 
Consequently, a crashing defect may disappear when there's plenty of free memory.
In a previous article (Using Memory Sweep for iPhone App Testing) we described a tool that can be used to determine free memory.

2 Provide 'crash reporter' logs with your defect reports.
Each time an iPhone application crashes, a .crash file is created on your iPhone. 
You can retrieve this file when you synch your iPhone with iTunes. 
Here's a link that describes where those files are stored: iPhone Crash Logs

            3 Spy on the app from the console
iPhone apps will report application and system level warnings to the console.
You can view these warnings in real-time using Apple's iPhone Configuration Tool
By knowing what's being reported when interacting with an app can help you refine the steps you need to reproduce tricky (and memory related) problems.

        4 Test under low memory conditions
This relates to #1 above.  You'll be able to tease additional crashing bugs if you force free memory to a very low level, e.g. < 2MB, before proceeding with your tests. 
One way to do this is to open several Safari windows before you start your testing.

            5 Screenshots, screenshots, screenshots.
Nothing makes a UI bug stand out for a developer than when you send screenshots. 
And with the iPhone's built-in screen capture, there's no excuse not to do this.

6  Provide useful defect characterization information.
Developers always like to have help in their debugging process, and useful defect characterization helps them narrow down the root cause of a bug. 
If a crash happens under low memory conditions (see #1 and #4 above), then try it under conditions where there's lots of memory available, e.g. >40MB.  If a problem occurs under iPhone OS 2.2.x, then try it under 3.x.

            7 Create connectivity problems.
If you're testing an iPhone app that depends on internet connectivity, then test for degraded or unavailable connectivity.
It's easy to make connectivity unavailable by simply turning on Airplane Mode.
To degrade connectivity, especially on Edge or 3G, employ some sort of metallic "shield" on top of your iPhone.

            8 Boundary test data input.
Wherever an iPhone app asks for text input, you have an opportunity to find a bug. 
My favorite technique for this is to copy a huge amount of text, then paste it into each text field. 
You'd be surprised at how this trips up some apps.
Additionally, we’ve been finding that application errors are generating when entering the following characters into text fields: !@#$%^&*()_.
(Note: Holding down letters (A, E, I, O, etc) or symbols ($, !, &, etc) on the onscreen keyboard generates a keyboard popup that includes localized and 2-byte characters. These should also be entered into text fields.)

            9 Gather up UDIDs (unique device identifiers) early
This is a simple logistics task but seems to be one that becomes critical as the first build approaches.
And it's a hassle for the dev team to add new UDIDs and create new provisioning files as each new person wants to install an application during development. 
Get the UDIDs of all know devices that will be used during testing and set a cut-off date for the addition of any new devices. 
Check out Find UDID with a single click. You can also connect all your iPhones and iPods touches to your computer and use the iPhone Configuration Tool to collect UDIDs.

10  Employ background applications.
But the iPhone can only have one application running at a time, right? That's true for those of us that develop and test applications, but not for Apple. 

Applications that continue running in the background on the iPhone are Safari, iPod and Mail. 
And what about reminders and push notifications?  These "interrupters" can affect the behavior of an application under test.
Also, since iPhones and iPod touches are devices that users buy primarily to use as a phone or a music player, it’s important to test that an app can gracefully handle situations where the user receives a call or plays music from their music library (iTunes) while the app is running. We’ve seen issues here where apps aren’t smoothly multi-functioning in these areas.