MT - 49 - Incremental Model (Multi-waterfall)

The incremental build model is a method of software development where the product is designed, implemented and tested incrementally (a little more is added each time) until the product is finished.In incremental model the whole requirement is divided into various builds. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle.  Cycles are divided up into smaller, more easily managed modules. Each modules are developed separately with separate requirement analysis phase.The product is decomposed into a number of components, each of which is designed and built separately (termed as builds). Each component is delivered to the client when it is complete.Each developed module in Incremental Model is standalone feature and could be delivered to the end users to use it. So ,a working version of software is produced during the first module, so you have working software early on during the software life cycle.Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.

We can explain the model with the help of following two diagrams :








Advantages of Incremental Model:

-Easier to manage risk because risky pieces are identified and handled during it’d iteration

-Core product is developed first i.e main functionality is added in the first increment.

-More flexible to add the new features based on the requirement.

-Each build is reviewed by client so very less probability to miss any requirement.

-Less resource required.

-Easy to manage the project and easy risk coverage.

-Easy to perform testing as each modules developed separately.

-Generates working software quickly and early during the software life cycle.

-This model is more flexible – less costly to change scope and requirements.

-It is easier to test and debug during a smaller iteration.

-In this model customer can respond to each built.

-Lowers initial delivery cost.

-It is generally easier to test and debug than other methods of software development because relatively smaller changes are made during each iteration. This allows for more targeted and rigorous testing of each element within the overall product.

-After each iteration, regression testing should be conducted. During this testing, faulty elements of the software can be quickly identified because few changes are made within any single iteration.

Disadvantages of Incremental Model:

-Need full specification and requirements so that number of modules could be decided.

-Final cost estimation might not be estimated in the beginning and depends on the complexity of the project.

-Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.

-As additional functionality is added to the product, problems may arise related to system architecture which were not evident in earlier prototypes.

-Each phase of an iteration is rigid and do not overlap each other.

-Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle

MT - 48 - V-Model

First of all I'd like to discuss why V-model was designed if we already had Waterfall model in place.
The waterfall was sequential model and the testing was covered at the last phase of the product. So the defect caught at last phase of the the development incurs more cost than in the beginning phase.
V - Model is an extension of the waterfall model and is based on association of a testing phase for each corresponding development stage.. So this model allowed us to catch the defects at early stage of development. In this model development and testing activities were done side by side.


V- Model Diagram


Verification Phases :

Requirements analysis : It is the first phase of the verification process . This is the first phase in the development cycle where the product requirements are understood from the customer perspective. This phase involves detailed communication with the customer to understand his expectations and exact requirement. This is a very important activity and need to be managed well, as most of the customers are not sure about what exactly they need. The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing.

The high-level design (HLD)(System Design):  Once you have the clear and detailed product requirements, it.s time to design the complete system. System design would comprise of understanding and detailing the complete hardware and communication setup for the product under development. System test plan is developed based on the system design. Doing this at an earlier stage leaves more time for actual test execution later.


The low-level design (LLD)(Architecture design) phase is where the actual software components are designed. It defines the actual logic for each and every component of the system. Class diagram with all the methods and relation between classes comes under LLD. Component tests are created in this phase as well.The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. With this information, integration tests can be designed and documented during this stage.

The implementation phase(Module design) : In this phase the detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD). It is important that the design is compatible with the other modules in the system architecture and the other external systems. Unit tests are an essential part of any development process and helps eliminate the maximum faults and errors at a very early stage. Unit tests can be designed at this stage based on the internal module designs.

Coding: The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The best suitable programming language is decided based on the system and architectural requirements. The coding is performed based on the coding guidelines and standards. The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.

Validation Phases
Following are the Validation phases in V-Model:

Unit Testing: Unit tests designed in the module design phase are executed on the code during this validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing.

Integration Testing: Integration testing is associated with the architectural design phase. Integration tests are performed to test the coexistence and communication of the internal modules within the system.

System Testing: System testing is directly associated with the System design phase. System tests check the entire system functionality and the communication of the system under development with external systems. Most of the software and hardware compatibility issues can be uncovered during system test execution.

Acceptance Testing: Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. Acceptance tests uncover the compatibility issues with the other systems available in the user environment. It also discovers the non functional issues such as load and performance defects in the actual user environment.



Advantages of V-model:

-Simple and easy to use.

-Testing activities like planning, test designing happens well before coding. This
saves a lot of time. Hence higher chance of
success over the waterfall model.

