Entries Tagged 'Basics of Software testing' ↓

In this post I am going to answer some of the questions asked by one of the reader Srinivas M.

1. In an application currently in production, one module of code is being modified. Is it necessary to re-test the whole application or is it enough to just test functionality associated with that module?

Vijay: Well, the answer is both. You will have to test the functionality of that module as well as the other modules. But you can differentiate on the stress to be given on the module to be tested.

I think this scenario will explain the answer to your question well.

If Module A is modified, Module B is depending on module A, and Module C is a general module independent of module A.
So in this case you will test the module A in depth to all test cases. Then your next stress will be on module B. Wait now what about module C? You will have to test this module as well but may be with less stress because module C is not depend on module A but may be depend on module B.

Again if you are a white box tester you probably know which modules will get affected and which modules should be tested. But as a black box tester you will need to do regression testing as well.

2. What is the most challenging situation you had during testing?

Vijay: A good question! When I switched my job some years back I was being asked the same question.
Well a good answer to this question is depends on each ones experience. If you came across any such a situation and found any interesting Bug that was difficult to find out or analyzed any project risk accurately before occurring then this could be the answer to this question.

Keep in mind that when answering such a question, be realistic and don’t overstress the situation.

3. What are you going to do if there is no Functional Spec or any documents related to the system and developer who wrote the code does not work in the company anymore, but you have system and need to test?

Vijay: A typical situation in Indian companies! Right? Due to high attrition rate
In this case fist you will need to do the exploratory testing of the product. In this testing you will come to know the system and its basic workflow. In exploratory testing you can also find some ‘blocker’ bugs that cause system to be crash.

If you are a white box tester then next step you can do is to see the different module code. By this you will know the test cases for different modules and relation of modules.

If you have any question please comment it below.

Sometimes Tester need common sense to test a application!!!

I am saying this because most of the times it is not possible to test the whole application within the specified time. In such situations it’s better to find out the risk factors in the projects and concentrate on them.

Here are some points to be considered when you are in such a situation:
1) Find out Important functionality is your project?
2) Find out High-risk module of the project?
3) Which functionality is most visible to the user?
4) Which functionality has the largest safety impact?
5) Which functionality has the largest financial impact on users?
6) Which aspects of the application are most important to the customer?
7) Which parts of the code are most complex, and thus most subject to errors?
Which parts of the application were developed in rush or panic mode?
9) What do the developers think are the highest-risk aspects of the application?
10) What kinds of problems would cause the worst publicity?
11) What kinds of problems would cause the most customer service complaints?
12) What kinds of tests could easily cover multiple functionalities?

Considering these points you can greatly reduce the risk of project releasing under less time constraint.

Feel free to ask me any testing query, resume tips or job help.

Is there any standard procedure to test the application as a whole? Or How can I test complete application right from the requirement gathering?

Here are the broad steps to test the application :These are the standard SQA peocesses to be followed in any application testing.

•  Marketing Requirements

 Review of the Objectives set for the Last Released Build
Objectives remaining to be completed are carried forward for the next release.

• Branching for the development cycle

• Objectives settings for the Major and customized releases

Target Date planned for the Releases and decision on the entire Project schedule that is required to achieve these target dates.

• A Detailed Project Plan and the release of design Specifications

This includes the decision on Design Specifications (Productwise), review of the design specs and development schedule. This involves QA during the phase of review.

• QA – Develop Test Plan based on Design Specifications

Test Plan : This is a top-level document that talks about how the product is going to be tested
This includes Objectives, Methodology adopted while testing, Features to be tested and not to be tested, risk criteria, testing schedule, cross-platform support and the resource allocation for testing.

Feature Test Plan : This document talks about how the testing is going to be carried out for each type of testing.

• QA – Functional Test Specifications

This document includes technical details (Software requirements) required prior to the testing. It is important from the tester’s point of view to understand and plan the technical resources prior to the testing.

Application Development : Considering the product features, tester has to make ready his/her own test suit.

• QA – Writing of Test Cases (CM)

- Smoke (BVT) test cases
- Sanity Test cases
- Regression Test Cases
- Extended Test Cases
- Negative Test Cases

• Development – Goes on Module by Module.

• Installers Binding and Building

