What is LCSAJ?

LCSAJ stands for Linear Code Sequence and Jump. Typically it contains three parts:
1) Initial step of the program code or a step to which control may jump and continue to execute after that.
2) The program terminating step or an instruction which lead to jump.
3) And the destination step of the jump.

Let’s there is a program which finds whether input number is prime or not.

1) Printf( “Enter the number:”);
2) Scanf(“%d”,&num) ;
3) bPrime=true;
4) for(int i=2;i&<num/2;i++)
5) {
6) if( num%i==0)
7) Printf( “ %d is factor of %d”, i, num);
bPrime = false;
8) }
9) if(bPrime==true)
10) {
11) Printf( “Number is Prime”);
12) }
13) End of program.

To find all LCSAJs in code, find all jumps in the program. Those are: (4->9, 8->5, 6->8 and 9->13). All those instructions, to which control could jump from instruction other than the preceding one, are called as start of the LCSAJ.
In the above code starts of LCSAJ are: (1 (entry of the program), 5, 8 and 13).

Now find LCSAJ from each LCSAJ start. For LCSAJ starting at 1, control goes from instruction 1 to 3 and checks for condition at step 4. If the condition is false, then code jump occurs giving first LCSAJ, assuming all other conditions following it are true, (Initial step, branching step and destination step) (1, 4, 9). Now, the case where condition at step 4 is true, control flows from step 5 and then step 6, which is a condition statement. If that condition is false, a new LCSAJ would be formed due to jump which is (1, 6, 8). Similarly, LCSAJs (1, 8, 5) and (1, 9, 13) are also there.
Similarly, LCSAJs could be formed with every start of the LCSAJ.

100% LCSAJ Coverage implies 100% Decision Coverage. But there is a possibility of LCSAJs being infeasible while testing and also effort required for LCSAJ testing and coverage is more as compared to decision coverage.

Unit testing techniques

Unit is an atomic part of a program which could not be decomposed in smaller parts. Testing that part for its correct implementation is called unit testing. There are various techniques for conducting unit testing. These techniques are complementary to each other and find different set of errors when applied to unit, one after the other.

1) Specification based testing techniques:
This technique generates test cases based on program’s behavior,input domain and expected output.Following are specification based techniques
a) Equivalence partition: Under the technique, input domain of the unit is partitioned into various classes. Each class contains input values which would have similar effect on the code. Test cases select input values at random,from these classes.

b) Boundary value analysis: test cases are generated so that they can cover the boundaries of any condition in the code. Generally, it is performed after equivalence partition. One test case is designed for inside of the classes and as many as necessary to cover its limits.

c) Decision tables and cause effect graphing: Inputs for the unit can occur in any combinations. Those combinations are represented and analyzed with decision tables and cause effect graphing. Then test cases are generated for all the possible input output combinations.

d) Random testing: Test cases are generated at random according to the input domain and expected output domain specified in specifications.

2) Code based testing techniques: These testing techniques can be again classified into two categories:
Control flow based criteria: This varies as to how well and what part of code, the test case covers in the program control flow.
Data flow based criteria: In this, test cases cover the execution space between variable defined and where they are used in the program flow.

Let’s consider the control flow based criteria techniques:
a) Statement coverage: Test cases generated for this criterion must ensure that they execute each and every statement of the code.

b) Decision (branch) coverage: Code contains many decisions and corresponding branches for those decisions. To fulfill the decision or branch coverage criterion test cases must ensure that all the program decisions take the value true or false and execute the corresponding code

c) Condition (Predicate) Coverage: In practice, decisions compose of many conditions. Combination of values attained by these conditions decides the final outcome for decisions. To satisfy condition coverage criterion, test cases must ensure that all conditions present in the decision take the value true and false.

d) Modified condition/ decision coverage: There may be a case where we have tested the condition and decision in the program, but still individual effect of each condition on the decision is not tested. There may be cases of short circuiting in logical expressions. To test the independent influence of every condition on decision modified condition/ decision coverage is used.

Nature of bugs found in code inspection

Code inspection is an important process in any mission or safety critical system development. It’s a type of static testing in which code is not executed but critically analyzed in order to find some subtle bugs which are not detectable or require lot of efforts to detect in testing phase. The point of interest is what kind of defects one can find in code inspection. This article analyses bugs classes found in the code in code inspection process.

1) Maintainability of the code: No code is perfect when it has been written. It is bound to change, enhanced and modified for adaptation to different platforms. So it is necessary that code written is understandable and maintainable. Code inspection focuses on this goal. Under this, following points are looked for in code:
a) Code to comment ratio is proper and whether comments explain intent of the code appropriately and correctly.
b) Whether all the variable names and function names are meaningful and clearly state the intention.
c) Whether the coding standards or guidelines are adhered to.
d) Whether code has proper logical flow or not?

