Answer- Functional testing is a form of black-box testing. As the name suggests, it focuses on the software’s functional requirements rather than its internal implementation. A functional requirement refers to required behavior in the system, in terms of its input and output.
It validates the software against the functional requirements or the specification, ignoring the non-functional attributes such as performance, usability, and reliability.
Functional testing aims to answer the following questions, in particular:
Does the software fulfill its functional requirements?
Does it solve its intended users’ problems?
Question-42. What is non-functional testing?
Answer- Non-functional testing tests the system’s non-functional requirements, which refer to an attribute or quality of the system explicitly requested by the client. These include performance, security, scalability, and usability.
Non-functional testing comes after functional testing. It tests the general characteristics unrelated to the functional requirements of the software. Non-functional testing ensures that the software is secure, scalable, high-performance, and won’t crash under heavy load.
Question-43. What is a bug report?
Answer- During testing, a tester records their observations, findings, and other information useful to the developers or the management. All this data belongs to a test record, also called a bug report.
A detailed bug report is an important artifact produced during testing. It helps the team members with:
Understand the problem,
Steps to reproduce the problem,
The environment and the specific conditions under which it happens, and
The resolution if/when the developers fix the problem.
Here are a few bits of information that a good bug report should contain. Image Source: Bugzilla
Field
Description
Title
A short headline that summarizes the problem. It shouldn’t be too long but just to give just the right information to the reader. It should be specific and accurate.
Description
The description should answer all the questions that are not explained by the title. It contains a detailed summary of the bug, its severity, and impact, steps to reproduce, expected results vs. the actual output.
Version
A lot of time can be wasted in trying to reproduce a bug in the wrong version of the product. Knowing the exact product version or the build number on which this bug was found is very useful to the developer in reproducing the bug.
Status
At any point, a bug can be either ‘Active’, ‘Ready for Testing’, or ‘Closed’. A bug becomes active when it is found, is ready for testing once the developer fixes it. A tester can mark it closed if the developer fixed it, or active if not.
Steps to Reproduce
Though the steps to reproduce the problem can be provided in the description, sometimes having a distinct field force the tester to think about them. They include each step one must take to successfully reproduce the problem.
Assigned To
Name of the developer or the tester to whom this bug is assigned.
Resolution
When a developer fixes the bug, they should include the cause for the bug and its resolution. It helps the team in the future when a similar bug resurfaces.
For example, here is a picture of a bug reported on Jira, a popular bug-tracking software.
Question-44. What are some important testing metrics?
Answer – Testing metrics provide a high-level overview to the management or the developers on how the project is going and the next action steps.
Here are some of the metrics derived from a record of the tests and failures:
Total number of defects found, ordered by their severity
Total number of bugs fixed
Total number of problems caused by an error in the source code vs. configuration or external environmental factors
Bug find and fix rate over time
Bugs by produce/feature area
The average time is taken by a bug since it’s found and fixed.
Total time spent on new feature development vs. time spent on resolving bugs and failures
Number of outstanding bugs before a release
Bugs/failures reported by the customers vs. those found by the testers
Question-45. What is Test-Driven-Development?
Answer- Test-Driven-Development (TDD) is a popular software development technique, first introduced by Kent Beck in his book with the same name, published in 1999.
In TDD, a developer working on a feature first writes a failing test, then writes just enough code to make that test pass. Once they have a passing test, they add another failing test and then write just enough code to pass the failing test. This cycle repeats until the developer has the fully working feature. If the code under the test has external dependencies such as database, files, or network, you can mock them to isolate the code.
Benefits of TDD:
Writing tests first forces you to think about the feature you are trying to build, helping you produce better code.
As you always have a working set of tests at hand, a failing test indicates that the problem is with the code you just added, reducing the time spent in debugging.
Writing tests help the developer to clarify the requirements and specification. It’s challenging to write good tests for a poor set of requirements.
It’s tough to produce high-quality software unless you can test the software after each new change. You can never be sure that your new code didn’t break the working software. TDD gives you the confidence to add new code, as you already have a test in place.
Question-46. What is Selenium? What are its benefits?
Answer- Selenium is a web browser automation tool that automates the test suits you need to run on a web browser.
Some of the benefits of Selenium include:
It is open-source software, eliminating licensing costs.
It supports all the major languages, such as Java, C#, Python, Ruby, etc.
It supports all the major web browsers, e.g., Google Chrome, Firefox, Safari, etc.
You can integrate it with other testing frameworks and tools to build a comprehensive test suite for your software.
Question-47. What are the various components of Selenium?
Answer- Selenium consists of the following components:
Selenium Remote Control (RC).
Selenium Integrated Development Environment (IDE).
Selenium WebDriver.
Selenium Grid.
Question-48. What is cross-browser testing?
Answer- All web applications run in browsers such as Google Chrome, Mozilla Firefox, Internet Explorer, Safari, etc. Though they all work primarily the same in implementing the web standards, there are subtle differences in all of them. When building the software, it’s not always possible for the software developer to meticulously test the feature on multiple browsers, noticing the subtle inconsistencies.
In cross-browser testing, a software tester launches the web application in all the supported browsers and tries to test the same functionality on all of them. They note any unexpected behavior in a browser that doesn’t work as expected or looks different; note the behavior and the browser name and version in the test report. This helps the programmer to fix the behavior in all the browsers where it doesn’t work as intended.
Question-49. What are the different HTTP status codes that a server can return?
Answer- An HTTP status code is a three-digit number that indicates the status of an incoming HTTP request, that is, if the request has been completed or not.
A server can send the following five types of responses for an HTTP request.
Information (100 – 199): These status codes provide a temporary response. The response consists of the status line and optional headers and terminates by an empty line.
Success (200 – 299): Indicate that the incoming HTTP request was successfully received, understood, and accepted.
Redirect (300 – 399): These status codes indicate further actions the client should take to satisfy the HTTP request. It can mean that the requested resource may have moved temporarily or permanently. It can also redirect the client to another URL.
A client error (400 – 499): Indicate a problem with the client who initiated the HTTP request.
Server error (500 – 599): The 5XX status code indicates a problem on the server while processing the request.
Question-50. What is automated testing?
Answer- As the name suggests, automated testing, which is also called test automation, is the programmatic execution of the tests. The tester uses an automation tool or software like Selenium to write code that performs the following tasks.
Automatically run the software.
Feed the input data to the system.
Examine the output with the expected outcome.
Fail the test if the results don’t match. Otherwise, pass the test.
Once a test is automated, you can run it as often as you want, to check if any new code has broken it. It enables you to spend your time on other high-value tests, such as exploratory testing that help find bugs that an automated test would miss.
Automated testing is beneficial for repetitive testing with inputs that don’t change frequently. Humans get tired and bored from conducting the same tests repeatedly and seeing the same results. It’s easy to make mistakes when you are testing a feature for the twentieth time. Software is much better at doing repetitive tasks without getting tired or making mistakes than a human operator would.
