Skip to content

Top 35 Interview Q/A’s

NOTE: Few of the questions are only asked for freshers.

1. Explain SDLC(Software Development Life Cycle).

2. Explain Waterfall model.

3. Explain Spiral model.

4. Explain V&V model.

5. Explain Prototype model.

6. Explain Hybrid model (spiral + prototype, V&V + prototype).

7. Explain Black box testing.

8. Explain Functional testing.

9. Explain Integration testing and Types of it.

10. Explain System testing.

11. Explain Re-spin in test life cycle.

12. What is a Patch file, Explain.

13. What is Acceptance testing, Explain.

14. What is Hot fix?

15. What is Root cause analysis?

16. Explain Short term release.

17. What is Smoke testing?, When and why we perform Smoke testing?

18. What is Ad-hoc testing?, When and why we perform Ad-hoc testing?

19. What is Exploratory testing?, When and why we perform Exploratory testing?

20. What is Globalization testing?, What are the types? When do we perform Globalization testing? and Why?

21. What is Performance testing? What are the types? When do we perform Performance test? and Why?

22. What is Usability testing?, When do we perform Usability testing and Why?

23. What is Compatibility testing?, When do we perform Compatibility testing and Why?

24. What is Test case, When do we write Test cases and Why?

25. What is Sanity? When do we perform Sanity? and Why?

26. What is Regression testing, What are the types of it. When do we perform Regression testing?

27. Difference between Re-testing and Regression testing?

28. Explain STLC.

29. Explain Test Plan.

30. Explain Defect distribution matrices.

31. Explain Test Efficiency matrices.

32. Explain Test Efficiency.

33. Explain Defect Life Cycle.

34. What is Severity.

34. What is Priority.

35. Explain Test case design techniques and types of it.

Answers for the above questions are as below..

1. Explain SDLC(Software Development Life Cycle).

It is a procedure to develop the software. It is a process of creating or altering systems and the models and methodologies that people use to develop these systems.

2. Explain Waterfall model.

 

1. Requirements Collection –

  • Done by Business Analysts and Product Analysts
  • Gathering requirements
  • Translates business language into software language

Feasibility Study –

  • Done by software team consisting of project managers, business analysts, architects, finance, HR and Developers but not testers

2. Design –

There are 2 stages in design,

HLD – High Level Design

LLD – Low Level Design

HLD – Gives the architecture of the software product to be developed and is done by architects and senior developers

LLD – Done by senior developers. It describes how each and every feature in the product should work and how every component should work. Here, only the design will be there and not the code.

3. Coding / Programming –

  • Done by all developers – seniors, juniors, freshers
  • This is the process where we start building the software and start writing the code for the product.

4. Testing 

  • Done by test engineers
  • It is the process of checking for all defects and rectifying it.

5. Installation 

Done by installation engineers, To install the product at a client’s place for using after the software has been developed and tested.

For ex, consider the example of a software to be developed and installed at XYZ bank.

6. Maintenance 

Here as the customer uses the product, he finds certain bugs and defects and sends the product back for error correction and bug fixing.

Bug fixing takes place

Minor changes like adding, deleting or modifying any small feature in the software product

100 % testing is not possible –because, the way testers test the product is different from the way customers use the product.

Drawbacks of Waterfall Model :-

In waterfall model, backtracking is not possible i.e, we cannot back and change requirements once the design stage is reached.

Advantages of waterfall model :- Requirements do not change nor does design and code, so we get a stable product.

Applications of waterfall model :-

Used in – developing a simple application

– for short term projects

– whenever we are sure that the requirements will not change

For ex, waterfall model can be used in developing a simple calculator as the functions of addition, subtraction etc and the numbers will not change for a long time.

3. Explain Spiral model.

— Image to be added —

The spiral model is shown in the figure above.

Ra — Requirements analysis of module A. Similarly with Rb, Rc, Rd.

Da – Design of module A. Similarly with Db, Dc, Dd

Ca – Coding of module A. Similarly with Cb, Cc, Cd

Ta – Testing of module A. Similarly with Tb, Tc, Td

In Spiral model, The software product is developed in small modules. Let us consider the image displayed above in developing a software product \\\”X\\\”. \\\”X\\\” is built by integrating modules a,b,c and d.

The module A –Requirements of the module is collected first and then the module is designed. The coding of module A is done after which it is tested for defects and bugs.

The module B – Once module A has been built,We start the same process for module B. But while testing module B, we test for 3 conditions – 1)test module B 2)test integration of module B with A 3)test module A.

