SlideShare a Scribd company logo

Qc trg 16 apr 2020

Download as DOCX, PDF
A
Aisha Saleem

The document provides information about smoke testing vs sanity testing, including their definitions, key differences, and examples. Some key points: - Smoke testing verifies critical functionality is working as expected after a new build, while sanity testing checks that new or fixed functionality works as intended after minor code changes. - Smoke testing aims to check stability before detailed testing, while sanity testing aims to check rationality before detailed testing. - Smoke testing can be done by developers or testers and is usually scripted, while sanity testing is done by testers and is typically not scripted. - Smoke testing is a type of acceptance testing, and sanity testing is a type of regression testing. The document also provides

Internet
1 of 23
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
DAY 1 TRG (14TH APR 2020) Q1. Sanity Testing Vs Smoke Testing: Introduction & Differences Ans. Smoke and Sanity testing are the most misunderstood topics in Software Testing. There is an enormous amount of literature on the subject, but most of them are confusing. The following article makes an attempt to address the confusion. The key differences between Smoke and Sanity Testing can be learned with the help of the following diagram – What is a Software Build?
If you are developing a simple computer program which consists of only one source code file, you merely need to compile and link this one file, to produce an executable file. This process is very simple. Usually, this is not the case. A typical Software Project consists of hundreds or even thousands of source code files. Creating an executable program from these source files is a complicated and time-consuming task. You need to use "build" software to create an executable program and the process is called " Software Build" What is Smoke Testing? Smoke Testing is a kind of Software Testing performed after software build to ascertain that the critical functionalities of the program are working fine. It is executed "before" any detailed functional or regression tests are executed on the software build. The purpose is to reject a badly broken application so that the QA team does not waste time installing and testing the software application. In Smoke Testing, the test cases chose to cover the most important functionality or component of the system. The objective is not to perform exhaustive testing, but to verify that the critical functionalities of the system are working fine. For Example, a typical smoke test would be - Verify that the application launches successfully, Check that the GUI is responsive ... etc. What is Sanity Testing? Sanity testing is a kind of Software Testing performed after receiving a software build, with minor changes in code, or functionality, to ascertain that the bugs have been fixed and no further issues are introduced due to these changes. The goal is to determine that the proposed functionality works roughly as expected. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing. The objective is "not" to verify thoroughly the new functionality but to determine that the developer has applied some rationality (sanity) while producing the software. For instance, if your scientific calculator gives the result of 2 + 2 =5! Then, there is no point testing the advanced functionalities like sin 30 + cos 50.
Smoke Testing Vs Sanity Testing - Key Differences Smoke Testing Sanity Testing Smoke Testing is performed to ascertain that the critical functionalities of the program is working fine Sanity Testing is done to check the new functionality/bugs have been fixed The objective of this testing is to verify the "stability" of the system in order to proceed with more rigorous testing The objective of the testing is to verify the "rationality" of the system in order to proceed with more rigorous testing This testing is performed by the developers or testers Sanity testing is usually performed by testers Smoke testing is usually documented or scripted Sanity testing is usually not documented and is unscripted Smoke testing is a subset of Acceptance testing Sanity testing is a subset of Regression Testing Smoke testing exercises the entire system from end to Sanity testing exercises only the particular component
Points to note.  Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing.  Sanity Testing is also called tester acceptance testing.  Smoke testing performed on a particular build is also known as a build verification test.  One of the best industry practice is to conduct a Daily build and smoke test in software projects.  Both smoke and sanity tests can be executed manually or using an automation tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself.  As per the needs of testing, you may have to execute both Sanity and Smoke Tests in the software build. In such cases, you will first execute Smoke tests and then go ahead with Sanity Testing. In industry, test cases for Sanity Testing are commonly combined with that for smoke tests, to speed up test execution. Hence, it's a common that the terms are often confused and used interchangeably KEY DIFFERENCE  Smoke Testing has a goal to verify “stability” whereas Sanity Testing has a goal to verify “rationality”.  Smoke Testing is done by both developers or testers whereas Sanity Testing is done by testers.  Smoke Testing verifies the critical functionalities of the system whereas Sanity Testing verifies the new functionality like bug fixes.  Smoke testing is a subset of acceptance testing whereas Sanity testing is a subset of Regression Testing.  Smoke testing is documented or scripted whereas Sanity testing isn’t.  Smoke testing verifies the entire system from end to end whereas Sanity Testing verifies only a particular component. end of the entire system Smoke testing is like General Health Check Up Sanity Testing is like specialized health check up
Q 2. Boundary Value Analysis & Equivalence Partitioning Practically, due to time and budget considerations, it is not possible to perform exhausting testing for each set of test data, especially when there is a large pool of input combinations.  We need an easy way or special techniques that can select test cases intelligently from the pool of test-case, such that all test scenarios are covered.  We use two techniques - Equivalence Partitioning & Boundary Value Analysis testing techniques to achieve this. What is Boundary Testing? Boundary testing is the process of testing between extreme ends or boundaries between partitions of the input values.  So these extreme ends like Start- End, Lower- Upper, Maximum-Minimum, Just Inside-Just Outside values are called boundary values and the testing is called "boundary testing".  The basic idea in boundary value testing is to select input variable values at their: 1. Minimum 2. Just above the minimum 3. A nominal value 4. Just below the maximum 5. Maximum
 In Boundary Testing, Equivalence Class Partitioning plays a good role  Boundary Testing comes after the Equivalence Class Partitioning. What is Equivalent Class Partitioning? Equivalent Class Partitioning is a black box technique (code is not visible to tester) which can be applied to all levels of testing like unit, integration, system, etc. In this technique, you divide the set of test condition into a partition that can be considered the same.  It divides the input data of software into different equivalence data classes.  You can apply this technique, where there is a range in the input field. Example 1: Equivalence and Boundary Value  Let's consider the behavior of Order Pizza Text Box Below  Pizza values 1 to 10 is considered valid. A success message is shown.  While value 11 to 99 are considered invalid for order and an error message will appear, "Only 10 Pizza can be ordered" Order Pizza: Submit Here is the test condition 1. Any Number greater than 10 entered in the Order Pizza field(let say 11) is considered invalid.
