Mallik asks:

What type of database (SQL) questions asked in interviews for test engineer position (not for database tester)?

This depends on many factors whether these questions are for testing positions at entry level or for experienced testing professionals. The depth of database interview questions depend on the experience of the candidate.

Irrespective of the position, candidate should always be clear and confident about the database concepts. For most software testing positions you need to have database knowledge to perform some database checks. Almost all applications need an interaction with database.

Let’s consider the database interview questions for entry-level software testing positions. For entry level testing positions generally following questions can be asked in interviews:

1) Basic and to some extent nested SQL queries to fetch data from database tables.
2) Examples of database statements for: Create Database, Create table and Drop Table.
3) Concept of “Primary Key”, “Foreign Key” and DB index
4) Examples of Select, Insert, Delete, Alter and Update SQL statements.
5) SQL joins (Inner Join, Left Join, Right Join and Full join) with examples.
Practice SQL join queries on dummy tables and see results.

For experienced level software testing positions, database interview questions depend on the job requirement. For such positions interviewers expect detailed database knowledge from candidates.

One more important point – If you get questions on database SQL queries, never say that “You get all query statements to be executed from developers”. It’s ok to say that you get help from developers to write complex SQL queries, but finally you manage by your own.

Shariff asks:

What is Test Strategy?

In simple words – Test strategy means “How you are going to test the application?” You need to mention the exact process/strategy that you are going to follow when you will get the application for testing.

I see many companies follow test strategy template very strictly. Even without any standard template you can keep this test strategy document simple but still effective.

Simple Tips to Write Test Strategy Document:

1) Include product background in test strategy document. In first paragraph of your test strategy document answer – Why stakeholders want to develop this project? This will help to understand and prioritize things quickly.
2) List all important features you are going to test. If you think some features are not part of this release then mention those features under “Features not to be tested” label.
3) Write down the test approach for your project. Clearly mention what types of testing you are going to conduct?
I.e. Functional testing, UI testing, Integration testing, Load/Stress testing, Security testing etc.
4) Answer questions like: How you are going to perform functional testing? Manual or automation testing? Are you going to execute all test cases from your test management tool?
5) Which bug tracking tool you are going to use? What will be the process when you will find a new bug?
6) What are your test entry and exit criteria?
7) How you will track your testing progress? What metrics are you going to use for tracking test completion?
8 ) Task distribution – Define roles and responsibilities of each team member.
9) What documents you will produce during and after testing phase?
10) What all risk you see in test completion?

If you answer all these questions, I think your test strategy document should be ready!

Ayyappang asks:

I want some more ISTQB questions and papers. Please send me these papers as it will be very helpful for my study

I think I have written many posts earlier on ISTQB sample papers and mock test. You can access all these papers and online mock test on below page:
- Sample ISTQB papers and mock tests

Also I have listed some papers for download on our Resources page.
- ISTQB sample papers with answers for practice

Here are some more resources for ISTQB exam preparation:
- ISTQB Foundation Exam Format & Guidelines to Solve Papers

I hope this will be helpful for you ISTQB exam preparation.
If readers are having some sample ISTQB papers please share with us!

If you want to ask any question please post your question in comment section of this post.

If you like this post bookmark & share it with friends.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
What Types of Database Questions are Asked in Interview for Testing Positions? – Testing Q&A Series

Thank you so much!

For success of any project test estimation and proper execution is equally important as the development cycle. Sticking to the estimation is very important to build good reputation with the client.

Experience play major role in estimating “software testing efforts”. Working on varied projects helps to prepare an accurate estimation for the testing cycle. Obviously one cannot just blindly put some number of days for any testing task. Test estimation should be realistic and accurate.

In this article I am trying to put some points in a very simple manner, which are helpful to prepare good test estimations. I am not going to discuss the standard methods for test estimations like testing metrics, instead I am putting some tips on – How to estimate testing efforts for any testing task, which I learned from my experience.

Factors Affecting Software Test Estimation, and General Tips to Estimate Accurately:

1) Think of Some Buffer Time
The estimation should include some buffer. But do not add a buffer, which is not realistic. Having a buffer in the estimation enables to cope for any delays that may occur. Having a buffer also helps to ensure maximum test coverage.

2) Consider the Bug Cycle
The test estimation also includes the bug cycle.  The actual test cycle may take more days than estimated. To avoid this, we should consider the fact that test cycle depends on the stability of the build. If the build is not stable, then developers may need more time to fix and obviously the testing cycle gets extended automatically.

3) Availability of All the Resources for Estimated Period
The test estimation should consider all the leaves planned by the team members (typically long leaves) in the next few weeks or next few months. This will ensure that the estimations are realistic. The estimation should consider some fixed number of resources for test cycle. If the number of resources reduces then the estimation should be re-visited and updated accordingly.

4) Can We Do Parallel Testing?
Do you have some previous versions of same product so that you can compare the output? If yes, then this can make your testing task bit easier. You should think the estimation based on your product version.

