Posts

Showing posts from November, 2024

Daily Tasks of a QA

Image
  The daily tasks of a Quality Assurance (QA) professional can vary depending on the project phase, the type of testing being performed, the team’s workflow, and the specific role of the QA (e.g., manual tester, automation tester, test lead, etc.). However, there are common tasks that most QA professionals engage in regularly to ensure software quality. Below is an overview of typical daily tasks. 1. Reviewing Requirements & Test Planning Reading and Analyzing User Stories/Requirements : Many days begin by reviewing the user stories, functional specifications, and any new requirements that have been added to the project. This ensures that we fully understand the expected behaviour of the software and what needs to be tested. Test Planning : For new features or updates, we may need to create or update test plans. This includes defining the scope of testing, creating test cases, and determining the necessary resources, environments, and tools for testing. 2. Writing and Reviewing...

Test Scenarios vs. Test Cases

Image
As a QA professional, you’ll frequently create various test deliverables. Among them, understanding the difference between Test Scenarios and Test Cases is crucial. The way you organize these testing documents directly impacts test coverage, defect tracking, and the overall efficiency of your testing process. Getting it right ensures you identify issues early and deliver higher-quality software. What are Test Scenarios? Test Scenarios focus on the "what" —they are high-level overviews of the functionality or user journey that will be tested. They lay out the big picture and provide the framework for the entire testing process. Test scenarios are typically created early in the testing cycle and are especially helpful when testing complex features involving multiple steps or user interactions. They help testers understand the main features or behaviours that need validation. Key Features of Test Scenarios : They provide a roadmap for testing, guiding testers on what to va...

Understanding HTTP Response Status Codes

Image
As a quality assurance professional, understanding HTTP response codes is essential, especially when testing APIs or web applications . These codes provide vital information about the status of requests, helping you identify issues quickly. In this post, we’ll break down what each response code means, why it matters, and how you can use it for effective testing. HTTP response codes are divided into five categories: informational, success, redirection, client error, and server error. While there are many codes in each category, the most common ones you'll encounter are 200 , 404 , and 500 . 1xx – Informational Responses You’ll rarely encounter these during typical testing, unless you're working with proxy servers or handling long-running requests . These responses simply indicate that the server has received the request and is processing it. 100 : Continue — The server has received the request headers, and the client should proceed with sending the request body. 101 : Switchi...

Understanding Severity vs. Priority

Image
As a software tester, one of the most essential skills you’ll develop is the ability to distinguish between Severity and Priority when logging defects. Knowing how to assess and articulate both concepts ensures that bugs are fixed in the right order and with the appropriate level of urgency. Let’s dive into each term and explore how to distinguish between them effectively. What is Severity? Severity refers to the technical impact of a defect on the product’s functionality. In simple terms, it’s all about how severely the defect affects the application and its features. The higher the severity, the more critical the issue is to the system’s core functionality. Common Severity Levels : Critical Severity : The application crashes, or essential features become completely unavailable. Think of a 500 error that stops users from completing their journey. Major Severity : A significant issue that disrupts functionality, but the application is still usable. For example, a key feature is bro...