Software Testing is essential for the betterment of the application and software. But apart from this many of us do not know that Software Testing is most time consuming and difficult task to perform.
People still believe that Software Testing is an easy task anybody can do it easily but in reality Software Testing is opposite of it because it is not an easy task to perform. Software Testing is as difficult as developing software because now days it requires more human efforts, as everyone wants quality so doing Software Testing are become difficult because it takes lot of time and money.
Software Testing - Hard and Difficult
Performing Software Testing is considered as Difficult as well as hard too because of the following reasons which are shown below.
1. Software Testing is hard and difficult because we need to test the software/application for both valid and invalid inputs and in Software Testing we also check the performance parameters as well as functionality too.
2. Another reason for considering Software Testing hard as well as difficult because during the time of testing we always need to give the inputs in such a way that each and every line of the program/code is tested efficiently.
3. Another reason for being hard and difficult is that tester needs to give inputs randomly and ensure that the software/application never fails.
4. Another reason is that we need to test the software by keeping the user perspective in mind means by keeping in mind how end user is using it and check whether the error messages displayed properly or not.
5. Another main and clear reason is that we need to test the application/software by simulating the actual/real environment. Considering example if a database application has to be accessed by 200 users simultaneously, then it is not enough if you test the software/application for 5 0r 10 users and declare that application/software is working fine by leaving the software without checking all 200 users simultaneously.
6. Software Testing is considered as hard and difficult because in several cases, it is not almost possible to test the software/application in real/actual environment. Considering example how do you test the software that is used in a satellite launch vehicle or a missile? You can do the complete testing only in a simulated environment.
Your opinion
This is all I know about why Software Testing is considered as hard and difficult task to perform and if you know some more reasons than you can discuss with me in comments to help others so that proper guidance will be given to every people those who are in the field of Software Testing.
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.
Test cases of pen are given below: -
But keep one thing in mind that test cases for pen may vary if you have different requirements or set of requirements.
Below is given different test cases of pen which does not contain any requirements or specifications?
Test cases of pen are like that:
1. Verify the color of the pen.
2. Check GUI testing means logo of the pen maker.
3. Check Usability testing means grip of the pen.
4. Verify whether the pen is ballpoint pen or ink pen.
5. Check Integration Testing means cap of the pen should easily fit beside the body of the pen.
6. Check pen should be continuously in writing mode.
2. Check GUI testing means logo of the pen maker.
3. Check Usability testing means grip of the pen.
4. Verify whether the pen is ballpoint pen or ink pen.
5. Check Integration Testing means cap of the pen should easily fit beside the body of the pen.
6. Check pen should be continuously in writing mode.
Some Functional test cases for pen:
1. Check whether it writes on paper or not.
2. Verify whether the ink on the paper is belongs with the similar color as what we see in the refill.
Performance and load test cases for pen:
1. Verify how it performs when writing on wet paper.
2. Verify how it performs when writing on rough paper.
3. Verify how it performs when writing on hand because we occasionally do that
4. Check load test means when pen is pressed very hard against the tough surface then pen refill should not come out of the pen.
Negative test cases about pen:
1. Verify whether ink is available or not.
2. Check if ink is available, than the pen does not write on the paper.
3. Verify by bend the refill at multiple ends and then try to write with it.
4. Verify by dip the pen always in to the water and then write it again.
5. Check whether it write on leaves or not.
Additional test cases for pen:
1. Check usability testing means test by writing on a section of paper, Examine if you can write smoothly. It should not be writing and stopping among (with) breaks.
2. Check capability or reliability testing means Test the writing capacity (the amount of writing that is possible from a single refill) of the pen.
3. Check Robustness testing means Test wherever you can carry the pen in to your shirt and pent pocket using its cap. The cap distension should be solid enough to grip your pocket.
4. Check Compatibility testing means Test by writing on distinct types of surfaces like: rough paper, packing material, glass, leather, cotton, wood, plastic, metals like aluminum or iron, polythene sheet etc.
Conclusion
At end we conclude that apart from above mentioned test cases there are numerous test cases for pen but these above mentioned are the universal one.
There are numerous test cases of fan which are given below:
Test case 1: Check whether it moves or not.
Description: Ensure that fan should moves properly.
Expected result: Fan should be moving.
Test case 2: Check it should have minimum 3 blades.
Description: Ensure that length of fan blades should be considered to 3 blades.
Expected result: Length of fan blades should not be shorter than 3 blades.
Test case 3: Check it should be on when electric button (switch) is on.
Description: Ensure that fan should start working when electric switch is on.
Expected result: Fan should be on when electric button (switch) is on.
Test case 4: Check whether Speed of the fan definitely be controlled by the regulator.
Description: Ensure that speed of fan should be controlled.
Expected result: Fan speed should be controlled by the regulator.
Test case 5: Check it should be stop working once the electric switch off.
Description: Ensure that fan should stop working once the electric switch is off.
Test case 6: Check the proper "company name" should be displayed on fan or not.
Description: Always ensure that name of company should be properly displayed on fan.
Expected result; Proper name of company should be displayed on fan.
Test case 7: Check Fan should always work in clock-wise direction.
Description: Ensure that direction of fan should be in clock-wise.
Expected result: Fan should work in clock-wise direction.
Test case 8: Check the color of the fan blades.
Description: Always ensure that all the blades of fan have same color.
Expected result: Color of all the blades of fan should be of same color.
Test case 9: Check the fan during (while) in motion should not vibrate.
Description: Ensure that the fan during (while) in motion should not vibrate.
Expected result: Fan should not vibrate.
Test case 10: Check whether the blades should have decent distance from the ceiling.
Description: Ensure that fan blades should have decent distance from the ceiling.
Expected result: Fan blades should have decent distance.
Test case 11: Check the size of the fan blades.
Description: Always ensure that all the blades of fan have same size.
Expected result: Size of all the blades of fan should be of same size.
Test case 12: Check whether it operates in low voltage.
Description: Ensure that fan should properly operate in low voltage.
Expected result: Fan should be properly operated on low voltage.
Test case 13: Check whether speed varies when regulator adjusted.
Description: Ensure that speed of fan varies when we adjust the regulator.
Expected result: Speed of fan varies while adjusting the regulator.
Conclusion:
At end we conclude that above mentioned test cases are not based on any requirements or specifications. These test cases are without specifications and requirements.