Assignment – 1

1. What are Software practices? Explain the phases in SDLC?

2. List different Software Engineering Tools and explain each of them?
3. Explain different Software Engineering Methods?
4. What is SRS? Explain the requirements classification?
5. What are functional and Nonfunctional requirements explain in detail?
6. Briefly explain the benefits of Requirement Management tool?
7. Write the selection criteria for choosing Requirement Management tool?
8. What is traceability? How do you generate traceability report using ReqView tool?
9. How does enterprise architecture support business goals and strategy?
10. Why is the enterprise architecture so important? What stakeholder groups would be
involved in the Enterprise Architecture lifecycle?
11. What are the architectural domains of TOGAF?
12. How the TOGAF creates importance as a skeleton for enterprise architecture?
13. What are the steps involved in Architecture Development Method (ADM)?
14. What is Version Control System? Explain types of Version control system in
detail?
15. What is GIT? Explain the advantages of using GIT?
16. What is “Staging Area” or “Index” in GIT? Explain them in detail
17. What is the difference between ‘git remote’ and ‘git clone’?
18. What is the difference between the ‘git diff ’and ‘git status’?
19. Why is it advisable to create an additional commit rather than amending an existing
commit?
20. What is repository? Name a few Git repository hosting services?
21. What is build tool? Explain the need for build tools? Give some examples
Assignment -2
1. What is Automation
Testing?
2. Why should Selenium be selected as a test tool?
3. What is Selenium? What are the different Selenium components?
4. What are the testing types that can be supported by Selenium?
5. What are the limitations of Selenium?
6. What is the difference between Selenium IDE, Selenium RC, and WebDriver?
7. What are the different types of locators in Selenium?
8. What the difference is between assert and verify commands?
9. How do I launch the browser using WebDriver?
 10. What are the different types of Drivers available in WebDriver?
11. What are the different types of navigation commands?
12. What is TestNG and how is it better than Junit?
13. What is white box testing and list the types of white box testing?
14. What is black box testing? What are the different black box testing techniques?
15. What are the different test levels?
16. What Test Plans consists of?
17. What is the difference between UAT (User Acceptance Testing) and System
testing?
System Testing:
System Testing is done to check whether the software or product meets the specified
requirements or not. It is done by both testers and developers. It contains the Tastings:
System testing, Integration Testing. It is done through more positive and negative teat
cases.
Acceptance Testing:
Acceptance Testing is done after the system testing. It is used to check whether the
software meets the customer requirements or not. Acceptance testing is used by testers,
stakeholders as well as clients. It includes only Functional Testing and it contain two
testing Alpha Testing and Beta Testing.
S.NO SYSTEM TESTING ACCEPTANCE TESTING

System testing is done to check Acceptance testing is the type of testing

whether the software or product meets which is used to check whether the software
1. the specified requirements or not. meets the customer requirements or not.

System testing is used by developers Acceptance testing is used by testers,

2. as well as testers. stakeholders as well as clients.

System Testing is both functional and

3. non-functional testing. Acceptance testing is only functional testing.

System Testing is the constitute of Acceptance testing is the constitute of alpha

4. System and integration testing. and beta testing.

System testing is done before the Acceptance testing is done after the System
5. Acceptance testing. testing.

System testing is the constitute of Acceptance Testing is the constitute of

6. positive as well as negative test cases. positive test cases.

In system testing, system is checked In acceptance testing, system is checked for

7. for dummy inputs. random inputs.
18. What is the difference between test scenarios, test cases, and test script?
Test Scenarios:  A Test Scenario is any functionality that can be tested. It is also called Test
Condition or Test Possibility.
Test Cases:  It is a document that contains the steps that has to be executed, it has been
planned earlier.
Test Script:  It is written in a programming language and it's a short program used to test part
of functionality of the software system. In other words a written set of steps that should be
performed manually.

19. Explain what Test Deliverables is?

What is a deliverable ?
A deliverable is a product or outcome that is given to the client. A deliverable can be
a software product, a design document, or any other asset that is required.
Test Deliverables :
Test Deliverables are the artifacts which means “things” that are produced by people
involved in the process and are given to the stakeholders. Some deliverables are
provided before testing phase, Some during the testing phase and rest after the testing
cycle. The below are the list of test deliverables.
 Test Specifications document
 Test Plan document
 Test Strategy
 Test Scenarios document
 Test Design standards
 Test Case document
 Traceability matrix
 Test execut
 ion reports
 Test logs
 Bug reports
 Test summary reports
 Test Data
 Flow document
 Test Metrics
 Test Status reports

20. What all things you should consider before selecting automation tools for the AUT?
Here are some things to consider when selecting an automated testing tool:
1.) Platforms, Technology and Types. Whether you're testing . ...
2.) Tester Skills. ...
3.) Feature-Rich. ...
4.) Manual and Automatic. ...
5.) Change Management. ...
6.) Results Management. ...
7.) Collaboration. ...
8.) Data In, Data Out

1.) Platforms, Technology and Types            

