Quick Learn :: Code Review v/s Code Walkthrough v/s Code Inspection :: MCQ

Code Review v/s Code Walkthrough v/s Code Inspection :: MCQ

Click here to get Text book contents.   Inspection, Walkthrough, Technical Review

Download Unit 1 Notes  Software testing unit 1

Download Unit 2 Notes Software testing unit 2

Download Unit 3 Notes Software testing unit 3

Scroll Down to access MCQ’s

Editors help authors catch errors. It’s human nature not to be able to proofread one’s own work effectively. To fulfil the aims of the software organization, software authors require the same assistance as novelists.

Creating software solutions is a mathematically repetitive process carried out by big teams of people from various backgrounds. That said, programmers are human, and no matter how much expertise they have, there is always the possibility that they will make a few mistakes here and there.

To avoid potential quality issues, software organizations require different ways to check their source code to check for inconsistencies that can lead to severe problems if left unchecked. This can be done in many ways:

  • Code Review
  • Pair Programming
  • Code Inspection
  • Code Walkthrough
  • Technical Review

The most sought-after methods are Code Review, Code Inspection, and Code walkthrough.

This blog will explain and compare these three review methods in detail.

Code Review 

In the software development life cycle, code reviews are a stage where programmers carefully verify each other’s code for errors, odd formatting, or discrepancies with system requirements that could cause more severe issues during software integration. It is the systematic study of computer source code, sometimes known as peer review.

How do Code Reviews work?

In general, the review process evaluates four key areas:

  1. Code issues
  2. Formatting consistency with the overall software design.
  3. Quality of documentation
  4. Compliance with coding standards and project specifications.

After a developer completes work on an issue, another developer reviews the code and thinks about topics like:

  • Are there any evident logical errors in the code?
  • Are all scenarios fully implemented based on the requirements?
  • The new code has been put through new automated tests; are they sufficient?
  • Is it necessary to rewrite existing automated tests to accommodate code changes?
  • Is the new code consistent with existing style guidelines?

The reviewers should be entirely disconnected from the project under review, as this maximizes impartiality and guarantees the code is legible and maintainable even by those who are unfamiliar with the project. Typically, reviewers will use a standard checklist to identify common errors and validate the code to the company’s coding standards.

Why are code reviews done?

Code review is especially beneficial for identifying security flaws. Specialist application packages can aid this approach. Automated code review simplifies the process of evaluating source code for vulnerabilities such as buffer overflows, race conditions, memory leaks, size violations, and duplicate statements. Another common application of code review is testing.

Code reviews should be integrated into an organization’s existing process.

For Example — A code review should be started if a team uses task branching processes after all the code has been produced and all the automated tests have been run and passed before the code is merged upstream.

By doing this, the primary development stream is shielded from bad coding mistakes, and the code reviewer’s time is devoted to looking for things machines miss.

Brief history

In the 1970s, Michael Fagan started publishing several papers for IBM on software inspections for the Waterfall approach, which helped establish code review as a common practice.

The Fagan Inspection was a process developed by Fagan in which developers engaged in a formal meeting with four primary steps: initialization, preparation, discussion, and corrections.

While approaches have changed in response to evolving technology and development methodologies, the core goal of code reviews has remained the same. Analyzing the source code as a team fosters a sense of collective responsibility for the software’s advancement.

Advantages of Code Review

Code reviews offer many significant advantages, such as:

  1. Improvement of code quality — Code reviews improve code quality by finding problems before they become unmanageable and enforcing consistent standards. This results in powerful software composed of components for seamless integration and functionality.
  2. Promotes Knowledge Transfer— The regular study of source code enables programmers to pick up more dependable methods and best practices.
  3. Supports teams in improving documentation— Code reviews also assist teams in creating better documentation, making it easier for developers to add new features and upgrade current ones in the future.
  4. It simplifies QA testing— Another advantage of having uniform standards is easier-to-understand source code for specialists and testers.

Code Inspection

Code inspection is the most formal evaluation. It is static testing used to prevent flaw amplification later in the process. The primary purpose of code inspection is to find defects, but it may also reveal potential process improvements.

The findings are documented in an inspection report containing metrics for improving the process. It can correct errors in the document under review. Thorough preparation is essential before the meeting, including reviewing source materials to ensure consistency.

Inspections help software products be more dependable, accessible, and maintainable.

How does Code Inspection work?

Participants in inspection activities follow a predetermined process and have clear duties to play.

