1.Q: How would you describe a good test engineer?
A: A test engineer has a specific attitude, in order to be a good test engineer we must see the product as we would be clients and this requires us to be detail oriented and to know what quality really means. As a test engineer we must know how to interact with the other people from the technical and non technical departments, a test engineer must have good verbal and writing skills. It is good for a test engineer to have past experience as a software developer, this can give the tester a deep understanding of a software developer process and a professional point of view.
2.Q: What does bug finding actually mean?
A: When the tester finds errors they must be reported and they must reach the developer in order to be repaired. After the repairing process, another test is made. There is a multitude of tools for software testing that help test engineers a lot in error management. The tools plus good engineers will give valuable information to the rest of the team to figure out the level of seriousness that the problem has and they will know the best solution to fix it.
3.Q: In what way is debugging different from testing?
A: When the developer receives the report concerning the errors found it is his/her duty to find the source of the problem and repair it, process that we call debugging. To define debugging we will say that debugging means to find, to analyze and to erase the reason for a software error. When it comes about testing, it has two parts: static testing and dynamic testing. Testing is for finding out if software is really done in such a way to fulfill the requirements and the reason for which it was built.
4.Q: How can be regression testing different form retesting?
A:Retesting is also called confirmation testing and it is made by running the last test cases which failed. These test cases were done to see if the repairs made by the developers on the errors found in the normal test procedurehave done their job or not. Regression testing means to test a program that was tested before but new things have been inserted and they could contain errors.
5.Q: Why are the requirements so important?
A: The best way to allow failure of different other issues in a software that is sophisticated is to have a lack of documentation regarding requirements, the requirements of an application means the relation that it has with the external factors. Requirements have the following characteristics: complete, detail oriented, testable, clear etc. The details of requirements can be organized in many ways and managing them in such a way that they can be efficient requires a lot of work, there are books that teach us how to do that. The requirements are not the same thing with design specifications.
6.Q: What happens when the time required for a thorough test is not enough?
A: We must take advantage of risk analysis to see the direction for focusing the tests. Rarely do we get the chance to test each and every part, event, possible wrong situations from an application. For risk analysis we need a common sense, experience and very good judgment skills.
7.Q:How is a test plan made?
A: A test plan for software is the document which contains data about the purpose , the reason the approach of the work involved in testing a software product. The preparation phase of a software test plan sees through the importance of the work and dedication that is involved in the validation of a software product. A document like this is made for use outside the group that made the testing, for those people that did not participate in testing to see why the certification of the software product was made and also this document explains how that certification was actually made. Even if the document contains various things about the testing, it is not described in detail but just as short comprehensive description, the people that were not involved in the testing will not know the deep aspects of the software testing process.
8.Q:What do we do in the case in which the requirements are changing all the time?
A: This is a popular issue:
a)We have to comprehend in which way do requirements change because in this way we can make alternate solutions from an early stage.
b)It is very important to design the application in a way that will permit it to be flexible and adapt to the changes that may occur, if not the application will have to be rebuilt from zero which is undesired.
c)The developers can adapt the modifications if we have good comments and good documentation to the code.
d)we should use fast prototyping if it’s possible to make the customers feel safe about the requirements.
e)We have to calculate more time in the default schedule of the project to allow the changes if they occur.
f)We should assign the initial requirements to “Phase 1” of the program and the new ones for “Phase 2”.
g)We have to permit only simple new requirements to enter the project , the later versions of the program will be the ones in which we will put difficult new requirements .
h)The price of the modifications in requirement , the risks involved, the impact that the schedule will have, all these must be well described to the management and the customers. It is their duty after that to determine if they are warranted.
i)We must equilibrate the work made for automated testing with the work that will be done for repeating the tests in case of changes.
J)We have to put flexibility in the scripts of automated testing.
kWe must concentrate the forst automated testing on the characteristics of the application that will stay unchanged.
l)Give the right interest to analyzing the risks involved with changes.
m)We have to give flexibility in test cases (which is hard enough to accomplish).
n)We have to concentrate on ad hoc testing much more than on test cases and detailed plans.
9.Q:What happens when we have a software that contains so much bugs that it won’t be tested?
A: If this situation occurs it is better to make the test engineers report the errors and issues that initially appeared focusing on the critical ones. In this type of issue the managers have to be kept informed and documented about Software Testing because it is that kind of problem that may have a great impact on the development due to bad unit tests, bad integration tests, weak design and building or release procedures.
10.Q:Is it possible to implement QA processes in such a way to avoid stifling productivity?
A: At first the QA processes must be implemented slowly then we have to adjust and experiment once the company rises and matures, in this way the productivity will not be stifled, but improved. If we will prevent the issues more than detecting them it will be less burn-out or panic and the concentration will be enhanced , the effort waste minimized. Also the processes should be kept simplistic , the paperwork and the time minimized, reporting and tracking should be automated and the training should be an integrating part of the QA. As people don’t really enjoy being under rules or bureaucracy the work could begin to take longer, but this is just the planning stage, we will gain time in the debugging and bug fixing stage and we will have less irritated clients.
11.Q:How do we describe the Big-bang waterfall model?
A: The Big-bang model is also called the waterfall model, the modules that are based on this model have their own way of the cycle individually, then they are joined. Big-bang is used for the development of a software application. It contains the requirement analysis, the design and implementation, the testing phase and the integration and the maintenance. This model gives us an entire plan that is applied once and in one single piece, it’s where the name comes from.
It is defined as seriousness:
a)The client must give us the whole set of requirements.
b)The design must be respected.
c)The construction of the design is made.
d)The testing of development work is made.
e)The system implementation takes place.
The Big-bang model should be followed when:
a)The contract is complete and correct.
b)The requirement criteria is complete and precise.
c)Modifications of requirement will not happen.
d)The stakeholders fully understand the issue and the solution.
e)Mistakes are excluded from the design phase and requirements.
12.Q: What is the meaning of the “test case”?
A:The document describing the possible response , the input, the event and the action required for testing if a quality of an application works properly is called a test case. It contains specific information like the name of the test case , its identifier, the objective, conditions and setup of the testing , the input data requirements , the possible results and the steps. Through developing test cases we can localize the problems in the design or in the requirements of a program because it allows us to see through the cycles of an application so to speak. The test cases have to be made available in the early stages of the developing process.
13.Q:How can we make the Risk Analysis in the software testing time?
A:For the Analysis we should implement:
1.Finding the score of the risk
2.Making a profile for the risk.
3.Changing the risk properties.
4. Deploy the resources of that test risk.
5.Making a database of risks.
Finding the risk score
The risk finding is made using the development team. It is made in the form of a questionnaire, in this way the risk level is determined.
Making a profile for the risk:
A profile is made using individual weights. After the risk data is being brought together and added to a spreadsheet which will calculate the score and after that we will see the possible risk areas.
Changing the properties of the risk:
After the possible risks have been identified, the next procedure will be to try lowering the risk possibility by implementing modifications.
Provide test resources:
The resources provided will be dependent on the risk degrees, the higher the risk area is, the more resources will be provided, and the lower the risk area is the fewer resources will be allocated.
Making a risk assessment database:
The database will include two big functions , one to enhance the risk assessment and one used for structure and management .
14.Q:How is testing different from QA?
A: QA or Quality Assurance is a group of activities that are meant to apply standards, to supervise and enhance the performance in such a way to have as much safety as we can. No matter if the product is accomplishing the requirements or not, we will obtain information from testing because they are useful seeing what is wrong.
15.Q: What makes Inspections to become separate from Walkthroughs?
A: Inspections are meant to determine if the product is compatible with the particular standards and requirements. It is a procedure made through comparison between the product and the design, artifact s, code and documentation, also it implied examining things. It is necessary to make good planning for it, many hours of preparing etc.
Walkthroughs: The author is showing the artifact to a public and then the author receives questions and answers about the artifact to spot the defects. It is no need for preparation and the defect tracking has no real substance.
16.Q: How much value can we find in a testing group and how can we prove our work and budget?
A: No matter how much effort will be met in development of a software product it will always have bugs , the product should be tested from an objective point of view, for this we must step outside from the group, it will be more efficient in this way. The group of testers is verifying the software from the perspective of requirements. The obligation of a tester is to check if an application functions as it was meant to function.
17.Q: What is the meaning of White box testing and Black box testing?
A:The first one refers to testing the structure of a program and the second is not based on the structure of the program but on requirements.
18.Q: How can we describe the evolutionary model?
A: Usually the disadvantage of a high period of time from the project beginning to the delivery point affects every model. To fix this the Evolutionary model enters the stage, approaching the problem in a different manner by cutting the work into small pieces giving priorities for each one and delivering them differently each at a time to the customer. There is the advantage of constant trust gaining over time, the requirements can in this way cut down as well in small chunks.
19.Q: How do we describe Regression testing?
A: Regression testing means testing the software again after it has been repaired or after changes have been implemented, there is no limit for the number of re-testing procedures as it is hard to see how much procedures are needed, , this type of testing uses automated testing tools.
20.Q:What differences can we find from system testing to functional testing?
A: With system testing the testers can verify the end product, in this type of testing we will test each module, interface into detail. It is classified into functional testing and non-functional testing, so functional testing belongs to the system testing and it has the role of verifying the product functionalities like load, stress, volume, security, scalability, performance. Hardware and software are not in need for functional testing.
21.Q: What is the meaning of Equivalence partitioning?
A: Equivalence Partitioning splits the input data into partitions, from where the test cases derive, when the cases are designed, every partition gets covered more than once.
22.Q:What is the role of drivers and stubs in the process of manual testing?
A: Stubs and drivers belong to incremental testing, which has two sides of seeing things: top down and bottom up. Bottom up testing involves the use of drivers. The drivers are modules just like the real ones and they are the ones that make the testing.
23.Q: What is the meaning of a boundary value analysis?
A: At the edge of the equivalence partition we will find a boundary value that can be output or input value. Being a black box technique, the boundary value analysis its tests are made with boundary values. It is also said to be the maximum or the minimum value that an edge can take.
24.Q: What is the meaning of pilot testing?
A: Pilot testing means to test a whole system or part of it or just a component in full working conditions (real life or real time). This will prevent finding bugs later when the client will use the system.
25.Q: How do we describe performance testing?
A: this type of testing belongs to the non-functional type and it represents the degree of performance that a software may have in terms of output rate and processing duration of a system or component.