-Easy to manage due to the rigidity of the model . each phase has specific deliverables and a review process.

-Proactive defect tracking – that is defects are found at early stage.

-Avoids the downward flow of the defects.

-Works well for small projects where requirements are easily understood.


Disadvantages of V-model:

-Very rigid and least flexible.

-Poor model for long and ongoing projects.

-Software is developed during the implementation phase, so no early prototypes of the software are produced.

-If any changes happen in midway, then the test documents along with requirement documents has to be updated.

-No working software is produced until late during the life cycle.

MT - 47 - Waterfall Model (Linear-sequential model ).

The best model for the sequential software design is waterfall model. Since the process flow is sequentially from top to down so it is called waterfall model. This model was considered to be the first process model or linear-sequential model. It is a simple linear model without phase overlapping. In this model the next phase begins only when the last phase ends.
This model is preferred only when requirements are very well- known clear and  fixed, product definition is stable and there are ample of resources and time.

Sequential flow diagram :




Requirement Gathering and analysis:This is the first phase of the model where all the possible requirements of the system to be developed are captured and documented.During this phase research is being conducted which includes brainstorming about the software, what it is going to be and what purpose is it going to fulfil.Software requirements specification includes the complete information about how actual end users are expecting from the system.

System Design: After the requirement gathering is done, there comes the phase of system design.System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.If the first phase gets successfully completed and a well thought out plan for the software development has been laid then the next step involves formulating the basic design of the software on paper.

Implementation: This is the third phase. Here the system is developed or implemented with the help of the above phases.Here the whole modules are divided into units and each units are developed and unit tested.

Integration and System Testing: In the previous model the system requirements are divided into models & each model is developed & tested separately.In this phase all units are integrated & done the system testing to check whether the all models/units are integrated properly or not & the system as whole doing as mention as per the system requirement document, so we call this phase as the Integration & System Testing. Upon complete testing of software is done then actual Software is successfully send to customer.

Deployment of system: Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market.

Maintenance: There are some issues , change orders which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment. This is a long tyerm process and the system keep on getting enhanced.


Advantages of waterfall model:

- This model is simple and easy to understand and use.

-It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.

- The project requires the fulfilment of one phase, before proceeding to the next. Therefore if there is a fault in this software it will be detected during one of the initial phases and will be sealed off for correction.

-In this model phases are processed and completed one at a time. Phases do not overlap.
Waterfall model works well for smaller projects where requirements are very well understood.

-For each stage deadlines can be set which will help to develop the system on decided time frame.

 Disadvantages of waterfall model:

- It requires a lot of time and resources

-Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.

-No working software is produced until late during the life cycle.

-High amounts of risk and uncertainty.

-Not a good model for complex and object-oriented projects.

-Poor model for long and ongoing projects.

- The testing period comes very late in this model.

- To make it customer happy such new requirement need to be implemented in new version of system which leads to added cost to system development.

-Not suitable for the projects where requirements are at a moderate to high risk of changing.

MT - 46 - SRS , FRS and BRS !

SRS: System Requirement Specification:
It depicts entire system flow, how data is going to flow into the system and overall functionality of the system. SRS says brief about each module's functionality and doesn't include in-depth functionality of each page and module.

BRS: Business Requirement Specification:
This document is called as high level document includes all the requirement demanded by the client. Ideally, this document simply includes all the requirements should be part of proposed system.


FRS: Functional Requirement Specification:
FRS includes requirements, converted into functionality and says that how this requirement is going to work as a part of proposed system.

SRS	FRS	BRS
1. It means “Software Requirement Specification” (SRS).	1. It means “Functional Requirement Specification” (FRS).	1. It means “Business Requirement Specification” (BRS).
2. It deals with resources provided by Company.	2. It deals with requirements given by client.	2. It deals with aspects of business requirements.
3. It always includes Use cases to describe the interaction of the system.	3. In this Use cases are not included.	3. In this Use cases are also not included.
4. It is derived from BRS.	4.It is also derived by discussions.	4.It is derived from the client requirement and discussions.
5. It is developed by System Analyst. And it is also known as User Requirement Specifications.	5. It is always developed by developers and engineers.	5. It is always developed by Business Analyst.
6. In SRS, we describe all the business functionalities of the application.	6. In FRS, we describe the particular functionalities of   every single page in detail from start to end.	6.In BRS, we defines what exactly customer wants. This is the document which is followed by team from start to end.
7. SRS tells means explains all the functional and non functional requirements.	7. FRS tells means explains the sequence of operations to be followed on every single process.	7. BRS tells means explains the story of whole requirements.
8. SRS is a complete document which describes the behavior of the system which would be developed.	8. FRS is a document, which describes the Functional requirements i.e. all the functionalities of the system would be easy and efficient for end user.	8. BRS is a simple document, which describes the business requirements on a quite broad level.