2. Any Number less than 1 that is 0 or below, then it is considered invalid. 3. Numbers 1 to 10 are considered valid 4. Any 3 Digit Number say -100 is invalid. We cannot test all the possible values because if done, the number of test cases will be more than 100. To address this problem, we use equivalence partitioning hypothesis where we divide the possible values of tickets into groups or sets as shown below where the system behavior can be considered the same. The divided sets are called Equivalence Partitions or Equivalence Classes. Then we pick only one value from each partition for testing. The hypothesis behind this technique is that if one condition/value in a partition passes all others will also pass. Likewise, if one condition in a partition fails, all other conditions in that partition will fail.
Boundary Value Analysis- in Boundary Value Analysis, you test boundaries between equivalence partitions
In our earlier example instead of checking, one value for each partition you will check the values at the partitions like 0, 1, 10, 11 and so on. As you may observe, you test values at both valid and invalid boundaries. Boundary Value Analysis is also called range checking. Equivalence partitioning and boundary value analysis (BVA) are closely related and can be used together at all levels of testing. Example 2: Equivalence and Boundary Value Following password field accepts minimum 6 characters and maximum 10 characters That means results for values in partitions 0-5, 6-10, 11-14 should be equivalent Enter Password: Submit Test Scenario # Test Scenario Description Expected Outcome 1 Enter 0 to 5 characters in password field System should not accept 2 Enter 6 to 10 characters in password field System should accept 3 Enter 11 to 14 character in password field System should not accept Examples 3: Input Box should accept the Number 1 to 10 Here we will see the Boundary Value Test Cases
Test Scenario Description Expected Outcome Boundary Value = 0 System should NOT accept Boundary Value = 1 System should accept Boundary Value = 2 System should accept Boundary Value = 9 System should accept Boundary Value = 10 System should accept Boundary Value = 11 System should NOT accept Why Equivalence & Boundary Analysis Testing 1. This testing is used to reduce a very large number of test cases to manageable chunks. 2. Very clear guidelines on determining test cases without compromising on the effectiveness of testing. 3. Appropriate for calculation-intensive applications with a large number of variables/inputs Summary:  Boundary Analysis testing is used when practically it is impossible to test a large pool of test cases individually  Two techniques - Equivalence Partitioning & Boundary Value Analysis testing techniques are used
 In Equivalence Partitioning, first, you divide a set of test condition into a partition that can be considered.  In Boundary Value Analysis you then test boundaries between equivalence partitions  Appropriate for calculation-intensive applications with variables that represent physical quantities Q3. How To Write Test Cases For A Login Page (Sample Scenarios) Sample Test Cases for a Login Page (Includes ALL important functional and non-functional test cases for login page) Whenever you will be asked to write the test cases forthe ‘Form with some controls’, you need to follow the list of rules for writing test cases as mentioned below:  Write a test case on each form object.  Written test cases should be a combination of both negative and positive test cases.  Also, test cases should always be a combination of functional, performance, UI, usability, and compatibility test cases.  When you will be asked in the interview to write the test cases for a login page, firstly you need to think about, how many maximum controls can be available on a login page?  Because you don’t have a login page in front of you and neither you have requirements document for this login page. But the login page is such a common thing of which we can easily imagine the controls.  There can be a username, password, ‘Sign In’ button, Cancel Button, and Forgot Password link. There can be one more control which is a checkbox named ‘Remember me’ to remember the login details on a particular machine. Test Cases – Login Page Following is the possible list of functional and non-functional test cases for a login page: Functional Test Cases: Sr. No. Functional Test Cases Type- Negative/ Positive Test Case 1 Verify if a user will be able to login with a valid username and valid Positive