The module C –After building module A,B, we start the same process for module C. Here we test for the following conditions – 1) test module C, B, A 2) test for integration of C and B, C and A, A and B.

And thus the cycle continues for different modules. Thus in the above example, module B can be built only after module A has been built correctly and similarly for module C.

Advantages of Spiral Model :-

1)  Requirement changes are allowed.

2)  After we develop one feature / module of the product, then only we can go on to develop the next module of the product.

Drawbacks of Spiral Model :-

1) Traditional model and thus developers only did testing job as well.

2) If any urgent changes to be done in any previously built model, The whole project has to be started from the beginning.

Applications of Spiral Model :-

1)Whenever there is dependency in building the different modules of the software, then we use Spiral Model.

2) Whenever the customer gives the requirements in stages, we develop the product in stages.

4. Explain V&V model.

— Image to be added —

This model came up in order to overcome the drawbacks of waterfall model –Here testing starts from the requirement stage itself.

The V & V model is as shown in the above figure.

1)   In the first stage, the client send the CRS(Customer Requirement Specification) to both developers and testers. The developers translate the CRS to the SRS(Software Requirement Specification).

The testers do the following tests on CRS:

1. Review CRS 

a. Conflicts in the requirements

b. Missing requirements

c. Wrong requirements

2. Write Acceptance Test plan

3. Write Acceptance Test cases

The testing team reviews the CRS and identifies mistakes and defects and send it to the development team for correcting the bugs. The development updates the CRS and continues developing SRS simultaneously.

2 ) In the next stage, the SRS is sent to the testing team for review and the developers start building the HLD(High Level Design) of the product. The testers do the following tests on SRS,

1.  Review SRS against CRS

a. Every CRS is converted to SRS

b. CRS not converted properly to SRS

2. Write System Test plan

3. Write System Test case

The testing team reviews every detail of the SRS if the CRS has been converted properly to SRS.

3 ) In the next stage, the developers start building the LLD(Low Level Design) of the product. The testers do the following tests on HLD,

1. Review HLD

2. Write Integration test plan

3. Write Integration test case

4 ) In the next stage, the developers start with the coding of the product. The testing team carries out the following tasks,

1. Review LLD

2. Write Functional test plan

3. Write Functional Test case

After coding, the developers themselves carry out unit testing or also known as white box testing. Here the developers check each and every line of code and make sure as the code is correct. After whitebox testing, the software product is sent to the testing team which tests the software product and carries out Functional testing, Integration testing, System testing and acceptance testing and finally deliver the product to the client.

Advantages of V&V model:-

1) Testing starts in very early stages of product development which avoids downward flow of defects which in turn reduces lot of rework

2) Testing is involved in every stage of product development

3) Deliverables are parallel/simultaneous –As developers are building SRS, testers are testing CRS and also writing Acceptance Test Plan and Acceptance Test Case and so on. Thus as the developers give the finished product to testing team, the testing team is ready with all the test plans and test cases and thus the project is completed fast.

4) Total investment is less – as there is no downward flow of defects. Thus there is less or no re-work

Drawbacks of V&V model:-

1) Initial investment is more – because right from the beginning testing team is needed

2) More documentation work – because of the test plans and test cases and all other documents

Applications of V&V model:-

1) For long term projects

2) For complex applications

5. Explain Prototype model.

The requirements are collected from the client in a textual format. The prototype of the software product is developed.

The prototype is just an image / picture of the required s/w product. The customer can look at the prototype and if he is not satisfied, then he can request more changes in the requirements.

Prototype testing means developers/ testers are checking if all the components mentioned in requirements are existing or not.

— Image to be added —-

From “REQUIREMENT COLLECTION” to “CUSTOMER REVIEW”, textual format has been converted to image format. It is simply extended requirement collection stage. Actual design starts from “DESIGN” stage.

Prototype development was earlier done by developers. But, now it is done by web designers/content developers. They develop prototype of the product using simple ready-made tools. Prototype is simply an image of the actual product to be developed.

Advantages of Prototype model:-

1) In the beginning itself, we set the expectation of the client.

2) There is clear communication b/w development team and client as to the requirements and the final outcome of the project.

3) Major advantage is –Customer gets the opportunity in the beginning itself to ask for changes in requirements as it is easy to do requirement changes in prototype rather than real applications. Thus costs are less and expectations are met.

Drawbacks of Prototype model:-

1) There is delay in starting the real project

2) To improve the communication, there is an investment needed in building the prototype.