An inspection team comprises three to eight people who serve as moderators, authors, recorders, readers, and inspectors. A designer, for example, can serve as an inspector during code inspections, whereas a quality assurance representative can serve as a standard enforcer.

  • Planning — The moderator plans the inspection. The inspection team is given relevant materials, and after that, the team schedules the inspection meeting and works together.
  • Overview meeting — The author gives the inspection team members a brief summary of the project and its code if they are unfamiliar with it.
  • Preparation — After that, each inspection team conducts a code inspection using a few inspection checklists.
  • Inspection meeting — During this meeting, the reader goes through the work output, section by section, and inspectors point out any flaws.
  • Rework — The author modifies the work output following the inspection meeting’s action plans.
  • Follow-up — Hold a meeting with the team after the code inspection to discuss the reviewed code.

Why are code inspections done?

  • It looks for any software code errors that might be present.
  • It indicates any necessary process improvements.
  • It determines if the coding standard has been adhered to or not.
  • It lists the errors found in the software code.
  • Codes are peer-reviewed in this process.

Advantages of Code Inspection

  • Enhances the overall product quality.
  • Finds the flaws/bugs in the program code.
  • In any event, it shows a process improvement.
  • Rapidly and effectively locates and removes faults.
  • Aids in learning from past failures.

Disadvantages of Code Inspection

  • It takes more time and planning.
  • The procedure is slower.

Code Walkthrough

A walkthrough is a methodology for doing informal solo or group reviews. In a walkthrough, the author describes and explains his work product to his peers or supervisor in a casual gathering to receive comments. Here, the feasibility of the suggested work product solution is examined.

A walkthrough is a static way of ensuring quality. It is less expensive to make modifications when the design is on paper rather than when it is being converted. Walkthroughs are casual but purposeful sessions.

How does Code Walkthrough work?

Code walkthroughs are a type of peer review. The code’s author often leads a meeting attended by other team members.

A few team members usually are provided a copy of the code a few days before the meeting. The author offers the document under review while the attendees manually run test cases against the code. Members of the team may also ask the author any pertinent questions.

All attendees share and discuss their individual results with the author.

Guidelines for performing code Walkthrough

  • The code walkthrough team should be a manageable size. It should ideally be made up of three to seven individuals.
  • The discussion does need to center on finding flaws rather than how to correct them.
  • Managers should refrain from attending code Walkthrough sessions to promote teamwork and avoid the perception among engineers that they are being evaluated.

What are the Goals of the Code Walkthrough?

The explicit goal of the code walkthrough is determined by its function in the document’s creation.

In general, the below goals are applicable in most cases:

  • To deliver the document to stakeholders inside and outside the software discipline, usually to obtain information about the subject it addresses.
  • To create a shared understanding of the documents.
  • To describe and assess the documents’ contents.
  • To investigate, debate, and agree on the plausibility of proposed solutions and alternatives.

Advantages of Code Walkthrough

  • Walkthrough offers a variety of viewpoints.
  • The primary goal of the code walkthrough is to equip team members with information about the substance of the document under review.
  • It raises awareness of the document’s content while also revealing problems.

Disadvantages of Code Walkthrough

  • Completeness is confined to the areas where the team raises doubts.
  • The code walkthrough lacks diversity, with the author driving the process and others validating that what has been said matches what has been done.
  • It results in a lack of depth.
  • Meetings can be time-consuming and difficult to arrange when different time zones separate participants.

Summary

#

Code Review

Code Inspection

Code Walkthrough

1. It can be a formal (Fagan Inspection) or informal process (Peer Review). It is a formal process. It is an informal process.
2. Initiated by the project team. Initiated by the project team. Initiated by author.
3. Code review is typically carried out as a peer review including associates and professional specialists. The inspection is carried out by a group of relevant personnel from several departments. Typically, walkthroughs are attended by team members from the same project. The author leads the walkthrough.
4. It is the systematic study of computer source code. Each phase has a formal method. There is no formal procedure in the phases.
5. A code review takes longer since the checklist items are checked off as they are completed. An inspection takes longer since the checklist items are checked off as they are completed. No formal checklist is used to evaluate the code, the walkthrough takes less time.
6. Sessions are planned with fixed responsibilities allocated to all participants. Sessions are planned with fixed responsibilities allocated to all participants. Unplanned

 

