Selenium Software Testing Tool-The Best Software Course

Selenium Software Testing Tool

  • Selenium IDE is a Firefox plug-in that can be used to automate web testing. Note that this plug-in works only in Firefox.
  • Selenium WebDriver is a robust and browser-based automation tool that can be used to execute regression test suits across different browsers, test phases and test environments.
  • Selenium IDE is a Firefox plug-in that can be used to automate web testing. Note that this plug-in works only in Firefox.
  • Selenium WebDriver is a robust and browser-based automation tool that can be used to execute regression test suits across different browsers, test phases and test environments.
  • IT companies leveraging automation testing tools to reduce software testing cost. And, being Selenium widely used tool across many IT companies hence it would create plenty of job opportunities if someone is full verse with this tool.
  • Selenium is the easiest way to get started with web site testing because as it requires no need of previous programming experience.
  • Compatible with widely used languages such as Java, C#, Python 2 and Ruby. This way a wide range of programmers and testers can develop the test scripts using Selenium IDE.
  • Ease of use in developing different version of test cases from the base version. Eg: Start record and play the app that is under test, copy and paste the record & play version code into any word doc then update the base version code to develop different version of test cases such as ‘code base’ or web driven test cases etc. This way you can maximize the testing power with Selenium IDE.
  • With one of the Selenium feature called XPath locators, one can easily develop and execute accurate GUI, content based tests such as on Help pages. Basically, XPath locators is used to find elements in a webpage. Manually validating help pages is very time consuming and more over it is high prone to overlook the defects within Help pages.
  • Cross-browser and regression testing friendly because of ease in running same test suit across multiple browsers and test phases without major test suit updates. This saves a lot of time and effort while doing mundane tests.
  • Programmers who follows white-box testing techniques because Selenium can help them to execute test faster and efficiently by quickly validating page elements such as broken links etc within the web page before QA test phase.
  • Testers can leverage Selenium to validate GUI, help contents, data dictionary and many more using Selenium IDE tool.
  • Freelancer testers.

Software Testing Interview Questions

This page contains frequently asked software testing interview questions asked in university examinations and job interviews. Click on each hyper linked question below to see the answer.

Software testing interview questions – Manual testing Questions:

1. What is Regression Testing?
 2. What is meant by Deferred? 
3. Which testing model is your company using?
4. What is meant by V-Model and Explain?
5. What is meant by Software Test Life Cycle?
6.  Explain Bug Life Cycle
7. What is Retesting?

8. What are different kind of bugs? Classify the different kinds of bugs and explain.

Software testing interview questions-Automation Testing  Questions:

1. What is meant by feasibility of application?
2. Which automation framework is your company using?
3. Explain about Automation Testing Process.
4. What is smart identification?
5. What is meant by ordinal identifier?
6. What is virtual object?
7. When do you go for automation testing?
8. Difference between Test Objects and run time objects
9. What is mean by Data driven, Keyword driven and Modular driven frameworks?
10. How will you retrieve the test data?
11. What is meant by Object Repository?
12. Difference between per action and shared action repository
13.What is meant by Synchronization?
14. What is meant by environment variable and types?
15. What are the methods and properties in Web button?
16. Explain about keyword driven and hybrid framework.
17. In how many ways we can add the objects in object repository?
18. What are different versions in QTP? And which version is your company using?
19. Write a script for excel object?
20. What is mid function?
21. What is split function?
22. What is checkpoints?
23. What is environment variable?
24. What is built environment variable?

Software testing interview questions-Domain Specific Questions:

1. Difference between Online Banking and Retail Banking?
2. What is debit and credit?

What is Boundary Value Analysis Testing?

Boundary Value Analysis testing is a software testing technique used to validate application functionality while processing boundary conditions. Also, we can consider that this is one of the Software Testing Techniques available in Black Box testing

This is one of the most effective software testing techniques to find defects.

Boundary Value Analysis Testing with Example:  We will see how Boundary Value Testing is used to test below requirement

Requirement: Risk assessment team in a credit card department of a bank requires to monitor payments when each transaction of an amount greater than or equal to Rs 1, 000, 00 is made more than or equal to 2 times in a day