Applications of prototype model:-

We use this model when,

1) Customer is new to the s/w

2) When developers are new to the domain

3) When customer is not clear about his own requirement

There are 2 types of prototype Model,

1. Static Prototype –Entire prototype of the requirement is stored in a word document with explanation and snapshots and instructions on how to go about building the s/w, how the finished product will look like and its working etc.

2. Dynamic Prototype –Similar to a browser, but we can’t enter any information. Only the features are available without entering data. It’s like a dummy page, made out of HTML with tags and links to different pages representing features of the project

6. Explain Hybrid model (spiral + prototype, V&V + prototype).

It combines 2 or more models and modify them as per business requirements.

A) Hybrid model of Spiral and Prototype development models

— Image to be added —

We go for this model when,

1) Whenever there is dependency, we go for this hybrid model

2) When the customer gives requirement in stages, we develop the product in stages using this      hybrid model.

3) When the customer is new to the s/w domain

4) When developers are new to the domain

5) When customer is not clear about his own requirements

B) Hybrid model of V&V and Prototype model

— Image to be added —

We go for this model when,

1) Testing starts from early stages of product development which avoids downward flow of defects, thus reducing re-work.

2) When customer is expecting a very high quality product within stipulated time frame because every stage is tested and developers and testing team work in parallel.

3) When client and developers are both new to the domain

4) When customer is not clear about his own requirements

In this hybrid model, the testing team is involved in testing the prototype.

7. Explain Black box testing.

It is verifying the functionality (behaviour) against requirement specifications.

Advantages of Black box testing:-

  • Well suited and efficient for large code segments.
  • Code Access not required.
  • Clearly separates user\\\’s perspective from the developer\\\’s perspective through visibly defined roles.
  • Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language or operating systems.

Disadvantages of Black box testing:-

  • Limited Coverage since only a selected number of test scenarios are actually performed.
  • Inefficient testing, due to the fact that the tester only has limited knowledge about an application.
  • Blind Coverage, since the tester cannot target specific code segments or error prone areas.
  • The test cases are difficult to design.

8. Explain Functional testing.

Also called component testing. Testing each and every component thoroughly (rigorously) against requirement specifications is known as functional testing.

For example, Let us consider an editor application here what we usually test few cases such as editing, deleting, printing etc.

Types of Functional testing:-

1. Positive Functional testing – Testing of the application by applying positive input and also checking the output.

Ex: – Here if we take an application which has one edit field which is made for entering of Mobile number, In this case the tester always takes positive values (lets take it as 9 digit) and test the functionality.

2. Negative Functional testing – Testing of the application by applying some negative scenarios and testing as how the application behaves on wrong inputs. The only thing we test is as weather the app is capable of providing proper error msgs to the user or not.

Ex – Lets take an application which takes input as proper email id, In this case the tester inputs wrong email id\\\’s, wrong inputs and check the application behaviour .

9. Explain Integration testing and Types of it.

Testing the data flow between two features is known as integration testing.

Ex- In Gmail, Entering of valid email and password, New logged in page has to be displayed.

Types of Integration testing:

1. Incremental integration testing –

Take two modules. Check if data flow between the two is working

fine. If it is, then add one more module and test again. Continue like

this. Incrementally add the modules and test the data flow between

the modules.

There are two ways,

a) Top-down Incremental Integration Testing

Incrementally add the modules and test the data flow between the modules. Make sure that the module that we are adding is child of previous one. Child3 is child of child2 and so on.

b) Bottom – up Incremental Integration Testing – 

Testing starts from last child upto parent. Incrementally add the modules and test the data flow between modules. Make sure that the module you are adding is the parent of the previous one.

2. Non – incremental Integration Testing:-

We use this method when,

a) When data flow is very complex

b) When it is difficult to identify who is parent and who is child.

It is also called Big – Bang method.

Combine all the modules at a shot and start testing the data flow between the modules. The disadvantage of this is that, a) We may miss to test some of the  interfaces  b)  Root cause analysis of the defect is difficult identifying the bug where it came from is a problem. We don’t know the origin of the bug.

10. Explain System testing.

It is end-to-end testing wherein testing environment is similar to the production environment.

End – to – end testing:-

Here, we navigate through all the features of the software and test if the end business / end feature works. We just test the end feature and don’t check for data flow or do functional testing and all.

We start System Testing

a) When the minimum number of features are ready  b) basic functionality of all the modules must be working c) testing environment should be similar to production environment

11. Explain Re-spin in test life cycle.