password. 2 Verify if a user cannot login with a valid username and an invalid password. Negative 3 Verify the login page for both, when the field is blank and Submit button is clicked. Negative 4 Verify the ‘Forgot Password’ functionality. Positive 5 Verify the messages forinvalid login. Positive 6 Verify the ‘Remember Me’ functionality. Positive 7 Verify if the data in password field is either visible as asterisk or bullet signs. Positive 8 Verify if a user is able to login with a new password only after he/she has changed the password. Positive 9 Verify if the login page allows to log in simultaneously with different credentials in a different browser. Positive
Non-functional Security Test Cases: Sr. No. Security test cases Type- Negative/ Positive Test Case 10 Verify if the ‘Enter’ key of the keyboard is working correctly on the login page. Positive Other Test Cases 11 Verify the time taken to log in with a valid username and password. Performance & Positive Testing 12 Verify if the font, text color, and color coding of the Login page is as per the standard. UI Testing & Positive Testing 13 Verify if there is a ‘Cancel’ button available to erase the entered text. Usability Testing 14 Verify the login page and all its controls in different browsers Browser Compatibility & Positive Testing.
Sr. No. Security test cases Type- Negative/ Positive Test Case 1 Verify if a user cannot enter the characters more than the specified range in each field (Username and Password). Negative 3 Verify the login page by pressing ‘Back button’ of the browser. It should not allow you to enter into the systemonce you log out. Negative 5 Verify if a user should not be allowed to log in with different credentials from the same browser at the same time. Negative 7 Verify the Login page against SQL injection attack. Negative 2 Verify if a user cannot enter the characters more than the specified range in each field (Username and Password). Positive 4 Verify the timeout functionality of the login session. Positive 6 Verify if a user should be able to login with the same credentials in different browsers at the same time. Positive
Sr. No. Security test cases Type- Negative/ Positive Test Case 8 Verify the implementation of SSL certificate. Positive We can take an Example of Gmail Login page. Here is the image of it.
Qc trg 16 apr 2020
Test Cases for Gmail Login page
Sr. No. Test Scenarios 1 Enter the valid email address & click next. Verify if the user gets an option to enter the password. 2 Don’t enter an email address or phone number & just click the Next button. Verify if the user will get the correct message or if the blank field will get highlighted. 3 Enter the invalid email address & click the Next button. Verify if the user will get the correct message. 4 Enter an invalid phone number & click the Next button. Verify if the user will get the correct message. 5 Verify if a user can log in with a valid email address and password. 6 Verify if a user can log in with a valid phone number and password. 7 Verify if a user cannot log in with a valid phone number and an invalid password. 8 Verify if a user cannot log in with a valid email address and a wrong password. 9 Verify the ‘Forgot email’ functionality. 10 Verify the ‘Forgot password’ functionality.
Test Scenarios for the Sign-up page #1) Verify the messages foreach mandatory field. #2) Verify if the user cannot proceed without filling all the mandatory fields. #3) Verify the age of the user when the DOB is selected. #4) Verify if the numbers and special characters are not allowed in the First and Last name. #5) Verify if a user can sign-up successfully with all the mandatory details. #6) Verify if a user can log in with the valid details. #7) Verify if the Password and Confirm Password fields are accepting similarstrings only. #8) Verify if the Password field will prompt you for the weak passwords. #9) Verify if duplicate email address will not get assigned. #10) Verify that hints are provided for each field on the form, for the ease of use.
Test Scenarios for the Login page of Mobile Application #1) Verify if a user can log in with a valid username and password. #2) Verify if a user cannot log in with an invalid username or password. Check permutation and combinations of this.
#3) Verify the ‘Keep me Sign In’ option. If this check box is selected, then the user should not get logged out even after exiting the app. #4) Verify if this check box is not selected by default. #5) If the user has signed up with Facebook or social media, verify that the user can log in with those credentials or not. #6) Verify the Forgot password functionality. #7) Verify if the login page fits the mobile screen. The user should not have to scroll the screen. Conclusion While writing test cases for login or sign-up page write the test cases for all the fields. There should be a combination of both positive and negative test cases. Try to cover the performance, security, and functional scenarios. The login page is the page with fewer controls, so even though it is looking simple for testing, it should not be considered as an easy task. Also many a time it is the first impression of an application, so it should be perfect for user interface and usability. DAY 2 TRG (15TH APR 2020) Basic checklist for Sanity testing Software sanity tests are synonymous with smoke tests. A sanity or smoke test determines whether it is possible and reasonable to continue Software Testing. It exercises the smallest subset of application functions needed to determine whether the systems are accessible and the application logic is responsive. During sanity testing the below mentioned checklist is almost applicable for all types of web applications depending on the business requirements.
a) UI Testing: 1. Web page title as per the page’s functionality. 2. Spelling/grammatical mistake (e.g. Text, Caption, Label). 3. Proper field alignment (Left margin, right margin, bottom margin, top margin). 4. Same font size/style or as per the requirement. 5. Proper space between texts, text lines, fields. 6. Standard format and size of button. 7. Textbox: Border, alignment, size, length, Data Type. 8. Combo box: Size, alignment, showing valid value. 9. Date picker (Not by keyboard, from date to date range). 10. Mandatory field identified with an identification like (*) sign. 11. Image length, size, alignment b) Functional Testing: 1. Mandatory and composite field validation. 2. Error message not mandatory for optional field. 3. Numeric field does not accept the alpha numeric and proper error message display. 4. Max length checking for specific input field (e.g. Credit card number, Account number). 5. Confirmation message for Insert/update/delete operations. 6. Correct format of amount value.(Should be numeric) 7. Uploaded documents are opened and generated properly. 8. Validation (different fields….Equivalence partitioning/Boundary value analysis/Positive testing/Negative/Page Refreshing testing). 9. System works properly with multiple browsers. 10. Pagination works and number shows properly. c) Database Testing: 1. Database name, Tables, columns name, column types matches according to requirement. 2. Data saves properly into the database after the each page submission. 3. Data display on the front end and make sure it is same in the back end.
4. Is any difference between Live and Test environment (Database Name, Table Name, Column Name, Data Type, Entity Relationship Key – Primary, Foreign, Unique key) 5. Checking Procedure/Function Create/Update related information(Entity Name, Author, Create/Update Date, Description/Purpose) d) Security Testing: 1. Session timeout checking. Whether the page is expiring after the specific time. 2. Does the page browse if I paste it in a newly open browser? 3. Browser back-forward button checking if the page consist any calculation or information submission. Does the browser’s back- forward button re-submit the page? 4. Does this application has admin/user log in the database? (IP Address, user ID, Login/logout date and time) . 5. Password, Account number, credit card number display in encrypted format. 6. Access the secured web page directly without login. 7. User account gets locked out if the user is entering the wrong password several times. (If available in BRS/SRS).