When to use Code Review, Code Inspection or Code Walkthrough? 

  • Code Review — This method can be helpful when you need to do a systematic review without planning a pre-determined structure. Usually, this can be performed as an over-the-shoulder review, when a senior developer reviews the new script offering suggestions and feedback, as an open conversation between team members. Code review becomes particularly handy in distributed teams; here, you can use remote collaborative tools to emulate the same exchange of ideas in an office setting. The most popular option for distributed teams is the email pass-around method. Typically, a developer uses version control systems with automatic notifications to email the updates to the development team. This kind of email initiates a discussion about the modifications. Next, team members might suggest modifications, point out errors, or request explanations. But as remote collaboration technologies grow, this approach is becoming more and more integrated with other software.
  • Code Inspection — This method should be implemented when you need to verify the product’s compliance with specified requirements and standards. It is done by looking through the development and comparing it to the designs, code, artifacts, and other available documentation. In order to ensure that inspections are held correctly, it is necessary to plan appropriately and perform overviews of the preparation. Many preparations are required, meetings are arranged to conduct inspections, and then rework is completed in accordance with the inspection’s feedback. Inspection is a procedure that should be carefully considered by a company that cares about the product’s quality. The quality control division should be responsible for handling the process.
  • Code Walk-through — This method can be implemented when there isn’t much need to maintain compliance or standards. Defect tracking in walk-throughs is inconsistent and informal and does not require prior preparation. A group of peers hears the author’s developed item. Peers probe and critique the item to find as many defects as possible. The audience need not prepare in advance. Typically, minimal documentation of the procedure or any emergent concerns is required.

 

 CC-307 Software Testing  MCQ

  • Unit-1,2,3 Covered from Software Testing By Naresh Chauhan
  • Unit-4 Covered from Software Testing By Srinivasan Desikan

 

Unit-1 [Chapter-1, 2]

Chapter-1

  1. Bug discovery is a _______ goal of software testing.

(a) Long-term

(b) Short-term

(c) Post-implementation

(d) All

 

  1. Customer satisfaction and risk management are _______ goals of software testing.

(a) Long-term

(b) Short-term

(c) Post-implementation

(d) All

 

  1. Reduced maintenance is a _______ goal of software testing.

(a) Long-term

(b) Short-term

(c) Post-implementation

(d) All

 

  1. Software testing produces ______.

(a) Reliability

(b) Quality

(c) Customer Satisfaction

(d) All

 

  1. Testing is the process of ______ errors.

 

(a) Hiding

(b) Finding

(c) Removing

(d) None

 

  1. Complete testing is ______.

 

(a) Possible

(b) Impossible

(c) None

 

 

 

Chapter-2

  1. Fault is synonymous with the word __________

 

(a) Failure

(b) Defect

(c) Error

(d) All of the above

 

  1. The inability of a system or component to perform a required function according to its specification is called as __________.

(a) Failure

(b) Bug

(c) Error

(d) None of the above

 

  1. Testware includes __________.

(a) test planning document

(b) test data

(c) test specifications

(d) All of the above

 

  1. Symptom(s) associated with a failure that alerts the user to the occurrence of a failure is called __________.

(a) Bug

(b) Error

(c) Defect

(d) Incident

 

  1. Testing process starts as soon as the __________ for the system are prepared.

(a) Design

(b) Coding

(c) Specifications

(d) None of the above

 

  1. Testing strategy should start at the __________ module level and expand towards the whole program.

(a) Smallest

(b) Largest

(c) None of the above

 

  1. Testing is a ______ process.

(a) Intuitive

(b) Random

(c) Planned

(d) None of the above

 

  1. Planning the whole testing process into a well-planned series of steps is called _________.

(a) Test strategy matrix

(b) Test factor

(c) Test phase

(d) Test strategy

 

 

  1. The test strategy matrix is prepared using the __________.

(a) test planning and execution

(b) test factor and test phase

(c) test factor

(d) test phase

 

  1. The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase is called __________.

(a) Verification

(b) Validation

(c) SDLC

(d) None of the above Software Testing Terminology and Methodology 63 l

 

  1. The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies the specified requirements is called __________.

(a) Verification

(b) Validation

(c) SDLC

(d) None of the above

 

  1. In the early stages of SDLC, testing comprises more __________ activities and towards the later stages, the emphasis is on the __________ activities.

(a) verification, validation

(b) validation, verification

(c) integration, coding

(d) None

 

  1. Technique for assessing the structural characteristics of source code, design specifications, or any notational representation that conforms to well-defined syntactic rules is called __________.

(a) Dynamic testing

(b) Static Testing

(c) Black-Box Testing

(d) None of the above

 

  1. Every design feature and its corresponding code is checked logically with every possible path execution in __________.

(a) Black-box testing

(b) White-box testing

(c) Testing tool

(d) None of the above

 

Unit-2 [Chapter-4, 5, 6]