When the first build comes in, immediately we find a bug and send it immediately to the development-team. Thus, immediately we find a bug within a cycle. If another build comes within a cycle where the bug is fixed, then we call it as Re-spin.

We find Re-spin –When the test engineer finds blocker defects / critical defects. For ex, if the login feature itself is not working in gmail, then the test engineer cannot continue with his testing and it has to be fixed immediately – thus re-spin comes into picture.

12. What is a Patch file, Explain.

Patch – is a piece of software which has only modified programs.

We get patch files whenever there is a Issue in a build and the fix for that issue will not affect other modules of the software. The patch file will recover only that particular affected area, Hence there is no need of a new build.

13. What is Acceptance testing, Explain.

Acceptance Testing can be defined as – end-to-end testing done by engineers sitting in customer’s place. Here, they take real time scenarios and check whether the software works or not. Here also, we are able to take real time business scenarios because the end-users know how the business flow works.

We are getting more and more builds for Acceptance Testing means,

  1. The product quality which is delivered to customers is not good. Development and testing both are not good.
  2. After receiving the s/w, customer is getting more and more ideas, so he is asking for more and more changes
  3. The requirement which was given in the beginning is not clear.

Acceptance testing can be performed as per below cases:

Case 1: The developed and tested product will be given to the customer say for example \\\”Sony\\\” is making a software for \\\”Honda\\\”, In this case \\\”Sony\\\” will send/share the final product to \\\”Honda\\\”. Here \\\”Honda\\\” company will be having few test engineers who will perform Acceptance testing and share the results to \\\”Sony\\\”.

Case 2: Here the product will be tested in the production side only i.e., as per our example \\\”Sony\\\”. In this case \\\”Honda\\\” will send few of their test engineers to test @ the production place and produce the results.

Case 3: Sometimes there will be no test engineers available at the customers place so at this time the customer asks the production side as to allocate few test engineers for Acceptance testing and these guys has to go to the customers place and test the build and generate the test results. And also there is a possibility as customer side if they don\\\’t have test engineers they will give the build or product to their customers or end users to test and generate the results.

Acceptance testing will be done after System testing is done.

The actual test flow will be Functional testing >> Integration testing >> System testing >> Acceptance testing.

14. What is Hot fix?

In production environment, whenever the client finds critical bugs – developers fix the bugs –small team of test engineers test it – reinstall the software –client starts using the new software. This entire process is known as Hot fix. It takes approximately few hours to 1 day.

For example,               If the login feature itself is not working at the production environment, then the client immediately sends it for fixing which is done asap.

15. What is Root Cause Analysis(RCA)?

The 5-Why’s and other RCA methods of “causal mapping” are typically illustrated in visual form as cause-effect graphs, with the Fishbone Diagram, or Ishikawa diagram. Taking into account a range of causal factors—from processes to people to materials and equipment—they begin with a problem and work back to its causes (or vice versa, as in the image below), generally looking something like this:

16. Explain Short term release.

Whenever there is a quick fix or any impotent enhancement to be done the dev team will release a new build within one cycle. This is called as Short term release and this release has to be done as soon as possible. Time duration for these types of releases will be less.

17. What is Smoke / Skim testing?, When and why we perform Smoke testing?

Testing the basic or critical features of an application before doing thorough testing or rigorous testing is called as smoke testing.

It is also called Build Verification Testing – because we check whether the build is broken or not.

Whenever a new build comes in, we always start with smoke testing, because for every new build –there might be some changes which might have broken a major feature ( fixing the bug or adding a new feature could have affected a major portion of the original software).

In smoke testing, we do only positive testing – i.e, we enter only valid data and not invalid data.

Why we do Smoke testing ?

  • Just to ensure that product is testable
  • Do smoke testing in the beginning – catch bugs in basic features –send it to development team so that development team will have sufficient time to fix it.
  • Just to ensure that product is installed properly.

In early stages of product development, doing smoke testing fetches more number of bugs. But, in later stages of product development, if you do smoke testing –the number of bugs that you are going to catch in smoke testing will be very less. Thus, gradually the effort spent on smoke testing is less.

18. What is Ad-hoc testing?, When and why we perform Ad-hoc testing?

Testing the application randomly is called Ad-hoc testing. Ad-hoc testing is also called as Monkey testing / Gorilla testing.

Why we do Ad-hoc testing ?

1) End users use the application randomly and he may see a defect, but professional test engineer uses the application systematically  so he might not find the same defect. In order to avoid this scenario, Test Engineer should test the application randomly (i.e., behave like end user and test).

