Software Testing

Its very hard to measure the test coverage quality. review is very key thing in testing and each phase of testing review should be incorporate,testcases coverage should be cover with the scenario and scenario should be derived from requirement and this the flow of writing test cases and also review the test cases. Testcase should be written to have focus of risk and the static and dynamic technique implemented as the measurement of test cases is the fault found which is actully increase the confidence.for writing the test cases many thing needs to keep focus as company to company process would be different but the concept of test case coverage should be define with the requirement and all the possible combination. There are different type of test cases review process and its define as below #1. Before writing,understand the fundamental #2. Do self review and try to find the improvement not mistake #3. ask developer/technical expert for review. #4. do review updated test c...

Things to care when you report bug Understand your audience view point Write effective and easy understandable Bug title ( Summary ) Do not use long summary as its confuse to understand Write proper and all step Step should be clear with what input given Write the impact of the issue and output of current test cases Its recommend that  customer impact should be written In the as its easy to make priority

Spelling mistakes:  Sometimes, spelling mistake can create a lot of confusions or make a sentence difficult to understand. Grammar:  If grammar is not proper then test case can be interpreted in a wrong way, resulting in wrong results. Template format:  If proper template is followed then it becomes easy to add/modify test cases in future and test case plan looks organized. Standard/Guidelines:  While review process, it is very important to check whether all the standards and guideline are properly followed. Language used:   Test cases  should have a very simple language which is easy to understand. Functionality coverage:  It is highly recommended that all the functionality associated with the system under test should be covered so that major defects are not missed. Replication:  It refers to the duplicate test cases removal. It is possible that two or ...

How to review?  –  The following are the list of activities involved: Define the criteria – Have a checklist of what to look for? Perform the check Record your results Share, discuss and implement the changes required Version control the documents involved Sign off and use the doc as intended.

1. Fail to communicate Communication is key to Software development, and therefore also to Software testing. One of the most important skills a Tester needs to have is the ability to communicate well. He or she needs to be able to express what they are thinking or doing to many different audiences – Developers, Test Managers, Product Owners, etc., all of whom have a different view of the problem. If a tester isn’t aware of this, they’ll be in trouble pretty quick. 2. Try to fix the bug yourself This is a basic and fundamental rule of testing: don’t try to do the developers work. It’s his job to find the root causes of the problem by debugging and fixing it. Don’t mislead the developer by giving him wrong assumptions. As a tester you need to be precise and give exact information to the developers. 3. Assume you are a multi-tasking expert This is a “skill” people assume they have, but believe me, multitasking will not help you finish your work sooner. On the contrar...

Static Testing Dynamic Testing Testing done without executing the program Testing done by executing the program This testing does verification process Dynamic testing does validation process Static testing is about prevention of defects Dynamic testing is about finding and fixing the defects Static testing gives assessment of code and documentation Dynamic testing gives bugs/bottlenecks in the software system. Static testing involves checklist and process to be followed Dynamic testing involves test cases for execution This testing can be performed before compilation Dynamic testing is performed after compilation Static testing covers the structural and statement coverage testing Dynamic testing covers the executable file of the code Cost of finding defects and fixing is less Cost of ...

Static testing is the testing of the software work products manually, or with a set of tools, but they are  not executed . It starts early in the Life cycle and so it is done during the verification process. It does not need computer as the testing of program is done without executing the program.  For example:  reviewing, walk through, inspection, etc. Most static testing techniques can be used to ‘test’ any form of document including source code, design documents and models, functional specifications and requirement specifications.

Testing Perception Perception 1: Testing is Too Expensive There is a saying, pay less for testing during software development or pay more for maintenance or correction later. Early testing saves both time and cost in many aspects, however reducing the cost without testing may result in improper design of a software application rendering the product useless. Perception   2: Testing is Time-Consuming During the SDLC phases, testing is never a time-consuming process. However diagnosing and fixing the errors identified during proper testing is a time-consuming but productive activity. Perception   3: Only Fully Developed Products are tested No doubt, testing depends on the source code but reviewing requirements and developing test cases is independent from the developed code. However iterative or incremental approach as a development life cycle model may reduce the dependency of testing on the fully developed software. Perception   ...

There are seven principles of  testing . They are as follows: 1) Testing shows presence of bug but not absence of bug:  Testing can show the  defects  are present, but cannot prove that there are no defects. Even after testing the application or product thoroughly we cannot say that the product is 100% defect free. Testing always reduces the number of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness. 2) Exhaustive testing is impossible:  Testing everything including all combinations of inputs and preconditions is not possible. So, instead of doing the exhaustive testing we can use  risks  and priorities to focus testing efforts. For example: In an application in one screen there are 15 input fields, each having 5 possible values, then to test all the valid combinations you would need 30  517  578  125  (5 15 ) tests. This is very unlikely that the project ti...