Software testing plays a major role in software development, but it is expensive too. In short-term we can say that software testing is time consuming but important too.
2. In case of critical and important software likes flight control, control on nuclear, space satellite control may always involves prototyping. Such testing based on prototyping or simulation is very expensive.
Software development organization spends between 30-40% of total project/product effort on software testing. Software testing thus often consumes several resources, than any other phase in the software project.
Here are some factors that make software testing so expensive:
1. Software testing is carried out throughout the software development mechanism; naturally its cost is for all duration of the software project till validation tests.
The idea behind this is that if bugs are detected earlier, it saves lot of trouble later. In this way software testing is exists from the beginning and increases expenses.
The idea behind this is that if bugs are detected earlier, it saves lot of trouble later. In this way software testing is exists from the beginning and increases expenses.
2. In case of critical and important software likes flight control, control on nuclear, space satellite control may always involves prototyping. Such testing based on prototyping or simulation is very expensive.
Software testing varies from several organizations to organization. Several factors in these organizations affect testing.
The several factors are listed below:
The several factors are listed below:
1. Communication and relationships of people
2. Testing scope
3. Misunderstanding regarding life cycle of testing
4. When test plans are poorly developed
5. Big testing constraints
Conclusion:
At end we conclude that Software testing often consumes more resource, than any other phase of software development. Software Testing is a most important element about the Software Quality Assurance and represents final review, specification, design and coding.
Top down integration is primarily considering as an approach where modules are developed and testing of that modules always starting at the finest level of the programming hierarchy and continuing towards the lower levels.
There are few drawbacks to this procedure as well:
Top down strategy of integration testing is an incremental approach because we proceed one level at a time. It can be determine either in "depth first search" and in "breadth first search" manner.
So now the question arises what does depth and breadth mean?
Depth means we always proceed from the top level complete the way down to the lowest level.
Below is given the meaning of breadth.
Below is given the meaning of breadth.
What is the meaning about breadth?
Breadth on the other hand is different with depth so breadth means that we start at the top of the hierarchy and then steadily go to the next level. We develop and test entire modules at this level before continuing with another level.
Below given are some major benefits of top-down integration testing:
1. Having the framework, we can test major or supreme functions early in the development process.
2. At the same time, we can also test any interfaces that we have considered and thus obviously identify any errors in that area special or very early.
3. The supreme or major benefit of this practice is that we include a partially working framework to show to the clients and to the top management too.
This of course increases everybody's confidence in the development squad and also in the model itself.
TOP DOWN STRATEGY DRAWBACKS
There are few drawbacks to this procedure as well:
1. Impose stubs does not permit all the essential upward data flow.
2. Not enough data in the stubs to fee back to the calling module so this means the top-level modules cannot be really tested perfectly and every time the stubs are replaced with the real modules, the modules which are calling should be properly re-tested again for integrity.
Conclusion:
At end we conclude that this top down integration testing procedure allows us to originate or establish a framework of the system or product.
Now what is your viewpoint regarding top-down strategy of integration testing.
Use Case
|
Test Case
| |
1
|
Use Case is prepared by business analyst.
|
Test case is prepared by test engineer and in small companies sometimes it is prepared by quality analyst too.
|
2
|
Based on test cases use cases cannot be prepared means it is not derived from test cases.
|
Based on use cases test cases can be prepared means it is derived from use cases.
|
3
|
Use case describes step by step instructions means how to use functionality.
|
Test case verifies the functionality means it is as per the instructions mentioned in use case or not.
|
4
|
Use case cannot be executed means it is only designed.
|
We design the test cases and later execute them.
|
5
|
It is derived from the BRS (Business requirement specification.)
|
It is derived from the use case.
|
6
|
It is a pictorial representation of client requirements or you can say customer requirements.
|
It is not represented diagrammatically it is only documented in excel sheet and in big companies it is also documented in some test case management tools.
|
7
|
It is a document which always describes the flow of events of an application.
|
It is a document which always contains an action, event and an expected result of particular feature of an application.
|
8
|
Use Cases can be written by BA (business analyst.) on the basis of client requirements or customer requirements.
|
Test cases are written by test engineer or quality analyst on the basis of use case document.
|
9
|
It always tells us about the story of how people interact with a software system to achieve a goal.
|
It verifies the goal to see it is as per the instructions of use case or not.
|
Difference between GUI Testing and Usability Testing
GUI Testing
|
Usability testing
|
1. In GUI Testing tester tests the application front end design to see whether its meets the client requirements or not.
|
1. In Usability Testing tester tests that whether the application is user friendly or not by checking how easily user can access the application.
|
2. In GUI Testing we check whether the design and layout of application as per the standards and client requirements or not.
|
2. In Usability Testing we check whether the design and layout of application is easy to use or not means it is user friendly or not.
|
3. GUI Testing is more concerned with look and feel of the application means how people react and feel after look in to the application so its testing is done accordingly that.
|
3. Usability Testing is more concerned with easiness and user friendliness of the application means how people react after using the application means application is easy to use or not so it's testing is done accordingly that.
|
4. In GUI Testing tester tests the appearance of the software.
|
4. In Usability Testing tester tests the easiness to use the software.
|
5. GUI Testing is done to ensure it meets the design specifications like links, colors, fonts, font sizes, fields etc are displayed as specified in SRS or as specified in client requirements.
|
5. Usability Testing is done to ensure that the GUI is well designed and easy to use like links and buttons are easily clickable and leaving any of the mandatory field blank gives the proper message that please enter the xyz in mandatory field.
|
6. GUI Testing is done by keeping in mind the look and feel of application means how application looks.
|
6. Usability Testing is done by keeping the end user in mind.
|
7. It stands for Graphical User Interface. It is nothing its only confirm the design specifications with the application.
|
7. It is done to ensure that the GUI is well designed and easy to use.
|
8. It is done on different platforms to verify the Look and Feel Testing. (Look and Feel of the application).
|
8. It is done to verify how much the application is user friendly to an end user.
|
9. In GUI Testing, tester test whether the front end design of the system is meeting with project standards or not.
|
9. In Usability Testing, tester tests whether the control flow of the system is convenient for end user or not.
|
10. In this testing we just test the appearance of the application.
|
10. In this testing we test the interaction of functionality with the user is effective or not.
|
11. Example: Example includes colors, fonts, font sizes, buttons, links, icons, placement of data labels and fields etc. are displayed as specified or not.
|
11. Example: Example includes firstly displayed all mandatory fields, cursor positioning for enter the data into the right field, tab button should work easily etc.
|
12. In GUI Testing we only focus on the interface of the application.
|
12. Quality of product is depending on Usability Testing.
|
13. In this testing we test only the front end of the application.
|
13. In this Testing we test the overall working of application according to a non-technical user's point of view.
|
Soak testing is different type about performance testing in which tester always test the stability and response time of affecting application by request the designed load for a longer time.
Soak testing is sometimes also called as Endurance testing and longevity testing.
Soak Testing is the form of Performance Testing, which incorporate testing a system with expressive load extended over an expressive period of time, to discover how the system and product behaves under repeated use.
Example of soak testing:
Considering example in a banking environment large amount of load is expected at the deadline of every month, means on the time of banking closing days.
So tester always perform the soak testing on banking application to test huge levels of load for prolonged amount of time. So in banking application tester put the grand amount of load for prolonged amount of time like put load for 72hrs to 120 hrs, to check how application behaves during this load period.
Soak testing means running a system at huge levels of load for prolonged amount of time. A soak test would generally execute some times more transactions in an entire (full) day (or night) that intend be expected in a busy day, to distinguish any performance issues that appear after a immense number of transactions have been executed.
A soak test also called an endurance test is generally done to originate whether an application can handle with the continuous expected load. A soak test is also used to audit whether there is any performance degradation afterwards a long period of activity.
This standard of test can identify problems relating to memory allotment, log file handles, and database resource utilization. Typically problems are identified in shorter targeted performance tests.
So apart from soak testing it is precise crucial for us to know endurance testing.
Endurance Testing: This form of testing checks how durable the system is over an amount (period) of time. It applies a large but general load pattern of transactions to the system/product for a continuous period. Checks are invented during the run to watch if any subtle errors frame up over a period of clock which can disturbs the performance or integrity of the system.
Conclusion:
Soak Testing always provides a measure of systems stability over an extended period of time.
Bugs are a mismatch between expected result and actual result. Bugs play an important role in software testing.
In little we can say that bugs can be of diver's types which could be always effective in software testing. Software bugs pose a great threat to the software industry.
Why Bugs Occur in the Software?
Plentiful studies have been on very little projects to extremely large ones and the analysis shows various causes of bugs in the software, few of them are listed below: -
1. One of the extreme causes is the specification. In several cases, specifications are the largest producer of bugs. Either specifications are not written, specifications are not thorough enough, constantly changing or not communicated well to the development team.
1. One of the extreme causes is the specification. In several cases, specifications are the largest producer of bugs. Either specifications are not written, specifications are not thorough enough, constantly changing or not communicated well to the development team.
2. Another bigger reason is that software is always created by human beings. They know numerous things but are not expert and might make mistakes.
3. Further, there are deadlines to deliver the project on time. So increasing pressure and workload conduct in no time to check, compromise on quality and incomplete systems. So this leads to occurrence of Bugs.
Some common types of software bugs
1. Use of Division by zero
2. Infinite loops
3. Result of Arithmetic overflow or underflow
4. Always Exceeding array bounds
5. Always Use of an uninitialized variable
6. Result on Buffer overflow
7. Deadlock
8. Damage or loss of precision in type conversion
Conclusion:
At end we conclude that bugs found earlier in project and product always reduces the fixing cost.