2) Development team looks at the requirements and build the product. Testing Team also look at the requirements and do the testing. By this method, Testing Team may not catch many bugs. They think everything works fine. In order to avoid this, we do random testing behaving like end-users.

3) Ad-hoc testing is a testing where we don\\\’t follow the requirements (we just randomly check the application). Since we don’t follow requirements, we don’t write test cases.

4) To some how break the product. To find more number of issues.

When to do Ad-Hoc testing ?

1) Whenever we are free, we do Ad-hoc testing, i.e., dev\\\’s develop the app and give it to testing team. If testing team is given 15 days for Test Cases execution in that he spend 12 days doing it and another 3 days he does ad-hoc testing. We must always do ad-hoc testing in the last because we always 1st concentrate on customer satisfaction.

19. What is Exploratory testing?, When and why we perform Exploratory testing?

Exploring the application, As how it works, what are the flows of the application, what all features it has, etc. and we write test cases based on it.

We perform Exploratory testing when we do not have requirements specifications for a project.

The reason why we perform exploratory testing, is as we will be not having requirements specification and some how we  have to write the test cases.

20. What is Globalization testing?, What are the types? When do we perform Globalization testing? and Why?

Developing the application for multiple languages is called globalization and testing the application which is developed for multiple languages is called globalization testing.

There are 2 types of globalization testing,

  • Internationalization Testing ( I18N testing )
  • Localization Testing ( L10N testing )

 

Internationalization Testing ( I18N testing ) – Checking the content is in right language and at right place is called as Internationalization testing. The name I18N came as there are 18 letters in between I and N. Here the imp thing we test is as the meaning of the text should not change and also the alignment is not changed cos of the language change.

Localization Testing ( L10N testing )- Format testing is nothing but Localization testing (OR) Testing done for format specification according to  region / country is called L10N testing.

The different format testing we do in L10N testing,

a) Currency Format testing

Here, we do not worry about the functionality of the format ( like $ is converted to Rs or not ). We only test whether the $ should be in the first or the last.

Ex : 100$, $100, Rs100. The standard should be as per country standards.

b) Date Format testing

Here, check whether the date format is according to its country format. This is also L10N testing.

Ex : In US, date format is : MM – DD – YY

In India, date format is : DD – MM – YYYY

c) PinCode Format testing

There are countries having Pincode with characters like AB100. Here,

Checking for the format in pincode is L10N testing.

Checking whether AB is translated to Chinese is I18N testing.

d) Image Format testing

In image – only name on the image can be changed –the image cannot be changed. Thus we must have multiple images depending on the country. When we click on Ukraine, it goes to Ukraine server, takes the contents and also selects Ukrainian image and thus contents are displayed in Ukraine.

21. What is Performance testing? What are the types? When do we perform Performance test? and Why?

Testing the stability and response time of an application by applying load is called as Performance testing.

There are 4 types in performance testing:-

1. Load testing – Testing the stability and response time by applying load which is equal or less than designed number of users.

2. Stress testing – Testing the stability and response time by applying load which is more than designed number of users.

3. Soak testing – Testing the stability and response time by applying load continuously for particular period of time.

4.Volume testing –  Testing the stability and response time of an application while processing huge amount of data.

Whenever there is a testing of hybrid application is going on, Performance testing is a must.

The reason why we need to perform this testing is to make the application more stable and to make sure the application is not broken due to more load or stress.

22. What is Usability testing?, When do we perform Usability testing and Why?

Testing the user friendliness of an application is called Usability testing.

Given below are some of the parameters we look into for testing. In this most of them are not measurable,

  1. Speed
  2. Help
  3. Navigation should be simple
  4. Compatibility
  5. Look & feel
  6. Features
  7. Location of components

1. Speed – How speed the application reacts to the user inputs. It should be so quick as user must not feel any lag in it.

2. Help – How good is the help part in the application is described. By reading the Help part the user has to understand about the whole application and its functionality.

3. navigation should be simple – Lets take an example of any shopping website, Here if the user wants to buy a product it should has to be purchased in very few clicks.

4. Compatibility – Lets take an example, as one software is built for windows 7 it should has to work in windows 8 too. There must be forward compatibility. If you take example of android then if an app is built for Gingerbread then it should work in Lollipop too.

5. Look and Feel – No mater which application you develop Look and feel does matters a lot. The application should be such that it should be pleasant looking [ suppose if we have red color text in yellow background, definitely we don’t feel like using it ] and make a feel to the end-user to use it.