The above requirement is developed technically as below

  1. All credit card transactions for a day are captured in a mainframe file called dataset2. Dataset above as in step 1 is loaded daily into a database table called credit card transactions
  2. A COBOL program is developed which picks up the data from database table ‘credit card transactions’ to create a report called ‘Risk Assessment Report’ in showing a transaction of amount greater than or equal to Rs 1, 000, 00 is made more than or equal to 2 times in a day
  3. Risk assessment team reviews the ‘Risk Assessment Report’ daily for transactions as specified in the above requirement

QA Test approach will be as below to test this requirement:

We must make sure the report is created with the specific amount and number of transactions as mentioned in the requirement. So, in this case it is appropriate to use Boundary Value Analysis testing technique to test this requirement.

Test Approach or Mainframe Test Approach: In QA testing we must simulate the steps 1 to 4 like in real time environment as mentioned above to make sure right transactions are captured in ‘Risk Assessment Report’

  1. First we have to create a mainframe file called dataset. In this file, we have to update the boundary value conditions like below
  2. a) First boundary value condition in the dataset:   Amount == Rs 1, 000, 00 and Number of Transactions == 2 times.

Expected Result: Boundary value conditions on ‘Amount’ and ‘Number of Transactions’ ensures that this transaction is captured in ‘Risk Assessment Report’ for Risk assessment team to review the file.

b) Second boundary value condition in the dataset:   Amount == Rs 2, 000, 00 and Number of Transactions == 2 times

Expected Result: Boundary value condition on ‘Number of Transactions’ ensures that this transaction is captured in ‘Risk Assessment Report’ for Risk assessment team to review the file.

c) Third boundary value condition in the dataset:   Amount == Rs 1, 000, 00 and Number of Transactions == 3 times

Expected Result: Boundary value condition on ‘Amount’ ensures that this transaction is captured in ‘Risk Assessment Report’ for Risk assessment team to review the file.

3. After creating data set with boundary value conditions as in step 1, load the dataset into a database table credit card transaction

4. Run the mainframe job which in turns executes a COBOL program to create ‘Risk Assessment Report’

5. Now QA team must verify if all the expected boundary value conditions discussed above in 1 a), 1 b) and 1 c) are captured in the ‘Risk Assessment Report’

 

Software defects priority

Software Defects Priority can be classified into four categories as i stated below:

Priority 1 – Resolve Immediately:

Example: User unable to launch ‘Funds Transfer’ page in a Banking application. When user clicks on ‘Funds Transfer’ button from Banking application home page the ‘Technical Problems’ or ‘Page Not Found’ displayed to the user.

In this example software tester should report the defect as Severity 1 or Showstopper because the system/application under test is out of service. In other words there is no work around or not usable to use the system/application unless the developer fix the defect for further usable.

In this case software tester should deem this as a top priority or Priority 1 defect to resolve immediately.

Priority 2 – High Attention:

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully but the ‘Complete Transfer’ button not clickable to initiate funds transfer.

In this example software tester should report the defect as Severity 2 or Critical because the major function of the system/application under test not working. In other words the intent of the application functionality is not usable and no workaround exists to use the application functionality unless the developer fix the defect for further usable.

In this case software tester should deem this as Priority 2 or High Attention defect to resolve the defect at the earliest.

Priority 3 – Medium:

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully and ‘Complete Transfer’ button is clickable to initiate funds transfer. But the application allows to transfer the money upto $1000 and not more than $1000. As a workaround user has to initiate funds transfer 2 times in order to transfer $2000 with each transfer of $1000.

In this example software tester should report the defect as Severity 3 or Medium because major function of the system/application under test not working but there is a temporary workaround exists to use the system.

In this case software tester should deem this as Priority 3 or Medium because this defect may be considered acceptable by the business to proceed to production and address as a post production issue.

Priority 4 – Low:

Example: Cosmetic issues in the ‘Funds Transfer’ page like spelling mistakes, page format issues.

In this example software tester should report the defect as Severity 4 or Minor because whenever components of the application are not functioning to specification but the situation is manageable i.e fix can be instituted in a future release.

In this case software tester should deem this as Priority 4 or Low because this defect may be considered acceptable by the business to proceed to production and address as a post production issue.

 

Software defects severity

