I am nervous before the interview. Just before I entered into the Interview room, I thought about the Krishna training classes. Ofcourse that gives me more confidence. For the first three mins while I am explanining about my first project, I am little nervous. From the fifth min onwards, I talked to them comfortably (as if I am talking to my friends) but having presence of mind with confidence.

     Here are some of my interview questions during my interview. I thought that these questions might help some of your students in their job search.

2.     Explain about your last project??

3.     Explain about your role in the last project??

4.     What are your Positives??

5.     What frustrates you??

6.    7.     What drives you? ?

8.     Did u work on any databases other than relational data base?

9.     Did you use TOAD for mySQL server??

10.  What does rank() in oracle do??

11.  Difference between System testing and User acceptance testing??

12.  What is ETL?? Do you know any tools for ETL?? Did you work on ETL??

13.  What does your previous manager tells me about you??

14.  What is your team size in the last project??

15.  Scale your database skills on a scale of 1-5 with 5 being highest?

16.  What testing do you like System testing or UAT testing??

17.  I told them that I had more System testing experience, How can I do the UAT with system testing experience??

18.  Explain about your role as UAT (From one of my titles in my resume)??

19.  How can you do UAT, if you don't have user specified requirements( Question for the above answer)??

20.  I do not have previous experience in Mortgage industry, how can I do it now?

21.  What are the SQL Statements I used in my previous project?

22.  Did you prepare Test plan documents in its entirety (Instead of bits and pieces)??

23.  What are the documents/Artifacts that you prepared during testing process??

24.  How did you use QTP in your project( I specified using QTP in one of my projects in my resume), Explain??

25.  Did you do any flat file testing other than xml testing using SOAP UI in one project??

26.  What are your Negatives?

27.  How did I work on my negatives, and while working on it did I miss any deadlines (For my answer to the above question)??

28.  Did u prepare any RTM ??

29.  Did you prefer to work on long projects or (short projects and move between different projects)??

30.  Did you work on Mainframes?? If you need to work on Mainframes, can u work??

31.  Did you have any previous experience as a BA(Because of specifying analyzed requirements in one of my project)??

32.  What do you know about our Company??

33.  I answered all of the questions. At the end, they told me that UAT testing at this company involves lot of Database testing. So, I told them that I want to add a point by saying that my expertise is in Database testing.

34.  It was a panel interview from two managers and one test lead. Because the two managers are looking for tester in their teams. Duration of the interview is about 45 mins.

You do not have Permission to view this Post

Acceptance Testing

Large scale software projects often have a final phase of testing called “Acceptance Testing”. Acceptance testing forms an important and distinctly separate phase from previous testing effortsand its purpose is to ensure that the product meets minimum defined standards of quality prior to .it being accept by the client or customer.

This is where someone has to sign the cheque.

Often the client will have his end-users to conduct the testing to verify the software has been implemented to their satisfaction (this is called “User Acceptance Testing” or “UAT”). Often UAT tests processes outside of the software itself to make sure the whole solution works as advertised. While other forms of testing can be more ‘free form’, the acceptance test phase should represent