- Installers are built around the individual product.
- Release Engg is responsible for releasing the Builds.
- Release Engg collects fresh/developed code from the developer’s initially/module wise.
- Installers have to take care of jar files updating, registry entries, and additional software installations.

• Build Procedure :

- A build includes Installers of the available products – multiple platforms.
- For each build one or 2 CDs are made/build the same are pushed to Pune/Chennai based on the priority.
- Each product build are received in the form of zip files under http://pun-qaftp/ftproot/QA-Builds ( Pune-Specific). The procedure goes along for Chennai. San Jose QA picks up builds from Nexus ( Build Specific Server )
- The same zip files need to be unzipped to get the desired installer and the same is put at Pun_fps1/QA/Builds folder. ( Pune-Specific)

• QA – Testing :

- Smoke Test (BVT) to check basic features of the product.
- Smoke Test results has to be posted on http://Chaquita which is an official site for posting Smoke
- Test results and to share the basic testing information.
- Prepare Smoke Test procedure.

• QA – Extensive testing :

- Testing of new features
- Document review
- Cross-platform testing
- Stress testing and memory leakage testing.

• QA- Bug Reporting :

- Use of Trackweb’s “Soffront” as the Bug Tracking tool.
- Further FET (Fixed Effectiveness testing) of the filed bugs.
- Exception study and verification.

• Development – Code freeze :

No more new features are added at this point.

• QA – Testing :

Candidate Builds and regression testing.

• QA- Media Verification :

CDs are cut for the released products and the product is installed using those CDs and it takes place in San Jose.

• Decision to release the product :

A review meeting to analyze the performance of the product, which is set, and the same is compared with the objectives set.

• Post-release Scenario :

One branch is kept for the post release modification and hence the product testing.
Post release review meeting to decide upon the objectives for the next release.

Way to become a good tester:

Remember these ten rules and I am sure you will definitely gain very good testing skill.

1. Test early and test often.
2. Integrate the application development and testing life cycles. You’ll get better results and you won’t have to mediate between two armed camps in your IT shop.
3. Formalize a testing methodology; you’ll test everything the same way and you’ll get uniform results.
4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
5. Use both static and dynamic testing.
6. Define your expected results.
7. Understand the business reason behind the application. You’ll write a better application and better testing scripts.
8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
9. Review and inspect the work, it will lower costs.
10. Don’t let your programmers check their own work; they’ll miss their own errors.

Automation Checklist

If you answer yes to any of these questions, then your test should be seriously considered for automation.

Can the test sequence of actions be defined?

Is it useful to repeat the sequence of actions many times? Examples of this would be Acceptance tests, Compatibility tests, Performance tests, and regression tests.

Is it possible to automate the sequence of actions?
This may determine that automation is not suitable for this sequence of actions.

Is it possible to “semi-automate” a test?
Automating portions of a test can speed up test execution time.

Is the behavior of the software under test the same with automation as without?
This is an important concern for performance testing.

Are you testing non-UI aspects of the program?
Almost all non-UI functions can and should be automated tests.

Do you need to run the same tests on multiple hardware configurations?
Run ad hoc tests (Note: Ideally every bug should have an associated test case. Ad hoc tests are best done manually. You should try to imagine yourself in real world situations and use your software as your customer would. As bugs are found during ad hoc testing, new test cases should be created so that they can be reproduced easily and so that regression tests can be performed when you get to the Zero Bug Build phase.) An ad hoc test is a test that is performed manually where the tester attempts to simulate real world use of the software product. It is when running ad hoc testing that the most bugs will be found. It should be stressed that automation cannot ever be a substitute for manual testing.

I am working on Search engine project for last 6 months and now I understood most of the functionality and search engine strategies.

When you work as a Manual tester then somewhere you feel to automate your work. Sometimes doing routine manual work bores you. So here comes the need of Automation.
So Automation is very helpful for the regression type of work, to avoid repeated manual work. Now I understood the need of Automation and I want to start with it, but from where shall I start is the big question.

Before starting the Automation of your project work you need to remember following points:

1. What is the type of my project? Is it a stand-alone project or a client – server project?
2. What is the size of my project? You can find size on various metrics like kilo line of code. 3. Is there repeated work in my project?
4. Time taken for My current Manual project testing
5. Error rate by Manual testing.

In next some posts I will discuss about the Advantage – Disadvantages of Manual and Automation testing, also the step-by-step process to automate your project work.