6. Features – The application should provide all sorts of features which is necessary.

7. Location of components – This also plays an important role. For example, Lets take an example of Google playstore application, Here search icon is always on the top of every screen/page that the user opens. So this makes the user easy to search any data whenever he wishes to.

Usability testing can be performed any time, But mainly it will be concentrated when we get a new build or on the arrival of First build.

The main reason why we perform this testing is to make sure the application is user-friendly or not.

23. What is Compatibility testing?, When do we perform Compatibility testing and Why?

Testing the functionality of an application in different software and hardware environment is called Compatibility testing.

We perform Compatibility testing when we have a software which is built for different platforms. Lets take an example of rhbroms website, the page has to be loaded with all sorts of browsers available (Ex: Chrome, FireFox, IE, Opera etc..). And also the webpage has to be displayed in mobile phones too. The website has to be designed in such a way that it should be compatible with all browsers and systems.

The main reason why we perform compatibility testing is to make sure that software is working fine in all sort of platforms.

24. What is Test case, When do we write Test cases and Why?

Test case is a document which covers all possible scenarios to test all the feature(s).

A test case is a document, which has a set of test data, preconditions, expected results and postconditions, developed for a particular test scenario in order to verify compliance against a specific requirement.

In other words you can say as its a documentation which is written by using test scenarios. Conversion of test scenarios into a document which contains test steps to make test engineer easy for execution.

We write test cases when customer gives requirements – developer start developing and they say they need about 4 months to develop this product –during this time, testing team start writing test cases –once it is done, they send it to test lead who reviews it and adds some more scenarios –developers finish developing the product and the product is given for testing –the test engineer then looks at the test cases and starts testing the product –the test engineer never looks at the requirements while testing the product –thus testing is consistent and does not depend on the mood and quality of the test engineer.

The main reason to write test cases is –

  • To have better test coverage –cover all possible scenarios and document it, so that we need not remember all the scenarios
  • To have consistency in test case execution –seeing the test case and testing the product
  • To avoid training every new engineer on the product –when an engineer leaves, he leaves with lot of knowledge and scenarios. Those scenarios should be documented, so that new engineer can test with the given scenarios and also write new scenarios.
  • To depend on process rather than on a person.

25. What is Sanity? When do we perform Sanity? and Why?

Sanity testing follows narrow and deep approach with detailed testing of some limited features.

For more please refer to answer 17. As in my opinion both smoke and sanity are one and the same. Just change is in the definition.

26. What is Regression testing, What are the types of it. When do we perform Regression testing?

Testing the unchanged features to make sure that it is not broken because of the changes (changes means – addition, modification, deletion or defect fixing).

When the development team gives a build, chances are there they would have done some changes. That change might affect unchanged features. So, Testing the unchanged features to make sure that it is not broken because of the changes is called Regression Testing.

Types of Regression testing –

  1. Unit Regression Testing
  2. Regional Regression Testing
  3. Full Regression Testing

1. Unit Regression Testing – 

Testing only the modified features is called Unit Regression Testing. Lets take one example as We are getting one new build and we know that there is a bug fix and that bug fix is not going to affect any other existing modules, So at this time we go for unit testing and just check the fixed issue and not related modules. Hence the name Unit Regression testing.

2. Regional Regression Testing –

Testing the changes and impact regions is called Regional Regression Testing. Here we not only test the fixed bug but we will also test few regional modules too, to make sure as they are not affected cos of the bug fix. Here the imp thing to notice is the test eng has to be well versed with the software so that he will know which all regional modules might get affected cos of the fixed bug.

3. Full Regression Testing –

Testing the changes and all the remaining features is called Full Regression Testing. He no matter which issue/bug has been fixed we have to test all the remaining modules too, to make sure as the all remaining features/modules are not crashed cos of a build containing more bug fixes.

We do full regression testing when changes are more in the build. mostly on the core part of the application.

27. Difference between Re-testing and Regression testing?

Re-Testing –Developer fixes the bug(or makes some changes) and gives the product for testing. We are testing only the fixed bug(or changed areas) i.e, we are testing only the defect fixes. We are re-validating the defect.

Regression – go through answer 26.

28. Explain STLC.

Testing itself has many phases i.e is called as STLC(Software Test Life Cycle).

STLC is a part of SDLC. The flow of STLC is as below:-

1. Requirements

2. Write Test Plan

3. Write Test Case

3a. Identify all possible test scenarios

3b. Write test case

