What is automation testing?
What is automation testing?
So, smoke testing is designed to test new feathers of a system, it is wide but not deep. By doing this, we can decide whether we need to do further testing.
For example, if a tester is asked to find out all the impurities of a river. Smoke testing is just for finding out all the impurities at the surface of the river, widely but not deeply.
Sanity is narrow but quite deep. It focuses on a particular or some particular feathers.
For example, find out all the impurities of the river, but only for a particular area, say like within 30 mile radius.
Unlike White Box Testing, which is focusing on the code or syntax stuff, Black Box Testing is focusing on functional requirements, and it compliments White Box Testing. it only concerns with testing the specification, and cannot guarantee that all parts of the implementation have been tested.
Thus black box testing is testing against the specification and will discover faults of omission, indicating that part of the specification has not been fulfilled. White box testing is testing against the implementation and will discover faults of commission, indicating that part of the implementation is faulty. In order to fully test a software product, both black and white box testing are required.
Black box testing attempts to find out: (1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external database access, (4) performance errors, and (5) initialisation and termination errors.
is a typical black box testing technique which divides the input domain of a program into classes of data from which test cases can be derived. Equivalence partitioning method strives to define a test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.
Choose the most representative one for each set.
is a black box testing method that where test cases are designed to test the boundary of an input domain. Studies have shown that more errors happen on the “boundary” of an input domain rather than on the “center area”.
So here, we can select the minimum and maximum values of an input and output range to test.
The basic idea of this method is that, a “cause” if an input condition, and an “effect” is a specific sequence of computations to be performed. A cause-effect graph is basically a directed graph that describes the logical combinations of causes and their relationship to the effects to be produced. It can help testers to select test cases to chekc if the program will produce right effect for every possible combination of causes.
Why we are using cause-effect graph/When should we use/What circumstances?
which comprises of comparing the content of multiple objects, e.g. files, databases, against actual results.
(Some good sources and articles about black box testing and test cases writing:
Well, it is a good question.
First of all, one of the challenges a tester will be faced is that how to build a good relationship with developers. For example, how you are going to tell developers that their job has not been completed properly? Or full of bugs? It requires skilled testers to handle this relation positively and even by completing the work in testers way. It always to see some disagreement on some points between the developer and testers. So how to express my self, how to describe a particular defect appropriately, how to discuss with developers, all of these are quite challengeable.
Second, understanding the requirements. When a tester cannot understand clearly or in the right way about what the system is proposed to do, what kinds of functions it should provide, etc., it can lead to a really bad and serious situation. So I think testers require a good listening and understanding capabilities.
Also, when facing a time constraint, we also need to decide how to decide which test case should be executed firstly and which should not be executed until the very last period? So a tester should define properly the priority and severity of each test case and defect, to ensure that the quality of a software system is maximised or optimised.
What’s more, it is not possible to test the whole application/software system. There are millions of test combinations. So if a tester is trying to test all these combinations he/she will never ship the product. Remember that there is no perfect quality.
(A good source here: http://www.softwaretestinghelp.com/manual-and-automation-testing-challenges/)
(Also if want to read more about the challenges of agile testing: http://blog.smartbear.com/sqc/top-5-common-challenges-for-agile-testing-teams/)
As a software tester, we can use Root Cause Analysis.
Root Cause Analysis (RCA) is an approach used in software testing to analyse and identify the root causes of defects and address them, instead of treating the symptoms. If some problems happen, instead of just fixing it, we can also investigate and try to fix the underlying cause so that this kind of problems will be prevented from the next or further phases.
Five whys technique: whose goal is to determine the root cause of a defect or problem by repeating the question “Why”. Each “why” forms the basis of the next question. For example:
The answer to these questions will give us the exact phase, where the defect actually exists. Then, we can come up with “What” question:
What will you do to avoid this in future?
So now we can prevent the same defect to arise again by implementing the answer of this question.
Doing the RCA accurately helps to prevent defects in the later releases or phases.
Problem Statement: You are on your way home from work and your car stops in the middle of the road.
1. Why did your car stop?
– Because it ran out of gas.
2. Why did it run out of gas?
– Because I didn’t buy any gas on my way to work.
3. Why didn’t you buy any gas this morning?
– Because I didn’t have any money.
4. Why didn’t you have any money?
– Because I lost it all last night in a poker game.
5. Why did you lose your money in last night’s poker game?
– Because I’m not very good at “bluffing” when I don’t have a good hand.
When do you do impact analysis and how does it help improve the quality of software developed
Impact analysis is basically analysing the impact of the changes in the deployed software product or system. It tells us about the parts of the system that may be unintentionally affected because of the changes in the application and therefore need careful regression testing.
The decision is taken together with the stakeholders.
How do you optimize test cases?
Having minimum ongoing test case will lead to increased efficiency and amplified savings.
Choose the most representative ones, ensure that this particular test case uncovers a class of errors that might otherwise require many cases to be executed before the general error is observed.
Can use techniques of black box testing to select and optimise test cases.