Testing Explained.....
As I mentioned in the main page, in a software company there will be Testing team. In industry terms we call is as Quality Assurance (QA) team or Quality Control (QC) team. Most popular terminology is QA or testing.
First - let’s see why this department is needed in software company or why testers are needed in software project or why testing?
1) Testing is not a new concept, it exists from ancient period. In earlier ages before prince take over ruling from his father, there use to be a test like sword fighting, archery etc. If prince clear the test he would become king.
2) In real life as well ‘testing’ is everywhere. When there are some guests at your home. You prepare delicious food and before you serve the food to your guests you will taste it and check if it is good or not. In case not good then immediately you will add some spice or salt etc to make it better.
3) If you go for shopping and get some clothes, before you purchase you will get those clothes into trial room to check if it fits or not.
4) You want to buy a Honda or Benz car. You would like to take a test ride to feel the car.
In day-to-day life ‘testing’ is everywhere. Assume if there was no testing then life would suck. You would take so many wrong decisions, so many wrong things would have occurred. Similarly if there was no “testing’ in software then software will have problems or you will not find satisfying software. So ‘testing’ is very important for successful project execution.
In ‘Testing’ there are 2 major types
a) Black-box testing
B) White-box testing
Black-box testing: Let me put in simple words, black-box testing deals mainly with the functionality testing. Here we test – if ‘x’ is input, are we getting ‘y’ as output.
White-box testing: here also tester will test if ‘x’ is input ‘y’ is the output or not but this type of testing deals with technical things. How program logic is written? Based on the code is the input and output are proper or not? How input is interacting with backend database and how results are fetched .
In simple words you can say, black-box testing needs functional knowledge and white-box needs technical knowledge.
Dear friends, my intention of putting ‘testing’ knowledge here is to make Business Analyst aspirants to know about testing not intended for Developers and testers. As a Business Analyst it is important to know how testing is done and how testers perform in real life scenarios. Let’s see now, how and what a ‘tester’ will do in real time projects;
As you know, Business Analyst will do requirement gathering and prepare SRS and share the documents with Development and testing team. Testers will read the SRS and if any doubts are there then they will ask Business Analyst for clarifications. After all the clarifications are made as first step; ‘Testing Lead’ will create high level Test Scenarios. In the test Scenario it will be mentioned – what to be tested? What all modules are to be tested and what all are the high-level expected results?
As a second step: Testers will write Test-cases which will be based on the SRS document provided by Business Analyst. You will get question, test-cases are almost similar to SRS (in fact it will be extract of SRS document) but test cases will be written in detail for each field and each function.
For entire application and including all the modules ‘test cases’ will be written. Usually MS-Excel will be used to write test-cases. Once test cases are ready then a senior tester or any of the other testers will review the test-cases.
Once Developers code the functionality build will be passed to testing team. (What is Build? – Build is the terminology used. Build means – Developed code.) Build will be tested in phase wise and accordingly to test plan prepared by Testing team leader. Testing will be done based on the test cases written. Usually it is called “test-case” execution. Before testing team start testing there are some tests , lets see..(Note Again: this article is for Business Analysts and not for testers because for testers testing document need to be in depth. This is just for understanding QA or testing cycle).
Before build is passed to testers there are some testing done. Yes!! Developers themselves do a round of testing before passing build to testing team. We call it as “Unit Testing”. Developers will write Unit Test- cases and execute unit test cases.
After unit testing is done, there is one more testing called BVT (build Verification testing). This testing is done by developers or testers or deployment engineer. The main purpose of this test is to ensure the Build is stable or not. (note: there will be different servers like development or lab server, test server, production server) when build is deployed in different server all the path and connections need to be changed and build should be ensured working. If not working Testers will not be able to test build. Also if any major bugs (what is Bug: it is terminology again. Bug means mistake or error) testing team will reject the build form testing.
After BVT is done testers will start testing the build as per test-cases written. Any bugs found will be logged into central repository. There are some tools specifically for testing team which will act as repository and as well as tracking purpose. Any bugs can be logged into tool and assign to development team. An email will be triggered to developer on that bug. Developer will check and if it is a bug he will fix that bug. If not bug developer will write his comments for that bug and close the bugs]
When testers log bugs and it will be fixed by developers, again it will be tested. The fixed functionality will be tested – this is called “Patch testing”. Usually any patch or fixes done by developers will have impact on different functionality so again from start application need to be tested. This type of testing is called “Regression Testing”
The other testing types are;
Smoke testing: This is a sort of high level testing done on all the major functionality to ensure all the main parts of software are working. This does not do in-depth testing minute level.
Sanity testing: This is to ensure all parts of software are working but this testing focuses on minute level of functionality.
Integration Testing: Software will be developed in phases or modules. Each module developed will be tested separately and at the end all the modules will be clubbed and tested. This is called Integration testing.
System testing: This is to ensure entire software is working properly. In this test not only testers but business analysts, consultants and other people will test. This is something like preparatory exam before main exam. After system testing is done build will be deployed for UAT.
UAT: User Acceptance testing – this is done by clients.
Beta Testing: This is done by both client and testing team or business analyst. Once UAT is passed and application is deployed for usability for some period application will be on Beta.
Now lets see bug classification:
· Blocker bugs
· Major bugs
· Critical bugs
· Normal bugs
· Trivial bugs
Blocker Bugs are those which blocks testers from further testing, say for example if application is having Login function and after login testers are supposed test some functions BUT if they are not able to login. i,e. some problem in development with respect to login function we call it as Blocker bug.
other important bugs which are critical will be categorized into major and critical.
Some small bugs like not accepting numbers, telephone number is accepting alphabets are considered as normal and trival bugs.
Once bugs are raised testers will pass it to developers, once developers fix those bugs it will be passed back to testers for verification of fixed bugs. if again there is some problem with fixed bugs testers will pass it back to developers. This cycle repeats and once bug is fixed, testers will verify and close the bugs.
There are some open source tools like Bugzilla which are used to keep track of bug status. i.e. opened, closed, verified etc..
Also there are 2 more types of bugs called Invalid bugs and duplicate bugs. If testers raise some bugs which have no problems then developers will mark it as Invalid bugs. If same bugs are repeated then developers will mark it as Duplicate bugs.
********************************* *********************************** **************
Site Links: Click on below links to know more which can be helpful for a business analyst
Testing--> http://anil-businessanalyst.weebly.com/qa.html
Domain Knowledge--> http://anil-businessanalyst.weebly.com/domain-knowledge.html
Interview Questions--> http://anil-businessanalyst.weebly.com/ba-interview-questions.html
Challenges--> http://anil-businessanalyst.weebly.com/business-analyst-challenges.html
FAQ's--> http://anil-businessanalyst.weebly.com/faqs.html
Contact--> http://anil-businessanalyst.weebly.com/contact.html
My Blog--> http://anil-businessanalyst.weebly.com/my-blog
BA Day to Day Activities--> http://anil-businessanalyst.weebly.com/business-analyst-day2day.html
********************************* *********************************** *************
First - let’s see why this department is needed in software company or why testers are needed in software project or why testing?
1) Testing is not a new concept, it exists from ancient period. In earlier ages before prince take over ruling from his father, there use to be a test like sword fighting, archery etc. If prince clear the test he would become king.
2) In real life as well ‘testing’ is everywhere. When there are some guests at your home. You prepare delicious food and before you serve the food to your guests you will taste it and check if it is good or not. In case not good then immediately you will add some spice or salt etc to make it better.
3) If you go for shopping and get some clothes, before you purchase you will get those clothes into trial room to check if it fits or not.
4) You want to buy a Honda or Benz car. You would like to take a test ride to feel the car.
In day-to-day life ‘testing’ is everywhere. Assume if there was no testing then life would suck. You would take so many wrong decisions, so many wrong things would have occurred. Similarly if there was no “testing’ in software then software will have problems or you will not find satisfying software. So ‘testing’ is very important for successful project execution.
In ‘Testing’ there are 2 major types
a) Black-box testing
B) White-box testing
Black-box testing: Let me put in simple words, black-box testing deals mainly with the functionality testing. Here we test – if ‘x’ is input, are we getting ‘y’ as output.
White-box testing: here also tester will test if ‘x’ is input ‘y’ is the output or not but this type of testing deals with technical things. How program logic is written? Based on the code is the input and output are proper or not? How input is interacting with backend database and how results are fetched .
In simple words you can say, black-box testing needs functional knowledge and white-box needs technical knowledge.
Dear friends, my intention of putting ‘testing’ knowledge here is to make Business Analyst aspirants to know about testing not intended for Developers and testers. As a Business Analyst it is important to know how testing is done and how testers perform in real life scenarios. Let’s see now, how and what a ‘tester’ will do in real time projects;
As you know, Business Analyst will do requirement gathering and prepare SRS and share the documents with Development and testing team. Testers will read the SRS and if any doubts are there then they will ask Business Analyst for clarifications. After all the clarifications are made as first step; ‘Testing Lead’ will create high level Test Scenarios. In the test Scenario it will be mentioned – what to be tested? What all modules are to be tested and what all are the high-level expected results?
As a second step: Testers will write Test-cases which will be based on the SRS document provided by Business Analyst. You will get question, test-cases are almost similar to SRS (in fact it will be extract of SRS document) but test cases will be written in detail for each field and each function.
For entire application and including all the modules ‘test cases’ will be written. Usually MS-Excel will be used to write test-cases. Once test cases are ready then a senior tester or any of the other testers will review the test-cases.
Once Developers code the functionality build will be passed to testing team. (What is Build? – Build is the terminology used. Build means – Developed code.) Build will be tested in phase wise and accordingly to test plan prepared by Testing team leader. Testing will be done based on the test cases written. Usually it is called “test-case” execution. Before testing team start testing there are some tests , lets see..(Note Again: this article is for Business Analysts and not for testers because for testers testing document need to be in depth. This is just for understanding QA or testing cycle).
Before build is passed to testers there are some testing done. Yes!! Developers themselves do a round of testing before passing build to testing team. We call it as “Unit Testing”. Developers will write Unit Test- cases and execute unit test cases.
After unit testing is done, there is one more testing called BVT (build Verification testing). This testing is done by developers or testers or deployment engineer. The main purpose of this test is to ensure the Build is stable or not. (note: there will be different servers like development or lab server, test server, production server) when build is deployed in different server all the path and connections need to be changed and build should be ensured working. If not working Testers will not be able to test build. Also if any major bugs (what is Bug: it is terminology again. Bug means mistake or error) testing team will reject the build form testing.
After BVT is done testers will start testing the build as per test-cases written. Any bugs found will be logged into central repository. There are some tools specifically for testing team which will act as repository and as well as tracking purpose. Any bugs can be logged into tool and assign to development team. An email will be triggered to developer on that bug. Developer will check and if it is a bug he will fix that bug. If not bug developer will write his comments for that bug and close the bugs]
When testers log bugs and it will be fixed by developers, again it will be tested. The fixed functionality will be tested – this is called “Patch testing”. Usually any patch or fixes done by developers will have impact on different functionality so again from start application need to be tested. This type of testing is called “Regression Testing”
The other testing types are;
Smoke testing: This is a sort of high level testing done on all the major functionality to ensure all the main parts of software are working. This does not do in-depth testing minute level.
Sanity testing: This is to ensure all parts of software are working but this testing focuses on minute level of functionality.
Integration Testing: Software will be developed in phases or modules. Each module developed will be tested separately and at the end all the modules will be clubbed and tested. This is called Integration testing.
System testing: This is to ensure entire software is working properly. In this test not only testers but business analysts, consultants and other people will test. This is something like preparatory exam before main exam. After system testing is done build will be deployed for UAT.
UAT: User Acceptance testing – this is done by clients.
Beta Testing: This is done by both client and testing team or business analyst. Once UAT is passed and application is deployed for usability for some period application will be on Beta.
Now lets see bug classification:
· Blocker bugs
· Major bugs
· Critical bugs
· Normal bugs
· Trivial bugs
Blocker Bugs are those which blocks testers from further testing, say for example if application is having Login function and after login testers are supposed test some functions BUT if they are not able to login. i,e. some problem in development with respect to login function we call it as Blocker bug.
other important bugs which are critical will be categorized into major and critical.
Some small bugs like not accepting numbers, telephone number is accepting alphabets are considered as normal and trival bugs.
Once bugs are raised testers will pass it to developers, once developers fix those bugs it will be passed back to testers for verification of fixed bugs. if again there is some problem with fixed bugs testers will pass it back to developers. This cycle repeats and once bug is fixed, testers will verify and close the bugs.
There are some open source tools like Bugzilla which are used to keep track of bug status. i.e. opened, closed, verified etc..
Also there are 2 more types of bugs called Invalid bugs and duplicate bugs. If testers raise some bugs which have no problems then developers will mark it as Invalid bugs. If same bugs are repeated then developers will mark it as Duplicate bugs.
********************************* *********************************** **************
Site Links: Click on below links to know more which can be helpful for a business analyst
Testing--> http://anil-businessanalyst.weebly.com/qa.html
Domain Knowledge--> http://anil-businessanalyst.weebly.com/domain-knowledge.html
Interview Questions--> http://anil-businessanalyst.weebly.com/ba-interview-questions.html
Challenges--> http://anil-businessanalyst.weebly.com/business-analyst-challenges.html
FAQ's--> http://anil-businessanalyst.weebly.com/faqs.html
Contact--> http://anil-businessanalyst.weebly.com/contact.html
My Blog--> http://anil-businessanalyst.weebly.com/my-blog
BA Day to Day Activities--> http://anil-businessanalyst.weebly.com/business-analyst-day2day.html
********************************* *********************************** *************
