Bz

Q1. What is  Coding ?

Coding: Good software companies want their programmers to adhere to some well-defined and standard style of coding called coding standards.

 Q2. Write details Coding Standards guidelines?

1. Have some rules for variables that can be declared global
2. Each modules should have same type of information (as comments) at the beginning (module name, author name, last update date, update history, short description etc.)
3. Naming convention for global, local variables, constants, methods etc.
4. Error/Exception handling mechanism
5. Avoid too clever or too difficult to understand coding style
6. Avoid variable hiding (using same name for local and global variables) – difficult to understand code
7. Use documentation (average one line comment for per 3-line source codes)
8. Use short functions (average 10/15 lines per method)
9. Do not use unstructured coding (example: avoid goto )

Q3. Details Code Review ?

• After compiling successfully (no syntax error), a working program is reviewed to produce high quality software.
  • Code Walk through
    • To find algorithmic/logical error
    • Before a walk through meeting, the code is handed to 3/7 project members.
    • Main focus is finding errors, not how to solve them
    • Managers/leaders should not attend the meeting (so programmers have no fear of evaluating)
  • Code Inspection
    • To find out certain types of error / improper programming (use of uninitialized variables, jumping into loop block, for-ever loop, incompatible assignment, array index out of bound, incorrect use logical operator, equality comparison between floats etc.)

Q4. What is software testing ?

• Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design, and code generation.
• Testing Objectives:
  • Testing is a process of executing a program with the intent of finding an error.
  • A good test case is one that has a high probability of finding an as-yet undiscovered error.
  • A successful test is one that uncovers an as-yet-undiscovered error.
• So main objective: Not to show absence of error/defect, but to show what error/defect the software have

Q5. Define the Testing Principles?

1. All tests should be traceable to customer requirements
2. Tests should be planned long before testing begins
3. The Pareto principle applies to software testing
4. Testing should begin “in the small” and progress toward testing “in the large.”
5. Exhaustive testing is not possible
6. Testing should be conducted by an independent third party.

Q6. Testability

1. Operability—it operates cleanly
2. Observability—the results of each test case are readily observed
3. Controllability—the degree to which testing can be automated and optimized
4. Decomposability—testing can be targeted
5. Simplicity—reduce complex architecture and logic to simplify tests
6. Stability—few changes are requested during testing
7. Understandability—of the design

Q7. White Box Testing.

1. (also known as glass-box testing). To find logic errors, incorrect assumption, typographical error
2. guarantee that all independent paths within a module have been exercised at least once
3. exercise all logical decisions on their true and false sides
4. execute all loops at their boundaries and within their operational bounds
5. exercise internal data structures to ensure their validity.
6. Basis path testing
   1. Flow-chart / flow graph
   1. Cyclomatic complexity – a measure of logical complexity)
   1. Steps:
      1. draw flowchart
      1. determine Cyclomatic Complexity
      1. Determine the basis set of linear independent path
      1. Prepare test data so that each path is executed at least once
7. Graph Matrix
8. Condition testing
9. Data flow testing
10. Loop testing

Q8, Black-box Testing.

1. (Behavioral Testing). To find
2. (1) incorrect or missing functions,
3. (2) interface errors,
4. (3) errors in data structures or external database access,
5. (4) behavior or performance errors, and
6. (5) initialization and termination errors.

Q9. Black box testing (case design)

1. Graph-based
   1. Transaction-flow modeling
   1. Data flow modeling
   1. Finite state modeling
   1. Timing modeling
2. Equivalence Partitioning
3. Boundary Value Analysis
4. Caparison Testing (2 or more  s/w are developed for critical system by separate teams. They are tested with same set of data)
5. Orthogonal Array Testing (for small input discrete data set)

Q10. Design Model

• The aim of design is to produce a model that will provide a seamless transition to the coding phase
  • once the requirements are analyzed and found to be satisfactory (requirement analysis/ analysis modeling), a design model is created which can be easily implemented.
• 4 major areas to focus for detail design modeling:
  • Data design
  • The System Architecture design
  • Interface design
  • Component design

Q11. A Good software design

• Design = Quality
• A good design :
  • Should implement all the explicit requirements mentioned in analysis model
  • Should accommodate all the implicit requirements desired by customers/users
  • Should be a readable, understandable guide for coder, tester, future support staffs
  • Should provide a complete picture of the software, addressing the data,  functional, and behavioral domains
  • Should be modular (logical partition of elements that perform specific tasks)
  • Should lead to appropriate data structure suitable for data objects
  • Should lead to interfaces that reduce complexity of connections between modules and external environment

Q12. Cohesion & Coupling

• These are the qualitative measurement of functional dependency
• Cohesion is a measure of the relative functional strength of a module
  • A cohesive module performs a single task within a software procedure, requiring little interaction with procedures being performed in other parts of a program.
  • We should avoid low-level of cohesion. (midlevel is as good as high-level)
• Coupling is a measure of the relative interdependence among modules.
  • Coupling is a measure of interconnection among modules in a software structure. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.
  • We should have low-level of coupling

Q13. What is a Use Case

• A formal way of representing how a business system interacts with its environment
  • Illustrates the activities that are performed by the users of the system
  • A scenario-based technique in the UML
  • A sequence of actions a system performs that yields a valuable result for a particular actor.

Q14. Deferent of Black Box & White Box.

Black Box Testing	White Box Testing
1. Black box testing techniques are also called functional testing techniques.	1.White box testing techniques are also called structural testing techniques.
Black box testing is a software testing method in which the internal structure/design/implementation of the item being tested is NOT known to the tester.	2. White Box Testing is a software testing method in which the internal structure/design/implementation of the item being tested is known to the tester.
3. It is mainly applicable to higher levels of testing such as acceptance testing and system testing.	3. Mainly applicable to lower levels of testing such as Integration Testing.
4. Black box testing is generally done by software Testers.	4. White box testing is generally done by software Developers.
5. Programing knowledge is not required.	5. Programing knowledge is required.
6. Implementation knowledge is not required.	6. Implementation knowledge is required.

Thanks for joining me!

Good company in a journey makes the way seem shorter. — Izaak Walton