5) Estimations Can Go Wrong – So re-visit the estimations frequently in initial stages before you commit it.
In early stages, we should frequently re-visit the test estimations and make modification if needed. We should not extend the estimation once we freeze it, unless there are major changes in requirement.

6) Think of Your Past Experience to Make Judgments!
Experiences from past projects play a vital role while preparing the time estimates. We can try to avoid all the difficulties or issues that were faced in past projects. We can analyze how the previous estimates were and how much they helped to deliver product on time.

7) Consider the Scope of Project
Know what is the end objective of the project and list of all final deliverables. Factors to be considered for small and large projects differ a lot. Large project, typically include setting up test bed, generating test data, test scripts etc. Hence the estimations should be based on all these factors. Whereas in small projects, typically the test cycle include test cases writing, execution and regression.

8 ) Are You Going to Perform Load Testing?
If you need to put considerable time on performance testing then estimate accordingly. Estimations for projects, which involve load testing, should be considered differently.

9) Do You Know Your Team?
If you know strengths and weaknesses of individuals working in your team then you can estimate testing tasks more precisely. While estimating one should consider the fact that all resources may not yield same productivity level. Some people can execute faster compared to others. Though this is not a major factor but it adds up to the total delay in deliverables.

And finally tip number 10.
Over To You!
This test estimation tip is purposefully left blank so that you can comment your best estimation techniques in below comment section.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Software Test Estimation – 9 General Tips on How to Estimate Testing Time Accurately

Thank you so much!

As testing is the last part of the project, it’s always under pressure and time constraint. To save time and money you should be able to prioritize your testing work. How will prioritize testing work? For this you should be able to judge more important and less important testing work. How will you decide which work is more or less important? Here comes need of risk-based testing.

What is Risk?
“Risk are future uncertain events with a probability of occurrence and a potential for loss”

Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work.

In this article I will cover what are the “types of risks”. In next articles I will try to focus on risk identification, risk management and mitigation.

Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories.

Categories of risks:

Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:

• Wrong time estimation
•  Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.
•  Failure to identify complex functionalities and time required to develop those functionalities.
•  Unexpected project scope expansions.

Budget Risk:

•  Wrong budget estimation.
•  Cost overruns
•  Project scope expansion

Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:

•  Failure to address priority conflicts
•  Failure to resolve the responsibilities
•  Insufficient resources
•  No proper subject training
•  No resource planning
•  No communication in team.

Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:

•  Continuous changing requirements
•  No advanced technology available or the existing technology is in initial stages.
•  Product is complex to implement.
•  Difficult project modules integration.

Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:

•   Running out of fund.
•   Market development
•   Changing customer product strategy and priority
•   Government rule changes.

These are all common categories in which software project risks can be classified. I will cover in detail “How to identify and manage risks” in next article.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Types of Risks in Software Projects

Thank you so much!

Testing Checklist:
1 Create System and Acceptance Tests [ ]
2 Start Acceptance test Creation [ ]
3 Identify test team [ ]
4 Create Workplan [ ]
5 Create test Approach [ ]
6 Link Acceptance Criteria and Requirements to form the basis of
acceptance test [ ]
7 Use subset of system test cases to form requirements portion of
acceptance test [ ]
8 Create scripts for use by the customer to demonstrate that the system meets
requirements [ ]
9 Create test schedule. Include people and all other resources. [ ]
10 Conduct Acceptance Test [ ]
11 Start System Test Creation [ ]
12 Identify test team members [ ]
13 Create Workplan [ ]
14 Determine resource requirements [ ]
15 Identify productivity tools for testing [ ]
16 Determine data requirements [ ]
17 Reach agreement with data center [ ]
18 Create test Approach [ ]
19 Identify any facilities that are needed [ ]
20 Obtain and review existing test material [ ]
21 Create inventory of test items [ ]
22 Identify Design states, conditions, processes, and procedures [ ]
23 Determine the need for Code based (white box) testing. Identify conditions. [ ]
24 Identify all functional requirements [ ]
25 End inventory creation [ ]
26 Start test case creation [ ]
27 Create test cases based on inventory of test items [ ]
28 Identify logical groups of business function for new sysyem [ ]
29 Divide test cases into functional groups traced to test item inventory [ ] 1.30 Design data sets to correspond to test cases [ ]
31 End test case creation [ ]
32 Review business functions, test cases, and data sets with users [ ]
33 Get signoff on test design from Project leader and QA [ ]
34 End Test Design [ ]
35 Begin test Preparation [ ]
36 Obtain test support resources [ ]
37 Outline expected results for each test case [ ]
38 Obtain test data. Validate and trace to test cases [ ]
39 Prepare detailed test scripts for each test case [ ]
40 Prepare & document environmental set up procedures. Include back up and
recovery plans [ ]
41 End Test Preparation phase [ ]
42 Conduct System Test [ ]
43 Execute test scripts [ ]
44 Compare actual result to expected [ ]
45 Document discrepancies and create problem report [ ]
46 Prepare maintenance phase input [ ]
47 Re-execute test group after problem repairs [ ]
48 Create final test report, include known bugs list [ ]
49 Obtain formal signoff [ ]