More Related Content

DOCX
A PARTICLE SWARM OPTIMIZATION TECHNIQUE FOR GENERATING PAIRWISE TEST CASES
Kula Sekhar Reddy Yerraguntla
 
PPTX
Combinatorial testing ppt
Kedar Kumar
 
PDF
Mutation Testing
Raja Nagendra Kumar
 
PDF
Block 1 ms-034 unit-1
Nirmal Jasmatiya
 
PDF
QAI QUEST 2016 Webinar Series: Pairwise Testing w/ Philip Lew
XBOSoft
 
PDF
TDD Presentation
Domenic Merenda
 
PPTX
Test design techniques
Mohamed Elshenawy
 
PDF
Software testing strategy
ijseajournal
 
A PARTICLE SWARM OPTIMIZATION TECHNIQUE FOR GENERATING PAIRWISE TEST CASES
Kula Sekhar Reddy Yerraguntla
 
Combinatorial testing ppt
Kedar Kumar
 
Mutation Testing
Raja Nagendra Kumar
 
Block 1 ms-034 unit-1
Nirmal Jasmatiya
 
QAI QUEST 2016 Webinar Series: Pairwise Testing w/ Philip Lew
XBOSoft
 
TDD Presentation
Domenic Merenda
 
Test design techniques
Mohamed Elshenawy
 
Software testing strategy
ijseajournal
 

What's hot (20)

PDF
Chapter 8 software testing
despicable me
 
PPT
Software Testing
Kiran Kumar
 
PDF
Best practices for test case creation & maintenance
99tests
 
PDF
Software testing lab manual
Tanzeem Syed
 
PDF
Pairwise testing - Strategic test case design
XBOSoft
 
PPTX
All you need to know about regression testing | David Tzemach
David Tzemach
 
PPT
12 functional-system-testing
nickynicks76
 
PPT
Testing
Muni Ram
 
PDF
03 test specification and execution
Clemens Reijnen
 
PPT
Testing strategies
chaitanya_yarlagadda
 
PPT
Debugging
Indu Sharma Bhardwaj
 
PPTX
A comparative on test case generation on concurrent
SoumyaRanjanBehera40
 
DOC
Smoke testing
Akansha Rawat
 
PPTX
10 Principles of Apex Testing
Kevin Poorman
 
PPT
Software testing for biginners
Sriman Eshwar
 
PDF
Black-Box
Jason Brown, PMP
 
PPT
Testers Desk Presentation
Quality Testing
 
PDF
Characterization of Open-Source Applications and Test Suites
ijseajournal
 
PPTX
What is sanity testing
pooja deshmukh
 
PPTX
Test Cases Vs Test Scenarios
Sneha Singh
 
Chapter 8 software testing
despicable me
 
Software Testing
Kiran Kumar
 
Best practices for test case creation & maintenance
99tests
 
Software testing lab manual
Tanzeem Syed
 
Pairwise testing - Strategic test case design
XBOSoft
 
All you need to know about regression testing | David Tzemach
David Tzemach
 
12 functional-system-testing
nickynicks76
 
Testing
Muni Ram
 
03 test specification and execution
Clemens Reijnen
 
Testing strategies
chaitanya_yarlagadda
 
Debugging
Indu Sharma Bhardwaj
 
A comparative on test case generation on concurrent
SoumyaRanjanBehera40
 
Smoke testing
Akansha Rawat
 
10 Principles of Apex Testing
Kevin Poorman
 
Software testing for biginners
Sriman Eshwar
 
Black-Box
Jason Brown, PMP
 
Testers Desk Presentation
Quality Testing
 
Characterization of Open-Source Applications and Test Suites
ijseajournal
 
What is sanity testing
pooja deshmukh
 
Test Cases Vs Test Scenarios
Sneha Singh
 
Ad

Similar to Qc trg 16 apr 2020 (20)

PPTX
Test design techniques
Oksana
 
PPT
Testing Software Solutions
gavhays
 
PPT
software testing
Mayank Gupta
 
PDF
Sanity Testing Vs. Smoke Testing: All You Need to Know!
Sterling Technolabs
 
PPTX
QA Worskhop For Begginers In the Power Point Presentation
WhiteLabel Fox
 
PPT
Types of Software Testing
Nishant Worah
 
PPTX
Importance of Software testing in SDLC and Agile
Chandan Mishra
 
PPT
Testing
nazeer pasha
 
DOCX
A PRACTITIONER'S GUIDE TO SOFTWARE TEST DESIGN [Summary]
Khizra Sammad
 
PPT
The Role Of The Sqa In Software Development By Jim Coleman
James Coleman
 
PDF
The Most Comprehensive and Friendly Guide On Smoke Testing [with Examples].pdf
Steve Wortham
 
PPS
Software test life cycle
Sumit Sinha CSM®, CSP®, EPGBM® - IIM-Calcutta
 
PDF
Test Case Design Techniques in Software Testing_ Elements, Types, and Best Pr...
Jace Reed
 
PPT
Software testing overview subbu
Subramanya Mudukutore
 
DOCX
Testing concept definition
Vivek V
 
PPT
SE-Testing.ppt
vishal choudhary
 
PPTX
Fundamentals of testing 2
seli purnianda
 
PPTX
Fundamentals of testing
Taufik hidayat
 