3c. Review test case

3d. Fix review comments

4. Traceability matrix

5. Test execution

6. Defect tracking

7. Prepare Test Execution report

8. Retrospect Meeting.

Explanation for the above is given below,

1. Requirements – This is the first phase, Here Collection of requirements is done, Usually done by BA(Business Analyst)

2. Test Plan- Is a document which derives all future activities of the project. All future testing activities is planned and put into a document and this document is known as Test Plan. It contains –number of engineers needed for the project, who should test which feature, how the defects must be communicated to the development team, when we should start and finish writing test cases, executing test cases, what are the types of testing we use to test for the application etc.

3. Write test case – We write test cases for each feature. These test cases are reviewed, and after all mistakes are corrected and once the test cases are approved – then they are stored in the test case repository.

4. Traceability Matrix – It is a document which ensures that every requirement has a test case. Test cases are written by looking at the requirements and test cases are executed by looking at the test cases. If any requirement is missed i.e, test cases are not written for a particular requirement, then that particular feature is not tested which may have some bugs. Just to ensure that all the requirements are converted, traceability matrix is written.

5. Test Execution – After completion of writing the Test Cases based on given requirements, Its time to execute them. Test Engineers uses the already written Test Cases and execute them. Test Cases will be divided and allocated to each test engineer.

6. Defect tracking – Any bug found by the testing team is sent to the development team by using some tool (Ex: Bugzilla). This bug has to be verified by the testing team if it has been fixed by the developers or not.

7. Prepare test execution report – Sent to the customer –Contains a list of bugs(major, minor and critical), summary of test pass, fail etc and when this is sent,according to the customer – the project is over.

Test Execution Report is prepared after every test cycle and sent to dev team, testing team, management team and customer (depends if it is a fixed bid project or time & material bid project).

The last Test execution report of the last test cycle is always sent to the customer. And this means that the project is over according to the customer.

8. Retrospect Meeting – (also called Post Mortem Meeting / Project Closure Meeting) The Test Manager calls everyone in the testing team for a meeting and asks them for a list of mistakes and achievements in the project.

This is done by test lead or test manager. Here, the manager documents this retrospect meeting and stores it in QMS (Quality Management System). It is a folder, where inside this folder, there is another folder called Retrospect folder and here this excel sheet document is stored. When we get new project, while we write the test plan we will open this retrospect file and will try and implement the good practices and correct the mistakes.

29. Explain Test Plan.

Test plan is a document which drives all future testing activities.

Test plan is prepared by Test manager(20%), Test Engineer(20%) and by Test Lead(60%).

There are 15 sections in a test plan.

1. Objective

2. Scope

3. Approach

4. Testing Methodologies

5. Assumptions

6. Risks

7. Backup plan

8. Schedule

9. Test Automation

10. Test Environment

11. Defect tracking

12. Test Stop criteria

13. Entry and Exit criteria

14. Deliverables

15. Roles and Responsibilities

16. Templates

1. Objective – It gives the aim of preparing test plan i.e, why are we preparing this test plan.

2. Scope – In the planing stage, we decide which feature to test and which not to test due to the limited time available for the project.

3. Approach – 

The way we go about testing the product in future,

a) By writing high level scenarios

b) By writing flow graphs

a) By writing high level scenarios – For example, if we are testing www.gmail.com here we will write the high level scenarios as below:-

1. Open gmail.com

2. Login to any account and check whether mail is being sent to desired email address or no.

b) By writing flow graphs –

We write flow graphs because of the following advantages,

i. Merging is easy

ii. Coverage is easy

Flow graphs are written because writing high level scenarios is time consuming.

4. Testing Methodologies

Depending upon the application, we decide what type of testing we do for the various features of the application. We should also define and describe each type of testing we mention in the testing methodologies so that everybody (dev team, management, testing team) can understand, because testing terminologies are not universal.

For example, we have to test www.google.com, we do the following types of testing,

Smoke testing, Functional testing, Integration testing, System testing, Adhoc testing Compatibility testing, Regression testing, Globalization testing, Accessibility testing, Usability testing and Performance testing.

For standalone applications, like Skype, we do the following types of testing,

Smoke testing, Functional testing, Integration testing, System testing, Adhoc testing Compatibility testing, Regression testing, Globalization testing, Accessibility testing, Usability testing, Reliability testing, Recovery testing and Installation / Uninstallation  testing.

5. Assumptions –When writing test plans, certain assumptions would be made like technology, resources etc.