Whether you’re testing .Net, C#, or WPF applications, Windows-based or relying on the
LINUX kernel, your automated testing tool must support these systems and technologies.
Comprehensive automated testing tools that support unit, functional (or UI), regression,
data-driven, manual and distributed testing of Windows applications exist, so why not use
an integrated solution? Look for flexibility and support for unit tests created in NUnit,
JUnit, DUnit, and MSTest.
 
2.) Tester Skills           
The bench strength within any given QA department can vary considerably, and you need
to take into account the skill levels your team has. Can your tests write automated test
scripts or will they need help? Is keyword testing part of the process? If so, how well can
the automated testing applications you’re looking at handle those tasks? Your testers may
have a wide range of skills, a narrow set of skills, or something in-between with gaps here
and there. Choose an automated testing application compatible with the skill-set your QA
team needs.
 
3.) Feature-Rich       
No matter where you are in the application lifecycle, one thing is clear, the app will only
get more sophisticated; it will only have more features, not less, as the application lives on.
Choose an automated testing tool that is feature-rich to keep up with the development
lifecycle and the challenges that each new waterfall release or iteration is certain to bring.
Look for the ability to implement checkpoints to verify values, databases, or key
functionality in your applications.
 
4.) Manual and Automatic                     
Look for automated testing tools that support record-and-playback test creation and manual
creation options.
 
5.) Change Management   
Over time, it's certain that some changes will need to be made in the application’s user
interface (UI). Choose automated testing tools that won’t break down and fail when the UI
changes. You want an automated testing tool that is easily maintained and whose tests can
be reused as long as possible.
 
6.) Results Management     
You want to be able to see the results of your testing clearly. Logs, dashboards, and other
instrumentation that automatically records and logs report results make managing the
testing process smoother and more effective from start to finish.
 
7.) Collaboration   
The ability for testers to share their work and have developers and other colleagues share
theirs too is invaluable. Look for automated testing applications that can support concurrent
work with project files, sharing script code among several projects and integration with
source code control and issue-tracking systems.
 
8.) Data In, Data Out               
Data sources and the venues to which you need to provide data are in constant flux. Look
for an automated testing tool that can provide reports in XML+HTML, Excel, and MHT.
The ability to intake data from multiple sources, such as text and XML files, Excel
worksheets , and databases, like SQL Server, Oracle, and MySQL, also make the tool more
valuable.
Prepare a list of the capabilities and features you’d like to have in your automated testing
tool. Identify which are “must-haves” and which are “nice-to-haves.” Leave a little space
on the list for the stuff you’ll soon discover along the way but you don’t know you want
yet.

21. How will you conduct Risk Analysis?

You do a Risk Analysis by identify threats, and estimating the likelihood of those threats
being realized. Once you've worked out the value of the risks you face, you can start
looking at ways to manage them effectively. This may include choosing to avoid the risk,
sharing it, or accepting it while reducing its impact.
While a test plan is being created, risks involved in testing the product are to be taken into
consideration along with possibility of their occurrence and the damage they may cause
along with solutions; if any. Detailed study of this is called as Risk Analysis.

Some of the risks could be:

- New Hardware
- New Technology
- New Automation Tool
- Sequence of code delivery
- Availability of application test resources
- Identify and describe the risk magnitude indicators: High, Medium and Low

High magnitude means the effect of the risk would be very high and non-tolerable.
Company may face severe loss and its reputation is at risk. Must be tested.

Medium: tolerable but not desirable. Company may suffer financially but there is limited
liability or loss of reputation. Should be tested.
Low: tolerable. Little or no external exposure. Little or no financial loss. Company’s
reputation unaffected. Might be tested.

Three perspectives of Risk Assessment: Effect, Cause and Likelihood.

- To assess risk by Effect, identify a condition, event or action and try to determine its
impact.
- To asses risk by Cause is opposite of by Effect. Begin by stating an undesirable event or
condition and identify the set of events that could have permitted the condition to exist.
- To asses risk by Likelihood is to determine the probability that a requirement will not be
satisfied.

22. Explain what Test Plan is? What is the information that should be covered in Test
Plan?
A TEST PLAN is a detailed document that describes the test strategy, objectives,
schedule, estimation and deliverables and resources required for testing. Test Plan helps us
determine the effort needed to validate the quality of the application under test. The test
plan serves as a blueprint to conduct software testing activities as a defined process which
is minutely monitored and controlled by the test manager.

23. What are the important steps that are covered in Functional testing?
What is Functional Testing?

FUNCTIONAL TESTING is a type of software testing that validates the software system
against the functional requirements/specifications. The purpose of Functional tests is to test
each function of the software application, by providing appropriate input, verifying the
output against the Functional requirements.

Functional testing mainly involves black box testing and it is not concerned about the
source code of the application. This testing checks User Interface, APIs, Database,
Security, Client/Server communication and other functionality of the Application Under
Test. The testing can be done either manually or using automation.

What do you test in Functional Testing?

The prime objective of Functional testing is checking the functionalities of the software
system. It mainly concentrates on -

 Mainline functions:  Testing the main functions of an application

 Basic Usability: It involves basic usability testing of the system. It checks whether