Source: Jarvis and Crandall, Inroads to Software Quality, Prentice-Hall, 1997, p. 323.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Testing Checklist

Thank you so much!

Here I focus on software Testing actual working process in the companies. As of now I got good experience of software testing career and day to day testing activities.  So I will try to share more practically rather than theoretically.

Whenever we get any new project there is initial project familiarity meeting. In this meeting we basically discuss on who is client? what is project duration and when is delivery? Who is involved in project i.e manager, Tech leads, QA leads, developers, testers etc etc..?

From the SRS (software requirement specification) project plan is developed. The responsibility of testers is to create software test plan from this SRS and project plan. Developers start coding from the design. The project work is devided into different modules and these project modules are distributed among the developers. In meantime testers responsibility is to create test scenario and write test cases according to assigned modules. We try to cover almost all the functional test cases from SRS.  The data can be maintained manually in some excel test case templates or bug tracking tools.

When developers finish individual modules, those modules are assigned to testers.  Smoke testing is performed on these modules and if they fail this test, modules are reassigned to respective developers for fix. For passed modules manual testing is carried out from the written test cases. If any bug is found that get assigned to module developer and  get logged in bug tracking tool. On bug fix tester do bug verification and regression testing of all related modules. If bug passes the verification it is marked as verified and marked as closed. Otherwise above mentioned bug cycle gets repeated.(I will cover bug life cycle in other post)

Different tests are performed on individual modules and integration testing on module integration. These tests includes Compatibility testing i.e testing application on different hardware, OS versions,  software platform, different browsers etc. Load and stress testing is also carried out according to SRS. Finally system testing is performed by creating virtual client environment. On passing all the test cases test report is prepared and decision is taken to release the product!

So this was a brief outline of process of project life cycle.

Here is detail of each step what testing exactly carried out in each software quality and testing life cycle specified by IEEE and ISO standards:

Review of the software requirement specifications

Objectives is set for the Major releases

Target Date planned for the Releases

Detailed Project Plan is build. This includes the decision on Design Specifications

Develop Test Plan based on Design Specifications

Test Plan : This includes Objectives, Methodology adopted while testing, Features to
be tested and not to be tested, risk criteria, testing schedule, multi-
platform support and the resource allocation for testing.

Test Specifications
This document includes technical details ( Software requirements )
required prior to the testing.

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

Development – Modules developed one by one

Installers Binding: Installers are build around the individual product.

Build procedure :
A build includes Installers of the available products – multiple platforms.

Testing
Smoke Test (BVT)  Basic application test to take decision on further testing

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

Bug Reporting
Bug report is created

Development – Code freezing
No more new features are added at this point.

Testing
Builds and regression testing.

Decision to release the product
Post-release Scenario for further objectives.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
What is actual testing process in practical or company environment?

Thank you so much!

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.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
What if there isn’t enough time for thorough testing

Thank you so much!

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.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
SQA Processes. How to Test complete application?

Thank you so much!

Q. When to stop testing?

Answer:
a) When all the requirements are adequately executed successfully through test
cases
b) Bug reporting rate reaches a particular limit
c) The test environment no more exists for conducting testing
d) The scheduled time for testing is over
e) The budget allocation for testing is over]

Q. Your company is about to roll out an E-Commerce application. It is not
possible to test the application on all types of browsers on all platforms and
operating systems. What steps would you take in the testing environment to
reduce the business risks and commercial risks?

Answer:
Compatibility testing should be done on all browsers (IE, Netscape, Mozilla etc.)
across all the operating systems (win 98/2K/NT/XP/ME/Unix etc.)]

Q. What’s the difference between priority and severity?

Answer:
“Priority” is associated with scheduling, and “severity” is associated with standards.
“Priority” means something is afforded or deserves prior attention; a precedence
established by order of importance (or urgency). “Severity” is the state or quality of
being severe; severe implies adherence to rigorous standards or high principles and
often suggests harshness; severe is marked by or requires strict adherence to
rigorous standards or high principles, e.g. a severe code of behavior. The words
priority and severity do come up in bug tracking. A variety of commercial, problemtracking/
management software tools are available. These tools, with the detailed
input of software test engineers, give the team complete information so developers
can understand the bug, get an idea of its ’severity’, reproduce it and fix it. The fixes
are based on project ‘priorities’ and ’severity’ of bugs. The ’severity’ of a problem is
defined in accordance to the customer’s risk assessment and recorded in their
selected tracking tool. A buggy software can ’severely’ affect schedules, which, in
turn can lead to a reassessment and renegotiation of ‘priorities’.]

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Priority and Severity

Thank you so much!