ISTQB

Test analysts and technical test analysts lay major attention to design, implementation and execution of tests using various testing techniques. Specification-based techniques are one of such techniques.

Specification-based techniques are popular by more refined names like behavior-based techniques or Black Box test design techniques. These techniques can be used for any level of test activity. These are used by both test analysts and technical test analysts, but exploited mainly by the test analysts.

Code is designed and developed from the software requirement’s specifications (SRS) documents being the primary input documents. Likewise specification-based test techniques too are based upon the test conditions & test cases derived from the SRS documents.

We can make our specifications that can be in the form of text documents, pictures, models, compilation of features, or any other document which could help us in understanding as to what we expect from the software & how it is going to accomplish that. Test coverage is represented by the percentage of the specified items addressed by the designed tests. Coverage of all the specified items does not necessarily indicate complete test coverage, but it does indicate that we have addressed what was specified. For further coverage, we may need to look for additional information.

ISTQB Advanced Level syllabus addresses following seven types of specification-based techniques

Sometimes one or more of these techniques are combined to create our tests. For example, the conditions identified in a decision table might be subjected to equivalence partitioning to discover multiple ways in which a condition might be satisfied. Tests would then cover not only every combination of conditions, but also, for those conditions which are partitioned, additional tests would be generated to cover the equivalence partitions. 

80-20 rule or ( Pareto Analysis)

Everybody heard about the 80-20 rule that says that 80% of the results are coming from 20% of the subjects.
This can be applied to any field as follows:
        - 80% of the revenue of a company is coming from 20% of the clients
        - 80% of the donations for a charity are coming from 20% of the people
        - 80% of the books from a bookstore are purchased by 20% of the clients
For software, this could mean that
        - 80% of the clients are using 20% of the functionality
        - 80% of the bugs are caused by 20% of the functionality
I used to think that this is how things are as the rule is too attractive in its common sense and simplicity.
The problem is that when you investigate it a little bit, things are becoming a little more complicated.
How does this apply to testing? 
Well, the project release date is fixed so you cannot test everything well.
So, test only 20% of the application as this is what the majority of the users will use. 
Select the 20% of the application's functionalities that have the highest risk and test them well. 
Test the remaining 80% of the functionalities by just taking the happy paths.
You think you did a good job, the project manager is happy with the results.
And after the release, the support team receives lots of issues from the clients about the 80% of the application not tested well.
More, the senior management of the company starts noticing problems all over the application too.
The solution is, of course, applying an endless number of patches with bug fixes for the issues discovered by the customers, frustrating the customers as much as possible and wasting as much time as possible for both the development and testing team.

Cyclomatic complexity

Cyclomatic complexity (or conditional complexity) is a software metric (measurement). It was developed by Thomas J. McCabe, Sr. in 1976 and is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program's source code.

Cyclomatic Complexity metric is based on the number of decision in a program. 

Cyclomatic Complexity :- The number of independent paths through a program. 

Cyclomaticcomplexity is defined as: L – N + 2P 

where- 

L = the number of edges/links in a graph- 

N = the number of nodes in a graph-

P = the number of disconnected parts of the graph (e.g. a called graph or subroutine) 

It doesn't take place in Manual testing .  Neither it is a part of White Box...   In fact It is the Part of Verification Static testing , It is done with the help of Static Analysis tools..

   Cyclomatic Complexity can be calculated using either of two rules
        1) Formal Formula 
        2 ) Decision Point rule 
Decision point rule : Which says CC = Total number of Decision Point + 1.
Ex 1 :-  void test::Test3()
                    {
                        string a,b,c,d,e,f;
                        if(((a==b)&&(e==f))||(f==a)||(a==b))
                                c=d;
                            else
                                c=f;
                    }

 To find the cyclomatic Complexity of the above program :-   

 Cyclomatic Complexity :- Total number of Condition + 1. 

 hence in this Example:-   there is only one if condition so the Cyclomatic Complexity is : 1+ 1 = 2.

Ex 2:-

void func1()
{
        int a,b,c,d;
        while (1)
        {
            if (a>b)
            print a
    else if (b>c)
            print b
    else
            print c
    }

}

 Now what is a Decision Point ..?

While there are many ways to calculate cyclomatic complexity, the easiest way is to sum the number of binary decision statements (e.g. if, while, for, etc.) and add 1 to it.

    hence in your program above , the Cyclomatic Complexity is 3 + 1= 4.

Ex 3:-

        IF A = 354

            THEN IF B > C

                        THEN A = B

                ELSEA= C

            ENDIF

        ENDIF

    Print A

The control flow generated from the program would look like below flow chart.

The control flow shows seven nodes (shapes) and eight edges (lines), thus using the formal formula the cyclomatic complexity is 8-7 + 2 = 3. In this case there is no graph called or subroutine. Alternatively one may calculate the cyclomatic complexity using the decision points rule. 

Since there are two decision points, the cyclomatic complexity is 2 + 1 = 3.