jump to navigation

Recent Questions asked in any Software Testing Interview June 19, 2008

Posted by kiranjoglekar in : General Interview Questions , add a comment

1)How do you know which software with version (ex.msoffice)
   available in our system, using tsl functions? 

GUI-get_name returns the type of GUI for the application under test.
GUI_get_name ( out_name, out_version );
out_name: An output variable that stores the name of the current GUI.
out_version: An output variable that stores the current version of the GUI.

 

2)Write the Test Cases for ATM (any time money)?

TC 1:- Check successful card insertion.
TC 2:- Check unsuccessful operation due to invalid account card.
TC 3:- Check the LCD screen display is readable.
TC 4:- Check to see if Welcome message is given when user logs in.
TC 5:- Check successful entry of pin number.
TC 6:- Check unsuccessful operation due to wrong pin number entered 3
            times.
TC 7:- Check successful selection of language.
TC 8:- Check successful selection of account type.
TC 9:- Check unsuccessful operation due to wrong account type.
TC 10:- Check successful selection of withdrawal option.
TC 11:- Check successful selection of amount.
TC 12:- Check unsuccessful operation due to wrong denominations.
TC 13:- Check successful withdrawal operation.
TC 14:- Check unsuccessful withdrawal operation due to amount
             greater than possible balance.
TC 15:- Check unsuccessful due to lack of amount in ATM.
TC 16:- Check unsuccessful withdrawal operation due to amount greater
              than the day limit.
TC 17:- Check unsuccessful withdrawal operation due to server down.
TC 18:- Check unsuccessful operation due to click cancel after insert card,
              language selection, account type selection, withdrawal selection,
              enter amount etc.
TC 19:- Check the card ejects the card once transaction is done. (This is 
              for some ATMs that suck the card into the machine)
TC 20:- Check the machine prints a receipt once transaction is done.

 

3)Write the Test Cases for Traffic Signals?
 
TC 1:- Check the signal has 3 coloured-Red, Yellow & Green light.
TC 2:- Check the first “Red” should be on, then “Yellow” and then “Green”.
           (Based on the duration set)
TC 3:- Check that only one light glows at a time.
TC 4:- Check that only one green light is On at a time on signal.

 

4)Explain how do we find duplicate defects?

     Duplicate Defects means the same type of defects that are present in
defferent places of application becouse of copy, paste operation of code
during the code development process.
For example if you take one application it has 9 screens. But the 9 screens
have some identical properties/features. The developpers will write a piece
of code then this code will be copied and used wherever they need. During the process of Test case execution if we find any bug we used to enter the
failure result in test case and we assign a bug id for that. We know that we used to write test case such that for each and every functionality there must be at least one test case. If we find the bug for first time we enter the bug description in defect report and we assign a bug id. If we fined the same bug again already entered bug will be present in the test case result column.

 

5)What are the contents RTM (Requirements Traceability Matrix)? 

Normally RTM is an simple excel sheet with the following columns:
1. Requirement ID 
2. Requirements description  
3. High Level Design (HLD)  
4. User Documentation  
5. Unit Test Case Id 
6. Integration Test Case Id 
7. System Test Case Id 
8. Release / Build Number

Requirement ID will be present in the SRS document. RTM is matrix of test
case id’s of each level of  testing.   Whenever  we write test case that test
case ID must be entered into RTM. During the Review process the reviewer
will look at the RTM for checking the testcases completeness against the
requirements. 

 

URGENT HIRING for Storage professional contract position for 6 months. June 17, 2008

Posted by kiranjoglekar in : Uncategorized , add a comment

Experienced engineer who has in depth knowledge in SAN 9980, Net App, IBM 3200, 3400 and Adaptec devices.
This contract position would be on the customers site for approx. 6 months.
Send your resume to roger.smithson@gmail.com immediately as this is immediate hiring requirement.

AN storage located on the same 9980 frame noted above, backed up using
Beta Systems Rapid Exchange product to MF Tape
Separate 9960 frame configured as SAN storage for the Part D program
Net Backup system with single cabinet Tape silo using LTO 2 drives,
using external Decru encryption device
Various smaller SAN/NAS components eg. Net App, IBM 3200, 3400 and Adaptec devices

Responsibilities :
 Manages the SAN, backup and restore environments and
requirements at the receiving data center for the migration
groups

Recommended Previous Experience :
3 years previous experience with data migration,
scripting and documenting standard procedures 
Working knowledge and understanding of clients internal
processes and tools such as; NSR, GCARS, OAR, NetEiss and the procurement process
Has at least 2 years participation experience with
SRT/RCA activities
Has working technical knowledge (3 years minimum) of
the migrating storage technologies in scope of the
Transformation, including storage management software
(Backup, SAN & NAS)
At least 3 years previous experience with the
following; replication projects, resolution of connectivity
and performance issues.
Demonstrated ability to provide technical guidance to
other technical resources in area of expertise

Send your resume to roger.smithson@gmail.com immediately as this is immediate hiring requirement.

Basic Questions asked in any Software Testing Interview June 3, 2008

Posted by kiranjoglekar in : General Interview Questions , add a comment

1. What is Testing?

   Testing  is  a  process  of  finding  the  bugs or defects in the software,
   reporting it & making sure that the bugs are fixed by the development.
   Once  the  development  fixes the reported bugs, again Testing team is
   responsible  to  verfiy the fixes & making sure that the new fix has not
   broken any previously working functionality of the product.

 
2. What is a Defect or a Bug?

   A defect or a bug is a mistake in the software considering the details
   mentioned  in  the  specification  document.  So  if  some  feature or
   functionality of a Software is varying  from what it is supposed to be
   with  regard  to  its  expectations  mentioned  in  the  Specification
   documents then it is considered as a bug or a Defect.

 
3. What will you do when you find a Defect in the product that
   you are Testing ?
 
   Generally  when we find a bug or defect we report it following the bug
   logging  process  or  Defect  Reporting.  But  it  is  also  the  job  of  a
   Testing Engineer to make sure it is a real product bug & not any setup
   or testcase issue before filing a Defect Report or Bug Logging.

 
4. How do you log a bug & what software you use for this
    process?

   We use Bugzilla which is an opensource software for logging bug. While
   logging  a  bug  we  need to give detailed information about  the  whole
   steps when we encountered a bug or defect.

 
5. Describe in detail what you should do after Finding the Bug?

   Write the bug report just when you are sure that you have found a bug,
   not  after  the  end  of  test  or at  the  end  of  the  day.   It  might  be
   possible  that  you  might miss out on many crucial points  if  you are
   delaying the write up for bug filing.  Put necessary  time  to  diagnose
   the defect you are reporting. Think of the possible causes. You might
   land  up  uncovering  more   defects  if  there  are  any.  Mention  your
   discoveries in your bug report.  The  programmers  will only be happy
   seeing that you have made their job easier. Take some time off before
   reading your bug report. You might feel like re-writing it.

 
6. What are the factors you consider while writing Defect
   Summary or Bug Synopsis ?

   The summary of the bug report is the readers first glance  with  your
   bug report.  The  fate  of  your  bug heavily depends on how well you
   compress yet describe the summary of your bug  report.  The  rule  is
   that  every  bug  should  have  a  one  line  summary  some reporting
   softwares  call it  as Bug Synopsis.  A good summary will not be more
   than 50 to 60 characters.

Keep reading for more common Testing Questions & Their Answers.