a user can freely navigate through the screens without any difficulties.
 Accessibility:  Checks the accessibility of the system for the user
 Error Conditions: Usage of testing techniques to check for error conditions.  It
checks whether suitable error messages are displayed.

How to perform Functional Testing: Complete Process

In order to functionally test an application, the following steps must be observed.

  Understand the Software Engineering Requirements
 Identify test input (test data)
 Compute the expected outcomes with the selected test input values
 Execute test cases
 Comparison of actual and computed expected result

24. Explain the difference between Functional testing and Non-Functional testing.
Functional Vs Non-Functional Testing:
Functional Testing Non-Functional Testing

Functional testing is performed using the functional Non-Functional testing checks the  Perform
specification provided by the client and verifies the system scalability and other non-functional aspects
against the functional requirements. system.

Functional testing is executed first Non-functional testing should be performed

testing

Manual Testing or automation tools can be used for functional Using tools will be effective for this testing
testing

Business requirements are the inputs to functional testing Performance parameters like speed, scalabi
non-functional testing.
 Functional testing describes what the product does Nonfunctional testing describes how good

Easy to do Manual Testing Tough to do Manual Testing

Examples of Functional testing are Examples of Non-functional testing are

 Unit Testing  Performance Testing

 Smoke Testing  Load Testing
 Sanity Testing  Volume Testing
 Integration Testing  Stress Testing
 White box testing  Security Testing
 Black Box testing  Installation Testing
 User Acceptance testing  Penetration Testing
 Regression Testing  Compatibility Testing
 Migration Testing
 

25. How is ‘Build’ different from ‘Release’?

A “build” is given by dev team to the test team. A “release” is formal release of the
product to its customers.

A build when tested and certified by the test team is given to the customers as “release”. A
“build” can be rejected by test team if any of the tests fail or it does not meet certain
requirements. One release can have several builds associated with it.
26. What are the important points that should be considered while writing Test Cases?
When writing test cases for your project, it’s often easy to forget what is important. This
article is aimed at reminding experienced testers or informing new ones of what the key
items are, to ensure we are being efficient in writing our tests.
The End User is key
Who will be executing the test scripts? Will the scripts form part of a Regression Pack?
Will the scripts be used for anything else (e.g. training manuals)?
These questions are meant to kick start your thought process. Essentially, the person who
writes the test is not always the person who executes it. As such, Test Cases need to be
written so that anyone of any level can read, understand and be able to execute the test
case. The aim of this is that no matter the level of the tester, the outcome will always be the
same. When writing your test, if you approach this with ‘baby-steps’ in mind and make no
assumptions that the person who executes it is has any prior knowledge of the project, and
you shouldn’t go far wrong. 
Unique, Measurable, Specific (UMS)
Every single test case should be Unique, Measurable and Specific. If you aren’t quite clear
what this means, I’ve defined this below for you.
  Unique – There should only be one test with a particular objective in the scenario
you are writing it for.
 Measurable – You should be able to say at the end of the test whether it has passed
or not. The objective should be very clear and each Input and Expected Output
should marry up concisely.
 Specific – Each test case must be written to test a particular function or action. A
good test case is usually brief and to the point.
Where possible, keep test cases reasonably short. A long number of test steps can add
complexity to the scenario, it can make the tester feel like they’ve been executing the same
test forever and it can affect the accuracy of progress and defect reporting. Break your test
scripts down into smaller scenarios if possible and although this will mean more test cases,
they will be quicker to execute and will produce more accurate statistics of test results.
Data
The inclusion of data in your test steps can be very useful. It saves time and energy
sourcing the test data. It makes test execution more efficient.
Before you do this though, you need to understand a few things. Can the data go out of
date? Is a database refresh likely to occur? If the data is likely to change however it may be
easier to create a database or reference sheet to store your test data in one place. This
means that if you need to change the data, you can do it in one place rather than have to
trawl through your test cases to make the change individually. 
Test Case Layout
Test Management tools often cater for the information which should go into a test case by
providing fields for testers to enter the details which need.
Those who have completed their ISTQB Foundation course will know that IEEE829 states
that the following should be included in a Test Case:

 Test Case Specification Identifier

 Test Items
o Describe features and conditions tested
 Input Specifications
o Data Names
o Ordering
o Values (with tolerances or generations procedures)
o States
o Timing
 Output Specifications
o Data Names
o Ordering
o Values
o States (with tolerances or generations procedures)
o Timing
 Environmental Needs
o Hardware
 o Software
o Other
 Special Procedural Requirements
 Inter-case Dependencies
Consider the approach
You may also need to consider using different approaches, dependant on the delivery
methodology being used and to ensure your test scripts are maintainable. Using a
Behaviour Driven Development (BDD) approach for your test scripting makes it easier to
automate your test scripts at a later date, enabling the automation team to pick up your
manual BDD scripts and convert them in to code. BDD scripts are also usually written
from an end users perspective, which helps if the scripts are to be reused for UAT - saving
valuable time and effort.