PPT
Testing
Kiran Kumar
 
DOCX
Qa Faqs
nitin lakhanpal
 
Test design techniques
Oksana
 
Testing Software Solutions
gavhays
 
software testing
Mayank Gupta
 
Sanity Testing Vs. Smoke Testing: All You Need to Know!
Sterling Technolabs
 
QA Worskhop For Begginers In the Power Point Presentation
WhiteLabel Fox
 
Types of Software Testing
Nishant Worah
 
Importance of Software testing in SDLC and Agile
Chandan Mishra
 
Testing
nazeer pasha
 
A PRACTITIONER'S GUIDE TO SOFTWARE TEST DESIGN [Summary]
Khizra Sammad
 
The Role Of The Sqa In Software Development By Jim Coleman
James Coleman
 
The Most Comprehensive and Friendly Guide On Smoke Testing [with Examples].pdf
Steve Wortham
 
Software test life cycle
Sumit Sinha CSM®, CSP®, EPGBM® - IIM-Calcutta
 
Test Case Design Techniques in Software Testing_ Elements, Types, and Best Pr...
Jace Reed
 
Software testing overview subbu
Subramanya Mudukutore
 
Testing concept definition
Vivek V
 
SE-Testing.ppt
vishal choudhary
 
Fundamentals of testing 2
seli purnianda
 
Fundamentals of testing
Taufik hidayat
 
Testing
Kiran Kumar
 
Qa Faqs
nitin lakhanpal
 
Ad

Recently uploaded (20)

PDF
Lean-Manufacturing-Tools-Techniques-and-How-To-Use-Them.pdf
Turreteng
 
PPT
FIRE PREVENTION AND CONTROL PLAN- LUS.FM.MQ.OM.UTM.PLN.00014.ppt
MelwinPaul6
 
PPTX
Cyber Hygine IN organizations in MSME or
paramkiet
 
PDF
📍 LABUAN4D EXCLUSIVE SERVER STAR GAMING ASIA NO.1 TERPOPULER DI INDONESIA ! 🌟
alexiskandar061
 
PPTX
Internet Safety for Seniors presentation
mwnorman1
 
PPT
12 Things That Make People Trust a Website Instantly
Shethil Ahammed
 
PPTX
E -tech empowerment technologies PowerPoint
kylebalatero12
 
PDF
FINAL CALL-6th International Conference on Networks & IOT (NeTIOT 2025)
IJMIT JOURNAL
 
PDF
SlidesGDGoCxRAIS about Google Dialogflow and NotebookLM.pdf
minhtrietgect
 
PPTX
The-Importance-of-School-Sanitation.pptx
shinjanmandal111
 
PDF
Exploring The Internet Of Things(IOT).ppt
rakeshk19831911
 
PPTX
Slides PPTX: World Game (s): Eco Economic Epochs.pptx
Steven McGee
 
PDF
Exploring VPS Hosting Trends for SMBs in 2025
Liquid Web
 
PDF
si manuel quezon at mga nagawa sa bansang pilipinas
LizaDeVeraFloresLaya
 
PPTX
module 1-Part 1.pptxdddddddddddddddddddddddddddddddddddd
KevinSeelu
 
PDF
Smart Home Technology for Health Monitoring (www.kiu.ac.ug)
publication11
 
PDF
Alethe Consulting Corporate Profile and Solution Aproach
debashisrakshit2025
 
PPTX
Database Information System - Management Information System
faizhossain3
 
PPTX
Layers_of_the_Earth_Grade7.pptx class by
varadhanvara05
 
PDF
📍 LABUAN4D EXCLUSIVE SERVER STAR GAMING ASIA NO.1 TERPOPULER DI INDONESIA ! 🌟
alexiskandar061
 
Lean-Manufacturing-Tools-Techniques-and-How-To-Use-Them.pdf
Turreteng
 
FIRE PREVENTION AND CONTROL PLAN- LUS.FM.MQ.OM.UTM.PLN.00014.ppt
MelwinPaul6
 
Cyber Hygine IN organizations in MSME or
paramkiet
 
📍 LABUAN4D EXCLUSIVE SERVER STAR GAMING ASIA NO.1 TERPOPULER DI INDONESIA ! 🌟
alexiskandar061
 
Internet Safety for Seniors presentation
mwnorman1
 
12 Things That Make People Trust a Website Instantly
Shethil Ahammed
 
E -tech empowerment technologies PowerPoint
kylebalatero12
 
FINAL CALL-6th International Conference on Networks & IOT (NeTIOT 2025)
IJMIT JOURNAL
 
SlidesGDGoCxRAIS about Google Dialogflow and NotebookLM.pdf
minhtrietgect
 
The-Importance-of-School-Sanitation.pptx
shinjanmandal111
 
Exploring The Internet Of Things(IOT).ppt
rakeshk19831911
 
Slides PPTX: World Game (s): Eco Economic Epochs.pptx
Steven McGee
 
Exploring VPS Hosting Trends for SMBs in 2025
Liquid Web
 
si manuel quezon at mga nagawa sa bansang pilipinas
LizaDeVeraFloresLaya
 
module 1-Part 1.pptxdddddddddddddddddddddddddddddddddddd
KevinSeelu
 
Smart Home Technology for Health Monitoring (www.kiu.ac.ug)
publication11
 
Alethe Consulting Corporate Profile and Solution Aproach
debashisrakshit2025
 
Database Information System - Management Information System
faizhossain3
 
Layers_of_the_Earth_Grade7.pptx class by
varadhanvara05
 