Software Defects Severity can be classified into four categories as i stated below:

  • Severity 1 which is also called as Showstopper. Software tester should report the defect as Severity 1/Showstopper whenever the system/application under test is out of service. In other words, there is no work around or not usable to use the system/application unless the developer fix the defect for further usable.

Example: User unable to launch ‘Funds Transfer’ page in a Banking application. When user clicks on ‘Funds Transfer’ button from Banking application home page the ‘Technical Problems’ or ‘Page Not Found’ displayed to the user.

  • Severity 2 which is also called as Critical. Software tester should report the defect as Severity 2/Critical whenever major function of the system/application under test not working. In other words, the intent of the application functionality is not usable and no workaround exists to use the application functionality unless the developer fix the defect for further usable.

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully but the ‘Complete Transfer’ button not clickable to initiate funds transfer.

  • Severity 3 which is also called as Major. Software tester should report the defect as Severity 3/Major whenever major function of the system/application under test not working but there is a temporary workaround exists to use the system.

Example: User able to launch ‘Funds Transfer’ page in a Banking application successfully and ‘Complete Transfer’ button is clickable to initiate funds transfer. But the application allows to transfer the money up to $1000 and not more than $1000. As a workaround user has to initiate funds transfer 2 times in order to transfer $2000 with each transfer of $1000.

  • Severity 4 which is also called as Minor. Software tester should report the defect as Severity 4/Minor whenever components of the application are not functioning to specification but the situation is manageable i.e fix can be instituted in a future release.

Example: Cosmetic issues in the ‘Funds Transfer’ page like spelling mistakes, page format issues.

 

Measuring software quality assurance team performance

We know that performance of developers is measured based on number of defects detected in developed.  But how to measuring software quality assurance team performance. Learn more here

  • No defects should be injected into subsequent phases:Here injecting means putting defects because of making mistakes while doing work. In Quality Assurance context injecting defects means missing defects to find while testing. This also known as defect injection.

Example:

a) In Stage 1 testing tester finds 5 defects. These defects are fixed and retested in stage 1. Now the code is promoted to stage 2 for clean run expecting no defects in stage 2.

b) But the tester finds brand new defects say 3 in stage 2 which supposed to be finding in stage 1, so the tester injected 2 defects into stage 2 due to not performing well in stage 1 testing.

  • Zero rejection defects:
    Rejected defects indicates that the defects created for developer investigation is not invalid i.e due to lack of knowledge on application functionality tester has created incorrect test cases which caused to create invalid defects. Also, these invalid defects caused developers to waste time on investigation.
  • No QA Effort Variance:
    It is impossible to get 0% effort variance i.e Actual effort will not be equal to planned effort. Acceptable effort variance will depend upon organization standards. For example, acceptable effort variance for an organization is + or – 20%, so if effort variance is beyond + or – 20% then it will be considered as effort variance. Again, the management should conduct root cause analysis to conclude if effort variance is due to quality assurance performance issues.

Software Retesting

From Software Testing perspective, software retesting involves following two set of tasks:

  • Retesting the defect to confirm the issue associated with the defect resolved successfully (or simple to say Defect Retest)
  • Retesting the failed test cases associated with the defect

Note that retesting is different from regression testing. Scope of retesting limited to failed test cases associated with the defect while regression testing involves testing the similar/relevant functionality associated with the functionality under question (or having an issue/defect).

 

Software Defect Life Cycle

In a Software Defect Life Cycle, software defects will undergo following states:

  1. New: This is the default state when Defect is created.
  2. Rejected: Defect has been evaluated and deemed not valid because of a triage session.
  3. Open: Defect has been reviewed and is waiting to be assigned
  4. Need More Info: The assignee (usually Development Lead or Developer), who has determined that more information is needed, returns the defect to the issuer.
  5. Assigned: Defect has been assigned to a team member for resolution by test lead.
  6. Analysis: Defect is being analyzed.
  7. Repair: Defect is being fixed.
  8. Fixed: Defect has been resolved by the assignee and is waiting to be included in a build for re-test.
  9. Deferred: Defect has been deemed not immediately required for production and will be reviewed for a future release of the project.
  10. Pending Management Decision: Defect has been analyzed and deemed to require decision from management before any action can be taken.  Response from management is required before moving forward with Defect.
  11. Ready for Re-Test: The configuration management team has received this fix in a build request and the Defect has been applied to the test environment and is ready to be re-tested.
  12. Monitor: Defect has been identified as possibly incidental in nature.  Defect issue will be monitored for a set period to determine if it occurs again for moving forward with any resolution.
  13. Re-Open: Defect did not pass a test case after being fixed.
  14. Closed: Defect has been resolved and validated; it is no longer a problem.

