What are low level and high level test cases? List out the differences?

IMPORTANCE OF TEST CASES
- Test cases are such an important part of software testing that they can’t be neglected.
- Test cases form the basis of any software testing methodology.
- After all, the efficiency of the software testing depends on how effective are the test cases developed for that particular type of software testing.
- The test cases are developed keeping in mind all the important aspects of the software testing.
- Aspects like the components of the application, its attributes, its features and functionality, kind of coverage needed, aim of the testing methodology and requirements of the software system or application.
- One test case tests only one feature, functionality or aspect of the software system or application.
- It is necessary that the test case is implemented properly and according to the specifications.
- If the test case is not implemented properly then it makes no sense of testing no matter how effective and efficient is the test case.

LOW LEVEL & HIGH LEVEL TEST CASES
There are basically two types of test cases about whom we shall be discussing in this article. These are namely low level test cases and high level test cases.

DIFFERENCES BETWEEN LOW LEVEL & HIGH LEVEL TEST CASES

DIFFERENCE #1:
- Low level test cases are developed pertaining to the low level bugs in a software system or application.
- On the other hand high level test cases are concerned with the bugs of high levels.
- Wherever a low level bug is suspected in the program code a low level test case is used for testing and wherever a high level bug persists, correspondingly a high level test case is used.

DIFFERENCE #2:
- High level test cases are developed for testing the major functionalities and features in a software system or application rather than just testing high level bugs.
- Major functionality may include display, update data base, retrieval and so on. They can be rather called test cases related to functionality.
- The low level test cases can be appropriately called test cases related to the user interfaces as they are very effective in testing the application’s user interfaces besides low level bugs.

DIFFERENCE #3:
- While carrying out the software testing, the high level test cases based on the requirements test the corresponding functionality.
- Requirements need to be identified properly so that there is no faltering while performing the test. This is called high level testing.
- Similarly testing carried out using low level test cases is called low level testing and is employed to test the software system or application at the micro level i.e., the expected outcome and the actual outcome.

DIFFERENCE #4:
- Low level test cases include the following test cases:
(a) For integration testing
(b) For unit testing
- On the other hand, the high level test cases are further sub divided into the following test cases:
(a) Test cases for system testing
(b) Test cases for functional testing and
(c) Test cases for acceptance testing.

DIFFERENCE #5:
- The high level test cases are able to provide better test coverage.
- They don’t focus much on the features and functionality but only to the extent that they should work properly and well in accordance with each other.
- The low level test cases are focused up on each and every minor detail of the program code.
- The program is tested in depth.
- Therefore we can say that the low level testing involves more detailed work than the high level testing.

DIFFERENCE #6:
- Low level testing and high level testing belong to the category of white box testing and black box testing respectively.

Why C compilers are better than other language Compilers?

A compiler as we all know is a program that translates source code into object code so that the code becomes executable, or we can say A compiler converts high level language code into a low level language code (assembly language).A compiler performs six major operations namely preprocessing, semantic analysis,lexical analysis, code generation, code optimization and parsing.

A compiler has basically 3 main parts. First is the front end that checks the semantics and syntax of the program and the errors are reported.Second, the middle end which does the optimization removing any unwanted or bad code.The last part is called the back end which translates the middle level intermediate representation or IR into the assembly language.

Processor registers are assigned. The back end also draws the schedule for the hardware units. Today we see a number of compilers available in the market like clang, Microsoft C, GCC, etc. C is still the favorite language of many programmers in the world. What makes it so special? It is its compiler. C compiler is better than any other language because it is small in size, so that you can execute a program everywhere. The C compiler is usually faster than any other language compiler. Furthermore there is no overhead byte code generated.