Chapter-4

  1. Black-box testing is a _______.

(a) Static testing

(b) Dynamic testing

(c) None of the above

 

  1. It has been observed that test cases, which are designed with boundary input values, have a _______ chance of finding errors.

(a) High

(b) Low

(c) Medium

(d) Zero

 

  1. How many test cases are there in BVC if there are 5 variables in a module?

(a) 23

(b) 13

(c) 10

(d) 21

 

  1. How many test cases are there in robustness testing if there are 5 variables in a module?

(a) 23

(b) 31

(c) 10

(d) 21

 

  1. How many test cases are there in worst-case testing if there are 4 variables in a module?

(a) 623

(b) 513

(c) 625

(d) 521

 

  1. Each row of state table corresponds to _______.

(a) Input

(b) State

(c) Transition

(d) None of the above

 

  1. Each column of state table corresponds to _______.

(a) Input

(b) State

(c) Transition

(d) None of the above

 

  1. Intersection of a row and a column specifies _______.

(a) Input

(b) State

(c) Transition and output

(d) None of the above

 

  1. What are the components of a decision table?

(a) Condition stub

(b) Condition entry

(c) Action stub

(d) All

 

  1. If there are k rules over n binary conditions, there are at least _______ test cases and at the most _______ test cases.

(a) k+2, 2n+2

(b) k+3, 2n+3

(c) k, 2n

(d) None of the above

 

  1. Boundary value analysis and equivalence class partitioning methods do not consider _______.

(a) Combinations of input conditions

(b) Inputs

(c) Outputs

(d) None

 

Chapter-5

  1. White-box testing is _______ to black-box testing.

(a) mutually exclusive

(b) complementary

(c) not related

 

  1. The effectiveness of path testing rapidly _______ as the size of software under test.

(a) decreases

(b) increases

(c) does not change

(d) none of the above

 

  1. A node with more than one arrow leaving it is called a _______

(a) decision node

(b) junction node

(c) region

(d) all of the above

 

  1. A node with more than one arrow entering it is called a _______

(a) decision node

(b) junction node

(c) region

(d) all of the above

 

  1. Areas bounded by edges and nodes are called _______

(a) decision node

(b) junction node

(c) region

(d) all of the above

 

  1. The length of a path is measured by the number of _______

(a) instructions

(b) junction nodes

(c) decision nodes

(d) links  

 

  1. An independent path is any path through the graph that introduces at least _______ new set of processing statements or new conditions.

(a) 4

(b) 3

(c) 1

(d) 2

 

 

 

  1. The number of independent paths is given by _______.

 

(a) V(G) = e – n + 1

(b) V(G) = 2e – n + 1

(c) V(G) = e – n + 2

(d) none of the above

 

  1. According to Mill’s Theorem, _______

 

(a) V(G) = d + 2P

(b) V(G) = d + P

(c) V(G) = 2d + P

(d) None of the above

 

Chapter 6

  1. In static testing, a bug is found at its _______ location.

 

(a) Exact

(b) Nearby

(c) None of the above

 

  1. Static testing can be applied for most of the _______ .

 

(a) Validation activities

(b) Verification activities

(c) SDLC activities

(d) None of the above

 

  1. Formal peer evaluation of a software element whose objective is to verify that the software element satisfies its specifications and conforms to standards, is called _______ .

 

(a) Walkthrough

(b) Inspections

(c) Reviews

(d) None of the above

 

  1. The programmer or designer responsible for producing the program or document is known as _______.

 

(a) Author

(b) Owner

(c) Producer

(d) All

 

  1. The person who finds errors, omissions, and inconsistencies in programs and

documents during an inspection is known as _______ .

(a) Inspector

(b) Moderator

(c) Author

(d) Producer

 

 

 

  1. The key person with the responsibility of planning and successful execution of inspection is known as _______ .

 

(a) Inspector

(b) Moderator

(c) Author

(d) Producer

 

  1. The inspection team points out any potential errors or problems found and records them in _______.

 

(a) SDD

(b) SRS

(c) STD

(d) Log Form

 

  1. ‘How much evaluation of an item has been done by the team’ is called _______ .

 

(a) Rate of errors

(b) Rate of inspection

(c) Rate of failures

(d) None of the above

 

  1. _______ is a more formal process.

 

(a) Walkthroughs

(b) Inspection

(c) Reviews

(d) None of the above

 

  1. A review is similar to an inspection or walkthrough, except that the review team also includes _______.

 

(a) Customer

(b) Developer

(c) Tester

(d) Management

 

Unit-3 [Chapter-7]