6. Risks – If the assumptions fail, risks are involved. Like if any shortage of resources happens what action can be taken and all are to be considered in this phase.

7. Backup plan –To overcome the risks, a contingency plan has to be made. At-least to reduce the percentage from 100% to 20%.

In the project, the assumption we have made is that all the 3 test engineers will be there till the completion of the project and each are assigned modules A, B, C respectively. The risk is one of the engineers may leave the project mid-way.

Thus, the mitigation plan would be to allocate a primary and secondary owner to each feature. Thus,one engineer quits –the secondary owner takes over that particular feature and helps the new engineer to understand their respective modules.

Always assumptions, risks, mitigation plan are specific to the project.

The different types of risks involved are,

Ø Resource point of view

Ø Technical point of view

Ø Customer point of view

8. Schedule –  This section contains –When exactly each activity should start and end? Exact date should be mentioned and for every activity, date will be specified.

9. Test Automation – 

Here we have to check the below –

1. Features to be automated – Which all features can be automated will be decided here.

2. Features not to be automated – Which all features which can be performed only by manual methods are written here.

3. Which automation tool – Here we decide as which tool can be used for the particular project, Based on the project we decide the automation tool, For Ex: If it is a web based project then we choose selenium. Or if it is an android based application we can go for Robotium or Monkeyrunner.

10. Test Environment – Here we decide the Hardware and Software part, As what all the Hardware / Software has to be given to the test engineer to test the product. Particular to software part which software tool has to be used to deploy the project to the device has to be decided.

11. Defect tracking – In this section, we mention – How to communicate the defects found during testing to the development team and also how development team should respond to it. We should also mention the priority of the defect –high, medium, low.

Defect tracking tool – We mention the name of the tool we will be using to track the defects.

12. Test Stop criteria – We decide to stop the project when – 1. The product is good. 2. The product is Bad.

13. Entry and Exit criteria – 

Entry criteria comes to picture once the following holds good –

A) Test cases should be ready.

B) Product should be installed with proper test environment.

C) Test data should be ready.

D) Resources should be available.

Exit criteria comes to picture once the following holds good –

A) Based on %age test execution.

B) Based on %age test pass.

C) Based on severity.

The Entry and Exit criteria is checked for each and every stage like Functional, Integration, System testing.

14. Deliverables – 

It is the output from the testing team. It contains what we will deliver to the customer at the end of the project. It has the following sections,

14.1 Test Plan

14.2 Test Cases

14.3 Test Scripts

14.4 Traceability Matrix

14.5 Defect Report

14.6 Test Execution Report

14.7 Graphs and Metrics

14.8 Release Note

15. Roles and Responsibilities –  

When a Big project comes, it’s the Test Manager who writes the test plan. If there are 3 small projects, then Test Manager allocates each project to each Test lead. The Test lead writes the test plan for the project which he is allocated.

Usually the below happens –>>

* Test Manager

Ø Writes or reviews test plan

Ø Interacts with customer, development team and management

Ø Sign off release note

Ø Handle issues and escalations

Ø ….

Ø ….

Ø ….

 

* Test Lead

Ø Writes or reviews test plan

Ø Interacts with development team and customers

Ø Allocates work to test engineers and ensure that they are completing the work within the schedule

Ø Consolidate reports sent by Test Engineers and communicate it to development team, customers (if it is a time&material project) and management

Ø …

Ø …

Ø …

 

* Test Engineer 1

Ø Review test plan

Ø Write test cases for trend analysis

Ø Asset survey

Ø Write traceability matrix

Ø Review test cases written for sales and purchase modules

Ø Execute test cases written for trend analysis, asset survey, registration (old module developed in previous release. Adding trend analysis and asset survey has affected. Old module has been affected. So do regression testing)

Ø Perform compatibility testing using Internet Explorer, Mozilla Firefox and Google Chrome in  Windows XP and Windows Vista

Ø Prepare test execution report and communicate it to Test lead.

Ø ….

Ø ….

Ø …

 

* Test Engineer 2

Ø Set up and install the product

Ø Identify test cases to be automated

Ø Automate identified test cases using QTP

Ø Execute and maintain automation scripts

Ø …

Ø …

16. Templates –  

This section contains all the templates for the documents which will be used in the project. Only these templates will be used by all the test engineers in the project so as to provide uniformity to the entire project. The various documents which will be covered in the Template section are,

· Test Case

· Traceability Matrix

· Test Execution Report

· Defect Report

· Test Case Review Template

· …

· …

· …

 

To be Continued …

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *