What Is The Difference Between Regression Testing And Smoke Testing?

Regression testing and smoke testing are both types of software testing, but they serve different purposes and have different characteristics.

Regression Testing:

• Regression testing is the process of testing a software application to ensure that any new changes or modifications to the code have not introduced new defects or broken existing functionality. 
• It involves running a set of previously executed test cases to check if any new errors have been introduced or if the changes made to the code have affected the existing functionality. Regression testing is usually done after code changes or bug fixes.

Smoke Testing:

• Smoke testing, on the other hand, is a preliminary level of testing that checks the basic functionality of an application. 
• It is usually performed to ensure that the build or the application is stable and ready for further testing. 
• Smoke testing is done to ensure that the most critical functionalities of the application are working fine, and the application is not completely broken.

Sanity Testing:

• Sanity testing is similar to smoke testing, but it is performed after smoke testing to verify that the defects found in smoke testing have been fixed and that the critical functionalities are still working fine. 
• Sanity testing is also used to ensure that the new features added to the application are working as expected, and the application is ready for further testing.

In summary, regression testing checks for any new errors or defects that might have been introduced after code changes, while smoke testing and sanity testing ensure that the basic and critical functionalities of the application are working fine. Smoke testing is done before further testing, while sanity testing is done after smoke testing to ensure that the application is ready for further testing.

How To Test Software - Get Functional Defects

1. User Interface Issues

• Poorly designed user interfaces can cause several defects, such as non-responsive buttons, broken links, or incorrect field validations.

2. Data Integrity Issues

• Defects in data integrity may occur when the system doesn't validate the data or doesn't store it correctly. An example of this is if a user enters an email address with an incorrect format, and the system accepts it.

3. Functionality Issues

• Functionality defects occur when the system doesn't meet the business requirements. For example, if a banking application doesn't allow users to transfer funds between accounts or a social media platform doesn't enable users to create a new post.

4. Integration Issues

• Integration defects arise when different modules or systems don't work well together. An example of this is if a CRM system doesn't synchronize data with a marketing automation system.

5. Boundary and Limits Issues

• Boundary and limits issues may arise when the system doesn't handle inputs or outputs correctly that are at the boundaries or limits of the system. For instance, if a system doesn't allow negative values for certain inputs.

6. Business Logic Issues 

• Business logic defects occur when the system doesn't correctly implement the business rules or logic. For example, if a discount code isn't applied correctly or if a system calculates taxes incorrectly.

7. Compatibility Issues

• Compatibility defects may occur when the system doesn't work correctly with different browsers or operating systems. For example, if a website works fine on Google Chrome but doesn't display correctly on Mozilla Firefox.

8. Localization Issues

• Localization defects occur when the system doesn't support various languages or regions. For instance, if a website's interface is not translated into Spanish, which is a required language for the user.

9. Accessibility Issues

• Accessibility defects may arise when the system doesn't provide easy access to all users, such as people with disabilities. For example, if a website doesn't offer a screen reader or keyboard shortcuts.

10. Usability Issues

• Usability defects occur when the system doesn't provide a user-friendly experience. For instance, if a user has difficulty finding the right button or menu item or if the user manual is hard to understand.

 Functional defects can impact the quality and performance of a system, leading to a negative user experience. As testers, it is crucial to identify these defects early in the software development lifecycle to prevent them from affecting the system's overall quality.

The Most Famous Software Failures of All Time

 1. Memory Failure - Tesla Recalls 135,000 Vehicles

•  Tesla will recall a maximum of 135,000 cars to fix computer memory issues in the touchscreen that could cause a loss of some features notified the electric car manufacturer to the U.S NHTSA (National Highway Traffic Safety Administration).
•  The manufacturer said that the touchscreen’s flash memory reached the end of its lifespan. It can trigger failures of the software components of the centre monitor and can unintentionally lead to the loss of external turn signal lighting, rearview camera display, and defog/defrost control settings.

2. HSBC’s Significant IT Outages

• One of the famous software failure examples. HSBC experienced a big IT outage in January 2016 and millions of bank customers were unable to access online accounts. The bank took almost two days to recover and get back to normal service. The Chief Operating Officer of HSBC (COO) claimed that this was the result of a ‘unique technological problem’ within internal systems.

3. Prison Break

•  An error that happened in December 2015 resulted in more than 3,200 US prisoners being released before their announced date of release. The software was developed to track the actions of prisoners and was released in 2002. The problem has been around for about 13 years and an average inmate has been released almost 49 days in advance.

4. The Explosion of the Ariane 5

•  On June 4, 1996, an Ariane 5 rocket launched by the ESA (European Space Agency) exploded just forty seconds after its launch from Kourou in French Guiana. The rocket was on its inaugural voyage, after a decade of development costing $8 billion and the result of this bug was the loss of $370 million.
•  The reason behind its failure was an integer Overflow, which is a widespread bug in computer programming. In this case, an attempt was made to set a 64-bit number in 16-bit space.

5. PayPal accidentally credits man $92 quadrillion

•  When Chris Reynolds opened his PayPal e-mail statement, the Pennsylvania PR executive’s account balance was $92,233,720,368,547,800.
•  The amount is significant in the world of 64-bit numbers suggesting a programming error. The error was quickly recognized, and his account had returned to zero by the time he logged in.
•  PayPal offered to give an unspecified amount of money to a cause of Reynolds’ choice.

6. Windows Calculator Bug

•  This bug exists in most Windows versions(except in Windows 10), including Windows XP, Windows 7, Windows Vista, and Windows 8. You can check it in your OS if you have one of these versions.
•  Steps: Open Windows Calculator, type 4 and take the square root, you will get two then subtract two from it. Instead of the result from zero, you will see different outputs on different versions of Windows.
•  The cause for the bug is the way calculator manages sqrt operations. The results are saved as floating-point numbers instead of integers, and the precision errors when it comes to floating-point calculations are the result that you can see.
•  Microsoft acknowledged this bug in the calculator app, and they fixed it in Windows 10 Build 17639.

7. Gangnam Style music video ‘broke’ YouTube

•  YouTube’s counter before used a 32-bit integer, which is a unit used to represent data in computer architecture. This 32-bit integer determines the maximum number of possible views it can count was 2,147,483,647.
•  The Gangnam Style video exceeded the maximum value, and we got the below famous Gangnam Style YouTube bug.
•  Nowadays, YouTube uses a 64-bit integer for its video counter, which means videos have a maximum viewer count of 9.22 quintillion.

How to Write a Good Bug Report: A Comprehensive Guide

1. Clear Summary:

•  Summarize the bug clearly.
•  The summary should give the bug's full picture in a single sentence.

2. One Issue = One Bug:

•  Do not combine multiple issues in one bug.
•  Because different bugs can be assigned to different developers to fix.

3. Clear & Detailed Description:

•  Expand the summary in description-simple and precise.
•  Provide as much information as possible.

4. Steps To Reproduce:

•  How can you reproduce the bug - mention it in bullet points.
•  Clear enough developers would reproduce and fix quickly.

5. Expected & Actual Results:

•  What is the requirement & what is happening?
•  The developer knows what is the issue by looking at it.

6. Additional Details As Notes:

•  Write about your additional observations.
•  Helps developers to analyze & hence fix bugs quickly.

7. Environment Details:

•  Where have you tested - QA/PRD/CHROME ETC.
•  Developer compares this with other environments.

8. Build Number:

•  In which version of the application you found the bug.

9. PRIORITY:

•  How soon the bug should be fixed.
•  Can be HIGH/LOIW/MEDIUM.

10. SEVERITY:

•  Impact on the product.
•  Can be CRITICAL/MAJOR/MINOR/TRIVIAL.

11. Screenshot/Screen Recording:

•  Evidence of the bug.
•  Can be screenshots or screen recordings.

12. Link the related test case and or story:

•  Link bug to story/test case you are testing.
•  Can be 'Associated With' OR 'Blocked By'.

13. LOGS:

•  Attach log file or snippet of log.
•  This is a mine of data for developers.

14. Avoid Duplicates:

•  Check if already bug is reported by someone. 

What Type of Test Cases Should Not Be Automated?

1. User Interface (UI) testing

2. Exploratory testing

3. Usability testing

4. Ad hoc testing

5. Performance testing

• Test cases that require human judgment, exploration, or unpredictability may not be suitable for automation. Additionally, test cases highly dependent on an application's user interface, performance, or usability may be better suited for manual testing.