| Listen to this blog |
On this planet everything that is developed should be tested, officially or unofficially. In our rota, we tend to do a lot of testing but we don’t realize because they are part and parcel of daily routines. In a similar profession, the information technology stream adopted the testing domain as one of their power to ensure that the application or software designed working as intended and it serves the purpose.
In this blog we are going to give the knowledge related software testing from the very basic level even a novice will be able to follow.
One must brainstorm themselves to get the motivation of being a software tester. Being an art testing requires some of below skillset.
Intelligence
Out of box thinking
Disciplinary and punctual actions
Planning
Leadership abilities
The mentioned skills were quite common for any profession but when it comes to the point of testing they play an additional role but are mandatory to possess. We keep everything crossed for you to choose to test as your profession, be ready to break the system in a procedural manner and ensure that you are of great help to your team always to launch a perfect flawless product.
Understanding the SDLC
As a pre-requisite, we would strongly recommend one to give yourself a walkthrough on SDLC (software testing life cycle), while going through the below content. A blog can still be understood without SDLC knowledge but it’s recommended as that way you connect the dots while undergoing discovery learning to understand better.
What is software testing?
Software testing a process of identifying the bugs present in the software by validating all possible scenarios that are applicable to the software. In this formal process, we design test cases basis the understanding of the application then executes to deem the correctness of the software
Why is software testing required?
For an illustration, let’s consider that a bank has launched one of its internet banking system applications into production for use without testing. It is evident that customers are going to initiate transactions and apply for various services that are offered by the system.
There is a high probability for the customer-friendly scenarios could fail, which in turn cause the bank to lose its reputation and trust in the market and it’s very expensive for the bank to correct the mistake and re-work on the application
1. Initiated transactions might get failed due to various reason
2. Fund would have not credited at the receiving end
3. Can’t be able to query about the balance?
4. Can’t apply for cheque leaves through the internet banking system.
In the above discussion, it’s a software imagine its software component that performs some physical actions based on the input such as airbag release system in the car, automotive alarms elevators, and lift..etc. failing which can cost lives. So we need to keep the mindset in such a way that, if the application or a working software is not tested we are going to see a huge amount of loss which is difficult to recover from. So we know why testing is essential now, great understanding!!!
Principles of testing
There are a few principles that must be learned which explain the reasoning of testing in all possible views, why wait? Let’s see them quickly
Early testing is beneficial
How early we start to test, that early we can stabilize the system also it’s true that early bugs are cheaper than bugs that are identified late in the business. When we say cheaper if we can identify and fix them early we can avoid doing late regression testing and that as well helps to meet the deadlines. So we should adopt a process that helps us proceed with test activities early in the software life cycle.
Error absence is the fallacy
Though the intention is to test as much as we can and identify all possible bugs, we can guarantee that system if bug-free and 100% flawless. We might have misbehavior seen at a very low level that might not have caught up in our test scope or an unfortunate miss. Despite the principle, we should always ensure that we don’t cover any bug present in customer use cases.
Exhaustive testing can’t be conducted
As part of the testing phase in the software development life cycle, we will conduct various levels and types of testing, but it’s still difficult to cover all the scenarios including positive and negative. Given the timelines for the testing phase we should understand the prioritized edge tests also we need to apply the proper test case techniques to make sure a few test cases will give more coverage.
Pesticide paradox (redundant test case)
We should be continuously reviewing the test cases in order to ensure we have powerful tests and no more duplicates present. If the same tests are being executed again and again we end up identifying no defects. Every time there is an operational change or enhancement in the module, we should build the tests accordingly.
Defect clustering
In any software system, every component has to be treated and tested thoroughly, it could be that most of the defects might be happening in smaller components or from a module which we don’t even think of. We should always focus on the integration pieces and also focus on edge cases as that gives confidence that either boundary are working.
Testing shows the presence of defects
It’s evident that only testing allows us to find defects, how much diligence we possess while testing that much defect rate can be achieved and in turn can help the business to make the application more stable within the nominal time.
Testing is situational dependent
We should keep changing the mindset and the game plan when we are supposed to test different applications or different software. The same strategy will not help us to find the bugs and which will cause so many complexities within the domain. For an illustration, the plan that’s applied for testing a banking-related application may not be useful to test the retail application or insurance application as the requirements and usage are significantly varying.
Software testing life cycle
STLC is a part of SDLC, it’s one of the phases which is executed after completion of development. It’s essential to understand the phases involved in the testing life cycle as that helps us apply the right testing approach. The steps involved in STLC are
Requirement analysis understanding
In this phase, the goal is to analyze the requirements thoroughly to understand the functionality. Any clarification that would be required should be clarified by discussing with the business analysts or the subject matter experts.
Test plan
Once the requirements are understood we should plan for proper testing. We should also define the scope as what comes into the scope and what can’t be. We should also plan the number of resources that would be required also the timelines.
Test case design
Basis the understanding the test case design should be commenced. By following the proper test case development techniques also keeping the type of test in scope we should have the test cases designed. Since the tests designed are going to be executed for finding the defects. Hence proper understanding of the design techniques are needed.
Test data preparation
Test data plays an important role in the execution front. Based on the test data the test execution flow changes, hence apparently we can believe that test data has the ability to drive the test case. We should identify possible combinations of negative and positive scenarios. Test data plays a major role in automation as well, in a pure data-driven or hybrid framework, we can execute the same test with different sets of inputs than writing them as a separate test case. Test data can be maintained in Database or in excel spreadsheet or in any other known form.
Test execution
Once the designing of the test cases and identification of test data is done we need to execute the test cases. Any underlying bugs present in the system can possibly be found in this phase. Due diligence is required while executing the tests as we need to catch up with minor cosmetic bugs as well. Every execution report should be shared with all the stakeholders for their reference and also help with understanding the progress of the test
Test closure
As a test closure activity we will share the final results observed during the execution phase in a detailed format. We will put in graphs, bar charts and presentations so that the higher management can actually understand the status better. Also, the sign-off documents, test risk assessments, and test completion reports are being circulated to get the approval from all business stakeholders.
Test case development techniques
While writing the test cases it’s essential to adopt the techniques to be smart enough also to ensure the coverage with a minimum set of test cases as possible. If the techniques are not followed we end up writing invalid tests also test cases might appear as redundant ones.
Given the two major classifications of testing, we have respective test case techniques designed as well
White box testing techniques
As discussed above it’s a test designed or executed on the structure or design of an application and proper understanding of the code and system is a must.
Statement coverage
Let’s consider a developer is conducting a unit testing, the developer must have a thorough understanding of what that module or component should do? Also, the developer must aware of the code that has been written. Predominantly with the help of this technique, we try to get rid of any unreachable code that’s available in the system. Ideally, the statement coverage is equal to the number of statements being written.
Eg.
Main(){
If(a>0&&b>0){
If(a>b){
Print is bigger;
Else
Print b is bigger;
}
Else{
Print error message saying, negative values are not allowed;
}
}
The statement coverage for the above program is 9, as there are 9 statements.
Decision coverage
The decision coverage mechanism of a white box testing technique ensures that we make proper conditional calls and don’t miss any edge cases. The decision coverage is equal to the number of decisions we have in the system.
Eg:
Main(){
If(a>0&&b>0){
If(a>b){
Print is bigger;
Else
Print b is bigger;
}
Else{
Print error message saying, negative values are not allowed;
}
}
In the above snippet we are making two decisions as to whether or not both the given numbers are non-negative integers then considering a decision as which number is bigger
So the decision coverage for the snippet is equaled to 2
Path coverage
Path coverage ensure that how many use cases and flows can be derived based on the given inputs. Also, we need to ensure that all possible paths are covered to ensure that the system is not open to breaking in any scenario. This can be understood by drawing some UML, flow chart diagrams.
Black box testing techniques
As we already discussed above that black box is a manual validation and test cases are mainly focused to test the functional validation. These techniques will help us to do some permutations and combinations and identify the test cases based on the edge cases or doing some partitioning
Boundary value analysis
In this technique based on the condition, the boundary values such one immediate left and one immediate right boundary values are tested to ensure the state transition is happening properly on the conditional edge.
Eg lets consider that a person whose age is 18 or above only can vote and below age group, people can’t cast their vote.
In order to test this condition we will understand the deciding factor age as “18” as it’s mentioned then identify one value just below 17 and one above 19 as boundary values to test that critical conditional logic.
Equivalence partitioning
This is another technique, which will help us to avoid the number of test cases but gives more coverage in this testing. In this technique based on the condition, we will partition the negative and positive slots and then pick one of those values to test. The lore is that, if the test case is behaving as expected for one value it is understood rest other values would be passed from the same slot.
Eg: let’s consider the same example as above that person with 18 or above can vote and rest can’t
We will identify three partitions as
Age- 0<=17- negative slot
Age- 18= positive slot
Age- 19 to any greater value- positive slot
We will pick any one test data from each classification then with the help of 3 test cases all the scenarios can be covered.
Decision tables
When we have multiple combinations of inputs to test, if we choose to write test cases for all the values it becomes an overhead. Then forming a table with all the conditions and actions put in would help better to identify the cases.
Eg: let’s consider a scenario of withdrawing money from the automated teller machine.
The machine will dispense money only when
Cond-1 user put incorrect passcode
Cond-2 withdrawal money should be lesser or equal to the savings balance.
Action / Goal: Withdraw money from the teller machine.
The above requirement can be converted into a decision table as,
State transition testing
In this technique we need to understand the state flow of the use case then come up with a design flow diagram. This flow can help us derive how many flows and how many are positive and negative. In order to do this, we must have proper knowledge of the application.
Use case testing
Use case tests are designed to be more customer-specific test. The test case is written in the form of a user guide where the steps are written in a procedural format. This gives more insight on the test procedure as it talks about the actors, events n pre and post conditions in specific.
Eg: let’s consider a login scenario into an application
Actor
Actor is the person who performs that events
Pre-condition
Actor should own a good network provision
Actor should be on the login page to be able to enter credentials
Events
Steps are addressed as events, the events involved in this step are
Enter the username and password
Click on the login button
Alternatives
This says what other actions can be possible when actor on that page.
The actor can look for help link or actor can try signing up if the account is not created yet.
Exceptions
These are the problems that user might encounter during the execution of events
Application might be throwing an error upon entering the credentials
After the clicking the login button, occurrence of any HTTP error
Post- actions
These are the subsequent actions executed after the completion of events.
Logging out from the application
Performing any business functionality with in the application
Conclusion
We reckon it’s a vague discussion, but every piece in this is important to be a competitive and distinguished tester. Adopting these fundamentals will help us test the applications with due diligence and with enhanced coverage. How much its the fact that the principles have to be understood, in the same fashion we must apply the sense to determine what technique to be used and when. I keep everything crossed for every reader to be a successful tester.
Thanks for reading!!! More we know more we grow.
Comments(0)