📍 LABUAN4D EXCLUSIVE SERVER STAR GAMING ASIA NO.1 TERPOPULER DI INDONESIA ! 🌟
alexiskandar061
 

Qc trg 16 apr 2020

  • 1. DAY 1 TRG (14TH APR 2020) Q1. Sanity Testing Vs Smoke Testing: Introduction & Differences Ans. Smoke and Sanity testing are the most misunderstood topics in Software Testing. There is an enormous amount of literature on the subject, but most of them are confusing. The following article makes an attempt to address the confusion. The key differences between Smoke and Sanity Testing can be learned with the help of the following diagram – What is a Software Build?
  • 2. If you are developing a simple computer program which consists of only one source code file, you merely need to compile and link this one file, to produce an executable file. This process is very simple. Usually, this is not the case. A typical Software Project consists of hundreds or even thousands of source code files. Creating an executable program from these source files is a complicated and time-consuming task. You need to use "build" software to create an executable program and the process is called " Software Build" What is Smoke Testing? Smoke Testing is a kind of Software Testing performed after software build to ascertain that the critical functionalities of the program are working fine. It is executed "before" any detailed functional or regression tests are executed on the software build. The purpose is to reject a badly broken application so that the QA team does not waste time installing and testing the software application. In Smoke Testing, the test cases chose to cover the most important functionality or component of the system. The objective is not to perform exhaustive testing, but to verify that the critical functionalities of the system are working fine. For Example, a typical smoke test would be - Verify that the application launches successfully, Check that the GUI is responsive ... etc. What is Sanity Testing? Sanity testing is a kind of Software Testing performed after receiving a software build, with minor changes in code, or functionality, to ascertain that the bugs have been fixed and no further issues are introduced due to these changes. The goal is to determine that the proposed functionality works roughly as expected. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing. The objective is "not" to verify thoroughly the new functionality but to determine that the developer has applied some rationality (sanity) while producing the software. For instance, if your scientific calculator gives the result of 2 + 2 =5! Then, there is no point testing the advanced functionalities like sin 30 + cos 50.
  • 3. Smoke Testing Vs Sanity Testing - Key Differences Smoke Testing Sanity Testing Smoke Testing is performed to ascertain that the critical functionalities of the program is working fine Sanity Testing is done to check the new functionality/bugs have been fixed The objective of this testing is to verify the "stability" of the system in order to proceed with more rigorous testing The objective of the testing is to verify the "rationality" of the system in order to proceed with more rigorous testing This testing is performed by the developers or testers Sanity testing is usually performed by testers Smoke testing is usually documented or scripted Sanity testing is usually not documented and is unscripted Smoke testing is a subset of Acceptance testing Sanity testing is a subset of Regression Testing Smoke testing exercises the entire system from end to Sanity testing exercises only the particular component
  • 4. Points to note.  Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing.  Sanity Testing is also called tester acceptance testing.  Smoke testing performed on a particular build is also known as a build verification test.  One of the best industry practice is to conduct a Daily build and smoke test in software projects.  Both smoke and sanity tests can be executed manually or using an automation tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself.  As per the needs of testing, you may have to execute both Sanity and Smoke Tests in the software build. In such cases, you will first execute Smoke tests and then go ahead with Sanity Testing. In industry, test cases for Sanity Testing are commonly combined with that for smoke tests, to speed up test execution. Hence, it's a common that the terms are often confused and used interchangeably KEY DIFFERENCE  Smoke Testing has a goal to verify “stability” whereas Sanity Testing has a goal to verify “rationality”.  Smoke Testing is done by both developers or testers whereas Sanity Testing is done by testers.  Smoke Testing verifies the critical functionalities of the system whereas Sanity Testing verifies the new functionality like bug fixes.  Smoke testing is a subset of acceptance testing whereas Sanity testing is a subset of Regression Testing.  Smoke testing is documented or scripted whereas Sanity testing isn’t.  Smoke testing verifies the entire system from end to end whereas Sanity Testing verifies only a particular component. end of the entire system Smoke testing is like General Health Check Up Sanity Testing is like specialized health check up
  • 5. Q 2. Boundary Value Analysis & Equivalence Partitioning Practically, due to time and budget considerations, it is not possible to perform exhausting testing for each set of test data, especially when there is a large pool of input combinations.  We need an easy way or special techniques that can select test cases intelligently from the pool of test-case, such that all test scenarios are covered.  We use two techniques - Equivalence Partitioning & Boundary Value Analysis testing techniques to achieve this. What is Boundary Testing? Boundary testing is the process of testing between extreme ends or boundaries between partitions of the input values.  So these extreme ends like Start- End, Lower- Upper, Maximum-Minimum, Just Inside-Just Outside values are called boundary values and the testing is called "boundary testing".  The basic idea in boundary value testing is to select input variable values at their: 1. Minimum 2. Just above the minimum 3. A nominal value 4. Just below the maximum 5. Maximum
  • 6.  In Boundary Testing, Equivalence Class Partitioning plays a good role  Boundary Testing comes after the Equivalence Class Partitioning. What is Equivalent Class Partitioning? Equivalent Class Partitioning is a black box technique (code is not visible to tester) which can be applied to all levels of testing like unit, integration, system, etc. In this technique, you divide the set of test condition into a partition that can be considered the same.  It divides the input data of software into different equivalence data classes.  You can apply this technique, where there is a range in the input field. Example 1: Equivalence and Boundary Value  Let's consider the behavior of Order Pizza Text Box Below  Pizza values 1 to 10 is considered valid. A success message is shown.  While value 11 to 99 are considered invalid for order and an error message will appear, "Only 10 Pizza can be ordered" Order Pizza: Submit Here is the test condition 1. Any Number greater than 10 entered in the Order Pizza field(let say 11) is considered invalid.
  • 7. 2. Any Number less than 1 that is 0 or below, then it is considered invalid. 3. Numbers 1 to 10 are considered valid 4. Any 3 Digit Number say -100 is invalid. We cannot test all the possible values because if done, the number of test cases will be more than 100. To address this problem, we use equivalence partitioning hypothesis where we divide the possible values of tickets into groups or sets as shown below where the system behavior can be considered the same. The divided sets are called Equivalence Partitions or Equivalence Classes. Then we pick only one value from each partition for testing. The hypothesis behind this technique is that if one condition/value in a partition passes all others will also pass. Likewise, if one condition in a partition fails, all other conditions in that partition will fail.
  • 8. Boundary Value Analysis- in Boundary Value Analysis, you test boundaries between equivalence partitions
  • 9. In our earlier example instead of checking, one value for each partition you will check the values at the partitions like 0, 1, 10, 11 and so on. As you may observe, you test values at both valid and invalid boundaries. Boundary Value Analysis is also called range checking. Equivalence partitioning and boundary value analysis (BVA) are closely related and can be used together at all levels of testing. Example 2: Equivalence and Boundary Value Following password field accepts minimum 6 characters and maximum 10 characters That means results for values in partitions 0-5, 6-10, 11-14 should be equivalent Enter Password: Submit Test Scenario # Test Scenario Description Expected Outcome 1 Enter 0 to 5 characters in password field System should not accept 2 Enter 6 to 10 characters in password field System should accept 3 Enter 11 to 14 character in password field System should not accept Examples 3: Input Box should accept the Number 1 to 10 Here we will see the Boundary Value Test Cases
  • 10. Test Scenario Description Expected Outcome Boundary Value = 0 System should NOT accept Boundary Value = 1 System should accept Boundary Value = 2 System should accept Boundary Value = 9 System should accept Boundary Value = 10 System should accept Boundary Value = 11 System should NOT accept Why Equivalence & Boundary Analysis Testing 1. This testing is used to reduce a very large number of test cases to manageable chunks. 2. Very clear guidelines on determining test cases without compromising on the effectiveness of testing. 3. Appropriate for calculation-intensive applications with a large number of variables/inputs Summary:  Boundary Analysis testing is used when practically it is impossible to test a large pool of test cases individually  Two techniques - Equivalence Partitioning & Boundary Value Analysis testing techniques are used
  • 11.  In Equivalence Partitioning, first, you divide a set of test condition into a partition that can be considered.  In Boundary Value Analysis you then test boundaries between equivalence partitions  Appropriate for calculation-intensive applications with variables that represent physical quantities Q3. How To Write Test Cases For A Login Page (Sample Scenarios) Sample Test Cases for a Login Page (Includes ALL important functional and non-functional test cases for login page) Whenever you will be asked to write the test cases forthe ‘Form with some controls’, you need to follow the list of rules for writing test cases as mentioned below:  Write a test case on each form object.  Written test cases should be a combination of both negative and positive test cases.  Also, test cases should always be a combination of functional, performance, UI, usability, and compatibility test cases.  When you will be asked in the interview to write the test cases for a login page, firstly you need to think about, how many maximum controls can be available on a login page?  Because you don’t have a login page in front of you and neither you have requirements document for this login page. But the login page is such a common thing of which we can easily imagine the controls.  There can be a username, password, ‘Sign In’ button, Cancel Button, and Forgot Password link. There can be one more control which is a checkbox named ‘Remember me’ to remember the login details on a particular machine. Test Cases – Login Page Following is the possible list of functional and non-functional test cases for a login page: Functional Test Cases: Sr. No. Functional Test Cases Type- Negative/ Positive Test Case 1 Verify if a user will be able to login with a valid username and valid Positive
  • 12. password. 2 Verify if a user cannot login with a valid username and an invalid password. Negative 3 Verify the login page for both, when the field is blank and Submit button is clicked. Negative 4 Verify the ‘Forgot Password’ functionality. Positive 5 Verify the messages forinvalid login. Positive 6 Verify the ‘Remember Me’ functionality. Positive 7 Verify if the data in password field is either visible as asterisk or bullet signs. Positive 8 Verify if a user is able to login with a new password only after he/she has changed the password. Positive 9 Verify if the login page allows to log in simultaneously with different credentials in a different browser. Positive
  • 13. Non-functional Security Test Cases: Sr. No. Security test cases Type- Negative/ Positive Test Case 10 Verify if the ‘Enter’ key of the keyboard is working correctly on the login page. Positive Other Test Cases 11 Verify the time taken to log in with a valid username and password. Performance & Positive Testing 12 Verify if the font, text color, and color coding of the Login page is as per the standard. UI Testing & Positive Testing 13 Verify if there is a ‘Cancel’ button available to erase the entered text. Usability Testing 14 Verify the login page and all its controls in different browsers Browser Compatibility & Positive Testing.
  • 14. Sr. No. Security test cases Type- Negative/ Positive Test Case 1 Verify if a user cannot enter the characters more than the specified range in each field (Username and Password). Negative 3 Verify the login page by pressing ‘Back button’ of the browser. It should not allow you to enter into the systemonce you log out. Negative 5 Verify if a user should not be allowed to log in with different credentials from the same browser at the same time. Negative 7 Verify the Login page against SQL injection attack. Negative 2 Verify if a user cannot enter the characters more than the specified range in each field (Username and Password). Positive 4 Verify the timeout functionality of the login session. Positive 6 Verify if a user should be able to login with the same credentials in different browsers at the same time. Positive
  • 15. Sr. No. Security test cases Type- Negative/ Positive Test Case 8 Verify the implementation of SSL certificate. Positive We can take an Example of Gmail Login page. Here is the image of it.
  • 17. Test Cases for Gmail Login page
  • 18. Sr. No. Test Scenarios 1 Enter the valid email address & click next. Verify if the user gets an option to enter the password. 2 Don’t enter an email address or phone number & just click the Next button. Verify if the user will get the correct message or if the blank field will get highlighted. 3 Enter the invalid email address & click the Next button. Verify if the user will get the correct message. 4 Enter an invalid phone number & click the Next button. Verify if the user will get the correct message. 5 Verify if a user can log in with a valid email address and password. 6 Verify if a user can log in with a valid phone number and password. 7 Verify if a user cannot log in with a valid phone number and an invalid password. 8 Verify if a user cannot log in with a valid email address and a wrong password. 9 Verify the ‘Forgot email’ functionality. 10 Verify the ‘Forgot password’ functionality.
  • 19. Test Scenarios for the Sign-up page #1) Verify the messages foreach mandatory field. #2) Verify if the user cannot proceed without filling all the mandatory fields. #3) Verify the age of the user when the DOB is selected. #4) Verify if the numbers and special characters are not allowed in the First and Last name. #5) Verify if a user can sign-up successfully with all the mandatory details. #6) Verify if a user can log in with the valid details. #7) Verify if the Password and Confirm Password fields are accepting similarstrings only. #8) Verify if the Password field will prompt you for the weak passwords. #9) Verify if duplicate email address will not get assigned. #10) Verify that hints are provided for each field on the form, for the ease of use.
  • 20. Test Scenarios for the Login page of Mobile Application #1) Verify if a user can log in with a valid username and password. #2) Verify if a user cannot log in with an invalid username or password. Check permutation and combinations of this.
  • 21. #3) Verify the ‘Keep me Sign In’ option. If this check box is selected, then the user should not get logged out even after exiting the app. #4) Verify if this check box is not selected by default. #5) If the user has signed up with Facebook or social media, verify that the user can log in with those credentials or not. #6) Verify the Forgot password functionality. #7) Verify if the login page fits the mobile screen. The user should not have to scroll the screen. Conclusion While writing test cases for login or sign-up page write the test cases for all the fields. There should be a combination of both positive and negative test cases. Try to cover the performance, security, and functional scenarios. The login page is the page with fewer controls, so even though it is looking simple for testing, it should not be considered as an easy task. Also many a time it is the first impression of an application, so it should be perfect for user interface and usability. DAY 2 TRG (15TH APR 2020) Basic checklist for Sanity testing Software sanity tests are synonymous with smoke tests. A sanity or smoke test determines whether it is possible and reasonable to continue Software Testing. It exercises the smallest subset of application functions needed to determine whether the systems are accessible and the application logic is responsive. During sanity testing the below mentioned checklist is almost applicable for all types of web applications depending on the business requirements.
  • 22. a) UI Testing: 1. Web page title as per the page’s functionality. 2. Spelling/grammatical mistake (e.g. Text, Caption, Label). 3. Proper field alignment (Left margin, right margin, bottom margin, top margin). 4. Same font size/style or as per the requirement. 5. Proper space between texts, text lines, fields. 6. Standard format and size of button. 7. Textbox: Border, alignment, size, length, Data Type. 8. Combo box: Size, alignment, showing valid value. 9. Date picker (Not by keyboard, from date to date range). 10. Mandatory field identified with an identification like (*) sign. 11. Image length, size, alignment b) Functional Testing: 1. Mandatory and composite field validation. 2. Error message not mandatory for optional field. 3. Numeric field does not accept the alpha numeric and proper error message display. 4. Max length checking for specific input field (e.g. Credit card number, Account number). 5. Confirmation message for Insert/update/delete operations. 6. Correct format of amount value.(Should be numeric) 7. Uploaded documents are opened and generated properly. 8. Validation (different fields….Equivalence partitioning/Boundary value analysis/Positive testing/Negative/Page Refreshing testing). 9. System works properly with multiple browsers. 10. Pagination works and number shows properly. c) Database Testing: 1. Database name, Tables, columns name, column types matches according to requirement. 2. Data saves properly into the database after the each page submission. 3. Data display on the front end and make sure it is same in the back end.
  • 23. 4. Is any difference between Live and Test environment (Database Name, Table Name, Column Name, Data Type, Entity Relationship Key – Primary, Foreign, Unique key) 5. Checking Procedure/Function Create/Update related information(Entity Name, Author, Create/Update Date, Description/Purpose) d) Security Testing: 1. Session timeout checking. Whether the page is expiring after the specific time. 2. Does the page browse if I paste it in a newly open browser? 3. Browser back-forward button checking if the page consist any calculation or information submission. Does the browser’s back- forward button re-submit the page? 4. Does this application has admin/user log in the database? (IP Address, user ID, Login/logout date and time) . 5. Password, Account number, credit card number display in encrypted format. 6. Access the secured web page directly without login. 7. User account gets locked out if the user is entering the wrong password several times. (If available in BRS/SRS).