Functional Testing

Also called component testing. Testing each and every component thoroughly (rigorously) against requirement specifications is known as functional testing.

Thus, during testing, we must remember the following points,

a) We must always start testing the application with the valid data. In the above example for amount transfer, we see that we have entered the valid data 100

only in the 6th test. This should not be done, because if the valid data itself is not taken correctly

, then we need not have to waste our time checking for the invalid data

b) If the application works for valid data, only then we must start testing for invalid data

c) If the application is not working for 1 of the invalid values, then we can continue testing for all the other invalid values and then submit the test report of all the defects for invalid values.

d) In testing, we should not assume or propose requirement. If we have any queries, talk to the one who knows the requirements very well and clarify the queries.

e) We must not do over-testing ( testing for all possible junk values ) or under-testing ( testing for only 1 or 2 values ). We must only try and do optimize testing (testing for only the necessary values- both invalid and valid data).

f) We must do both positive testing (testing for valid data) and negative testing (testing for invalid data).

Interface elements include but are not limited to:

Input Controls: checkboxes, radio buttons, dropdown lists, list boxes, buttons, toggles, text fields, date field

Navigational Components: breadcrumb, slider, search field, pagination, slider, tags, icons

Informational Components: tooltips, icons, progress bar, notifications, message boxes, modal windows

Containers: accordion

The characterstics of a good requirement are,

1) Unitary ( cohesive ) – the requirement addresses 1 and only 1 thing

2) Complete – the requirement is fully stated in 1 place with no missing information

3) Consistent – the requirement does not contradict any other requirement and is fully consistent

with all authoritative external documentation 

4) Non-Conjugated ( Atomic ) – the requirement is atomic i.e, it does not contain certain conjunctions

. Ex – “the postal code field must validate American and Canadian postal codes” should be

written as two separate requirements : 1) “The postal code field must validate American

Postal codes” and 2)

“The postal code field must validate Canadian Postal codes”.

5) Traceable – the requirement meets all or part of a business need as stated by stakeholders and

authoritatively documented

6) Current – the requirement has not been made obsolete by the passage of time

7) Unambiguous – the requirement is concisely stated without recourse to technical jargon,

acronyms etc. it expresses objective facts, not subjective opinions. It is subjective to one and

only one interpretation.

8) Mandatory – the requirement represents a stakeholder defined characterstic the absence of

which will result in a deficiency that cannot be ameliorated

9) Verifiable – the implementation of the requirement can be determined through one of 4

possible methods – inspection, demonstration, test or analysis.

Test Scenarios for GUI Components:

Test Scenario for Email_id

Test Scenarios For Text Field

Test Scenario For Check Box

Software Testing

Testing the functionality of an application according to customers requirement specification is called Software Testing.

There are different types Software Testing.
1. White Box Testing
2. Black Box Testing
3. Grey Box Testing.

White Box Testing:
Testing each and every line of the program is called white box testing. It is also called as Unit testing or Structural testing or Glass box testing or Open box testing.

Black Box Testing.
Testing the functionality of an application according to customers requirement specification is called Black box testing

Why we do Software Testing:

1. In order to find the defect in the Software.
2.To provide the good quality of the software to the customer.

• Software Testing Saves Money.
• Security.
• Product Quality.
• Customer Satisfaction.

• Software testing is really required to point out the defects and errors that were made during the development phases.
• It’s essential since it makes sure that the customer finds the organization reliable and their satisfaction in the application is maintained.
• It is very important to ensure the Quality of the product. Quality product delivered to the customers helps in gaining their confidence.
• Testing is necessary in order to provide the facilities to the customers like the delivery of high quality product or software application which requires lower maintenance cost and hence results into more accurate, consistent and reliable results.
• Testing is required for an effective performance of software application or product.
• It’s important to ensure that the application should not result into any failures because it can be very expensive in the future or in the later stages of the development
• It’s required to stay in the business.

http://tryqa.com/why-is-testing-necessary/

https://www.testdevlab.com/blog/2018/07/importance-of-software-testing/

Spiral model

It is a step by step procedure to develop the software.

Waterfall Model

Drawback of waterfall model:

1. Cannot adopt the changes in requirements

2. Testing is a small phase which is done only after coding. 

3. Rework cost is high

5. For bigger and complex projects, this model is not good as a risk  factor is higher.

7. Not suitable for the projects where requirements are changed frequently.

8. Not suitable for long term project

Advantages of Waterfall model.

1. Simple and easy to understand and use.

2. it is easy to maintain

3. Initial investment is less

4. Since requirements are not going to change we can expect very good quality of the product

Application of Waterfall model:

1. To build small application.

2. To build short term application

3. Whenever we are sure that requirements are not going to change

What are the disadvantages of developer testing the application.

1. Developers will utilize the time allocated for testing to build the application.

2. Developers will be over confident 

3. They will be concentrate more on development rather than testing.

4. They will not test the software from negative point of view 

5. Even though bugs are there in the software they may hide it.

6 .Lack of End-to-End knowledge and real-user perspective

Why this model is called waterfall model?

Here backtracking is not possible. i,e once after the feasibility study is completed all the requirement will be frees-ed and we cannot go back and change the requirement, so this model is called WFM.