a planned series of tests and release procedures to ensure the output from the production phase reaches the end-user in an optimal state, as free of defects as is humanly possible. In theory Acceptance Testing should also be fast and relatively painless. Previous phases of testing will have eliminated any issues and this should be a formality. In immature software development, the Acceptance Test becomes a last trap for issues, back-loading the project with risk. Acceptance testing also typically focusses on artefacts outside the software itself. A solution often has many elements outside of the software itself. These might include : manuals and documentation; process changes; training material; operational procedures; operational

 performance measures (SLA's).

These are typically not tested in previous phases of testing which focus on functional aspects of  the software itself. But the correct delivery of these other elements is important for the success of the solution as a whole. They are typically not evaluated until the software is complete because they require a fully functional piece of software, with its new workflows and new data requirements, to evaluate.

Unit, Integration and System testing

The first type of testing that can be conducted in any development phase is unit testing.

In the UNIT TESTING, discrete components of the final product are tested independently before being assembled into larger units. Units are typically tested through the use of ‘test harnesses’ which simulate the context into which the unit will be integrated. The test harness provides a number of known inputs and measures the outputs of the unit under test, which are then compared with expected values to determine if any issues exist.

In INTEGRATION TESTING smaller units are integrated into larger units and larger units into theoverall system. This differs from unit testing in that units are no longer tested independently but in groups, the focus shifting from the individual units to the interaction between them.

At this point “stubs” and “drivers” take over from test harnesses.
A stub is a simulation of a particular sub-unit which can be used to simulate that unit in a larger assembly. For example if units A, B and C constitute the major parts of unit D then the overall  assembly could be tested by assembling units A and B and a simulation of C, if C were not complete. Similarly if unit D itself was not complete it could be represented by a “driver” or a simulation of the super-unit.

As successive areas of functionality are completed they can be evaluated and integrated into the
overall project. Without integration testing you are limited to testing a completely assembled
product or system which is inefficient and error prone. Much better to test the building blocks as
you go and build your project from the ground up in a series of controlled steps.
System testing represents the overall test on an assembled software product.

SYSTEM TESTING is particularly important because it is only at this stage that the full complexity of the product is present. The focus in systems testing is typically to ensure that the product responds correctly to all possible input conditions and (importantly) the product handles exceptions in a controlled and acceptable fashion. System testing is often the most formal stage of testing and more structured.

The SIT or Test Team [SIT means SYSTEM INTEGRATION TESTING]

In large organizations it is common to find a “SIT” or independent test team. SIT usually stands for “Systems Integration Testing” or “Systems Implementation Testing” or possibly “Save It, Testing!” And is the role of this team unit, system testing or integration testing?

Well, nobody really knows. The role of the SIT team usually is not unit, integration nor system testing but a combination of all three. They are expected to get involved in unit testing with developers, to carry through the integration of units into larger components and then to provide end-to-end testing of the systems.

Sometimes the expectation is that the SIT team will become the companies Quality Assurance team, even though they have no direct influence on the way software is developed. The assumption is that by increasing the length and rigour of testing it will improve the quality of released products – and so it does. But it does nothing to increase the quality of built products – so it's not really QA. In the best of worlds, this team can act as an agent of change. It can introduce measures and processes which prevent defects from being in written into the code in the first place; they can work with development teams to identify areas which need fixing; and they can highlight successful
improvements to development processes.

In the worst of worlds the pressure on software development drives longer and longer projects with extended test cycles where huge amounts of defects are found and project schedules slip. The testing team attracts blame for finding defects and for long testing cycles and nobody knows how to solve the problem.

Alpha and Beta Testing

There are some commonly recognized milestones in the testing life cycle.Typically these milestones are known as “alpha” and “beta”. There is no precise definition for what constitutes alpha and beta test but the following are offered as common examples of what is meant by these terms

Alpha – enough functionality has been reasonably completed to enable the first round of (end-to-end) system testing to commence. At this point the interface might not be complete and the system may have many bugs.

 Beta – the bulk of functionality and the interface has been completed and remaining work is aimed at improving performance, eliminating defects and completing cosmetic work. At this point many defects still remain but they are generally well understood.

 Beta testing is often associated with the first end-user tests.

 The product is sent out to prospective customers who have registered their interest in participating in trials of the software. Beta testing, however, needs to be well organized and controlled otherwise feedback will be fragmentary and inconclusive. Care must also be taken to ensure that a properly prepared prototype is delivered to end-users, otherwise they will be disappointed and time will be wasted.

Verification and Validation

Testers often make the mistake of not keeping their eye on the end goal. They narrow their focus to the immediate phase of software development and lose sight of the bigger picture. Verification tasks are designed to ensure that the product is internally consistent. They ensure that the product meets the specification; the specification meets the requirements and so on.

 The majority of testing tasks are verification – with the final product being checked against some kind of reference to ensure the output is as expected.
For example, test plans are normally written from the requirements documents and from the specification. This verifies that the software delivers the requirements as laid out in the technical and requirement specifications. It does not however address the ‘correctness’ of those requirements!

 On a large scale project I worked on as a test manager, we complained to the development team thatour documentation was out of date and we were having difficulty constructing valid tests. TheyGrumbled but eventually assured us they would update the specification and provide us with a new version to plan our tests from.
When I came in the next day, I found two programmers sitting at a pair of computer terminals. While one of them ran the latest version of the software, the other would look over their shoulder and then write up the onscreen behavior of the product as the latest version of the specification! When we complained to the development manager she said “What do you want? The spec is up to

date now, isn’t it?” The client, however, was not amused; they now had no way of determining what the program was supposed to do as opposed to what it actually did.

Validation tasks are just as important as verification, but less common.

Validation is the use of external sources of reference to ensure that the internal design is valid, i.e.it meets users expectations. By using external references (such as the direct involvement of endusers) the test team can validate design decisions and ensure the project is heading in the correctdirection. Usability testing is a prime example of a useful validation technique.

 A Note on the 'V-model'

There exists a software testing model called the V-model, but I won't reproduce it here since I thinkit is a terrible model. It illustrates different phases of testing in the SDLC, matching a phase of testing to a phase of requirements/design. I don't like it because it emphasizes verification tasks over validation tasks. Just like the waterfall model it relies on each phase being perfect and will ultimately only catch errors at the very end of the cycle. And just like the waterfall model there is an updated version which

attempts to rectify this but only serves to muddy the waters. But the V-model does illustrate the importance of different levels of testing at different phases of theproject. I leave it as an exercise for the reader to uncover it.

Regression vs. Retesting

You must retest fixes to ensure that issues have been resolved before development can progress.So, retesting is the act of repeating a test to verify that a found defect has been correctly fixed.Regression testing on the other hand is the act of repeating other tests in 'parallel' areas to ensurethat the applied fix or a change of code has not introduced other errors or unexpected behavior.

 For example, if an error is detected in a particular file handling routine then it might be corrected by a simple change of code. If that code, however, is utilized in a number of different places throughout the software, the effects of such a change could be difficult to anticipate. What appears to be a minor detail could affect a separate module of code elsewhere in the program. A bug fix could in fact be introducing bugs elsewhere.

You would be surprised to learn how common this actually is. In empirical studies it has been estimated that up to 50% of bug fixes actually introduce additional errors in the code. Given this, it's a wonder that any software project makes its delivery on time.

Better QA processes will reduce this ratio but will never eliminate it. Programmers risk introducing casual errors every time they place their hands on the keyboard. An inadvertent slip of a key that replaces a full stop with a comma might not be detected for weeks but could have serious repercussions.

Regression testing attempts to mitigate this problem by assessing the ‘area of impact’ affected by change or a bug fix to see if it has unintended consequences. It verifies known good behavior after a change.

It is quite common for regression testing to cover ALL of the product or software under test.Why? Because programmers are notoriously bad at being able to track and control change in their software. When they fix a problem they will cause other problems. They generally have no idea of the impact a change will make, nor can they reliably back-out those changes. If developers could, with any certainty, specify the exact scope and effects of a change they made then testing could be confined to the area affected. Woe betide the tester that makes such an assumption

however!

Incremental Development

Note that not all iterations need be complete, fully functional software. Nor should they

Necessarily focus on the same areas of functionality. It is better to deliver separate 'increments' of functionality and assemble the whole project only at the conclusion of the production phase. This way you can take partial steps towards your completed goal. Each unit can be individually developed, tested and then bolted together to form the overall product or system.

The diagram above indicates progress through the development life-cycle in an iterative incremental development. Early on the iterations focus on 'design tasks' and the emphasis is on making design decisions and prototypes. As the project progresses tasks shift to development where the bulk of the coding is done. Finally, the emphasis is on testing or evaluation to ensure that what has been developed meets requirements and is solid, stable and bug free (ha!).

Iterative or Rapid Development

In iterative development, the same waterfall process is used to deliver smaller chunks of

Functionality in a step-by-step manner. This reduces the management and overheads in

Delivering software and reduces the risk inherent in the project. One of the major reasons cited for software project failure (and common sources of defects) is poor quality requirements. That is a failure to correctly specify what to build. By delivering small chunks and validating them, the project can self correct and hopefully converge on the desired outcome. This contrasts with the long lag times in the waterfall model.A variation on this theme is “Rapid Applications Development” or RAD. The phases are similar to waterfall but the 'chunks' are smaller. The emphasis in this model is onfast iterations through the cycle. Prototypes are designed, developed and evaluated with users, involving them in the process and correcting the design. The model is particularly suited to projects in rapidly changing environments where the team needs to adapt to different situations.

Making something can be thought of as a linear sequence of events. You start at A, you do B andthen go to C and eventually end up at Z. This is extremely simplistic but it does allow you tovisualise the series of events in the simplest way and it emphasises the importance of delivery withsteps being taken towards a conclusion.

Below is the “Waterfall Model” which shows typical development tasks flowing into each other.Early in the history of software development it was adapted from engineering models to be ablueprint for software development.

The five steps outlined are :

• Analyse the requirements of the project and decide what it is supposed to do

• Design a solution to meet these requirements

• Implement the design into a working product

• Verify the finished product against the design (and requirements)

• Maintain the project as necessary

The Waterfall Model was widely adopted in the early days of software development and a lot ofblame has been laid at its door.Critics argue that many problems in software development stem from this model. Earlydevelopment projects that followed this model ran over budget and over schedule and the blamewas attributed to the linear, step-wise nature of the model.It is very rare that requirements analysis can be entirely completed before design and designbefore development and so on. It is far more likely that each phase will have interaction with eachof the other phases.

In a small project this is not a problem since the span from “analyse” to “implement” may be aperiod of weeks or even days. For a large scale project which span months or even years the gapbecomes significant. The more time that passes between analysis and implementation, the more agap exists between the delivered project and the requirements of end-users.

 Think about a finance system which is ‘analysed’ one year, designed the next year and developedand implemented the following year. That’s three years between the point at which therequirements are captured and the system actually reaches its end users. In three years its likelythat the business, if not the whole industry, will have moved considerably and the requirements willno longer be valid. The developers will be developing the wrong system! Software of this scale isnot uncommon either.

Figure 1: Waterfall Model

• Requirements
• Implementation
• Design
• Verification
• Maintenance

A definition of requirements may be accurate at the time of capture but delays with frighteningspeed. In the modern business world, the chance of your requirements analysis being valid a coupleof months after it has been conducted is very slim indeed.Other versions of the waterfall model have been developed to alleviate this. One, the IterativeWaterfall Model, includes a loop as shown below.

  This model attempts to overcome the limitations of the original model by adding an “iterative”loop to the end of the cycle. That is, in order to keep up with changing requirements the “analysis”phase is revisited at the end of the cycle and the process starts over again.This alleviates the situation somewhat but still introduces a considerable lag between analysis andimplementation. The waterfall model implies you have to complete all the steps before you startthe process again. If requirements change during the life of the project the waterfall model requiresthe completion of a full cycle before they can be revisited.