What is meant by Software Defects?

The prime objective of a code developer is to write the code for creating a software while software tester prime objective is to find defects or bugs in the developed software. Now let’s see what is meant by software defects or software bugs.

Software defect or bug: The software functionality which is not in accordance with requirement specification documentation is called software defect or bug.

Type of defects: Defects are categorized based on the root cause on how they occur. The different types of defects are

  • Coding defects: The requirements have been coded incorrectly due to which behavior of an implemented software function is not in accordance with the requirement specification documents.

The other frequently occurred defects made by developers are due to

  1. Missed to code for the requirements which listed in requirement specification document
  2. Coding the requirements which are not specified in the requirement specification document

These types of defects are usually caused by developer’s oversight.

Example:

Requirement as per specification document: If user clicks on ‘Home’ link in a website then ‘Home’ page should be presented to the user.

Tester observation while testing the ‘Home’ link:  Tester found that ‘About Me’ page is displayed each time the ‘Home’ link is clicked which is a deviation in the behavior from the requirement specification document. This is an example of coding defect.

  • ‘Missing requirement’ defects:  A valid requirement which is mandatory and supposed to code (or implement) is missed. The root cause of this defect is due to not capturing this requirement in the specification document. These types of observations are categorized as ‘Missed requirements defects’ since the requirements are missed from requirement specification document.

These types of defects are usually caused by business analyst’s oversight.

Example:

Tester observation while testing the Website:  Tester found that ‘Disclaimer’ link is missing in the website. According to organization/webmaster guidelines it is mandatory to show ‘Disclaimer’ link in the website so tester expressed his/her concern that the ‘Disclaimer’ link is missing and to fix this developer expects the business analyst to document in requirement specification document.

  • ‘New requirement’ defects:  A requirement which is not in project scope to code (or implement) but later on it was determined that is mandatory to code (or implement) to address potential failures in the production (or after implementation).

These types of defects are usually caused by poor requirement analysis for scoping in assessing potential failures.

Example:

Requirement as per specification document:  System A transmits data to system B for data processing in system B.

System A: Transmits student records (records contain marks of each student) to system B

System B: Responsible for

  • Filter student records who gained more than 80 % passed marks in the examination
  • Process filtered student records to pass this information to the scholarship department

Tester observation while conducting system integration testing:  Tester found that data is not getting loaded in system B and on further investigation it is found that the root cause is memory constraints i.e system B fails to load data whenever system A transmits of more than 100000 student records.

To address this defect the project stakeholders decided to create additional (or new) requirement. So, the additional (or new) requirements are created as below in specification document.

System A: Transmits student records (record contains marks of each student) to system C

System C: This system is optimized to process (or handle) large volume of data i.e in this case system filter student records who gained more than 80 % passed marks in the examination and send to system B for further processing.

System B: Process filtered student records to pass this information to the scholarship department

Software Test Life Cycle

Software Test Life Cycle is the sequence of test activities that needs to be completed to test software. All related test activities are grouped called phases and each phase in a testing life cycle should be completed successfully.

Test Activities in Test Life Cycle:

Test Activities in Test Life Cycle are as follows:

  • Test Planning
  • Test Design
  • Test Data Preparation
  • Test Environment Setup
  • Test Execution
  • Evaluate Exit Criteria
  • Test Signoff

Integrating Software Test Life Cycle into Software Development Life Cycle:

The sequence of Software Test Life Cycle activities differs from each SDLC model to SDLC model.

  1.  Software Test Life Cycle activities inWaterfall Model:

Software development activities are performed in sequence to build software. The most important characteristic of a waterfall model is that entire system is built at once i.e all identified functions of software are released into production at once.

The different phases of waterfall model are as follows:

  • Requirement Analysis
  • System Design
  • Software Development
  • Software Testing
  • Implementation
  • Maintenance

The output of each phase is an input to subsequent phases as below:

  • System design phase activities should start only when requirements are identified and freezed in Requirements Analysis phase.
  • Software development phase activities should start only when system design activities are completed and signed off.
  • Software testing phase activities should start only when software development activities are completed and signed off.
  • Implementation phase activities should start only when software testing activities are completed and signed off.
  • Maintenance phase activities will occur only when Implementation is completed.

Challenges in waterfall model:

  • High probability of requirement changes while development is in progress
  • Frequent requirement changes causes to rework and delay in implementation
  • Cost overhead due to frequent requirement changes and rework

How to overcome waterfall software development life cycle model challenges?

Waterfall software development life cycle model challenges can be handled by integrating software test life cycle process into this waterfall model. Please note that software test life cycle integration is not a complete solution to overcome waterfall software development life cycle model challenges. The software test life cycle process integration into waterfall software development life cycle model helps to resolve challenges as follows:

Requirement changes and rework can occur due to

  • Defect Injection from one phase to the subsequent phases

Example: Requirement defects injected at requirement analysis phase can creep into subsequent phases and     causes to build incorrect software

  • Technical challenges encountered while coding the software and this can lead to requirement change

To prevent above challenges, we need to find as many defects as possible at beginning of the life cycle i.e at requirement analysis phase. This can be achieved by incorporating software test life cycle activities as early as possible.

Given the challenges and nature of the activities in waterfall model we can use V-Model as a software test life cycle model. The testing activities in V-Model progress in parallel with development activities. Test activities in V-Model are as follows:

Requirement Analysis ———- User Acceptance Testing

Design ——————-System Testing

Coding- ————Unit Testing

As shown in above figure for every development activity there is a corresponding testing activity so the V-Model aids in finding defects and technical challenges as early as possible in the life cycle to reduce rework, cost overhead and frequent requirement changes.

2. Software Test Life Cycle activities in Iterative or Incremental Life cycle model:

As opposed to waterfall model, software developed is chunks in this model.  Functions are grouped called chunks and each chunk is implemented or released into live on incremental basis. Example of this model is Agile where each chunk is called sprint. The objective of each sprint is to develop a chunk of software and released accordingly in live environment.

The phases of Iterative or Incremental model looks like as below

Iterative 1

  • Chunk 1 Requirement Analysis
  • Chunk 1 Design
  • Chunk 1 Coding
  • Chunk 1 Testing
  • Chunk 1 Implementation

Iterative 2

  • Chunk 2 Requirement Analysis
  • Chunk 2 Design
  • Chunk 2 Coding
  • Chunk 2 Testing
  • Chunk 2 Implementation

Likewise Iterative n

  • Chunk n Requirement Analysis
  • Chunk n Design
  • Chunk n Coding
  • Chunk n Testing
  • Chunk n Implementation

The complete product with all features will be in live after Iterative n.

The objective of testing in this model is to test each chunk before implementation. The sequences of test activities are as below.

Iterative 1

  • Chunk 1 Test Planning
  • Chunk 1 Test Design
  • Chunk 1 Test Data Setup
  • Chunk 1 Environment Setup
  • Chunk 1 Test Execution
  • Chunk 1 Exit Criteria
  • Chunk 1 Test sign off

Iterative 2

  • Chunk 2 Test Planning
  • Chunk 2 Test Design
  • Chunk 2 Test Data Setup
  • Chunk 2 Environment Setup
  • Chunk 2 Test Execution
  • Chunk 2 Exit Criteria
  • Chunk 2 Test sign off

Likewise Iterative n

  • Chunk n Test Planning
  • Chunk n Test Design
  • Chunk n Test Data Setup
  • Chunk n Environment Setup
  • Chunk n Test Execution
  • Chunk n Exit Criteria
  • Chunk n Test sign off

Regression testing plays a key role in addition to functional testing in this model. As software is developed and implemented in chunks so testing team should ensure that each chunk’s functionality should not be broken while development of each chunk is in progress.

Regression testing is quite challenging in this model as duration of each Iteration is small. Automation tools can be used to overcome this challenge.