- You can use the dynamic C library directly.
- Most of the C compilers include memory and bound checker.
- Many C compilers are capable of running under windows XP and windows Vista and are also able to compile the command line.
- Most of them support integrated environment.
- C compilers are capable of handling multi- threaded programming and are good for exploiting dynamic parallelism which otherwise can make it difficult for passing messages.
- C compilers are algorithmic in nature and provide a scheduler to schedule the performance of the programs.
- They compile and link the codes very fast and they have a very powerful optimization technology.
- They come with a library source which is complete and brows able.
- They do extensive checking during the process of compilation.
- Some C compilers are safe from the risk of pointers and are capable of fast prototyping of the programs.
- They also don’t allow violation of array bonding.
- They can be run as interactive or non- interactive phases.
- They support enumerated data types, all data type variables like int, long, and float etc. some may also provide you with some sample programs to help you understand the features of the language.
- They are perfect for parallel computing. Global vectorization and optimization is also supported.
- These C compilers do inter procedural analysis. While doing optimization they give the user necessary feedback. They are able of transferring loops.
- C compilers are capable of code generation and give optimal performance from the processors.
- They simplify the execution thus, accelerating it. No limitations are imposed code size and optimization. They are very fast and accurate as compared to the compilers of other languages.
- Latest compilers are capable of building internet, distributed and windows applications. The code generation includes compiling, assembling, linking, resource compiling and adding library files.
- The integrated development includes editing, debugging, generating files and resource editing.
- They come with documentation and user’s manual.
- Most of the C compilers don’t come as freeware.
- C compilers require Windows 95 and other latest versions for implementing command lines.
- If a C compiler is supporting IDE, you need to have windows 2000 and following versions. The system should have a minimum of 32 MB of RAM and 500 MB of ROM.

We can say they are like many in one package which allow writing, developing, compiling, interpreting, assembling and debugging, and execution of the programs.

High-level Best Practice Four(4) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first, second and third area and there practices are already discussed.

Change Propagation

Propagating file changes across branches needs to be managed. The practices involved with this work space are :
- Do not delay to propagate a change. When it’s feasible to propagate a change from one
branch to another (that is, if the change wouldn’t violate the target branch’s
policy), do it sooner rather than later.
- It is much easier to merge a change from a file that is close to the common
ancestor than it is to merge a change from a file that has diverged considerably.
This is because the change in the file that has diverged may be built upon
changes that are not being propagated, and those unwanted changes can
confound the merge process.
- Changes can be propagated by the owner of the target files, the person who make the original changes, or someone else.

High-level Best Practice Two(2) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first area and its practices are already discussed.

The Codeline
It is a set of source programs or files required to develop a software. Codelines are branched, and the branches evolve into variant codelines embodying different releases.
The best practices are :
- Give each codeline a policy : It is the essential user’s manual for codeline SCM. The policy of the development codeline should state that it is not for release or the policy of the release codeline should state that it is not for testing or bug fixing. It specifies the check-ins for the codeline.
- Give each codeline an owner : After the policy is defined for a codeline, there would be situations where the policy is inapplicable or ambiguous. When the developers face these ambiguities, they will turn to the person who is in charge of the codeline. There has to be a owner of the codeline because if there would be no owner, the developer will create their own workarounds without documenting them.
- Have a mainline : A mainline is the branch of a codeline that evolves forever. A mainline provides an ultimate destination for almost all changes – both maintenance fixes and new features – and represents the primary, linear evolution of a software product.

High-level Best Practice One(1) in Software Configuration Management

Software configuration management (SCM) is a set of activities that are designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling changes that are imposed, and auditing and reporting on the changes that are made.
Software Configuration Management Best Practices are the techniques, policies and procedures for ensuring the integrity, reliability and reproducibility of developing software products.
When implementing SCM tools and processes, you must define what practices and policies to employ to avoid common configuration problems and maximize team productivity. There are six areas of SCM deployment, and some coarse-grained
best practices within each of those areas.
- Workspaces: It is the area where the engineers edit source files, build the software components they’re working on, and test and debug what they have built. The best practices for workspaces include:
. Don’t share workspaces.
· Don’t work outside of managed workspaces.
· Don’t use jello views: A file in your workspace should not change unless you
explicitly cause the change. A “jello view” is a workspace where file changes are
caused by external events beyond your control.
· Stay in sync with the code line.
· Check in often: Integrating your development work with other peoples’ work also
requires you to check in your changes as soon as they are ready.