Tuesday, September 7, 2010

Manual Software Testing:

What Is Software Testing?
Testing involves operation of a system or application under controlled conditions and evaluating the results. (eg, 'if the user is in interface A of the application while using hardware B, and does C, then D should happen’) The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection'. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they're the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization's size and business structure.

Write any attributes which will impact the testing process.

    • Maintainability
    •  Reliability
    •  Correctness
    •  Flexibility
What is software quality?
  ¡  Quality is frequently defined as meeting the customer’s requirement the first and every time.

What are the characteristics of Software Quality?
    Characteristics:-
¡  Transcendent – I know when I see it
¡  Product based – own desired feature
¡  User based – fitness for use
¡  Development and manufacturing based – conforms to requirement
¡  Value based – at an acceptable cost

Software development life cycle(SDLC).
¡  Information gathering
¡  Requirement Analysis
¡  Designing
¡  Coding
¡  Testing
¡  Implementation
¡  Final Release & Maintenance

Software testing life cycle(STLC)

¡  1. Test planning
¡  2. Test development
¡  3. Test execution
¡  4. Result analysis
¡  5. Bug reporting
¡  6. Preparation of reports




Testing lifecycle


Software Testing Life Cycle




 V Model Of Software Testing :-


SDLC  and  STLC  Life Cycle



Verification & Validation

¡  Verification
                                Although "verification" and "validation" at first seem quite similar in CMMI models, on closer inspection you can see that each addresses different issues. Verification confirms that work products properly reflect the requirements specified for them. In other words, verification ensures that "you built it right."  
¡  Validation
                Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that "you built the right thing."

What are 5 common problems in the Software Development process?
¡  Poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems.
¡  Unrealistic schedule - if too much work is crammed in too little time, problems are inevitable.  
¡  Insufficient testing - no one will know whether or not the program is any good until the customer complaints or systems crash.
¡  Futurities - requests to pile on new features after development is underway; extremely common.
¡  Miscommunication - if developers don't know what's needed or customers have erroneous expectations, problems are guaranteed.

Why to test the software?

¡  To uncover the bugs
¡  Improve the quality prior to sales
¡  To check the performance of application in
¡  To ensure that application is as per user requirement
¡  To reduce the failure cost
¡  To reduce the risk
¡  To build the confidence in to software

What makes a good test engineer?
            A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

What makes a good Software QA engineer?
The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is important for inspections and reviews.
What makes a good QA or Test manager?
¡  A good QA, test, or QA/Test(combined) manager should:
¡  be familiar with the software development process
¡  be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a somewhat 'negative' process (e.g., looking for or preventing problems)
¡  be able to promote teamwork to increase productivity
¡  be able to promote cooperation between software, test, and QA engineers
¡  have the diplomatic skills needed to promote improvements in QA processes
¡  have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are not being adhered to
¡  have people judgment skills for hiring and keeping skilled personnel
¡  be able to communicate with technical and non-technical people, engineers, managers, and customers.
¡  be able to run meetings and keep them focused





There are many potential pitfalls to manual software testing, including:

Manual testing is slow and costly. Manual tests do not scale well. Manual testing is not consistent or repeatable. Lack of training. Testing is difficult to manage. This article will cover five "best practices" recommendations to help avoid the pitfalls associated with manual software testing.

Be Thorough in Test Design and Documentation

In designing the tests, there should be agreement among the business staff, product and project managers, developers, and testers on test coverage. This can be documented as test requirements in a test plan. With this documentation, management can have visibility of the test coverage and know that the right areas are being tested. This then becomes an important management tool in managing testing.



--------------------------------------------------------------------------------



The goal is to find the easiest way to document as many test cases as possible without having the test effort turn into a documentation effort.



--------------------------------------------------------------------------------



Have the test requirements and test cases peer-reviewed, just as you would have software design reviews. The software development staff and the test staff should jointly develop the test designs, as they have complementary skill sets and knowledge bases.

In manual testing, like in other processes, several factors influence the effectiveness of the tests, including the completeness of the test cases and the thoroughness of the documentation. The goal should be to maximize management's understanding of the testing by spending the appropriate resources in each area, within the overall resource constraints. If you do not document your tests, you will not understand the coverage or software quality as revealed by the tests, and you also will not be able to determine that the test team is testing features that are the most important to your development team and customers. However, if you document everything related to each test case, you will not have time to do as many tests as you should. Documenting test cases can get expensive.

Automate Turnkey Tests as Much as Possible

There are various tools available that support test automation. When it is cost-effective and time-efficient to do so, there is no excuse for not automating software tests. The benefit of automation is that the testing becomes less burdensome, and less likely to be scrimped on when under pressure. This also makes the testing easier to manage.





Manage the Test Activities Well

Do this as closely, and by establishing as full a procedure, as the software development activities. Be sure that the project plan has sufficient resources and time allocated to testing so that it does not get short shrift.

Rank Test Cases in Order of Importance, by Impact on Quality, by Risk, by How Often the Feature Tested is Used, or Some Other Related Metric

A goal should be to run all important test cases, but if there are resource constraints that prevent all test cases from being run, then the ranking will enable the important test cases to be run. This provides the maximum impact of the testing with the available resources. In manual software testing, you are always short on time. There should be an agreement or signoff procedure on the ranking and the coverage of the tests.

Have a Separate Budget with Proper Funding Allocated for Testing

Just as there is a budget allocated for the software code development, there should be a budget allocated for testing. Be sure that this budget is well-funded. Watch how much is spent on testing, and what the return on investment is.

Even when you have a good test automation program in place, you will still need to do some manual testing. The usability testing, for example, requires human involvement. However, manual testing is not the solution for short-cycle, high-volume test challenges. For example, if you have a daily build process where you need to run smoke-tests to assess the changes and stability of the software from build to build, these tests can be high-volume and short-cycle. Manual testing cannot solve your testing problem in this case.

Conclusion

To summarize the preceding in a simple list, the five best practice suggestions for manual software testing success are:

Be thorough in test design and documentation Automate turnkey tests as much as possible Manage the test activities well Rank test cases in order of importance, by impact on quality, by risk, by how often the feature tested is used, or some other related metric