Chapter-7.

 

  1. Software validation is achieved through a series of _______ tests that demonstrate conformity with requirements.

 

(a) white-box

(b) black-box

(c) unit tests

(d) none of the above

 

  1. Before we validate the entire software, _______ must be validated first.

 

(a) modules

(b) system

(c) functionality

(d) all of the above

 

  1. Unit tests ensure that the software meets at least a _______ of functionality prior to integration and system testing.

 

(a) high-level

(b) low-level Validation Activities

(c) baseline level

(d) none of the above

 

  1. Two types of interface modules which must be simulated, if required, to test the module are _______.

 

(a) unit and integration

(b) simulators and emulators

(c) stubs and drivers

(d) none of the above

 

  1. Overhead of stubs and drivers may increase the _______ of the entire software system. (a) test cases

 

(b) time

(c) cost

(d) time and cost

 

  1. Integration of modules is according to the _______ of software.

 

(a) design

(b) coding

(c) specifications

(d) all of the above

 

  1. Recovery is the ability of a system to _______ operations after the integrity of the application has been lost.

 

(a) suspend

(b) observe

(c) restart

(d) all of the above

 

  1. A system that meticulously records transactions and system states periodically so that these are preserved in case of a failure is called a _______.

 

(a) checkpoint

(b) transaction system

(c) recovery system

(d) none of the above

 

 

 

  1. Security requirements should be associated with each _______ requirement.

 

(a) functional

(b) design

(c) coding

(d) testing

 

  1. Measures intended to allow the receiver to determine that the information which it receives has not been altered in transit is known as _______.

 

(a) confidentiality

(b) integrity

(c) authentication

(d) none of the above

 

  1. The process of determining that a requester is allowed to receive a service or perform an operation is called _______.

 

(a) confidentiality

(b) integrity

(c) authentication

(d) authorization

 

  1. A measure intended to prevent the later denial that an action happened, or a communication took place is called _______.

 

(a) confidentiality

(b) integrity

(c) non-repudiation

(d) authorization

 

  1. Acceptance testing must occur at the _______ of the development process.

 

(a) start

(b) end

(c) middle

(d) none of the above

 

 

  1. The total number of sessions in a pair-wise call graph-based integration testing is _______.

 

(a) total edges in the graph + 2

(b) nodes + leaves

(c) nodes – leaves + edges

(d) total edges in the graph

 

  1. Total number of sessions in neighborhood call graph-based integration testing is _______.

 

(a) total edges in the graph + 2

(b) nodes + sink nodes

(c) nodes – leaves + edges

(d) nodes – sink nodes

 

  1. The nodes where the control is being transferred after calling the module, are called _______.

 

(a) sink nodes

(b) source nodes

(c) message

(d) none of the above

  1. The nodes from which the control is transferred are called _______.

(a) sink node

(b) source nodes

(c) message

(d) none of the above4

 

  1. When the control from one unit is transferred to another unit, then the programming language mechanism used to do this is known as

 

(a) sink nodes

(b) source nodes

(c) message

(d) none of the above

 

  1. A call graph is a _______.

 

(a) undirected graph

(b) cyclic graph

(c) directed graph

(d) none of the above

 

 

 

Unit-4

  1. The ____ criteria specify when a test activity is started. – entry
  2. The ____ criteria specify when a test cycle can be completed. – exit
  3. A test cycle is an isolated activity. [True/ False] – False (It is continuous activity)
  4. ____ is done based on estimation of effort involved and avaibility of time for release. – Staffing
  5. ____ standards are externally visible to the customers. – External
  6. _____ standards are formulated by a testing organization. – Internal
  7. The elements of test infrastructure management are ____, _____ and _____ – TCDB, DR, CM
  8. TCDB stands for _____ – Test Case Database
  9. DR stands for _____ – Defect Repository
  10. SCM stands for _____ – Software configuration management
  11. The ___ contains all the information about the test cases in an organization. – TCDB
  12. The ___ captures all the details of defects reported for a product. – DR
  13. A _____ keeps track of change control and version control of all the files. – SCM or CM
  14. A ______ is a tool used to validate that every requirement is tested. – Traceability matrix
  15. Using the test plan, the _______ is designed. – Test case specifications
  16. A report that summarizes the results of a test cycle is the ________ report. – Test Summary Report
  17. A _______ is a communication that happens through the testing cycle when defects are encountered. – Test Incident Report
  18. A _______ gives summary of the activities carried out during the testing cycle. – Test Cycle Report

 

http://newsvoop.com

http://ukashaz.com

Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Rits Blog by Crimson Themes.