2) Design flaws: Code reflects design of the software. What if the deign itself contains flaws. Since software is tested against requirements and design, it is very difficult to detect these kind of defects in testing phase. In that case, code inspection provides an additional design review step. There are issues which will never fail the system but very dangerous from the quality point of view. For example, when designing system, one designs a structure to keep track of some of the hardware channels status like if they were empty or full etc. The very thought instrumental behind the design was that structure could be used bit wise and memory could be saved which would have not possible by using arrays. But this thought didn’t consider that system had some functionality which requires checking status of all channels at the same time like for averaging of all channels data. Since the data structure used was bit wise structure, one has to check all the fields of the structure one by one resulting in very lengthy and unstructured code which would have been very simple, in single loop if array has been used.

3) Structural flaws: Proper structure of the code is must for understanding and testing of the software. Following points which are given stress on in code inspection process:

a) Does every function implement single functionality and is testable?
b) Does length of the function justifiable or shall it be broken into smaller ones?
c) Is any dead or extra code present in the code?
d) Is any unreachable code present in the code?
e) Whether there are multiple exists for functions and can they be removed?
f) Does every variable, that has been assigned value in any conditional block, get initialized prior to usage?

4) Logical errors: These are errors which are infused in the coding phase by developer because of ambiguous design or unclear requirements. As there is no guard against them in requirements and design, these kinds of bugs are subtle,not obvious in nature,may occur once in many execution cycles or when a particular sequence of events occur.
For example, lets say, software works in sequence of steps like power on, operation on, check of automatic corrections,operation off and then power off. In operation phase, it first checks whether given number of passes have already been elapsed in operation then only does the automatic correction. The variable which keeps track of no of passes was reinitialized at the power on stage. Assuming that software goes to operation off state; again comes to operation on state without going to power off state. Now since this is a fresh operation, automatic correction shall be applied after given no of passes have been elapsed in this operation, but as variable keeping track of no of passes is not reinitialized hence contains last value, so software does not wait for given no of passes to elapse and starts performing automatic correction. This error will not hamper the functioning of the software but will surely hamper the algorithm which calculates the corrections to be applied to the data. These kinds of errors are found in the code inspection by hypothesis.

There is subtle difference between code walkthrough and code inspection
Code walkthrough is an informal process which is conducted by developer team. Peer reviews are kind of code walkthrough.
Code inspection is more formal process with formal team,roles and meetings. Code inspections report is asked for in project and process audits. Checklists are used for code inspection.

Improving code quality

Code is implementation of design of your software. However robust and reliable you design your software it is going to give problems especially while maintaining, changing or debugging. It is therefore important that code written shall be quality one. So the question is how to write quality code. There is set of steps which if followed while coding can result in quality code.

1) Identify and implement coding standard: Coding standards provide a common platform to all involved in the development so that everybody can understand code written by other and can easily change and test it. Coding standard makes code more readable and understandable which is most important form the QA point of view who conducts code walkthroughs. These also prevent mistakes which are induced due to hidden characteristics (Like precedence order of operators) of the language in which code has been implemented. Standards specify naming conventions, mandatory things to do and not to do etc. It is not necessary that coding standard followed by one organization or even project be suitable or mandatory for the other. These shall identified as per the project needs and project critically. Like in an on board projects MISRA C standard shall be followed but it is too strict for any ground software.
Various coding standards available are:

2) Code walkthrough/ Inspection: This technique comes under static testing process and finds out bugs and violation in code without executing the code. Code walkthrough try to improve the structure, flow and understandability of the code and focuses on errors which are hindrance to maintainability and changeability of the code although it tries to find out logical mistakes in the code. Usually, a checklist, which contains a list of commonly occurring errors, is used in code walkthrough/ inspection. These some faults therefore are removed in the code before going for testing.

3) Proper commenting:
Commenting is the best way to document your code. Commenting shall be mandatory for all projects but the extent of commenting may vary. For example for a critical medical software there may be 1:1 ratio of comments i.e. for every line of code written, there is a comment explaining the intent of the statement while for a website code it can 1:10 i.e. one comment for every ten lines of code. A format can be devised for comments at module level which may contain the version no of the module, purpose of the module, Functional requirement implemented in the module, inputs, processing and out of the module.

4) Use static code analyzer:
These kinds of software are very useful in detecting trivial errors like connection not closed, file not closed, null pointer dereference (if applicable for language) etc. Using these tools can save time as well resources for code walkthrough as majority of the trivial errors will be detected by these tools and they can focus on major logical errors. There are many static code analyzer are available both commercial and open source. FindBugs is one of such open source code analyzer software for JAVA