NOTE : FRS and BRS is little confusing : BRS includes list of requirements which are demanded by client and should be part of proposed system; whereas, FRS includes requirement converted into the way it is going to work as a part of proposed system.

MT - 45 - Test scenario and Test case - Difference!

Often we get confused between test case and Test scenario. These are two important points from testing point of view :

Test Case	Test Scenario
Test Case is ‘How to be tested’	Test Scenario is ‘What to be tested’
Test case consist of test case name, Precondition, steps / input condition, expected result.	Test scenario consists of a detailed test procedure. We can also say that a test scenario has many test cases associated with it. Before executing the test scenario we need to think of test cases for each scenario.
Test cases are low level actions and it can be derived from test scenarios.	Test scenarios are the high level classification of test requirement grouped depending on the functionality of a module and it can be derived from use cases.
Each test case checks for a single functionality or test scenario.	Test scenario may have numbers of test cases.
Test case means detailed documenting the cases which help executing while testing.	Test Scenario means talking and thinking requirements in detail.
Test cases are set of steps which performed on system to verify the expected output.	Test scenario is thread of operations.
Test cases are more importance in case where development is happening onsite and QA is happening Off shored. It will help to understand and make both developer and QA in sync.	Test scenarios are more important when time to write test cases is no sufficient and team members are agree with the detailed one liner scenario.
Writing test cases is one time effort which can be used in future while executing regression test case. While reporting defects it will help tester to link the defect with test case id.	In new software testing generation it is new idea and time saver activity. The addition and modification (easy maintainability) of test scenarios is easy and independent on specific person.
The intention of test cases is to capture all the requirements. If developer missed something then it is easy to catch while executing these full-proof test cases.	One of the most positive point about test scenario is good test scenarios reduces the complexity and repeatability of product.
It requires more effort due to detailed test case which talks about how to test .	If the test scenario not detailed enough then it might take some time to discussion and understand what test scenario is exactly talking about.
Test cases has one to one relation	Test scenarios has one to many relation.
Test cases are the set of valid and invalid executable procedure of a test scenario. A test case with valid functionality is called positive test case and a test case with invalid functionality is called negative test case.	A test scenario may have one or more test cases associated to it.

MT - 44 - Error Seeding or Bee-bugging ?

Bee-bugging or error seeding is a process of intentionally adding errors to the code to evaluate the amount of residual errors during the phase of testing. In Simple language we can say that we can estimate the total error found in the application to that of the error seeded in the code. This may be used to map the testcases and the level of testcases designed. Additionally we can check that the behaviour of application after introducing errors. IN error-seeding technique a certain number of errors are sown in code while in mutation testing a change in the statement is done (Refer blog 26 for mutation testing).

Here are few differences between them

Error Seeding	Mutation Testing
No mutants are present here.	Mutants are developed for testing.
Here source code is tested within itself.	Here mutants are combined, compared for testing to find error introduced.
Errors are introduced directly.	Special techniques are used to introduce errors.
Test cases which detect errors are used for testing.	Here, test cases which kill mutants are used for testing.
It is less efficient error testing technique.	It is more efficient than error seeding	.
It requires less time.	It is more time consuming.
It is economical to perform.	It is expensive to perform.
It is better method for bigger problems.	It is a better method for small size programs.

MT - 43 - What is baseline testing?

As the name says , base-lining is defined as the standard that forms the base for any software or application.
Its a type of non-functional testing which refers to the validation of the documents and specifications on which the test-cases will be designed.In configuration management, a baseline is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change Normally SRS is considered as the baseline of testing.
Baseline is the point at which some deliverable produced during the software engineering process is put under formal change control.Base Lining is the very important process in the Configuration Management.Once the base lining is done the application is blocked for the editing. Only after the base lining we can give the version no to the particular application.A specification or software product that has been formally reviewed or agreed upon ,that thereafter serves as the basis for further development,and that can be changed only through a formal change control process.he point at which some deliverable produced during the software engineering process is put under formal change control.